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@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
