On Fri, 2017-08-11 at 14:43 +0000, Mario.Limonciello@xxxxxxxx wrote: > > > > -----Original Message----- > > From: Srinivas Pandruvada [mailto:srinivas.pandruvada@linux.intel.c > > om] > > Sent: Thursday, August 10, 2017 5:54 PM > > To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>; rjw@rjwysocki. > > net; > > lenb@xxxxxxxxxx > > Cc: linux-pm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux- > > acpi@xxxxxxxxxxxxxxx; lukas@xxxxxxxxx > > Subject: Re: [PATCH v2 2/2] ACPI / Sleep: Check low power idle > > constraints for > > debug only > > > > On Thu, 2017-08-10 at 22:07 +0000, Mario.Limonciello@xxxxxxxx > > wrote: > > > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > + > > > > + ret = acpi_device_get_power(adev, &state); > > > > + if (!ret) > > > > + pr_debug("LPI: %s required min power > > > > state > > > > %d, current > > > > power state %d, real power state %d\n", > > > > + lpi_constraints_table[i].name > > > > , > > > > + lpi_constraints_table[i].min_ > > > > dsta > > > > te, > > > > + adev->power.state, state); > > > Isn't this superfluous to be showing the state returned from > > > acpi_device_get_power and > > > also probing directly at the state? You can't just rely on the > > > information you got > > > back from apci_device_get_power? > > They can be different as one is real power state and the other is > > what > > was set. > > For example on Dell 9365 it shows > > > > [ 1924.393653] LPI: \_SB.PCI0.XHC required min power state 3, > > current > > power state 3, real power state 255 > > > Isn't 255 ACPI_STATE_UNKNOWN? That makes it seem like it > is a logic problem in acpi_device_get_power (or somewhere down the > chain) > doesn't it? There is no _PSC for XHC device. So it will return unknown. This is an optional object, so I think that dumping the status is fine, but matching with output of acpi_device_get_power() as it relies on _PSC is not correct for the constraint. Thanks, Srinivas > > > > > > > > > > > > > > > > > > > > > + > > > > + if (adev->flags.power_manageable && adev- > > > > > > > > > > power.state < > > > > + lpi_constraints_table[ > > > > i].m > > > > in_dstate) > > > > + pr_info("LPI: Constraint [%s] not > > > > matched\n", > > > > + lpi_constraints_table[i].name > > > > ); > > > Similarly here, can't you just compare against &state instead? > > > > > The problem then the check will fail for XHCI on Dell 9365. So not > > using "state". > > > > Thanks, > > Srinivas > > > > > > > > > > > > > > > + } > > > > +} > > > > + > > > > static void acpi_sleep_run_lps0_dsm(unsigned int func) > > > > { > > > > union acpi_object *out_obj; > > > > @@ -729,6 +886,9 @@ static int lps0_device_attach(struct > > > > acpi_device *adev, > > > > "_DSM function 0 evaluation > > > > failed\n"); > > > > } > > > > ACPI_FREE(out_obj); > > > > + > > > > + lpi_device_get_constraints(); > > > > + > > > > return 0; > > > > } > > > > > > > > @@ -773,6 +933,8 @@ static void acpi_freeze_wake(void) > > > > */ > > > > if (acpi_sci_irq_valid() && > > > > !irqd_is_wakeup_armed(irq_get_irq_data(acpi_sci_ir > > > > q))) > > > > { > > > > + if (pm_debug_messages_enabled()) > > > > + lpi_check_constraints(); > > > > pm_system_cancel_wakeup(); > > > > s2idle_wakeup = true; > > > > } > > > > -- > > > > 2.7.5 -- 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
