All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: Alagu Sankar <alagusankar@silex-india.com>,
	Kalle Valo <kvalo@qca.qualcomm.com>
Cc: silexcommon@gmail.com, linux-wireless@vger.kernel.org,
	ath10k@lists.infradead.org
Subject: Re: [PATCH 03/11] ath10k_sdio: DMA bounce buffers for read write
Date: Wed, 27 Dec 2017 19:49:11 +0100	[thread overview]
Message-ID: <5A43EB27.9040100@broadcom.com> (raw)
In-Reply-To: <5281f48b04f8f593ec06e72a041ec021@silex-india.com>

On 12/25/2017 1:26 PM, Alagu Sankar wrote:
> On 2017-12-22 21:38, Kalle Valo wrote:
>> silexcommon@gmail.com writes:
>>
>>> From: Alagu Sankar <alagusankar@silex-india.com>
>>>
>>> Some SD host controllers still need bounce buffers for SDIO data
>>> transfers. While the transfers worked fine on x86 platforms,
>>> this is found to be required for i.MX6 based systems.
>>>
>>> Changes are similar to and derived from the ath6kl sdio driver.
>>>
>>> Signed-off-by: Alagu Sankar <alagusankar@silex-india.com>
>>
>> Why is the bounce buffer needed exactly, what are the symptoms etc? To
>> me this sounds like an ugly workaround for a SDIO controller driver bug.
>
> We faced problems with i.MX6. The authentication frame sent by the
> driver never reached the air. The host driver accepted the buffer, but
> did not send out the packet to the sdio module. No errors reported
> anywhere, but the buffer is not accepted due to alignment. The same
> driver however works fine without bounce buffer on x86 platform with
> stdhci drivers. To make it compliant with all host controllers, we
> introduced the bounce buffers, similar to what was done in ath6kl_sdio
> drivers.

As mentioned by Adrian the comment from Kalle is that you are solving an 
issue caused by the sdio host controller. Although strictly speaking it 
may not be a driver bug, but a requirement of the host controller 
hardware. Either way it seems the obvious place to solve this is in the 
sdio host controller driver to which the issue applies. Or make it a 
generic quirk which can be enabled for sdio host controller drivers that 
need it. However, there may reasons to do it in the networking driver. 
For instance, the buffer you want to transfer might be the data buffer 
of an sk_buff you got from the networking stack and you want to have a 
zero-copy solution towards the wireless device.

Your solution checks for 4-byte alignment which is a requirement for 
ADMA as per SDIO spec. However, I have come across host controllers 
which have different alignment requirements. Also when 
CONFIG_ARCH_DMA_ADDR_T_64BIT is enabled the alignment changes from 4 to 
8 bytes. So it seems you are solving a specific case you have come 
across, but you may want to design for more flexibility.

Hope this helps.

Regards,
Arend

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: Alagu Sankar <alagusankar@silex-india.com>,
	Kalle Valo <kvalo@qca.qualcomm.com>
Cc: silexcommon@gmail.com, linux-wireless@vger.kernel.org,
	ath10k@lists.infradead.org
Subject: Re: [PATCH 03/11] ath10k_sdio: DMA bounce buffers for read write
Date: Wed, 27 Dec 2017 19:49:11 +0100	[thread overview]
Message-ID: <5A43EB27.9040100@broadcom.com> (raw)
In-Reply-To: <5281f48b04f8f593ec06e72a041ec021@silex-india.com>

On 12/25/2017 1:26 PM, Alagu Sankar wrote:
> On 2017-12-22 21:38, Kalle Valo wrote:
>> silexcommon@gmail.com writes:
>>
>>> From: Alagu Sankar <alagusankar@silex-india.com>
>>>
>>> Some SD host controllers still need bounce buffers for SDIO data
>>> transfers. While the transfers worked fine on x86 platforms,
>>> this is found to be required for i.MX6 based systems.
>>>
>>> Changes are similar to and derived from the ath6kl sdio driver.
>>>
>>> Signed-off-by: Alagu Sankar <alagusankar@silex-india.com>
>>
>> Why is the bounce buffer needed exactly, what are the symptoms etc? To
>> me this sounds like an ugly workaround for a SDIO controller driver bug.
>
> We faced problems with i.MX6. The authentication frame sent by the
> driver never reached the air. The host driver accepted the buffer, but
> did not send out the packet to the sdio module. No errors reported
> anywhere, but the buffer is not accepted due to alignment. The same
> driver however works fine without bounce buffer on x86 platform with
> stdhci drivers. To make it compliant with all host controllers, we
> introduced the bounce buffers, similar to what was done in ath6kl_sdio
> drivers.

As mentioned by Adrian the comment from Kalle is that you are solving an 
issue caused by the sdio host controller. Although strictly speaking it 
may not be a driver bug, but a requirement of the host controller 
hardware. Either way it seems the obvious place to solve this is in the 
sdio host controller driver to which the issue applies. Or make it a 
generic quirk which can be enabled for sdio host controller drivers that 
need it. However, there may reasons to do it in the networking driver. 
For instance, the buffer you want to transfer might be the data buffer 
of an sk_buff you got from the networking stack and you want to have a 
zero-copy solution towards the wireless device.

Your solution checks for 4-byte alignment which is a requirement for 
ADMA as per SDIO spec. However, I have come across host controllers 
which have different alignment requirements. Also when 
CONFIG_ARCH_DMA_ADDR_T_64BIT is enabled the alignment changes from 4 to 
8 bytes. So it seems you are solving a specific case you have come 
across, but you may want to design for more flexibility.

Hope this helps.

Regards,
Arend

  parent reply	other threads:[~2017-12-27 18:49 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-30 17:37 [PATCH 00/11] SDIO support for ath10k silexcommon
2017-09-30 17:37 ` silexcommon
2017-09-30 17:37 ` [PATCH 01/11] ath10k_sdio: sdio htt data transfer fixes silexcommon
2017-09-30 17:37   ` silexcommon
2017-10-02  7:36   ` Arend van Spriel
2017-10-02  7:36     ` Arend van Spriel
2017-10-02  7:44     ` Alagu Sankar
2017-10-02  7:44       ` Alagu Sankar
2017-10-04  8:55     ` Kalle Valo
2017-10-04  8:55       ` Kalle Valo
2017-09-30 17:37 ` [PATCH 02/11] ath10k_sdio: wb396 reference card fix silexcommon
2017-09-30 17:37   ` silexcommon
2017-10-01 22:47   ` Steve deRosier
2017-10-01 22:47     ` Steve deRosier
2017-10-02  7:02     ` Alagu Sankar
2017-10-02  7:02       ` Alagu Sankar
2017-10-02  9:06       ` Erik Stromdahl
2017-10-02  9:06         ` Erik Stromdahl
2017-09-30 17:37 ` [PATCH 03/11] ath10k_sdio: DMA bounce buffers for read write silexcommon
2017-09-30 17:37   ` silexcommon
2017-12-22 16:08   ` Kalle Valo
2017-12-22 16:08     ` Kalle Valo
2017-12-25 12:26     ` Alagu Sankar
2017-12-25 12:26       ` Alagu Sankar
2017-12-25 16:11       ` Adrian Chadd
2017-12-25 16:11         ` Adrian Chadd
2017-12-27 18:49       ` Arend van Spriel [this message]
2017-12-27 18:49         ` Arend van Spriel
2017-12-27 19:26         ` Adrian Chadd
2017-12-27 19:26           ` Adrian Chadd
2018-01-08 12:58       ` Kalle Valo
2018-01-08 12:58         ` Kalle Valo
2017-09-30 17:37 ` [PATCH 04/11] ath10k_sdio: reduce transmit msdu count silexcommon
2017-09-30 17:37   ` silexcommon
2017-09-30 17:37 ` [PATCH 05/11] ath10k_sdio: use clean packet headers silexcommon
2017-09-30 17:37   ` silexcommon
2017-09-30 17:37 ` [PATCH 06/11] ath10k_sdio: high latency fixes for beacon buffer silexcommon
2017-09-30 17:37   ` silexcommon
2017-09-30 17:37 ` [PATCH 07/11] ath10k_sdio: fix rssi indication silexcommon
2017-09-30 17:37   ` silexcommon
2017-09-30 17:37 ` [PATCH 08/11] ath10k_sdio: common read write silexcommon
2017-09-30 17:37   ` silexcommon
2017-10-04  9:49   ` Kalle Valo
2017-10-04  9:49     ` Kalle Valo
2017-10-05 10:09   ` [08/11] " Gary Bisson
2017-10-05 10:09     ` Gary Bisson
2017-10-05 17:33     ` Alagu Sankar
2017-10-05 17:33       ` Alagu Sankar
2017-12-08 14:42       ` Gary Bisson
2017-12-08 14:42         ` Gary Bisson
2017-09-30 17:37 ` [PATCH 09/11] ath10k_sdio: virtual scatter gather for receive silexcommon
2017-09-30 17:37   ` silexcommon
2017-10-04 19:56   ` Erik Stromdahl
2017-10-04 19:56     ` Erik Stromdahl
2017-09-30 17:37 ` [PATCH 10/11] ath10k_sdio: enable firmware crash dump silexcommon
2017-09-30 17:37   ` silexcommon
2017-09-30 17:37 ` [PATCH 11/11] ath10k_sdio: hif start once addition silexcommon
2017-09-30 17:37   ` silexcommon
2017-10-02  9:02 ` [PATCH 00/11] SDIO support for ath10k Erik Stromdahl
2017-10-02  9:02   ` Erik Stromdahl
2017-10-04  6:22   ` Alagu Sankar
2017-10-04  6:22     ` Alagu Sankar
2017-10-04 15:53     ` Erik Stromdahl
2017-10-04 15:53       ` Erik Stromdahl
2017-10-05 15:12 ` Gary Bisson
2017-10-05 15:12   ` Gary Bisson
2017-10-05 17:24   ` Alagu Sankar
2017-10-05 17:24     ` Alagu Sankar
2017-10-06 11:16     ` Gary Bisson
2017-10-06 11:16       ` Gary Bisson
2017-12-18 16:19       ` Gary Bisson
2017-12-18 16:19         ` Gary Bisson
2017-12-22 16:21         ` Kalle Valo
2017-12-22 16:21           ` Kalle Valo
2017-12-22 16:25 ` Kalle Valo
2017-12-22 16:25   ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5A43EB27.9040100@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --cc=alagusankar@silex-india.com \
    --cc=ath10k@lists.infradead.org \
    --cc=kvalo@qca.qualcomm.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=silexcommon@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
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.