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
<Xogium>
oomf. Wow
<Xogium>
that's down right bad
<marc|gonzalez>
What was cool was that I worked with the VHDL devs, so I participated in the mask fix :)
<Xogium>
:D
<ardb>
most of the synopsys and cadence root complexes we support are hopeless
<Xogium>
vhdl looks kind of fancy
<marc|gonzalez>
ardb: I think the design was based off a synopsys IP block IIRC
<ardb>
well 'complex' is too generous
<ardb>
marc|gonzalez: of course, they all are
<Xogium>
meanwhile I toy with stm32 and I've never experienced any real issue beside an oops because of the fairly new driver for hw crypto
<marc|gonzalez>
I had a 5000$ riser card to test the conformance. It would bend to the point that it almost snapped in half
<Xogium>
holy
headless has quit [Quit: Konversation terminated!]
<marc|gonzalez>
And in the end, I think we just misplaced that card :(
<marc|gonzalez>
whoever would steal that piece of expensive garbage...?
<Xogium>
x)
heat_ has joined #armlinux
heat has quit [Ping timeout: 246 seconds]
monstr has joined #armlinux
elastic_dog has quit [Remote host closed the connection]
elastic_dog has joined #armlinux
cbeznea has quit [Quit: Leaving.]
mcoquelin has quit [Ping timeout: 256 seconds]
heat has joined #armlinux
heat_ has quit [Read error: Connection reset by peer]
monstr has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
mcoquelin has joined #armlinux
<marc|gonzalez>
narmstrong: khilman: I stumbled upon something that blows my mind. (Never expected it.) The order of declaration of DT nodes has an influence on the probe timing at boot...?!?!?!
<marc|gonzalez>
Basically, I tried factorizing a few nodes away in a DTSI file, and this moved the init back. I reverted my factorization patch, and the init went back to the original order...
<broonie>
marc|gonzalez: Think about how you'd naively implement probing a list of devices...
<marc|gonzalez>
broonie: in order of appearance?
<broonie>
Exactly, just walk the list.
<marc|gonzalez>
broonie: so I'm not crazy? The order does influence the probe?
<broonie>
Yes.
<marc|gonzalez>
But, since the compiler knows the dependences, can't it reorder the nodes to minimize boot time?
<broonie>
You can't rely on this (eg, we have support for async probe and fwlink dependencies might reorder things).
<broonie>
There's some stuff that might do that at runtime. The compiler doesn't really understand what it's compiling.
<marc|gonzalez>
I had never thought about that...
<marc|gonzalez>
and it has a pretty measurable effect: one DT boots 10% than the other (1.7s vs 1.5s)