[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210915075007.GD20024@lst.de>
Date: Wed, 15 Sep 2021 09:50:07 +0200
From: Christoph Hellwig <hch@....de>
To: guoren@...nel.org
Cc: anup.patel@....com, atish.patra@....com, palmerdabbelt@...gle.com,
christoph.muellner@...ll.eu, philipp.tomsich@...ll.eu, hch@....de,
liush@...winnertech.com, wefu@...hat.com, lazyparser@...il.com,
drew@...gleboard.org, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org, taiten.peng@...onical.com,
aniket.ponkshe@...onical.com, heinrich.schuchardt@...onical.com,
gordan.markus@...onical.com
Subject: Re: [RFC PATCH V4 4/6] RISC-V: Implement arch_sync_dma* functions
On Sat, Sep 11, 2021 at 05:21:37PM +0800, guoren@...nel.org wrote:
> +static void __dma_sync(phys_addr_t paddr, size_t size, enum dma_data_direction dir)
> +{
> + if ((dir == DMA_FROM_DEVICE) && (dma_cache_sync->cache_invalidate))
> + dma_cache_sync->cache_invalidate(paddr, size);
> + else if ((dir == DMA_TO_DEVICE) && (dma_cache_sync->cache_clean))
> + dma_cache_sync->cache_clean(paddr, size);
> + else if ((dir == DMA_BIDIRECTIONAL) && dma_cache_sync->cache_flush)
> + dma_cache_sync->cache_flush(paddr, size);
> +}
Despite various snipplets this is a still pretty much the broken previous
versions. These need to use the CMO instructions directly which are
about to go into review, and then your SBI can trap on those can call
whatever non-standard mess you're using.
Powered by blists - more mailing lists