Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 1/2] mmc: mmci: enable MMC_CAP_NEED_RSP_BUSY
To:     Ulf Hansson <ulf.hansson@linaro.org>
CC:     Russell King <linux@armlinux.org.uk>,
        Linus Walleij <linus.walleij@linaro.org>,
        <ludovic.barre@foss.st.com>,
        =?UTF-8?Q?Marek_Va=c5=a1ut?= <marex@denx.de>,
        "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <20210204120547.15381-1-yann.gautier@foss.st.com>
 <20210204120547.15381-2-yann.gautier@foss.st.com>
 <CAPDyKFqdtK33HSW_AM0s9172V=cBM6wnKuHubXSOGCVqJ8nzFg@mail.gmail.com>
From:   Yann GAUTIER <yann.gautier@foss.st.com>
Message-ID: <e31df871-ae1a-7c80-d741-0813f90532c7@foss.st.com>
Date:   Fri, 5 Feb 2021 13:19:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CAPDyKFqdtK33HSW_AM0s9172V=cBM6wnKuHubXSOGCVqJ8nzFg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2/5/21 10:53 AM, Ulf Hansson wrote:
> - trimmed cc-list
> 
> On Thu, 4 Feb 2021 at 13:08, <yann.gautier@foss.st.com> wrote:
>>
>> From: Yann Gautier <yann.gautier@foss.st.com>
>>
>> To properly manage commands awaiting R1B responses, the capability
>> MMC_CAP_NEED_RSP_BUSY is enabled in mmci driver, for variants that
>> manage busy detection.
>> This R1B management needs both the flags MMC_CAP_NEED_RSP_BUSY and
>> MMC_CAP_WAIT_WHILE_BUSY to be enabled together.
> 
> Would it be possible for you to share a little bit more about the
> problem? Like under what circumstances does things screw up?
> 
> Is the issue only occurring when the cmd->busy_timeout becomes larger
> than host->max_busy_timeout. Or even in other cases?
> 
>>
>> Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
>> ---
>>   drivers/mmc/host/mmci.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
>> index 1bc674577ff9..bf6971fdd1a6 100644
>> --- a/drivers/mmc/host/mmci.c
>> +++ b/drivers/mmc/host/mmci.c
>> @@ -2148,7 +2148,7 @@ static int mmci_probe(struct amba_device *dev,
>>                  if (variant->busy_dpsm_flag)
>>                          mmci_write_datactrlreg(host,
>>                                                 host->variant->busy_dpsm_flag);
>> -               mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
>> +               mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_NEED_RSP_BUSY;
> 
> This isn't correct as the ux500 (and likely also other legacy
> variants) don't need this. I have tried it in the past and it works
> fine for ux500 without MMC_CAP_NEED_RSP_BUSY.
> 
> The difference is rather that the busy detection for stm32 variants
> needs a corresponding HW busy timeout to be set (its
> variant->busy_timeout flag is set). Perhaps we can use that
> information instead?
> 
> Note that, MMC_CAP_NEED_RSP_BUSY, means that cmd->busy_timeout will
> not be set by the core for erase commands, CMD5 and CMD6.
> 
> By looking at the code in mmci_start_command(), it looks like we will
> default to a timeout of 10s, when cmd->busy_timeout isn't set. At
> least for some erase requests, that won't be sufficient. Would it be
> possible to disable the HW busy timeout in some way - and maybe use a
> software timeout instead? Maybe I already asked Ludovic about this?
> :-)
> 
> BTW, did you check that the MMCIDATATIMER does get the correct value
> set for the timer in mmci_start_command() and if
> host->max_busy_timeout gets correctly set in
> mmci_set_max_busy_timeout()?
> 
> [...]
> 
> Kind regards
> Uffe
> 

Hi Ulf,

Thanks for the hints.
I'll check all of that and get back with updated patches.

As I tried to explain in the cover letter and in reply to Adrian, I saw
a freeze (BUSYD0) in test 37 during MMC_ERASE command  with 
SECURE_ERASE_ARG, when running this test just after test 36 (or any 
other write test). But maybe, as you said that's mostly a incorrect 
timeout issue.

Regards,
Yann