On Mon, Sep 2, 2019 at 11:03 AM Fabio Estevam festevam@gmail.com wrote:
Hi Robin,
On Mon, Sep 2, 2019 at 11:45 AM Robin Murphy robin.murphy@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 festevam@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 festevam@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