[linux-sunxi] Re: [PATCH v2 06/16] drm/sun4i: Don't process LVDS if TCON doesn't support it

[Jernej Škrabec]

Hi Maxime,

Dne sreda, 28. februar 2018 ob 08:36:08 CET je Maxime Ripard napisal(a):
> On Tue, Feb 27, 2018 at 11:26:51PM +0100, Jernej Skrabec wrote:
> > TCON checks for LVDS properties even if it doesn't support it. Add a
> > check to skip that part of the code if TCON doesn't support channel 0.
> > 
> > Signed-off-by: Jernej Skrabec 
> 
> I have already sent a similar patch here:
> https://lists.freedesktop.org/archives/dri-devel/2018-February/15.html

Right. However, check last chunk in my patch. There is no need to call 
sun4i_rgb_init() if TCON doesn't support channel 0. It doesn't do anything, 
except producing warning. Will you add that this change to your patch and then 
I can remove this patch from next revision?

BTW, your patch won't apply cleanly, since you didn't base it on latest code 
(every TCON variant has at least one entry now).

Best regards,
Jernej


-- 
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 v2 00/16] Implement H3/H5 HDMI driver

[Jernej Škrabec]

Hi Maxime,

Dne torek, 27. februar 2018 ob 23:26:45 CET je Jernej Skrabec napisal(a):
> This series implements H3/H5 HDMI driver. It was tested on OrangePi 2 (H3),
> OrangePi Plus2e (H3) and OrangePi PC2 (H5) with many resolutions and it
> works well. Bug, which prevented correct operation for some resolutions,
> is also fixed.
> 
> Code is based on linux-next, next-20180226 tag.

Today I tried on this series on  next-20180228, but resolution switching 
doesn't really work. The reason for this is use of clk_set_rate_exclusive() in 
sun4i_tcon1_mode_set(). If I revert it to ordinary clk_set_rate() it works ok. 
I investigated a bit and it seems that clocks stays at first set even if tcon 
(the owner of exclusive lock) request the new one. Example:

[   69.325732] TCON clk wanted: 14850
[   69.325740] TCON real clk: 69272728
[   69.325770] HDMI clk wanted: 14850
[   69.325773] HDMI real clk: 138545455
[   69.325815] HDMI PHY clk wanted: 14850
[   69.325819] HDMI PHY real clk: 138545454

Is there anything I can do to help debug this?

Best regards,
Jernej


-- 
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 v2 01/16] clk: sunxi-ng: Add check for minimal rate to NM PLLs

[Jernej Škrabec]

Hi,

