All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: "Christoph Hellwig" <hch@lst.de>,
	"Pawel Osciak" <pawel@osciak.com>,
	"Kyungmin Park" <kyungmin.park@samsung.com>,
	"Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>,
	"Russell King" <linux@armlinux.org.uk>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	iommu@lists.linux-foundation.org,
	linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-media@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] videobuf2: replace a layering violation with dma_map_resource
Date: Thu, 17 Jan 2019 18:21:52 +0100	[thread overview]
Message-ID: <20190117172152.GA32292@lst.de> (raw)
In-Reply-To: <6f8892ac-c2aa-10df-c74f-ba032bf75160@samsung.com>

On Mon, Jan 14, 2019 at 01:42:26PM +0100, Marek Szyprowski wrote:
> Hi Christoph,
> 
> On 2019-01-11 19:17, Christoph Hellwig wrote:
> > vb2_dc_get_userptr pokes into arm direct mapping details to get the
> > resemblance of a dma address for a a physical address that does is
> > not backed by a page struct.  Not only is this not portable to other
> > architectures with dma direct mapping offsets, but also not to uses
> > of IOMMUs of any kind.  Switch to the proper dma_map_resource /
> > dma_unmap_resource interface instead.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> There are checks for IOMMU presence in other places in vb2-dma-contig,
> so it was used only when no IOMMU is available, but I agree that the
> hacky code should be replaced by a generic code if possible.
> 
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> 
> V4L2 pipeline works fine on older Exynos-based boards with CMA and IOMMU
> disabled.

Do you know if these rely on the offsets?  E.g. would they still work
with the patch below applied on top.  That would keep the map_resource
semantics as-is as solve the issue pointed out by Robin for now.

If not I can only think of a flag to bypass the offseting for now, but
that would be pretty ugly.  Or go for the long-term solution of
discovering the relationship between the two devices, as done by the
PCIe P2P code..

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 8e0359b04957..25bd19974223 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -359,7 +359,7 @@ EXPORT_SYMBOL(dma_direct_map_sg);
 dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr,
 		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
-	dma_addr_t dma_addr = phys_to_dma(dev, paddr);
+	dma_addr_t dma_addr = paddr;
 
 	if (unlikely(!dma_direct_possible(dev, dma_addr, size))) {
 		report_addr(dev, dma_addr, size);


WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>,
	"Pawel Osciak" <pawel@osciak.com>,
	"Russell King" <linux@armlinux.org.uk>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	"Kyungmin Park" <kyungmin.park@samsung.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	linuxppc-dev@lists.ozlabs.org, "Christoph Hellwig" <hch@lst.de>,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 3/3] videobuf2: replace a layering violation with dma_map_resource
Date: Thu, 17 Jan 2019 18:21:52 +0100	[thread overview]
Message-ID: <20190117172152.GA32292@lst.de> (raw)
In-Reply-To: <6f8892ac-c2aa-10df-c74f-ba032bf75160@samsung.com>

On Mon, Jan 14, 2019 at 01:42:26PM +0100, Marek Szyprowski wrote:
> Hi Christoph,
> 
> On 2019-01-11 19:17, Christoph Hellwig wrote:
> > vb2_dc_get_userptr pokes into arm direct mapping details to get the
> > resemblance of a dma address for a a physical address that does is
> > not backed by a page struct.  Not only is this not portable to other
> > architectures with dma direct mapping offsets, but also not to uses
> > of IOMMUs of any kind.  Switch to the proper dma_map_resource /
> > dma_unmap_resource interface instead.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> There are checks for IOMMU presence in other places in vb2-dma-contig,
> so it was used only when no IOMMU is available, but I agree that the
> hacky code should be replaced by a generic code if possible.
> 
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> 
> V4L2 pipeline works fine on older Exynos-based boards with CMA and IOMMU
> disabled.

Do you know if these rely on the offsets?  E.g. would they still work
with the patch below applied on top.  That would keep the map_resource
semantics as-is as solve the issue pointed out by Robin for now.

If not I can only think of a flag to bypass the offseting for now, but
that would be pretty ugly.  Or go for the long-term solution of
discovering the relationship between the two devices, as done by the
PCIe P2P code..

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 8e0359b04957..25bd19974223 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -359,7 +359,7 @@ EXPORT_SYMBOL(dma_direct_map_sg);
 dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr,
 		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
-	dma_addr_t dma_addr = phys_to_dma(dev, paddr);
+	dma_addr_t dma_addr = paddr;
 
 	if (unlikely(!dma_direct_possible(dev, dma_addr, size))) {
 		report_addr(dev, dma_addr, size);


WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>,
	"Pawel Osciak" <pawel@osciak.com>,
	"Russell King" <linux@armlinux.org.uk>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	"Kyungmin Park" <kyungmin.park@samsung.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	linuxppc-dev@lists.ozlabs.org, "Christoph Hellwig" <hch@lst.de>,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 3/3] videobuf2: replace a layering violation with dma_map_resource
Date: Thu, 17 Jan 2019 18:21:52 +0100	[thread overview]
Message-ID: <20190117172152.GA32292@lst.de> (raw)
In-Reply-To: <6f8892ac-c2aa-10df-c74f-ba032bf75160@samsung.com>

