Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

2016-07-05 Thread Bruno Prémont 
On Tue, 5 Jul 2016 11:25:10 +0200 Maxime Ripard wrote:
> On Tue, Jul 05, 2016 at 04:33:31PM +0800, Icenowy Zheng wrote:
> > 
> > 
> > 05.07.2016, 13:26, "Michael Haas" :  
> > > Hi,
> > >
> > > nice work! Is this in any way related to Bruno Prémonts driver for the
> > > axp20x?
> > >
> > > I've got a reworked version of that lying around, but it's not quite
> > > ready for submission. Do you know what pieces are missing in your driver
> > > for axp20x support - as opposed to axp22x, which is already working?  
> > 
> > Therotically, it can run on axp20x. However, I have currently no
> > test device. (Still waiting for my C.H.I.P.)  So I can only promise
> > it to run on axp22x.  
> 
> Still, it looks like you just took Bruno's driver, stripped out the
> axp20x parts and added the one to deal with axp22x.
> 
> This makes the driver look weird, by being called axp20x, without
> actually supporting those PMICs, but having some axp22x variables
> right in the middle. And that's awfully inconsistent.
> 
> I'd rather have you add the AXP20x driver directly, and then add the
> needed stuff for the AXP22x.

>From a very quick look at the patch it looks like only basic
"monitoring" features have been retained, and yes, claiming the driver
to be for axp22x and having the functions named axp20x feels weird.

Missing parts are OCV, charge control (be it as interaction with
USB-power where charge current must be limited to not over-drain
USB power source or manual control when user knows more about the USB
power plug than the device).

Proper capacity measurement is a completely different story which I
did not implement (it exists in 3.4 sunxi kernel but is not
straight-forward and makes use of extra registers for data keeping).

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.

Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

2016-07-05 Thread Bruno Prémont 
On Tue, 05 Jul 2016 16:47:38 +0800 Icenowy Zheng wrote:
> I read the datasheet of axp20x, and then found that this driver does
> not support backup RTC battery.
> (But maybe backup battery do not need a driver -- at least on IBM PC
> it has no driver)

A driver is needed to enable/disable the RTC battery charging (unless
uboot does it).
However all the driver can do according to datasheet is configure the
charge voltage/current or disable charging completely.
Monitoring RTC battery is not possible, neither is presence detection.

So driver should just apply configuration it finds in device-tree and
eventually share that information via power supply class.

> And I don't know whether the axp20x has default Li-ion/LiPo battery
> OCV parameter. (axp22x seems to be have a set of default OCV)

It seems to have default OCV parameters as well. With empty RTC
battery OCV values are present.

> You can test this driver on AXP20x. (I think I didn't access to
> AXP22x-specified registers in the power supply code)

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.

Re: [linux-sunxi] Charger/battery driver for axp20x being worked on?

2016-03-31 Thread Bruno Prémont 
Hello Michael,

On Thu, 31 Mar 2016 08:41:57 +0200 Michael Haas wrote:
> Hello,
> 
> (adding Bruno to CC)

Thanks for CCing, as I currently catch up with mailing list rather
sporadically!

> On 03/31/2016 08:24 AM, Chen-Yu Tsai wrote:
> >>
> >> Is anyone working on that? If not, I'll get started.  
> > 
> > There was an attempt some time ago:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/295547.html
> >   
> 
> 
> Bruno had submitted a new version a year later:
> 
> http://comments.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/17980
> 
> There was also a different patchset by Siarhei Siamashka:
> 
> https://groups.google.com/forum/#!topic/linux-sunxi/u4Rwo630MnY
> 
> Bruno,
> 
> can you comment on the state of the patchset? I'd be happy to pick up
> where you left off.

Currently I don't have enough spare time to (actively) work on the patch
set, so feel free to pick up!

With recent additions of support for other AXP variants some porting
work has to be done (not sure I published my latest porting attempts
with some rework to adapt to Hans's axp20x_usb_power.c) and I won't have
time/access to right device to check before mid April.

> >> CC'ing Hans as he implemented axp20x_usb_power.c.  
> > 
> > IIRC, Hans previously said that the acin and vbus supplies should be handled
> > by separate power supply drivers. ACIN is easy to do. Just port the VBUS 
> > one.
> >   
> 
> Yeah, that is very straightforward.

Just remember that some devices short-cut ACIN and VBUS, thus the ACIN
driver should only load when the AXP status bit indicates they are
distinct (maybe also having device-tree flag to indicate connector
presence when not short-cutted).

> > The charger would likely be another separate driver, either combined or
> > separate from the fuel gauge (charge level) driver.  

One thing I explicitly left aside was "estimating battery capacity", the
original 3.4.x code included some heuristics for that with saving
intermediate values to AXP's registers (data registers kept alive as
long as power was present).

Gauge and charger should be a single driver, especially when capacity
estimation comes into play. Interesting is the part of adjusting charge
current based on AC/VBUS power source and taking VBUS's max-current into
account.


The RTC battery charger though can be a mostly hidden driver as all it
needs is some settings from device-tree (voltage/current) and has no
data to report. Letting the user tune voltage/current or enable/disable
the charger is a matter of taste. From my cubietruck's behavior it seems
as if charger enablement might have an impact of rtc battery's
discharge rate while device is powered-off.

Best,
bruno

> I agree.
> 
> Best
> 
> Michael

-- 
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: [PATCH WIP] AXP20x drivers for RTC-battery, AC and Li-Ion battery

2015-08-08 Thread Bruno Prémont 
Hi Hans,

The best way to figure out is to dump AXP registers via i2c, though no
idea how easy it's to get such a dumping tool running on android
(static binary with root should work fine).
Rebooting from android and dumping AXP under uboot should work too.

I wrote some code to decode such i2c dumps, need to look it up (might
event be in a mail to linux-sunxi list).

FEX file should also include at least some of the values.
Battery capacity should be show in android's battery power supply.

Regards,
Bruno


On Sat, 8 Aug 2015 16:32:21 Hans de Goede hdego...@redhat.com wrote:
 Hi,
 
 On 04-08-15 22:11, Bruno Prémont wrote:
  This is all my changes to port my original driver on top of Hans' work.
 
  Before anything of this can be merged a few steps are still needed:
  - split big patch in a series
  - rtc/ac supplies: document DT bindings
  - battery driver: implement missing parts, cleanup, handle delayed_work
   suspend/resume, document DT bindings, setup charge-LED if
   flagged present in DT
 
  Comments and suggestions welcome.
 
 Cool stuff. I would like to test this on a couple of axp209
 using tablets I have, how can I figure out the various
 battery devicetree fields from within android ?
 
 Regards,
 
 Hans

-- 
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] [PATCH WIP] AXP20x drivers for RTC-battery, AC and Li-Ion battery

2015-08-04 Thread Bruno Prémont 
,
+   .of_compatible  = x-powers,axp202-rtc-battery,
},
 };
 
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index ae0f27d..67794e8 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY)   += generic-adc-battery.o
 
 obj-$(CONFIG_PDA_POWER)+= pda_power.o
 obj-$(CONFIG_APM_POWER)+= apm_power.o
-obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o
+obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o axp20x_rtc_power.o 
axp20x_ac_power.o axp20x_fuel_gauge.o
 obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
 obj-$(CONFIG_WM831X_BACKUP)+= wm831x_backup.o
 obj-$(CONFIG_WM831X_POWER) += wm831x_power.o