Dne sreda, 28. februar 2018 ob 08:34:40 CET je Maxime Ripard napisal(a):
> Hi,
> 
> On Tue, Feb 27, 2018 at 11:26:46PM +0100, Jernej Skrabec wrote:
> > Some NM PLLs doesn't work well when their output clock rate is set below
> > certain rate.
> > 
> > Add support for that constrain.
> > 
> > Signed-off-by: Jernej Skrabec 
> > ---
> > 
> >  drivers/clk/sunxi-ng/ccu_nm.c | 11 +++
> >  drivers/clk/sunxi-ng/ccu_nm.h | 27 +++
> >  2 files changed, 34 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/clk/sunxi-ng/ccu_nm.c b/drivers/clk/sunxi-ng/ccu_nm.c
> > index a16de092bf94..7fc743c78c1b 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nm.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nm.c
> > @@ -20,7 +20,7 @@ struct _ccu_nm {
> > 
> >  };
> >  
> >  static void ccu_nm_find_best(unsigned long parent, unsigned long rate,
> > 
> > -struct _ccu_nm *nm)
> > +unsigned long min_rate, struct _ccu_nm *nm)
> > 
> >  {
> >  
> > unsigned long best_rate = 0;
> > unsigned long best_n = 0, best_m = 0;
> > 
> > @@ -30,7 +30,7 @@ static void ccu_nm_find_best(unsigned long parent,
> > unsigned long rate,> 
> > for (_m = nm->min_m; _m <= nm->max_m; _m++) {
> > 
> > unsigned long tmp_rate = parent * _n  / _m;
> > 
> > -   if (tmp_rate > rate)
> > +   if (tmp_rate > rate || tmp_rate < min_rate)
> > 
> > continue;
> > 
> > if ((rate - tmp_rate) < (rate - best_rate)) {
> > 
> > @@ -117,6 +117,9 @@ static long ccu_nm_round_rate(struct clk_hw *hw,
> > unsigned long rate,> 
> > if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
> > 
> > rate *= nm->fixed_post_div;
> > 
> > +   if (rate < nm->min_rate)
> > +   rate = nm->min_rate;
> > +
> 
> I guess you can just return there. There's no point in trying to find
> the factors at this point, since the minimum should be a value that
> can be reached.
> 

Right, I already tested it and it works.

Best regards,
Jernej

> > if (ccu_frac_helper_has_rate(>common, >frac, rate)) {
> > 
> > if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
> > 
> > rate /= nm->fixed_post_div;
> > 
> > @@ -134,7 +137,7 @@ static long ccu_nm_round_rate(struct clk_hw *hw,
> > unsigned long rate,> 
> > _nm.min_m = 1;
> > _nm.max_m = nm->m.max ?: 1 << nm->m.width;
> > 
> > -   ccu_nm_find_best(*parent_rate, rate, &_nm);
> > +   ccu_nm_find_best(*parent_rate, rate, nm->min_rate, &_nm);
> 
> Therefore, you don't need to change the prototype there either.
> 
> Maxime
> 
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.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] [PATCH 2/3] ARM: dts: sun8i: a711: set regulator for each cluster of CPUs

[Quentin Schulz]

The Allwinner A83T is a SoC with two clusters of 4 A7 which have a
different clock and regulator.

Set the CPU regulator.

Signed-off-by: Quentin Schulz 
---
 arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts |  9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts 
b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
index 1de362f..d65162c 100644
--- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
@@ -128,6 +128,14 @@
};
 };
 
+ {
+   cpu-supply = <_dcdc2>;
+};
+
+ {
+   cpu-supply = <_dcdc3>;
+};
+
  {
status = "okay";
 };
@@ -136,6 +144,7 @@
  * An USB-2 hub is connected here, which also means we don't need to
  * enable the OHCI controller.
  */
+
  {
status = "okay";
 };
-- 
git-series 0.9.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.

[linux-sunxi] [PATCH 3/3] ARM: dts: sun8i: a83t: add stable OPP tables and CPUfreq

[Quentin Schulz]

The Allwinner A83T is an octacore A7 divided in two clusters of 4 A7,
each cluster having its own regulator and clock.

The operating points were found in Allwinner BSP and fex files.

Note that there are a few OPPs that are missing:

160800Hz with 92mV
18Hz with 100mV
201600Hz with 108mV

These OPPs are pretty unstable but it might be due to the SoC quickly
overheating (till the board completely shuts down).
It seems impossible to reach those frequencies with none or passive
cooling, so better leave them out by default.

It's still possible to add those OPPs on a per-board basis though.

Signed-off-by: Quentin Schulz 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 118 +++-
 1 file changed, 118 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 016d22f..05d5dd7 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -56,55 +56,173 @@
#address-cells = <1>;
#size-cells = <1>;
 
+   cpu0_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp-48000 {
+   opp-hz = /bits/ 64 <48000>;
+   opp-microvolt = <84>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-6 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <84>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-72000 {
+   opp-hz = /bits/ 64 <72000>;
+   opp-microvolt = <84>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-86400 {
+   opp-hz = /bits/ 64 <86400>;
+   opp-microvolt = <84>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-91200 {
+   opp-hz = /bits/ 64 <91200>;
+   opp-microvolt = <84>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-100800 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-microvolt = <84>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-112800 {
+   opp-hz = /bits/ 64 <112800>;
+   opp-microvolt = <84>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-12 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <84>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+   };
+
+   cpu1_opp_table: opp_table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp-48000 {
+   opp-hz = /bits/ 64 <48000>;
+   opp-microvolt = <84>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-6 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <84>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-72000 {
+   opp-hz = /bits/ 64 <72000>;
+   opp-microvolt = <84>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-86400 {
+   opp-hz = /bits/ 64 <86400>;
+   opp-microvolt = <84>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-91200 {
+   opp-hz = /bits/ 64 <91200>;
+   opp-microvolt = <84>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-100800 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-microvolt = <84>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-112800 {
+   opp-hz = /bits/ 64 <112800>;
+   opp-microvolt = <84>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-12 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <84>;
+   clock-latency-ns = 

[linux-sunxi] [PATCH 1/3] ARM: dts: sun8i: a83t: add cpu0 and cpu100 labels

[Quentin Schulz]

The Allwinner A83T is a SoC with two clusters of 4 A7, each cluster
having its own regulator and clock.

The regulators are board-specific, thus we need labels for cpu0 and
cpu100 so that we can use references to these nodes from the board
header file.

Signed-off-by: Quentin Schulz 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 46ae4fa..016d22f 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -60,7 +60,7 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   cpu@0 {
+   cpu0: cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0>;
@@ -84,7 +84,7 @@
reg = <3>;
};
 
-   cpu@100 {
+   cpu100: cpu@100 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0x100>;
-- 
git-series 0.9.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.

[linux-sunxi] [PATCH 0/3] add CPUs OPPs to sun8i a83t

[Quentin Schulz]

Hi all,

The Allwinner A83T is an octacore A7 divided in two clusters of 4 A7,
each cluster having its own regulator and clock.

Let's add the OPPs for each cluster so that we can use cpufreq on this SoC.

The operating points were found in Allwinner BSP and fex files and have
been tested on a TBS A711 with cpuburn and cpufreq-ljt-stress-test.

Note that there are a few OPPs that are missing:

160800Hz with 92mV
18Hz with 100mV
201600Hz with 108mV

These OPPs are pretty unstable but it might be due to the SoC quickly
overheating (till the board completely shuts down).
It seems[1] impossible to reach those frequencies with none or passive
cooling, so better leave them out by default.

It's still possible to add those OPPs on a per-board basis though.

[1] http://linux-sunxi.org/User:Tkaiser#First_steps_with_Banana_Pi_M3

Thanks,
Quentin

Quentin Schulz (3):
  ARM: dts: sun8i: a83t: add cpu0 and cpu100 labels
  ARM: dts: sun8i: a711: set regulator for each cluster of CPUs
  ARM: dts: sun8i: a83t: add stable OPP tables and CPUfreq

 arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts |   9 ++-
 arch/arm/boot/dts/sun8i-a83t.dtsi | 122 ++-
 2 files changed, 129 insertions(+), 2 deletions(-)

base-commit: 827ad482fda17d0de5df5116fda827cd3671e62e
-- 
git-series 0.9.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] Re: [PATCH v3 6/7] arm64: allwinner: h6: add the basical Allwinner H6 DTSI file

[Andre Przywara]

Hi,

On 26/02/18 15:54, Samuel Holland wrote:
> On 02/26/18 03:26, Maxime Ripard wrote:
>> On Fri, Feb 23, 2018 at 11:22:06PM +0800, Icenowy Zheng wrote:
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };

 Is it needed? The bootloader should fill it with whatever version it
 has, shouldn't it?
>>>
>>> But we now use ATF rather than U-Boot PSCI. U-Boot will not fill ATF
>>> info.
>>>
>>> See A64/H5 device trees.
>>
>> So if the PSCI version implemented in ATF ever changes, we would have
>> to update all the DT everywhere, but only if you're running the new
>> version?
> 
> Yes but no. PSCI 1.0 is generally backward compatible with PSCI 0.2. In fact,
> the Linux driver treats them exactly the same:
> 
> { .compatible = "arm,psci-0.2", .data = psci_0_2_init},
> { .compatible = "arm,psci-1.0", .data = psci_0_2_init},

Yeah, it's actually unclear why we have that new compatible name in the
first place, since starting with PSCI v0.2 the version can be perfectly
read using the mandatory PSCI_VERSION call. And DT aims to only cover
things that are not discoverable.

> For the H6, however, the oldest ATF source available (which I believe was the
> one in use during bringup) is based on mainline 1.4, and is already at PSCI
> version 1.1:
> 
> [0.00] psci: probing for conduit method from DT.
> [0.00] psci: PSCIv1.1 detected in firmware.
> [0.00] psci: Using standard PSCI v0.2 function IDs
> [0.00] psci: MIGRATE_INFO_TYPE not supported.
> 
> So we could go ahead and bump the compatible to "arm,psci-1.0".

I'd rather leave it at "arm,psci-0.2", since this improves compatibility
to other OSes or DT users.

Cheers,
Andre.

-- 
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 v5 6/6] mfd: axp20x: add battery power supply cell for AXP813

[Quentin Schulz]

As axp20x-battery-power-supply now supports AXP813, add a cell for it.

Signed-off-by: Quentin Schulz 
Acked-for-MFD-by: Lee Jones 
Reviewed-by: Chen-Yu Tsai 
---
 drivers/mfd/axp20x.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index e5516aa..aaf2acb 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -888,6 +888,9 @@ static struct mfd_cell axp813_cells[] = {
}, {
.name   = "axp813-adc",
.of_compatible  = "x-powers,axp813-adc",
+   }, {
+   .name   = "axp20x-battery-power-supply",
+   .of_compatible  = "x-powers,axp813-battery-power-supply",
},
 };
 
-- 
git-series 0.9.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.

[linux-sunxi] [PATCH v5 3/6] power: supply: axp20x_battery: use data struct for variant specific code

[Quentin Schulz]

We used to use IDs to select a function or a feature depending on the
variant. It's easier to maintain the code by adding data structure
storing the few differences between variants so that we don't add a pile
of if conditions.

Let's use this data structure and update the code to use it.

Signed-off-by: Quentin Schulz 
Reviewed-by: Chen-Yu Tsai 
---
 drivers/power/supply/axp20x_battery.c | 100 +--
 1 file changed, 66 insertions(+), 34 deletions(-)

diff --git a/drivers/power/supply/axp20x_battery.c 
b/drivers/power/supply/axp20x_battery.c
index 7494f0f..04a0d91 100644
--- a/drivers/power/supply/axp20x_battery.c
+++ b/drivers/power/supply/axp20x_battery.c
@@ -53,6 +53,16 @@
 
 #define AXP20X_V_OFF_MASK  GENMASK(2, 0)
 
+struct axp20x_batt_ps;
+
+struct axp_data {
+   int ccc_scale;
+   int ccc_offset;
+   boolhas_fg_valid;
+   int (*get_max_voltage)(struct axp20x_batt_ps *batt, int *val);
+   int (*set_max_voltage)(struct axp20x_batt_ps *batt, int val);
+};
+
 struct axp20x_batt_ps {
struct regmap *regmap;
struct power_supply *batt;
@@ -62,7 +72,7 @@ struct axp20x_batt_ps {
struct iio_channel *batt_v;
/* Maximum constant charge current */
unsigned int max_ccc;
-   u8 axp_id;
+   const struct axp_data   *data;
 };
 
 static int axp20x_battery_get_max_voltage(struct axp20x_batt_ps *axp20x_batt,
@@ -123,22 +133,6 @@ static int axp22x_battery_get_max_voltage(struct 
axp20x_batt_ps *axp20x_batt,
return 0;
 }
 
-static void raw_to_constant_charge_current(struct axp20x_batt_ps *axp, int 
*val)
-{
-   if (axp->axp_id == AXP209_ID)
-   *val = *val * 10 + 30;
-   else
-   *val = *val * 15 + 30;
-}
-
-static void constant_charge_current_to_raw(struct axp20x_batt_ps *axp, int 
*val)
-{
-   if (axp->axp_id == AXP209_ID)
-   *val = (*val - 30) / 10;
-   else
-   *val = (*val - 30) / 15;
-}
-
 static int axp20x_get_constant_charge_current(struct axp20x_batt_ps *axp,
  int *val)
 {
@@ -150,7 +144,7 @@ static int axp20x_get_constant_charge_current(struct 
axp20x_batt_ps *axp,
 
*val &= AXP20X_CHRG_CTRL1_TGT_CURR;
 
-   raw_to_constant_charge_current(axp, val);
+   *val = *val * axp->data->ccc_scale + axp->data->ccc_offset;
 
return 0;
 }
@@ -269,8 +263,7 @@ static int axp20x_battery_get_prop(struct power_supply *psy,
if (ret)
return ret;
 
-   if (axp20x_batt->axp_id == AXP221_ID &&
-   !(reg & AXP22X_FG_VALID))
+   if (axp20x_batt->data->has_fg_valid && !(reg & AXP22X_FG_VALID))
return -EINVAL;
 
/*
@@ -281,11 +274,8 @@ static int axp20x_battery_get_prop(struct power_supply 
*psy,
break;
 
case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN:
-   if (axp20x_batt->axp_id == AXP209_ID)
-   return axp20x_battery_get_max_voltage(axp20x_batt,
- >intval);
-   return axp22x_battery_get_max_voltage(axp20x_batt,
- >intval);
+   return axp20x_batt->data->get_max_voltage(axp20x_batt,
+ >intval);
 
case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN:
ret = regmap_read(axp20x_batt->regmap, AXP20X_V_OFF, );
@@ -312,6 +302,32 @@ static int axp20x_battery_get_prop(struct power_supply 
*psy,
return 0;
 }
 
+static int axp22x_battery_set_max_voltage(struct axp20x_batt_ps *axp20x_batt,
+ int val)
+{
+   switch (val) {
+   case 410:
+   val = AXP20X_CHRG_CTRL1_TGT_4_1V;
+   break;
+
+   case 420:
+   val = AXP20X_CHRG_CTRL1_TGT_4_2V;
+   break;
+
+   default:
+   /*
+* AXP20x max voltage can be set to 4.36V and AXP22X max voltage
+* can be set to 4.22V and 4.24V, but these voltages are too
+* high for Lithium based batteries (AXP PMICs are supposed to
+* be used with these kinds of battery).
+*/
+   return -EINVAL;
+   }
+
+   return regmap_update_bits(axp20x_batt->regmap, AXP20X_CHRG_CTRL1,
+ AXP20X_CHRG_CTRL1_TGT_VOLT, val);
+}
+
 static int axp20x_battery_set_max_voltage(struct axp20x_batt_ps *axp20x_batt,
  int val)
 {
@@ -321,9 +337,6 @@ static int axp20x_battery_set_max_voltage(struct 
axp20x_batt_ps *axp20x_batt,
break;
 
case 415:
-   if (axp20x_batt->axp_id == AXP221_ID)
-   

[linux-sunxi] [PATCH v5 0/6] add support for AXP813 ADC and battery power supply

[Quentin Schulz]

The AXP813 PMIC is relatively close to the already supported AXP20X and
AXP22X. It provides three different power outputs: battery, AC and USB, and
measures a few different things: temperature, power supply status, current
current and voltage supplied, maximum current limit, battery capacity, min
and max voltage limits.

One of its two GPIOs can be used as an ADC.

There are a few differences with AXP20X/AXP22X PMICs though:
  - a different constant charge current formula,
  - battery temperature, GPIO0 and battery voltages are the only voltages
  measurable,
  - all data are stored on 12 bits (AXP20X/AXP22X had one type of data that
  was stored on 13 bits),
  - different scales and offsets,
  - a different ADC rate formula and register,

This patch series adds support for the PMIC's ADC and battery power supply
in the existing drivers.

Make the axp20x MFD automatically probe the ADC driver, add the battery
power supply node in axp81x node and enable it for the TBS A711 since it
has a soldered battery.

I suggest patches:
  - 1,2,6 go through Lee's tree,
  - 3,4,5 go through Sebastian's tree,

v5:
  - added static in front of the axp_data struct in the battery driver to
  make sparse happy,
  - removed merged patches,

v4:
  - shortened one commit title as a workaround to Chen-Yu note,
  - added const to data structures as proposed by Chen-Yu,
  - added last patch for making sparse happy, on a proposal from Jonathan,
  - removed already applied patches (IIO ones),

v3:
  - merging dt-bindings patches for axp_adc as requested by Rob,
  - re-ordered constant in IIO driver as requested by Julian,
  - compatibles for ADC are now named after the first design that
  introduced the IP instead of wildcard as requested by Maxime,
  - renamed DT node name from axp-adc to adc as requested by Rob,
  - replaced enumeration of supported PMICs in battery power supply DT
  bindings documentation by "supported devices" as requested by Jonathan,
  - added a new patch for removing "axp-" from axp81x's pinctrl DT node,

v2:
  - introduce data structure instead of ID for variant specific code in
  battery driver,
  - add DT binding for ADC driver,
  - make mfd probe the ADC driver via DT as well so that its IIO channels
  can be consumed by other drivers via DT mapping,

Thanks,
Quentin

Quentin Schulz (6):
  mfd: axp20x: make AXP209/22x cells probe their ADC via DT
  mfd: axp20x: probe axp20x_adc driver for AXP813
  power: supply: axp20x_battery: use data struct for variant specific code
  dt-bindings: power: supply: axp20x: add AXP813 battery DT binding
  power: supply: axp20x_battery: add support for AXP813
  mfd: axp20x: add battery power supply cell for AXP813

 Documentation/devicetree/bindings/power/supply/axp20x_battery.txt |   8 ++--
 drivers/mfd/axp20x.c  |  13 +--
 drivers/power/supply/axp20x_battery.c | 134 
+++-
 3 files changed, 119 insertions(+), 36 deletions(-)

base-commit: 827ad482fda17d0de5df5116fda827cd3671e62e
-- 
git-series 0.9.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.

[linux-sunxi] [PATCH v5 5/6] power: supply: axp20x_battery: add support for AXP813

[Quentin Schulz]

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 
Reviewed-by: Chen-Yu Tsai 
---
 drivers/power/supply/axp20x_battery.c | 42 -
 1 file changed, 42 insertions(+)

diff --git a/drivers/power/supply/axp20x_battery.c 
b/drivers/power/supply/axp20x_battery.c
index 04a0d91..4f69c0e 100644
--- a/drivers/power/supply/axp20x_battery.c
+++ b/drivers/power/supply/axp20x_battery.c
@@ -49,6 +49,8 @@
 #define AXP22X_CHRG_CTRL1_TGT_4_22V(1 << 5)
 #define AXP22X_CHRG_CTRL1_TGT_4_24V(3 << 5)
 
+#define AXP813_CHRG_CTRL1_TGT_4_35V(3 << 5)
+
 #define AXP20X_CHRG_CTRL1_TGT_CURR GENMASK(3, 0)
 
 #define AXP20X_V_OFF_MASK  GENMASK(2, 0)
@@ -133,6 +135,35 @@ 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, );
+   if (ret)
+   return ret;
+
+   switch (reg & AXP20X_CHRG_CTRL1_TGT_VOLT) {
+   case AXP20X_CHRG_CTRL1_TGT_4_1V:
+   *val = 410;
+   break;
+   case AXP20X_CHRG_CTRL1_TGT_4_15V:
+   *val = 415;
+   break;
+   case AXP20X_CHRG_CTRL1_TGT_4_2V:
+   *val = 420;
+   break;
+   case AXP813_CHRG_CTRL1_TGT_4_35V:
+   *val = 435;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static int axp20x_get_constant_charge_current(struct axp20x_batt_ps *axp,
  int *val)
 {
@@ -491,6 +522,14 @@ static const struct axp_data axp221_data = {
.set_max_voltage = axp22x_battery_set_max_voltage,
 };
 
+static const struct axp_data axp813_data = {
+   .ccc_scale = 20,
+   .ccc_offset = 20,
+   .has_fg_valid = true,
+   .get_max_voltage = axp813_battery_get_max_voltage,
+   .set_max_voltage = axp20x_battery_set_max_voltage,
+};
+
 static const struct of_device_id axp20x_battery_ps_id[] = {
{
.compatible = "x-powers,axp209-battery-power-supply",
@@ -498,6 +537,9 @@ static const struct of_device_id axp20x_battery_ps_id[] = {
}, {
.compatible = "x-powers,axp221-battery-power-supply",
.data = (void *)_data,
+   }, {
+   .compatible = "x-powers,axp813-battery-power-supply",
+   .data = (void *)_data,
}, { /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, axp20x_battery_ps_id);
-- 
git-series 0.9.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.

[linux-sunxi] [PATCH v5 1/6] mfd: axp20x: make AXP209/22x cells probe their ADC via DT

[Quentin Schulz]

This makes AXP209 and AXP22x ADCs probe first via DT and then by
fallback via platform.

Signed-off-by: Quentin Schulz 
Acked-for-MFD-by: Lee Jones 
Acked-by: Chen-Yu Tsai 
---
 drivers/mfd/axp20x.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index e94c72c..1977a03 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -660,6 +660,7 @@ static struct mfd_cell axp20x_cells[] = {
.name   = "axp20x-regulator",
}, {
.name   = "axp20x-adc",
+   .of_compatible  = "x-powers,axp209-adc",
}, {
.name   = "axp20x-battery-power-supply",
.of_compatible  = "x-powers,axp209-battery-power-supply",
@@ -684,7 +685,8 @@ static struct mfd_cell axp221_cells[] = {
}, {
.name   = "axp20x-regulator",
}, {
-   .name   = "axp22x-adc"
+   .name   = "axp22x-adc",
+   .of_compatible  = "x-powers,axp221-adc",
}, {
.name   = "axp20x-ac-power-supply",
.of_compatible  = "x-powers,axp221-ac-power-supply",
@@ -708,6 +710,7 @@ static struct mfd_cell axp223_cells[] = {
.resources  = axp22x_pek_resources,
}, {
.name   = "axp22x-adc",
+   .of_compatible  = "x-powers,axp221-adc",
}, {
.name   = "axp20x-battery-power-supply",
.of_compatible  = "x-powers,axp221-battery-power-supply",
-- 
git-series 0.9.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.

[linux-sunxi] [PATCH v5 4/6] dt-bindings: power: supply: axp20x: add AXP813 battery DT binding

[Quentin Schulz]

The AXP813 can have a battery as power supply, so let's add it to the
list of compatibles.

Signed-off-by: Quentin Schulz 
Reviewed-by: Rob Herring 
Acked-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/power/supply/axp20x_battery.txt | 8 +++
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt 
b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
index c248866..41916f6 100644
--- a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
+++ b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
@@ -4,12 +4,12 @@ Required Properties:
  - compatible, one of:
"x-powers,axp209-battery-power-supply"
"x-powers,axp221-battery-power-supply"
+   "x-powers,axp813-battery-power-supply"
 
-This node is a subnode of the axp20x/axp22x PMIC.
+This node is a subnode of its respective PMIC DT node.
 
-The AXP20X and AXP22X can read the battery voltage, charge and discharge
-currents of the battery by reading ADC channels from the AXP20X/AXP22X
-ADC.
+The supported devices can read the battery voltage, charge and discharge
+currents of the battery by reading ADC channels from the ADC.
 
 Example:
 
-- 
git-series 0.9.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.

[linux-sunxi] [PATCH v5 2/6] mfd: axp20x: probe axp20x_adc driver for AXP813

[Quentin Schulz]

This makes the axp20x_adc driver probe with platform device id
"axp813-adc".

Signed-off-by: Quentin Schulz 
Acked-for-MFD-by: Lee Jones 
Acked-by: Chen-Yu Tsai 
---
 drivers/mfd/axp20x.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 1977a03..e5516aa 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -885,7 +885,10 @@ static struct mfd_cell axp813_cells[] = {
}, {
.name   = "axp20x-gpio",
.of_compatible  = "x-powers,axp813-gpio",
-   }
+   }, {
+   .name   = "axp813-adc",
+   .of_compatible  = "x-powers,axp813-adc",
+   },
 };
 
 static struct axp20x_dev *axp20x_pm_power_off;
-- 
git-series 0.9.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.