Devicetree
 help / color / mirror / Atom feed
* [PATCH v2 4/4] arm64: dts: ti: k3-j721e-common-proc-board: Add IPC sub-mailbox nodes
From: Suman Anna @ 2019-07-25  0:10 UTC (permalink / raw)
  To: Tero Kristo, Nishanth Menon; +Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190725001020.23781-1-s-anna@ti.com>

Add the sub-mailbox nodes that are used to communicate between MPU and
various remote processors present in the J721E SoCs to the J721E common
processor board. These include the R5F remote processors in the dual-R5F
cluster (MCU_R5FSS0) in the MCU domain and the two dual-R5F clusters
(MAIN_R5FSS0 & MAIN_R5FSS1) in the MAIN domain; the two C66x DSP remote
processors and the single C71x DSP remote processor in the MAIN domain.
These sub-mailbox nodes utilize the System Mailbox clusters 0 through 4.
All the remaining mailbox clusters are currently not used on A72 core,
and so are disabled.

The sub-mailbox nodes added match the hard-coded mailbox configuration
used within the TI RTOS IPC software packages. The R5F processor
sub-systems are assumed to be running in Split mode, so a sub-mailbox
node is used by each of the R5F cores. Only the sub-mailbox node for
the first R5F core in each cluster is used in case of a Lockstep mode
for that R5F cluster.

NOTE:
The GIC_SPI interrupts to be used are dynamically allocated and managed
by the System Firmware through the ti-sci-intr irqchip driver. So, only
valid interrupts (each cluster's User 0 IRQ output) that are used by the
sub-mailbox devices are enabled. This is done to minimize the number of
NavSS Interrupt Router outputs utilized.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2:
 - Sub-mailboxes added in board dts file instead of base dtsi file
 - Unused mailbox clusters 5 through 11 disabled
 - Patch description and title updated
v1: https://patchwork.kernel.org/patch/11053409/

 .../dts/ti/k3-j721e-common-proc-board.dts     | 93 +++++++++++++++++++
 1 file changed, 93 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
index c680123f067c..93ae1d49dcc1 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
@@ -48,3 +48,96 @@
 	/* UART not brought out */
 	status = "disabled";
 };
+
+&mailbox0_cluster0 {
+	interrupts = <214 0>;
+
+	mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 {
+		ti,mbox-rx = <0 0 0>;
+		ti,mbox-tx = <1 0 0>;
+	};
+
+	mbox_mcu_r5fss0_core1: mbox-mcu-r5fss0-core1 {
+		ti,mbox-rx = <2 0 0>;
+		ti,mbox-tx = <3 0 0>;
+	};
+};
+
+&mailbox0_cluster1 {
+	interrupts = <215 0>;
+
+	mbox_main_r5fss0_core0: mbox-main-r5fss0-core0 {
+		ti,mbox-rx = <0 0 0>;
+		ti,mbox-tx = <1 0 0>;
+	};
+
+	mbox_main_r5fss0_core1: mbox-main-r5fss0-core1 {
+		ti,mbox-rx = <2 0 0>;
+		ti,mbox-tx = <3 0 0>;
+	};
+};
+
+&mailbox0_cluster2 {
+	interrupts = <216 0>;
+
+	mbox_main_r5fss1_core0: mbox-main-r5fss1-core0 {
+		ti,mbox-rx = <0 0 0>;
+		ti,mbox-tx = <1 0 0>;
+	};
+
+	mbox_main_r5fss1_core1: mbox-main-r5fss1-core1 {
+		ti,mbox-rx = <2 0 0>;
+		ti,mbox-tx = <3 0 0>;
+	};
+};
+
+&mailbox0_cluster3 {
+	interrupts = <217 0>;
+
+	mbox_c66_0: mbox-c66-0 {
+		ti,mbox-rx = <0 0 0>;
+		ti,mbox-tx = <1 0 0>;
+	};
+
+	mbox_c66_1: mbox-c66-1 {
+		ti,mbox-rx = <2 0 0>;
+		ti,mbox-tx = <3 0 0>;
+	};
+};
+
+&mailbox0_cluster4 {
+	interrupts = <218 0>;
+
+	mbox_c71_0: mbox-c71-0 {
+		ti,mbox-rx = <0 0 0>;
+		ti,mbox-tx = <1 0 0>;
+	};
+};
+
+&mailbox0_cluster5 {
+	status = "disabled";
+};
+
+&mailbox0_cluster6 {
+	status = "disabled";
+};
+
+&mailbox0_cluster7 {
+	status = "disabled";
+};
+
+&mailbox0_cluster8 {
+	status = "disabled";
+};
+
+&mailbox0_cluster9 {
+	status = "disabled";
+};
+
+&mailbox0_cluster10 {
+	status = "disabled";
+};
+
+&mailbox0_cluster11 {
+	status = "disabled";
+};
-- 
2.22.0

^ permalink raw reply related

* [PATCH v2 3/4] arm64: dts: ti: k3-j721e-main: Add mailbox cluster nodes
From: Suman Anna @ 2019-07-25  0:10 UTC (permalink / raw)
  To: Tero Kristo, Nishanth Menon; +Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190725001020.23781-1-s-anna@ti.com>

The J721E Main NavSS block contains a Mailbox IP instance with
multiple clusters. Each cluster is equivalent to an Mailbox IP
instance on OMAP platforms.

Add all the Mailbox clusters as their own nodes under the MAIN
NavSS cbass_main_navss interconnect node instead of creating an
almost empty parent node for the new K3 mailbox IP and the clusters
as its child nodes. All these nodes are enabled by default in the
base dtsi file, but any cluster that does not define any child
sub-mailbox nodes should be disabled in the corresponding board
dts files.

NOTE:
The NavSS only has a limited number of interrupts, so none of the
interrupts generated by a Mailbox IP are added by default. Only
the needed interrupts that are targeted towards the A72 GIC will
have to be added later on in the board dts files alongside the
corresponding sub-mailbox child nodes.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2:
 - Add interrupt-parent property and enable all clusters by default
 - Patch description revised accordingly
v1: https://patchwork.kernel.org/patch/11053407/

 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 108 ++++++++++++++++++++++
 1 file changed, 108 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index a2e031f7d88e..2f86c92b2b74 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -95,6 +95,114 @@
 			reg = <0x00 0x30e00000 0x00 0x1000>;
 			#hwlock-cells = <1>;
 		};
+
+		mailbox0_cluster0: mailbox@31f80000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f80000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&main_navss_intr>;
+		};
+
+		mailbox0_cluster1: mailbox@31f81000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f81000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&main_navss_intr>;
+		};
+
+		mailbox0_cluster2: mailbox@31f82000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f82000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&main_navss_intr>;
+		};
+
+		mailbox0_cluster3: mailbox@31f83000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f83000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&main_navss_intr>;
+		};
+
+		mailbox0_cluster4: mailbox@31f84000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f84000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&main_navss_intr>;
+		};
+
+		mailbox0_cluster5: mailbox@31f85000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f85000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&main_navss_intr>;
+		};
+
+		mailbox0_cluster6: mailbox@31f86000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f86000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&main_navss_intr>;
+		};
+
+		mailbox0_cluster7: mailbox@31f87000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f87000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&main_navss_intr>;
+		};
+
+		mailbox0_cluster8: mailbox@31f88000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f88000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&main_navss_intr>;
+		};
+
+		mailbox0_cluster9: mailbox@31f89000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f89000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&main_navss_intr>;
+		};
+
+		mailbox0_cluster10: mailbox@31f8a000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f8a000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&main_navss_intr>;
+		};
+
+		mailbox0_cluster11: mailbox@31f8b000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f8b000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&main_navss_intr>;
+		};
 	};
 
 	secure_proxy_main: mailbox@32c00000 {
-- 
2.22.0

^ permalink raw reply related

* [PATCH v2 2/4] arm64: dts: ti: k3-am65-base-board: Add IPC sub-mailbox nodes for R5Fs
From: Suman Anna @ 2019-07-25  0:10 UTC (permalink / raw)
  To: Tero Kristo, Nishanth Menon; +Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190725001020.23781-1-s-anna@ti.com>

Add the sub-mailbox nodes that are used to communicate between MPU and
the two R5F remote processors present in the MCU domain to the AM654
EVM base board. These sub-mailbox nodes utilize the System Mailbox
clusters 0 and 1. The interrupts associated with the Mailbox Cluster
User interrupt used by the sub-mailbox nodes are also added. The GIC_SPI
interrupt to be used is dynamically allocated and managed by the System
Firmware through the ti-sci-intr irqchip driver. All the remaining
mailbox clusters are currently not used on A53 core, and so are disabled.

The sub-mailbox nodes added match the hard-coded mailbox configuration
used within the TI RTOS IPC software packages. The Cortex R5F processor
sub-system is assumed to be running in Split mode, so a sub-mailbox node
is used by each of the R5F cores. Only the sub-mailbox node from cluster 0
is used in case of Lockstep mode.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2:
 - Sub-mailboxes added in board dts file instead of base dtsi file
 - Unused mailbox clusters 2 through 11 disabled
 - Patch description and title updated
v1: https://patchwork.kernel.org/patch/11053405/

 .../arm64/boot/dts/ti/k3-am654-base-board.dts | 58 +++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index 52c245d36db9..579b7a474f35 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -279,3 +279,61 @@
 &pcie1_ep {
 	status = "disabled";
 };
+
+&mailbox0_cluster0 {
+	interrupts = <164 0>;
+
+	mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 {
+		ti,mbox-tx = <1 0 0>;
+		ti,mbox-rx = <0 0 0>;
+	};
+};
+
+&mailbox0_cluster1 {
+	interrupts = <165 0>;
+
+	mbox_mcu_r5fss0_core1: mbox-mcu-r5fss0-core1 {
+		ti,mbox-tx = <1 0 0>;
+		ti,mbox-rx = <0 0 0>;
+	};
+};
+
+&mailbox0_cluster2 {
+	status = "disabled";
+};
+
+&mailbox0_cluster3 {
+	status = "disabled";
+};
+
+&mailbox0_cluster4 {
+	status = "disabled";
+};
+
+&mailbox0_cluster5 {
+	status = "disabled";
+};
+
+&mailbox0_cluster6 {
+	status = "disabled";
+};
+
+&mailbox0_cluster7 {
+	status = "disabled";
+};
+
+&mailbox0_cluster8 {
+	status = "disabled";
+};
+
+&mailbox0_cluster9 {
+	status = "disabled";
+};
+
+&mailbox0_cluster10 {
+	status = "disabled";
+};
+
+&mailbox0_cluster11 {
+	status = "disabled";
+};
-- 
2.22.0

^ permalink raw reply related

* [PATCH v2 1/4] arm64: dts: ti: k3-am65-main: Add mailbox cluster nodes
From: Suman Anna @ 2019-07-25  0:10 UTC (permalink / raw)
  To: Tero Kristo, Nishanth Menon; +Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190725001020.23781-1-s-anna@ti.com>

The AM65x Main NavSS block contains a Mailbox IP instance with
multiple clusters. Each cluster is equivalent to an Mailbox IP
instance on OMAP platforms.

Add all the Mailbox clusters as their own nodes under the MAIN
NavSS cbass_main_navss interconnect node instead of creating an
almost empty parent node for the new K3 mailbox IP and the clusters
as its child nodes. All these nodes are enabled by default in the
base dtsi file, but any cluster that does not define any child
sub-mailbox nodes should be disabled in the corresponding board
dts files.

NOTE:
The NavSS only has a limited number of interrupts, so none of the
interrupts generated by a Mailbox IP are added by default. Only
the needed interrupts that are targeted towards the A53 GIC will
have to be added later on in the board dts files alongside the
corresponding sub-mailbox child nodes.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2:
 - Add interrupt-parent property and enable all clusters by default
 - Patch description revised accordingly
v1: https://patchwork.kernel.org/patch/11053403/

 arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 108 +++++++++++++++++++++++
 1 file changed, 108 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 8413e80f9d3a..24c66f09e899 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -419,6 +419,114 @@
 			reg = <0x00 0x30e00000 0x00 0x1000>;
 			#hwlock-cells = <1>;
 		};
+
+		mailbox0_cluster0: mailbox@31f80000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f80000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&intr_main_navss>;
+		};
+
+		mailbox0_cluster1: mailbox@31f81000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f81000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&intr_main_navss>;
+		};
+
+		mailbox0_cluster2: mailbox@31f82000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f82000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&intr_main_navss>;
+		};
+
+		mailbox0_cluster3: mailbox@31f83000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f83000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&intr_main_navss>;
+		};
+
+		mailbox0_cluster4: mailbox@31f84000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f84000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&intr_main_navss>;
+		};
+
+		mailbox0_cluster5: mailbox@31f85000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f85000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&intr_main_navss>;
+		};
+
+		mailbox0_cluster6: mailbox@31f86000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f86000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&intr_main_navss>;
+		};
+
+		mailbox0_cluster7: mailbox@31f87000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f87000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&intr_main_navss>;
+		};
+
+		mailbox0_cluster8: mailbox@31f88000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f88000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&intr_main_navss>;
+		};
+
+		mailbox0_cluster9: mailbox@31f89000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f89000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&intr_main_navss>;
+		};
+
+		mailbox0_cluster10: mailbox@31f8a000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f8a000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&intr_main_navss>;
+		};
+
+		mailbox0_cluster11: mailbox@31f8b000 {
+			compatible = "ti,am654-mailbox";
+			reg = <0x00 0x31f8b000 0x00 0x200>;
+			#mbox-cells = <1>;
+			ti,mbox-num-users = <4>;
+			ti,mbox-num-fifos = <16>;
+			interrupt-parent = <&intr_main_navss>;
+		};
 	};
 
 	main_gpio0:  main_gpio0@600000 {
-- 
2.22.0

^ permalink raw reply related

* [PATCH v2 0/4] Add Mailbox nodes for TI K3 AM65x & J721E SoCs
From: Suman Anna @ 2019-07-25  0:10 UTC (permalink / raw)
  To: Tero Kristo, Nishanth Menon; +Cc: devicetree, linux-arm-kernel

Hi Tero, Nishanth,

The following series is a revised version of the series [1] that adds
the Mailbox DT nodes and the sub-mailboxes used to communicate between
the main MPU processor running Linux and the various R5F and DSP remote
processors present on the TI K3 AM65x and J721E SoC families. Patches
are based on v5.3-rc1 + the HwSpinlock DT node series [2], and are
intended for the 5.4 merge window. Functionality is verified using a
out-of-tree unit-test module and some additional loopback test nodes
available here [3] for reference.

Changes in v2:
 - All clusters are enabled by default in base dtsi files
 - The sub-mailboxes are moved to the actual board dts files
 - Unused clusters disabled in the board dts files

regards
Suman

[1] https://patchwork.kernel.org/cover/11053401/
[2] https://patchwork.kernel.org/cover/11053311/
[3] https://github.com/sumananna/mailbox/commits/mbox/test/5.3-rc1-k3-v2

Suman Anna (4):
  arm64: dts: ti: k3-am65-main: Add mailbox cluster nodes
  arm64: dts: ti: k3-am65-base-board: Add IPC sub-mailbox nodes for R5Fs
  arm64: dts: ti: k3-j721e-main: Add mailbox cluster nodes
  arm64: dts: ti: k3-j721e-common-proc-board: Add IPC sub-mailbox nodes

 arch/arm64/boot/dts/ti/k3-am65-main.dtsi      | 108 ++++++++++++++++++
 .../arm64/boot/dts/ti/k3-am654-base-board.dts |  58 ++++++++++
 .../dts/ti/k3-j721e-common-proc-board.dts     |  93 +++++++++++++++
 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi     | 108 ++++++++++++++++++
 4 files changed, 367 insertions(+)

-- 
2.22.0

^ permalink raw reply

* Re: [PATCH V6 01/21] irqchip: tegra: Do not disable COP IRQ during suspend
From: Sowjanya Komatineni @ 2019-07-24 23:09 UTC (permalink / raw)
  To: Dmitry Osipenko, Marc Zyngier
  Cc: thierry.reding, jonathanh, tglx, jason, linus.walleij, stefan,
	mark.rutland, pdeschrijver, pgaikwad, sboyd, linux-clk,
	linux-gpio, jckuo, josephl, talho, linux-tegra, linux-kernel,
	mperttunen, spatra, robh+dt, devicetree
In-Reply-To: <8e9f821c-3717-510d-c64f-8a1cc2452c25@gmail.com>


On 7/22/19 4:35 PM, Dmitry Osipenko wrote:
> 22.07.2019 21:38, Marc Zyngier пишет:
>> On Mon, 22 Jul 2019 09:21:21 -0700
>> Sowjanya Komatineni <skomatineni@nvidia.com> wrote:
>>
>>> On 7/22/19 3:57 AM, Dmitry Osipenko wrote:
>>>> 22.07.2019 13:13, Marc Zyngier пишет:
>>>>> On 22/07/2019 10:54, Dmitry Osipenko wrote:
>>>>>> 21.07.2019 22:40, Sowjanya Komatineni пишет:
>>>>>>> Tegra210 platforms use sc7 entry firmware to program Tegra LP0/SC7 entry
>>>>>>> sequence and sc7 entry firmware is run from COP/BPMP-Lite.
>>>>>>>
>>>>>>> So, COP/BPMP-Lite still need IRQ function to finish SC7 suspend sequence
>>>>>>> for Tegra210.
>>>>>>>
>>>>>>> This patch has fix for leaving the COP IRQ enabled for Tegra210 during
>>>>>>> interrupt controller suspend operation.
>>>>>>>
>>>>>>> Acked-by: Thierry Reding <treding@nvidia.com>
>>>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>>>>>> ---
>>>>>>>    drivers/irqchip/irq-tegra.c | 20 ++++++++++++++++++--
>>>>>>>    1 file changed, 18 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/irqchip/irq-tegra.c b/drivers/irqchip/irq-tegra.c
>>>>>>> index e1f771c72fc4..851f88cef508 100644
>>>>>>> --- a/drivers/irqchip/irq-tegra.c
>>>>>>> +++ b/drivers/irqchip/irq-tegra.c
>>>>>>> @@ -44,6 +44,7 @@ static unsigned int num_ictlrs;
>>>>>>>    
>>>>>>>    struct tegra_ictlr_soc {
>>>>>>>    	unsigned int num_ictlrs;
>>>>>>> +	bool supports_sc7;
>>>>>>>    };
>>>>>>>    
>>>>>>>    static const struct tegra_ictlr_soc tegra20_ictlr_soc = {
>>>>>>> @@ -56,6 +57,7 @@ static const struct tegra_ictlr_soc tegra30_ictlr_soc = {
>>>>>>>    
>>>>>>>    static const struct tegra_ictlr_soc tegra210_ictlr_soc = {
>>>>>>>    	.num_ictlrs = 6,
>>>>>>> +	.supports_sc7 = true,
>>>>>>>    };
>>>>>>>    
>>>>>>>    static const struct of_device_id ictlr_matches[] = {
>>>>>>> @@ -67,6 +69,7 @@ static const struct of_device_id ictlr_matches[] = {
>>>>>>>    
>>>>>>>    struct tegra_ictlr_info {
>>>>>>>    	void __iomem *base[TEGRA_MAX_NUM_ICTLRS];
>>>>>>> +	const struct tegra_ictlr_soc *soc;
>>>>>>>    #ifdef CONFIG_PM_SLEEP
>>>>>>>    	u32 cop_ier[TEGRA_MAX_NUM_ICTLRS];
>>>>>>>    	u32 cop_iep[TEGRA_MAX_NUM_ICTLRS];
>>>>>>> @@ -147,8 +150,20 @@ static int tegra_ictlr_suspend(void)
>>>>>>>    		lic->cop_ier[i] = readl_relaxed(ictlr + ICTLR_COP_IER);
>>>>>>>    		lic->cop_iep[i] = readl_relaxed(ictlr + ICTLR_COP_IEP_CLASS);
>>>>>>>    
>>>>>>> -		/* Disable COP interrupts */
>>>>>>> -		writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
>>>>>>> +		/*
>>>>>>> +		 * AVP/COP/BPMP-Lite is the Tegra boot processor.
>>>>>>> +		 *
>>>>>>> +		 * Tegra210 system suspend flow uses sc7entry firmware which
>>>>>>> +		 * is executed by COP/BPMP and it includes disabling COP IRQ,
>>>>>>> +		 * clamping CPU rail, turning off VDD_CPU, and preparing the
>>>>>>> +		 * system to go to SC7/LP0.
>>>>>>> +		 *
>>>>>>> +		 * COP/BPMP wakes up when COP IRQ is triggered and runs
>>>>>>> +		 * sc7entry-firmware. So need to keep COP interrupt enabled.
>>>>>>> +		 */
>>>>>>> +		if (!lic->soc->supports_sc7)
>>>>>>> +			/* Disable COP interrupts if SC7 is not supported */
>>>>>> All Tegra SoCs support SC7, hence the 'supports_sc7' and the comment
>>>>>> doesn't sound correct to me. Something like 'firmware_sc7' should suit
>>>>>> better here.
>>>>> If what you're saying is true, then the whole patch is wrong, and the
>>>>> SC7 property should come from DT.
>>>> It should be safe to assume that all of existing Tegra210 devices use
>>>> the firmware for SC7, hence I wouldn't say that the patch is entirely
>>>> wrong. To me it's not entirely correct.
>>> Yes, all existing Tegra210 platforms uses sc7 entry firmware for SC7 and
>>> AVP/COP IRQ need to be kept enabled as during suspend ATF triggers IRQ
>>> to COP for SC7 entry fw execution.
> Okay, as I already wrote before, it looks to me that a more proper
> solution should be to just remove everything related to COP from this
> driver instead of adding custom quirks for T210.
>
> The disabling / restoring of COP interrupts should be relevant only for
> the multimedia firmware on older Tegra SoCs. That firmware won't be ever
> supported in the upstream simply because NVIDIA abandoned the support
> for older hardware in the downstream and because it is not possible due
> to some legal weirdness (IIUC). The only variant for upstream is
> reverse-engineering of hardware (not the firmware BLOB) and writing
> proper opensource drivers for the upstream kernel, which we're already
> doing and have success to a some extent.
>
>> That's not the question. Dmitry says that the SC7 support is not a
>> property of the SoC, but mostly a platform decision on whether the
>> firmware supports SC7 or not.
>>
>> To me, that's a clear indication that this should not be hardcoded in
>> the driver, but instead obtained dynamically, via DT or otherwise.
> We already have an nvidia,suspend-mode property in the device-tree of
> the Power Management Controller node (all Tegra SoCs) which defines what
> suspending type is supported by a particular board.
>
>>>>>>> +			writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
>>>>>> Secondly, I'm also not sure why COP interrupts need to be disabled for
>>>>>> pre-T210 at all, since COP is unused. This looks to me like it was
>>>>>> cut-n-pasted from downstream kernel without a good reason and could be
>>>>>> simply removed.
>>>>> Please verify that this is actually the case. Tegra-2 definitely needed
>>>>> some level of poking, and I'm not keen on changing anything there until
>>>>> you (or someone else) has verified it on actual HW (see e307cc8941fc).
>>>> Tested on Tegra20 and Tegra30, LP1 suspend-resume works perfectly fine
>>>> with all COP bits removed from the driver.
>>>>
>>>> AFAIK, the reason why downstream needed that disabling is that it uses
>>>> proprietary firmware which is running on the COP and that firmware is
>>>> usually a BLOB audio/video DEC-ENC driver which doesn't cleanup
>>>> interrupts after itself. That firmware is not applicable for the
>>>> upstream kernel, hence there is no need to care about it.
>>>>   
>>>>> Joseph, can you please shed some light here?
>>> SC7 entry flow uses 3rd party ATF (arm-trusted FW) blob which is the
>>> one that actually loads SC7 entry firmware and triggers IRQ to
>>> AVP/COP which causes COP to wakeup and run SC7 entry FW.
>>>
>>> So when SC7 support is enabled, IRQ need to be kept enabled and when
>>> SC7 FW starts execution, it will disable COP IRQ.
>> This looks like a lot of undocumented assumptions on what firmware
>> does, as well as what firmware *is*. What I gather from this thread is
>> that there is at least two versions of firmware (a "proprietary
>> firmware" for "downstream kernels", and another one for mainline), and
>> that they do different things.
>>
>> Given that we cannot know what people actually run, I don't think we
>> can safely remove anything unless this gets tested on the full spectrum
>> of HW/FW combination.
> I'm not sure whether multiple firmware variations exist in the wild for
> Tegra210. Maybe Sowjanya or somebody else from NVIDIA could clarify. I
> think there should be some efforts in regards to a fully opensource
> firmware on Tegra210, but I'm not following it and have no idea about
> the status.
>
> You're right that there are multiple variants of suspend-resuming flow
> on Tegra SoCs. The older 32bit Tegra SoC generations have a variety of
> options in regards to suspend-resuming, including firmware-less variants
> on platforms that are having kernel running in secure mode (dev boards,
> most of Tegra20 consumer devices) and Trusted-Foundations firmware
> variant for insecure platforms (consumer devices). And yes, vendor
> firmware creates a lot of headache in regards to bringing support into
> upstream because it usually does a lot of odd undocumented things which
> may also vary depending on a firmware version (bootloader, etc) and it
> also usually difficult to replace it with an opensource alternative due
> to a crypto signing.

Tried without this patch which keeps COP IRQ disabled and I see SC7 
entry FW execution happens still.

Digging through the ATF FW code, I see on SC7 entry firmware loading 
into IRAM, COP processor is reset with RESET VECTOR set to SC7 entry 
firmware location in IRAM and on reset de-assert & unhalt COP, SC7 
firmware starts execution.

Will remove this patch in next version...

^ permalink raw reply

* Re: [PATCH v2 2/2] ARM: dts: rockchip: consolidate veyron panel and backlight settings
From: Matthias Kaehlcke @ 2019-07-24 22:38 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stuebner,
	open list:ARM/Rockchip SoC..., Rob Herring, Linux ARM
In-Reply-To: <CAD=FV=Wj4Fei6t-STjY_FJkDKQYys5PcVquBJcdRE3wUN=y3Yg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Wed, Jul 24, 2019 at 02:46:30PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Thu, Jul 11, 2019 at 3:35 PM Matthias Kaehlcke <mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> >
> > diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
> > index 4cc7d3659484..2b0801a539c9 100644
> > --- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
> > +++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
> > @@ -15,40 +15,6 @@
> >                      "google,veyron-minnie-rev0", "google,veyron-minnie",
> >                      "google,veyron", "rockchip,rk3288";
> >
> > -       backlight_regulator: backlight-regulator {
> > -               compatible = "regulator-fixed";
> > -               enable-active-high;
> > -               gpio = <&gpio2 RK_PB4 GPIO_ACTIVE_HIGH>;
> > -               pinctrl-names = "default";
> > -               pinctrl-0 = <&bl_pwr_en>;
> > -               regulator-name = "backlight_regulator";
> > -               vin-supply = <&vcc33_sys>;
> > -               startup-delay-us = <15000>;
> > -       };
> > -
> > -       panel_regulator: panel-regulator {
> > -               compatible = "regulator-fixed";
> > -               enable-active-high;
> > -               gpio = <&gpio7 RK_PB6 GPIO_ACTIVE_HIGH>;
> > -               pinctrl-names = "default";
> > -               pinctrl-0 = <&lcd_enable_h>;
> > -               regulator-name = "panel_regulator";
> > -               startup-delay-us = <100000>;
> > -               vin-supply = <&vcc33_sys>;
> > -       };
> > -
> > -       vcc18_lcd: vcc18-lcd {
> > -               compatible = "regulator-fixed";
> > -               enable-active-high;
> > -               gpio = <&gpio2 RK_PB5 GPIO_ACTIVE_HIGH>;
> > -               pinctrl-names = "default";
> > -               pinctrl-0 = <&avdd_1v8_disp_en>;
> > -               regulator-name = "vcc18_lcd";
> > -               regulator-always-on;
> > -               regulator-boot-on;
> > -               vin-supply = <&vcc18_wl>;
> > -       };
> > -
> >         volume_buttons: volume-buttons {
> >                 compatible = "gpio-keys";
> >                 pinctrl-names = "default";
> 
> You forgot to remove the line:
> 
> power-supply = <&backlight_regulator>;
> 
> ...from minnie.

good catch, thanks!

> > diff --git a/arch/arm/boot/dts/rk3288-veyron-pinky.dts b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > index 9b6f4d9b03b6..06af58e37a4b 100644
> > --- a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > +++ b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > @@ -14,7 +14,14 @@
> >         compatible = "google,veyron-pinky-rev2", "google,veyron-pinky",
> >                      "google,veyron", "rockchip,rk3288";
> >
> > +       /delete-node/backlight-regulator;
> > +       /delete-node/panel-regulator;
> >         /delete-node/emmc-pwrseq;
> > +       /delete-node/vcc18-lcd;
> > +};
> > +
> > +&backlight {
> > +       /delete-property/power-supply;
> >  };
> >
> >  &emmc {
> > @@ -52,7 +59,17 @@
> >         i2c-scl-rising-time-ns = <300>;
> >  };
> >
> > +&panel {
> > +       power-supply= <&vcc33_lcd>;
> 
> Might as well put a space before the "="?

will do

> >  &pinctrl {
> > +       /delete-node/ lcd;
> > +
> > +       backlight {
> > +               /delete-node/ bl_pwr_en;
> > +       };
> 
> I general as the defender of "pinky", I'll let Heiko confirm he's OK
> with the color of this bikeshed.  Sometimes a bit of repetition is
> preferred over a bunch of confusing /delete-node/ statements since
> those tend to make things harder to reason about in general.  In this
> case I think things are cleaner after your patch but I won't say it's
> 100% clear cut.

I agree that some repetition can be preferrable over /delete-node/
statements. In this case repetition is above my personal threshold,
especially since I'm about to add another device with eDP display and
would have to repeat the mostly redundant config yet another time.

If Heiko prefer's the repetition so be it :)

> Other than nits I have double-checked this patch, so feel free to add
> my Reviewed-by after nits are fixed.

Thanks for the review!

^ permalink raw reply

* Re: [PATCH v2 2/2] ARM: dts: rockchip: consolidate veyron panel and backlight settings
From: Heiko Stuebner @ 2019-07-24 22:38 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Mark Rutland, devicetree, Rob Herring,
	open list:ARM/Rockchip SoC..., Matthias Kaehlcke, Linux ARM
In-Reply-To: <CAD=FV=Wj4Fei6t-STjY_FJkDKQYys5PcVquBJcdRE3wUN=y3Yg@mail.gmail.com>

Am Mittwoch, 24. Juli 2019, 23:46:30 CEST schrieb Doug Anderson:
> Hi,
> 
> On Thu, Jul 11, 2019 at 3:35 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
> > index 4cc7d3659484..2b0801a539c9 100644
> > --- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
> > +++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
> > @@ -15,40 +15,6 @@
> >                      "google,veyron-minnie-rev0", "google,veyron-minnie",
> >                      "google,veyron", "rockchip,rk3288";
> >
> > -       backlight_regulator: backlight-regulator {
> > -               compatible = "regulator-fixed";
> > -               enable-active-high;
> > -               gpio = <&gpio2 RK_PB4 GPIO_ACTIVE_HIGH>;
> > -               pinctrl-names = "default";
> > -               pinctrl-0 = <&bl_pwr_en>;
> > -               regulator-name = "backlight_regulator";
> > -               vin-supply = <&vcc33_sys>;
> > -               startup-delay-us = <15000>;
> > -       };
> > -
> > -       panel_regulator: panel-regulator {
> > -               compatible = "regulator-fixed";
> > -               enable-active-high;
> > -               gpio = <&gpio7 RK_PB6 GPIO_ACTIVE_HIGH>;
> > -               pinctrl-names = "default";
> > -               pinctrl-0 = <&lcd_enable_h>;
> > -               regulator-name = "panel_regulator";
> > -               startup-delay-us = <100000>;
> > -               vin-supply = <&vcc33_sys>;
> > -       };
> > -
> > -       vcc18_lcd: vcc18-lcd {
> > -               compatible = "regulator-fixed";
> > -               enable-active-high;
> > -               gpio = <&gpio2 RK_PB5 GPIO_ACTIVE_HIGH>;
> > -               pinctrl-names = "default";
> > -               pinctrl-0 = <&avdd_1v8_disp_en>;
> > -               regulator-name = "vcc18_lcd";
> > -               regulator-always-on;
> > -               regulator-boot-on;
> > -               vin-supply = <&vcc18_wl>;
> > -       };
> > -
> >         volume_buttons: volume-buttons {
> >                 compatible = "gpio-keys";
> >                 pinctrl-names = "default";
> 
> You forgot to remove the line:
> 
> power-supply = <&backlight_regulator>;
> 
> ...from minnie.
> 
> 
> > diff --git a/arch/arm/boot/dts/rk3288-veyron-pinky.dts b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > index 9b6f4d9b03b6..06af58e37a4b 100644
> > --- a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > +++ b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > @@ -14,7 +14,14 @@
> >         compatible = "google,veyron-pinky-rev2", "google,veyron-pinky",
> >                      "google,veyron", "rockchip,rk3288";
> >
> > +       /delete-node/backlight-regulator;
> > +       /delete-node/panel-regulator;
> >         /delete-node/emmc-pwrseq;
> > +       /delete-node/vcc18-lcd;
> > +};
> > +
> > +&backlight {
> > +       /delete-property/power-supply;
> >  };
> >
> >  &emmc {
> > @@ -52,7 +59,17 @@
> >         i2c-scl-rising-time-ns = <300>;
> >  };
> >
> > +&panel {
> > +       power-supply= <&vcc33_lcd>;
> 
> Might as well put a space before the "="?
> 
> 
> >  &pinctrl {
> > +       /delete-node/ lcd;
> > +
> > +       backlight {
> > +               /delete-node/ bl_pwr_en;
> > +       };
> 
> I general as the defender of "pinky", I'll let Heiko confirm he's OK
> with the color of this bikeshed.  Sometimes a bit of repetition is
> preferred over a bunch of confusing /delete-node/ statements since
> those tend to make things harder to reason about in general.  In this
> case I think things are cleaner after your patch but I won't say it's
> 100% clear cut.

going this way with the delete-nodes looks good to me :-) ... pinky is
the "odd" one in that, so I think it can carry the burden ... especially
as you said, this really only affects me and my boardfarm at all ;-) .


Heiko

> 
> Other than nits I have double-checked this patch, so feel free to add
> my Reviewed-by after nits are fixed.
> 
> -Doug
> 

^ permalink raw reply

* Re: [PATCH v2 1/2] ARM: dts: rockchip: move rk3288-veryon display settings into a separate file
From: Matthias Kaehlcke @ 2019-07-24 22:28 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Mark Rutland, devicetree, Heiko Stuebner,
	open list:ARM/Rockchip SoC..., Rob Herring, Linux ARM
In-Reply-To: <CAD=FV=U5Z4QqyjzJpERwhvJFPATS+khVWBCStnaJKZR0hHBWNQ@mail.gmail.com>

On Wed, Jul 24, 2019 at 02:19:35PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Thu, Jul 11, 2019 at 3:35 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > diff --git a/arch/arm/boot/dts/rk3288-veyron-edp.dtsi b/arch/arm/boot/dts/rk3288-veyron-edp.dtsi
> > new file mode 100644
> > index 000000000000..5d812e9e78aa
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/rk3288-veyron-edp.dtsi
> > @@ -0,0 +1,124 @@
> > +// SPDX-License-Identifier: GPL-2.0
> 
> Please allow MIT license:
> 
> // SPDX-License-Identifier: (GPL-2.0+ OR MIT)

ok

> > +&pinctrl {
> > +       backlight {
> > +               bl_en: bl-en {
> > +                       rockchip,pins = <7 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
> > +               };
> > +       };
> > +};
> 
> nit: convention on Rockchip device tree files is that all pinctrl
> stuff is at the bottom.  Downstream I think I added comments about
> this but those didn't make it upstream.

I'll move it to the bottom

> Also: why did you move "bl_en" here but not "edp_hpd"?

'bl_en' is defined in rk3288-veyron-chromebook.dtsi, 'edp_hdp' in
rk3288.dtsi of the SoC.

^ permalink raw reply

* Re: [PATCH v2 2/2] ARM: dts: rockchip: consolidate veyron panel and backlight settings
From: Doug Anderson @ 2019-07-24 21:46 UTC (permalink / raw)
  To: Matthias Kaehlcke
  Cc: Mark Rutland, devicetree, Heiko Stuebner,
	open list:ARM/Rockchip SoC..., Rob Herring, Linux ARM
In-Reply-To: <20190711223455.12210-2-mka@chromium.org>

Hi,

On Thu, Jul 11, 2019 at 3:35 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
> index 4cc7d3659484..2b0801a539c9 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
> +++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
> @@ -15,40 +15,6 @@
>                      "google,veyron-minnie-rev0", "google,veyron-minnie",
>                      "google,veyron", "rockchip,rk3288";
>
> -       backlight_regulator: backlight-regulator {
> -               compatible = "regulator-fixed";
> -               enable-active-high;
> -               gpio = <&gpio2 RK_PB4 GPIO_ACTIVE_HIGH>;
> -               pinctrl-names = "default";
> -               pinctrl-0 = <&bl_pwr_en>;
> -               regulator-name = "backlight_regulator";
> -               vin-supply = <&vcc33_sys>;
> -               startup-delay-us = <15000>;
> -       };
> -
> -       panel_regulator: panel-regulator {
> -               compatible = "regulator-fixed";
> -               enable-active-high;
> -               gpio = <&gpio7 RK_PB6 GPIO_ACTIVE_HIGH>;
> -               pinctrl-names = "default";
> -               pinctrl-0 = <&lcd_enable_h>;
> -               regulator-name = "panel_regulator";
> -               startup-delay-us = <100000>;
> -               vin-supply = <&vcc33_sys>;
> -       };
> -
> -       vcc18_lcd: vcc18-lcd {
> -               compatible = "regulator-fixed";
> -               enable-active-high;
> -               gpio = <&gpio2 RK_PB5 GPIO_ACTIVE_HIGH>;
> -               pinctrl-names = "default";
> -               pinctrl-0 = <&avdd_1v8_disp_en>;
> -               regulator-name = "vcc18_lcd";
> -               regulator-always-on;
> -               regulator-boot-on;
> -               vin-supply = <&vcc18_wl>;
> -       };
> -
>         volume_buttons: volume-buttons {
>                 compatible = "gpio-keys";
>                 pinctrl-names = "default";

You forgot to remove the line:

power-supply = <&backlight_regulator>;

...from minnie.


> diff --git a/arch/arm/boot/dts/rk3288-veyron-pinky.dts b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> index 9b6f4d9b03b6..06af58e37a4b 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> +++ b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> @@ -14,7 +14,14 @@
>         compatible = "google,veyron-pinky-rev2", "google,veyron-pinky",
>                      "google,veyron", "rockchip,rk3288";
>
> +       /delete-node/backlight-regulator;
> +       /delete-node/panel-regulator;
>         /delete-node/emmc-pwrseq;
> +       /delete-node/vcc18-lcd;
> +};
> +
> +&backlight {
> +       /delete-property/power-supply;
>  };
>
>  &emmc {
> @@ -52,7 +59,17 @@
>         i2c-scl-rising-time-ns = <300>;
>  };
>
> +&panel {
> +       power-supply= <&vcc33_lcd>;

Might as well put a space before the "="?


>  &pinctrl {
> +       /delete-node/ lcd;
> +
> +       backlight {
> +               /delete-node/ bl_pwr_en;
> +       };

I general as the defender of "pinky", I'll let Heiko confirm he's OK
with the color of this bikeshed.  Sometimes a bit of repetition is
preferred over a bunch of confusing /delete-node/ statements since
those tend to make things harder to reason about in general.  In this
case I think things are cleaner after your patch but I won't say it's
100% clear cut.

Other than nits I have double-checked this patch, so feel free to add
my Reviewed-by after nits are fixed.

-Doug

^ permalink raw reply

* Re: [PATCH] ARM: dts: am335x-boneblue: Use of am335x-osd335x-common.dtsi
From: David Lechner @ 2019-07-24 21:41 UTC (permalink / raw)
  To: linux-omap
  Cc: Benoît Cousson, Tony Lindgren, Rob Herring, Mark Rutland,
	devicetree, linux-kernel, Robert Nelson
In-Reply-To: <20190724212616.17945-1-david@lechnology.com>

On 7/24/19 4:26 PM, David Lechner wrote:
> This makes use of the am335x-osd335x-common.dtsi file that contains the
> common device tree components for Octavo Systems AM335x System-in-
> Package that is used on the BeagleBone Blue.
> 
> This has two minor side-effects:
> 1. pinmux_i2c0_pins is renamed to pinmux-i2c0-pins
> 2. the 1MHz cpufreq operating point is enabled

Oops. should be 1000MHz

^ permalink raw reply

* [PATCH] ARM: dts: am335x-boneblue: Use of am335x-osd335x-common.dtsi
From: David Lechner @ 2019-07-24 21:26 UTC (permalink / raw)
  To: linux-omap
  Cc: David Lechner, Benoît Cousson, Tony Lindgren, Rob Herring,
	Mark Rutland, devicetree, linux-kernel, Robert Nelson

This makes use of the am335x-osd335x-common.dtsi file that contains the
common device tree components for Octavo Systems AM335x System-in-
Package that is used on the BeagleBone Blue.

This has two minor side-effects:
1. pinmux_i2c0_pins is renamed to pinmux-i2c0-pins
2. the 1MHz cpufreq operating point is enabled

Cc: Robert Nelson <robertcnelson@gmail.com>
Signed-off-by: David Lechner <david@lechnology.com>
---
 arch/arm/boot/dts/am335x-boneblue.dts | 92 +--------------------------
 1 file changed, 2 insertions(+), 90 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-boneblue.dts b/arch/arm/boot/dts/am335x-boneblue.dts
index 0257576d5d16..2f6652ef9a15 100644
--- a/arch/arm/boot/dts/am335x-boneblue.dts
+++ b/arch/arm/boot/dts/am335x-boneblue.dts
@@ -5,23 +5,13 @@
 /dts-v1/;
 
 #include "am33xx.dtsi"
+#include "am335x-osd335x-common.dtsi"
 #include <dt-bindings/interrupt-controller/irq.h>
 
 / {
 	model = "TI AM335x BeagleBone Blue";
 	compatible = "ti,am335x-bone-blue", "ti,am33xx";
 
-	cpus {
-		cpu@0 {
-			cpu0-supply = <&dcdc2_reg>;
-		};
-	};
-
-	memory@80000000 {
-		device_type = "memory";
-		reg = <0x80000000 0x20000000>; /* 512 MB */
-	};
-
 	chosen {
 		stdout-path = &uart0;
 	};
@@ -142,13 +132,6 @@
 		>;
 	};
 
-	i2c0_pins: pinmux_i2c0_pins {
-		pinctrl-single,pins = <
-			AM33XX_PADCONF(AM335X_PIN_I2C0_SDA, PIN_INPUT_PULLUP, MUX_MODE0)	/* (C17) I2C0_SDA.I2C0_SDA */
-			AM33XX_PADCONF(AM335X_PIN_I2C0_SCL, PIN_INPUT_PULLUP, MUX_MODE0)	/* (C16) I2C0_SCL.I2C0_SCL */
-		>;
-	};
-
 	i2c2_pins: pinmux_i2c2_pins {
 		pinctrl-single,pins = <
 			AM33XX_PADCONF(AM335X_PIN_UART1_CTSN, PIN_INPUT_PULLUP, MUX_MODE3)	/* (D18) uart1_ctsn.I2C2_SDA */
@@ -328,16 +311,6 @@
 };
 
 &i2c0 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&i2c0_pins>;
-
-	status = "okay";
-	clock-frequency = <400000>;
-
-	tps: tps@24 {
-		reg = <0x24>;
-	};
-
 	baseboard_eeprom: baseboard_eeprom@50 {
 		compatible = "atmel,24c256";
 		reg = <0x50>;
@@ -381,66 +354,13 @@
 /include/ "tps65217.dtsi"
 
 &tps {
-	interrupts = <7>; /* NMI */
-	interrupt-parent = <&intc>;
+	/delete-property/ ti,pmic-shutdown-controller;
 
 	charger {
 		interrupts = <0>, <1>;
 		interrupt-names = "USB", "AC";
 		status = "okay";
 	};
-
-	pwrbutton {
-		interrupts = <2>;
-		status = "okay";
-	};
-
-	regulators {
-		dcdc1_reg: regulator@0 {
-			regulator-name = "vdds_dpr";
-			regulator-always-on;
-		};
-
-		dcdc2_reg: regulator@1 {
-			/* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
-			regulator-name = "vdd_mpu";
-			regulator-min-microvolt = <925000>;
-			regulator-max-microvolt = <1351500>;
-			regulator-boot-on;
-			regulator-always-on;
-		};
-
-		dcdc3_reg: regulator@2 {
-			/* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */
-			regulator-name = "vdd_core";
-			regulator-min-microvolt = <925000>;
-			regulator-max-microvolt = <1150000>;
-			regulator-boot-on;
-			regulator-always-on;
-		};
-
-		ldo1_reg: regulator@3 {
-			regulator-name = "vio,vrtc,vdds";
-			regulator-always-on;
-		};
-
-		ldo2_reg: regulator@4 {
-			regulator-name = "vdd_3v3aux";
-			regulator-always-on;
-		};
-
-		ldo3_reg: regulator@5 {
-			regulator-name = "vdd_1v8";
-			regulator-min-microvolt = <1800000>;
-			regulator-max-microvolt = <1800000>;
-			regulator-always-on;
-		};
-
-		ldo4_reg: regulator@6 {
-			regulator-name = "vdd_3v3a";
-			regulator-always-on;
-		};
-	};
 };
 
 &mmc1 {
@@ -502,14 +422,6 @@
 	};
 };
 
-&aes {
-	status = "okay";
-};
-
-&sham {
-	status = "okay";
-};
-
 &rtc {
 	system-power-controller;
 	clocks = <&clk_32768_ck>, <&clk_24mhz_clkctrl AM3_CLK_24MHZ_CLKDIV32K_CLKCTRL 0>;
-- 
2.17.1

^ permalink raw reply related

* Re: [PATCH v2 1/2] ARM: dts: rockchip: move rk3288-veryon display settings into a separate file
From: Doug Anderson @ 2019-07-24 21:19 UTC (permalink / raw)
  To: Matthias Kaehlcke
  Cc: Mark Rutland, devicetree, Heiko Stuebner,
	open list:ARM/Rockchip SoC..., Rob Herring, Linux ARM
In-Reply-To: <20190711223455.12210-1-mka@chromium.org>

Hi,

On Thu, Jul 11, 2019 at 3:35 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> diff --git a/arch/arm/boot/dts/rk3288-veyron-edp.dtsi b/arch/arm/boot/dts/rk3288-veyron-edp.dtsi
> new file mode 100644
> index 000000000000..5d812e9e78aa
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk3288-veyron-edp.dtsi
> @@ -0,0 +1,124 @@
> +// SPDX-License-Identifier: GPL-2.0

Please allow MIT license:

// SPDX-License-Identifier: (GPL-2.0+ OR MIT)


> +&pinctrl {
> +       backlight {
> +               bl_en: bl-en {
> +                       rockchip,pins = <7 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
> +               };
> +       };
> +};

nit: convention on Rockchip device tree files is that all pinctrl
stuff is at the bottom.  Downstream I think I added comments about
this but those didn't make it upstream.

Also: why did you move "bl_en" here but not "edp_hpd"?

-Doug

^ permalink raw reply

* Re: [PATCH v5 00/26] Add generic support for composing LED class device name
From: Jacek Anaszewski @ 2019-07-24 21:02 UTC (permalink / raw)
  To: Pavel Machek
  Cc: linux-leds, dmurphy, devicetree, linux-kernel, robh, dtor, linux
In-Reply-To: <20190718105233.GA3859@amd>

On 7/18/19 12:52 PM, Pavel Machek wrote:
> 
>> Hi all,
>>
>> I need explicit acks for some patches from this series, that
>> were either requested improvements or I modified them by myself
>> after v4.
>>
>> The patches I am talking about are the following:
>>
>> 1/26
>> 21/26
>> 23/26
>> 25/26
> 
> Acked-by: Pavel Machek <pavel@ucw.cz>

Applied the patch set without patch 26/26 for now.
I had to make some formatting related changes in leds-class.rst, in
part of the added text (we had leds-class.txt -> leds-class.rst
transition in the meantime) to fix resulting html formatting.
Basically they aimed to achieve nice bullets to compensate some
sphinx issue related to lack of line breaks after quoted strings.

Current shape of leds-class.rst on linux-leds.git for-next branch can
be looked up via [0].

>> 26/26 would be nice to have but I presume it needs more discussion
>> and analysis.
> 
> Idea is good, but I'd sort the file in different way.
> 
> Best regards,
> 									Pavel
> 

[0]
https://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git/tree/Documentation/leds/leds-class.rst?h=for-next

-- 
Best regards,
Jacek Anaszewski

^ permalink raw reply

* Re: [PATCH 2/2] dt-bindings: bus: imx-weim: document optional burst clock mode
From: Rob Herring @ 2019-07-24 20:48 UTC (permalink / raw)
  To: Sven Van Asbroeck
  Cc: Shawn Guo, NXP Linux Team, Kees Cook, linux-kernel,
	linux-arm-kernel, Mark Rutland, Sascha Hauer, devicetree,
	Fabio Estevam, Pengutronix Kernel Team, Arnd Bergmann
In-Reply-To: <20190712204316.16783-2-TheSven73@gmail.com>

On Fri, 12 Jul 2019 16:43:16 -0400, Sven Van Asbroeck wrote:
> An optional devicetree property was added to the imx-weim driver,
> which if present instructs it to operate in burst clock mode.
> Update the dt-bindings to reflect this.
> 
> Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
> ---
>  Documentation/devicetree/bindings/bus/imx-weim.txt | 4 ++++
>  1 file changed, 4 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v6 4/8] clk: mediatek: add mt6765 clock IDs
From: Rob Herring @ 2019-07-24 20:46 UTC (permalink / raw)
  Cc: Sean Wang, Mars Cheng, Owen Chen, Matthias Brugger,
	linux-arm-kernel, linux-mediatek, linux-kernel, wsd_upstream,
	CC Hwang, Loda Chou, devicetree, linux-serial, linux-clk,
	Macpaul Lin
In-Reply-To: <1562924653-10056-5-git-send-email-macpaul.lin@mediatek.com>

On Fri, 12 Jul 2019 17:43:40 +0800, Macpaul Lin wrote:
> From: Mars Cheng <mars.cheng@mediatek.com>
> 
> Add MT6765 clock dt-bindings, include topckgen, apmixedsys,
> infracfg, mcucfg and subsystem clocks.
> 
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
>  include/dt-bindings/clock/mt6765-clk.h | 313 +++++++++++++++++++++++++
>  1 file changed, 313 insertions(+)
>  create mode 100644 include/dt-bindings/clock/mt6765-clk.h
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v6 1/8] dt-bindings: clock: mediatek: document clk bindings for Mediatek MT6765 SoC
From: Rob Herring @ 2019-07-24 20:45 UTC (permalink / raw)
  To: Macpaul Lin
  Cc: Marc Zyngier, Ryder Lee, Stephen Boyd, Sean Wang, Mars Cheng,
	Owen Chen, Matthias Brugger, linux-arm-kernel, linux-mediatek,
	linux-kernel, wsd_upstream, CC Hwang, Loda Chou, devicetree,
	linux-serial, linux-clk
In-Reply-To: <1562924653-10056-2-git-send-email-macpaul.lin@mediatek.com>

On Fri, Jul 12, 2019 at 05:43:37PM +0800, Macpaul Lin wrote:
> From: Mars Cheng <mars.cheng@mediatek.com>
> 
> This patch adds the binding documentation for apmixedsys, audsys, camsys,
> imgsys, infracfg, mipi0a, topckgen, vcodecsys
> 
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Signed-off-by: Owen Chen <owen.chen@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
>  .../arm/mediatek/mediatek,apmixedsys.txt      |  1 +
>  .../bindings/arm/mediatek/mediatek,audsys.txt |  1 +
>  .../bindings/arm/mediatek/mediatek,camsys.txt |  1 +
>  .../bindings/arm/mediatek/mediatek,imgsys.txt |  1 +
>  .../arm/mediatek/mediatek,infracfg.txt        |  1 +
>  .../bindings/arm/mediatek/mediatek,mipi0a.txt | 28 +++++++++++++++++++
>  .../bindings/arm/mediatek/mediatek,mmsys.txt  |  1 +
>  .../arm/mediatek/mediatek,pericfg.txt         |  1 +
>  .../arm/mediatek/mediatek,topckgen.txt        |  1 +
>  .../arm/mediatek/mediatek,vcodecsys.txt       | 27 ++++++++++++++++++
>  10 files changed, 63 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
> index 161e63a6c254..5f2757e0f844 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
> @@ -8,6 +8,7 @@ Required Properties:
>  - compatible: Should be one of:
>  	- "mediatek,mt2701-apmixedsys"
>  	- "mediatek,mt2712-apmixedsys", "syscon"
> +	- "mediatek,mt6765-apmixedsys", "syscon"
>  	- "mediatek,mt6797-apmixedsys"
>  	- "mediatek,mt7622-apmixedsys"
>  	- "mediatek,mt7623-apmixedsys", "mediatek,mt2701-apmixedsys"
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> index f3cef1a6d95c..243db5275438 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> @@ -7,6 +7,7 @@ Required Properties:
>  
>  - compatible: Should be one of:
>  	- "mediatek,mt2701-audsys", "syscon"
> +	- "mediatek,mt6765-audsys", "syscon"
>  	- "mediatek,mt7622-audsys", "syscon"
>  	- "mediatek,mt7623-audsys", "mediatek,mt2701-audsys", "syscon"
>  	- "mediatek,mt8183-audiosys", "syscon"
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt
> index d8930f64aa98..17acc4c5402c 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt
> @@ -6,6 +6,7 @@ The MediaTek camsys controller provides various clocks to the system.
>  Required Properties:
>  
>  - compatible: Should be one of:
> +	- "mediatek,mt6765-camsys", "syscon"
>  	- "mediatek,mt8183-camsys", "syscon"
>  - #clock-cells: Must be 1
>  
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
> index e3bc4a1e7a6e..4e7b617acfb6 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
> @@ -8,6 +8,7 @@ Required Properties:
>  - compatible: Should be one of:
>  	- "mediatek,mt2701-imgsys", "syscon"
>  	- "mediatek,mt2712-imgsys", "syscon"
> +	- "mediatek,mt6765-imgsys", "syscon"
>  	- "mediatek,mt6797-imgsys", "syscon"
>  	- "mediatek,mt7623-imgsys", "mediatek,mt2701-imgsys", "syscon"
>  	- "mediatek,mt8173-imgsys", "syscon"
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
> index a90913988d7e..6a6ffb61dd29 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
> @@ -9,6 +9,7 @@ Required Properties:
>  - compatible: Should be one of:
>  	- "mediatek,mt2701-infracfg", "syscon"
>  	- "mediatek,mt2712-infracfg", "syscon"
> +	- "mediatek,mt6765-infracfg", "syscon"
>  	- "mediatek,mt6797-infracfg", "syscon"
>  	- "mediatek,mt7622-infracfg", "syscon"
>  	- "mediatek,mt7623-infracfg", "mediatek,mt2701-infracfg", "syscon"
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt
> new file mode 100644
> index 000000000000..49313055e574
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mipi0a.txt
> @@ -0,0 +1,28 @@
> +Mediatek mipi0a (mipi_rx_ana_csi0a) controller
> +============================
> +
> +The Mediatek mipi0a controller provides various clocks
> +to the system.

Is that all it does?

> +
> +Required Properties:
> +
> +- compatible: Should be one of:
> +	- "mediatek,mt6765-mipi0a", "syscon"
> +- #clock-cells: Must be 1
> +
> +The mipi0a controller uses the common clk binding from
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +The available clocks are defined in dt-bindings/clock/mt*-clk.h.
> +
> +The mipi0a controller also uses the common power domain from
> +Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> +The available power doamins are defined in dt-bindings/power/mt*-power.h.
> +
> +Example:
> +
> +mipi0a: mipi0a@11c10000 {

if so, then clock-controller@...

Same question on the next one.

> +	compatible = "mediatek,mt6765-mipi0a", "syscon";
> +	reg = <0 0x11c10000 0 0x1000>;
> +	power-domains = <&scpsys MT6765_POWER_DOMAIN_CAM>;
> +	#clock-cells = <1>;
> +};
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
> index 545eab717c96..0c7b1698b98e 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
> @@ -8,6 +8,7 @@ Required Properties:
>  - compatible: Should be one of:
>  	- "mediatek,mt2701-mmsys", "syscon"
>  	- "mediatek,mt2712-mmsys", "syscon"
> +	- "mediatek,mt6765-mmsys", "syscon"
>  	- "mediatek,mt6797-mmsys", "syscon"
>  	- "mediatek,mt7623-mmsys", "mediatek,mt2701-mmsys", "syscon"
>  	- "mediatek,mt8173-mmsys", "syscon"
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
> index 4c7e478117a0..b49b40741be1 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
> @@ -9,6 +9,7 @@ Required Properties:
>  - compatible: Should be one of:
>  	- "mediatek,mt2701-pericfg", "syscon"
>  	- "mediatek,mt2712-pericfg", "syscon"
> +	- "mediatek,mt6765-pericfg", "syscon"
>  	- "mediatek,mt7622-pericfg", "syscon"
>  	- "mediatek,mt7623-pericfg", "mediatek,mt2701-pericfg", "syscon"
>  	- "mediatek,mt7629-pericfg", "syscon"
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
> index a023b8338960..21ad416bfeec 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
> @@ -8,6 +8,7 @@ Required Properties:
>  - compatible: Should be one of:
>  	- "mediatek,mt2701-topckgen"
>  	- "mediatek,mt2712-topckgen", "syscon"
> +	- "mediatek,mt6765-topckgen", "syscon"
>  	- "mediatek,mt6797-topckgen"
>  	- "mediatek,mt7622-topckgen"
>  	- "mediatek,mt7623-topckgen", "mediatek,mt2701-topckgen"
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt
> new file mode 100644
> index 000000000000..83f7f8634943
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vcodecsys.txt
> @@ -0,0 +1,27 @@
> +Mediatek vcodecsys controller
> +============================
> +
> +The Mediatek vcodecsys controller provides various clocks to the system.
> +
> +Required Properties:
> +
> +- compatible: Should be one of:
> +	- "mediatek,mt6765-vcodecsys", "syscon"
> +- #clock-cells: Must be 1
> +
> +The vcodecsys controller uses the common clk binding from
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +The available clocks are defined in dt-bindings/clock/mt*-clk.h.
> +
> +The vcodecsys controller also uses the common power domain from
> +Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> +The available power doamins are defined in dt-bindings/power/mt*-power.h.
> +
> +Example:
> +
> +venc_gcon: venc_gcon@17000000 {
> +	compatible = "mediatek,mt6765-vcodecsys", "syscon";
> +	reg = <0 0x17000000 0 0x10000>;
> +	power-domains = <&scpsys MT6765_POWER_DOMAIN_VCODEC>;
> +	#clock-cells = <1>;
> +};
> -- 
> 2.18.0
> 

^ permalink raw reply

* Re: [PATCH 2/2] ARM: dts: aspeed: tiogapass: Add Riser card
From: Vijay Khemka @ 2019-07-24 20:42 UTC (permalink / raw)
  To: Joel Stanley
  Cc: Mark Rutland, linux-hwmon@vger.kernel.org, Jean Delvare,
	Sai Dasari, linux-aspeed@lists.ozlabs.org,
	devicetree@vger.kernel.org, Andrew Jeffery,
	openbmc @ lists . ozlabs . org, linux-kernel@vger.kernel.org,
	Rob Herring, linux-arm-kernel@lists.infradead.org, Guenter Roeck
In-Reply-To: <CACPK8Xc+1ZLoCQoERBjr7OQh3V0rV1g+mq+bPiJzCCzJix_13A@mail.gmail.com>



On 7/23/19, 3:34 PM, "Joel Stanley" <joel@jms.id.au> wrote:

    On Tue, 23 Jul 2019 at 17:22, Vijay Khemka <vijaykhemka@fb.com> wrote:
    >
    > Team,
    > This patch also needs review. I separated first patch with v2 and that was acked. Please review this as well.
    
    Do you have a coworker who has access to the schematics and can review
    the device tree? They would make a great reviewer.
Thanks Joel, Please see there is v2 for this and I will ask coworker to review.
    
    If no reviewer steps forward I will merge it next time I'm merging patches.
    
    Cheers,
    
    Joel
    
    >
    > Regards
    > -Vijay
    >
    > On 7/22/19, 12:41 PM, "Vijay Khemka" <vijaykhemka@fb.com> wrote:
    >
    >     Added i2c mux for riser card and multiple ava card and its sensor
    >     components for Facebook Tiogapass platform
    >
    >     Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
    >     ---
    >      .../dts/aspeed-bmc-facebook-tiogapass.dts     | 230 ++++++++++++++++++
    >      1 file changed, 230 insertions(+)
    >
    >     diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
    >     index b7783833a58c..8d0bcb3cd419 100644
    >     --- a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
    >     +++ b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
    >     @@ -12,6 +12,27 @@
    >         aliases {
    >                 serial0 = &uart1;
    >                 serial4 = &uart5;
    >     +
    >     +           /*
    >     +            * Hardcode the bus number of i2c switches' channels to
    >     +            * avoid breaking the legacy applications.
    >     +            */
    >     +           i2c16 = &imux16;
    >     +           i2c17 = &imux17;
    >     +           i2c18 = &imux18;
    >     +           i2c19 = &imux19;
    >     +           i2c20 = &imux20;
    >     +           i2c21 = &imux21;
    >     +           i2c22 = &imux22;
    >     +           i2c23 = &imux23;
    >     +           i2c24 = &imux24;
    >     +           i2c25 = &imux25;
    >     +           i2c26 = &imux26;
    >     +           i2c27 = &imux27;
    >     +           i2c28 = &imux28;
    >     +           i2c29 = &imux29;
    >     +           i2c30 = &imux30;
    >     +           i2c31 = &imux31;
    >         };
    >         chosen {
    >                 stdout-path = &uart5;
    >     @@ -124,6 +145,215 @@
    >      &i2c1 {
    >         status = "okay";
    >         //X24 Riser
    >     +   i2c-switch@71 {
    >     +           compatible = "nxp,pca9544";
    >     +           #address-cells = <1>;
    >     +           #size-cells = <0>;
    >     +           reg = <0x71>;
    >     +
    >     +           imux16: i2c@0 {
    >     +                   #address-cells = <1>;
    >     +                   #size-cells = <0>;
    >     +                   reg = <0>;
    >     +
    >     +                   ina219@45 {
    >     +                           compatible = "ti,ina219";
    >     +                           reg = <0x45>;
    >     +                   };
    >     +
    >     +                   tmp75@48 {
    >     +                           compatible = "ti,tmp75";
    >     +                           reg = <0x48>;
    >     +                   };
    >     +
    >     +                   tmp421@49 {
    >     +                           compatible = "ti,tmp75";
    >     +                           reg = <0x49>;
    >     +                   };
    >     +
    >     +                   eeprom@50 {
    >     +                           compatible = "atmel,24c64";
    >     +                           reg = <0x50>;
    >     +                           pagesize = <32>;
    >     +                   };
    >     +
    >     +                   i2c-switch@73 {
    >     +                           compatible = "nxp,pca9546";
    >     +                           #address-cells = <1>;
    >     +                           #size-cells = <0>;
    >     +                           reg = <0x73>;
    >     +
    >     +                           imux20: i2c@0 {
    >     +                                   #address-cells = <1>;
    >     +                                   #size-cells = <0>;
    >     +                                   reg = <0>;
    >     +                           };
    >     +
    >     +                           imux21: i2c@1 {
    >     +                                   #address-cells = <1>;
    >     +                                   #size-cells = <0>;
    >     +                                   reg = <1>;
    >     +                           };
    >     +
    >     +                           imux22: i2c@2 {
    >     +                                   #address-cells = <1>;
    >     +                                   #size-cells = <0>;
    >     +                                   reg = <2>;
    >     +                           };
    >     +
    >     +                           imux23: i2c@3 {
    >     +                                   #address-cells = <1>;
    >     +                                   #size-cells = <0>;
    >     +                                   reg = <3>;
    >     +                           };
    >     +
    >     +                   };
    >     +
    >     +           };
    >     +
    >     +           imux17: i2c@1 {
    >     +                   #address-cells = <1>;
    >     +                   #size-cells = <0>;
    >     +                   reg = <1>;
    >     +
    >     +                   ina219@45 {
    >     +                           compatible = "ti,ina219";
    >     +                           reg = <0x45>;
    >     +                   };
    >     +
    >     +                   tmp421@48 {
    >     +                           compatible = "ti,tmp75";
    >     +                           reg = <0x48>;
    >     +                   };
    >     +
    >     +                   tmp421@49 {
    >     +                           compatible = "ti,tmp75";
    >     +                           reg = <0x49>;
    >     +                   };
    >     +
    >     +                   eeprom@50 {
    >     +                           compatible = "atmel,24c64";
    >     +                           reg = <0x50>;
    >     +                           pagesize = <32>;
    >     +                   };
    >     +
    >     +                   i2c-switch@73 {
    >     +                           compatible = "nxp,pca9546";
    >     +                           #address-cells = <1>;
    >     +                           #size-cells = <0>;
    >     +                           reg = <0x73>;
    >     +
    >     +                           imux24: i2c@0 {
    >     +                                   #address-cells = <1>;
    >     +                                   #size-cells = <0>;
    >     +                                   reg = <0>;
    >     +                           };
    >     +
    >     +                           imux25: i2c@1 {
    >     +                                   #address-cells = <1>;
    >     +                                   #size-cells = <0>;
    >     +                                   reg = <1>;
    >     +                           };
    >     +
    >     +                           imux26: i2c@2 {
    >     +                                   #address-cells = <1>;
    >     +                                   #size-cells = <0>;
    >     +                                   reg = <2>;
    >     +                           };
    >     +
    >     +                           imux27: i2c@3 {
    >     +                                   #address-cells = <1>;
    >     +                                   #size-cells = <0>;
    >     +                                   reg = <3>;
    >     +                           };
    >     +
    >     +                   };
    >     +
    >     +           };
    >     +
    >     +           imux18: i2c@2 {
    >     +                   #address-cells = <1>;
    >     +                   #size-cells = <0>;
    >     +                   reg = <2>;
    >     +
    >     +                   ina219@45 {
    >     +                           compatible = "ti,ina219";
    >     +                           reg = <0x45>;
    >     +                   };
    >     +
    >     +                   tmp421@48 {
    >     +                           compatible = "ti,tmp75";
    >     +                           reg = <0x48>;
    >     +                   };
    >     +
    >     +                   tmp421@49 {
    >     +                           compatible = "ti,tmp75";
    >     +                           reg = <0x49>;
    >     +                   };
    >     +
    >     +                   eeprom@50 {
    >     +                           compatible = "atmel,24c64";
    >     +                           reg = <0x50>;
    >     +                           pagesize = <32>;
    >     +                   };
    >     +
    >     +                   i2c-switch@73 {
    >     +                           compatible = "nxp,pca9546";
    >     +                           #address-cells = <1>;
    >     +                           #size-cells = <0>;
    >     +                           reg = <0x73>;
    >     +
    >     +                           imux28: i2c@0 {
    >     +                                   #address-cells = <1>;
    >     +                                   #size-cells = <0>;
    >     +                                   reg = <0>;
    >     +                           };
    >     +
    >     +                           imux29: i2c@1 {
    >     +                                   #address-cells = <1>;
    >     +                                   #size-cells = <0>;
    >     +                                   reg = <1>;
    >     +                           };
    >     +
    >     +                           imux30: i2c@2 {
    >     +                                   #address-cells = <1>;
    >     +                                   #size-cells = <0>;
    >     +                                   reg = <2>;
    >     +                           };
    >     +
    >     +                           imux31: i2c@3 {
    >     +                                   #address-cells = <1>;
    >     +                                   #size-cells = <0>;
    >     +                                   reg = <3>;
    >     +                           };
    >     +
    >     +                   };
    >     +
    >     +           };
    >     +
    >     +           imux19: i2c@3 {
    >     +                   #address-cells = <1>;
    >     +                   #size-cells = <0>;
    >     +                   reg = <3>;
    >     +
    >     +                   i2c-switch@40 {
    >     +                           compatible = "ti,ina219";
    >     +                           reg = <0x40>;
    >     +                   };
    >     +
    >     +                   i2c-switch@41 {
    >     +                           compatible = "ti,ina219";
    >     +                           reg = <0x41>;
    >     +                   };
    >     +
    >     +                   i2c-switch@45 {
    >     +                           compatible = "ti,ina219";
    >     +                           reg = <0x45>;
    >     +                   };
    >     +
    >     +           };
    >     +
    >     +   };
    >      };
    >
    >      &i2c2 {
    >     --
    >     2.17.1
    >
    >
    >
    

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH V2 1/2] usb: dwc3: Add node to update cache type setting
From: Rob Herring @ 2019-07-24 20:42 UTC (permalink / raw)
  To: Ran Wang
  Cc: Greg Kroah-Hartman, Mark Rutland, Felipe Balbi, linux-usb,
	devicetree, linux-kernel
In-Reply-To: <20190712064206.48249-1-ran.wang_1@nxp.com>

On Fri, Jul 12, 2019 at 02:42:05PM +0800, Ran Wang wrote:
> Some Layerscape paltforms (such as LS1088A, LS2088A, etc) encounter USB
> detect failues when adding dma-coherent to DWC3 node. This is because the
> HW default cache type configuration of those SoC are not right, need to
> be updated in DTS.
> 
> Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> ---
> Change in v2:
> 	- New file.
> 
>  Documentation/devicetree/bindings/usb/dwc3.txt | 43 ++++++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
> index 8e5265e..7bc1cef 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -110,6 +110,43 @@ Optional properties:
>   - in addition all properties from usb-xhci.txt from the current directory are
>     supported as well
>  
> +* Cache type nodes (optional)
> +
> +The Cache type node is used to tell how to configure cache type on 4 different
> +transfer types: Data Read, Desc Read, Data Write and Desc write. For each
> +treasfer type, controller has a 4-bit register field to enable different cache
> +type. Quoted from DWC3 data book Table 6-5 Cache Type Bit Assignments:
> +----------------------------------------------------------------
> +MBUS_TYPE| bit[3]       |bit[2]       |bit[1]     |bit[0]
> +----------------------------------------------------------------
> +AHB      |Cacheable     |Bufferable   |Privilegge |Data
> +AXI3     |Write Allocate|Read Allocate|Cacheable  |Bufferable
> +AXI4     |Allocate Other|Allocate     |Modifiable |Bufferable
> +AXI4     |Other Allocate|Allocate     |Modifiable |Bufferable
> +Native   |Same as AXI   |Same as AXI  |Same as AXI|Same as AXI
> +----------------------------------------------------------------
> +Note: The AHB, AXI3, AXI4, and PCIe busses use different names for certain
> +signals, which have the same meaning:
> +  Bufferable = Posted
> +  Cacheable = Modifiable = Snoop (negation of No Snoop)

This should all be implied from the SoC specific compatible strings. 

Rob

^ permalink raw reply

* Re: [PATCH 1/2] dt-bindings: interconnect: Update Qualcomm SDM845 DT bindings
From: David Dai @ 2019-07-24 20:42 UTC (permalink / raw)
  To: Stephen Boyd, bjorn.andersson, georgi.djakov, robh+dt
  Cc: evgreen, ilina, seansw, elder, linux-kernel, devicetree,
	linux-arm-msm, linux-pm
In-Reply-To: <5d38a31d.1c69fb81.80992.0052@mx.google.com>


On 7/24/2019 11:27 AM, Stephen Boyd wrote:
> Quoting David Dai (2019-07-24 10:22:57)
>> The way that I view this is that the consumers consume both bandwidth
>> and QoS from these physical NoC devices by getting some path between two
>> endpoints on these different NoCs and applying some constraints. The NoC
>> providers can accomplish that either by writing to MMIO spaces or by
>> talking to some remote processor/hardware to tune its clock speed. The
>> consumer doesn't interact with the RSCs directly, but can select a
>> different bcm voter based on the endpoints that are associated with a
>> particular bcm(apps or disp rsc). Each node(endpoints) will have its own
>> BCM designation and an unique bcm voter.
> Ok. I get it now. The MMIO nodes will be interconnect providers and
> they'll know what RSCs they can use by exposing the same RSC "resource"
> multiple times for each RSC that can be targeted? This is what the
> postfix is with _DISP on your examples? Presumably there's an _APPS
> version of the same prefixed endpoint in case the consumer wants to use
> the APPS RSC instead of the DISP one, or maybe there's just no postfix
> in this case because APPS is the "default".

Right, the suffixes will denote the RSC association and will default to 
APPS otherwise.

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply

* Re: [PATCH 10/12] dt-bindings: firmware: qcom: Add compatible for IPQ8074 SoC
From: Rob Herring @ 2019-07-24 20:38 UTC (permalink / raw)
  Cc: agross, david.brown, robh+dt, mark.rutland, mturquette, sboyd,
	jassisinghbrar, ohad, bjorn.andersson, linux-arm-msm, devicetree,
	linux-kernel, linux-clk, linux-remoteproc, sricharan, gokulsri
In-Reply-To: <1562859668-14209-11-git-send-email-gokulsri@codeaurora.org>

On Thu, 11 Jul 2019 21:11:06 +0530, Gokul Sriram Palanisamy wrote:
> Add compatible for IPQ8074 support.
> This does not need clocks for scm calls.
> 
> Signed-off-by: Gokul Sriram Palanisamy <gokulsri@codeaurora.org>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> ---
>  Documentation/devicetree/bindings/firmware/qcom,scm.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH 08/12] dt-bindings: mailbox: qom: Add ipq8074 APPS compatible
From: Rob Herring @ 2019-07-24 20:37 UTC (permalink / raw)
  Cc: agross, david.brown, robh+dt, mark.rutland, mturquette, sboyd,
	jassisinghbrar, ohad, bjorn.andersson, linux-arm-msm, devicetree,
	linux-kernel, linux-clk, linux-remoteproc, sricharan, gokulsri
In-Reply-To: <1562859668-14209-9-git-send-email-gokulsri@codeaurora.org>

On Thu, 11 Jul 2019 21:11:04 +0530, Gokul Sriram Palanisamy wrote:
> Add mailbox support required in IPQ8074 SoCs.
> 
> Signed-off-by: Gokul Sriram Palanisamy <gokulsri@codeaurora.org>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> ---
>  Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH 06/12] dt-bindings: clock: qcom: Add reset for WCSSAON
From: Rob Herring @ 2019-07-24 20:37 UTC (permalink / raw)
  To: Gokul Sriram Palanisamy
  Cc: agross, david.brown, mark.rutland, mturquette, sboyd,
	jassisinghbrar, ohad, bjorn.andersson, linux-arm-msm, devicetree,
	linux-kernel, linux-clk, linux-remoteproc, sricharan
In-Reply-To: <1562859668-14209-7-git-send-email-gokulsri@codeaurora.org>

On Thu, Jul 11, 2019 at 09:11:02PM +0530, Gokul Sriram Palanisamy wrote:
> Add binding for WCSSAON reset required for Q6v5 reset on IPQ8074 SoC.
> 
> Signed-off-by: Gokul Sriram Palanisamy <gokulsri@codeaurora.org>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> Signed-off-by: Nikhil Prakash V <nprakash@codeaurora.org>
> ---
>  include/dt-bindings/clock/qcom,gcc-ipq8074.h | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v2 3/4] dt-bindings: iommu/arm,smmu: add compatible string for Marvell
From: Rob Herring @ 2019-07-24 20:36 UTC (permalink / raw)
  Cc: Robin Murphy, Joerg Roedel, linux-kernel, iommu, devicetree,
	Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT,
	Thomas Petazzoni, linux-arm-kernel, Catalin Marinas, Will Deacon,
	Antoine Tenart, Miquèl Raynal, Maxime Chevallier,
	Nadav Haklai, Hanna Hawa
In-Reply-To: <20190711150242.25290-4-gregory.clement@bootlin.com>

On Thu, 11 Jul 2019 17:02:41 +0200, Gregory CLEMENT wrote:
> From: Hanna Hawa <hannah@marvell.com>
> 
> Add specific compatible string for Marvell usage due errata of
> accessing 64bits registers of ARM SMMU, in AP806.
> 
> AP806 SoC uses the generic ARM-MMU500, and there's no specific
> implementation of Marvell, this compatible is used for errata only.
> 
> Signed-off-by: Hanna Hawa <hannah@marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH 1/1] dt-bindings: interrupt-controller: al-fic: remove redundant binding
From: Rob Herring @ 2019-07-24 20:36 UTC (permalink / raw)
  Cc: robh+dt, marc.zyngier, tglx, jason, mark.rutland, nicolas.ferre,
	mchehab+samsung, shawn.lin, gregkh, dwmw, benh, talel,
	linux-kernel, devicetree
In-Reply-To: <1562827139-1666-1-git-send-email-talel@amazon.com>

On Thu, 11 Jul 2019 09:38:59 +0300, Talel Shenhar wrote:
> Remove dt binding description for standard binding.
> 
> Signed-off-by: Talel Shenhar <talel@amazon.com>
> ---
>  .../bindings/interrupt-controller/amazon,al-fic.txt      | 16 +++++++---------
>  1 file changed, 7 insertions(+), 9 deletions(-)
> 

Applied, thanks.

Rob

^ permalink raw reply


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