> >> request before making any decisions here.
> >
> > It's a lack of proper D3hot support and GC6 support in Nouveau.
>
> Thanks, but that is still a bit enigmatic.
>
> What exactly do you mean by "proper D3hot support", in particular?
>
I don't believe Nouveau or NVIDIA has support for D3hot at all from
what I've heard. I've not dug further into this.
Maybe Canonical guys will have some more detail.
> Well, I have some reservations.
>
> While the idea of using _OSI to let the platform firmware find out
> what the kernel can do is generally fine by me, the implementation
> here isn't really.
>
> In the first place, the _OSI "feature" has to be defined clearly and
> in such a way that the kernel can say right away whether or not it is
> "supported". That doesn't seem to be the case here.
>
> Second (and what follows from the above), the kernel should not need
> any quirks on its side at all to give an answer. It should be able to
> say "yes" or "no" regardless of the platform it runs on if the
> firmware asks the question.
>
> So something like "Do you support native PCI power management?" would
> be fine, because native PCI power management is defined by the PCI
> standard and it should be clear what supporting it means and it
> doesn't depend on what platform the kernel runs on.
>
The problem is this is in conflict with the documentation.
As quoted:
```
_OSI("Linux-OEM-my_interface_name")
where 'OEM' is needed if this is an OEM-specific hook,
and 'my_interface_name' describes the hook, which could be a
quirk, a bug, or a bug-fix.
```
Quite literally from an OEM perspective this is a quirk. The affected
platforms as configured by default won't work properly with Linux.
We apply a code deviation if the OSPM responds yes to that OSI string.
It's entirely possible that the Linux kernel could not store a quirk table
to match the affected platforms and instead give a blanket simple fast
"Yes" answer to "Linux-Dell-Video", but I think that is no better than
_OSI("Linux"). This is at least an attestation from the OEM perspective
that we have only changed one thing by this string.
The alternative (and what has been done in the past) was the ACPI
_OSI rev hack marking those platforms for quirks and other things
before that and. I really don't want to go down that road again.
��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
