From: Christoph Hellwig <hch@infradead.org> To: Daniel Vetter <daniel@ffwll.ch> Cc: "Christoph Hellwig" <hch@infradead.org>, "Christian König" <christian.koenig@amd.com>, "moderated list:DMA BUFFER SHARING FRAMEWORK" <linaro-mm-sig@lists.linaro.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "amd-gfx list" <amd-gfx@lists.freedesktop.org>, "Jerome Glisse" <jglisse@redhat.com>, dri-devel <dri-devel@lists.freedesktop.org>, "Dan Williams" <dan.j.williams@intel.com>, "Logan Gunthorpe" <logang@deltatee.com>, "open list:DMA BUFFER SHARING FRAMEWORK" <linux-media@vger.kernel.org> Subject: Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag Date: Tue, 24 Apr 2018 22:48:55 -0700 [thread overview] Message-ID: <20180425054855.GA17038@infradead.org> (raw) In-Reply-To: <CAKMK7uFL68pu+-9LODTgz+GQYvxpnXOGhxfz9zorJ_JKsPVw2g@mail.gmail.com> On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote: > Out of curiosity, how much virtual flushing stuff is there still out > there? At least in drm we've pretty much ignore this, and seem to be > getting away without a huge uproar (at least from driver developers > and users, core folks are less amused about that). As I've just been wading through the code, the following architectures have non-coherent dma that flushes by virtual address for at least some platforms: - arm [1], arm64, hexagon, nds32, nios2, parisc, sh, xtensa, mips, powerpc These have non-coherent dma ops that flush by physical address: - arc, arm [1], c6x, m68k, microblaze, openrisc, sparc And these do not have non-coherent dma ops at all: - alpha, h8300, riscv, unicore32, x86 [1] arm ѕeems to do both virtually and physically based ops, further audit needed. Note that using virtual addresses in the cache flushing interface doesn't mean that the cache actually is virtually indexed, but it at least allows for the possibility. > > I think the most important thing about such a buffer object is that > > it can distinguish the underlying mapping types. While > > dma_alloc_coherent, dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT, > > dma_map_page/dma_map_single/dma_map_sg and dma_map_resource all give > > back a dma_addr_t they are in now way interchangable. And trying to > > stuff them all into a structure like struct scatterlist that has > > no indication what kind of mapping you are dealing with is just > > asking for trouble. > > Well the idea was to have 1 interface to allow all drivers to share > buffers with anything else, no matter how exactly they're allocated. Isn't that interface supposed to be dmabuf? Currently dma_map leaks a scatterlist through the sg_table in dma_buf_map_attachment / ->map_dma_buf, but looking at a few of the callers it seems like they really do not even want a scatterlist to start with, but check that is contains a physically contiguous range first. So kicking the scatterlist our there will probably improve the interface in general. > dma-buf has all the functions for flushing, so you can have coherent > mappings, non-coherent mappings and pretty much anything else. Or well > could, because in practice people hack up layering violations until it > works for the 2-3 drivers they care about. On top of that there's the > small issue that x86 insists that dma is coherent (and that's true for > most devices, including v4l drivers you might want to share stuff > with), and gpus really, really really do want to make almost > everything incoherent. How do discrete GPUs manage to be incoherent when attached over PCIe?
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org> To: Daniel Vetter <daniel@ffwll.ch> Cc: "moderated list:DMA BUFFER SHARING FRAMEWORK" <linaro-mm-sig@lists.linaro.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "amd-gfx list" <amd-gfx@lists.freedesktop.org>, "Christoph Hellwig" <hch@infradead.org>, "Jerome Glisse" <jglisse@redhat.com>, dri-devel <dri-devel@lists.freedesktop.org>, "Dan Williams" <dan.j.williams@intel.com>, "Logan Gunthorpe" <logang@deltatee.com>, "Christian König" <christian.koenig@amd.com>, "open list:DMA BUFFER SHARING FRAMEWORK" <linux-media@vger.kernel.org> Subject: Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag Date: Tue, 24 Apr 2018 22:48:55 -0700 [thread overview] Message-ID: <20180425054855.GA17038@infradead.org> (raw) In-Reply-To: <CAKMK7uFL68pu+-9LODTgz+GQYvxpnXOGhxfz9zorJ_JKsPVw2g@mail.gmail.com> On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote: > Out of curiosity, how much virtual flushing stuff is there still out > there? At least in drm we've pretty much ignore this, and seem to be > getting away without a huge uproar (at least from driver developers > and users, core folks are less amused about that). As I've just been wading through the code, the following architectures have non-coherent dma that flushes by virtual address for at least some platforms: - arm [1], arm64, hexagon, nds32, nios2, parisc, sh, xtensa, mips, powerpc These have non-coherent dma ops that flush by physical address: - arc, arm [1], c6x, m68k, microblaze, openrisc, sparc And these do not have non-coherent dma ops at all: - alpha, h8300, riscv, unicore32, x86 [1] arm ѕeems to do both virtually and physically based ops, further audit needed. Note that using virtual addresses in the cache flushing interface doesn't mean that the cache actually is virtually indexed, but it at least allows for the possibility. > > I think the most important thing about such a buffer object is that > > it can distinguish the underlying mapping types. While > > dma_alloc_coherent, dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT, > > dma_map_page/dma_map_single/dma_map_sg and dma_map_resource all give > > back a dma_addr_t they are in now way interchangable. And trying to > > stuff them all into a structure like struct scatterlist that has > > no indication what kind of mapping you are dealing with is just > > asking for trouble. > > Well the idea was to have 1 interface to allow all drivers to share > buffers with anything else, no matter how exactly they're allocated. Isn't that interface supposed to be dmabuf? Currently dma_map leaks a scatterlist through the sg_table in dma_buf_map_attachment / ->map_dma_buf, but looking at a few of the callers it seems like they really do not even want a scatterlist to start with, but check that is contains a physically contiguous range first. So kicking the scatterlist our there will probably improve the interface in general. > dma-buf has all the functions for flushing, so you can have coherent > mappings, non-coherent mappings and pretty much anything else. Or well > could, because in practice people hack up layering violations until it > works for the 2-3 drivers they care about. On top of that there's the > small issue that x86 insists that dma is coherent (and that's true for > most devices, including v4l drivers you might want to share stuff > with), and gpus really, really really do want to make almost > everything incoherent. How do discrete GPUs manage to be incoherent when attached over PCIe? _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-04-25 5:49 UTC|newest] Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-25 10:59 [PATCH 1/8] lib/scatterlist: add sg_set_dma_addr() helper Christian König 2018-03-25 10:59 ` Christian König 2018-03-25 10:59 ` [PATCH 2/8] PCI: Add pci_find_common_upstream_dev() Christian König 2018-03-25 10:59 ` Christian König 2018-03-28 12:38 ` Christoph Hellwig 2018-03-28 15:07 ` Christian König 2018-03-28 15:07 ` Christian König 2018-03-28 15:47 ` Logan Gunthorpe 2018-03-28 16:02 ` Christian König 2018-03-28 16:02 ` Christian König 2018-03-28 16:25 ` Logan Gunthorpe 2018-03-28 18:28 ` Christian König 2018-03-28 18:28 ` Christian König 2018-03-28 18:57 ` Logan Gunthorpe 2018-03-28 19:44 ` Christian König 2018-03-28 19:44 ` Christian König 2018-03-28 19:53 ` Logan Gunthorpe 2018-03-29 11:44 ` Christian König 2018-03-29 15:45 ` Logan Gunthorpe 2018-03-29 16:10 ` Christian König 2018-03-29 16:10 ` Christian König 2018-03-29 16:25 ` Logan Gunthorpe 2018-03-29 18:15 ` Christian König 2018-03-29 18:15 ` Christian König 2018-03-30 1:58 ` Jerome Glisse 2018-03-30 1:58 ` Jerome Glisse 2018-03-30 6:33 ` Christoph Hellwig 2018-03-30 6:33 ` Christoph Hellwig 2018-03-30 15:25 ` Jerome Glisse 2018-03-30 18:46 ` Logan Gunthorpe 2018-03-30 19:45 ` Jerome Glisse 2018-03-30 19:45 ` Jerome Glisse 2018-04-02 17:02 ` Logan Gunthorpe 2018-04-02 17:20 ` Jerome Glisse 2018-04-02 17:20 ` Jerome Glisse 2018-04-02 17:37 ` Logan Gunthorpe 2018-04-02 19:16 ` Jerome Glisse 2018-04-02 19:16 ` Jerome Glisse 2018-04-02 19:32 ` Logan Gunthorpe 2018-04-02 19:45 ` Jerome Glisse 2018-04-02 19:45 ` Jerome Glisse [not found] ` <CADnq5_P-z=Noos_jaME9_CERri3C-m2hPPvx2bArr36O=1FnrA@mail.gmail.com> 2018-03-29 14:37 ` Alex Deucher 2018-03-29 14:37 ` Alex Deucher 2018-03-25 10:59 ` [PATCH 3/8] PCI: Add pci_peer_traffic_supported() Christian König 2018-03-25 10:59 ` Christian König 2018-03-25 10:59 ` [PATCH 4/8] dma-buf: add peer2peer flag Christian König 2018-03-25 10:59 ` Christian König 2018-03-29 6:57 ` Daniel Vetter 2018-03-29 6:57 ` Daniel Vetter 2018-03-29 11:34 ` Christian König 2018-03-29 11:34 ` Christian König 2018-04-03 9:09 ` Daniel Vetter 2018-04-03 9:09 ` Daniel Vetter 2018-04-03 17:06 ` Jerome Glisse 2018-04-03 17:06 ` Jerome Glisse 2018-04-03 18:08 ` Daniel Vetter 2018-04-03 18:08 ` Daniel Vetter 2018-04-16 12:39 ` Christoph Hellwig 2018-04-16 12:39 ` Christoph Hellwig 2018-04-16 13:38 ` Daniel Vetter 2018-04-16 13:38 ` Daniel Vetter 2018-04-19 8:16 ` Christoph Hellwig 2018-04-19 8:16 ` Christoph Hellwig 2018-04-20 7:13 ` Daniel Vetter 2018-04-20 7:13 ` Daniel Vetter 2018-04-20 8:58 ` Christian König 2018-04-20 8:58 ` Christian König 2018-04-20 10:17 ` Christoph Hellwig 2018-04-20 10:17 ` Christoph Hellwig 2018-04-20 10:44 ` Christian König 2018-04-20 10:44 ` Christian König 2018-04-20 12:46 ` Christoph Hellwig 2018-04-20 15:21 ` [Linaro-mm-sig] " Daniel Vetter 2018-04-24 18:48 ` Christoph Hellwig 2018-04-24 18:48 ` Christoph Hellwig 2018-04-24 19:32 ` Daniel Vetter 2018-04-24 19:32 ` Daniel Vetter 2018-04-25 5:48 ` Christoph Hellwig [this message] 2018-04-25 5:48 ` Christoph Hellwig 2018-04-25 6:10 ` Alex Deucher 2018-04-25 6:10 ` Alex Deucher 2018-04-25 6:13 ` Daniel Vetter 2018-04-25 6:13 ` Daniel Vetter 2018-04-25 6:23 ` Daniel Vetter 2018-04-25 6:23 ` Daniel Vetter 2018-04-25 6:43 ` Christoph Hellwig 2018-04-25 6:43 ` Christoph Hellwig 2018-04-25 7:02 ` Daniel Vetter 2018-04-25 7:02 ` Daniel Vetter 2018-04-25 7:09 ` Christoph Hellwig 2018-04-25 7:09 ` Christoph Hellwig 2018-04-25 7:30 ` Daniel Vetter 2018-04-25 7:30 ` Daniel Vetter 2018-04-25 7:56 ` Thierry Reding 2018-04-25 7:56 ` Thierry Reding 2018-04-25 8:55 ` Christoph Hellwig 2018-04-25 8:55 ` Christoph Hellwig 2018-04-25 7:43 ` Thierry Reding 2018-04-25 7:43 ` Thierry Reding 2018-04-25 7:41 ` Thierry Reding 2018-04-25 7:41 ` Thierry Reding 2018-04-25 8:54 ` noveau vs arm dma ops Christoph Hellwig 2018-04-25 8:54 ` Christoph Hellwig 2018-04-25 8:54 ` Christoph Hellwig 2018-04-25 9:25 ` Russell King - ARM Linux 2018-04-25 9:25 ` Russell King - ARM Linux 2018-04-25 10:04 ` Daniel Vetter 2018-04-25 10:04 ` Daniel Vetter 2018-04-25 10:04 ` Daniel Vetter 2018-04-25 15:33 ` Christoph Hellwig 2018-04-25 15:33 ` Christoph Hellwig 2018-04-25 15:33 ` Christoph Hellwig 2018-04-25 21:35 ` Daniel Vetter 2018-04-25 21:35 ` Daniel Vetter 2018-04-25 21:35 ` Daniel Vetter 2018-04-25 23:26 ` Russell King - ARM Linux 2018-04-25 23:26 ` Russell King - ARM Linux 2018-04-26 9:17 ` Daniel Vetter 2018-04-26 9:17 ` Daniel Vetter 2018-04-26 9:17 ` Daniel Vetter 2018-04-26 9:09 ` Christoph Hellwig 2018-04-26 9:09 ` Christoph Hellwig 2018-04-26 9:09 ` Christoph Hellwig 2018-04-26 9:45 ` Daniel Vetter 2018-04-26 9:45 ` Daniel Vetter 2018-04-26 9:45 ` Daniel Vetter 2018-04-26 11:12 ` Russell King - ARM Linux 2018-04-26 11:12 ` Russell King - ARM Linux 2018-04-25 22:54 ` Russell King - ARM Linux 2018-04-25 22:54 ` Russell King - ARM Linux 2018-04-26 9:13 ` Christoph Hellwig 2018-04-26 9:13 ` Christoph Hellwig 2018-04-26 9:13 ` Christoph Hellwig 2018-04-26 9:20 ` [Linaro-mm-sig] " Daniel Vetter 2018-04-26 9:20 ` Daniel Vetter 2018-04-26 9:20 ` Daniel Vetter 2018-04-26 9:24 ` Christoph Hellwig 2018-04-26 9:24 ` Christoph Hellwig 2018-04-26 9:24 ` Christoph Hellwig 2018-04-26 9:39 ` Daniel Vetter 2018-04-26 9:39 ` Daniel Vetter 2018-04-26 9:39 ` Daniel Vetter 2018-04-25 6:24 ` [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag Alex Deucher 2018-04-25 6:24 ` Alex Deucher 2018-04-25 6:41 ` Christoph Hellwig 2018-04-25 6:41 ` Christoph Hellwig 2018-04-25 17:44 ` Alex Deucher 2018-04-25 17:44 ` Alex Deucher 2018-04-25 18:38 ` Dan Williams 2018-04-25 18:38 ` Dan Williams 2018-05-04 12:45 ` Lucas Stach 2018-03-25 10:59 ` [PATCH 5/8] drm/amdgpu: print DMA-buf status in debugfs Christian König 2018-03-25 10:59 ` Christian König 2018-03-25 10:59 ` [PATCH 6/8] drm/amdgpu: note that we can handle peer2peer DMA-buf Christian König 2018-03-25 10:59 ` Christian König 2018-03-25 10:59 ` [PATCH 7/8] drm/amdgpu: add amdgpu_gem_attach Christian König 2018-03-25 10:59 ` Christian König 2018-03-25 11:00 ` [PATCH 8/8] drm/amdgpu: add support for exporting VRAM using DMA-buf Christian König 2018-03-25 11:00 ` Christian König 2018-03-28 12:37 ` [PATCH 1/8] lib/scatterlist: add sg_set_dma_addr() helper Christoph Hellwig 2018-03-28 12:37 ` Christoph Hellwig
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180425054855.GA17038@infradead.org \ --to=hch@infradead.org \ --cc=amd-gfx@lists.freedesktop.org \ --cc=christian.koenig@amd.com \ --cc=dan.j.williams@intel.com \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=jglisse@redhat.com \ --cc=linaro-mm-sig@lists.linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=logang@deltatee.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.