Re: [PATCH v2] mmc: sdhci-pci-gli: fix LPM negotiation so x86/S0ix SoCs can suspend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Sven van Ashbrook,

On Thu, Aug 31, 2023 at 4:14 AM Sven van Ashbrook <svenva@xxxxxxxxxxxx> wrote:
>
> On Tue, Aug 29, 2023 at 10:27 PM Ben Chuang <benchuanggli@xxxxxxxxx> wrote:
> >
> > >
> > > - if /sys/devices/.../power/control is "on", then:
> > >   <snip>
> > >
> > In this cas, after gl9763e_resume(), it is LPM disabled.
> > Is there no chance for gl9763e to enter L1.x again when the system is idle?
> >
>
> AFAIK the only way to disable runtime_pm is to write:
>   $ echo on > /sys/devices/.../power/control
> where
>   $ echo auto > /sys/devices/.../power/control
>       means: runtime_pm is actively managing the device, device can be "active"
>       or "suspended".
>   $ echo on > /sys/devices/.../power/control
>       means: runtime_pm is not managing the device, device is "active" only.
>
> In the "auto" case, we know what should happen: LPM negotiation is enabled when
> idle, disabled when active.
>
> What should be the LPM negotiation state in the "on" case? We have to
> make a choice:
> a) LPM negotiation disabled: normal performance, high power consumption, OR
> b) LPM negotiation  enabled: low    performance, low  power consumption
>
> If userspace disables our device's runtime_pm by writing "on", it expects the
> device to be always-on. It should then expect a higher power consumption.
> It should then also expect a performance that is not-worse than the "auto" case.
>
> So my suggestion would be to use (a), which is what this patch does.

Understood, I accept your suggestion.

>
> Appreciate your thoughts.

Best regards,
Ben Chuang




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux