lkml.org 
[lkml]   [2023]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2] mmc: sdhci-pci-gli: fix LPM negotiation so x86/S0ix SoCs can suspend
On Tue, Aug 29, 2023 at 10:27 PM Ben Chuang <benchuanggli@gmail.com> 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.

Appreciate your thoughts.

\
 
 \ /
  Last update: 2023-08-30 22:51    [W:0.112 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site