[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200911071751.GG22394@lst.de>
Date: Fri, 11 Sep 2020 09:17:51 +0200
From: Christoph Hellwig <hch@....de>
To: Robin Murphy <robin.murphy@....com>
Cc: Christoph Hellwig <hch@....de>, Tony Luck <tony.luck@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
iommu@...ts.linux-foundation.org, Tomasz Figa <tfiga@...omium.org>,
Joerg Roedel <joro@...tes.org>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-ia64@...r.kernel.org,
linux-mips@...r.kernel.org
Subject: Re: [PATCH 12/12] dma-mapping: move the
dma_declare_coherent_memory documentation
On Thu, Sep 10, 2020 at 02:51:47PM +0100, Robin Murphy wrote:
> On 2020-09-08 17:47, Christoph Hellwig wrote:
>> dma_declare_coherent_memory should not be in a DMA API guide aimed
>> at driver writers (that is consumers of the API). Move it to a comment
>> near the function instead.
>
> I still think there might be an occasional valid use for device-local
> memory outside the scope of platform code without the driver having to go
> full ZONE_DEVICE/HMM/TTM, e.g. with stuff like PCIe-based FPGA prototyping
> cards, but the kind of driver I'm imagining for that case would never be
> upstream anyway (if it were even written, rather than just using hard-coded
> hacks), so meh.
And I'm not sure this would be the right interface for it. E.g. NVMe
has the concept of a Controller Memory buffer (and a similar persistent
variant not supported by Linux), where the device can do this local DMA
(in a completely broken way that relies on correlating addresses seen
by the device and those by the host, but that's another disgression).
But that memory obviously can also be addresses by other devices using
PCIe P2P transactions which would also be useful for any HMM-ish devices,
so we'd need to expose it as P2P memory anyay..
Powered by blists - more mailing lists