On Mon, Jan 14, 2019 at 01:42:26PM +0100, Marek Szyprowski wrote:
> Hi Christoph,
> 
> On 2019-01-11 19:17, Christoph Hellwig wrote:
> > vb2_dc_get_userptr pokes into arm direct mapping details to get the
> > resemblance of a dma address for a a physical address that does is
> > not backed by a page struct.  Not only is this not portable to other
> > architectures with dma direct mapping offsets, but also not to uses
> > of IOMMUs of any kind.  Switch to the proper dma_map_resource /
> > dma_unmap_resource interface instead.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> There are checks for IOMMU presence in other places in vb2-dma-contig,
> so it was used only when no IOMMU is available, but I agree that the
> hacky code should be replaced by a generic code if possible.
> 
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> 
> V4L2 pipeline works fine on older Exynos-based boards with CMA and IOMMU
> disabled.

Do you know if these rely on the offsets?  E.g. would they still work
with the patch below applied on top.  That would keep the map_resource
semantics as-is as solve the issue pointed out by Robin for now.

If not I can only think of a flag to bypass the offseting for now, but
that would be pretty ugly.  Or go for the long-term solution of
discovering the relationship between the two devices, as done by the
PCIe P2P code..

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 8e0359b04957..25bd19974223 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -359,7 +359,7 @@ EXPORT_SYMBOL(dma_direct_map_sg);
 dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr,
 		size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
-	dma_addr_t dma_addr = phys_to_dma(dev, paddr);
+	dma_addr_t dma_addr = paddr;
 
 	if (unlikely(!dma_direct_possible(dev, dma_addr, size))) {
 		report_addr(dev, dma_addr, size);


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-01-17 17:21 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20190111181841epcas3p2d7c0bf8f5c11a9863e22ec1b12da6e1b@epcas3p2.samsung.com>
2019-01-11 18:17 ` fix a layering violation in videobuf2 and improve dma_map_resource Christoph Hellwig
2019-01-11 18:17   ` Christoph Hellwig
2019-01-11 18:17   ` Christoph Hellwig
2019-01-11 18:17   ` [PATCH 1/3] dma-mapping: remove the default map_resource implementation Christoph Hellwig
2019-01-11 18:17     ` Christoph Hellwig
2019-01-11 18:17     ` Christoph Hellwig
2019-01-14 13:12     ` Robin Murphy
2019-01-14 13:12       ` Robin Murphy
2019-01-14 17:08       ` Christoph Hellwig
2019-01-14 17:08         ` Christoph Hellwig
2019-01-14 17:08         ` Christoph Hellwig
2019-01-11 18:17   ` [PATCH 2/3] dma-mapping: don't BUG when calling dma_map_resource on RAM Christoph Hellwig
2019-01-11 18:17     ` Christoph Hellwig
2019-01-11 18:17     ` Christoph Hellwig
2019-01-14 14:16     ` Robin Murphy
2019-01-14 14:16       ` Robin Murphy
2019-01-11 18:17   ` [PATCH 3/3] videobuf2: replace a layering violation with dma_map_resource Christoph Hellwig
2019-01-11 18:17     ` Christoph Hellwig
2019-01-11 18:17     ` Christoph Hellwig
2019-01-11 19:54     ` Mauro Carvalho Chehab
2019-01-11 19:54       ` Mauro Carvalho Chehab
2019-01-11 19:54       ` Mauro Carvalho Chehab
2019-01-14 10:31       ` Christoph Hellwig
2019-01-14 10:31         ` Christoph Hellwig
2019-01-14 10:31         ` Christoph Hellwig
2019-01-14 11:04         ` Mauro Carvalho Chehab
2019-01-14 11:04           ` Mauro Carvalho Chehab
2019-01-14 11:04           ` Mauro Carvalho Chehab
2019-01-14 11:12           ` Christoph Hellwig
2019-01-14 11:12             ` Christoph Hellwig
2019-01-14 11:12             ` Christoph Hellwig
2019-01-14 12:42     ` Marek Szyprowski
2019-01-14 12:42       ` Marek Szyprowski
2019-01-14 12:42       ` Marek Szyprowski
2019-01-17 17:21       ` Christoph Hellwig [this message]
2019-01-17 17:21         ` Christoph Hellwig
2019-01-17 17:21         ` Christoph Hellwig
2019-01-18  9:41         ` Marek Szyprowski
2019-01-18  9:41           ` Marek Szyprowski
2019-01-18  9:41           ` Marek Szyprowski
2019-01-31 15:31           ` Christoph Hellwig
2019-01-31 15:31             ` Christoph Hellwig
2019-01-31 15:31             ` Christoph Hellwig
2019-01-14 11:43   ` fix a layering violation in videobuf2 and improve dma_map_resource Marek Szyprowski
2019-01-14 11:43     ` Marek Szyprowski
2019-01-14 11:43     ` Marek Szyprowski
2019-01-18 11:37 fix a layering violation in videobuf2 and improve dma_map_resource v2 Christoph Hellwig
2019-01-18 11:37 ` [PATCH 3/3] videobuf2: replace a layering violation with dma_map_resource Christoph Hellwig
2019-01-18 11:37   ` Christoph Hellwig
2019-01-18 11: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=20190117172152.GA32292@lst.de \
    --to=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mchehab@kernel.org \
    --cc=niklas.soderlund+renesas@ragnatech.se \
    --cc=pawel@osciak.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: link
Be 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.