From: acourbot@nvidia.com (Alexandre Courbot)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask
Date: Tue, 12 Apr 2016 21:25:04 +0900 [thread overview]
Message-ID: <570CE920.4040204@nvidia.com> (raw)
In-Reply-To: <570CC6F2.4090301@intel.com>
On 04/12/2016 06:59 PM, Adrian Hunter wrote:
> On 12/04/16 11:40, Russell King - ARM Linux wrote:
>> On Tue, Apr 12, 2016 at 09:05:34AM +0300, Adrian Hunter wrote:
>>> On 11/04/16 19:13, Alexander Kurz wrote:
>>>> Hi Adrian,
>>>> On Mon, 11 Apr 2016, Adrian Hunter wrote:
>>>>
>>>>> On 11/04/16 11:35, Uwe Kleine-K?nig wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I added the people involved in 7b91369b4655 to Cc.
>>>>>>
>>>>>> On Mon, Apr 11, 2016 at 10:20:46AM +0200, Alexander Kurz wrote:
>>>>>>> With commit 7b91369b DMA access got disabled for device drivers with zero
>>>>>
>>>>> Is that because dma_set_mask_and_coherent() fails?
>>>> right, dma_set_mask_and_coherent() fails, thats the only reason for
>>>> this patch. This popped up on a Kindle3 (IMX35 with eMMC based root fs).
>>>
>>> Arnd, Alexandre : Why should dma_set_mask_and_coherent() fail in this case
>>> when DMA apparently doesn't need a dma_mask anyway?
>>
>> What do you mean "doesn't need a dma_mask" ? DMA _always_ requires a
>> DMA mask. The DMA mask defines how many address bits are capable of
>> being used on the bus.
>>
>> If there's no DMA mask, then there's no usable address bits, and so
>> the device is not DMA capable. Hence, dma_set_mask_and_coherent()
>> will fail because its not possible to negotiate a non-zero number of
>> address bits.
>>
>
> The point is, now we valid dma_set_mask_and_coherent(), DMA will stop
> working for any other SDHCI device that hasn't allocated dev.dma_mask. Is
> that OK?
Clearly these devices need to be fixed. If we want to give them a grace
period, we could also (temporarily) not propagate the return value of
dma_set_mask_and_coherent() and limit ourselves to emitting a big
warning about the inconsistency of having SDHCI_USE_SDMA/SDHCI_USE_ADMA
in the host flags while not setting a dma mask.
But in the past, how prompt have people been to react to such warnings
vs. their device not working as expected?
next prev parent reply other threads:[~2016-04-12 12:25 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-11 8:20 [PATCH] ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask Alexander Kurz
2016-04-11 8:35 ` Uwe Kleine-König
2016-04-11 10:10 ` Adrian Hunter
2016-04-11 16:13 ` Alexander Kurz
2016-04-12 6:05 ` Adrian Hunter
2016-04-12 8:40 ` Russell King - ARM Linux
2016-04-12 9:59 ` Adrian Hunter
2016-04-12 12:25 ` Alexandre Courbot [this message]
2016-04-12 15:31 ` Russell King - ARM Linux
2016-04-13 2:02 ` Alexandre Courbot
2016-04-13 8:07 ` Adrian Hunter
2016-04-16 21:48 ` Arnd Bergmann
2016-04-18 6:58 ` Adrian Hunter
2016-04-18 14:33 ` Arnd Bergmann
[not found] ` <57232233.1030702@intel.com>
2016-04-29 8:59 ` Potential issue with SDHCI DMA Adrian Hunter
2016-04-29 8:59 ` Adrian Hunter
2016-04-29 9:19 ` Jisheng Zhang
2016-04-29 9:19 ` Jisheng Zhang
2016-04-12 15:29 ` [PATCH] ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask Russell King - ARM Linux
2016-04-11 12:46 ` Sergei Shtylyov
2016-04-13 1:38 ` Shawn Guo
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=570CE920.4040204@nvidia.com \
--to=acourbot@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.