Devicetree
 help / color / mirror / Atom feed
* 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 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

* [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 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 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 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 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 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 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 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 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 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 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"
 
 &reg_aldo1 {
 	regulator-always-on;
-- 
2.9.3

^ permalink raw reply related

* [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"
 
 &reg_aldo1 {
 	regulator-always-on;
-- 
2.9.3


^ permalink raw reply related

* [PATCH v2 10/11] ARM: dts: sun8i-r16-parrot: 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 Allwinner Parrot R16 used everything declared in AXP221
DTSI while it has an AXP223 PMIC.

This corrects that so the Allwinner Parrot R16 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-r16-parrot.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-r16-parrot.dts b/arch/arm/boot/dts/sun8i-r16-parrot.dts
index 47553e5..6afdba3 100644
--- a/arch/arm/boot/dts/sun8i-r16-parrot.dts
+++ b/arch/arm/boot/dts/sun8i-r16-parrot.dts
@@ -209,7 +209,7 @@
 	};
 };
 
-#include "axp22x.dtsi"
+#include "axp223.dtsi"
 
 &reg_aldo1 {
 	regulator-always-on;
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2 11/11] ARM: dtsi: sun8i-reference-design-tablet: 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 sun8i tablets used everything declared in AXP221 DTSI
while they have an AXP223 PMIC.

This corrects that so the sun8i tablets 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-reference-design-tablet.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
index 08cd001..ea79c33 100644
--- a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
@@ -136,7 +136,7 @@
 	};
 };
 
-#include "axp22x.dtsi"
+#include "axp223.dtsi"
 
 &reg_aldo1 {
 	regulator-always-on;
-- 
2.9.3

^ permalink raw reply related

* Re: [PATCH v2 1/8] mfd: sun6i-prcm: Add codec analog controls sub-device for Allwinner A23
From: Lee Jones @ 2016-12-09 11:22 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Liam Girdwood, Mark Brown, Maxime Ripard, alsa-devel,
	linux-arm-kernel, linux-kernel, devicetree, Mylene Josserand
In-Reply-To: <20161125123442.28410-2-wens@csie.org>

On Fri, 25 Nov 2016, Chen-Yu Tsai wrote:

> The PRCM block on the A23 contains a message box like interface to
> the registers for the analog path controls of the internal codec.
> 
> Add a sub-device for it.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  drivers/mfd/sun6i-prcm.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)

Applied for v4.11, thanks.

> diff --git a/drivers/mfd/sun6i-prcm.c b/drivers/mfd/sun6i-prcm.c
> index 011fcc555945..2b658bed47db 100644
> --- a/drivers/mfd/sun6i-prcm.c
> +++ b/drivers/mfd/sun6i-prcm.c
> @@ -12,6 +12,9 @@
>  #include <linux/init.h>
>  #include <linux/of.h>
>  
> +#define SUN8I_CODEC_ANALOG_BASE	0x1c0
> +#define SUN8I_CODEC_ANALOG_SIZE	0x4
> +
>  struct prcm_data {
>  	int nsubdevs;
>  	const struct mfd_cell *subdevs;
> @@ -57,6 +60,10 @@ static const struct resource sun6i_a31_apb0_rstc_res[] = {
>  	},
>  };
>  
> +static const struct resource sun8i_codec_analog_res[] = {
> +	DEFINE_RES_MEM(SUN8I_CODEC_ANALOG_BASE, SUN8I_CODEC_ANALOG_SIZE),
> +};
> +
>  static const struct mfd_cell sun6i_a31_prcm_subdevs[] = {
>  	{
>  		.name = "sun6i-a31-ar100-clk",
> @@ -109,6 +116,12 @@ static const struct mfd_cell sun8i_a23_prcm_subdevs[] = {
>  		.num_resources = ARRAY_SIZE(sun6i_a31_apb0_rstc_res),
>  		.resources = sun6i_a31_apb0_rstc_res,
>  	},
> +	{
> +		.name		= "sun8i-codec-analog",
> +		.of_compatible	= "allwinner,sun8i-a23-codec-analog",
> +		.num_resources	= ARRAY_SIZE(sun8i_codec_analog_res),
> +		.resources	= sun8i_codec_analog_res,
> +	},
>  };
>  
>  static const struct prcm_data sun6i_a31_prcm_data = {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH] ARM: dts: am335x-chiliboard: Support power button
From: Marcin Niestroj @ 2016-12-09 11:32 UTC (permalink / raw)
  To: Benoît Cousson
  Cc: Tony Lindgren, Rob Herring, Mark Rutland,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Marcin Niestroj

On chiliBoard power button is connected to TPS65217. It signals power
button presses by asserting interrupt output and allows to read the
state by i2c bus.

Handle TPS65217 interrupts and enable notifications of power button
presses.

Signed-off-by: Marcin Niestroj <m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
---
 arch/arm/boot/dts/am335x-chiliboard.dts | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-chiliboard.dts b/arch/arm/boot/dts/am335x-chiliboard.dts
index 2a624b3..3cc870a 100644
--- a/arch/arm/boot/dts/am335x-chiliboard.dts
+++ b/arch/arm/boot/dts/am335x-chiliboard.dts
@@ -185,3 +185,13 @@
 	cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
 	status = "okay";
 };
