> -----Original Message----- > From: Limonciello, Mario <Mario.Limonciello@xxxxxxx> > Sent: Tuesday, May 11, 2021 1:25 PM > To: Rafael J. Wysocki <rafael@xxxxxxxxxx>; Liang, Prike > <Prike.Liang@xxxxxxx>; Deucher, Alexander > <Alexander.Deucher@xxxxxxx> > Cc: Rafael J . Wysocki <rjw@xxxxxxxxxxxxx>; Len Brown <lenb@xxxxxxxxxx>; > ACPI Devel Maling List <linux-acpi@xxxxxxxxxxxxxxx> > Subject: RE: [PATCH] ACPI / idle: override c-state latency when not in > conformance with s0ix > > > On Tue, May 11, 2021 at 6:59 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> > wrote: > > > > > > On Tue, May 11, 2021 at 5:21 PM Limonciello, Mario > > > <Mario.Limonciello@xxxxxxx> wrote: > > > > > > > > > Well, if find_deepest_state() looked at the target residency > > > > > instead of the exit latency, this would work I suppose? > > > > > > > > Unfortunately I don't think this would help - from an OEM system > > > > the > > following > > > > target residency values: > > > > > > > > # cat /sys/devices/system/cpu/cpu0/cpuidle/*/residency > > > > 0 > > > > 2 > > > > 800 > > > > 700 > > > > > > But this means that not just S0ix, but cpuidle in general doesn't > > > work correctly on those systems and the latency quirk doesn't help here. > > > > > > Well, it looks like the driver needs to sort the C-states table, then. > > > > But that wouldn't help, because the 700 us idle state is in fact deeper, > right? > > > > Are the values just swapped or are they completely bogus? > > Actually I think the value set in the OEM BIOS for state2 from LPI looks bogus > too. > It should have been 36us. > > @Liang, Prike and @Deucher, Alexander you have some more history on this > than I do. I think they were just bogus, at least in the initial cases where we saw this. Alex
