Re: [PATCH] [v2] mmc: sdhci-pci-gli: Improve Random 4K Read Performance of GL9763E

[Renius Chen]

Hi Adrain,

What do you think of this patch?
Or do you have any ideas or suggestions about the modification for
Ulf's comments?

Thank you.


Best regards,

Renius

Renius Chen <reniuschengl@xxxxxxxxx> 於 2021年7月7日 週三 下午9:49寫道：
>
> Ulf Hansson <ulf.hansson@xxxxxxxxxx> 於 2021年7月7日 週三 下午8:16寫道：
> >
> > [...]
> >
> > >
> > > 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