<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]
<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?
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>
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]
<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