+
+/* Power button */
+&tps {
+	interrupt-parent = <&intc>;
+	interrupts = <7>; /* NNMI */
+
+	tps65217-pwrbutton {
+		compatible = "ti,tps65217-pwrbutton";
+	};
+};
-- 
2.10.2

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

* [PATCH] ARM: dts: am335x-chilisom: Wakeup from RTC-only state by power on event
From: Marcin Niestroj @ 2016-12-09 11:33 UTC (permalink / raw)
  To: Benoît Cousson
  Cc: Tony Lindgren, Rob Herring, Mark Rutland,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Marcin Niestroj

On chiliSOM TPS65217 nWAKEUP pin is connected to AM335x internal RTC
EXT_WAKEUP input. In RTC-only state TPS65217 is notifying about power on
events (such as power buton presses) by setting nWAKEUP output
low. After that it waits 5s for proper device boot. Currently it doesn't
happen, as the processor doesn't listen for such events. Consequently
TPS65217 changes state from SLEEP (RTC-only state) to OFF.

Enable EXT_WAKEUP input of AM335x's RTC, so the processor can properly
detect power on events and recover immediately from RTC-only states,
without powering off RTC and losing time.

Signed-off-by: Marcin Niestroj <m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
---
 arch/arm/boot/dts/am335x-chilisom.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-chilisom.dtsi b/arch/arm/boot/dts/am335x-chilisom.dtsi
index f9ee585..1b43ebd 100644
--- a/arch/arm/boot/dts/am335x-chilisom.dtsi
+++ b/arch/arm/boot/dts/am335x-chilisom.dtsi
@@ -124,6 +124,14 @@
 
 &rtc {
 	system-power-controller;
+
+	pinctrl-0 = <&ext_wakeup>;
+	pinctrl-names = "default";
+
+	ext_wakeup: ext-wakeup {
+		pins = "ext_wakeup0";
+		input-enable;
+	};
 };
 
 /* NAND Flash */
-- 
2.10.2

--
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 02/12] ARM: dts: imx6qdl: rename ipu client nodes
From: Philipp Zabel @ 2016-12-09 11:39 UTC (permalink / raw)
  To: Steve Longerbeam
  Cc: shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
	fabio.estevam-3arQi8VN3Tc, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
	tomi.valkeinen-l0cyMroinI0,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Steve Longerbeam
In-Reply-To: <1481158673-15937-3-git-send-email-steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>

Hi Steve,

Am Mittwoch, den 07.12.2016, 16:57 -0800 schrieb Steve Longerbeam:
> To allow for IPU client devices that are composed of more than one
> port for input and output (SMFC and IC), change the nodes from being
> a single port node to nodes that can contain multiple ports. Rename
> the nodes to use the following format: "ipu<id>_<subunit>".

Don't do this. These are not IPU client device nodes, they are input and
output port nodes according to the of graph bindings, as described in
Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt.

They happen to match to the CSI0/1 and DI0/1 modules, but really what is
described here are the external connections of the IPU. The IPU
internals are not described in the device tree at all.