diff --git a/drivers/power/axp20x_ac_power.c b/drivers/power/axp20x_ac_power.c
index e69de29..d8ecde6 100644
--- a/drivers/power/axp20x_ac_power.c
+++ b/drivers/power/axp20x_ac_power.c
@@ -0,0 +1,203 @@
+/*
+ * AXP20x PMIC AC power driver
+ *
+ * Copyright 2014-2015 Bruno Prémont bonb...@linux-vserver.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under  the terms of the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/err.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/mfd/axp20x.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/power_supply.h
+#include linux/regmap.h
+#include linux/slab.h
+
+#define DRVNAME axp20x-ac-power
+/* Fields of AXP20X_PWR_INPUT_STATUS */
+#define AXP20X_PWR_STATUS_AC_PRESENT BIT(7)
+#define AXP20X_PWR_STATUS_AC_AVAILABLE   BIT(6)
+#define AXP20X_PWR_STATUS_AC_VBUS_SHORT  BIT(1)
+#define AXP20X_PWR_STATUS_AC_VBUS_SELBIT(0)
+
+/* Fields of AXP20X_ADC_EN1 */
+#define AXP20X_ADC_EN1_ACIN_VOLT BIT(5)
+#define AXP20X_ADC_EN1_ACIN_CURR BIT(4)
+
+struct axp20x_ac_power {
+   struct regmap *regmap;
+   struct power_supply *supply;
+};
+
+static int axp20x_ac_power_get_property(struct power_supply *psy,
+   enum power_supply_property psp, union power_supply_propval *val)
+{
+   struct axp20x_ac_power *power = power_supply_get_drvdata(psy);
+   unsigned int input;
+   int r;
+
+   switch (psp) {
+   case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+   r = axp20x_read_variable_width(power-regmap,
+  AXP20X_ACIN_V_ADC_H, 12);
+   if (r  0)
+   return r;
+
+   val-intval = r * 1700; /* 1 step = 1.7 mV */
+   return 0;
+   case POWER_SUPPLY_PROP_CURRENT_NOW:
+   r = axp20x_read_variable_width(power-regmap,
+  AXP20X_ACIN_I_ADC_H, 12);
+   if (r  0)
+   return r;
+
+   val-intval = r * 375; /* 1 step = 0.375 mA */
+   return 0;
+   default:
+   break;
+   }
+
+   /* All the properties below need the input-status reg value */
+   r = regmap_read(power-regmap, AXP20X_PWR_INPUT_STATUS, input);
+   if (r)
+   return r;
+
+   switch (psp) {
+   case POWER_SUPPLY_PROP_PRESENT:
+   val-intval = !!(input  AXP20X_PWR_STATUS_AC_PRESENT);
+   break;
+   case POWER_SUPPLY_PROP_ONLINE:
+   val-intval = !!(input  AXP20X_PWR_STATUS_AC_AVAILABLE);
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static enum power_supply_property axp20x_ac_power_properties[] = {
+   POWER_SUPPLY_PROP_PRESENT,
+   POWER_SUPPLY_PROP_ONLINE,
+   POWER_SUPPLY_PROP_VOLTAGE_NOW,
+   POWER_SUPPLY_PROP_CURRENT_NOW,
+};
+
+static const struct power_supply_desc axp20x_ac_power_desc = {
+   .name = axp20x-ac,
+   .type = POWER_SUPPLY_TYPE_MAINS,
+   .properties = axp20x_ac_power_properties,
+   .num_properties = ARRAY_SIZE(axp20x_ac_power_properties),
+   .get_property = axp20x_ac_power_get_property,
+};
+
+static irqreturn_t axp20x_irq_ac_over_v(int irq, void *devid)
+{
+   struct axp20x_ac_power *power = devid;
+
+   dev_warn(power-supply-dev, IRQ#%d AC over voltage\n, irq);
+   power_supply_changed(power-supply);
+
+   return IRQ_HANDLED;
+}
+
+static irqreturn_t axp20x_irq_ac_plugin(int irq, void *devid)
+{
+   struct axp20x_ac_power *power = devid;
+
+   dev_info(power-supply-dev, IRQ#%d AC connected\n, irq);
+   power_supply_changed(power-supply);
+
+   return IRQ_HANDLED;
+}
+
+static irqreturn_t axp20x_irq_ac_removal(int irq, void *devid)
+{
+   struct axp20x_ac_power *power = devid;
+
+   dev_info(power-supply-dev, IRQ#%d AC disconnected\n, irq);
+   power_supply_changed(power-supply);
+
+   return IRQ_HANDLED;
+}
+
+static int axp20x_ac_power_probe(struct platform_device *pdev)
+{
+   struct axp20x_dev *axp20x

[linux-sunxi] Re: [PATCH v3 resend 1/2] mfd: axp20x: Add missing registers, and mark more registers volatile

2015-08-02 Thread Bruno Prémont 
On Sat,  1 Aug 2015 09:25:17 Hans de Goede hdego...@redhat.com wrote:
 From: Bruno Prémont bonb...@linux-vserver.org
 
 Add an extra set of registers which is necessary tu support the PMICs
 battery charger function, and mark registers which contain status bits,
 gpio status, and adc readings as volatile.
 
 Cc: Bruno Prémont bonb...@linux-vserver.org
 Signed-off-by: Bruno Prémont bonb...@linux-vserver.org
 Signed-off-by: Hans de Goede hdego...@redhat.com
 Acked-by: Lee Jones lee.jo...@linaro.org
 Acked-by: Maxime Ripard maxime.rip...@free-electrons.com
 ---
 Changes in v2:
 -Add a AXP20X_OCV_MAX define
 Changes in v3:
 -Add Bruno's S-o-b
 ---
  drivers/mfd/axp20x.c   | 8 +++-
  include/linux/mfd/axp20x.h | 6 ++
  2 files changed, 13 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
 index b369cfc..8bd3283 100644
 --- a/drivers/mfd/axp20x.c
 +++ b/drivers/mfd/axp20x.c
 @@ -61,10 +61,16 @@ static const struct regmap_access_table 
 axp152_volatile_table = {
  static const struct regmap_range axp20x_writeable_ranges[] = {
   regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
   regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
 + regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(15)),

As AXP20X_OCV_MAX has been added, this should be:
+   regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),

  };
  
  static const struct regmap_range axp20x_volatile_ranges[] = {
 + regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_USB_OTG_STATUS),
 + regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL2),
   regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
 + regmap_reg_range(AXP20X_ACIN_V_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
 + regmap_reg_range(AXP20X_GPIO20_SS, AXP20X_GPIO3_CTRL),
 + regmap_reg_range(AXP20X_FG_RES, AXP20X_RDC_L),
  };
  
  static const struct regmap_access_table axp20x_writeable_table = {
 @@ -195,7 +201,7 @@ static const struct regmap_config axp20x_regmap_config = {
   .val_bits   = 8,
   .wr_table   = axp20x_writeable_table,
   .volatile_table = axp20x_volatile_table,
 - .max_register   = AXP20X_FG_RES,
 + .max_register   = AXP20X_OCV(AXP20X_OCV_MAX),
   .cache_type = REGCACHE_RBTREE,
  };
  
 diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
 index 52203d5..cc8ad1e 100644
 --- a/include/linux/mfd/axp20x.h
 +++ b/include/linux/mfd/axp20x.h
 @@ -190,6 +190,12 @@ enum {
  #define AXP20X_CC_CTRL   0xb8
  #define AXP20X_FG_RES0xb9
  
 +/* OCV */
 +#define AXP20X_RDC_H 0xba
 +#define AXP20X_RDC_L 0xbb
 +#define AXP20X_OCV(m)(0xc0 + (m))
 +#define AXP20X_OCV_MAX   0xf
 +
  /* AXP22X specific registers */
  #define AXP22X_BATLOW_THRES1 0xe6
  

-- 
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.

Re: [linux-sunxi] [PATCH 6/8] ARM: dts: axp209: Add usb_power_supply child node to the ax209 node

2015-07-31 Thread Bruno Prémont 
On Fri, 31 Jul 2015 14:14:28 +0800 Chen-Yu Tsai wrote:
 On Fri, Jul 31, 2015 at 1:51 PM, Bruno Prémont wrote:
  Hi ChenYu,
 
  On Fri, 31 Jul 2015 13:31:53 +0800 Chen-Yu Tsai wrote:
  Hi Hans,
 
  On Wed, Jun 10, 2015 at 5:37 AM, Hans de Goede wrote:
   Add a node representing the usb power supply part of the axp209 pmic, 
   note
   that the usb power supply and the (to be added later) ac power supply 
   will
   each have their own child-node, so that they can be separately specified
   as power-supply for other nodes using a power-supply property with a
   phandle pointing to the right axp209 child-node.
  
   Signed-off-by: Hans de Goede hdego...@redhat.com
   ---
arch/arm/boot/dts/axp209.dtsi | 5 +
1 file changed, 5 insertions(+)
  
   diff --git a/arch/arm/boot/dts/axp209.dtsi 
   b/arch/arm/boot/dts/axp209.dtsi
   index 24c935c..051ab3b 100644
   --- a/arch/arm/boot/dts/axp209.dtsi
   +++ b/arch/arm/boot/dts/axp209.dtsi
   @@ -89,4 +89,9 @@
   regulator-name = ldo5;
   };
   };
   +
   +   usb_power_supply: usb_power_supply {
   +   compatible = x-powers,axp202-usb-power-supply;
   +   status = disabled;
 
  Is there any reason to have this disabled by default?
  AFAIK this is not something configurable in hardware,
  and the driver just gives readouts and status updates.
 
  There are some devices that only have 'AC-IN' instead of usb/otg power
  (set-top boxes) so having the devices tell what power sources they
  have makes sense (otherwise those that have ac-in instead of otg would
  have to disable usb_power_supply) and avoids confusion by explicitly
  stating presence in device dts.
 
 That's true. But this is a bit of hardware inside the AXP.
 If it's power isn't routed, it should report it, shouldn't it?

If the device does not use the input there are two cases:
- ac-in and usb/otg in short-circuited (there is a bit in AXP registers
  to provide this indication)
- the unused one is just not connected/connectable

In either case the voltage of the unused/unusable branch is not really
useful, nor is it useful to have it show up in sysfs.

 And normal users would probably expect to read the input
 voltage/current/status through sysfs (or maybe hwmon?),
 instead of not finding the device and having to look through
 the DTS.

Only those supplies effectively present (in-use or with connectors
to eventually use them) should be visible in sysfs.
Having more of them will just confuse the users, they would be searching
how they can connect the supply while there is no means to do so
except soldering to the tiny AXP pins.

hwmon makes more sense for output voltages of the AXP or temperature
of AXP chip itself, not so much for the input side if that side is
covered by power_supply devices (otherwise the information is being
duplicated and if so should only be via power_supply class, not
individual drivers).

 If you're using a distro, you might not have the kernel sources
 around, and digging through the in-system device tree isn't that
 straightforward if you don't know where to look.

If the dts is incomplete that's another issue.

  NB: I should hopefully get my battery supply driver ported this WE,
  ac-in/rtc are done, this WE. I'm going to default-off for them as well
  (note that for some extra details should be provided in dts).
 
 I'm guessing we won't be using the axp288 one?

In a first step I won't be using it.

There are a few reasons for that:
- axp288 is based on ACPI/platform to provide configuration information
  instead of dts
- it makes extensive use of OCV and registers that are possibly present
  on axp20x but undocumented there.

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.

Re: [linux-sunxi] [PATCH 6/8] ARM: dts: axp209: Add usb_power_supply child node to the ax209 node

2015-07-30 Thread Bruno Prémont 
Hi ChenYu,

On Fri, 31 Jul 2015 13:31:53 +0800 Chen-Yu Tsai wrote:
 Hi Hans,
 
 On Wed, Jun 10, 2015 at 5:37 AM, Hans de Goede hdego...@redhat.com wrote:
  Add a node representing the usb power supply part of the axp209 pmic, note
  that the usb power supply and the (to be added later) ac power supply will
  each have their own child-node, so that they can be separately specified
  as power-supply for other nodes using a power-supply property with a
  phandle pointing to the right axp209 child-node.
 
  Signed-off-by: Hans de Goede hdego...@redhat.com
  ---
   arch/arm/boot/dts/axp209.dtsi | 5 +
   1 file changed, 5 insertions(+)
 
  diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
  index 24c935c..051ab3b 100644
  --- a/arch/arm/boot/dts/axp209.dtsi
  +++ b/arch/arm/boot/dts/axp209.dtsi
  @@ -89,4 +89,9 @@
  regulator-name = ldo5;
  };
  };
  +
  +   usb_power_supply: usb_power_supply {
  +   compatible = x-powers,axp202-usb-power-supply;
  +   status = disabled;
 
 Is there any reason to have this disabled by default?
 AFAIK this is not something configurable in hardware,
 and the driver just gives readouts and status updates.

There are some devices that only have 'AC-IN' instead of usb/otg power
(set-top boxes) so having the devices tell what power sources they
have makes sense (otherwise those that have ac-in instead of otg would
have to disable usb_power_supply) and avoids confusion by explicitly
stating presence in device dts.

NB: I should hopefully get my battery supply driver ported this WE,
ac-in/rtc are done, this WE. I'm going to default-off for them as well
(note that for some extra details should be provided in dts).

Bruno

 ChenYu
 
  +   };
   };
  --
  2.3.6

-- 
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: [PATCH v3 4/4] power: Add an axp20x-usb-power driver

2015-06-27 Thread Bruno Prémont 
On Sat, 27 Jun 2015 14:28:40 Krzysztof Kozlowski wrote:
 W dniu 26.06.2015 o 19:59, Hans de Goede pisze:
  This adds a driver for the usb power_supply bits of the axp20x PMICs.
  
  I initially started writing my own driver, before coming aware of
  Bruno Prémont's excellent earlier RFC with a driver for this.
  
  My driver was lacking CURRENT_MAX and VOLTAGE_MIN support Bruno's
  drvier has, so I've copied the code for those from his driver.
  
  Note that the AC-power-supply and battery charger bits will need separate
  drivers. Each one needs its own devictree child-node so that other
  devicetree nodes can reference the right power-supply, and thus each one
  will get its own mfd-cell / platform_device and platform-driver.
  
  Cc: Bruno Prémont bonb...@linux-vserver.org
  Acked-by: Lee Jones lee.jo...@linaro.org
  Signed-off-by: Bruno Prémont bonb...@linux-vserver.org
  Signed-off-by: Hans de Goede hdego...@redhat.com
  ---
  Changes in v2:
  -Split out the dt-bindings documentation into a separate patch
  -Renamed axp20x_read_16bit to axp20x_read_variable_width
  -Use better local variable names inside axp20x_read_variable_width
  Changes in v3:
  -Add Bruno's S-o-b
 
 Hi,
 
 Two minor comments below, the driver itself looks good.
 
 
  ---
   drivers/power/Kconfig|   7 ++
   drivers/power/Makefile   |   1 +
   drivers/power/axp20x_usb_power.c | 243 
  +++
   include/linux/mfd/axp20x.h   |  24 
   4 files changed, 275 insertions(+)
   create mode 100644 drivers/power/axp20x_usb_power.c
  
  diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
  index 4091fb0..1fee60c 100644
  --- a/drivers/power/Kconfig
  +++ b/drivers/power/Kconfig
  @@ -439,6 +439,13 @@ config BATTERY_RT5033
The fuelgauge calculates and determines the battery state of charge
according to battery open circuit voltage.
   
  +config AXP20X_POWER
  +   tristate AXP20x power supply driver
  +   depends on MFD_AXP20X
  +   help
  + This driver provides support for the power supply features of
  + AXP20x PMIC.
  +
   source drivers/power/reset/Kconfig
   
   endif # POWER_SUPPLY
  diff --git a/drivers/power/Makefile b/drivers/power/Makefile
  index b7b0181..ae0f27d 100644
  --- a/drivers/power/Makefile
  +++ b/drivers/power/Makefile
  @@ -9,6 +9,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY)   += generic-adc-battery.o
   
   obj-$(CONFIG_PDA_POWER)+= pda_power.o
   obj-$(CONFIG_APM_POWER)+= apm_power.o
  +obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o
   obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
   obj-$(CONFIG_WM831X_BACKUP)+= wm831x_backup.o
   obj-$(CONFIG_WM831X_POWER) += wm831x_power.o
  diff --git a/drivers/power/axp20x_usb_power.c 
  b/drivers/power/axp20x_usb_power.c
  new file mode 100644
  index 000..09f388e
  --- /dev/null
  +++ b/drivers/power/axp20x_usb_power.c
  @@ -0,0 +1,243 @@
  +/*
  + * AXP20x PMIC USB power supply status driver
  + *
  + * Copyright (C) 2015 Hans de Goede hdego...@redhat.com
  + * Copyright (C) 2014 Bruno Prémont bonb...@linux-vserver.org
  + *
  + * This program is free software; you can redistribute it and/or modify it
  + * under  the terms of the GNU General  Public License as published by the
  + * Free Software Foundation;  either version 2 of the License, or (at your
  + * option) any later version.
  + */
  +
  +#include linux/device.h
  +#include linux/init.h
  +#include linux/interrupt.h
  +#include linux/kernel.h
  +#include linux/mfd/axp20x.h
  +#include linux/module.h
  +#include linux/of.h
  +#include linux/platform_device.h
  +#include linux/power_supply.h
  +#include linux/regmap.h
  +#include linux/slab.h
  +
  +#define DRVNAME axp20x-usb-power-supply
  +
  +#define AXP20X_PWR_STATUS_VBUS_PRESENT BIT(5)
  +#define AXP20X_PWR_STATUS_VBUS_USEDBIT(4)
  +
  +#define AXP20X_USB_STATUS_VBUS_VALID   BIT(2)
  +
  +#define AXP20X_VBUS_VHOLD_uV(b)(400 + (((b)  3)  7) * 
  10)
  +#define AXP20X_VBUS_CLIMIT_MASK3
  +#define AXP20X_VBUC_CLIMIT_900mA   0
  +#define AXP20X_VBUC_CLIMIT_500mA   1
  +#define AXP20X_VBUC_CLIMIT_100mA   2
  +#define AXP20X_VBUC_CLIMIT_NONE3
  +
  +#define AXP20X_ADC_EN1_VBUS_CURR   BIT(2)
  +#define AXP20X_ADC_EN1_VBUS_VOLT   BIT(3)
  +
  +#define AXP20X_VBUS_MON_VBUS_VALID BIT(3)
  +
  +struct axp20x_usb_power {
  +   struct regmap *regmap;
  +   struct power_supply *supply;
  +};
  +
  +static irqreturn_t axp20x_usb_power_irq(int irq, void *devid)
  +{
  +   struct axp20x_usb_power *power = devid;
  +
  +   power_supply_changed(power-supply);
  +
  +   return IRQ_HANDLED;
  +}
  +
  +static int axp20x_usb_power_get_property(struct power_supply *psy,
  +   enum power_supply_property psp, union power_supply_propval *val)
  +{
  +   struct axp20x_usb_power *power = power_supply_get_drvdata(psy);
  +   unsigned int input, v;
  +   int r;
 
 Here and in probe function

Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues

2015-02-18 Thread Bruno Prémont 
Hi Simo,

On Wed, 18 Feb 2015 07:15:22 +0200 Siarhei Siamashka wrote:
 On Wed, 18 Feb 2015 07:08:42 +0200 Siarhei Siamashka wrote:
  On Fri, 13 Feb 2015 09:04:48 -0800 (PST) Simo Xefil wrote:
  There are surely plenty of ways to clear the framebuffer. And you can
  also even make a copy of the old framebuffer data and restore it after
  the application has terminated. Everything is up to you. Or up to the
  developers of the framebuffer based applications.
  
   With an emulator, where I could need switch between games often, every 
   time 
   I quit the game, the image remains impressed and I cannot change it.
  
   I've no idea how to invent a way to force the refresh. If you have an 
   idea 
   I would try to investigate in that direction.
   I don't expect a finished solution (even it, in case, would be of course 
   appreciated). I'd try to find/try by myself, but have no idea where to 
   search.
   
   Any suggestion is really welcome :-)
  
  Does, for example, running cat /dev/zero  /dev/fb0 help?
 
 Or create a simple wrapper shell script, which might look like:
 
 #!/bin/sh
 
 dd if=/dev/fb0 of=/tmp/fbbackup.bin
 run-your-cool-game-or-emulator
 dd if=/tmp/fbbackup.bin of=/dev/fb0

