Re: [PATCH] USB: set device dma_mask without reference to global data

[Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 05/08/2013 02:11 AM, Matthijs Kooijman wrote:
> Hi folks,
> 
> I also bumped into the question of how to set the dma_mask when enabling
> the dwc2 driver on the ramips target and found there didn't seem to be
> any clear way to get a dma_mask.
> 
> It seems to me that in the pre-DT era, a platform_device would get a
> dma_mask when it was defined in the board / soc code, which makes sense
> since that code knows if a dma_mask is required and what its value
> should be (it seems to me that a driver can only know it needs a
> dma_mask, but not what value it should have?).
> 
>>> This probably could be initialized from some DT property. However,
>>> there's no such property defined right now, and considering that DT is
>>> supposed to be an ABI, we'd always need the code in this patch as a
>>> fallback for DTs that were created before any such property was defined.
> It seems there has already been a patch to implement this. For
> reference, this seems to be the most recent version:
> 
> https://lkml.org/lkml/2012/12/4/54
> 
> And here's the previous attempt, to which Rob Herring refers in a reply.
> 
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-March/013180.html

I believe most of the issues have been around supporting ARM LPAE
systems. There is a much more simple approach to address this by using
the dma_addr_t size to set the coherent_dma_mask which I have queued for
3.11:

https://patchwork-mail1.kernel.org/patch/2495861/

This does not set dma_mask though. There's always been some mystery
around why there are separate masks. I think for most systems dma_mask
can be set to coherent_dma_mask based on what Arnd found:

http://pastebin.com/E7fFVJyq

This can always be overridden by a platform with a bus notifier or by a
driver if needed.

Rob

> 
>>> Equally, since the data is SoC-specific rather than board-specific, and
>>> is even fairly unlikely to vary between SoC versions since these values
>>> are all 0xffffffff anyway, I don't really see much point in putting it
>>> into DT, rather than just putting the static data into the driver.
>>
>> I mean there is already dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> at function of_platform_device_create, why can't add
>> dev->dev.dma_mask = &dev->dev.coherent_dma_mask after that?
> Perhaps it would sense to set the 32-bit mask as a default, but allow to
> override this mask from the devicetree for boards that need another
> value? Or perhaps override it from the soc code instead?
> 
> For the ramips target, the MIPS folks suggested another approach: The
> soc code finds the platform_device generated by DT and adds the
> dma_mask:
> 
> http://www.linux-mips.org/archives/linux-mips/2013-04/msg00162.html
> 
>> If DT core can do above things, can we delete dma_mask assignment
>> at every driver?
> That would seem like a likeably goal to me :-)
> 
> 
> Gr.
> 
> Matthijs
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>