On Fri, Jul 18, 2014 at 03:34:52PM +0530, Nikhil Badola wrote: > Modifies get_dma_ops() implementation on ppc arch to check null condition > for dev->archdata.dma_ops; returns common dma_direct_ops structure in > case its NULL > > Signed-off-by: Nikhil Badola <nikhil.bad...@freescale.com> > --- > arch/powerpc/include/asm/dma-mapping.h | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-)
I'm not sure why this was delegated to me in patchwork, as it doesn't appear to be FSL-specific... I wish patchwork showed the history of changes to a patch. > The use case in which ops are null is while running USB in Gadget and > Otg mode. > > For PPC architecture, whenever a platform device is registered, > pdev->dev is assigned dma_ops. In USB, one single chipidea platform > device is registered for any mode (host, gadget or otg) whose dev, as > explained above, has dma_ops set and this dev is assigned to > ci->dev(dev of chipidea struct) which is used by host controller > device. That is why we don't need the above null case checking in host > mode. But when we run usb in gadget/otg mode, the device structure > used is ci->gadget.dev which does not have dma_ops set and it crashes > when dma transaction starts when it calls get_dma_ops() which returns > NULL. > > A similar approach is used in ARM architecture which checks for null > condition and returns common dma_ops The above doesn't make it clear to me why dma_ops is NULL in non-host modes, or why "direct" is necessarily the right ops -- what if swiotlb or an iommu is needed? If the problem is that you're using a "struct device" other than the platform device, shouldn't that be fixed? Or make sure that this other "struct device" has been properly set up by arch code for doing DMA. > } > > + > static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops) Don't add this newline -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
