[linux-sunxi] Re: [RFC Patch 1/4] mfd: AXP20x: Add power supply bindings documentation

2014-11-05 Thread Bruno Prémont 
Hi Ezaul,

On Tue, 04 November 2014 Ezaul Zillmer ezaulzill...@gmail.com wrote:
 Cubieboard2  + Kernel 3.18-rc3
 
 [   15.955655] axp20x-regulator axp20x-regulator: regulators node not found
 [   15.962580] LDO1: 1300 mV
 [   15.965732] LDO2: at 3000 mV
 [   15.969120] LDO3: at 2275 mV
 [   15.972314] LDO4: at 2800 mV
 [   15.975700] LDO5: at 2800 mV
 [   15.979075] DCDC2: at 1400 mV
 [   15.982555] DCDC3: at 1250 mV
 [   15.985706] axp20x 0-0034: AXP20X driver loaded
 
 What was missing for axp20x work of cubieboard2 dt? 
 as poderiar do to run this drive? 

Not sure what patches, it at all you have on top of 3.18-rc3.
As far as I know 3.18 should not have any AXP driver that's
not already present in 3.17.

The base AXP driver only includes power-off support and bits for
regulators while the DT part of regulators is missing (at least
for cubietruck).

My patches, ideally combined with Carlo's patches from June or so
I mentioned in introduction mail would include power supply and 
input driver for power button. The regulator DT entries are in some
other patch (I think Maxime did have them in some of his trees -
probably defining them causes too much trouble because all uses are
not yet ready to explicitly use them).

On DT side, on top of my patches, for cubieboard2 you might need to
add the backup battery property if it has such a battery - I don't
think the CB2 has a main battery connector but I might be wrong
(I only have a cubietruck).

Except for that a hwmon driver would be useful to cover some of the
last bits of the AXP like temprature sensor and main voltage sensor.
With that about all the features should be covered.

Bruno

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [RFC Patch 1/4] mfd: AXP20x: Add power supply bindings documentation

2014-11-05 Thread Ezaul Zillmer 


*Hello Bruno Thank you for your attention sought some more docs just 
applying a patch and here is the result.*

*add*

*https://dev.openwrt.org/browser/trunk/target/linux/sunxi/patches-3.14/210-mfd-add-axp20x-pmic-driver.patch?rev=42463*

*https://dev.openwrt.org/browser/trunk/target/linux/sunxi/patches-3.14/211-input-add-axp20x-power-enable-key-support.patch?rev=42463*

*https://dev.openwrt.org/browser/trunk/target/linux/sunxi/patches-3.14/213-dt-sunxi-add-x-powers.patch?rev=42463*

*https://dev.openwrt.org/browser/trunk/target/linux/sunxi/patches-3.14/214-1-dt-sun7i-add-axp209-to-cubieboard2.patch?rev=42463*

*[   15.962628] i2c /dev entries driver*
*[   15.975115] input: axp20x-pek as 
/devices/soc@01c0/1c2ac00.i2c/i2c-0/0-0034/axp20x-pek/input/input0*
*[   15.985426] LDO1: 1300 mV*
*[   15.988789] LDO2: 1800 -- 3300 mV at 3000 mV*
*[   15.993788] LDO3: 700 -- 3500 mV at 2275 mV*
*[   15.998416] LDO4: 1250 -- 3300 mV at 2800 mV*
*[   16.003440] LDO5: 1800 -- 3300 mV at 2800 mV*
*[   16.008406] DCDC2: 700 -- 2275 mV at 1400 mV*
*[   16.013377] DCDC3: 700 -- 3500 mV at 1250 mV*
*[   16.018005] axp20x 0-0034: AXP20X driver loaded*

Thank´s 

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [RFC Patch 1/4] mfd: AXP20x: Add power supply bindings documentation