If I remember correctly, in you application you can switching current VT
from TEXT mode into GRAPHICS mode so the kernel stops interfering with
the framebuffer and once you revert the VT to TEXT mode kernel will
just redraw the whole console, erasing what your application left
around.

If you want to have things operate properly in case of application
mis-behavior/crash you probably need a wrapper process to perform that
work and react to VT switches (STOP your application when leaving VT,
resume it when coming back).

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.

Re: [linux-sunxi] Reported battery percentage lower than it should be

2015-01-14 Thread Bruno Prémont 
On Tue, 13 January 2015 Dave McLaughlin davemclaughli...@gmail.com wrote:
 I am running Android sunxi-linux 3.4 and on boot up, with battery power
 only, I see the following in the debug output.
 
 [0.148] boot1 version : 2.0.0
 [0.149] script installed early ok
 [0.149] pmu type = 3
 [0.253] bat vol = 3894 mv
 
 
 This corresponds pretty much with what I am reading with a multi-meter
 across the battery temrinals. Battery is a 6600mA Li-Ion type.
 
 The issue is that once Android starts, it shows a low battery warning
 and a reading of around 13% when the actual reading should be around
 55%. The battery voltage with a meter is still  3800mV
 
 
 I/PowerUI ( 1826): updating low battery warning: level=13 [-1]
 
 
 If I plug in a charger it stays at the same reading and now shows charging.
 
 If I power off and then on again, it repeats this reading. If I apply
 external power via the charger, it boots up and shows the correct
 percentage 55%.
 
 Monitoring the battery voltage during the startup process sees only a
 few mV of drop as the loads switch in.
 
 It's always a lower percentage and dependent on the starting rate. For
 example, a higher 80% on the charger shows are around 30% when powered
 up on the battery.
 
 Looking into /sys/class/power_supply/battery/voltage_min_design the
 value is 3400 and in voltage_max_design it is 420
 
 The MIN value is not the same as I have in the FEX. That is 3300
 
 Is this a known issue with a fix? It's causing a major headache with
 the system running on battery power as the user thinks the battery
 needs recharging when in fact it could run for longer and the OS goes
 into shutdown when it gets too low. Plugging in USB and it reboots with
 over 50% left.

