<minute>
tried to run the sdio card now on 12,25,50mhz and all freqs lead to the same issue
<phh>
minute: fyi the conclusion of that thread is that mainline bcm driver is capped and sdio bus wasn't the limiting factor at that point
<minute>
phh: ah thx
<phh>
that being said, we still had like 8MB/s on mainline bcm driver, that's maybe enough for your usage?
<phh>
getting vendor driver to run will require quite some work, because you need to plug in various gpio code manually
<minute>
phh: yeah, in case it wasn't clear, i have a different problem with a different sdio card, but found the same weird stuff in the sdio {} note
<minute>
node
<minute>
phh: i get corrupted rx skbs with a311d and rtl8822cs
<minute>
i couldn't get the vendor driver to do anything useful though
<phh>
ah ok
<minute>
will need to boot the vendor distro later
<phh>
well, at one point I had an issue where wifi would work for ~ 100MB and after that I would lose any communication with the chip...
<minute>
oof
<phh>
but my colleague with almost exactly the same setup didn't...
<minute>
hmm, so the chip could be broken?
<phh>
na
<phh>
we're running fine on vendor kernel
<minute>
ah.
<minute>
xdarklight: lets say my sdio is running at 25mhz (high-speed). shouldn't this rate be reflected somewhere in clk_summary? because it isn't. all the sd_emmc_..._sel show 24mhz
<minute>
ah, not true, it's ffe03000.mmc#div i guess
<minute>
(that shows 25mhz)
<minute>
i was thinking that if the problem shows up only for large packets, there might be some clock skew
<minute>
but large packets maybe just increase the chance for some bit errors... but why wouldn't those be caught by CRC?
<phh>
CRC could be offloaded to wifi firmware
<minute>
hmm
<minute>
i.e. what happens is, i trace the rx buffer lengths in the interrupt handler. normally it's lots of small ones, everything is fine, i can ping etc. if i start a bigger transfer (http), i can see a big buffer (~16kb for example) and it goes boom, skb corrupt, kernel oops
<phh>
so uh, on our chip we have a workaround because the sdio controller is broken, maybe yours need it too?
<phh>
"amlogic,dram-access-quirk;" in the mmc dt node
<minute>
ah yeah, but that is in there
<phh>
ok. could still be related, because in that mode, the sdio packet size is 4kB
<minute>
oh hm
<minute>
so it shouldn't ever be >4kB?
<phh>
ah no it's actually limited to 1536
<minute>
huh.
<phh>
in drivers/mmc/host/meson-gx-mmc.c se max_segs and max_blk_count
<minute>
ok but would this be transparent to the wifi driver?
<minute>
i mean, i get the transfer length from a register from the module
<phh>
well, that's where my limited knowledge of many things stop
<minute>
ok
<narmstrong>
yep it's also broken on the a311d, but it will only limit the bandwidth
<minute>
i wonder if that explains the max_req_size = <0x400>; in vendor dts
<minute>
this way they limit sdio bulk reads to 1024 bytes?
ebach has quit [Ping timeout: 240 seconds]
fiii has quit [Quit: Ping timeout (120 seconds)]
fiii has joined #linux-amlogic
<xdarklight>
minute: if I had to guess then it's a register we're not setting correctly inside the rtl8822cs driver. so I'm curious: did you manage to get the vendor wifi driver work on mainline Linux?
<xdarklight>
minute: I also think that the hardware limitations you mentioned are irrelevant because I've been testing on a SM1 (S905X3) SoC which should have the same MMC/SD/SDIO controller IP (and IP revision) and everything works fine there with an RTL8822CS module (the only difference I can see so far is that I'm running SDIO 3 speeds, while you're on high-speed mode)
<minute>
xdarklight: yep, my guess is that we can only do high-speed because the module is connected with 3v3 io only
<minute>
xdarklight: interesting @ register. i will conclude my experiments and then try to boot vendor linux
<xdarklight>
minute: can you help me find the vendor driver that's used on the Banana PI boards?
<xdarklight>
I can't find any other place where it's checking for the SDIO version (which is related to the clock speed) so I'm not sure what we're missing (which makes me curious...)
<xdarklight>
if I had to guess then VDD_GPIO would be my first choice
<minute>
well, the SD_D* pins measure ~3.3V
<xdarklight>
that's suspicious...
<minute>
VDD_GPIO is also 3v3...
<minute>
that's bizarre, so they're running it somehow at 200mhz but UHS
<minute>
at 3v3 i mean
<xdarklight>
I have no idea how/why that works
<minute>
secret sauce
<xdarklight>
maybe patch up mainline to mimic the same thing, then ask the MMC maintainer (Ulf) for some advice. maybe it's out of spec but not enough out of spec that it breaks (so we could add a quirk)
<minute>
yep, gonna do that right now before i head home
<minute>
xdarklight: yep, card is now detected as ultra high speed
<minute>
at 200mhz clock
<xdarklight>
now let's push some traffic :-)
<minute>
xdarklight: skb_panic unfortunately still a thing
<xdarklight>
what the...
<minute>
so there must be more.
<xdarklight>
yep, although that's not for today anymore as I'm going to bed now. good night
<minute>
good night, thanks for the help!
<minute>
i'm beginning to wonder if this is some kind of regression vs the 6.0 kernel they are using