* [PATCH v2 09/11] ARM: dts: sun8i-a33-sinlinx-sina33: use AXP223 DTSI
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
Previously, the Sinlinx SinA33 used everything declared in AXP221 DTSI
while it has an AXP223 PMIC.
This corrects that so the Sinlinx SinA33 can get some features the
AXP223 has (at the moment, ability to have 100mA as maximal current on
VBUS power supply).
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index fef6abc..1fc459c 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -145,7 +145,7 @@
};
};
-#include "axp22x.dtsi"
+#include "axp223.dtsi"
®_aldo1 {
regulator-always-on;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 08/11] ARM: dts: sun8i-a33-olinuxino: use AXP223 DTSI
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
Previously, the Olimex A33-OlinuXino used everything declared in AXP221
DTSI while it has an AXP223 PMIC.
This corrects that so the Olimex A33-OlinuXino can get some features the
AXP223 has (at the moment, ability to have 100mA as maximal current on
VBUS power supply).
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a33-olinuxino.dts b/arch/arm/boot/dts/sun8i-a33-olinuxino.dts
index 9ea637e..3e8f2ec 100644
--- a/arch/arm/boot/dts/sun8i-a33-olinuxino.dts
+++ b/arch/arm/boot/dts/sun8i-a33-olinuxino.dts
@@ -126,7 +126,7 @@
};
};
-#include "axp22x.dtsi"
+#include "axp223.dtsi"
®_aldo1 {
regulator-always-on;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 07/11] ARM: dtsi: add DTSI for AXP223
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
The AXP223 shares most of its logic with the AXP221 but it has some
differences for the VBUS driver.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
v2:
- adding small explanation of AXP223 variation compared to AXP221,
arch/arm/boot/dts/axp223.dtsi | 58 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
create mode 100644 arch/arm/boot/dts/axp223.dtsi
diff --git a/arch/arm/boot/dts/axp223.dtsi b/arch/arm/boot/dts/axp223.dtsi
new file mode 100644
index 0000000..b91b6c1
--- /dev/null
+++ b/arch/arm/boot/dts/axp223.dtsi
@@ -0,0 +1,58 @@
+/*
+ * Copyright 2016 Free Electrons
+ *
+ * Quentin Schulz <quentin.schulz@free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * AXP223 Integrated Power Management Chip
+ * http://www.x-powers.com/product/AXP22X.php
+ * http://dl.linux-sunxi.org/AXP/AXP223-en.pdf
+ *
+ * The AXP223 shares most of its logic with the AXP221 but it has some
+ * differences, for the VBUS driver for example.
+ */
+
+#include "axp22x.dtsi"
+
+&usb_power_supply {
+ compatible = "x-powers,axp223-usb-power-supply";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 06/11] mfd: axp20x: add separate MFD cell for AXP223
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
The AXP223 shares most of its logic with the AXP221 but has some
differences for the VBUS power supply driver. Thus, to probe the driver
with the correct compatible, the AXP221 and the AXP223 now have separate
MFD cells.
AXP221 MFD cells are renamed from axp22x_cells to axp221_cells to avoid
confusion.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
v2:
- correct indentation,
- renaming axp22x_cells to axp221_cells to avoid confusion between axp22x,
axp221 and axp223
drivers/mfd/axp20x.c | 28 ++++++++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 6ee2cc6..b31f123 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -591,7 +591,22 @@ static struct mfd_cell axp20x_cells[] = {
},
};
-static struct mfd_cell axp22x_cells[] = {
+static struct mfd_cell axp221_cells[] = {
+ {
+ .name = "axp20x-pek",
+ .num_resources = ARRAY_SIZE(axp22x_pek_resources),
+ .resources = axp22x_pek_resources,
+ }, {
+ .name = "axp20x-regulator",
+ }, {
+ .name = "axp20x-usb-power-supply",
+ .of_compatible = "x-powers,axp221-usb-power-supply",
+ .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
+ .resources = axp22x_usb_power_supply_resources,
+ },
+};
+
+static struct mfd_cell axp223_cells[] = {
{
.name = "axp20x-pek",
.num_resources = ARRAY_SIZE(axp22x_pek_resources),
@@ -600,7 +615,7 @@ static struct mfd_cell axp22x_cells[] = {
.name = "axp20x-regulator",
}, {
.name = "axp20x-usb-power-supply",
- .of_compatible = "x-powers,axp221-usb-power-supply",
+ .of_compatible = "x-powers,axp223-usb-power-supply",
.num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
.resources = axp22x_usb_power_supply_resources,
},
@@ -793,9 +808,14 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_irq_chip = &axp20x_regmap_irq_chip;
break;
case AXP221_ID:
+ axp20x->nr_cells = ARRAY_SIZE(axp221_cells);
+ axp20x->cells = axp221_cells;
+ axp20x->regmap_cfg = &axp22x_regmap_config;
+ axp20x->regmap_irq_chip = &axp22x_regmap_irq_chip;
+ break;
case AXP223_ID:
- axp20x->nr_cells = ARRAY_SIZE(axp22x_cells);
- axp20x->cells = axp22x_cells;
+ axp20x->nr_cells = ARRAY_SIZE(axp223_cells);
+ axp20x->cells = axp223_cells;
axp20x->regmap_cfg = &axp22x_regmap_config;
axp20x->regmap_irq_chip = &axp22x_regmap_irq_chip;
break;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 05/11] power: supply: axp20x_usb_power: add 100mA max current limit for AXP223
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
The X-Powers AXP223 shares most of its behaviour with the AXP221 PMIC
but allows the VBUS power supply max current to be set to 100mA (like
the AXP209 PMIC).
This basically adds a new compatible to the VBUS power supply driver and
adds a check on the compatible when setting current max limit.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/power/supply/axp20x_usb_power.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c
index 9e3f4ae..1bcb025 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -90,11 +90,10 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
switch (v & AXP20X_VBUS_CLIMIT_MASK) {
case AXP20X_VBUC_CLIMIT_100mA:
- if (power->axp20x_id == AXP202_ID) {
- val->intval = 100000;
- } else {
+ if (power->axp20x_id == AXP221_ID)
val->intval = -1; /* No 100mA limit */
- }
+ else
+ val->intval = 100000;
break;
case AXP20X_VBUC_CLIMIT_500mA:
val->intval = 500000;
@@ -317,7 +316,8 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
usb_power_desc = &axp20x_usb_power_desc;
irq_names = axp20x_irq_names;
- } else if (power->axp20x_id == AXP221_ID) {
+ } else if (power->axp20x_id == AXP221_ID ||
+ power->axp20x_id == AXP223_ID) {
usb_power_desc = &axp22x_usb_power_desc;
irq_names = axp22x_irq_names;
} else {
@@ -360,6 +360,9 @@ static const struct of_device_id axp20x_usb_power_match[] = {
}, {
.compatible = "x-powers,axp221-usb-power-supply",
.data = (void *)AXP221_ID,
+ }, {
+ .compatible = "x-powers,axp223-usb-power-supply",
+ .data = (void *)AXP223_ID,
}, { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
--
2.9.3
^ permalink raw reply related
* [PATCH v2 04/11] Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
This adds the "x-powers,axp223-usb-power-supply" to the list of
compatibles for AXP20X VBUS power supply driver.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
v2:
- adding small explanation on AXP223 variation compared to the AXP221,
Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
index f1d7bee..ba8d35f 100644
--- a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
+++ b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
@@ -3,6 +3,11 @@ AXP20x USB power supply
Required Properties:
-compatible: One of: "x-powers,axp202-usb-power-supply"
"x-powers,axp221-usb-power-supply"
+ "x-powers,axp223-usb-power-supply"
+
+The AXP223 PMIC shares most of its behaviour with the AXP221 but has slight
+variations such as the former being able to set the VBUS power supply max
+current to 100mA, unlike the latter.
This node is a subnode of the axp20x PMIC.
--
2.9.3
^ permalink raw reply related
* [PATCH v2 03/11] power: supply: axp20x_usb_power: set min voltage and max current from sysfs
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
AXP20X and AXP22X PMICs allow setting the min voltage and max current of
VBUS power supply. This adds entries in sysfs to allow to do so.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
v2:
- moving defines from header mfd/axp20x.h to the driver,
- adding two functions to reduce indentation in axp20x_usb_power_set_property,
- adding new define for VBUS register VHOLD bits offset,
- switching return values in case of invalid value from 0 to -EINVAL,
drivers/power/supply/axp20x_usb_power.c | 81 +++++++++++++++++++++++++++++++++
1 file changed, 81 insertions(+)
diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c
index 8985646..9e3f4ae 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -31,6 +31,8 @@
#define AXP20X_USB_STATUS_VBUS_VALID BIT(2)
#define AXP20X_VBUS_VHOLD_uV(b) (4000000 + (((b) >> 3) & 7) * 100000)
+#define AXP20X_VBUS_VHOLD_MASK GENMASK(5, 3)
+#define AXP20X_VBUS_VHOLD_OFFSET 3
#define AXP20X_VBUS_CLIMIT_MASK 3
#define AXP20X_VBUC_CLIMIT_900mA 0
#define AXP20X_VBUC_CLIMIT_500mA 1
@@ -155,6 +157,81 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
return 0;
}
+static int axp20x_usb_power_set_voltage_min(struct axp20x_usb_power *power,
+ int intval)
+{
+ int val;
+
+ switch (intval) {
+ case 4000000:
+ case 4100000:
+ case 4200000:
+ case 4300000:
+ case 4400000:
+ case 4500000:
+ case 4600000:
+ case 4700000:
+ val = (intval - 4000000) / 100000;
+ return regmap_update_bits(power->regmap,
+ AXP20X_VBUS_IPSOUT_MGMT,
+ AXP20X_VBUS_VHOLD_MASK,
+ val << AXP20X_VBUS_VHOLD_OFFSET);
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static int axp20x_usb_power_set_current_max(struct axp20x_usb_power *power,
+ int intval)
+{
+ int val;
+
+ switch (intval) {
+ case 100000:
+ if (power->axp20x_id == AXP221_ID)
+ return -EINVAL;
+ case 500000:
+ case 900000:
+ val = (900000 - intval) / 400000;
+ return regmap_update_bits(power->regmap,
+ AXP20X_VBUS_IPSOUT_MGMT,
+ AXP20X_VBUS_CLIMIT_MASK, val);
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static int axp20x_usb_power_set_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ const union power_supply_propval *val)
+{
+ struct axp20x_usb_power *power = power_supply_get_drvdata(psy);
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_VOLTAGE_MIN:
+ return axp20x_usb_power_set_voltage_min(power, val->intval);
+
+ case POWER_SUPPLY_PROP_CURRENT_MAX:
+ return axp20x_usb_power_set_current_max(power, val->intval);
+
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static int axp20x_usb_power_prop_writeable(struct power_supply *psy,
+ enum power_supply_property psp)
+{
+ return psp == POWER_SUPPLY_PROP_VOLTAGE_MIN ||
+ psp == POWER_SUPPLY_PROP_CURRENT_MAX;
+}
+
static enum power_supply_property axp20x_usb_power_properties[] = {
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_PRESENT,
@@ -178,7 +255,9 @@ static const struct power_supply_desc axp20x_usb_power_desc = {
.type = POWER_SUPPLY_TYPE_USB,
.properties = axp20x_usb_power_properties,
.num_properties = ARRAY_SIZE(axp20x_usb_power_properties),
+ .property_is_writeable = axp20x_usb_power_prop_writeable,
.get_property = axp20x_usb_power_get_property,
+ .set_property = axp20x_usb_power_set_property,
};
static const struct power_supply_desc axp22x_usb_power_desc = {
@@ -186,7 +265,9 @@ static const struct power_supply_desc axp22x_usb_power_desc = {
.type = POWER_SUPPLY_TYPE_USB,
.properties = axp22x_usb_power_properties,
.num_properties = ARRAY_SIZE(axp22x_usb_power_properties),
+ .property_is_writeable = axp20x_usb_power_prop_writeable,
.get_property = axp20x_usb_power_get_property,
+ .set_property = axp20x_usb_power_set_property,
};
static int axp20x_usb_power_probe(struct platform_device *pdev)
--
2.9.3
^ permalink raw reply related
* [PATCH v2 02/11] mfd: axp20x: add volatile and writeable reg ranges for VBUS power supply driver
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
The X-Powers AXP20X and AXP22X PMICs allow to choose the maximum voltage
and minimum current delivered by the VBUS power supply.
This adds the register used by the VBUS power supply driver to the range
of volatile and writeable regs ranges.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
added in v2
drivers/mfd/axp20x.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index ba130be..6ee2cc6 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -65,12 +65,14 @@ static const struct regmap_access_table axp152_volatile_table = {
static const struct regmap_range axp20x_writeable_ranges[] = {
regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
+ regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
};
static const struct regmap_range axp20x_volatile_ranges[] = {
regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_USB_OTG_STATUS),
+ regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL2),
regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
regmap_reg_range(AXP20X_ACIN_V_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
@@ -91,11 +93,13 @@ static const struct regmap_access_table axp20x_volatile_table = {
/* AXP22x ranges are shared with the AXP809, as they cover the same range */
static const struct regmap_range axp22x_writeable_ranges[] = {
regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
+ regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
};
static const struct regmap_range axp22x_volatile_ranges[] = {
regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_PWR_OP_MODE),
+ regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
regmap_reg_range(AXP22X_GPIO_STATE, AXP22X_GPIO_STATE),
regmap_reg_range(AXP20X_FG_RES, AXP20X_FG_RES),
--
2.9.3
^ permalink raw reply related
* [PATCH v2 01/11] power: supply: axp20x_usb_power: use of_device_id data field instead of device_is_compatible
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: thomas.petazzoni, devicetree, linux-pm, linux-kernel,
Quentin Schulz, linux-arm-kernel
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
This replaces calls to of_device_is_compatible to check data field of
of_device_id matched when probing the driver.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
drivers/power/supply/axp20x_usb_power.c | 26 +++++++++++++++-----------
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c
index 6af6feb..8985646 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -17,6 +17,7 @@
#include <linux/mfd/axp20x.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>
@@ -45,6 +46,7 @@ struct axp20x_usb_power {
struct device_node *np;
struct regmap *regmap;
struct power_supply *supply;
+ int axp20x_id;
};
static irqreturn_t axp20x_usb_power_irq(int irq, void *devid)
@@ -86,8 +88,7 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
switch (v & AXP20X_VBUS_CLIMIT_MASK) {
case AXP20X_VBUC_CLIMIT_100mA:
- if (of_device_is_compatible(power->np,
- "x-powers,axp202-usb-power-supply")) {
+ if (power->axp20x_id == AXP202_ID) {
val->intval = 100000;
} else {
val->intval = -1; /* No 100mA limit */
@@ -130,8 +131,7 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
val->intval = POWER_SUPPLY_HEALTH_GOOD;
- if (of_device_is_compatible(power->np,
- "x-powers,axp202-usb-power-supply")) {
+ if (power->axp20x_id == AXP202_ID) {
ret = regmap_read(power->regmap,
AXP20X_USB_OTG_STATUS, &v);
if (ret)
@@ -214,11 +214,12 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
if (!power)
return -ENOMEM;
+ power->axp20x_id = (int)of_device_get_match_data(&pdev->dev);
+
power->np = pdev->dev.of_node;
power->regmap = axp20x->regmap;
- if (of_device_is_compatible(power->np,
- "x-powers,axp202-usb-power-supply")) {
+ if (power->axp20x_id == AXP202_ID) {
/* Enable vbus valid checking */
ret = regmap_update_bits(power->regmap, AXP20X_VBUS_MON,
AXP20X_VBUS_MON_VBUS_VALID,
@@ -235,8 +236,7 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
usb_power_desc = &axp20x_usb_power_desc;
irq_names = axp20x_irq_names;
- } else if (of_device_is_compatible(power->np,
- "x-powers,axp221-usb-power-supply")) {
+ } else if (power->axp20x_id == AXP221_ID) {
usb_power_desc = &axp22x_usb_power_desc;
irq_names = axp22x_irq_names;
} else {
@@ -273,9 +273,13 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
}
static const struct of_device_id axp20x_usb_power_match[] = {
- { .compatible = "x-powers,axp202-usb-power-supply" },
- { .compatible = "x-powers,axp221-usb-power-supply" },
- { }
+ {
+ .compatible = "x-powers,axp202-usb-power-supply",
+ .data = (void *)AXP202_ID,
+ }, {
+ .compatible = "x-powers,axp221-usb-power-supply",
+ .data = (void *)AXP221_ID,
+ }, { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
--
2.9.3
^ permalink raw reply related
* [PATCH v2 00/11] add support for VBUS max current and min voltage limits AXP20X and AXP22X PMICs
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
The X-Powers AXP209 and AXP20X PMICs are able to set a limit for the
VBUS power supply for both max current and min voltage supplied. This
series of patch adds the possibility to set these limits from sysfs.
Also, the AXP223 PMIC shares most of its behaviour with the AXP221 but
the former can set the VBUS power supply max current to 100mA, unlike
the latter. The AXP223 VBUS power supply driver used to probe on the
AXP221 compatible. This series of patch introduces a new compatible for
the AXP223 to be able to set the current max limit to 100mA.
With that new compatible, boards having the AXP223 see their DT updated
to use the VBUS power supply driver with the correct compatible.
This series of patch also migrates from of_device_is_compatible function
to the data field of of_device_id to identify the compatible used to
probe. This improves the code readability.
Mostly cosmetic changes in v2 and adding volatile and writeable regs to
AXP20X and AXP22X MFD cells for the VBUS power supply driver.
Quentin Schulz (11):
power: supply: axp20x_usb_power: use of_device_id data field instead
of device_is_compatible
mfd: axp20x: add volatile and writeable reg ranges for VBUS power
supply driver
power: supply: axp20x_usb_power: set min voltage and max current from
sysfs
Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
power: supply: axp20x_usb_power: add 100mA max current limit for
AXP223
mfd: axp20x: add separate MFD cell for AXP223
ARM: dtsi: add DTSI for AXP223
ARM: dts: sun8i-a33-olinuxino: use AXP223 DTSI
ARM: dts: sun8i-a33-sinlinx-sina33: use AXP223 DTSI
ARM: dts: sun8i-r16-parrot: use AXP223 DTSI
ARM: dtsi: sun8i-reference-design-tablet: use AXP223 DTSI
.../bindings/power/supply/axp20x_usb_power.txt | 5 +
arch/arm/boot/dts/axp223.dtsi | 58 +++++++++++
arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 2 +-
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 2 +-
arch/arm/boot/dts/sun8i-r16-parrot.dts | 2 +-
.../boot/dts/sun8i-reference-design-tablet.dtsi | 2 +-
drivers/mfd/axp20x.c | 32 +++++-
drivers/power/supply/axp20x_usb_power.c | 116 ++++++++++++++++++---
8 files changed, 197 insertions(+), 22 deletions(-)
create mode 100644 arch/arm/boot/dts/axp223.dtsi
--
2.9.3
^ permalink raw reply
* [PATCH 2/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding
From: Simon Horman @ 2016-12-09 10:50 UTC (permalink / raw)
To: Thomas Gleixner, Jason Cooper, Marc Zyngier
Cc: Rob Herring, Magnus Damm, linux-kernel, linux-renesas-soc,
devicetree, Simon Horman
In-Reply-To: <1481280650-9258-1-git-send-email-horms+renesas@verge.net.au>
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 1, Gen 2 and Gen 3. But beyond that its not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7779 is older than r8a7778 but that doesn't imply that the latter is a
descendant of the former or vice versa.
We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.
For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme being adopted for
drivers for Renesas SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
.../interrupt-controller/renesas,intc-irqpin.txt | 44 ++++++++++++----------
drivers/irqchip/irq-renesas-intc-irqpin.c | 2 +
2 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
index 772c550d3b4b..e5a5251be9f5 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
@@ -2,13 +2,19 @@ DT bindings for the R-/SH-Mobile irqpin controller
Required properties:
-- compatible: has to be "renesas,intc-irqpin-<soctype>", "renesas,intc-irqpin"
- as fallback.
- Examples with soctypes are:
+- compatible:
- "renesas,intc-irqpin-r8a7740" (R-Mobile A1)
- "renesas,intc-irqpin-r8a7778" (R-Car M1A)
- "renesas,intc-irqpin-r8a7779" (R-Car H1)
- "renesas,intc-irqpin-sh73a0" (SH-Mobile AG5)
+ - "renesas,rcar-gen1-intc-irqpin" (generic R-Car Gen1 compatible device)
+ - "renesas,intc-irqpin" (generic device)
+
+ When compatible with a generic R-Car version, nodes must list the
+ SoC-specific version corresponding to the platform first followed by
+ the generic R-Car version.
+
+ "renesas,intc-irqpin" must be present and last.
- reg: Base address and length of each register bank used by the external
IRQ pins driven by the interrupt controller hardware module. The base
@@ -39,24 +45,22 @@ Optional properties:
Example
-------
- irqpin1: interrupt-controller@e6900004 {
- compatible = "renesas,intc-irqpin-r8a7740",
+ irqpin0: interrupt-controller@fe78001c {
+ compatible = "renesas,intc-irqpin-r8a7779",
+ "renesas,rcar-gen1-intc-irqpin",
"renesas,intc-irqpin";
#interrupt-cells = <2>;
+ status = "disabled";
interrupt-controller;
- reg = <0xe6900004 4>,
- <0xe6900014 4>,
- <0xe6900024 1>,
- <0xe6900044 1>,
- <0xe6900064 1>;
- interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH
- 0 149 IRQ_TYPE_LEVEL_HIGH
- 0 149 IRQ_TYPE_LEVEL_HIGH
- 0 149 IRQ_TYPE_LEVEL_HIGH
- 0 149 IRQ_TYPE_LEVEL_HIGH
- 0 149 IRQ_TYPE_LEVEL_HIGH
- 0 149 IRQ_TYPE_LEVEL_HIGH
- 0 149 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp2_clks R8A7740_CLK_INTCA>;
- power-domains = <&pd_a4s>;
+ reg = <0xfe78001c 4>,
+ <0xfe780010 4>,
+ <0xfe780024 4>,
+ <0xfe780044 4>,
+ <0xfe780064 4>,
+ <0xfe780000 4>;
+ interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ sense-bitfield-width = <2>;
};
diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c b/drivers/irqchip/irq-renesas-intc-irqpin.c
index 5fe1207a079c..70095b61a90a 100644
--- a/drivers/irqchip/irq-renesas-intc-irqpin.c
+++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
@@ -378,6 +378,8 @@ static const struct of_device_id intc_irqpin_dt_ids[] = {
.data = &intc_irqpin_irlm_r8a777x },
{ .compatible = "renesas,intc-irqpin-r8a7779",
.data = &intc_irqpin_irlm_r8a777x },
+ { .compatible = "renesas,rcar-gen1-intc-irqpin",
+ .data = &intc_irqpin_irlm_r8a777x },
{ .compatible = "renesas,intc-irqpin-r8a7740",
.data = &intc_irqpin_rmobile },
{ .compatible = "renesas,intc-irqpin-sh73a0",
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 1/2] irqchip/renesas-intc-irqpin: List fallback compatibility last
From: Simon Horman @ 2016-12-09 10:50 UTC (permalink / raw)
To: Thomas Gleixner, Jason Cooper, Marc Zyngier
Cc: Rob Herring, Magnus Damm, linux-kernel, linux-renesas-soc,
devicetree, Simon Horman
In-Reply-To: <1481280650-9258-1-git-send-email-horms+renesas@verge.net.au>
Improve readability by listing the rmobile fallback compatibility string
after the more-specific compatibility strings they provide a fallback for.
This does not effect run-time behaviour as it is the order in the DTB that
determines which compatibility string is used.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
drivers/irqchip/irq-renesas-intc-irqpin.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c b/drivers/irqchip/irq-renesas-intc-irqpin.c
index 713177d97c7a..5fe1207a079c 100644
--- a/drivers/irqchip/irq-renesas-intc-irqpin.c
+++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
@@ -374,7 +374,6 @@ static const struct intc_irqpin_config intc_irqpin_rmobile = {
};
static const struct of_device_id intc_irqpin_dt_ids[] = {
- { .compatible = "renesas,intc-irqpin", },
{ .compatible = "renesas,intc-irqpin-r8a7778",
.data = &intc_irqpin_irlm_r8a777x },
{ .compatible = "renesas,intc-irqpin-r8a7779",
@@ -383,6 +382,7 @@ static const struct of_device_id intc_irqpin_dt_ids[] = {
.data = &intc_irqpin_rmobile },
{ .compatible = "renesas,intc-irqpin-sh73a0",
.data = &intc_irqpin_rmobile },
+ { .compatible = "renesas,intc-irqpin", },
{},
};
MODULE_DEVICE_TABLE(of, intc_irqpin_dt_ids);
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 0/2] irqchip/renesas-intc-irqpin: fallback enhancements
From: Simon Horman @ 2016-12-09 10:50 UTC (permalink / raw)
To: Thomas Gleixner, Jason Cooper, Marc Zyngier
Cc: Rob Herring, Magnus Damm, linux-kernel, linux-renesas-soc,
devicetree, Simon Horman
Hi,
this short series aims to improve the fallback compatibility strings
for the renesas-intc-irqpin driver.
Based on v4.9-rc1.
Simon Horman (2):
irqchip/renesas-intc-irqpin: List fallback compatibility last
irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding
.../interrupt-controller/renesas,intc-irqpin.txt | 44 ++++++++++++----------
drivers/irqchip/irq-renesas-intc-irqpin.c | 4 +-
2 files changed, 27 insertions(+), 21 deletions(-)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* Re: [PATCH v2] mtd/spi-nor: Add SPI memory controllers for Aspeed SoCs
From: Cédric Le Goater @ 2016-12-09 10:42 UTC (permalink / raw)
To: Marek Vasut, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, Cyrille Pitchen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Joel Stanley
In-Reply-To: <6d1bb5a6-3a99-3320-297b-311d359294f6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 12/09/2016 03:29 AM, Marek Vasut wrote:
> On 12/08/2016 05:36 PM, Cédric Le Goater wrote:
>> Hello Marek,
>
> Hi!
Hello Hello,
[...]
>>>> + /*
>>>> + * Read the existing control register to get basic values.
>>>> + *
>>>> + * XXX This register probably needs more sanitation.
>>>
>>> What's this comment about ?
>>
>> This is an initial comment about settings being done by U-Boot
>> before the kernel is loaded, and some optimisations should be
>> nice to keep, for the FMC controller. I will rephrase.
>
> Shouldn't that be passed via DT instead ? We want to be bootloader
> agnostic in Linux.
Yes, clearly, Linux should do its own timing calibration and not depend
on the bootloader but I am not sure how to do that correctly, yet, in
the driver for all controllers. It depends on the controller type and
a lot on the flash model being used, which can vary for the same board.
U-Boot uses specific registers of the FMC controller to evaluate the
best SPI clock frequency. So, for the moment, keeping the previous
setting for :
bits [11:8] SPI clock frequency selection
is a nice thing to have. we can replace this setting when calibration
is handled from Linux.
The SPI controllers are different, they don't have the specific registers
for calibration, and so the algo is bit more painful.
> btw off-topic, but is U-Boot support for these aspeed devices ever
> be upstreamed ?
It is the plan to.
This year, we have spent quite sometime porting, fixing, cleaning
up the original code and getting ready to send a minimal framework,
cpu and console, to mainline (flash and net drivers can come later).
The code is operational on various boards but there is a major task
we have not completed yet, which is to rewrite the 2/3 KLOC of
assembly doing the DDR initialization :/ Once this is done, we
should send.
Here is the tree we use on OpenBMC :
https://github.com/openbmc/u-boot/commits/v2016.07-aspeed-openbmc
and a more recent branch with some extra cleanups :
https://github.com/legoater/u-boot/commits/v2016.11-aspeed-openbmc
Thanks,
C.
--
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
* [PATCH] Documentation: ti-syscon-reset: fix header path
From: yegorslists-gM/Ye1E23mwN+BqQ9rBEUg @ 2016-12-09 10:11 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
Yegor Yefremov
From: Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
'include' was missing from path.
Signed-off-by: Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
index 164c7f3..5b20e20 100644
--- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
+++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
@@ -44,7 +44,7 @@ Required properties:
reset status register
Cell #7 : Flags used to control reset behavior,
availible flags defined in the DT include
- file <dt-bindings/reset/ti-syscon.h>
+ file <include/dt-bindings/reset/ti-syscon.h>
SysCon Reset Consumer Nodes
===========================
--
2.1.4
--
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 v1 2/2] crypto: mediatek - add DT bindings documentation
From: Matthias Brugger @ 2016-12-09 9:45 UTC (permalink / raw)
To: Ryder Lee
Cc: Herbert Xu, David S. Miller, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sean Wang,
Roy Luo
In-Reply-To: <1481188776.14860.26.camel@mtkswgap22>
On 08/12/16 10:19, Ryder Lee wrote:
> Hello,
>
> On Mon, 2016-12-05 at 11:18 +0100, Matthias Brugger wrote:
>>
>> On 05/12/16 08:01, Ryder Lee wrote:
>>> Add DT bindings documentation for the crypto driver
>>>
>>> Signed-off-by: Ryder Lee <ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>> ---
>>> .../devicetree/bindings/crypto/mediatek-crypto.txt | 32 ++++++++++++++++++++++
>>> 1 file changed, 32 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
>>> new file mode 100644
>>> index 0000000..8b1db08
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
>>> @@ -0,0 +1,32 @@
>>> +MediaTek cryptographic accelerators
>>> +
>>> +Required properties:
>>> +- compatible: Should be "mediatek,mt7623-crypto"
>>
>> Do you know how big the difference is between the crypto engine for
>> mt7623/mt2701/mt8521p in comparison, let's say mt8173 or mt6797?
>> Do this SoCs have a crypot engine? If so and they are quite similar, we
>> might think of adding a mtk-crypto binding and add soc specific bindings.
>
> This engine is just available in mt7623/mt2701/mt8521p series SoCs and
> they have no difference.
>
> But there are still other crypto IPs in MTK, i think maybe we could use
> "mediatek,{IP name}-crypto” to distinguish them ?
>
Sounds good, thanks for the clarification.
Matthias
>> Regards,
>> Matthias
>>
>>> +- reg: Address and length of the register set for the device
>>> +- interrupts: Should contain the five crypto engines interrupts in numeric
>>> + order. These are global system and four descriptor rings.
>>> +- clocks: the clock used by the core
>>> +- clock-names: the names of the clock listed in the clocks property. These are
>>> + "ethif", "cryp"
>>> +- power-domains: Must contain a reference to the PM domain.
>>> +
>>> +
>>> +Optional properties:
>>> +- interrupt-parent: Should be the phandle for the interrupt controller
>>> + that services interrupts for this device
>>> +
>>> +
>>> +Example:
>>> + crypto: crypto@1b240000 {
>>> + compatible = "mediatek,mt7623-crypto";
>>> + reg = <0 0x1b240000 0 0x20000>;
>>> + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_LOW>,
>>> + <GIC_SPI 83 IRQ_TYPE_LEVEL_LOW>,
>>> + <GIC_SPI 84 IRQ_TYPE_LEVEL_LOW>,
>>> + <GIC_SPI 91 IRQ_TYPE_LEVEL_LOW>,
>>> + <GIC_SPI 97 IRQ_TYPE_LEVEL_LOW>;
>>> + clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
>>> + <ðsys CLK_ETHSYS_CRYPTO>;
>>> + clock-names = "ethif","cryp";
>>> + power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
>>> + };
>>>
>
>
--
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 v13 0/7] dtc: Dynamic DT support
From: Pantelis Antoniou @ 2016-12-09 9:12 UTC (permalink / raw)
To: David Gibson
Cc: Jon Loeliger, Grant Likely, Frank Rowand, Rob Herring, Jan Luebbe,
Sascha Hauer, Phil Elwell, Simon Glass, Maxime Ripard,
Thomas Petazzoni, Boris Brezillon, Antoine Tenart, Stephen Boyd,
Devicetree Compiler, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161209085432.GR13139-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
Hi David,
> On Dec 9, 2016, at 10:54 , David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
>
> On Fri, Dec 09, 2016 at 10:16:51AM +0200, Pantelis Antoniou wrote:
>> Hi David,
>>
>>> On Dec 9, 2016, at 07:57 , David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
>>>
>>> On Wed, Dec 07, 2016 at 02:48:16PM +0200, Pantelis Antoniou wrote:
>>>> This patchset adds Dynamic DT support in the DTC compiler
>>>> as used in a number of boards like the beaglebone/rpi/chip and others.
>>>>
>>>> The first patch documents the internals of overlay generation, while
>>>> the second one adds dynamic object/overlay support proper.
>>>>
>>>> The third patch adds a test method that can is used by the subsequent
>>>> patch which adds a few overlay tests verifying operation.
>>>>
>>>> The following 3 patches add support for the syntactic sugar version
>>>> of &foo { }; in a similar manner.
>>>>
>>>> This patchset is against DTC mainline and is also available for a pull
>>>> request from https://github.com/pantoniou/dtc/tree/overlays
>>>
>>> Ok, I've merged patches 1-4 into mainline, along with a bunch of minor
>>> fixes of my own on top. 5..7 (the start of the new) I want to hold
>>> off on for now, to thrash out the details of what we want a new
>>> cleaner format to look like a bit more thoroughly.
>>>
>>
>> Thank you.
>>
>> My git tree contains an updated patchset of the syntactic sugar patches
>> for reference now.
>
> Ok. Note that one of the patches I merged afterwards was a big rename
> of struct boot_info, so your patches will probably need a fair bit of
> fiddly though straightforward rebasing.
>
Fortunately not. The syntax sugar stuff do not rely on boot_info at all now
that the rule uses the inherited attribute trick.
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
Regards
— Pantelis
--
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: [RESEND-PATCH] ARM: EXYNOS: remove smp hook from machine descriptor
From: pankaj.dubey @ 2016-12-09 9:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, arnd, kgene,
javier, thomas.ab
In-Reply-To: <20161208173349.GA8522@kozik-lap>
Hi Krzysztof,
On Thursday 08 December 2016 11:03 PM, Krzysztof Kozlowski wrote:
> On Thu, Dec 08, 2016 at 08:32:15AM +0530, Pankaj Dubey wrote:
>> Use CPU_METHOD_OF_DECLARE() for smp_ops instead of using it
>> via machine descriptor.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> ---
>>
>> Resending as I missed to include samsung mailing list.
>>
>> arch/arm/boot/dts/exynos3250.dtsi | 1 +
>> arch/arm/boot/dts/exynos4210.dtsi | 1 +
>> arch/arm/boot/dts/exynos4212.dtsi | 1 +
>> arch/arm/boot/dts/exynos4412.dtsi | 1 +
>> arch/arm/boot/dts/exynos5250.dtsi | 1 +
>> arch/arm/boot/dts/exynos5260.dtsi | 1 +
>> arch/arm/boot/dts/exynos5410.dtsi | 1 +
>> arch/arm/boot/dts/exynos5420-cpus.dtsi | 1 +
>> arch/arm/boot/dts/exynos5422-cpus.dtsi | 1 +
>> arch/arm/boot/dts/exynos5440.dtsi | 1 +
>> arch/arm/mach-exynos/common.h | 2 --
>> arch/arm/mach-exynos/exynos.c | 1 -
>> arch/arm/mach-exynos/platsmp.c | 2 ++
>> 13 files changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
>> index ba17ee1..f28f669 100644
>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>> @@ -53,6 +53,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
>> index 7f3a18c..6dfd98d 100644
>> --- a/arch/arm/boot/dts/exynos4210.dtsi
>> +++ b/arch/arm/boot/dts/exynos4210.dtsi
>> @@ -35,6 +35,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@900 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
>> index 5389011..3e8982e 100644
>> --- a/arch/arm/boot/dts/exynos4212.dtsi
>> +++ b/arch/arm/boot/dts/exynos4212.dtsi
>> @@ -25,6 +25,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@A00 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
>> index 40beede..faf2fb8 100644
>> --- a/arch/arm/boot/dts/exynos4412.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412.dtsi
>> @@ -25,6 +25,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@A00 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
>> index b6d7444..580897c 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -52,6 +52,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi
>> index 5818718..1af6e76 100644
>> --- a/arch/arm/boot/dts/exynos5260.dtsi
>> +++ b/arch/arm/boot/dts/exynos5260.dtsi
>> @@ -32,6 +32,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu@0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
>> index 2b6adaf..b092cdc 100644
>> --- a/arch/arm/boot/dts/exynos5410.dtsi
>> +++ b/arch/arm/boot/dts/exynos5410.dtsi
>> @@ -33,6 +33,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> index 5c052d7..a587704 100644
>> --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> @@ -24,6 +24,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi b/arch/arm/boot/dts/exynos5422-cpus.dtsi
>> index bf3c6f1..7fcdfd0 100644
>> --- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
>> @@ -23,6 +23,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu@100 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
>> index 2a2e570..0a958e8 100644
>> --- a/arch/arm/boot/dts/exynos5440.dtsi
>> +++ b/arch/arm/boot/dts/exynos5440.dtsi
>> @@ -50,6 +50,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu@0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
>> index fb12d11..051e1ab 100644
>> --- a/arch/arm/mach-exynos/common.h
>> +++ b/arch/arm/mach-exynos/common.h
>> @@ -143,8 +143,6 @@ static inline void exynos_pm_init(void) {}
>> extern void exynos_cpu_resume(void);
>> extern void exynos_cpu_resume_ns(void);
>>
>> -extern const struct smp_operations exynos_smp_ops;
>> -
>> extern void exynos_cpu_power_down(int cpu);
>> extern void exynos_cpu_power_up(int cpu);
>> extern int exynos_cpu_power_state(int cpu);
>> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
>> index fa08ef9..f0a766e 100644
>> --- a/arch/arm/mach-exynos/exynos.c
>> +++ b/arch/arm/mach-exynos/exynos.c
>> @@ -211,7 +211,6 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
>> /* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
>> .l2c_aux_val = 0x3c400001,
>> .l2c_aux_mask = 0xc20fffff,
>> - .smp = smp_ops(exynos_smp_ops),
>> .map_io = exynos_init_io,
>> .init_early = exynos_firmware_init,
>> .init_irq = exynos_init_irq,
>> diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
>> index 94405c7..43eec10 100644
>> --- a/arch/arm/mach-exynos/platsmp.c
>> +++ b/arch/arm/mach-exynos/platsmp.c
>> @@ -474,3 +474,5 @@ const struct smp_operations exynos_smp_ops __initconst = {
>> .cpu_die = exynos_cpu_die,
>> #endif
>> };
>> +
>> +CPU_METHOD_OF_DECLARE(exynos_smp, "samsung,exynos-smp", &exynos_smp_ops);
>
> Three issues:
> 1. This has to be documented. Checkpatch did not complain about it?
No it didn't.
> 2. I think this breaks the ABI with existing DTBs because now the
> enable-method of cpus becomes mandatory. But the
> Documentation/devicetree/bindings/arm/cpus.txt is saying that:
> "On ARM 32-bit systems this property is optional and can be one of"
>
I am not very sure that this is an ABI break, as other platforms (e.g
hisilicon,hip01-smp) also adopted this as some later stage and they also
removed smp hook support from their machine files when they adopted to
this enable-method in DTS files.
If we want to keep older DTBs keep working with new Kernel image, then I
need to drop patch from mach-exynos and keep smp_ops hook in machine
descriptor as it is to keep supporting older DTBs. I can see some
platforms have adopted this way as well.
Surely I will add new bindings details in
Documentation/devicetree/bindings/arm/cpus.txt file. I am not sure why
checkpatch did not complain about this?
> 3. Please split DTS changes to separate patches. This is, by the way,
> connected with #2 above: if there was no ABI break, then the DTS
> could go to separate branch easily.
>
Since I am not sure if this will considered as ABI break or not, I just
looked how this was handled in other platforms, I can see some platforms
have clubbed DTS change along with mach files, and some have done in
separate patch as well. So I will look for suggestion from you for this
how we can go for exynos platform?
Thanks,
Pankaj Dubey
> Best regards,
> Krzysztof
>
>
>
^ permalink raw reply
* Re: [PATCH v4 6/7] IIO: add STM32 timer trigger driver
From: Lee Jones @ 2016-12-09 8:59 UTC (permalink / raw)
To: Daniel Thompson
Cc: Benjamin Gaignard, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Mark Rutland,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List, Thierry Reding,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, Jonathan Cameron,
knaack.h-Mmb7MZpHnFY, Lars-Peter Clausen, Peter Meerwald-Stadler,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Fabrice Gasnier, Gerald Baeza, Arnaud Pouliquen, Linus Walleij,
Linaro Kernel Mailman List, Benjamin Gaignard
In-Reply-To: <5dcec09c-8b4b-4cc2-ce3f-fde86366ec05-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Wed, 07 Dec 2016, Daniel Thompson wrote:
> On 07/12/16 11:00, Benjamin Gaignard wrote:
> > 2016-12-07 11:50 GMT+01:00 Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
> > > On Tue, 06 Dec 2016, Benjamin Gaignard wrote:
> > >
> > > > [snip]
> > > > > > +
> > > > > > +static const char * const triggers0[] = {
> > > > > > + TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers1[] = {
> > > > > > + TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers2[] = {
> > > > > > + TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers3[] = {
> > > > > > + TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers4[] = {
> > > > > > + TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers5[] = {
> > > > > > + TIM6_TRGO, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers6[] = {
> > > > > > + TIM7_TRGO, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers7[] = {
> > > > > > + TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers8[] = {
> > > > > > + TIM9_TRGO, TIM9_CH1, TIM9_CH2, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers9[] = {
> > > > > > + TIM12_TRGO, TIM12_CH1, TIM12_CH2, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const void *triggers_table[] = {
> > > > > > + triggers0,
> > > > > > + triggers1,
> > > > > > + triggers2,
> > > > > > + triggers3,
> > > > > > + triggers4,
> > > > > > + triggers5,
> > > > > > + triggers6,
> > > > > > + triggers7,
> > > > > > + triggers8,
> > > > > > + triggers9,
> > > > > > +};
> > > > >
> > > > > What about:
> > > > >
> > > > > static const char * const triggers[][] = {
> > > > > { TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4, NULL },
> > > > > { TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4, NULL },
> > > > > { TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4, NULL },
> > > > > { TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4, NULL },
> > > > > { TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4, NULL },
> > > > > { TIM6_TRGO, NULL },
> > > > > { TIM7_TRGO, NULL },
> > > > > { TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4, NULL },
> > > > > { TIM9_TRGO, TIM9_CH1, TIM9_CH2, NULL },
> > > > > { TIM12_TRGO, TIM12_CH1, TIM12_CH2, NULL }
> > > > > };
> > > >
> > > > I can't because the second dimension of the array isn't fix.
> > > > I could have between 2 and 6 elements per row... to create a dual dimension
> > > > array I would have to add NULL entries like that:
> > > >
> > > > #define MAX_TRIGGERS 6
> > > >
> > > > static const void *triggers_table[][MAX_TRIGGERS] = {
> > > > { TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4, NULL,},
> > > > { TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4, NULL,},
> > > > { TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4, NULL,},
> > > > { TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4, NULL,},
> > > > { TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4, NULL,},
> > > > { TIM6_TRGO, NULL, NULL, NULL, NULL, NULL,},
> > > > { TIM7_TRGO, NULL, NULL, NULL, NULL, NULL,},
> > > > { TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4, NULL,},
> > > > { TIM9_TRGO, TIM9_CH1, TIM9_CH2, NULL, NULL, NULL,},
> > > > { TIM12_TRGO, TIM12_CH1, TIM12_CH2, NULL, NULL, NULL,},
> > > > };
> > >
> > > It was just an idea, not a tested implementation.
> > >
> > > I don't understand why you have to pad with NULLs, but either way, it
> > > looks much better than before and saves lots of lines of code.
> >
> > I have tested it this morning and it works fine so I will include it in v5.
> > I use NULL as limit when iterate in the table and for table padding too.
>
> If the initializer is shorter than the array then the array will be
> implicitly zero/NULL padded. I don't think there is any need to type out all
> the NULLs (not even at -Wall).
+1. My point precisely.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v13 0/7] dtc: Dynamic DT support
From: David Gibson @ 2016-12-09 8:54 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Jon Loeliger, Grant Likely, Frank Rowand, Rob Herring, Jan Luebbe,
Sascha Hauer, Phil Elwell, Simon Glass, Maxime Ripard,
Thomas Petazzoni, Boris Brezillon, Antoine Tenart, Stephen Boyd,
Devicetree Compiler, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <3C4DD870-3736-42A7-A110-0975C31E74A4-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]
On Fri, Dec 09, 2016 at 10:16:51AM +0200, Pantelis Antoniou wrote:
> Hi David,
>
> > On Dec 9, 2016, at 07:57 , David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
> >
> > On Wed, Dec 07, 2016 at 02:48:16PM +0200, Pantelis Antoniou wrote:
> >> This patchset adds Dynamic DT support in the DTC compiler
> >> as used in a number of boards like the beaglebone/rpi/chip and others.
> >>
> >> The first patch documents the internals of overlay generation, while
> >> the second one adds dynamic object/overlay support proper.
> >>
> >> The third patch adds a test method that can is used by the subsequent
> >> patch which adds a few overlay tests verifying operation.
> >>
> >> The following 3 patches add support for the syntactic sugar version
> >> of &foo { }; in a similar manner.
> >>
> >> This patchset is against DTC mainline and is also available for a pull
> >> request from https://github.com/pantoniou/dtc/tree/overlays
> >
> > Ok, I've merged patches 1-4 into mainline, along with a bunch of minor
> > fixes of my own on top. 5..7 (the start of the new) I want to hold
> > off on for now, to thrash out the details of what we want a new
> > cleaner format to look like a bit more thoroughly.
> >
>
> Thank you.
>
> My git tree contains an updated patchset of the syntactic sugar patches
> for reference now.
Ok. Note that one of the patches I merged afterwards was a big rename
of struct boot_info, so your patches will probably need a fair bit of
fiddly though straightforward rebasing.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/7] MFD: add bindings for STM32 General Purpose Timer driver
From: Lee Jones @ 2016-12-09 8:53 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: robh+dt, mark.rutland, alexandre.torgue, devicetree, linux-kernel,
thierry.reding, linux-pwm, jic23, knaack.h, lars, pmeerw,
linux-iio, linux-arm-kernel, fabrice.gasnier, gerald.baeza,
arnaud.pouliquen, linus.walleij, linaro-kernel, Benjamin Gaignard
In-Reply-To: <1481199650-22484-2-git-send-email-benjamin.gaignard@st.com>
Sorry to do this Ben. Not much to do now though!
> Add bindings information for STM32 General Purpose Timer
>
> version 2:
> - rename stm32-mfd-timer to stm32-gptimer
> - only keep one compatible string
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../bindings/mfd/stm32-general-purpose-timer.txt | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
> new file mode 100644
> index 0000000..ce67755
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
> @@ -0,0 +1,39 @@
> +STM32 General Purpose Timer driver bindings
This is a great place to describe what we're *actually* trying to
achieve with this driver, and the worst place to use the term "general
purpose", since this IP is so much more than that.
"STM32 Timers
This IP provides 3 types of timer along with PWM functionality.
[...]"
... then go on to explain what the 3 types are and how they can be
used.
> +Required parameters:
> +- compatible: must be "st,stm32-gptimer"
I vehemently disagree that this entire IP is a GP Timer. It contains
GP timers, sure, but it also contains Advanced and Basic timers.
IMHO this compatible should be "st,stm32-timers".
And the file name of both this and the *.c file should reflect that
too.
Remainder looks nice.
> +- reg: Physical base address and length of the controller's
> + registers.
> +- clock-names: Set to "clk_int".
> +- clocks: Phandle to the clock used by the timer module.
> + For Clk properties, please refer to ../clock/clock-bindings.txt
> +
> +Optional parameters:
> +- resets: Phandle to the parent reset controller.
> + See ../reset/st,stm32-rcc.txt
> +
> +Optional subnodes:
> +- pwm: See ../pwm/pwm-stm32.txt
> +- timer: See ../iio/timer/stm32-timer-trigger.txt
> +
> +Example:
> + timers@40010000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-gptimer";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm@0 {
Out of interest, do you use the "@0", "@1" for anything now?
> + compatible = "st,stm32-pwm";
> + pinctrl-0 = <&pwm1_pins>;
> + pinctrl-names = "default";
> + };
> +
> + timer@0 {
> + compatible = "st,stm32-timer-trigger";
> + reg = <0>;
> + };
> + };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 3/6] net: ethernet: ti: cpts: add support of cpts HW_TS_PUSH
From: Richard Cochran @ 2016-12-09 8:50 UTC (permalink / raw)
To: Grygorii Strashko
Cc: David S. Miller, netdev, Mugunthan V N, Sekhar Nori, linux-kernel,
linux-omap, Rob Herring, devicetree, Murali Karicheri,
Wingman Kwok
In-Reply-To: <58eea45f-b8fe-6892-e784-b41638c62fd8@ti.com>
On Thu, Dec 08, 2016 at 01:04:11PM -0600, Grygorii Strashko wrote:
> huh. Seems this is not really good idea, because MISC Irq will be
> triggered for *any* CPTS event and there is no way to enable it just for
> HW_TS_PUSH.
So what? That is not a problem.
> So, this doesn't work will with current code for RX/TX timestamping
> (which uses polling mode).
Why doesn't it work?
> + runtime overhead in net RX/TX caused by
> triggering more interrupts.
This is not relevant. Without HW_TS_PUSH, there is no need for
enabling the interrupt simply because we don't need it. Now, with
HW_TS_PUSH, we do need it.
> May be, overflow check/polling timeout can be made configurable (module parameter).
No, it should just work without any user space fiddling.
I getting a bit tired of your half-baked implementations of the
ancillary clock functions. Either do it right, or just leave it
unsupported.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH] misc: eeprom: implement compatible DT probing
From: Wolfram Sang @ 2016-12-09 8:18 UTC (permalink / raw)
To: Peter Rosin
Cc: Linus Walleij, Wolfram Sang,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <806f55f3-3fed-572d-4859-7c7dc76c5e08-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 736 bytes --]
> Many on the patterns at,24c256 and at24,24c256 (should be probably
> be atmel,24c256)
I remember patches fixing that. Since I usually don't take DTS patches,
I can't recall what happened to them. It might well be that those were
accepted and meanwhile new bad bindings got in.
> but also a few atmel,at24c16 and atmel,at24c128b.
> I don't understand how those last ones ever worked, if it is not
> working for you? Especially those with the trailing "b". WTF?
I'd simply assume it was never tested. EEPROMs are often convenience
storage and not essential for a working board. Also, for historic
reasons, they are often used via the i2c-dev interface directly, so a
wrong binding with the kernel driver might simply go unnoticed.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 -next 2/2] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-12-09 8:17 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Rob Herring, Russell King, Andre Przywara,
Hans de Goede, Arnd Bergmann, Vishnu Patekar,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161202150513.34691-2-icenowy-ymACFijhrKM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
On Fri, Dec 02, 2016 at 11:05:13PM +0800, Icenowy Zheng wrote:
> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC and a
> SDIO Wi-Fi chip by Allwinner (XR819).
>
> Add a device tree file for it.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v13 0/7] dtc: Dynamic DT support
From: Pantelis Antoniou @ 2016-12-09 8:16 UTC (permalink / raw)
To: David Gibson
Cc: Jon Loeliger, Grant Likely, Frank Rowand, Rob Herring, Jan Luebbe,
Sascha Hauer, Phil Elwell, Simon Glass, Maxime Ripard,
Thomas Petazzoni, Boris Brezillon, Antoine Tenart, Stephen Boyd,
Devicetree Compiler, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161209055709.GP13139-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
Hi David,
> On Dec 9, 2016, at 07:57 , David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
>
> On Wed, Dec 07, 2016 at 02:48:16PM +0200, Pantelis Antoniou wrote:
>> This patchset adds Dynamic DT support in the DTC compiler
>> as used in a number of boards like the beaglebone/rpi/chip and others.
>>
>> The first patch documents the internals of overlay generation, while
>> the second one adds dynamic object/overlay support proper.
>>
>> The third patch adds a test method that can is used by the subsequent
>> patch which adds a few overlay tests verifying operation.
>>
>> The following 3 patches add support for the syntactic sugar version
>> of &foo { }; in a similar manner.
>>
>> This patchset is against DTC mainline and is also available for a pull
>> request from https://github.com/pantoniou/dtc/tree/overlays
>
> Ok, I've merged patches 1-4 into mainline, along with a bunch of minor
> fixes of my own on top. 5..7 (the start of the new) I want to hold
> off on for now, to thrash out the details of what we want a new
> cleaner format to look like a bit more thoroughly.
>
Thank you.
My git tree contains an updated patchset of the syntactic sugar patches
for reference now.
Regards
— Pantelis
>>
>> Regards
>>
>> -- Pantelis
>>
>> Changes since v12:
>> * Dropped DTBO magic option completely.
>> * Dropped fixup generation option.
>> * Renamed dstversionflags to dstflags
>> * Drop support for the new style /plugin/ tag.
>>
>> Changes since v11:
>> * Syntax and grammatical fixes to the documentation.
>> * Renamed options and internal variables controlling generation of symbols
>> and fixups.
>> * Rename version flags to specify that they refer to DTS version.
>> * Made sure that no symbols/fixup nodes are only generated if they contain
>> entries.
>>
>> Changes since v10:
>> * Split out the syntactic sugar version of &foo { }; into a different
>> patches to make things clearer.
>> * Reworked a bit the arguments passed to fixup node generation method
>> making things simpler and utilize common methodology.
>> * Avoid string parsing the full path using the node walking instead for
>> local fixup generation.
>> * Added an option to suppress generation of fixup nodes on base trees.
>> * Added automatic generation of symbols and fixups when compiling a
>> plugin.
>> * Minor rework according to maintainer requests.
>>
>> Changes since v9:
>> * Reversed -M switch to by default use new DTBO magic value.
>> * Removed global versionflags in the parser by using inherited
>> attributes.
>> * build_node instead of malloc at add_orphan_node().
>> * Do not use escape for path copy
>> * Do not generate /plugin/ when generating a dts file even when
>> the plugin flag is set..
>>
>> Changes since v8:
>> * Removed extra member of boot_info in each node; passing boot_info
>> parameter to the check methods instead.
>> * Reworked yacc syntax that supports both old and new plugin syntax
>> * Added handling for new magic number (enabled by 'M' switch).
>> * Dropped dtbo/asmo formats.
>> * Added overlay testsuite.
>> * Addressed last version maintainer comments.
>>
>> Changes since v7:
>> * Dropped xasprintf & backward compatibility patch
>> * Rebased against dgibson's overlay branch
>> * Minor doc wording fixes.
>>
>> Changes since v6:
>> * Introduced xasprintf
>> * Added append_to_property and used it
>> * Changed some die()'s to assert
>> * Reordered node generation to respect sort
>> * Addressed remaining maintainer changes from v6
>>
>> Changes since v5:
>> * Rebase to latest dtc version.
>> * Addressed all the maintainer requested changes from v5
>> * Added new magic value for dynamic objects and new format
>>
>> Changes since v4:
>> * Rebase to latest dtc version.
>> * Completely redesigned the generation of resolution data.
>> Now instead of being generated as part of blob generation
>> they are created in the live tree.
>> * Consequently the patchset is much smaller.
>> * Added -A auto-label alias generation option.
>> * Addressed maintainer comments.
>> * Added syntactic sugar for overlays in the form of .dtsi
>> * Added /dts-v1/ /plugin/ preferred plugin form and deprecate
>> the previous form (although still works for backward compatibility)
>>
>> Changes since v3:
>> * Rebase to latest dtc version.
>>
>> Changes since v2:
>> * Split single patch to a patchset.
>> * Updated to dtc mainline.
>> * Changed __local_fixups__ format
>> * Clean up for better legibility.
>> Pantelis Antoniou (7):
>> dtc: Document the dynamic plugin internals
>> dtc: Plugin and fixup support
>> tests: Add check_path test
>> tests: Add overlay tests
>> overlay: Documentation for the overlay sugar syntax
>> overlay: Add syntactic sugar version of overlays
>> tests: Add a test for overlays syntactic sugar
>>
>> Documentation/dt-object-internal.txt | 327 +++++++++++++++++++++++++++++++++++
>> Documentation/manual.txt | 21 ++-
>> checks.c | 8 +-
>> dtc-lexer.l | 5 +
>> dtc-parser.y | 48 ++++-
>> dtc.c | 33 +++-
>> dtc.h | 17 +-
>> flattree.c | 2 +-
>> fstree.c | 2 +-
>> livetree.c | 291 ++++++++++++++++++++++++++++++-
>> tests/.gitignore | 1 +
>> tests/Makefile.tests | 3 +-
>> tests/check_path.c | 82 +++++++++
>> tests/overlay_base_fixups.dts | 22 +++
>> tests/overlay_overlay_dtc.dts | 1 +
>> tests/overlay_overlay_simple.dts | 12 ++
>> tests/run_tests.sh | 38 ++++
>> 17 files changed, 898 insertions(+), 15 deletions(-)
>> create mode 100644 Documentation/dt-object-internal.txt
>> create mode 100644 tests/check_path.c
>> create mode 100644 tests/overlay_base_fixups.dts
>> create mode 100644 tests/overlay_overlay_simple.dts
>>
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
--
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
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