All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Renius Chen <reniuschengl@gmail.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ben Chuang <Ben.Chuang@genesyslogic.com.tw>
Subject: Re: [PATCH] [v2] mmc: sdhci-pci-gli: Improve Random 4K Read Performance of GL9763E
Date: Wed, 7 Jul 2021 14:15:47 +0200	[thread overview]
Message-ID: <CAPDyKFoSOk+4pmW60uGzKaYw3XOXshx+NSNqF_po=VLkK1-7Qw@mail.gmail.com> (raw)
In-Reply-To: <CAJU4x8t+aOqq82EJMUNDpWiE3GPeyZkjFhy=AkmctcDE3mx6fA@mail.gmail.com>

[...]

>
> Thanks, I understand what you mean.
>
> I simply searched for the keyword "MMC_READ_MULTIPLE_BLOCK" in the
> drivers/mmc/host folder, and found that in some SD/MMC host controller
> driver codes such as alcor.c, cavium.c, ...etc, there are also
> behaviors for monitoring the request in their driver. What's the
> difference between theirs and ours?

Those checks are there to allow the HWs to be supported properly.

>
> And if the code that monitors the requstes does not belong the driver,
> where should I implement the code and how to add some functions only
> for GL9763e in that place, in your opinion?

Honestly, I am not sure what suits your use case best.

So far we have used runtime PM with a default auto suspend timeout, in
combination with dev PM Qos. In other words, run as fast as possible
to complete the requests in the queue then go back to idle and enter a
low power state. Clearly, that seems not to be sufficient for your use
case, sorry.

Kind regards
Uffe

  reply	other threads:[~2021-07-07 12:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-05  9:00 [PATCH] [v2] mmc: sdhci-pci-gli: Improve Random 4K Read Performance of GL9763E Renius Chen
2021-07-05 10:02 ` Ulf Hansson
2021-07-05 10:59   ` Renius Chen
2021-07-05 12:50     ` Ulf Hansson
2021-07-05 15:09       ` Renius Chen
2021-07-06  9:16         ` Ulf Hansson
2021-07-06  9:54           ` Renius Chen
2021-07-06 10:08             ` Ulf Hansson
2021-07-06 10:56               ` Renius Chen
2021-07-07 12:15                 ` Ulf Hansson [this message]
2021-07-07 13:49                   ` Renius Chen
2021-07-14  2:15                     ` Renius Chen
2021-07-16 10:27                       ` Adrian Hunter
2021-07-19  9:26                         ` Renius Chen
2021-08-04  6:27                           ` Adrian Hunter
2021-08-10  4:23                             ` Renius Chen
2021-08-17 10:30                               ` Renius Chen

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='CAPDyKFoSOk+4pmW60uGzKaYw3XOXshx+NSNqF_po=VLkK1-7Qw@mail.gmail.com' \
    --to=ulf.hansson@linaro.org \
    --cc=Ben.Chuang@genesyslogic.com.tw \
    --cc=adrian.hunter@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=reniuschengl@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.