[PATCH] ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask
acourbot at nvidia.com
Tue Apr 12 05:25:04 PDT 2016
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:
>>>>>> 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?
More information about the linux-arm-kernel