linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Baolin Wang <baolin.wang7@gmail.com>
To: Adrian Hunter <adrian.hunter@intel.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 v2 0/3] Introduce the request_atomic() for the host
Date: Wed, 18 Mar 2020 15:35:15 +0800	[thread overview]
Message-ID: <CADBw62pAm2h5m2Hz4uXHv6m0W3RpA7BoegwBHc+s2RK6spF_3Q@mail.gmail.com> (raw)
In-Reply-To: <ce622b0c-6ec0-10c8-f71f-fa2bba8b4a66@intel.com>

On Tue, Mar 17, 2020 at 11:07 PM Adrian Hunter <adrian.hunter@intel.com> wrote:
>
> On 17/03/20 3:49 pm, Baolin Wang wrote:
> > On Tue, Mar 17, 2020 at 9:25 PM Adrian Hunter <adrian.hunter@intel.com> wrote:
> >>
> >> On 17/03/20 12:14 pm, Baolin Wang wrote:
> >>> This patch set introduces a new request_atomic() interface for the
> >>> MMC host controller, which is used to submit a request to host in
> >>> the atomic context, such as in the irq hard handler, to reduce the
> >>> request latency.
> >>>
> >>> Any comments are welcome. Thanks.
> >>>
> >>> Note: Adrian pointed out that it is not good if moving the polling of
> >>> inhibit bits in sdhci_send_command() into the interrupt context, but
> >>> now I have not found a better way to address Adrian's concern. Moveover
> >>> this is an unusual abnormal case and the original code has the same
> >>> problem, so I plan to create another patch set to talk about and fix
> >>> this issue.
> >>
> >> I tend to think the API requires the possibility for host controllers to
> >> return "busy", so that should be sorted out first.
> >
> > If request_atomic() can return 'busy', the HSQ need queue a work to
> > dispatch this request to host again?
>
> Sounds reasonable
>
> >
> > I am thinking if I can introduce a new flag to avoid polling the
> > status before sending commands, cause from the datasheet, I did not
> > see we should need do this if the command complete and transfer
> > complete interrupts are processed normally. At least on my platfrom, I
> > did not see the inhibit bits are set. If we meet this issue, I think
> > some abormal things are happened, we should give out errors. How do
> > you think?
>
> For the atomic path, some kind of warning would be ok.

OK. I will try in next version. Thanks.

> >
> >>>
> >>> Changes from v1:
> >>>  - Re-split the changes to make them more clear suggested by Ulf.
> >>>  - Factor out the auto CMD23 checking into a separate function.
> >>>
> >>> Baolin Wang (3):
> >>>   mmc: host: Introduce the request_atomic() for the host
> >>>   mmc: host: sdhci: Implement the request_atomic() API
> >>>   mmc: host: sdhci-sprd: Implement the request_atomic() API
> >>>
> >>>  drivers/mmc/host/mmc_hsq.c    |  5 ++++-
> >>>  drivers/mmc/host/sdhci-sprd.c | 23 ++++++++++++++++++++---
> >>>  drivers/mmc/host/sdhci.c      | 27 +++++++++++++++++++--------
> >>>  drivers/mmc/host/sdhci.h      |  1 +
> >>>  include/linux/mmc/host.h      |  3 +++
> >>>  5 files changed, 47 insertions(+), 12 deletions(-)
> >>>
> >>
> >
> >
>


-- 
Baolin Wang

      reply	other threads:[~2020-03-18  7:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-17 10:14 [PATCH v2 0/3] Introduce the request_atomic() for the host Baolin Wang
2020-03-17 10:14 ` [PATCH v2 1/3] mmc: host: " Baolin Wang
2020-03-17 10:14 ` [PATCH v2 2/3] mmc: host: sdhci: Implement the request_atomic() API Baolin Wang
2020-03-17 10:14 ` [PATCH v2 3/3] mmc: host: sdhci-sprd: " Baolin Wang
2020-03-17 13:25 ` [PATCH v2 0/3] Introduce the request_atomic() for the host Adrian Hunter
2020-03-17 13:49   ` Baolin Wang
2020-03-17 15:06     ` Adrian Hunter
2020-03-18  7:35       ` Baolin Wang [this message]

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=CADBw62pAm2h5m2Hz4uXHv6m0W3RpA7BoegwBHc+s2RK6spF_3Q@mail.gmail.com \
    --to=baolin.wang7@gmail.com \
    --cc=adrian.hunter@intel.com \
    --cc=arnd@arndb.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).