On Mon, 11 Dec 2017 09:18:55 +0100
Quentin Schulz <[email protected]> wrote:

> Hi Jonathan,
>
> On 10/12/2017 17:36, Jonathan Cameron wrote:
> > On Mon, 4 Dec 2017 15:12:48 +0100
> > Quentin Schulz <[email protected]> wrote:
> >
> >> The X-Powers AXP813 PMIC is really close to what is already done for
> >> AXP20X/AXP22X.
> >>
> >> There are two pairs of bits to set the rate (one for Voltage and Current
> >> measurements and one for TS/GPIO0 voltage measurements) instead of one.
> >
> > This would normally imply we need to split the device into two logical
> > IIO devices. However, that only becomes relevant if we are using
> > buffered output which this driver doesn't support.
> > > It'll be nasty to deal with this if we add that support down the line
> > though. Up to you though as it's more likely to be your problem than
> > anyone else's :)
> >
>
> I have no plans for supporting buffered output for the AXPs at the
> moment. But that's an interesting (and important) limitation to raise.
> Wouldn't be more of a hack to have two IIO devices representing the
> actual same IP?

We have thought about allowing multiple buffers from a single IIO device
but that makes for some horrible changes to the ABI - so as things stand
the only option is two devices for one IP. Ultimately they aren't really
two devices - in the same way we have triggers separating registered on
the IIO bus (often many of them). Just two different elements of the same IP.

>
> > For now you could elect to support the different sampling frequencies
> > if you wanted to but just providing controls for each channel.
> >
>
> I guess that you're offering to use IIO_CHAN_INFO_SAMP_FREQ in
> info_mask_separate for each channel?
Yes
>
> > Given the driver doesn't currently expose these at all (I think)
> > this is all rather immaterial ;)
>
> I'm not giving the user the option to chose the sampling frequency for
> now. I have no plans to do it either, but I think it would be rather
> simple to later add support for setting frequency sampling since we only
> need to add a sysfs entry (with IIO_CHAN_INFO_SAMP_FREQ) that does not
> exist yet. Don't you think? Am I missing something?
No should be straight forward as long as we keep clear of the buffered
interfaces with their limitations.

>
> Thanks,
> Quentin

2017-12-12 19:55:33

by Jonathan Cameron

[permalink] [raw]

Subject: Re: [PATCH 5/8] power: supply: axp20x_battery: add support for AXP813

On Mon, 11 Dec 2017 09:35:43 +0100
Quentin Schulz <[email protected]> wrote:

> Hi Jonathan,
>
> On 10/12/2017 17:49, Jonathan Cameron wrote:
> > On Mon, 4 Dec 2017 15:12:51 +0100
> > Quentin Schulz <[email protected]> wrote:
> >
> >> The X-Powers AXP813 PMIC has got some slight differences from
> >> AXP20X/AXP22X PMICs:
> >> - the maximum voltage supplied by the PMIC is 4.35 instead of 4.36/4.24
> >> for AXP20X/AXP22X,
> >> - the constant charge current formula is different,
> >>
> >> It also has a bit to tell whether the battery percentage returned by the
> >> PMIC is valid.
> >>
> >> Signed-off-by: Quentin Schulz <[email protected]>
> >
> > I'd use switch statements when matching the IDs as that'll be more elegant
> > as you perhaps add further devices going forward...
> >
> > Other than that, looks good to me.
> >
>
> Well, I was wondering if it shouldn't be better to define a structure
> for each device containing their quirks, functions, etc... like it is
> done for the ADC or the ACIN power supply driver part.
>

Even better.

> struct axp20x_data {
> bool has_valid_fg_reg;
> void constant_charge_current_to_raw(struct axp20x_batt_ps *axp, int *val);
> void raw_to_constant_charge_current(struct axp20x_batt_ps *axp, int *val);
> int get_max_voltage(struct axp20x_batt_ps *axp, int *val);
> [...]
> };
>
> static const struct of_device_id axp20x_battery_ps_id[] = {
> { .compatible = "x-powers,axp209-battery-power-supply", .data = (void
> *)&axp209_data, }, {}
> };
>
> void probe()
> {
> [...]
> axp20x_batt->info = of_device_get_match_data(&pdev->dev);
> [...]
> }
>
> Sebastian, any objection on doing this?
>
> Thanks,
> Quentin
>
> > Jonathan
> >
> >> ---
> >> drivers/power/supply/axp20x_battery.c | 44 +++++++++++++++++++++++++++-
> >> 1 file changed, 43 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/power/supply/axp20x_battery.c b/drivers/power/supply/axp20x_battery.c
> >> index 7494f0f..cb30302 100644
> >> --- a/drivers/power/supply/axp20x_battery.c
> >> +++ b/drivers/power/supply/axp20x_battery.c
> >> @@ -46,6 +46,8 @@
> >> #define AXP20X_CHRG_CTRL1_TGT_4_2V (2 << 5)
> >> #define AXP20X_CHRG_CTRL1_TGT_4_36V (3 << 5)
> >>
> >> +#define AXP813_CHRG_CTRL1_TGT_4_35V (3 << 5)
> >> +
> >> #define AXP22X_CHRG_CTRL1_TGT_4_22V (1 << 5)
> >> #define AXP22X_CHRG_CTRL1_TGT_4_24V (3 << 5)
> >>
> >> @@ -123,10 +125,41 @@ static int axp22x_battery_get_max_voltage(struct axp20x_batt_ps *axp20x_batt,
> >> return 0;
> >> }
> >>
> >> +static int axp813_battery_get_max_voltage(struct axp20x_batt_ps *axp20x_batt,
> >> + int *val)
> >> +{
> >> + int ret, reg;
> >> +
> >> + ret = regmap_read(axp20x_batt->regmap, AXP20X_CHRG_CTRL1, &reg);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + switch (reg & AXP20X_CHRG_CTRL1_TGT_VOLT) {
> >
> > You could do a lookup based from a table instead which might
> > be ever so slightly more elegant..
> >
> >> + case AXP20X_CHRG_CTRL1_TGT_4_1V:
> >> + *val = 4100000;
> >> + break;
> >> + case AXP20X_CHRG_CTRL1_TGT_4_15V:
> >> + *val = 4150000;
> >> + break;
> >> + case AXP20X_CHRG_CTRL1_TGT_4_2V:
> >> + *val = 4200000;
> >> + break;
> >> + case AXP813_CHRG_CTRL1_TGT_4_35V:
> >> + *val = 4350000;
> >> + break;
> >> + default:
> >> + return -EINVAL;
> >> + }
> >> +
> >> + return 0;
> >> +}
> >> +
> >> static void raw_to_constant_charge_current(struct axp20x_batt_ps *axp, int *val)
> >> {
> >> if (axp->axp_id == AXP209_ID)
> >> *val = *val * 100000 + 300000;
> >> + else if (axp->axp_id == AXP813_ID)
> >> + *val = *val * 200000 + 200000;
> >> else
> >> *val = *val * 150000 + 300000;
> >
> > Switch?
> >
> >> }
> >> @@ -135,6 +168,8 @@ static void constant_charge_current_to_raw(struct axp20x_batt_ps *axp, int *val)
> >> {
> >> if (axp->axp_id == AXP209_ID)
> >> *val = (*val - 300000) / 100000;
> >> + else if (axp->axp_id == AXP813_ID)
> >> + *val = (*val - 200000) / 200000;
> >> else
> >> *val = (*val - 300000) / 150000;
> >> }
> >> @@ -269,7 +304,8 @@ static int axp20x_battery_get_prop(struct power_supply *psy,
> >> if (ret)
> >> return ret;
> >>
> >> - if (axp20x_batt->axp_id == AXP221_ID &&
> >> + if ((axp20x_batt->axp_id == AXP221_ID ||
> >> + axp20x_batt->axp_id == AXP813_ID) &&
> >> !(reg & AXP22X_FG_VALID))
> >> return -EINVAL;
> >>
> >> @@ -284,6 +320,9 @@ static int axp20x_battery_get_prop(struct power_supply *psy,
> >> if (axp20x_batt->axp_id == AXP209_ID)
> >> return axp20x_battery_get_max_voltage(axp20x_batt,
> >> &val->intval);
> >> + else if (axp20x_batt->axp_id == AXP813_ID)
> >> + return axp813_battery_get_max_voltage(axp20x_batt,
> >> + &val->intval);
> >> return axp22x_battery_get_max_voltage(axp20x_batt,
> >> &val->intval);
> >
> > Worth converting to a switch statement to make it more elegant for future
> > devices?
> >
> >>
> >> @@ -467,6 +506,9 @@ static const struct of_device_id axp20x_battery_ps_id[] = {
> >> }, {
> >> .compatible = "x-powers,axp221-battery-power-supply",
> >> .data = (void *)AXP221_ID,
> >> + }, {
> >> + .compatible = "x-powers,axp813-battery-power-supply",
> >> + .data = (void *)AXP813_ID,
> >> }, { /* sentinel */ },
> >> };
> >> MODULE_DEVICE_TABLE(of, axp20x_battery_ps_id);
> >
>