From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [PATCH] USB: set device dma_mask without reference to global data Date: Wed, 08 May 2013 08:50:36 -0500 Message-ID: <518A582C.8070600@gmail.com> References: <1367967232-10128-1-git-send-email-swarren@wwwdotorg.org> <5189B7BF.8070607@wwwdotorg.org> <20130508071137.GM25742@login.drsnuggles.stderr.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130508071137.GM25742-tJobPqrNDpleFRaWBN1JIYg6o0x57dKM8/qWW+O4k6E@public.gmane.org> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Peter Chen , Stephen Warren , Greg Kroah-Hartman , Stephen Warren , Arnd Bergmann , Alexander Shishkin , "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Felipe Balbi , Alan Stern , linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Laura Abbott List-Id: linux-omap@vger.kernel.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 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: robherring2@gmail.com (Rob Herring) Date: Wed, 08 May 2013 08:50:36 -0500 Subject: [PATCH] USB: set device dma_mask without reference to global data In-Reply-To: <20130508071137.GM25742@login.drsnuggles.stderr.nl> References: <1367967232-10128-1-git-send-email-swarren@wwwdotorg.org> <5189B7BF.8070607@wwwdotorg.org> <20130508071137.GM25742@login.drsnuggles.stderr.nl> Message-ID: <518A582C.8070600@gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.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 at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >