Re: LKFT: arm x15: mmc1: cache flush error -110

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 3/10/20 4:10 PM, Sowjanya Komatineni wrote:

On 3/10/20 2:59 PM, Sowjanya Komatineni wrote:

On 3/10/20 10:27 AM, Sowjanya Komatineni wrote:

On 3/10/20 10:09 AM, Ulf Hansson wrote:
External email: Use caution opening links or attachments


[...]

I would like to get the regression fixed asap, but I also would like to avoid reverting patches, unless really necessary. May I propose the
following two options.

1. Find out why polling with ->card_busy() or CMD13, for a CMD6 with
an R1 response doesn't work - and then fix that behaviour.

2. Set the mmc->max_busy_timeout to zero for sdhci-tegra, which makes the core to always use R1B for CMD6 (and erase). This also means that when the cmd->busy_timeout becomes longer than 11s, sdhci-tegra must
disable the HW busy timeout and just wait "forever".

If you decide for 2, you can add the software timeout support on top,
but make that can be considered as a next step of an improvement,
rather than needed as fix. Note that, I believe there are some support
for software timeout already in the sdhci core, maybe you need to
tweak it a bit for your case, I don't know.

Kind regards
Uffe
Hi Uffe

Will go with 2nd option and will send patches out when ready.
Okay, good.

BTW, Tegra host also supports SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for
data timeout based on host clock when using finite mode (HW busy
detection based on DATA TIMEOUT count value when cmd operation timeout
is < 11s for tegra host).

So, looks like we cant set host max_busy_timeout to 0 for Tegra host to
force R1B during SWITCH and SLEEP_AWAKE.

So, was thinking to introduce host capability MMC_CAP2_LONG_WAIT_HW_BUSY which can be used for hosts supporting long or infinite HW busy wait detection and will update mmc and mmc_ops drivers to not allow convert R1B to R1B for hosts with this capability during SLEEP_AWAKE and SWITCH.
That seems reasonable, it becomes probably both easier and clearer by
adding a new host cap.

In any case, let me help out and cook a patch for this for the core
part (I leave the sdhci change to you). It may be a bit tricky,
especially since I have currently queued a bunch of new changes for
v5.7, that enables more users of mmc_poll_for_busy() in the core.
Maybe I need to temporarily drop them, so we can fix these problems
first. I will check.

Probably, I would also name the cap MMC_CAP_HW_NEED_RSP_BUSY, as that
seems to be describing the common problem we have for sdhci
omap/tegra.

Finally, it seems like MMC_CAP_WAIT_WHILE_BUSY should be set for
sdhci- tegra, so while at it, perhaps you can cook a patch for that as
well.

Kind regards
Uffe
OK, I sent v1 yesterday. Please ignore them then.
Oh, I haven't seen them. In any case, I am ignoring them.

Will send out patches only for HW busy wait modes program based on cmd
timeout and WAIT_WHILE_BUSY enabled.
Great, thanks!

Please help test the series I just posted as well, if you have the
time ofcourse.

Kind regards
Uffe

Sure,

Thanks

Sowjanya


mmc_sleep() also needs update to force R1B when host sets capability MMC_CAP_NEED_RSP_BUSY


Tested patches and they work good.

Sent sdhci-tegra v2 patches

- includes busy wait mode programming based on cmd busy_timeout

- enables MMC_CAP_WAIT_WHILE_BUSY

Thanks

Sowjanya




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux