On Mon, Feb 12, 2018 at 3:14 PM, <Mario.Limonciello@xxxxxxxx> wrote:
>> >> 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.
I do not have more information than current NV GPU driver doesn't
support RTD3 now but NV would support RTD3 from next new GPU chip.
If this is true, we may not need this _OSI or any workaround in next generation.
>
>> 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.
--
Cheers,
Alex Hung
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
