[PATCH 0/2] mmc: rtsx_pci: Enable support for erase/discard/trim requests

[PATCH 0/2] mmc: rtsx_pci: Enable support for erase/discard/trim requests

[Ulf Hansson]

To enable the rtsx_pci driver to support erase/discard/trim, it needs to manage
timeouts for R1B responses according to the expecations from the mmc core. Fix
this and then enable MMC_CAP_ERASE.

Ulf Hansson (2):
  mmc: rtsx_pci: Use the provided busy timeout from the mmc core
  mmc: rtsx_pci: Enable MMC_CAP_ERASE to allow erase/discard/trim
    requests

 drivers/mmc/host/rtsx_pci_sdmmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
1.9.1

[PATCH 1/2] mmc: rtsx_pci: Use the provided busy timeout from the mmc core

[Ulf Hansson]

The rtsx_pci driver is using a fixed 3s timeout for R1B responses, which
in some cases isn't suffient. For example, erase/discard requests may
require longer timeouts.

Instead of always using a fixed timeout, let's use the per request
calculated busy timeout from the mmc core.

Cc: Micky Ching <micky_ching@realsil.com.cn>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mmc/host/rtsx_pci_sdmmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 9313748..6158b96 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -244,7 +244,7 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc *host,
 	stat_idx = sd_status_index(rsp_type);
 
 	if (rsp_type == SD_RSP_TYPE_R1b)
-		timeout = 3000;
+		timeout = cmd->busy_timeout ? cmd->busy_timeout : 3000;
 
 	if (cmd->opcode == SD_SWITCH_VOLTAGE) {
 		err = rtsx_pci_write_register(pcr, SD_BUS_STAT,
-- 
1.9.1

[PATCH 2/2] mmc: rtsx_pci: Enable MMC_CAP_ERASE to allow erase/discard/trim requests

[Ulf Hansson]

Cc: Micky Ching <micky_ching@realsil.com.cn>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mmc/host/rtsx_pci_sdmmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 6158b96..40f957e 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -1360,7 +1360,7 @@ static void realtek_init_host(struct realtek_pci_sdmmc *host)
 	mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
 	mmc->caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SD_HIGHSPEED |
 		MMC_CAP_MMC_HIGHSPEED | MMC_CAP_BUS_WIDTH_TEST |
-		MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25;
+		MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 | MMC_CAP_ERASE;
 	mmc->caps2 = MMC_CAP2_NO_PRESCAN_POWERUP | MMC_CAP2_FULL_PWR_CYCLE;
 	mmc->max_current_330 = 400;
 	mmc->max_current_180 = 800;
-- 
1.9.1

Re: [PATCH 0/2] mmc: rtsx_pci: Enable support for erase/discard/trim requests

[Ulf Hansson]

On 27 July 2016 at 14:25, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> To enable the rtsx_pci driver to support erase/discard/trim, it needs to manage
> timeouts for R1B responses according to the expecations from the mmc core. Fix
> this and then enable MMC_CAP_ERASE.
>
> Ulf Hansson (2):
>   mmc: rtsx_pci: Use the provided busy timeout from the mmc core
>   mmc: rtsx_pci: Enable MMC_CAP_ERASE to allow erase/discard/trim
>     requests
>
>  drivers/mmc/host/rtsx_pci_sdmmc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> --
> 1.9.1
>

Mauro, I have applied this for my next branch (based on 4.7), to allow
it to be easily tested.

Just clone my tree below and build/replace your kernel.
git://git.linaro.org/people/ulf.hansson/mmc.git next

Running fstrim and checking blkdiscard should be sufficient as test cases.

Don't hesitate to ask if problems occurs!

Kind regards
Uffe

Re: [PATCH 0/2] mmc: rtsx_pci: Enable support for erase/discard/trim requests

[Mauro Santos]

On 27-07-2016 13:45, Ulf Hansson wrote:
> Mauro, I have applied this for my next branch (based on 4.7), to allow
> it to be easily tested.
> 
> Just clone my tree below and build/replace your kernel.
> git://git.linaro.org/people/ulf.hansson/mmc.git next
> 
> Running fstrim and checking blkdiscard should be sufficient as test cases.
> 
> Don't hesitate to ask if problems occurs!
> 
> Kind regards
> Uffe
> 

I've tested both blkdiscard and fstrim (on ext4) and they both worked.

I haven't noticed any errors or warnings on dmesg or complaints from
blkdiscard/fstrim.

If there are any more specific tests you would like me to do let me know.

Regards,
Mauro Santos

Re: [PATCH 0/2] mmc: rtsx_pci: Enable support for erase/discard/trim requests

[Ulf Hansson]

On 27 July 2016 at 22:35, Mauro Santos <registo.mailling@gmail.com> wrote:
> On 27-07-2016 13:45, Ulf Hansson wrote:
>> Mauro, I have applied this for my next branch (based on 4.7), to allow
>> it to be easily tested.
>>
>> Just clone my tree below and build/replace your kernel.
>> git://git.linaro.org/people/ulf.hansson/mmc.git next
>>
>> Running fstrim and checking blkdiscard should be sufficient as test cases.
>>
>> Don't hesitate to ask if problems occurs!
>>
>> Kind regards
>> Uffe
>>
>
> I've tested both blkdiscard and fstrim (on ext4) and they both worked.
>
> I haven't noticed any errors or warnings on dmesg or complaints from
> blkdiscard/fstrim.
>
> If there are any more specific tests you would like me to do let me know.

Perhaps just run some dd operation to read and write some data to the
card, then I am happy. :)

Thanks a lot for your help in testing, I will apply a tested-by tag
from you, unless you object.

Kind regards
Uffe

Re: [PATCH 0/2] mmc: rtsx_pci: Enable support for erase/discard/trim requests

[Mauro Santos]

On 27-07-2016 23:02, Ulf Hansson wrote:
> On 27 July 2016 at 22:35, Mauro Santos <registo.mailling@gmail.com> wrote:
>> On 27-07-2016 13:45, Ulf Hansson wrote:
>>> Mauro, I have applied this for my next branch (based on 4.7), to allow
>>> it to be easily tested.
>>>
>>> Just clone my tree below and build/replace your kernel.
>>> git://git.linaro.org/people/ulf.hansson/mmc.git next
>>>
>>> Running fstrim and checking blkdiscard should be sufficient as test cases.
>>>
>>> Don't hesitate to ask if problems occurs!
>>>
>>> Kind regards
>>> Uffe
>>>
>>
>> I've tested both blkdiscard and fstrim (on ext4) and they both worked.
>>
>> I haven't noticed any errors or warnings on dmesg or complaints from
>> blkdiscard/fstrim.
>>
>> If there are any more specific tests you would like me to do let me know.
> 
> Perhaps just run some dd operation to read and write some data to the
> card, then I am happy. :)
> 

