From: Alexandre Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> To: Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org> Cc: Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, David Airlie <airlied-cv59FeDIM0c@public.gmane.org>, David Herrmann <dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>, Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Maarten Lankhorst <maarten.lankhorst-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>, nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Alexandre Courbot <gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Subject: Re: [Nouveau] [PATCH v4 2/6] drm/nouveau: map pages using DMA API on platform devices Date: Fri, 11 Jul 2014 11:35:23 +0900 [thread overview] Message-ID: <53BF4D6B.70904@nvidia.com> (raw) In-Reply-To: <20140710125849.GF17271-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org> On 07/10/2014 09:58 PM, Daniel Vetter wrote: > On Tue, Jul 08, 2014 at 05:25:57PM +0900, Alexandre Courbot wrote: >> page_to_phys() is not the correct way to obtain the DMA address of a >> buffer on a non-PCI system. Use the DMA API functions for this, which >> are portable and will allow us to use other DMA API functions for >> buffer synchronization. >> >> Signed-off-by: Alexandre Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> >> --- >> drivers/gpu/drm/nouveau/core/engine/device/base.c | 8 +++++++- >> 1 file changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/nouveau/core/engine/device/base.c b/drivers/gpu/drm/nouveau/core/engine/device/base.c >> index 18c8c7245b73..e4e9e64988fe 100644 >> --- a/drivers/gpu/drm/nouveau/core/engine/device/base.c >> +++ b/drivers/gpu/drm/nouveau/core/engine/device/base.c >> @@ -489,7 +489,10 @@ nv_device_map_page(struct nouveau_device *device, struct page *page) >> if (pci_dma_mapping_error(device->pdev, ret)) >> ret = 0; >> } else { >> - ret = page_to_phys(page); >> + ret = dma_map_page(&device->platformdev->dev, page, 0, >> + PAGE_SIZE, DMA_BIDIRECTIONAL); >> + if (dma_mapping_error(&device->platformdev->dev, ret)) >> + ret = 0; >> } >> >> return ret; >> @@ -501,6 +504,9 @@ nv_device_unmap_page(struct nouveau_device *device, dma_addr_t addr) >> if (nv_device_is_pci(device)) >> pci_unmap_page(device->pdev, addr, PAGE_SIZE, >> PCI_DMA_BIDIRECTIONAL); > > pci_map/unmap alias to dma_unmap/map when called on the underlying struct > device embedded in pci_device (like for platform drivers). Dunno whether > it's worth to track a pointer to the struct device directly and always > call dma_unmap/map. Isn't it (theoretically) possible to have a platform that does not use the DMA API for its PCI implementation and thus requires the pci_* functions to be called? I could not find such a case in -next, which suggests that all PCI platforms have been converted to the DMA API already and that we could indeed refactor this to always use the DMA functions. But at the same time the way we use APIs should not be directed by their implementation, but by their intent - and unless the PCI API has been deprecated in some way (something I am not aware of), the rule is still that you should use it on a PCI device. > > Just drive-by comment since I'm interested in how you solve this - i915 > has similar fun with buffer sharing and coherent and non-coherent > platforms. Although we don't have fun with pci and non-pci based > platforms. Yeah, I am not familiar with i915 but it seems like we are on a similar boat here (excepted ARM is more constrained as to its memory mappings). The strategy in this series is, map buffers used by user-space cached and explicitly synchronize them (since the ownership transition from user to GPU is always clearly performed by syscalls), and use coherent mappings for buffers used by the kernel which are accessed more randomly. This has solved all our coherency issues and resulted in the best performance so far.
WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Courbot <acourbot@nvidia.com> To: Daniel Vetter <daniel@ffwll.ch> Cc: Ben Skeggs <bskeggs@redhat.com>, David Airlie <airlied@linux.ie>, David Herrmann <dh.herrmann@gmail.com>, Lucas Stach <dev@lynxeye.de>, Thierry Reding <thierry.reding@gmail.com>, Maarten Lankhorst <maarten.lankhorst@canonical.com>, <nouveau@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>, <dri-devel@lists.freedesktop.org>, <linux-tegra@vger.kernel.org>, Alexandre Courbot <gnurou@gmail.com> Subject: Re: [Nouveau] [PATCH v4 2/6] drm/nouveau: map pages using DMA API on platform devices Date: Fri, 11 Jul 2014 11:35:23 +0900 [thread overview] Message-ID: <53BF4D6B.70904@nvidia.com> (raw) In-Reply-To: <20140710125849.GF17271@phenom.ffwll.local> On 07/10/2014 09:58 PM, Daniel Vetter wrote: > On Tue, Jul 08, 2014 at 05:25:57PM +0900, Alexandre Courbot wrote: >> page_to_phys() is not the correct way to obtain the DMA address of a >> buffer on a non-PCI system. Use the DMA API functions for this, which >> are portable and will allow us to use other DMA API functions for >> buffer synchronization. >> >> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> >> --- >> drivers/gpu/drm/nouveau/core/engine/device/base.c | 8 +++++++- >> 1 file changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/nouveau/core/engine/device/base.c b/drivers/gpu/drm/nouveau/core/engine/device/base.c >> index 18c8c7245b73..e4e9e64988fe 100644 >> --- a/drivers/gpu/drm/nouveau/core/engine/device/base.c >> +++ b/drivers/gpu/drm/nouveau/core/engine/device/base.c >> @@ -489,7 +489,10 @@ nv_device_map_page(struct nouveau_device *device, struct page *page) >> if (pci_dma_mapping_error(device->pdev, ret)) >> ret = 0; >> } else { >> - ret = page_to_phys(page); >> + ret = dma_map_page(&device->platformdev->dev, page, 0, >> + PAGE_SIZE, DMA_BIDIRECTIONAL); >> + if (dma_mapping_error(&device->platformdev->dev, ret)) >> + ret = 0; >> } >> >> return ret; >> @@ -501,6 +504,9 @@ nv_device_unmap_page(struct nouveau_device *device, dma_addr_t addr) >> if (nv_device_is_pci(device)) >> pci_unmap_page(device->pdev, addr, PAGE_SIZE, >> PCI_DMA_BIDIRECTIONAL); > > pci_map/unmap alias to dma_unmap/map when called on the underlying struct > device embedded in pci_device (like for platform drivers). Dunno whether > it's worth to track a pointer to the struct device directly and always > call dma_unmap/map. Isn't it (theoretically) possible to have a platform that does not use the DMA API for its PCI implementation and thus requires the pci_* functions to be called? I could not find such a case in -next, which suggests that all PCI platforms have been converted to the DMA API already and that we could indeed refactor this to always use the DMA functions. But at the same time the way we use APIs should not be directed by their implementation, but by their intent - and unless the PCI API has been deprecated in some way (something I am not aware of), the rule is still that you should use it on a PCI device. > > Just drive-by comment since I'm interested in how you solve this - i915 > has similar fun with buffer sharing and coherent and non-coherent > platforms. Although we don't have fun with pci and non-pci based > platforms. Yeah, I am not familiar with i915 but it seems like we are on a similar boat here (excepted ARM is more constrained as to its memory mappings). The strategy in this series is, map buffers used by user-space cached and explicitly synchronize them (since the ownership transition from user to GPU is always clearly performed by syscalls), and use coherent mappings for buffers used by the kernel which are accessed more randomly. This has solved all our coherency issues and resulted in the best performance so far.
next prev parent reply other threads:[~2014-07-11 2:35 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-07-08 8:25 [PATCH v4 0/6] drm: nouveau: memory coherency on ARM Alexandre Courbot 2014-07-08 8:25 ` Alexandre Courbot [not found] ` <1404807961-30530-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2014-07-08 8:25 ` [PATCH v4 1/6] drm/ttm: expose CPU address of DMA-allocated pages Alexandre Courbot 2014-07-08 8:25 ` Alexandre Courbot 2014-07-08 8:25 ` [PATCH v4 2/6] drm/nouveau: map pages using DMA API on platform devices Alexandre Courbot 2014-07-08 8:25 ` Alexandre Courbot [not found] ` <1404807961-30530-3-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2014-07-10 12:58 ` Daniel Vetter 2014-07-10 12:58 ` [Nouveau] " Daniel Vetter [not found] ` <20140710125849.GF17271-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org> 2014-07-11 2:35 ` Alexandre Courbot [this message] 2014-07-11 2:35 ` Alexandre Courbot [not found] ` <53BF4D6B.70904-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2014-07-11 2:50 ` Ben Skeggs 2014-07-11 2:50 ` [Nouveau] " Ben Skeggs [not found] ` <CACAvsv7eER4VmbR81Ym=YE7fQZ9cNuJsb5372SAuSX+PQfYyrQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-07-11 2:57 ` Alexandre Courbot 2014-07-11 2:57 ` Alexandre Courbot 2014-07-11 9:53 ` Lucas Stach 2014-07-11 9:53 ` Lucas Stach 2014-07-11 7:38 ` Daniel Vetter 2014-07-11 7:38 ` Daniel Vetter 2014-07-08 8:25 ` [PATCH v4 3/6] drm/nouveau: introduce nv_device_is_cpu_coherent() Alexandre Courbot 2014-07-08 8:25 ` Alexandre Courbot 2014-07-08 8:25 ` [PATCH v4 4/6] drm/nouveau: synchronize BOs when required Alexandre Courbot 2014-07-08 8:25 ` Alexandre Courbot 2014-07-10 13:04 ` [Nouveau] " Daniel Vetter 2014-07-10 13:04 ` Daniel Vetter [not found] ` <20140710130449.GG17271-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org> 2014-07-11 2:40 ` Alexandre Courbot 2014-07-11 2:40 ` Alexandre Courbot [not found] ` <53BF4E9B.7090606-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2014-07-11 7:41 ` Daniel Vetter 2014-07-11 7:41 ` [Nouveau] " Daniel Vetter [not found] ` <20140711074138.GW17271-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org> 2014-07-11 9:35 ` Alexandre Courbot 2014-07-11 9:35 ` [Nouveau] " Alexandre Courbot 2014-07-08 8:26 ` [PATCH v4 5/6] drm/nouveau: implement explicitly coherent BOs Alexandre Courbot 2014-07-08 8:26 ` Alexandre Courbot 2014-07-08 8:26 ` [PATCH v4 6/6] drm/nouveau: allocate GPFIFOs and fences coherently Alexandre Courbot 2014-07-08 8:26 ` Alexandre Courbot
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=53BF4D6B.70904@nvidia.com \ --to=acourbot-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \ --cc=airlied-cv59FeDIM0c@public.gmane.org \ --cc=bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=daniel-/w4YWyX8dFk@public.gmane.org \ --cc=dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org \ --cc=dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \ --cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=maarten.lankhorst-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \ --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \ --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ /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.