driver notification when switching between battery vs AC power?
Hi Rafael,
do we have infrastructure that notifies the driver when a system is switching from batter to AC power? There is a proposal to make the Linux NVMe driver power management match the policy used by the Windows driver more closely, which does this and we'd like to prototype that to check what difference the policy makes.
Hi Christoph,
Quoted 5 lines · Christoph Hellwig
Hi Rafael,
do we have infrastructure that notifies the driver when a system is switching from batter to AC power?
On systems with ACPI that can be done through an ACPI notifier, see amdgpu_acpi_event() for one example.
Adding Rui who's likely to be more familiar with this topic than I am.
Quoted 4 lines
There is a proposal to make the
Linux NVMe driver power management match the policy used by the Windows driver more closely, which does this and we'd like to prototype that to check what difference the policy makes.
Quoted 6 lines · Rafael J. Wysocki
Hi Christoph,
Quoted 3 lines · Christoph Hellwig
Hi Rafael,
Quoted 8 lines
Quoted 2 lines
do we have infrastructure that notifies the driver when a system is switching from batter to AC power?
On systems with ACPI that can be done through an ACPI notifier, see
amdgpu_acpi_event()for one example.Adding Rui who's likely to be more familiar with this topic than I am.
Thanks for adding me in the loop.
Yes, an ACPI notifier callback should be sufficient for this purpose.
Usually, we get an ACPI notification upon AC plug/unplug, so what we need in the NVMe driver is to get the notification and then get the status of AC adapter. As ACPI AC driver always sends the AC events to acpi notifier chain, what we need is
a) define a notifier callback, and in the notifier callback
1. ignore non-AC devices,
2. get AC status, you can refer to acpi_ac_get_state()
b) register the notifier cb to ACPI notifier chain, by invoking register_acpi_notifier()
thanks,
rui
Quoted 6 lines
Quoted 6 lines
There is a proposal to make the
Linux NVMe driver power management match the policy used by the Windows driver more closely, which does this and we'd like to prototype
that to check what difference the policy makes.
Quoted 4 lines · Zhang Rui
Thanks for adding me in the loop.
Yes, an ACPI notifier callback should be sufficient for this purpose.
Quoted 9 lines
Usually, we get an ACPI notification upon AC plug/unplug, so what we need in the NVMe driver is to get the notification and then get the status of AC adapter. As ACPI AC driver always sends the AC events to acpi notifier chain, what we need is
a) define a notifier callback, and in the notifier callback
1. ignore non-AC devices,
2. get AC status, you can refer toacpi_ac_get_state()
b) register the notifier cb to ACPI notifier chain, by invokingregister_acpi_notifier()
Not my direct priority now, but would there be any objections to wire up a power_source_notifier method in struct dev_pm_ops to avoid boilerplate code and ACPI dependencies in drivers?
Quoted 16 lines · Christoph Hellwig
Quoted 4 lines · Zhang Rui
Thanks for adding me in the loop.
Yes, an ACPI notifier callback should be sufficient for this purpose.
Quoted 9 lines
Usually, we get an ACPI notification upon AC plug/unplug, so what we need in the NVMe driver is to get the notification and then get the status of AC adapter. As ACPI AC driver always sends the AC events to acpi notifier chain, what we need is
a) define a notifier callback, and in the notifier callback
1. ignore non-AC devices,
2. get AC status, you can refer toacpi_ac_get_state()
b) register the notifier cb to ACPI notifier chain, by invokingregister_acpi_notifier()
Quoted 3 lines
Not my direct priority now, but would there be any objections to wire up a
power_source_notifiermethod in structdev_pm_opsto avoid boilerplate code and ACPI dependencies in drivers?
That would work for me, unless there is something more generic than the ACPI-based notification mechanism already in the power supply framework. Sebastian?
Quoted 18 lines · Rafael J. Wysocki
Quoted 16 lines · Christoph Hellwig
Quoted 13 lines · Zhang Rui
Thanks for adding me in the loop.
Yes, an ACPI notifier callback should be sufficient for this purpose.
Usually, we get an ACPI notification upon AC plug/unplug, so what we need in the NVMe driver is to get the notification and then get the status of AC adapter. As ACPI AC driver always sends the AC events to acpi notifier chain, what we need is
a) define a notifier callback, and in the notifier callback
1. ignore non-AC devices,
2. get AC status, you can refer toacpi_ac_get_state()
b) register the notifier cb to ACPI notifier chain, by invokingregister_acpi_notifier()
Quoted 5 lines
Quoted 3 lines
Not my direct priority now, but would there be any objections to wire up a
power_source_notifiermethod in structdev_pm_opsto avoid boilerplate code and ACPI dependencies in drivers?That would work for me,
Kind of on a second thought, the convention around dev_pm_ops is that if the given callback is provided by the device's bus type, it will be invoked from there and not directly from the driver, and the bus-type-level callback is expected to decide whether or not to invoke the driver one.
If that doesn't match the envisioned power_source_notifier handling, dev_pm_ops may not be the most suitable location for it. It may be better to add something to struct device_driver directly.
Quoted 3 lines
unless there is something more generic than
the ACPI-based notification mechanism already in the power supply framework. Sebastian?
Hi,
Quoted 16 lines · Rafael J. Wysocki
Quoted 15 lines · Christoph Hellwig
Quoted 13 lines · Zhang Rui
Thanks for adding me in the loop.
Yes, an ACPI notifier callback should be sufficient for this purpose.
Usually, we get an ACPI notification upon AC plug/unplug, so what we need in the NVMe driver is to get the notification and then get the status of AC adapter. As ACPI AC driver always sends the AC events to acpi notifier chain, what we need is
a) define a notifier callback, and in the notifier callback
1. ignore non-AC devices,
2. get AC status, you can refer toacpi_ac_get_state()
b) register the notifier cb to ACPI notifier chain, by invokingregister_acpi_notifier()
Quoted 7 lines
Quoted 3 lines
Not my direct priority now, but would there be any objections to wire up a
power_source_notifiermethod in structdev_pm_opsto avoid boilerplate code and ACPI dependencies in drivers?That would work for me, unless there is something more generic than the ACPI-based notification mechanism already in the power supply framework. Sebastian?
power-supply framework provides two things:
a) One can register into the power-supply notifier chain using power_supply_reg_notifier(). This should be triggered by AC plug/unplug (among other things) as long as the driver calls power_supply_changed() when online state changes. I took a quick glance and ACPI AC driver does not seem to call it at the moment. I think both calls to kobject_uevent() in the driver need to change into power_supply_changed() for this to work on ACPI based systems.
b) There is power_supply_is_system_supplied() to check if the system is supplied by a non-battery type device (which might also be USB-C).
-- Sebastian