regards
Philipp

> The IPUv3 driver will then need to lookup the client nodes by name
> rather than by port id.
> 
> Signed-off-by: Steve Longerbeam <steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
> ---
>  arch/arm/boot/dts/imx6q.dtsi   | 12 ++++++------
>  arch/arm/boot/dts/imx6qdl.dtsi | 12 ++++++------
>  2 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index e9a5d0b..2b261ba 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -141,18 +141,18 @@
>  			clock-names = "bus", "di0", "di1";
>  			resets = <&src 4>;
>  
> -			ipu2_csi0: port@0 {
> +			ipu2_csi0: ipu2_csi@0 {
>  				reg = <0>;
>  			};
>  
> -			ipu2_csi1: port@1 {
> +			ipu2_csi1: ipu2_csi@1 {
>  				reg = <1>;
>  			};
>  
> -			ipu2_di0: port@2 {
> +			ipu2_di0: ipu2_di@0 {
>  				#address-cells = <1>;
>  				#size-cells = <0>;
> -				reg = <2>;
> +				reg = <0>;
>  
>  				ipu2_di0_disp0: disp0-endpoint {
>  				};
> @@ -174,10 +174,10 @@
>  				};
>  			};
>  
> -			ipu2_di1: port@3 {
> +			ipu2_di1: ipu2_di@1 {
>  				#address-cells = <1>;
>  				#size-cells = <0>;
> -				reg = <3>;
> +				reg = <1>;
>  
>  				ipu2_di1_hdmi: hdmi-endpoint {
>  					remote-endpoint = <&hdmi_mux_3>;
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index e01e5d5..2465187 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -1226,18 +1226,18 @@
>  			clock-names = "bus", "di0", "di1";
>  			resets = <&src 2>;
>  
> -			ipu1_csi0: port@0 {
> +			ipu1_csi0: ipu1_csi@0 {
>  				reg = <0>;
>  			};
>  
> -			ipu1_csi1: port@1 {
> +			ipu1_csi1: ipu1_csi@1 {
>  				reg = <1>;
>  			};
>  
> -			ipu1_di0: port@2 {
> +			ipu1_di0: ipu1_di@0 {
>  				#address-cells = <1>;
>  				#size-cells = <0>;
> -				reg = <2>;
> +				reg = <0>;
>  
>  				ipu1_di0_disp0: disp0-endpoint {
>  				};
> @@ -1259,10 +1259,10 @@
>  				};
>  			};
>  
> -			ipu1_di1: port@3 {
> +			ipu1_di1: ipu1_di@1 {
>  				#address-cells = <1>;
>  				#size-cells = <0>;
> -				reg = <3>;
> +				reg = <1>;
>  
>  				ipu1_di1_disp1: disp1-endpoint {
>  				};


--
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: Re: [PATCH 2/2] arm: dts: sun8i: reuse the uart1 node of iNet D978 rev2 board
From: Icenowy Zheng @ 2016-12-09 11:42 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Hans de Goede, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel, Chen-Yu Tsai, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw


2016年12月9日 下午4:11于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道:
>
> On Mon, Dec 05, 2016 at 05:03:35PM +0800, Icenowy Zheng wrote: 
> > 
> > 2016年12月5日 16:50于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道: 
> > > 
> > > On Fri, Dec 02, 2016 at 11:19:13PM +0800, Icenowy Zheng wrote: 
> > > > As a uart1 node is added into sun8i-reference-design-tablet.dtsi, simply 
> > > > use it in iNet D978 rev2 device tree. 
> > > > 
> > > > Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org> 
> > > 
> > > I'd like to see more consolidation before that change is needed. If we 
> > > find more boards using that, it will make sense, but for a single 
> > > board it's not worth it. 
> > 
> > At least 2~3 Q8 A33 tablets in #linux-sunxi are found to have 
> > rtl8703as, which contains UART bluetooth. (including mine) 
>
> Still, I'm not fond of creating a default on such a low count sample 
> of (out-of-tree) DTs. Support and enable the bluetooth on more boards, 
> and then consolidate. 
>
> > In fact, what I want to do is to get the node ready-to-be-okay in Q8 
> > dts, so it can be enabled by either u-boot command or (theortically) 
> > Hans de Goede's q8-hardwaremgr, just like what is done at 
> > touchscreen node. 
>
> If your plan is to enable all the combinations possible accross the Q8 
> tablets and let the bootloader/user figure it all out, then it's not 
> going to happen, sorry. 

This wire is in the A23/33 tablet reference design schemetics.

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

-- 
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 1/2] devicetree: i2c-hid: Add regulator support
From: Jiri Kosina @ 2016-12-09 12:17 UTC (permalink / raw)
  To: Brian Norris
  Cc: Benjamin Tissoires, Caesar Wang, linux-rockchip, Rob Herring,
	linux-input, devicetree, linux-kernel, Dmitry Torokhov,
	Mark Rutland, Doug Anderson
In-Reply-To: <1480717140-14558-1-git-send-email-briannorris@chromium.org>

On Fri, 2 Dec 2016, Brian Norris wrote:

> From: Caesar Wang <wxt@rock-chips.com>
> 
> Document a "vdd-supply" and an initialization delay. Can be used for
> powering on/off a HID.
> 
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: linux-input@vger.kernel.org
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> v2:
>  * add compatible property for wacom, per Rob's request
>  * name the regulator property specifically (VDD)
> 
> v3:
>  * remove wacom property, per Benjamin's request
>  * add delay property
> 
> v4: no change

Applied both patches to for-4.10/i2c-hid.

Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply

* Re: [PATCH v5 1/7] MFD: add bindings for STM32 General Purpose Timer driver
From: Benjamin Gaignard @ 2016-12-09 12:40 UTC (permalink / raw)
  To: Lee Jones
  Cc: robh+dt, Mark Rutland, alexandre.torgue, devicetree,
	Linux Kernel Mailing List, Thierry Reding, linux-pwm,
	Jonathan Cameron, knaack.h, Lars-Peter Clausen,
	Peter Meerwald-Stadler, linux-iio, linux-arm-kernel,
	Fabrice Gasnier, Gerald Baeza, Arnaud Pouliquen, Linus Walleij,
	Linaro Kernel Mailman List, Benjamin Gaignard
In-Reply-To: <20161209085331.GB3625@dell.home>

2016-12-09 9:53 GMT+01:00 Lee Jones <lee.jones@linaro.org>:
> 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.

I will do those name changes in v6.

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

No I don't use them so I will remove them in v6

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



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* Re: [PATCH 1/2] irqchip/renesas-intc-irqpin: List fallback compatibility last
From: Geert Uytterhoeven @ 2016-12-09 12:45 UTC (permalink / raw)
  To: Simon Horman
  Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
	Magnus Damm, linux-kernel@vger.kernel.org, Linux-Renesas,
	devicetree@vger.kernel.org
In-Reply-To: <1481280650-9258-2-git-send-email-horms+renesas@verge.net.au>

Hi Simon,

On Fri, Dec 9, 2016 at 11:50 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Improve readability by listing the rmobile fallback compatibility string

s/rmobile/generic/

> 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", },

BTW, I'm wondering what's the added value of keeping the generic
"renesas,intc-irqpin" fallback. There is no user of the pure generic version
only, and all SoC-specific versions are treated slightly different.

>         {},
>  };
>  MODULE_DEVICE_TABLE(of, intc_irqpin_dt_ids);

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/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding
From: Geert Uytterhoeven @ 2016-12-09 12:52 UTC (permalink / raw)
  To: Simon Horman
  Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
	Magnus Damm, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linux-Renesas, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1481280650-9258-3-git-send-email-horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>

Hi Simon,

On Fri, Dec 9, 2016 at 11:50 AM, Simon Horman
<horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> 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

it's

> 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-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
> ---
>  .../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)

Does it make sense to add a new family-specific compatible value to a driver
that's unlikely to receive more users in the future? More recent SoCs use
renesas,irqc.

If the answer is yes, do we want one for SH/R-Mobile too?

> +    - "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",

And now we have three compatible values to list...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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
--
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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox