> On 6 Apr 2023, at 8:35 pm, Marc Gonzalez <marc.w.gonzalez@xxxxxxx> wrote: > > On 04/04/2023 23:06, Martin Blumenstingl wrote: > >> Hi Marc, > > Hello Martin :) > >> On Tue, Apr 4, 2023 at 6:09 PM Marc Gonzalez wrote: >> >>> bus-width = <4>; >>> cap-sd-highspeed; >>> cap-mmc-highspeed; >>> max-frequency = <100000000>; >> >> I would start by comparing the bus mode. You can get it from >> /sys/kernel/debug/mmc2/ios >> On the vendor kernel it should be in /sys/kernel/debug/sdio/ios (or >> similar, I'm typing this from the top of my head). >> It will give you insights on the clock and timing that has been >> negotiated between the host and card. >> >> From this information you can get the maximum bus speed, e.g. from [0] >> Please note that any card will add overhead for communication, so bus >> speed will not be equal to wifi throughput. > > For the vendor kernel: > > /sys/kernel/debug/sdio/sdio:0001/state:0x00000001 > /sys/kernel/debug/sdio/clock:200000000 > /sys/kernel/debug/sdio/ios:clock: 200000000 Hz > /sys/kernel/debug/sdio/ios:actual clock: 199999997 Hz > /sys/kernel/debug/sdio/ios:vdd: 21 (3.3 ~ 3.4 V) > /sys/kernel/debug/sdio/ios:bus mode: 2 (push-pull) > /sys/kernel/debug/sdio/ios:chip select: 0 (don't care) > /sys/kernel/debug/sdio/ios:power mode: 1 (up) > /sys/kernel/debug/sdio/ios:bus width: 2 (4 bits) > /sys/kernel/debug/sdio/ios:timing spec: 6 (sd uhs SDR104) > /sys/kernel/debug/sdio/ios:signal voltage: 1 (1.80 V) > /sys/kernel/debug/sdio/ios:driver type: 0 (driver type B) > > > For mainline: > > /sys/kernel/debug/mmc2/mmc2:0001/state:0x00000001 > /sys/kernel/debug/mmc2/err_stats:# Command Timeout Occurred: 0 > /sys/kernel/debug/mmc2/err_stats:# Command CRC Errors Occurred: 0 > /sys/kernel/debug/mmc2/err_stats:# Data Timeout Occurred: 0 > /sys/kernel/debug/mmc2/err_stats:# Data CRC Errors Occurred: 0 > /sys/kernel/debug/mmc2/err_stats:# Auto-Cmd Error Occurred: 0 > /sys/kernel/debug/mmc2/err_stats:# ADMA Error Occurred: 0 > /sys/kernel/debug/mmc2/err_stats:# Tuning Error Occurred: 0 > /sys/kernel/debug/mmc2/err_stats:# CMDQ RED Errors: 0 > /sys/kernel/debug/mmc2/err_stats:# CMDQ GCE Errors: 0 > /sys/kernel/debug/mmc2/err_stats:# CMDQ ICCE Errors: 0 > /sys/kernel/debug/mmc2/err_stats:# Request Timedout: 0 > /sys/kernel/debug/mmc2/err_stats:# CMDQ Request Timedout: 0 > /sys/kernel/debug/mmc2/err_stats:# ICE Config Errors: 0 > /sys/kernel/debug/mmc2/err_stats:# Controller Timedout errors: 0 > /sys/kernel/debug/mmc2/err_stats:# Unexpected IRQ errors: 0 > /sys/kernel/debug/mmc2/err_state:0 > /sys/kernel/debug/mmc2/clock:100000000 > /sys/kernel/debug/mmc2/caps2:0x00040000 > /sys/kernel/debug/mmc2/caps:0x40040105 > /sys/kernel/debug/mmc2/ios:clock: 100000000 Hz > /sys/kernel/debug/mmc2/ios:actual clock: 99999999 Hz > /sys/kernel/debug/mmc2/ios:vdd: 21 (3.3 ~ 3.4 V) > /sys/kernel/debug/mmc2/ios:bus mode: 2 (push-pull) > /sys/kernel/debug/mmc2/ios:chip select: 0 (don't care) > /sys/kernel/debug/mmc2/ios:power mode: 2 (on) > /sys/kernel/debug/mmc2/ios:bus width: 2 (4 bits) > /sys/kernel/debug/mmc2/ios:timing spec: 5 (sd uhs SDR50) > /sys/kernel/debug/mmc2/ios:signal voltage: 1 (1.80 V) > /sys/kernel/debug/mmc2/ios:driver type: 0 (driver type B) > > > The clock is indeed running twice as fast on the vendor system. > And in SDR104 vs SDR50 mode. > > Adjusting mainline device tree... > > > /sys/kernel/debug/mmc2/mmc2:0001/state:0x00000001 > /sys/kernel/debug/mmc2/err_stats:# Command Timeout Occurred: 0 > /sys/kernel/debug/mmc2/err_stats:# Command CRC Errors Occurred: 0 > /sys/kernel/debug/mmc2/err_stats:# Data Timeout Occurred: 0 > /sys/kernel/debug/mmc2/err_stats:# Data CRC Errors Occurred: 0 > /sys/kernel/debug/mmc2/err_stats:# Auto-Cmd Error Occurred: 0 > /sys/kernel/debug/mmc2/err_stats:# ADMA Error Occurred: 0 > /sys/kernel/debug/mmc2/err_stats:# Tuning Error Occurred: 0 > /sys/kernel/debug/mmc2/err_stats:# CMDQ RED Errors: 0 > /sys/kernel/debug/mmc2/err_stats:# CMDQ GCE Errors: 0 > /sys/kernel/debug/mmc2/err_stats:# CMDQ ICCE Errors: 0 > /sys/kernel/debug/mmc2/err_stats:# Request Timedout: 0 > /sys/kernel/debug/mmc2/err_stats:# CMDQ Request Timedout: 0 > /sys/kernel/debug/mmc2/err_stats:# ICE Config Errors: 0 > /sys/kernel/debug/mmc2/err_stats:# Controller Timedout errors: 0 > /sys/kernel/debug/mmc2/err_stats:# Unexpected IRQ errors: 0 > /sys/kernel/debug/mmc2/err_state:0 > /sys/kernel/debug/mmc2/clock:200000000 > /sys/kernel/debug/mmc2/caps2:0x00040000 > /sys/kernel/debug/mmc2/caps:0x40080105 > /sys/kernel/debug/mmc2/ios:clock: 200000000 Hz > /sys/kernel/debug/mmc2/ios:actual clock: 199999997 Hz > /sys/kernel/debug/mmc2/ios:vdd: 21 (3.3 ~ 3.4 V) > /sys/kernel/debug/mmc2/ios:bus mode: 2 (push-pull) > /sys/kernel/debug/mmc2/ios:chip select: 0 (don't care) > /sys/kernel/debug/mmc2/ios:power mode: 2 (on) > /sys/kernel/debug/mmc2/ios:bus width: 2 (4 bits) > /sys/kernel/debug/mmc2/ios:timing spec: 6 (sd uhs SDR104) > /sys/kernel/debug/mmc2/ios:signal voltage: 1 (1.80 V) > /sys/kernel/debug/mmc2/ios:driver type: 0 (driver type B) > > > # curl -o /dev/null http://192.168.1.254:8095/fixed/1G > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 1024M 100 1024M 0 0 9747k 0 0:01:47 0:01:47 --:--:-- 9544k > > With this new setting, WiFi throughput increases 20% > (from 60 Mbps to 75 Mbps). > > (Uggg, I've been using 10^9 for the amount transferred, > but it looks to be 2^30 actually. Absolute speeds are > actually 7% higher, but doesn't change the conclusion) > > I also noticed that I reported 11 MB/s (88 Mbps) at the beginning > of this thread. This would point to a performance regression caused > by my defconfig & device tree changes :( > > >>> vendor DTS has the following child node: >>> >>> sdio { >>> pinname = "sdio"; >>> ocr_avail = <0x200080>; /**VDD voltage 3.3 ~ 3.4 */ >>> /* max_req_size = <0x20000>; */ /**128KB*/ >>> max_req_size = <0x400>; >>> card_type = <3>; >>> /* 3:sdio device(ie:sdio-wifi), >>> * 4:SD combo (IO+mem) card >>> */ >>> dmode = "pio"; >>> }; >>> >>> Maybe the vendor kernel uses the above information to "boost" >>> the performance of the SDIO-based WiFi adapter? >> >> PIO is also what we support upstream with the >> amlogic,dram-access-quirk; (which is enabled for &sd_emmc_a). >> This suggests that the pinctrl trick that Neil mentioned is not used here. >> >> I assume that the wifi driver on the vendor kernel is the brcmdhd (out >> of tree) driver, while mainline uses brcmfmac. > > Correct. > hardware/wifi/broadcom/drivers/ap6xxx/bcmdhd.100.10.545.x > vs > drivers/net/wireless/broadcom/brcm80211/brcmfmac > >> One idea that comes to my mind is to enable the >> amlogic,dram-access-quirk; (and use pio mode on the vendor kernel) for >> eMMC or SD card and then compare read/write speeds. If they are >> similar-ish then the wifi performance difference is likely caused by >> the wifi driver (or in the opposite case: if read/write speeds on >> mainline with amlogic,dram-access-quirk; perform worse than the vendor >> kernel with pio mode then it's likely that it's a meson-gx-mmc driver >> limitation). > > Thanks for the suggestion. > > Are you aware whether someone has tried running the bcmdhd driver > on mainline? https://gitlab.baylibre.com/baylibre/amlogic/atv/linux/-/commits/narmstrong/v5.1/aml/integ-5.1-bcmdhd IIRC not long after this ^ support for BCM4359 was added to brcmfmac so using bcmdhd wasn’t pursued. Neil? Christian > Thanks for the test suggestion. > >> From my work on the rtw88 SDIO wifi driver I can say that the >> meson-gx-mmc driver can push (TX direction) at least 120Mbit/s. >> I understand that this is half of what you get with the vendor kernel >> - and that this is the wrong direction (you're testing RX while I'm >> testing TX). >> The point that I want to get across is: I think nobody has the one >> answer why wifi performance is lower (personally I'm happy with having >> it work at all, performance is second). >> So it'll be a process to find the reason, and I think it requires >> being creative due to the large amounts of different code (MMC driver, >> wifi driver, additional patches...) between mainline and the vendor >> kernel. > > I really appreciate you sharing this insight. > > Regards. >
