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 > > 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 -- 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
