Am 22.05.19 um 13:29 schrieb Daniel Vetter: > [SNIP] > Forgot to add: Iirc it was buffer sharing between i915 and amdgpu that > hits this. Can't say for sure since intel-gfx isn't cc'ed on this > version, so our CI hasn't picked this up. I've changed this so that when exporter/importer disagree on dynamic handling we always cache the sgt during the attachment process. Going to CC intel-gfx on the next version. > -Daniel > >>>>> + struct sg_table *sgt; >>>>> + >>>>> + sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL); >>>> And unfortunately the non-dynamic, i.e. legacy/current code importer is >>>> also the one which uses other flags than DMA_BIDIRECTIONAL. At least on >>>> ARM, and that's the only place where this matters because there the dma >>>> api might do cache flushing. >>> Well the only implementer for now is amdgpu, and amdgpu always requires >>> a coherent bidirectional mapping. >>> >>> So this won't be a problem unless the ARM drivers start to implement >>> dynamic DMA-buf handling themselves or start to talk to amdgpu (which >>> wouldn't have worked before anyway). >> Hm, feels a bit evil. I just heard a some soc people tell me that drm >> isn't cool because it likes to ignore soc at the expensive of x86. >> >> Otoh I don't see a way out either, and maybe this will be motivation >> enough to make the dma-api cache management a bit more explicit. Not >> that I expect much change there ... Actually it's not evil at all, see those exporters/importers could implement the callbacks for dynamic handling as well and the problem of the caching wouldn't appear either. Christian. >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
