From: Ulf Hansson <ulf.hansson@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
"linux-mmc @ vger . kernel . org" <linux-mmc@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Subject: Re: [PATCH RFC 0/6] mmc: renesas_sdhi: add support for DMA end irqs
Date: Tue, 25 Oct 2022 14:32:13 +0200 [thread overview]
Message-ID: <CAPDyKFr1xxKCC+aOPD8vW3oBnMyt5366mXgkcgNugDwWa_R3ew@mail.gmail.com> (raw)
In-Reply-To: <60c3285a-e1a1-4aac-8c6f-23301f7b05e4@app.fastmail.com>
On Tue, 25 Oct 2022 at 13:04, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Oct 25, 2022, at 12:51, Ulf Hansson wrote:
> > Hi Wolfram,
> >
> > On Thu, 6 Oct 2022 at 21:05, Wolfram Sang
> > <wsa+renesas@sang-engineering.com> wrote:
> >>
> >> Motivation for this series from patch 5:
> >>
> >> ===
> >> So far, we have been relying on access_end interrupts only to mark DMA
> >> transfers as done implying that DMA end interrupts have occurred by then
> >> anyhow. On some SoCs under some conditions, this turned out to be not
> >> enough. So, we enable DMA interrupts as well and make sure that both
> >> events, DMA irq and access_end irq, have happened before finishing the
> >> DMA transfer.
> >
> > The tmio/sdhi core still relies on using tasklets. I think we should
> > strive to move away from tasklets for all mmc host drivers and to use
> > threaded irqs instead.
> >
> > That said, I am worried that it might be harder to move away from
> > tasklets beyond $subject series, for tmio/sdhi, but I might be wrong?
> > So, I am wondering if it perhaps would be better to make that
> > modernization/conversion as the first step instead?
>
> Moving away from tasklets is probably a good idea overall, but I'm
> not sure that MMC actually needs a custom IRQ deferral mechanism
> in addition to the existing BLOCK_SOFTIRQ. I would expect that block
> drivers usually operate in the context of the blk_mq caller, and
> adding in another thread context can add substantial latency.
Well, it's not that simple as it depends on what the MMC controller
supports too (and whether the MMC/SD card really conforms to the
specs). We can't poll for busy completions in IRQ context, for
example. And in some cases, we simply need to poll with a CMD13.
Don't get me wrong, I am not promoting a custom deferral mechanism for
MMC, but just a regular threaded IRQ handler (per host driver of
course) when that is needed. And most mmc host drivers already have
that today.
For more sophisticated HWs, we have the mmc hsq interface, that host
drivers can hook into, to potentially avoid some unnecessary context
switchings.
>
> Arnd
Kind regards
Uffe
next prev parent reply other threads:[~2022-10-25 12:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-06 19:04 [PATCH RFC 0/6] mmc: renesas_sdhi: add support for DMA end irqs Wolfram Sang
2022-10-06 19:04 ` [PATCH RFC 1/6] mmc: renesas_sdhi: remove accessor function for internal_dmac Wolfram Sang
2022-10-06 19:04 ` [PATCH RFC 2/6] mmc: renesas_sdhi: improve naming of DMA struct Wolfram Sang
2022-10-06 19:04 ` [PATCH RFC 3/6] mmc: tmio: add callback for dma irq Wolfram Sang
2022-10-06 19:04 ` [PATCH RFC 4/6] mmc: renesas_sdhi: add quirk for broken register layout Wolfram Sang
2022-10-06 19:04 ` [PATCH RFC 5/6] mmc: renesas_sdhi: take DMA end interrupts into account Wolfram Sang
2022-10-07 7:45 ` Geert Uytterhoeven
2022-10-07 8:13 ` Wolfram Sang
2022-10-06 19:04 ` [PATCH 6/6] DEBUG mmc: renesas_sdhi: debug end_flags for DMA Wolfram Sang
2022-10-25 10:51 ` [PATCH RFC 0/6] mmc: renesas_sdhi: add support for DMA end irqs Ulf Hansson
2022-10-25 11:04 ` Arnd Bergmann
2022-10-25 12:32 ` Ulf Hansson [this message]
2022-11-02 19:14 ` Wolfram Sang
2022-11-03 15:04 ` Ulf Hansson
2022-11-03 18:23 ` Wolfram Sang
2022-11-18 0:49 ` Yoshihiro Shimoda
2022-11-18 20:55 ` Wolfram Sang
2022-11-18 9:45 ` Ulf Hansson
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=CAPDyKFr1xxKCC+aOPD8vW3oBnMyt5366mXgkcgNugDwWa_R3ew@mail.gmail.com \
--to=ulf.hansson@linaro.org \
--cc=arnd@arndb.de \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=wsa+renesas@sang-engineering.com \
--cc=yoshihiro.shimoda.uh@renesas.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).