* [PATCH] mmc: meson-gx: work around broken SDIO with certain WiFi chips
@ 2017-06-08 5:56 Heiner Kallweit
2017-06-08 6:56 ` Ulf Hansson
0 siblings, 1 reply; 12+ messages in thread
From: Heiner Kallweit @ 2017-06-08 5:56 UTC (permalink / raw)
To: linus-amlogic
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.
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] 12+ messages in thread
* [PATCH] mmc: meson-gx: work around broken SDIO with certain WiFi chips
2017-06-08 5:56 Heiner Kallweit
@ 2017-06-08 6:56 ` Ulf Hansson
2017-06-08 18:36 ` Heiner Kallweit
0 siblings, 1 reply; 12+ messages in thread
From: Ulf Hansson @ 2017-06-08 6:56 UTC (permalink / raw)
To: linus-amlogic
On 8 June 2017 at 07:56, 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.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Is this material for stable? What commit does it fix?
Please resend to linux-mmc.
Kind regards
Uffe
> ---
> 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 [flat|nested] 12+ messages in thread
* [PATCH] mmc: meson-gx: work around broken SDIO with certain WiFi chips
2017-06-08 6:56 ` Ulf Hansson
@ 2017-06-08 18:36 ` Heiner Kallweit
0 siblings, 0 replies; 12+ messages in thread
From: Heiner Kallweit @ 2017-06-08 18:36 UTC (permalink / raw)
To: linus-amlogic
Am 08.06.2017 um 08:56 schrieb Ulf Hansson:
> On 8 June 2017 at 07:56, 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.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>
> Is this material for stable? What commit does it fix?
>
> Please resend to linux-mmc.
>
Sorry, will re-send with the missing information.
Rgds, Heiner
> Kind regards
> Uffe
>
>> ---
>> 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 [flat|nested] 12+ messages in thread
* [PATCH] mmc: meson-gx: work around broken SDIO with certain WiFi chips
@ 2017-06-08 18:43 ` Heiner Kallweit
0 siblings, 0 replies; 12+ messages in thread
From: Heiner Kallweit @ 2017-06-08 18:43 UTC (permalink / raw)
To: linus-amlogic
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] 12+ messages in thread
* [PATCH] mmc: meson-gx: work around broken SDIO with certain WiFi chips
@ 2017-06-08 18:43 ` Heiner Kallweit
0 siblings, 0 replies; 12+ 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] 12+ messages in thread
* [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
-1 siblings, 0 replies; 12+ messages in thread
From: Martin Blumenstingl @ 2017-06-09 22:06 UTC (permalink / raw)
To: linus-amlogic
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] 12+ messages in thread
* Re: [PATCH] mmc: meson-gx: work around broken SDIO with certain WiFi chips
@ 2017-06-09 22:06 ` Martin Blumenstingl
0 siblings, 0 replies; 12+ 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] 12+ messages in thread
* [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
-1 siblings, 0 replies; 12+ messages in thread
From: Heiner Kallweit @ 2017-06-10 11:34 UTC (permalink / raw)
To: linus-amlogic
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] 12+ messages in thread
* Re: [PATCH] mmc: meson-gx: work around broken SDIO with certain WiFi chips
@ 2017-06-10 11:34 ` Heiner Kallweit
0 siblings, 0 replies; 12+ 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] 12+ messages in thread
* [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
-1 siblings, 0 replies; 12+ messages in thread
From: Martin Blumenstingl @ 2017-06-11 20:31 UTC (permalink / raw)
To: linus-amlogic
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] 12+ messages in thread
* Re: [PATCH] mmc: meson-gx: work around broken SDIO with certain WiFi chips
@ 2017-06-11 20:31 ` Martin Blumenstingl
0 siblings, 0 replies; 12+ 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] 12+ messages in thread
* [PATCH] mmc: meson-gx: work around broken SDIO with certain WiFi chips
2017-06-11 20:31 ` Martin Blumenstingl
(?)
@ 2017-06-15 12:36 ` crow
-1 siblings, 0 replies; 12+ messages in thread
From: crow @ 2017-06-15 12:36 UTC (permalink / raw)
To: linus-amlogic
Hi,
On Sun, Jun 11, 2017 at 10:31 PM, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> 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
Well that are nice value. My were much worse until I did chang my AP
(but only issue I have had was with Khadas VIM, thus never suspected
it is AP problem, notebook ping was just fine)
before AP change:
ssh router (AP) ping khadas vim with ArchLinuxArm mainline 4.12-rc5
with SDIO patch test 5GHz
30 packets transmitted, 29 packets received, 3% packet loss
round-trip min/avg/max = 177.542/791.630/1376.008 ms
ssh router (AP) ping ping notebook
30 packets transmitted, 30 packets received, 0% packet loss
round-trip min/avg/max = 1.523/1.907/3.687 ms
After router (AP) change to Archer C7 (AP) with LEDE:
ssh to router (AP) ping khadas vim with android nougat 5GHz
30 packets transmitted, 30 packets received, 0% packet loss
round-trip min/avg/max = 2.721/107.992/224.975 ms
ssh to router (AP) ping khadas vim with ArchLinuxArm 5GHz
30 packets transmitted, 30 packets received, 0% packet loss
round-trip min/avg/max = 31.109/130.086/227.538 ms
ssh to router (AP) ping notebook 5GHz
30 packets transmitted, 30 packets received, 0% packet loss
round-trip min/avg/max = 0.987/1.622/4.589 ms
ping notebook -> khadas vim which are connected to same router (AP):
Minimum = 10ms, Maximum = 611ms, Mittelwert = 149ms
ping khadas vim -> notebook which are connected to same router (AP):
30 packets transmitted, 30 received, 0% packet loss, time 29045ms
rtt min/avg/max/mdev = 6.889/15.296/23.906/4.942 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.)
My Khadas VIM Pro and the Notebook are both on one the same table,
distance between them and AP (Archer C7 router with LADE, was Netgear
WNDR 3700v2 with OpenWRT) is maybe 1,5m.
> 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
As you can see before changing the router (AP) the average ping time
was 791ms (from router (AP) to device) and there was a huge lag (but
did not measure from notebook -> khadas vim), and after changing to
new router (AP) I get "only" 107ms with Android and 130ms with
ArchLinuxArm kernel 4.12-rc5 from router (AP).
And between notebook -> khadas vim only 149ms, other way around khadas
vim -> notebook only 15ms.
And now I don't have any input lag. Seems it was false positive :(.
Regards,
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-06-15 12:36 UTC | newest]
Thread overview: 12+ 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-08 18:43 ` Heiner Kallweit
2017-06-09 22:06 ` Martin Blumenstingl
2017-06-09 22:06 ` Martin Blumenstingl
2017-06-10 11:34 ` Heiner Kallweit
2017-06-10 11:34 ` Heiner Kallweit
2017-06-11 20:31 ` Martin Blumenstingl
2017-06-11 20:31 ` Martin Blumenstingl
2017-06-15 12:36 ` crow
-- strict thread matches above, loose matches on Subject: below --
2017-06-08 5:56 Heiner Kallweit
2017-06-08 6:56 ` Ulf Hansson
2017-06-08 18:36 ` Heiner Kallweit
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.