You should read AXP registers for both cases.

At least the code in sunxi-linux 3.4 does store some information about
the battery in there.
In addition to that, there are the OCV values in fex file that will also
influence the reported battery percentage.

As such it might be disagreement between 3.4 and android on how to
preserve battery status information in AXP registers. Probably using
battery so voltage drops enough will also trigger the percentage value
to be corrected.

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.

Re: [linux-sunxi] Re: Is it possible to select kernel on boot ?

2014-12-20 Thread Bruno Prémont 
Hi,

On Fri, 19 December 2014 nilsnu...@gmail.com wrote:
 I use lilo on x86/64 PC from 2002.
 Why it doesnt work on allwinner ? What is the problem ?
 
  I want try mainline kernel, is it possible to select kernel on boot ? 
  Something similar to lilo\grub.

Lilo has its core bootloader part written in x86 assembler and also
depends on BIOS interface to work. So it's not compatible with uboot
(nor EFI on PCs!).


You can select different kernels from uboot if you want. It will
not provide you with a nice graphical kernel selector but you can
load the kernel you want from uboot command line (similar to what
you would do in grub command line).
With proper uboot scripting you can e.g. select the kernel based on
status of GPIO lines (or pressed buttons).

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.

Re: [linux-sunxi] Cubietruck, gmac freezing TCP connections when at gigabit speed

2014-11-11 Thread Bruno Prémont 
On Sat, 08 November 2014 Bruno Prémont wrote:
 Since I have my Cubietruck, be it with 3.4 kernels or with mainline
 kernels I've been experiencing unstable TCP connections.
 
 The symptoms are stalling connections (usually SSH connections to the
 Cubietruck) that have nearly no chance at recovering.
 
 When I tell GMAC to only advertise up to 100Mbps speed the SSH
 sessions do no show above symptoms anymore.

A thread seen on LKML and ARM/NetDev that might also point to the
cause of this trouble:
  stmmac: potential circular locking dependency
  http://www.spinics.net/lists/arm-kernel/msg374256.html

Bruno


 If it's important, my setup is:
 
   100Mbps1Gbps
 Laptop  --- Switch - Cubietruck
 
 
 
 Any idea what the cause might be and how to fix it?
 
 
 When running wireshark on the laptop there is only silence when the
 SSH session is stalled. Just prior to stalling Wireshark mentions
 one missed packet (previous segment not captured) and no more packets
 after this.
 
 I've not yet had the opportunity to perform a tcpdump capture on the
 Cubietruck side (not installed yet).


signature.asc
Description: PGP signature

Re: [linux-sunxi] Cubietruck, u-boot-2014.10, SATA drive power cut during boot

2014-11-10 Thread Bruno Prémont 
Hi Hans,

On Mon, 10 November 2014 Hans de Goede wrote:
 On 11/08/2014 08:34 PM, Bruno Prémont wrote:
  Since updating my cubietruck to u-boot-2014.10 the SATA hard drive
  connected to it performs emergency head parking around the time
  uboot hands over control to kernel (or kernel is booting).
  
  The same issue also exists during reboot.
 
 Right, during reboot there unfortunately is nothing we can do to avoid this
 afaik. Although there is one thing which you could try, edit:
 
 linux/drivers/ata/libahci_platform.c
 
 Around line 500 you should find the following in there:
 
 static void ahci_host_stop(struct ata_host *host)
 {
 struct ahci_host_priv *hpriv = host-private_data;
 
 ahci_platform_disable_resources(hpriv);
 }

 Try commenting out the ahci_platform_disable_resources() call, I'm not sure
 if this gets called at reboot / shutdown, but if it does then it could be
 the culprit, although I think the real problem is that the SoC at reset
 tri-states all its gpio-s.

I don't care too much about the linux shutdown/reboot as the patch I included
does a good job there. (also useful on my x86 Acer TM660 laptop!)

I might retry getting it upstream (a few years ago I sent one with DMI match
for just my laptop, but it was not applied).
With a few devices affected, and that cross-platform, applying it would
make some more sense.

  Looking at the changes in u-boot-2014.10 SATA support has been added.
  
  It looks like u-boot is setting up SATA then kernel is doing the same,
  killing SATA power while reconfiguring the AHCI or SATApower GPIO.
 
 Hmm, good one, I think we can avoid this from happening with the following
 patch:
 
 diff --git a/arch/arm/boot/dts/sunxi-common-regulators.dtsi 
 b/arch/arm/boot/dts/sunxi-common-regulators.dtsi
 index c9c5b10..a950671 100644
 --- a/arch/arm/boot/dts/sunxi-common-regulators.dtsi
 +++ b/arch/arm/boot/dts/sunxi-common-regulators.dtsi
 @@ -44,6 +44,7 @@
   regulator-name = ahci-5v;
   regulator-min-microvolt = 500;
   regulator-max-microvolt = 500;
 + regulator-boot-on;
   enable-active-high;
   gpio = pio 1 8 0;
   status = disabled;
 
 Can you try applying this, then do make dtbs in your kernel sources
 dir and copy the new cubietruck dtb file to your sdcard, and give things
 a spin ?

