From: Christoph Hellwig <hch@lst.de>
To: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Christoph Hellwig <hch@lst.de>,
"joro@8bytes.org" <joro@8bytes.org>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
"wsa+renesas@sang-engineering.com"
<wsa+renesas@sang-engineering.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>
Subject: Re: [RFC PATCH v6 5/5] mmc: queue: Use bigger segments if IOMMU can merge the segments
Date: Mon, 17 Jun 2019 08:53:31 +0200 [thread overview]
Message-ID: <20190617065331.GA5456@lst.de> (raw)
In-Reply-To: <OSBPR01MB3590FA5DB10D9EF34F551335D8EB0@OSBPR01MB3590.jpnprd01.prod.outlook.com>
On Mon, Jun 17, 2019 at 06:46:33AM +0000, Yoshihiro Shimoda wrote:
> > can_merge seems a little too generic a name to me. Maybe can_iommu_merge?
>
> I'll fix the name. Also, only the device_iommu_mapped() condition wiil cause
> a problem on iommu=pt [1]. So, I'll add another condition here.
Instead of adding another condition here I think we need to properly
abstract it out in the DMA layer. E.g. have a
unsigned long dma_get_merge_boundary(struct device *dev)
{
const struct dma_map_ops *ops = get_dma_ops(dev);
if (!ops || !ops->get_merge_boundary)
return 0; /* can't merge */
return ops->get_merge_boundary(dev);
}
and then implement the method in dma-iommu.c.
blk_queue_can_use_iommu_merging then comes:
bool blk_queue_enable_iommu_merging(struct request_queue *q,
struct device *dev)
{
unsigned long boundary = dma_get_merge_boundary(dev);
if (!boundary)
return false;
blk_queue_virt_boundary(q, boundary);
return true;
}
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
To: Yoshihiro Shimoda
<yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Cc: "axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org"
<axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>,
"linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/@public.gmane.org"
<wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/@public.gmane.org>,
"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Subject: Re: [RFC PATCH v6 5/5] mmc: queue: Use bigger segments if IOMMU can merge the segments
Date: Mon, 17 Jun 2019 08:53:31 +0200 [thread overview]
Message-ID: <20190617065331.GA5456@lst.de> (raw)
In-Reply-To: <OSBPR01MB3590FA5DB10D9EF34F551335D8EB0-zhdMvvdcU0ZkIAJEWnuByncolHNk5qUtvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
On Mon, Jun 17, 2019 at 06:46:33AM +0000, Yoshihiro Shimoda wrote:
> > can_merge seems a little too generic a name to me. Maybe can_iommu_merge?
>
> I'll fix the name. Also, only the device_iommu_mapped() condition wiil cause
> a problem on iommu=pt [1]. So, I'll add another condition here.
Instead of adding another condition here I think we need to properly
abstract it out in the DMA layer. E.g. have a
unsigned long dma_get_merge_boundary(struct device *dev)
{
const struct dma_map_ops *ops = get_dma_ops(dev);
if (!ops || !ops->get_merge_boundary)
return 0; /* can't merge */
return ops->get_merge_boundary(dev);
}
and then implement the method in dma-iommu.c.
blk_queue_can_use_iommu_merging then comes:
bool blk_queue_enable_iommu_merging(struct request_queue *q,
struct device *dev)
{
unsigned long boundary = dma_get_merge_boundary(dev);
if (!boundary)
return false;
blk_queue_virt_boundary(q, boundary);
return true;
}
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
"linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>,
"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"wsa+renesas@sang-engineering.com"
<wsa+renesas@sang-engineering.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC PATCH v6 5/5] mmc: queue: Use bigger segments if IOMMU can merge the segments
Date: Mon, 17 Jun 2019 08:53:31 +0200 [thread overview]
Message-ID: <20190617065331.GA5456@lst.de> (raw)
In-Reply-To: <OSBPR01MB3590FA5DB10D9EF34F551335D8EB0@OSBPR01MB3590.jpnprd01.prod.outlook.com>
On Mon, Jun 17, 2019 at 06:46:33AM +0000, Yoshihiro Shimoda wrote:
> > can_merge seems a little too generic a name to me. Maybe can_iommu_merge?
>
> I'll fix the name. Also, only the device_iommu_mapped() condition wiil cause
> a problem on iommu=pt [1]. So, I'll add another condition here.
Instead of adding another condition here I think we need to properly
abstract it out in the DMA layer. E.g. have a
unsigned long dma_get_merge_boundary(struct device *dev)
{
const struct dma_map_ops *ops = get_dma_ops(dev);
if (!ops || !ops->get_merge_boundary)
return 0; /* can't merge */
return ops->get_merge_boundary(dev);
}
and then implement the method in dma-iommu.c.
blk_queue_can_use_iommu_merging then comes:
bool blk_queue_enable_iommu_merging(struct request_queue *q,
struct device *dev)
{
unsigned long boundary = dma_get_merge_boundary(dev);
if (!boundary)
return false;
blk_queue_virt_boundary(q, boundary);
return true;
}
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-06-17 6:54 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-13 10:20 [RFC PATCH v6 0/5] treewide: improve R-Car SDHI performance Yoshihiro Shimoda
2019-06-13 10:20 ` Yoshihiro Shimoda
2019-06-13 10:20 ` Yoshihiro Shimoda
2019-06-13 10:20 ` [RFC PATCH v6 1/5] iommu: add an exported function to get minimum page size for a domain Yoshihiro Shimoda
2019-06-13 10:20 ` Yoshihiro Shimoda
2019-06-13 10:20 ` Yoshihiro Shimoda
2019-06-13 19:37 ` Wolfram Sang
2019-06-13 19:37 ` Wolfram Sang
2019-06-13 19:37 ` Wolfram Sang
2019-06-14 7:16 ` Christoph Hellwig
2019-06-14 7:16 ` Christoph Hellwig
2019-06-14 7:16 ` Christoph Hellwig
2019-06-17 5:08 ` Yoshihiro Shimoda
2019-06-17 5:08 ` Yoshihiro Shimoda
2019-06-17 5:08 ` Yoshihiro Shimoda
2019-06-14 9:41 ` Robin Murphy
2019-06-14 9:41 ` Robin Murphy
2019-06-14 9:41 ` Robin Murphy
2019-06-17 5:23 ` Yoshihiro Shimoda
2019-06-17 5:23 ` Yoshihiro Shimoda
2019-06-17 5:23 ` Yoshihiro Shimoda
2019-06-13 10:20 ` [RFC PATCH v6 2/5] block: sort headers on blk-setting.c Yoshihiro Shimoda
2019-06-13 10:20 ` Yoshihiro Shimoda
2019-06-13 10:20 ` Yoshihiro Shimoda
2019-06-13 19:40 ` Wolfram Sang
2019-06-13 19:40 ` Wolfram Sang
2019-06-13 19:40 ` Wolfram Sang
2019-06-13 10:20 ` [RFC PATCH v6 3/5] block: add a helper function to merge the segments by an IOMMU Yoshihiro Shimoda
2019-06-13 10:20 ` Yoshihiro Shimoda
2019-06-13 10:20 ` Yoshihiro Shimoda
2019-06-14 7:22 ` Christoph Hellwig
2019-06-14 7:22 ` Christoph Hellwig
2019-06-14 7:22 ` Christoph Hellwig
2019-06-14 9:54 ` Robin Murphy
2019-06-14 9:54 ` Robin Murphy
2019-06-14 9:54 ` Robin Murphy
2019-06-17 6:29 ` Yoshihiro Shimoda
2019-06-17 6:29 ` Yoshihiro Shimoda
2019-06-17 6:29 ` Yoshihiro Shimoda
2019-06-13 10:20 ` [RFC PATCH v6 4/5] mmc: tmio: Use dma_max_mapping_size() instead of a workaround Yoshihiro Shimoda
2019-06-13 10:20 ` Yoshihiro Shimoda
2019-06-13 10:20 ` Yoshihiro Shimoda
2019-06-13 19:45 ` Wolfram Sang
2019-06-13 19:45 ` Wolfram Sang
2019-06-13 19:45 ` Wolfram Sang
2019-06-17 4:25 ` Yoshihiro Shimoda
2019-06-17 4:25 ` Yoshihiro Shimoda
2019-06-17 4:25 ` Yoshihiro Shimoda
2019-06-13 20:35 ` Geert Uytterhoeven
2019-06-13 20:35 ` Geert Uytterhoeven
2019-06-13 20:35 ` Geert Uytterhoeven
2019-06-14 7:18 ` Christoph Hellwig
2019-06-14 7:18 ` Christoph Hellwig
2019-06-14 7:18 ` Christoph Hellwig
2019-06-14 7:27 ` Geert Uytterhoeven
2019-06-14 7:27 ` Geert Uytterhoeven
2019-06-14 7:27 ` Geert Uytterhoeven
2019-06-17 4:54 ` Yoshihiro Shimoda
2019-06-17 4:54 ` Yoshihiro Shimoda
2019-06-17 4:54 ` Yoshihiro Shimoda
2019-06-17 6:23 ` Geert Uytterhoeven
2019-06-17 6:23 ` Geert Uytterhoeven
2019-06-17 6:23 ` Geert Uytterhoeven
2019-06-17 6:54 ` Yoshihiro Shimoda
2019-06-17 6:54 ` Yoshihiro Shimoda
2019-06-17 6:54 ` Yoshihiro Shimoda
2019-06-13 10:20 ` [RFC PATCH v6 5/5] mmc: queue: Use bigger segments if IOMMU can merge the segments Yoshihiro Shimoda
2019-06-13 10:20 ` Yoshihiro Shimoda
2019-06-13 10:20 ` Yoshihiro Shimoda
2019-06-13 19:58 ` Wolfram Sang
2019-06-13 19:58 ` Wolfram Sang
2019-06-13 19:58 ` Wolfram Sang
2019-06-17 6:38 ` Yoshihiro Shimoda
2019-06-17 6:38 ` Yoshihiro Shimoda
2019-06-17 6:38 ` Yoshihiro Shimoda
2019-06-14 7:24 ` Christoph Hellwig
2019-06-14 7:24 ` Christoph Hellwig
2019-06-14 7:24 ` Christoph Hellwig
2019-06-14 10:42 ` Wolfram Sang
2019-06-14 10:42 ` Wolfram Sang
2019-06-14 10:42 ` Wolfram Sang
2019-06-17 6:46 ` Yoshihiro Shimoda
2019-06-17 6:46 ` Yoshihiro Shimoda
2019-06-17 6:46 ` Yoshihiro Shimoda
2019-06-17 6:53 ` Christoph Hellwig [this message]
2019-06-17 6:53 ` Christoph Hellwig
2019-06-17 6:53 ` Christoph Hellwig
2019-06-17 7:02 ` Yoshihiro Shimoda
2019-06-17 7:02 ` Yoshihiro Shimoda
2019-06-17 7:02 ` Yoshihiro Shimoda
2019-06-13 19:36 ` [RFC PATCH v6 0/5] treewide: improve R-Car SDHI performance Wolfram Sang
2019-06-13 19:36 ` Wolfram Sang
2019-06-13 19:36 ` Wolfram Sang
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=20190617065331.GA5456@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=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.