From: Christoph Hellwig <hch@infradead.org> To: "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 11:48:47 -0700 [thread overview] Message-ID: <20180424184847.GA3247@infradead.org> (raw) In-Reply-To: <20180420152111.GR31310@phenom.ffwll.local> On Fri, Apr 20, 2018 at 05:21:11PM +0200, Daniel Vetter wrote: > > At the very lowest level they will need to be handled differently for > > many architectures, the questions is at what point we'll do the > > branching out. > > Having at least struct page also in that list with (dma_addr_t, lenght) > pairs has a bunch of benefits for drivers in unifying buffer handling > code. You just pass that one single list around, use the dma_addr_t side > for gpu access (generally bashing it into gpu ptes). And the struct page > (if present) for cpu access, using kmap or vm_insert_*. We generally > ignore virt, if we do need a full mapping then we construct a vmap for > that buffer of our own. Well, for mapping a resource (which gets back to the start of the discussion) you will need an explicit virt pointer. You also need an explicit virt pointer and not just page_address/kmap for users of dma_get_sgtable, because for many architectures you will need to flush the virtual address used to access the data, which might be a vmap/ioremap style mapping retourned from dma_alloc_address, and not the directly mapped kernel address. Here is another idea at the low-level dma API level: - dma_get_sgtable goes away. The replacement is a new dma_alloc_remap helper that takes the virtual address returned from dma_alloc_attrs/coherent and creates a dma_addr_t for the given new device. If the original allocation was a coherent one no cache flushing is required either (because the arch made sure it is coherent), if the original allocation used DMA_ATTR_NON_CONSISTENT the new allocation will need dma_cache_sync calls as well. - you never even try to share a mapping retourned from dma_map_resource - instead each device using it creates a new mapping, which makes sense as no virtual addresses are involved at all. > So maybe a list of (struct page *, dma_addr_t, num_pages) would suit best, > with struct page * being optional (if it's a resource, or something else > that the kernel core mm isn't aware of). But that only has benefits if we > really roll it out everywhere, in all the subsystems and drivers, since if > we don't we've made the struct pages ** <-> sgt conversion fun only worse > by adding a 3 representation of gpu buffer object backing storage. 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.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org> To: "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 11:48:47 -0700 [thread overview] Message-ID: <20180424184847.GA3247@infradead.org> (raw) In-Reply-To: <20180420152111.GR31310@phenom.ffwll.local> On Fri, Apr 20, 2018 at 05:21:11PM +0200, Daniel Vetter wrote: > > At the very lowest level they will need to be handled differently for > > many architectures, the questions is at what point we'll do the > > branching out. > > Having at least struct page also in that list with (dma_addr_t, lenght) > pairs has a bunch of benefits for drivers in unifying buffer handling > code. You just pass that one single list around, use the dma_addr_t side > for gpu access (generally bashing it into gpu ptes). And the struct page > (if present) for cpu access, using kmap or vm_insert_*. We generally > ignore virt, if we do need a full mapping then we construct a vmap for > that buffer of our own. Well, for mapping a resource (which gets back to the start of the discussion) you will need an explicit virt pointer. You also need an explicit virt pointer and not just page_address/kmap for users of dma_get_sgtable, because for many architectures you will need to flush the virtual address used to access the data, which might be a vmap/ioremap style mapping retourned from dma_alloc_address, and not the directly mapped kernel address. Here is another idea at the low-level dma API level: - dma_get_sgtable goes away. The replacement is a new dma_alloc_remap helper that takes the virtual address returned from dma_alloc_attrs/coherent and creates a dma_addr_t for the given new device. If the original allocation was a coherent one no cache flushing is required either (because the arch made sure it is coherent), if the original allocation used DMA_ATTR_NON_CONSISTENT the new allocation will need dma_cache_sync calls as well. - you never even try to share a mapping retourned from dma_map_resource - instead each device using it creates a new mapping, which makes sense as no virtual addresses are involved at all. > So maybe a list of (struct page *, dma_addr_t, num_pages) would suit best, > with struct page * being optional (if it's a resource, or something else > that the kernel core mm isn't aware of). But that only has benefits if we > really roll it out everywhere, in all the subsystems and drivers, since if > we don't we've made the struct pages ** <-> sgt conversion fun only worse > by adding a 3 representation of gpu buffer object backing storage. 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. _______________________________________________ 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-24 18:48 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 [this message] 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 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=20180424184847.GA3247@infradead.org \ --to=hch@infradead.org \ --cc=amd-gfx@lists.freedesktop.org \ --cc=christian.koenig@amd.com \ --cc=dan.j.williams@intel.com \ --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.