ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
gpiccoli has quit [Quit: Quit...]
balrog has quit [Read error: Connection reset by peer]
balrog has joined #armlinux
gdd has quit [Ping timeout: 265 seconds]
gdd has joined #armlinux
Grimler has quit [Ping timeout: 248 seconds]
Grimler has joined #armlinux
heat_ has joined #armlinux
heat has quit [Ping timeout: 246 seconds]
apritzel_ has quit [Ping timeout: 255 seconds]
heat_ is now known as heat
Guest5802 has quit [Ping timeout: 276 seconds]
nsc has joined #armlinux
nsc is now known as Guest319
jclsn has quit [Ping timeout: 246 seconds]
jclsn has joined #armlinux
robmur01 has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
sudeepholla has quit [Ping timeout: 248 seconds]
apritzel has quit [Ping timeout: 265 seconds]
robmur01 has joined #armlinux
apritzel has joined #armlinux
sudeepholla has joined #armlinux
amitk has joined #armlinux
heat has quit [Remote host closed the connection]
torez has joined #armlinux
torez has quit [Client Quit]
apritzel_ has joined #armlinux
apritzel_ has quit [Ping timeout: 246 seconds]
sszy has joined #armlinux
frieder has joined #armlinux
guillaume_g has joined #armlinux
iivanov has joined #armlinux
headless has joined #armlinux
viorel_suman has joined #armlinux
prabhakarlad has joined #armlinux
perr has joined #armlinux
perr has quit [Quit: Leaving]
sszy has quit [Read error: Connection reset by peer]
sszy has joined #armlinux
sudeepholla has quit [Read error: Connection reset by peer]
sudeepholla has joined #armlinux
amitk_ has joined #armlinux
amitk has quit [Ping timeout: 265 seconds]
heat has joined #armlinux
Grimler has quit [Ping timeout: 268 seconds]
cbeznea has joined #armlinux
marc|gonzalez has joined #armlinux
heat has quit [Remote host closed the connection]
<marc|gonzalez>
narmstrong: thanks for you explanation on the S905X2 SDIO situation
<narmstrong>
marc|gonzalez: you’re welcome !
<marc|gonzalez>
Do you think it has been fixed in the upcoming X4?
<narmstrong>
marc|gonzalez: it was fixed for SM1 (S905X3) so yes
<narmstrong>
But I’m sure they added some other funny bugs :-)
<marc|gonzalez>
Good to know. Also I'm investigating high CPU use when running full tilt
<marc|gonzalez>
Vendor kernel consumes around 40% for 220 Mbps, which I find quite excessive
<marc|gonzalez>
Mainline kernel consumes about 20% (need to run perf for finer stat) for 90 Mbps
<marc|gonzalez>
Is that due to SDIO overhead? Is the CPU use better when the WiFi chip is connected over PCIe?
heat has joined #armlinux
<narmstrong>
Yep since you do some extra copies in the scratch buffer it adds some overhead, the normal case is to use the internal scatter gather dma which avoids all copies
<narmstrong>
For sure PCIe would be much faster and consume even les than sdio
<marc|gonzalez>
Didn't you say that the vendor implementation avoids the scratch buffer?
elastic_1 has joined #armlinux
elastic_dog has quit [Killed (zinc.libera.chat (Nickname regained by services))]
elastic_1 is now known as elastic_dog
<narmstrong>
Yes by using a fully functional mmc controller
<marc|gonzalez>
narmstrong: I don't understand :(
<narmstrong>
The vendor tree uses a special trick to connect the SDIO pads to the sdcard controller, so they don’t have to force usage of the seam scratch buffer and so it uses the full capacity of the sdcard dma controller which enables zero copies
<marc|gonzalez>
yet the vendor implementation burns 40% of a 4-core system (160% out of 400%) when pushing 220 Mbps.
<marc|gonzalez>
I thought there was something broken in their implementation... /me confused
<narmstrong>
SDIO consumes a lot of cpu time, so it’s expected
<narmstrong>
Wifi over Pcie would consume a lot less cpu time
gpiccoli has joined #armlinux
<narmstrong>
marc|gonzalez: chewitt is right about the SDIO mode and driver, vendor driver would be probably faster, but you'll never achieve 220mbps with upstream due to the bounce buffer even with SDR104 and the vendor driver
<marc|gonzalez>
narmstrong: if I bump the clock from 100 to 200 MHz, performance would improve, right?
<narmstrong>
marc|gonzalez: probably, not sure if SDR104 at 200MHz is stable enough upstream
<marc|gonzalez>
narmstrong: current node is cap-sd-highspeed; sd-uhs-sdr50; max-frequency = <100000000>; ... I can't just double the frequency?
<marc|gonzalez>
(I don't know much about MMC/SDIO)
<narmstrong>
marc|gonzalez: you'll need to add sd-uhs-sdr104 aswell because 200Mhz is only valid in SDR104 mode
<marc|gonzalez>
Doh! Makes sense :)
<narmstrong>
but beware, it may be unstable or even broken...
<marc|gonzalez>
Roger that, it would be just for a quick benchmark
<narmstrong>
the Amlogic MMC controllers are very buggy, and required some weird very complex code to tune the SDIO lines at high speed
<marc|gonzalez>
SoC black magic is infuriating
<marc|gonzalez>
I used to work for Sigma Designs. Their last SoC was so buggy it bankrupted the company.
<marc|gonzalez>
Turns out the machine at the foundry was "incorrectly calibrated" WTF?
<Xogium>
ouch
<Xogium>
narmstrong: I remember that issue with the mmc lines haha I experienced it myself !
<narmstrong>
at my previous, previous company the foundry "forgot to pass some tests on the wafers"
<marc|gonzalez>
"oops, sry :)"
<Xogium>
it appeared to run well for a while, then you'd go and delete some folder, do ls, notice it was still around and... Uh oh. That's when all hell broke looss
<narmstrong>
well, the yield was very good! until we told them we had millions of buggy chips :-]
<bjdooks>
"but you can work around that in software, right?"
<Xogium>
darn
<marc|gonzalez>
On tango4, the PCIe root hub had a bug so severe that Bjorn H the maintainer only accepted to take it if it was marked with BROKEN_BEYOND_ANY_HOPE