From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Tue, 25 Jun 2019 08:11:04 +0200 Subject: [OpenRISC] [PATCH 5/7] dma-direct: handle DMA_ATTR_NON_CONSISTENT in common code In-Reply-To: <20190614144431.21760-6-hch@lst.de> References: <20190614144431.21760-1-hch@lst.de> <20190614144431.21760-6-hch@lst.de> Message-ID: <20190625061104.GB28986@lst.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: openrisc@lists.librecores.org On Sun, Jun 16, 2019 at 06:08:40PM +0800, Hillf Danton wrote: > Literally, any cpu (call it cpuW) other than pcx12 and pcx1 will no longer do > dma alloc for any device with this patch applied. Yes. And that is not a chance from the previous code, where only pcx1 and pcx12 could do coherent allocations, > On the other hand, > !dev_is_dma_coherent(dev) && !(attrs & DMA_ATTR_NON_CONSISTENT) will ask > any cpu to do dma alloc, regardless of pcx1. This patch works imo unless cpuW > plays games only with devices that are dma coherent. I doubt it is true. I can't parse these two sentences. But to explains the bits mentioned here - dev_is_dma_coherent will return if a device is coherently attached vs the cpu. This will never be true for the parisc direct mapping. DMA_ATTR_NON_CONSISTENT asks for a non-coherent mapping that needs to be explicitly synced. This support now is in the dma-direct core code, and this is what the parisc specific devices used on the non-pcxl systems use, as they do not support dma coherency at all. (the story slightly changes when using an iommu, but that is irrelevant here)