From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
To: joro@8bytes.org, axboe@kernel.dk, ulf.hansson@linaro.org,
wsa+renesas@sang-engineering.com
Cc: linux-renesas-soc@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-block@vger.kernel.org, iommu@lists.linux-foundation.org,
hch@lst.de
Subject: [RFC PATCH v6 5/5] mmc: queue: Use bigger segments if IOMMU can merge the segments
Date: Thu, 13 Jun 2019 19:20:15 +0900 [thread overview]
Message-ID: <1560421215-10750-6-git-send-email-yoshihiro.shimoda.uh@renesas.com> (raw)
In-Reply-To: <1560421215-10750-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>
If max_segs of a mmc host is smaller than BLK_MAX_SEGMENTS,
the mmc subsystem tries to use such bigger segments by using
IOMMU subsystem, and then the mmc subsystem exposes such information
to the block layer by using blk_queue_can_use_iommu_merging().
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/mmc/core/queue.c | 33 +++++++++++++++++++++++++++++----
include/linux/mmc/host.h | 1 +
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index b5b9c61..59d7606 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -196,6 +196,11 @@ static void mmc_queue_setup_discard(struct request_queue *q,
blk_queue_flag_set(QUEUE_FLAG_SECERASE, q);
}
+static unsigned int mmc_get_max_segments(struct mmc_host *host)
+{
+ return host->can_merge ? BLK_MAX_SEGMENTS : host->max_segs;
+}
+
/**
* mmc_init_request() - initialize the MMC-specific per-request data
* @q: the request queue
@@ -209,7 +214,7 @@ static int __mmc_init_request(struct mmc_queue *mq, struct request *req,
struct mmc_card *card = mq->card;
struct mmc_host *host = card->host;
- mq_rq->sg = mmc_alloc_sg(host->max_segs, gfp);
+ mq_rq->sg = mmc_alloc_sg(mmc_get_max_segments(host), gfp);
if (!mq_rq->sg)
return -ENOMEM;
@@ -368,15 +373,24 @@ static void mmc_setup_queue(struct mmc_queue *mq, struct mmc_card *card)
blk_queue_bounce_limit(mq->queue, limit);
blk_queue_max_hw_sectors(mq->queue,
min(host->max_blk_count, host->max_req_size / 512));
- blk_queue_max_segments(mq->queue, host->max_segs);
+ /* blk_queue_can_use_iommu_merging() should succeed if can_merge = 1 */
+ if (host->can_merge &&
+ !blk_queue_can_use_iommu_merging(mq->queue, mmc_dev(host)))
+ WARN_ON(1);
+ blk_queue_max_segments(mq->queue, mmc_get_max_segments(host));
if (mmc_card_mmc(card))
block_size = card->ext_csd.data_sector_size;
blk_queue_logical_block_size(mq->queue, block_size);
- blk_queue_max_segment_size(mq->queue,
+ /*
+ * After blk_queue_can_use_iommu_merging() was called with succeed,
+ * since it calls blk_queue_virt_boundary for IOMMU, the mmc should
+ * not call blk_queue_max_segment_size().
+ */
+ if (!host->can_merge)
+ blk_queue_max_segment_size(mq->queue,
round_down(host->max_seg_size, block_size));
-
INIT_WORK(&mq->recovery_work, mmc_mq_recovery_handler);
INIT_WORK(&mq->complete_work, mmc_blk_mq_complete_work);
@@ -422,6 +436,17 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card)
mq->tag_set.cmd_size = sizeof(struct mmc_queue_req);
mq->tag_set.driver_data = mq;
+ /*
+ * Since blk_mq_alloc_tag_set() calls .init_request() of mmc_mq_ops,
+ * the host->can_merge should be set before to get max_segs from
+ * mmc_get_max_segments().
+ */
+ if (host->max_segs < BLK_MAX_SEGMENTS &&
+ device_iommu_mapped(mmc_dev(host)))
+ host->can_merge = 1;
+ else
+ host->can_merge = 0;
+
ret = blk_mq_alloc_tag_set(&mq->tag_set);
if (ret)
return ret;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 43d0f0c..84b9bef 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -398,6 +398,7 @@ struct mmc_host {
unsigned int retune_now:1; /* do re-tuning at next req */
unsigned int retune_paused:1; /* re-tuning is temporarily disabled */
unsigned int use_blk_mq:1; /* use blk-mq */
+ unsigned int can_merge:1; /* merging can be used */
int rescan_disable; /* disable card detection */
int rescan_entered; /* used with nonremovable devices */
--
2.7.4
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-06-13 10:21 UTC|newest]
Thread overview: 31+ 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 ` [RFC PATCH v6 1/5] iommu: add an exported function to get minimum page size for a domain Yoshihiro Shimoda
2019-06-13 19:37 ` Wolfram Sang
2019-06-14 7:16 ` Christoph Hellwig
2019-06-17 5:08 ` Yoshihiro Shimoda
2019-06-14 9:41 ` Robin Murphy
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 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-14 7:22 ` Christoph Hellwig
2019-06-14 9:54 ` Robin Murphy
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 19:45 ` Wolfram Sang
2019-06-17 4:25 ` Yoshihiro Shimoda
2019-06-13 20:35 ` Geert Uytterhoeven
2019-06-14 7:18 ` Christoph Hellwig
2019-06-14 7:27 ` Geert Uytterhoeven
2019-06-17 4:54 ` Yoshihiro Shimoda
2019-06-17 6:23 ` Geert Uytterhoeven
2019-06-17 6:54 ` Yoshihiro Shimoda
2019-06-13 10:20 ` Yoshihiro Shimoda [this message]
2019-06-13 19:58 ` [RFC PATCH v6 5/5] mmc: queue: Use bigger segments if IOMMU can merge the segments Wolfram Sang
2019-06-17 6:38 ` Yoshihiro Shimoda
2019-06-14 7:24 ` Christoph Hellwig
2019-06-14 10:42 ` Wolfram Sang
2019-06-17 6:46 ` Yoshihiro Shimoda
2019-06-17 6:53 ` Christoph Hellwig
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
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=1560421215-10750-6-git-send-email-yoshihiro.shimoda.uh@renesas.com \
--to=yoshihiro.shimoda.uh@renesas.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).