public inbox for linux-mmc@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mmc: meson-gx: work around broken SDIO with certain WiFi chips
@ 2017-06-08 18:43 Heiner Kallweit
  2017-06-09 22:06 ` Martin Blumenstingl
  0 siblings, 1 reply; 4+ messages in thread
From: Heiner Kallweit @ 2017-06-08 18:43 UTC (permalink / raw)
  To: Kevin Hilman, Ulf Hansson
  Cc: open list:ARM/Amlogic Meson..., Martin Blumenstingl,
	linux-mmc@vger.kernel.org

There have been reports about SDIO failing with certain WiFi chips in
descriptor chain mode. SD / eMMC are working fine.

So let's fall back to bounce buffer mode for command SD_IO_RW_EXTENDED.
This was reported to fix this error.

Fixes: 79ed05e329c3 "mmc: meson-gx: add support for descriptor chain mode"
Cc: <stable@vger.kernel.org> # 4.12.x
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
 drivers/mmc/host/meson-gx-mmc.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index 1842ed34..4cdbe3c0 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -210,6 +210,15 @@ static void meson_mmc_get_transfer_mode(struct mmc_host *mmc,
 	int i;
 	bool use_desc_chain_mode = true;
 
+	/*
+	 * Broken SDIO with AP6335-based WiFi on Khadas VIM Pro has been
+	 * reported. For some strange reason this occurs in descriptor
+	 * chain mode only. So let's fall back to bounce buffer mode
+	 * for command SD_IO_RW_EXTENDED.
+	 */
+	if (mrq->cmd->opcode == SD_IO_RW_EXTENDED)
+		return;
+
 	for_each_sg(data->sg, sg, data->sg_len, i)
 		/* check for 8 byte alignment */
 		if (sg->offset & 7) {
-- 
2.13.0


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] mmc: meson-gx: work around broken SDIO with certain WiFi chips
  2017-06-08 18:43 [PATCH] mmc: meson-gx: work around broken SDIO with certain WiFi chips Heiner Kallweit
@ 2017-06-09 22:06 ` Martin Blumenstingl
  2017-06-10 11:34   ` Heiner Kallweit
  0 siblings, 1 reply; 4+ messages in thread
From: Martin Blumenstingl @ 2017-06-09 22:06 UTC (permalink / raw)
  To: Heiner Kallweit
  Cc: Kevin Hilman, Ulf Hansson, open list:ARM/Amlogic Meson...,
	linux-mmc@vger.kernel.org

Hi Heiner,

thanks for finding a solution (it didn't even take you long)!

On Thu, Jun 8, 2017 at 8:43 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
> There have been reports about SDIO failing with certain WiFi chips in
> descriptor chain mode. SD / eMMC are working fine.
>
> So let's fall back to bounce buffer mode for command SD_IO_RW_EXTENDED.
> This was reported to fix this error.
>
> Fixes: 79ed05e329c3 "mmc: meson-gx: add support for descriptor chain mode"
> Cc: <stable@vger.kernel.org> # 4.12.x
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>

> ---
>  drivers/mmc/host/meson-gx-mmc.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
> index 1842ed34..4cdbe3c0 100644
> --- a/drivers/mmc/host/meson-gx-mmc.c
> +++ b/drivers/mmc/host/meson-gx-mmc.c
> @@ -210,6 +210,15 @@ static void meson_mmc_get_transfer_mode(struct mmc_host *mmc,
>         int i;
>         bool use_desc_chain_mode = true;
>
> +       /*
> +        * Broken SDIO with AP6335-based WiFi on Khadas VIM Pro has been
nit-pick: Khadas VIM Pro uses an Ampak AP6255 (not AP6335)

> +        * reported. For some strange reason this occurs in descriptor
> +        * chain mode only. So let's fall back to bounce buffer mode
> +        * for command SD_IO_RW_EXTENDED.
> +        */
> +       if (mrq->cmd->opcode == SD_IO_RW_EXTENDED)
> +               return;
> +
>         for_each_sg(data->sg, sg, data->sg_len, i)
>                 /* check for 8 byte alignment */
>                 if (sg->offset & 7) {
> --
> 2.13.0
>
for the record: wireless performance with this patch applied is excellent

# iperf3 --client <server ip>
Connecting to host <server ip>, port 5201
[  4] local <khadas vim ip> port 38352 connected to <server ip> port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  8.19 MBytes  68.7 Mbits/sec    0    349 KBytes
[  4]   1.00-2.00   sec  8.56 MBytes  71.8 Mbits/sec    1    287 KBytes
[  4]   2.00-3.00   sec  8.89 MBytes  74.6 Mbits/sec    0    315 KBytes
[  4]   3.00-4.00   sec  8.59 MBytes  72.1 Mbits/sec    0    344 KBytes
[  4]   4.00-5.00   sec  9.11 MBytes  76.5 Mbits/sec    0    355 KBytes
[  4]   5.00-6.00   sec  8.92 MBytes  74.8 Mbits/sec    0    356 KBytes
[  4]   6.00-7.00   sec  8.75 MBytes  73.4 Mbits/sec    0    356 KBytes
[  4]   7.00-8.00   sec  8.79 MBytes  73.7 Mbits/sec    0    356 KBytes
[  4]   8.00-9.00   sec  8.64 MBytes  72.5 Mbits/sec    0    359 KBytes
[  4]   9.00-10.00  sec  8.98 MBytes  75.3 Mbits/sec    0    366 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  87.4 MBytes  73.3 Mbits/sec    1             sender
[  4]   0.00-10.00  sec  87.0 MBytes  73.0 Mbits/sec                  receiver

iperf Done.
# iperf3 --client <server ip> -R
Connecting to host <server ip>, port 5201
Reverse mode, remote host <server ip> is sending
[  4] local <khadas vim ip> port 38356 connected to <server ip> port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  2.04 MBytes  17.1 Mbits/sec
[  4]   1.00-2.00   sec  2.17 MBytes  18.2 Mbits/sec
[  4]   2.00-3.00   sec  3.85 MBytes  32.3 Mbits/sec
[  4]   3.00-4.00   sec  7.60 MBytes  63.8 Mbits/sec
[  4]   4.00-5.00   sec  6.90 MBytes  57.9 Mbits/sec
[  4]   5.00-6.00   sec  6.46 MBytes  54.2 Mbits/sec
[  4]   6.00-7.00   sec  7.49 MBytes  62.9 Mbits/sec
[  4]   7.00-8.00   sec  7.11 MBytes  59.7 Mbits/sec
[  4]   8.00-9.00   sec  6.58 MBytes  55.2 Mbits/sec
[  4]   9.00-10.00  sec  6.83 MBytes  57.3 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  58.8 MBytes  49.3 Mbits/sec   30             sender
[  4]   0.00-10.00  sec  57.4 MBytes  48.2 Mbits/sec                  receiver

iperf Done.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] mmc: meson-gx: work around broken SDIO with certain WiFi chips
  2017-06-09 22:06 ` Martin Blumenstingl
@ 2017-06-10 11:34   ` Heiner Kallweit
  2017-06-11 20:31     ` Martin Blumenstingl
  0 siblings, 1 reply; 4+ messages in thread
From: Heiner Kallweit @ 2017-06-10 11:34 UTC (permalink / raw)
  To: Martin Blumenstingl
  Cc: Kevin Hilman, Ulf Hansson, open list:ARM/Amlogic Meson...,
	linux-mmc@vger.kernel.org

Am 10.06.2017 um 00:06 schrieb Martin Blumenstingl:
> Hi Heiner,
> 
> thanks for finding a solution (it didn't even take you long)!
> 
> On Thu, Jun 8, 2017 at 8:43 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>> There have been reports about SDIO failing with certain WiFi chips in
>> descriptor chain mode. SD / eMMC are working fine.
>>
>> So let's fall back to bounce buffer mode for command SD_IO_RW_EXTENDED.
>> This was reported to fix this error.
>>
>> Fixes: 79ed05e329c3 "mmc: meson-gx: add support for descriptor chain mode"
>> Cc: <stable@vger.kernel.org> # 4.12.x
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> 
>> ---
>>  drivers/mmc/host/meson-gx-mmc.c | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
>> index 1842ed34..4cdbe3c0 100644
>> --- a/drivers/mmc/host/meson-gx-mmc.c
>> +++ b/drivers/mmc/host/meson-gx-mmc.c
>> @@ -210,6 +210,15 @@ static void meson_mmc_get_transfer_mode(struct mmc_host *mmc,
>>         int i;
>>         bool use_desc_chain_mode = true;
>>
>> +       /*
>> +        * Broken SDIO with AP6335-based WiFi on Khadas VIM Pro has been
> nit-pick: Khadas VIM Pro uses an Ampak AP6255 (not AP6335)
> 
Uups, I obviously mixed up the device with one of the S905-based tv boxes.
Will fix it.

>> +        * reported. For some strange reason this occurs in descriptor
>> +        * chain mode only. So let's fall back to bounce buffer mode
>> +        * for command SD_IO_RW_EXTENDED.
>> +        */
>> +       if (mrq->cmd->opcode == SD_IO_RW_EXTENDED)
>> +               return;
>> +
>>         for_each_sg(data->sg, sg, data->sg_len, i)
>>                 /* check for 8 byte alignment */
>>                 if (sg->offset & 7) {
>> --
>> 2.13.0
>>
> for the record: wireless performance with this patch applied is excellent
> 
Just curious:
Do you also experience the lagging mentioned by crow?

> # iperf3 --client <server ip>
> Connecting to host <server ip>, port 5201
> [  4] local <khadas vim ip> port 38352 connected to <server ip> port 5201
> [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
> [  4]   0.00-1.00   sec  8.19 MBytes  68.7 Mbits/sec    0    349 KBytes
> [  4]   1.00-2.00   sec  8.56 MBytes  71.8 Mbits/sec    1    287 KBytes
> [  4]   2.00-3.00   sec  8.89 MBytes  74.6 Mbits/sec    0    315 KBytes
> [  4]   3.00-4.00   sec  8.59 MBytes  72.1 Mbits/sec    0    344 KBytes
> [  4]   4.00-5.00   sec  9.11 MBytes  76.5 Mbits/sec    0    355 KBytes
> [  4]   5.00-6.00   sec  8.92 MBytes  74.8 Mbits/sec    0    356 KBytes
> [  4]   6.00-7.00   sec  8.75 MBytes  73.4 Mbits/sec    0    356 KBytes
> [  4]   7.00-8.00   sec  8.79 MBytes  73.7 Mbits/sec    0    356 KBytes
> [  4]   8.00-9.00   sec  8.64 MBytes  72.5 Mbits/sec    0    359 KBytes
> [  4]   9.00-10.00  sec  8.98 MBytes  75.3 Mbits/sec    0    366 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bandwidth       Retr
> [  4]   0.00-10.00  sec  87.4 MBytes  73.3 Mbits/sec    1             sender
> [  4]   0.00-10.00  sec  87.0 MBytes  73.0 Mbits/sec                  receiver
> 
> iperf Done.
> # iperf3 --client <server ip> -R
> Connecting to host <server ip>, port 5201
> Reverse mode, remote host <server ip> is sending
> [  4] local <khadas vim ip> port 38356 connected to <server ip> port 5201
> [ ID] Interval           Transfer     Bandwidth
> [  4]   0.00-1.00   sec  2.04 MBytes  17.1 Mbits/sec
> [  4]   1.00-2.00   sec  2.17 MBytes  18.2 Mbits/sec
> [  4]   2.00-3.00   sec  3.85 MBytes  32.3 Mbits/sec
> [  4]   3.00-4.00   sec  7.60 MBytes  63.8 Mbits/sec
> [  4]   4.00-5.00   sec  6.90 MBytes  57.9 Mbits/sec
> [  4]   5.00-6.00   sec  6.46 MBytes  54.2 Mbits/sec
> [  4]   6.00-7.00   sec  7.49 MBytes  62.9 Mbits/sec
> [  4]   7.00-8.00   sec  7.11 MBytes  59.7 Mbits/sec
> [  4]   8.00-9.00   sec  6.58 MBytes  55.2 Mbits/sec
> [  4]   9.00-10.00  sec  6.83 MBytes  57.3 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bandwidth       Retr
> [  4]   0.00-10.00  sec  58.8 MBytes  49.3 Mbits/sec   30             sender
> [  4]   0.00-10.00  sec  57.4 MBytes  48.2 Mbits/sec                  receiver
> 
> iperf Done.
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] mmc: meson-gx: work around broken SDIO with certain WiFi chips
  2017-06-10 11:34   ` Heiner Kallweit
@ 2017-06-11 20:31     ` Martin Blumenstingl
  0 siblings, 0 replies; 4+ messages in thread
From: Martin Blumenstingl @ 2017-06-11 20:31 UTC (permalink / raw)
  To: Heiner Kallweit
  Cc: Kevin Hilman, Ulf Hansson, open list:ARM/Amlogic Meson...,
	linux-mmc@vger.kernel.org

On Sat, Jun 10, 2017 at 1:34 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
> Am 10.06.2017 um 00:06 schrieb Martin Blumenstingl:
>> Hi Heiner,
>>
>> thanks for finding a solution (it didn't even take you long)!
>>
>> On Thu, Jun 8, 2017 at 8:43 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>>> There have been reports about SDIO failing with certain WiFi chips in
>>> descriptor chain mode. SD / eMMC are working fine.
>>>
>>> So let's fall back to bounce buffer mode for command SD_IO_RW_EXTENDED.
>>> This was reported to fix this error.
>>>
>>> Fixes: 79ed05e329c3 "mmc: meson-gx: add support for descriptor chain mode"
>>> Cc: <stable@vger.kernel.org> # 4.12.x
>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>>
>>> ---
>>>  drivers/mmc/host/meson-gx-mmc.c | 9 +++++++++
>>>  1 file changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
>>> index 1842ed34..4cdbe3c0 100644
>>> --- a/drivers/mmc/host/meson-gx-mmc.c
>>> +++ b/drivers/mmc/host/meson-gx-mmc.c
>>> @@ -210,6 +210,15 @@ static void meson_mmc_get_transfer_mode(struct mmc_host *mmc,
>>>         int i;
>>>         bool use_desc_chain_mode = true;
>>>
>>> +       /*
>>> +        * Broken SDIO with AP6335-based WiFi on Khadas VIM Pro has been
>> nit-pick: Khadas VIM Pro uses an Ampak AP6255 (not AP6335)
>>
> Uups, I obviously mixed up the device with one of the S905-based tv boxes.
> Will fix it.
>
>>> +        * reported. For some strange reason this occurs in descriptor
>>> +        * chain mode only. So let's fall back to bounce buffer mode
>>> +        * for command SD_IO_RW_EXTENDED.
>>> +        */
>>> +       if (mrq->cmd->opcode == SD_IO_RW_EXTENDED)
>>> +               return;
>>> +
>>>         for_each_sg(data->sg, sg, data->sg_len, i)
>>>                 /* check for 8 byte alignment */
>>>                 if (sg->offset & 7) {
>>> --
>>> 2.13.0
>>>
>> for the record: wireless performance with this patch applied is excellent
>>
> Just curious:
> Do you also experience the lagging mentioned by crow?
I just made a quick ping test:

Khadas VIM Pro (AP6255, directly connected to my 802.11ac wifi AP):
30 packets transmitted, 30 received, 0% packet loss, time 29057ms
rtt min/avg/max/mdev = 2.263/13.614/20.336/4.583 ms

on my workstation (connected via ethernet to a router running LEDE,
which is also connected via wifi to my 802.11ac wifi AP):
30 packets transmitted, 30 received, 0% packet loss, time 29040ms
rtt min/avg/max/mdev = 1.040/1.405/5.977/0.862 ms

(distance between my Khadas VIM Pro and my AP vs the router running
LEDE vs my AP is roughly the same, less than 50cm difference in
distance, no additional walls etc.)

so the delay is definitely "higher" than with other devices, but an
average pin time of ~14ms still doesn't seem to cause any lags for me

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-06-11 20:32 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-06-08 18:43 [PATCH] mmc: meson-gx: work around broken SDIO with certain WiFi chips Heiner Kallweit
2017-06-09 22:06 ` Martin Blumenstingl
2017-06-10 11:34   ` Heiner Kallweit
2017-06-11 20:31     ` Martin Blumenstingl

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox