rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi - *only registered users can talk*
Andy-D has quit [Ping timeout: 250 seconds]
Andy-D has joined #linux-sunxi
vagrantc has quit [Ping timeout: 250 seconds]
vagrantc_ is now known as vagrantc
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 250 seconds]
vagrantc has quit [Quit: leaving]
Andy-D has quit [Ping timeout: 250 seconds]
dev1990 has quit [Quit: Konversation terminated!]
kaspter has quit [Quit: kaspter]
kaspter has joined #linux-sunxi
lynxis has quit [Quit: No Ping reply in 180 seconds.]
agraf has quit [Ping timeout: 244 seconds]
lynxis has joined #linux-sunxi
agraf has joined #linux-sunxi
lynxis has quit [Quit: No Ping reply in 180 seconds.]
lynxis has joined #linux-sunxi
victhor has quit [Ping timeout: 240 seconds]
lynxis has quit [Quit: No Ping reply in 180 seconds.]
lynxis has joined #linux-sunxi
kaspter has quit [Quit: kaspter]
angelo_ts has quit [Ping timeout: 244 seconds]
angelo_ts has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
leviathanch has joined #linux-sunxi
NeuroScr has quit [Quit: NeuroScr]
Jojo1411_22 has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
<wens> I still remember when we upgraded a server to a newer CPU with AES-NI, the drop in CPU usage was substantial
lynxis has quit [Quit: No Ping reply in 180 seconds.]
lynxis has joined #linux-sunxi
NeuroScr has joined #linux-sunxi
lurchi_ is now known as lurchi__
_whitelogger has joined #linux-sunxi
lynxis has quit [Quit: No Ping reply in 180 seconds.]
lynxis has joined #linux-sunxi
lynxis has quit [Quit: No Ping reply in 180 seconds.]
lynxis has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
lynxis has quit [Quit: No Ping reply in 180 seconds.]
lynxis has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
lynxis has quit [Quit: No Ping reply in 180 seconds.]
lynxis has joined #linux-sunxi
IgorPec has joined #linux-sunxi
nuuuciano has quit [Ping timeout: 246 seconds]
NeuroScr has quit [Quit: NeuroScr]
leviathanch has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
paulliu has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 245 seconds]
pmpp has joined #linux-sunxi
pmpp_ has quit [Ping timeout: 245 seconds]
f0xx has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 246 seconds]
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 250 seconds]
Putti has joined #linux-sunxi
[7] has quit [Ping timeout: 250 seconds]
TheSeven has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
Putti has quit [Ping timeout: 246 seconds]
IgorPec has quit [Ping timeout: 245 seconds]
clemens3 has joined #linux-sunxi
IgorPec has joined #linux-sunxi
clemens3 has quit [Ping timeout: 250 seconds]
clemens3 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 246 seconds]
yann has quit [Ping timeout: 272 seconds]
tnovotny has joined #linux-sunxi
Rafael1980 has joined #linux-sunxi
selfbg has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
f0xx has quit [Ping timeout: 245 seconds]
afaerber has quit [Quit: Leaving]
victhor has joined #linux-sunxi
f0xx has joined #linux-sunxi
afaerber has joined #linux-sunxi
victhor has quit [Ping timeout: 258 seconds]
SergiusUA has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
Andy-D has joined #linux-sunxi
yann has joined #linux-sunxi
<willmore> Yep, it's at least a 10x improvement.
<willmore> I did some testing back when IVB came out and the difference was "I guess if the whole CPU is doing crypto, then it can keep up with a laptop hard drive..." to "Wish I had a 10GigE port so I could stress this.."
tnovotny has joined #linux-sunxi
yann has quit [Read error: Connection reset by peer]
<KotCzarny> but isnt it what linus said? once it's in cpu and using caches, its worth it
<mru> any (decent) accelerator is helpful if the CPU has other things it should be doing
<mru> even if the accelerator is slower than the CPU at doing whatever it does
<wens> that's assuming the accelerator pipeline can keep up?
<mru> it always depends on the total system load
<wens> for something like a web load balancer or streaming server, in-cpu is probably the best, unless you can shelve out extra for accelerated network cards
<mru> right, since in that case there's little other cpu load
<mru> if the cpu is doing some heavy processing to generate whatever data is being encrypted, offloading it can benefit as long as the accelerator keeps up with the data rate
<mru> if it's too slow even for that, you're better off doing it on the cpu
nuuuciano has joined #linux-sunxi
nuuuciano has quit [Remote host closed the connection]
airwind has joined #linux-sunxi
nuuuciano has joined #linux-sunxi
mhlavink has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
mhlavink has joined #linux-sunxi
<willmore> As long as the crypto doesn't require another data transfer than is already required, then it can be useful, but if it requires an extra data transfer, then it's probably going to be a loss these days.
<willmore> And that does assume that it's sanely designed such that it can keep up with the device speed--SATA for a storage controller, line speed for a network controller, etc.
<mru> it only needs to be as fast as the slowest part of the chain
AneoX_ has joined #linux-sunxi
chewitt has joined #linux-sunxi
AneoX has quit [Ping timeout: 245 seconds]
<willmore> Which, unless someone messed up, is going to be the attached storage, network, etc.
<willmore> But latency is still an issue.
<mru> depends on the application
<mru> storate/network isn't always the bottleneck
<willmore> It's true that there may be applications that aren't latency sensitive, but they're not the norm.
<mru> as I said, if the data is the result of a slow computation, you don't want to burden the cpu with also doing encryption
<willmore> The range of applications that require that much CPU and produce enough data such that having the CPU also do the crypto is very small. And given the speed at which CPUs can do crypto, the performance difference will ony be a few percent. Better to dedicate those resources to a better CPU.
<mru> fine, have it your way
<mru> everything is a web server
<willmore> The arguement here isn't "is it good to have peripherials that can do crypto", but "does it make sense to have a dedicated crypto unit that requires setup and extra data transfers".
<mru> the answer is "sometimes"
<willmore> Especially when the crypto unit is slow--in the range of a CPU core worth of throughput.
afaerber has quit [Quit: Leaving]
reinforce has joined #linux-sunxi
<willmore> The answer is "only if the CPU is freakishly slow". Otherwise the CPU will wast more time setting up the crypto, waiting for it to transfer, and having its caches trashed by the DMA.
<willmore> Which is to say "almost never"
<mru> you're assuming the cpu needs to read back the encrypted data
<willmore> So Linus's assertion is that it makes little sense to invest a lot of infrastructure and code to support that case. Especially if the architecture that yields prevents other more common and more efficient uses of crypto.
dddddd has joined #linux-sunxi
<willmore> No, I'm really not.
<willmore> On systems weak enough to worry about the small overhead that the cyrpto will add, main memory bandwidth is also a concern.
<mru> you really do like generalisations
<willmore> Do you have a specific scenario you want to discuss?
<mru> no, but I can imagine them
<mru> apparently you cannot
<willmore> Sorry, I live in reality.
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
SergiusUA has quit [Ping timeout: 250 seconds]
kaspter has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
fkluknav has quit [Quit: ZNC 1.6.3 - http://znc.in]
fkluknav has joined #linux-sunxi
camh has quit [Ping timeout: 244 seconds]
camh has joined #linux-sunxi
chewitt has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-sunxi
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #linux-sunxi
fkluknav has quit [Remote host closed the connection]
fkluknav has joined #linux-sunxi
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #linux-sunxi
f0xx has quit [Ping timeout: 250 seconds]
voodoovood has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
camh1 has joined #linux-sunxi
camh has quit [Ping timeout: 245 seconds]
afaerber has joined #linux-sunxi
lurchi_ is now known as lurchi__
chewitt has quit [Remote host closed the connection]
lynxis has quit [Read error: Connection reset by peer]
DonkeyHotei has quit [Read error: Connection reset by peer]
DonkeyHotei has joined #linux-sunxi
lynxis has joined #linux-sunxi
Andy-D has quit [Ping timeout: 258 seconds]
selfbg has quit [Remote host closed the connection]
<ElBarto> is the sram "mux controller" documented somewhere ? (for A64)
<ElBarto> I need to make a driver for FreeBSD so we don't rely on u-boot for assigning the sram to the DE
f0xx has joined #linux-sunxi
ashleyk has joined #linux-sunxi
nuuuciano has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
nuuuciano has joined #linux-sunxi
victhor has joined #linux-sunxi
nuuuciano has quit [Read error: Connection timed out]
clemens3 has quit [Ping timeout: 245 seconds]
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 250 seconds]
Mr__Anderson has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
dev1990 has joined #linux-sunxi
aalm has quit [Quit: xyz 2.3]
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
Jojo1411_73 has joined #linux-sunxi
Jojo1411_73 has left #linux-sunxi [#linux-sunxi]
Jojo1411_73 has joined #linux-sunxi
shfil has joined #linux-sunxi
Jojo1411_73 has left #linux-sunxi [#linux-sunxi]
Jojo1411_73 has joined #linux-sunxi
<Jojo1411_73> Hello. I try to get hdmi audio working on my OrangePi PC (H3) with armbian mainline kernel. As I found out it's still not officially supported but there are some forks with patches included, that should work (https://github.com/megous/linux/tree/orange-pi-4.19). Is it possible to get it working or do I have to go back to legacy?
Andy-D has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
sutke1178 has joined #linux-sunxi
sutke1178 has quit [Max SendQ exceeded]
sutke1178 has joined #linux-sunxi
afaerber has quit [Quit: Leaving]
Putti has joined #linux-sunxi
nuuuciano has joined #linux-sunxi
<KotCzarny> in libreelec hdmi audio works
<KotCzarny> so its definitely possible
<KotCzarny> so you might check their kernel patches
<KotCzarny> patches in devices and linux subdirs
nuuuciano has quit [Read error: Connection timed out]
scelestic has quit [Remote host closed the connection]
<vagrantc> so i can't seem to get linux 5.x to display on the pinebook ... i've got a 4.20.x and 4.19.x with some backported patches working just fine
<anarsoul> :)
<anarsoul> I've already responded several times about that
<anarsoul> vagrantc: ^^
nuuuciano has joined #linux-sunxi
<anarsoul> I have no idea why it didn't make into 5.0, probably Mark forgot to send pull req
<vagrantc> anarsoul: is it in next?
<anarsoul> yes
<anarsoul> it's in 5.1
<vagrantc> ok, then i should be able to get it into debian
<vagrantc> anarsoul: sometimes my irc client has been crashing, sorry you keep re-answering and i keep missing it :/
<vagrantc> or rather, my pinebook keeps crashing :(
<anarsoul> :(
<vagrantc> hopefully 5.0 will be more stable than my hacked up 4.19.x/4.20.x
<vagrantc> support in debian buster is going to be so-so ... it'll run, but will probably want a newer kernel
clemens3 has joined #linux-sunxi
<anarsoul> vagrantc: well, with 5.0 you'll get audio
sutke1178 has quit [Quit: Leaving]
sutke1178 has joined #linux-sunxi
NeuroScr has joined #linux-sunxi
sutke1178 has quit [Client Quit]
sutke1178 has joined #linux-sunxi
vagrantc_ has joined #linux-sunxi
lkcl has quit [Read error: Connection reset by peer]
wrmyrx has joined #linux-sunxi
nuuuciano has quit [Read error: Connection timed out]
<vagrantc> anarsoul: and battery status
<anarsoul> right
<anarsoul> and faster charging if you poke current limits in sysfs :)
<vagrantc> oh!
<vagrantc> i've sometimes been surprised at how slow it charges
<vagrantc> i had hoped to get those backported to 4.19.x for debian buster ... but it proved either too invasive for this late in the release cycle
<anarsoul> it still will be slow, but a bit faster
lkcl has joined #linux-sunxi
nuuuciano has joined #linux-sunxi
nuuuciano has quit [Ping timeout: 250 seconds]
nuuuciano has joined #linux-sunxi
sunshavi has quit [Read error: Connection reset by peer]
scelestic has joined #linux-sunxi
sunshavi has joined #linux-sunxi
<vagrantc_> anarsoul: does that patch depend on some of the other fixes in axp20x regulator?
Mandragor has quit [Ping timeout: 250 seconds]
Mandragor has joined #linux-sunxi
aalm has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
camh1 has quit [Ping timeout: 268 seconds]
<Jojo1411_73> @KotCzarny Thanks for your help! Do you think, this patch (https://github.com/jernejsk/LibreELEC.tv/blob/hw_dec_ffmpeg/projects/Allwinner/patches/linux/0001-hdmi-sound-improvements.patch) should do the trick? How can I integrate it in armbian?
<KotCzarny> you can always try compiling vanilla 5.0.x with that patch and seeing if it's enough for your needs
<anarsoul> vagrantc_: nope
<vagrantc_> KotCzarny: basically what i'm doing
<vagrantc_> but anarsoul's "nope" adds greater confidence :)
<anarsoul> vagrantc_: I answered in your question about axp20x regulator fix
<anarsoul> s/in/on
<vagrantc_> yes, that's how i interpreted it
<vagrantc_> will see if it works for me in a few
camh1 has joined #linux-sunxi
f0xx has quit [Ping timeout: 246 seconds]
camh2 has joined #linux-sunxi
camh1 has quit [Ping timeout: 250 seconds]
shfil has quit [Quit: Connection closed for inactivity]
* vagrantc reboots to try new kernel
vagrantc has quit [Quit: leaving]
vagrantc_ is now known as vagrantc
vagrantc_ has joined #linux-sunxi
<vagrantc_> success!
<vagrantc_> anarsoul: many thanks!
<anarsoul> vagrantc: no problem
<vagrantc_> seems like a simple enough patch it could go through the stable fixes process
<vagrantc_> seems i'll need to crack open the pinebook and flip the serial console switch to test sound support ... and enable the modules in the debian kenrel
tllim has joined #linux-sunxi
vagrantc_ has quit [Quit: leaving]
MangyDog has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 245 seconds]
netlynx has quit [Quit: Ex-Chat]
MangyDog has quit [Remote host closed the connection]
Mangy_Dog has joined #linux-sunxi
<anarsoul> vagrantc: you can also try speakers
<anarsoul> lineout control in alsamixer corresponds to speaker
<anarsoul> and you want to configure it as 'mono differential'
<vagrantc> let's see ... need to enable CONFIG_SND_SUN4I_I2S at least, i'm guessing
<anarsoul> and SUN50I_CODEC_ANALOG
<anarsoul> and SUN8I_CODEC
Mandragor has quit [Ping timeout: 245 seconds]
Mandragor has joined #linux-sunxi
paulliu has quit [Quit: Leaving.]
tllim has quit [Remote host closed the connection]
tllim has joined #linux-sunxi
karlp has quit [Quit: WeeChat 2.3]
lurchi__ is now known as lurchi_
tuxd3v has joined #linux-sunxi
ashleyk has quit [Ping timeout: 256 seconds]
<pgreco> anarsoul, is https://github.com/anarsoul/linux-2.6/commit/1bd8400e92c386fec73b74363e78ce84ec077c53 related wifi not working with 5.0 in my bpi-m2u?
<anarsoul> maybe, there's couple of other commits that fix https://github.com/anarsoul/linux-2.6/commit/db4a555f7c4cfcca26ca3a4ff5f9ee9bd6a78f98 :)
<pgreco> ok, I'll track the series in patchwork.kernel.org and try all those together, thanks
vagrantc_ has joined #linux-sunxi
afaerber has joined #linux-sunxi
lynxis has quit [Quit: beaming to the mars]
lurchi_ is now known as lurchi__
lynxis has joined #linux-sunxi
wrmyrx has quit [Quit: Leaving]
tllim has quit [Remote host closed the connection]
karlp has joined #linux-sunxi
tllim has joined #linux-sunxi
tllim has quit [Remote host closed the connection]
<vagrantc> hrm. SUN8I_CODEC and SUN50I_CODEC_ANALOG are being resistant to enabling ...
lurchi__ is now known as lurchi_
<vagrantc> any hidden dependencies?
<anarsoul> try menuconfig?
<vagrantc> i don't think i've used menuconfig in probably 15 years ...
<mru> what do people use if not menuconfig?
<vagrantc> i add config options to debian/ARCH/*config and build the package
fl_0 has quit [Quit: STRG + Q]
<vagrantc> er, debian/config/ARCH/config ...
<vagrantc> which is a few layers of configurations...
Mangy_Dog has quit [Ping timeout: 244 seconds]
<vagrantc> typo SND_..._CODEC
fl_0 has joined #linux-sunxi
Putti has quit [Ping timeout: 245 seconds]
lurchi_ has quit [Read error: Connection reset by peer]
lurchi_ has joined #linux-sunxi
<vagrantc_> anarsoul: is it /sys/class/power_supply/axp20x-battery/constant_charge_current* that need adjusting to get faster charging? what limits would be ... wise.
<anarsoul> I don't remember, sorry
<anarsoul> I wouldn't set it to higher than 2A
<vagrantc_> there's also axp813-ac/input_current_limit
<anarsoul> check both?
<vagrantc_> seems to be 1.8 for constant_charge_current and 1.5 for input_current_limit
<anarsoul> looks reasonable
<vagrantc_> well, presuming i'm putting the decimal in the right place :)
karlp has quit [Quit: WeeChat 1.9.1]
<vagrantc_> they seem to ignore writes
<vagrantc_> ah well, can always tinker with that later
<vagrantc_> well, the SUN*CODEC enabled just fine when specifying the right values :)
karlp has joined #linux-sunxi
montjoie has quit [Ping timeout: 250 seconds]
karlp has quit [Quit: WeeChat 2.4]
clemens3_ has joined #linux-sunxi
clemens3 has quit [Ping timeout: 250 seconds]
karlp has joined #linux-sunxi
vagrantc_ has quit [Quit: leaving]
<vagrantc> the modules loaded, but looks like it's marked as disabled in the device-tree
<vagrantc> so no sound just yet...