On Wed, Aug 14, 2019 at 11:51 PM Christoph Hellwig <hch@xxxxxx> wrote:
>
> As said before I don't think these low-level helpers are the
> right API to export, but even if they did you'd just cover a tiny
> subset of the architectures.
Are you thinking instead something like:
void dma_sync_sg_for_{cpu,device}(struct device *dev, struct scatterlist *sgl,
int nents, enum dma_data_direction dir)
{
for_each_sg(sgl, sg, nents, i) {
arch_sync_dma_for_..(dev, sg_phys(sg), sg->length, dir);
}
}
EXPORT_SYMBOL_GPL(dma_sync_sg_for_..)
or did you have something else in mind?
I guess something like this would avoid figuring out *which* archs
actually build drm..
> Also to distil the previous thread - if you remap memory to uncached
> the helper to use is arch_dma_prep_coherent, which does a writeback+
> invalidate everywhere, and there is no need to clean up after a
> long-term uncached mapping. We might still get speculations into
> that area, if we don't remap the direct mapping, but it isn't like
> invalidting that just before freeing the memory is going to help
> anyone.
hmm, IIUC the aarch64 cache instructions, what I'm doing now is equiv
to what I would get with dma_map_sg(DMA_BIDIRECTIONAL) and
arch_dma_prep_coherent() is equiv to what I'd get w/ DMA_FROM_DEVICE
(but a single pass instead of separate inv+clean passes)..
but I can respin this with a single dma_prep_coherent_sg() which uses
arch_dma_prep_coherent()..
> Also it seems like patches 5 and 6 are missing in my inbox.
Hmm, not entirely sure why.. you should be on the cc list for each
individual patch.
But here is the patchwork link if you want to see them:
https://patchwork.freedesktop.org/series/65211/
BR,
-R
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
