* [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Bin Liu @ 2017-01-11 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <418251484165614@web21h.yandex.ru>
On Thu, Jan 12, 2017 at 04:13:34AM +0800, Icenowy Zheng wrote:
>
>
> 12.01.2017, 04:08, "Bin Liu" <b-liu@ti.com>:
> > On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
> >> ?11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
> >> ?> On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> >> ?>> ?Lichee Pi Zero features a USB OTG port.
> >> ?>>
> >> ?>> ?Add support for it.
> >> ?>>
> >> ?>> ?Note: in order to use the Host mode, the board must be powered via the
> >> ?>> ?+5V and GND pins.
> >> ?>>
> >> ?>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >> ?>> ?---
> >> ?>> ??arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
> >> ?>> ??1 file changed, 10 insertions(+)
> >> ?>>
> >> ?>> ?diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> ?>> ?index 0099affc6ce3..3d9168cbaeca 100644
> >> ?>> ?--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> ?>> ?+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> ?>> ?@@ -71,3 +71,13 @@
> >> ?>> ??????????pinctrl-names = "default";
> >> ?>> ??????????status = "okay";
> >> ?>> ??};
> >> ?>> ?+
> >> ?>> ?+&usb_otg {
> >> ?>> ?+ dr_mode = "otg";
> >> ?>
> >> ?> Why not set this default mode in dtsi instead?
> >> ?>
> >> ?> Regards,
> >> ?> -Bin.
> >>
> >> ?There's possibly boards which do not have OTG functions.
> >
> > That is board specific.
> >
> > You'd better to define the default dr_mode which the musb _controller_
> > supports in the dtsi, and then override it in a specific board dts if
> > necessary.
>
> Is there MUSB controllers which do not support a certain mode?
I am not aware of any. That is why I recommended to set "otg" in dtsi,
then override it in board dts if a port is specically designed to
host-only or device-only mode.
>
> (I remembered my omap3-n900 which do not work under OTG mode...)
I belive it is n900 board specific. omap3 itself doesn't have such
limitation, AFAIK.
Regards,
-Bin.
>
> >
> > Regards,
> > -Bin.
> >
> >> ?Even the official CDR design of V3s uses the USB controller to
> >> ?connect a UVC webcam to make the design a dual-cam design
> >> ?(V3s itself has a CSI).
> >>
> >> ?>
> >> ?>> ?+ status = "okay";
> >> ?>> ?+};
> >> ?>> ?+
> >> ?>> ?+&usbphy {
> >> ?>> ?+ usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> >> ?>> ?+ status = "okay";
> >> ?>> ?+};
> >> ?>> ?--
> >> ?>> ?2.11.0
^ permalink raw reply
* [PATCH v2 0/2] arm64: dts: juno: Updates for juno r1/r2 boards
From: Mike Leach @ 2017-01-11 20:44 UTC (permalink / raw)
To: linux-arm-kernel
Juno r1/r2 boards have different CoreSight infrastructure outside the
clusters. This patchset moves the none cluster CoreSight to separate
.dtsi files to allow for these differences.
v2 moves the Addition of the STM component into a separate patch.
Mike Leach (2):
arm64: dts: juno: Fix CoreSight support for Juno r1/r2 variants
arm64: dts: juno: Adds missing CoreSight STM component.
arch/arm64/boot/dts/arm/juno-base.dtsi | 135 ---------------
arch/arm64/boot/dts/arm/juno-cs-r0.dtsi | 166 +++++++++++++++++++
arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 266 ++++++++++++++++++++++++++++++
arch/arm64/boot/dts/arm/juno-r1.dts | 1 +
arch/arm64/boot/dts/arm/juno-r2.dts | 1 +
arch/arm64/boot/dts/arm/juno.dts | 1 +
6 files changed, 435 insertions(+), 135 deletions(-)
create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r0.dtsi
create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: juno: Fix CoreSight support for Juno r1/r2 variants
From: Mike Leach @ 2017-01-11 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484167449-14432-1-git-send-email-mike.leach@linaro.org>
The CoreSight support added for Juno is valid for only Juno r0.
The Juno r1 and r2 variants have additional components and alternative
connection routes between trace source and sinks.
The CoreSight infrastructure external to the Cortex-Axx clusters, has
been split into separate .dtsi include files for r0 and r1/r2 to correctly
represent these variations.
Signed-off-by: Mike Leach <mike.leach@linaro.org>
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 135 ----------------
arch/arm64/boot/dts/arm/juno-cs-r0.dtsi | 150 ++++++++++++++++++
arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 250 ++++++++++++++++++++++++++++++
arch/arm64/boot/dts/arm/juno-r1.dts | 1 +
arch/arm64/boot/dts/arm/juno-r2.dts | 1 +
arch/arm64/boot/dts/arm/juno.dts | 1 +
6 files changed, 403 insertions(+), 135 deletions(-)
create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r0.dtsi
create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 7d83224..7c89000 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -83,104 +83,6 @@
* The actual size is just 4K though 64K is reserved. Access to the
* unmapped reserved region results in a DECERR response.
*/
- etf at 20010000 {
- compatible = "arm,coresight-tmc", "arm,primecell";
- reg = <0 0x20010000 0 0x1000>;
-
- clocks = <&soc_smc50mhz>;
- clock-names = "apb_pclk";
- power-domains = <&scpi_devpd 0>;
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- /* input port */
- port at 0 {
- reg = <0>;
- etf_in_port: endpoint {
- slave-mode;
- remote-endpoint = <&main_funnel_out_port>;
- };
- };
-
- /* output port */
- port at 1 {
- reg = <0>;
- etf_out_port: endpoint {
- remote-endpoint = <&replicator_in_port0>;
- };
- };
- };
- };
-
- tpiu at 20030000 {
- compatible = "arm,coresight-tpiu", "arm,primecell";
- reg = <0 0x20030000 0 0x1000>;
-
- clocks = <&soc_smc50mhz>;
- clock-names = "apb_pclk";
- power-domains = <&scpi_devpd 0>;
- port {
- tpiu_in_port: endpoint {
- slave-mode;
- remote-endpoint = <&replicator_out_port0>;
- };
- };
- };
-
- main-funnel at 20040000 {
- compatible = "arm,coresight-funnel", "arm,primecell";
- reg = <0 0x20040000 0 0x1000>;
-
- clocks = <&soc_smc50mhz>;
- clock-names = "apb_pclk";
- power-domains = <&scpi_devpd 0>;
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port at 0 {
- reg = <0>;
- main_funnel_out_port: endpoint {
- remote-endpoint = <&etf_in_port>;
- };
- };
-
- port at 1 {
- reg = <0>;
- main_funnel_in_port0: endpoint {
- slave-mode;
- remote-endpoint = <&cluster0_funnel_out_port>;
- };
- };
-
- port at 2 {
- reg = <1>;
- main_funnel_in_port1: endpoint {
- slave-mode;
- remote-endpoint = <&cluster1_funnel_out_port>;
- };
- };
-
- };
- };
-
- etr at 20070000 {
- compatible = "arm,coresight-tmc", "arm,primecell";
- reg = <0 0x20070000 0 0x1000>;
- iommus = <&smmu_etr 0>;
-
- clocks = <&soc_smc50mhz>;
- clock-names = "apb_pclk";
- power-domains = <&scpi_devpd 0>;
- port {
- etr_in_port: endpoint {
- slave-mode;
- remote-endpoint = <&replicator_out_port1>;
- };
- };
- };
-
etm0: etm at 22040000 {
compatible = "arm,coresight-etm4x", "arm,primecell";
reg = <0 0x22040000 0 0x1000>;
@@ -351,43 +253,6 @@
};
};
- coresight-replicator {
- /*
- * Non-configurable replicators don't show up on the
- * AMBA bus. As such no need to add "arm,primecell".
- */
- compatible = "arm,coresight-replicator";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- /* replicator output ports */
- port at 0 {
- reg = <0>;
- replicator_out_port0: endpoint {
- remote-endpoint = <&tpiu_in_port>;
- };
- };
-
- port at 1 {
- reg = <1>;
- replicator_out_port1: endpoint {
- remote-endpoint = <&etr_in_port>;
- };
- };
-
- /* replicator input port */
- port at 2 {
- reg = <0>;
- replicator_in_port0: endpoint {
- slave-mode;
- remote-endpoint = <&etf_out_port>;
- };
- };
- };
- };
-
sram: sram at 2e000000 {
compatible = "arm,juno-sram-ns", "mmio-sram";
reg = <0x0 0x2e000000 0x0 0x8000>;
diff --git a/arch/arm64/boot/dts/arm/juno-cs-r0.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r0.dtsi
new file mode 100644
index 0000000..24419ed
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/juno-cs-r0.dtsi
@@ -0,0 +1,150 @@
+ /*
+ * Juno trace infrastructure.
+ * Trace links and sinks and interconnections
+ * from clusters.
+ * Connections for Juno r0.
+ */
+ etf at 20010000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x20010000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* input port */
+ port at 0 {
+ reg = <0>;
+ etf_in_port: endpoint {
+ slave-mode;
+ remote-endpoint = <&main_funnel_out_port>;
+ };
+ };
+
+ /* output port */
+ port at 1 {
+ reg = <0>;
+ etf_out_port: endpoint {
+ remote-endpoint = <&replicator_in_port0>;
+ };
+ };
+ };
+ };
+
+ tpiu at 20030000 {
+ compatible = "arm,coresight-tpiu", "arm,primecell";
+ reg = <0 0x20030000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ port {
+ tpiu_in_port: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out_port0>;
+ };
+ };
+ };
+
+ main-funnel at 20040000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x20040000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* output port */
+ port at 0 {
+ reg = <0>;
+ main_funnel_out_port: endpoint {
+ remote-endpoint = <&etf_in_port>;
+ };
+ };
+
+ /* input ports */
+ port at 1 {
+ reg = <0>;
+ main_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&cluster0_funnel_out_port>;
+ };
+ };
+
+ port at 2 {
+ reg = <1>;
+ main_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint = <&cluster1_funnel_out_port>;
+ };
+ };
+
+ port at 3 {
+ reg = <2>;
+ main_funnel_in_port2: endpoint {
+ slave-mode;
+ remote-endpoint = <&stm_out_port>;
+ };
+ };
+
+
+ };
+ };
+
+ etr at 20070000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x20070000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ port {
+ etr_in_port: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out_port1>;
+ };
+ };
+ };
+
+ coresight-replicator {
+ /*
+ * Non-configurable replicators don't show up on the
+ * AMBA bus. As such no need to add "arm,primecell".
+ */
+ compatible = "arm,coresight-replicator";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* replicator output ports */
+ port at 0 {
+ reg = <0>;
+ replicator_out_port0: endpoint {
+ remote-endpoint = <&tpiu_in_port>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ replicator_out_port1: endpoint {
+ remote-endpoint = <&etr_in_port>;
+ };
+ };
+
+ /* replicator input port */
+ port at 2 {
+ reg = <0>;
+ replicator_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etf_out_port>;
+ };
+ };
+ };
+ };
diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
new file mode 100644
index 0000000..caaf58e
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
@@ -0,0 +1,250 @@
+ /*
+ * Juno trace infrastructure.
+ * Trace links and sinks and interconnections
+ * from clusters.
+ * Connections for Juno r1 and r2.
+ */
+ etf0 at 20010000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x20010000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* input port */
+ port at 0 {
+ reg = <0>;
+ etf0_in_port: endpoint {
+ slave-mode;
+ remote-endpoint = <&main_funnel_out_port>;
+ };
+ };
+
+ /* output port */
+ port at 1 {
+ reg = <0>;
+ etf0_out_port: endpoint {
+ remote-endpoint = <&csys2_funnel_in_port0>;
+ };
+ };
+ };
+ };
+
+ etf1 at 20140000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x20140000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* input port */
+ port at 0 {
+ reg = <0>;
+ etf1_in_port: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&csys1_funnel_out_port>;
+ };
+ };
+
+ /* output port */
+ port at 1 {
+ reg = <0>;
+ etf1_out_port: endpoint {
+ remote-endpoint =
+ <&csys2_funnel_in_port1>;
+ };
+ };
+ };
+ };
+
+ csys1_funnel at 20130000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x20130000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* input port */
+ port at 0 {
+ reg = <0>;
+ csys1_funnel_out_port: endpoint {
+ remote-endpoint =
+ <&etf1_in_port>;
+ };
+ };
+
+ /* output port */
+ port at 1 {
+ reg = <0>;
+ csys1_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&stm_out_port>;
+ };
+ };
+
+ };
+ };
+
+ csys2_funnel at 20150000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x20150000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* output port */
+ port at 0 {
+ reg = <0>;
+ csys2_funnel_out_port: endpoint {
+ remote-endpoint =
+ <&replicator_in_port0>;
+ };
+ };
+
+ /* input ports */
+ port at 1 {
+ reg = <0>;
+ csys2_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etf0_out_port>;
+ };
+ };
+
+ port at 2 {
+ reg = <1>;
+ csys2_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint = <&etf1_out_port>;
+ };
+ };
+
+ };
+ };
+
+ tpiu at 20030000 {
+ compatible = "arm,coresight-tpiu", "arm,primecell";
+ reg = <0 0x20030000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ port {
+ tpiu_in_port: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out_port0>;
+ };
+ };
+ };
+
+ /*
+ * This is labelled cssys0 funnel in the Juno r1/r2 TRM
+ * Retain the name from r0 to maintain compatibility with common
+ * juno-base.dtsi
+ */
+ main-funnel at 20040000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x20040000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* output port */
+ port at 0 {
+ reg = <0>;
+ main_funnel_out_port: endpoint {
+ remote-endpoint = <&etf0_in_port>;
+ };
+ };
+
+ /* input ports */
+ port at 1 {
+ reg = <0>;
+ main_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&cluster0_funnel_out_port>;
+ };
+ };
+
+ port at 2 {
+ reg = <1>;
+ main_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint = <&cluster1_funnel_out_port>;
+ };
+ };
+ };
+ };
+
+ etr at 20070000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x20070000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ port {
+ etr_in_port: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out_port1>;
+ };
+ };
+ };
+
+ coresight-replicator {
+ /*
+ * Non-configurable replicators don't show up on the
+ * AMBA bus. As such no need to add "arm,primecell".
+ */
+ compatible = "arm,coresight-replicator";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* replicator output ports */
+ port at 0 {
+ reg = <0>;
+ replicator_out_port0: endpoint {
+ remote-endpoint = <&tpiu_in_port>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ replicator_out_port1: endpoint {
+ remote-endpoint = <&etr_in_port>;
+ };
+ };
+
+ /* replicator input port */
+ port at 2 {
+ reg = <0>;
+ replicator_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&csys2_funnel_out_port>;
+ };
+ };
+ };
+ };
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
index eec37fe..8813395 100644
--- a/arch/arm64/boot/dts/arm/juno-r1.dts
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -178,6 +178,7 @@
};
#include "juno-base.dtsi"
+ #include "juno-cs-r1r2.dtsi"
};
&memtimer {
diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts b/arch/arm64/boot/dts/arm/juno-r2.dts
index 28f40ec..fca3a17 100644
--- a/arch/arm64/boot/dts/arm/juno-r2.dts
+++ b/arch/arm64/boot/dts/arm/juno-r2.dts
@@ -178,6 +178,7 @@
};
#include "juno-base.dtsi"
+ #include "juno-cs-r1r2.dtsi"
};
&memtimer {
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index ac5ceb7..c90c37b 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -178,6 +178,7 @@
};
#include "juno-base.dtsi"
+ #include "juno-cs-r0.dtsi"
};
&etm0 {
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: juno: Adds missing CoreSight STM component.
From: Mike Leach @ 2017-01-11 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484167449-14432-1-git-send-email-mike.leach@linaro.org>
Add missing CoreSight STM component definition to Juno CoreSight
infrastructure juno-cs-rX.dtsi files.
Component connected to different funnels depending on Juno platform variant.
Signed-off-by: Mike Leach <mike.leach@linaro.org>
---
arch/arm64/boot/dts/arm/juno-cs-r0.dtsi | 16 ++++++++++++++++
arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 16 ++++++++++++++++
2 files changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/arm/juno-cs-r0.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r0.dtsi
index 24419ed..4e01b0e 100644
--- a/arch/arm64/boot/dts/arm/juno-cs-r0.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-cs-r0.dtsi
@@ -148,3 +148,19 @@
};
};
};
+
+ stm at 20100000 {
+ compatible = "arm,coresight-stm", "arm,primecell";
+ reg = <0 0x20100000 0 0x1000>,
+ <0 0x28000000 0 0x180000>;
+ reg-names = "stm-base", "stm-stimulus-base";
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ port {
+ stm_out_port: endpoint {
+ remote-endpoint = <&main_funnel_in_port2>;
+ };
+ };
+ };
diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
index caaf58e..6fe8b62 100644
--- a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
@@ -248,3 +248,19 @@
};
};
};
+
+ stm at 20100000 {
+ compatible = "arm,coresight-stm", "arm,primecell";
+ reg = <0 0x20100000 0 0x1000>,
+ <0 0x28000000 0 0x180000>;
+ reg-names = "stm-base", "stm-stimulus-base";
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ port {
+ stm_out_port: endpoint {
+ remote-endpoint = <&csys1_funnel_in_port0>;
+ };
+ };
+ };
--
2.7.4
^ permalink raw reply related
* [PATCHv3 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Sebastian Hesselbarth @ 2017-01-11 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaC+USN7YhZo49LAL9sorMxbTfhQbT5NrAu5D=Q1DHnnA@mail.gmail.com>
On 01/11/2017 03:44 PM, Linus Walleij wrote:
> On Fri, Jan 6, 2017 at 5:15 AM, Chris Packham
> <chris.packham@alliedtelesis.co.nz> wrote:
>
>> From: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>>
>> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
>> from Marvell.
>>
>> Signed-off-by: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>
> I am waiting for an ACK or comment from the maintainers on
> this patch. Sebastian?
Sorry for the ignorance.
I don't have the patch to reply to inline, but:
- In the driver MPP_MODE2, spi0 there is a typo "csk" instead of "sck".
- MPP_MODE5 binding "dev","bootcs" and driver "dev","bootcs0" differ.
- MPP_MODE6 binding "gpio" and driver "gpo" differ.
- MPP_MODE17 binding "dev","clk" and driver "dev","clkout" differ.
- MPP_MODE19 binding mentiones "dev","rb" but driver does not.
- MPP_MODE20 binding "gpio" and driver "gpo" differ.
- MPP_MODE20 binding "dev","we" and driver "dev","we0" differ.
- MPP_MODE21 through MPP_MODE30 binding "gpio" and driver "gpo" differ.
- remove spaces before "0, 0" in mv98dx3236_mpp_gpio_ranges.
Most of it is cosmetic stuff, so if you fix it feel free to add my
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Sebastian
^ permalink raw reply
* [RFC PATCH 09/10] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension
From: Kim Phillips @ 2017-01-11 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111123714.GK12388@arm.com>
On Wed, 11 Jan 2017 12:37:15 +0000
Will Deacon <will.deacon@arm.com> wrote:
> Hi Kim,
>
> On Tue, Jan 10, 2017 at 04:04:19PM -0600, Kim Phillips wrote:
> > On Tue, 3 Jan 2017 18:10:26 +0000
> > Will Deacon <will.deacon@arm.com> wrote:
> >
> > > +#define DRVNAME "arm_spe_pmu"
> >
> > Based on Intel naming "intel_pt" and "intel_bts', I had expected
> > "arm-spe" as the universal basename for SPE. I don't really care about
> > whether '_pmu' is included, but it's yet another naming inconsistency we
> > have with coresight's "cs_etm" (the other being prefixed with "arm_").
>
> It's consistent with the other PMUs under drivers/perf.
>
> > Also, nit, since I don't know why perf userspace tools can't handle
> > dashes in PMU names (commit 3d1ff755e367 "arm: perf: clean up PMU
> > names" doesn't say), can we at least start to use dashes in our
> > filenames? arm-spe-pmu.c is easier to type than arm_spe_pmu.c.
>
> I'd rather go for consistency both with the other PMU drivers under
> drivers/perf, but also with the PMU name itself.
Selecting a PMU naming consistency domain based on its driver's source
path doesn't accurately represent the naming consistency the user
expects. Not to mention there are only 2 out of 44 PMU device
registration callsites under drivers/perf...
> > > +static int arm_spe_pmu_event_init(struct perf_event *event)
> > > +{
> > > + u64 reg;
> > > + struct perf_event_attr *attr = &event->attr;
> > > + struct arm_spe_pmu *spe_pmu = to_spe_pmu(event->pmu);
> > > +
> > > + /* This is, of course, deeply driver-specific */
> > > + if (attr->type != event->pmu->type)
> > > + return -ENOENT;
> > > +
> > > + if (event->cpu >= 0 &&
> > > + !cpumask_test_cpu(event->cpu, &spe_pmu->supported_cpus))
> > > + return -ENOENT;
> > > +
> > > + if (arm_spe_event_to_pmsevfr(event) & PMSEVFR_EL1_RES0)
> > > + return -EOPNOTSUPP;
> > > +
> > > + if (event->hw.sample_period < spe_pmu->min_period ||
> > > + event->hw.sample_period & PMSIRR_EL1_IVAL_MASK)
> > > + return -EOPNOTSUPP;
> > > +
> > > + if (attr->exclude_idle)
> > > + return -EOPNOTSUPP;
> > > +
> > > + /*
> > > + * Feedback-directed frequency throttling doesn't work when we
> > > + * have a buffer of samples. We'd need to manually count the
> > > + * samples in the buffer when it fills up and adjust the event
> > > + * count to reflect that. Instead, force the user to specify a
> > > + * sample period instead.
> > > + */
> > > + if (attr->freq)
> > > + return -EINVAL;
> > > +
> > > + if (is_kernel_in_hyp_mode()) {
> > > + if (attr->exclude_kernel != attr->exclude_hv)
> > > + return -EOPNOTSUPP;
> > > + } else if (!attr->exclude_hv) {
> > > + return -EOPNOTSUPP;
> > > + }
> > > +
> > > + reg = arm_spe_event_to_pmsfcr(event);
> > > + if ((reg & BIT(PMSFCR_EL1_FE_SHIFT)) &&
> > > + !(spe_pmu->features & SPE_PMU_FEAT_FILT_EVT))
> > > + return -EOPNOTSUPP;
> > > +
> > > + if ((reg & BIT(PMSFCR_EL1_FT_SHIFT)) &&
> > > + !(spe_pmu->features & SPE_PMU_FEAT_FILT_TYP))
> > > + return -EOPNOTSUPP;
> > > +
> > > + if ((reg & BIT(PMSFCR_EL1_FL_SHIFT)) &&
> > > + !(spe_pmu->features & SPE_PMU_FEAT_FILT_LAT))
> > > + return -EOPNOTSUPP;
> > > +
> > > + return 0;
> > > +}
> >
> > Without being provided instructions on how to use, I had to add
> > debug printks here to find out e.g., an event period *must* be specified
> > with record -c, and then again to find out that only a certain set of
> > numbers is allowed by the h/w (256, 512, etc.). Is it possible to
> > report why the driver is returning an error before it does? Otherwise,
> > all the user sees is, e.g.:
> >
> > Error:
> > The sys_perf_event_open() syscall returned with 19 (No such device) for event (arm_spe_pmu_0).
> > /bin/dmesg may provide additional information.
> > No CONFIG_PERF_EVENTS=y kernel support configured?
> >
> > ...and, in this case, with nothing in dmesg. And, IIRC, the above text
> > is emitted only if perf is run with -v and/or built with DEBUG set.
> > Granted, *that* problem is not explicitly relevant to this patch, but
> > new drivers should nevertheless express their usage details better.
>
> I don't disagree that the error reporting from the driver up to userspace
> leaves much to be desired, but there currently isn't a sensible way to
> communicate the exact reason for failure back from event_init and I
> don't think we're different to other PMU drivers in this respect. Yes,
> you can paper around the problem using pr_debug, but that really only
> helps the developer writing the perf tool support, and much of the
> constraints can also be inferred from the architecture spec.
This applies to all users of the driver, not just the developer writing
the perf tool support. And users definitely shouldn't need to read the
architecture spec in order to use the feature.
> There were patches to allow providing strings back via perf_err:
>
> https://lkml.org/lkml/2015/8/24/506
>
> but I don't think it ended up getting merged. Other subsystems wanted to
> use the same approach, and there are ABI considerations with all of this
> (the thread is worth a read).
OK I didn't read everything, but meanwhile, we need to be making perf -
esp. as it's so clearly pointed out already - to be easier to use in
the time being. Like one of the threads' responses, *anything* is
better than blindly returning -EINVAL/-ENOTSUPP, etc. Please insert
pr_* statements before returning errors.
We can easily migrate from pr_* to perf_err (or equivalent) when
perf_err becomes available. Maintenance-wise, it is much more
efficient to do this at driver submission time, rather than waiting for
perf_err to be merged, since it's likely the code will be in the same
place.
> > Also, curiously, arm_spe_pmu doesn't appear in 'perf list' (even when
> > SPE h/w is present).
>
> Weird, it would be nice to understand why that is. The sysfs plumbing should
> all be there, so I'd expect to see something. On my laptop, for example,
> intel_pt appears as:
>
> intel_pt// [Kernel PMU event]
>
> and strace show perf doing the following:
>
> stat("/sys/bus/event_source/devices/intel_pt/format", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> open("/sys/bus/event_source/devices/intel_pt/format", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 82
> open("/sys/bus/event_source/devices/intel_pt/format/psb_period", O_RDONLY) = 83
> open("/sys/bus/event_source/devices/intel_pt/format/noretcomp", O_RDONLY) = 83
> open("/sys/bus/event_source/devices/intel_pt/format/tsc", O_RDONLY) = 83
> open("/sys/bus/event_source/devices/intel_pt/format/cyc_thresh", O_RDONLY) = 83
> open("/sys/bus/event_source/devices/intel_pt/format/mtc_period", O_RDONLY) = 83
> open("/sys/bus/event_source/devices/intel_pt/format/cyc", O_RDONLY) = 83
> open("/sys/bus/event_source/devices/intel_pt/format/mtc", O_RDONLY) = 83
> stat("/sys/bus/event_source/devices/intel_pt/events", 0x7ffe54eebb40) = -1 ENOENT (No such file or directory)
> stat("/sys/bus/event_source/devices/intel_pt/type", {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> open("/sys/bus/event_source/devices/intel_pt/type", O_RDONLY) = 82
> stat("/sys/bus/event_source/devices/intel_pt/cpumask", 0x7ffe54eedd60) = -1 ENOENT (No such file or directory)
> stat("/sys/bus/event_source/devices/intel_pt/cpus", 0x7ffe54eedd60) = -1 ENOENT (No such file or directory)
> stat("/sys/bus/event_source/devices/intel_pt/caps/mtc", {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> open("/sys/bus/event_source/devices/intel_pt/caps/mtc", O_RDONLY) = 82
> stat("/sys/bus/event_source/devices/intel_pt/caps/psb_cyc", {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> open("/sys/bus/event_source/devices/intel_pt/caps/psb_cyc", O_RDONLY) = 82
>
> What do you see for SPE?
2154 newfstatat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format", {st_mode=S_IFDIR|0755, st_size=0, ...}, 0) = 0
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 58
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/branch_filter", O_RDONLY) = 59
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/ts_enable", O_RDONLY) = 59
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/pa_enable", O_RDONLY) = 59
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/event_filter", O_RDONLY) = 59
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/load_filter", O_RDONLY) = 59
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/jitter", O_RDONLY) = 59
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/store_filter", O_RDONLY) = 59
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/min_latency", O_RDONLY) = 59
2154 newfstatat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/events", 0xffffcd6bb078, 0) = -1 ENOENT (No such file or directory)
2154 newfstatat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/type", {st_mode=S_IFREG|0444, st_size=4096, ...}, 0) = 0
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/type", O_RDONLY) = 58
2154 newfstatat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/cpumask", {st_mode=S_IFREG|0444, st_size=4096, ...}, 0) = 0
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/cpumask", O_RDONLY) = 58
they're identical up until /.../cpumask's stat, which exists on the
ARM SPE run (as opposed to the Intel run).
Kim
^ permalink raw reply
* [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Maxime Ripard @ 2017-01-11 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111200811.GA16865@uda0271908>
On Wed, Jan 11, 2017 at 02:08:11PM -0600, Bin Liu wrote:
> On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
> >
> >
> > 11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
> > > On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> > >> ?Lichee Pi Zero features a USB OTG port.
> > >>
> > >> ?Add support for it.
> > >>
> > >> ?Note: in order to use the Host mode, the board must be powered via the
> > >> ?+5V and GND pins.
> > >>
> > >> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> > >> ?---
> > >> ??arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
> > >> ??1 file changed, 10 insertions(+)
> > >>
> > >> ?diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> ?index 0099affc6ce3..3d9168cbaeca 100644
> > >> ?--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> ?+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> ?@@ -71,3 +71,13 @@
> > >> ??????????pinctrl-names = "default";
> > >> ??????????status = "okay";
> > >> ??};
> > >> ?+
> > >> ?+&usb_otg {
> > >> ?+ dr_mode = "otg";
> > >
> > > Why not set this default mode in dtsi instead?
> > >
> > > Regards,
> > > -Bin.
> >
> > There's possibly boards which do not have OTG functions.
>
> That is board specific.
Exactly, and this is why it should be done in the board DT.
The controller in the Allwinner SoCs do not handle directly the ID pin
and VBUS, but rather rely on a GPIO to do so.
So boards with OTG will need setup anyway, at least to tell which
GPIOs are used. There's no point in enforcing a default if it doesn't
work by default.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170111/2d54e75b/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Arnd Bergmann @ 2017-01-11 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484159512-28515-2-git-send-email-nikita.yoush@cogentembedded.com>
On Wednesday, January 11, 2017 9:31:51 PM CET Nikita Yushchenko wrote:
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index 9afcbf7..0995ab3 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -1096,7 +1096,7 @@ static int rk_iommu_domain_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> /* Set dma_ops for dev, otherwise it would be dummy_dma_ops */
> - arch_setup_dma_ops(dev, 0, DMA_BIT_MASK(32), NULL, false);
> + arch_setup_dma_ops(dev, 0, DMA_BIT_MASK(32), false, NULL, false);
>
> dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
> dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
> diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> index c9b7ad6..19f70d8 100644
> --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> @@ -2533,7 +2533,7 @@ static int dpaa_eth_probe(struct platform_device *pdev)
> priv->buf_layout[TX].priv_data_size = DPAA_TX_PRIV_DATA_SIZE; /* Tx */
>
> /* device used for DMA mapping */
> - arch_setup_dma_ops(dev, 0, 0, NULL, false);
> + arch_setup_dma_ops(dev, 0, 0, false, NULL, false);
> err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(40));
> if (err) {
> dev_err(dev, "dma_coerce_mask_and_coherent() failed\n");
> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> index 5ac373c..480b644 100644
> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
>
> /* Objects are coherent, unless 'no shareability' flag set. */
> if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY))
> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true);
>
> /*
> * The device-specific probe callback will get invoked by device_add()
Why are these actually calling arch_setup_dma_ops() here in the first
place? Are these all devices that are DMA masters without an OF node?
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index fd5cfad..1cc2115 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -89,6 +89,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
> bool coherent;
> unsigned long offset;
> const struct iommu_ops *iommu;
> + bool enforce_range = false;
>
> /*
> * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> @@ -126,6 +127,8 @@ void of_dma_configure(struct device *dev, struct device_node *np)
> return;
> }
> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
> +
> + enforce_range = true;
> }
>
> dev->dma_pfn_offset = offset;
Hmm, I think when the dma-ranges are missing, we should either enforce
a 32-bit mask, or disallow DMA completely. It's probably too late for
the latter, I wish we had done this earlier in order to force everyone
on ARM64 to have a valid dma-ranges property for any DMA master.
Arnd
^ permalink raw reply
* [PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports
From: Arnd Bergmann @ 2017-01-11 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484159512-28515-3-git-send-email-nikita.yoush@cogentembedded.com>
On Wednesday, January 11, 2017 9:31:52 PM CET Nikita Yushchenko wrote:
> @@ -959,6 +990,15 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> if (!dev->archdata.dma_ops)
> dev->archdata.dma_ops = &swiotlb_dma_ops;
>
> + /*
> + * Whatever the parent bus can set. A device must not set
> + * a DMA mask larger than this.
> + */
> + if (enforce_range)
> + dev->archdata.parent_dma_mask = size - 1;
> + else
> + dev->archdata.parent_dma_mask = DMA_BIT_MASK(64);
> +
> dev->archdata.dma_coherent = coherent;
> __iommu_setup_dma_ops(dev, dma_base, size, iommu);
>
Could we just pass the mask instead of the size here?
Arnd
^ permalink raw reply
* [PATCH net-next] net: thunderx: Fix error return code in nicvf_open()
From: David Miller @ 2017-01-11 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111163251.19367-1-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Wed, 11 Jan 2017 16:32:51 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: 712c31853440 ("net: thunderx: Program LMAC credits based on MTU")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* [PATCH] arm64: dts: exynos: Replace small letter of base address/offset on Exynos5433
From: Rob Herring @ 2017-01-11 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484096148-17120-1-git-send-email-cw00.choi@samsung.com>
On Wed, Jan 11, 2017 at 09:55:48AM +0900, Chanwoo Choi wrote:
> This patch replaces the small letter of base address, offset and hex value
> with the capital letter to keep the consistency on Exynos5433.
You mean the other way around, right?
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index abaf6b4d599d..d7ed1a68b6fd 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -231,7 +231,7 @@
> compatible = "arm,psci";
> method = "smc";
> cpu_off = <0x84000002>;
> - cpu_on = <0xC4000003>;
> + cpu_on = <0xc4000003>;
> };
>
> reboot: syscon-reboot {
> @@ -753,7 +753,7 @@
>
> dsi: dsi at 13900000 {
> compatible = "samsung,exynos5433-mipi-dsi";
> - reg = <0x13900000 0xC0>;
> + reg = <0x13900000 0xc0>;
> interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
> phys = <&mipi_phy 1>;
> phy-names = "dsim";
> @@ -880,9 +880,9 @@
> iommus = <&sysmmu_jpeg>;
> };
>
> - mfc: codec at 152E0000 {
> + mfc: codec at 152e0000 {
> compatible = "samsung,exynos5433-mfc";
> - reg = <0x152E0000 0x10000>;
> + reg = <0x152e0000 0x10000>;
> interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> clock-names = "pclk", "aclk", "aclk_xiu";
> clocks = <&cmu_mfc CLK_PCLK_MFC>,
> @@ -914,7 +914,7 @@
>
> sysmmu_gscl0: sysmmu at 13c80000 {
> compatible = "samsung,exynos-sysmmu";
> - reg = <0x13C80000 0x1000>;
> + reg = <0x13c80000 0x1000>;
> interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
> clock-names = "aclk", "pclk";
> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL0>,
> @@ -924,7 +924,7 @@
>
> sysmmu_gscl1: sysmmu at 13c90000 {
> compatible = "samsung,exynos-sysmmu";
> - reg = <0x13C90000 0x1000>;
> + reg = <0x13c90000 0x1000>;
> interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
> clock-names = "aclk", "pclk";
> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL1>,
> @@ -934,7 +934,7 @@
>
> sysmmu_gscl2: sysmmu at 13ca0000 {
> compatible = "samsung,exynos-sysmmu";
> - reg = <0x13CA0000 0x1000>;
> + reg = <0x13ca0000 0x1000>;
> interrupts = <GIC_SPI 292 IRQ_TYPE_LEVEL_HIGH>;
> clock-names = "aclk", "pclk";
> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL2>,
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] Documentation: dt: reset: Revise typos in TI syscon reset example
From: Rob Herring @ 2017-01-11 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109192814.26811-1-s-anna@ti.com>
On Mon, Jan 09, 2017 at 01:28:14PM -0600, Suman Anna wrote:
> Fix couple of typos in the example given in the TI syscon reset
> binding. The ti,reset-bits used for DSP0 are corrected to match
> the values that will be used in the actual DT node.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> Hi Philipp,
>
> This is the Documentation part fix that goes along with
> the ti-syscon-reset fix that you have on your next branch.
> I will be submitting the DT nodes very soon
>
> regards
> Suman
>
> Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
> index 164c7f34c451..21ba739b162e 100644
> --- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
> +++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
> @@ -63,7 +63,7 @@ Example:
> --------
> The following example demonstrates a syscon node, the reset controller node
> using the syscon node, and a consumer (a DSP device) on the TI Keystone 2
> -Edison SoC.
> +66AK2E SoC.
>
> / {
> soc {
> @@ -71,13 +71,13 @@ Edison SoC.
> compatible = "syscon", "simple-mfd";
> reg = <0x02350000 0x1000>;
>
> - pscrst: psc-reset {
> + pscrst: psc-reset-controller {
Really, this should be just 'reset-controller'.
Rob
^ permalink raw reply
* [PATCH v2 1/6] mmc: sunxi: Always set signal delay to 0 for A64
From: Maxime Ripard @ 2017-01-11 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <96ba5fd8-d551-5993-f347-202c47efec8c@arm.com>
On Tue, Jan 10, 2017 at 12:30:41AM +0000, Andr? Przywara wrote:
> On 09/01/17 16:46, Maxime Ripard wrote:
> > Experience have shown that the using the autocalibration could severely
> > degrade the performances of the MMC bus.
> >
> > Allwinner is using in its BSP a delay set to 0 for all the modes but HS400.
> > Remove the calibration code for now, and add comments to document our
> > findings.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > drivers/mmc/host/sunxi-mmc.c | 50 ++++++++++++-------------------------
> > 1 file changed, 17 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> > index b1d1303389a7..ea9552a0d820 100644
> > --- a/drivers/mmc/host/sunxi-mmc.c
> > +++ b/drivers/mmc/host/sunxi-mmc.c
> > @@ -683,41 +683,19 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
> >
> > static int sunxi_mmc_calibrate(struct sunxi_mmc_host *host, int reg_off)
> > {
> > - u32 reg = readl(host->reg_base + reg_off);
> > - u32 delay;
> > - unsigned long timeout;
> > -
> > if (!host->cfg->can_calibrate)
> > return 0;
> >
> > - reg &= ~(SDXC_CAL_DL_MASK << SDXC_CAL_DL_SW_SHIFT);
> > - reg &= ~SDXC_CAL_DL_SW_EN;
> > -
> > - writel(reg | SDXC_CAL_START, host->reg_base + reg_off);
> > -
> > - dev_dbg(mmc_dev(host->mmc), "calibration started\n");
> > -
> > - timeout = jiffies + HZ * SDXC_CAL_TIMEOUT;
> > -
> > - while (!((reg = readl(host->reg_base + reg_off)) & SDXC_CAL_DONE)) {
> > - if (time_before(jiffies, timeout))
> > - cpu_relax();
> > - else {
> > - reg &= ~SDXC_CAL_START;
> > - writel(reg, host->reg_base + reg_off);
> > -
> > - return -ETIMEDOUT;
> > - }
> > - }
> > -
> > - delay = (reg >> SDXC_CAL_DL_SHIFT) & SDXC_CAL_DL_MASK;
> > -
> > - reg &= ~SDXC_CAL_START;
> > - reg |= (delay << SDXC_CAL_DL_SW_SHIFT) | SDXC_CAL_DL_SW_EN;
> > -
> > - writel(reg, host->reg_base + reg_off);
> > -
> > - dev_dbg(mmc_dev(host->mmc), "calibration ended, reg is 0x%x\n", reg);
> > + /*
> > + * FIXME:
> > + * This is not clear how the calibration is supposed to work
> > + * yet. The best rate have been obtained by simply setting the
> > + * delay to 0, as Allwinner does in its BSP.
> > + *
> > + * The only mode that doesn't have such a delay is HS400, that
> > + * is in itself a TODO.
> > + */
> > + writel(SDXC_CAL_DL_SW_EN, host->reg_base + reg_off);
> >
> > return 0;
> > }
> > @@ -806,7 +784,13 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
> > if (ret)
> > return ret;
> >
> > - /* TODO: enable calibrate on sdc2 SDXC_REG_DS_DL_REG of A64 */
> > + /*
> > + * FIXME:
> > + *
> > + * In HS400 we'll also need to calibrate the data strobe
> > + * signal. This should only happen on the MMC2 controller (at
> > + * least on the A64 and older SoCs).
>
> Which older SoCs have this calibration register and a DS signal?
> Is that supposed to mean "other" SoCs?
That was supposed to mean that newer (than A64) SoCs might have that
calibration on other controllers than MMC2. But you're right that it
actually applies only to A64 anyway, I'll remove the and older part.
> Other than that:
>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170111/1c8767ce/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: dts: exynos: Replace small letter of base address/offset on Exynos5433
From: Chanwoo Choi @ 2017-01-11 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162613.lxkc7k75f6q3fsz2@kozik-lap>
2017-01-12 1:26 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> On Wed, Jan 11, 2017 at 09:55:48AM +0900, Chanwoo Choi wrote:
>> This patch replaces the small letter of base address, offset and hex value
>> with the capital letter to keep the consistency on Exynos5433.
>>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 +++++++-------
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> index abaf6b4d599d..d7ed1a68b6fd 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> @@ -231,7 +231,7 @@
>> compatible = "arm,psci";
>> method = "smc";
>> cpu_off = <0x84000002>;
>> - cpu_on = <0xC4000003>;
>> + cpu_on = <0xc4000003>;
>
> There is no point of such "improvements". This is just unnecessary
> churn.
>
> Sometimes such things are accepted as part of some bigger work (vide
> recent Andrzej's sysmmu for HDMI/TV). But on its own? No sense at all.
Do you mean that this patch is not reasonable? or
The modification of cpu_on property is only not reasonable?
It is simple for the consistency to use the hex value in dts file.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [PATCH 1/2] Documentation: devicetree: Add document bindings for mtk-cir
From: Rob Herring @ 2017-01-11 21:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484015754.4057.4.camel@mtkswgap22>
On Mon, Jan 9, 2017 at 8:35 PM, Sean Wang <sean.wang@mediatek.com> wrote:
> Hi Rob,
>
> thanks for your effort for reviewing. I added comments inline.
>
> On Mon, 2017-01-09 at 12:32 -0600, Rob Herring wrote:
>> On Fri, Jan 06, 2017 at 12:06:23AM +0800, sean.wang at mediatek.com wrote:
>> > From: Sean Wang <sean.wang@mediatek.com>
>> >
>> > This patch adds documentation for devicetree bindings for
>> > Mediatek IR controller.
>> >
>> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
>> > ---
>> > .../devicetree/bindings/media/mtk-cir.txt | 23 ++++++++++++++++++++++
>> > 1 file changed, 23 insertions(+)
>> > create mode 100644 linux-4.8.rc1_p0/Documentation/devicetree/bindings/media/mtk-cir.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt b/Documentation/devicetree/bindings/media/mtk-cir.txt
>> > new file mode 100644
>> > index 0000000..bbedd71
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
>> > @@ -0,0 +1,23 @@
>> > +Device-Tree bindings for Mediatek IR controller found in Mediatek SoC family
>> > +
>> > +Required properties:
>> > +- compatible : "mediatek,mt7623-ir"
>> > +- clocks : list of clock specifiers, corresponding to
>> > + entries in clock-names property;
>> > +- clock-names : should contain "clk" entries;
>> > +- interrupts : should contain IR IRQ number;
>> > +- reg : should contain IO map address for IR.
>> > +
>> > +Optional properties:
>> > +- linux,rc-map-name : Remote control map name.
>>
>> Would 'label' be appropriate here instead? If not, this needs to be
>> documented in a common location and explained better.
>>
> I checked with how the way applied in other IR drivers is and found that
> most IR driver also use the same label to identify the scan/key table
> they prefer to use such as gpio-ir-recv, ir-hix5hd2, meson-ir and
> sunxi-cir or use hard coding inside the driver. So I thought it should
> be appropriate here currently.
Maybe so, but anything with linux prefix gets extra scrutiny and I'm
not sure that happened on the previous cases. If label has the same
meaning, then we should start using that and deprecate this property.
In any case, a property used by multiple bindings needs to be
documented in a common place. The explanation of the property is bad
too. It just spells out RC with no explanation. I'm sure you just
copy-n-pasted it from the others, but that doesn't make it okay.
Rob
^ permalink raw reply
* [PATCH] arm64: dts: exynos: Replace small letter of base address/offset on Exynos5433
From: Chanwoo Choi @ 2017-01-11 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111211503.6kwqaunb5mpe6eb2@rob-hp-laptop>
2017-01-12 6:15 GMT+09:00 Rob Herring <robh@kernel.org>:
> On Wed, Jan 11, 2017 at 09:55:48AM +0900, Chanwoo Choi wrote:
>> This patch replaces the small letter of base address, offset and hex value
>> with the capital letter to keep the consistency on Exynos5433.
>
> You mean the other way around, right?
When I posted the dts patches, I got the comment that small letter is better
for base address/offset. (It doesn?t mean that all dts file in Linux Kernel
have to use the small letter of base address and offset.)
This dts uses the both capital and small letter for each base address/offset.
Almost hex value already uses the small letter. If possible, I hope to use
the one style (small letter).
>
>>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 +++++++-------
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> index abaf6b4d599d..d7ed1a68b6fd 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> @@ -231,7 +231,7 @@
>> compatible = "arm,psci";
>> method = "smc";
>> cpu_off = <0x84000002>;
>> - cpu_on = <0xC4000003>;
>> + cpu_on = <0xc4000003>;
>> };
>>
>> reboot: syscon-reboot {
>> @@ -753,7 +753,7 @@
>>
>> dsi: dsi at 13900000 {
>> compatible = "samsung,exynos5433-mipi-dsi";
>> - reg = <0x13900000 0xC0>;
>> + reg = <0x13900000 0xc0>;
>> interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
>> phys = <&mipi_phy 1>;
>> phy-names = "dsim";
>> @@ -880,9 +880,9 @@
>> iommus = <&sysmmu_jpeg>;
>> };
>>
>> - mfc: codec at 152E0000 {
>> + mfc: codec at 152e0000 {
>> compatible = "samsung,exynos5433-mfc";
>> - reg = <0x152E0000 0x10000>;
>> + reg = <0x152e0000 0x10000>;
>> interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
>> clock-names = "pclk", "aclk", "aclk_xiu";
>> clocks = <&cmu_mfc CLK_PCLK_MFC>,
>> @@ -914,7 +914,7 @@
>>
>> sysmmu_gscl0: sysmmu at 13c80000 {
>> compatible = "samsung,exynos-sysmmu";
>> - reg = <0x13C80000 0x1000>;
>> + reg = <0x13c80000 0x1000>;
>> interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
>> clock-names = "aclk", "pclk";
>> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL0>,
>> @@ -924,7 +924,7 @@
>>
>> sysmmu_gscl1: sysmmu at 13c90000 {
>> compatible = "samsung,exynos-sysmmu";
>> - reg = <0x13C90000 0x1000>;
>> + reg = <0x13c90000 0x1000>;
>> interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
>> clock-names = "aclk", "pclk";
>> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL1>,
>> @@ -934,7 +934,7 @@
>>
>> sysmmu_gscl2: sysmmu at 13ca0000 {
>> compatible = "samsung,exynos-sysmmu";
>> - reg = <0x13CA0000 0x1000>;
>> + reg = <0x13ca0000 0x1000>;
>> interrupts = <GIC_SPI 292 IRQ_TYPE_LEVEL_HIGH>;
>> clock-names = "aclk", "pclk";
>> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL2>,
>> --
>> 1.9.1
>>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Rob Herring @ 2017-01-11 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7bd282d9-df6f-f4c6-1f7f-c8ed81c78af3@ti.com>
On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
> Rob,
>
> On 01/09/2017 11:50 AM, Rob Herring wrote:
>>
>> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>>>
>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>> will hook into the genpd framework and allow the TI SCI protocol to
>>> control device power states.
>>>
>>> Also, provide macros representing each device index as understood
>>> by TI SCI to be used in the device node power-domain references.
>>> These are identifiers for the K2G devices managed by the PMMC.
>>>
>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>> ---
>>> v2->v3:
>>> Update k2g_pds node docs to show it should be a child of pmmc
>>> node.
>>> In early versions a phandle was used to point to pmmc and docs
>>> still
>>> incorrectly showed this.
>>>
>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59 ++++++++++++++
>>> MAINTAINERS | 2 +
>>> include/dt-bindings/genpd/k2g.h | 90
>>> ++++++++++++++++++++++
>>> 3 files changed, 151 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> new file mode 100644
>>> index 000000000000..4c9064e512cb
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> @@ -0,0 +1,59 @@
>>> +Texas Instruments TI-SCI Generic Power Domain
>>> +---------------------------------------------
>>> +
>>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>>> +responsible for controlling the state of the IPs that are present.
>>> +Communication between the host processor running an OS and the system
>>> +controller happens through a protocol known as TI-SCI [1]. This pm
>>> domain
>>> +implementation plugs into the generic pm domain framework and makes use
>>> of
>>> +the TI SCI protocol power on and off each device when needed.
>>> +
>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>> +
>>> +PM Domain Node
>>> +==============
>>> +The PM domain node represents the global PM domain managed by the PMMC,
>>> +which in this case is the single implementation as documented by the
>>> generic
>>> +PM domain bindings in
>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>> +Because this relies on the TI SCI protocol to communicate with the PMMC
>>> it
>>> +must be a child of the pmmc node.
>>> +
>>> +Required Properties:
>>> +--------------------
>>> +- compatible: should be "ti,sci-pm-domain"
>>> +- #power-domain-cells: Must be 0.
>>> +
>>> +Example (K2G):
>>> +-------------
>>> + pmmc: pmmc {
>>> + compatible = "ti,k2g-sci";
>>> + ...
>>> +
>>> + k2g_pds: k2g_pds {
>>> + compatible = "ti,sci-pm-domain";
>>> + #power-domain-cells = <0>;
>>> + };
>>> + };
>>> +
>>> +PM Domain Consumers
>>> +===================
>>> +Hardware blocks that require SCI control over their state must provide
>>> +a reference to the sci-pm-domain they are part of and a unique device
>>> +specific ID that identifies the device.
>>> +
>>> +Required Properties:
>>> +--------------------
>>> +- power-domains: phandle pointing to the corresponding PM domain node.
>>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>>> + be used for device control.
>>
>>
>> As I've already stated before, this goes in power-domain cells. When you
>> have a single thing (i.e. node) that controls multiple things, then you
>> you need to specify the ID for each of them in phandle args. This is how
>> irqs, gpio, clocks, *everything* in DT works.
>
>
> You think the reasoning for doing it this way provided by both Ulf and
> myself on v2 [1] is not valid then?
>
> From Ulf:
>
> To me, the TI SCI ID, is similar to a "conid" for any another "device
> resource" (like clock, pinctrl, regulator etc) which we can describe
> in DT and assign to a device node. The only difference here, is that
> we don't have common API to fetch the resource (like clk_get(),
> regulator_get()), but instead we fetches the device's resource from
> SoC specific code, via genpd's device ->attach() callback.
Sorry, but that sounds like a kernel problem to me and has nothing to
do with DT bindings.
> From me:
>
> Yes, you've pretty much hit it on the head. It is not an index into a list
> of genpds but rather identifies the device *within* a single genpd. It is a
> property specific to each device that resides in a ti-sci-genpd, not a
> mapping describing which genpd the device belongs to. The generic power
> domain binding is concerned with mapping the device to a specific genpd,
> which is does fine for us, but we have a sub mapping for devices that exist
> inside a genpd which, we must describe as well, hence the ti,sci-id.
>
>
> So to summarize, the genpd framework does interpret the phandle arg as an
> index into multiple genpds, just as you've said other frameworks do, but
> this is not what I am trying to do, we have multiple devices within this
> *single* genpd, hence the need for the ti,sci-id property.
Fix the genpd framework rather than work around it in DT.
Rob
^ permalink raw reply
* [PATCH] Documentation: dt: reset: Revise typos in TI syscon reset example
From: Suman Anna @ 2017-01-11 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111211520.w3sy5pkvjydiwvcs@rob-hp-laptop>
On 01/11/2017 03:15 PM, Rob Herring wrote:
> On Mon, Jan 09, 2017 at 01:28:14PM -0600, Suman Anna wrote:
>> Fix couple of typos in the example given in the TI syscon reset
>> binding. The ti,reset-bits used for DSP0 are corrected to match
>> the values that will be used in the actual DT node.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> ---
>> Hi Philipp,
>>
>> This is the Documentation part fix that goes along with
>> the ti-syscon-reset fix that you have on your next branch.
>> I will be submitting the DT nodes very soon
>>
>> regards
>> Suman
>>
>> Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
>> index 164c7f34c451..21ba739b162e 100644
>> --- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
>> +++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
>> @@ -63,7 +63,7 @@ Example:
>> --------
>> The following example demonstrates a syscon node, the reset controller node
>> using the syscon node, and a consumer (a DSP device) on the TI Keystone 2
>> -Edison SoC.
>> +66AK2E SoC.
>>
>> / {
>> soc {
>> @@ -71,13 +71,13 @@ Edison SoC.
>> compatible = "syscon", "simple-mfd";
>> reg = <0x02350000 0x1000>;
>>
>> - pscrst: psc-reset {
>> + pscrst: psc-reset-controller {
>
> Really, this should be just 'reset-controller'.
Thanks Rob, I will fix this patch and the DTS patches as well.
regards
Suman
^ permalink raw reply
* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: Bjorn Helgaas @ 2017-01-11 22:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111194942.q5rdma2es6hkmxfe@perseus.defre.kleine-koenig.org>
Hi Uwe,
On Wed, Jan 11, 2017 at 08:49:46PM +0100, Uwe Kleine-K?nig wrote:
> Hello,
>
> on an Marvell Armada 385 based machine (Turris Omnia) with 4.9 the
> ath10k driver fails to bind to the matching hardware if CONFIG_PCIEASPM
> is enabled:
>
> # dmesg | grep ath
> [ 7.207770] ath10k_pci 0000:02:00.0: Refused to change power state, currently in D3
> [ 7.237955] ath10k_pci 0000:02:00.0: failed to wake up device : -110
> [ 7.238146] ath10k_pci: probe of 0000:02:00.0 failed with error -110
>
> if however PCIEASPM is off, the driver probes correctly and the ath10k
> adapter works fine.
>
> I wonder if someone has an idea what needs to be done to fix this
> problem. (OK, I could disable PCIEASPM, but I'd like to have a solution
> for a distribution kernel where I think PCIEASPM=y is sensible in
> general.)
PCIEASPM=y is definitely sensible and disabling ASPM is OK for a
workaround but is not a fix.
We have several open issues related to ASPM:
https://bugzilla.kernel.org/show_bug.cgi?id=102311 ASPM: ASMEDA asm1062 not working
https://bugzilla.kernel.org/show_bug.cgi?id=187731 Null pointer dereference in ASPM
https://bugzilla.kernel.org/show_bug.cgi?id=189951 Enabling ASPM causes NIC performance issue
https://bugzilla.kernel.org/show_bug.cgi?id=60111 NULL pointer deref in ASPM alloc_pcie_link_state()
I don't recognize yours as being one of these. Can you open a new
issue and attach the complete dmesg log and "lspci -vv" output?
Is this a regression?
Bjorn
^ permalink raw reply
* [Patch v3 0/2] Support ARM SMCC SoC vendor quirks
From: Andy Gross @ 2017-01-11 22:31 UTC (permalink / raw)
To: linux-arm-kernel
At least one SoC vendor (Qualcomm) requires additional processing done
during ARM SMCCC calls. As such, an additional parameter to the
arm_smccc_smc is required to be able to handle SoC specific quirks.
The Qualcomm quirk is necessary due to the fact that the scm call can
be interrupted on Qualcomm ARM64 platforms. When this occurs, the
call must be restarted using information that was passed back during
the original smc call.
The first patch in this series adds a quirk structure and also adds a
quirk parameter to arm_smccc_smc calls. I added macros to allow users
to choose the API they need. This keeps all of the current users who
do not need quirks from having to change anything.
The second patch adds the Qualcomm quirk and also implements the
Qualcomm firmware changes required to handle the restarting of the
interrupted SMC call.
The original patch set for the SMCCC session ID is located at:
https://lkml.org/lkml/2016/8/20/7
Changes from v2:
- Use variadic macros
Changes from v1:
- Add macros to handle both use cases per review comments
Andy Gross (2):
arm: kernel: Add SMC structure parameter
firmware: qcom: scm: Fix interrupted SCM calls
arch/arm/kernel/armksyms.c | 2 +-
arch/arm/kernel/smccc-call.S | 7 ++++---
arch/arm64/kernel/arm64ksyms.c | 2 +-
arch/arm64/kernel/asm-offsets.c | 7 +++++--
arch/arm64/kernel/smccc-call.S | 16 ++++++++++++----
drivers/firmware/qcom_scm-64.c | 13 ++++++++++---
include/linux/arm-smccc.h | 37 ++++++++++++++++++++++++++++++-------
7 files changed, 63 insertions(+), 21 deletions(-)
--
1.9.1
^ permalink raw reply
* [Patch v3 1/2] arm: kernel: Add SMC structure parameter
From: Andy Gross @ 2017-01-11 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484173918-25090-1-git-send-email-andy.gross@linaro.org>
This patch adds a quirk parameter to the arm_smccc_smc call. The quirk
structure allows for specialized SMC operations due to SoC specific
requirements. The current arm_smccc_smc is renamed and macros are used
instead to specify the standard arm_smccc_smc or the arm_smccc_smc_quirk
function.
This patch and partial implementation was suggested by Will Deacon.
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Reviewed-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/kernel/armksyms.c | 2 +-
arch/arm/kernel/smccc-call.S | 7 ++++---
arch/arm64/kernel/arm64ksyms.c | 2 +-
arch/arm64/kernel/asm-offsets.c | 7 +++++--
arch/arm64/kernel/smccc-call.S | 7 ++++---
include/linux/arm-smccc.h | 26 ++++++++++++++++++++++----
6 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
index 7e45f69..c2a8e79 100644
--- a/arch/arm/kernel/armksyms.c
+++ b/arch/arm/kernel/armksyms.c
@@ -178,6 +178,6 @@
#endif
#ifdef CONFIG_HAVE_ARM_SMCCC
-EXPORT_SYMBOL(arm_smccc_smc);
+EXPORT_SYMBOL(__arm_smccc_smc);
EXPORT_SYMBOL(arm_smccc_hvc);
#endif
diff --git a/arch/arm/kernel/smccc-call.S b/arch/arm/kernel/smccc-call.S
index 2e48b67..eb666d7 100644
--- a/arch/arm/kernel/smccc-call.S
+++ b/arch/arm/kernel/smccc-call.S
@@ -46,11 +46,12 @@ UNWIND( .fnend)
/*
* void smccc_smc(unsigned long a0, unsigned long a1, unsigned long a2,
* unsigned long a3, unsigned long a4, unsigned long a5,
- * unsigned long a6, unsigned long a7, struct arm_smccc_res *res)
+ * unsigned long a6, unsigned long a7, struct arm_smccc_res *res,
+ * struct arm_smccc_quirk *quirk)
*/
-ENTRY(arm_smccc_smc)
+ENTRY(__arm_smccc_smc)
SMCCC SMCCC_SMC
-ENDPROC(arm_smccc_smc)
+ENDPROC(__arm_smccc_smc)
/*
* void smccc_hvc(unsigned long a0, unsigned long a1, unsigned long a2,
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index 78f3680..43370a0 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -73,5 +73,5 @@
#endif
/* arm-smccc */
-EXPORT_SYMBOL(arm_smccc_smc);
+EXPORT_SYMBOL(__arm_smccc_smc);
EXPORT_SYMBOL(arm_smccc_hvc);
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index bc049af..b3bb7ef 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -143,8 +143,11 @@ int main(void)
DEFINE(SLEEP_STACK_DATA_SYSTEM_REGS, offsetof(struct sleep_stack_data, system_regs));
DEFINE(SLEEP_STACK_DATA_CALLEE_REGS, offsetof(struct sleep_stack_data, callee_saved_regs));
#endif
- DEFINE(ARM_SMCCC_RES_X0_OFFS, offsetof(struct arm_smccc_res, a0));
- DEFINE(ARM_SMCCC_RES_X2_OFFS, offsetof(struct arm_smccc_res, a2));
+ DEFINE(ARM_SMCCC_RES_X0_OFFS, offsetof(struct arm_smccc_res, a0));
+ DEFINE(ARM_SMCCC_RES_X2_OFFS, offsetof(struct arm_smccc_res, a2));
+ DEFINE(ARM_SMCCC_QUIRK_ID_OFFS, offsetof(struct arm_smccc_quirk, id));
+ DEFINE(ARM_SMCCC_QUIRK_STATE_OFFS, offsetof(struct arm_smccc_quirk, state));
+
BLANK();
DEFINE(HIBERN_PBE_ORIG, offsetof(struct pbe, orig_address));
DEFINE(HIBERN_PBE_ADDR, offsetof(struct pbe, address));
diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
index ae0496f..6290696 100644
--- a/arch/arm64/kernel/smccc-call.S
+++ b/arch/arm64/kernel/smccc-call.S
@@ -27,11 +27,12 @@
/*
* void arm_smccc_smc(unsigned long a0, unsigned long a1, unsigned long a2,
* unsigned long a3, unsigned long a4, unsigned long a5,
- * unsigned long a6, unsigned long a7, struct arm_smccc_res *res)
+ * unsigned long a6, unsigned long a7, struct arm_smccc_res *res,
+ * struct arm_smccc_quirk *quirk)
*/
-ENTRY(arm_smccc_smc)
+ENTRY(__arm_smccc_smc)
SMCCC smc
-ENDPROC(arm_smccc_smc)
+ENDPROC(__arm_smccc_smc)
/*
* void arm_smccc_hvc(unsigned long a0, unsigned long a1, unsigned long a2,
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index b5abfda..3e28d08 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -72,19 +72,33 @@ struct arm_smccc_res {
};
/**
- * arm_smccc_smc() - make SMC calls
+ * struct arm_smccc_quirk - Contains quirk information
+ * id contains quirk identification
+ * state contains the quirk specific information
+ */
+struct arm_smccc_quirk {
+ int id;
+ union {
+ unsigned long a6;
+ } state;
+};
+
+/**
+ * __arm_smccc_smc() - make SMC calls
* @a0-a7: arguments passed in registers 0 to 7
* @res: result values from registers 0 to 3
+ * @quirk: optional quirk structure
*
* This function is used to make SMC calls following SMC Calling Convention.
* The content of the supplied param are copied to registers 0 to 7 prior
* to the SMC instruction. The return values are updated with the content
- * from register 0 to 3 on return from the SMC instruction.
+ * from register 0 to 3 on return from the SMC instruction. An optional
+ * quirk structure provides vendor specific behavior.
*/
-asmlinkage void arm_smccc_smc(unsigned long a0, unsigned long a1,
+asmlinkage void __arm_smccc_smc(unsigned long a0, unsigned long a1,
unsigned long a2, unsigned long a3, unsigned long a4,
unsigned long a5, unsigned long a6, unsigned long a7,
- struct arm_smccc_res *res);
+ struct arm_smccc_res *res, struct arm_smccc_quirk *quirk);
/**
* arm_smccc_hvc() - make HVC calls
@@ -101,4 +115,8 @@ asmlinkage void arm_smccc_hvc(unsigned long a0, unsigned long a1,
unsigned long a5, unsigned long a6, unsigned long a7,
struct arm_smccc_res *res);
+#define arm_smccc_smc(...) __arm_smccc_smc(__VA_ARGS__, NULL)
+
+#define arm_smccc_smc_quirk(...) __arm_smccc_smc(__VA_ARGS__)
+
#endif /*__LINUX_ARM_SMCCC_H*/
--
1.9.1
^ permalink raw reply related
* [Patch v3 2/2] firmware: qcom: scm: Fix interrupted SCM calls
From: Andy Gross @ 2017-01-11 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484173918-25090-1-git-send-email-andy.gross@linaro.org>
This patch adds a Qualcomm specific quirk to the arm_smccc_smc call.
On Qualcomm ARM64 platforms, the SMC call can return before it has
completed. If this occurs, the call can be restarted, but it requires
using the returned session ID value from the interrupted SMC call.
The quirk stores off the session ID from the interrupted call in the
quirk structure so that it can be used by the caller.
This patch folds in a fix given by Sricharan R:
https://lkml.org/lkml/2016/9/28/272
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Reviewed-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/smccc-call.S | 9 ++++++++-
drivers/firmware/qcom_scm-64.c | 13 ++++++++++---
include/linux/arm-smccc.h | 11 ++++++++---
3 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
index 6290696..72ecdca 100644
--- a/arch/arm64/kernel/smccc-call.S
+++ b/arch/arm64/kernel/smccc-call.S
@@ -12,6 +12,7 @@
*
*/
#include <linux/linkage.h>
+#include <linux/arm-smccc.h>
#include <asm/asm-offsets.h>
.macro SMCCC instr
@@ -20,7 +21,13 @@
ldr x4, [sp]
stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
- ret
+ ldr x4, [sp, #8]
+ cbz x4, 1f /* no quirk structure */
+ ldr x9, [x4, #ARM_SMCCC_QUIRK_ID_OFFS]
+ cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6
+ b.ne 1f
+ str x6, [x4, ARM_SMCCC_QUIRK_STATE_OFFS]
+1: ret
.cfi_endproc
.endm
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 4a0f5ea..1e2e519 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -91,6 +91,7 @@ static int qcom_scm_call(struct device *dev, u32 svc_id, u32 cmd_id,
dma_addr_t args_phys = 0;
void *args_virt = NULL;
size_t alloc_len;
+ struct arm_smccc_quirk quirk = {.id = ARM_SMCCC_QUIRK_QCOM_A6};
if (unlikely(arglen > N_REGISTER_ARGS)) {
alloc_len = N_EXT_QCOM_SCM_ARGS * sizeof(u64);
@@ -131,10 +132,16 @@ static int qcom_scm_call(struct device *dev, u32 svc_id, u32 cmd_id,
qcom_smccc_convention,
ARM_SMCCC_OWNER_SIP, fn_id);
+ quirk.state.a6 = 0;
+
do {
- arm_smccc_smc(cmd, desc->arginfo, desc->args[0],
- desc->args[1], desc->args[2], x5, 0, 0,
- res);
+ arm_smccc_smc_quirk(cmd, desc->arginfo, desc->args[0],
+ desc->args[1], desc->args[2], x5,
+ quirk.state.a6, 0, res, &quirk);
+
+ if (res->a0 == QCOM_SCM_INTERRUPTED)
+ cmd = res->a0;
+
} while (res->a0 == QCOM_SCM_INTERRUPTED);
mutex_unlock(&qcom_scm_lock);
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 3e28d08..9ca3a10 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -14,9 +14,6 @@
#ifndef __LINUX_ARM_SMCCC_H
#define __LINUX_ARM_SMCCC_H
-#include <linux/linkage.h>
-#include <linux/types.h>
-
/*
* This file provides common defines for ARM SMC Calling Convention as
* specified in
@@ -60,6 +57,13 @@
#define ARM_SMCCC_OWNER_TRUSTED_OS 50
#define ARM_SMCCC_OWNER_TRUSTED_OS_END 63
+#define ARM_SMCCC_QUIRK_NONE 0
+#define ARM_SMCCC_QUIRK_QCOM_A6 1 /* Save/restore register a6 */
+
+#ifndef __ASSEMBLY__
+
+#include <linux/linkage.h>
+#include <linux/types.h>
/**
* struct arm_smccc_res - Result from SMC/HVC call
* @a0-a3 result values from registers 0 to 3
@@ -119,4 +123,5 @@ asmlinkage void arm_smccc_hvc(unsigned long a0, unsigned long a1,
#define arm_smccc_smc_quirk(...) __arm_smccc_smc(__VA_ARGS__)
+#endif /*__ASSEMBLY__*/
#endif /*__LINUX_ARM_SMCCC_H*/
--
1.9.1
^ permalink raw reply related
* [PATCH] firmware: qcom: scm: Mask APQ8064 core clk dependency
From: Andy Gross @ 2017-01-11 22:58 UTC (permalink / raw)
To: linux-arm-kernel
This patch masks the core clk requirement for the APQ8064. Until the
other peripherals correctly describe their clock dependencies or the
bus driver is put in place to handle the RPM dependencies, this bit
will remain masked.
Signed-off-by: Andy Gross <andy.gross@linaro.org>
---
drivers/firmware/qcom_scm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 893f953ea..65d0d9d 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -387,7 +387,7 @@ static int qcom_scm_probe(struct platform_device *pdev)
static const struct of_device_id qcom_scm_dt_match[] = {
{ .compatible = "qcom,scm-apq8064",
- .data = (void *) SCM_HAS_CORE_CLK,
+ /* FIXME: This should have .data = (void *) SCM_HAS_CORE_CLK */
},
{ .compatible = "qcom,scm-msm8660",
.data = (void *) SCM_HAS_CORE_CLK,
--
1.9.1
^ permalink raw reply related
* [PATCH v3 00/24] i.MX Media Driver
From: Tim Harvey @ 2017-01-11 23:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483755102-24785-1-git-send-email-steve_longerbeam@mentor.com>
On Fri, Jan 6, 2017 at 6:11 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
> In version 3:
>
> Changes suggested by Rob Herring <robh@kernel.org>:
>
> - prepended FIM node properties with vendor prefix "fsl,".
>
> - make mipi csi-2 receiver compatible string SoC specific:
> "fsl,imx6-mipi-csi2" instead of "fsl,imx-mipi-csi2".
>
> - redundant "_clk" removed from mipi csi-2 receiver clock-names property.
>
> - removed board-specific info from the media driver binding doc. These
> were all related to sensor bindings, which already are (adv7180)
> or will be (ov564x) covered in separate binding docs. All reference
> board info not related to DT bindings has been moved to
> Documentation/media/v4l-drivers/imx.rst.
>
> - removed "_mipi" from the OV5640 compatible string.
>
> Changes suggested by Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>:
>
> Mostly cosmetic/non-functional changes which I won't list here, except
> for the following:
>
> - spin_lock_irqsave() changed to spin_lock() in a couple interrupt handlers.
>
> - fixed some unnecessary of_node_put()'s in for_each_child_of_node() loops.
>
> - check/handle return code from required reg property of CSI port nodes.
>
> - check/handle return code from clk_prepare_enable().
>
> Changes suggested by Fabio Estevam <festevam@gmail.com>:
>
> - switch to VGEN3 Analog Vdd supply assuming rev. C SabreSD boards.
>
> - finally got around to passing valid IOMUX pin config values to the
> pin groups.
>
> Other changes:
>
> - removed the FIM properties that overrided the v4l2 FIM control defaults
> values. This was left-over from a requirement of a customer and is not
> necessary here.
>
> - The FIM must be explicitly enabled in the fim child node under the CSI
> port nodes, using the status property. If not enabled, FIM v4l2 controls
> will not appear in the video capture driver.
>
> - brought in additional media types patch from Philipp Zabel. Use new
> MEDIA_ENT_F_VID_IF_BRIDGE in mipi csi-2 receiver subdev.
>
> - brought in latest platform generic video multiplexer subdevice driver
> from Philipp Zabel (squashed with patch that uses new MEDIA_ENT_F_MUX).
>
> - removed imx-media-of.h, moved those prototypes into imx-media.h.
>
>
<snip>
Hi Steve,
I took a stab at testing this today on a gw51xx which has an adv7180
hooked up as follows:
- i2c3 at 0x20
- 8bit data bus from DAT12 to DAT19, HSYNC, VSYNC, PIXCLK on CSI0 pads
(CSI0_IPU1)
- PWRDWN# on MX6QDL_PAD_CSI0_DATA_EN__GPIO5_IO20
- IRQ# on MX6QDL_PAD_CSI0_DAT5__GPIO5_IO23
- all three analog inputs available to off-board connector
My patch to the imx6qdl-gw51xx dtsi is:
diff --git a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
index afec2c7..2583d72 100644
--- a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
@@ -165,6 +174,52 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c3>;
status = "okay";
+
+ camera: adv7180 at 20 {
+ compatible = "adi,adv7180";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adv7180>;
+ reg = <0x20>;
+ powerdown-gpio = <&gpio5 20 GPIO_ACTIVE_LOW>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <23 GPIO_ACTIVE_LOW>;
+ inputs = <0x00 0x01 0x02>;
+ input-names = "ADV7180 Composite on Ain1",
+ "ADV7180 Composite on Ain2",
+ "ADV7180 Composite on Ain3";
+
+ port {
+ adv7180_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint =
<&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <8>;
+ };
+ };
+ };
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <8>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&adv7180_to_ipu1_csi0_mux>;
+ bus-width = <8>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
+
+ /* enable frame interval monitor on this port */
+ fim {
+ status = "okay";
+ };
};
&pcie {
@@ -236,6 +291,13 @@
&iomuxc {
imx6qdl-gw51xx {
+ pinctrl_adv7180: adv7180grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT5__GPIO5_IO23
0x0001b0b0 /* VIDDEC_IRQ# */
+ MX6QDL_PAD_CSI0_DATA_EN__GPIO5_IO20
0x4001b0b0 /* VIDDEC_EN */
+ >;
+ };
+
pinctrl_enet: enetgrp {
fsl,pins = <
MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b030
@@ -306,6 +368,22 @@
>;
};
+ pinctrl_ipu1_csi0: ipu1csi0grp { /* IPU1_CSI0: 8-bit input */
+ fsl,pins = <
+
MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x1b0b0
+
MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x1b0b0
+
MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x1b0b0
+
MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x1b0b0
+
MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x1b0b0
+
MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x1b0b0
+
MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x1b0b0
+
MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 0x1b0b0
+ MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC
0x1b0b0
+ MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC
0x1b0b0
+
MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x1b0b0
+ >;
+ };
+
pinctrl_pcie: pciegrp {
fsl,pins = <
MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
On an IMX6Q I'm getting the following when the adv7180 module loads:
[ 12.862477] adv7180 2-0020: chip found @ 0x20 (21a8000.i2c)
[ 12.907767] imx-media: Registered subdev adv7180 2-0020
[ 12.907793] imx-media soc:media@0: Entity type for entity adv7180
2-0020 was not initialized!
[ 12.907867] imx-media: imx_media_create_link: adv7180 2-0020:0 ->
ipu1_csi0_mux:1
Is the warning that adv7180 was not initialized expected and or an issue?
Now that your driver is hooking into the current media framework, I'm
not at all clear on how to link and configure the media entities.
Using 'media-ctl -p' to list the entities I see:
Media controller API version 0.1.0
Media device information
------------------------
driver imx-media
model imx-media
serial
bus info
hw revision 0x0
driver version 0.0.0
Device topology
- entity 1: ipu2_csi1_mux (3 pads, 1 link)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev0
pad0: Sink
[fmt:unknown/0x0]
pad1: Sink
[fmt:unknown/0x0]
pad2: Source
[fmt:unknown/0x0]
-> "ipu2_csi1":0 []
- entity 5: ipu1_csi0_mux (3 pads, 2 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev1
pad0: Sink
[fmt:unknown/0x0]
pad1: Sink
[fmt:unknown/0x0]
<- "adv7180 2-0020":0 []
pad2: Source
[fmt:unknown/0x0]
-> "ipu1_csi0":0 []
- entity 9: ipu1_ic_prpenc (2 pads, 4 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev2
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu1_csi0":1 []
<- "ipu1_csi1":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "camif0":0 []
-> "camif1":0 []
- entity 12: ipu1_ic_prpvf (2 pads, 8 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev3
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu1_csi0":1 []
<- "ipu1_csi1":1 []
<- "ipu1_smfc0":1 []
<- "ipu1_smfc1":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "camif0":0 []
-> "camif1":0 []
-> "ipu1_ic_pp0":0 []
-> "ipu1_ic_pp1":0 []
- entity 15: ipu1_ic_pp0 (2 pads, 4 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev4
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu1_ic_prpvf":1 []
<- "ipu1_smfc0":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "camif0":0 []
-> "camif1":0 []
- entity 18: ipu1_ic_pp1 (2 pads, 4 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev5
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu1_ic_prpvf":1 []
<- "ipu1_smfc1":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "camif0":0 []
-> "camif1":0 []
- entity 21: ipu2_ic_prpenc (2 pads, 4 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev6
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu2_csi0":1 []
<- "ipu2_csi1":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "camif2":0 []
-> "camif3":0 []
- entity 24: ipu2_ic_prpvf (2 pads, 8 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev7
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu2_csi0":1 []
<- "ipu2_csi1":1 []
<- "ipu2_smfc0":1 []
<- "ipu2_smfc1":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "camif2":0 []
-> "camif3":0 []
-> "ipu2_ic_pp0":0 []
-> "ipu2_ic_pp1":0 []
- entity 27: ipu2_ic_pp0 (2 pads, 4 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev8
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu2_ic_prpvf":1 []
<- "ipu2_smfc0":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "camif2":0 []
-> "camif3":0 []
- entity 30: ipu2_ic_pp1 (2 pads, 4 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev9
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu2_ic_prpvf":1 []
<- "ipu2_smfc1":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "camif2":0 []
-> "camif3":0 []
- entity 33: ipu1_csi0 (2 pads, 4 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev10
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu1_csi0_mux":2 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none
crop.bounds:(0,0)/640x480
crop:(0,0)/0x0]
-> "ipu1_ic_prpenc":0 []
-> "ipu1_ic_prpvf":0 []
-> "ipu1_smfc0":0 []
- entity 36: ipu1_csi1 (2 pads, 3 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev11
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
pad1: Source
[fmt:UYVY2X8/640x480 field:none
crop.bounds:(0,0)/640x480
crop:(0,0)/0x0]
-> "ipu1_ic_prpenc":0 []
-> "ipu1_ic_prpvf":0 []
-> "ipu1_smfc1":0 []
- entity 39: ipu2_csi0 (2 pads, 3 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev12
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
pad1: Source
[fmt:UYVY2X8/640x480 field:none
crop.bounds:(0,0)/640x480
crop:(0,0)/0x0]
-> "ipu2_ic_prpenc":0 []
-> "ipu2_ic_prpvf":0 []
-> "ipu2_smfc0":0 []
- entity 42: ipu2_csi1 (2 pads, 4 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev13
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu2_csi1_mux":2 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none
crop.bounds:(0,0)/640x480
crop:(0,0)/0x0]
-> "ipu2_ic_prpenc":0 []
-> "ipu2_ic_prpvf":0 []
-> "ipu2_smfc1":0 []
- entity 45: ipu1_smfc0 (2 pads, 5 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev14
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu1_csi0":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "ipu1_ic_prpvf":0 []
-> "ipu1_ic_pp0":0 []
-> "camif0":0 []
-> "camif1":0 []
- entity 48: ipu1_smfc1 (2 pads, 5 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev15
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu1_csi1":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "ipu1_ic_prpvf":0 []
-> "ipu1_ic_pp1":0 []
-> "camif0":0 []
-> "camif1":0 []
- entity 51: ipu2_smfc0 (2 pads, 5 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev16
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu2_csi0":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "ipu2_ic_prpvf":0 []
-> "ipu2_ic_pp0":0 []
-> "camif2":0 []
-> "camif3":0 []
- entity 54: ipu2_smfc1 (2 pads, 5 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev17
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu2_csi1":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "ipu2_ic_prpvf":0 []
-> "ipu2_ic_pp1":0 []
-> "camif2":0 []
-> "camif3":0 []
- entity 57: camif0 (2 pads, 7 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev18
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu1_ic_prpenc":1 []
<- "ipu1_ic_prpvf":1 []
<- "ipu1_ic_pp0":1 []
<- "ipu1_ic_pp1":1 []
<- "ipu1_smfc0":1 []
<- "ipu1_smfc1":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "camif0 devnode":0 [ENABLED,IMMUTABLE]
- entity 58: camif0 devnode (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Sink
<- "camif0":1 [ENABLED,IMMUTABLE]
- entity 66: camif1 (2 pads, 7 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev19
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu1_ic_prpenc":1 []
<- "ipu1_ic_prpvf":1 []
<- "ipu1_ic_pp0":1 []
<- "ipu1_ic_pp1":1 []
<- "ipu1_smfc0":1 []
<- "ipu1_smfc1":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "camif1 devnode":0 [ENABLED,IMMUTABLE]
- entity 67: camif1 devnode (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video1
pad0: Sink
<- "camif1":1 [ENABLED,IMMUTABLE]
- entity 75: camif2 (2 pads, 7 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev20
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu2_ic_prpenc":1 []
<- "ipu2_ic_prpvf":1 []
<- "ipu2_ic_pp0":1 []
<- "ipu2_ic_pp1":1 []
<- "ipu2_smfc0":1 []
<- "ipu2_smfc1":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "camif2 devnode":0 [ENABLED,IMMUTABLE]
- entity 76: camif2 devnode (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video2
pad0: Sink
<- "camif2":1 [ENABLED,IMMUTABLE]
- entity 84: camif3 (2 pads, 7 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev21
pad0: Sink
[fmt:UYVY2X8/640x480 field:none]
<- "ipu2_ic_prpenc":1 []
<- "ipu2_ic_prpvf":1 []
<- "ipu2_ic_pp0":1 []
<- "ipu2_ic_pp1":1 []
<- "ipu2_smfc0":1 []
<- "ipu2_smfc1":1 []
pad1: Source
[fmt:UYVY2X8/640x480 field:none]
-> "camif3 devnode":0 [ENABLED,IMMUTABLE]
- entity 85: camif3 devnode (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video3
pad0: Sink
<- "camif3":1 [ENABLED,IMMUTABLE]
- entity 93: adv7180 2-0020 (1 pad, 1 link)
type V4L2 subdev subtype Unknown flags 20004
device node name /dev/v4l-subdev22
pad0: Source
[fmt:UYVY2X8/720x480 field:interlaced]
-> "ipu1_csi0_mux":1 []
How do I link the entities here to be able to capture frames with
v4l2-ctl or gstreamer?
Additionally I've found that on an IMX6S/IMX6DL we crash while
registering the media-ic subdev's:
[ 3.975473] imx-media: Registered subdev ipu1_csi1_mux
[ 3.980921] imx-media: Registered subdev ipu1_csi0_mux
[ 4.003205] imx-media: Registered subdev ipu1_ic_prpenc
[ 4.025373] imx-media: Registered subdev ipu1_ic_prpvf
[ 4.037944] ------------[ cut here ]------------
[ 4.042571] Kernel BUG at c06717dc [verbose debug info unavailable]
[ 4.048845] Internal error: Oops - BUG: 0 [#1] SMP ARM
[ 4.053990] Modules linked in:
[ 4.057076] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
4.9.0-rc6-00524-g84dad6e-dirty #446
[ 4.065260] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
...
[ 4.296250] [<c0671780>] (v4l2_subdev_init) from [<c06fb02c>]
(imx_ic_probe+0x94/0x1ac)
[ 4.304271] [<c06faf98>] (imx_ic_probe) from [<c05173d8>]
(platform_drv_probe+0x54/0xb8)
[ 4.312373] r9:c0d5e858 r8:00000000 r7:fffffdfb r6:c0e5dbf8
r5:da603810 r4:c16738d8
[ 4.320129] [<c0517384>] (platform_drv_probe) from [<c0515978>]
(driver_probe_device+0x20c/0x2c0)
[ 4.329010] r7:c0e5dbf8 r6:00000000 r5:da603810 r4:c16738d8
[ 4.334681] [<c051576c>] (driver_probe_device) from [<c0515af4>]
(__driver_attach+0xc8/0xcc)
[ 4.343129] r9:c0d5e858 r8:00000000 r7:00000000 r6:da603844
r5:c0e5dbf8 r4:da603810
[ 4.350889] [<c0515a2c>] (__driver_attach) from [<c0513adc>]
(bus_for_each_dev+0x74/0xa8)
[ 4.359078] r7:00000000 r6:c0515a2c r5:c0e5dbf8 r4:00000000
[ 4.364753] [<c0513a68>] (bus_for_each_dev) from [<c05151d4>]
(driver_attach+0x20/0x28)
I assume there is an iteration that needs a test on a missing pointer
only available on chips with both IPU's or PRP
Regards,
Tim
^ permalink raw reply related
* [PATCH 0/4] video: ARM CLCD: add support of an optional GPIO to enable panel
From: Vladimir Zapolskiy @ 2017-01-12 0:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYv87Tmp6i-vccVmtVD5NDk2y1=62sgP7VQgWctC+t3Tg@mail.gmail.com>
On 01/11/2017 05:16 PM, Linus Walleij wrote:
> On Tue, Jan 10, 2017 at 2:47 PM, Vladimir Murzin
> <vladimir.murzin@arm.com> wrote:
>
>> In another thread Benjamin pointed at patch [1] in drm/kms part for noMMU.
>>
>> [1] https://cgit.freedesktop.org/drm/drm-misc/commit/?id=62a0d98a188cc4ebd8ea54b37d274ec20465e464
>
> Problem solved?
>
> Vladimir: I do not require in any way that you create a CLCD driver for DRM,
> I just think it would be very very nice...
>
I have no other option, this series is unreviewed and thus unlikely it will
be applied, still a panel PCB on my board needs power management support.
--
With best wishes,
Vladimir
^ 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