Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210705090050.15077-1-reniuschengl@gmail.com>
 <CAPDyKFotmw-HQpZKCOD_8kThEa0_KSPnn36FNFLKRyUHYRHQjQ@mail.gmail.com>
 <CAJU4x8u8JPBJ3V6MCi1XcO4Qim-COPuxOhTdUnor7JdNCUFb=w@mail.gmail.com>
 <CAPDyKFqXsn91BvkJXMYSnc7X=RP9DXxXp2nKMmv+aMPoNdK2Tw@mail.gmail.com>
 <CAJU4x8srB7skGFVcj1SPrzEZSnVkwKiW3OPN0GQxvgtRG7GAAQ@mail.gmail.com>
 <CAPDyKFq0yHxX7wb4XGeiMiSGGiOf8RKJ5ahhFQ+_vodqnyPV9Q@mail.gmail.com>
 <CAJU4x8uGxb5VD1WVV5-QeLkVzuuR09-NacL-9nuXe8Zofzb2=w@mail.gmail.com>
 <CAPDyKFpvCFYQVEp77hiRHY6CVDej-ffF5UE=LH=HSGcqMZA02w@mail.gmail.com>
 <CAJU4x8t+aOqq82EJMUNDpWiE3GPeyZkjFhy=AkmctcDE3mx6fA@mail.gmail.com> <CAPDyKFoSOk+4pmW60uGzKaYw3XOXshx+NSNqF_po=VLkK1-7Qw@mail.gmail.com>
In-Reply-To: <CAPDyKFoSOk+4pmW60uGzKaYw3XOXshx+NSNqF_po=VLkK1-7Qw@mail.gmail.com>
From:   Renius Chen <reniuschengl@gmail.com>
Date:   Wed, 7 Jul 2021 21:49:45 +0800
Message-ID: <CAJU4x8sMJSOnfBwDq7tVygRGFRw-SyrM1z8GBsF_Mur64-Y3_g@mail.gmail.com>
Subject: Re: [PATCH] [v2] mmc: sdhci-pci-gli: Improve Random 4K Read
 Performance of GL9763E
To:     Ulf Hansson <ulf.hansson@linaro.org>
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Ulf Hansson <ulf.hansson@linaro.org> =E6=96=BC 2021=E5=B9=B47=E6=9C=887=E6=
=97=A5 =E9=80=B1=E4=B8=89 =E4=B8=8B=E5=8D=888:16=E5=AF=AB=E9=81=93=EF=BC=9A
>
> [...]
>
> >
> > 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.
>
Yes, the runtime PM, auto suspend, and PM Qos are all about the
suspend/resume behaviors of the system or related to power states such
as D0/D3 of the device. But these are totally different from the ASPM
L0s/L1 for link states. Entering/exiting the ASPM is pure hardware
behavior on the link layer and is not handled by any codes in
drivers/mmc/core or drivers/mmc/host. We'd like to try to modify the
patch by your opinions, but we are also confused about what or where
suits our use case best. So we wonder how to start the modification
and may need some suggestions to deal with the work, sorry.

Thank you.


Best regards,

Renius


> Kind regards
> Uffe