Re: [PATCH 2/3] acpi: dptf_power: Add DPTF power participant

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

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@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.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html