On Thu, Feb 11, 2016 at 01:51:31AM +0200, Laurent Pinchart wrote: > Hi Vinod, > > > Okay I did look back and checked. I tend to agree with you on this and > > client are not really taking care of mapping so easy approach would be to > > get this fixed in dmanegine which helps in IOMMU case (which I still think > > is in infancy, but who know how designers will throw their pipe dreams at > > us) > > > > Now, am checking this with Dan on why we started with client based mapping > > assumption in case of slave, we don't want to miss anything here, so I will > > get back in couple of days.. So discussed a bit with Dan, and now have ressurected the patch from Linus and compiled with it, nothing seems to break. But I think for slave cases we should also change the prep_ calls to take phys_addr_t which will fix the case for IOMMU being on either side as you pointed out. Should we keep interleaved template as dma or phys, am for latter. Only non slave cases will be dma types and mapping done by clients. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
