From: Christoph Hellwig <hch@lst.de>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
ulf.hansson@linaro.org, hch@lst.de, robin.murphy@arm.com,
joro@8bytes.org, axboe@kernel.dk,
wsa+renesas@sang-engineering.com, linux-mmc@vger.kernel.org,
iommu@lists.linux-foundation.org, linux-block@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
Subject: Re: [RFC PATCH v7 2/5] iommu/dma: Add a new dma_map_ops of get_merge_boundary()
Date: Mon, 24 Jun 2019 08:21:57 +0200 [thread overview]
Message-ID: <20190624062157.GB2989@lst.de> (raw)
In-Reply-To: <8bce95ea-93ac-e783-af7c-ec5bfb8e82f6@samsung.com>
On Fri, Jun 21, 2019 at 09:59:21AM +0200, Marek Szyprowski wrote:
> Hi,
>
> On 2019-06-20 10:50, Yoshihiro Shimoda wrote:
> > This patch adds a new dma_map_ops of get_merge_boundary() to
> > expose the DMA merge boundary if the domain type is IOMMU_DOMAIN_DMA.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > ---
> > drivers/iommu/dma-iommu.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 205d694..9950cb5 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -1091,6 +1091,16 @@ static int iommu_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
> > return ret;
> > }
> >
> > +static unsigned long iommu_dma_get_merge_boundary(struct device *dev)
> > +{
> > + struct iommu_domain *domain = iommu_get_dma_domain(dev);
> > +
> > + if (domain->type != IOMMU_DOMAIN_DMA)
> > + return 0; /* can't merge */
> > +
> > + return (1 << __ffs(domain->pgsize_bitmap)) - 1;
> > +}
>
> I really wonder if there is any IOMMU, which doesn't support 4KiB pages.
> Cannot you simply assume that the merge boundary is 4KiB and avoid
> adding this new API?
No idea if we have one, but I would not be surprised if one shows
up on a system only built to run with 64k pages for example.
Either way the abstraction seems light and self-explanatory, so I see
now reason not to have it even if we assume it would always return
4k, especially as we'd also still need a flag at the dma_map_ops level
to indicate if segement merging is supported at all.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: axboe@kernel.dk, linux-renesas-soc@vger.kernel.org,
ulf.hansson@linaro.org, linux-mmc@vger.kernel.org, hch@lst.de,
linux-block@vger.kernel.org, wsa+renesas@sang-engineering.com,
iommu@lists.linux-foundation.org, robin.murphy@arm.com
Subject: Re: [RFC PATCH v7 2/5] iommu/dma: Add a new dma_map_ops of get_merge_boundary()
Date: Mon, 24 Jun 2019 08:21:57 +0200 [thread overview]
Message-ID: <20190624062157.GB2989@lst.de> (raw)
In-Reply-To: <8bce95ea-93ac-e783-af7c-ec5bfb8e82f6@samsung.com>
On Fri, Jun 21, 2019 at 09:59:21AM +0200, Marek Szyprowski wrote:
> Hi,
>
> On 2019-06-20 10:50, Yoshihiro Shimoda wrote:
> > This patch adds a new dma_map_ops of get_merge_boundary() to
> > expose the DMA merge boundary if the domain type is IOMMU_DOMAIN_DMA.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > ---
> > drivers/iommu/dma-iommu.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 205d694..9950cb5 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -1091,6 +1091,16 @@ static int iommu_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
> > return ret;
> > }
> >
> > +static unsigned long iommu_dma_get_merge_boundary(struct device *dev)
> > +{
> > + struct iommu_domain *domain = iommu_get_dma_domain(dev);
> > +
> > + if (domain->type != IOMMU_DOMAIN_DMA)
> > + return 0; /* can't merge */
> > +
> > + return (1 << __ffs(domain->pgsize_bitmap)) - 1;
> > +}
>
> I really wonder if there is any IOMMU, which doesn't support 4KiB pages.
> Cannot you simply assume that the merge boundary is 4KiB and avoid
> adding this new API?
No idea if we have one, but I would not be surprised if one shows
up on a system only built to run with 64k pages for example.
Either way the abstraction seems light and self-explanatory, so I see
now reason not to have it even if we assume it would always return
4k, especially as we'd also still need a flag at the dma_map_ops level
to indicate if segement merging is supported at all.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
To: Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Cc: axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
hch-jcswGhMUV9g@public.gmane.org,
linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
robin.murphy-5wv7dgnIgG8@public.gmane.org
Subject: Re: [RFC PATCH v7 2/5] iommu/dma: Add a new dma_map_ops of get_merge_boundary()
Date: Mon, 24 Jun 2019 08:21:57 +0200 [thread overview]
Message-ID: <20190624062157.GB2989@lst.de> (raw)
In-Reply-To: <8bce95ea-93ac-e783-af7c-ec5bfb8e82f6-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Fri, Jun 21, 2019 at 09:59:21AM +0200, Marek Szyprowski wrote:
> Hi,
>
> On 2019-06-20 10:50, Yoshihiro Shimoda wrote:
> > This patch adds a new dma_map_ops of get_merge_boundary() to
> > expose the DMA merge boundary if the domain type is IOMMU_DOMAIN_DMA.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> > ---
> > drivers/iommu/dma-iommu.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 205d694..9950cb5 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -1091,6 +1091,16 @@ static int iommu_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
> > return ret;
> > }
> >
> > +static unsigned long iommu_dma_get_merge_boundary(struct device *dev)
> > +{
> > + struct iommu_domain *domain = iommu_get_dma_domain(dev);
> > +
> > + if (domain->type != IOMMU_DOMAIN_DMA)
> > + return 0; /* can't merge */
> > +
> > + return (1 << __ffs(domain->pgsize_bitmap)) - 1;
> > +}
>
> I really wonder if there is any IOMMU, which doesn't support 4KiB pages.
> Cannot you simply assume that the merge boundary is 4KiB and avoid
> adding this new API?
No idea if we have one, but I would not be surprised if one shows
up on a system only built to run with 64k pages for example.
Either way the abstraction seems light and self-explanatory, so I see
now reason not to have it even if we assume it would always return
4k, especially as we'd also still need a flag at the dma_map_ops level
to indicate if segement merging is supported at all.
next prev parent reply other threads:[~2019-06-24 6:22 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-20 8:50 [RFC PATCH v7 0/5] treewide: improve R-Car SDHI performance Yoshihiro Shimoda
2019-06-20 8:50 ` Yoshihiro Shimoda
2019-06-20 8:50 ` Yoshihiro Shimoda
2019-06-20 8:50 ` [RFC PATCH v7 1/5] dma: Introduce dma_get_merge_boundary() Yoshihiro Shimoda
2019-06-20 8:50 ` Yoshihiro Shimoda
2019-06-20 8:50 ` Yoshihiro Shimoda
2019-06-24 6:20 ` Christoph Hellwig
2019-06-24 6:20 ` Christoph Hellwig
2019-06-24 6:20 ` Christoph Hellwig
2019-06-20 8:50 ` [RFC PATCH v7 2/5] iommu/dma: Add a new dma_map_ops of get_merge_boundary() Yoshihiro Shimoda
2019-06-20 8:50 ` Yoshihiro Shimoda
2019-06-20 8:50 ` Yoshihiro Shimoda
2019-06-21 7:59 ` Marek Szyprowski
2019-06-21 7:59 ` Marek Szyprowski
2019-06-21 7:59 ` Marek Szyprowski
2019-06-24 6:21 ` Christoph Hellwig [this message]
2019-06-24 6:21 ` Christoph Hellwig
2019-06-24 6:21 ` Christoph Hellwig
2019-06-20 8:50 ` [RFC PATCH v7 3/5] block: sort headers on blk-setting.c Yoshihiro Shimoda
2019-06-20 8:50 ` Yoshihiro Shimoda
2019-06-20 8:50 ` Yoshihiro Shimoda
2019-06-20 8:50 ` [RFC PATCH v7 4/5] block: add a helper function to merge the segments Yoshihiro Shimoda
2019-06-20 8:50 ` Yoshihiro Shimoda
2019-06-20 8:50 ` Yoshihiro Shimoda
2019-06-24 6:22 ` Christoph Hellwig
2019-06-24 6:22 ` Christoph Hellwig
2019-06-24 6:22 ` Christoph Hellwig
2019-06-20 8:50 ` [RFC PATCH v7 5/5] mmc: queue: Use bigger segments if DMA MAP layer can " Yoshihiro Shimoda
2019-06-20 8:50 ` Yoshihiro Shimoda
2019-06-20 8:50 ` Yoshihiro Shimoda
2019-06-24 6:24 ` Christoph Hellwig
2019-06-24 6:24 ` Christoph Hellwig
2019-06-24 6:24 ` Christoph Hellwig
2019-07-08 11:45 ` Ulf Hansson
2019-07-08 11:45 ` Ulf Hansson
2019-07-08 11:45 ` Ulf Hansson
2019-07-01 8:32 ` [RFC PATCH v7 0/5] treewide: improve R-Car SDHI performance Christoph Hellwig
2019-07-01 8:32 ` Christoph Hellwig
2019-07-01 8:32 ` Christoph Hellwig
2019-07-08 11:45 ` Ulf Hansson
2019-07-08 11:45 ` Ulf Hansson
2019-07-08 11:45 ` Ulf Hansson
2019-07-08 16:22 ` Christoph Hellwig
2019-07-08 16:22 ` Christoph Hellwig
2019-07-08 16:22 ` 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=20190624062157.GB2989@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=robin.murphy@arm.com \
--cc=ulf.hansson@linaro.org \
--cc=wsa+renesas@sang-engineering.com \
--cc=yoshihiro.shimoda.uh@renesas.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.