Re: [PATCH v17 2/4] PCI: Add support for drivers to register optin or veto of D3

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

 



On Mon, Sep 11, 2023 at 10:23 PM Mario Limonciello
<mario.limonciello@xxxxxxx> wrote:
>
> On 9/11/2023 13:34, Rafael J. Wysocki wrote:
> > On Wed, Sep 6, 2023 at 9:16 PM Mario Limonciello
> > <mario.limonciello@xxxxxxx> wrote:
> >>

[cut]

> >
> > IMV, the underlying issue all boils down to the platform firmware
> > inadequately describing the behavior of the system to the OS.
> > Specifically, had it provided a _S0W returning 0 for the Root Port(s)
> > in question, wakeup signaling would have worked (or else there would
> > have been a defect in the kernel code to be addressed).
>
> I think you're right.  I'll try and get BIOS guys to provide a test BIOS
> to prove this direction is correct.
>
> It wouldn't help all the machines already in the field but if it can be
> done without harm to Windows maybe future SoCs could use it.
>
> > Instead, it
> > decided to kind-of guide Windows in the "right" direction through PEP
> > constraints which doesn't have the same effect on Linux and honestly
> > I'm not even sure if it is a good idea to adjust Linux to that.
> >
>
> What is the worry with bringing Linux in this direction (using constraints)?

First off, ostensibly the purpose of the constraints is to indicate to
Windows when it can attempt to put the system into the deepest power
state.  Specifically, AFAICS, Windows is not expected to do so when
the current power state of a given device is shallower than the
relevant constraint.  Consequently, a constraint of D0 means that
effectively Windows is expected to ignore the given device as far as
Modern Standby goes.

In any case, this has no bearing on the behavior of suspend-to-idle in Linux.

Now, there may be other undocumented side-effects of setting a
constraint of D0 in Windows, but it is generally risky to rely on such
things.

Second, it is not entirely clear to me whether or not the future
versions of Windows will continue to use the constraints in the same
way.

> My main hope is that by generalizing this fundamental difference in how
> Windows and Linux handle Modern Standby / suspend-to-idle we can avoid
> other future bugs.

There is a fundamental difference between Modern Standby and
suspend-to-idle already, as the former is opportunistic and the latter
is on-demand.  They can both follow the exact same set of rules.



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux