On 08/01/17 10:48, Quentin Schulz wrote:

Hi Jonathan,

On 07/01/2017 20:33, Jonathan Cameron wrote:

quoted

On 04/01/17 08:21, Rob Herring wrote:

quoted

On Mon, Jan 02, 2017 at 05:37:14PM +0100, Quentin Schulz wrote:

quoted

The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.

This patch adds the DT binding documentation for the battery power
supply which gets various data from the PMIC, such as the battery status
(charging, discharging, full, dead), current max limit, current current,
battery capacity (in percentage), voltage max and min limits, current
voltage and battery capacity (in Ah).

Signed-off-by: Quentin Schulz <redacted>
---
 .../bindings/power/supply/axp20x_battery.txt       | 27 ++++++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/supply/axp20x_battery.txt

diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
new file mode 100644
index 0000000..5489d0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt

@@ -0,0 +1,27 @@
+AXP20x and AXP22x battery power supply
+
+Required Properties:
+ - compatible, one of:
+			"x-powers,axp209-battery-power-supply"
+			"x-powers,axp221-battery-power-supply"
+ - io-channels: phandles to battery voltage, charge and discharge
+ currents ADC channels
+ - io-channel-names = "batt_v", "batt_chrg_i", "batt_dischrg_i";
+
+This node is a subnode of the axp20x/axp22x PMIC.
+
+The AXP20X and AXP22X can read the battery voltage, charge and discharge
+currents of the battery by reading ADC channels from the AXP20X/AXP22X
+ADC.
+
+Example:
+
+&axp209 {
+	battery_power_supply: battery_power_supply {

Humm, I guess you power-supply is not sufficient, so 
'battery-power-supply' and similar for ac.

quoted

+		compatible = "x-powers,axp209-battery-power-supply";
+		io-channels = <&axp209_adc 7>, <&axp209_adc 8>,
+			<&axp209_adc 9>;
+		io-channel-names = "batt_v", "batt_chrg_i",
+			"batt_dischrg_i";

Is this stuff fixed for the device?

If we don't mix the IIO channels order, it is. This driver only requires
batt_v, batt_chrg_i and batt_dischrg_i so we've to keep them at that
place in the list of IIO channels. Or as suggested by Rob and Chen-Yu, I
can move all this inside the driver with iio_map and don't care anymore
about the order.

I'd do that. Makes life easier to represented fixed things as fixed!

Thanks,
Quentin