* Re: [PATCH v15 04/11] pwm: clps711x: Use 64-bit division macro
From: Guru Das Srinagesh @ 2020-05-28 20:33 UTC (permalink / raw)
To: linux-pwm, Thierry Reding, Daniel Thompson, Uwe Kleine-König
Cc: linux-arm-kernel, Arnd Bergmann, David Collins, Stephen Boyd,
linux-kernel, Geert Uytterhoeven, Dan Carpenter, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck
In-Reply-To: <dd03cc467ac3fc470826aef523822b32e15dc929.1590514331.git.gurus@codeaurora.org>
On Tue, May 26, 2020 at 10:35:04AM -0700, Guru Das Srinagesh wrote:
> Since the PWM framework is switching struct pwm_args.period's datatype
> to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to
> handle a 64-bit divisor.
>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> ---
> drivers/pwm/pwm-clps711x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-clps711x.c b/drivers/pwm/pwm-clps711x.c
> index 924d39a..ba9500a 100644
> --- a/drivers/pwm/pwm-clps711x.c
> +++ b/drivers/pwm/pwm-clps711x.c
> @@ -43,7 +43,7 @@ static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v)
> static unsigned int clps711x_get_duty(struct pwm_device *pwm, unsigned int v)
> {
> /* Duty cycle 0..15 max */
> - return DIV_ROUND_CLOSEST(v * 0xf, pwm->args.period);
> + return DIV64_U64_ROUND_CLOSEST(v * 0xf, pwm->args.period);
> }
>
> static int clps711x_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
> --
Hi Daniel,
Could you please review this patch when you get a chance to?
Thank you.
Guru Das.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: omap2: drop broken broadcast timer hack
From: Arnd Bergmann @ 2020-05-28 20:33 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Rob Herring, Grygorii Strashko, Geert Uytterhoeven, Tony Lindgren,
Keerthy, linux-kernel@vger.kernel.org, Tero Kristo, Lokesh Vutla,
arm-soc, Olof Johansson, linux-omap, afzal mohammed, Linux ARM
In-Reply-To: <34e8fb61-b452-529b-b2c6-3849b2395096@oracle.com>
On Thu, May 28, 2020 at 6:18 PM <santosh.shilimkar@oracle.com> wrote:
> On 5/28/20 8:57 AM, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [200528 13:51]:
> >> * Tony Lindgren <tony@atomide.com> [200528 13:47]:
> >>> * Arnd Bergmann <arnd@arndb.de> [200528 09:20]:
> >>>> The OMAP4 timer code had a special hack for using the broadcast timer
> >>>> without SMP. Since the dmtimer is now gone, this also needs to be dropped
> >>>> to avoid a link failure for non-SMP AM43xx configurations:
> >>>>
> >>>> kernel/time/tick-broadcast.o: in function `tick_device_uses_broadcast':
> >>>> tick-broadcast.c:(.text+0x130): undefined reference to `tick_broadcast'
> >>>
> >>> Hmm this sounds like a regression though. Isn't this needed for using
> >>> the ARM local timers on non-SMP SoC, so a separate timer from dmtimer?
> >>>
> >>> I've probably removed something accidentally to cause this.
> >>
> >> Sounds like arch/arm/mach-omap2/Makefile change needs to be removed
> >> to always still build in timer.o. And probably timer.c needs back
> >> the ifdef for CONFIG_SOC_HAS_REALTIME_COUNTER.
> >>
> >> I'll take a look today.
> >
> > I've sent a patch along those lines as:
> >
> > [PATCH] ARM: OMAP2+: Fix regression for using local timer on non-SMP SoCs
> >
> > A link for the patch at [0] below.
> >
> CPU local timers not being in always ON power domain use to be the
> reason on early version of the SOCs but later SOC moved the CPU local
> timer also in always on domain. Probably AM43xx does loose local timer
> on CPU PD in low power so yes broadcast would be needed with dmtimer
> help.
>
> >
> > [0] https://lore.kernel.org/linux-omap/20200528155453.8585-1-tony@atomide.com/T/#u
> >
> This should restore it.
Should I apply the fix directly to the arm/soc branch that has the
other changes then?
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: omap2: drop broken broadcast timer hack
From: Tony Lindgren @ 2020-05-28 20:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rob Herring, Grygorii Strashko, Geert Uytterhoeven, Lokesh Vutla,
Keerthy, Santosh Shilimkar, linux-kernel@vger.kernel.org,
Tero Kristo, arm-soc, Olof Johansson, linux-omap, afzal mohammed,
Linux ARM
In-Reply-To: <CAK8P3a0AaH+pAdhu7jzEAGC-bECgmz7w=D8PN6NOUjj2kxevkg@mail.gmail.com>
* Arnd Bergmann <arnd@arndb.de> [200528 20:35]:
> On Thu, May 28, 2020 at 6:18 PM <santosh.shilimkar@oracle.com> wrote:
> > On 5/28/20 8:57 AM, Tony Lindgren wrote:
> > > * Tony Lindgren <tony@atomide.com> [200528 13:51]:
> > >> * Tony Lindgren <tony@atomide.com> [200528 13:47]:
> > >>> * Arnd Bergmann <arnd@arndb.de> [200528 09:20]:
> > >>>> The OMAP4 timer code had a special hack for using the broadcast timer
> > >>>> without SMP. Since the dmtimer is now gone, this also needs to be dropped
> > >>>> to avoid a link failure for non-SMP AM43xx configurations:
> > >>>>
> > >>>> kernel/time/tick-broadcast.o: in function `tick_device_uses_broadcast':
> > >>>> tick-broadcast.c:(.text+0x130): undefined reference to `tick_broadcast'
> > >>>
> > >>> Hmm this sounds like a regression though. Isn't this needed for using
> > >>> the ARM local timers on non-SMP SoC, so a separate timer from dmtimer?
> > >>>
> > >>> I've probably removed something accidentally to cause this.
> > >>
> > >> Sounds like arch/arm/mach-omap2/Makefile change needs to be removed
> > >> to always still build in timer.o. And probably timer.c needs back
> > >> the ifdef for CONFIG_SOC_HAS_REALTIME_COUNTER.
> > >>
> > >> I'll take a look today.
> > >
> > > I've sent a patch along those lines as:
> > >
> > > [PATCH] ARM: OMAP2+: Fix regression for using local timer on non-SMP SoCs
> > >
> > > A link for the patch at [0] below.
> > >
> > CPU local timers not being in always ON power domain use to be the
> > reason on early version of the SOCs but later SOC moved the CPU local
> > timer also in always on domain. Probably AM43xx does loose local timer
> > on CPU PD in low power so yes broadcast would be needed with dmtimer
> > help.
> >
> > >
> > > [0] https://lore.kernel.org/linux-omap/20200528155453.8585-1-tony@atomide.com/T/#u
> > >
> > This should restore it.
>
> Should I apply the fix directly to the arm/soc branch that has the
> other changes then?
Sure please do, that saves a single-fix pull request.
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] ARM: dts: orange-pi-zero-plus2: enable USB OTG port
From: Diego Rondini @ 2020-05-28 20:47 UTC (permalink / raw)
To: Maxime Ripard
Cc: devicetree, Chen-Yu Tsai, linux-kernel, Diego Rondini,
linux-sunxi, Rob Herring, linux-arm-kernel
Enable support for USB OTG port on Orange Pi Zero Plus 2 (both H3 and H5
variants). As, according to the board schematics, the USB OTG port cannot
provide power to external devices, we set dr_mode to peripheral.
Signed-off-by: Diego Rondini <diego.rondini@kynetics.com>
---
.../boot/dts/sun8i-h3-orangepi-zero-plus2.dts | 23 +++++++++++++++++++
.../sun50i-h5-orangepi-zero-plus2.dts | 23 +++++++++++++++++++
2 files changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-zero-plus2.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-zero-plus2.dts
index b8f46e2802fd3..4376767699a47 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-zero-plus2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-zero-plus2.dts
@@ -137,3 +137,26 @@ &uart0 {
pinctrl-0 = <&uart0_pa_pins>;
status = "okay";
};
+
+&usbphy {
+ status = "okay";
+};
+
+&usb_otg {
+ /*
+ * According to schematics CN1 MicroUSB port can be used to take
+ * external 5V to power up the board VBUS. On the contrary CN1 MicroUSB
+ * port cannot provide power externally even if the board is powered
+ * via GPIO pins. It thus makes sense to force peripheral mode.
+ */
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
index c95a68541309c..d8192a7483e9e 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
@@ -103,3 +103,26 @@ &uart1 {
pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
status = "okay";
};
+
+&usbphy {
+ status = "okay";
+};
+
+&usb_otg {
+ /*
+ * According to schematics CN1 MicroUSB port can be used to take
+ * external 5V to power up the board VBUS. On the contrary CN1 MicroUSB
+ * port cannot provide power externally even if the board is powered
+ * via GPIO pins. It thus makes sense to force peripheral mode.
+ */
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
--
2.25.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: orange-pi-zero-plus2: add leds configuration
From: Diego Rondini @ 2020-05-28 20:47 UTC (permalink / raw)
To: Maxime Ripard
Cc: devicetree, Chen-Yu Tsai, linux-kernel, Diego Rondini,
linux-sunxi, Rob Herring, linux-arm-kernel
In-Reply-To: <20200528204712.552964-1-diego.rondini@kynetics.com>
Add pwr and status leds configuration and turn on pwr led by default for Orange
Pi Zero Plus 2 (both H3 and H5 variants).
Signed-off-by: Diego Rondini <diego.rondini@kynetics.com>
---
.../boot/dts/sun8i-h3-orangepi-zero-plus2.dts | 16 ++++++++++++++++
.../allwinner/sun50i-h5-orangepi-zero-plus2.dts | 16 ++++++++++++++++
2 files changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-zero-plus2.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-zero-plus2.dts
index 4376767699a47..4cd0ac706bd2c 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-zero-plus2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-zero-plus2.dts
@@ -82,6 +82,22 @@ wifi_pwrseq: wifi_pwrseq {
reset-gpios = <&pio 0 9 GPIO_ACTIVE_LOW>; /* PA9 */
post-power-on-delay-ms = <200>;
};
+
+ leds {
+ compatible = "gpio-leds";
+
+ pwr_led {
+ label = "orangepi:green:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ status_led {
+ label = "orangepi:red:status";
+ gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
+ };
+
+ };
};
&de {
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
index d8192a7483e9e..517d53e1b0ff1 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
@@ -42,6 +42,22 @@ wifi_pwrseq: wifi_pwrseq {
reset-gpios = <&pio 0 9 GPIO_ACTIVE_LOW>; /* PA9 */
post-power-on-delay-ms = <200>;
};
+
+ leds {
+ compatible = "gpio-leds";
+
+ pwr_led {
+ label = "orangepi:green:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ status_led {
+ label = "orangepi:red:status";
+ gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
+ };
+
+ };
};
&de {
--
2.25.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 5/8] dt-bindings: display: panel: Add ilitek ili9341 panel bindings
From: Rob Herring @ 2020-05-28 20:49 UTC (permalink / raw)
To: dillon.minfei
Cc: devicetree, p.zabel, airlied, mturquette, linux-stm32,
linux-kernel, dri-devel, linux-spi, robh+dt, thierry.reding,
broonie, linux-arm-kernel, daniel, sboyd, sam, linux-clk,
mcoquelin.stm32, alexandre.torgue
In-Reply-To: <1589800165-3271-6-git-send-email-dillon.minfei@gmail.com>
On Mon, 18 May 2020 19:09:22 +0800, dillon.minfei@gmail.com wrote:
> From: dillon min <dillon.minfei@gmail.com>
>
> Add documentation for "ilitek,ili9341" panel.
>
> Signed-off-by: dillon min <dillon.minfei@gmail.com>
> ---
> .../bindings/display/panel/ilitek,ili9341.yaml | 69 ++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2] dt-bindings: clock: Convert i.MX7D clock to json-schema
From: Rob Herring @ 2020-05-28 20:54 UTC (permalink / raw)
To: Anson Huang
Cc: devicetree, s.hauer, sboyd, shawnguo, mturquette, Frank.Li,
linux-kernel, robh+dt, Linux-imx, kernel, festevam, linux-clk,
linux-arm-kernel
In-Reply-To: <1589813554-20929-1-git-send-email-Anson.Huang@nxp.com>
On Mon, 18 May 2020 22:52:34 +0800, Anson Huang wrote:
> Convert the i.MX7D clock binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V1:
> - Update maintainer's e-mail address.
> ---
> .../devicetree/bindings/clock/imx7d-clock.txt | 13 -----
> .../devicetree/bindings/clock/imx7d-clock.yaml | 64 ++++++++++++++++++++++
> 2 files changed, 64 insertions(+), 13 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/clock/imx7d-clock.txt
> create mode 100644 Documentation/devicetree/bindings/clock/imx7d-clock.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 1/3] dt-bindings: timer: Convert i.MX GPT to json-schema
From: Rob Herring @ 2020-05-28 20:58 UTC (permalink / raw)
To: Anson Huang
Cc: aisheng.dong, devicetree, ping.bai, shawnguo, s.hauer,
daniel.lezcano, linux-kernel, Linux-imx, kernel, tglx, festevam,
linux-arm-kernel
In-Reply-To: <1589860547-3207-2-git-send-email-Anson.Huang@nxp.com>
On Tue, May 19, 2020 at 11:55:45AM +0800, Anson Huang wrote:
> Convert the i.MX GPT binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V1:
> - remove unnecessary compatible item descriptions;
> - remove unnecessary maxItems for clocks/clock-names;
> ---
> .../devicetree/bindings/timer/fsl,imxgpt.txt | 45 ------------
> .../devicetree/bindings/timer/fsl,imxgpt.yaml | 80 ++++++++++++++++++++++
> 2 files changed, 80 insertions(+), 45 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
>
> diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> deleted file mode 100644
> index 5d8fd5b..0000000
> --- a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> +++ /dev/null
> @@ -1,45 +0,0 @@
> -Freescale i.MX General Purpose Timer (GPT)
> -
> -Required properties:
> -
> -- compatible : should be one of following:
> - for i.MX1:
> - - "fsl,imx1-gpt";
> - for i.MX21:
> - - "fsl,imx21-gpt";
> - for i.MX27:
> - - "fsl,imx27-gpt", "fsl,imx21-gpt";
> - for i.MX31:
> - - "fsl,imx31-gpt";
> - for i.MX25:
> - - "fsl,imx25-gpt", "fsl,imx31-gpt";
> - for i.MX50:
> - - "fsl,imx50-gpt", "fsl,imx31-gpt";
> - for i.MX51:
> - - "fsl,imx51-gpt", "fsl,imx31-gpt";
> - for i.MX53:
> - - "fsl,imx53-gpt", "fsl,imx31-gpt";
> - for i.MX6Q:
> - - "fsl,imx6q-gpt", "fsl,imx31-gpt";
> - for i.MX6DL:
> - - "fsl,imx6dl-gpt";
> - for i.MX6SL:
> - - "fsl,imx6sl-gpt", "fsl,imx6dl-gpt";
> - for i.MX6SX:
> - - "fsl,imx6sx-gpt", "fsl,imx6dl-gpt";
> -- reg : specifies base physical address and size of the registers.
> -- interrupts : should be the gpt interrupt.
> -- clocks : the clocks provided by the SoC to drive the timer, must contain
> - an entry for each entry in clock-names.
> -- clock-names : must include "ipg" entry first, then "per" entry.
> -
> -Example:
> -
> -gpt1: timer@10003000 {
> - compatible = "fsl,imx27-gpt", "fsl,imx21-gpt";
> - reg = <0x10003000 0x1000>;
> - interrupts = <26>;
> - clocks = <&clks IMX27_CLK_GPT1_IPG_GATE>,
> - <&clks IMX27_CLK_PER1_GATE>;
> - clock-names = "ipg", "per";
> -};
> diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
> new file mode 100644
> index 0000000..5479290
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
> @@ -0,0 +1,80 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/timer/fsl,imxgpt.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX General Purpose Timer (GPT)
> +
> +maintainers:
> + - Sascha Hauer <s.hauer@pengutronix.de>
> +
> +properties:
> + compatible:
> + oneOf:
> + - const: "fsl,imx1-gpt"
> + - const: "fsl,imx21-gpt"
> + - items:
> + - const: "fsl,imx27-gpt"
> + - const: "fsl,imx21-gpt"
> + - const: "fsl,imx31-gpt"
> + - items:
> + - const: "fsl,imx25-gpt"
> + - const: "fsl,imx31-gpt"
> + - items:
> + - const: "fsl,imx50-gpt"
> + - const: "fsl,imx31-gpt"
> + - items:
> + - const: "fsl,imx51-gpt"
> + - const: "fsl,imx31-gpt"
> + - items:
> + - const: "fsl,imx53-gpt"
> + - const: "fsl,imx31-gpt"
> + - items:
> + - const: "fsl,imx6q-gpt"
> + - const: "fsl,imx31-gpt"
> + - const: "fsl,imx6dl-gpt"
> + - items:
> + - const: "fsl,imx6sl-gpt"
> + - const: "fsl,imx6dl-gpt"
> + - items:
> + - const: "fsl,imx6sx-gpt"
> + - const: "fsl,imx6dl-gpt"
Don't need quotes.
Group all the ones with the same fallback to a single 'items' list
using enum for the first entry.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 2/3] dt-bindings: timer: Convert i.MX TPM to json-schema
From: Rob Herring @ 2020-05-28 20:59 UTC (permalink / raw)
To: Anson Huang
Cc: aisheng.dong, devicetree, ping.bai, festevam, s.hauer,
daniel.lezcano, linux-kernel, robh+dt, Linux-imx, kernel, tglx,
shawnguo, linux-arm-kernel
In-Reply-To: <1589860547-3207-3-git-send-email-Anson.Huang@nxp.com>
On Tue, 19 May 2020 11:55:46 +0800, Anson Huang wrote:
> Convert the i.MX TPM binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> Changes since V1:
> - remove unnecessary maxItems for clocks/clock-names.
> ---
> .../devicetree/bindings/timer/nxp,tpm-timer.txt | 28 ----------
> .../devicetree/bindings/timer/nxp,tpm-timer.yaml | 61 ++++++++++++++++++++++
> 2 files changed, 61 insertions(+), 28 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
> create mode 100644 Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 3/3] dt-bindings: timer: Convert i.MX SYSCTR to json-schema
From: Rob Herring @ 2020-05-28 21:00 UTC (permalink / raw)
To: Anson Huang
Cc: aisheng.dong, devicetree, ping.bai, shawnguo, s.hauer,
daniel.lezcano, linux-kernel, robh+dt, Linux-imx, kernel, tglx,
festevam, linux-arm-kernel
In-Reply-To: <1589860547-3207-4-git-send-email-Anson.Huang@nxp.com>
On Tue, 19 May 2020 11:55:47 +0800, Anson Huang wrote:
> Convert the i.MX SYSCTR binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> No changes.
> ---
> .../devicetree/bindings/timer/nxp,sysctr-timer.txt | 25 ----------
> .../bindings/timer/nxp,sysctr-timer.yaml | 54 ++++++++++++++++++++++
> 2 files changed, 54 insertions(+), 25 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
> create mode 100644 Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 08/16] soc: mediatek: cmdq: add write_s function
From: Matthias Brugger @ 2020-05-28 21:08 UTC (permalink / raw)
To: Dennis YC Hsieh, Rob Herring, Mark Rutland, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: devicetree, wsd_upstream, linux-kernel, dri-devel, HS Liao,
linux-mediatek, Houlong Wei, Bibby Hsieh, CK Hu, linux-arm-kernel
In-Reply-To: <1590685491-17107-9-git-send-email-dennis-yc.hsieh@mediatek.com>
On 28/05/2020 19:04, Dennis YC Hsieh wrote:
> add write_s function in cmdq helper functions which
> writes value contains in internal register to address
> with large dma access support.
>
> Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 21 ++++++++++++++++++++-
> include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
> include/linux/soc/mediatek/mtk-cmdq.h | 20 ++++++++++++++++++++
> 3 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 33153d17c9d9..ee24c0ec0a24 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -18,6 +18,10 @@ struct cmdq_instruction {
> union {
> u32 value;
> u32 mask;
> + struct {
> + u16 arg_c;
> + u16 src_reg;
> + };
> };
> union {
> u16 offset;
> @@ -29,7 +33,7 @@ struct cmdq_instruction {
> struct {
> u8 sop:5;
> u8 arg_c_t:1;
> - u8 arg_b_t:1;
> + u8 src_t:1;
This should be part of 7/16.
> u8 dst_t:1;
> };
> };
> @@ -222,6 +226,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> }
> EXPORT_SYMBOL(cmdq_pkt_write_mask);
>
> +int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> + u16 addr_low, u16 src_reg_idx)
> +{
> + struct cmdq_instruction inst = { {0} };
If you want an empty struct on the stack, I think {}; should be enough, right?
Regards,
Matthias
> +
> + inst.op = CMDQ_CODE_WRITE_S;
> + inst.src_t = CMDQ_REG_TYPE;
> + inst.sop = high_addr_reg_idx;
> + inst.offset = addr_low;
> + inst.src_reg = src_reg_idx;
> +
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_write_s);
> +
> int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> {
> struct cmdq_instruction inst = { {0} };
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 121c3bb6d3de..ee67dd3b86f5 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -59,6 +59,7 @@ enum cmdq_code {
> CMDQ_CODE_JUMP = 0x10,
> CMDQ_CODE_WFE = 0x20,
> CMDQ_CODE_EOC = 0x40,
> + CMDQ_CODE_WRITE_S = 0x90,
> CMDQ_CODE_LOGIC = 0xa0,
> };
>
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> index 83340211e1d3..d623f1aa7814 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -12,6 +12,8 @@
> #include <linux/timer.h>
>
> #define CMDQ_NO_TIMEOUT 0xffffffffu
> +#define CMDQ_ADDR_HIGH(addr) ((u32)(((addr) >> 16) & GENMASK(31, 0)))
> +#define CMDQ_ADDR_LOW(addr) ((u16)(addr) | BIT(1))
>
> struct cmdq_pkt;
>
> @@ -102,6 +104,24 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value);
> int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> u16 offset, u32 value, u32 mask);
>
> +/**
> + * cmdq_pkt_write_s() - append write_s command to the CMDQ packet
> + * @pkt: the CMDQ packet
> + * @high_addr_reg_idx: internal register ID which contains high address of pa
> + * @addr_low: low address of pa
> + * @src_reg_idx: the CMDQ internal register ID which cache source value
> + * @mask: the specified target address mask, use U32_MAX if no need
> + *
> + * Return: 0 for success; else the error code is returned
> + *
> + * Support write value to physical address without subsys. Use CMDQ_ADDR_HIGH()
> + * to get high address and call cmdq_pkt_assign() to assign value into internal
> + * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low parameter when
> + * call to this function.
> + */
> +int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> + u16 addr_low, u16 src_reg_idx);
> +
> /**
> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
> * @pkt: the CMDQ packet
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: interrupt-controller: arm, gic: Document resets property
From: Rob Herring @ 2020-05-28 21:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: devicetree, Jason Cooper, Andre Przywara, linux-kernel,
linux-renesas-soc, Rob Herring, Marc Zyngier, Thomas Gleixner,
linux-arm-kernel
In-Reply-To: <20200519080519.28324-1-geert+renesas@glider.be>
On Tue, 19 May 2020 10:05:19 +0200, Geert Uytterhoeven wrote:
> A generic GIC block embedded in an SoC may be connected to an on-SoC
> reset controller. Hence allow the DTS writer to describe this relation,
> by documenting the optional presence of a "reset" property.
>
> This gets rid of "make dtbs_check" warnings like:
>
> arch/arm/boot/dts/r8a7791-porter.dt.yaml: interrupt-controller@f1001000: 'resets' does not match any of the regexes: '^v2m@[0-9a-f]+$', 'pinctrl-[0-9]+'
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> .../devicetree/bindings/interrupt-controller/arm,gic.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/4] ARM: dts: dove: Make the DT compliant with the ti,tfp410 binding
From: Laurent Pinchart @ 2020-05-28 21:12 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, jason, airlied, shawnguo, dri-devel, tomi.valkeinen,
kernel, Ricardo Cañuelo, linux-arm-kernel
In-Reply-To: <20200528173755.GA113289@bogus>
Hi Rob,
On Thu, May 28, 2020 at 11:37:55AM -0600, Rob Herring wrote:
> On Thu, May 14, 2020 at 04:36:09PM +0200, Ricardo Cañuelo wrote:
> > Define a 'ports' node for 'dvi: video@39' and use the proper naming for
> > the powerdown-gpios property to make it compliant with the ti,tfp410
> > binding.
> >
> > This fills the minimum requirements to meet the binding requirements,
> > port endpoints are not defined.
>
> Just make 'ports' optional. This isn't really any better unless you add
> endpoints too.
I wonder how this is supposed to work though. The ti-tfp410 driver will
fail to probe if there's no endpoint. I'd rather already add a node for
the DVI connector and connect it to port@1 of the TFP410.
> > Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> > ---
> > arch/arm/boot/dts/dove-sbc-a510.dts | 13 ++++++++++++-
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/dove-sbc-a510.dts b/arch/arm/boot/dts/dove-sbc-a510.dts
> > index 2bb85a9b7614..32804c981625 100644
> > --- a/arch/arm/boot/dts/dove-sbc-a510.dts
> > +++ b/arch/arm/boot/dts/dove-sbc-a510.dts
> > @@ -132,7 +132,18 @@
> > dvi: video@39 {
> > compatible = "ti,tfp410";
> > reg = <0x39>;
> > - powerdown-gpio = <&gpio_ext 3 GPIO_ACTIVE_LOW>;
> > + powerdown-gpios = <&gpio_ext 3 GPIO_ACTIVE_LOW>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + port@0 {
> > + reg = <0>;
> > + };
> > + port@1 {
> > + reg = <1>;
> > + };
> > + };
> > };
> > };
> >
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 05/10] dt-bindings: dmaengine: convert Actions Semi Owl SoCs bindings to yaml
From: Rob Herring @ 2020-05-28 21:17 UTC (permalink / raw)
To: Amit Singh Tomar
Cc: devicetree, andre.przywara, linux-actions, linux-kernel,
cristian.ciocaltea, vkoul, manivannan.sadhasivam, dan.j.williams,
afaerber, linux-arm-kernel
In-Reply-To: <1589912368-480-6-git-send-email-amittomer25@gmail.com>
On Tue, May 19, 2020 at 11:49:23PM +0530, Amit Singh Tomar wrote:
> Converts the device tree bindings for the Actions Semi Owl SoCs DMA
> Controller over to YAML schemas.
>
> It also adds new compatible string "actions,s700-dma".
>
> Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
> ---
> Change since v1:
> * Updated the description field to reflect
> only the necessary information.
> * replaced the maxItems field with description for each
> controller attribute(except interrupts).
> * Replaced the clock macro with number to keep the example
> as independent as possible.
>
> New patch, was not there in RFC.
> ---
> Documentation/devicetree/bindings/dma/owl-dma.txt | 47 -------------
> Documentation/devicetree/bindings/dma/owl-dma.yaml | 76 ++++++++++++++++++++++
> 2 files changed, 76 insertions(+), 47 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/dma/owl-dma.txt
> create mode 100644 Documentation/devicetree/bindings/dma/owl-dma.yaml
>
> diff --git a/Documentation/devicetree/bindings/dma/owl-dma.txt b/Documentation/devicetree/bindings/dma/owl-dma.txt
> deleted file mode 100644
> index 03e9bb12b75f..000000000000
> --- a/Documentation/devicetree/bindings/dma/owl-dma.txt
> +++ /dev/null
> @@ -1,47 +0,0 @@
> -* Actions Semi Owl SoCs DMA controller
> -
> -This binding follows the generic DMA bindings defined in dma.txt.
> -
> -Required properties:
> -- compatible: Should be "actions,s900-dma".
> -- reg: Should contain DMA registers location and length.
> -- interrupts: Should contain 4 interrupts shared by all channel.
> -- #dma-cells: Must be <1>. Used to represent the number of integer
> - cells in the dmas property of client device.
> -- dma-channels: Physical channels supported.
> -- dma-requests: Number of DMA request signals supported by the controller.
> - Refer to Documentation/devicetree/bindings/dma/dma.txt
> -- clocks: Phandle and Specifier of the clock feeding the DMA controller.
> -
> -Example:
> -
> -Controller:
> - dma: dma-controller@e0260000 {
> - compatible = "actions,s900-dma";
> - reg = <0x0 0xe0260000 0x0 0x1000>;
> - interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
> - #dma-cells = <1>;
> - dma-channels = <12>;
> - dma-requests = <46>;
> - clocks = <&clock CLK_DMAC>;
> - };
> -
> -Client:
> -
> -DMA clients connected to the Actions Semi Owl SoCs DMA controller must
> -use the format described in the dma.txt file, using a two-cell specifier
> -for each channel.
> -
> -The two cells in order are:
> -1. A phandle pointing to the DMA controller.
> -2. The channel id.
> -
> -uart5: serial@e012a000 {
> - ...
> - dma-names = "tx", "rx";
> - dmas = <&dma 26>, <&dma 27>;
> - ...
> -};
> diff --git a/Documentation/devicetree/bindings/dma/owl-dma.yaml b/Documentation/devicetree/bindings/dma/owl-dma.yaml
> new file mode 100644
> index 000000000000..82e7d261e967
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/owl-dma.yaml
> @@ -0,0 +1,76 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/dma/owl-dma.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Actions Semi Owl SoCs DMA controller
> +
> +description: |
> + The OWL DMA is a general-purpose direct memory access controller capable of
> + supporting 10 and 12 independent DMA channels for S700 and S900 SoCs
> + respectively.
> +
> +maintainers:
> + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> +
> +allOf:
> + - $ref: "dma-controller.yaml#"
> +
> +properties:
> + compatible:
> + enum:
> + - actions,s900-dma
> + - actions,s700-dma
> +
> + reg:
> + description:
> + DMA registers location and length.
Don't need a description. Just need:
maxItems: 1
> +
> + interrupts:
> + description:
> + controller supports 4 interrupts, which are freely assignable to the
> + DMA channels.
> + maxItems: 4
> +
> + "#dma-cells":
> + const: 1
> +
> + dma-channels:
> + description:
> + Physical channels supported.
Already defined in dma-controller.yaml. You need to add any constraints.
2^32 channels okay?
> +
> + dma-requests:
> + description:
> + Number of DMA request signals supported by the controller.
Same here.
> +
> + clocks:
> + description:
> + Phandle and Specifier of the clock feeding the DMA controller.
How many?
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - "#dma-cells"
> + - dma-channels
> + - dma-requests
> + - clocks
Add:
unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + dma: dma-controller@e0260000 {
> + compatible = "actions,s900-dma";
> + reg = <0x0 0xe0260000 0x0 0x1000>;
> + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
> + #dma-cells = <1>;
> + dma-channels = <12>;
> + dma-requests = <46>;
> + clocks = <&clock 22>;
> + };
> +
> +...
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 08/10] dt-bindings: mmc: owl: add compatible string actions, s700-mmc
From: Rob Herring @ 2020-05-28 21:17 UTC (permalink / raw)
To: Amit Singh Tomar
Cc: devicetree, andre.przywara, linux-actions, linux-kernel,
cristian.ciocaltea, robh+dt, manivannan.sadhasivam, afaerber,
linux-arm-kernel
In-Reply-To: <1589912368-480-9-git-send-email-amittomer25@gmail.com>
On Tue, 19 May 2020 23:49:26 +0530, Amit Singh Tomar wrote:
> The commit adds a new SoC specific compatible string "actions,s700-mmc"
> in combination with more generic string "actions,owl-mmc".
>
> Placement order of these strings should abide by the principle of
> "from most specific to most general".
>
> Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
> ---
> * Newly added patch in v2.
> ---
> Documentation/devicetree/bindings/mmc/owl-mmc.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 2/4] dt-bindings: regulator: add pca9450 regulator yaml
From: Rob Herring @ 2020-05-28 21:20 UTC (permalink / raw)
To: Robin Gong
Cc: devicetree, festevam, anson.huang, john.lee, catalin.marinas,
s.hauer, linux-kernel, robh+dt, lgirdwood, broonie, linux-imx,
kernel, shawnguo, will, linux-arm-kernel
In-Reply-To: <1589925907-9195-3-git-send-email-yibin.gong@nxp.com>
On Wed, 20 May 2020 06:05:05 +0800, Robin Gong wrote:
> Add device binding doc for pca9450 pmic driver.
>
> Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> ---
> .../bindings/regulator/nxp,pca9450-regulator.yaml | 190 +++++++++++++++++++++
> 1 file changed, 190 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: gpio: Convert mxs to json-schema
From: Rob Herring @ 2020-05-28 21:24 UTC (permalink / raw)
To: Anson Huang
Cc: devicetree, linux-gpio, shawnguo, s.hauer, linux-kernel,
bgolaszewski, robh+dt, Linux-imx, kernel, festevam, linus.walleij,
linux-arm-kernel
In-Reply-To: <1589934035-5309-1-git-send-email-Anson.Huang@nxp.com>
On Wed, 20 May 2020 08:20:35 +0800, Anson Huang wrote:
> Convert the MXS GPIO binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/gpio/gpio-mxs.txt | 88 -------------
> .../devicetree/bindings/gpio/gpio-mxs.yaml | 136 +++++++++++++++++++++
> 2 files changed, 136 insertions(+), 88 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-mxs.txt
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mxs.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clk: versatile: Fix kconfig dependency on COMMON_CLK_VERSATILE
From: Rob Herring @ 2020-05-28 21:29 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Anders Roxell, Stephen Boyd, Michael Turquette, linux-clk,
SoC Team, Linus Walleij, Linux ARM
In-Reply-To: <CAK8P3a27RkBkt5mnBeVJ-67MnJi29Dc+jYL2Q8JskaZ1W_XrKg@mail.gmail.com>
On Thu, May 28, 2020 at 5:57 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wed, May 27, 2020 at 8:13 PM Rob Herring <robh@kernel.org> wrote:
> > diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig
> > index a0ed412e8396..8c1b0e8e8d32 100644
> > --- a/drivers/clk/versatile/Kconfig
> > +++ b/drivers/clk/versatile/Kconfig
> > @@ -1,11 +1,8 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> >
> > -menuconfig COMMON_CLK_VERSATILE
> > - bool "Clock driver for ARM Reference designs" if COMPILE_TEST
> > - default y if ARCH_INTEGRATOR || ARCH_REALVIEW || \
> > - ARCH_VERSATILE || ARCH_VEXPRESS
> > -
> > -if COMMON_CLK_VERSATILE
> > +menu "Clock driver for ARM Reference designs"
> > + depends on ARCH_INTEGRATOR || ARCH_REALVIEW || \
> > + ARCH_VERSATILE || ARCH_VEXPRESS || COMPILE_TEST
> >
>
> I've applied this version now but added ARCH_ZYNQ as an additional
> dependency to work around one of the warnings we got earlier.
That's just spreading a copy-n-paste error. Why don't you apply the
Zynq patch I referenced if Michal never did?
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: display: ti,tfp410.txt: convert to yaml
From: Laurent Pinchart @ 2020-05-28 21:43 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: devicetree, jason, airlied, dri-devel, robh+dt, tomi.valkeinen,
kernel, shawnguo, linux-arm-kernel
In-Reply-To: <20200514143612.2094-4-ricardo.canuelo@collabora.com>
Hi Ricardo,
Thank you for the patch.
On Thu, May 14, 2020 at 04:36:11PM +0200, Ricardo Cañuelo wrote:
> Convert the DT binding documentation for the TI TFP410 DPI-to-DVI
> encoder to json-schema.
>
> The 'ti,deskew' is now an unsigned value from 0 to 7 instead of a signed
> value from -4 to 3. The rest of the binding is a direct translation from
> the old one.
I would have modified this in a separate patch.
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
> .../bindings/display/bridge/ti,tfp410.txt | 66 ----------
> .../bindings/display/bridge/ti,tfp410.yaml | 124 ++++++++++++++++++
> 2 files changed, 124 insertions(+), 66 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> deleted file mode 100644
> index 5ff4f64ef8e8..000000000000
> --- a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> +++ /dev/null
> @@ -1,66 +0,0 @@
> -TFP410 DPI to DVI encoder
> -=========================
> -
> -Required properties:
> -- compatible: "ti,tfp410"
> -
> -Optional properties:
> -- powerdown-gpios: power-down gpio
> -- reg: I2C address. If and only if present the device node should be placed
> - into the I2C controller node where the TFP410 I2C is connected to.
> -- ti,deskew: data de-skew in 350ps increments, from -4 to +3, as configured
> - through th DK[3:1] pins. This property shall be present only if the TFP410
> - is not connected through I2C.
> -
> -Required nodes:
> -
> -This device has two video ports. Their connections are modeled using the OF
> -graph bindings specified in [1]. Each port node shall have a single endpoint.
> -
> -- Port 0 is the DPI input port. Its endpoint subnode shall contain a
> - pclk-sample and bus-width property and a remote-endpoint property as specified
> - in [1].
> - - If pclk-sample is not defined, pclk-sample = 0 should be assumed for
> - backward compatibility.
> - - If bus-width is not defined then bus-width = 24 should be assumed for
> - backward compatibility.
> - bus-width = 24: 24 data lines are connected and single-edge mode
> - bus-width = 12: 12 data lines are connected and dual-edge mode
> -
> -- Port 1 is the DVI output port. Its endpoint subnode shall contain a
> - remote-endpoint property is specified in [1].
> -
> -[1] Documentation/devicetree/bindings/media/video-interfaces.txt
> -
> -
> -Example
> --------
> -
> -tfp410: encoder@0 {
> - compatible = "ti,tfp410";
> - powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
> - ti,deskew = <4>;
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> -
> - tfp410_in: endpoint@0 {
> - pclk-sample = <1>;
> - bus-width = <24>;
> - remote-endpoint = <&dpi_out>;
> - };
> - };
> -
> - port@1 {
> - reg = <1>;
> -
> - tfp410_out: endpoint@0 {
> - remote-endpoint = <&dvi_connector_in>;
> - };
> - };
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
> new file mode 100644
> index 000000000000..a9f4fd8ea621
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml
> @@ -0,0 +1,124 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/ti,tfp410.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TFP410 DPI to DVI encoder
> +
> +maintainers:
> + - Tomi Valkeinen <tomi.valkeinen@ti.com>
> + - Jyri Sarha <jsarha@ti.com>
> +
> +properties:
> + compatible:
> + const: ti,tfp410
> +
> + reg:
> + description: I2C address of the device.
> + maxItems: 1
> +
> + powerdown-gpios:
> + maxItems: 1
> +
> + ti,deskew:
> + description:
> + Data de-skew value in 350ps increments, from 0 to 7, as configured
> + through the DK[3:1] pins. The de-skew multiplier is computed as
> + (DK[3:1] - 4), so it ranges from -4 to 3. This property shall be
> + present only if the TFP410 is not connected through I2C.
I'd replace the last sentence with
if:
required:
- reg
then:
properties:
ti,deskew: false
else:
required:
- ti,deskew
(between the required: and additionalProperties: objects below)
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 7
> +
> + ports:
> + description:
> + A node containing input and output port nodes with endpoint
> + definitions as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> + type: object
> +
> + properties:
> + port@0:
> + description: DPI input port.
> + type: object
> +
> + properties:
> + reg:
> + const: 0
> +
> + endpoint:
> + type: object
> +
> + properties:
> + pclk-sample:
> + description:
> + Endpoint sampling edge. If not defined, pclk-sample =
> + 0 should be assumed for backwards compatibility.
Should the second sentence be dropped, as it's expressed with default: 0
?
> + enum:
> + - 0 # Falling edge
> + - 1 # Rising edge
> + default: 0
> +
> + bus-width:
> + description:
> + Endpoint bus width. If not defined, bus-width = 24
> + should be assumed for backwards compatibility.
Same here for the second sentence.
With these small issues fixed,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> + enum:
> + - 12 # 12 data lines connected and dual-edge mode
> + - 24 # 24 data lines connected and single-edge mode
> + default: 24
> +
> + port@1:
> + description: DVI output port.
> + type: object
> +
> + properties:
> + reg:
> + const: 1
> +
> + endpoint:
> + type: object
> +
> + required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + tfp410: encoder {
> + compatible = "ti,tfp410";
> + powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
> + ti,deskew = <3>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + tfp410_in: endpoint {
> + pclk-sample = <1>;
> + bus-width = <24>;
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + tfp410_out: endpoint {
> + remote-endpoint = <&dvi_connector_in>;
> + };
> + };
> + };
> + };
> +
> +...
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 4/4] drm/bridge: tfp410: Fix setup and hold time calculation
From: Laurent Pinchart @ 2020-05-28 21:46 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: devicetree, jason, airlied, dri-devel, robh+dt, tomi.valkeinen,
kernel, shawnguo, linux-arm-kernel
In-Reply-To: <20200514143612.2094-5-ricardo.canuelo@collabora.com>
Hi Ricardo,
Thank you for the patch.
On Thu, May 14, 2020 at 04:36:12PM +0200, Ricardo Cañuelo wrote:
> The tfp410 has a data de-skew feature that allows the user to compensate
> the skew between IDCK and the pixel data and control signals.
>
> In the driver, the setup and hold times are calculated from the de-skew
> value. This retrieves the deskew value from the DT using the proper
> datatype and range check as described by the binding (u32 from 0 to 7)
> and fixes the calculation of the setup and hold times.
How about mentioning that the fix results from a change in the DT
bindings ? Otherwise it sounds it was a bug in the driver.
I would also mention that the patch fixes the min() calculation, which
was clearly wrong. I think I would have split this in two patches.
With this addressed,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c
> index e3eb6364c0f7..21d99b4ea0c9 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -220,7 +220,7 @@ static int tfp410_parse_timings(struct tfp410 *dvi, bool i2c)
> struct device_node *ep;
> u32 pclk_sample = 0;
> u32 bus_width = 24;
> - s32 deskew = 0;
> + u32 deskew = 0;
>
> /* Start with defaults. */
> *timings = tfp410_default_timings;
> @@ -274,12 +274,12 @@ static int tfp410_parse_timings(struct tfp410 *dvi, bool i2c)
> }
>
> /* Get the setup and hold time from vendor-specific properties. */
> - of_property_read_u32(dvi->dev->of_node, "ti,deskew", (u32 *)&deskew);
> - if (deskew < -4 || deskew > 3)
> + of_property_read_u32(dvi->dev->of_node, "ti,deskew", &deskew);
> + if (deskew > 7)
> return -EINVAL;
>
> - timings->setup_time_ps = min(0, 1200 - 350 * deskew);
> - timings->hold_time_ps = min(0, 1300 + 350 * deskew);
> + timings->setup_time_ps = 1200 - 350 * ((s32)deskew - 4);
> + timings->hold_time_ps = max(0, 1300 + 350 * ((s32)deskew - 4));
>
> return 0;
> }
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: edt-ft5x06: change reg property
From: Rob Herring @ 2020-05-28 22:01 UTC (permalink / raw)
To: Heiko Stübner
Cc: devicetree, Dmitry Torokhov, linux-kernel, linux-rockchip,
linux-input, Johan Jonker, linux-arm-kernel
In-Reply-To: <4727344.YYj2SkWT1V@diego>
On Wed, May 20, 2020 at 08:41:59PM +0200, Heiko Stübner wrote:
> Hi Dmitry,
>
> Am Mittwoch, 20. Mai 2020, 19:13:24 CEST schrieb Dmitry Torokhov:
> > Hi Johan,
> >
> > On Wed, May 20, 2020 at 09:33:27AM +0200, Johan Jonker wrote:
> > > A test with the command below gives this error:
> > >
> > > arch/arm/boot/dts/rk3188-bqedison2qc.dt.yaml:
> > > touchscreen@3e: reg:0:0: 56 was expected
> > >
> > > The touchscreen chip on 'rk3188-bqedison2qc' and other BQ models
> > > was shipped with different addresses then the binding currently allows.
> > > Change the reg property that any address will pass.
> > >
> > > make ARCH=arm dtbs_check
> > > DT_SCHEMA_FILES=Documentation/devicetree/bindings/input/touchscreen/
> > > edt-ft5x06.yaml
> > >
> > > Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> > > ---
> > > Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > index 383d64a91..baa8e8f7e 100644
> > > --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > @@ -42,7 +42,7 @@ properties:
> > > - focaltech,ft6236
> > >
> > > reg:
> > > - const: 0x38
> > > + maxItems: 1
> >
> > Should we have a list of valid addresses instead of allowing any
> > address? Controllers usually have only a couple of addresses that they
> > support.
>
> from what I've read, the fdt touchscreen controllers are just a generic
> cpu with device-specific (or better panel-specific) firmware, which seems
> to include the address as well - so it looks to be variable.
>
> But of course that is only 2nd hand knowledge for me ;-)
>
>
> But also, the i2c address is something you cannot really mess up,
> either it is correct and your touchscreen works, or it isn't and and
> adding entries to this list every time a new address variant pops up
> feels clumsy.
Is that an Ack?
I'm fine either way. It's really only useful if there's a single
address because with a list it could still be wrong just as any other
data like an interrupt number could be wrong.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: edt-ft5x06: change reg property
From: Heiko Stübner @ 2020-05-28 22:02 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Dmitry Torokhov, linux-kernel, linux-rockchip,
linux-input, Johan Jonker, linux-arm-kernel
In-Reply-To: <20200528220136.GA748777@bogus>
Am Freitag, 29. Mai 2020, 00:01:36 CEST schrieb Rob Herring:
> On Wed, May 20, 2020 at 08:41:59PM +0200, Heiko Stübner wrote:
> > Hi Dmitry,
> >
> > Am Mittwoch, 20. Mai 2020, 19:13:24 CEST schrieb Dmitry Torokhov:
> > > Hi Johan,
> > >
> > > On Wed, May 20, 2020 at 09:33:27AM +0200, Johan Jonker wrote:
> > > > A test with the command below gives this error:
> > > >
> > > > arch/arm/boot/dts/rk3188-bqedison2qc.dt.yaml:
> > > > touchscreen@3e: reg:0:0: 56 was expected
> > > >
> > > > The touchscreen chip on 'rk3188-bqedison2qc' and other BQ models
> > > > was shipped with different addresses then the binding currently allows.
> > > > Change the reg property that any address will pass.
> > > >
> > > > make ARCH=arm dtbs_check
> > > > DT_SCHEMA_FILES=Documentation/devicetree/bindings/input/touchscreen/
> > > > edt-ft5x06.yaml
> > > >
> > > > Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> > > > ---
> > > > Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > > index 383d64a91..baa8e8f7e 100644
> > > > --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > > +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> > > > @@ -42,7 +42,7 @@ properties:
> > > > - focaltech,ft6236
> > > >
> > > > reg:
> > > > - const: 0x38
> > > > + maxItems: 1
> > >
> > > Should we have a list of valid addresses instead of allowing any
> > > address? Controllers usually have only a couple of addresses that they
> > > support.
> >
> > from what I've read, the fdt touchscreen controllers are just a generic
> > cpu with device-specific (or better panel-specific) firmware, which seems
> > to include the address as well - so it looks to be variable.
> >
> > But of course that is only 2nd hand knowledge for me ;-)
> >
> >
> > But also, the i2c address is something you cannot really mess up,
> > either it is correct and your touchscreen works, or it isn't and and
> > adding entries to this list every time a new address variant pops up
> > feels clumsy.
>
> Is that an Ack?
for the patch itself:
Acked-by: Heiko Stuebner <heiko@sntech.de>
> I'm fine either way. It's really only useful if there's a single
> address because with a list it could still be wrong just as any other
> data like an interrupt number could be wrong.
>
> Rob
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V4] dt-bindings: thermal: Convert i.MX to json-schema
From: Rob Herring @ 2020-05-28 22:05 UTC (permalink / raw)
To: Anson Huang
Cc: devicetree, amit.kucheria, linux-pm, festevam, s.hauer,
daniel.lezcano, linux-kernel, robh+dt, Linux-imx, kernel,
rui.zhang, shawnguo, linux-arm-kernel
In-Reply-To: <1589967737-1128-1-git-send-email-Anson.Huang@nxp.com>
On Wed, 20 May 2020 17:42:17 +0800, Anson Huang wrote:
> Convert the i.MX thermal binding to DT schema format using json-schema
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> Changes since V3:
> - improve "fsl,tempmon" description.
> ---
> .../devicetree/bindings/thermal/imx-thermal.txt | 61 ------------
> .../devicetree/bindings/thermal/imx-thermal.yaml | 102 +++++++++++++++++++++
> 2 files changed, 102 insertions(+), 61 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/thermal/imx-thermal.txt
> create mode 100644 Documentation/devicetree/bindings/thermal/imx-thermal.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 04/12] dt-bindings: irqchip: ti, sci-intr: Update bindings to drop the usage of gic as parent
From: Rob Herring @ 2020-05-28 22:14 UTC (permalink / raw)
To: Lokesh Vutla
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Marc Zyngier, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
In-Reply-To: <20200520124454.10532-5-lokeshvutla@ti.com>
On Wed, May 20, 2020 at 06:14:46PM +0530, Lokesh Vutla wrote:
> Drop the firmware related dt-bindings and use the hardware specified
> interrupt numbers within Interrupt Router. This ensures interrupt router
> DT node need not assume any interrupt parent type.
I didn't like this binding to begin with, but now you're breaking
compatibility.
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> .../interrupt-controller/ti,sci-intr.txt | 31 ++++++++++---------
> 1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
> index 1a8718f8855d..8b56b2de1c73 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
> @@ -44,15 +44,17 @@ Required Properties:
> 4: If intr supports level triggered interrupts.
> - interrupt-controller: Identifies the node as an interrupt controller
> - #interrupt-cells: Specifies the number of cells needed to encode an
> - interrupt source. The value should be 2.
> - First cell should contain the TISCI device ID of source
> - Second cell should contain the interrupt source offset
> - within the device.
> + interrupt source. The value should be 1.
> + First cell should contain interrupt router input number
> + as specified by hardware.
> - ti,sci: Phandle to TI-SCI compatible System controller node.
> -- ti,sci-dst-id: TISCI device ID of the destination IRQ controller.
> -- ti,sci-rm-range-girq: Array of TISCI subtype ids representing the host irqs
> - assigned to this interrupt router. Each subtype id
> - corresponds to a range of host irqs.
> +- ti,sci-dev-id: TISCI device id of interrupt controller.
> +- ti,interrupt-ranges: Set of triplets containing ranges that convert
> + the INTR output interrupt numbers to parent's
> + interrupt number. Each triplet has following entries:
> + - First entry specifies the base for intr output irq
> + - Second entry specifies the base for parent irqs
> + - Third entry specifies the limit
Humm, sounds like what interrupt-map does.
>
> For more details on TISCI IRQ resource management refer:
> http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html
> @@ -62,21 +64,20 @@ Example:
> The following example demonstrates both interrupt router node and the consumer
> node(main gpio) on the AM654 SoC:
>
> -main_intr: interrupt-controller0 {
> +main_gpio_intr: interrupt-controller0 {
> compatible = "ti,sci-intr";
> ti,intr-trigger-type = <1>;
> interrupt-controller;
> interrupt-parent = <&gic500>;
> - #interrupt-cells = <2>;
> + #interrupt-cells = <1>;
> ti,sci = <&dmsc>;
> - ti,sci-dst-id = <56>;
> - ti,sci-rm-range-girq = <0x1>;
> + ti,sci-dev-id = <131>;
> + ti,interrupt-ranges = <0 360 32>;
> };
>
> main_gpio0: gpio@600000 {
> ...
> - interrupt-parent = <&main_intr>;
> - interrupts = <57 256>, <57 257>, <57 258>,
> - <57 259>, <57 260>, <57 261>;
> + interrupt-parent = <&main_gpio_intr>;
> + interrupts = <192>, <193>, <194>, <195>, <196>, <197>;
> ...
> };
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: omap: Update PRM binding for genpd
From: Rob Herring @ 2020-05-28 22:20 UTC (permalink / raw)
To: Tony Lindgren
Cc: devicetree, linux-omap, linux-kernel, Andrew F . Davis,
Tero Kristo, Santosh Shilimkar, Suman Anna, linux-arm-kernel
In-Reply-To: <20200520211334.61814-2-tony@atomide.com>
On Wed, May 20, 2020 at 02:13:29PM -0700, Tony Lindgren wrote:
> The PRM (Power and Reset Module) has registers to enable and disable
> power domains, so let's update the binding for that.
multiple domains? Then why 0 cells?
>
> Cc: devicetree@vger.kernel.org
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> Documentation/devicetree/bindings/arm/omap/prm-inst.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> --- a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> @@ -18,6 +18,7 @@ Required properties:
> (base address and length)
>
> Optional properties:
> +- #power-domain-cells: Should be 0 if the PRM instance is a power domain.
...power domain provider.
> - #reset-cells: Should be 1 if the PRM instance in question supports resets.
>
> Example:
> @@ -25,5 +26,6 @@ Example:
> prm_dsp2: prm@1b00 {
> compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
> reg = <0x1b00 0x40>;
> + #power-domain-cells = <0>;
> #reset-cells = <1>;
> };
> --
> 2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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