2014-11-05 Thread Maxime Ripard 
On Tue, Nov 04, 2014 at 10:08:27PM +0100, Bruno Prémont wrote:
 On Tue, 04 November 2014 Maxime Ripard maxime.rip...@free-electrons.com 
 wrote:
  On Mon, Nov 03, 2014 at 09:02:44PM +0100, Bruno Prémont wrote: 
   Doing something like this?:
   
   --- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
   +++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
   @@ -126,9 +126,11 @@
   interrupt-controller;
   #interrupt-cells = 1;

   -   backup = 300 200;
   -   battery.resistance = 100;
   -   battery.capacity = 2000;
   +   x-powers,backup = 300 200;
  
  I don't really remember what was that property used for. Would it make
  sense to put it into the battery node?
 
 The backup/rtc battery is completely distinct from main battery.
 
 It's presence is in no way related to that of the main battery,
 thus I would not put it into the same node.
 As all the information needed is included in the property I see
 no reason to move it into a separate node.

Oh. So it is to model some button battery that might be here to keep
the RTC state while the board is unpowered?

How is that related to the PMIC?

Maybe modeling as a fixed regulator would be more accurate.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

[linux-sunxi] Re: [RFC Patch 1/4] mfd: AXP20x: Add power supply bindings documentation

2014-11-04 Thread Bruno Prémont 
Hi Maxime,

On Tue, 21 October 2014 Maxime Ripard maxime.rip...@free-electrons.com wrote:
 On Tue, Oct 21, 2014 at 06:09:16PM +0200, Bruno Prémont wrote:
  On Tue, 21 October 2014 Lee Jones lee.jo...@linaro.org wrote:
   On Mon, 20 Oct 2014, Bruno Prémont wrote:
---
Note: the OCV values seem to have some defaults build into the
PMIC though may need adjustment if the used battery has a different
open circuit voltage curve.
As far as understood (these values are set in vendor driver but not
mentioned in chip documentation) they represent charge percentage
for some predefined voltages.

If prefixing these values with x-power, is preferred the following
patch should becomes a dependency:
  
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/267606.html
and users in patch 2/4, 4/4 need adjusting.


 Documentation/devicetree/bindings/mfd/axp20x.txt |   20 +
 1 files changed, 20 insertions(+), 0 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index cc9e01b..8ea681c 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -28,6 +28,20 @@ Required properties:
  (range: 750-1875). Default: 1.5MHz
 
 Optional properties for DCDCs:
+- backup: Settings for backup/RTC battery charger
+ (Voltage in µV, current in µA)
+ If not present, charger will be left untouched
+- battery.ocv: OCV capacity curve points (16 data values)
+- battery.resistance: internal battery resistance in mΩ
+  (defaults to 100mΩ)
+- battery.capacity: Battery capacity in mAh
+   If this attribute is missing, charger will be 
disabled
+   unless there is a battery connected.
+- battery.temp_sensor: Description of temperautre sensor, 3 values
+  - driver current (20µA, 40µA, 60µA or 80µA)
+  - low temperature warning level (in µV)
+  - high temperature warning level (in µV)
+  If missing, temperature sensor gets disabled
 - x-powers,dcdc-workmode: 1 for PWM mode, 0 for AUTO mode
  Default: AUTO mode
 
@@ -49,6 +63,12 @@ axp209: pmic@34 {
ldo3in-supply = axp_ipsout_reg;
ldo5in-supply = axp_ipsout_reg;
 
+   backup = 300 200;
+   battery.ocv = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0;
+   battery.resistance = 0;
+   battery.capacity = 2000;
+   battery.temp_sensor = 20 100 400;
   
   Since when do we use '.'s in property names?
  
  I've not found guidelines on this, but whatever is the right way to
  name them, I'm open for suggestions.
 
 You can take a look at the ePAPR specs. Even if it's quite outdated,
 it still puts you in the right mindset.

There seems to be some kind of e-mail wall in front of this document.

 That being said, since they are driver-specific properties, they
 should be prefixed by the vendor name (here x-powers).
 
 And I think they all belong in a sub-node, just like what's been done
 for the regulators.

Doing something like this?:

--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -126,9 +126,11 @@
interrupt-controller;
#interrupt-cells = 1;
 
-   backup = 300 200;
-   battery.resistance = 100;
-   battery.capacity = 2000;
+   x-powers,backup = 300 200;
+   battery: battery@0 {
+   x-powers,resistance = 100;
+   x-powers,capacity = 2000;
+   };
};
};

What are the rules to define the label after the colon?
Looking at the existing nodes it's either some address or a number...


and then the following in driver code (also adjusting the other
property names accessed)?:

@@ -678,11 +677,11 @@ static int axp20x_battery_config(struct platform_device 
*pdev,
if (ret)
return ret;
 
-   np = of_node_get(axp20x-dev-of_node);
+   np = of_find_node_by_name(axp20x-dev-of_node, battery);
if (!np)
return -ENODEV;
 
-   ret = of_property_read_u32_array(np, battery.ocv, ocv, 16);
+   ret = of_property_read_u32_array(np, x-powers,ocv, ocv, 16);
for (i = 0; ret == 0  i  ARRAY_SIZE(ocv); i++)
if (ocv[i]  100) {
dev_warn(pdev-dev, OCV[%d] %u  100\n, i, ocv[i]);


Bruno

-- 
You received this message because you are subscribed to the Google Groups

[linux-sunxi] Re: [RFC Patch 1/4] mfd: AXP20x: Add power supply bindings documentation

2014-11-04 Thread Ezaul Zillmer 
Hi Bruno

Cubieboard2  + Kernel 3.18-rc3

[   15.955655] axp20x-regulator axp20x-regulator: regulators node not found
[   15.962580] LDO1: 1300 mV
[   15.965732] LDO2: at 3000 mV
[   15.969120] LDO3: at 2275 mV
[   15.972314] LDO4: at 2800 mV
[   15.975700] LDO5: at 2800 mV
[   15.979075] DCDC2: at 1400 mV
[   15.982555] DCDC3: at 1250 mV
[   15.985706] axp20x 0-0034: AXP20X driver loaded

What was missing for axp20x work of cubieboard2 dt? 
as poderiar do to run this drive? 

I thank you!

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [RFC Patch 1/4] mfd: AXP20x: Add power supply bindings documentation

2014-11-04 Thread Maxime Ripard 
Hi Bruno,

On Mon, Nov 03, 2014 at 09:02:44PM +0100, Bruno Prémont wrote: 
 Doing something like this?:
 
 --- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
 +++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
 @@ -126,9 +126,11 @@
 interrupt-controller;
 #interrupt-cells = 1;
  
 -   backup = 300 200;
 -   battery.resistance = 100;
 -   battery.capacity = 2000;
 +   x-powers,backup = 300 200;

I don't really remember what was that property used for. Would it make
sense to put it into the battery node?

 +   battery: battery@0 {
 +   x-powers,resistance = 100;
 +   x-powers,capacity = 2000;
 +   };
 };
 };
 
 What are the rules to define the label after the colon?
 Looking at the existing nodes it's either some address or a number...

It's not called the label, but the node name, and it's defined in the
ePAPR.

It's device-class[@address]

The address being something to identify the node on a bus, so it can
be a chip select number, a memory address, an i2c address,
etc. there's really no absolute answer here.

I don't think you really need one in this case.

 and then the following in driver code (also adjusting the other
 property names accessed)?:
 
 @@ -678,11 +677,11 @@ static int axp20x_battery_config(struct platform_device 
 *pdev,
 if (ret)
 return ret;
  
 -   np = of_node_get(axp20x-dev-of_node);
 +   np = of_find_node_by_name(axp20x-dev-of_node, battery);
 if (!np)
 return -ENODEV;
  
 -   ret = of_property_read_u32_array(np, battery.ocv, ocv, 16);
 +   ret = of_property_read_u32_array(np, x-powers,ocv, ocv, 16);
 for (i = 0; ret == 0  i  ARRAY_SIZE(ocv); i++)
 if (ocv[i]  100) {
 dev_warn(pdev-dev, OCV[%d] %u  100\n, i, ocv[i]);

Yep, it looks sensible.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

[linux-sunxi] Re: [RFC Patch 1/4] mfd: AXP20x: Add power supply bindings documentation

2014-11-04 Thread Bruno Prémont 
Hi Maxime,

On Tue, 04 November 2014 Maxime Ripard maxime.rip...@free-electrons.com wrote:
 On Mon, Nov 03, 2014 at 09:02:44PM +0100, Bruno Prémont wrote: 
  Doing something like this?:
  
  --- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
  +++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
  @@ -126,9 +126,11 @@
  interrupt-controller;
  #interrupt-cells = 1;
   
  -   backup = 300 200;
  -   battery.resistance = 100;
  -   battery.capacity = 2000;
  +   x-powers,backup = 300 200;
 
 I don't really remember what was that property used for. Would it make
 sense to put it into the battery node?

The backup/rtc battery is completely distinct from main battery.

It's presence is in no way related to that of the main battery,
thus I would not put it into the same node.
As all the information needed is included in the property I see
no reason to move it into a separate node.

  +   battery: battery@0 {
  +   x-powers,resistance = 100;
  +   x-powers,capacity = 2000;
  +   };
  };
  };
  
  What are the rules to define the label after the colon?
  Looking at the existing nodes it's either some address or a number...
 
 It's not called the label, but the node name, and it's defined in the
 ePAPR.
 
 It's device-class[@address]
 
 The address being something to identify the node on a bus, so it can
 be a chip select number, a memory address, an i2c address,
 etc. there's really no absolute answer here.
 
 I don't think you really need one in this case.

In that case, I better omit it completely.

  and then the following in driver code (also adjusting the other
  property names accessed)?:
  
  @@ -678,11 +677,11 @@ static int axp20x_battery_config(struct 
  platform_device *pdev,
  if (ret)
  return ret;
   
  -   np = of_node_get(axp20x-dev-of_node);
  +   np = of_find_node_by_name(axp20x-dev-of_node, battery);
  if (!np)
  return -ENODEV;
   
  -   ret = of_property_read_u32_array(np, battery.ocv, ocv, 16);
  +   ret = of_property_read_u32_array(np, x-powers,ocv, ocv, 16);
  for (i = 0; ret == 0  i  ARRAY_SIZE(ocv); i++)
  if (ocv[i]  100) {
  dev_warn(pdev-dev, OCV[%d] %u  100\n, i, 
  ocv[i]);
 
 Yep, it looks sensible.

Thanks,
Bruno


signature.asc
Description: PGP signature

[linux-sunxi] Re: [RFC Patch 1/4] mfd: AXP20x: Add power supply bindings documentation

2014-10-21 Thread Lee Jones 
On Mon, 20 Oct 2014, Bruno Prémont wrote:

 
 ---
 Note: the OCV values seem to have some defaults build into the
 PMIC though may need adjustment if the used battery has a different
 open circuit voltage curve.
 As far as understood (these values are set in vendor driver but not
 mentioned in chip documentation) they represent charge percentage
 for some predefined voltages.
 
 If prefixing these values with x-power, is preferred the following
 patch should becomes a dependency:
   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/267606.html
 and users in patch 2/4, 4/4 need adjusting.
 
 
  Documentation/devicetree/bindings/mfd/axp20x.txt |   20 +
  1 files changed, 20 insertions(+), 0 deletion(-)
 
 diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
 b/Documentation/devicetree/bindings/mfd/axp20x.txt
 index cc9e01b..8ea681c 100644
 --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
 +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
 @@ -28,6 +28,20 @@ Required properties:
 (range: 750-1875). Default: 1.5MHz
  
  Optional properties for DCDCs:
 +- backup: Settings for backup/RTC battery charger
 +   (Voltage in µV, current in µA)
 +   If not present, charger will be left untouched
 +- battery.ocv: OCV capacity curve points (16 data values)
 +- battery.resistance: internal battery resistance in mΩ
 +  (defaults to 100mΩ)
 +- battery.capacity: Battery capacity in mAh
 + If this attribute is missing, charger will be disabled
 + unless there is a battery connected.
 +- battery.temp_sensor: Description of temperautre sensor, 3 values
 +- driver current (20µA, 40µA, 60µA or 80µA)
 +- low temperature warning level (in µV)
 +- high temperature warning level (in µV)
 +If missing, temperature sensor gets disabled
  - x-powers,dcdc-workmode: 1 for PWM mode, 0 for AUTO mode
 Default: AUTO mode
  
 @@ -49,6 +63,12 @@ axp209: pmic@34 {
   ldo3in-supply = axp_ipsout_reg;
   ldo5in-supply = axp_ipsout_reg;
  
 + backup = 300 200;
 + battery.ocv = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0;
 + battery.resistance = 0;
 + battery.capacity = 2000;
 + battery.temp_sensor = 20 100 400;

Since when do we use '.'s in property names?

   regulators {
   x-powers,dcdc-freq = 1500;
  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

-- 
You received this message because you are subscribed to the Google Groups 
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [RFC Patch 1/4] mfd: AXP20x: Add power supply bindings documentation

2014-10-21 Thread Maxime Ripard 
Hi Bruno,

Thanks a lot for working on this!

On Tue, Oct 21, 2014 at 06:09:16PM +0200, Bruno Prémont wrote:
 On Tue, 21 October 2014 Lee Jones lee.jo...@linaro.org wrote:
  On Mon, 20 Oct 2014, Bruno Prémont wrote:
   ---
   Note: the OCV values seem to have some defaults build into the
   PMIC though may need adjustment if the used battery has a different
   open circuit voltage curve.
   As far as understood (these values are set in vendor driver but not
   mentioned in chip documentation) they represent charge percentage
   for some predefined voltages.
   
   If prefixing these values with x-power, is preferred the following
   patch should becomes a dependency:
 
   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/267606.html
   and users in patch 2/4, 4/4 need adjusting.
   
   
Documentation/devicetree/bindings/mfd/axp20x.txt |   20 +
1 files changed, 20 insertions(+), 0 deletion(-)
   
   diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
   b/Documentation/devicetree/bindings/mfd/axp20x.txt
   index cc9e01b..8ea681c 100644
   --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
   +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
   @@ -28,6 +28,20 @@ Required properties:
   (range: 750-1875). Default: 1.5MHz

Optional properties for DCDCs:
   +- backup: Settings for backup/RTC battery charger
   +   (Voltage in µV, current in µA)
   +   If not present, charger will be left untouched
   +- battery.ocv: OCV capacity curve points (16 data values)
   +- battery.resistance: internal battery resistance in mΩ
   +  (defaults to 100mΩ)
   +- battery.capacity: Battery capacity in mAh
   + If this attribute is missing, charger will be disabled
   + unless there is a battery connected.
   +- battery.temp_sensor: Description of temperautre sensor, 3 values
   +- driver current (20µA, 40µA, 60µA or 80µA)
   +- low temperature warning level (in µV)
   +- high temperature warning level (in µV)
   +If missing, temperature sensor gets disabled
- x-powers,dcdc-workmode: 1 for PWM mode, 0 for AUTO mode
   Default: AUTO mode

   @@ -49,6 +63,12 @@ axp209: pmic@34 {
 ldo3in-supply = axp_ipsout_reg;
 ldo5in-supply = axp_ipsout_reg;

   + backup = 300 200;
   + battery.ocv = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0;
   + battery.resistance = 0;
   + battery.capacity = 2000;
   + battery.temp_sensor = 20 100 400;
  
  Since when do we use '.'s in property names?
 
 I've not found guidelines on this, but whatever is the right way to
 name them, I'm open for suggestions.

You can take a look at the ePAPR specs. Even if it's quite outdated,
it still puts you in the right mindset.

That being said, since they are driver-specific properties, they
should be prefixed by the vendor name (here x-powers).

And I think they all belong in a sub-node, just like what's been done
for the regulators.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature