* [PATCH 3/8] ARM: dts: am335x-sl50: add a node for the LCD controller
From: Enric Balletbo i Serra @ 2018-06-06 15:54 UTC (permalink / raw)
To: linux-kernel
Cc: kernel, devicetree, Benoît Cousson, Rob Herring,
Tony Lindgren, Mark Rutland, linux-omap
In-Reply-To: <20180606155413.23542-1-enric.balletbo@collabora.com>
Add the pins used by the LCD controller, the panel-info and display-timings
information for the MIDAS displays connected to the board. There are
two displays in the board, and these, are connected to the LCD controller
through a FPGA, so the timings and the resolution is what expects the FPGA,
not the MIDAS displays.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
arch/arm/boot/dts/am335x-sl50.dts | 69 ++++++++++++++++++++++++++++++-
1 file changed, 68 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-sl50.dts b/arch/arm/boot/dts/am335x-sl50.dts
index 58fe84f2ec8b..ea047b85b726 100644
--- a/arch/arm/boot/dts/am335x-sl50.dts
+++ b/arch/arm/boot/dts/am335x-sl50.dts
@@ -111,6 +111,45 @@
};
};
+ panel: lcd_panel {
+ compatible = "ti,tilcdc,panel";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+
+ panel-info {
+ ac-bias = <255>;
+ ac-bias-intrpt = <0>;
+ dma-burst-sz = <16>;
+ bpp = <16>;
+ fdd = <0x80>;
+ tft-alt-mode = <0>;
+ mono-8bit-mode = <0>;
+ sync-edge = <0>;
+ sync-ctrl = <1>;
+ raster-order = <0>;
+ fifo-th = <0>;
+ };
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 960x128 {
+ clock-frequency = <18000000>;
+ hactive = <960>;
+ vactive = <272>;
+
+ hback-porch = <40>;
+ hfront-porch = <16>;
+ hsync-len = <24>;
+ hsync-active = <0>;
+
+ vback-porch = <3>;
+ vfront-porch = <8>;
+ vsync-len = <4>;
+ vsync-active = <0>;
+ };
+ };
+ };
+
sound {
compatible = "ti,da830-evm-audio";
ti,model = "AM335x-SL50";
@@ -166,6 +205,31 @@
>;
};
+ lcd_pins: pinmux_lcd_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x8a0, PIN_OUTPUT | MUX_MODE0) /* lcd_data0.lcd_data0 */
+ AM33XX_IOPAD(0x8a4, PIN_OUTPUT | MUX_MODE0) /* lcd_data1.lcd_data1 */
+ AM33XX_IOPAD(0x8a8, PIN_OUTPUT | MUX_MODE0) /* lcd_data2.lcd_data2 */
+ AM33XX_IOPAD(0x8ac, PIN_OUTPUT | MUX_MODE0) /* lcd_data3.lcd_data3 */
+ AM33XX_IOPAD(0x8b0, PIN_OUTPUT | MUX_MODE0) /* lcd_data4.lcd_data4 */
+ AM33XX_IOPAD(0x8b4, PIN_OUTPUT | MUX_MODE0) /* lcd_data5.lcd_data5 */
+ AM33XX_IOPAD(0x8b8, PIN_OUTPUT | MUX_MODE0) /* lcd_data6.lcd_data6 */
+ AM33XX_IOPAD(0x8bc, PIN_OUTPUT | MUX_MODE0) /* lcd_data7.lcd_data7 */
+ AM33XX_IOPAD(0x8c0, PIN_OUTPUT | MUX_MODE0) /* lcd_data8.lcd_data8 */
+ AM33XX_IOPAD(0x8c4, PIN_OUTPUT | MUX_MODE0) /* lcd_data9.lcd_data9 */
+ AM33XX_IOPAD(0x8c8, PIN_OUTPUT | MUX_MODE0) /* lcd_data10.lcd_data10 */
+ AM33XX_IOPAD(0x8cc, PIN_OUTPUT | MUX_MODE0) /* lcd_data11.lcd_data11 */
+ AM33XX_IOPAD(0x8d0, PIN_OUTPUT | MUX_MODE0) /* lcd_data12.lcd_data12 */
+ AM33XX_IOPAD(0x8d4, PIN_OUTPUT | MUX_MODE0) /* lcd_data13.lcd_data13 */
+ AM33XX_IOPAD(0x8d8, PIN_OUTPUT | MUX_MODE0) /* lcd_data14.lcd_data14 */
+ AM33XX_IOPAD(0x8dc, PIN_OUTPUT | MUX_MODE0) /* lcd_data15.lcd_data15 */
+ AM33XX_IOPAD(0x8e0, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_vsync.lcd_vsync */
+ AM33XX_IOPAD(0x8e4, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_hsync.lcd_hsync */
+ AM33XX_IOPAD(0x8e8, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_pclk.lcd_pclk */
+ AM33XX_IOPAD(0x8ec, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* lcd_ac_bias_en.lcd_ac_bias_en */
+ >;
+ };
+
led_pins: pinmux_led_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x854, PIN_OUTPUT | MUX_MODE7) /* gpmc_a5.gpio1_21 */
@@ -323,7 +387,6 @@
lwb_pins: pinmux_lwb_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x9a4, PIN_OUTPUT | MUX_MODE7) /* SoundPA_en - mcasp0_fsr.gpio3_19 */
- AM33XX_IOPAD(0x828, PIN_OUTPUT | MUX_MODE7) /* nKbdOnC - gpmc_ad10.gpio0_26 */
AM33XX_IOPAD(0x830, PIN_INPUT_PULLUP | MUX_MODE7) /* nKbdInt - gpmc_ad12.gpio1_12 */
AM33XX_IOPAD(0x834, PIN_INPUT_PULLUP | MUX_MODE7) /* nKbdReset - gpmc_ad13.gpio1_13 */
AM33XX_IOPAD(0x844, PIN_INPUT_PULLUP | MUX_MODE7) /* USB1_enPower - gpmc_a1.gpio1_17 */
@@ -595,3 +658,7 @@
pinctrl-names = "default";
pinctrl-0 = <&ehrpwm1_pins>;
};
+
+&lcdc {
+ status = "okay";
+};
--
2.17.1
^ permalink raw reply related
* [PATCH 2/8] ARM: dts: am335x-sl50: use phy-phandle declarations
From: Enric Balletbo i Serra @ 2018-06-06 15:54 UTC (permalink / raw)
To: linux-kernel
Cc: kernel, devicetree, Benoît Cousson, Rob Herring,
Tony Lindgren, Mark Rutland, linux-omap
In-Reply-To: <20180606155413.23542-1-enric.balletbo@collabora.com>
phy-phandle is now a preferred method to reference a PHY device. The new
method also allows you to specify a reset gpio which is required for
this board.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
arch/arm/boot/dts/am335x-sl50.dts | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-sl50.dts b/arch/arm/boot/dts/am335x-sl50.dts
index 6d78bf828bbf..58fe84f2ec8b 100644
--- a/arch/arm/boot/dts/am335x-sl50.dts
+++ b/arch/arm/boot/dts/am335x-sl50.dts
@@ -253,6 +253,8 @@
/* MDIO */
AM33XX_IOPAD(0x948, PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0) /* mdio_data.mdio_data */
AM33XX_IOPAD(0x94c, PIN_OUTPUT_PULLUP | MUX_MODE0) /* mdio_clk.mdio_clk */
+ /* Ethernet */
+ AM33XX_IOPAD(0x838, PIN_INPUT_PULLUP | MUX_MODE7) /* Ethernet_nRST - gpmc_ad14.gpio1_14 */
>;
};
@@ -324,7 +326,6 @@
AM33XX_IOPAD(0x828, PIN_OUTPUT | MUX_MODE7) /* nKbdOnC - gpmc_ad10.gpio0_26 */
AM33XX_IOPAD(0x830, PIN_INPUT_PULLUP | MUX_MODE7) /* nKbdInt - gpmc_ad12.gpio1_12 */
AM33XX_IOPAD(0x834, PIN_INPUT_PULLUP | MUX_MODE7) /* nKbdReset - gpmc_ad13.gpio1_13 */
- AM33XX_IOPAD(0x838, PIN_INPUT_PULLUP | MUX_MODE7) /* nDispReset - gpmc_ad14.gpio1_14 */
AM33XX_IOPAD(0x844, PIN_INPUT_PULLUP | MUX_MODE7) /* USB1_enPower - gpmc_a1.gpio1_17 */
/* PDI Bus - Battery system */
AM33XX_IOPAD(0x840, PIN_INPUT_PULLUP | MUX_MODE7) /* nBattReset gpmc_a0.gpio1_16 */
@@ -553,13 +554,8 @@
};
&cpsw_emac0 {
- phy_id = <&davinci_mdio>, <0>;
- phy-mode = "mii";
-};
-
-&cpsw_emac1 {
- phy_id = <&davinci_mdio>, <1>;
phy-mode = "mii";
+ phy-handle = <ðphy0>;
};
&mac {
@@ -574,6 +570,12 @@
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
+ reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>;
+ reset-delay-us = <100>; /* PHY datasheet states 100us min */
+
+ ethphy0: ethernet-phy@0 {
+ reg = <0>;
+ };
};
&sham {
--
2.17.1
^ permalink raw reply related
* [PATCH 1/8] ARM: dts: am335x-sl50: update backlight nodes
From: Enric Balletbo i Serra @ 2018-06-06 15:54 UTC (permalink / raw)
To: linux-kernel
Cc: kernel, devicetree, Benoît Cousson, Rob Herring,
Tony Lindgren, Mark Rutland, linux-omap
This patch updates the backlight nodes to improve the support and describe
better how hardware is done. The changes done were:
* Use PWM_POLARITY_INVERTED instead of the hardcoded number.
* Add pinctrl configuration.
* Add the enable gpio definition.
* Add the power supply definition.
* Add more brightness levels.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
arch/arm/boot/dts/am335x-sl50.dts | 61 ++++++++++++++++++++++++++++---
1 file changed, 55 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-sl50.dts b/arch/arm/boot/dts/am335x-sl50.dts
index ddfa7192afd5..6d78bf828bbf 100644
--- a/arch/arm/boot/dts/am335x-sl50.dts
+++ b/arch/arm/boot/dts/am335x-sl50.dts
@@ -5,6 +5,7 @@
/dts-v1/;
#include "am33xx.dtsi"
+#include <dt-bindings/pwm/pwm.h>
/ {
model = "Toby Churchill SL50 Series";
@@ -57,16 +58,44 @@
backlight0: disp0 {
compatible = "pwm-backlight";
- pwms = <&ehrpwm1 0 500000 0>;
- brightness-levels = <0 10 20 30 40 50 60 70 80 90 99>;
- default-brightness-level = <6>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&backlight0_pins>;
+ pwms = <&ehrpwm1 0 500000 PWM_POLARITY_INVERTED>;
+ brightness-levels = < 0 1 2 3 4 5 6 7 8 9
+ 10 11 12 13 14 15 16 17 18 19
+ 20 21 22 23 24 25 26 27 28 29
+ 30 31 32 33 34 35 36 37 38 39
+ 40 41 42 43 44 45 46 47 48 49
+ 50 51 52 53 54 55 56 57 58 59
+ 60 61 62 63 64 65 66 67 68 69
+ 70 71 72 73 74 75 76 77 78 79
+ 80 81 82 83 84 85 86 87 88 89
+ 90 91 92 93 94 95 96 97 98 99
+ 100>;
+ default-brightness-level = <50>;
+ enable-gpios = <&gpio2 4 GPIO_ACTIVE_HIGH>;
+ power-supply = <&vdd_sys_reg>;
};
backlight1: disp1 {
compatible = "pwm-backlight";
- pwms = <&ehrpwm1 1 500000 0>;
- brightness-levels = <0 10 20 30 40 50 60 70 80 90 99>;
- default-brightness-level = <6>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&backlight1_pins>;
+ pwms = <&ehrpwm1 1 500000 PWM_POLARITY_INVERTED>;
+ brightness-levels = < 0 1 2 3 4 5 6 7 8 9
+ 10 11 12 13 14 15 16 17 18 19
+ 20 21 22 23 24 25 26 27 28 29
+ 30 31 32 33 34 35 36 37 38 39
+ 40 41 42 43 44 45 46 47 48 49
+ 50 51 52 53 54 55 56 57 58 59
+ 60 61 62 63 64 65 66 67 68 69
+ 70 71 72 73 74 75 76 77 78 79
+ 80 81 82 83 84 85 86 87 88 89
+ 90 91 92 93 94 95 96 97 98 99
+ 100>;
+ default-brightness-level = <50>;
+ enable-gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
+ power-supply = <&vdd_sys_reg>;
};
clocks {
@@ -105,6 +134,14 @@
reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
};
+ vdd_sys_reg: regulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_sys_reg";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
vmmcsd_fixed: fixedregulator0 {
compatible = "regulator-fixed";
regulator-name = "vmmcsd_fixed";
@@ -117,6 +154,18 @@
pinctrl-names = "default";
pinctrl-0 = <&lwb_pins>;
+ backlight0_pins: pinmux_backlight0_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x898, PIN_OUTPUT | MUX_MODE7) /* gpmc_wen.gpio2_4 */
+ >;
+ };
+
+ backlight1_pins: pinmux_backlight1_pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x828, PIN_OUTPUT | MUX_MODE7) /* gpmc_ad10.gpio0_26 */
+ >;
+ };
+
led_pins: pinmux_led_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x854, PIN_OUTPUT | MUX_MODE7) /* gpmc_a5.gpio1_21 */
--
2.17.1
^ permalink raw reply related
* [PATCH] Documentation: devicetree: tilcdc: fix spelling mistake "suppors" -> "supports"
From: Enric Balletbo i Serra @ 2018-06-06 15:39 UTC (permalink / raw)
To: linux-kernel
Cc: kernel, devicetree, dri-devel, Rob Herring, Tomi Valkeinen,
Mark Rutland, Jyri Sarha, David Airlie
Trivial fix to spelling mistake in tilcdc.txt devicetree documentation.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
index 6fddb4f4f71a..3055d5c2c04e 100644
--- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
@@ -36,7 +36,7 @@ Optional nodes:
- port/ports: to describe a connection to an external encoder. The
binding follows Documentation/devicetree/bindings/graph.txt and
- suppors a single port with a single endpoint.
+ supports a single port with a single endpoint.
- See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and
Documentation/devicetree/bindings/display/tilcdc/tfp410.txt for connecting
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] arm64: dts: rockchip: Switch to SPDX identifier.
From: Enric Balletbo i Serra @ 2018-06-06 15:35 UTC (permalink / raw)
To: klaus.goger
Cc: LKML, kernel, Simon Xue, Yakir Yang, Liang Chen, Robin Murphy,
Rob Herring, Icenowy Zheng, Shawn Lin, Catalin Marinas,
Vicente Bergas, David Wu, Corentin Labbe, Finley Xiao,
Heiko Stuebner, Jacob Chen, William Wu, Brian Norris,
Jaehoon Chung, linux-rockchip, Douglas
In-Reply-To: <DCD2814D-35CD-4856-9479-3A09922586DD@theobroma-systems.com>
On 06/06/18 17:31, klaus.goger@theobroma-systems.com wrote:
> Hi Enric,
>
>> On 06.06.2018, at 17:21, Enric Balletbo i Serra <enric.balletbo@collabora.com> wrote:
>>
>> Adopt the SPDX license identifier headers to ease license compliance
>> management.
>
> [snip]
>
> Heiko merged a similar patch 2 days ago
> http://lists.infradead.org/pipermail/linux-rockchip/2018-June/020939.html
>
Nice, then forget this patch. I had this in my list of patches to send and I did
not noticed that another patch was send.
Cheers,
Enric
> Cheers,
> Klaus
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: Switch to SPDX identifier.
From: klaus.goger @ 2018-06-06 15:31 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: LKML, kernel, Simon Xue, Yakir Yang, Liang Chen, Robin Murphy,
Rob Herring, Icenowy Zheng, Shawn Lin, Catalin Marinas,
Vicente Bergas, David Wu, Corentin Labbe, Finley Xiao,
Heiko Stuebner, Jacob Chen, William Wu, Brian Norris,
Jaehoon Chung, linux-rockchip, Douglas
In-Reply-To: <20180606152109.12359-1-enric.balletbo@collabora.com>
Hi Enric,
> On 06.06.2018, at 17:21, Enric Balletbo i Serra <enric.balletbo@collabora.com> wrote:
>
> Adopt the SPDX license identifier headers to ease license compliance
> management.
[snip]
Heiko merged a similar patch 2 days ago
http://lists.infradead.org/pipermail/linux-rockchip/2018-June/020939.html
Cheers,
Klaus
^ permalink raw reply
* [PATCH 2/2] ARM: dts: am335x-sl50: Relicense the SL50 dts under GPLv2/X11
From: Enric Balletbo i Serra @ 2018-06-06 15:25 UTC (permalink / raw)
To: linux-kernel
Cc: kernel, devicetree, Benoît Cousson, Rob Herring,
Tony Lindgren, Mark Rutland, linux-omap
In-Reply-To: <20180606152500.14034-1-enric.balletbo@collabora.com>
The current GPLv2 only licensing on this dts makes it very impractical
for other software components licensed under another license.
In order to make it easier for them to reuse our device trees, relicense
this dts under a GPLv2/X11 dual-license. Also switch to use the SPDX
identifier and remove the boiler plate license text.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
arch/arm/boot/dts/am335x-sl50.dts | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-sl50.dts b/arch/arm/boot/dts/am335x-sl50.dts
index 38d57b89f7d3..522fc7decfd7 100644
--- a/arch/arm/boot/dts/am335x-sl50.dts
+++ b/arch/arm/boot/dts/am335x-sl50.dts
@@ -1,9 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (C) 2015 Toby Churchill - http://www.toby-churchill.com/
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
*/
/dts-v1/;
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: igep: Relicense the IGEP boards under GPLv2/X11
From: Enric Balletbo i Serra @ 2018-06-06 15:24 UTC (permalink / raw)
To: linux-kernel
Cc: kernel, devicetree, Javier Martinez Canillas, Benoît Cousson,
Rob Herring, Tony Lindgren, Mark Rutland, linux-omap,
linux-arm-kernel, Enric Balletbo i Serra
The current GPLv2 only licensing on IGEP boards makes it very impractical
for other software components licensed under another license.
In order to make it easier for them to reuse our device trees, relicense
all boards under a GPLv2/X11 dual-license. Also switch to use the SPDX
identifiers and remove the boiler plate license text.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
arch/arm/boot/dts/am335x-igep0033.dtsi | 7 ++-----
arch/arm/boot/dts/omap3-igep.dtsi | 6 ++----
arch/arm/boot/dts/omap3-igep0020-common.dtsi | 5 +----
arch/arm/boot/dts/omap3-igep0020-rev-f.dts | 5 +----
arch/arm/boot/dts/omap3-igep0020.dts | 5 +----
arch/arm/boot/dts/omap3-igep0030-common.dtsi | 5 +----
arch/arm/boot/dts/omap3-igep0030-rev-g.dts | 5 +----
arch/arm/boot/dts/omap3-igep0030.dts | 5 +----
8 files changed, 10 insertions(+), 33 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi b/arch/arm/boot/dts/am335x-igep0033.dtsi
index a5769a8f5fc8..c79066df4e0c 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -1,11 +1,8 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
- * am335x-igep0033.dtsi - Device Tree file for IGEP COM AQUILA AM335x
+ * Device Tree file for IGEP COM AQUILA AM335x
*
* Copyright (C) 2013 ISEE 2007 SL - http://www.isee.biz
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
*/
/dts-v1/;
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi b/arch/arm/boot/dts/omap3-igep.dtsi
index f33cc80c9dbc..9c02942a58a7 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -1,13 +1,11 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Common device tree for IGEP boards based on AM/DM37x
*
* Copyright (C) 2012 Javier Martinez Canillas <javier@osg.samsung.com>
* Copyright (C) 2012 Enric Balletbo i Serra <eballetbo@gmail.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
*/
+
/dts-v1/;
#include "omap36xx.dtsi"
diff --git a/arch/arm/boot/dts/omap3-igep0020-common.dtsi b/arch/arm/boot/dts/omap3-igep0020-common.dtsi
index ecbec23af49f..9675ce2cf069 100644
--- a/arch/arm/boot/dts/omap3-igep0020-common.dtsi
+++ b/arch/arm/boot/dts/omap3-igep0020-common.dtsi
@@ -1,12 +1,9 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Common Device Tree Source for IGEPv2
*
* Copyright (C) 2014 Javier Martinez Canillas <javier@osg.samsung.com>
* Copyright (C) 2014 Enric Balletbo i Serra <eballetbo@gmail.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
*/
#include "omap3-igep.dtsi"
diff --git a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
index 321c2b7a4e9f..8b8959930d19 100644
--- a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
+++ b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
@@ -1,12 +1,9 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Device Tree Source for IGEPv2 Rev. F (TI OMAP AM/DM37x)
*
* Copyright (C) 2012 Javier Martinez Canillas <javier@osg.samsung.com>
* Copyright (C) 2012 Enric Balletbo i Serra <eballetbo@gmail.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
*/
#include "omap3-igep0020-common.dtsi"
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts
index 33d6b4ead092..770b69f13c9e 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -1,12 +1,9 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Device Tree Source for IGEPv2 Rev. C (TI OMAP AM/DM37x)
*
* Copyright (C) 2012 Javier Martinez Canillas <javier@osg.samsung.com>
* Copyright (C) 2012 Enric Balletbo i Serra <eballetbo@gmail.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
*/
#include "omap3-igep0020-common.dtsi"
diff --git a/arch/arm/boot/dts/omap3-igep0030-common.dtsi b/arch/arm/boot/dts/omap3-igep0030-common.dtsi
index 443f71707437..9cd3e427ae22 100644
--- a/arch/arm/boot/dts/omap3-igep0030-common.dtsi
+++ b/arch/arm/boot/dts/omap3-igep0030-common.dtsi
@@ -1,12 +1,9 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Common Device Tree Source for IGEP COM MODULE
*
* Copyright (C) 2014 Javier Martinez Canillas <javier@osg.samsung.com>
* Copyright (C) 2014 Enric Balletbo i Serra <eballetbo@gmail.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
*/
#include "omap3-igep.dtsi"
diff --git a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
index 76dc08868bfb..8b2d01e7996b 100644
--- a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
+++ b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
@@ -1,12 +1,9 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Device Tree Source for IGEP COM MODULE Rev. G (TI OMAP AM/DM37x)
*
* Copyright (C) 2014 Javier Martinez Canillas <javier@osg.samsung.com>
* Copyright (C) 2014 Enric Balletbo i Serra <eballetbo@gmail.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
*/
#include "omap3-igep0030-common.dtsi"
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts
index 55b0cc4f5ee5..22329ae502c5 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -1,12 +1,9 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Device Tree Source for IGEP COM MODULE Rev. E (TI OMAP AM/DM37x)
*
* Copyright (C) 2012 Javier Martinez Canillas <javier@osg.samsung.com>
* Copyright (C) 2012 Enric Balletbo i Serra <eballetbo@gmail.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
*/
#include "omap3-igep0030-common.dtsi"
--
2.17.1
^ permalink raw reply related
* [PATCH] arm64: dts: rockchip: Switch to SPDX identifier.
From: Enric Balletbo i Serra @ 2018-06-06 15:21 UTC (permalink / raw)
To: linux-kernel
Cc: kernel, Simon Xue, Yakir Yang, Liang Chen, Klaus Goger,
Robin Murphy, Rob Herring, Icenowy Zheng, Shawn Lin,
Catalin Marinas, Vicente Bergas, David Wu, Corentin Labbe,
Finley Xiao, Heiko Stuebner, Jacob Chen, William Wu, Brian Norris,
Jaehoon Chung, linux-rockchip, Doug
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 39 +------------------
.../arm64/boot/dts/rockchip/rk3328-rock64.dts | 39 +------------------
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 39 +------------------
.../boot/dts/rockchip/rk3368-evb-act8846.dts | 39 +------------------
arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi | 39 +------------------
.../boot/dts/rockchip/rk3368-geekbox.dts | 39 +------------------
.../dts/rockchip/rk3368-orion-r68-meta.dts | 39 +------------------
.../boot/dts/rockchip/rk3368-px5-evb.dts | 39 +------------------
arch/arm64/boot/dts/rockchip/rk3368-r88.dts | 39 +------------------
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 39 +------------------
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 39 +------------------
.../boot/dts/rockchip/rk3399-firefly.dts | 39 +------------------
.../boot/dts/rockchip/rk3399-gru-kevin.dts | 39 +------------------
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 39 +------------------
.../boot/dts/rockchip/rk3399-op1-opp.dtsi | 39 +------------------
arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 39 +------------------
.../boot/dts/rockchip/rk3399-puma-haikou.dts | 39 +------------------
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 39 +------------------
.../rockchip/rk3399-sapphire-excavator.dts | 39 +------------------
.../boot/dts/rockchip/rk3399-sapphire.dtsi | 39 +------------------
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 39 +------------------
21 files changed, 21 insertions(+), 798 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
index 3d551e3e6c23..8302d86d35c4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
- *
- * 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 library 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 library 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.
*/
/dts-v1/;
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index 28257724a56e..5272e887a434 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2017 PINE64
- *
- * 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 library 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 library 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.
*/
/dts-v1/;
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index be2bfbc6b483..cd060a913df7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
- *
- * 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 library 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 library 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.
*/
#include <dt-bindings/clock/rk3328-cru.h>
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-evb-act8846.dts b/arch/arm64/boot/dts/rockchip/rk3368-evb-act8846.dts
index 8a5275f0539b..160f2c7e9559 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-evb-act8846.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-evb-act8846.dts
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2015 Caesar Wang <wxt@rock-chips.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.
*/
/dts-v1/;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi b/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi
index a37220a9387c..4de089149c50 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2015 Caesar Wang <wxt@rock-chips.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.
*/
#include <dt-bindings/input/input.h>
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
index 5e4d3a7015f5..6b9b1ac1994c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2016 Andreas Färber
- *
- * 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.
*/
/dts-v1/;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts b/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
index d3f6c8e0d206..96147d93dd1d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2016 Matthias Brugger <mbrugger@suse.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.
*/
/dts-v1/;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts b/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
index 13a9e22f5d2d..fc1bf078a41f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
- *
- * 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.
*/
/dts-v1/;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
index b3510d56517a..7452bedf1a7e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2015 Heiko Stuebner <heiko@sntech.de>
- *
- * 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.
*/
/dts-v1/;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 03458ac44201..dd480c0936e6 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2015 Heiko Stuebner <heiko@sntech.de>
- *
- * 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 library 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 library 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.
*/
#include <dt-bindings/clock/rk3368-cru.h>
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
index 56533c344ef2..959ddc3c7df5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
- *
- * 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.
*/
/dts-v1/;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
index 2a352763c848..86ff1eb45795 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
- *
- * 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.
*/
/dts-v1/;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index 191a6bcb1704..d7d7d335091b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -1,45 +1,8 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Google Gru-Kevin Rev 6+ board device tree source
*
* Copyright 2016-2017 Google, Inc
- *
- * 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.
*/
/dts-v1/;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 18f546f2dfd1..d46a8166ac37 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -1,45 +1,8 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Google Gru (and derivatives) board device tree source
*
* Copyright 2016-2017 Google, Inc
- *
- * 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.
*/
#include <dt-bindings/input/input.h>
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
index d8a120f945c8..69cc9b05baa5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2016-2017 Fuzhou Rockchip Electronics Co., Ltd
- *
- * 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 library 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 library 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.
*/
/ {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
index 81617bcf2522..d6f1095abb04 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2016-2017 Fuzhou Rockchip Electronics Co., Ltd
- *
- * 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 library 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 library 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.
*/
/ {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts b/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts
index bb2b5a804408..6ebf2e1fda77 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2017 Theobroma Systems Design und Consulting GmbH
- *
- * 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.
*/
/dts-v1/;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
index 14a0f1998639..111839a18465 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2017 Theobroma Systems Design und Consulting GmbH
- *
- * 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.
*/
#include <dt-bindings/pwm/pwm.h>
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts b/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts
index 56952d1a3fb8..3de6b50c3d6c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
- *
- * 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.
*/
/dts-v1/;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
index 96c097b56c85..d58ffe26f610 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
- *
- * 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.
*/
#include "dt-bindings/pwm/pwm.h"
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 4550c0f82be9..8c17cb4a8d0a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1,43 +1,6 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
- *
- * 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 library 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 library 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.
*/
#include <dt-bindings/clock/rk3399-cru.h>
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v4 2/6] mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
From: Rob Herring @ 2018-06-06 15:16 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Michael Turquette, Stephen Boyd, Mark Rutland,
Lee Jones, Liam Girdwood, Mark Brown, linux-clk, devicetree,
linux-kernel@vger.kernel.org, mikko.mutanen, heikki.haikola
In-Reply-To: <20180606073449.GD20078@localhost.localdomain>
On Wed, Jun 6, 2018 at 2:34 AM, Matti Vaittinen
<mazziesaccount@gmail.com> wrote:
> On Tue, Jun 05, 2018 at 10:46:14AM -0500, Rob Herring wrote:
>> On Mon, Jun 4, 2018 at 6:32 AM, Matti Vaittinen
>> <mazziesaccount@gmail.com> wrote:
>> > On Fri, Jun 01, 2018 at 12:32:16PM -0500, Rob Herring wrote:
>> >> On Fri, Jun 1, 2018 at 1:25 AM, Matti Vaittinen
>> >> <mazziesaccount@gmail.com> wrote:
>> >> > On Thu, May 31, 2018 at 09:07:24AM -0500, Rob Herring wrote:
>> >> >> On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen
>> >> >> <mazziesaccount@gmail.com> wrote:
>> >> >> > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote:
>> >> >> >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote:
>> >> >> >> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote:
>> >> >> >> > > Document devicetree bindings for ROHM BD71837 PMIC MFD.
>> >> >> >> > > + - interrupts : The interrupt line the device is connected to.
>> >> >> >> > > + - interrupt-controller : Marks the device node as an interrupt controller.
>> >> >> >> >
>> >> >> >> > What sub blocks have interrupts?
>> >> >> >>
>> >> >> >> The PMIC can generate interrupts from events which cause it to reset.
>> >> >> >> Eg, irq from watchdog line change, power button pushes, reset request
>> >> >> >> via register interface etc. I don't know any generic handling for these
>> >> >> >> interrupts. In "normal" use-case this PMIC is powering the processor
>> >> >> >> where driver is running and I do not see reasonable handling because
>> >> >> >> power-reset is going to follow the irq.
>> >> >> >>
>> >> >> >
>> >> >> > Oh, but when reading this I understand that the interrupt-controller
>> >> >> > property should at least be optional.
>> >> >>
>> >> >> I don't think it should. The h/w either has an interrupt controller or
>> >> >> it doesn't.
>> >> >
>> >> > I hope this explains why I did this interrupt controller - please tell
>> >> > me if this is legitimate use-case and what you think of following:
>> >> >
>> >> > +Optional properties:
>> >> > + - interrupt-controller : Marks the device node as an interrupt controller.
>> >> > + BD71837MWV can report different power state change
>> >> > + events to other devices. Different events can be seen
>> >> > + as separate BD71837 domain interrupts.
>> >>
>> >> To what other devices?
>> >
>> > Would it be better if I wrote "other drivers" instead? I think I've seen
>> > examples where MFD driver is just providing the interrupts for other
>> > drivers - like power-button input driver. Currently I have no such "irq
>> > consumer" drivers written. Still I would like to expose these interrupts
>> > so that they are ready for using if any platform using PMIC needs them.
>>
>> No, worse. Interrupt binding describes interrupt connections between a
>> controller and devices (which could be sub-blocks in a device), not to
>> drivers.
>
> Ok.
>
>> I'm just curious as to what sub-blocks/devices there are. You don't
>> have to have a driver (yet) to define the devices.
>
> Right. I should have done this from the start. I just thought everyone
> is busy with other things and pushing people to read data sheets might
> be considered as lazines. "Go and read from data sheet what my driver
> does, I am too lazy to try to explain what I am doing" - type of thing
> you know... But as people asked me for more information about HW:
>
> Datasheet:
> https://www.rohm.com/datasheet/BD71837MWV/bd71837mwv-e
> (Would it be good idea to add this link to comments in MFD driver or to
> binding document(s)?)
Yes, it would.
> Page 8 contains roughly the same picture I drew
> below. Page 69 shows the interrupt registers. And for interested ones,
> HW state transitions are described on page 24.
>
> +--------------------------------------------------+
> | |
> VSYS +-----------------+ +-----------+ |
> | | | | |
> | +-------+ | | BUCKS 1-4 +-------->
> | | | | | | |
> I2C IF +-------> H | +--------------------+ DVS +-------->
> | | O | | | Support | |
> PWRON_B +-------> S | | | +-------->
> | | T | | | | |
> PMIC_STBY_REQ +-------> | | | +-------->
> | | I | | | | |
> PMIC_ON_REQ +-------> / | | +-----------+ |
> | | F | | |
> WDOG_B +-------> | | +-----------+ |
> | | | | | +-------->
> | | | +--------------------+ BUCKS 5,8 | |
> | | | | | +-------->
> | | | | +-----------+ |
> | | | | |
> | | | | +----------+ |
> IRQ_OUT <-------+ | | | | |
> | | | +---------------------+ LDO1 +-------->
> C32K_OUT <-------+ | | | | |
> | | | | +----------+ |
> | | | | |
> | | | | +----------+ |
> | | | | | | |
> | | | +---------------------+ LDO2 +-------->
> | | | | | | |
> | | | | +----------+ |
> | | | | |
> | | | | +----------+ |
> | | | | | | |
> | | | +---------------------+ LDO7 +-------->
> | +-------+ | | | |
> | | +----------+ |
> | | |
> | | +----------+ +-------------------------->
> | | | | | |
> | +-+ BUCK6 +-+ +----------+ |
> | | | | | | | |
> | | +----------+ +------> LDO5 +-------->
> | | | | | |
> | | | +----------+ |
> | | | |
> | +-------+ | | +----------+ |
> | | | | o | | |
> XIN +---------+ 32K | | \-----> LDO3 +-------->
> | |Crystal| +--------------o | | |
> | |Driver | | +---------+ +----------+ |
> XOUT +---------+ | | | | |
> | | | +--+ BUCK7 +-+-------------------------->
> | +-------+ | | | | |
> | | +---------+ | +-----------+ |
> | | | | | |
> | | +------> LDO6 +------->
> | | | | | |
> | | | +-----------+ |
> | | | |
> | | | +-----------+ |
> | | o | | |
> | | \-----> LDO4 +------->
> | +--------------o | | |
> | +-----------+ |
> | |
> +--------------------------------------------------+
>
> On the left we see input lines to PMIC. PWRON_B intended to be connected
> to power button. PMIC_STBY_REQ and PMIC_ON_REQ lines for controlling HW
> state machine PMIC has. And WDOG_B from watch dog.
>
> PMIC has control register for controlling what happens to BUCK/LDO
> outputs when input line states change. PMIC reports change in input
> lines via the IRQ_OUT line and IRQ status register.
So it looks like this is just regulators with a few other signals to handle.
> So HW mapping for interrup(s) from PMIC would be:
>
> (HW) event => BD71837 domain IRQ
>
> PMIC_STBY_REQ line level change => 0
> PMIC_ON_REQ line level change => 1
I'm not really clear how these would have s/w handling. They look like
handshake signals for the processor to enter and exit standby/suspend.
H/w designers don't always know what to do with things and may have
just said lets have an interrupt for every input signal. I'd think you
would just want DT properties to configure what action to take (and
perhaps polarity?).
> PMIC_WDOG_B line level change => 2
Ah, this is an input signal, not a watchdog block within the PMIC. I
think this should just be handled by the core driver. If you need to
configure what this does, then we can add a property to handle that.
> PMIC_PWRON_B line level change => 3
> PMIC_PWRON_B line/long push detected => 4
> PMIC_PWRON_B line/short push detected => 5
So you need a power button driver (or maybe not even a separate
driver) for this, but I don't think that warrants a child node. I
think some PMIC drivers just generate a power key press (which just
gets punted to userspace), but some will do an actual power down. Or
maybe a combination of those based on short/long press.
I think there's already some DT properties defined to control the
behavior as well.
> SWRESET register on PMIC written => 6
Probably this can be handled within the core driver. Seems like you'd
only use this if you have separate entities that write and read this.
If you don't know, then just ignore it for now.
>> > "The BD71837 driver only provides the infrastructure for the IRQs. The
>> > users can write his own driver to convert the IRQ into the event they
>> > wish. The IRQ can be used with the standard
>> > request_irq/enable_irq/disable_irq API inside the kernel." (I found this
>> > text from NXP forums and ruthlessly copied and modified it over here)
>>
>> That's all OS details that have nothing to do with the binding. The
>> binding describes the h/w.
>
> Right. I'll drop it.
>
>>
>> > If this is not feasible, then I will remove the irq handling from MFD
>> > (or leave code there but remove the binding information?) as I don't
>> > know what the irq handles should do in generic case.
>>
>> I don't understand what you mean by generic. An IRQ has to be wired to
>> something. The only generic IRQs are GPIOs.
>
> By generic case I mean for example when PMIC_WDOG_B line changes. In
> example use-case I have seen, this would be cutting the power from
> processor. But this is not necessarily the case. This can be configured
> from PMIC register so that action can be warm or cold reset, or no
> action. Finally, I'd rather not expect that the BUCKs are supplying
> power to processor which is controlling the PMIC. Thus I do not know how
> to do generic _handler_ for these interrupts.
>
> So from PMIC HW point of view I know that the interrupt is tied to
> PMIC_WDOG_B line change. And this can be described in binding document.
> (I tried doing this to v5 patch). Still from system/SW point of view I
> don't know what action should be taken (or by which driver) when such
> change happens. Hence I liked the idea of hiding the irq register
> details in MFD driver by declaring it as interrupt controller - and
> leaving the interrupts to be used by what ever drivers need the change
> information is system the PMIC is used.
This can still be done but doesn't have to be in DT.
>> >> > + - #interrupt-cells : The number of cells to describe an IRQ should be 1.
>> >> > + The first cell is the IRQ number.
>> >> > + masks from ../interrupt-controller/interrupts.txt.
>> >
>> > Sorry this "masks from ../interrupt-controller/interrupts.txt." was
>> > accidentally pasted here. I should have deleted it.
>> >
>> >> I'm still not clear. Generally in a PMIC, you'd define an interrupt
>> >> controller when there's a common set of registers to manage sub-block
>> >> interrupts (typical mask/unmask, ack regs) and the subblocks
>> >> themselves have control of masking/unmasking interrupts. If there's
>> >> not a need to have these 2 levels of interrupt handling, then you
>> >> don't really need to define an interrupt controller.
>> >
>> > And to clarify - the PMIC can generate irq via one irq line. This is
>> > typical ACTIVE_LOW irq with 8 bit "write 1 to clear" status register and
>> > 8 bit mask register. The role of interrupt-controller code here is just
>> > to allow these 8 irq reasons to be seen as individual BD71837 domain
>> > interrupts. I just don't have the driver(s) for handling these
>> > interrupts.
>>
>> If what I'm asking for above is still not clear, what are the 8 bits
>> defined as or what are those 8 lines connected to?
>
> I am sorry - there were only 7 bits. One bit was unused. I hope my
> explanation abowe did clarify this.
>
>> > Or should I just
>> > somehow state that irq X in BD71837 is a "power button short push"
>> > event and power button driver should be the consumer for it?
>>
>> Yes, at least, but who is the consumer is an OS detail that is not
>> relevant to the binding. Ideally, you would describe the node with the
>> interrupts property for "irq X".
>
> I think I need to try changing my mind set. I tend to think the DT nodes
> are for drivers so that drivers can get the information they need. An as
> I don't know what kind of driver would be handling the irq, I don't know
> what kind of DT node would be good for it. Hence I would rather leave
> constructing the node who consumes the IRQ to someone who knows what
> they want to do with this IRQ information.
>
>>
>> > Rest of the interrupts are not so obvious. I have no idea how I should
>> > handle rest of the interrupts. Those are interrupts which cause the PMIC
>> > to reset and cut the powers from most of the regulators too. I can
>> > easily think setup where one processor is controlling PMIC which powers
>> > for the other processor. And getting IRQ if for example watchdog reset
>> > the other processor would probably be very usefull. But doing any
>> > 'de-facto' handler for this is hard. Only generally usefull thing would
>> > be notifying the user-space but I don't think I should invent any new
>> > kernelspace - userspace interfaces for this. I believe that when such
>> > are needed those should be implemented by ones knowing the platform.
>>
>> Don't think about the OS or driver details. Think about sub-blocks of
>> the hardware and the connections between them (like irqs) and to board
>> that need to be described in DT.
>>
>> If you can't describe that, then you just probably shouldn't have
>> sub-nodes in DT (ever).
>
> This is why I did not add any "irq consumer" nodes in example DT. But I
> believe someone can think of a board/setup where such are needed. Thus I
> liked the idea of providing the interrupt-controller.
>
>> >
>> > So please bear with me but do you mean I should
>> > a) document what conditions generate which IRQ
>> > or
>> > b) should I tell what kind of driver is needed for handling the IRQs
>> > or
>> > c) should I first write code using IRQs before addinf MFD binding?
>>
>> A.
>
>
> So what do you think of this:
>
> +Optional properties:
> + - interrupt-controller : Marks the device node as an interrupt controller.
> + BD71837MWV can report input line state change and SW
> + reset events via interrupts. Different events can be seen
> + as separate BD71837 domain interrupts.
> + - #interrupt-cells : The number of cells to describe an IRQ should be 1.
> + The value in cell is the IRQ number.
> + Meaningfull numbers are:
> + 0 => PMIC_STBY_REQ level change
> + 1 => PMIC_ON_REQ level change
> + 2 => WDOG_B level change
> + 3 => Power Button level change
> + 4 => Power Button Long Push
> + 5 => Power Button Short Push
> + 6 => SWRESET register is written 1
>
> Would this be getting closer to what is needed from binding document?
I don't think any of this needs to live in DT. All you really need a
separate driver (and hence irq) for is really just the power button.
You can just define the interrupts within the kernel.
Rob
^ permalink raw reply
* Re: [PATCH v2 5/5] memory: tegra: Introduce Tegra20 EMC driver
From: Dmitry Osipenko @ 2018-06-06 13:42 UTC (permalink / raw)
To: Thierry Reding
Cc: Peter De Schrijver, Jonathan Hunter, Prashant Gaikwad,
Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
linux-tegra, linux-clk, devicetree, linux-kernel
In-Reply-To: <20180606110258.GL11810@ulmo>
On 06.06.2018 14:02, Thierry Reding wrote:
> On Mon, Jun 04, 2018 at 01:36:54AM +0300, Dmitry Osipenko wrote:
>> Introduce driver for the External Memory Controller (EMC) found on Tegra20
>> chips, which controls the external DRAM on the board. The purpose of this
>> driver is to program memory timing for external memory on the EMC clock
>> rate change.
>>
>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>> ---
>> drivers/memory/tegra/Kconfig | 10 +
>> drivers/memory/tegra/Makefile | 1 +
>> drivers/memory/tegra/tegra20-emc.c | 586 +++++++++++++++++++++++++++++
>> 3 files changed, 597 insertions(+)
>> create mode 100644 drivers/memory/tegra/tegra20-emc.c
>>
>> diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
>> index 6d74e499e18d..34e0b70f5c5f 100644
>> --- a/drivers/memory/tegra/Kconfig
>> +++ b/drivers/memory/tegra/Kconfig
>> @@ -6,6 +6,16 @@ config TEGRA_MC
>> This driver supports the Memory Controller (MC) hardware found on
>> NVIDIA Tegra SoCs.
>>
>> +config TEGRA20_EMC
>> + bool "NVIDIA Tegra20 External Memory Controller driver"
>> + default y
>> + depends on ARCH_TEGRA_2x_SOC
>> + help
>> + This driver is for the External Memory Controller (EMC) found on
>> + Tegra20 chips. The EMC controls the external DRAM on the board.
>> + This driver is required to change memory timings / clock rate for
>> + external memory.
>> +
>> config TEGRA124_EMC
>> bool "NVIDIA Tegra124 External Memory Controller driver"
>> default y
>> diff --git a/drivers/memory/tegra/Makefile b/drivers/memory/tegra/Makefile
>> index 94ab16ba075b..3971a6b7c487 100644
>> --- a/drivers/memory/tegra/Makefile
>> +++ b/drivers/memory/tegra/Makefile
>> @@ -10,5 +10,6 @@ tegra-mc-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210.o
>>
>> obj-$(CONFIG_TEGRA_MC) += tegra-mc.o
>>
>> +obj-$(CONFIG_TEGRA20_EMC) += tegra20-emc.o
>> obj-$(CONFIG_TEGRA124_EMC) += tegra124-emc.o
>> obj-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186.o
>> diff --git a/drivers/memory/tegra/tegra20-emc.c b/drivers/memory/tegra/tegra20-emc.c
>> new file mode 100644
>> index 000000000000..26a18b5e7941
>> --- /dev/null
>> +++ b/drivers/memory/tegra/tegra20-emc.c
>> @@ -0,0 +1,586 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Tegra20 External Memory Controller driver
>> + *
>> + * Author: Dmitry Osipenko <digetx@gmail.com>
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/completion.h>
>> +#include <linux/err.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/iopoll.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/sort.h>
>> +#include <linux/types.h>
>> +
>> +#include <soc/tegra/fuse.h>
>> +
>> +#define EMC_INTSTATUS 0x000
>> +#define EMC_INTMASK 0x004
>> +#define EMC_TIMING_CONTROL 0x028
>> +#define EMC_RC 0x02c
>> +#define EMC_RFC 0x030
>> +#define EMC_RAS 0x034
>> +#define EMC_RP 0x038
>> +#define EMC_R2W 0x03c
>> +#define EMC_W2R 0x040
>> +#define EMC_R2P 0x044
>> +#define EMC_W2P 0x048
>> +#define EMC_RD_RCD 0x04c
>> +#define EMC_WR_RCD 0x050
>> +#define EMC_RRD 0x054
>> +#define EMC_REXT 0x058
>> +#define EMC_WDV 0x05c
>> +#define EMC_QUSE 0x060
>> +#define EMC_QRST 0x064
>> +#define EMC_QSAFE 0x068
>> +#define EMC_RDV 0x06c
>> +#define EMC_REFRESH 0x070
>> +#define EMC_BURST_REFRESH_NUM 0x074
>> +#define EMC_PDEX2WR 0x078
>> +#define EMC_PDEX2RD 0x07c
>> +#define EMC_PCHG2PDEN 0x080
>> +#define EMC_ACT2PDEN 0x084
>> +#define EMC_AR2PDEN 0x088
>> +#define EMC_RW2PDEN 0x08c
>> +#define EMC_TXSR 0x090
>> +#define EMC_TCKE 0x094
>> +#define EMC_TFAW 0x098
>> +#define EMC_TRPAB 0x09c
>> +#define EMC_TCLKSTABLE 0x0a0
>> +#define EMC_TCLKSTOP 0x0a4
>> +#define EMC_TREFBW 0x0a8
>> +#define EMC_QUSE_EXTRA 0x0ac
>> +#define EMC_ODT_WRITE 0x0b0
>> +#define EMC_ODT_READ 0x0b4
>> +#define EMC_FBIO_CFG5 0x104
>> +#define EMC_FBIO_CFG6 0x114
>> +#define EMC_AUTO_CAL_INTERVAL 0x2a8
>> +#define EMC_CFG_2 0x2b8
>> +#define EMC_CFG_DIG_DLL 0x2bc
>> +#define EMC_DLL_XFORM_DQS 0x2c0
>> +#define EMC_DLL_XFORM_QUSE 0x2c4
>> +#define EMC_ZCAL_REF_CNT 0x2e0
>> +#define EMC_ZCAL_WAIT_CNT 0x2e4
>> +#define EMC_CFG_CLKTRIM_0 0x2d0
>> +#define EMC_CFG_CLKTRIM_1 0x2d4
>> +#define EMC_CFG_CLKTRIM_2 0x2d8
>> +
>> +#define EMC_CLKCHANGE_REQ_ENABLE BIT(0)
>> +#define EMC_CLKCHANGE_PD_ENABLE BIT(1)
>> +#define EMC_CLKCHANGE_SR_ENABLE BIT(2)
>> +
>> +#define EMC_TIMING_UPDATE BIT(0)
>> +
>> +#define EMC_CLKCHANGE_COMPLETE_INT BIT(4)
>> +
>> +static const unsigned long emc_timing_registers[] = {
>> + EMC_RC,
>> + EMC_RFC,
>> + EMC_RAS,
>> + EMC_RP,
>> + EMC_R2W,
>> + EMC_W2R,
>> + EMC_R2P,
>> + EMC_W2P,
>> + EMC_RD_RCD,
>> + EMC_WR_RCD,
>> + EMC_RRD,
>> + EMC_REXT,
>> + EMC_WDV,
>> + EMC_QUSE,
>> + EMC_QRST,
>> + EMC_QSAFE,
>> + EMC_RDV,
>> + EMC_REFRESH,
>> + EMC_BURST_REFRESH_NUM,
>> + EMC_PDEX2WR,
>> + EMC_PDEX2RD,
>> + EMC_PCHG2PDEN,
>> + EMC_ACT2PDEN,
>> + EMC_AR2PDEN,
>> + EMC_RW2PDEN,
>> + EMC_TXSR,
>> + EMC_TCKE,
>> + EMC_TFAW,
>> + EMC_TRPAB,
>> + EMC_TCLKSTABLE,
>> + EMC_TCLKSTOP,
>> + EMC_TREFBW,
>> + EMC_QUSE_EXTRA,
>> + EMC_FBIO_CFG6,
>> + EMC_ODT_WRITE,
>> + EMC_ODT_READ,
>> + EMC_FBIO_CFG5,
>> + EMC_CFG_DIG_DLL,
>> + EMC_DLL_XFORM_DQS,
>> + EMC_DLL_XFORM_QUSE,
>> + EMC_ZCAL_REF_CNT,
>> + EMC_ZCAL_WAIT_CNT,
>> + EMC_AUTO_CAL_INTERVAL,
>> + EMC_CFG_CLKTRIM_0,
>> + EMC_CFG_CLKTRIM_1,
>> + EMC_CFG_CLKTRIM_2,
>> +};
>> +
>> +struct emc_timing {
>> + unsigned long rate;
>> + u32 emc_registers_data[ARRAY_SIZE(emc_timing_registers)];
>> +};
>
> Nit: this seems like a very long variable name for something that is
> really just "values" or "data" written into a set of registers.
>
Ok.
>> +struct tegra_emc {
>> + struct device *dev;
>> + struct notifier_block clk_nb;
>> + struct clk *backup_clk;
>> + struct clk *emc_mux;
>> + struct clk *pll_m;
>> + struct clk *clk;
>> + void __iomem *regs;
>> +
>> + struct completion clk_handshake_complete;
>> + int irq;
>> +
>> + struct emc_timing *timings;
>> + unsigned int num_timings;
>> +};
>> +
>> +static irqreturn_t tegra_emc_isr(int irq, void *data)
>> +{
>> + struct tegra_emc *emc = data;
>> + u32 intmask = EMC_CLKCHANGE_COMPLETE_INT;
>> + u32 status;
>> +
>> + status = readl_relaxed(emc->regs + EMC_INTSTATUS) & intmask;
>> + if (!status)
>> + return IRQ_NONE;
>> +
>> + /* clear interrupts */
>> + writel_relaxed(status, emc->regs + EMC_INTSTATUS);
>
> Do we really want to just clear the handshake complete interrupt or do
> we want to clear all of them? Perhaps we should also warn if there are
> other interrupts that we're not handling? Currently we'd only get some
> warning if another interrupt triggered without the handshake complete
> one triggering at the same time, but couldn't there be others asserted
> along with the handshake complete interrupt? In which case we'd just
> be ignoring them. Or perhaps not clearing it would get the ISR run
> immediately again and produce the "nobody cared" warning?
>
Yes, we really want to just clear the handshake-complete interrupt. No, we
shouldn't warn about other interrupts because IRQ subsys does it for us. Other
interrupts shouldn't be asserted because we disabled them with the interrupts
masking in emc_setup_hw(). Other interrupts can only be asserted in a case of a
bug, there will be a "nobody cared" warning and interrupt will be disabled, this
is exactly what we want in that case.
>> +
>> + /* notify about EMC-CAR handshake completion */
>> + complete(&emc->clk_handshake_complete);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static struct emc_timing *tegra_emc_find_timing(struct tegra_emc *emc,
>> + unsigned long rate)
>> +{
>> + struct emc_timing *timing = NULL;
>> + unsigned int i;
>> +
>> + for (i = 0; i < emc->num_timings; i++) {
>> + if (emc->timings[i].rate >= rate) {
>> + timing = &emc->timings[i];
>> + break;
>> + }
>> + }
>> +
>> + if (!timing) {
>> + dev_err(emc->dev, "no timing for rate %lu\n", rate);
>> + return NULL;
>> + }
>> +
>> + return timing;
>> +}
>> +
>> +static int emc_prepare_timing_change(struct tegra_emc *emc, unsigned long rate)
>> +{
>> + struct emc_timing *timing = tegra_emc_find_timing(emc, rate);
>> + unsigned int i;
>> +
>> + if (!timing)
>> + return -ENOENT;
>> +
>> + dev_dbg(emc->dev, "%s: timing rate %lu emc rate %lu\n",
>> + __func__, timing->rate, rate);
>> +
>> + /* program shadow registers */
>> + for (i = 0; i < ARRAY_SIZE(timing->emc_registers_data); i++)
>> + writel_relaxed(timing->emc_registers_data[i],
>> + emc->regs + emc_timing_registers[i]);
>> +
>> + /* wait until programming has settled */
>> + readl_relaxed(emc->regs + emc_timing_registers[0]);
>> +
>> + if (emc->irq < 0)
>> + writel_relaxed(EMC_CLKCHANGE_COMPLETE_INT,
>> + emc->regs + EMC_INTMASK);
>> + else
>> + reinit_completion(&emc->clk_handshake_complete);
>> +
>> + return 0;
>> +}
>> +
>> +static int emc_complete_timing_change(struct tegra_emc *emc, bool flush)
>> +{
>> + long timeout;
>> + u32 value;
>> + int err;
>> +
>> + dev_dbg(emc->dev, "%s: flush %d\n", __func__, flush);
>> +
>> + if (flush) {
>> + /* manually initiate memory timing update */
>> + writel_relaxed(EMC_TIMING_UPDATE,
>> + emc->regs + EMC_TIMING_CONTROL);
>> + return 0;
>> + }
>> +
>> + if (emc->irq < 0) {
>> + /* poll interrupt status if IRQ isn't available */
>> + err = readl_relaxed_poll_timeout(emc->regs + EMC_INTSTATUS,
>> + value, value & EMC_CLKCHANGE_COMPLETE_INT,
>> + 1, 100);
>> + if (err) {
>> + dev_err(emc->dev, "EMC-CAR handshake failed\n");
>> + return -EIO;
>> + }
>> +
>> + return 0;
>> + }
>> +
>> + timeout = wait_for_completion_timeout(&emc->clk_handshake_complete,
>> + usecs_to_jiffies(100));
>> + if (timeout == 0) {
>> + dev_err(emc->dev, "EMC handshake failed\n");
>> + return -EIO;
>> + } else if (timeout < 0) {
>> + dev_err(emc->dev, "failed to wait for EMC-CAR handshake: %ld\n",
>> + timeout);
>> + return timeout;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int load_one_timing_from_dt(struct tegra_emc *emc,
>> + struct emc_timing *timing,
>> + struct device_node *node)
>> +{
>> + u32 rate;
>> + int err;
>> +
>> + if (!of_device_is_compatible(node, "nvidia,tegra20-emc-table")) {
>> + dev_err(emc->dev, "incompatible DT node \"%s\"\n",
>> + node->name);
>> + return -EINVAL;
>> + }
>> +
>> + err = of_property_read_u32(node, "clock-frequency", &rate);
>> + if (err) {
>> + dev_err(emc->dev, "timing %s: failed to read rate: %d\n",
>> + node->name, err);
>> + return err;
>> + }
>> +
>> + err = of_property_read_u32_array(node, "nvidia,emc-registers",
>> + timing->emc_registers_data,
>> + ARRAY_SIZE(emc_timing_registers));
>> + if (err) {
>> + dev_err(emc->dev,
>> + "timing %s: failed to read emc timing data: %d\n",
>> + node->name, err);
>> + return err;
>> + }
>> +
>> + /*
>> + * The EMC clock rate is twice the bus rate, and the bus rate is
>> + * measured in kHz.
>> + */
>> + timing->rate = rate * 2 * 1000;
>> +
>> + dev_dbg(emc->dev, "%s: emc rate %ld\n", __func__, timing->rate);
>
> Nit: %lu for timing->rate?
>
Yes.
>> +
>> + return 0;
>> +}
>> +
>> +static int cmp_timings(const void *_a, const void *_b)
>> +{
>> + const struct emc_timing *a = _a;
>> + const struct emc_timing *b = _b;
>> +
>> + if (a->rate < b->rate)
>> + return -1;
>> + else if (a->rate == b->rate)
>> + return 0;
>> + else
>> + return 1;
>
> Nit, I tend to
>
Tend to..?
>> +}
>> +
>> +static int tegra_emc_load_timings_from_dt(struct tegra_emc *emc,
>> + struct device_node *node)
>> +{
>> + struct device_node *child;
>> + struct emc_timing *timing;
>> + int child_count;
>> + int err;
>> +
>> + child_count = of_get_child_count(node);
>
> It's unfortunate that of_get_child_count() doesn't return unsigned int,
> there's no reason why this would have to be signed.
>
Patches are welcome ;)
>> + if (!child_count) {
>> + dev_err(emc->dev, "no memory timings in DT node\n");
>> + return -ENOENT;
>> + }
>> +
>> + emc->timings = devm_kcalloc(emc->dev, child_count, sizeof(*timing),
>> + GFP_KERNEL);
>> + if (!emc->timings)
>> + return -ENOMEM;
>> +
>> + emc->num_timings = child_count;
>> + timing = emc->timings;
>> +
>> + for_each_child_of_node(node, child) {
>> + err = load_one_timing_from_dt(emc, timing++, child);
>> + if (err) {
>> + of_node_put(child);
>> + return err;
>> + }
>> + }
>> +
>> + sort(emc->timings, emc->num_timings, sizeof(*timing), cmp_timings,
>> + NULL);
>> +
>> + return 0;
>> +}
>> +
>> +static struct device_node *
>> +tegra_emc_find_node_by_ram_code(struct tegra_emc *emc, u32 ram_code)
>> +{
>> + struct device_node *np;
>> + int err;
>> +
>> + for_each_child_of_node(emc->dev->of_node, np) {
>> + u32 value;
>> +
>> + err = of_property_read_u32(np, "nvidia,ram-code", &value);
>> + if (err || value != ram_code)
>> + continue;
>> +
>> + return np;
>> + }
>> +
>> + dev_info(emc->dev, "no memory timings for RAM code %u found in DT\n",
>> + ram_code);
>
> This seems like it should be dev_warn() or perhaps even dev_err() given
> that the result of it is the driver failing to probe. dev_info() may go
> unnoticed.
>
Absence of memory timings is a valid case, hence dev_info() suit well here.
I can't see anything wrong with returning a errno if driver has nothing to do
and prefer to keep it because in that case managed resources would be free'd by
the driver core, though returning '0' also would work.
>> +
>> + return NULL;
>> +}
>> +
>> +static int tegra_emc_clk_change_notify(struct notifier_block *nb,
>> + unsigned long msg, void *data)
>> +{
>> + struct tegra_emc *emc = container_of(nb, struct tegra_emc, clk_nb);
>> + struct clk_notifier_data *cnd = data;
>> + int err;
>> +
>> + switch (msg) {
>> + case PRE_RATE_CHANGE:
>> + err = emc_prepare_timing_change(emc, cnd->new_rate);
>> + break;
>> +
>> + case ABORT_RATE_CHANGE:
>> + err = emc_prepare_timing_change(emc, cnd->old_rate);
>> + if (err)
>> + break;
>> +
>> + err = emc_complete_timing_change(emc, true);
>> + break;
>> +
>> + case POST_RATE_CHANGE:
>> + err = emc_complete_timing_change(emc, false);
>> + break;
>> +
>> + default:
>> + return NOTIFY_DONE;
>> + }
>> +
>> + return notifier_from_errno(err);
>> +}
>> +
>> +static int emc_setup_hw(struct tegra_emc *emc)
>> +{
>> + u32 emc_cfg;
>> +
>> + emc_cfg = readl_relaxed(emc->regs + EMC_CFG_2);
>> +
>> + /*
>> + * Depending on a memory type, DRAM should enter either self-refresh
>> + * or power-down state on EMC clock change.
>> + */
>> + if (!(emc_cfg & EMC_CLKCHANGE_PD_ENABLE) &&
>> + !(emc_cfg & EMC_CLKCHANGE_SR_ENABLE))
>> + {
>> + dev_err(emc->dev,
>> + "bootloader didn't specify DRAM auto-suspend mode\n");
>> + return -EINVAL;
>> + }
>> +
>> + /* allow EMC and CAR to handshake on PLL divider/source changes */
>> + emc_cfg |= EMC_CLKCHANGE_REQ_ENABLE;
>> + writel_relaxed(emc_cfg, emc->regs + EMC_CFG_2);
>> +
>> + /* initialize interrupt */
>> + writel_relaxed(EMC_CLKCHANGE_COMPLETE_INT, emc->regs + EMC_INTMASK);
>> + writel_relaxed(EMC_CLKCHANGE_COMPLETE_INT, emc->regs + EMC_INTSTATUS);
>> +
>> + return 0;
>> +}
>> +
>> +static int emc_init(struct tegra_emc *emc, unsigned long rate)
>> +{
>> + int err;
>> +
>> + err = clk_set_parent(emc->emc_mux, emc->backup_clk);
>> + if (err) {
>> + dev_err(emc->dev,
>> + "failed to reparent to backup source: %d\n", err);
>> + return err;
>> + }
>> +
>> + err = clk_set_rate(emc->pll_m, rate);
>> + if (err)
>> + dev_err(emc->dev,
>> + "failed to change pll_m rate: %d\n", err);
>> +
>> + err = clk_set_parent(emc->emc_mux, emc->pll_m);
>> + if (err) {
>> + dev_err(emc->dev,
>> + "failed to reparent to pll_m: %d\n", err);
>> + return err;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int tegra_emc_probe(struct platform_device *pdev)
>> +{
>> + struct device_node *np;
>> + struct tegra_emc *emc;
>> + struct resource *res;
>> + u32 ram_code;
>> + int err;
>> +
>> + emc = devm_kzalloc(&pdev->dev, sizeof(*emc), GFP_KERNEL);
>> + if (!emc)
>> + return -ENOMEM;
>> +
>> + emc->dev = &pdev->dev;
>> +
>> + ram_code = tegra_read_ram_code();
>> +
>> + np = tegra_emc_find_node_by_ram_code(emc, ram_code);
>> + if (!np)
>> + return -ENOENT;
>> +
>> + err = tegra_emc_load_timings_from_dt(emc, np);
>> + of_node_put(np);
>> + if (err)
>> + return err;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + emc->regs = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(emc->regs))
>> + return PTR_ERR(emc->regs);
>> +
>> + err = emc_setup_hw(emc);
>> + if (err)
>> + return err;
>> +
>> + emc->irq = platform_get_irq(pdev, 0);
>> + if (emc->irq < 0) {
>> + dev_warn(&pdev->dev, "interrupt not specified\n");
>> + dev_warn(&pdev->dev, "continuing, but please update your DT\n");
>
> Do we really need this? I think this is a case where we don't have to
> keep backwards-compatibility because this driver hasn't "worked" in a
> very long time (because it was absent). Therefore, if we error out in
> the absence of an interrupt we don't break anything.
>
> There's a few places in this driver that are awkward just because the
> interrupt isn't mandatory. I don't think it's warranted in this case.
>
Backwards compatibility is always nice to have, but I don't really mind dropping it.
>> + } else {
>> + init_completion(&emc->clk_handshake_complete);
>> +
>> + err = devm_request_irq(&pdev->dev, emc->irq, tegra_emc_isr, 0,
>> + dev_name(&pdev->dev), emc);
>> + if (err < 0) {
>> + dev_err(&pdev->dev, "failed to request IRQ#%u: %d\n",
>> + emc->irq, err);
>> + return err;
>> + }
>> + }
>> +
>> + emc->pll_m = clk_get_sys(NULL, "pll_m");
>> + if (IS_ERR(emc->pll_m)) {
>> + err = PTR_ERR(emc->pll_m);
>> + dev_err(&pdev->dev, "failed to get pll_m: %d\n", err);
>> + return err;
>> + }
>> +
>> + emc->backup_clk = clk_get_sys(NULL, "pll_p");
>> + if (IS_ERR(emc->backup_clk)) {
>> + err = PTR_ERR(emc->backup_clk);
>> + dev_err(&pdev->dev, "failed to get pll_p: %d\n", err);
>> + goto put_pll_m;
>> + }
>> +
>> + emc->clk = clk_get_sys(NULL, "emc");
>> + if (IS_ERR(emc->clk)) {
>> + err = PTR_ERR(emc->clk);
>> + dev_err(&pdev->dev, "failed to get emc: %d\n", err);
>> + goto put_backup;
>> + }
>
> Instead of using clk_get_sys(), why not specify these in the DT with
> proper names for context ("emc", "pll", "backup")? Again, I don't think
> we have to worry about backwards-compatibility here since there can be
> no regression.
>
I don't think that "pll" and "backup" could be placed in DT because it is a pure
software-driver description.
"emc" could be retrieved from DT if we don't care about backwards compatibility.
^ permalink raw reply
* Re: [PATCH 2/2] dmaengine: rcar-dmac: Document R8A77990 bindings
From: Geert Uytterhoeven @ 2018-06-06 13:34 UTC (permalink / raw)
To: Ulrich Hecht
Cc: Linux-Renesas, Simon Horman, dmaengine,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Hiroyuki Yokoyama
In-Reply-To: <1526475979-13891-2-git-send-email-ulrich.hecht+renesas@gmail.com>
On Wed, May 16, 2018 at 3:06 PM, Ulrich Hecht
<ulrich.hecht+renesas@gmail.com> wrote:
> From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
>
> Renesas R-Car E3 (R8A77990) SoC also has the R-Car gen2/3 compatible DMA
> controllers, so document the SoC specific binding.
>
> Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
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 v2 5/5] venus: register separate driver for firmware device
From: Vikash Garodia @ 2018-06-06 13:03 UTC (permalink / raw)
To: Tomasz Figa
Cc: Rob Herring, Hans Verkuil, Mauro Carvalho Chehab, Mark Rutland,
Andy Gross, bjorn.andersson, Stanimir Varbanov,
Linux Media Mailing List, Linux Kernel Mailing List,
linux-arm-msm, linux-soc, devicetree, Alexandre Courbot,
linux-media-owner
In-Reply-To: <CAAFQd5DGKnU15pjF2+eyMUaSuE0FCr2FMF90WrJb+kXt80xBCw@mail.gmail.com>
On 2018-06-06 10:16, Tomasz Figa wrote:
> Hi Rob,
>
> On Wed, Jun 6, 2018 at 6:08 AM Rob Herring <robh@kernel.org> wrote:
>>
>> On Sat, Jun 02, 2018 at 01:56:08AM +0530, Vikash Garodia wrote:
>> > A separate child device is added for video firmware.
>> > This is needed to
>> > [1] configure the firmware context bank with the desired SID.
>> > [2] ensure that the iova for firmware region is from 0x0.
>> >
>> > Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
>> > ---
>> > .../devicetree/bindings/media/qcom,venus.txt | 8 +++-
>> > drivers/media/platform/qcom/venus/core.c | 48 +++++++++++++++++++---
>> > drivers/media/platform/qcom/venus/firmware.c | 20 ++++++++-
>> > drivers/media/platform/qcom/venus/firmware.h | 2 +
>> > 4 files changed, 71 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt b/Documentation/devicetree/bindings/media/qcom,venus.txt
>> > index 00d0d1b..701cbe8 100644
>> > --- a/Documentation/devicetree/bindings/media/qcom,venus.txt
>> > +++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
>> > @@ -53,7 +53,7 @@
>> >
>> > * Subnodes
>> > The Venus video-codec node must contain two subnodes representing
>> > -video-decoder and video-encoder.
>> > +video-decoder and video-encoder, one optional firmware subnode.
>> >
>> > Every of video-encoder or video-decoder subnode should have:
>> >
>> > @@ -79,6 +79,8 @@ Every of video-encoder or video-decoder subnode should have:
>> > power domain which is responsible for collapsing
>> > and restoring power to the subcore.
>> >
>> > +The firmware sub node must contain the iommus specifiers for ARM9.
>> > +
>> > * An Example
>> > video-codec@1d00000 {
>> > compatible = "qcom,msm8916-venus";
>> > @@ -105,4 +107,8 @@ Every of video-encoder or video-decoder subnode should have:
>> > clock-names = "core";
>> > power-domains = <&mmcc VENUS_CORE1_GDSC>;
>> > };
>> > + venus-firmware {
>> > + compatible = "qcom,venus-firmware-no-tz";
>> > + iommus = <&apps_smmu 0x10b2 0x0>;
>>
>> This mostly looks like you are adding a node in order to create a
>> platform device. DT is not the only way to create platform devices and
>> shouldn't be used when the device is not really a separate h/w device.
>> Plus it seems like it is debatable that you even need a driver.
>>
>> For iommus, just move it up to the parent (or add to existing prop).
>
> As far as I understood the issue from reading this series and also
> talking a bit with Stanimir, there are multiple (physical?) ports from
> the Venus hardware block and that includes one dedicated for firmware
> loading, which has IOVA range restrictions up to 6 MiBs or something
> like that.
>
> If we add the firmware port to the iommus property of the main node,
> we would bind it to the same IOVA address space as the other ports and
> so it would be part of the main full 32-bit IOMMU domain.
Not really port-wise, but the restriction part is right. Once the
firmware
is loaded, the ARM9 can only execute those firmware instructions if it
is
present in iova address 0x0.
Merging it to parent device cannot guarantee that the firmware memory is
mapped from 0x0.
> Best regards,
> Tomasz
^ permalink raw reply
* Re: [PATCH v2 5/5] venus: register separate driver for firmware device
From: Rob Herring @ 2018-06-06 12:53 UTC (permalink / raw)
To: Tomasz Figa
Cc: Vikash Garodia, Hans Verkuil, Mauro Carvalho Chehab, Mark Rutland,
Andy Gross, Bjorn Andersson, Stanimir Varbanov,
Linux Media Mailing List, Linux Kernel Mailing List,
linux-arm-msm, open list:ARM/QUALCOMM SUPPORT, devicetree,
Alexandre Courbot
In-Reply-To: <CAAFQd5DGKnU15pjF2+eyMUaSuE0FCr2FMF90WrJb+kXt80xBCw@mail.gmail.com>
On Tue, Jun 5, 2018 at 11:46 PM, Tomasz Figa <tfiga@google.com> wrote:
> Hi Rob,
>
> On Wed, Jun 6, 2018 at 6:08 AM Rob Herring <robh@kernel.org> wrote:
>>
>> On Sat, Jun 02, 2018 at 01:56:08AM +0530, Vikash Garodia wrote:
>> > A separate child device is added for video firmware.
>> > This is needed to
>> > [1] configure the firmware context bank with the desired SID.
>> > [2] ensure that the iova for firmware region is from 0x0.
>> >
>> > Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
>> > ---
>> > .../devicetree/bindings/media/qcom,venus.txt | 8 +++-
>> > drivers/media/platform/qcom/venus/core.c | 48 +++++++++++++++++++---
>> > drivers/media/platform/qcom/venus/firmware.c | 20 ++++++++-
>> > drivers/media/platform/qcom/venus/firmware.h | 2 +
>> > 4 files changed, 71 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt b/Documentation/devicetree/bindings/media/qcom,venus.txt
>> > index 00d0d1b..701cbe8 100644
>> > --- a/Documentation/devicetree/bindings/media/qcom,venus.txt
>> > +++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
>> > @@ -53,7 +53,7 @@
>> >
>> > * Subnodes
>> > The Venus video-codec node must contain two subnodes representing
>> > -video-decoder and video-encoder.
>> > +video-decoder and video-encoder, one optional firmware subnode.
>> >
>> > Every of video-encoder or video-decoder subnode should have:
>> >
>> > @@ -79,6 +79,8 @@ Every of video-encoder or video-decoder subnode should have:
>> > power domain which is responsible for collapsing
>> > and restoring power to the subcore.
>> >
>> > +The firmware sub node must contain the iommus specifiers for ARM9.
>> > +
>> > * An Example
>> > video-codec@1d00000 {
>> > compatible = "qcom,msm8916-venus";
>> > @@ -105,4 +107,8 @@ Every of video-encoder or video-decoder subnode should have:
>> > clock-names = "core";
>> > power-domains = <&mmcc VENUS_CORE1_GDSC>;
>> > };
>> > + venus-firmware {
>> > + compatible = "qcom,venus-firmware-no-tz";
>> > + iommus = <&apps_smmu 0x10b2 0x0>;
>>
>> This mostly looks like you are adding a node in order to create a
>> platform device. DT is not the only way to create platform devices and
>> shouldn't be used when the device is not really a separate h/w device.
>> Plus it seems like it is debatable that you even need a driver.
>>
>> For iommus, just move it up to the parent (or add to existing prop).
>
> As far as I understood the issue from reading this series and also
> talking a bit with Stanimir, there are multiple (physical?) ports from
> the Venus hardware block and that includes one dedicated for firmware
> loading, which has IOVA range restrictions up to 6 MiBs or something
> like that.
>
> If we add the firmware port to the iommus property of the main node,
> we would bind it to the same IOVA address space as the other ports and
> so it would be part of the main full 32-bit IOMMU domain.
Sounds like an OS limitation, not a DT problem.
That being said, I suppose we can live with having this sub-node if we
can't fix or work-around this limitation.
Rob
^ permalink raw reply
* [PATCH] dt-bindings: Add bitmain vendor prefix
From: Michal Simek @ 2018-06-06 12:49 UTC (permalink / raw)
To: devicetree
Cc: Thierry Reding, Andreas Färber, linux-kernel, David Lechner,
Rob Herring, Noralf Trønnes, Alexandre Belloni, Mark Rutland,
SZ Lin
Bitmain (https://www.bitmain.com) is a vendor of cryptocurrency
hardware.
Signed-off-by: Michal Simek <monstr@monstr.eu>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 36003832c2a8..ddb52511a583 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -51,6 +51,7 @@ axentia Axentia Technologies AB
axis Axis Communications AB
bananapi BIPAI KEJI LIMITED
bhf Beckhoff Automation GmbH & Co. KG
+bitmain Bitmain Technologies
boe BOE Technology Group Co., Ltd.
bosch Bosch Sensortec GmbH
boundary Boundary Devices Inc.
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 0/5] Tegra20 External Memory Controller driver
From: Dmitry Osipenko @ 2018-06-06 12:41 UTC (permalink / raw)
To: Thierry Reding
Cc: Peter De Schrijver, Jonathan Hunter, Prashant Gaikwad,
Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
linux-tegra, linux-clk, devicetree, linux-kernel
In-Reply-To: <20180606104550.GK11810@ulmo>
On 06.06.2018 13:45, Thierry Reding wrote:
> On Mon, Jun 04, 2018 at 01:36:49AM +0300, Dmitry Osipenko wrote:
>> Hello,
>>
>> Couple years ago the Tegra20 EMC driver was removed from the kernel
>> due to incompatible changes in the Tegra's clock driver. This patchset
>> introduces a modernized EMC driver. Currently the sole purpose of the
>> driver is to initialize DRAM frequency to maximum rate during of the
>> kernels boot-up. Later we may consider implementing dynamic memory
>> frequency scaling, utilizing functionality provided by this driver.
>>
>> Changelog:
>>
>> v2:
>> - Minor code cleanups like consistent use of writel_relaxed instead
>> of non-relaxed version, reworded error messages, etc.
>>
>> - Factored out use_pllm_ud bit checking into a standalone patch for
>> consistency.
>>
>> Dmitry Osipenko (5):
>> dt: bindings: tegra20-emc: Document interrupt property
>> ARM: dts: tegra20: Add interrupt to External Memory Controller
>> clk: tegra20: Turn EMC clock gate into divider
>> clk: tegra20: Check whether direct PLLM sourcing is turned off for EMC
>> memory: tegra: Introduce Tegra20 EMC driver
>
> I took a brief look and didn't spot any dependencies between the clk and
> memory patches. Is it correct that these can be applied separately?
Yes, it is correct.
^ permalink raw reply
* Re: [PATCH v3 3/6] mtd: rawnand: tegra: add devicetree binding
From: Boris Brezillon @ 2018-06-06 12:31 UTC (permalink / raw)
To: Stefan Agner
Cc: Thierry Reding, Dmitry Osipenko, dwmw2, computersforpeace,
marek.vasut, robh+dt, mark.rutland, benjamin.lindqvist, pgaikwad,
dev, mirza.krak, richard, pdeschrijver, linux-kernel, krzk,
jonathanh, devicetree, linux-mtd, marcel, miquel.raynal,
linux-tegra
In-Reply-To: <c687fc59e2662d07568f94efb55bc250@agner.ch>
On Wed, 06 Jun 2018 14:14:23 +0200
Stefan Agner <stefan@agner.ch> wrote:
> On 06.06.2018 13:07, Thierry Reding wrote:
> > On Wed, Jun 06, 2018 at 12:45:40PM +0200, Boris Brezillon wrote:
> >> Hi Thierry,
> >>
> >> On Wed, 6 Jun 2018 12:39:03 +0200
> >> Thierry Reding <thierry.reding@gmail.com> wrote:
> >>
> >> > On Tue, Jun 05, 2018 at 11:19:14PM +0300, Dmitry Osipenko wrote:
> >> > > On 01.06.2018 10:30, Boris Brezillon wrote:
> >> > > > On Fri, 1 Jun 2018 00:16:34 +0200
> >> > > > Stefan Agner <stefan@agner.ch> wrote:
> >> > > >
> >> > > >> This adds the devicetree binding for the Tegra 2 NAND flash
> >> > > >> controller.
> >> > > >>
> >> > > >> Signed-off-by: Lucas Stach <dev@lynxeye.de>
> >> > > >> Signed-off-by: Stefan Agner <stefan@agner.ch>
> >> > > >> ---
> >> > > >> .../bindings/mtd/nvidia-tegra20-nand.txt | 64 +++++++++++++++++++
> >> > > >> 1 file changed, 64 insertions(+)
> >> > > >> create mode 100644 Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
> >> > > >>
> >> > > >> diff --git a/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
> >> > > >> new file mode 100644
> >> > > >> index 000000000000..5cd984ef046b
> >> > > >> --- /dev/null
> >> > > >> +++ b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
> >> > > >> @@ -0,0 +1,64 @@
> >> > > >> +NVIDIA Tegra NAND Flash controller
> >> > > >> +
> >> > > >> +Required properties:
> >> > > >> +- compatible: Must be one of:
> >> > > >> + - "nvidia,tegra20-nand"
> >> > > >
> >> > > > As discussed previously, I prefer "nvidia,tegra20-nand-controller" or
> >> > > > "nvidia,tegra20-nfc".
> >> > > >
> >> > > >> +- reg: MMIO address range
> >> > > >> +- interrupts: interrupt output of the NFC controller
> >> > > >> +- clocks: Must contain an entry for each entry in clock-names.
> >> > > >> + See ../clocks/clock-bindings.txt for details.
> >> > > >> +- clock-names: Must include the following entries:
> >> > > >> + - nand
> >> > > >> +- resets: Must contain an entry for each entry in reset-names.
> >> > > >> + See ../reset/reset.txt for details.
> >> > > >> +- reset-names: Must include the following entries:
> >> > > >> + - nand
> >> > > >> +
> >> > > >> +Optional children nodes:
> >> > > >> +Individual NAND chips are children of the NAND controller node. Currently
> >> > > >> +only one NAND chip supported.
> >> > > >> +
> >> > > >> +Required children node properties:
> >> > > >> +- reg: An integer ranging from 1 to 6 representing the CS line to use.
> >> > > >> +
> >> > > >> +Optional children node properties:
> >> > > >> +- nand-ecc-mode: String, operation mode of the NAND ecc mode. Currently only
> >> > > >> + "hw" is supported.
> >> > > >> +- nand-ecc-algo: string, algorithm of NAND ECC.
> >> > > >> + Supported values with "hw" ECC mode are: "rs", "bch".
> >> > > >> +- nand-bus-width : See nand.txt
> >> > > >> +- nand-on-flash-bbt: See nand.txt
> >> > > >> +- nand-ecc-strength: integer representing the number of bits to correct
> >> > > >> + per ECC step (always 512). Supported strength using HW ECC
> >> > > >> + modes are:
> >> > > >> + - RS: 4, 6, 8
> >> > > >> + - BCH: 4, 8, 14, 16
> >> > > >> +- nand-ecc-maximize: See nand.txt
> >> > > >> +- nand-is-boot-medium: Makes sure only ECC strengths supported by the boot ROM
> >> > > >> + are choosen.
> >> > > >> +- wp-gpios: GPIO specifier for the write protect pin.
> >> > > >> +
> >> > > >> +Optional child node of NAND chip nodes:
> >> > > >> +Partitions: see partition.txt
> >> > > >> +
> >> > > >> + Example:
> >> > > >> + nand@70008000 {
> >> > > >
> >> > > > nand-controller@70008000 {
> >> > > >
> >> > > >> + compatible = "nvidia,tegra20-nand";
> >> > > >
> >> > > > compatible = "nvidia,tegra20-nand-controller";
> >> > > >
> >> > > > or
> >> > > >
> >> > > > compatible = "nvidia,tegra20-nfc";
> >> > > >
> >> > >
> >> > > Maybe it's just me, but when I'm reading "nfc", my first association is the
> >> > > "Near Field Communication". Probably an explicit
> >> > > "nvidia,tegra20-nand-controller" variant is more preferable.
> >>
> >> I also prefer nvidia,tegra20-nand-controller.
> >>
> >> >
> >> > We don't really use a -controller suffix for any of the other
> >> > controllers because it is kind of implied. "nfc" is also not something
> >> > that is ever referred to in the technical documentation.
> >> >
> >> > "nvidia,tegra20-nand" would be most consistent with all the rest of
> >> > Tegra (c.f. "nvidia,tegra*-ahci", "nvidia,tegra*-pci",
> >> > "nvidia,tegra*-hda", "nvidia,tegra*-gmi", ...).
> >>
> >> People get confused about what this node represents when you just have
> >> "nvidia,tegra20-nand", and then you start seeing NAND related props or
> >> partition nodes being defined under the NAND controller node.
> >> I really prefer to have the "-controller" prefix here to avoid such
> >> confusions.
> >
> > Hmm... odd. I mean, the node is already called nand-controller@...,
> > which makes it pretty obvious to me that this represents a controller
> > rather than a NAND chip. Also, the placement of this in the DT hierarchy
> > should make it pretty obvious that it is a controller since you can't
> > just put a NAND chip directly on the CPU's address bus.
> >
> > In addition I think the nvidia,tegra* part already pretty strongly
> > suggests that this is part of an SoC, so further implies "controller".
>
> The reference manual states:
> "16.0 NAND FLASH CONTROLLER
>
> The NAND flash controller allows Tegra 2 Processor to access NAND flash
> memories for mass storage."
>
> So I guess "nvidia,tegra20-nand-flash-controller" would be most
> explicit. But the manual also has "GPIO controller" and we use
> "nvidia,tegra20-gpio" as compatible string.
>
> I dislike nfc since it is an increasingly less known abbreviation and
> not used in the reference manual at all.
>
> "nvidia,tegra20-nand" or "nvidia,tegra20-nand-flash-controller" is fine
> for me...
Enough bikeshedding, let's go for "nvidia,tegra20-nand" :-). As long as
the representation clearly differentiate the NAND controller and the
NAND chips I'm fine with it.
^ permalink raw reply
* Re: [PATCH v3 3/6] mtd: rawnand: tegra: add devicetree binding
From: Stefan Agner @ 2018-06-06 12:14 UTC (permalink / raw)
To: Thierry Reding
Cc: Boris Brezillon, Dmitry Osipenko, dwmw2, computersforpeace,
marek.vasut, robh+dt, mark.rutland, benjamin.lindqvist, pgaikwad,
dev, mirza.krak, richard, pdeschrijver, linux-kernel, krzk,
jonathanh, devicetree, linux-mtd, marcel, miquel.raynal,
linux-tegra
In-Reply-To: <20180606110735.GM11810@ulmo>
On 06.06.2018 13:07, Thierry Reding wrote:
> On Wed, Jun 06, 2018 at 12:45:40PM +0200, Boris Brezillon wrote:
>> Hi Thierry,
>>
>> On Wed, 6 Jun 2018 12:39:03 +0200
>> Thierry Reding <thierry.reding@gmail.com> wrote:
>>
>> > On Tue, Jun 05, 2018 at 11:19:14PM +0300, Dmitry Osipenko wrote:
>> > > On 01.06.2018 10:30, Boris Brezillon wrote:
>> > > > On Fri, 1 Jun 2018 00:16:34 +0200
>> > > > Stefan Agner <stefan@agner.ch> wrote:
>> > > >
>> > > >> This adds the devicetree binding for the Tegra 2 NAND flash
>> > > >> controller.
>> > > >>
>> > > >> Signed-off-by: Lucas Stach <dev@lynxeye.de>
>> > > >> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> > > >> ---
>> > > >> .../bindings/mtd/nvidia-tegra20-nand.txt | 64 +++++++++++++++++++
>> > > >> 1 file changed, 64 insertions(+)
>> > > >> create mode 100644 Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
>> > > >>
>> > > >> diff --git a/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
>> > > >> new file mode 100644
>> > > >> index 000000000000..5cd984ef046b
>> > > >> --- /dev/null
>> > > >> +++ b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
>> > > >> @@ -0,0 +1,64 @@
>> > > >> +NVIDIA Tegra NAND Flash controller
>> > > >> +
>> > > >> +Required properties:
>> > > >> +- compatible: Must be one of:
>> > > >> + - "nvidia,tegra20-nand"
>> > > >
>> > > > As discussed previously, I prefer "nvidia,tegra20-nand-controller" or
>> > > > "nvidia,tegra20-nfc".
>> > > >
>> > > >> +- reg: MMIO address range
>> > > >> +- interrupts: interrupt output of the NFC controller
>> > > >> +- clocks: Must contain an entry for each entry in clock-names.
>> > > >> + See ../clocks/clock-bindings.txt for details.
>> > > >> +- clock-names: Must include the following entries:
>> > > >> + - nand
>> > > >> +- resets: Must contain an entry for each entry in reset-names.
>> > > >> + See ../reset/reset.txt for details.
>> > > >> +- reset-names: Must include the following entries:
>> > > >> + - nand
>> > > >> +
>> > > >> +Optional children nodes:
>> > > >> +Individual NAND chips are children of the NAND controller node. Currently
>> > > >> +only one NAND chip supported.
>> > > >> +
>> > > >> +Required children node properties:
>> > > >> +- reg: An integer ranging from 1 to 6 representing the CS line to use.
>> > > >> +
>> > > >> +Optional children node properties:
>> > > >> +- nand-ecc-mode: String, operation mode of the NAND ecc mode. Currently only
>> > > >> + "hw" is supported.
>> > > >> +- nand-ecc-algo: string, algorithm of NAND ECC.
>> > > >> + Supported values with "hw" ECC mode are: "rs", "bch".
>> > > >> +- nand-bus-width : See nand.txt
>> > > >> +- nand-on-flash-bbt: See nand.txt
>> > > >> +- nand-ecc-strength: integer representing the number of bits to correct
>> > > >> + per ECC step (always 512). Supported strength using HW ECC
>> > > >> + modes are:
>> > > >> + - RS: 4, 6, 8
>> > > >> + - BCH: 4, 8, 14, 16
>> > > >> +- nand-ecc-maximize: See nand.txt
>> > > >> +- nand-is-boot-medium: Makes sure only ECC strengths supported by the boot ROM
>> > > >> + are choosen.
>> > > >> +- wp-gpios: GPIO specifier for the write protect pin.
>> > > >> +
>> > > >> +Optional child node of NAND chip nodes:
>> > > >> +Partitions: see partition.txt
>> > > >> +
>> > > >> + Example:
>> > > >> + nand@70008000 {
>> > > >
>> > > > nand-controller@70008000 {
>> > > >
>> > > >> + compatible = "nvidia,tegra20-nand";
>> > > >
>> > > > compatible = "nvidia,tegra20-nand-controller";
>> > > >
>> > > > or
>> > > >
>> > > > compatible = "nvidia,tegra20-nfc";
>> > > >
>> > >
>> > > Maybe it's just me, but when I'm reading "nfc", my first association is the
>> > > "Near Field Communication". Probably an explicit
>> > > "nvidia,tegra20-nand-controller" variant is more preferable.
>>
>> I also prefer nvidia,tegra20-nand-controller.
>>
>> >
>> > We don't really use a -controller suffix for any of the other
>> > controllers because it is kind of implied. "nfc" is also not something
>> > that is ever referred to in the technical documentation.
>> >
>> > "nvidia,tegra20-nand" would be most consistent with all the rest of
>> > Tegra (c.f. "nvidia,tegra*-ahci", "nvidia,tegra*-pci",
>> > "nvidia,tegra*-hda", "nvidia,tegra*-gmi", ...).
>>
>> People get confused about what this node represents when you just have
>> "nvidia,tegra20-nand", and then you start seeing NAND related props or
>> partition nodes being defined under the NAND controller node.
>> I really prefer to have the "-controller" prefix here to avoid such
>> confusions.
>
> Hmm... odd. I mean, the node is already called nand-controller@...,
> which makes it pretty obvious to me that this represents a controller
> rather than a NAND chip. Also, the placement of this in the DT hierarchy
> should make it pretty obvious that it is a controller since you can't
> just put a NAND chip directly on the CPU's address bus.
>
> In addition I think the nvidia,tegra* part already pretty strongly
> suggests that this is part of an SoC, so further implies "controller".
The reference manual states:
"16.0 NAND FLASH CONTROLLER
The NAND flash controller allows Tegra 2 Processor to access NAND flash
memories for mass storage."
So I guess "nvidia,tegra20-nand-flash-controller" would be most
explicit. But the manual also has "GPIO controller" and we use
"nvidia,tegra20-gpio" as compatible string.
I dislike nfc since it is an increasingly less known abbreviation and
not used in the reference manual at all.
"nvidia,tegra20-nand" or "nvidia,tegra20-nand-flash-controller" is fine
for me...
--
Stefan
^ permalink raw reply
* RE: [PATCH 09/10] dpaa_eth: add support for hardware timestamping
From: Y.b. Lu @ 2018-06-06 11:48 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev@vger.kernel.org, Madalin-cristian Bucur, Rob Herring,
Shawn Guo, David S . Miller, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20180605135748.mlarwiyzf2oe27ax@localhost>
Hi Richard,
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Tuesday, June 5, 2018 9:58 PM
> To: Y.b. Lu <yangbo.lu@nxp.com>
> Cc: netdev@vger.kernel.org; Madalin-cristian Bucur
> <madalin.bucur@nxp.com>; Rob Herring <robh+dt@kernel.org>; Shawn Guo
> <shawnguo@kernel.org>; David S . Miller <davem@davemloft.net>;
> devicetree@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 09/10] dpaa_eth: add support for hardware timestamping
>
> On Tue, Jun 05, 2018 at 03:35:28AM +0000, Y.b. Lu wrote:
> > [Y.b. Lu] Actually these timestamping codes affected DPAA networking
> performance in our previous performance test.
> > That's why we used ifdef for it.
>
> How much does time stamping hurt performance?
>
> If the time stamping is compiled in but not enabled at run time, does it still
> affect performace?
[Y.b. Lu] I can't remember and find the old data since it had been a long time.
I just did the iperf test today between two 10G ports. I didn’t see any performance changes with timestamping code 😊
So, let's me remove the ifdef in next version.
Thanks a lot.
>
> Thanks,
> Richard
^ permalink raw reply
* Re: [PATCH v3 3/6] mtd: rawnand: tegra: add devicetree binding
From: Thierry Reding @ 2018-06-06 11:07 UTC (permalink / raw)
To: Boris Brezillon
Cc: Dmitry Osipenko, Stefan Agner, dwmw2, computersforpeace,
marek.vasut, robh+dt, mark.rutland, benjamin.lindqvist, pgaikwad,
dev, mirza.krak, richard, pdeschrijver, linux-kernel, krzk,
jonathanh, devicetree, linux-mtd, marcel, miquel.raynal,
linux-tegra
In-Reply-To: <20180606124540.46bfa00b@bbrezillon>
[-- Attachment #1: Type: text/plain, Size: 5146 bytes --]
On Wed, Jun 06, 2018 at 12:45:40PM +0200, Boris Brezillon wrote:
> Hi Thierry,
>
> On Wed, 6 Jun 2018 12:39:03 +0200
> Thierry Reding <thierry.reding@gmail.com> wrote:
>
> > On Tue, Jun 05, 2018 at 11:19:14PM +0300, Dmitry Osipenko wrote:
> > > On 01.06.2018 10:30, Boris Brezillon wrote:
> > > > On Fri, 1 Jun 2018 00:16:34 +0200
> > > > Stefan Agner <stefan@agner.ch> wrote:
> > > >
> > > >> This adds the devicetree binding for the Tegra 2 NAND flash
> > > >> controller.
> > > >>
> > > >> Signed-off-by: Lucas Stach <dev@lynxeye.de>
> > > >> Signed-off-by: Stefan Agner <stefan@agner.ch>
> > > >> ---
> > > >> .../bindings/mtd/nvidia-tegra20-nand.txt | 64 +++++++++++++++++++
> > > >> 1 file changed, 64 insertions(+)
> > > >> create mode 100644 Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
> > > >>
> > > >> diff --git a/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
> > > >> new file mode 100644
> > > >> index 000000000000..5cd984ef046b
> > > >> --- /dev/null
> > > >> +++ b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
> > > >> @@ -0,0 +1,64 @@
> > > >> +NVIDIA Tegra NAND Flash controller
> > > >> +
> > > >> +Required properties:
> > > >> +- compatible: Must be one of:
> > > >> + - "nvidia,tegra20-nand"
> > > >
> > > > As discussed previously, I prefer "nvidia,tegra20-nand-controller" or
> > > > "nvidia,tegra20-nfc".
> > > >
> > > >> +- reg: MMIO address range
> > > >> +- interrupts: interrupt output of the NFC controller
> > > >> +- clocks: Must contain an entry for each entry in clock-names.
> > > >> + See ../clocks/clock-bindings.txt for details.
> > > >> +- clock-names: Must include the following entries:
> > > >> + - nand
> > > >> +- resets: Must contain an entry for each entry in reset-names.
> > > >> + See ../reset/reset.txt for details.
> > > >> +- reset-names: Must include the following entries:
> > > >> + - nand
> > > >> +
> > > >> +Optional children nodes:
> > > >> +Individual NAND chips are children of the NAND controller node. Currently
> > > >> +only one NAND chip supported.
> > > >> +
> > > >> +Required children node properties:
> > > >> +- reg: An integer ranging from 1 to 6 representing the CS line to use.
> > > >> +
> > > >> +Optional children node properties:
> > > >> +- nand-ecc-mode: String, operation mode of the NAND ecc mode. Currently only
> > > >> + "hw" is supported.
> > > >> +- nand-ecc-algo: string, algorithm of NAND ECC.
> > > >> + Supported values with "hw" ECC mode are: "rs", "bch".
> > > >> +- nand-bus-width : See nand.txt
> > > >> +- nand-on-flash-bbt: See nand.txt
> > > >> +- nand-ecc-strength: integer representing the number of bits to correct
> > > >> + per ECC step (always 512). Supported strength using HW ECC
> > > >> + modes are:
> > > >> + - RS: 4, 6, 8
> > > >> + - BCH: 4, 8, 14, 16
> > > >> +- nand-ecc-maximize: See nand.txt
> > > >> +- nand-is-boot-medium: Makes sure only ECC strengths supported by the boot ROM
> > > >> + are choosen.
> > > >> +- wp-gpios: GPIO specifier for the write protect pin.
> > > >> +
> > > >> +Optional child node of NAND chip nodes:
> > > >> +Partitions: see partition.txt
> > > >> +
> > > >> + Example:
> > > >> + nand@70008000 {
> > > >
> > > > nand-controller@70008000 {
> > > >
> > > >> + compatible = "nvidia,tegra20-nand";
> > > >
> > > > compatible = "nvidia,tegra20-nand-controller";
> > > >
> > > > or
> > > >
> > > > compatible = "nvidia,tegra20-nfc";
> > > >
> > >
> > > Maybe it's just me, but when I'm reading "nfc", my first association is the
> > > "Near Field Communication". Probably an explicit
> > > "nvidia,tegra20-nand-controller" variant is more preferable.
>
> I also prefer nvidia,tegra20-nand-controller.
>
> >
> > We don't really use a -controller suffix for any of the other
> > controllers because it is kind of implied. "nfc" is also not something
> > that is ever referred to in the technical documentation.
> >
> > "nvidia,tegra20-nand" would be most consistent with all the rest of
> > Tegra (c.f. "nvidia,tegra*-ahci", "nvidia,tegra*-pci",
> > "nvidia,tegra*-hda", "nvidia,tegra*-gmi", ...).
>
> People get confused about what this node represents when you just have
> "nvidia,tegra20-nand", and then you start seeing NAND related props or
> partition nodes being defined under the NAND controller node.
> I really prefer to have the "-controller" prefix here to avoid such
> confusions.
Hmm... odd. I mean, the node is already called nand-controller@...,
which makes it pretty obvious to me that this represents a controller
rather than a NAND chip. Also, the placement of this in the DT hierarchy
should make it pretty obvious that it is a controller since you can't
just put a NAND chip directly on the CPU's address bus.
In addition I think the nvidia,tegra* part already pretty strongly
suggests that this is part of an SoC, so further implies "controller".
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/5] memory: tegra: Introduce Tegra20 EMC driver
From: Thierry Reding @ 2018-06-06 11:02 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Peter De Schrijver, Jonathan Hunter, Prashant Gaikwad,
Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
linux-tegra, linux-clk, devicetree, linux-kernel
In-Reply-To: <20180603223654.23324-6-digetx@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 19214 bytes --]
On Mon, Jun 04, 2018 at 01:36:54AM +0300, Dmitry Osipenko wrote:
> Introduce driver for the External Memory Controller (EMC) found on Tegra20
> chips, which controls the external DRAM on the board. The purpose of this
> driver is to program memory timing for external memory on the EMC clock
> rate change.
>
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> ---
> drivers/memory/tegra/Kconfig | 10 +
> drivers/memory/tegra/Makefile | 1 +
> drivers/memory/tegra/tegra20-emc.c | 586 +++++++++++++++++++++++++++++
> 3 files changed, 597 insertions(+)
> create mode 100644 drivers/memory/tegra/tegra20-emc.c
>
> diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
> index 6d74e499e18d..34e0b70f5c5f 100644
> --- a/drivers/memory/tegra/Kconfig
> +++ b/drivers/memory/tegra/Kconfig
> @@ -6,6 +6,16 @@ config TEGRA_MC
> This driver supports the Memory Controller (MC) hardware found on
> NVIDIA Tegra SoCs.
>
> +config TEGRA20_EMC
> + bool "NVIDIA Tegra20 External Memory Controller driver"
> + default y
> + depends on ARCH_TEGRA_2x_SOC
> + help
> + This driver is for the External Memory Controller (EMC) found on
> + Tegra20 chips. The EMC controls the external DRAM on the board.
> + This driver is required to change memory timings / clock rate for
> + external memory.
> +
> config TEGRA124_EMC
> bool "NVIDIA Tegra124 External Memory Controller driver"
> default y
> diff --git a/drivers/memory/tegra/Makefile b/drivers/memory/tegra/Makefile
> index 94ab16ba075b..3971a6b7c487 100644
> --- a/drivers/memory/tegra/Makefile
> +++ b/drivers/memory/tegra/Makefile
> @@ -10,5 +10,6 @@ tegra-mc-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210.o
>
> obj-$(CONFIG_TEGRA_MC) += tegra-mc.o
>
> +obj-$(CONFIG_TEGRA20_EMC) += tegra20-emc.o
> obj-$(CONFIG_TEGRA124_EMC) += tegra124-emc.o
> obj-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186.o
> diff --git a/drivers/memory/tegra/tegra20-emc.c b/drivers/memory/tegra/tegra20-emc.c
> new file mode 100644
> index 000000000000..26a18b5e7941
> --- /dev/null
> +++ b/drivers/memory/tegra/tegra20-emc.c
> @@ -0,0 +1,586 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Tegra20 External Memory Controller driver
> + *
> + * Author: Dmitry Osipenko <digetx@gmail.com>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/completion.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/sort.h>
> +#include <linux/types.h>
> +
> +#include <soc/tegra/fuse.h>
> +
> +#define EMC_INTSTATUS 0x000
> +#define EMC_INTMASK 0x004
> +#define EMC_TIMING_CONTROL 0x028
> +#define EMC_RC 0x02c
> +#define EMC_RFC 0x030
> +#define EMC_RAS 0x034
> +#define EMC_RP 0x038
> +#define EMC_R2W 0x03c
> +#define EMC_W2R 0x040
> +#define EMC_R2P 0x044
> +#define EMC_W2P 0x048
> +#define EMC_RD_RCD 0x04c
> +#define EMC_WR_RCD 0x050
> +#define EMC_RRD 0x054
> +#define EMC_REXT 0x058
> +#define EMC_WDV 0x05c
> +#define EMC_QUSE 0x060
> +#define EMC_QRST 0x064
> +#define EMC_QSAFE 0x068
> +#define EMC_RDV 0x06c
> +#define EMC_REFRESH 0x070
> +#define EMC_BURST_REFRESH_NUM 0x074
> +#define EMC_PDEX2WR 0x078
> +#define EMC_PDEX2RD 0x07c
> +#define EMC_PCHG2PDEN 0x080
> +#define EMC_ACT2PDEN 0x084
> +#define EMC_AR2PDEN 0x088
> +#define EMC_RW2PDEN 0x08c
> +#define EMC_TXSR 0x090
> +#define EMC_TCKE 0x094
> +#define EMC_TFAW 0x098
> +#define EMC_TRPAB 0x09c
> +#define EMC_TCLKSTABLE 0x0a0
> +#define EMC_TCLKSTOP 0x0a4
> +#define EMC_TREFBW 0x0a8
> +#define EMC_QUSE_EXTRA 0x0ac
> +#define EMC_ODT_WRITE 0x0b0
> +#define EMC_ODT_READ 0x0b4
> +#define EMC_FBIO_CFG5 0x104
> +#define EMC_FBIO_CFG6 0x114
> +#define EMC_AUTO_CAL_INTERVAL 0x2a8
> +#define EMC_CFG_2 0x2b8
> +#define EMC_CFG_DIG_DLL 0x2bc
> +#define EMC_DLL_XFORM_DQS 0x2c0
> +#define EMC_DLL_XFORM_QUSE 0x2c4
> +#define EMC_ZCAL_REF_CNT 0x2e0
> +#define EMC_ZCAL_WAIT_CNT 0x2e4
> +#define EMC_CFG_CLKTRIM_0 0x2d0
> +#define EMC_CFG_CLKTRIM_1 0x2d4
> +#define EMC_CFG_CLKTRIM_2 0x2d8
> +
> +#define EMC_CLKCHANGE_REQ_ENABLE BIT(0)
> +#define EMC_CLKCHANGE_PD_ENABLE BIT(1)
> +#define EMC_CLKCHANGE_SR_ENABLE BIT(2)
> +
> +#define EMC_TIMING_UPDATE BIT(0)
> +
> +#define EMC_CLKCHANGE_COMPLETE_INT BIT(4)
> +
> +static const unsigned long emc_timing_registers[] = {
> + EMC_RC,
> + EMC_RFC,
> + EMC_RAS,
> + EMC_RP,
> + EMC_R2W,
> + EMC_W2R,
> + EMC_R2P,
> + EMC_W2P,
> + EMC_RD_RCD,
> + EMC_WR_RCD,
> + EMC_RRD,
> + EMC_REXT,
> + EMC_WDV,
> + EMC_QUSE,
> + EMC_QRST,
> + EMC_QSAFE,
> + EMC_RDV,
> + EMC_REFRESH,
> + EMC_BURST_REFRESH_NUM,
> + EMC_PDEX2WR,
> + EMC_PDEX2RD,
> + EMC_PCHG2PDEN,
> + EMC_ACT2PDEN,
> + EMC_AR2PDEN,
> + EMC_RW2PDEN,
> + EMC_TXSR,
> + EMC_TCKE,
> + EMC_TFAW,
> + EMC_TRPAB,
> + EMC_TCLKSTABLE,
> + EMC_TCLKSTOP,
> + EMC_TREFBW,
> + EMC_QUSE_EXTRA,
> + EMC_FBIO_CFG6,
> + EMC_ODT_WRITE,
> + EMC_ODT_READ,
> + EMC_FBIO_CFG5,
> + EMC_CFG_DIG_DLL,
> + EMC_DLL_XFORM_DQS,
> + EMC_DLL_XFORM_QUSE,
> + EMC_ZCAL_REF_CNT,
> + EMC_ZCAL_WAIT_CNT,
> + EMC_AUTO_CAL_INTERVAL,
> + EMC_CFG_CLKTRIM_0,
> + EMC_CFG_CLKTRIM_1,
> + EMC_CFG_CLKTRIM_2,
> +};
> +
> +struct emc_timing {
> + unsigned long rate;
> + u32 emc_registers_data[ARRAY_SIZE(emc_timing_registers)];
> +};
Nit: this seems like a very long variable name for something that is
really just "values" or "data" written into a set of registers.
> +struct tegra_emc {
> + struct device *dev;
> + struct notifier_block clk_nb;
> + struct clk *backup_clk;
> + struct clk *emc_mux;
> + struct clk *pll_m;
> + struct clk *clk;
> + void __iomem *regs;
> +
> + struct completion clk_handshake_complete;
> + int irq;
> +
> + struct emc_timing *timings;
> + unsigned int num_timings;
> +};
> +
> +static irqreturn_t tegra_emc_isr(int irq, void *data)
> +{
> + struct tegra_emc *emc = data;
> + u32 intmask = EMC_CLKCHANGE_COMPLETE_INT;
> + u32 status;
> +
> + status = readl_relaxed(emc->regs + EMC_INTSTATUS) & intmask;
> + if (!status)
> + return IRQ_NONE;
> +
> + /* clear interrupts */
> + writel_relaxed(status, emc->regs + EMC_INTSTATUS);
Do we really want to just clear the handshake complete interrupt or do
we want to clear all of them? Perhaps we should also warn if there are
other interrupts that we're not handling? Currently we'd only get some
warning if another interrupt triggered without the handshake complete
one triggering at the same time, but couldn't there be others asserted
along with the handshake complete interrupt? In which case we'd just
be ignoring them. Or perhaps not clearing it would get the ISR run
immediately again and produce the "nobody cared" warning?
> +
> + /* notify about EMC-CAR handshake completion */
> + complete(&emc->clk_handshake_complete);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static struct emc_timing *tegra_emc_find_timing(struct tegra_emc *emc,
> + unsigned long rate)
> +{
> + struct emc_timing *timing = NULL;
> + unsigned int i;
> +
> + for (i = 0; i < emc->num_timings; i++) {
> + if (emc->timings[i].rate >= rate) {
> + timing = &emc->timings[i];
> + break;
> + }
> + }
> +
> + if (!timing) {
> + dev_err(emc->dev, "no timing for rate %lu\n", rate);
> + return NULL;
> + }
> +
> + return timing;
> +}
> +
> +static int emc_prepare_timing_change(struct tegra_emc *emc, unsigned long rate)
> +{
> + struct emc_timing *timing = tegra_emc_find_timing(emc, rate);
> + unsigned int i;
> +
> + if (!timing)
> + return -ENOENT;
> +
> + dev_dbg(emc->dev, "%s: timing rate %lu emc rate %lu\n",
> + __func__, timing->rate, rate);
> +
> + /* program shadow registers */
> + for (i = 0; i < ARRAY_SIZE(timing->emc_registers_data); i++)
> + writel_relaxed(timing->emc_registers_data[i],
> + emc->regs + emc_timing_registers[i]);
> +
> + /* wait until programming has settled */
> + readl_relaxed(emc->regs + emc_timing_registers[0]);
> +
> + if (emc->irq < 0)
> + writel_relaxed(EMC_CLKCHANGE_COMPLETE_INT,
> + emc->regs + EMC_INTMASK);
> + else
> + reinit_completion(&emc->clk_handshake_complete);
> +
> + return 0;
> +}
> +
> +static int emc_complete_timing_change(struct tegra_emc *emc, bool flush)
> +{
> + long timeout;
> + u32 value;
> + int err;
> +
> + dev_dbg(emc->dev, "%s: flush %d\n", __func__, flush);
> +
> + if (flush) {
> + /* manually initiate memory timing update */
> + writel_relaxed(EMC_TIMING_UPDATE,
> + emc->regs + EMC_TIMING_CONTROL);
> + return 0;
> + }
> +
> + if (emc->irq < 0) {
> + /* poll interrupt status if IRQ isn't available */
> + err = readl_relaxed_poll_timeout(emc->regs + EMC_INTSTATUS,
> + value, value & EMC_CLKCHANGE_COMPLETE_INT,
> + 1, 100);
> + if (err) {
> + dev_err(emc->dev, "EMC-CAR handshake failed\n");
> + return -EIO;
> + }
> +
> + return 0;
> + }
> +
> + timeout = wait_for_completion_timeout(&emc->clk_handshake_complete,
> + usecs_to_jiffies(100));
> + if (timeout == 0) {
> + dev_err(emc->dev, "EMC handshake failed\n");
> + return -EIO;
> + } else if (timeout < 0) {
> + dev_err(emc->dev, "failed to wait for EMC-CAR handshake: %ld\n",
> + timeout);
> + return timeout;
> + }
> +
> + return 0;
> +}
> +
> +static int load_one_timing_from_dt(struct tegra_emc *emc,
> + struct emc_timing *timing,
> + struct device_node *node)
> +{
> + u32 rate;
> + int err;
> +
> + if (!of_device_is_compatible(node, "nvidia,tegra20-emc-table")) {
> + dev_err(emc->dev, "incompatible DT node \"%s\"\n",
> + node->name);
> + return -EINVAL;
> + }
> +
> + err = of_property_read_u32(node, "clock-frequency", &rate);
> + if (err) {
> + dev_err(emc->dev, "timing %s: failed to read rate: %d\n",
> + node->name, err);
> + return err;
> + }
> +
> + err = of_property_read_u32_array(node, "nvidia,emc-registers",
> + timing->emc_registers_data,
> + ARRAY_SIZE(emc_timing_registers));
> + if (err) {
> + dev_err(emc->dev,
> + "timing %s: failed to read emc timing data: %d\n",
> + node->name, err);
> + return err;
> + }
> +
> + /*
> + * The EMC clock rate is twice the bus rate, and the bus rate is
> + * measured in kHz.
> + */
> + timing->rate = rate * 2 * 1000;
> +
> + dev_dbg(emc->dev, "%s: emc rate %ld\n", __func__, timing->rate);
Nit: %lu for timing->rate?
> +
> + return 0;
> +}
> +
> +static int cmp_timings(const void *_a, const void *_b)
> +{
> + const struct emc_timing *a = _a;
> + const struct emc_timing *b = _b;
> +
> + if (a->rate < b->rate)
> + return -1;
> + else if (a->rate == b->rate)
> + return 0;
> + else
> + return 1;
Nit, I tend to
> +}
> +
> +static int tegra_emc_load_timings_from_dt(struct tegra_emc *emc,
> + struct device_node *node)
> +{
> + struct device_node *child;
> + struct emc_timing *timing;
> + int child_count;
> + int err;
> +
> + child_count = of_get_child_count(node);
It's unfortunate that of_get_child_count() doesn't return unsigned int,
there's no reason why this would have to be signed.
> + if (!child_count) {
> + dev_err(emc->dev, "no memory timings in DT node\n");
> + return -ENOENT;
> + }
> +
> + emc->timings = devm_kcalloc(emc->dev, child_count, sizeof(*timing),
> + GFP_KERNEL);
> + if (!emc->timings)
> + return -ENOMEM;
> +
> + emc->num_timings = child_count;
> + timing = emc->timings;
> +
> + for_each_child_of_node(node, child) {
> + err = load_one_timing_from_dt(emc, timing++, child);
> + if (err) {
> + of_node_put(child);
> + return err;
> + }
> + }
> +
> + sort(emc->timings, emc->num_timings, sizeof(*timing), cmp_timings,
> + NULL);
> +
> + return 0;
> +}
> +
> +static struct device_node *
> +tegra_emc_find_node_by_ram_code(struct tegra_emc *emc, u32 ram_code)
> +{
> + struct device_node *np;
> + int err;
> +
> + for_each_child_of_node(emc->dev->of_node, np) {
> + u32 value;
> +
> + err = of_property_read_u32(np, "nvidia,ram-code", &value);
> + if (err || value != ram_code)
> + continue;
> +
> + return np;
> + }
> +
> + dev_info(emc->dev, "no memory timings for RAM code %u found in DT\n",
> + ram_code);
This seems like it should be dev_warn() or perhaps even dev_err() given
that the result of it is the driver failing to probe. dev_info() may go
unnoticed.
> +
> + return NULL;
> +}
> +
> +static int tegra_emc_clk_change_notify(struct notifier_block *nb,
> + unsigned long msg, void *data)
> +{
> + struct tegra_emc *emc = container_of(nb, struct tegra_emc, clk_nb);
> + struct clk_notifier_data *cnd = data;
> + int err;
> +
> + switch (msg) {
> + case PRE_RATE_CHANGE:
> + err = emc_prepare_timing_change(emc, cnd->new_rate);
> + break;
> +
> + case ABORT_RATE_CHANGE:
> + err = emc_prepare_timing_change(emc, cnd->old_rate);
> + if (err)
> + break;
> +
> + err = emc_complete_timing_change(emc, true);
> + break;
> +
> + case POST_RATE_CHANGE:
> + err = emc_complete_timing_change(emc, false);
> + break;
> +
> + default:
> + return NOTIFY_DONE;
> + }
> +
> + return notifier_from_errno(err);
> +}
> +
> +static int emc_setup_hw(struct tegra_emc *emc)
> +{
> + u32 emc_cfg;
> +
> + emc_cfg = readl_relaxed(emc->regs + EMC_CFG_2);
> +
> + /*
> + * Depending on a memory type, DRAM should enter either self-refresh
> + * or power-down state on EMC clock change.
> + */
> + if (!(emc_cfg & EMC_CLKCHANGE_PD_ENABLE) &&
> + !(emc_cfg & EMC_CLKCHANGE_SR_ENABLE))
> + {
> + dev_err(emc->dev,
> + "bootloader didn't specify DRAM auto-suspend mode\n");
> + return -EINVAL;
> + }
> +
> + /* allow EMC and CAR to handshake on PLL divider/source changes */
> + emc_cfg |= EMC_CLKCHANGE_REQ_ENABLE;
> + writel_relaxed(emc_cfg, emc->regs + EMC_CFG_2);
> +
> + /* initialize interrupt */
> + writel_relaxed(EMC_CLKCHANGE_COMPLETE_INT, emc->regs + EMC_INTMASK);
> + writel_relaxed(EMC_CLKCHANGE_COMPLETE_INT, emc->regs + EMC_INTSTATUS);
> +
> + return 0;
> +}
> +
> +static int emc_init(struct tegra_emc *emc, unsigned long rate)
> +{
> + int err;
> +
> + err = clk_set_parent(emc->emc_mux, emc->backup_clk);
> + if (err) {
> + dev_err(emc->dev,
> + "failed to reparent to backup source: %d\n", err);
> + return err;
> + }
> +
> + err = clk_set_rate(emc->pll_m, rate);
> + if (err)
> + dev_err(emc->dev,
> + "failed to change pll_m rate: %d\n", err);
> +
> + err = clk_set_parent(emc->emc_mux, emc->pll_m);
> + if (err) {
> + dev_err(emc->dev,
> + "failed to reparent to pll_m: %d\n", err);
> + return err;
> + }
> +
> + return 0;
> +}
> +
> +static int tegra_emc_probe(struct platform_device *pdev)
> +{
> + struct device_node *np;
> + struct tegra_emc *emc;
> + struct resource *res;
> + u32 ram_code;
> + int err;
> +
> + emc = devm_kzalloc(&pdev->dev, sizeof(*emc), GFP_KERNEL);
> + if (!emc)
> + return -ENOMEM;
> +
> + emc->dev = &pdev->dev;
> +
> + ram_code = tegra_read_ram_code();
> +
> + np = tegra_emc_find_node_by_ram_code(emc, ram_code);
> + if (!np)
> + return -ENOENT;
> +
> + err = tegra_emc_load_timings_from_dt(emc, np);
> + of_node_put(np);
> + if (err)
> + return err;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + emc->regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(emc->regs))
> + return PTR_ERR(emc->regs);
> +
> + err = emc_setup_hw(emc);
> + if (err)
> + return err;
> +
> + emc->irq = platform_get_irq(pdev, 0);
> + if (emc->irq < 0) {
> + dev_warn(&pdev->dev, "interrupt not specified\n");
> + dev_warn(&pdev->dev, "continuing, but please update your DT\n");
Do we really need this? I think this is a case where we don't have to
keep backwards-compatibility because this driver hasn't "worked" in a
very long time (because it was absent). Therefore, if we error out in
the absence of an interrupt we don't break anything.
There's a few places in this driver that are awkward just because the
interrupt isn't mandatory. I don't think it's warranted in this case.
> + } else {
> + init_completion(&emc->clk_handshake_complete);
> +
> + err = devm_request_irq(&pdev->dev, emc->irq, tegra_emc_isr, 0,
> + dev_name(&pdev->dev), emc);
> + if (err < 0) {
> + dev_err(&pdev->dev, "failed to request IRQ#%u: %d\n",
> + emc->irq, err);
> + return err;
> + }
> + }
> +
> + emc->pll_m = clk_get_sys(NULL, "pll_m");
> + if (IS_ERR(emc->pll_m)) {
> + err = PTR_ERR(emc->pll_m);
> + dev_err(&pdev->dev, "failed to get pll_m: %d\n", err);
> + return err;
> + }
> +
> + emc->backup_clk = clk_get_sys(NULL, "pll_p");
> + if (IS_ERR(emc->backup_clk)) {
> + err = PTR_ERR(emc->backup_clk);
> + dev_err(&pdev->dev, "failed to get pll_p: %d\n", err);
> + goto put_pll_m;
> + }
> +
> + emc->clk = clk_get_sys(NULL, "emc");
> + if (IS_ERR(emc->clk)) {
> + err = PTR_ERR(emc->clk);
> + dev_err(&pdev->dev, "failed to get emc: %d\n", err);
> + goto put_backup;
> + }
Instead of using clk_get_sys(), why not specify these in the DT with
proper names for context ("emc", "pll", "backup")? Again, I don't think
we have to worry about backwards-compatibility here since there can be
no regression.
> +
> + emc->emc_mux = clk_get_parent(emc->clk);
> + if (IS_ERR(emc->emc_mux)) {
> + err = PTR_ERR(emc->emc_mux);
> + dev_err(&pdev->dev, "failed to get emc_mux: %d\n", err);
> + goto put_emc;
> + }
> +
> + emc->clk_nb.notifier_call = tegra_emc_clk_change_notify;
> +
> + err = clk_notifier_register(emc->clk, &emc->clk_nb);
> + if (err) {
> + dev_err(&pdev->dev, "failed to register clk notifier: %d\n",
> + err);
> + goto put_emc;
> + }
> +
> + /* set DRAM clock rate to maximum */
> + err = emc_init(emc, emc->timings[emc->num_timings - 1].rate);
> + if (err) {
> + dev_err(&pdev->dev, "failed to initialize clk rate: %d\n",
> + err);
> + goto unreg_notifier;
> + }
> +
> + return 0;
> +
> +unreg_notifier:
> + clk_notifier_unregister(emc->emc_mux, &emc->clk_nb);
> +put_emc:
> + clk_put(emc->clk);
> +put_backup:
> + clk_put(emc->backup_clk);
> +put_pll_m:
> + clk_put(emc->pll_m);
> +
> + return err;
> +}
> +
> +static const struct of_device_id tegra_emc_of_match[] = {
> + { .compatible = "nvidia,tegra20-emc", },
> + {},
> +};
> +
> +static struct platform_driver tegra_emc_driver = {
> + .probe = tegra_emc_probe,
> + .driver = {
> + .name = "tegra20-emc",
> + .of_match_table = tegra_emc_of_match,
> + .suppress_bind_attrs = true,
> + },
> +};
> +
> +static int __init tegra_emc_init(void)
> +{
> + return platform_driver_register(&tegra_emc_driver);
> +}
> +subsys_initcall(tegra_emc_init);
> --
> 2.17.0
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5 6/6] tty/serial: atmel: changed the driver to work under at91-usart mfd
From: Richard Genoud @ 2018-06-06 11:02 UTC (permalink / raw)
To: Radu Pirea, broonie, nicolas.ferre, alexandre.belloni, lee.jones,
richard.genoud, robh+dt, mark.rutland, gregkh
Cc: linux-spi, linux-arm-kernel, linux-kernel, devicetree,
linux-serial
In-Reply-To: <20180604165943.31381-7-radu.pirea@microchip.com>
Typo in the subject:
changed->change
On 04/06/2018 18:59, Radu Pirea wrote:
> This patch modifies the place where resources and device tree properties
> are searched.
>
> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
> ---
> drivers/tty/serial/Kconfig | 1 +
> drivers/tty/serial/atmel_serial.c | 41 ++++++++++++++++++-------------
> 2 files changed, 25 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 3682fd3e960c..25e55332f8b1 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -119,6 +119,7 @@ config SERIAL_ATMEL
> depends on ARCH_AT91 || COMPILE_TEST
> select SERIAL_CORE
> select SERIAL_MCTRL_GPIO if GPIOLIB
> + select MFD_AT91_USART
> help
> This enables the driver for the on-chip UARTs of the Atmel
> AT91 processors.
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index df46a9e88c34..5c74e03396ef 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -193,8 +193,8 @@ static struct console atmel_console;
>
> #if defined(CONFIG_OF)
> static const struct of_device_id atmel_serial_dt_ids[] = {
> - { .compatible = "atmel,at91rm9200-usart" },
> - { .compatible = "atmel,at91sam9260-usart" },
> + { .compatible = "atmel,at91rm9200-usart-serial" },
> + { .compatible = "atmel,at91sam9260-usart-serial" },
Sorry, I didn't catch that before, but we can drop "atmel,at91sam9260-usart-serial" don't we ?
Only "atmel,at91rm9200-usart-serial" is used in the MFD driver.
> { /* sentinel */ }
> };
> #endif
> @@ -915,6 +915,7 @@ static void atmel_tx_dma(struct uart_port *port)
> static int atmel_prepare_tx_dma(struct uart_port *port)
> {
> struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> + struct device *mfd_dev = port->dev->parent;
> dma_cap_mask_t mask;
> struct dma_slave_config config;
> int ret, nent;
> @@ -922,7 +923,7 @@ static int atmel_prepare_tx_dma(struct uart_port *port)
> dma_cap_zero(mask);
> dma_cap_set(DMA_SLAVE, mask);
>
> - atmel_port->chan_tx = dma_request_slave_channel(port->dev, "tx");
> + atmel_port->chan_tx = dma_request_slave_channel(mfd_dev, "tx");
> if (atmel_port->chan_tx == NULL)
> goto chan_err;
> dev_info(port->dev, "using %s for tx DMA transfers\n",
> @@ -1093,6 +1094,7 @@ static void atmel_rx_from_dma(struct uart_port *port)
> static int atmel_prepare_rx_dma(struct uart_port *port)
> {
> struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> + struct device *mfd_dev = port->dev->parent;
> struct dma_async_tx_descriptor *desc;
> dma_cap_mask_t mask;
> struct dma_slave_config config;
> @@ -1104,7 +1106,7 @@ static int atmel_prepare_rx_dma(struct uart_port *port)
> dma_cap_zero(mask);
> dma_cap_set(DMA_CYCLIC, mask);
>
> - atmel_port->chan_rx = dma_request_slave_channel(port->dev, "rx");
> + atmel_port->chan_rx = dma_request_slave_channel(mfd_dev, "rx");
> if (atmel_port->chan_rx == NULL)
> goto chan_err;
> dev_info(port->dev, "using %s for rx DMA transfers\n",
> @@ -1631,7 +1633,7 @@ static void atmel_tasklet_tx_func(unsigned long data)
> static void atmel_init_property(struct atmel_uart_port *atmel_port,
> struct platform_device *pdev)
> {
> - struct device_node *np = pdev->dev.of_node;
> + struct device_node *np = pdev->dev.parent->of_node;
I think this is not needed anymore (cf atmel_probe())
>
> /* DMA/PDC usage specification */
> if (of_property_read_bool(np, "atmel,use-dma-rx")) {
> @@ -2222,8 +2224,8 @@ static const char *atmel_type(struct uart_port *port)
> */
> static void atmel_release_port(struct uart_port *port)
> {
> - struct platform_device *pdev = to_platform_device(port->dev);
> - int size = pdev->resource[0].end - pdev->resource[0].start + 1;
> + struct platform_device *mpdev = to_platform_device(port->dev->parent);
> + int size = resource_size(mpdev->resource);
>
> release_mem_region(port->mapbase, size);
>
> @@ -2238,8 +2240,8 @@ static void atmel_release_port(struct uart_port *port)
> */
> static int atmel_request_port(struct uart_port *port)
> {
> - struct platform_device *pdev = to_platform_device(port->dev);
> - int size = pdev->resource[0].end - pdev->resource[0].start + 1;
> + struct platform_device *mpdev = to_platform_device(port->dev->parent);
> + int size = resource_size(mpdev->resource);
>
> if (!request_mem_region(port->mapbase, size, "atmel_serial"))
> return -EBUSY;
> @@ -2341,27 +2343,28 @@ static int atmel_init_port(struct atmel_uart_port *atmel_port,
> {
> int ret;
> struct uart_port *port = &atmel_port->uart;
> + struct platform_device *mpdev = to_platform_device(pdev->dev.parent);
>
> atmel_init_property(atmel_port, pdev);
> atmel_set_ops(port);
>
> - uart_get_rs485_mode(&pdev->dev, &port->rs485);
> + uart_get_rs485_mode(&mpdev->dev, &port->rs485);
>
> port->iotype = UPIO_MEM;
> port->flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP;
> port->ops = &atmel_pops;
> port->fifosize = 1;
> port->dev = &pdev->dev;
> - port->mapbase = pdev->resource[0].start;
> - port->irq = pdev->resource[1].start;
> + port->mapbase = mpdev->resource[0].start;
> + port->irq = mpdev->resource[1].start;
> port->rs485_config = atmel_config_rs485;
> - port->membase = NULL;
> + port->membase = NULL;
>
> memset(&atmel_port->rx_ring, 0, sizeof(atmel_port->rx_ring));
>
> /* for console, the clock could already be configured */
> if (!atmel_port->clk) {
> - atmel_port->clk = clk_get(&pdev->dev, "usart");
> + atmel_port->clk = clk_get(&mpdev->dev, "usart");
> if (IS_ERR(atmel_port->clk)) {
> ret = PTR_ERR(atmel_port->clk);
> atmel_port->clk = NULL;
> @@ -2652,11 +2655,13 @@ static int atmel_serial_resume(struct platform_device *pdev)
> static void atmel_serial_probe_fifos(struct atmel_uart_port *atmel_port,
> struct platform_device *pdev)
> {
> + struct device *dev = pdev->dev.parent;
> +
Ditto
> atmel_port->fifo_size = 0;
> atmel_port->rts_low = 0;
> atmel_port->rts_high = 0;
>
> - if (of_property_read_u32(pdev->dev.of_node,
> + if (of_property_read_u32(dev->of_node,
Ditto
> "atmel,fifo-size",
> &atmel_port->fifo_size))
> return;
> @@ -2694,13 +2699,15 @@ static void atmel_serial_probe_fifos(struct atmel_uart_port *atmel_port,
> static int atmel_serial_probe(struct platform_device *pdev)
> {
> struct atmel_uart_port *atmel_port;
> - struct device_node *np = pdev->dev.of_node;
> + struct device_node *np = pdev->dev.parent->of_node;
> void *data;
> int ret = -ENODEV;
> bool rs485_enabled;
>
> BUILD_BUG_ON(ATMEL_SERIAL_RINGSIZE & (ATMEL_SERIAL_RINGSIZE - 1));
>
> + pdev->dev.of_node = np;
> +
As atmel_serial device's of_node is now the parent node, the changes
in atmel_init_property() and atmel_serial_probe_fifos() are not needed anymore.
And maybe add a comment to explain that this is part of a MFD and all
the attributes are in the parent node, so we're using the MFD device node
instead of this device node.
> ret = of_alias_get_id(np, "serial");
> if (ret < 0)
> /* port id not found in platform data nor device-tree aliases:
> @@ -2845,7 +2852,7 @@ static struct platform_driver atmel_serial_driver = {
> .suspend = atmel_serial_suspend,
> .resume = atmel_serial_resume,
> .driver = {
> - .name = "atmel_usart",
> + .name = "atmel_usart_serial",
> .of_match_table = of_match_ptr(atmel_serial_dt_ids),
> },
> };
>
Thanks !
Richard.
^ permalink raw reply
* Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
From: Heiko Stübner @ 2018-06-06 10:46 UTC (permalink / raw)
To: Archit Taneja
Cc: devicetree, boris.brezillon, linux-arm-msm, tomi.valkeinen,
briannorris, philippe.cornu, dri-devel, nickey.yang, robh+dt,
thierry.reding, laurent.pinchart, maxime.ripard
In-Reply-To: <fc1dfb22-efda-77b7-5f2f-fa188f6e4471@codeaurora.org>
Hi Archit,
Am Mittwoch, 6. Juni 2018, 12:21:16 CEST schrieb Archit Taneja:
> On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote:
> > Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja:
> >> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:
> >>> Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:
> >>>> Add binding info for peripherals that support dual-channel DSI. Add
> >>>> corresponding optional bindings for DSI host controllers that may
> >>>> be configured in this mode. Add an example of an I2C controlled
> >>>> device operating in dual-channel DSI mode.
> >>>>
> >>>> Signed-off-by: Archit Taneja <architt@codeaurora.org>
> >>>
> >>> Looks like a great solution for that problem, so
> >>> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> >>>
> >>> As I'm looking into that for my rk3399-scarlet device right now and
> >>> couldn't find this patchset in the kernel yet, is it planned to
> >>> merge or refresh these binding changes or were problems encountered.
> >>>
> >>> At least an Ack/Review from Rob seems to be missing.
> >>
> >> I forgot about these patches. Rob had reviewed the first one in
> >> the set the second one still needed an Ack. I'll post a v3
> >> that adds the Reviewed-bys and fixes a small typo.
> >
> > very nice ... because it looks like yesterday I managed to make the
> > Rockchip dsi work in dual mode following this.
> >
> > But one question came up, do you really want two input ports on the panel
> > side? I.e. hardware-wise, I guess the panel will have one 8-lane or so
> > input thatonly gets split up on the soc side onto 2 dsi controllers?
>
> I think all dual DSI panels actually have 2 DSI controllers/parsers
> within them, one on each port. The MIPI DSI spec doesn't support 8
> lanes. Also, the pixels coming out of the host are distributed among
> the lanes differently than what would have been the case with a
> 'theoretical' 8 lane receiver.
>
> Other than that, some dual DSI panels only accept DSI commands on the
> 'master' port, where as others expect the same command to be sent across
> both the ports.
>
> Therefore, I think it's better to represent dual DSI panels having 2
> DSI input ports.
>
> Your DT looks good to me.
Hmm, that doesn't match up then ;-) ... as my dt uses 2 endpoints
in one port for the dsi-links.
The issue I see with using ports and not endpoints for dual-dsi links
is with distinguishing between input and output ports.
For a panel that's easy, as you every port will be an input port and if
you have 2, it's supposed dual-dsi. But for example I guess there might
exist some dual-dsi-to-something bridges, where you would end up
with say 3 (or even more) ports ... two dual-dsi inputs and 1 or more
outputs.
While the following argument might not be 100% valid from a dt-purity
standpoint implementing this might get hairy for _any_ operating system,
as you will need each panel/bridge to tell what the ports are used for.
I.e. in my endpoint based mapping, right now I have this nice and generic
WIP function to parse the of_graph and get the master+slave nodes:
https://github.com/mmind/linux-rockchip/blob/tmp/rk3399-gru-bob-scarlet/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c#L697
[0]
So I guess my proposal would be to have one port for inputs
and one port for outputs for dsi peripherals, with possibly
multiple endpoints in each.
Heiko
[0] github seems to have reliability problems, so for reference my
parsing function:
static int dw_mipi_dsi_is_dual(struct dw_mipi_dsi_rockchip *dsi,
struct device_node **master, struct device_node **slave)
{
struct device_node *local_ep, *remote_port, *ep;
struct device_node *ctrls[2] = { NULL, NULL };
int num = 0, ret = 0, idx;
/* get local panel endpoint of the dsi controller */
local_ep = of_graph_get_endpoint_by_regs(dsi->dev->of_node, 1, 0);
if (!local_ep) {
DRM_DEV_ERROR(dsi->dev, "couldn't find local panel endpoint\n");
return -ENXIO;
}
/* get panel port */
remote_port = of_graph_get_remote_port_parent(local_ep);
of_node_put(local_ep);
if (!remote_port) {
DRM_DEV_ERROR(dsi->dev, "couldn't find panel port\n");
return -ENXIO;
}
/* check other endpoints */
for_each_endpoint_of_node(remote_port, ep) {
struct device_node *np = of_graph_get_remote_port_parent(ep);
if (!np)
continue;
idx = of_property_read_bool(np, "clock-master");
/*
* Either master or slave already defined, drop refcnt
* but catch errors only after the full loop.
*/
if (ctrls[idx])
of_node_put(np);
else
ctrls[idx] = np;
num++;
}
of_node_put(remote_port);
if (num > 2) {
DRM_DEV_ERROR(dsi->dev, "too many dsi devices linked\n");
ret = -EINVAL;
goto cleanup;
}
/* nothing to do */
if (num < 1) {
ret = 0;
goto cleanup;
}
if (!ctrls[1]) {
DRM_DEV_ERROR(dsi->dev, "no master defined in dual-dsi\n");
ret = -ENODEV;
goto cleanup;
}
if (!ctrls[0]) {
DRM_DEV_ERROR(dsi->dev, "no slave defined in dual-dsi\n");
ret = -ENODEV;
goto cleanup;
}
*master = ctrls[1];
*slave = ctrls[0];
return 1;
cleanup:
for (idx = 0; idx < 2; idx++)
if (ctrls[idx])
of_node_put(ctrls[idx]);
return ret;
}
> > So right now I'm operating with a devicetree like
> >
> > &mipi_dsi {
> >
> > status = "okay";
> > clock-master;
> >
> > ports {
> >
> > mipi_out: port@1 {
> >
> > reg = <1>;
> >
> > mipi_out_panel: endpoint {
> >
> > remote-endpoint = <&mipi_in_panel>;
> >
> > };
> >
> > };
> >
> > };
> >
> > mipi_panel: panel@0 {
> >
> > compatible = "innolux,p097pfg";
> >
> > reg = <0>;
> > backlight = <&backlight>;
> > enable-gpios = <&gpio4 25 GPIO_ACTIVE_HIGH>;
> > pinctrl-names = "default";
> > pinctrl-0 = <&display_rst_l>;
> >
> > port {
> >
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > mipi_in_panel: endpoint@0 {
> >
> > reg = <0>;
> > remote-endpoint = <&mipi_out_panel>;
> >
> > };
> >
> > mipi1_in_panel: endpoint@1 {
> >
> > reg = <1>;
> > remote-endpoint = <&mipi1_out_panel>;
> >
> > };
> >
> > };
> >
> > };
> >
> > };
> >
> > &mipi_dsi1 {
> >
> > status = "okay";
> >
> > ports {
> >
> > mipi1_out: port@1 {
> >
> > reg = <1>;
> >
> > mipi1_out_panel: endpoint {
> >
> > remote-endpoint = <&mipi1_in_panel>;
> >
> > };
> >
> > };
> >
> > };
> >
> > };
> >
> >
> > I guess it is a matter of preference on what reflects the hardware
> > best, so maybe that's Robs call?
> >
> >
> > Heiko
> >
> >>>> ---
> >>>> v2:
> >>>> - Specify that clock-master is a boolean property.
> >>>> - Drop/add unit-address and #*-cells where applicable.
> >>>>
> >>>> .../devicetree/bindings/display/mipi-dsi-bus.txt | 80
> >>>> ++++++++++++++++++++++ 1 file changed, 80 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> >>>> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt index
> >>>> 94fb72cb916f..7a3abbedb3fa 100644
> >>>> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> >>>> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> >>>>
> >>>> @@ -29,6 +29,13 @@ Required properties:
> >>>> - #size-cells: Should be 0. There are cases where it makes sense to
> >>>> use
> >>>> a
> >>>>
> >>>> different value here. See below.
> >>>>
> >>>> +Optional properties:
> >>>> +- clock-master: boolean. Should be enabled if the host is being used
> >>>> in
> >>>> + conjunction with another DSI host to drive the same peripheral.
> >>>> Hardware
> >>>> + supporting such a configuration generally requires the data on both
> >>>> the busses + to be driven by the same clock. Only the DSI host
> >>>> instance
> >>>> controlling this + clock should contain this property.
> >>>> +
> >>>>
> >>>> DSI peripheral
> >>>> ==============
> >>>>
> >>>> @@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI
> >>>> bus (mostly for the data>>
> >>>>
> >>>> path). Connections between such peripherals and a DSI host can be
> >>>> represented using the graph bindings [1], [2].
> >>>>
> >>>> +Peripherals that support dual channel DSI
> >>>> +-----------------------------------------
> >>>> +
> >>>> +Peripherals with higher bandwidth requirements can be connected to 2
> >>>> DSI
> >>>> +busses. Each DSI bus/channel drives some portion of the pixel data
> >>>> (generally +left/right half of each line of the display, or even/odd
> >>>> lines of the display). +The graph bindings should be used to represent
> >>>> the multiple DSI busses that are +connected to this peripheral. Each
> >>>> DSI
> >>>> host's output endpoint can be linked to +an input endpoint of the DSI
> >>>> peripheral.
> >>>> +
> >>>>
> >>>> [1] Documentation/devicetree/bindings/graph.txt
> >>>> [2] Documentation/devicetree/bindings/media/video-interfaces.txt
> >>>>
> >>>> @@ -71,6 +88,8 @@ Examples
> >>>>
> >>>> with different virtual channel configurations.
> >>>>
> >>>> - (4) is an example of a peripheral on a I2C control bus connected
> >>>> with
> >>>> to
> >>>>
> >>>> a DSI host using of-graph bindings.
> >>>>
> >>>> +- (5) is an example of 2 DSI hosts driving a dual-channel DSI
> >>>> peripheral,
> >>>> + which uses I2C as its primary control bus.
> >>>>
> >>>> 1)
> >>>>
> >>>> dsi-host {
> >>>>
> >>>> @@ -153,3 +172,64 @@ Examples
> >>>>
> >>>> };
> >>>>
> >>>> };
> >>>>
> >>>> };
> >>>>
> >>>> +
> >>>> +5)
> >>>> + i2c-host {
> >>>> + dsi-bridge@35 {
> >>>> + compatible = "...";
> >>>> + reg = <0x35>;
> >>>> +
> >>>> + ports {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> +
> >>>> + port@0 {
> >>>> + reg = <0>;
> >>>> + dsi0_in: endpoint {
> >>>> + remote-endpoint = <&dsi0_out>;
> >>>> + };
> >>>> + };
> >>>> +
> >>>> + port@1 {
> >>>> + reg = <1>;
> >>>> + dsi1_in: endpoint {
> >>>> + remote-endpoint = <&dsi1_out>;
> >>>> + };
> >>>> + };
> >>>> + };
> >>>> + };
> >>>> + };
> >>>> +
> >>>> + dsi0-host {
> >>>> + ...
> >>>> +
> >>>> + /*
> >>>> + * this DSI instance drives the clock for both the host
> >>>> + * controllers
> >>>> + */
> >>>> + clock-master;
> >>>> +
> >>>> + ports {
> >>>> + ...
> >>>> +
> >>>> + port {
> >>>> + dsi0_out: endpoint {
> >>>> + remote-endpoint = <&dsi0_in>;
> >>>> + };
> >>>> + };
> >>>> + };
> >>>> + };
> >>>> +
> >>>> + dsi1-host {
> >>>> + ...
> >>>> +
> >>>> + ports {
> >>>> + ...
> >>>> +
> >>>> + port {
> >>>> + dsi1_out: endpoint {
> >>>> + remote-endpoint = <&dsi1_in>;
> >>>> + };
> >>>> + };
> >>>> + };
> >>>> + };
> >>>
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm"
> >>> in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 0/5] Tegra20 External Memory Controller driver
From: Thierry Reding @ 2018-06-06 10:45 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Peter De Schrijver, Jonathan Hunter, Prashant Gaikwad,
Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
linux-tegra, linux-clk, devicetree, linux-kernel
In-Reply-To: <20180603223654.23324-1-digetx@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]
On Mon, Jun 04, 2018 at 01:36:49AM +0300, Dmitry Osipenko wrote:
> Hello,
>
> Couple years ago the Tegra20 EMC driver was removed from the kernel
> due to incompatible changes in the Tegra's clock driver. This patchset
> introduces a modernized EMC driver. Currently the sole purpose of the
> driver is to initialize DRAM frequency to maximum rate during of the
> kernels boot-up. Later we may consider implementing dynamic memory
> frequency scaling, utilizing functionality provided by this driver.
>
> Changelog:
>
> v2:
> - Minor code cleanups like consistent use of writel_relaxed instead
> of non-relaxed version, reworded error messages, etc.
>
> - Factored out use_pllm_ud bit checking into a standalone patch for
> consistency.
>
> Dmitry Osipenko (5):
> dt: bindings: tegra20-emc: Document interrupt property
> ARM: dts: tegra20: Add interrupt to External Memory Controller
> clk: tegra20: Turn EMC clock gate into divider
> clk: tegra20: Check whether direct PLLM sourcing is turned off for EMC
> memory: tegra: Introduce Tegra20 EMC driver
I took a brief look and didn't spot any dependencies between the clk and
memory patches. Is it correct that these can be applied separately?
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/6] mtd: rawnand: tegra: add devicetree binding
From: Boris Brezillon @ 2018-06-06 10:45 UTC (permalink / raw)
To: Thierry Reding
Cc: Dmitry Osipenko, Stefan Agner, dwmw2, computersforpeace,
marek.vasut, robh+dt, mark.rutland, benjamin.lindqvist, pgaikwad,
dev, mirza.krak, richard, pdeschrijver, linux-kernel, krzk,
jonathanh, devicetree, linux-mtd, marcel, miquel.raynal,
linux-tegra
In-Reply-To: <20180606103903.GJ11810@ulmo>
Hi Thierry,
On Wed, 6 Jun 2018 12:39:03 +0200
Thierry Reding <thierry.reding@gmail.com> wrote:
> On Tue, Jun 05, 2018 at 11:19:14PM +0300, Dmitry Osipenko wrote:
> > On 01.06.2018 10:30, Boris Brezillon wrote:
> > > On Fri, 1 Jun 2018 00:16:34 +0200
> > > Stefan Agner <stefan@agner.ch> wrote:
> > >
> > >> This adds the devicetree binding for the Tegra 2 NAND flash
> > >> controller.
> > >>
> > >> Signed-off-by: Lucas Stach <dev@lynxeye.de>
> > >> Signed-off-by: Stefan Agner <stefan@agner.ch>
> > >> ---
> > >> .../bindings/mtd/nvidia-tegra20-nand.txt | 64 +++++++++++++++++++
> > >> 1 file changed, 64 insertions(+)
> > >> create mode 100644 Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
> > >>
> > >> diff --git a/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
> > >> new file mode 100644
> > >> index 000000000000..5cd984ef046b
> > >> --- /dev/null
> > >> +++ b/Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt
> > >> @@ -0,0 +1,64 @@
> > >> +NVIDIA Tegra NAND Flash controller
> > >> +
> > >> +Required properties:
> > >> +- compatible: Must be one of:
> > >> + - "nvidia,tegra20-nand"
> > >
> > > As discussed previously, I prefer "nvidia,tegra20-nand-controller" or
> > > "nvidia,tegra20-nfc".
> > >
> > >> +- reg: MMIO address range
> > >> +- interrupts: interrupt output of the NFC controller
> > >> +- clocks: Must contain an entry for each entry in clock-names.
> > >> + See ../clocks/clock-bindings.txt for details.
> > >> +- clock-names: Must include the following entries:
> > >> + - nand
> > >> +- resets: Must contain an entry for each entry in reset-names.
> > >> + See ../reset/reset.txt for details.
> > >> +- reset-names: Must include the following entries:
> > >> + - nand
> > >> +
> > >> +Optional children nodes:
> > >> +Individual NAND chips are children of the NAND controller node. Currently
> > >> +only one NAND chip supported.
> > >> +
> > >> +Required children node properties:
> > >> +- reg: An integer ranging from 1 to 6 representing the CS line to use.
> > >> +
> > >> +Optional children node properties:
> > >> +- nand-ecc-mode: String, operation mode of the NAND ecc mode. Currently only
> > >> + "hw" is supported.
> > >> +- nand-ecc-algo: string, algorithm of NAND ECC.
> > >> + Supported values with "hw" ECC mode are: "rs", "bch".
> > >> +- nand-bus-width : See nand.txt
> > >> +- nand-on-flash-bbt: See nand.txt
> > >> +- nand-ecc-strength: integer representing the number of bits to correct
> > >> + per ECC step (always 512). Supported strength using HW ECC
> > >> + modes are:
> > >> + - RS: 4, 6, 8
> > >> + - BCH: 4, 8, 14, 16
> > >> +- nand-ecc-maximize: See nand.txt
> > >> +- nand-is-boot-medium: Makes sure only ECC strengths supported by the boot ROM
> > >> + are choosen.
> > >> +- wp-gpios: GPIO specifier for the write protect pin.
> > >> +
> > >> +Optional child node of NAND chip nodes:
> > >> +Partitions: see partition.txt
> > >> +
> > >> + Example:
> > >> + nand@70008000 {
> > >
> > > nand-controller@70008000 {
> > >
> > >> + compatible = "nvidia,tegra20-nand";
> > >
> > > compatible = "nvidia,tegra20-nand-controller";
> > >
> > > or
> > >
> > > compatible = "nvidia,tegra20-nfc";
> > >
> >
> > Maybe it's just me, but when I'm reading "nfc", my first association is the
> > "Near Field Communication". Probably an explicit
> > "nvidia,tegra20-nand-controller" variant is more preferable.
I also prefer nvidia,tegra20-nand-controller.
>
> We don't really use a -controller suffix for any of the other
> controllers because it is kind of implied. "nfc" is also not something
> that is ever referred to in the technical documentation.
>
> "nvidia,tegra20-nand" would be most consistent with all the rest of
> Tegra (c.f. "nvidia,tegra*-ahci", "nvidia,tegra*-pci",
> "nvidia,tegra*-hda", "nvidia,tegra*-gmi", ...).
People get confused about what this node represents when you just have
"nvidia,tegra20-nand", and then you start seeing NAND related props or
partition nodes being defined under the NAND controller node.
I really prefer to have the "-controller" prefix here to avoid such
confusions.
Regards,
Boris
^ 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