On Sun, Aug 18, 2019 at 10:23 PM Christoph Hellwig <hch@xxxxxx> 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? BR, -R _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
