On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst <kherbst@xxxxxxxxxx> wrote: > > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg > > <mika.westerberg@xxxxxxxxx> wrote: > > > > > > On Wed, Nov 20, 2019 at 11:52:22AM +0100, Rafael J. Wysocki wrote: > > > > On Wed, Nov 20, 2019 at 11:18 AM Mika Westerberg > > > > <mika.westerberg@xxxxxxxxx> wrote: > > > > > [cut] > > > > > > > > Oh, so does it look like we are trying to work around AML that tried > > > > to work around some problematic behavior in Linux at one point? > > > > > > Yes, it looks like so if I read the ASL right. > > > > OK, so that would call for a DMI-based quirk as the real cause for the > > issue seems to be the AML in question, which means a firmware problem. > > > > And I disagree as this is a linux specific workaround and windows goes > that path and succeeds. This firmware based workaround was added, > because it broke on Linux. Apparently so at the time it was added, but would it still break after the kernel changes made since then? Moreover, has it not become harmful now? IOW, wouldn't it work after removing the "Linux workaround" from the AML? The only way to verify that I can see would be to run the system with custom ACPI tables without the "Linux workaround" in the AML in question. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