Maybe I should have mentioned in my previous email, I have used the ext4
formatted fs to write some files, if you want me to still test with dd
let me know.

I have tested it like this:

- Filesystem was not mounted with the discard option.
- Almost fill the card with files, determine md5sum for all files and
reboot to make sure there are no cached files in ram
- Delete half of the files, fstrim -v (trimmed space looks about right),
check md5sum of remaining files - no problems here.
- fsck -f filesystem - no problems detected.

After this I have written more data to the card and checked the md5sums,
but I already forgot the exact sequence, I was looking for any sign that
using fstrim would delete more than it should have or that writing new
files might for some reason corrupt the old files.

I have confirmed that blkdiscard does work, the card returns zeros for
the few sectors I've checked, but I haven't confirmed that fstrim is
doing what it is supposed to do, the same applies to the case where the
filesystem is mounted with the discard option (quick google search
didn't return recipe for going from file->lba/sector or inode->lba/sector).

That said, given that blkdiscard works I'm assuming fstrim (and the
discard option) also work. I can check that if you want, but I would
need some pointers on how to do it. I could also check fstrim on a well
used f2fs formatted card where data should be all over the place by now.

> Thanks a lot for your help in testing, I will apply a tested-by tag
> from you, unless you object.
> 

No objections.

> Kind regards
> Uffe
> 

Regards,
Mauro Santos

Re: [PATCH 0/2] mmc: rtsx_pci: Enable support for erase/discard/trim requests

[Ulf Hansson]

On 28 July 2016 at 01:07, Mauro Santos <registo.mailling@gmail.com> wrote:
> On 27-07-2016 23:02, Ulf Hansson wrote:
>> On 27 July 2016 at 22:35, Mauro Santos <registo.mailling@gmail.com> wrote:
>>> On 27-07-2016 13:45, Ulf Hansson wrote:
>>>> Mauro, I have applied this for my next branch (based on 4.7), to allow
>>>> it to be easily tested.
>>>>
>>>> Just clone my tree below and build/replace your kernel.
>>>> git://git.linaro.org/people/ulf.hansson/mmc.git next
>>>>
>>>> Running fstrim and checking blkdiscard should be sufficient as test cases.
>>>>
>>>> Don't hesitate to ask if problems occurs!
>>>>
>>>> Kind regards
>>>> Uffe
>>>>
>>>
>>> I've tested both blkdiscard and fstrim (on ext4) and they both worked.
>>>
>>> I haven't noticed any errors or warnings on dmesg or complaints from
>>> blkdiscard/fstrim.
>>>
>>> If there are any more specific tests you would like me to do let me know.
>>
>> Perhaps just run some dd operation to read and write some data to the
>> card, then I am happy. :)
>>
>
> Maybe I should have mentioned in my previous email, I have used the ext4
> formatted fs to write some files, if you want me to still test with dd
> let me know.
>
> I have tested it like this:
>
> - Filesystem was not mounted with the discard option.
> - Almost fill the card with files, determine md5sum for all files and
> reboot to make sure there are no cached files in ram
> - Delete half of the files, fstrim -v (trimmed space looks about right),
> check md5sum of remaining files - no problems here.
> - fsck -f filesystem - no problems detected.
>
> After this I have written more data to the card and checked the md5sums,
> but I already forgot the exact sequence, I was looking for any sign that
> using fstrim would delete more than it should have or that writing new
> files might for some reason corrupt the old files.
>
> I have confirmed that blkdiscard does work, the card returns zeros for
> the few sectors I've checked, but I haven't confirmed that fstrim is
> doing what it is supposed to do, the same applies to the case where the
> filesystem is mounted with the discard option (quick google search
> didn't return recipe for going from file->lba/sector or inode->lba/sector).
>
> That said, given that blkdiscard works I'm assuming fstrim (and the
> discard option) also work. I can check that if you want, but I would
> need some pointers on how to do it. I could also check fstrim on a well
> used f2fs formatted card where data should be all over the place by now.
>

Thanks for your report. I think this is good enough!

>> Thanks a lot for your help in testing, I will apply a tested-by tag
>> from you, unless you object.
>>
>
> No objections.

Great, applied!

Kind regards
Uffe