From: Eugeniu Rosca <erosca@de.adit-jv.com> To: Ulf Hansson <ulf.hansson@linaro.org>, Wolfram Sang <wsa+renesas@sang-engineering.com>, Masahiro Yamada <yamada.masahiro@socionext.com> Cc: <linux-mmc@vger.kernel.org>, <linux-renesas-soc@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Eugeniu Rosca <erosca@de.adit-jv.com>, Eugeniu Rosca <roscaeugeniu@gmail.com>, Andrew Gabbasov <andrew_gabbasov@mentor.com>, Harish Jenny K N <harish_kandiga@mentor.com> Subject: [PATCH v2] mmc: tmio: Add MMC_CAP_ERASE to allow erase/discard/trim requests Date: Fri, 15 Nov 2019 14:44:30 +0100 [thread overview] Message-ID: <20191115134430.12621-1-erosca@de.adit-jv.com> (raw) Isolated initially to renesas_sdhi_internal_dmac [1], Ulf suggested adding MMC_CAP_ERASE to the TMIO mmc core: On Fri, Nov 15, 2019 at 10:27:25AM +0100, Ulf Hansson wrote: -- snip -- This test and due to the discussions with Wolfram and you in this thread, I would actually suggest that you enable MMC_CAP_ERASE for all tmio variants, rather than just for this particular one. In other words, set the cap in tmio_mmc_host_probe() should be fine, as it seems none of the tmio variants supports HW busy detection at this point. -- snip -- Testing on R-Car H3ULCB-KF doesn't reveal any issues (v5.4-rc7): root@rcar-gen3:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 59.2G 0 disk <--- eMMC mmcblk0boot0 179:8 0 4M 1 disk mmcblk0boot1 179:16 0 4M 1 disk mmcblk1 179:24 0 30G 0 disk <--- SD card root@rcar-gen3:~# time blkdiscard /dev/mmcblk0 real 0m8.659s user 0m0.001s sys 0m1.920s root@rcar-gen3:~# time blkdiscard /dev/mmcblk1 real 0m1.176s user 0m0.001s sys 0m0.124s [1] https://lore.kernel.org/linux-renesas-soc/20191112134808.23546-1-erosca@de.adit-jv.com/ Cc: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Andrew Gabbasov <andrew_gabbasov@mentor.com> Originally-by: Harish Jenny K N <harish_kandiga@mentor.com> Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> --- drivers/mmc/host/tmio_mmc_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c index 9b6e1001e77c..dec5a99f52cf 100644 --- a/drivers/mmc/host/tmio_mmc_core.c +++ b/drivers/mmc/host/tmio_mmc_core.c @@ -1184,7 +1184,7 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host) if (ret == -EPROBE_DEFER) return ret; - mmc->caps |= MMC_CAP_4_BIT_DATA | pdata->capabilities; + mmc->caps |= MMC_CAP_ERASE | MMC_CAP_4_BIT_DATA | pdata->capabilities; mmc->caps2 |= pdata->capabilities2; mmc->max_segs = pdata->max_segs ? : 32; mmc->max_blk_size = TMIO_MAX_BLK_SIZE; -- 2.24.0
WARNING: multiple messages have this Message-ID (diff)
From: Eugeniu Rosca <erosca@de.adit-jv.com> To: Ulf Hansson <ulf.hansson@linaro.org>, Wolfram Sang <wsa+renesas@sang-engineering.com>, Masahiro Yamada <yamada.masahiro@socionext.com> Cc: linux-mmc@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org, Eugeniu Rosca <erosca@de.adit-jv.com>, Eugeniu Rosca <roscaeugeniu@gmail.com>, Andrew Gabbasov <andrew_gabbasov@mentor.com>, Harish Jenny K N <harish_kandiga@mentor.com> Subject: [PATCH v2] mmc: tmio: Add MMC_CAP_ERASE to allow erase/discard/trim requests Date: Fri, 15 Nov 2019 14:44:30 +0100 [thread overview] Message-ID: <20191115134430.12621-1-erosca@de.adit-jv.com> (raw) Isolated initially to renesas_sdhi_internal_dmac [1], Ulf suggested adding MMC_CAP_ERASE to the TMIO mmc core: On Fri, Nov 15, 2019 at 10:27:25AM +0100, Ulf Hansson wrote: -- snip -- This test and due to the discussions with Wolfram and you in this thread, I would actually suggest that you enable MMC_CAP_ERASE for all tmio variants, rather than just for this particular one. In other words, set the cap in tmio_mmc_host_probe() should be fine, as it seems none of the tmio variants supports HW busy detection at this point. -- snip -- Testing on R-Car H3ULCB-KF doesn't reveal any issues (v5.4-rc7): root@rcar-gen3:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 59.2G 0 disk <--- eMMC mmcblk0boot0 179:8 0 4M 1 disk mmcblk0boot1 179:16 0 4M 1 disk mmcblk1 179:24 0 30G 0 disk <--- SD card root@rcar-gen3:~# time blkdiscard /dev/mmcblk0 real 0m8.659s user 0m0.001s sys 0m1.920s root@rcar-gen3:~# time blkdiscard /dev/mmcblk1 real 0m1.176s user 0m0.001s sys 0m0.124s [1] https://lore.kernel.org/linux-renesas-soc/20191112134808.23546-1-erosca@de.adit-jv.com/ Cc: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Andrew Gabbasov <andrew_gabbasov@mentor.com> Originally-by: Harish Jenny K N <harish_kandiga@mentor.com> Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> --- drivers/mmc/host/tmio_mmc_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c index 9b6e1001e77c..dec5a99f52cf 100644 --- a/drivers/mmc/host/tmio_mmc_core.c +++ b/drivers/mmc/host/tmio_mmc_core.c @@ -1184,7 +1184,7 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host) if (ret == -EPROBE_DEFER) return ret; - mmc->caps |= MMC_CAP_4_BIT_DATA | pdata->capabilities; + mmc->caps |= MMC_CAP_ERASE | MMC_CAP_4_BIT_DATA | pdata->capabilities; mmc->caps2 |= pdata->capabilities2; mmc->max_segs = pdata->max_segs ? : 32; mmc->max_blk_size = TMIO_MAX_BLK_SIZE; -- 2.24.0
next reply other threads:[~2019-11-15 13:45 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-15 13:44 Eugeniu Rosca [this message] 2019-11-15 13:44 ` [PATCH v2] mmc: tmio: Add MMC_CAP_ERASE to allow erase/discard/trim requests Eugeniu Rosca 2019-11-15 13:51 ` Wolfram Sang 2019-11-18 9:08 ` Ulf Hansson
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=20191115134430.12621-1-erosca@de.adit-jv.com \ --to=erosca@de.adit-jv.com \ --cc=andrew_gabbasov@mentor.com \ --cc=harish_kandiga@mentor.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mmc@vger.kernel.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=roscaeugeniu@gmail.com \ --cc=ulf.hansson@linaro.org \ --cc=wsa+renesas@sang-engineering.com \ --cc=yamada.masahiro@socionext.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: 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.