sdhci-msm controller requires the R1B response for commands that
has this response associated with them.
So enable MMC_CAP_NEED_RSP_BUSY capability.
Signed-off-by: Veerabhadrarao Badiganti <[email protected]>
---
drivers/mmc/host/sdhci-msm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 013dcea..d826e9b 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -2088,6 +2088,7 @@ static int sdhci_msm_probe(struct platform_device *pdev)
}
msm_host->mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
+ msm_host->mmc->caps |= MMC_CAP_NEED_RSP_BUSY;
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
On 12/04/20 6:53 pm, Veerabhadrarao Badiganti wrote:
> sdhci-msm controller requires the R1B response for commands that
> has this response associated with them.
>
> So enable MMC_CAP_NEED_RSP_BUSY capability.
>
> Signed-off-by: Veerabhadrarao Badiganti <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
> ---
> drivers/mmc/host/sdhci-msm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index 013dcea..d826e9b 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -2088,6 +2088,7 @@ static int sdhci_msm_probe(struct platform_device *pdev)
> }
>
> msm_host->mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
> + msm_host->mmc->caps |= MMC_CAP_NEED_RSP_BUSY;
>
> pm_runtime_get_noresume(&pdev->dev);
> pm_runtime_set_active(&pdev->dev);
>
Hi Ulf,
On 4/16/2020 5:46 PM, Ulf Hansson wrote:
> On Sun, 12 Apr 2020 at 17:54, Veerabhadrarao Badiganti
> <[email protected]> wrote:
>> sdhci-msm controller requires the R1B response for commands that
>> has this response associated with them.
>>
>> So enable MMC_CAP_NEED_RSP_BUSY capability.
> I assume this potentially should be considered as fix and tagged for stable?
Yes Stable flag can be applied to this.
Patch with MMC_CAP_WAIT_WHILE_BUSY cap also needed besides this.
Shall I push V2 with stable flag?
> Another question, if there is there an upper limit of the busy timeout
> in the HW (cmd->busy_timeout) or does the driver use a software
> timeout that is adjustable?
The max supported h.w busy timeout value on qcom h/w 21sec.
> Kind regards
> Uffe
>
>> Signed-off-by: Veerabhadrarao Badiganti <[email protected]>
>> ---
>> drivers/mmc/host/sdhci-msm.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
>> index 013dcea..d826e9b 100644
>> --- a/drivers/mmc/host/sdhci-msm.c
>> +++ b/drivers/mmc/host/sdhci-msm.c
>> @@ -2088,6 +2088,7 @@ static int sdhci_msm_probe(struct platform_device *pdev)
>> }
>>
>> msm_host->mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
>> + msm_host->mmc->caps |= MMC_CAP_NEED_RSP_BUSY;
>>
>> pm_runtime_get_noresume(&pdev->dev);
>> pm_runtime_set_active(&pdev->dev);
>> --
>> Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
On Thu, 16 Apr 2020 at 16:49, Veerabhadrarao Badiganti
<[email protected]> wrote:
>
> Hi Ulf,
>
> On 4/16/2020 5:46 PM, Ulf Hansson wrote:
> > On Sun, 12 Apr 2020 at 17:54, Veerabhadrarao Badiganti
> > <[email protected]> wrote:
> >> sdhci-msm controller requires the R1B response for commands that
> >> has this response associated with them.
> >>
> >> So enable MMC_CAP_NEED_RSP_BUSY capability.
> > I assume this potentially should be considered as fix and tagged for stable?
> Yes Stable flag can be applied to this.
>
> Patch with MMC_CAP_WAIT_WHILE_BUSY cap also needed besides this.
> Shall I push V2 with stable flag?
Ah, so maybe squash both into one patch to simplify for stable?
Yes, please add a stable tag in v2.
>
> > Another question, if there is there an upper limit of the busy timeout
> > in the HW (cmd->busy_timeout) or does the driver use a software
> > timeout that is adjustable?
>
> The max supported h.w busy timeout value on qcom h/w 21sec.
Alright, that sounds like it should be sufficient for most cases. But
perhaps not for eMMC sanitize.
How do you cope with the situation when the R1B response is passed to
the driver and the cmd->busy_timeout exceeds the 21s?
[...]
Kind regards
Uffe
On Sun, 12 Apr 2020 at 17:54, Veerabhadrarao Badiganti
<[email protected]> wrote:
>
> sdhci-msm controller requires the R1B response for commands that
> has this response associated with them.
>
> So enable MMC_CAP_NEED_RSP_BUSY capability.
I assume this potentially should be considered as fix and tagged for stable?
Another question, if there is there an upper limit of the busy timeout
in the HW (cmd->busy_timeout) or does the driver use a software
timeout that is adjustable?
Kind regards
Uffe
>
> Signed-off-by: Veerabhadrarao Badiganti <[email protected]>
> ---
> drivers/mmc/host/sdhci-msm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index 013dcea..d826e9b 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -2088,6 +2088,7 @@ static int sdhci_msm_probe(struct platform_device *pdev)
> }
>
> msm_host->mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
> + msm_host->mmc->caps |= MMC_CAP_NEED_RSP_BUSY;
>
> pm_runtime_get_noresume(&pdev->dev);
> pm_runtime_set_active(&pdev->dev);
> --
> Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project