Works like a charm!

Does it have any impact when:
- u-boot does not support SATA/AHCI
- u-boot does not initialize SATA/AHCI
- there is no SATA drive connected?


Reported-and-Tested-by: Bruno Prémont bonb...@linux-vserver.org


Thanks,
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 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-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 2/4] mfd: AXP20x: Add power supply sub-driver

2014-11-04 Thread Bruno Prémont 
On Thu, 23 October 2014 Edgar Toernig fro...@gmx.de wrote:
  +   getnstimeofday(ts);
  +   /* only query hardware if our data is stale */
  +   spin_lock(devdata-lock);
  +   if (!init  !(ts.tv_sec  devdata-next_check.tv_sec ||
  +  ts.tv_nsec  devdata-next_check.tv_sec)) {
  +   spin_unlock(devdata-lock);
  +   return 0;
  +   }
  +   spin_unlock(devdata-lock);
 
 That time comparison is broken - it compares nsec with sec and
 doesn't check that secs are equal before comparing the nsecs.
 There's timespec_compare which gets it right.

Oops, yeah, going to switch to timespec_compare().
Thanks for spotting!

 Btw, you are aware that the timeofday is a user adjustable
 value?  If I ever turn back system time I won't get power
 data any more until the old (future) time is reached.

Huh, no, I didn't consider that.

 Wouldn't it be easier to simply use jiffies and limit the
 poll rate to one second or so?

I considered limiting to some arbitrary polling rate though think
it's better to give users the option to query values more often,
up to the rate at which the value are measured by AXP.
As the AXP's measurement rate is configurable (not exposed by
driver) it's better to base on that setting instead of having
to care at the time of exposing the configuration knob.

Thus jiffies seem to be a bit at their limit. Is using ktime better?


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-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] [RFC Patch 2/4] mfd: AXP20x: Add power supply sub-driver

2014-10-21 Thread Bruno Prémont 
  = IORESOURCE_IRQ,
+   }, {
+   .name   = POWER_LOW_CRIT,
+   .start  = AXP20X_IRQ_LOW_PWR_LVL2,
+   .end= AXP20X_IRQ_LOW_PWR_LVL2,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
 static const struct regmap_config axp20x_regmap_config = {
.reg_bits   = 8,
.val_bits   = 8,
.wr_table   = axp20x_writeable_table,
.volatile_table = axp20x_volatile_table,
-   .max_register   = AXP20X_FG_RES,
+   .max_register   = AXP20X_OCV(15),
.cache_type = REGCACHE_RBTREE,
 };
 
@@ -158,6 +258,10 @@ static struct mfd_cell axp20x_cells[] = {
.name   = axp20x-regulator,
.parent_supplies= axp20x_supplies,
.num_parent_supplies= ARRAY_SIZE(axp20x_supplies),
+   }, {
+   .name   = axp20x-power,
+   .num_resources  = ARRAY_SIZE(axp20x_power_resources),
+   .resources  = axp20x_power_resources,
},
 };
 
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 73cfcdf..209d677 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -396,6 +396,15 @@ config BATTERY_GOLDFISH
  Say Y to enable support for the battery and AC power in the
  Goldfish emulator.
 
+config AXP20X_POWER
+   tristate AXP20x power supply driver
+   depends on MFD_AXP20X
+   help
+ This driver provides support for the power supply features of
+ AXP20x PMIC.
+ Included features are: AC-power, USB-power, Battery charger
+ (RTC backup-battery and Lithium main bettery).
+
 source drivers/power/reset/Kconfig
 
 endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index dfa8942..ab2324f 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY)   += generic-adc-battery.o
 
 obj-$(CONFIG_PDA_POWER)+= pda_power.o
 obj-$(CONFIG_APM_POWER)+= apm_power.o
+obj-$(CONFIG_AXP20X_POWER) += axp20x_power.o
 obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
 obj-$(CONFIG_WM831X_BACKUP)+= wm831x_backup.o
 obj-$(CONFIG_WM831X_POWER) += wm831x_power.o
diff --git a/drivers/power/axp20x_power.c b/drivers/power/axp20x_power.c
new file mode 100644
index 000..9d6b8bc
--- /dev/null
+++ b/drivers/power/axp20x_power.c
@@ -0,0 +1,1530 @@
+/*
+ * AC power input driver for X-Powers AXP20x PMICs
+ *
+ * Copyright 2014 Bruno Prémont bonb...@linux-vserver.org
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/err.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/power_supply.h
+#include linux/regmap.h
+#include linux/slab.h
+#include linux/time.h
+#include linux/mfd/axp20x.h
+
+struct axp20x_power {
+   struct axp20x_dev *axp20x;
+   /* RTC / Backup battery */
+   struct power_supply backup;
+   char backup_name[24];
+   /* ACIN power supply */
+   struct power_supply ac;
+   char ac_name[24];
+   /* VBUS/OTG power supply */
+   struct power_supply vbus;
+   char vbus_name[24];
+   /* Battery charger */
+   struct power_supply battery;
+   char battery_name[24];
+   char *battery_supplies[2];
+   /* AXP state tracking */
+   struct work_struct work;
+   spinlock_t lock;
+   struct timespec next_check;
+   uint8_t status1;
+   uint8_t status2;
+   uint8_t vbusmgt;
+   int vvbus;
+   int ivbus;
+   int vac;
+   int iac;
+   int vbatt;
+   int ibatt;
+   int pbatt;
+   int tbatt;
+   int tbatt_min;
+   int tbatt_max;
+   int batt_percent;
+   int batt_capacity;
+   int batt_health;
+   int batt_user_imax;
+};
+
+/* Fields of AXP20X_PWR_INPUT_STATUS */
+#define AXP20X_PWR_STATUS_AC_PRESENT (1  7)
+#define AXP20X_PWR_STATUS_AC_AVAILABLE   (1  6)
+#define AXP20X_PWR_STATUS_VBUS_PRESENT   (1  5)
+#define AXP20X_PWR_STATUS_VBUS_AVAILABLE (1  4)
+#define AXP20X_PWR_STATUS_VBUS_VHOLD (1  3)
+#define AXP20X_PWR_STATUS_BAT_CHARGING   (1  2)
+#define AXP20X_PWR_STATUS_AC_VBUS_SHORT  (1  1)
+#define AXP20X_PWR_STATUS_AC_VBUS_SEL(1  0)
+
+/* Fields of AXP20X_PWR_OP_MODE */
+#define AXP20X_PWR_OP_OVERTEMP (1  7)
+#define AXP20X_PWR_OP_CHARGING (1  6)
+#define AXP20X_PWR_OP_BATT_PRESENT (1  5)
+#define AXP20X_PWR_OP_BATT_ACTIVATED   (1  3

[linux-sunxi] [RFC Patch 0/4] mfd: AXP20x: Add power supply sub-driver

2014-10-21 Thread Bruno Prémont 
This series adds a power-supply driver to cover backup/RTC battery
charger, VBUS/OTG power in, AC power in and battery charger features
supported by AXP20x PMIC.

The DT bindings documentation patch depends on the following patch
from Carlo Caione:
  http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/267604.html

Note, the reporting of some of the power supply interrupts might need
to be changed to dev_debug instead of dev_info.

For the DT bindings names they might need prefixing in which case
the corresponding prefix declaration patch from Carlo would be needed
as well:
  http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/267606.html


Changes since initial posting on linux-sunxi:
 - A few typo fixes in strings/comments
 - Patch splitting

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] [RFC Patch 4/4] mfd: AXP20x: Add backup battery DTS entry for Cubietruck

2014-10-21 Thread Bruno Prémont 

---
 arch/arm/boot/dts/sun7i-a20-cubietruck.dts   |4 +
 1 files changed, 2 insertions(+), 0 deletion(-)

diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts 
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index a6c1a3c..efb65fb 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -125,6 +125,8 @@
 
interrupt-controller;
#interrupt-cells = 1;
+
+   backup = 300 200;
};
};
 
-- 
2.0.4

-- 
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.

Re: [linux-sunxi] [PATCHv2 3.4 4/4] sunxi: axp20x: Calculate moving average for ACIN voltage/current/power

2014-10-12 Thread Bruno Prémont 
Hey Olliver,

For mainline I wrote a driver for the power supply part some time ago
and posted it here (it's referenced from the mainlining page on the WIKI).

It covers ACIN, BATTERY and VBUS power supplies with both current and
voltage measurements. For battery it could also provide temperature
information though converting the voltage reading into a temperature
is still missing (I have no board with battery temperature sensor)

I will review which parts it depends on already hit mainline since
then and post an updated series, probably sometime next weekend.

Bruno

On Sun, 12 October 2014 Olliver Schinagl oliver+l...@schinagl.nl wrote:
 Hey Siarhei,
 
 this driver only works on 3.4 right? I think we have the axp20x driver 
 in mainline too do we not?
 
 Anyway, I think in a few weeks time from now, I will run some 
 temperature calibration tests on various Lime's and will generate a lot 
 of temperature data. It won't be a huge problem to also generate voltage 
 (fixed at 5.00V) and current data based on different workloads (gpu, cpu 
 (no vpu)) if that is helpfull at all.
 
 Let me know what you think.
 
 Olliver
 
 On 04/01/2014 08:36 PM, Siarhei Siamashka wrote:
  As long as somebody is regularly accessing axp20x hwmon sysfs entries,
  maintain a work queue for 25Hz periodic sampling of ACIN voltage/current
  information. And calculate moving average using this data. This periodic
  sampling stops after ~1 minute from the last access to axp20x hwmon sysfs.
 
  Comparison of the current draw (in mA) for different workloads, measured
  by the axp20x hwmon averaged stats (on the left side) and with a multimeter
  (on the right side). The following sunxi based hardware has been tested
  (without anything extra connected to USB/SATA):
 
  Olinuxino-Lime (Allwinner A10):
  300  315
  555  590
  990 1060
 
  Cubietruck (Allwinner A20):
  215  240
  310  345
  730  800
 
  Cubieboard2 (Allwinner A20):
   80  245
  180  415
  325  610
  490  820
 
  Mele A2000 (Allwinner A10):
  180  450
  280  560
  450  770
 
  AXP209 on Olinuxino-Lime and Cubietruck reports reasonably accurate
  results. But not so much for the other devices.
 
  v2: The decision whether to run periodic sampling is now fully
   automatic. No configuration is needed. And no parasitic background
   activity is expected when nobody is interested in axp20x hwmon
   sysfs data.
 
  Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
  ---
drivers/power/axp_power/axp-mfd.c   |  4 +++
drivers/power/axp_power/axp20-mfd.h | 68 
  +
include/linux/mfd/axp-mfd.h |  3 ++
3 files changed, 69 insertions(+), 6 deletions(-)
 
  diff --git a/drivers/power/axp_power/axp-mfd.c 
  b/drivers/power/axp_power/axp-mfd.c
  index cfa894a..6fd1264 100644
  --- a/drivers/power/axp_power/axp-mfd.c
  +++ b/drivers/power/axp_power/axp-mfd.c
  @@ -365,6 +365,10 @@ static int __devexit axp_mfd_remove(struct i2c_client 
  *client)
 
#ifdef CONFIG_AXP_HWMON
  if (chip-itm_enabled == 1) {
  +   cancel_delayed_work(axp_hwmon_work);
  +   flush_workqueue(wq);
  +   destroy_workqueue(wq);
  +
  hwmon_device_unregister(chip-hwmon_dev);
  sysfs_remove_group(client-dev.kobj, axp20_group);
  }
  diff --git a/drivers/power/axp_power/axp20-mfd.h 
  b/drivers/power/axp_power/axp20-mfd.h
  index 4244d49..fe7aeb1 100644
  --- a/drivers/power/axp_power/axp20-mfd.h
  +++ b/drivers/power/axp_power/axp20-mfd.h
  @@ -28,13 +28,14 @@
#include linux/hwmon.h
#include linux/err.h
 
  -static struct axp_mfd_chip *axp20_update_device(struct device *dev);
  +static struct
  +axp_mfd_chip *axp20_update_device(struct device *dev, int from_wq);
 
static ssize_t
show_temp(struct device *dev, struct device_attribute *devattr, char *buf)
{
  struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
  -   struct axp_mfd_chip *data = axp20_update_device(dev);
  +   struct axp_mfd_chip *data = axp20_update_device(dev, 0);
  if (attr-index == 1)
  return sprintf(buf, 264800\n);
  if (attr-index == 2)
  @@ -49,9 +50,11 @@ show_acin_voltage(struct device *dev, struct 
  device_attribute *devattr,
char *buf)
{
  struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
  -   struct axp_mfd_chip *data = axp20_update_device(dev);
  +   struct axp_mfd_chip *data = axp20_update_device(dev, 0);
  if (attr-index == 3)
  return sprintf(buf, ACIN voltage\n);
  +   if (attr-index == 4)
  +   return sprintf(buf, %d\n, data-acin_avg_voltage / 64);
  return sprintf(buf, %d\n, data-acin_voltage);
}
 
  @@ -60,9 +63,11 @@ show_acin_current(struct device *dev,

[linux-sunxi] Re: [Patch RFC] mfd: AXP20x: add power_supply driver

2014-10-03 Thread Bruno Prémont 
Hello,

On Fri, 3 Oct 2014 04:55:22 -0700 (PDT) Markus Rathgeb wrote:
 Thank you for your work!
 
 Is there a git repository the changes could be found (to simplify merging / 
 cherry-picking)?
 Is there some progress to get that mainline?

I've been waiting for some feed-back from sunxi community and been
otherwise busy.
Starting next weekend I may be able to get enough time to assemble a
new round and CC mainline mailing lists.
I don't have a corresponding (public) git tree though.

 Is there some way to enable RTC battery charging for the mainline 3.17?
 Using the 3.4 kernel we could use i2cset, is there something similar, we 
 could use till the changes are merged?
 i2cset -f sunxi-i2c.0 0x34 0x35 0x82

It seems the default state of backup battery charging is enabled, at
least with the uboot version I'm using on my cubietruck (would have to
check which one exactly it is though).
However I have the impression that leaving the backup battery
charging on power-off causes the backup battery to drain quickly.

i2cset should still work even with 3.17, maybe with the need to point
it to proper /dev/i2c* device.

 Best regards,
 Markus

Best regards,
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.

Re: [linux-sunxi] Battery charge status not consistent

2014-09-20 Thread Bruno Prémont 
On Fri, 19 September 2014 Dave McLaughlin davemclaughli...@gmail.com wrote:
 With an A20 board I have found that if I power up with external DC 
 connected, the battery shows the correct charge percentage. If I run on 
 batter and make sure it never sleeps (through the app I am developing) it 
 discharges as expected.
 
 If I disconnect DC and run on the battery and *put it into standby* with 
 the power button and wake it up again with the power button it shows the 
 correct battery charge. This is very repeatable.
 
 If I power it off and then power up only on battery, the battery state is 
 wrong. My tests today were showing it was 78% before I powered off (after 
 disconnecting the external DC power). After I powered it up again it was 
 showing 18%. 
 
 I put it into standby with the power button and then bring it back up, the 
 charge now showed 78%. If I let it sleep again and power up, it again shows 
 a different reading. This time it was 32%.
 
 If I power off and connect external DC and power it back on, the charge 
 indication is again correct.
 
 I am not getting consistent readings when running on battery only and I 
 have checked the FEX settings and I am pretty much sure they are correct 
 and this is what I am using with a 3.7V 6600mAh battery.
 
 Any ideas?

What are the battery voltage readings for all those battery charge % cases?

From your reporting with FEX I assume you are using 3.4 kernel or
Android/Allwinner kernel (which one?).

As far as I understood the whole battery charge monitoring the % is provided
by AXP chip itself an based on the pmu_bat_paraXX settings.

The remaining capacity though is calculated by the power_supply driver.

Bruno

 [pmu_para]
 pmu_used = 1
 pmu_twi_addr = 52
 pmu_twi_id = 0
 pmu_irq_id = 32
 pmu_battery_rdc = 60
 pmu_battery_cap = 6600
 pmu_init_chgcur = 300
 pmu_earlysuspend_chgcur = 600
 pmu_suspend_chgcur = 1000
 pmu_resume_chgcur = 300
 pmu_shutdown_chgcur = 1000
 pmu_init_chgvol = 4200
 pmu_init_chgend_rate = 15
 pmu_init_chg_enabled = 1
 pmu_init_adc_freq = 100
 pmu_init_adc_freqc = 100
 pmu_init_chg_pretime = 50
 pmu_init_chg_csttime = 720
 pmu_bat_para1 = 0
 pmu_bat_para2 = 0
 pmu_bat_para3 = 0
 pmu_bat_para4 = 0
 pmu_bat_para5 = 5
 pmu_bat_para6 = 11
 pmu_bat_para7 = 13
 pmu_bat_para8 = 15
 pmu_bat_para9 = 19
 pmu_bat_para10 = 32
 pmu_bat_para11 = 50
 pmu_bat_para12 = 58
 pmu_bat_para13 = 71
 pmu_bat_para14 = 81
 pmu_bat_para15 = 89
 pmu_bat_para16 = 100
 pmu_usbvol_limit = 1
 pmu_usbcur_limit = 0
 pmu_usbvol = 4000
 pmu_usbcur = 0
 pmu_usbvol_pc = 4400
 pmu_usbcur_pc = 0
 pmu_pwroff_vol = 3300
 pmu_pwron_vol = 2900
 pmu_pekoff_time = 6000
 pmu_pekoff_en = 1
 pmu_peklong_time = 1500
 pmu_pekon_time = 1000
 pmu_pwrok_time = 64
 pmu_pwrnoe_time = 2000
 pmu_intotp_en = 1
 pmu_used2 = 0
 pmu_adpdet = port:PH020defaultdefaultdefault
 pmu_init_chgcur2 = 400
 pmu_earlysuspend_chgcur2 = 600
 pmu_suspend_chgcur2 = 1200
 pmu_resume_chgcur2 = 400
 pmu_shutdown_chgcur2 = 1200
 pmu_suspendpwroff_vol = 3300
 pmu_batdeten = 1
 
 

-- 
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.

Re: [linux-sunxi] Battery charge status not consistent

2014-09-20 Thread Bruno Prémont 
Hi Dave,

On Sat, 20 September 2014 Dave McLaughlin davemclaughli...@gmail.com wrote:
 The battery voltages I assume are set internally to the AXP209 as I don't 
 see any way to set these. I did find a listing for these.

On AXP209 you can just set the target charge voltage for the battery.

What charging voltage is applied depends on the charge current.

 Yes, this is the Android Linux 3.4 kernel.
 
 When I get the likes of 18% showing on the Android status bar and check the 
 actual voltage of the battery it reads much higher than what I expect to 
 get with the DC power applied at power up.

The LI-ION batteries should have a voltage ranging between 3.3V (nearly empty)
and 4.2V (full).

The battery voltage should not be influenced by the presence of DC power
(except for charging versus discharging or unused). But see below.

The system power voltage can be different from all input voltages as the AXP
does voltage conversion.

 I checked dmesg and I saw that the prev reading was 78% and then this was 
 updated to 32% when a voltage change notification was received. I need to 
 track down where this lower value is coming from. 

Does it happen for each suspend oder just sporadically? If sporadically it
might be a race condition where some AXP data got read before suspend, the
rest after resume - ending up with incoherent data and maybe some 16bit words
read half before suspend and half after resume.
Just a wild guess without looking at the code.

 I think I will leave the system ON to drain the battery and I will record 
 the battery voltage as it does so and see how this compares.
 
 If indeed the percentage value should be as per the pmu_bat_paraXX setting, 
 it still doesn't explain why powering up on battery gives such a low ready 
 than when on DC power.

How fresh is your battery?
The value of pmu_battery_rdc (represents battery internal resistance) might
also influence the behavior. Current draw on the battery may very well
influence the readings. If the (in-rush) drawn current is high battery may
not have enough time to recover and thus presents a lower voltage for one of
the first readings by AXP.

Those pmu_bat_para* values are used under the name of OCV (which I understand
as open-circuit-voltage in their context).


Bruno



 Dave...
 
 On Saturday, 20 September 2014 16:09:35 UTC+7, Bruno Prémont wrote:
 
  What are the battery voltage readings for all those battery charge % 
  cases? 
 
  From your reporting with FEX I assume you are using 3.4 kernel or 
  Android/Allwinner kernel (which one?). 
 
  As far as I understood the whole battery charge monitoring the % is 
  provided 
  by AXP chip itself an based on the pmu_bat_paraXX settings. 
 
  The remaining capacity though is calculated by the power_supply driver. 
 
  Bruno 
 
   [pmu_para] 
   pmu_used = 1 
   pmu_twi_addr = 52 
   pmu_twi_id = 0 
   pmu_irq_id = 32 
   pmu_battery_rdc = 60 
   pmu_battery_cap = 6600 
   pmu_init_chgcur = 300 
   pmu_earlysuspend_chgcur = 600 
   pmu_suspend_chgcur = 1000 
   pmu_resume_chgcur = 300 
   pmu_shutdown_chgcur = 1000 
   pmu_init_chgvol = 4200 
   pmu_init_chgend_rate = 15 
   pmu_init_chg_enabled = 1 
   pmu_init_adc_freq = 100 
   pmu_init_adc_freqc = 100 
   pmu_init_chg_pretime = 50 
   pmu_init_chg_csttime = 720 
   pmu_bat_para1 = 0 
   pmu_bat_para2 = 0 
   pmu_bat_para3 = 0 
   pmu_bat_para4 = 0 
   pmu_bat_para5 = 5 
   pmu_bat_para6 = 11 
   pmu_bat_para7 = 13 
   pmu_bat_para8 = 15 
   pmu_bat_para9 = 19 
   pmu_bat_para10 = 32 
   pmu_bat_para11 = 50 
   pmu_bat_para12 = 58 
   pmu_bat_para13 = 71 
   pmu_bat_para14 = 81 
   pmu_bat_para15 = 89 
   pmu_bat_para16 = 100 
   pmu_usbvol_limit = 1 
   pmu_usbcur_limit = 0 
   pmu_usbvol = 4000 
   pmu_usbcur = 0 
   pmu_usbvol_pc = 4400 
   pmu_usbcur_pc = 0 
   pmu_pwroff_vol = 3300 
   pmu_pwron_vol = 2900 
   pmu_pekoff_time = 6000 
   pmu_pekoff_en = 1 
   pmu_peklong_time = 1500 
   pmu_pekon_time = 1000 
   pmu_pwrok_time = 64 
   pmu_pwrnoe_time = 2000 
   pmu_intotp_en = 1 
   pmu_used2 = 0 
   pmu_adpdet = port:PH020defaultdefaultdefault 
   pmu_init_chgcur2 = 400 
   pmu_earlysuspend_chgcur2 = 600 
   pmu_suspend_chgcur2 = 1200 
   pmu_resume_chgcur2 = 400 
   pmu_shutdown_chgcur2 = 1200 
   pmu_suspendpwroff_vol = 3300 
   pmu_batdeten = 1 
   
   
 
 

-- 
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.

Re: [linux-sunxi] [Tool] AXP20x register decoding utility

2014-08-05 Thread Bruno Prémont 
On Mon, 04 August 2014 jonsm...@gmail.com jonsm...@gmail.com wrote:
 On Mon, Aug 4, 2014 at 4:29 PM, jonsm...@gmail.com jonsm...@gmail.com wrote:
  Would it make sense to add this to the device driver and the put this
  output in debugfs?
 
 Some of this should probably always be present in sysfs

The register values themselves are in debugfs via regmap infrastructure.

Providing a decoded dump in debugfs is probably asking too much
and better suited in a userspace decoding application (maybe some
hwinfo package?).
Important higher-level information is being exported via respective
subdrivers (e.g. pek input driver, power_supply drivers, regulators, ...).

Bruno


  On Mon, Aug 4, 2014 at 4:20 PM, Bruno Prémont bonb...@linux-vserver.org 
  wrote:
  Hi,
 
  Attached code is a little program to decode AXP20x registers and present
  their values in a readable way.
 
  By default it looks for AXP20x mfd driver's regmap in sysfs.
 
  Not all registers are being decoded yet (missing are e.g. GPIOs).
  Some undocumented registers are mentioned (e.g. OCV values, RDC).
 
  A nice bonus would be to add support for reading the regs directly
  via i2c (in order to easily display register status under 3.4 kernels).
 
  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.
 
 
 
  --
  Jon Smirl
  jonsm...@gmail.com
 
 
 

-- 
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] [Tool] AXP20x register decoding utility

2014-08-04 Thread Bruno Prémont 
Hi,

Attached code is a little program to decode AXP20x registers and present
their values in a readable way.

By default it looks for AXP20x mfd driver's regmap in sysfs.

Not all registers are being decoded yet (missing are e.g. GPIOs).
Some undocumented registers are mentioned (e.g. OCV values, RDC).

A nice bonus would be to add support for reading the regs directly
via i2c (in order to easily display register status under 3.4 kernels).

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.
/*
 * AXP20x register decoding utility
 *
 * Copyright 2014 Bruno Prémont bonb...@linux-vserver.org
 *
 * This file is subject to the terms and conditions of the GNU General
 * Public License. See the file COPYING in the main directory of this
 * archive for more details.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 */
#include stdlib.h
#include stdio.h
#include fcntl.h
#include unistd.h
#include errno.h
#include string.h
#include sys/types.h
#include dirent.h
#include stdint.h
#include sys/stat.h

struct {
	const char *b0;
	const char *b1;
	const char *b2;
	const char *b3;
	const char *b4;
	const char *b5;
	const char *b6;
	const char *b7;
	const char *bR;
	const char *rst;
	const char *inv;
	const char *bld;
	const char *h;
	const char *err;
} c = {
	.b0 = \033[48;5;1;30m,
	.b1 = \033[48;5;2;30m,
	.b2 = \033[48;5;3;30m,
	.b3 = \033[48;5;4;30m,
	.b4 = \033[48;5;5;30m,
	.b5 = \033[48;5;6;30m,
	.b6 = \033[48;5;10;30m,
	.b7 = \033[48;5;12;30m,
	.bR = \033[48;5;8;30m,
	.rst = \033[0m,
	.inv = \033[7m,
	.bld = \033[1m,
	.h   = \033[34m,
	.err = \033[31m,
};
#define MASK_COLOR_0 0
#define MASK_COLOR_1 1
#define MASK_COLOR_2 2
#define MASK_COLOR_3 3
#define MASK_COLOR_4 4
#define MASK_COLOR_5 5
#define MASK_COLOR_6 6
#define MASK_COLOR_7 7
#define MASK_COLOR_R 8
#define MASK_COLOR(mc) ((const char *)(((void **)c.b0)[mc]))

struct mask_info {
	uint8_t mask;
	uint8_t color;
	const char *name;
	void (*print)(uint8_t reg, const uint8_t *values, const struct mask_info *mi);
	const char **data;
};

void print_reg(uint8_t reg, const char *name, const uint8_t *values, const struct mask_info *masks) {
	int i, j;
	for (i = 7; i = 0; i--)
		if (!masks)
			printf(%s%d, c.bR, (values[reg]  (1  i)) ? 1 : 0);
		else for (j = 0; j  8  masks[j].mask; j++)
			if (masks[j].mask  (1  i))
printf(%s%d, MASK_COLOR(masks[j].color), (values[reg]  (1  i)) ? 1 : 0);
	printf(%s%s 0x%02hhx%s @ 0x%02hhx %s%s%s\n, c.inv, c.bR, values[reg], c.rst, reg, c.bld, name, c.rst);
	if (!masks)
		return;
	for (j = 0; j  8  masks[j].mask; j++) {
		if (!masks[j].name)
			continue;
		printf(%s%s, MASK_COLOR(masks[j].color), c.inv);
		for (i = 7; i = 0; i--)
			if (masks[j].mask  (1  i))
printf(%d, (values[reg]  (1  i)) ? 1 : 0);
			else
printf( );
		if (masks[j].print) {
			printf(%s   %s: , c.rst, masks[j].name);
			masks[j].print(reg, values, masks[j]);
			printf(\n);
		} else
			printf(%s   %s\n, c.rst, masks[j].name);
	}
}

void print_reg_bool(uint8_t reg, const uint8_t *values, const struct mask_info *mi) {
	if (values[reg]  mi-mask)
		printf(%s, mi-data ? mi-data[1] : ON);
	else
		printf(%s, mi-data ? mi-data[0] : off);
}
void print_reg_23(uint8_t reg, const uint8_t *values, const struct mask_info *mi) {
	printf(%dmV, 700 + (values[reg]  mi-mask) * 25);
}
void print_reg_28a(uint8_t reg, const uint8_t *values, const struct mask_info *mi) {
	printf(%dmV, 1800 + ((values[reg]  mi-mask)  4) * 100);
}
void print_reg_28b(uint8_t reg, const uint8_t *values, const struct mask_info *mi) {
	const char *labels[] = { 1.25, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 2.0, 2.5, 2.7, 2.8, 3.0, 3.1, 3.2, 3.3 };
	printf(%sV, labels[values[reg]  mi-mask]);
}
void print_reg_30a(uint8_t reg, const uint8_t *values, const struct mask_info *mi) {
	printf(%dmV, 4000 + ((values[reg]  mi-mask)  3) * 100);
}
void print_reg_30b(uint8_t reg, const uint8_t *values, const struct mask_info *mi) {
	const char *labels[] = { 900mA, 500mA, 100mA, unlimited };
	printf(%s, labels[values[reg]  mi-mask]);
}
void print_reg_31(uint8_t reg, const uint8_t *values, const struct mask_info *mi) {
	printf(%dmV, 2600 + (values[reg]  mi-mask) * 100);
}
void print_reg_32a(uint8_t reg, const uint8_t *values, const struct mask_info *mi) {
	const char *labels[] = { high resistance, 25%, 1Hz flicker, 25%, 4Hz flicker, Low level output };
	printf(%s, labels[(values[reg]  mi-mask)  4]);
}
void print_reg_32b(uint8_t reg, const uint8_t *values, const struct mask_info *mi) {
	const char *labels[] = { 128ms, 1s, 2s, 3s };
	printf(%s, labels[values[reg]  mi-mask]);
}
void

[linux-sunxi] [Patch RFC] mfd: AXP20x: add power_supply driver

2014-08-04 Thread Bruno Prémont 
  = AXP20X_IRQ_BATT_TEMP_HIGH,
+   .end= AXP20X_IRQ_BATT_TEMP_HIGH,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = BATT_COLD,
+   .start  = AXP20X_IRQ_BATT_TEMP_LOW,
+   .end= AXP20X_IRQ_BATT_TEMP_LOW,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = BATT_CHG_CURR_LOW,
+   .start  = AXP20X_IRQ_CHARG_I_LOW,
+   .end= AXP20X_IRQ_CHARG_I_LOW,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = POWER_LOW_WARN,
+   .start  = AXP20X_IRQ_LOW_PWR_LVL1,
+   .end= AXP20X_IRQ_LOW_PWR_LVL1,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = POWER_LOW_CRIT,
+   .start  = AXP20X_IRQ_LOW_PWR_LVL2,
+   .end= AXP20X_IRQ_LOW_PWR_LVL2,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
 static const struct regmap_config axp20x_regmap_config = {
.reg_bits   = 8,
.val_bits   = 8,
.wr_table   = axp20x_writeable_table,
.volatile_table = axp20x_volatile_table,
-   .max_register   = AXP20X_FG_RES,
+   .max_register   = AXP20X_OCV(15),
.cache_type = REGCACHE_RBTREE,
 };
 
@@ -158,6 +258,10 @@ static struct mfd_cell axp20x_cells[] = {
.name   = axp20x-regulator,
.parent_supplies= axp20x_supplies,
.num_parent_supplies= ARRAY_SIZE(axp20x_supplies),
+   }, {
+   .name   = axp20x-power,
+   .num_resources  = ARRAY_SIZE(axp20x_power_resources),
+   .resources  = axp20x_power_resources,
},
 };
 
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index ba69751..e158431 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -389,6 +389,15 @@ config BATTERY_GOLDFISH
  Say Y to enable support for the battery and AC power in the
  Goldfish emulator.
 
+config AXP20X_POWER
+   tristate AXP20x power supply driver
+   depends on MFD_AXP20X
+   help
+ This driver provides support for the power supply features of
+ APX20x PMIC.
+ Included features are: AC-power, USB-power, Battery charger
+ (RTC backup-battery and Lithium main bettery).
+
 source drivers/power/reset/Kconfig
 
 endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index ee54a3e..914c3fc 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY)   += generic-adc-battery.o
 
 obj-$(CONFIG_PDA_POWER)+= pda_power.o
 obj-$(CONFIG_APM_POWER)+= apm_power.o
+obj-$(CONFIG_AXP20X_POWER) += axp20x_power.o
 obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
 obj-$(CONFIG_WM831X_BACKUP)+= wm831x_backup.o
 obj-$(CONFIG_WM831X_POWER) += wm831x_power.o
diff --git a/drivers/power/axp20x_power.c b/drivers/power/axp20x_power.c
new file mode 100644
index 000..9d6b8bc
--- /dev/null
+++ b/drivers/power/axp20x_power.c
@@ -0,0 +1,1528 @@
+/*
+ * AC power input driver for X-Powers AXP20x PMICs
+ *
+ * Copyright 2014 Bruno Prémont bonb...@linux-vserver.org
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/err.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/power_supply.h
+#include linux/regmap.h
+#include linux/slab.h
+#include linux/time.h
+#include linux/mfd/axp20x.h
+
+struct axp20x_power {
+   struct axp20x_dev *axp20x;
+   /* RTC / Backup battery */
+   struct power_supply backup;
+   char backup_name[24];
+   /* ACIN power supply */
+   struct power_supply ac;
+   char ac_name[24];
+   /* VBUS/OTG power supply */
+   struct power_supply vbus;
+   char vbus_name[24];
+   /* Battery charger */
+   struct power_supply battery;
+   char battery_name[24];
+   char *battery_supplies[2];
+   /* AXP state tracking */
+   struct work_struct work;
+   spinlock_t lock;
+   struct timespec next_check;
+   uint8_t status1;
+   uint8_t status2;
+   uint8_t vbusmgt;
+   int vvbus;
+   int ivbus;
+   int vac;
+   int iac;
+   int vbatt;
+   int ibatt;
+   int pbatt;
+   int tbatt;
+   int tbatt_min;
+   int tbatt_max;
+   int batt_percent;
+   int batt_capacity;
+   int batt_health