Messages in this thread | | | From | Vivek Gautam <> | Date | Thu, 29 Nov 2018 15:14:21 +0530 | Subject | Re: [PATCH v2 1/1] drm: msm: Replace dma_map_sg with dma_sync_sg* |
| |
On Wed, Nov 28, 2018 at 6:09 PM Rob Clark <robdclark@gmail.com> wrote: > > On Wed, Nov 28, 2018 at 2:39 AM Christoph Hellwig <hch@infradead.org> wrote: > > > > > + /* > > > + * dma_sync_sg_*() flush the physical pages, so point > > > + * sg->dma_address to the physical ones for the right behavior. > > > + */ > > > + for_each_sg(msm_obj->sgt->sgl, s, msm_obj->sgt->nents, i) > > > + sg_dma_address(s) = sg_phys(s); > > > + > > > > I'm sorry, but this is completely bogus and not acceptable. > > > > The only place that is allowed to initialize sg_dma_address is > > dma_map_sg. If the default dma ops don't work for your setup we have > > major a problem and need to fix the dma api / iommu integration instead > > of hacking around it. > > I agree that the dma/iommu integration is very problematic for drm (in > particular, gpu drivers that use the iommu as an gpu mmu).. Really we > need a way that a driver can opt-out of this, and access the cpu cache > APIs directly, skipping the dma API entirely. But as it is, we've had > to hack around the dma API. I'm not really sure this hack is any > worse than abusing dma_(un)map_sg() for doing cache operations. > > I probably should have paid more attention and nak'd the dma/iommu > integration before it landed. But given that now we are stuck in this > situation, while I'm certainly interested if anyone has some ideas > about how to let drivers opt out of the dma/iommu integration and > bypass the dma API layer, I'm ok with replacing a hack with a less-bad > hack.
May I take it as a positive nod to respin the next version?
Regards Vivek
> > BR, > -R
-- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
| |