* [PATCH v5 6/7] ARM: dts: sun8i: sina33: enable battery power supply subnode
From: Quentin Schulz @ 2017-04-05 8:10 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405081059.1684-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The Sinlinx SinA33 has an AXP223 PMIC and a battery connector, thus, we
enable the battery power supply subnode in its Device Tree.
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index e34e092..7afe7fe 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -182,6 +182,10 @@
status = "okay";
};
+&battery_power_supply {
+ status = "okay";
+};
+
®_aldo1 {
regulator-always-on;
regulator-min-microvolt = <3000000>;
--
2.9.3
^ permalink raw reply related
* [PATCH v5 5/7] ARM: dtsi: axp22x: add battery power supply subnode
From: Quentin Schulz @ 2017-04-05 8:10 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405081059.1684-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The X-Powers AXP22X PMIC exposes battery supply various data such as
the battery status (charging, discharging, full, dead), current max
limit, current current, battery capacity (in percentage), voltage max
limit, current voltage, and battery capacity (in Ah).
This adds the battery power supply subnode for AXP22X PMIC.
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
v2:
- changed DT node name from battery_power_supply to
battery-power-supply,
- removed io-channels and io-channel-names from DT (the IIO mapping is
done in the IIO ADC driver now),
arch/arm/boot/dts/axp22x.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/axp22x.dtsi b/arch/arm/boot/dts/axp22x.dtsi
index 67331c5..87fb08e 100644
--- a/arch/arm/boot/dts/axp22x.dtsi
+++ b/arch/arm/boot/dts/axp22x.dtsi
@@ -57,6 +57,11 @@
status = "disabled";
};
+ battery_power_supply: battery-power-supply {
+ compatible = "x-powers,axp221-battery-power-supply";
+ status = "disabled";
+ };
+
regulators {
/* Default work frequency for buck regulators */
x-powers,dcdc-freq = <3000>;
--
2.9.3
^ permalink raw reply related
* [PATCH v5 4/7] ARM: dtsi: axp209: add battery power supply subnode
From: Quentin Schulz @ 2017-04-05 8:10 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405081059.1684-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The X-Powers AXP209 PMIC exposes battery supply various data such as
the battery status (charging, discharging, full, dead), current max
limit, current current, battery capacity (in percentage), voltage max
and min limits, current voltage, and battery capacity (in Ah).
This adds the battery power supply subnode for AXP20X PMIC.
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
v2:
- changed DT node name from battery_power_supply to
battery-power-supply,
- removed io-channels and io-channel-names from DT (the IIO mapping is
done in the IIO ADC driver now),
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 9677dd5..3c8fa26 100644
--- a/arch/arm/boot/dts/axp209.dtsi
+++ b/arch/arm/boot/dts/axp209.dtsi
@@ -64,6 +64,11 @@
#gpio-cells = <2>;
};
+ battery_power_supply: battery-power-supply {
+ compatible = "x-powers,axp209-battery-power-supply";
+ status = "disabled";
+ };
+
regulators {
/* Default work frequency for buck regulators */
x-powers,dcdc-freq = <1500>;
--
2.9.3
^ permalink raw reply related
* [PATCH v5 3/7] mfd: axp20x: add MFD cells for AXP20X and AXP22X battery driver
From: Quentin Schulz @ 2017-04-05 8:10 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405081059.1684-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
This patch adds the AXP20X/AXP22X battery driver to the MFD cells of the
AXP209, AXP221 and AXP223 MFD.
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
v2:
- changed DT node name from battery_power_supply to
battery-power-supply,
- removed io-channels and io-channel-names from DT (the IIO mapping is
done in the IIO ADC driver now),
drivers/mfd/axp20x.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 5ba3b04..e6f5507 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -594,6 +594,9 @@ static struct mfd_cell axp20x_cells[] = {
}, {
.name = "axp20x-adc",
}, {
+ .name = "axp20x-battery-power-supply",
+ .of_compatible = "x-powers,axp209-battery-power-supply",
+ }, {
.name = "axp20x-ac-power-supply",
.of_compatible = "x-powers,axp202-ac-power-supply",
.num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
@@ -621,6 +624,9 @@ static struct mfd_cell axp221_cells[] = {
.num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
.resources = axp20x_ac_power_supply_resources,
}, {
+ .name = "axp20x-battery-power-supply",
+ .of_compatible = "x-powers,axp221-battery-power-supply",
+ }, {
.name = "axp20x-usb-power-supply",
.of_compatible = "x-powers,axp221-usb-power-supply",
.num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
@@ -636,6 +642,9 @@ static struct mfd_cell axp223_cells[] = {
}, {
.name = "axp22x-adc",
}, {
+ .name = "axp20x-battery-power-supply",
+ .of_compatible = "x-powers,axp221-battery-power-supply",
+ }, {
.name = "axp20x-regulator",
}, {
.name = "axp20x-ac-power-supply",
--
2.9.3
^ permalink raw reply related
* [PATCH v5 2/7] power: supply: add battery driver for AXP20X and AXP22X PMICs
From: Quentin Schulz @ 2017-04-05 8:10 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405081059.1684-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
This patch adds the battery power supply driver to get various data from
the PMIC, such as the battery status (charging, discharging, full,
dead), current max limit, current current, battery capacity (in
percentage), voltage max and min limits, current voltage and battery
capacity (in Ah).
This battery driver uses the AXP20X/AXP22X ADC driver as PMIC data
provider.
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Acked-by: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
v5:
- removed support for constant charge current setting from DT,
- added a function to compute the constant charge current depending on the
PMIC variant,
v4:
- removed useless axp20x_dev variable in struct axp20x_batt_ps,
- added struct device and maximum constant current charge variables in struct
axp20x_batt_ps,
- fixed wrong maximum constant current charge formula for AXP22X (forgot to add
a custom formula so it was calculated like the AXP209),
- when a battery node in DT does not have a valid constant current charge or
there is no battery, the maximum current constant current charge are set to the
lowest possible value,
- it is possible to set maximum constant current charge now but a warn message
is printed when trying to increase it to inform people it is risky,
- added a check to verify the constant current charge to be set is under the
maximum allowed,
- lower the current constant charge current if it is higher than the maximum
current value to be set,
v3:
- added axp20x_set_voltage_min_design function so it can be reused,
- used power_supply_get_battery_info for setting constant charge current
instead of x-powers,constant-charge-current introduced in v2,
- used power_supply_get_battery_info for setting voltage min design of
the battery,
v2:
- changed BIT(x) to 1 << x when describing bits purpose for which 2 <<
x or 3 << x exists, to be consistent,
- switched from POWER_SUPPLY_PROP_CURRENT_MAX to
POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
- added POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX to the list of
readable properties,
- replaced µ character by a common u for micro units to make checkpatch
happy,
- factorized code in axp20x_battery_set_max_voltage,
- added a axp20x_set_constant_charge_current function to be used when
setting the value from sysfs and from the DT,
- removed some dead code,
- added a DT property to set constant current charge of the battery
(x-powers,constant-charge-current),
- migrated to dev_get_regmap instead of manually looking for the regmap
in the drvdata of the parent,
- switched from int to uintptr_t cast to make sure the cast is always
for the same size type (make build on 64bits platforms happy mainly),
drivers/power/supply/Kconfig | 12 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/axp20x_battery.c | 502 ++++++++++++++++++++++++++++++++++
3 files changed, 515 insertions(+)
create mode 100644 drivers/power/supply/axp20x_battery.c
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index cc50e15..7f1ada8 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -232,6 +232,18 @@ config CHARGER_AXP20X
This driver can also be built as a module. If so, the module will be
called axp20x_ac_power.
+config BATTERY_AXP20X
+ tristate "X-Powers AXP20X battery driver"
+ depends on MFD_AXP20X
+ depends on AXP20X_ADC
+ depends on IIO
+ help
+ Say Y here to enable support for X-Powers AXP20X PMICs' battery power
+ supply.
+
+ This driver can also be built as a module. If so, the module will be
+ called axp20x_battery.
+
config AXP288_CHARGER
tristate "X-Powers AXP288 Charger"
depends on MFD_AXP20X && EXTCON_AXP288
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index 3789a2c..52dd17d 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_TEST_POWER) += test_power.o
obj-$(CONFIG_BATTERY_88PM860X) += 88pm860x_battery.o
obj-$(CONFIG_BATTERY_ACT8945A) += act8945a_charger.o
+obj-$(CONFIG_BATTERY_AXP20X) += axp20x_battery.o
obj-$(CONFIG_CHARGER_AXP20X) += axp20x_ac_power.o
obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o
obj-$(CONFIG_BATTERY_DS2780) += ds2780_battery.o
diff --git a/drivers/power/supply/axp20x_battery.c b/drivers/power/supply/axp20x_battery.c
new file mode 100644
index 0000000..5d29b2e
--- /dev/null
+++ b/drivers/power/supply/axp20x_battery.c
@@ -0,0 +1,502 @@
+/*
+ * Battery power supply driver for X-Powers AXP20X and AXP22X PMICs
+ *
+ * Copyright 2016 Free Electrons NextThing Co.
+ * Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
+ *
+ * This driver is based on a previous upstreaming attempt by:
+ * Bruno Prémont <bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy@public.gmane.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/iio/iio.h>
+#include <linux/iio/consumer.h>
+#include <linux/mfd/axp20x.h>
+
+#define AXP20X_PWR_STATUS_BAT_CHARGING BIT(2)
+
+#define AXP20X_PWR_OP_BATT_PRESENT BIT(5)
+#define AXP20X_PWR_OP_BATT_ACTIVATED BIT(3)
+
+#define AXP209_FG_PERCENT GENMASK(6, 0)
+#define AXP22X_FG_VALID BIT(7)
+
+#define AXP20X_CHRG_CTRL1_TGT_VOLT GENMASK(6, 5)
+#define AXP20X_CHRG_CTRL1_TGT_4_1V (0 << 5)
+#define AXP20X_CHRG_CTRL1_TGT_4_15V (1 << 5)
+#define AXP20X_CHRG_CTRL1_TGT_4_2V (2 << 5)
+#define AXP20X_CHRG_CTRL1_TGT_4_36V (3 << 5)
+
+#define AXP22X_CHRG_CTRL1_TGT_4_22V (1 << 5)
+#define AXP22X_CHRG_CTRL1_TGT_4_24V (3 << 5)
+
+#define AXP20X_CHRG_CTRL1_TGT_CURR GENMASK(3, 0)
+
+#define AXP20X_V_OFF_MASK GENMASK(2, 0)
+
+struct axp20x_batt_ps {
+ struct regmap *regmap;
+ struct power_supply *batt;
+ struct device *dev;
+ struct iio_channel *batt_chrg_i;
+ struct iio_channel *batt_dischrg_i;
+ struct iio_channel *batt_v;
+ u8 axp_id;
+};
+
+static int axp20x_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 = 4100000;
+ break;
+ case AXP20X_CHRG_CTRL1_TGT_4_15V:
+ *val = 4150000;
+ break;
+ case AXP20X_CHRG_CTRL1_TGT_4_2V:
+ *val = 4200000;
+ break;
+ case AXP20X_CHRG_CTRL1_TGT_4_36V:
+ *val = 4360000;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int axp22x_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 = 4100000;
+ break;
+ case AXP20X_CHRG_CTRL1_TGT_4_2V:
+ *val = 4200000;
+ break;
+ case AXP22X_CHRG_CTRL1_TGT_4_22V:
+ *val = 4220000;
+ break;
+ case AXP22X_CHRG_CTRL1_TGT_4_24V:
+ *val = 4240000;
+ 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
+ *val = *val * 150000 + 300000;
+}
+
+static int axp20x_get_constant_charge_current(struct axp20x_batt_ps *axp,
+ int *val)
+{
+ int ret;
+
+ ret = regmap_read(axp->regmap, AXP20X_CHRG_CTRL1, val);
+ if (ret)
+ return ret;
+
+ *val &= AXP20X_CHRG_CTRL1_TGT_CURR;
+
+ raw_to_constant_charge_current(axp, val);
+
+ return 0;
+}
+
+static int axp20x_battery_get_prop(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct axp20x_batt_ps *axp20x_batt = power_supply_get_drvdata(psy);
+ struct iio_channel *chan;
+ int ret = 0, reg, val1;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_PRESENT:
+ case POWER_SUPPLY_PROP_ONLINE:
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_PWR_OP_MODE,
+ ®);
+ if (ret)
+ return ret;
+
+ val->intval = !!(reg & AXP20X_PWR_OP_BATT_PRESENT);
+ break;
+
+ case POWER_SUPPLY_PROP_STATUS:
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_PWR_INPUT_STATUS,
+ ®);
+ if (ret)
+ return ret;
+
+ if (reg & AXP20X_PWR_STATUS_BAT_CHARGING) {
+ val->intval = POWER_SUPPLY_STATUS_CHARGING;
+ return 0;
+ }
+
+ ret = iio_read_channel_processed(axp20x_batt->batt_dischrg_i,
+ &val1);
+ if (ret)
+ return ret;
+
+ if (val1) {
+ val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
+ return 0;
+ }
+
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_FG_RES, &val1);
+ if (ret)
+ return ret;
+
+ /*
+ * Fuel Gauge data takes 7 bits but the stored value seems to be
+ * directly the raw percentage without any scaling to 7 bits.
+ */
+ if ((val1 & AXP209_FG_PERCENT) == 100)
+ val->intval = POWER_SUPPLY_STATUS_FULL;
+ else
+ val->intval = POWER_SUPPLY_STATUS_NOT_CHARGING;
+ break;
+
+ case POWER_SUPPLY_PROP_HEALTH:
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_PWR_OP_MODE,
+ &val1);
+ if (ret)
+ return ret;
+
+ if (val1 & AXP20X_PWR_OP_BATT_ACTIVATED) {
+ val->intval = POWER_SUPPLY_HEALTH_DEAD;
+ return 0;
+ }
+
+ val->intval = POWER_SUPPLY_HEALTH_GOOD;
+ break;
+
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
+ ret = axp20x_get_constant_charge_current(axp20x_batt,
+ &val->intval);
+ if (ret)
+ return ret;
+ break;
+
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX:
+ val->intval = AXP20X_CHRG_CTRL1_TGT_CURR;
+ raw_to_constant_charge_current(axp20x_batt, &val->intval);
+
+ break;
+
+ case POWER_SUPPLY_PROP_CURRENT_NOW:
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_PWR_INPUT_STATUS,
+ ®);
+ if (ret)
+ return ret;
+
+ if (reg & AXP20X_PWR_STATUS_BAT_CHARGING)
+ chan = axp20x_batt->batt_chrg_i;
+ else
+ chan = axp20x_batt->batt_dischrg_i;
+
+ ret = iio_read_channel_processed(chan, &val->intval);
+ if (ret)
+ return ret;
+
+ /* IIO framework gives mA but Power Supply framework gives uA */
+ val->intval *= 1000;
+ break;
+
+ case POWER_SUPPLY_PROP_CAPACITY:
+ /* When no battery is present, return capacity is 100% */
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_PWR_OP_MODE,
+ ®);
+ if (ret)
+ return ret;
+
+ if (!(reg & AXP20X_PWR_OP_BATT_PRESENT)) {
+ val->intval = 100;
+ return 0;
+ }
+
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_FG_RES, ®);
+ if (ret)
+ return ret;
+
+ if (axp20x_batt->axp_id == AXP221_ID &&
+ !(reg & AXP22X_FG_VALID))
+ return -EINVAL;
+
+ /*
+ * Fuel Gauge data takes 7 bits but the stored value seems to be
+ * directly the raw percentage without any scaling to 7 bits.
+ */
+ val->intval = reg & AXP209_FG_PERCENT;
+ break;
+
+ case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN:
+ if (axp20x_batt->axp_id == AXP209_ID)
+ return axp20x_battery_get_max_voltage(axp20x_batt,
+ &val->intval);
+ return axp22x_battery_get_max_voltage(axp20x_batt,
+ &val->intval);
+
+ case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN:
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_V_OFF, ®);
+ if (ret)
+ return ret;
+
+ val->intval = 2600000 + 100000 * (reg & AXP20X_V_OFF_MASK);
+ break;
+
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ ret = iio_read_channel_processed(axp20x_batt->batt_v,
+ &val->intval);
+ if (ret)
+ return ret;
+
+ /* IIO framework gives mV but Power Supply framework gives uV */
+ val->intval *= 1000;
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int axp20x_battery_set_max_voltage(struct axp20x_batt_ps *axp20x_batt,
+ int val)
+{
+ switch (val) {
+ case 4100000:
+ val = AXP20X_CHRG_CTRL1_TGT_4_1V;
+ break;
+
+ case 4150000:
+ if (axp20x_batt->axp_id == AXP221_ID)
+ return -EINVAL;
+
+ val = AXP20X_CHRG_CTRL1_TGT_4_15V;
+ break;
+
+ case 4200000:
+ 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_set_constant_charge_current(struct axp20x_batt_ps *axp_batt,
+ int charge_current)
+{
+ if (axp_batt->axp_id == AXP209_ID)
+ charge_current = (charge_current - 300000) / 100000;
+ else
+ charge_current = (charge_current - 300000) / 150000;
+
+ if (charge_current > AXP20X_CHRG_CTRL1_TGT_CURR || charge_current < 0)
+ return -EINVAL;
+
+ return regmap_update_bits(axp_batt->regmap, AXP20X_CHRG_CTRL1,
+ AXP20X_CHRG_CTRL1_TGT_CURR, charge_current);
+}
+
+static int axp20x_set_voltage_min_design(struct axp20x_batt_ps *axp_batt,
+ int min_voltage)
+{
+ int val1 = (min_voltage - 2600000) / 100000;
+
+ if (val1 < 0 || val1 > AXP20X_V_OFF_MASK)
+ return -EINVAL;
+
+ return regmap_update_bits(axp_batt->regmap, AXP20X_V_OFF,
+ AXP20X_V_OFF_MASK, val1);
+}
+
+static int axp20x_battery_set_prop(struct power_supply *psy,
+ enum power_supply_property psp,
+ const union power_supply_propval *val)
+{
+ struct axp20x_batt_ps *axp20x_batt = power_supply_get_drvdata(psy);
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN:
+ return axp20x_set_voltage_min_design(axp20x_batt, val->intval);
+
+ case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN:
+ return axp20x_battery_set_max_voltage(axp20x_batt, val->intval);
+
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
+ return axp20x_set_constant_charge_current(axp20x_batt,
+ val->intval);
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static enum power_supply_property axp20x_battery_props[] = {
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX,
+ POWER_SUPPLY_PROP_HEALTH,
+ POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
+ POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
+ POWER_SUPPLY_PROP_CAPACITY,
+};
+
+static int axp20x_battery_prop_writeable(struct power_supply *psy,
+ enum power_supply_property psp)
+{
+ return psp == POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN ||
+ psp == POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN ||
+ psp == POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT;
+}
+
+static const struct power_supply_desc axp20x_batt_ps_desc = {
+ .name = "axp20x-battery",
+ .type = POWER_SUPPLY_TYPE_BATTERY,
+ .properties = axp20x_battery_props,
+ .num_properties = ARRAY_SIZE(axp20x_battery_props),
+ .property_is_writeable = axp20x_battery_prop_writeable,
+ .get_property = axp20x_battery_get_prop,
+ .set_property = axp20x_battery_set_prop,
+};
+
+static const struct of_device_id axp20x_battery_ps_id[] = {
+ {
+ .compatible = "x-powers,axp209-battery-power-supply",
+ .data = (void *)AXP209_ID,
+ }, {
+ .compatible = "x-powers,axp221-battery-power-supply",
+ .data = (void *)AXP221_ID,
+ }, { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, axp20x_battery_ps_id);
+
+static int axp20x_power_probe(struct platform_device *pdev)
+{
+ struct axp20x_batt_ps *axp20x_batt;
+ struct power_supply_config psy_cfg = {};
+
+ if (!of_device_is_available(pdev->dev.of_node))
+ return -ENODEV;
+
+ axp20x_batt = devm_kzalloc(&pdev->dev, sizeof(*axp20x_batt),
+ GFP_KERNEL);
+ if (!axp20x_batt)
+ return -ENOMEM;
+
+ axp20x_batt->dev = &pdev->dev;
+
+ axp20x_batt->batt_v = devm_iio_channel_get(&pdev->dev, "batt_v");
+ if (IS_ERR(axp20x_batt->batt_v)) {
+ if (PTR_ERR(axp20x_batt->batt_v) == -ENODEV)
+ return -EPROBE_DEFER;
+ return PTR_ERR(axp20x_batt->batt_v);
+ }
+
+ axp20x_batt->batt_chrg_i = devm_iio_channel_get(&pdev->dev,
+ "batt_chrg_i");
+ if (IS_ERR(axp20x_batt->batt_chrg_i)) {
+ if (PTR_ERR(axp20x_batt->batt_chrg_i) == -ENODEV)
+ return -EPROBE_DEFER;
+ return PTR_ERR(axp20x_batt->batt_chrg_i);
+ }
+
+ axp20x_batt->batt_dischrg_i = devm_iio_channel_get(&pdev->dev,
+ "batt_dischrg_i");
+ if (IS_ERR(axp20x_batt->batt_dischrg_i)) {
+ if (PTR_ERR(axp20x_batt->batt_dischrg_i) == -ENODEV)
+ return -EPROBE_DEFER;
+ return PTR_ERR(axp20x_batt->batt_dischrg_i);
+ }
+
+ axp20x_batt->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+ platform_set_drvdata(pdev, axp20x_batt);
+
+ psy_cfg.drv_data = axp20x_batt;
+ psy_cfg.of_node = pdev->dev.of_node;
+
+ axp20x_batt->axp_id = (uintptr_t)of_device_get_match_data(&pdev->dev);
+
+ axp20x_batt->batt = devm_power_supply_register(&pdev->dev,
+ &axp20x_batt_ps_desc,
+ &psy_cfg);
+ if (IS_ERR(axp20x_batt->batt)) {
+ dev_err(&pdev->dev, "failed to register power supply: %ld\n",
+ PTR_ERR(axp20x_batt->batt));
+ return PTR_ERR(axp20x_batt->batt);
+ }
+
+ return 0;
+}
+
+static struct platform_driver axp20x_batt_driver = {
+ .probe = axp20x_power_probe,
+ .driver = {
+ .name = "axp20x-battery-power-supply",
+ .of_match_table = axp20x_battery_ps_id,
+ },
+};
+
+module_platform_driver(axp20x_batt_driver);
+
+MODULE_DESCRIPTION("Battery power supply driver for AXP20X and AXP22X PMICs");
+MODULE_AUTHOR("Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>");
+MODULE_LICENSE("GPL");
--
2.9.3
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply related
* [PATCH v5 1/7] dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding
From: Quentin Schulz @ 2017-04-05 8:10 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405081059.1684-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
This patch adds the DT binding documentation for the battery power
supply which gets various data from the PMIC, such as the battery status
(charging, discharging, full, dead), current max limit, current current,
battery capacity (in percentage), voltage max and min limits, current
voltage and battery capacity (in Ah).
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
v5:
- removed DT property example from monitored-battery,
v4:
- added monitored-battery optional property,
- added example with battery,
v3:
- removed constant charge current property, now should use the WIP
battery framework,
v2:
- changed DT node name from ac_power_supply to ac-power-supply,
- removed io-channels and io-channel-names from DT (the IIO mapping is
done in the IIO ADC driver now),
- added x-powers,constant-charge-current property to set the maximal
default constant current charge of the battery,
.../bindings/power/supply/axp20x_battery.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
new file mode 100644
index 0000000..63826fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
@@ -0,0 +1,28 @@
+AXP20x and AXP22x battery power supply
+
+Required Properties:
+ - compatible, one of:
+ "x-powers,axp209-battery-power-supply"
+ "x-powers,axp221-battery-power-supply"
+
+Optional properties:
+ - monitored-battery, phandle to a fixed battery
+
+This node is a subnode of the axp20x/axp22x PMIC.
+
+The AXP20X and AXP22X can read the battery voltage, charge and discharge
+currents of the battery by reading ADC channels from the AXP20X/AXP22X
+ADC.
+
+Example:
+
+battery: battery {
+ compatible = "fixed-battery";
+};
+
+&axp209 {
+ battery_power_supply: battery-power-supply {
+ compatible = "x-powers,axp209-battery-power-supply";
+ monitored-battery = <&battery>;
+ }
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v5 0/7] add support for AXP20X and AXP22X battery power supply driver
From: Quentin Schulz @ 2017-04-05 8:10 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
This is a series for AXP20X and AXP22X battery power supply without the
support for changing constant charge current from the DT. The patches for
supporting the constant charge current from DT are ready and will be sent
once the battery framework required to make this work has been merged.
Quote from v4 cover letter:
The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose
information and data of the various power supplies they support such as
ACIN, battery and VBUS. For example, they expose the current battery
voltage, charge or discharge, as well as ACIN and VBUS current voltages
and currents, internal PMIC temperature and ADC on 2 different GPIOs
when in the right mode (for the AXP209 only).
The ACIN power supply driver is added by this patch. The AXP20X and
AXP22X can both read the status and the "usability" of the power supply
but only the AXP209 will be able to tell the current current and voltage
of the power supply by reading ADC channels. It is simply not supported
by the AXP22X PMICs.
The battery power supply driver is also added by this patch. The AXP20X
and AXP22X share most of their behaviour but have slight variations. The
allowed target voltages for battery charging are not the same, the
AXP22X PMIC are able to tell if the battery percentage computed by the
PMIC is trustworthy and they have different formulas for computing max
current for battery power supply. The driver is able to give the current
voltage and current of the battery (be it charging or discharging), the
maximal and minimal voltage and maximal current allowed for the battery,
whether the battery is present and usable and its capacity. It will get
the battery current current and voltage by reading the ADC channels. The
PMIC allows maximal voltages (4.36V for AXP20X and 4.22V and 4.24V for
AXP22X) that should not be used with Lithium-based batteries and since
this PMIC is supposed to be used with Lithium-based batteries, they have
been disabled. The values returned by the ADC driver are multipled by
1000 to scale from the mV returned by the ADC to the uV expected by the
power supply framework.
This series of patch adds DT bindings for ACIN power supply, ADC and
battery power supply drivers for AXP20X and AXP22X PMICs and their
documentation. It also enables the supported power supplies for the
Nextthing Co. CHIP and Sinlinx SinA33 boards.
The different drivers are also added to the MFD cells of the AXP20X and
AXP22X cells and the writeable and volatile regs updated to work with
the newly added drivers.
This series of patch is based on a previous upstreaming attempt done by
Bruno Prémont few months ago. It differs in three points: the ADC
driver does not tell the battery temperature (TS_IN) as I do not have a
board to test it with, it does not tell the instantaneous battery power
as it returns crazy values for me and finally no support for OCV curves
for the battery.
You can test these patches from this repo and branch:
https://github.com/QSchulz/linux/tree/axp2xx_adc_batt_ac_v4
v4:
- added the ability to set maximum constant charge current from sysfs,
- added a warning when setting a higher than current maximum constant charge
current,
- set default to minimum possible value for current and maximum constant charge
current when no battery DT is present or invalid battery DT,
- fixed a forgotten custom formula to compute maximum constant charge current
for AXP22X,
- automatically lower the current constant charge current when it is higher
than the maximum constant charge current about to be set,
v3:
- Removed DT property for constant charge current in favor of the WIP
battery framework as requested by Sebastian Reichel,
- Using a simple if condition instead of a switch in the ADC driver,
- Fixed error handling in ADC driver's probe,
- Fixed missing call to iio_map_array_unregister in the ADC driver's
remove,
- Removed ADC driver's DT node and documentation,
- Merged IIO channel mapping patches into the original ADC driver
patch,
- Removed `adding V-OFF to writeable reg' patch as it's already in
writeable reg range,
v2:
- Some registers' name have been changed to better reflect their
purpose,
- Make VBUS power supply driver use IIO channels when AXP ADC driver is
enabled, but fall back on previous behavior when disabled. This is made
to avoid the ADC driver overwritting registers for VBUS power supply
ADC when removed,
- Removed useless adding of data registers to volatile registers,
- Reordered IIO channels, now grouped by same part of the PMIC (e.g.
voltage and current of the battery have the same index in different
IIO types),
- Added structures for specific data instead of matching on IDs,
- Switched from DT IIO channels mapping to iio_map structures IIO
channels mapping,
Quentin
Quentin Schulz (7):
dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding
power: supply: add battery driver for AXP20X and AXP22X PMICs
mfd: axp20x: add MFD cells for AXP20X and AXP22X battery driver
ARM: dtsi: axp209: add battery power supply subnode
ARM: dtsi: axp22x: add battery power supply subnode
ARM: dts: sun8i: sina33: enable battery power supply subnode
ARM: sun5i: chip: enable battery power supply subnode
.../bindings/power/supply/axp20x_battery.txt | 28 ++
arch/arm/boot/dts/axp209.dtsi | 5 +
arch/arm/boot/dts/axp22x.dtsi | 5 +
arch/arm/boot/dts/sun5i-r8-chip.dts | 4 +
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 4 +
drivers/mfd/axp20x.c | 9 +
drivers/power/supply/Kconfig | 12 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/axp20x_battery.c | 502 +++++++++++++++++++++
9 files changed, 570 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
create mode 100644 drivers/power/supply/axp20x_battery.c
--
2.9.3
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: Re: [PATCH v3 04/11] drm/sun4i: abstract the layer type
From: Maxime Ripard @ 2017-04-05 8:09 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, linux-arm-kernel, Sean Paul, linux-sunxi,
Rob Herring, linux-kernel, devicetree, Jernej Skrabec, linux-clk,
dri-devel
In-Reply-To: <20170405052325.98B958A2E94-Y9/x5g2N/Tt0ykcd9G8QkxTxI0vvWBSX@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 7199 bytes --]
On Wed, Apr 05, 2017 at 01:23:15PM +0800, Icenowy Zheng wrote:
>
> 2017年4月5日 10:27于 Chen-Yu Tsai <wens@csie.org>写道：
> >
> > On Wed, Apr 5, 2017 at 3:53 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> > >
> > >
> > > 在 2017年04月05日 03:28, Sean Paul 写道:
> > >>
> > >> On Thu, Mar 30, 2017 at 03:46:06AM +0800, Icenowy Zheng wrote:
> > >>>
> > >>> As we are going to add support for the Allwinner DE2 Mixer in sun4i-drm
> > >>> driver, we will finally have two types of layer.
> > >>>
> > >>> Abstract the layer type to void * and a ops struct, which contains the
> > >>> only function used by crtc -- get the drm_plane struct of the layer.
> > >>>
> > >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > >>> ---
> > >>> Refactored patch in v3.
> > >>>
> > >>> drivers/gpu/drm/sun4i/sun4i_crtc.c | 19 +++++++++++--------
> > >>> drivers/gpu/drm/sun4i/sun4i_crtc.h | 3 ++-
> > >>> drivers/gpu/drm/sun4i/sun4i_layer.c | 19 ++++++++++++++++++-
> > >>> drivers/gpu/drm/sun4i/sun4i_layer.h | 2 +-
> > >>> drivers/gpu/drm/sun4i/sunxi_layer.h | 17 +++++++++++++++++
> > >>> 5 files changed, 49 insertions(+), 11 deletions(-)
> > >>> create mode 100644 drivers/gpu/drm/sun4i/sunxi_layer.h
> > >>>
> > >>> diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> > >>> b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> > >>> index 3c876c3a356a..33854ee7f636 100644
> > >>> --- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> > >>> +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> > >>> @@ -29,6 +29,7 @@
> > >>> #include "sun4i_crtc.h"
> > >>> #include "sun4i_drv.h"
> > >>> #include "sun4i_layer.h"
> > >>> +#include "sunxi_layer.h"
> > >>> #include "sun4i_tcon.h"
> > >>>
> > >>> static void sun4i_crtc_atomic_begin(struct drm_crtc *crtc,
> > >>> @@ -149,7 +150,7 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device
> > >>> *drm,
> > >>> scrtc->tcon = tcon;
> > >>>
> > >>> /* Create our layers */
> > >>> - scrtc->layers = sun4i_layers_init(drm, scrtc->backend);
> > >>> + scrtc->layers = (void **)sun4i_layers_init(drm, scrtc);
> > >>> if (IS_ERR(scrtc->layers)) {
> > >>> dev_err(drm->dev, "Couldn't create the planes\n");
> > >>> return NULL;
> > >>> @@ -157,14 +158,15 @@ struct sun4i_crtc *sun4i_crtc_init(struct
> > >>> drm_device *drm,
> > >>>
> > >>> /* find primary and cursor planes for drm_crtc_init_with_planes
> > >>> */
> > >>> for (i = 0; scrtc->layers[i]; i++) {
> > >>> - struct sun4i_layer *layer = scrtc->layers[i];
> > >>> + void *layer = scrtc->layers[i];
> > >>> + struct drm_plane *plane =
> > >>> scrtc->layer_ops->get_plane(layer);
> > >>>
> > >>> - switch (layer->plane.type) {
> > >>> + switch (plane->type) {
> > >>> case DRM_PLANE_TYPE_PRIMARY:
> > >>> - primary = &layer->plane;
> > >>> + primary = plane;
> > >>> break;
> > >>> case DRM_PLANE_TYPE_CURSOR:
> > >>> - cursor = &layer->plane;
> > >>> + cursor = plane;
> > >>> break;
> > >>> default:
> > >>> break;
> > >>> @@ -190,10 +192,11 @@ struct sun4i_crtc *sun4i_crtc_init(struct
> > >>> drm_device *drm,
> > >>> /* Set possible_crtcs to this crtc for overlay planes */
> > >>> for (i = 0; scrtc->layers[i]; i++) {
> > >>> uint32_t possible_crtcs =
> > >>> BIT(drm_crtc_index(&scrtc->crtc));
> > >>> - struct sun4i_layer *layer = scrtc->layers[i];
> > >>> + void *layer = scrtc->layers[i];
> > >>> + struct drm_plane *plane =
> > >>> scrtc->layer_ops->get_plane(layer);
> > >>>
> > >>> - if (layer->plane.type == DRM_PLANE_TYPE_OVERLAY)
> > >>> - layer->plane.possible_crtcs = possible_crtcs;
> > >>> + if (plane->type == DRM_PLANE_TYPE_OVERLAY)
> > >>> + plane->possible_crtcs = possible_crtcs;
> > >>> }
> > >>>
> > >>> return scrtc;
> > >>> diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.h
> > >>> b/drivers/gpu/drm/sun4i/sun4i_crtc.h
> > >>> index 230cb8f0d601..a4036ee44cf8 100644
> > >>> --- a/drivers/gpu/drm/sun4i/sun4i_crtc.h
> > >>> +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.h
> > >>> @@ -19,7 +19,8 @@ struct sun4i_crtc {
> > >>>
> > >>> struct sun4i_backend *backend;
> > >>> struct sun4i_tcon *tcon;
> > >>> - struct sun4i_layer **layers;
> > >>> + void **layers;
> > >>> + const struct sunxi_layer_ops *layer_ops;
> > >>
> > >>
> > >> I think you should probably take a different approach to abstract the
> > >> layer
> > >> type. How about creating
> > >>
> > >> struct sunxi_layer {
> > >> struct drm_plane plane;
> > >> }
> > >>
> > >> base and then subclassing that for sun4i and sun8i? By doing this you can
> > >> avoid
> > >> the nasty casting and you can also get rid of the get_plane() hook and
> > >> layer_ops.
> > >
> > >
> > > For the situation that using ** things are easily to get weird.
> >
> > That code could be reworked, by initializing the layers directly within
> > the crtc init code. If you look at rockchip's drm driver, you'll see
> > they do this. There is a good reason to do it this way, as you need
> > to first create the primary and cursor layers, pass them in when you
> > create the crtc, then initialize any additional layers with the
> > possible_crtcs bitmap.
>
> But furthurly maybe more layers will be created for DE2 mixer, and
> may even depends on mixer type (On A83T/H3/A64/H5 mixer1 has fewer
> channel than mixer0).
You'll always have one primary and one cursor plane, no matter how
much planes you support.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Re: [PATCH 10/11] arm64: allwinner: a64: enable AXP803 regulators for Pine64
From: Maxime Ripard @ 2017-04-05 8:08 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, linux-kernel, devicetree-u79uwXL29TY76Z2rM5mHXA,
Lee Jones, Liam Girdwood,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Chen-Yu Tsai
In-Reply-To: <20170405061552.C15201033DF-Y9/x5g2N/Tt0ykcd9G8QkxTxI0vvWBSX@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4689 bytes --]
On Wed, Apr 05, 2017 at 02:15:43PM +0800, Icenowy Zheng wrote:
>
> 2017年4月5日 14:13于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
> >
> > On Wed, Apr 05, 2017 at 02:01:44AM +0800, Icenowy Zheng wrote:
> > > Add support of AXP803 regulators in the Pine64 device tree, in order to
> > > enable many future functionalities, e.g. Wi-Fi.
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> > > ---
> > > .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
> > > 1 file changed, 109 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > > index 2132d8e6cb3d..7da074f95065 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > > @@ -106,6 +106,115 @@
> > > };
> > > };
> > >
> > > +#include "axp803.dtsi"
> > > +
> > > +®_aldo1 {
> > > + regulator-min-microvolt = <2800000>;
> > > + regulator-max-microvolt = <2800000>;
> > > + regulator-name = "vcc-csi";
> > > +};
> > > +
> > > +®_aldo2 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <1800000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-name = "vcc-pl";
> > > +};
> > > +
> > > +®_aldo3 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <2700000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-name = "vcc-pll-avcc";
> > > +};
> > > +
> > > +®_dc1sw {
> > > + regulator-name = "vcc-phy";
> > > +};
> > > +
> > > +®_dcdc1 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-name = "vcc-3v3";
> > > +};
> > > +
> > > +®_dcdc2 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <1000000>;
> > > + regulator-max-microvolt = <1300000>;
> > > + regulator-name = "vdd-cpux";
> > > +};
> > > +
> > > +/* DCDC3 is polyphased with DCDC2 */
> > > +
> > > +®_dcdc5 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <1500000>;
> > > + regulator-max-microvolt = <1500000>;
> > > + regulator-name = "vcc-dram";
> > > +};
> > > +
> > > +®_dcdc6 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <1100000>;
> > > + regulator-max-microvolt = <1100000>;
> > > + regulator-name = "vdd-sys";
> > > +};
> > > +
> > > +®_dldo1 {
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-name = "vcc-hdmi";
> > > +};
> > > +
> > > +®_dldo2 {
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-name = "vcc-mipi";
> > > +};
> > > +
> > > +®_dldo3 {
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-name = "avdd-csi";
> > > +};
> > > +
> > > +®_dldo4 {
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-name = "vcc-wifi";
> > > +};
> > > +
> > > +®_eldo1 {
> > > + regulator-min-microvolt = <1800000>;
> > > + regulator-max-microvolt = <1800000>;
> > > + regulator-name = "cpvdd";
> > > +};
> > > +
> > > +®_eldo3 {
> > > + regulator-min-microvolt = <1800000>;
> > > + regulator-max-microvolt = <1800000>;
> > > + regulator-name = "vdd-1v8-csi";
> > > +};
> > > +
> > > +®_fldo1 {
> > > + regulator-min-microvolt = <1200000>;
> > > + regulator-max-microvolt = <1200000>;
> > > + regulator-name = "vcc-1v2-hsic";
> > > +};
> > > +
> > > +®_fldo2 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <1100000>;
> > > + regulator-max-microvolt = <1100000>;
> > > + regulator-name = "vdd-cpus";
> > > +};
> >
> > Why do you need to always power the AR100 on?
>
> It's for CPUS power domain, not the AR100 processor.
>
> Kill it will lead to instantly system hang.
What are you calling CPUS then?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: cpu of_node links broken
From: Benjamin Herrenschmidt @ 2017-04-05 7:58 UTC (permalink / raw)
To: Wesley Terpstra; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAMgXwThRqAO0vG0QVC7LYO2Srf9inh+osw7+u21abRVhH0LDSA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 2017-04-04 at 23:49 -0700, Wesley Terpstra wrote:
> On Tue, Apr 4, 2017 at 11:41 PM, Benjamin Herrenschmidt
> <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> wrote:
> > > [ 0.010000] cpu cpu0: Error -2 creating of_node link
> >
> > Interesting. I've never seen that error, I wonder if that's because
> > we fail to link the CPU to an OF node to begin with on our
> > platforms.
>
> You can find quite a few dmesg traces on google that include the
> warning. It affects at least nios2, microblaze and riscv.
>
> It's because the 'sd' pointer in the of_node's kobject is null, which
> causes sysfs_do_create_link_sd to return -ENOENT. AFAICT, it's null
> because the device tree nodes have not yet been linked into sysfs;
> that is what of_core_init() does.
>
> > Devices might try to create symlinks to device-tree nodes,
> > thus all devices that have OF node linkages should be created
> > after of_core_init() has been called.
>
> Your proposed patch fixes the warning for me on riscv.
Thanks. I'll smoke-test it on powerpc tomorrow (and figure out why we
don't hit the warning) and submit it formally to Greg.
Remind me if I forget, I'm rather swamped these days :)
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] drm: rcar-du: Document the vsps property in the DT bindings
From: Geert Uytterhoeven @ 2017-04-05 7:54 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Laurent Pinchart, Sergei Shtylyov, devicetree@vger.kernel.org,
DRI Development, Linux-Renesas
In-Reply-To: <CAMuHMdWSuz79mdHLuT4jDQsNvecFck21aBNLOrs5JHmMXnyTCQ@mail.gmail.com>
Hi Laurent,
On Fri, Mar 31, 2017 at 11:21 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, Mar 31, 2017 at 11:19 AM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
>> On Monday 27 Mar 2017 13:05:48 Geert Uytterhoeven wrote:
>>> On Mon, Mar 27, 2017 at 11:56 AM, Laurent Pinchart wrote:
>>> > The property is used by the driver but is missing from the DT bindings.
>>> > Document it.
>>> >
>>> > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>> > Signed-off-by: Laurent Pinchart
>>> > <laurent.pinchart+renesas@ideasonboard.com>
>>> > ---
>>> > Documentation/devicetree/bindings/display/renesas,du.txt | 5 +++++
>>> > 1 file changed, 5 insertions(+)
>>> >
>>> > diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
>>> > b/Documentation/devicetree/bindings/display/renesas,du.txt index
>>> > 1a02f099a0ff..cf34893a1b53 100644
>>> > --- a/Documentation/devicetree/bindings/display/renesas,du.txt
>>> > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
>>> >
>>> > @@ -36,6 +36,11 @@ Required Properties:
>>> > When supplied they must be named "dclkin.x" with "x" being the
>>> > input
>>> > clock numerical index.
>>> >
>>> > +Optional Properties:
>>> > +
>>> > + - vsps: A list of phandles to the VSP nodes that handle the memory
>>> > + interfaces for the DU channels (Gen3 only).
>>>
>>> ", one per channel"?
>>>
>>> Required for Gen3, optional for Gen2? (cfr. Sergei's patches).
>>
>> How about making it mandatory on Gen2 as well ? The VSPs are there, even if
>> the driver doesn't use them, it makes sense to describe the connection. Of
>
> Fine for me, as this is hardware description.
>
>> course the driver will treat the property as optional for backward
>> compatibility.
>
> OK.
Will you do this as an incremental update?
I noticed the initial version is now in drm-next.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/3] arm64: allwinner: a64: add USB0 OHCI/EHCI related devicetree parts
From: Icenowy Zheng @ 2017-04-05 7:33 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Kishon Vijay Abraham I, linux-arm-kernel,
devicetree, linux-kernel, linux-sunxi
In-Reply-To: <20170405072631.ou4e5gafvagwpykq@lukather>
在 2017年04月05日 15:26, Maxime Ripard 写道:
> On Wed, Apr 05, 2017 at 03:17:19PM +0800, Icenowy Zheng wrote:
>>
>>
>> 在 2017年04月05日 15:15, Maxime Ripard 写道:
>>> On Wed, Apr 05, 2017 at 02:45:17AM +0800, Icenowy Zheng wrote:
>>>> As we added USB0 route auto switching support for A64, add related
>>>> device tree parts to the A64 DTSI file (EHCI0/OHCI0 controllers and the
>>>> pmu0 memory area for PHY).
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>> ---
>>>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 ++++++++++++++++++++++++
>>>> 1 file changed, 24 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> index 1c64ea2d23f9..a8916df99048 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> @@ -179,8 +179,10 @@
>>>> usbphy: phy@01c19400 {
>>>> compatible = "allwinner,sun50i-a64-usb-phy";
>>>> reg = <0x01c19400 0x14>,
>>>> + <0x01c1a800 0x4>,
>>>> <0x01c1b800 0x4>;
>>>> reg-names = "phy_ctrl",
>>>> + "pmu0",
>>>
>>> This breaks the older DTs, and that property isn't documented.
>>
>> It's already documented.
>>
>> In the H3 dual-route patchset I have already added this.
>>
>> (" * "pmu0" for H3, V3s and A64")
>
> This is not in linux-next then, sorry.
It's already in next-20160405.
>
>> P.S. to be compatible with older DTs, I think I should adjust
>> the phy driver, make it enable dual-route function only when
>> pmu0 is present.
>
> That, or if we're quick enough, we can still add it to 4.11. There's a
> bit of time left.
Thus the device tree binding patch and the DT part of this patchset
should be all pushed to 4.11 .
The device tree binding patch is commit ee73fd7dfc86 ("dt: bindings: add
pmu0 regs for USB PHYs on Allwinner H3/V3s/A64").
>
> Maxime
>
^ permalink raw reply
* Re: [PATCH 02/11] arm64: allwinner: a64: add NMI controller on A64
From: Maxime Ripard @ 2017-04-05 7:28 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Icenowy Zheng, Lee Jones, Rob Herring, Liam Girdwood, devicetree,
linux-sunxi, linux-kernel, linux-arm-kernel
In-Reply-To: <CAGb2v672Z2JedGF3n+8Hi78QG_hAxz0ZYXaCkw0GAkA3xEdKrA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]
On Wed, Apr 05, 2017 at 02:20:31PM +0800, Chen-Yu Tsai wrote:
> On Wed, Apr 5, 2017 at 2:11 PM, Maxime Ripard
> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > On Wed, Apr 05, 2017 at 11:51:45AM +0800, Chen-Yu Tsai wrote:
> >> On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> >> > Allwinner A64 SoC features a NMI controller, which is usually connected
> >> > to the AXP PMIC.
> >> >
> >> > Add support for it.
> >> >
> >> > Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> >>
> >> This might not be the best representation of the R_INTC block. Though
> >> we'd need to change it for all SoCs if we want to be accurate. For now,
> >
> > What do you think would be a good representation?
>
> My gut feeling is that this is the old INTC from sun4/5i.
Ah, that would make sense.
> It's supposed to be the interrupt controller for the embedded low
> power core. I've not done a thorough comparison though.
Do we have some documentation / code for this one?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 2/3] arm64: allwinner: a64: add USB0 OHCI/EHCI related devicetree parts
From: Maxime Ripard @ 2017-04-05 7:26 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Kishon Vijay Abraham I,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <7828ffa0-f570-9841-a9e6-fe175f8169ac-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]
On Wed, Apr 05, 2017 at 03:17:19PM +0800, Icenowy Zheng wrote:
>
>
> 在 2017年04月05日 15:15, Maxime Ripard 写道:
> > On Wed, Apr 05, 2017 at 02:45:17AM +0800, Icenowy Zheng wrote:
> > > As we added USB0 route auto switching support for A64, add related
> > > device tree parts to the A64 DTSI file (EHCI0/OHCI0 controllers and the
> > > pmu0 memory area for PHY).
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> > > ---
> > > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 ++++++++++++++++++++++++
> > > 1 file changed, 24 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > index 1c64ea2d23f9..a8916df99048 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > @@ -179,8 +179,10 @@
> > > usbphy: phy@01c19400 {
> > > compatible = "allwinner,sun50i-a64-usb-phy";
> > > reg = <0x01c19400 0x14>,
> > > + <0x01c1a800 0x4>,
> > > <0x01c1b800 0x4>;
> > > reg-names = "phy_ctrl",
> > > + "pmu0",
> >
> > This breaks the older DTs, and that property isn't documented.
>
> It's already documented.
>
> In the H3 dual-route patchset I have already added this.
>
> (" * "pmu0" for H3, V3s and A64")
This is not in linux-next then, sorry.
> P.S. to be compatible with older DTs, I think I should adjust
> the phy driver, make it enable dual-route function only when
> pmu0 is present.
That, or if we're quick enough, we can still add it to 4.11. There's a
bit of time left.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] arm64: allwinner: a64: add USB0 OHCI/EHCI related devicetree parts
From: Icenowy Zheng @ 2017-04-05 7:17 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Kishon Vijay Abraham I,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405071508.yaur35xuli4jgkfb@lukather>
在 2017年04月05日 15:15, Maxime Ripard 写道:
> On Wed, Apr 05, 2017 at 02:45:17AM +0800, Icenowy Zheng wrote:
>> As we added USB0 route auto switching support for A64, add related
>> device tree parts to the A64 DTSI file (EHCI0/OHCI0 controllers and the
>> pmu0 memory area for PHY).
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 ++++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index 1c64ea2d23f9..a8916df99048 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -179,8 +179,10 @@
>> usbphy: phy@01c19400 {
>> compatible = "allwinner,sun50i-a64-usb-phy";
>> reg = <0x01c19400 0x14>,
>> + <0x01c1a800 0x4>,
>> <0x01c1b800 0x4>;
>> reg-names = "phy_ctrl",
>> + "pmu0",
>
> This breaks the older DTs, and that property isn't documented.
It's already documented.
In the H3 dual-route patchset I have already added this.
(" * "pmu0" for H3, V3s and A64")
P.S. to be compatible with older DTs, I think I should adjust
the phy driver, make it enable dual-route function only when
pmu0 is present.
>
> Maxime
>
--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 2/3] arm64: allwinner: a64: add USB0 OHCI/EHCI related devicetree parts
From: Maxime Ripard @ 2017-04-05 7:15 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Kishon Vijay Abraham I, linux-arm-kernel,
devicetree, linux-kernel, linux-sunxi
In-Reply-To: <20170404184518.33610-2-icenowy@aosc.io>
[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]
On Wed, Apr 05, 2017 at 02:45:17AM +0800, Icenowy Zheng wrote:
> As we added USB0 route auto switching support for A64, add related
> device tree parts to the A64 DTSI file (EHCI0/OHCI0 controllers and the
> pmu0 memory area for PHY).
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 1c64ea2d23f9..a8916df99048 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -179,8 +179,10 @@
> usbphy: phy@01c19400 {
> compatible = "allwinner,sun50i-a64-usb-phy";
> reg = <0x01c19400 0x14>,
> + <0x01c1a800 0x4>,
> <0x01c1b800 0x4>;
> reg-names = "phy_ctrl",
> + "pmu0",
This breaks the older DTs, and that property isn't documented.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] phy: sun4i-usb: enable PHY0 dual route switching for A64 USB PHY
From: Maxime Ripard @ 2017-04-05 7:03 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Kishon Vijay Abraham I,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170404184518.33610-1-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 554 bytes --]
On Wed, Apr 05, 2017 at 02:45:16AM +0800, Icenowy Zheng wrote:
> Allwinner A64 SoC features a switchable PHY0 like the one in H3, which
> can switch between a MUSB controller and a pair of OHCI/EHCI controller.
>
> Enable PHY0 route auto switching for A64.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: cpu of_node links broken
From: Wesley Terpstra @ 2017-04-05 6:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491374467.4166.81.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
On Tue, Apr 4, 2017 at 11:41 PM, Benjamin Herrenschmidt
<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> wrote:
>> [ 0.010000] cpu cpu0: Error -2 creating of_node link
> Interesting. I've never seen that error, I wonder if that's because
> we fail to link the CPU to an OF node to begin with on our platforms.
You can find quite a few dmesg traces on google that include the
warning. It affects at least nios2, microblaze and riscv.
It's because the 'sd' pointer in the of_node's kobject is null, which
causes sysfs_do_create_link_sd to return -ENOENT. AFAICT, it's null
because the device tree nodes have not yet been linked into sysfs;
that is what of_core_init() does.
> Devices might try to create symlinks to device-tree nodes,
> thus all devices that have OF node linkages should be created
> after of_core_init() has been called.
Your proposed patch fixes the warning for me on riscv.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: cpu of_node links broken
From: Benjamin Herrenschmidt @ 2017-04-05 6:41 UTC (permalink / raw)
To: Wesley Terpstra, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAMgXwThQk=3V1HQ8YpoY57mpY0SrdyfAwS5szpsqwkS-r=FPAw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 2017-04-04 at 23:12 -0700, Wesley Terpstra wrote:
> In commit 5590f3196b293574a12be58d06d5e1120d8856ec symlinks from
> devices to their OF node were added.
Yup. I did that ;)
> Unfortunately, the code looks for them in cpu_dev_init before they
> exist (of_core_init has not run).
> This results in:
> [ 0.010000] cpu cpu0: Error -2 creating of_node link
>
> I don't know if this code used to work and it got broken, but as of
> 4.6 it does not work and still does not work in 4.11. Moving
> of_core_init() before platform_bus_init() in driver_init()
> [drivers/base/init.c] fixes the problem for me.
>
> Is there any downside to reordering these function calls?
Interesting. I've never seen that error, I wonder if that's because
we fail to link the CPU to an OF node to begin with on our platforms.
I agree though. of_core_init() should probably be called before
we create any device that might have an OF node reference.
In fact we should probably be able to move it right before
platform_bus_init(). Something like this (untested):
[PATCH] drivers/base: Initialize OF sysfs core before creating devices
Devices might try to create symlinks to device-tree nodes,
thus all devices that have OF node linkages should be created
after of_core_init() has been called.
This especially includes cpu_dev_init().
Reported-by: Wesley Terpstra <wesley-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org>
Signed-off-when-somebody-tests-it-by: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
---
diff --git a/drivers/base/init.c b/drivers/base/init.c
index 48c0e22..f65d686 100644
--- a/drivers/base/init.c
+++ b/drivers/base/init.c
@@ -28,6 +28,13 @@ void __init driver_init(void)
firmware_init();
hypervisor_init();
+ /*
+ * This relies on the firmware_kobj already existing
+ * and should be done before any device that might have
+ * an OF link is created
+ */
+ of_core_init();
+
/* These are also core pieces, but must come after the
* core core pieces.
*/
@@ -35,5 +42,4 @@ void __init driver_init(void)
cpu_dev_init();
memory_dev_init();
container_dev_init();
- of_core_init();
}
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/2] doc: Add bindings document for Xilinx LogiCore PR Decoupler
From: Michal Simek @ 2017-04-05 6:26 UTC (permalink / raw)
To: Moritz Fischer, Rob Herring
Cc: Alan Tull, Greg Kroah-Hartman, Linux Kernel Mailing List,
linux-fpga, Moritz Fischer, Michal Simek, Sören Brinkmann,
Devicetree List
In-Reply-To: <CAAtXAHe0qnu7Ub6sing4VUgFa-tkdvH767kNbZnu1S5THHS2oQ@mail.gmail.com>
On 5.4.2017 01:36, Moritz Fischer wrote:
> On Thu, Mar 30, 2017 at 05:44:29PM -0500, Rob Herring wrote:
>> On Fri, Mar 24, 2017 at 10:33:20AM -0500, Alan Tull wrote:
>>> From: Moritz Fischer <mdf@kernel.org>
>>
>> Please use "dt-bindings: fpga: ..." for the subject.
>>
>>
>>>
>>> This adds the binding documentation for the Xilinx LogiCORE PR
>>> Decoupler soft core.
>>>
>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>>> Acked-by: Alan Tull <atull@kernel.org>
>>
>> I'm confused why you are sending these instead of Moritz? If it goes
>> through you, then it should have your S-o-B too.
>
> Do you want me to resend this Alan (with Rob's suggestions)?
>>
>>> Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
>>> Cc: linux-kernel@vger.kernel.org
>>> Cc: devicetree@vger.kernel.org
>>> ---
>>> .../bindings/fpga/xilinx-pr-decoupler.txt | 35 ++++++++++++++++++++++
>>> 1 file changed, 35 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>>> new file mode 100644
>>> index 000000000000..2c527ac30398
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>>> @@ -0,0 +1,35 @@
>>> +Xilinx LogiCORE Partial Reconfig Decoupler Softcore
>>> +
>>> +The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
>>> +decouplers / fpga bridges.
>>> +The controller can decouple/disable the bridges which prevents signal
>>> +changes from passing through the bridge. The controller can also
>>> +couple / enable the bridges which allows traffic to pass through the
>>> +bridge normally.
>>> +
>>> +The Driver supports only MMIO handling. A PR region can have multiple
>>> +PR Decouplers which can be handled independently or chained via decouple/
>>> +decouple_status signals.
>>> +
>>> +Required properties:
>>> +- compatible : Should contain "xlnx,pr-decoupler-1.00" or "xlnx,pr-decoupler"
>>
>> I'd drop xlnx,pr-decoupler, but in any case, it should not be OR rather
>> "followed by". Plus the example has both.
>
> Michal wanted to have both, so I put both. Personally I don't care. I
> think they have some downstream stuff that relied on it.
Agree with Rob with using "followed by" instead of or.
M
^ permalink raw reply
* Re: [PATCH] mmc: core: add mmc-card hardware reset enable support
From: Richard Leitner @ 2017-04-05 6:23 UTC (permalink / raw)
To: Jaehoon Chung, ulf.hansson, robh+dt, mark.rutland
Cc: shawn.lin, adrian.hunter, linus.walleij, linux-mmc, linux-kernel,
devicetree, dev
In-Reply-To: <ea610a5c-3857-14f8-3039-414bee724223@samsung.com>
On 04/05/2017 06:40 AM, Jaehoon Chung wrote:
> Hi,
>
> On 04/04/2017 11:16 PM, Richard Leitner wrote:
>> Some eMMCs disable their hardware reset line (RST_N) by default. To enable
>> it the host must set the corresponding bit in ECSD. An example for such
>> a device is the Micron MTFCxGACAANA-4M.
>>
>> This patch adds a new mmc-card devicetree property to let the host enable
>> this feature during card initialization.
>>
>> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
>> ---
>> Documentation/devicetree/bindings/mmc/mmc-card.txt | 3 +++
>> drivers/mmc/core/mmc.c | 21 +++++++++++++++++++++
>> 2 files changed, 24 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.txt b/Documentation/devicetree/bindings/mmc/mmc-card.txt
>> index a70fcd6..8590a40 100644
>> --- a/Documentation/devicetree/bindings/mmc/mmc-card.txt
>> +++ b/Documentation/devicetree/bindings/mmc/mmc-card.txt
>> @@ -12,6 +12,9 @@ Required properties:
>> Optional properties:
>> -broken-hpi : Use this to indicate that the mmc-card has a broken hpi
>> implementation, and that hpi should not be used
>> +-enable-hw-reset : some eMMC devices have disabled the hw reset functionality
>> + (RST_N_FUNCTION) by default. By adding this property the
>> + host will enable it during initialization.
>
> As i know, RST_N_FUNCTION is controlled bit[1:0]
> 0x0 : RST_n disabled (by default)
> 0x1 : permanently enabled
> 0x2 : permanently disabled
>
> I think that it needs to add the description about these..
Ok.
>>
>> Example:
>>
>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> index b502601..518d0e3 100644
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -1520,9 +1520,16 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
>> int err;
>> u32 cid[4];
>> u32 rocr;
>> + struct device_node *np;
>> + bool enable_rst_n = false;
>>
>> WARN_ON(!host->claimed);
>>
>> + np = mmc_of_find_child_device(host, 0);
>> + if (np && of_device_is_compatible(np, "mmc-card"))
>> + enable_rst_n = of_property_read_bool(np, "enable-hw-reset");
>> + of_node_put(np);
>> +
>> /* Set correct bus mode for MMC before attempting init */
>> if (!mmc_host_is_spi(host))
>> mmc_set_bus_mode(host, MMC_BUSMODE_OPENDRAIN);
>> @@ -1810,6 +1817,20 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
>> }
>> }
>>
>> + /*
>> + * try to enable RST_N if requested
>> + * This is needed because some eMMC chips disable this function by
>> + * default.
>> + */
>> + if (enable_rst_n) {
>> + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> + EXT_CSD_RST_N_FUNCTION, EXT_CSD_RST_N_ENABLED,
>> + card->ext_csd.generic_cmd6_time);
>> + if (err && err != -EBADMSG)
>> + pr_warn("%s: Enabling RST_N feature failed\n",
>> + mmc_hostname(card->host));
>> + }
>
> If enabled hw-reset, it doesn't need to re-enable this bit.
Ok. I can add a check to prevent setting it, if it is set already.
> i didn't check the mmc-util..
> If mmc-util provides the changing this, the using mmc-util is better than this.
mmc-utils is providing a enable/disable hwreset feature. But as this
setting is required for my hardware to allow rebooting it, I thought it
would be better if it's in the kernel. So I/the hw doesn't have to
depend on userspace tools.
Nonetheless you're the experts, therefore if you say it shouldn't be in
the kernel/dt I'd be fine with that too. ;-)
^ permalink raw reply
* Re: [PATCH v4 0/6] ARM: dts: sunxi: Add CAN node and can0_pins_a pinctrl settings
From: Maxime Ripard @ 2017-04-05 6:22 UTC (permalink / raw)
To: Patrick Menschel
Cc: robh+dt, mark.rutland, linux, wens, devicetree, linux-arm-kernel,
linux-kernel, linux-can
In-Reply-To: <1491330992-9876-1-git-send-email-menschel.p@posteo.de>
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
On Tue, Apr 04, 2017 at 08:36:26PM +0200, Patrick Menschel wrote:
> The Allwinner A10/A20 SoCs have an on-board CAN (Controller Area Network)
> controller. This patch adds the CAN core to the SoC's include files,
> sun4i-a10.dtsi and sun7i-a20.dtsi.
>
> On linux-can mailing list was a discussion about updating the device tree bindings
> https://lkml.org/lkml/2015/9/17/220
> but it did not progress past writing the documentation file.
> Documentation/devicetree/bindings/net/can/sun4i_can.txt
>
> The CAN controller can be enabled in a board specific dts file as
> described in the documentation file or by using a device tree overlay.
Applied 1 and 4. The others were already merged.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 02/11] arm64: allwinner: a64: add NMI controller on A64
From: Chen-Yu Tsai @ 2017-04-05 6:20 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Icenowy Zheng, Lee Jones, Rob Herring,
Liam Girdwood, devicetree, linux-sunxi, linux-kernel,
linux-arm-kernel
In-Reply-To: <20170405061137.n66ectbkl7a2fv5f@lukather>
On Wed, Apr 5, 2017 at 2:11 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Wed, Apr 05, 2017 at 11:51:45AM +0800, Chen-Yu Tsai wrote:
>> On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>> > Allwinner A64 SoC features a NMI controller, which is usually connected
>> > to the AXP PMIC.
>> >
>> > Add support for it.
>> >
>> > Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>
>> This might not be the best representation of the R_INTC block. Though
>> we'd need to change it for all SoCs if we want to be accurate. For now,
>
> What do you think would be a good representation?
My gut feeling is that this is the old INTC from sun4/5i. It's supposed
to be the interrupt controller for the embedded low power core. I've not
done a thorough comparison though.
ChenYu
^ permalink raw reply
* RE: [PATCH 1/2 v2] dt-bindings: qoriq-clock: Add coreclk
From: Andy Tang @ 2017-04-05 6:16 UTC (permalink / raw)
To: mturquette@baylibre.com, sboyd@codeaurora.org
Cc: robh+dt@kernel.org, mark.rutland@arm.com,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Scott Wood
In-Reply-To: <1489977443-33582-1-git-send-email-andy.tang@nxp.com>
Hello Stephen and Michael,
Do you have any comments on this patch set which was acked by Rob?
Regards,
Andy
> -----Original Message-----
> From: Yuantian Tang [mailto:andy.tang@nxp.com]
> Sent: Monday, March 20, 2017 10:37 AM
> To: mturquette@baylibre.com
> Cc: sboyd@codeaurora.org; robh+dt@kernel.org; mark.rutland@arm.com;
> linux-clk@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; Scott Wood
> <oss@buserror.net>; Andy Tang <andy.tang@nxp.com>
> Subject: [PATCH 1/2 v2] dt-bindings: qoriq-clock: Add coreclk
>
> From: Scott Wood <oss@buserror.net>
>
> ls1012a has separate input root clocks for core PLLs versus the platform PLL,
> with the latter described as sysclk in the hw docs.
> Update the qoriq-clock binding to allow a second input clock, named
> "coreclk". If present, this clock will be used for the core PLLs.
>
> Signed-off-by: Scott Wood <oss@buserror.net>
> Signed-off-by: Tang Yuantian <andy.tang@nxp.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> v2:
> -- change the author to Scott
> Documentation/devicetree/bindings/clock/qoriq-clock.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> index aa3526f..119cafd 100644
> --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> @@ -56,6 +56,11 @@ Optional properties:
> - clocks: If clock-frequency is not specified, sysclk may be provided
> as an input clock. Either clock-frequency or clocks must be
> provided.
> + A second input clock, called "coreclk", may be provided if
> + core PLLs are based on a different input clock from the
> + platform PLL.
> +- clock-names: Required if a coreclk is present. Valid names are
> + "sysclk" and "coreclk".
>
> 2. Clock Provider
>
> @@ -72,6 +77,7 @@ second cell is the clock index for the specified type.
> 2 hwaccel index (n in CLKCGnHWACSR)
> 3 fman 0 for fm1, 1 for fm2
> 4 platform pll 0=pll, 1=pll/2, 2=pll/3, 3=pll/4
> + 5 coreclk must be 0
>
> 3. Example
>
> --
> 2.1.0.27.g96db324
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 10/11] arm64: allwinner: a64: enable AXP803 regulators for Pine64
From: Icenowy Zheng @ 2017-04-05 6:15 UTC (permalink / raw)
To: Maxime Ripard
Cc: Rob Herring, linux-kernel, devicetree, Lee Jones, Liam Girdwood,
linux-arm-kernel, linux-sunxi, Chen-Yu Tsai
2017年4月5日 14:13于 Maxime Ripard <maxime.ripard@free-electrons.com>写道：
>
> On Wed, Apr 05, 2017 at 02:01:44AM +0800, Icenowy Zheng wrote:
> > Add support of AXP803 regulators in the Pine64 device tree, in order to
> > enable many future functionalities, e.g. Wi-Fi.
> >
> > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > ---
> > .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
> > 1 file changed, 109 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > index 2132d8e6cb3d..7da074f95065 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > @@ -106,6 +106,115 @@
> > };
> > };
> >
> > +#include "axp803.dtsi"
> > +
> > +®_aldo1 {
> > + regulator-min-microvolt = <2800000>;
> > + regulator-max-microvolt = <2800000>;
> > + regulator-name = "vcc-csi";
> > +};
> > +
> > +®_aldo2 {
> > + regulator-always-on;
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-name = "vcc-pl";
> > +};
> > +
> > +®_aldo3 {
> > + regulator-always-on;
> > + regulator-min-microvolt = <2700000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-name = "vcc-pll-avcc";
> > +};
> > +
> > +®_dc1sw {
> > + regulator-name = "vcc-phy";
> > +};
> > +
> > +®_dcdc1 {
> > + regulator-always-on;
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-name = "vcc-3v3";
> > +};
> > +
> > +®_dcdc2 {
> > + regulator-always-on;
> > + regulator-min-microvolt = <1000000>;
> > + regulator-max-microvolt = <1300000>;
> > + regulator-name = "vdd-cpux";
> > +};
> > +
> > +/* DCDC3 is polyphased with DCDC2 */
> > +
> > +®_dcdc5 {
> > + regulator-always-on;
> > + regulator-min-microvolt = <1500000>;
> > + regulator-max-microvolt = <1500000>;
> > + regulator-name = "vcc-dram";
> > +};
> > +
> > +®_dcdc6 {
> > + regulator-always-on;
> > + regulator-min-microvolt = <1100000>;
> > + regulator-max-microvolt = <1100000>;
> > + regulator-name = "vdd-sys";
> > +};
> > +
> > +®_dldo1 {
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-name = "vcc-hdmi";
> > +};
> > +
> > +®_dldo2 {
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-name = "vcc-mipi";
> > +};
> > +
> > +®_dldo3 {
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-name = "avdd-csi";
> > +};
> > +
> > +®_dldo4 {
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-name = "vcc-wifi";
> > +};
> > +
> > +®_eldo1 {
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + regulator-name = "cpvdd";
> > +};
> > +
> > +®_eldo3 {
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + regulator-name = "vdd-1v8-csi";
> > +};
> > +
> > +®_fldo1 {
> > + regulator-min-microvolt = <1200000>;
> > + regulator-max-microvolt = <1200000>;
> > + regulator-name = "vcc-1v2-hsic";
> > +};
> > +
> > +®_fldo2 {
> > + regulator-always-on;
> > + regulator-min-microvolt = <1100000>;
> > + regulator-max-microvolt = <1100000>;
> > + regulator-name = "vdd-cpus";
> > +};
>
> Why do you need to always power the AR100 on?
It's for CPUS power domain, not the AR100 processor.
Kill it will lead to instantly system hang.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.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+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox