All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bean Huo <huobean@gmail.com>
To: Adrian Hunter <adrian.hunter@intel.com>,
	Ulf Hansson <ulf.hansson@linaro.org>
Cc: Bean Huo <beanhuo@micron.com>,
	linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/2] mmc: sdhci: Use the SW timer when the HW timer cannot meet the timeout value required by the device
Date: Fri, 24 Sep 2021 11:17:05 +0200	[thread overview]
Message-ID: <beda2d5ecc3c15e9bf9aa18383c22c2a90d31dab.camel@gmail.com> (raw)
In-Reply-To: <fc14d8e1-9438-d4b0-80f4-ccf9055ab7d3@intel.com>

On Fri, 2021-09-24 at 08:29 +0300, Adrian Hunter wrote:
> > If the data transmission timeout value required by the device
> > exceeds
> > the maximum timeout value of the host HW timer, we still use the HW
> > timer with the maximum timeout value of the HW timer. This setting
> > is
> > suitable for most R/W situations. But sometimes, the device will
> > complete
> > the R/W task within its required timeout value (greater than the HW
> > timer).
> > In this case, the HW timer for data transmission will time out.
> > Currently, in this condition, we  disable the HW timer and use the
> > SW
> > timer only when the SDHCI_QUIRK2_DISABLE_HW_TIMEOUT quirk is set by
> > the
> > host driver. The patch is to remove this if statement restriction
> > and
> > allow data transmission to use the SW timer when the hardware timer
> > cannot
> > meet the required timeout value.
> 
> 
> The reason it is a quirk is because it does not work for all
> hardware.
> 
> For some controllers the timeout cannot really be disabled, only the
> 
> interrupt is disabled, and then the controller never indicates
> completion
> 
> if the timeout is exceeded.

Hi Adrian,
Thanks for your review.

Yes, you are right. But this quirk prevents disabling the hardware timeoutIRQ. The purpose of this patch is to disable the hardware timeout IRQ and
select the software timeout.

void __sdhci_set_timeout(struct sdhci_host *host, struct mmc_command
*cmd)
{
        bool too_big = false;
        u8 count = sdhci_calc_timeout(host, cmd, &too_big);

        if (too_big) {
                sdhci_calc_sw_timeout(host, cmd);
                sdhci_set_data_timeout_irq(host, false); // disable IRQ
        } else if (!(host->ier & SDHCI_INT_DATA_TIMEOUT)) {
                sdhci_set_data_timeout_irq(host, true);
        }

        sdhci_writeb(host, count, SDHCI_TIMEOUT_CONTROL);
}


The driver has detected that the hardware timer cannot meet the timeout
requirements of the device, but we still use the hardware timer, which will
allow potential timeout issuea . Rather than allowing a potential
problem to exist, why can’t software timing be used to avoid this
problem?


Kind regards,
Bean


  reply	other threads:[~2021-09-24  9:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210917172727.26834-1-huobean@gmail.com>
2021-09-17 17:27 ` [PATCH v1 1/2] mmc: sdhci: Return true only when timeout exceeds capacity of the HW timer Bean Huo
2021-09-24  6:32   ` Adrian Hunter
2021-09-27 22:31   ` Ulf Hansson
2021-09-17 17:27 ` [PATCH v1 2/2] mmc: sdhci: Use the SW timer when the HW timer cannot meet the timeout value required by the device Bean Huo
2021-09-24  5:29   ` Adrian Hunter
2021-09-24  9:17     ` Bean Huo [this message]
2021-09-24 10:07       ` Adrian Hunter
2021-09-24 11:45         ` Bean Huo
2021-09-24 12:17           ` Adrian Hunter
2021-09-24 13:08             ` Bean Huo
2021-09-24 13:26               ` Adrian Hunter
2021-09-24 21:33                 ` Bean Huo
2021-09-28  9:39                   ` Bean Huo
2021-09-28 10:18                   ` Adrian Hunter
2021-09-29 10:49                     ` Bean Huo
2021-09-29 12:38                       ` Adrian Hunter
2021-09-30  8:34                         ` Bean Huo
2021-09-30  8:59                           ` Adrian Hunter
2021-09-30  9:02                             ` Bean Huo

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=beda2d5ecc3c15e9bf9aa18383c22c2a90d31dab.camel@gmail.com \
    --to=huobean@gmail.com \
    --cc=adrian.hunter@intel.com \
    --cc=beanhuo@micron.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    /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: link
Be 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.