* [PATCH 17/18] arm64: dts: r8a7795: Add device node for PRR
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 681f54422375..a39a702b904d 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -321,6 +321,11 @@
#power-domain-cells = <0>;
};
+ prr: chipid at fff00044 {
+ compatible = "renesas,prr";
+ reg = <0 0xfff00044 0 4>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7795-sysc";
reg = <0 0xe6180000 0 0x0400>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 16/18] arm64: dts: h3ulcb: rename SDHI0 pins
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This changes SDHI0 pin names for H3ULCB board
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index 8d0ac076d8e2..6ffb0517421a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -163,13 +163,13 @@
function = "avb";
};
- sdhi0_pins_3v3: sd0_3v3 {
+ sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
power-source = <3300>;
};
- sdhi0_pins_1v8: sd0_1v8 {
+ sdhi0_pins_uhs: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
power-source = <1800>;
@@ -291,8 +291,8 @@
};
&sdhi0 {
- pinctrl-0 = <&sdhi0_pins_3v3>;
- pinctrl-1 = <&sdhi0_pins_1v8>;
+ pinctrl-0 = <&sdhi0_pins>;
+ pinctrl-1 = <&sdhi0_pins_uhs>;
pinctrl-names = "default", "state_uhs";
vmmc-supply = <&vcc_sdhi0>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 15/18] arm64: dts: h3ulcb: enable SDHI2
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This supports SDHI2 for H3ULCB onboard eMMC
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 43 ++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index f178fe1730de..8d0ac076d8e2 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -62,6 +62,24 @@
clock-frequency = <24576000>;
};
+ reg_1p8v: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
vcc_sdhi0: regulator-vcc-sdhi0 {
compatible = "regulator-fixed";
@@ -157,6 +175,18 @@
power-source = <1800>;
};
+ sdhi2_pins: sd2 {
+ groups = "sdhi2_data8", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <3300>;
+ };
+
+ sdhi2_pins_uhs: sd2_uhs {
+ groups = "sdhi2_data8", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <1800>;
+ };
+
sound_pins: sound {
groups = "ssi01239_ctrl", "ssi0_data", "ssi1_data_a";
function = "ssi";
@@ -273,6 +303,19 @@
status = "okay";
};
+&sdhi2 {
+ /* used for on-board 8bit eMMC */
+ pinctrl-0 = <&sdhi2_pins>;
+ pinctrl-1 = <&sdhi2_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_1p8v>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
&ssi1 {
shared-pin;
};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 14/18] arm64: dts: m3ulcb: enable SDHI2
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This supports SDHI2 for M3ULCB onboard eMMC
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 43 ++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index d209e5480ff6..c3f064ac2cb4 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -55,6 +55,24 @@
};
};
+ reg_1p8v: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
vcc_sdhi0: regulator-vcc-sdhi0 {
compatible = "regulator-fixed";
@@ -113,6 +131,18 @@
function = "sdhi0";
power-source = <1800>;
};
+
+ sdhi2_pins: sd2 {
+ groups = "sdhi2_data8", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <3300>;
+ };
+
+ sdhi2_pins_uhs: sd2_uhs {
+ groups = "sdhi2_data8", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <1800>;
+ };
};
&sdhi0 {
@@ -128,6 +158,19 @@
status = "okay";
};
+&sdhi2 {
+ /* used for on-board 8bit eMMC */
+ pinctrl-0 = <&sdhi2_pins>;
+ pinctrl-1 = <&sdhi2_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_1p8v>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
&scif2 {
pinctrl-0 = <&scif2_pins>;
pinctrl-names = "default";
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 13/18] arm64: dts: m3ulcb: enable SDHI0
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This supports SDHI0 on M3ULCB board SD card slot
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 49 ++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index 593d0b4ab31a..d209e5480ff6 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -54,6 +54,30 @@
gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
};
};
+
+ vcc_sdhi0: regulator-vcc-sdhi0 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI0 Vcc";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&gpio5 2 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vccq_sdhi0: regulator-vccq-sdhi0 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI0 VccQ";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <3300000 1
+ 1800000 0>;
+ };
};
&extal_clk {
@@ -77,6 +101,31 @@
groups = "scif_clk_a";
function = "scif_clk";
};
+
+ sdhi0_pins: sd0 {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <3300>;
+ };
+
+ sdhi0_pins_uhs: sd0_uhs {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <1800>;
+ };
+};
+
+&sdhi0 {
+ pinctrl-0 = <&sdhi0_pins>;
+ pinctrl-1 = <&sdhi0_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <&vcc_sdhi0>;
+ vqmmc-supply = <&vccq_sdhi0>;
+ cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ sd-uhs-sdr50;
+ status = "okay";
};
&scif2 {
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 12/18] arm64: dts: m3ulcb: enable WDT
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This supports watchdog timer for M3ULCB board
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index 5567c46f3753..593d0b4ab31a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -90,3 +90,8 @@
clock-frequency = <14745600>;
status = "okay";
};
+
+&wdt0 {
+ timeout-sec = <60>;
+ status = "okay";
+};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 11/18] arm64: dts: m3ulcb: enable EXTALR clk
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This enables EXTALR clock that can be used for the watchdog.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index 2f8f183ea0cd..5567c46f3753 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -60,6 +60,10 @@
clock-frequency = <16666666>;
};
+&extalr_clk {
+ clock-frequency = <32768>;
+};
+
&pfc {
pinctrl-0 = <&scif_clk_pins>;
pinctrl-names = "default";
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 10/18] arm64: dts: m3ulcb: enable GPIO keys
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This supports GPIO keys on M3ULCB board
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index 49162bd488f8..2f8f183ea0cd 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -12,6 +12,7 @@
/dts-v1/;
#include "r8a7796.dtsi"
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
/ {
model = "Renesas M3ULCB board based on r8a7796";
@@ -41,6 +42,18 @@
gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>;
};
};
+
+ keyboard {
+ compatible = "gpio-keys";
+
+ key-1 {
+ linux,code = <KEY_1>;
+ label = "SW3";
+ wakeup-source;
+ debounce-interval = <20>;
+ gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+ };
+ };
};
&extal_clk {
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 09/18] arm64: dts: m3ulcb: enable GPIO leds
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This supports GPIO leds on M3ULCB board
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index 96cda59c2698..49162bd488f8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -30,6 +30,17 @@
/* first 128MB is reserved for secure area. */
reg = <0x0 0x48000000 0x0 0x38000000>;
};
+
+ leds {
+ compatible = "gpio-leds";
+
+ led5 {
+ gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
+ };
+ led6 {
+ gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>;
+ };
+ };
};
&extal_clk {
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 08/18] arm64: dts: m3ulcb: enable SCIF clk and pins
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This enables the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index 1ae0708bb495..96cda59c2698 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -37,10 +37,18 @@
};
&pfc {
+ pinctrl-0 = <&scif_clk_pins>;
+ pinctrl-names = "default";
+
scif2_pins: scif2 {
groups = "scif2_data_a";
function = "scif2";
};
+
+ scif_clk_pins: scif_clk {
+ groups = "scif_clk_a";
+ function = "scif_clk";
+ };
};
&scif2 {
@@ -49,3 +57,8 @@
status = "okay";
};
+
+&scif_clk {
+ clock-frequency = <14745600>;
+ status = "okay";
+};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 07/18] arm64: dts: m3ulcb: initial device tree
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Add the initial device tree for the R8A7796 SoC based M3ULCB low cost
board (R-Car Starter Kit Pro)
This commit supports the following peripherals:
- SCIF (console)
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/Makefile | 2 +-
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 51 ++++++++++++++++++++++++++
2 files changed, 52 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
index eb72830ec9eb..1618e0a3c81d 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -1,5 +1,5 @@
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb
-dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb
+dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-m3ulcb.dtb
always := $(dtb-y)
clean-files := *.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
new file mode 100644
index 000000000000..1ae0708bb495
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -0,0 +1,51 @@
+/*
+ * Device Tree Source for the M3ULCB (R-Car Starter Kit Pro) board
+ *
+ * Copyright (C) 2016 Renesas Electronics Corp.
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7796.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ model = "Renesas M3ULCB board based on r8a7796";
+ compatible = "renesas,m3ulcb", "renesas,r8a7796";
+
+ aliases {
+ serial0 = &scif2;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory at 48000000 {
+ device_type = "memory";
+ /* first 128MB is reserved for secure area. */
+ reg = <0x0 0x48000000 0x0 0x38000000>;
+ };
+};
+
+&extal_clk {
+ clock-frequency = <16666666>;
+};
+
+&pfc {
+ scif2_pins: scif2 {
+ groups = "scif2_data_a";
+ function = "scif2";
+ };
+};
+
+&scif2 {
+ pinctrl-0 = <&scif2_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 06/18] arm64: dts: m3ulcb: add M3ULCB board DT bindings
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Add M3ULCB Device tree bindings Documentation, listing it as a supported
board.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 1c2499ca1bee..29bf24ca0b7b 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -61,6 +61,8 @@ Boards:
compatible = "renesas,kzm9g", "renesas,sh73a0"
- Lager (RTP0RC7790SEB00010S)
compatible = "renesas,lager", "renesas,r8a7790"
+ - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKB00010S)
+ compatible = "renesas,m3ulcb", "renesas,r8a7796";
- Marzen
compatible = "renesas,marzen", "renesas,r8a7779"
- Porter (M2-LCDP)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 05/18] arm64: dts: h3ulcb: update header
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This updates H3ULCB device tree header with official board name
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index bcb11a868343..f178fe1730de 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -1,5 +1,5 @@
/*
- * Device Tree Source for the H3ULCB board
+ * Device Tree Source for the H3ULCB (R-Car Starter Kit Premier) board
*
* Copyright (C) 2016 Renesas Electronics Corp.
* Copyright (C) 2016 Cogent Embedded, Inc.
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 04/18] arm64: dts: h3ulcb: update documentation with official board name
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This updates H3ULCB Device tree bindings Documentation with
official board name
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 2f0b7169f132..1c2499ca1bee 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -49,7 +49,7 @@ Boards:
compatible = "renesas,genmai", "renesas,r7s72100"
- Gose
compatible = "renesas,gose", "renesas,r8a7793"
- - H3ULCB (RTP0RC7795SKB00010S)
+ - H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKB00010S)
compatible = "renesas,h3ulcb", "renesas,r8a7795";
- Henninger
compatible = "renesas,henninger", "renesas,r8a7791"
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 03/18] arm64: dts: r8a7796: salvator-x: enable I2C
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index a9c296b1e1b7..f35e96ca7d60 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -111,6 +111,11 @@
function = "scif_clk";
};
+ i2c2_pins: i2c2 {
+ groups = "i2c2_a";
+ function = "i2c2";
+ };
+
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
@@ -208,6 +213,13 @@
status = "okay";
};
+&i2c2 {
+ pinctrl-0 = <&i2c2_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
&wdt0 {
timeout-sec = <60>;
status = "okay";
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 02/18] arm64: dts: r8a7796: Enable I2C DMA
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 2e940ff61378..9599f5691099 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -257,6 +257,9 @@
interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 931>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ dmas = <&dmac1 0x91>, <&dmac1 0x90>,
+ <&dmac2 0x91>, <&dmac2 0x90>;
+ dma-names = "tx", "rx", "tx", "rx";
i2c-scl-internal-delay-ns = <110>;
status = "disabled";
};
@@ -269,6 +272,9 @@
interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 930>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ dmas = <&dmac1 0x93>, <&dmac1 0x92>,
+ <&dmac2 0x93>, <&dmac2 0x92>;
+ dma-names = "tx", "rx", "tx", "rx";
i2c-scl-internal-delay-ns = <6>;
status = "disabled";
};
@@ -281,6 +287,9 @@
interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 929>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ dmas = <&dmac1 0x95>, <&dmac1 0x94>,
+ <&dmac2 0x95>, <&dmac2 0x94>;
+ dma-names = "tx", "rx", "tx", "rx";
i2c-scl-internal-delay-ns = <6>;
status = "disabled";
};
@@ -293,6 +302,8 @@
interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 928>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ dmas = <&dmac0 0x97>, <&dmac0 0x96>;
+ dma-names = "tx", "rx";
i2c-scl-internal-delay-ns = <110>;
status = "disabled";
};
@@ -305,6 +316,8 @@
interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 927>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ dmas = <&dmac0 0x99>, <&dmac0 0x98>;
+ dma-names = "tx", "rx";
i2c-scl-internal-delay-ns = <110>;
status = "disabled";
};
@@ -317,6 +330,8 @@
interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 919>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ dmas = <&dmac0 0x9b>, <&dmac0 0x9a>;
+ dma-names = "tx", "rx";
i2c-scl-internal-delay-ns = <110>;
status = "disabled";
};
@@ -329,6 +344,8 @@
interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 918>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ dmas = <&dmac0 0x9d>, <&dmac0 0x9c>;
+ dma-names = "tx", "rx";
i2c-scl-internal-delay-ns = <6>;
status = "disabled";
};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 01/18] arm64: dts: r8a7796: add I2C support
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 94 ++++++++++++++++++++++++++++++++
1 file changed, 94 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index f9cb7796ad49..2e940ff61378 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -17,6 +17,16 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
+ i2c6 = &i2c6;
+ };
+
psci {
compatible = "arm,psci-0.2";
method = "smc";
@@ -239,6 +249,90 @@
#power-domain-cells = <1>;
};
+ i2c0: i2c at e6500000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a7796";
+ reg = <0 0xe6500000 0 0x40>;
+ interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 931>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ i2c-scl-internal-delay-ns = <110>;
+ status = "disabled";
+ };
+
+ i2c1: i2c at e6508000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a7796";
+ reg = <0 0xe6508000 0 0x40>;
+ interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 930>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ i2c-scl-internal-delay-ns = <6>;
+ status = "disabled";
+ };
+
+ i2c2: i2c at e6510000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a7796";
+ reg = <0 0xe6510000 0 0x40>;
+ interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 929>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ i2c-scl-internal-delay-ns = <6>;
+ status = "disabled";
+ };
+
+ i2c3: i2c at e66d0000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a7796";
+ reg = <0 0xe66d0000 0 0x40>;
+ interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 928>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ i2c-scl-internal-delay-ns = <110>;
+ status = "disabled";
+ };
+
+ i2c4: i2c at e66d8000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a7796";
+ reg = <0 0xe66d8000 0 0x40>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 927>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ i2c-scl-internal-delay-ns = <110>;
+ status = "disabled";
+ };
+
+ i2c5: i2c at e66e0000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a7796";
+ reg = <0 0xe66e0000 0 0x40>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 919>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ i2c-scl-internal-delay-ns = <110>;
+ status = "disabled";
+ };
+
+ i2c6: i2c at e66e8000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a7796";
+ reg = <0 0xe66e8000 0 0x40>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 918>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ i2c-scl-internal-delay-ns = <6>;
+ status = "disabled";
+ };
+
scif2: serial at e6e88000 {
compatible = "renesas,scif-r8a7796",
"renesas,rcar-gen3-scif", "renesas,scif";
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [GIT PULL v2] Second Round of Renesas ARM64 Based SoC DT Updates for v4.10
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Kevin, Hi Arnd,
Please consider these second round of Renesas ARM64 based SoC DT updates for v4.10.
This pull request is based on the previous round of
such requests, tagged as renesas-arm64-dt-for-v4.10,
which I have already sent a pull-request for.
Changes since v1:
* No longer includes unnecessary dependencies in base
The following changes since commit 935085209343a0c507e3d9a3e01883b25c8f743e:
arm64: renesas: r8a7796: add SYS-DMAC controller nodes (2016-11-04 10:18:07 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-dt2-for-v4.10
for you to fetch changes up to 5de68961cf5618c1ce5bb15848b36121247f23d5:
arm64: dts: r8a7796: Add device node for PRR (2016-11-21 10:18:53 +0100)
----------------------------------------------------------------
Second Round of Renesas ARM64 Based SoC DT Updates for v4.10
Enhancements:
* Add device nodes for PRR
* Add m3ulcb board
* Enable I2C on r8a7796/salvator-x board
* Enable SDHI0 on h3ulcb board
----------------------------------------------------------------
Geert Uytterhoeven (2):
arm64: dts: r8a7795: Add device node for PRR
arm64: dts: r8a7796: Add device node for PRR
Ulrich Hecht (3):
arm64: dts: r8a7796: add I2C support
arm64: dts: r8a7796: Enable I2C DMA
arm64: dts: r8a7796: salvator-x: enable I2C
Vladimir Barinov (13):
arm64: dts: h3ulcb: update documentation with official board name
arm64: dts: h3ulcb: update header
arm64: dts: m3ulcb: add M3ULCB board DT bindings
arm64: dts: m3ulcb: initial device tree
arm64: dts: m3ulcb: enable SCIF clk and pins
arm64: dts: m3ulcb: enable GPIO leds
arm64: dts: m3ulcb: enable GPIO keys
arm64: dts: m3ulcb: enable EXTALR clk
arm64: dts: m3ulcb: enable WDT
arm64: dts: m3ulcb: enable SDHI0
arm64: dts: m3ulcb: enable SDHI2
arm64: dts: h3ulcb: enable SDHI2
arm64: dts: h3ulcb: rename SDHI0 pins
Documentation/devicetree/bindings/arm/shmobile.txt | 4 +-
arch/arm64/boot/dts/renesas/Makefile | 2 +-
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 53 +++++-
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 5 +
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 189 +++++++++++++++++++++
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 12 ++
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 116 +++++++++++++
7 files changed, 374 insertions(+), 7 deletions(-)
create mode 100644 arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
^ permalink raw reply
* [BUG] i2c-designware silently fails on long transfers
From: Russell King - ARM Linux @ 2016-11-21 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121112135.GE1005@e106497-lin.cambridge.arm.com>
On Mon, Nov 21, 2016 at 11:21:35AM +0000, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 10:43:29AM +0000, Russell King - ARM Linux wrote:
> > It would need to DMA to the Tx FIFO to keep it filled - it triggers the
> > stop condition when the Tx FIFO empties. From what I can see in the
> > driver, the Tx FIFO not only takes the data but also a "command" to tell
> > the hardware what to do.
> >
> > The Rx FIFO would also need DMA to avoid it overflowing due to high
> > interrupt latency.
> >
> > I don't know what state DMA is in on the Juno, or even whether it has
> > DMA - it has a PL330 DMA controller, but I see nothing in the DT files
> > making use of it.
>
> The only thing we have tested PL330 with was UART and I2S. I'm not sure we
> can really use it with I2C given the above hardware configuration issue.
>
> The other thing we have tried in our private branches was to repeat the EDID
> transfer a number of times until the checksum was correct. Andrew Jackson
> sent a patch a year or so back to have some ridiculously high number of
> retries (30) and that has been rightfully shut down in the upstream.
>
> The unfortunate thing is that the monitors and TVs that we use inside ARM
> for testing don't seem to trigger this issue on a regular basis. We had one
> or two small 7" TVs that did that, and the brute force retry of EDID transfer
> sorted them out for the limited use that we had for them.
Due to the way the TDA998x works, it doesn't have much to do with the TV.
The TDA998x is instructed to read up to 128 bytes of EDID data into its
own internal buffer. It then does so, and raises an interrupt (or we
notice that the interrupt flag is set when there's no hardware interrupt
line), and we then read the EDID data out of the TDA998x.
At the point we're reading from the TDA998x, it has loaded the data from
the DDC bus and the DDC bus is idle... we don't have direct access to
the DDC bus.
The only reason I can think that the checksum would pass is if you were
somehow ending up with data in the buffer that did cause the basic
checksum to pass, even though you had an incomplete read.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Liviu Dudau @ 2016-11-21 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121112030.GC1041@n2100.armlinux.org.uk>
On Mon, Nov 21, 2016 at 11:20:30AM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 11:06:04AM +0000, Liviu Dudau wrote:
> > On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> > > Hi,
> >
> > Hi Russell,
> >
> > >
> > > While testing HDMI with Xorg on the Juno board, I find that when Xorg
> > > starts up or shuts down, the display is shifted significantly to the
> > > right and wrapped in the active region. (No sync bars are visible.)
> > > The timings are correct, it behaves as if the start address has been
> > > shifted many pixels _into_ the framebuffer.
> > >
> > > This occurs whenever the display mode size is changed - using xrandr
> > > in Xorg shows that changing the resolution triggers the problem
> > > almost every time, but changing the refresh rate does not.
> >
> > Thanks for reporting this. To double check your issue, you are booting
> > with HDLCD using the native monitor resolution as detected via EDID
> > and then using xrandr to change the display mode. When you do that you
> > are seeing the image being shifted to the right. Is that a correct
> > description? (I'm trying to reproduce it here and want to make sure
> > I've got the details right).
>
> I first noticed it when booting with the buggy I2C EDID reading, so
> DRM wasn't seeing a valid EDID. Then when Xorg started up and shut
> down, I noticed that the framebuffer console was shifted. It's actually
> shifted to the left because framebuffer pixel 0,0 is not displayed.
I see. So the reason why I did not notice this was the EDID transfers
mostly working for me.
>
> > > Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> > > and repeated disable/enable cycles do not make the issue re-appear.
> >
> > Do you resize the display mode as well afer re-enabling HDLCD?
>
> I quite literally just did:
>
> ./devmem2 0x7ff60230 w 0; ./devmem2 0x7ff60230 w 1
Sorry, was not very clear. Under my assumption that you were resizing the
display with xrandr, I was wondering if the issue you were seeing disappeared
when using devmem2 plus the resizing.
>
> (with a devmem2 fixed for ARM64) which immediately fixed the issue.
>
> > > What I think is going on is that the FIFO or address generator for
> > > reading data from the AXI bus is not properly reset when changing the
> > > resolution, and the enable-disable-enable cycle causes the HDLCD
> > > hardware to sort itself out.
> >
> > That is likely what is happening. According to the datasheet, changing
> > the resolution should be done while the HDLCD command mode is disabled,
> > which is what writing 0 into HDLCD_REG_COMMAND does.
>
> That does not appear to be sufficient.
>
> > > It's (eg) significantly out - for example,
> > > to properly align the display, I have to program an address of
> > > 0xf4ff0200 into the hardware rather than 0xf5000000 - that's 896 pixels
> > > before the real start of the frame buffer.
> >
> > What is the resolution you are using?
>
> In the case I detailed here, 1920x1080.
>
> > > With this patch, a patch to TDA998x to avoid the i2c-designware issue,
> > > and xf86-video-armada, I have LXDE running on the Juno.
> >
> > Can you tell me more about the TDA998x and i2c-designware issue?
> > Also, I don't think you need to use xf86-video-armada, the mode-setting
> > driver built into Xorg should be working fine (that is what I've used
> > in my testing).
>
> See the i2c-designware thread on lakml. It's a spontaneous high
> interrupt latency causing the Tx FIFO not to be loaded before it
> empties, and the i2c-designware crap decides at that point to
> immediately generate an I2C stop. The I2C controller in Juno can
> only work reliably in a system which has guaranteed low interrupt
> latencies.
Sorry, my email setup had a hickup and it was slow fetching all my emails.
I've seen the thread after replying in this thread.
>
> > > Something I also noticed is this:
> > >
> > > scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> > > plane->state->crtc_y * plane->state->fb->pitches[0] +
> > > plane->state->crtc_x * bpp / 8;
> > >
> > > Surely this should be using src_[xy] (which are the position in the
> > > source - iow, memory, and not crtc_[xy] which is the position on the
> > > CRTC displayed window. To put it another way, the src_* define the
> > > region of the source material that is mapped onto a rectangular area
> > > on the display defined by crtc_*.
> >
> > Yes, that is a bug and most likely the source of the issue that you are
> > seeing if my understanding of your testing is correct.
>
> It isn't the source of this issue at all. gem->paddr is 0xf5000000, and
> the value programmed originally into the register is the same. So, from
> those two pieces of information, we can reasonably assume that crtc_y
> and crtc_x were both zero here.
Yes, they should be zero all the time, as we don't support plane positioning
with HDLCD.
>
> > > Another note is that since the CRTC can't place the plane in arbitary
> > > positions and sizes within the active area, should the atomic_check
> > > ensure that crtc_x = crtc_y = 0, and the crtc width/height are the
> > > size of the active area?
> >
> > That should be the case, indeed. I'm going prepare a patch to do that.
>
> I've already a patch along the lines of Daniel Vetter's response to this
> point which I'm just testing.
OK, let me know how it goes and please Cc me on it.
>
> > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > index 48019ae22ddb..3e97acf6e2a7 100644
> > > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > @@ -150,6 +150,8 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
> > > clk_prepare_enable(hdlcd->clk);
> > > hdlcd_crtc_mode_set_nofb(crtc);
> > > hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> > > + hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> > > + hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> >
> > I am not convinced that this is the right fix. If anything, I would put a
> > hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0); line before hdlcd_crtc_mode_set_nofs(crtc);
> > line to make sure the command mode is disabled before setting the mode, but
> > again, I need to understand your use case to make sure that this indeed fixes it.
>
> Maybe hdlcd shouldn't be implementing the ->enable callback but instead
> the ->commit callback then?
I believe we need ->enable for the initial setup (cold boot or module reloading).
Best regards,
Liviu
>
> I'll give it a try.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [PATCH v3] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Nicolas Ferre @ 2016-11-21 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479705283-3052-1-git-send-email-wenyou.yang@atmel.com>
Le 21/11/2016 ? 06:14, Wenyou Yang a ?crit :
> The sama5d36ek CMP board is the variant of sama5d3xek board.
> It is equipped with the low-power DDR2 SDRAM, PMIC ACT8865 and
> some power rail. Its main purpose is used to measure the power
> consumption.
> The difference of the sama5d36ek CMP dts from sama5d36ek dts is
> listed as below.
> 1. The USB host nodes are removed, that is, the USB host is disabled.
> 2. The gpio_keys node is added to wake up from the sleep.
> 3. The LCD isn't supported due to the pins for LCD are conflicted
> with gpio_keys.
> 4. The adc0 node support the pinctrl sleep state to fix the over
> consumption on VDDANA.
>
> As said in errata, "When the USB host ports are used in high speed
> mode (EHCI), it is not possible to suspend the ports if no device is
> attached on each port. This leads to increased power consumption even
> if the system is in a low power mode." That is why the the USB host
> is disabled.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks Wenyou.
Regards,
> ---
>
> Changes in v3:
> - Use a dual license scheme for DT files.
> - Use the proper model name and the compatible string to reflect
> the nature of this new "CMP" board.
> - Change name of wakeup property to "wakeup-source".
> - Remove unnecessary comments.
> - Remove bootargs.
>
> Changes in v2:
> - Add the pinctrl sleep state for adc0 node to fix the over
> consumption on VDDANA.
> - Improve the commit log.
>
> arch/arm/boot/dts/sama5d36ek_cmp.dts | 87 ++++++++++
> arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 201 +++++++++++++++++++++++
> arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 301 ++++++++++++++++++++++++++++++++++
> 3 files changed, 589 insertions(+)
> create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
> create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
>
> diff --git a/arch/arm/boot/dts/sama5d36ek_cmp.dts b/arch/arm/boot/dts/sama5d36ek_cmp.dts
> new file mode 100644
> index 0000000..b632143
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d36ek_cmp.dts
> @@ -0,0 +1,87 @@
> +/*
> + * sama5d36ek_cmp.dts - Device Tree file for SAMA5D36-EK CMP board
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +/dts-v1/;
> +#include "sama5d36.dtsi"
> +#include "sama5d3xmb_cmp.dtsi"
> +
> +/ {
> + model = "Atmel SAMA5D36EK-CMP";
> + compatible = "atmel,sama5d36ek-cmp", "atmel,sama5d3xmb-cmp", "atmel,sama5d3xcm-cmp", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
> +
> + ahb {
> + apb {
> + spi0: spi at f0004000 {
> + status = "okay";
> + };
> +
> + ssc0: ssc at f0008000 {
> + status = "okay";
> + };
> +
> + can0: can at f000c000 {
> + status = "okay";
> + };
> +
> + i2c0: i2c at f0014000 {
> + status = "okay";
> + };
> +
> + i2c1: i2c at f0018000 {
> + status = "okay";
> + };
> +
> + macb0: ethernet at f0028000 {
> + status = "okay";
> + };
> +
> + macb1: ethernet at f802c000 {
> + status = "okay";
> + };
> + };
> + };
> +
> + sound {
> + status = "okay";
> + };
> +};
> diff --git a/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> new file mode 100644
> index 0000000..dc7572b
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> @@ -0,0 +1,201 @@
> +/*
> + * sama5d3xcm_cmp.dtsi - Device Tree Include file for SAMA5D36 CMP CPU Module
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/ {
> + compatible = "atmel,sama5d3xcm-cmp", "atmel,sama5d3", "atmel,sama5";
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + reg = <0x20000000 0x20000000>;
> + };
> +
> + clocks {
> + slow_xtal {
> + clock-frequency = <32768>;
> + };
> +
> + main_xtal {
> + clock-frequency = <12000000>;
> + };
> + };
> +
> + ahb {
> + apb {
> + spi0: spi at f0004000 {
> + cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
> + };
> +
> + macb0: ethernet at f0028000 {
> + phy-mode = "rgmii";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet-phy at 1 {
> + reg = <0x1>;
> + interrupt-parent = <&pioB>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + txen-skew-ps = <800>;
> + txc-skew-ps = <3000>;
> + rxdv-skew-ps = <400>;
> + rxc-skew-ps = <3000>;
> + rxd0-skew-ps = <400>;
> + rxd1-skew-ps = <400>;
> + rxd2-skew-ps = <400>;
> + rxd3-skew-ps = <400>;
> + };
> +
> + ethernet-phy at 7 {
> + reg = <0x7>;
> + interrupt-parent = <&pioB>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + txen-skew-ps = <800>;
> + txc-skew-ps = <3000>;
> + rxdv-skew-ps = <400>;
> + rxc-skew-ps = <3000>;
> + rxd0-skew-ps = <400>;
> + rxd1-skew-ps = <400>;
> + rxd2-skew-ps = <400>;
> + rxd3-skew-ps = <400>;
> + };
> + };
> +
> + i2c1: i2c at f0018000 {
> + pmic: act8865 at 5b {
> + compatible = "active-semi,act8865";
> + reg = <0x5b>;
> + status = "disabled";
> +
> + regulators {
> + vcc_1v8_reg: DCDC_REG1 {
> + regulator-name = "VCC_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + vcc_1v2_reg: DCDC_REG2 {
> + regulator-name = "VCC_1V2";
> + regulator-min-microvolt = <1100000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-always-on;
> + };
> +
> + vcc_3v3_reg: DCDC_REG3 {
> + regulator-name = "VCC_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vddana_reg: LDO_REG1 {
> + regulator-name = "VDDANA";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vddfuse_reg: LDO_REG2 {
> + regulator-name = "FUSE_2V5";
> + regulator-min-microvolt = <2500000>;
> + regulator-max-microvolt = <2500000>;
> + };
> + };
> + };
> + };
> + };
> +
> + nand0: nand at 60000000 {
> + nand-bus-width = <8>;
> + nand-ecc-mode = "hw";
> + atmel,has-pmecc;
> + atmel,pmecc-cap = <4>;
> + atmel,pmecc-sector-size = <512>;
> + nand-on-flash-bbt;
> + status = "okay";
> +
> + at91bootstrap at 0 {
> + label = "at91bootstrap";
> + reg = <0x0 0x40000>;
> + };
> +
> + bootloader at 40000 {
> + label = "bootloader";
> + reg = <0x40000 0x80000>;
> + };
> +
> + bootloaderenv at c0000 {
> + label = "bootloader env";
> + reg = <0xc0000 0xc0000>;
> + };
> +
> + dtb at 180000 {
> + label = "device tree";
> + reg = <0x180000 0x80000>;
> + };
> +
> + kernel at 200000 {
> + label = "kernel";
> + reg = <0x200000 0x600000>;
> + };
> +
> + rootfs at 800000 {
> + label = "rootfs";
> + reg = <0x800000 0x0f800000>;
> + };
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + d2 {
> + label = "d2";
> + gpios = <&pioE 25 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
> new file mode 100644
> index 0000000..252e0d3
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
> @@ -0,0 +1,301 @@
> +/*
> + * sama5d3xmb_cmp.dts - Device Tree file for SAMA5D3x CMP mother board
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +#include "sama5d3xcm_cmp.dtsi"
> +
> +/ {
> + compatible = "atmel,sama5d3xmb-cmp", "atmel,sama5d3xcm-cmp", "atmel,sama5d3", "atmel,sama5";
> +
> + ahb {
> + apb {
> + mmc0: mmc at f0000000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
> + status = "okay";
> + slot at 0 {
> + reg = <0>;
> + bus-width = <4>;
> + cd-gpios = <&pioD 17 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + spi0: spi at f0004000 {
> + dmas = <0>, <0>; /* Do not use DMA for spi0 */
> +
> + m25p80 at 0 {
> + compatible = "atmel,at25df321a";
> + spi-max-frequency = <50000000>;
> + reg = <0>;
> + };
> + };
> +
> + ssc0: ssc at f0008000 {
> + atmel,clk-from-rk-pin;
> + };
> +
> + /*
> + * i2c0 conflicts with ISI:
> + * disable it to allow the use of ISI
> + * can not enable audio when i2c0 disabled
> + */
> + i2c0: i2c at f0014000 {
> + wm8904: wm8904 at 1a {
> + compatible = "wlf,wm8904";
> + reg = <0x1a>;
> + clocks = <&pck0>;
> + clock-names = "mclk";
> + };
> + };
> +
> + i2c1: i2c at f0018000 {
> + ov2640: camera at 0x30 {
> + compatible = "ovti,ov2640";
> + reg = <0x30>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pck1_as_isi_mck &pinctrl_sensor_power &pinctrl_sensor_reset>;
> + resetb-gpios = <&pioE 24 GPIO_ACTIVE_LOW>;
> + pwdn-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
> + /* use pck1 for the master clock of ov2640 */
> + clocks = <&pck1>;
> + clock-names = "xvclk";
> + assigned-clocks = <&pck1>;
> + assigned-clock-rates = <25000000>;
> +
> + port {
> + ov2640_0: endpoint {
> + remote-endpoint = <&isi_0>;
> + bus-width = <8>;
> + };
> + };
> + };
> + };
> +
> + usart1: serial at f0020000 {
> + dmas = <0>, <0>; /* Do not use DMA for usart1 */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
> + status = "okay";
> + };
> +
> + isi: isi at f0034000 {
> + port {
> + isi_0: endpoint {
> + remote-endpoint = <&ov2640_0>;
> + bus-width = <8>;
> + vsync-active = <1>;
> + hsync-active = <1>;
> + };
> + };
> + };
> +
> + mmc1: mmc at f8000000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3 &pinctrl_mmc1_cd>;
> + status = "okay";
> + slot at 0 {
> + reg = <0>;
> + bus-width = <4>;
> + cd-gpios = <&pioD 18 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + adc0: adc at f8018000 {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <
> + &pinctrl_adc0_adtrg
> + &pinctrl_adc0_ad0
> + &pinctrl_adc0_ad1
> + &pinctrl_adc0_ad2
> + &pinctrl_adc0_ad3
> + &pinctrl_adc0_ad4
> + >;
> + pinctrl-1 = <
> + &pinctrl_adc0_adtrg_sleep
> + &pinctrl_adc0_ad0_sleep
> + &pinctrl_adc0_ad1_sleep
> + &pinctrl_adc0_ad2_sleep
> + &pinctrl_adc0_ad3_sleep
> + &pinctrl_adc0_ad4_sleep
> + >;
> + status = "okay";
> + };
> +
> + macb1: ethernet at f802c000 {
> + phy-mode = "rmii";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy0: ethernet-phy at 1 {
> + /*interrupt-parent = <&pioE>;*/
> + /*interrupts = <30 IRQ_TYPE_EDGE_FALLING>;*/
> + reg = <1>;
> + };
> + };
> +
> + pinctrl at fffff200 {
> + adc0 {
> + pinctrl_adc0_adtrg_sleep: adc0_adtrg_1 {
> + atmel,pins =
> + <AT91_PIOD 19 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>;
> + };
> + pinctrl_adc0_ad0_sleep: adc0_ad0_1 {
> + atmel,pins =
> + <AT91_PIOD 20 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>;
> + };
> + pinctrl_adc0_ad1_sleep: adc0_ad1_1 {
> + atmel,pins =
> + <AT91_PIOD 21 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>;
> + };
> + pinctrl_adc0_ad2_sleep: adc0_ad2_1 {
> + atmel,pins =
> + <AT91_PIOD 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>;
> + };
> + pinctrl_adc0_ad3_sleep: adc0_ad3_1 {
> + atmel,pins =
> + <AT91_PIOD 23 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>;
> + };
> + pinctrl_adc0_ad4_sleep: adc0_ad4_1 {
> + atmel,pins =
> + <AT91_PIOD 24 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>;
> + };
> + };
> +
> + board {
> + pinctrl_gpio_keys: gpio_keys {
> + atmel,pins =
> + <AT91_PIOE 27 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
> + };
> +
> + pinctrl_mmc0_cd: mmc0_cd {
> + atmel,pins =
> + <AT91_PIOD 17 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
> + };
> +
> + pinctrl_mmc1_cd: mmc1_cd {
> + atmel,pins =
> + <AT91_PIOD 18 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
> + };
> +
> + pinctrl_pck0_as_audio_mck: pck0_as_audio_mck {
> + atmel,pins =
> + <AT91_PIOD 30 AT91_PERIPH_B AT91_PINCTRL_NONE>;
> + };
> +
> + pinctrl_pck1_as_isi_mck: pck1_as_isi_mck-0 {
> + atmel,pins =
> + <AT91_PIOD 31 AT91_PERIPH_B AT91_PINCTRL_NONE>;
> + };
> +
> + pinctrl_sensor_reset: sensor_reset-0 {
> + atmel,pins =
> + <AT91_PIOE 24 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
> + };
> +
> + pinctrl_sensor_power: sensor_power-0 {
> + atmel,pins =
> + <AT91_PIOE 29 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
> + };
> +
> + pinctrl_usba_vbus: usba_vbus {
> + atmel,pins =
> + <AT91_PIOD 29 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
> + };
> + };
> + };
> +
> + dbgu: serial at ffffee00 {
> + dmas = <0>, <0>; /* Do not use DMA for dbgu */
> + status = "okay";
> + };
> +
> + watchdog at fffffe40 {
> + status = "okay";
> + };
> + };
> +
> + usb0: gadget at 00500000 {
> + atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usba_vbus>;
> + status = "okay";
> + };
> + };
> +
> + sound {
> + compatible = "atmel,asoc-wm8904";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pck0_as_audio_mck>;
> +
> + atmel,model = "wm8904 @ SAMA5D3EK";
> + atmel,audio-routing =
> + "Headphone Jack", "HPOUTL",
> + "Headphone Jack", "HPOUTR",
> + "IN2L", "Line In Jack",
> + "IN2R", "Line In Jack",
> + "Mic", "MICBIAS",
> + "IN1L", "Mic";
> +
> + atmel,ssc-controller = <&ssc0>;
> + atmel,audio-codec = <&wm8904>;
> +
> + status = "disabled";
> + };
> +
> + /* Conflict with LCD pins */
> + gpio_keys {
> + compatible = "gpio-keys";
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_keys>;
> +
> + pb_user1 {
> + label = "pb_user1";
> + gpios = <&pioE 27 GPIO_ACTIVE_HIGH>;
> + linux,code = <0x100>;
> + wakeup-source;
> + };
> + };
> +};
>
--
Nicolas Ferre
^ permalink raw reply
* [BUG] i2c-designware silently fails on long transfers
From: Liviu Dudau @ 2016-11-21 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121104329.GB1041@n2100.armlinux.org.uk>
On Mon, Nov 21, 2016 at 10:43:29AM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 12:29:01PM +0200, Mika Westerberg wrote:
> > On Fri, Nov 18, 2016 at 07:35:42PM +0000, Russell King - ARM Linux wrote:
> > > Another mitigation would be to lower the I2C bus frequency on Juno from
> > > 400kHz to 100kHz, so that there's 4x longer IRQ latency possible.
> > > However, even that isn't going to be reliable - even going to 100kHz
> > > isn't going to allow the above case to be solved - the interrupt is
> > > delayed by around 2ms, and it takes about 1.4ms to send/receive 16 bytes
> > > at 100kHz. (9 * 16 / (100*10^3)).
> > >
> > > So, I think all hope is lost for i2c-designware on Juno to cope with
> > > reading the EDID from TDA998x reliably.
> >
> > :-(
> >
> > I wonder if we can get it work more reliably by using DMA (provided that
> > there are DMA channels available for I2C in Juno)? That would allow the
> > hardware to perform longer reads without relying on how fast the
> > interrupt handler is able to empty the Rx FIFO.
>
> It would need to DMA to the Tx FIFO to keep it filled - it triggers the
> stop condition when the Tx FIFO empties. From what I can see in the
> driver, the Tx FIFO not only takes the data but also a "command" to tell
> the hardware what to do.
>
> The Rx FIFO would also need DMA to avoid it overflowing due to high
> interrupt latency.
>
> I don't know what state DMA is in on the Juno, or even whether it has
> DMA - it has a PL330 DMA controller, but I see nothing in the DT files
> making use of it.
The only thing we have tested PL330 with was UART and I2S. I'm not sure we
can really use it with I2C given the above hardware configuration issue.
The other thing we have tried in our private branches was to repeat the EDID
transfer a number of times until the checksum was correct. Andrew Jackson
sent a patch a year or so back to have some ridiculously high number of
retries (30) and that has been rightfully shut down in the upstream.
The unfortunate thing is that the monitors and TVs that we use inside ARM
for testing don't seem to trigger this issue on a regular basis. We had one
or two small 7" TVs that did that, and the brute force retry of EDID transfer
sorted them out for the limited use that we had for them.
Best regards,
Liviu
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [RFT v2 2/5] ASoC: samsung: smdk_wm8580: Remove old platforms and drop mach-types usage
From: Sylwester Nawrocki @ 2016-11-21 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <713e7f53-16b2-a510-e99e-77e785f8a7c1@metafoo.de>
On 11/21/2016 11:34 AM, Lars-Peter Clausen wrote:
> On 11/21/2016 11:30 AM, Sylwester Nawrocki wrote:
>> > On 11/20/2016 08:24 PM, Krzysztof Kozlowski wrote:
>>> >>
>>> >> Not tested. The driver did not override .platform_name which looks
>>> >> suspicious to me. However I did not want to add changes which could have
>>> >> some visible impact on output code.
>> >
>> > The patch looks good to me. However the existing smdk64xx sound support
>> > less so. I don't have smdk6410 set up for testing yet, possibly I get
>> > around that next week.
>> > Indeed it's strange .platform_name is not also "samsung-i2s.2".
>
> I think that is a fallout from commit a08485d8fdf6f ("ASoC: Samsung: Do not
> register samsung audio dma device as pdev"). Given nobody noticed this in
> the last 4 years maybe its time to drop this machine driver as well.
Yeah, looks like since that commit things are broken. Even though nobody
seems to be interested I'm inclined to not removing this machine driver
just yet, otherwise there will not be any board in mainline I could test
s3c64xx IP block related code changes. I'll try to find time to make this
working again.
--
Thanks,
Sylwester
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Russell King - ARM Linux @ 2016-11-21 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121110604.GC1005@e106497-lin.cambridge.arm.com>
On Mon, Nov 21, 2016 at 11:06:04AM +0000, Liviu Dudau wrote:
> On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> > Hi,
>
> Hi Russell,
>
> >
> > While testing HDMI with Xorg on the Juno board, I find that when Xorg
> > starts up or shuts down, the display is shifted significantly to the
> > right and wrapped in the active region. (No sync bars are visible.)
> > The timings are correct, it behaves as if the start address has been
> > shifted many pixels _into_ the framebuffer.
> >
> > This occurs whenever the display mode size is changed - using xrandr
> > in Xorg shows that changing the resolution triggers the problem
> > almost every time, but changing the refresh rate does not.
>
> Thanks for reporting this. To double check your issue, you are booting
> with HDLCD using the native monitor resolution as detected via EDID
> and then using xrandr to change the display mode. When you do that you
> are seeing the image being shifted to the right. Is that a correct
> description? (I'm trying to reproduce it here and want to make sure
> I've got the details right).
I first noticed it when booting with the buggy I2C EDID reading, so
DRM wasn't seeing a valid EDID. Then when Xorg started up and shut
down, I noticed that the framebuffer console was shifted. It's actually
shifted to the left because framebuffer pixel 0,0 is not displayed.
> > Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> > and repeated disable/enable cycles do not make the issue re-appear.
>
> Do you resize the display mode as well afer re-enabling HDLCD?
I quite literally just did:
./devmem2 0x7ff60230 w 0; ./devmem2 0x7ff60230 w 1
(with a devmem2 fixed for ARM64) which immediately fixed the issue.
> > What I think is going on is that the FIFO or address generator for
> > reading data from the AXI bus is not properly reset when changing the
> > resolution, and the enable-disable-enable cycle causes the HDLCD
> > hardware to sort itself out.
>
> That is likely what is happening. According to the datasheet, changing
> the resolution should be done while the HDLCD command mode is disabled,
> which is what writing 0 into HDLCD_REG_COMMAND does.
That does not appear to be sufficient.
> > It's (eg) significantly out - for example,
> > to properly align the display, I have to program an address of
> > 0xf4ff0200 into the hardware rather than 0xf5000000 - that's 896 pixels
> > before the real start of the frame buffer.
>
> What is the resolution you are using?
In the case I detailed here, 1920x1080.
> > With this patch, a patch to TDA998x to avoid the i2c-designware issue,
> > and xf86-video-armada, I have LXDE running on the Juno.
>
> Can you tell me more about the TDA998x and i2c-designware issue?
> Also, I don't think you need to use xf86-video-armada, the mode-setting
> driver built into Xorg should be working fine (that is what I've used
> in my testing).
See the i2c-designware thread on lakml. It's a spontaneous high
interrupt latency causing the Tx FIFO not to be loaded before it
empties, and the i2c-designware crap decides at that point to
immediately generate an I2C stop. The I2C controller in Juno can
only work reliably in a system which has guaranteed low interrupt
latencies.
> > Something I also noticed is this:
> >
> > scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> > plane->state->crtc_y * plane->state->fb->pitches[0] +
> > plane->state->crtc_x * bpp / 8;
> >
> > Surely this should be using src_[xy] (which are the position in the
> > source - iow, memory, and not crtc_[xy] which is the position on the
> > CRTC displayed window. To put it another way, the src_* define the
> > region of the source material that is mapped onto a rectangular area
> > on the display defined by crtc_*.
>
> Yes, that is a bug and most likely the source of the issue that you are
> seeing if my understanding of your testing is correct.
It isn't the source of this issue at all. gem->paddr is 0xf5000000, and
the value programmed originally into the register is the same. So, from
those two pieces of information, we can reasonably assume that crtc_y
and crtc_x were both zero here.
> > Another note is that since the CRTC can't place the plane in arbitary
> > positions and sizes within the active area, should the atomic_check
> > ensure that crtc_x = crtc_y = 0, and the crtc width/height are the
> > size of the active area?
>
> That should be the case, indeed. I'm going prepare a patch to do that.
I've already a patch along the lines of Daniel Vetter's response to this
point which I'm just testing.
> > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > index 48019ae22ddb..3e97acf6e2a7 100644
> > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > @@ -150,6 +150,8 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
> > clk_prepare_enable(hdlcd->clk);
> > hdlcd_crtc_mode_set_nofb(crtc);
> > hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> > + hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> > + hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
>
> I am not convinced that this is the right fix. If anything, I would put a
> hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0); line before hdlcd_crtc_mode_set_nofs(crtc);
> line to make sure the command mode is disabled before setting the mode, but
> again, I need to understand your use case to make sure that this indeed fixes it.
Maybe hdlcd shouldn't be implementing the ->enable callback but instead
the ->commit callback then?
I'll give it a try.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] [media] VPU: mediatek: fix dereference of pdev before checking it is null
From: andrew-ct chen @ 2016-11-21 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116191650.11486-1-colin.king@canonical.com>
On Wed, 2016-11-16 at 19:16 +0000, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> pdev is dereferenced using platform_get_drvdata before a check to
> see if it is null, hence there could be a potential null pointer
> dereference issue. Instead, first check if pdev is null and only then
> deference pdev when initializing vpu.
>
> Found with static analysis by CoverityScan, CID 1357797
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
Reviewed-by: Andrew-CT Chen <andrew-ct.chen@mediatek.com>
> drivers/media/platform/mtk-vpu/mtk_vpu.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> index c9bf58c..41f31b2 100644
> --- a/drivers/media/platform/mtk-vpu/mtk_vpu.c
> +++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> @@ -523,9 +523,9 @@ static int load_requested_vpu(struct mtk_vpu *vpu,
>
> int vpu_load_firmware(struct platform_device *pdev)
> {
> - struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> + struct mtk_vpu *vpu;
> struct device *dev = &pdev->dev;
> - struct vpu_run *run = &vpu->run;
> + struct vpu_run *run;
> const struct firmware *vpu_fw = NULL;
> int ret;
>
> @@ -533,6 +533,8 @@ int vpu_load_firmware(struct platform_device *pdev)
> dev_err(dev, "VPU platform device is invalid\n");
> return -EINVAL;
> }
> + vpu = platform_get_drvdata(pdev);
> + run = &vpu->run;
>
> mutex_lock(&vpu->vpu_mutex);
> if (vpu->fw_loaded) {
^ 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