Hi,
I tried this and it works with patches 4+5 from Rob's series and
changing gpummu to use sg_phys(sg) instead of sg->dma_address
(dma_address isn't set now that dma_map_sg isn't used).
Jonathan
On 9/3/19 11:22 AM, Rob Clark wrote:
On Mon, Sep 2, 2019 at 11:03 AM Fabio Estevam <feste...@gmail.com> wrote:
Hi Robin,
On Mon, Sep 2, 2019 at 11:45 AM Robin Murphy <robin.mur...@arm.com> wrote:
Try 0036bc73ccbe - that looks like something that CONFIG_DMA_API_DEBUG
should have been screaming about anyway.
Thanks for your suggestion.
I can successfully boot after reverting the following commits:
commit 141db5703c887f46957615cd6616ca28fe4691e0 (HEAD)
Author: Fabio Estevam <feste...@gmail.com>
Date: Mon Sep 2 14:58:18 2019 -0300
Revert "drm/msm: stop abusing dma_map/unmap for cache"
This reverts commit 0036bc73ccbe7e600a3468bf8e8879b122252274.
commit fa5b1f620f2984c254877d6049214c39c24c8207
Author: Fabio Estevam <feste...@gmail.com>
Date: Mon Sep 2 14:56:01 2019 -0300
Revert "drm/msm: Use the correct dma_sync calls in msm_gem"
This reverts commit 3de433c5b38af49a5fc7602721e2ab5d39f1e69c.
Rob,
What would be the recommended approach for fixing this?
We need a direct way to handle cache, so we can stop trying to trick
DMA API into doing what we want.
Something like this is what I had in mind:
https://patchwork.freedesktop.org/series/65211/
I guess I could respin that. I'm not really sure of any other way to
have things working on the different combinations of archs and dma_ops
that we have. Lately fixing one has been breaking another.
BR,
-R
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
