[PATCH 0/6] drm+dma: cache support for arm, etc
robdclark at chromium.org
Mon Aug 19 14:39:28 UTC 2019
On Sun, Aug 18, 2019 at 10:23 PM Christoph Hellwig <hch at lst.de> wrote:
> On Fri, Aug 16, 2019 at 02:04:35PM -0700, Rob Clark wrote:
> > I don't disagree about needing an API to get uncached memory (or
> > ideally just something outside of the linear map). But I think this
> > is a separate problem.
> > What I was hoping for, for v5.4, is a way to stop abusing dma_map/sync
> > for cache ops to get rid of the hack I had to make for v5.3. And also
> > to fix vgem on non-x86. (Unfortunately changing vgem to used cached
> > mappings breaks x86 CI, but fixes CI on arm/arm64..) We can do that
> > without any changes in allocation. There is still the possibility for
> > problems due to cached alias, but that has been a problem this whole
> > time, it isn't something new.
> But that just means we start exposing random low-level APIs that
> people will quickly abuse.. In fact even your simple plan to some
> extent already is an abuse of the intent of these functions, and
> it also requires a lot of knowledge in the driver that in the normal
> cases drivers can't know (e.g. is the device dma coherent or not).
I can agree that most drivers should use the higher level APIs.. but
not that we must prevent *all* drivers from using them. Most of what
DMA API is trying to solve doesn't apply to a driver like drm/msm..
which is how we ended up with hacks to try and misuse the high level
API to accomplish what we need.
Perhaps we can protect the prototypes with #ifdef LOWLEVEL_DMA_API /
#endif type thing to make it more obvious to other drivers that it
probably isn't the API they should use?
More information about the dri-devel