Re: [PATCH 2/3] acpi: dptf_power: Add DPTF power participant
From: Rafael J. Wysocki <hidden>
Date: 2016-06-21 16:17:47
On Friday, May 06, 2016 07:59:43 PM Srinivas Pandruvada wrote:
quoted hunk ↗ jump to hunk
This driver adds support for Dynamic Platform and Thermal Framework (DPTF) Platform Power Participant device support. This participant is responsible for exposing platform telemetry such as platform Power, battery Information such as state of Charge, estimated maximum sustainable power (PMax), SMART battery spec information. This driver is implemented as a platform driver for INT3407 and presented as power_supply device. Since this has common features with the ACPI battery, existing interface provide by battery_common driver are reused to present as a battery power supply device. Since this driver will also register a battery power supply device,this driver will exit if CONFIG_ACPI_BATTERY is defined. There are two types of objects in INT3407: - Same as ACPI Battery objects: _BST and _BIX. These are exposed as standard power supply attributes. - Specific to INT3407, which are related to platform power There are some objects, for which it doesn't make sense to enhance power_supply class and add attributes there. They are represented as sysfs attribute under acpi device. Here the bid for INT3407 is TPWR in the following example. /sys/class/power_supply/TPWR ├── alarm ├── capacity ├── capacity_level ├── cycle_count ├── device -> ../../../INT3407:00 │ ├── dptf_power │ │ ├── adapter_rating │ │ ├── battery_steady_power │ │ ├── charger_type │ │ ├── max_platform_power │ │ ├── platform_power_source │ │ ├── power_sampling_period For example representing AC/adapter properties as a power_supply properties will not make sense for a battery device. In some case when there is an existing property, the meaning is different. For example charger_type has a equivalent power_supply property, which has different symantics than INT3407. ACPI methods description used in this driver: PSOC: Platform Battery State Of Charge as a percentage. PMAX: Maximum platform power that can be supported by the battery in mW. PSRC: System charge source, 0x00 = DC 0x01 = AC 0x02 = USB 0x03 = Wireless Charger ARTG: Adapter rating in mW (Maximum Adapter power) Must be 0 if no AC Adaptor is plugged in. CTYP: Charger Type, Traditional : 0x01 Hybrid: 0x02 NVDC: 0x03 PBSS: Returns max sustained power for battery in milliWatts. DPSP: Sets the polling interval in 10ths of seconds. A value of 0 tells the driver to use event notification for PMAX and PBSS Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> --- drivers/acpi/Kconfig | 19 ++++++ drivers/acpi/Makefile | 1 + drivers/acpi/dptf_power.c | 157 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 177 insertions(+) create mode 100644 drivers/acpi/dptf_power.cdiff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index bc5af2c..ac5cfe8 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig@@ -526,4 +526,23 @@ config XPOWER_PMIC_OPREGION endif +config DPTF_POWER + tristate "DPTF Platform Power Participant" + depends on X86 && !ACPI_BATTERY
After a closer look, distros won't like this. They need to have a binary image that will work on all systems, so they need to be able to build both modules at the same time. I guess the DPTF one can be made look if there is a driver attached to the battery device object already and bail out if that's the case. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html