From: Ladislav Michl <oss-lists@triops.cz>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Robert Richter <rric@kernel.org>,
linux-mmc@vger.kernel.org, linux-mips@vger.kernel.org
Subject: Re: (Octeon) MMC performance degradation due to too many requests
Date: Sun, 6 Aug 2023 23:03:35 +0200 [thread overview]
Message-ID: <ZNAKpw02GR0yfbyv@lenoch> (raw)
In-Reply-To: <CACRpkdZmd-nb21Cx-jp-CDRjW4VQRV=c4MekHxS3h2p3HsDwZQ@mail.gmail.com>
On Sun, Aug 06, 2023 at 10:44:21PM +0200, Linus Walleij wrote:
> On Sun, Aug 6, 2023 at 1:48 PM Ladislav Michl <oss-lists@triops.cz> wrote:
>
> > How do we get there?
> > ff4143ccff31 ("MIPS: Octeon: cavium_octeon_defconfig: Enable Octeon MMC")
> > enabled MMC driver, but left MMC_BLOCK_BOUNCE disabled, although driver
> > performace depends on it.
>
> Ooops.
>
> > c3dccb74be28 ("mmc: core: Delete bounce buffer Kconfig option")
> > Added MMC_CAP_NO_BOUNCE_BUFF to the caps, based on assumption it should
> > be there as MMC_BLOCK_BOUNCE is disabled in defconfig
> > de3ee99b097d ("mmc: Delete bounce buffer handling")
> > finally removed all bounce buffer handling as almost nothing needs that.
> >
> > Sadly, 70XX SoC cannot do SG, so it suffers a lot. Strangely enough,
> > above patches are either authored or suggested by Cavium's employees.
> >
> > So, given the number of affected SoC and before cooking driver specific
> > solution, are we sure we indeed do not want some generic one?
>
> So you are talking about something along the lines of:
>
> commit bd9b902798ab14d19ca116b10bde581ddff8f905
> Author: Linus Walleij <linus.walleij@linaro.org>
> Date: Mon Jan 29 00:44:53 2018 +0100
>
> mmc: sdhci: Implement an SDHCI-specific bounce buffer
>
> ?
Yes, this is the exact commit I had in mind :)
> Yeah I guess that if this is needed by more than one driver it
> should be made into a library, or say a piece of code turned on by
> a config option that the dependent drivers select.
>
> Interested in the job? :D
Interested is not the word I'd use, but yes, I'll give it a try making it
a little more generic solution.
> Yours,
> Linus Walleij
Best reards,
ladis
next prev parent reply other threads:[~2023-08-06 21:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-06 11:48 (Octeon) MMC performance degradation due to too many requests Ladislav Michl
2023-08-06 20:44 ` Linus Walleij
2023-08-06 21:03 ` Ladislav Michl [this message]
2023-08-11 11:39 ` Ladislav Michl
2023-08-11 12:02 ` Linus Walleij
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=ZNAKpw02GR0yfbyv@lenoch \
--to=oss-lists@triops.cz \
--cc=linus.walleij@linaro.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=rric@kernel.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.