* [PATCH 09/20] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
From: Steve Longerbeam @ 2016-12-29 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483050455-10683-1-git-send-email-steve_longerbeam@mentor.com>
Enables the ADV7180 decoder sensor. The ADV7180 connects to the
parallel-bus mux input on ipu1_csi0_mux.
On the sabreauto, two analog video inputs are routed to the ADV7180,
composite on Ain1, and composite on Ain3. Those inputs are defined
via inputs and input-names under the ADV7180 node. The ADV7180 power
pin is via max7310_b port expander.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 56 ++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 83ac2ff..30ee378 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -147,10 +147,42 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+ camera: adv7180 at 21 {
+ compatible = "adi,adv7180";
+ reg = <0x21>;
+ powerdown-gpios = <&max7310_b 2 GPIO_ACTIVE_LOW>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <27 0x8>;
+ inputs = <0x00 0x02>;
+ input-names = "ADV7180 Composite on Ain1",
+ "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>;
+};
+
&clks {
assigned-clocks = <&clks IMX6QDL_PLL4_BYPASS_SRC>,
<&clks IMX6QDL_PLL4_BYPASS>,
@@ -451,6 +483,30 @@
>;
};
+ pinctrl_ipu1_csi0: ipu1grp-csi0 {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04 0x80000000
+ MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05 0x80000000
+ MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06 0x80000000
+ MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07 0x80000000
+ MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08 0x80000000
+ MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09 0x80000000
+ MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10 0x80000000
+ MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11 0x80000000
+ MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x80000000
+ MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x80000000
+ MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x80000000
+ MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x80000000
+ MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x80000000
+ MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x80000000
+ MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x80000000
+ MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 0x80000000
+ MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x80000000
+ MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC 0x80000000
+ MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC 0x80000000
+ >;
+ };
+
pinctrl_pwm3: pwm1grp {
fsl,pins = <
MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
--
2.7.4
^ permalink raw reply related
* [PATCH 08/20] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
From: Steve Longerbeam @ 2016-12-29 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483050455-10683-1-git-send-email-steve_longerbeam@mentor.com>
Add pinctrl groups for both GPT input capture channels.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 516bac6..83ac2ff 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -457,6 +457,18 @@
>;
};
+ pinctrl_gpt_input_capture0: gptinputcapture0grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT0__GPT_CAPTURE1 0x80000000
+ >;
+ };
+
+ pinctrl_gpt_input_capture1: gptinputcapture1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT1__GPT_CAPTURE2 0x80000000
+ >;
+ };
+
pinctrl_spdif: spdifgrp {
fsl,pins = <
MX6QDL_PAD_KEY_COL3__SPDIF_IN 0x1b0b0
--
2.7.4
^ permalink raw reply related
* [PATCH 07/20] ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b
From: Steve Longerbeam @ 2016-12-29 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483050455-10683-1-git-send-email-steve_longerbeam@mentor.com>
The reset pin to the port expander chip (MAX7310) is controlled by a gpio,
so define a reset-gpios property to control it. There are three MAX7310's
on the SabreAuto CPU card (max7310_[abc]), but all use the same pin for
their reset. Since all can't acquire the same pin, assign it to max7310_b,
that chip is needed by more functions (usb and adv7180).
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 4a6d038..516bac6 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -136,6 +136,9 @@
reg = <0x32>;
gpio-controller;
#gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_max7310>;
+ reset-gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
};
max7310_c: gpio at 34 {
@@ -442,6 +445,12 @@
>;
};
+ pinctrl_max7310: max7310grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_DAT0__GPIO1_IO15 0x80000000
+ >;
+ };
+
pinctrl_pwm3: pwm1grp {
fsl,pins = <
MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
--
2.7.4
^ permalink raw reply related
* [PATCH 06/20] ARM: dts: imx6-sabreauto: create i2cmux for i2c3
From: Steve Longerbeam @ 2016-12-29 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483050455-10683-1-git-send-email-steve_longerbeam@mentor.com>
The sabreauto uses a steering pin to select between the SDA signal on
i2c3 bus, and a data-in pin for an SPI NOR chip. Use i2cmux to control
this steering pin. Idle state of the i2cmux selects SPI NOR. This is not
a classic way to use i2cmux, since one side of the mux selects something
other than an i2c bus, but it works and is probably the cleanest
solution. Note that if one thread is attempting to access SPI NOR while
another thread is accessing i2c3, the SPI NOR access will fail since the
i2cmux has selected the SDA pin rather than SPI NOR data-in. This couldn't
be avoided in any case, the board is not designed to allow concurrent
i2c3 and SPI NOR functions (and the default device-tree does not enable
SPI NOR anyway).
Devices hanging off i2c3 should now be defined under i2cmux, so
that the steering pin can be properly controlled to access those
devices. The port expanders (MAX7310) are thus moved into i2cmux.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 65 +++++++++++++++++++++-----------
1 file changed, 44 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 52390ba..4a6d038 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -108,6 +108,44 @@
default-brightness-level = <7>;
status = "okay";
};
+
+ i2cmux {
+ compatible = "i2c-mux-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3mux>;
+ mux-gpios = <&gpio5 4 0>;
+ i2c-parent = <&i2c3>;
+ idle-state = <0>;
+
+ i2c at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ max7310_a: gpio at 30 {
+ compatible = "maxim,max7310";
+ reg = <0x30>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ max7310_b: gpio at 32 {
+ compatible = "maxim,max7310";
+ reg = <0x32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ max7310_c: gpio at 34 {
+ compatible = "maxim,max7310";
+ reg = <0x34>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+ };
};
&clks {
@@ -291,27 +329,6 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c3>;
status = "okay";
-
- max7310_a: gpio at 30 {
- compatible = "maxim,max7310";
- reg = <0x30>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- max7310_b: gpio at 32 {
- compatible = "maxim,max7310";
- reg = <0x32>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- max7310_c: gpio at 34 {
- compatible = "maxim,max7310";
- reg = <0x34>;
- gpio-controller;
- #gpio-cells = <2>;
- };
};
&iomuxc {
@@ -419,6 +436,12 @@
>;
};
+ pinctrl_i2c3mux: i2c3muxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_A24__GPIO5_IO04 0x80000000
+ >;
+ };
+
pinctrl_pwm3: pwm1grp {
fsl,pins = <
MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
--
2.7.4
^ permalink raw reply related
* [PATCH 05/20] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
From: Steve Longerbeam @ 2016-12-29 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483050455-10683-1-git-send-email-steve_longerbeam@mentor.com>
Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
The OV5640 connects to the input port on the MIPI CSI-2 receiver on
mipi_csi. It is set to transmit over MIPI virtual channel 1.
Until the OV5652 sensor module compatible with the SabreSD becomes
available for testing, the ov5642 node is currently disabled.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6dl-sabresd.dts | 5 ++
arch/arm/boot/dts/imx6q-sabresd.dts | 5 ++
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 114 ++++++++++++++++++++++++++++++++-
3 files changed, 123 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6dl-sabresd.dts b/arch/arm/boot/dts/imx6dl-sabresd.dts
index 1e45f2f..6cf7a50 100644
--- a/arch/arm/boot/dts/imx6dl-sabresd.dts
+++ b/arch/arm/boot/dts/imx6dl-sabresd.dts
@@ -15,3 +15,8 @@
model = "Freescale i.MX6 DualLite SABRE Smart Device Board";
compatible = "fsl,imx6dl-sabresd", "fsl,imx6dl";
};
+
+&ipu1_csi1_from_ipu1_csi1_mux {
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+};
diff --git a/arch/arm/boot/dts/imx6q-sabresd.dts b/arch/arm/boot/dts/imx6q-sabresd.dts
index 9cbdfe7..8c1d7ad 100644
--- a/arch/arm/boot/dts/imx6q-sabresd.dts
+++ b/arch/arm/boot/dts/imx6q-sabresd.dts
@@ -23,3 +23,8 @@
&sata {
status = "okay";
};
+
+&ipu1_csi1_from_mipi_vc1 {
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 55ef535..39b4228 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -10,6 +10,7 @@
* http://www.gnu.org/copyleft/gpl.html
*/
+#include <dt-bindings/clock/imx6qdl-clock.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
@@ -146,6 +147,33 @@
};
};
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <8>;
+ data-shift = <12>; /* Lines 19:12 used */
+ hsync-active = <1>;
+ vsync-active = <1>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&ov5642_to_ipu1_csi0_mux>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
+};
+
+&mipi_csi {
+ status = "okay";
+};
+
+/* Incoming port from sensor */
+&mipi_csi_from_mipi_sensor {
+ remote-endpoint = <&ov5640_to_mipi_csi>;
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+};
+
&audmux {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_audmux>;
@@ -214,7 +242,33 @@
0x8014 /* 4:FN_DMICCDAT */
0x0000 /* 5:Default */
>;
- };
+ };
+
+ camera: ov5642 at 3c {
+ compatible = "ovti,ov5642";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ov5642>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ clock-names = "xclk";
+ reg = <0x3c>;
+ xclk = <24000000>;
+ DOVDD-supply = <&vgen4_reg>; /* 1.8v */
+ AVDD-supply = <&vgen5_reg>; /* 2.8v, rev C board is VGEN3
+ rev B board is VGEN5 */
+ DVDD-supply = <&vgen2_reg>; /* 1.5v*/
+ pwdn-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>; /* SD1_DAT0 */
+ reset-gpios = <&gpio1 17 GPIO_ACTIVE_LOW>; /* SD1_DAT1 */
+ status = "disabled";
+
+ port {
+ ov5642_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <8>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
};
&i2c2 {
@@ -322,6 +376,34 @@
};
};
};
+
+ mipi_camera: ov5640 at 3c {
+ compatible = "ovti,ov5640_mipi";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ov5640>;
+ reg = <0x3c>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ clock-names = "xclk";
+ xclk = <24000000>;
+ DOVDD-supply = <&vgen4_reg>; /* 1.8v */
+ AVDD-supply = <&vgen5_reg>; /* 2.8v, rev C board is VGEN3
+ rev B board is VGEN5 */
+ DVDD-supply = <&vgen2_reg>; /* 1.5v*/
+ pwdn-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; /* SD1_DAT2 */
+ reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>; /* SD1_CLK */
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov5640_to_mipi_csi: endpoint at 1 {
+ reg = <1>;
+ remote-endpoint = <&mipi_csi_from_mipi_sensor>;
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+ };
+ };
+ };
};
&i2c3 {
@@ -426,6 +508,36 @@
>;
};
+ pinctrl_ov5640: ov5640grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT2__GPIO1_IO19 0x80000000
+ MX6QDL_PAD_SD1_CLK__GPIO1_IO20 0x80000000
+ >;
+ };
+
+ pinctrl_ov5642: ov5642grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT0__GPIO1_IO16 0x80000000
+ MX6QDL_PAD_SD1_DAT1__GPIO1_IO17 0x80000000
+ >;
+ };
+
+ pinctrl_ipu1_csi0: ipu1grp-csi0 {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x80000000
+ MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x80000000
+ MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x80000000
+ MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x80000000
+ MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x80000000
+ MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x80000000
+ MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x80000000
+ MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 0x80000000
+ MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x80000000
+ MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC 0x80000000
+ MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC 0x80000000
+ >;
+ };
+
pinctrl_pcie: pciegrp {
fsl,pins = <
MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
--
2.7.4
^ permalink raw reply related
* [PATCH 04/20] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
From: Steve Longerbeam @ 2016-12-29 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483050455-10683-1-git-send-email-steve_longerbeam@mentor.com>
Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
Both hang off the same i2c2 bus, so they require different (and non-
default) i2c slave addresses.
The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
The OV5640 connects to the input port on the MIPI CSI-2 receiver on
mipi_csi. It is set to transmit over MIPI virtual channel 1.
Note there is a pin conflict with GPIO6. This pin functions as a power
input pin to the OV5642, but ENET uses it as the h/w workaround for
erratum ERR006687, to wake-up the ARM cores on normal RX and TX packet
done events (see 6261c4c8). So workaround 6261c4c8 is reverted here to
support the OV5642, and the "fsl,err006687-workaround-present" boolean
also must be removed. The result is that the CPUidle driver will no longer
allow entering the deep idle states on the sabrelite.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6dl-sabrelite.dts | 5 ++
arch/arm/boot/dts/imx6q-sabrelite.dts | 6 ++
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 122 ++++++++++++++++++++++++++++++-
3 files changed, 129 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl-sabrelite.dts b/arch/arm/boot/dts/imx6dl-sabrelite.dts
index 0f06ca5..fec2524 100644
--- a/arch/arm/boot/dts/imx6dl-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6dl-sabrelite.dts
@@ -48,3 +48,8 @@
model = "Freescale i.MX6 DualLite SABRE Lite Board";
compatible = "fsl,imx6dl-sabrelite", "fsl,imx6dl";
};
+
+&ipu1_csi1_from_ipu1_csi1_mux {
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+};
diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts b/arch/arm/boot/dts/imx6q-sabrelite.dts
index 66d10d8..9e2d26d 100644
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -52,3 +52,9 @@
&sata {
status = "okay";
};
+
+&ipu1_csi1_from_mipi_vc1 {
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+};
+
diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 1f9076e..4a50bb1 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -39,6 +39,8 @@
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*/
+
+#include <dt-bindings/clock/imx6qdl-clock.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
@@ -96,6 +98,15 @@
};
};
+ mipi_xclk: mipi_xclk {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <22000000>;
+ clock-output-names = "mipi_pwm3";
+ pwms = <&pwm3 0 45>; /* 1 / 45 ns = 22 MHz */
+ status = "okay";
+ };
+
gpio-keys {
compatible = "gpio-keys";
pinctrl-names = "default";
@@ -220,6 +231,22 @@
};
};
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <8>;
+ data-shift = <12>; /* Lines 19:12 used */
+ hsync-active = <1>;
+ vync-active = <1>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&ov5642_to_ipu1_csi0_mux>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
+};
+
&audmux {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_audmux>;
@@ -271,9 +298,6 @@
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
- interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
- <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
- fsl,err006687-workaround-present;
status = "okay";
};
@@ -302,6 +326,52 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c2>;
status = "okay";
+
+ camera: ov5642 at 42 {
+ compatible = "ovti,ov5642";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ov5642>;
+ clocks = <&clks IMX6QDL_CLK_CKO2>;
+ clock-names = "xclk";
+ reg = <0x42>;
+ xclk = <24000000>;
+ reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
+ pwdn-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+ gp-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
+
+ port {
+ ov5642_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <8>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
+
+ mipi_camera: ov5640 at 40 {
+ compatible = "ovti,ov5640_mipi";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ov5640>;
+ clocks = <&mipi_xclk>;
+ clock-names = "xclk";
+ reg = <0x40>;
+ xclk = <22000000>;
+ reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>; /* NANDF_D5 */
+ pwdn-gpios = <&gpio6 9 GPIO_ACTIVE_HIGH>; /* NANDF_WP_B */
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov5640_to_mipi_csi: endpoint at 1 {
+ reg = <1>;
+ remote-endpoint = <&mipi_csi_from_mipi_sensor>;
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+ };
+ };
+ };
};
&i2c3 {
@@ -374,7 +444,6 @@
MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b030
/* Phy reset */
MX6QDL_PAD_EIM_D23__GPIO3_IO23 0x000b0
- MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
>;
};
@@ -449,6 +518,39 @@
>;
};
+ pinctrl_ov5642: ov5642grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT0__GPIO1_IO16 0x80000000
+ MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x80000000
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x80000000
+ MX6QDL_PAD_GPIO_3__CCM_CLKO2 0x80000000
+ >;
+ };
+
+ pinctrl_ipu1_csi0: ipu1grp-csi0 {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x80000000
+ MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x80000000
+ MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x80000000
+ MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x80000000
+ MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x80000000
+ MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x80000000
+ MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x80000000
+ MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 0x80000000
+ MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x80000000
+ MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC 0x80000000
+ MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC 0x80000000
+ MX6QDL_PAD_CSI0_DATA_EN__IPU1_CSI0_DATA_EN 0x80000000
+ >;
+ };
+
+ pinctrl_ov5640: ov5640grp {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x000b0
+ MX6QDL_PAD_NANDF_WP_B__GPIO6_IO09 0x0b0b0
+ >;
+ };
+
pinctrl_pwm1: pwm1grp {
fsl,pins = <
MX6QDL_PAD_SD1_DAT3__PWM1_OUT 0x1b0b1
@@ -605,3 +707,15 @@
vmmc-supply = <®_3p3v>;
status = "okay";
};
+
+&mipi_csi {
+ status = "okay";
+};
+
+/* Incoming port from sensor */
+&mipi_csi_from_mipi_sensor {
+ remote-endpoint = <&ov5640_to_mipi_csi>;
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+};
+
--
2.7.4
^ permalink raw reply related
* [PATCH 03/20] ARM: dts: imx6qdl: add media device
From: Steve Longerbeam @ 2016-12-29 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483050455-10683-1-git-send-email-steve_longerbeam@mentor.com>
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6q.dtsi | 4 ++++
arch/arm/boot/dts/imx6qdl.dtsi | 8 ++++++++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 56a314f..2fbe0b3 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -454,3 +454,7 @@
&vpu {
compatible = "fsl,imx6q-vpu", "cnm,coda960";
};
+
+&media0 {
+ ports = <&ipu1_csi0>, <&ipu1_csi1>, <&ipu2_csi0>, <&ipu2_csi1>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 89218a4..12ae045 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1296,5 +1296,13 @@
};
};
};
+
+ media0: media at 0 {
+ compatible = "fsl,imx-media";
+ ports = <&ipu1_csi0>, <&ipu1_csi1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 02/20] ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their connections
From: Steve Longerbeam @ 2016-12-29 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483050455-10683-1-git-send-email-steve_longerbeam@mentor.com>
From: Philipp Zabel <p.zabel@pengutronix.de>
This patch adds the device tree graph connecting the input multiplexers
to the IPU CSIs and the MIPI-CSI2 gasket on i.MX6. The MIPI_IPU
multiplexers are added as children of the iomuxc-gpr syscon device node.
On i.MX6Q/D two two-input multiplexers in front of IPU1 CSI0 and IPU2
CSI1 allow to select between CSI0/1 parallel input pads and the MIPI
CSI-2 virtual channels 0/3.
On i.MX6DL/S two five-input multiplexers in front of IPU1 CSI0 and IPU1
CSI1 allow to select between CSI0/1 parallel input pads and any of the
four MIPI CSI-2 virtual channels.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
- Removed some dangling/unused endpoints (ipu2_csi0_from_csi2ipu)
- Renamed the mipi virtual channel endpoint labels, from "mipi_csiX_..."
to "mipi_vcX...".
- Added input endpoints to the video muxes for the connections from parallel
sensors.
- Added input endpoints to the mipi_csi for the connections from mipi csi-2
sensors.
- The video multiplexer node has compatible string "imx-video-mux" instead
of "video-multiplexer".
- The video multiplexer node indicates GPR register via reg propert only,
(register offset and bitmask), instead of specifying with "bit-mask" and
"bit-shift" properties.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6dl.dtsi | 183 +++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx6q.dtsi | 119 +++++++++++++++++++++++++++
arch/arm/boot/dts/imx6qdl.dtsi | 10 ++-
3 files changed, 311 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 1ade195..0a1718c 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -181,6 +181,189 @@
"di0", "di1";
};
+&gpr {
+ ipu1_csi0_mux: ipu1_csi0_mux at 34 {
+ compatible = "imx-video-mux";
+ reg = <0x34 0x07>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ port at 0 {
+ reg = <0>;
+
+ ipu1_csi0_mux_from_mipi_vc0: endpoint {
+ remote-endpoint = <&mipi_vc0_to_ipu1_csi0_mux>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ ipu1_csi0_mux_from_mipi_vc1: endpoint {
+ remote-endpoint = <&mipi_vc1_to_ipu1_csi0_mux>;
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+
+ ipu1_csi0_mux_from_mipi_vc2: endpoint {
+ remote-endpoint = <&mipi_vc2_to_ipu1_csi0_mux>;
+ };
+ };
+
+ port at 3 {
+ reg = <3>;
+
+ ipu1_csi0_mux_from_mipi_vc3: endpoint {
+ remote-endpoint = <&mipi_vc3_to_ipu1_csi0_mux>;
+ };
+ };
+
+ port at 4 {
+ reg = <4>;
+
+ ipu1_csi0_mux_from_parallel_sensor: endpoint {
+ };
+ };
+
+ port at 5 {
+ reg = <5>;
+
+ ipu1_csi0_mux_to_ipu1_csi0: endpoint {
+ remote-endpoint = <&ipu1_csi0_from_ipu1_csi0_mux>;
+ };
+ };
+ };
+
+ ipu1_csi1_mux: ipu1_csi1_mux at 34 {
+ compatible = "imx-video-mux";
+ reg = <0x34 0x38>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ port at 0 {
+ reg = <0>;
+
+ ipu1_csi1_mux_from_mipi_vc0: endpoint {
+ remote-endpoint = <&mipi_vc0_to_ipu1_csi1_mux>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ ipu1_csi1_mux_from_mipi_vc1: endpoint {
+ remote-endpoint = <&mipi_vc1_to_ipu1_csi1_mux>;
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+
+ ipu1_csi1_mux_from_mipi_vc2: endpoint {
+ remote-endpoint = <&mipi_vc2_to_ipu1_csi1_mux>;
+ };
+ };
+
+ port at 3 {
+ reg = <3>;
+
+ ipu1_csi1_mux_from_mipi_vc3: endpoint {
+ remote-endpoint = <&mipi_vc3_to_ipu1_csi1_mux>;
+ };
+ };
+
+ port at 4 {
+ reg = <4>;
+
+ ipu1_csi1_mux_from_parallel_sensor: endpoint {
+ };
+ };
+
+ port at 5 {
+ reg = <5>;
+
+ ipu1_csi1_mux_to_ipu1_csi1: endpoint {
+ remote-endpoint = <&ipu1_csi1_from_ipu1_csi1_mux>;
+ };
+ };
+ };
+};
+
+&ipu1_csi1 {
+ ipu1_csi1_from_ipu1_csi1_mux: endpoint {
+ remote-endpoint = <&ipu1_csi1_mux_to_ipu1_csi1>;
+ };
+};
+
+&mipi_csi {
+ port at 0 {
+ reg = <0>;
+
+ mipi_csi_from_mipi_sensor: endpoint {
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_vc0_to_ipu1_csi0_mux: endpoint at 0 {
+ remote-endpoint = <&ipu1_csi0_mux_from_mipi_vc0>;
+ };
+
+ mipi_vc0_to_ipu1_csi1_mux: endpoint at 1 {
+ remote-endpoint = <&ipu1_csi1_mux_from_mipi_vc0>;
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_vc1_to_ipu1_csi0_mux: endpoint at 0 {
+ remote-endpoint = <&ipu1_csi0_mux_from_mipi_vc1>;
+ };
+
+ mipi_vc1_to_ipu1_csi1_mux: endpoint at 1 {
+ remote-endpoint = <&ipu1_csi1_mux_from_mipi_vc1>;
+ };
+ };
+
+ port at 3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_vc2_to_ipu1_csi0_mux: endpoint at 0 {
+ remote-endpoint = <&ipu1_csi0_mux_from_mipi_vc2>;
+ };
+
+ mipi_vc2_to_ipu1_csi1_mux: endpoint at 1 {
+ remote-endpoint = <&ipu1_csi1_mux_from_mipi_vc2>;
+ };
+ };
+
+ port at 4 {
+ reg = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_vc3_to_ipu1_csi0_mux: endpoint at 0 {
+ remote-endpoint = <&ipu1_csi0_mux_from_mipi_vc3>;
+ };
+
+ mipi_vc3_to_ipu1_csi1_mux: endpoint at 1 {
+ remote-endpoint = <&ipu1_csi1_mux_from_mipi_vc3>;
+ };
+ };
+};
+
&vpu {
compatible = "fsl,imx6dl-vpu", "cnm,coda960";
};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index e9a5d0b..56a314f 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -143,10 +143,18 @@
ipu2_csi0: port at 0 {
reg = <0>;
+
+ ipu2_csi0_from_mipi_vc2: endpoint {
+ remote-endpoint = <&mipi_vc2_to_ipu2_csi0>;
+ };
};
ipu2_csi1: port at 1 {
reg = <1>;
+
+ ipu2_csi1_from_ipu2_csi1_mux: endpoint {
+ remote-endpoint = <&ipu2_csi1_mux_to_ipu2_csi1>;
+ };
};
ipu2_di0: port at 2 {
@@ -266,6 +274,76 @@
};
};
+&gpr {
+ ipu1_csi0_mux: ipu1_csi0_mux at 4 {
+ compatible = "imx-video-mux";
+ reg = <0x04 0x80000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ port at 0 {
+ reg = <0>;
+
+ ipu1_csi0_mux_from_mipi_vc0: endpoint {
+ remote-endpoint = <&mipi_vc0_to_ipu1_csi0_mux>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ ipu1_csi0_mux_from_parallel_sensor: endpoint {
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+
+ ipu1_csi0_mux_to_ipu1_csi0: endpoint {
+ remote-endpoint = <&ipu1_csi0_from_ipu1_csi0_mux>;
+ };
+ };
+ };
+
+ ipu2_csi1_mux: ipu2_csi1_mux at 4 {
+ compatible = "imx-video-mux";
+ reg = <0x04 0x100000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ port at 0 {
+ reg = <0>;
+
+ ipu2_csi1_mux_from_mipi_vc3: endpoint {
+ remote-endpoint = <&mipi_vc3_to_ipu2_csi1_mux>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ ipu2_csi1_mux_from_parallel_sensor: endpoint {
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+
+ ipu2_csi1_mux_to_ipu2_csi1: endpoint {
+ remote-endpoint = <&ipu2_csi1_from_ipu2_csi1_mux>;
+ };
+ };
+ };
+};
+
+&ipu1_csi1 {
+ ipu1_csi1_from_mipi_vc1: endpoint {
+ remote-endpoint = <&mipi_vc1_to_ipu1_csi1>;
+ };
+};
+
&ldb {
clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>, <&clks IMX6QDL_CLK_LDB_DI1_SEL>,
<&clks IMX6QDL_CLK_IPU1_DI0_SEL>, <&clks IMX6QDL_CLK_IPU1_DI1_SEL>,
@@ -312,6 +390,47 @@
};
};
+&mipi_csi {
+ port at 0 {
+ reg = <0>;
+
+ mipi_csi_from_mipi_sensor: endpoint {
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ mipi_vc0_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint = <&ipu1_csi0_mux_from_mipi_vc0>;
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+
+ mipi_vc1_to_ipu1_csi1: endpoint {
+ remote-endpoint = <&ipu1_csi1_from_mipi_vc1>;
+ };
+ };
+
+ port at 3 {
+ reg = <3>;
+
+ mipi_vc2_to_ipu2_csi0: endpoint {
+ remote-endpoint = <&ipu2_csi0_from_mipi_vc2>;
+ };
+ };
+
+ port at 4 {
+ reg = <4>;
+
+ mipi_vc3_to_ipu2_csi1_mux: endpoint {
+ remote-endpoint = <&ipu2_csi1_mux_from_mipi_vc3>;
+ };
+ };
+};
+
&mipi_dsi {
ports {
port at 2 {
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 7b546e3..89218a4 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -799,8 +799,10 @@
};
gpr: iomuxc-gpr at 020e0000 {
- compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
+ compatible = "fsl,imx6q-iomuxc-gpr", "syscon", "simple-mfd";
reg = <0x020e0000 0x38>;
+ #address-cells = <1>;
+ #size-cells = <0>;
};
iomuxc: iomuxc at 020e0000 {
@@ -1127,6 +1129,8 @@
mipi_csi: mipi at 021dc000 {
compatible = "fsl,imx-mipi-csi2";
reg = <0x021dc000 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
interrupts = <0 100 0x04>, <0 101 0x04>;
clocks = <&clks IMX6QDL_CLK_HSI_TX>,
<&clks IMX6QDL_CLK_VIDEO_27M>,
@@ -1232,6 +1236,10 @@
ipu1_csi0: port at 0 {
reg = <0>;
+
+ ipu1_csi0_from_ipu1_csi0_mux: endpoint {
+ remote-endpoint = <&ipu1_csi0_mux_to_ipu1_csi0>;
+ };
};
ipu1_csi1: port at 1 {
--
2.7.4
^ permalink raw reply related
* [PATCH 01/20] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node
From: Steve Longerbeam @ 2016-12-29 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483050455-10683-1-git-send-email-steve_longerbeam@mentor.com>
Add to the MIPI CSI2 receiver node: compatible string, interrupt sources,
clocks.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6qdl.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 53e6e63..7b546e3 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1125,7 +1125,14 @@
};
mipi_csi: mipi at 021dc000 {
+ compatible = "fsl,imx-mipi-csi2";
reg = <0x021dc000 0x4000>;
+ interrupts = <0 100 0x04>, <0 101 0x04>;
+ clocks = <&clks IMX6QDL_CLK_HSI_TX>,
+ <&clks IMX6QDL_CLK_VIDEO_27M>,
+ <&clks IMX6QDL_CLK_EIM_SEL>;
+ clock-names = "dphy_clk", "cfg_clk", "pix_clk";
+ status = "disabled";
};
mipi_dsi: mipi at 021e0000 {
--
2.7.4
^ permalink raw reply related
* [PATCH 00/20] i.MX Media Driver
From: Steve Longerbeam @ 2016-12-29 22:27 UTC (permalink / raw)
To: linux-arm-kernel
This is a media driver for video capture on i.MX.
Refer to Documentation/media/v4l-drivers/imx.rst for example capture
pipelines on SabreSD, SabreAuto, and SabreLite reference platforms.
This patchset includes the OF graph layout as proposed by Philipp Zabel,
with only minor changes which are enumerated in the patch header.
Philipp Zabel (2):
ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their
connections
media: imx: Add video switch subdev driver
Steve Longerbeam (18):
ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node
ARM: dts: imx6qdl: add media device
ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
ARM: dts: imx6-sabreauto: create i2cmux for i2c3
ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b
ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
gpio: pca953x: Add optional reset gpio control
media: Add i.MX media core driver
media: imx: Add CSI subdev driver
media: imx: Add SMFC subdev driver
media: imx: Add IC subdev drivers
media: imx: Add Camera Interface subdev driver
media: imx: Add MIPI CSI-2 Receiver subdev driver
media: imx: Add MIPI CSI-2 OV5640 sensor subdev driver
media: imx: Add Parallel OV5642 sensor subdev driver
ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers
.../devicetree/bindings/gpio/gpio-pca953x.txt | 4 +
Documentation/devicetree/bindings/media/imx.txt | 205 +
Documentation/media/v4l-drivers/imx.rst | 429 ++
arch/arm/boot/dts/imx6dl-sabrelite.dts | 5 +
arch/arm/boot/dts/imx6dl-sabresd.dts | 5 +
arch/arm/boot/dts/imx6dl.dtsi | 183 +
arch/arm/boot/dts/imx6q-sabrelite.dts | 6 +
arch/arm/boot/dts/imx6q-sabresd.dts | 5 +
arch/arm/boot/dts/imx6q.dtsi | 123 +
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 142 +-
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 122 +-
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 114 +-
arch/arm/boot/dts/imx6qdl.dtsi | 25 +-
arch/arm/configs/imx_v6_v7_defconfig | 10 +-
drivers/gpio/gpio-pca953x.c | 17 +
drivers/staging/media/Kconfig | 2 +
drivers/staging/media/Makefile | 1 +
drivers/staging/media/imx/Kconfig | 36 +
drivers/staging/media/imx/Makefile | 16 +
drivers/staging/media/imx/TODO | 18 +
drivers/staging/media/imx/imx-camif.c | 1011 +++++
drivers/staging/media/imx/imx-csi.c | 638 +++
drivers/staging/media/imx/imx-ic-common.c | 113 +
drivers/staging/media/imx/imx-ic-pp.c | 636 +++
drivers/staging/media/imx/imx-ic-prpenc.c | 1037 +++++
drivers/staging/media/imx/imx-ic-prpvf.c | 1181 ++++++
drivers/staging/media/imx/imx-ic.h | 36 +
drivers/staging/media/imx/imx-media-common.c | 981 +++++
drivers/staging/media/imx/imx-media-dev.c | 479 +++
drivers/staging/media/imx/imx-media-fim.c | 508 +++
drivers/staging/media/imx/imx-media-internal-sd.c | 456 ++
drivers/staging/media/imx/imx-media-of.c | 291 ++
drivers/staging/media/imx/imx-media-of.h | 25 +
drivers/staging/media/imx/imx-media.h | 290 ++
drivers/staging/media/imx/imx-mipi-csi2.c | 509 +++
drivers/staging/media/imx/imx-smfc.c | 739 ++++
drivers/staging/media/imx/imx-video-switch.c | 349 ++
drivers/staging/media/imx/ov5640-mipi.c | 2349 +++++++++++
drivers/staging/media/imx/ov5642.c | 4364 ++++++++++++++++++++
include/media/imx.h | 15 +
include/uapi/Kbuild | 1 +
include/uapi/linux/v4l2-controls.h | 4 +
include/uapi/media/Kbuild | 2 +
include/uapi/media/imx.h | 30 +
44 files changed, 17484 insertions(+), 28 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/imx.txt
create mode 100644 Documentation/media/v4l-drivers/imx.rst
create mode 100644 drivers/staging/media/imx/Kconfig
create mode 100644 drivers/staging/media/imx/Makefile
create mode 100644 drivers/staging/media/imx/TODO
create mode 100644 drivers/staging/media/imx/imx-camif.c
create mode 100644 drivers/staging/media/imx/imx-csi.c
create mode 100644 drivers/staging/media/imx/imx-ic-common.c
create mode 100644 drivers/staging/media/imx/imx-ic-pp.c
create mode 100644 drivers/staging/media/imx/imx-ic-prpenc.c
create mode 100644 drivers/staging/media/imx/imx-ic-prpvf.c
create mode 100644 drivers/staging/media/imx/imx-ic.h
create mode 100644 drivers/staging/media/imx/imx-media-common.c
create mode 100644 drivers/staging/media/imx/imx-media-dev.c
create mode 100644 drivers/staging/media/imx/imx-media-fim.c
create mode 100644 drivers/staging/media/imx/imx-media-internal-sd.c
create mode 100644 drivers/staging/media/imx/imx-media-of.c
create mode 100644 drivers/staging/media/imx/imx-media-of.h
create mode 100644 drivers/staging/media/imx/imx-media.h
create mode 100644 drivers/staging/media/imx/imx-mipi-csi2.c
create mode 100644 drivers/staging/media/imx/imx-smfc.c
create mode 100644 drivers/staging/media/imx/imx-video-switch.c
create mode 100644 drivers/staging/media/imx/ov5640-mipi.c
create mode 100644 drivers/staging/media/imx/ov5642.c
create mode 100644 include/media/imx.h
create mode 100644 include/uapi/media/Kbuild
create mode 100644 include/uapi/media/imx.h
--
2.7.4
^ permalink raw reply
* [PATCH v1] watchdog: imx2: fix hang-up on boot for i.MX21, i.MX27 and i.MX31 SoCs
From: Uwe Kleine-König @ 2016-12-29 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CBfiRMicxvGyHrm-rQFzn8yEQyb5=t49PBr6rdpZYPug@mail.gmail.com>
On Wed, Dec 28, 2016 at 09:39:51PM -0200, Fabio Estevam wrote:
> On Wed, Dec 28, 2016 at 7:46 PM, Uwe Kleine-K?nig
> <u.kleine-koenig@pengutronix.de> wrote:
>
> > Right, so they would fall back to the i.MX21 type and not profit from
> > Markus' change until either the dtb is updated or the third commit is
> > added. I'll try to contact Markus to ask if he remembers more details.
>
> There is no profit from Markus' change for mx21/mx27/mx31.
Ack. If you teach the driver now about i.MX35 and only make use of the WMCR
register on this one, the possible breakage is that this register isn't
written to on the i.MX35 type until the dtb is updated.
> As Vladimir explained in his commit log these SoCs do not have the
> WMCR register, which causes a hang on these SoCs when we try to write
> to it.
So this should be fixed by adding support for i.MX35.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [BUG] ARM64: amlogic: gxbb: unhandled level 2 translation fault (11)
From: Heinrich Schuchardt @ 2016-12-29 21:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <478f1429-03f2-a944-8d47-3757a4d44a40@baylibre.com>
On 12/29/2016 10:07 AM, Neil Armstrong wrote:
> On 12/24/2016 03:00 PM, Heinrich Schuchardt wrote:
>> When trying to run sddm on an Hardkernel Odroid C2 I invariably run into the
>> translation fault below.
>>
>> The following mail thread relates this kind of problem to TLB (translation
>> lookaside buffer) broadcasting.
>>
>> https://lkml.org/lkml/2014/4/15/207
>>
>> [ 3163.014263] sddm[1851]: unhandled level 2 translation fault (11) at 0x00000160, esr 0x82000006
>> [ 3163.017287] pgd = ffff80007bf86000
>> [ 3163.020589] [00000160] *pgd=000000007a8a3003
>> [ 3163.024733] , *pud=000000007be9c003
>> [ 3163.028095] , *pmd=0000000000000000
>>
>>
>> [ 3163.033026] CPU: 1 PID: 1851 Comm: sddm Not tainted 4.9.0-next-20161212-r022-arm64 #1
>> [ 3163.040831] Hardware name: Hardkernel ODROID-C2 (DT)
>> [ 3163.045698] task: ffff80007bc6d780 task.stack: ffff80007c524000
>> [ 3163.051563] PC is at 0x160
>> [ 3163.054231] LR is at 0xffff9a9fbc98
>> [ 3163.057686] pc : [<0000000000000160>] lr : [<0000ffff9a9fbc98>] pstate: 40000000
>> [ 3163.065022] sp : 0000ffffd7180130
>> [ 3163.068281] x29: 0000ffffd7180130 x28: 0000ffffd7180288
>> [ 3163.073538] x27: 0000ffff9aa94000 x26: 0000000000000001
>> [ 3163.078798] x25: 0000000000000000 x24: 0000ffffd7180410
>> [ 3163.084060] x23: 000000000e0c2190 x22: 000000000e0ca5c0
>> [ 3163.089322] x21: 0000ffff9ac35000 x20: 0000000000454fa9
>> [ 3163.094583] x19: 0000000000454fa8 x18: 000000000e0b5938
>> [ 3163.099843] x17: 0000ffff9a3f2988 x16: 0000ffff9ac36aa0
>> [ 3163.105105] x15: 0000000000000000 x14: 0000000000000000
>> [ 3163.110367] x13: 6d00640064007300 x12: 0800000005000000
>> [ 3163.115627] x11: 0000040000000000 x10: 0000a00000000000
>> [ 3163.120889] x9 : 00003fffffffffff x8 : 0000000000000000
>> [ 3163.126150] x7 : 000000000e0cb520 x6 : 0000000000454fc0
>> [ 3163.131412] x5 : 0000ffffd717ffd8 x4 : 000000000e0cb510
>> [ 3163.136680] x3 : 0000000000000004 x2 : f2f9022b551b3900
>> [ 3163.141935] x1 : 0000000000000160 x0 : 000000000e0ca5c0
>>
>> Best regards
>>
>> Heinrich Schuchardt
>
> Hi Heinrich,
>
> I personally never had this issue even while loading huge applications loke LibreOffice and Gnome environment.
>
> I will have a look and try to reproduce this issue, can you provide us your configuration and user-space complete use case ?
>
> Neil
>
Hello Neil,
the kernel is build with
https://github.com/xypron/kernel-odroid-c2/tree/f8d565ff755e92fd585f5ae10123ce20abe03968
Especially look at the patch directory and config/config-next-20161212.
The userland is Debian Stretch with this package:
https://packages.debian.org/stretch/sddm
The link
https://www.spinics.net/lists/arm-kernel/msg550204.html
that you mention in a separate mail just links to this very thread due
to linux-arm-kernel at lists.infradead.org being in copy.
Best regards
Heinrich Schuchardt
^ permalink raw reply
* [PATCH 2/2] rcar-pcie: set host bridge's DMA mask
From: Nikita Yushchenko @ 2016-12-29 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com>
This gives platform DMA mapping code a chance to disallow setting device
DMA mask to something that host bridge can't support.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
---
drivers/pci/host/pcie-rcar.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index aca85be..b1edc3c 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -451,6 +451,7 @@ static int rcar_pcie_enable(struct rcar_pcie *pcie)
{
struct device *dev = pcie->dev;
struct pci_bus *bus, *child;
+ struct pci_host_bridge *bridge;
LIST_HEAD(res);
/* Try setting 5 GT/s link speed */
@@ -480,6 +481,10 @@ static int rcar_pcie_enable(struct rcar_pcie *pcie)
list_for_each_entry(child, &bus->children, node)
pcie_bus_configure_settings(child);
+ bridge = pci_find_host_bridge(bus);
+ bridge->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ bridge->dev.dma_mask = &bridge->dev.coherent_dma_mask;
+
pci_bus_add_devices(bus);
return 0;
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Nikita Yushchenko @ 2016-12-29 20:45 UTC (permalink / raw)
To: linux-arm-kernel
It is possible that PCI device supports 64-bit DMA addressing, and thus
it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host
bridge has limitations on inbound transactions addressing. Example of
such setup is NVME SSD device connected to RCAR PCIe controller.
Previously there was attempt to handle this via bus notifier: after
driver is attached to PCI device, bridge driver gets notifier callback,
and resets dma_mask from there. However, this is racy: PCI device driver
could already allocate buffers and/or start i/o in probe routine.
In NVME case, i/o is started in workqueue context, and this race gives
"sometimes works, sometimes not" effect.
Proper solution should make driver's dma_set_mask() call to fail if host
bridge can't support mask being set.
This patch makes __swiotlb_dma_supported() to check mask being set for
PCI device against dma_mask of struct device corresponding to PCI host
bridge (one with name "pciXXXX:YY"), if that dma_mask is set.
This is the least destructive approach: currently dma_mask of that device
object is not used anyhow, thus all existing setups will work as before,
and modification is required only in actually affected components -
driver of particular PCI host bridge, and dma_map_ops of particular
platform.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
---
arch/arm64/mm/dma-mapping.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 290a84f..49645277 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -28,6 +28,7 @@
#include <linux/dma-contiguous.h>
#include <linux/vmalloc.h>
#include <linux/swiotlb.h>
+#include <linux/pci.h>
#include <asm/cacheflush.h>
@@ -347,6 +348,16 @@ static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
static int __swiotlb_dma_supported(struct device *hwdev, u64 mask)
{
+#ifdef CONFIG_PCI
+ if (dev_is_pci(hwdev)) {
+ struct pci_dev *pdev = to_pci_dev(hwdev);
+ struct pci_host_bridge *br = pci_find_host_bridge(pdev->bus);
+
+ if (br->dev.dma_mask && (*br->dev.dma_mask) &&
+ (mask & (*br->dev.dma_mask)) != mask)
+ return 0;
+ }
+#endif
if (swiotlb)
return swiotlb_dma_supported(hwdev, mask);
return 1;
--
2.1.4
^ permalink raw reply related
* [PATCH 4/6] ARM: mach-mx35_3ds: Remove camera support
From: Fabio Estevam @ 2016-12-29 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM=E1R4a6Qd1ib-cmRi4PzuDXPDwLEarHOxc6aDDVLDZcWvVeQ@mail.gmail.com>
On Thu, Dec 29, 2016 at 5:07 PM, Magnus Lilja <lilja.magnus@gmail.com> wrote:
> Ok, good, so vcam is used for something else than camera then?
Yes, vcam is used to power de sgtl5000 codec:
static struct regulator_consumer_supply vcam_consumers[] = {
/* sgtl5000 */
REGULATOR_SUPPLY("VDDA", "0-000a"),
};
^ permalink raw reply
* [PATCH 00/39] ARM: dts: mvebu: Fix license text
From: Rafał Miłecki @ 2016-12-29 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214223746.23066-1-alexandre.belloni@free-electrons.com>
On 14 December 2016 at 23:37, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> When the license was switched to dual GPLv2/X11, the text that was used
> was missing a few characters. Fix that now.
>
> I'll let the maintainers decide whether this change requires an ack of
> every contributors. It has been separated with that in mind if
> necessary.
Acked-by: Rafa? Mi?ecki <zajec5@gmail.com>
for patches I was cc-ed in, I think a complete list is:
01
05
08
10
14
15
20
23
24
26
34
^ permalink raw reply
* [PATCH 4/6] ARM: mach-mx35_3ds: Remove camera support
From: Magnus Lilja @ 2016-12-29 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CF8QiJ21VbJCs4nj-WiAnfhsU0v7XpLGM3rcN1GoPiMQ@mail.gmail.com>
On 29 December 2016 at 19:55, Fabio Estevam <festevam@gmail.com> wrote:
> On Thu, Dec 29, 2016 at 4:41 PM, Magnus Lilja <lilja.magnus@gmail.com> wrote:
>
>> Umm, did you really mean to remove VAUDIO/vaudio_init stuff in this
>> camera related patch?
>
> VAUDIO is the MC13783 PMIC output name, but despite its name it has no
> relationship with the audio circuitry on mx35pdk board.
>
> It powers the OV2640 camera on this board, so it is safe to remove it.
Ok, good, so vcam is used for something else than camera then?
/Magnus
^ permalink raw reply
* [PATCH 4/6] ARM: mach-mx35_3ds: Remove camera support
From: Fabio Estevam @ 2016-12-29 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM=E1R64X6o0o604gGiU4+uQ6W_PUSbzgpaAYWSYEiSz_D8uGQ@mail.gmail.com>
On Thu, Dec 29, 2016 at 4:41 PM, Magnus Lilja <lilja.magnus@gmail.com> wrote:
> Umm, did you really mean to remove VAUDIO/vaudio_init stuff in this
> camera related patch?
VAUDIO is the MC13783 PMIC output name, but despite its name it has no
relationship with the audio circuitry on mx35pdk board.
It powers the OV2640 camera on this board, so it is safe to remove it.
^ permalink raw reply
* [PATCH 1/6] ARM: mach-mx31_3ds: Remove camera support
From: Fabio Estevam @ 2016-12-29 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM=E1R4ExOmqn3YCjS6wVtpCS13=dAPDtT9sgYxcAgc4UreV=A@mail.gmail.com>
On Thu, Dec 29, 2016 at 4:44 PM, Magnus Lilja <lilja.magnus@gmail.com> wrote:
> So we keep the init of the other CSI pins bit not the power down and
> reset? Can / should the other CSI pins also be removed?
Yes, I will remove CSI pins in v2.
> I've run-time tested the patch on the i.MX31 PDK board now and it works.
Thanks for testing.
^ permalink raw reply
* [PATCH 1/6] ARM: mach-mx31_3ds: Remove camera support
From: Magnus Lilja @ 2016-12-29 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482756987-12414-1-git-send-email-festevam@gmail.com>
Hi
On 26 December 2016 at 13:56, Fabio Estevam <festevam@gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Since commit c93cc61475ebbe6e66 ("[media] staging/media: remove deprecated
> mx3 driver") the mx3 camera driver has been removed, so remove the camera
> support from the board file as well.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> arch/arm/mach-imx/mach-mx31_3ds.c | 145 --------------------------------------
> 1 file changed, 145 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c b/arch/arm/mach-imx/mach-mx31_3ds.c
> index 12b8a52..ada29d0 100644
> --- a/arch/arm/mach-imx/mach-mx31_3ds.c
> +++ b/arch/arm/mach-imx/mach-mx31_3ds.c
> @@ -26,16 +26,12 @@
> #include <linux/regulator/machine.h>
> #include <linux/usb/otg.h>
> #include <linux/usb/ulpi.h>
> -#include <linux/memblock.h>
> -
> -#include <media/soc_camera.h>
>
> #include <asm/mach-types.h>
> #include <asm/mach/arch.h>
> #include <asm/mach/time.h>
> #include <asm/memory.h>
> #include <asm/mach/map.h>
> -#include <asm/memblock.h>
>
> #include "3ds_debugboard.h"
> #include "common.h"
> @@ -152,8 +148,6 @@ static int mx31_3ds_pins[] = {
> MX31_PIN_CSI_MCLK__CSI_MCLK,
> MX31_PIN_CSI_PIXCLK__CSI_PIXCLK,
> MX31_PIN_CSI_VSYNC__CSI_VSYNC,
> - MX31_PIN_CSI_D5__GPIO3_5, /* CMOS PWDN */
> - IOMUX_MODE(MX31_PIN_RI_DTE1, IOMUX_CONFIG_GPIO), /* CMOS reset */
So we keep the init of the other CSI pins bit not the power down and
reset? Can / should the other CSI pins also be removed?
I've run-time tested the patch on the i.MX31 PDK board now and it works.
Regards, Magnus
^ permalink raw reply
* [PATCH 4/6] ARM: mach-mx35_3ds: Remove camera support
From: Magnus Lilja @ 2016-12-29 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482756987-12414-4-git-send-email-festevam@gmail.com>
Hi
On 26 December 2016 at 13:56, Fabio Estevam <festevam@gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Since commit c93cc61475ebbe6e66 ("[media] staging/media: remove deprecated
> mx3 driver") the mx3 camera driver has been removed, so remove the camera
> support from the board file as well.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> arch/arm/mach-imx/mach-mx35_3ds.c | 88 ---------------------------------------
> 1 file changed, 88 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mach-mx35_3ds.c b/arch/arm/mach-imx/mach-mx35_3ds.c
> index c8c2e09..64fc161 100644
> --- a/arch/arm/mach-imx/mach-mx35_3ds.c
> +++ b/arch/arm/mach-imx/mach-mx35_3ds.c
...
> @@ -321,10 +260,6 @@ static struct regulator_consumer_supply vcam_consumers[] = {
> REGULATOR_SUPPLY("VDDA", "0-000a"),
> };
>
> -static struct regulator_consumer_supply vaudio_consumers[] = {
> - REGULATOR_SUPPLY("cmos_vio", "soc-camera-pdrv.0"),
> -};
> -
> static struct regulator_init_data sw1_init = {
> .constraints = {
> .name = "SW1",
> @@ -405,18 +340,6 @@ static struct regulator_init_data vvideo_init = {
> }
> };
>
> -static struct regulator_init_data vaudio_init = {
> - .constraints = {
> - .name = "VAUDIO",
> - .min_uV = 2300000,
> - .max_uV = 3000000,
> - .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
> - .boot_on = 1
> - },
> - .num_consumer_supplies = ARRAY_SIZE(vaudio_consumers),
> - .consumer_supplies = vaudio_consumers,
> -};
> -
> static struct regulator_init_data vcam_init = {
> .constraints = {
> .name = "VCAM",
> @@ -460,7 +383,6 @@ static struct mc13xxx_regulator_init_data mx35_3ds_regulators[] = {
> { .id = MC13892_VDIG, .init_data = &vdig_init },
> { .id = MC13892_VUSB2, .init_data = &vusb2_init },
> { .id = MC13892_VVIDEO, .init_data = &vvideo_init },
> - { .id = MC13892_VAUDIO, .init_data = &vaudio_init },
> { .id = MC13892_VCAM, .init_data = &vcam_init },
Umm, did you really mean to remove VAUDIO/vaudio_init stuff in this
camera related patch?
Regards, Magnus
^ permalink raw reply
* [PATCH v1] mtd: nand: tango: Update DT binding description
From: Boris Brezillon @ 2016-12-29 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ba47f2f1-bcdc-91e8-ed79-153931ccdad8@sigmadesigns.com>
On Mon, 19 Dec 2016 15:30:12 +0100
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> wrote:
> Visually separate register ranges (address/size pairs) in reg prop.
> Change DMA channel name, for consistency with other drivers.
>
> Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
> ---
> Documentation/devicetree/bindings/mtd/tango-nand.txt | 6 +++---
> drivers/mtd/nand/tango_nand.c | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/tango-nand.txt b/Documentation/devicetree/bindings/mtd/tango-nand.txt
> index ad5a02f2ac8c..cd1bf2ac9055 100644
> --- a/Documentation/devicetree/bindings/mtd/tango-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/tango-nand.txt
> @@ -5,7 +5,7 @@ Required properties:
> - compatible: "sigma,smp8758-nand"
> - reg: address/size of nfc_reg, nfc_mem, and pbus_reg
> - dmas: reference to the DMA channel used by the controller
> -- dma-names: "nfc_sbox"
> +- dma-names: "rxtx"
You probably want to fix the driver accordingly ;-).
> - clocks: reference to the system clock
> - #address-cells: <1>
> - #size-cells: <0>
> @@ -17,9 +17,9 @@ Example:
>
> nandc: nand-controller at 2c000 {
> compatible = "sigma,smp8758-nand";
> - reg = <0x2c000 0x30 0x2d000 0x800 0x20000 0x1000>;
> + reg = <0x2c000 0x30>, <0x2d000 0x800>, <0x20000 0x1000>;
> dmas = <&dma0 3>;
> - dma-names = "nfc_sbox";
> + dma-names = "rxtx";
> clocks = <&clkgen SYS_CLK>;
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/drivers/mtd/nand/tango_nand.c b/drivers/mtd/nand/tango_nand.c
> index cc23db64f0ca..51dc88d6b8da 100644
> --- a/drivers/mtd/nand/tango_nand.c
> +++ b/drivers/mtd/nand/tango_nand.c
> @@ -629,7 +629,7 @@ static int tango_nand_probe(struct platform_device *pdev)
> if (IS_ERR(clk))
> return PTR_ERR(clk);
>
> - nfc->chan = dma_request_chan(&pdev->dev, "nfc_sbox");
> + nfc->chan = dma_request_chan(&pdev->dev, "rxtx");
> if (IS_ERR(nfc->chan))
> return PTR_ERR(nfc->chan);
>
^ permalink raw reply
* [PATCHv2 net-next 00/11] net: mvpp2: misc improvements and preparation patches
From: David Miller @ 2016-12-29 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482943567-12483-1-git-send-email-thomas.petazzoni@free-electrons.com>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Wed, 28 Dec 2016 17:45:56 +0100
> This series contains a number of misc improvements and preparation
> patches for an upcoming series that adds support for the new PPv2.2
> network controller to the mvpp2 driver.
>
> The most significant improvements are:
>
> - Switching to using build_skb(), which is necessary for the upcoming
> PPv2.2 support, but anyway a good improvement to the current mvpp2
> driver (supporting PPv2.1).
>
> - Making the driver build on 64-bit platforms.
>
> Changes since v1:
>
> - This series is split as a separate series from the larger patch set
> adding support for PPv2.2 in the mvpp2 driver, as requested by
> David Miller.
>
> - Rebased on top of v4.10-rc1.
You still have warnings to fix for the 64-bit build:
drivers/net/ethernet/marvell/mvpp2.c: In function ?mvpp2_rx?:
drivers/net/ethernet/marvell/mvpp2.c:5125:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
data = (void *)rx_desc->buf_cookie;
^
^ permalink raw reply
* Unhandled level 2 translation fault (11) at 0x000000b8, esr 0x92000046, rpi3 (aarch64)
From: Neil Armstrong @ 2016-12-29 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGDbNAD7-TM6+x0A3FebTOPYmqQqbm1w29ZwH+9qePaAvhxTKw@mail.gmail.com>
On 12/29/2016 05:38 PM, Bas van Tiel wrote:
> Hi,
>
> when using a signal handler as a way to context switch between
> different usercontexts a reproducible exception occurs on my rpi3 in
> 64-bit mode. (https://gist.github.com/DanGe42/7148946)
>
> Running the context_demo program as a 32-bit ARM executable on a
> 64-bit kernel is OK, running as a 32 || 64 bit executable on an x86
> kernel is OK.
>
> In the first exception the PC doesn?t look correct, and the *pmd is 0.
> The 2nd exception happens after running the program again, the PC is 0x0.
>
> A successful function trace was not possible -> complete kernel hangup
> when enabling.
>
> Is there another way to gather more information about what is happening?
>
> Linux (none) 4.10.0-rc1-v8+ #3 SMP PREEMPT Thu Dec 29 12:10:12 CET
> 2016 aarch64 GNU/Linux
>
> [ 46.350738] a.out[196]: unhandled level 2 translation fault (11) at
> 0x000000b8, esr 0x92000046
> [ 46.360516] pgd = ffffffc0392cb000
> [ 46.365377] [000000b8] *pgd=00000000392ec003
> [ 46.365381] , *pud=00000000392ec003
> [ 46.370878] , *pmd=0000000000000000
> [ 46.375907]
> [ 46.383974]
> [ 46.389107] CPU: 0 PID: 196 Comm: a.out Not tainted 4.10.0-rc1-v8+ #3
> [ 46.397949] Hardware name: Raspberry Pi 3 Model B (DT)
> [ 46.406218] task: ffffffc039ad6580 task.stack: ffffffc039bfc000
> [ 46.413892] PC is at 0x7fb4e34810
> [ 46.418230] LR is at 0x400b84
> [ 46.422956] pc : [<0000007fb4e34810>] lr : [<0000000000400b84>]
> pstate: 60000000
> [ 46.431522] sp : 0000000000413350
> [ 46.436480] x29: 0000000000413350 x28: 0000000000000016
> [ 46.443142] x27: 0000000000000000 x26: 0000000000000020
> [ 46.451908] x25: 0000007fb4f35488 x24: 0000000000415f00
> [ 46.459641] x23: 0000000000000016 x22: 0000000000400b84
> [ 46.469198] x21: 0000000000413670 x20: 0000000000417030
> [ 46.476970] x19: 0000000000001000 x18: 0000000000000000
> [ 46.484744] x17: 0000007fb4e34810 x16: 0000000000411270
> [ 46.492175] x15: 00000000000005f1 x14: 0000000000000000
> [ 46.498884] x13: 0000000000000000 x12: 0000000000000000
> [ 46.506013] x11: 0000000000000020 x10: 0101010101010101
> [ 46.517164] x9 : 0000000000413670 x8 : 00000000ffffffe0
> [ 46.525541] x7 : 0000000000413350 x6 : 0000000000413350
> [ 46.533495] x5 : 00000000ffffffe0 x4 : 0000000000413730
> [ 46.544052] x3 : 0000000000000008 x2 : 0000000000000000
> [ 46.552211] x1 : 0000000000413670 x0 : 0000000000000000
> [ 46.558668]
>
> 2nd time startup of the executable
>
> [ 262.565147] a.out[201]: unhandled level 2 translation fault (11) at
> 0x00000000, esr 0x82000006
> [ 262.575243] pgd = ffffffc03939a000
> [ 262.579948] [00000000] *pgd=000000003938f003
> [ 262.579951] , *pud=000000003938f003
> [ 262.586040] , *pmd=0000000000000000
> [ 262.590479]
> [ 262.598234]
> [ 262.601108] CPU: 0 PID: 201 Comm: a.out Not tainted 4.10.0-rc1-v8+ #3
> [ 262.609086] Hardware name: Raspberry Pi 3 Model B (DT)
> [ 262.615731] task: ffffffc03904a600 task.stack: ffffffc039bfc000
> [ 262.621768] PC is at 0x0
> [ 262.624300] LR is at 0x0
> [ 262.626835] pc : [<0000000000000000>] lr : [<0000000000000000>]
> pstate: 60000000
> [ 262.634437] sp : 00000000004159c0
> [ 262.637753] x29: 0000000000000000 x28: 0000000000000000
> [ 262.643242] x27: 0000000000000000 x26: 0000000000000000
> [ 262.648554] x25: 0000000000000000 x24: 0000000000000000
> [ 262.654033] x23: 0000000000000000 x22: 0000000000000000
> [ 262.659349] x21: 00000000004008f0 x20: 0000000000000000
> [ 262.664825] x19: 0000000000000000 x18: 0000000000000000
> [ 262.670145] x17: 0000007fb065b620 x16: 0000000000400b84
> [ 262.675622] x15: 00000000000003d1 x14: 0000000000000000
> [ 262.680938] x13: 0000000000000000 x12: 0000000000000000
> [ 262.686413] x11: 0000000000000020 x10: 0101010101010101
> [ 262.691835] x9 : 00000000004112c0 x8 : 0000000000000087
> [ 262.697159] x7 : 0000000000000000 x6 : 0000000000000000
> [ 262.702634] x5 : 0000000000000000 x4 : 0000000000000000
> [ 262.707949] x3 : 0000000000000000 x2 : 0000000000000000
> [ 262.713424] x1 : 0000000000000000 x0 : 0000000000000000
> [ 262.718739]
>
> rpi3:
> minimal kernel (64-bit, cortex-a53, little endian, 4Kb page,
> initramfs), different kernels tried 4.8/4.9/4.10.0-rc1-v8+ the same
> result occurs, also with different compilers.
>
> kernel, aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
> application, aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
>
> The only item I found by reading through the different source-files was the
> structure definition of struct kernel_rt_sigframe
> (http://osxr.org:8080/glibc/source/ports/sysdeps/unix/sysv/linux/aarch64/kernel_rt_sigframe.h?v=glibc-2.18)
> compared to the struct rt_sigframe (linux/arch/arm64/signal.c).
>
> Any help or pointers to solve this issue are welcome,
>
> regards
> Bas
>
Hi,
The same issue was reported on Amlogic 64bit aswell : https://www.spinics.net/lists/arm-kernel/msg550204.html
Neil
^ permalink raw reply
* Unhandled level 2 translation fault (11) at 0x000000b8, esr 0x92000046, rpi3 (aarch64)
From: Bas van Tiel @ 2016-12-29 16:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
when using a signal handler as a way to context switch between
different usercontexts a reproducible exception occurs on my rpi3 in
64-bit mode. (https://gist.github.com/DanGe42/7148946)
Running the context_demo program as a 32-bit ARM executable on a
64-bit kernel is OK, running as a 32 || 64 bit executable on an x86
kernel is OK.
In the first exception the PC doesn?t look correct, and the *pmd is 0.
The 2nd exception happens after running the program again, the PC is 0x0.
A successful function trace was not possible -> complete kernel hangup
when enabling.
Is there another way to gather more information about what is happening?
Linux (none) 4.10.0-rc1-v8+ #3 SMP PREEMPT Thu Dec 29 12:10:12 CET
2016 aarch64 GNU/Linux
[ 46.350738] a.out[196]: unhandled level 2 translation fault (11) at
0x000000b8, esr 0x92000046
[ 46.360516] pgd = ffffffc0392cb000
[ 46.365377] [000000b8] *pgd=00000000392ec003
[ 46.365381] , *pud=00000000392ec003
[ 46.370878] , *pmd=0000000000000000
[ 46.375907]
[ 46.383974]
[ 46.389107] CPU: 0 PID: 196 Comm: a.out Not tainted 4.10.0-rc1-v8+ #3
[ 46.397949] Hardware name: Raspberry Pi 3 Model B (DT)
[ 46.406218] task: ffffffc039ad6580 task.stack: ffffffc039bfc000
[ 46.413892] PC is at 0x7fb4e34810
[ 46.418230] LR is at 0x400b84
[ 46.422956] pc : [<0000007fb4e34810>] lr : [<0000000000400b84>]
pstate: 60000000
[ 46.431522] sp : 0000000000413350
[ 46.436480] x29: 0000000000413350 x28: 0000000000000016
[ 46.443142] x27: 0000000000000000 x26: 0000000000000020
[ 46.451908] x25: 0000007fb4f35488 x24: 0000000000415f00
[ 46.459641] x23: 0000000000000016 x22: 0000000000400b84
[ 46.469198] x21: 0000000000413670 x20: 0000000000417030
[ 46.476970] x19: 0000000000001000 x18: 0000000000000000
[ 46.484744] x17: 0000007fb4e34810 x16: 0000000000411270
[ 46.492175] x15: 00000000000005f1 x14: 0000000000000000
[ 46.498884] x13: 0000000000000000 x12: 0000000000000000
[ 46.506013] x11: 0000000000000020 x10: 0101010101010101
[ 46.517164] x9 : 0000000000413670 x8 : 00000000ffffffe0
[ 46.525541] x7 : 0000000000413350 x6 : 0000000000413350
[ 46.533495] x5 : 00000000ffffffe0 x4 : 0000000000413730
[ 46.544052] x3 : 0000000000000008 x2 : 0000000000000000
[ 46.552211] x1 : 0000000000413670 x0 : 0000000000000000
[ 46.558668]
2nd time startup of the executable
[ 262.565147] a.out[201]: unhandled level 2 translation fault (11) at
0x00000000, esr 0x82000006
[ 262.575243] pgd = ffffffc03939a000
[ 262.579948] [00000000] *pgd=000000003938f003
[ 262.579951] , *pud=000000003938f003
[ 262.586040] , *pmd=0000000000000000
[ 262.590479]
[ 262.598234]
[ 262.601108] CPU: 0 PID: 201 Comm: a.out Not tainted 4.10.0-rc1-v8+ #3
[ 262.609086] Hardware name: Raspberry Pi 3 Model B (DT)
[ 262.615731] task: ffffffc03904a600 task.stack: ffffffc039bfc000
[ 262.621768] PC is at 0x0
[ 262.624300] LR is at 0x0
[ 262.626835] pc : [<0000000000000000>] lr : [<0000000000000000>]
pstate: 60000000
[ 262.634437] sp : 00000000004159c0
[ 262.637753] x29: 0000000000000000 x28: 0000000000000000
[ 262.643242] x27: 0000000000000000 x26: 0000000000000000
[ 262.648554] x25: 0000000000000000 x24: 0000000000000000
[ 262.654033] x23: 0000000000000000 x22: 0000000000000000
[ 262.659349] x21: 00000000004008f0 x20: 0000000000000000
[ 262.664825] x19: 0000000000000000 x18: 0000000000000000
[ 262.670145] x17: 0000007fb065b620 x16: 0000000000400b84
[ 262.675622] x15: 00000000000003d1 x14: 0000000000000000
[ 262.680938] x13: 0000000000000000 x12: 0000000000000000
[ 262.686413] x11: 0000000000000020 x10: 0101010101010101
[ 262.691835] x9 : 00000000004112c0 x8 : 0000000000000087
[ 262.697159] x7 : 0000000000000000 x6 : 0000000000000000
[ 262.702634] x5 : 0000000000000000 x4 : 0000000000000000
[ 262.707949] x3 : 0000000000000000 x2 : 0000000000000000
[ 262.713424] x1 : 0000000000000000 x0 : 0000000000000000
[ 262.718739]
rpi3:
minimal kernel (64-bit, cortex-a53, little endian, 4Kb page,
initramfs), different kernels tried 4.8/4.9/4.10.0-rc1-v8+ the same
result occurs, also with different compilers.
kernel, aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
application, aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
The only item I found by reading through the different source-files was the
structure definition of struct kernel_rt_sigframe
(http://osxr.org:8080/glibc/source/ports/sysdeps/unix/sysv/linux/aarch64/kernel_rt_sigframe.h?v=glibc-2.18)
compared to the struct rt_sigframe (linux/arch/arm64/signal.c).
Any help or pointers to solve this issue are welcome,
regards
Bas
^ 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