On Friday, May 06, 2016 07:59:43 PM Srinivas Pandruvada wrote: > 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@xxxxxxxxxxxxxxx> > --- > 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.c > > diff --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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
