call trace on Khadas VIM Pro with AP6255 WiFi

Heiner Kallweit hkallweit1 at
Mon Jun 5 09:12:11 PDT 2017

Am 05.06.2017 um 01:03 schrieb Martin Blumenstingl:
> Hi Heiner,
> On Sun, Jun 4, 2017 at 9:11 PM, Heiner Kallweit <hkallweit1 at> wrote:
>> Am 04.06.2017 um 17:59 schrieb crow:
>>> Hi,
>>> Posting to list as requested. I get call trace when using WiFi on Khadas VIM Pro, which comes with an AP6255. Firstly i wrote about this directly to Martin Blumenstingl, and he pointed me for this to post here.
>>> This looks like a bug in the meson-gx-mmc.c (SD/SDIO/eMMC) driver [1]. Martin last successful test was with kernel 2.11.
>>> How to reproduce this:
>>> mainline kernel 4.12.0-rc3 (using ArchLinuxARM arm8v generic rootfs)
>>> Khadas VIM Pro nvram file [2]
>> I have been in contact with others using AP6255-based SDIO WiFi with this driver. After the recent version of the driver
>> was released I didn't hear back from them so I assume WiFi is working fine for them.
> I've also seen the errors with older version of your patches where
> SDIO wifi would fail to initialize (or load the firmware).
> I just tried it myself on a Khadas VIM Pro (= the one with AP6255):
> - wifi firmware loads fine
> - as soon as I put traffic on the wireless interface (iperf3 -c <ip of
> server>) I hit the same WARN_ON as crow (it happens almost instantly
> after I start iperf3)
>> The firmware image you use seems to be for Android. Not sure which firmware the others are using.
>> This might be a potential reason for the issue.
>>> Enable WiFI (connected to 5GHZ AP)
>>> just do an SSH to Khadas VIM Pro device and you will get these call trace [3] , eventually you get login prompt but it is very slow login.
>> The log shows that first HW reports a failed write transfer (status 0x0100) and then an unexpected interrupt occurs (host->cmd being NULL).
>> Apart from the firmware the failed transfer might also be caused by e.g. a too high frequency.
> # cat /sys/kernel/debug/mmc2/ios
> clock:          50000000 Hz
> actual clock:   50000000 Hz
> vdd:            21 (3.3 ~ 3.4 V)
> bus mode:       2 (push-pull)
> chip select:    0 (don't care)
> power mode:     2 (on)
> bus width:      2 (4 bits)
> timing spec:    2 (sd high-speed)
> signal voltage: 0 (3.30 V)
> driver type:    0 (driver type B)
> The .dts from Khadas (based on the Amlogic kernel) uses f_max 200000000
>> Would be interesting to hear what's the latest kernel version (or even better: a bisect) working for you.
> I don't really remember what the last actual working version was, but
> I can try to bisect it tomorrow

This would be great.

>> I'm using a Odroid-C2 where SDIO isn't available, so I'm not able to test.
> are you from Germany? I can give you a Khadas VIM so you can test this
> yourself for a few weeks if you want
> what just caught my eye though is the max_req_size calculation: [0]
> Amlogic's kernel uses max_req_size = <0x20000>; /**128KB*/ for the SD
> and SDIO controllers, but max_req_size = <0x20000>; /**256KB*/ for the
> eMMC controller
> it caught my eye because (some time ago) I found out that there are
> two different hardware buffer sizes for the UART FIFO buffer (see page
> 309 of the public S905 datasheet, UART0 has a 128 byte buffer, while
> all other UARTs only have a 64 byte buffer)
In the logs provided by crow the issue happened with small writes
(just one or two blocks), so most likely the problem here has a
different nature.

In general I'm wondering whether the mainline Meson GX mmc driver ever
fully supported SDIO. For example SDIO interrupts aren't supported.

Before submitting the initial version of the driver, did you test also
SDIO or just SD/eMMC?

> Regards,
> Martin
> [0]

More information about the linux-amlogic mailing list