All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Baolin Wang <baolin.wang7@gmail.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	Orson Zhai <orsonzhai@gmail.com>,
	Chunyan Zhang <zhang.lyra@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 1/3] mmc: host: Introduce the request_atomic() for the host
Date: Tue, 7 Apr 2020 13:14:17 +0300	[thread overview]
Message-ID: <5cc006fe-e5f5-b9bf-bb01-c425d943783c@intel.com> (raw)
In-Reply-To: <CADBw62qXyQCO5s+8Ytg2VCn5tEXS6dPQarQW1mHWJMJm+jUiXQ@mail.gmail.com>

On 7/04/20 10:21 am, Baolin Wang wrote:
> On Tue, Apr 7, 2020 at 2:38 PM Adrian Hunter <adrian.hunter@intel.com> wrote:
>>
>> On 3/04/20 10:05 am, Baolin Wang wrote:
>>> The SD host controller can process one request in the atomic context if
>>> the card is nonremovable, which means we can submit next request in the
>>> irq hard handler when using the MMC host software queue to reduce the
>>> latency. Thus this patch adds a new API request_atomic() for the host
>>> controller, as well as adding support for host software queue to submit
>>> a request by the new request_atomic() API.
>>>
>>> Moreover there is an unusual case that the card is busy when trying to
>>> send a command, and we can not polling the card status in interrupt
>>> context by using request_atomic() to dispatch requests. Thus we should
>>> queue a work to try again in the non-atomic context in case the host
>>> releases the busy signal later.
>>>
>>> Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
>>> Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
>>
>>
>> One minor point below, otherwise:
>>
>> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
>>
>>> ---
>>>  drivers/mmc/host/mmc_hsq.c | 29 ++++++++++++++++++++++++++++-
>>>  drivers/mmc/host/mmc_hsq.h |  1 +
>>>  include/linux/mmc/host.h   |  3 +++
>>>  3 files changed, 32 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/host/mmc_hsq.c b/drivers/mmc/host/mmc_hsq.c
>>> index b90b2c9..a57f802 100644
>>> --- a/drivers/mmc/host/mmc_hsq.c
>>> +++ b/drivers/mmc/host/mmc_hsq.c
>>> @@ -16,11 +16,20 @@
>>>  #define HSQ_NUM_SLOTS        64
>>>  #define HSQ_INVALID_TAG      HSQ_NUM_SLOTS
>>>
>>> +static void mmc_hsq_retry_handler(struct work_struct *work)
>>> +{
>>> +     struct mmc_hsq *hsq = container_of(work, struct mmc_hsq, retry_work);
>>> +     struct mmc_host *mmc = hsq->mmc;
>>> +
>>> +     mmc->ops->request(mmc, hsq->mrq);
>>> +}
>>> +
>>>  static void mmc_hsq_pump_requests(struct mmc_hsq *hsq)
>>>  {
>>>       struct mmc_host *mmc = hsq->mmc;
>>>       struct hsq_slot *slot;
>>>       unsigned long flags;
>>> +     int ret = 0;
>>>
>>>       spin_lock_irqsave(&hsq->lock, flags);
>>>
>>> @@ -42,7 +51,24 @@ static void mmc_hsq_pump_requests(struct mmc_hsq *hsq)
>>>
>>>       spin_unlock_irqrestore(&hsq->lock, flags);
>>>
>>> -     mmc->ops->request(mmc, hsq->mrq);
>>> +     if (mmc->ops->request_atomic)
>>> +             ret = mmc->ops->request_atomic(mmc, hsq->mrq);
>>> +     else
>>> +             mmc->ops->request(mmc, hsq->mrq);
>>> +
>>> +     /*
>>> +      * If returning BUSY from request_atomic(), which means the card
>>> +      * may be busy now, and we should change to non-atomic context to
>>> +      * try again for this unusual case, to avoid time-consuming operations
>>> +      * in the atomic context.
>>> +      *
>>> +      * Note: we just give a warning for other error cases, since the host
>>> +      * driver will handle them.
>>> +      */
>>> +     if (ret == -EBUSY)
>>> +             schedule_work(&hsq->retry_work);
>>> +     else
>>> +             WARN_ON_ONCE(ret && ret != -EBUSY);
>>
>> 'ret != -EBUSY' is redundant because it is always true in the 'else' clause.
> 
> Ah, Yes, thanks for pointing this out and I will fix it ine next version.
> 
> By the way, could you help to review patch 2 and 3 in this patch set? Thanks.
> 

I'd like to handle the inhibit wait differently.  I will make some patches
for that and send them out.


  reply	other threads:[~2020-04-07 10:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-03  7:05 [PATCH v4 0/3] Introduce the request_atomic() for the host Baolin Wang
2020-04-03  7:05 ` [PATCH v4 1/3] mmc: host: " Baolin Wang
2020-04-07  6:37   ` Adrian Hunter
2020-04-07  7:21     ` Baolin Wang
2020-04-07 10:14       ` Adrian Hunter [this message]
2020-04-08  2:18         ` Baolin Wang
2020-04-03  7:05 ` [PATCH v4 2/3] mmc: host: sdhci: Implement the request_atomic() API Baolin Wang
2020-04-03  7:05 ` [PATCH v4 3/3] mmc: host: sdhci-sprd: " Baolin Wang

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=5cc006fe-e5f5-b9bf-bb01-c425d943783c@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=arnd@arndb.de \
    --cc=baolin.wang7@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=orsonzhai@gmail.com \
    --cc=ulf.hansson@linaro.org \
    --cc=zhang.lyra@gmail.com \
    /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.