* [PATCH v5 1/3] ARM: dts: tegra: Remove skeleton.dtsi and fix DTC warnings for /memory
From: Krzysztof Kozlowski @ 2018-05-17 7:45 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Thierry Reding, Jonathan Hunter,
devicetree, linux-tegra, linux-kernel
Cc: Marcel Ziswiler, Stefan Agner, Lucas Stach, Krzysztof Kozlowski
Remove the usage of skeleton.dtsi and add necessary properties to /memory
node to fix the DTC warnings:
arch/arm/boot/dts/tegra20-harmony.dtb: Warning (unit_address_vs_reg):
/memory: node has a reg or ranges property, but no unit name
The DTB after the change is the same as before except adding
unit-address to /memory node.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes since v4:
1. None
---
arch/arm/boot/dts/tegra114-dalmore.dts | 3 ++-
arch/arm/boot/dts/tegra114-roth.dts | 3 ++-
arch/arm/boot/dts/tegra114-tn7.dts | 3 ++-
arch/arm/boot/dts/tegra114.dtsi | 4 ++--
arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi | 3 ++-
arch/arm/boot/dts/tegra124-apalis.dtsi | 3 ++-
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 3 ++-
arch/arm/boot/dts/tegra124-nyan.dtsi | 3 ++-
arch/arm/boot/dts/tegra124-venice2.dts | 3 ++-
arch/arm/boot/dts/tegra124.dtsi | 2 --
arch/arm/boot/dts/tegra20-colibri-512.dtsi | 3 ++-
arch/arm/boot/dts/tegra20-harmony.dts | 3 ++-
arch/arm/boot/dts/tegra20-paz00.dts | 3 ++-
arch/arm/boot/dts/tegra20-seaboard.dts | 3 ++-
arch/arm/boot/dts/tegra20-tamonten.dtsi | 3 ++-
arch/arm/boot/dts/tegra20-trimslice.dts | 3 ++-
arch/arm/boot/dts/tegra20-ventana.dts | 3 ++-
arch/arm/boot/dts/tegra20.dtsi | 7 +++++--
arch/arm/boot/dts/tegra30-apalis.dtsi | 5 +++++
arch/arm/boot/dts/tegra30-beaver.dts | 3 ++-
arch/arm/boot/dts/tegra30-cardhu.dtsi | 3 ++-
arch/arm/boot/dts/tegra30-colibri.dtsi | 3 ++-
arch/arm/boot/dts/tegra30.dtsi | 7 +++++--
23 files changed, 53 insertions(+), 26 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index eafff16765b4..5cdcedfc19cb 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -23,7 +23,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@80000000 {
+ device_type = "memory";
reg = <0x80000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra114-roth.dts b/arch/arm/boot/dts/tegra114-roth.dts
index 7ed7370ee67a..b4f329a07c60 100644
--- a/arch/arm/boot/dts/tegra114-roth.dts
+++ b/arch/arm/boot/dts/tegra114-roth.dts
@@ -28,7 +28,8 @@
};
};
- memory {
+ memory@80000000 {
+ device_type = "memory";
/* memory >= 0x79600000 is reserved for firmware usage */
reg = <0x80000000 0x79600000>;
};
diff --git a/arch/arm/boot/dts/tegra114-tn7.dts b/arch/arm/boot/dts/tegra114-tn7.dts
index 7fc4a8b31e45..12092d344ce8 100644
--- a/arch/arm/boot/dts/tegra114-tn7.dts
+++ b/arch/arm/boot/dts/tegra114-tn7.dts
@@ -28,7 +28,8 @@
};
};
- memory {
+ memory@80000000 {
+ device_type = "memory";
/* memory >= 0x37e00000 is reserved for firmware usage */
reg = <0x80000000 0x37e00000>;
};
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 0e4a13295d8a..b917784d3f97 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -5,11 +5,11 @@
#include <dt-bindings/pinctrl/pinctrl-tegra.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
-#include "skeleton.dtsi"
-
/ {
compatible = "nvidia,tegra114";
interrupt-parent = <&lic>;
+ #address-cells = <1>;
+ #size-cells = <1>;
host1x@50000000 {
compatible = "nvidia,tegra114-host1x", "simple-bus";
diff --git a/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi b/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
index bb67edb016c5..80b52c612891 100644
--- a/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
@@ -15,7 +15,8 @@
compatible = "toradex,apalis-tk1-v1.2", "toradex,apalis-tk1",
"nvidia,tegra124";
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x0 0x80000000 0x0 0x80000000>;
};
diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi b/arch/arm/boot/dts/tegra124-apalis.dtsi
index 65a2161b9b8e..3ca7601cafe9 100644
--- a/arch/arm/boot/dts/tegra124-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis.dtsi
@@ -50,7 +50,8 @@
model = "Toradex Apalis TK1";
compatible = "toradex,apalis-tk1", "nvidia,tegra124";
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x0 0x80000000 0x0 0x80000000>;
};
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 6dbcf84dafbc..8d9e6ee6c6a7 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -24,7 +24,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x0 0x80000000 0x0 0x80000000>;
};
diff --git a/arch/arm/boot/dts/tegra124-nyan.dtsi b/arch/arm/boot/dts/tegra124-nyan.dtsi
index 3609367037a6..15a2b0e3237e 100644
--- a/arch/arm/boot/dts/tegra124-nyan.dtsi
+++ b/arch/arm/boot/dts/tegra124-nyan.dtsi
@@ -13,7 +13,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x0 0x80000000 0x0 0x80000000>;
};
diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
index 89bcc178994d..241cdc4b6600 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -18,7 +18,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x0 0x80000000 0x0 0x80000000>;
};
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 174092bfac90..df1642876a4c 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -7,8 +7,6 @@
#include <dt-bindings/reset/tegra124-car.h>
#include <dt-bindings/thermal/tegra124-soctherm.h>
-#include "skeleton.dtsi"
-
/ {
compatible = "nvidia,tegra124";
interrupt-parent = <&lic>;
diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
index 5c202b3e3bb1..305efb275b48 100644
--- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
@@ -10,7 +10,8 @@
rtc1 = "/rtc@7000e000";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x00000000 0x20000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index 628a55a9318b..5009a55ae15c 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -18,7 +18,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x00000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index 30436969adc0..e794ac5442ef 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -19,7 +19,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x00000000 0x20000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index 284aae351ff2..6cb832cfa4f3 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -18,7 +18,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x00000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi b/arch/arm/boot/dts/tegra20-tamonten.dtsi
index 872046d48709..6ceb1228fed3 100644
--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
+++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
@@ -15,7 +15,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x00000000 0x20000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index d55c6b240a30..3f94be3da9e5 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -18,7 +18,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x00000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index ee3fbf941e79..c897a90289bc 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -18,7 +18,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x00000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 0a7136462a1a..290ebbeb210f 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -4,11 +4,14 @@
#include <dt-bindings/pinctrl/pinctrl-tegra.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
-#include "skeleton.dtsi"
-
/ {
compatible = "nvidia,tegra20";
interrupt-parent = <&lic>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ chosen { };
+ aliases { };
iram@40000000 {
compatible = "mmio-sram";
diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi b/arch/arm/boot/dts/tegra30-apalis.dtsi
index d1d21ec2a844..184f60c720fa 100644
--- a/arch/arm/boot/dts/tegra30-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
@@ -10,6 +10,11 @@
model = "Toradex Apalis T30";
compatible = "toradex,apalis_t30", "nvidia,tegra30";
+ memory@0 {
+ device_type = "memory";
+ reg = <0 0>;
+ };
+
pcie@3000 {
avdd-pexa-supply = <&vdd2_reg>;
vdd-pexa-supply = <&vdd2_reg>;
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index ae52a5039506..72369877d284 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -17,7 +17,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@80000000 {
+ device_type = "memory";
reg = <0x80000000 0x7ff00000>;
};
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index 92a9740c533f..24c04d4c335d 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -40,7 +40,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@80000000 {
+ device_type = "memory";
reg = <0x80000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra30-colibri.dtsi b/arch/arm/boot/dts/tegra30-colibri.dtsi
index c44d8c40c410..cc46cedf80b9 100644
--- a/arch/arm/boot/dts/tegra30-colibri.dtsi
+++ b/arch/arm/boot/dts/tegra30-colibri.dtsi
@@ -10,7 +10,8 @@
model = "Toradex Colibri T30";
compatible = "toradex,colibri_t30", "nvidia,tegra30";
- memory {
+ memory@80000000 {
+ device_type = "memory";
reg = <0x80000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index a110cf84d85f..4383f0fd789d 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -5,11 +5,14 @@
#include <dt-bindings/pinctrl/pinctrl-tegra.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
-#include "skeleton.dtsi"
-
/ {
compatible = "nvidia,tegra30";
interrupt-parent = <&lic>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ chosen { };
+ aliases { };
pcie@3000 {
compatible = "nvidia,tegra30-pcie";
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/3] ARM: dts: tegra: Fix unit_address_vs_reg and avoid_unnecessary_addr_size DTC warnings
From: Krzysztof Kozlowski @ 2018-05-17 7:45 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Thierry Reding, Jonathan Hunter,
devicetree, linux-tegra, linux-kernel
Cc: Marcel Ziswiler, Stefan Agner, Lucas Stach, Krzysztof Kozlowski
In-Reply-To: <1526543103-21668-1-git-send-email-krzk@kernel.org>
Remove unneeded address/size cells properties and unit addresses to fix
DTC warnings like:
arch/arm/boot/dts/tegra30-apalis-eval.dtb: Warning (unit_address_vs_reg):
/i2c@7000d000/stmpe811@41/stmpe_touchscreen@0: node has a unit name, but no reg property
arch/arm/boot/dts/tegra30-apalis-eval.dtb: Warning (avoid_unnecessary_addr_size):
/i2c@7000d000/stmpe811@41: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes since v4:
1. None
---
arch/arm/boot/dts/tegra30-apalis.dtsi | 4 +---
arch/arm/boot/dts/tegra30-beaver.dts | 3 ---
arch/arm/boot/dts/tegra30-colibri.dtsi | 2 --
3 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi b/arch/arm/boot/dts/tegra30-apalis.dtsi
index 184f60c720fa..5038ca7b68af 100644
--- a/arch/arm/boot/dts/tegra30-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
@@ -590,8 +590,6 @@
/* STMPE811 touch screen controller */
stmpe811@41 {
compatible = "st,stmpe811";
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0x41>;
interrupts = <TEGRA_GPIO(V, 0) IRQ_TYPE_LEVEL_LOW>;
interrupt-parent = <&gpio>;
@@ -600,7 +598,7 @@
blocks = <0x5>;
irq-trigger = <0x1>;
- stmpe_touchscreen@0 {
+ stmpe_touchscreen {
compatible = "st,stmpe-ts";
/* 3.25 MHz ADC clock speed */
st,adc-freq = <1>;
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index 72369877d284..961934f70639 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -1791,9 +1791,6 @@
vccio-supply = <&vdd_5v_in_reg>;
regulators {
- #address-cells = <1>;
- #size-cells = <0>;
-
vdd1_reg: vdd1 {
regulator-name = "vddio_ddr_1v2";
regulator-min-microvolt = <1200000>;
diff --git a/arch/arm/boot/dts/tegra30-colibri.dtsi b/arch/arm/boot/dts/tegra30-colibri.dtsi
index cc46cedf80b9..a593dc8be47f 100644
--- a/arch/arm/boot/dts/tegra30-colibri.dtsi
+++ b/arch/arm/boot/dts/tegra30-colibri.dtsi
@@ -352,8 +352,6 @@
/* STMPE811 touch screen controller */
stmpe811@41 {
compatible = "st,stmpe811";
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0x41>;
interrupts = <TEGRA_GPIO(V, 0) IRQ_TYPE_LEVEL_LOW>;
interrupt-parent = <&gpio>;
--
2.7.4
^ permalink raw reply related
* [PATCH v5 3/3] ARM: dts: tegra: Work safely with 256 MB Colibri-T20 modules
From: Krzysztof Kozlowski @ 2018-05-17 7:45 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Thierry Reding, Jonathan Hunter,
devicetree, linux-tegra, linux-kernel
Cc: Marcel Ziswiler, Stefan Agner, Lucas Stach, Krzysztof Kozlowski
In-Reply-To: <1526543103-21668-1-git-send-email-krzk@kernel.org>
Colibri-T20 can come in 256 MB RAM (with 512 MB NAND) or 512 MB RAM
(with 1024 MB NAND) flavors. Both of them will use the same DTSI
expecting the bootloader to do the fixup of /memory node. However in
case it does not happen, let's stay on safe side by limiting the memory
to 256 MB for both versions of Colibri-T20.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
RFT:
Not tested on 512 MB module as I have only the 256 MB one.
Changes since v4:
1. Drop the 512 suffix from file names (suggested by Stefan).
Changes since v3:
1. Reduce the memory in existing DTSI instead of creating a new one
(suggested by Marcel).
Changes since v2:
1. Do not add new compatible but use everywhere existing
"toradex,colibri_t20-512" (suggested by Rob).
Changes since v1:
1. Fix memory size in tegra20-colibri-256.dtsi (was working fine because
my bootloader uses mem= argument).
---
arch/arm/boot/dts/Makefile | 2 +-
.../boot/dts/{tegra20-colibri-512.dtsi => tegra20-colibri.dtsi} | 9 +++++++--
arch/arm/boot/dts/{tegra20-iris-512.dts => tegra20-iris.dts} | 4 ++--
3 files changed, 10 insertions(+), 5 deletions(-)
rename arch/arm/boot/dts/{tegra20-colibri-512.dtsi => tegra20-colibri.dtsi} (98%)
rename arch/arm/boot/dts/{tegra20-iris-512.dts => tegra20-iris.dts} (95%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ec2024ea8b1e..837f8274b3ee 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1030,7 +1030,7 @@ dtb-$(CONFIG_ARCH_TANGO) += \
tango4-vantage-1172.dtb
dtb-$(CONFIG_ARCH_TEGRA_2x_SOC) += \
tegra20-harmony.dtb \
- tegra20-iris-512.dtb \
+ tegra20-iris.dtb \
tegra20-medcom-wide.dtb \
tegra20-paz00.dtb \
tegra20-plutux.dtb \
diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi b/arch/arm/boot/dts/tegra20-colibri.dtsi
similarity index 98%
rename from arch/arm/boot/dts/tegra20-colibri-512.dtsi
rename to arch/arm/boot/dts/tegra20-colibri.dtsi
index 305efb275b48..b9387c540450 100644
--- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri.dtsi
@@ -2,7 +2,7 @@
#include "tegra20.dtsi"
/ {
- model = "Toradex Colibri T20 512MB";
+ model = "Toradex Colibri T20 256/512 MB";
compatible = "toradex,colibri_t20-512", "nvidia,tegra20";
aliases {
@@ -12,7 +12,12 @@
memory@0 {
device_type = "memory";
- reg = <0x00000000 0x20000000>;
+ /*
+ * Set memory to 256 MB to be safe as this could be used on
+ * 256 or 512 MB module. It is expected from bootloader
+ * to fix this up for 512 MB version.
+ */
+ reg = <0x00000000 0x10000000>;
};
host1x@50000000 {
diff --git a/arch/arm/boot/dts/tegra20-iris-512.dts b/arch/arm/boot/dts/tegra20-iris.dts
similarity index 95%
rename from arch/arm/boot/dts/tegra20-iris-512.dts
rename to arch/arm/boot/dts/tegra20-iris.dts
index 40126388946d..57f16c0e9917 100644
--- a/arch/arm/boot/dts/tegra20-iris-512.dts
+++ b/arch/arm/boot/dts/tegra20-iris.dts
@@ -1,10 +1,10 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
-#include "tegra20-colibri-512.dtsi"
+#include "tegra20-colibri.dtsi"
/ {
- model = "Toradex Colibri T20 512MB on Iris";
+ model = "Toradex Colibri T20 256/512 MB on Iris";
compatible = "toradex,iris", "toradex,colibri_t20-512", "nvidia,tegra20";
aliases {
--
2.7.4
^ permalink raw reply related
* RE: [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver
From: ilialin @ 2018-05-17 7:50 UTC (permalink / raw)
To: 'Viresh Kumar', 'Amit Kucheria'
Cc: 'Michael Turquette', sboyd, 'Rob Herring',
'Mark Rutland', nm, lgirdwood, broonie,
'Andy Gross', 'David Brown', catalin.marinas,
will.deacon, 'Rafael J. Wysocki', linux-clk, devicetree,
'LKML', 'Linux PM list', linux-arm-msm, linux-soc,
'lakml', 'Rajendra Nayak', nicolas.dechesne,
celster, tfinkel
In-Reply-To: <20180516141132.aqjif7d5motmmnlo@vireshk-i7>
> -----Original Message-----
> From: Viresh Kumar <viresh.kumar@linaro.org>
> Sent: Wednesday, May 16, 2018 17:12
> To: Amit Kucheria <amit.kucheria@linaro.org>
> Cc: Ilia Lin <ilialin@codeaurora.org>; Michael Turquette
> <mturquette@baylibre.com>; sboyd@kernel.org; Rob Herring
> <robh@kernel.org>; Mark Rutland <mark.rutland@arm.com>; nm@ti.com;
> lgirdwood@gmail.com; broonie@kernel.org; Andy Gross
> <andy.gross@linaro.org>; David Brown <david.brown@linaro.org>;
> catalin.marinas@arm.com; will.deacon@arm.com; Rafael J. Wysocki
> <rjw@rjwysocki.net>; linux-clk@vger.kernel.org;
> devicetree@vger.kernel.org; LKML <linux-kernel@vger.kernel.org>; Linux
> PM list <linux-pm@vger.kernel.org>; linux-arm-msm@vger.kernel.org; linux-
> soc@vger.kernel.org; lakml <linux-arm-kernel@lists.infradead.org>;
> Rajendra Nayak <rnayak@codeaurora.org>; nicolas.dechesne@linaro.org;
> celster@codeaurora.org; tfinkel@codeaurora.org
> Subject: Re: [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver
>
> On 16-05-18, 16:12, Amit Kucheria wrote:
> > > + ret = PTR_ERR_OR_ZERO(opp_temp =
> > > +
> dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> > > + if (0 > ret)
> >
> > Any particular reason to prefer this over (ret < 0) that is generally
> > used? I've seen it used to avoid the == vs. = typos, but not for other
> > comparisons.
> >
> > Suggest sticking to what is commonly used i.e. ret < 0.
> >
> > > + goto free_opp;
> > > +
> > > + cpu_dev = get_cpu_device(GOLD_LEAD);
> >
> > Error check cpu_dev here?
> >
> > > + ret = PTR_ERR_OR_ZERO(opp_temp =
> > > +
> dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> > > + if (0 > ret)
> > > + goto free_opp;
>
> The goto here is wrong
If we are here, then the first dev_pm_opp_set_supported_hw() succeeded. And
should be deallocated before exit with error.
>
> > > +
> > > +
> > > + ret =
> PTR_ERR_OR_ZERO(platform_device_register_simple("cpufreq-dt",
> > > + -1,
> > > + NULL, 0));
> > > +
> > > + if (0 == ret)
> > > + return 0;
> > > +
> > > +free_opp:
> > > + dev_pm_opp_put_supported_hw(opp_temp);
> >
> > This is not needed because dev_pm_opp_set_supported_hw will free
> > memory in case of failure. This call in only needed in case of a
> > successful get.
>
> But this is still required for the case where platform device registration
fails.
>
> --
> viresh
^ permalink raw reply
* Re: [PATCH/RFT v3 0/3] thermal: add support for r8a77995
From: Simon Horman @ 2018-05-17 7:54 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Ulrich Hecht, jacopo mondi, Yoshihiro Kaneko, Linux-Renesas,
Zhang Rui, Eduardo Valentin, Rob Herring, Linux PM list,
devicetree
In-Reply-To: <20180516190806.GA17838@bigcity.dyn.berto.se>
On Wed, May 16, 2018 at 09:08:06PM +0200, Niklas Söderlund wrote:
> Hi Ulrich,
>
> On 2018-05-16 15:07:01 +0200, Ulrich Hecht wrote:
> > On Wed, Apr 11, 2018 at 11:01 AM, jacopo mondi <jacopo@jmondi.org> wrote:
> > > Hello Kaneko-san,
> > >
> > > On Tue, Apr 03, 2018 at 09:43:02PM +0900, Yoshihiro Kaneko wrote:
> > >> This series adds thermal support for r8a77995.
> > >> R-Car D3 (r8a77995) have a thermal sensor module which is similar to Gen2.
> > >> Therefore this series adds r8a77995 support to rcar_thermal driver not
> > >> rcar_gen3_thermal driver.
> > >
> > > I tested this on D3 Draak.
> > >
> > > I generated load expecting the detected temperature to rise.
> > >
> > > It took a while, and I only see a slight increase of the temperature
> > > reported by the 'temp' attribute.
> >
> > Pointing a heat gun at the SoC, I managed to get the temperature up to
> > 80000, and it went back to 40000 when I removed it. I'd say this
> > works.
>
> I like your style! I contemplated using a hairdryer when testing some
> Gen3 thermal work but decided against it. Good too see others are not as
> weak minded as my self :-)
I think that we may need some new tags to differentiate between
weak and awesome tests.
> > Tested-By: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
> >
> > CU
> > Uli
>
> --
> Regards,
> Niklas Söderlund
>
^ permalink raw reply
* Re: [PATCH 2/3] clk: renesas: r8a7795: Add ccree clock
From: Gilad Ben-Yossef @ 2018-05-17 8:00 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Michael Turquette, Stephen Boyd, Herbert Xu, David S. Miller,
Ofir Drang, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Linux Kernel Mailing List, linux-clk
In-Reply-To: <CAMuHMdXWPwW_p=D56BhNF274m+JLe+mbD2fqQu8-we-uMW4b8Q@mail.gmail.com>
On Tue, May 15, 2018 at 5:47 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Gilad,
>
> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>> This patch adds the clock used by the CryptoCell 630p instance in the SoC.
>>
>> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>
> Thanks for your patch!
>
>> --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
>> +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
>> @@ -132,6 +132,7 @@ static struct mssr_mod_clk r8a7795_mod_clks[] __initdata = {
>> DEF_MOD("sys-dmac2", 217, R8A7795_CLK_S0D3),
>> DEF_MOD("sys-dmac1", 218, R8A7795_CLK_S0D3),
>> DEF_MOD("sys-dmac0", 219, R8A7795_CLK_S0D3),
>> + DEF_MOD("ccree", 229, R8A7795_CLK_S3D2),
>
> I don't know if "ccree" is the proper name for this clock, as there
> may be multiple
> instances.
I'd be happy to rename it to anything else. Suggestions?
> I also can't verify the parent clock.
I'm afraid I can't really help. This is based on code snippet from
Renesas. I verified it works but
I am not an expert on the clock settings :-(
>
>> DEF_MOD("cmt3", 300, R8A7795_CLK_R),
>> DEF_MOD("cmt2", 301, R8A7795_CLK_R),
>> DEF_MOD("cmt1", 302, R8A7795_CLK_R),
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Gilad Ben-Yossef @ 2018-05-17 8:01 UTC (permalink / raw)
To: Simon Horman
Cc: Geert Uytterhoeven, Magnus Damm, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Michael Turquette, Stephen Boyd, Herbert Xu, David S. Miller,
Ofir Drang, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Linux Kernel Mailing List, linux-clk
In-Reply-To: <20180516074333.i2672u435ymwffk3@verge.net.au>
On Wed, May 16, 2018 at 10:43 AM, Simon Horman <horms@verge.net.au> wrote:
> On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote:
>> Hi Gilad,
>>
>> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>> > Add bindings for CryptoCell instance in the SoC.
>> >
>> > Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>>
>> Thanks for your patch!
>>
>> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> > @@ -528,6 +528,14 @@
>> > status = "disabled";
>> > };
>> >
>> > + arm_cc630p: crypto@e6601000 {
>> > + compatible = "arm,cryptocell-630p-ree";
>> > + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
>> > + #interrupt-cells = <2>;
>>
>> I believe the #interrupt-cells property is not needed.
>>
>> > + reg = <0x0 0xe6601000 0 0x1000>;
>> > + clocks = <&cpg CPG_MOD 229>;
>> > + };
>>
>> The rest looks good, but I cannot verify the register block.
>>
>> > +
>> > i2c3: i2c@e66d0000 {
>> > #address-cells = <1>;
>> > #size-cells = <0>;
>
> Thanks, I have applied this after dropping the #interrupt-cells property.
Thanks you!
Alas, it will not work without the clk patch (the previous one in the
series) so they need to be
taken or dropped together.
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dra762: hwmod: Add MCAN support
From: Faiz Abbas @ 2018-05-17 8:13 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-kernel, linux-omap, devicetree, bcousson, robh+dt,
mark.rutland, paul, lokeshvutla, linux
In-Reply-To: <20180515172324.GS98604@atomide.com>
Hi Tony,
On Tuesday 15 May 2018 10:53 PM, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [180515 17:20]:
>> * Tony Lindgren <tony@atomide.com> [180515 17:17]:
>>> * Faiz Abbas <faiz_abbas@ti.com> [180515 06:05]:
>>>> Hi Tony,
>>>>
>>>> On Tuesday 01 May 2018 08:56 PM, Tony Lindgren wrote:
>>>>> Hi,
>>>>>
>>>>> * Faiz Abbas <faiz_abbas@ti.com> [180408 09:59]:
>>>>>> From: Lokesh Vutla <lokeshvutla@ti.com>
>>>>>>
>>>>>> Add MCAN hwmod data and register it for dra762 silicons.
>>>>>>
>>>>>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>>>>>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>>>>>> ---
>>>>>> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 32 +++++++++++++++++++++++++++++++
>>>>>> 1 file changed, 32 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>>>>> index 62352d1..a2cd7f8 100644
>>>>>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>>>>> @@ -1356,6 +1356,29 @@ static struct omap_hwmod dra7xx_mailbox13_hwmod = {
>>>>>> };
>>>>>>
>>>>>> /*
>>>>>> + * 'mcan' class
>>>>>> + *
>>>>>> + */
>>>>>> +static struct omap_hwmod_class dra76x_mcan_hwmod_class = {
>>>>>> + .name = "mcan",
>>>>>> +};
>>>>>
>>>>> Looks like you're missing the related struct omap_hwmod_class_sysconfig
>>>>> entry for this with the rev and sysconfig registers.
>>>>>
>>>>
>>>> Sorry, I missed this email earlier. The MCAN module doesn't have
>>>> sysconfig registers.
>>>
>>> If there's no sysconfig register you should have no need for adding
>>> anything to omap_hwmod_7xx_data.c. We now have the dts clkctrl
>>> clocks, you can just add that to the dts node for the device.
>>
>> However.. My guess is there is somewhere a top level interconnect
>> target module that uses DRA7XX_CM_WKUPAON_ADC_CLKCTRL. And that
>> module may have multiple child devices.
>
> And I'm guessing the top level module with sysconfig related
> registers is named "adc" :)
>
Yes. The MCAN clocks are controlled by the ADC_CLKCTRL register.
Please see TRM:
http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=spruie9&fileType=pdf
page: 1530
Thanks,
Faiz
^ permalink raw reply
* RE: [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver
From: ilialin @ 2018-05-17 8:20 UTC (permalink / raw)
To: 'Viresh Kumar', 'Amit Kucheria'
Cc: 'Michael Turquette', sboyd, 'Rob Herring',
'Mark Rutland', nm, lgirdwood, broonie,
'Andy Gross', 'David Brown', catalin.marinas,
will.deacon, 'Rafael J. Wysocki', linux-clk, devicetree,
'LKML', 'Linux PM list', linux-arm-msm, linux-soc,
'lakml', 'Rajendra Nayak', nicolas.dechesne,
celster, tfinkel
In-Reply-To: <20180516141132.aqjif7d5motmmnlo@vireshk-i7>
> -----Original Message-----
> From: ilialin@codeaurora.org <ilialin@codeaurora.org>
> Sent: Thursday, May 17, 2018 10:51
> To: 'Viresh Kumar' <viresh.kumar@linaro.org>; 'Amit Kucheria'
> <amit.kucheria@linaro.org>
> Cc: 'Michael Turquette' <mturquette@baylibre.com>; 'sboyd@kernel.org'
> <sboyd@kernel.org>; 'Rob Herring' <robh@kernel.org>; 'Mark Rutland'
> <mark.rutland@arm.com>; 'nm@ti.com' <nm@ti.com>;
> 'lgirdwood@gmail.com' <lgirdwood@gmail.com>; 'broonie@kernel.org'
> <broonie@kernel.org>; 'Andy Gross' <andy.gross@linaro.org>; 'David Brown'
> <david.brown@linaro.org>; 'catalin.marinas@arm.com'
> <catalin.marinas@arm.com>; 'will.deacon@arm.com'
> <will.deacon@arm.com>; 'Rafael J. Wysocki' <rjw@rjwysocki.net>; 'linux-
> clk@vger.kernel.org' <linux-clk@vger.kernel.org>;
> 'devicetree@vger.kernel.org' <devicetree@vger.kernel.org>; 'LKML' <linux-
> kernel@vger.kernel.org>; 'Linux PM list' <linux-pm@vger.kernel.org>;
'linux-
> arm-msm@vger.kernel.org' <linux-arm-msm@vger.kernel.org>; 'linux-
> soc@vger.kernel.org' <linux-soc@vger.kernel.org>; 'lakml' <linux-arm-
> kernel@lists.infradead.org>; 'Rajendra Nayak' <rnayak@codeaurora.org>;
> 'nicolas.dechesne@linaro.org' <nicolas.dechesne@linaro.org>;
> 'celster@codeaurora.org' <celster@codeaurora.org>;
> 'tfinkel@codeaurora.org' <tfinkel@codeaurora.org>
> Subject: RE: [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver
>
>
>
> > -----Original Message-----
> > From: Viresh Kumar <viresh.kumar@linaro.org>
> > Sent: Wednesday, May 16, 2018 17:12
> > To: Amit Kucheria <amit.kucheria@linaro.org>
> > Cc: Ilia Lin <ilialin@codeaurora.org>; Michael Turquette
> > <mturquette@baylibre.com>; sboyd@kernel.org; Rob Herring
> > <robh@kernel.org>; Mark Rutland <mark.rutland@arm.com>; nm@ti.com;
> > lgirdwood@gmail.com; broonie@kernel.org; Andy Gross
> > <andy.gross@linaro.org>; David Brown <david.brown@linaro.org>;
> > catalin.marinas@arm.com; will.deacon@arm.com; Rafael J. Wysocki
> > <rjw@rjwysocki.net>; linux-clk@vger.kernel.org;
> > devicetree@vger.kernel.org; LKML <linux-kernel@vger.kernel.org>; Linux
> > PM list <linux-pm@vger.kernel.org>; linux-arm-msm@vger.kernel.org;
> > linux- soc@vger.kernel.org; lakml
> > <linux-arm-kernel@lists.infradead.org>;
> > Rajendra Nayak <rnayak@codeaurora.org>; nicolas.dechesne@linaro.org;
> > celster@codeaurora.org; tfinkel@codeaurora.org
> > Subject: Re: [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver
> >
> > On 16-05-18, 16:12, Amit Kucheria wrote:
> > > > + ret = PTR_ERR_OR_ZERO(opp_temp =
> > > > +
> > dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> > > > + if (0 > ret)
> > >
> > > Any particular reason to prefer this over (ret < 0) that is
> > > generally used? I've seen it used to avoid the == vs. = typos, but
> > > not for other comparisons.
> > >
> > > Suggest sticking to what is commonly used i.e. ret < 0.
> > >
> > > > + goto free_opp;
> > > > +
> > > > + cpu_dev = get_cpu_device(GOLD_LEAD);
> > >
> > > Error check cpu_dev here?
> > >
> > > > + ret = PTR_ERR_OR_ZERO(opp_temp =
> > > > +
> > dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> > > > + if (0 > ret)
> > > > + goto free_opp;
> >
> > The goto here is wrong
>
> If we are here, then the first dev_pm_opp_set_supported_hw() succeeded.
> And should be deallocated before exit with error.
My bad. Got you.
>
> >
> > > > +
> > > > +
> > > > + ret =
> > PTR_ERR_OR_ZERO(platform_device_register_simple("cpufreq-dt",
> > > > + -1,
> > > > + NULL, 0));
> > > > +
> > > > + if (0 == ret)
> > > > + return 0;
> > > > +
> > > > +free_opp:
> > > > + dev_pm_opp_put_supported_hw(opp_temp);
> > >
> > > This is not needed because dev_pm_opp_set_supported_hw will free
> > > memory in case of failure. This call in only needed in case of a
> > > successful get.
> >
> > But this is still required for the case where platform device
registration fails.
> >
> > --
> > viresh
^ permalink raw reply
* Re: [PATCH 2/6] dt-bindings: media: rcar-vin: Document data-active
From: jacopo mondi @ 2018-05-17 8:25 UTC (permalink / raw)
To: Niklas Söderlund
Cc: devicetree, robh+dt, linux-renesas-soc, horms, geert,
laurent.pinchart, Jacopo Mondi, linux-arm-kernel, linux-media
In-Reply-To: <20180516215538.GC17948@bigcity.dyn.berto.se>
[-- Attachment #1.1: Type: text/plain, Size: 3473 bytes --]
Hi Niklas,
On Wed, May 16, 2018 at 11:55:38PM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your work.
>
> On 2018-05-16 18:32:28 +0200, Jacopo Mondi wrote:
> > Document 'data-active' property in R-Car VIN device tree bindings.
> > The property is optional when running with explicit synchronization
> > (eg. BT.601) but mandatory when embedded synchronization is in use (eg.
> > BT.656) as specified by the hardware manual.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> > Documentation/devicetree/bindings/media/rcar_vin.txt | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > index c53ce4e..17eac8a 100644
> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > @@ -63,6 +63,11 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
> > If both HSYNC and VSYNC polarities are not specified, embedded
> > synchronization is selected.
> >
> > + - data-active: active state of data enable signal (CLOCKENB pin).
>
> I'm not sure what you mean by active state here. video-interfaces.txt
> defines data-active as 'similar to HSYNC and VSYNC, specifies data line
> polarity' so I assume this is the polarity of the CLOCKENB pin?
Yes, I can change this if it feels confusing to you.
>
> > + 0/1 for LOW/HIGH respectively. If not specified, use HSYNC as
> > + data enable signal. When using embedded synchronization this
> > + property is mandatory.
>
> I'm confused, why is this mandatory if we have no embedded sync (that is
> hsync-active and vsync-active not defined)? I can't find any reference
> to this in the Gen2 datasheet but I'm sure I'm just missing it :-)
>
Not exactly, it becomes mandatory IF we have embedded sync.
Here it is my reasoning:
In the documentation of CHS bit of Vn_DMR2 register [1] the following
is specified:
"When using ITU-R BT.601, BT.709, BT.1358 interface, and the
VIn_CLKENB pin is unused, the CHS bit must be set to 1."
And setting the CHS bit to 1:
"HSYNC signal (VIn_HSYNC#) input from the pin is internally used
as the clock enable signal"
So, if 'data-active' property is not specified I assume CLCKENB is not
used, and set the CHS bit. What if we are using BT656 and there is no
HSYNC? Then specifying 'data-active' becomes mandatory, as otherwise we
set the CHS bit and wait for HSYNC pin transitions that won't happen.
This is probably wrong, as in the Koelsch case, there is no guarantee
that CLKENB is connected, and what I should have done is probably set
the CHS bit only when running on V4L2_MBUS_PARALLEL, and leave CHS
(and CES, if 'data-active' is not specified) untouched, as we're doing
today when running on V4L2_MBUS_BT656. Does this work better in your
opinion?
This also makes patch [6/6] (where I was adding 'data-active' to Gen-2
boards) not required.
Thanks
j
[1] 26.2.18 Video n Data Mode Register 2 (VnDMR2) Datasheet version,
R19UH0105EJ0100 Rev.1.00 Apr 30, 2018
> > +
> > - port 1 - sub-nodes describing one or more endpoints connected to
> > the VIN from local SoC CSI-2 receivers. The endpoint numbers must
> > use the following schema.
> > --
> > 2.7.4
> >
>
> --
> Regards,
> Niklas Söderlund
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] clk: imx7d: correct enet clock CCGR register offset
From: Anson Huang @ 2018-05-17 8:40 UTC (permalink / raw)
To: shawnguo, kernel, fabio.estevam, robh+dt, mark.rutland,
mturquette, sboyd, stefan, adriana.reus, rui.silva
Cc: Linux-imx, linux-arm-kernel, devicetree, linux-kernel, linux-clk
Correct enet clock CCGR register offset.
CCGR6: IMX7D_ENET_AXI_ROOT_CLK (enet1 and enet2 bus clocks)
CCGR112: IMX7D_ENET1_TIME_ROOT_CLK, IMX7D_ENET1_IPG_ROOT_CLK
CCGR113: IMX7D_ENET2_TIME_ROOT_CLK, IMX7D_ENET2_IPG_ROOT_CLK
IMX7D_ENET_PHY_REF_ROOT_DIV supplies clock for PHY,
no gate after this clock, its parent clock root has gate.
IMX7D_ENET1_REF_ROOT_DIV/IMX7D_ENET2_REF_ROOT_DIV supplies clocks
for enet IPG_CLK_RMII, no gate after the clock, its parent
clock root has gate.
IMX7D_PLL_ENET_MAIN_125M_CLK (anatop pll) supplies clock for
enet RGMII tx_clk.
Based on Andy Duan's patch from the NXP kernel tree.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/clk/imx/clk-imx7d.c | 11 ++++++-----
include/dt-bindings/clock/imx7d-clock.h | 4 +++-
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 975a20d..485ab49 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -26,6 +26,8 @@ static u32 share_count_sai1;
static u32 share_count_sai2;
static u32 share_count_sai3;
static u32 share_count_nand;
+static u32 share_count_enet1;
+static u32 share_count_enet2;
static const struct clk_div_table test_div_table[] = {
{ .val = 3, .div = 1, },
@@ -805,6 +807,10 @@ static void __init imx7d_clocks_init(struct device_node *ccm_node)
clks[IMX7D_MIPI_DSI_ROOT_CLK] = imx_clk_gate4("mipi_dsi_root_clk", "mipi_dsi_post_div", base + 0x4650, 0);
clks[IMX7D_MIPI_CSI_ROOT_CLK] = imx_clk_gate4("mipi_csi_root_clk", "mipi_csi_post_div", base + 0x4640, 0);
clks[IMX7D_MIPI_DPHY_ROOT_CLK] = imx_clk_gate4("mipi_dphy_root_clk", "mipi_dphy_post_div", base + 0x4660, 0);
+ clks[IMX7D_ENET1_IPG_ROOT_CLK] = imx_clk_gate2_shared2("enet1_ipg_root_clk", "enet_axi_post_div", base + 0x4700, 0, &share_count_enet1);
+ clks[IMX7D_ENET1_TIME_ROOT_CLK] = imx_clk_gate2_shared2("enet1_time_root_clk", "enet1_time_post_div", base + 0x4700, 0, &share_count_enet1);
+ clks[IMX7D_ENET2_IPG_ROOT_CLK] = imx_clk_gate2_shared2("enet2_ipg_root_clk", "enet_axi_post_div", base + 0x4710, 0, &share_count_enet2);
+ clks[IMX7D_ENET2_TIME_ROOT_CLK] = imx_clk_gate2_shared2("enet2_time_root_clk", "enet2_time_post_div", base + 0x4710, 0, &share_count_enet2);
clks[IMX7D_SAI1_ROOT_CLK] = imx_clk_gate2_shared2("sai1_root_clk", "sai1_post_div", base + 0x48c0, 0, &share_count_sai1);
clks[IMX7D_SAI1_IPG_CLK] = imx_clk_gate2_shared2("sai1_ipg_clk", "ipg_root_clk", base + 0x48c0, 0, &share_count_sai1);
clks[IMX7D_SAI2_ROOT_CLK] = imx_clk_gate2_shared2("sai2_root_clk", "sai2_post_div", base + 0x48d0, 0, &share_count_sai2);
@@ -812,11 +818,6 @@ static void __init imx7d_clocks_init(struct device_node *ccm_node)
clks[IMX7D_SAI3_ROOT_CLK] = imx_clk_gate2_shared2("sai3_root_clk", "sai3_post_div", base + 0x48e0, 0, &share_count_sai3);
clks[IMX7D_SAI3_IPG_CLK] = imx_clk_gate2_shared2("sai3_ipg_clk", "ipg_root_clk", base + 0x48e0, 0, &share_count_sai3);
clks[IMX7D_SPDIF_ROOT_CLK] = imx_clk_gate4("spdif_root_clk", "spdif_post_div", base + 0x44d0, 0);
- clks[IMX7D_ENET1_REF_ROOT_CLK] = imx_clk_gate4("enet1_ref_root_clk", "enet1_ref_post_div", base + 0x44e0, 0);
- clks[IMX7D_ENET1_TIME_ROOT_CLK] = imx_clk_gate4("enet1_time_root_clk", "enet1_time_post_div", base + 0x44f0, 0);
- clks[IMX7D_ENET2_REF_ROOT_CLK] = imx_clk_gate4("enet2_ref_root_clk", "enet2_ref_post_div", base + 0x4500, 0);
- clks[IMX7D_ENET2_TIME_ROOT_CLK] = imx_clk_gate4("enet2_time_root_clk", "enet2_time_post_div", base + 0x4510, 0);
- clks[IMX7D_ENET_PHY_REF_ROOT_CLK] = imx_clk_gate4("enet_phy_ref_root_clk", "enet_phy_ref_post_div", base + 0x4520, 0);
clks[IMX7D_EIM_ROOT_CLK] = imx_clk_gate4("eim_root_clk", "eim_post_div", base + 0x4160, 0);
clks[IMX7D_NAND_RAWNAND_CLK] = imx_clk_gate2_shared2("nand_rawnand_clk", "nand_root_clk", base + 0x4140, 0, &share_count_nand);
clks[IMX7D_NAND_USDHC_BUS_RAWNAND_CLK] = imx_clk_gate2_shared2("nand_usdhc_rawnand_clk", "nand_usdhc_root_clk", base + 0x4140, 0, &share_count_nand);
diff --git a/include/dt-bindings/clock/imx7d-clock.h b/include/dt-bindings/clock/imx7d-clock.h
index b2325d3e2..fef0647 100644
--- a/include/dt-bindings/clock/imx7d-clock.h
+++ b/include/dt-bindings/clock/imx7d-clock.h
@@ -455,5 +455,7 @@
#define IMX7D_SNVS_CLK 442
#define IMX7D_CAAM_CLK 443
#define IMX7D_KPP_ROOT_CLK 444
-#define IMX7D_CLK_END 445
+#define IMX7D_ENET1_IPG_ROOT_CLK 445
+#define IMX7D_ENET2_IPG_ROOT_CLK 446
+#define IMX7D_CLK_END 447
#endif /* __DT_BINDINGS_CLOCK_IMX7D_H */
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: imx7: correct enet clock settings
From: Anson Huang @ 2018-05-17 8:40 UTC (permalink / raw)
To: shawnguo, kernel, fabio.estevam, robh+dt, mark.rutland,
mturquette, sboyd, stefan, adriana.reus, rui.silva
Cc: Linux-imx, linux-arm-kernel, devicetree, linux-kernel, linux-clk
In-Reply-To: <1526546422-7431-1-git-send-email-Anson.Huang@nxp.com>
This patch corrects ENET "ipg" and "enet_out"
clock settings according to clock driver's changes.
Based on Andy Duan's patch from the NXP kernel tree.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/boot/dts/imx7d.dtsi | 4 ++--
arch/arm/boot/dts/imx7s.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index 200714e..92022ea 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -120,11 +120,11 @@
<GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX7D_ENET_AXI_ROOT_CLK>,
+ clocks = <&clks IMX7D_ENET2_IPG_ROOT_CLK>,
<&clks IMX7D_ENET_AXI_ROOT_CLK>,
<&clks IMX7D_ENET2_TIME_ROOT_CLK>,
<&clks IMX7D_PLL_ENET_MAIN_125M_CLK>,
- <&clks IMX7D_ENET_PHY_REF_ROOT_CLK>;
+ <&clks IMX7D_ENET_PHY_REF_ROOT_DIV>;
clock-names = "ipg", "ahb", "ptp",
"enet_clk_ref", "enet_out";
fsl,num-tx-queues=<3>;
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 4d42335..cf4ba53 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -1091,11 +1091,11 @@
<GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX7D_ENET_AXI_ROOT_CLK>,
+ clocks = <&clks IMX7D_ENET1_IPG_ROOT_CLK>,
<&clks IMX7D_ENET_AXI_ROOT_CLK>,
<&clks IMX7D_ENET1_TIME_ROOT_CLK>,
<&clks IMX7D_PLL_ENET_MAIN_125M_CLK>,
- <&clks IMX7D_ENET_PHY_REF_ROOT_CLK>;
+ <&clks IMX7D_ENET_PHY_REF_ROOT_DIV>;
clock-names = "ipg", "ahb", "ptp",
"enet_clk_ref", "enet_out";
fsl,num-tx-queues=<3>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/3] clk: renesas: r8a7795: Add ccree clock
From: Geert Uytterhoeven @ 2018-05-17 8:41 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Michael Turquette, Stephen Boyd, Herbert Xu, David S. Miller,
Ofir Drang, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Linux Kernel Mailing List, linux-clk
In-Reply-To: <CAOtvUMf0pnX1+MOz0KkB5LxqL5HTmLRYjVZTUrAx-eCvm26+LA@mail.gmail.com>
Hi Gilad,
On Thu, May 17, 2018 at 10:00 AM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> On Tue, May 15, 2018 at 5:47 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>>> This patch adds the clock used by the CryptoCell 630p instance in the SoC.
>>>
>>> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>>
>> Thanks for your patch!
>>
>>> --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
>>> +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
>>> @@ -132,6 +132,7 @@ static struct mssr_mod_clk r8a7795_mod_clks[] __initdata = {
>>> DEF_MOD("sys-dmac2", 217, R8A7795_CLK_S0D3),
>>> DEF_MOD("sys-dmac1", 218, R8A7795_CLK_S0D3),
>>> DEF_MOD("sys-dmac0", 219, R8A7795_CLK_S0D3),
>>> + DEF_MOD("ccree", 229, R8A7795_CLK_S3D2),
>>
>> I don't know if "ccree" is the proper name for this clock, as there
>> may be multiple
>> instances.
>
> I'd be happy to rename it to anything else. Suggestions?
I believe it should be called "sceg-pub".
>> I also can't verify the parent clock.
>
> I'm afraid I can't really help. This is based on code snippet from
> Renesas. I verified it works but
> I am not an expert on the clock settings :-(
As your driver doesn't care about the clock rate, only about
enabling/disabling the clock, the actual parent doesn't matter much.
After some deeper diving into the datasheet, I believe the correct parent is
the CR clock, which is unfortunately not yet supported by the R-Car H3 clock
driver. I'll send a patch...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/3] input: touchscreen: edt-ft5x06: make wakeup source behavior configurable
From: Daniel Mack @ 2018-05-17 8:48 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: mark.rutland, devicetree, robh+dt, kernel, linux-input,
fabio.estevam, shawnguo, linux-arm-kernel
In-Reply-To: <20180516170333.GA21971@dtor-ws>
Hi Dmitry,
On Wednesday, May 16, 2018 07:03 PM, Dmitry Torokhov wrote:
>> diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
>> index 5bf63f76ddda..955f085627fa 100644
>> --- a/drivers/input/touchscreen/edt-ft5x06.c
>> +++ b/drivers/input/touchscreen/edt-ft5x06.c
>> @@ -1007,7 +1007,8 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
>> goto err_remove_attrs;
>>
>> edt_ft5x06_ts_prepare_debugfs(tsdata, dev_driver_string(&client->dev));
>> - device_init_wakeup(&client->dev, 1);
>> + device_init_wakeup(&client->dev,
>> + device_property_read_bool(dev, "wakeup-source"));
>
> I think we should actually drop device_init_wakeup() call. I2C core
> already handles "wakeup-source" property (for OF). The static board
> files can instantiate clients with I2C_CLIENT_WAKE, so that's handled
> too, and I think ACPI has its own notion of annotating wakeup sources.
Ah, right! Thanks, will respin :)
Daniel
^ permalink raw reply
* Re: [PATCH 3/3] sh_eth: add R8A77980 support
From: Simon Horman @ 2018-05-17 8:56 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev, devicetree, David S. Miller, Rob Herring, Mark Rutland,
linux-renesas-soc
In-Reply-To: <d3fe7c8e-3356-4f3a-d550-bc813f3f72cd@cogentembedded.com>
On Wed, May 16, 2018 at 11:00:29PM +0300, Sergei Shtylyov wrote:
> Finally, add support for the DT probing of the R-Car V3H (AKA R8A77980) --
> it's the only R-Car gen3 SoC having the GEther controller -- others have
> only EtherAVB...
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 5/6] ARM: dts: rcar-gen2: Remove unused VIN properties
From: jacopo mondi @ 2018-05-17 9:01 UTC (permalink / raw)
To: Niklas Söderlund
Cc: devicetree, robh+dt, linux-renesas-soc, horms, geert,
laurent.pinchart, Jacopo Mondi, linux-arm-kernel, linux-media
In-Reply-To: <20180516221307.GF17948@bigcity.dyn.berto.se>
[-- Attachment #1.1: Type: text/plain, Size: 4603 bytes --]
Hi Niklas,
On Thu, May 17, 2018 at 12:13:07AM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your work.
>
> On 2018-05-16 18:32:31 +0200, Jacopo Mondi wrote:
> > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> > driver and only confuse users. Remove them in all Gen2 SoC that used
> > them.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> > arch/arm/boot/dts/r8a7790-lager.dts | 3 ---
> > arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
> > arch/arm/boot/dts/r8a7791-porter.dts | 1 -
> > arch/arm/boot/dts/r8a7793-gose.dts | 3 ---
> > arch/arm/boot/dts/r8a7794-alt.dts | 1 -
> > arch/arm/boot/dts/r8a7794-silk.dts | 1 -
> > 6 files changed, 12 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
> > index 063fdb6..b56b309 100644
> > --- a/arch/arm/boot/dts/r8a7790-lager.dts
> > +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> > @@ -873,10 +873,8 @@
> > port {
> > vin0ep2: endpoint {
> > remote-endpoint = <&adv7612_out>;
> > - bus-width = <24>;
>
> I can't really make up my mind if this is a good thing or not. Device
> tree describes the hardware and not what the drivers make use of. And
> the fact is that this bus is 24 bits wide. So I'm not sure we should
> remove these properties. But I would love to hear what others think
> about this.
>
Just to point out those properties are not even documented in rcar-vin
bindings (actually, none of them was).
I feel it's wrong to have them here, as someone may think that
changing their value should actually change the VIN interface behavior,
which it's not true, leading to massive confusion and quite some code
digging for no reason (and they will get mad at us at some point, probably :)
Thanks
j
> > hsync-active = <0>;
> > vsync-active = <0>;
> > - pclk-sample = <1>;
> > data-active = <1>;
> > };
> > };
> > @@ -895,7 +893,6 @@
> >
> > vin1ep0: endpoint {
> > remote-endpoint = <&adv7180>;
> > - bus-width = <8>;
> > };
> > };
> > };
> > diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
> > index f40321a..9967666 100644
> > --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> > +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> > @@ -849,10 +849,8 @@
> >
> > vin0ep2: endpoint {
> > remote-endpoint = <&adv7612_out>;
> > - bus-width = <24>;
> > hsync-active = <0>;
> > vsync-active = <0>;
> > - pclk-sample = <1>;
> > data-active = <1>;
> > };
> > };
> > @@ -870,7 +868,6 @@
> >
> > vin1ep: endpoint {
> > remote-endpoint = <&adv7180>;
> > - bus-width = <8>;
> > };
> > };
> > };
> > diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
> > index c14e6fe..055a7f1 100644
> > --- a/arch/arm/boot/dts/r8a7791-porter.dts
> > +++ b/arch/arm/boot/dts/r8a7791-porter.dts
> > @@ -391,7 +391,6 @@
> >
> > vin0ep: endpoint {
> > remote-endpoint = <&adv7180>;
> > - bus-width = <8>;
> > };
> > };
> > };
> > diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
> > index 9ed6961..9d3fba2 100644
> > --- a/arch/arm/boot/dts/r8a7793-gose.dts
> > +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> > @@ -759,10 +759,8 @@
> >
> > vin0ep2: endpoint {
> > remote-endpoint = <&adv7612_out>;
> > - bus-width = <24>;
> > hsync-active = <0>;
> > vsync-active = <0>;
> > - pclk-sample = <1>;
> > data-active = <1>;
> > };
> > };
> > @@ -781,7 +779,6 @@
> >
> > vin1ep: endpoint {
> > remote-endpoint = <&adv7180_out>;
> > - bus-width = <8>;
> > };
> > };
> > };
> > diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
> > index 26a8834..4bbb9cc 100644
> > --- a/arch/arm/boot/dts/r8a7794-alt.dts
> > +++ b/arch/arm/boot/dts/r8a7794-alt.dts
> > @@ -380,7 +380,6 @@
> >
> > vin0ep: endpoint {
> > remote-endpoint = <&adv7180>;
> > - bus-width = <8>;
> > };
> > };
> > };
> > diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
> > index 351cb3b..c0c5d31 100644
> > --- a/arch/arm/boot/dts/r8a7794-silk.dts
> > +++ b/arch/arm/boot/dts/r8a7794-silk.dts
> > @@ -480,7 +480,6 @@
> >
> > vin0ep: endpoint {
> > remote-endpoint = <&adv7180>;
> > - bus-width = <8>;
> > };
> > };
> > };
> > --
> > 2.7.4
> >
>
> --
> Regards,
> Niklas Söderlund
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: media: rcar_vin: fix style for ports and endpoints
From: Sergei Shtylyov @ 2018-05-17 9:02 UTC (permalink / raw)
To: Niklas Söderlund, Rob Herring, devicetree
Cc: linux-media, linux-renesas-soc, Geert Uytterhoeven
In-Reply-To: <20180516233212.30931-1-niklas.soderlund+renesas@ragnatech.se>
On 5/17/2018 2:32 AM, Niklas Söderlund wrote:
> The style for referring to ports and endpoint are wrong. Refer to them
> using lowercase and a unit address, port@x and endpoint@x.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
More typos, yay! :-)
> ---
> .../devicetree/bindings/media/rcar_vin.txt | 20 +++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index c2c57dcf73f4851b..a574b9c037c05a3c 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -45,23 +45,23 @@ The per-board settings Gen2 platforms:
> The per-board settings Gen3 platforms:
>
> Gen3 platforms can support both a single connected parallel input source
> -from external SoC pins (port0) and/or multiple parallel input sources
> -from local SoC CSI-2 receivers (port1) depending on SoC.
> +from external SoC pins (port@0) and/or multiple parallel input sources
> +from local SoC CSI-2 receivers (port@1) depending on SoC.
>
> - renesas,id - ID number of the VIN, VINx in the documentation.
> - ports
> - - port 0 - sub-node describing a single endpoint connected to the VIN
> + - port@0 - sub-node describing a single endpoint connected to the VIN
> from external SoC pins described in video-interfaces.txt[1].
> - Describing more then one endpoint in port 0 is invalid. Only VIN
> - instances that are connected to external pins should have port 0.
> - - port 1 - sub-nodes describing one or more endpoints connected to
> + Describing more then one endpoint in port@0 is invalid. Only VIN
s/then/than/.
> + instances that are connected to external pins should have port@0.
> + - port@1 - sub-nodes describing one or more endpoints connected to
> the VIN from local SoC CSI-2 receivers. The endpoint numbers must
> use the following schema.
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: Simon Horman @ 2018-05-17 9:03 UTC (permalink / raw)
To: jacopo mondi
Cc: Niklas Söderlund, Jacopo Mondi, laurent.pinchart, geert,
magnus.damm, robh+dt, linux-renesas-soc, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20180517071456.GT5956@w540>
On Thu, May 17, 2018 at 09:14:56AM +0200, jacopo mondi wrote:
> Hi Niklas,
>
> On Thu, May 17, 2018 at 12:23:18AM +0200, Niklas Söderlund wrote:
> > Hi Jacopo,
> >
> > Thanks for your patch.
> >
> > On 2018-05-16 15:42:09 +0200, Jacopo Mondi wrote:
> > > Describe HDMI input connector and ADV7612 HDMI decoder installed on
> > > R-Car Gen3 Draak board.
> > >
> > > The video signal routing to the HDMI decoder to the video input interface
> > > VIN4 is multiplexed with CVBS input path, and enabled/disabled through
> > > on-board switches SW-49, SW-50, SW-51 and SW-52.
> > >
> > > As the default board switches configuration connects CVBS input to VIN4,
> > > leave the HDMI decoder unconnected in DTS.
> > >
> > > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> >
> > I'm not sure we have a policy about describing hardware which can't be
> > used without flipping switches. I have no opinion on if we should do
> > that or not I leave that to others, but for the change itself.
> >
> > Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> >
>
> Thanks
>
> > I think it's good we describe it as it's part of the Draak board itself
> > and not an expansion board which we have seen a lot of :-) Maybe even
> > add a commented out line in the adv7612 port@2 which hints which VIN
> > this is connected to if the switches are flipped?
>
> The only VIN instance that's on Draak, VIN4.
>
> I can add a comment that describes the switch settings that enables
> the HDMI video capture path.
That sounds like a good plan to me.
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Simon Horman @ 2018-05-17 9:04 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Geert Uytterhoeven, Magnus Damm, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Michael Turquette, Stephen Boyd, Herbert Xu, David S. Miller,
Ofir Drang, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Linux Kernel Mailing List, linux-clk
In-Reply-To: <CAOtvUMfFjokOLCg6aHNQESJ_q4Jiok3izrPtae5wR+cND=XL6g@mail.gmail.com>
On Thu, May 17, 2018 at 11:01:57AM +0300, Gilad Ben-Yossef wrote:
> On Wed, May 16, 2018 at 10:43 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote:
> >> Hi Gilad,
> >>
> >> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> >> > Add bindings for CryptoCell instance in the SoC.
> >> >
> >> > Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
> >>
> >> Thanks for your patch!
> >>
> >> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> >> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> >> > @@ -528,6 +528,14 @@
> >> > status = "disabled";
> >> > };
> >> >
> >> > + arm_cc630p: crypto@e6601000 {
> >> > + compatible = "arm,cryptocell-630p-ree";
> >> > + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
> >> > + #interrupt-cells = <2>;
> >>
> >> I believe the #interrupt-cells property is not needed.
> >>
> >> > + reg = <0x0 0xe6601000 0 0x1000>;
> >> > + clocks = <&cpg CPG_MOD 229>;
> >> > + };
> >>
> >> The rest looks good, but I cannot verify the register block.
> >>
> >> > +
> >> > i2c3: i2c@e66d0000 {
> >> > #address-cells = <1>;
> >> > #size-cells = <0>;
> >
> > Thanks, I have applied this after dropping the #interrupt-cells property.
>
> Thanks you!
>
> Alas, it will not work without the clk patch (the previous one in the
> series) so they need to be
> taken or dropped together.
I think its fine if it does not yet work.
But not if its causes things that previously worked to stop working.
^ permalink raw reply
* [PATCH v2 0/3] input: touchscreen: edt-ft5x06: make wakeup source behavior configurable
From: Daniel Mack @ 2018-05-17 9:05 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, mark.rutland, shawnguo, kernel,
fabio.estevam
Cc: devicetree, Daniel Mack, linux-arm-kernel, linux-input
Hi,
I have a platform that features an edt-ft5x06 touch panel and that
doesn't want to wake on touch screen activity.
Here's a trivial series of patches that make the edt-ft5x06 driver only
act as wakeup source when requested through device properties or DTS.
The third patch changes the default in two DTS files that use this
driver.
I guess the first two patches should go through the input tree, while
the third can be picked by the IMX people. There are no compile-time
dependencies, so the order doesn't matter.
Thanks,
Daniel
v1 → v2:
* simply drop device_init_wakeup() as the I2C core does handles
the wakeup-source property already (1/3)
* add a delay after reset deassertion at resume time (2/3)
* no changes in the DTS patch (3/3)
Daniel Mack (3):
input: touchscreen: edt-ft5x06: don't make device a wakeup source by
default
input: touchscreen: edt-ft5x06: assert reset during suspend
ARM: dts: imx28/imx53: enable edt-ft5x06 wakeup source
.../bindings/input/touchscreen/edt-ft5x06.txt | 3 +++
arch/arm/boot/dts/imx28-tx28.dts | 1 +
arch/arm/boot/dts/imx53-tx53-x03x.dts | 1 +
drivers/input/touchscreen/edt-ft5x06.c | 27 +++++++++++++++++-----
4 files changed, 26 insertions(+), 6 deletions(-)
--
2.14.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/3] input: touchscreen: edt-ft5x06: don't make device a wakeup source by default
From: Daniel Mack @ 2018-05-17 9:05 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, mark.rutland, shawnguo, kernel,
fabio.estevam
Cc: devicetree, Daniel Mack, linux-arm-kernel, linux-input
In-Reply-To: <20180517090552.5704-1-daniel@zonque.org>
Allow configuring the device as wakeup source through device properties, as
not all platforms want to wake up on touch screen activity.
The I2C core automatically reads the "wakeup-source" DT property to
configure a device's wakeup capability, and board supports files can set
I2C_CLIENT_WAKE in the flags.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt | 3 +++
drivers/input/touchscreen/edt-ft5x06.c | 1 -
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
index 025cf8c9324a..83f792d4d88c 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
@@ -52,6 +52,8 @@ Optional properties:
- touchscreen-inverted-y : See touchscreen.txt
- touchscreen-swapped-x-y : See touchscreen.txt
+ - wakeup-source: touchscreen acts as wakeup source
+
Example:
polytouch: edt-ft5x06@38 {
compatible = "edt,edt-ft5406", "edt,edt-ft5x06";
@@ -62,4 +64,5 @@ Example:
interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
reset-gpios = <&gpio2 6 GPIO_ACTIVE_LOW>;
wake-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>;
+ wakeup-source;
};
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index 5bf63f76ddda..e18a2f215500 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1007,7 +1007,6 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
goto err_remove_attrs;
edt_ft5x06_ts_prepare_debugfs(tsdata, dev_driver_string(&client->dev));
- device_init_wakeup(&client->dev, 1);
dev_dbg(&client->dev,
"EDT FT5x06 initialized: IRQ %d, WAKE pin %d, Reset pin %d.\n",
--
2.14.3
^ permalink raw reply related
* [PATCH v2 2/3] input: touchscreen: edt-ft5x06: assert reset during suspend
From: Daniel Mack @ 2018-05-17 9:05 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, mark.rutland, shawnguo, kernel,
fabio.estevam
Cc: devicetree, Daniel Mack, linux-arm-kernel, linux-input
In-Reply-To: <20180517090552.5704-1-daniel@zonque.org>
If the device is not configured as wakeup source, it can be put in reset
during suspend to save some power.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
drivers/input/touchscreen/edt-ft5x06.c | 26 +++++++++++++++++++++-----
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index e18a2f215500..145499022e1c 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -883,6 +883,20 @@ edt_ft5x06_ts_set_regs(struct edt_ft5x06_ts_data *tsdata)
}
}
+static void edt_ft5x06_reset(struct edt_ft5x06_ts_data *tsdata, bool reset)
+{
+ if (!tsdata->reset_gpio)
+ return;
+
+ if (reset) {
+ gpiod_set_value_cansleep(tsdata->reset_gpio, 1);
+ } else {
+ usleep_range(5000, 6000);
+ gpiod_set_value_cansleep(tsdata->reset_gpio, 0);
+ msleep(300);
+ }
+}
+
static int edt_ft5x06_ts_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -934,11 +948,7 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
gpiod_set_value_cansleep(tsdata->wake_gpio, 1);
}
- if (tsdata->reset_gpio) {
- usleep_range(5000, 6000);
- gpiod_set_value_cansleep(tsdata->reset_gpio, 0);
- msleep(300);
- }
+ edt_ft5x06_reset(tsdata, false);
input = devm_input_allocate_device(&client->dev);
if (!input) {
@@ -1034,9 +1044,12 @@ static int edt_ft5x06_ts_remove(struct i2c_client *client)
static int __maybe_unused edt_ft5x06_ts_suspend(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
+ struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
if (device_may_wakeup(dev))
enable_irq_wake(client->irq);
+ else
+ edt_ft5x06_reset(tsdata, true);
return 0;
}
@@ -1044,9 +1057,12 @@ static int __maybe_unused edt_ft5x06_ts_suspend(struct device *dev)
static int __maybe_unused edt_ft5x06_ts_resume(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
+ struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
if (device_may_wakeup(dev))
disable_irq_wake(client->irq);
+ else
+ edt_ft5x06_reset(tsdata, false);
return 0;
}
--
2.14.3
^ permalink raw reply related
* [PATCH v2 3/3] ARM: dts: imx28/imx53: enable edt-ft5x06 wakeup source
From: Daniel Mack @ 2018-05-17 9:05 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, mark.rutland, shawnguo, kernel,
fabio.estevam
Cc: devicetree, Daniel Mack, linux-arm-kernel, linux-input
In-Reply-To: <20180517090552.5704-1-daniel@zonque.org>
The touchscreen driver no longer configures the device as wakeup source by
default. A "wakeup-source" property is needed.
To avoid regressions, this patch changes the DTS files for the only two
users of this driver that didn't have this property yet.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
---
arch/arm/boot/dts/imx28-tx28.dts | 1 +
arch/arm/boot/dts/imx53-tx53-x03x.dts | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts
index 0ebbc83852d0..094a39a67ec8 100644
--- a/arch/arm/boot/dts/imx28-tx28.dts
+++ b/arch/arm/boot/dts/imx28-tx28.dts
@@ -328,6 +328,7 @@
interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
reset-gpios = <&gpio2 6 GPIO_ACTIVE_LOW>;
wake-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>;
+ wakeup-source;
};
touchscreen: tsc2007@48 {
diff --git a/arch/arm/boot/dts/imx53-tx53-x03x.dts b/arch/arm/boot/dts/imx53-tx53-x03x.dts
index 0ecb43d88522..dbf0d73dc7b9 100644
--- a/arch/arm/boot/dts/imx53-tx53-x03x.dts
+++ b/arch/arm/boot/dts/imx53-tx53-x03x.dts
@@ -220,6 +220,7 @@
interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
reset-gpios = <&gpio2 22 GPIO_ACTIVE_LOW>;
wake-gpios = <&gpio2 21 GPIO_ACTIVE_HIGH>;
+ wakeup-source;
};
touchscreen: tsc2007@48 {
--
2.14.3
^ permalink raw reply related
* Re: [PATCH v6 1/4] drm/bridge: add support for sn65dsi86 bridge driver
From: spanda-sgV2jX0FEOL9JmXXK+q4OQ @ 2018-05-17 9:10 UTC (permalink / raw)
To: Andrzej Hajda
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, ryadav-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
abhinavk-sgV2jX0FEOL9JmXXK+q4OQ,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
hoegsberg-F7+t8E8rja9g9hUCZPvPmw,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
chandanu-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <e270a97a-43c9-2725-aace-f3829a916f84-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On 2018-05-16 12:56, Andrzej Hajda wrote:
> I suppose you wanted to respond on the list, so I have added back all
> recipients.
>
> On 16.05.2018 06:39, spanda@codeaurora.org wrote:
>> On 2018-05-15 19:23, Andrzej Hajda wrote:
>>> On 15.05.2018 07:52, Sandeep Panda wrote:
>>>> Add support for TI's sn65dsi86 dsi2edp bridge chip.
>>>> The chip converts DSI transmitted signal to eDP signal,
>>>> which is fed to the connected eDP panel.
>>>>
>>>> This chip can be controlled via either i2c interface or
>>>> dsi interface. Currently in driver all the control registers
>>>> are being accessed through i2c interface only.
>>>> Also as of now HPD support has not been added to bridge
>>>> chip driver.
>>>>
>>>> Changes in v1:
>>>> - Split the dt-bindings and the driver support into separate
>>>> patches
>>>> (Andrzej Hajda).
>>>> - Use of gpiod APIs to parse and configure gpios instead of
>>>> obsolete
>>>> ones
>>>> (Andrzej Hajda).
>>>> - Use macros to define the register offsets (Andrzej Hajda).
>>>>
>>>> Changes in v2:
>>>> - Separate out edp panel specific HW resource handling from bridge
>>>> driver and create a separate edp panel drivers to handle panel
>>>> specific mode information and HW resources (Sean Paul).
>>>> - Replace pr_* APIs to DRM_* APIs to log error or debug information
>>>> (Sean Paul).
>>>> - Remove some of the unnecessary structure/variable from driver
>>>> (Sean
>>>> Paul).
>>>> - Rename the function and structure prefix "sn65dsi86" to
>>>> "ti_sn_bridge"
>>>> (Sean Paul / Rob Herring).
>>>> - Remove most of the hard-coding and modified the bridge init
>>>> sequence
>>>> based on current mode (Sean Paul).
>>>> - Remove the existing function to retrieve the EDID data and
>>>> implemented this as an i2c_adapter and use drm_get_edid() (Sean
>>>> Paul).
>>>> - Remove the dummy irq handler implementation, will add back the
>>>> proper irq handling later (Sean Paul).
>>>> - Capture the required enable gpios in a single array based on dt
>>>> entry
>>>> instead of having individual descriptor for each gpio (Sean
>>>> Paul).
>>>>
>>>> Changes in v3:
>>>> - Remove usage of irq_gpio and replace it as "interrupts" property
>>>> (Rob
>>>> Herring).
>>>> - Remove the unnecessary header file inclusions (Sean Paul).
>>>> - Rearrange the header files in alphabetical order (Sean Paul).
>>>> - Use regmap interface to perform i2c transactions.
>>>> - Update Copyright/License field and address other review comments
>>>> (Jordan Crouse).
>>>>
>>>> Changes in v4:
>>>> - Update License/Copyright (Sean Paul).
>>>> - Add Kconfig and Makefile changes (Sean Paul).
>>>> - Drop i2c gpio handling from this bridge driver, since i2c sda/scl
>>>> gpios
>>>> will be handled by i2c master.
>>>> - Update required supplies names.
>>>> - Remove unnecessary goto statements (Sean Paul).
>>>> - Add mutex lock to power_ctrl API to avoid race conditions (Sean
>>>> Paul).
>>>> - Add support to parse reference clk frequency from dt(optional).
>>>> - Update the bridge chip enable/disable sequence.
>>>>
>>>> Changes in v5:
>>>> - Fixed Kbuild test service reported warnings.
>>>>
>>>> Changes in v6:
>>>> - Use PM runtime based ref-counting instead of local ref_count
>>>> mechanism
>>>> (Stephen Boyd).
>>>> - Clean up some debug logs and indentations (Sean Paul).
>>>> - Simplify dp rate calculation (Sean Paul).
>>>> - Add support to configure refclk based on input REFCLK pin or
>>>> DACP/N
>>>> pin (Stephen Boyd).
>>>>
>>>> Signed-off-by: Sandeep Panda <spanda@codeaurora.org>
>>>> ---
>>>> drivers/gpu/drm/bridge/Kconfig | 9 +
>>>> drivers/gpu/drm/bridge/Makefile | 1 +
>>>> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 766
>>>> ++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 776 insertions(+)
>>>> create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/Kconfig
>>>> b/drivers/gpu/drm/bridge/Kconfig
>>>> index 3b99d5a..8153150 100644
>>>> --- a/drivers/gpu/drm/bridge/Kconfig
>>>> +++ b/drivers/gpu/drm/bridge/Kconfig
>>>> @@ -108,6 +108,15 @@ config DRM_TI_TFP410
>>>> ---help---
>>>> Texas Instruments TFP410 DVI/HDMI Transmitter driver
>>>>
>>>> +config DRM_TI_SN65DSI86
>>>> + tristate "TI SN65DSI86 DSI to eDP bridge"
>>>> + depends on OF
>>>> + select DRM_KMS_HELPER
>>>> + select REGMAP_I2C
>>>> + select DRM_PANEL
>>>> + ---help---
>>>> + Texas Instruments SN65DSI86 DSI to eDP Bridge driver
>>>> +
>>>> source "drivers/gpu/drm/bridge/analogix/Kconfig"
>>>>
>>>> source "drivers/gpu/drm/bridge/adv7511/Kconfig"
>>>> diff --git a/drivers/gpu/drm/bridge/Makefile
>>>> b/drivers/gpu/drm/bridge/Makefile
>>>> index 373eb28..3711be8 100644
>>>> --- a/drivers/gpu/drm/bridge/Makefile
>>>> +++ b/drivers/gpu/drm/bridge/Makefile
>>>> @@ -12,4 +12,5 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>>>> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>>>> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
>>>> obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
>>>> +obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
>>>> obj-y += synopsys/
>>>> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
>>>> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
>>>> new file mode 100644
>>>> index 0000000..1d3e549
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
>>>> @@ -0,0 +1,766 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
>>>> + */
>>>> +
>>>> +#include <drm/drmP.h>
>>>> +#include <drm/drm_atomic.h>
>>>> +#include <drm/drm_atomic_helper.h>
>>>> +#include <drm/drm_crtc_helper.h>
>>>> +#include <drm/drm_mipi_dsi.h>
>>>> +#include <drm/drm_panel.h>
>>>> +#include <linux/clk.h>
>>>> +#include <linux/gpio.h>
>>>> +#include <linux/i2c.h>
>>>> +#include <linux/of_gpio.h>
>>>> +#include <linux/of_graph.h>
>>>> +#include <linux/pm_runtime.h>
>>>> +#include <linux/regmap.h>
>>>> +#include <linux/regulator/consumer.h>
>>>> +
>>>> +#define SN_BRIDGE_REVISION_ID 0x2
>>>> +
>>>> +/* Link Training specific registers */
>>>> +#define SN_DEVICE_REV_REG 0x08
>>>> +#define SN_HPD_DISABLE_REG 0x5C
>>>> +#define SN_REFCLK_FREQ_REG 0x0A
>>>> +#define SN_DSI_LANES_REG 0x10
>>>> +#define SN_DSIA_CLK_FREQ_REG 0x12
>>>> +#define SN_ENH_FRAME_REG 0x5A
>>>> +#define SN_SSC_CONFIG_REG 0x93
>>>> +#define SN_DATARATE_CONFIG_REG 0x94
>>>> +#define SN_PLL_ENABLE_REG 0x0D
>>>> +#define SN_SCRAMBLE_CONFIG_REG 0x95
>>>> +#define SN_AUX_WDATA0_REG 0x64
>>>> +#define SN_AUX_ADDR_19_16_REG 0x74
>>>> +#define SN_AUX_ADDR_15_8_REG 0x75
>>>> +#define SN_AUX_ADDR_7_0_REG 0x76
>>>> +#define SN_AUX_LENGTH_REG 0x77
>>>> +#define SN_AUX_CMD_REG 0x78
>>>> +#define SN_ML_TX_MODE_REG 0x96
>>>> +/* video config specific registers */
>>>> +#define SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG 0x20
>>>> +#define SN_CHA_ACTIVE_LINE_LENGTH_HIGH_REG 0x21
>>>> +#define SN_CHA_VERTICAL_DISPLAY_SIZE_LOW_REG 0x24
>>>> +#define SN_CHA_VERTICAL_DISPLAY_SIZE_HIGH_REG 0x25
>>>> +#define SN_CHA_HSYNC_PULSE_WIDTH_LOW_REG 0x2C
>>>> +#define SN_CHA_HSYNC_PULSE_WIDTH_HIGH_REG 0x2D
>>>> +#define SN_CHA_VSYNC_PULSE_WIDTH_LOW_REG 0x30
>>>> +#define SN_CHA_VSYNC_PULSE_WIDTH_HIGH_REG 0x31
>>>> +#define SN_CHA_HORIZONTAL_BACK_PORCH_REG 0x34
>>>> +#define SN_CHA_VERTICAL_BACK_PORCH_REG 0x36
>>>> +#define SN_CHA_HORIZONTAL_FRONT_PORCH_REG 0x38
>>>> +#define SN_CHA_VERTICAL_FRONT_PORCH_REG 0x3A
>>>> +#define SN_DATA_FORMAT_REG 0x5B
>>>> +
>>>> +#define MIN_DSI_CLK_FREQ_MHZ 40
>>>> +
>>>> +/* fudge factor required to account for 8b/10b encoding */
>>>> +#define DP_CLK_FUDGE_NUM 10
>>>> +#define DP_CLK_FUDGE_DEN 8
>>>> +
>>>> +#define DPPLL_CLK_SRC_REFCLK 0
>>>> +#define DPPLL_CLK_SRC_DSICLK 1
>>>> +
>>>> +#define SN_DSIA_REFCLK_OFFSET 1
>>>> +#define SN_DSIA_LANE_OFFSET 3
>>>> +#define SN_DP_LANE_OFFSET 4
>>>> +#define SN_DP_DATA_RATE_OFFSET 5
>>>> +#define SN_TIMING_HIGH_OFFSET 8
>>>> +
>>>> +#define SN_ENABLE_VID_STREAM_BIT BIT(3)
>>>> +#define SN_DSIA_NUM_LANES_BITS (BIT(4) | BIT(3))
>>>> +#define SN_DP_NUM_LANES_BITS (BIT(5) | BIT(4))
>>>> +#define SN_DP_DATA_RATE_BITS (BIT(7) | BIT(6) | BIT(5))
>>>> +#define SN_HPD_DISABLE_BIT BIT(0)
>>>> +
>>>> +struct ti_sn_bridge {
>>>> + struct device *dev;
>>>> + struct regmap *regmap;
>>> I have not spotted who advised you to use regmap, I think unless you
>>> share hardware between multiple drivers it is an overkill.
>>> Are there any features of this interface to use it over i2c?
>>>
>> Since we are using the i2c mechanism to update the control registers
>> of the bridge, thought that regmap gives a proper interface for
>> handling
>> all the register control operations like read/write/update_bit/mask
>> etc.
>> Also most of the bridge driver present in drm are using this
>> mechanism.
>
> Yes, I know many ppl advertises it but also many are against using it
> in
> such simple cases. Anyway I do not want to force you to remove it, do
> what you prefer.
>
>>
>>>> + struct drm_bridge bridge;
>>>> + struct drm_connector connector;
>>>> + struct device_node *host_node;
>>>> + struct mipi_dsi_device *dsi;
>>>> + struct clk *refclk;
>>>> + struct drm_panel *panel;
>>>> + struct gpio_desc *enable_gpio;
>>>> + unsigned int num_supplies;
>>>> + struct regulator_bulk_data *supplies;
>>>> + struct i2c_adapter *ddc;
>>>> + struct drm_display_mode curr_mode;
>>> I think you can drop this field, current mode is always available
>>> via:
>>>
>>> pdata->bridge.encoder.crtc->state->adjusted_mode;
>>>
>>>
>> Ok. i will remove this curr_mode.
>>
>>>> +};
>>>> +
>>>> +static const struct regmap_range ti_sn_bridge_volatile_ranges[] = {
>>>> + { .range_min = 0, .range_max = 0xff },
>>>> +};
>>>> +
>>>> +static const struct regmap_access_table ti_sn_bridge_volatile_table
>>>> =
>>>> {
>>>> + .yes_ranges = ti_sn_bridge_volatile_ranges,
>>>> + .n_yes_ranges = ARRAY_SIZE(ti_sn_bridge_volatile_ranges),
>>>> +};
>>>> +
>>>> +static const struct regmap_config ti_sn_bridge_regmap_config = {
>>>> + .reg_bits = 8,
>>>> + .val_bits = 8,
>>>> + .volatile_table = &ti_sn_bridge_volatile_table,
>>>> + .cache_type = REGCACHE_NONE,
>>>> +};
>>>> +
>>>> +#ifdef CONFIG_PM
>>> Please mark PM callbacks with __maybe_unused instead if conditional
>>> macros.
>>>
>> Ok.
>>
>>>> +static int ti_sn_bridge_resume(struct device *dev)
>>>> +{
>>>> + struct ti_sn_bridge *pdata = dev_get_drvdata(dev);
>>>> + int ret = 0;
>>>> +
>>>> + ret = regulator_bulk_enable(pdata->num_supplies, pdata->supplies);
>>>> + if (ret) {
>>>> + DRM_ERROR("failed to enable supplies %d\n", ret);
>>>> + return ret;
>>>> + }
>>>> +
>>>> + gpiod_set_value(pdata->enable_gpio, 1);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static int ti_sn_bridge_suspend(struct device *dev)
>>>> +{
>>>> + struct ti_sn_bridge *pdata = dev_get_drvdata(dev);
>>>> + int ret = 0;
>>>> +
>>>> + gpiod_set_value(pdata->enable_gpio, 0);
>>>> +
>>>> + ret = regulator_bulk_disable(pdata->num_supplies,
>>>> pdata->supplies);
>>>> + if (ret)
>>>> + DRM_ERROR("failed to disable supplies %d\n", ret);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +#endif
>>>> +
>>>> +static const struct dev_pm_ops ti_sn_bridge_pm_ops = {
>>>> + SET_RUNTIME_PM_OPS(ti_sn_bridge_suspend, ti_sn_bridge_resume,
>>>> NULL)
>>>> +};
>>>> +
>>>> +/* Connector funcs */
>>>> +static struct ti_sn_bridge *
>>>> +connector_to_ti_sn_bridge(struct drm_connector *connector)
>>>> +{
>>>> + return container_of(connector, struct ti_sn_bridge, connector);
>>>> +}
>>>> +
>>>> +static int ti_sn_bridge_connector_get_modes(struct drm_connector
>>>> *connector)
>>>> +{
>>>> + struct ti_sn_bridge *pdata = connector_to_ti_sn_bridge(connector);
>>>> + struct drm_panel *panel = pdata->panel;
>>>> + struct edid *edid;
>>>> + u32 num_modes;
>>>> +
>>>> + if (panel) {
>>>> + DRM_DEBUG_KMS("get mode from connected drm_panel\n");
>>>> + return drm_panel_get_modes(panel);
>>>> + }
>>>> +
>>>> + if (!pdata->ddc)
>>>> + return 0;
>>>> +
>>>> + pm_runtime_get_sync(pdata->dev);
>>>> + edid = drm_get_edid(connector, pdata->ddc);
>>>> + pm_runtime_put_sync(pdata->dev);
>>>> + if (!edid)
>>>> + return 0;
>>>> +
>>>> + drm_mode_connector_update_edid_property(connector, edid);
>>>> + num_modes = drm_add_edid_modes(connector, edid);
>>>> + kfree(edid);
>>>> +
>>>> + return num_modes;
>>>> +}
>>>> +
>>>> +static enum drm_mode_status
>>>> +ti_sn_bridge_connector_mode_valid(struct drm_connector *connector,
>>>> + struct drm_display_mode *mode)
>>>> +{
>>>> + /* maximum supported resolution is 4K at 60 fps */
>>>> + if (mode->clock > 594000)
>>>> + return MODE_CLOCK_HIGH;
>>>> +
>>>> + return MODE_OK;
>>>> +}
>>>> +
>>>> +static struct drm_connector_helper_funcs
>>>> ti_sn_bridge_connector_helper_funcs = {
>>>> + .get_modes = ti_sn_bridge_connector_get_modes,
>>>> + .mode_valid = ti_sn_bridge_connector_mode_valid,
>>>> +};
>>>> +
>>>> +static enum drm_connector_status
>>>> +ti_sn_bridge_connector_detect(struct drm_connector *connector, bool
>>>> force)
>>>> +{
>>>> + struct ti_sn_bridge *pdata = connector_to_ti_sn_bridge(connector);
>>>> +
>>>> + /**
>>>> + * TODO: Currently if drm_panel is present, then always
>>>> + * return the status as connected. Need to add support to detect
>>>> + * device state for no panel(hot pluggable) scenarios.
>>>> + */
>>>> + if (pdata->panel)
>>>> + return connector_status_connected;
>>>> + else
>>>> + return connector_status_unknown;
>>>> +}
>>>> +
>>>> +static const struct drm_connector_funcs
>>>> ti_sn_bridge_connector_funcs
>>>> = {
>>>> + .fill_modes = drm_helper_probe_single_connector_modes,
>>>> + .detect = ti_sn_bridge_connector_detect,
>>>> + .destroy = drm_connector_cleanup,
>>>> + .reset = drm_atomic_helper_connector_reset,
>>>> + .atomic_duplicate_state =
>>>> drm_atomic_helper_connector_duplicate_state,
>>>> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>>>> +};
>>>> +
>>>> +static struct ti_sn_bridge *bridge_to_ti_sn_bridge(struct
>>>> drm_bridge
>>>> *bridge)
>>>> +{
>>>> + return container_of(bridge, struct ti_sn_bridge, bridge);
>>>> +}
>>>> +
>>>> +static int ti_sn_bridge_read_device_rev(struct ti_sn_bridge *pdata)
>>>> +{
>>>> + unsigned int rev = 0;
>>>> + int ret = 0;
>>>> +
>>>> + ret = regmap_read(pdata->regmap, SN_DEVICE_REV_REG, &rev);
>>>> + if (ret) {
>>>> + DRM_ERROR("Revision read failed %d\n", ret);
>>>> + return ret;
>>>> + }
>>>> +
>>>> + if (rev != SN_BRIDGE_REVISION_ID) {
>>>> + DRM_ERROR("ti_sn_bridge revision id: 0x%x mismatch\n", rev);
>>>> + ret = -EINVAL;
>>>> + }
>>> Are you sure it won't work with other revisions?
>>>
>> The datasheet which i have, mentions the revision to be 0x2. I am not
>> sure whether this driver works with other revisions, that's why i have
>> put this check.
>> Also this check helps to confirm if the gpio and supplies of the
>> bridge
>> chip has been successfully enabled not depending on the value read.
>
> So maybe better convert DRM_ERROR to warning and continue.
>
Ok. I will remove the failure return in case of id mismatch and just
print a warning.
>>
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static const char * const ti_sn_bridge_supply_names[] = {
>>>> + "vcca",
>>>> + "vcc",
>>>> + "vccio",
>>>> + "vpll",
>>>> +};
>>>> +
>>>> +static int ti_sn_bridge_parse_regulators(struct ti_sn_bridge
>>>> *pdata)
>>>> +{
>>>> + unsigned int i;
>>>> +
>>>> + pdata->num_supplies = ARRAY_SIZE(ti_sn_bridge_supply_names);
>>>> +
>>>> + pdata->supplies = devm_kcalloc(pdata->dev, pdata->num_supplies,
>>>> + sizeof(*pdata->supplies), GFP_KERNEL);
>>> It seems there is constant number of supplies. You can convert
>>> supplies
>>> to array and avoid dynamic allocation.
>>>
>> Just want to understand here what is the issue with dynamic allocation
>> here?
>> We are using device managed allocation, so the resource management
>> will
>> be properly
>> done by kernel.
>
> Just less code, no extra allocations, no extra resource management.
> Dynamic allocations in such case makes sense only if array size is
> computed in runtime.
>
Ok.
>>
>>>> + if (!pdata->supplies)
>>>> + return -ENOMEM;
>>>> +
>>>> + for (i = 0; i < pdata->num_supplies; i++)
>>>> + pdata->supplies[i].supply = ti_sn_bridge_supply_names[i];
>>>> +
>>>> + return devm_regulator_bulk_get(pdata->dev,
>>>> + pdata->num_supplies, pdata->supplies);
>>>> +}
>>>> +
>>>> +static int ti_sn_bridge_attach_panel(struct ti_sn_bridge *pdata)
>>>> +{
>>>> + struct device_node *panel_node, *port, *endpoint;
>>>> +
>>>> + pdata->panel = NULL;
>>>> + port = of_graph_get_port_by_id(pdata->dev->of_node, 1);
>>>> + if (!port)
>>>> + return 0;
>>>> +
>>>> + endpoint = of_get_child_by_name(port, "endpoint");
>>>> + of_node_put(port);
>>>> + if (!endpoint) {
>>>> + DRM_ERROR("no output endpoint found\n");
>>>> + return -EINVAL;
>>>> + }
>>> Why not of_graph_get_endpoint_by_regs ?
>>>
>>>> +
>>>> + panel_node = of_graph_get_remote_port_parent(endpoint);
>>>> + of_node_put(endpoint);
>>>> + if (!panel_node) {
>>>> + DRM_ERROR("no output node found\n");
>>>> + return -EINVAL;
>>>> + }
>>> Or even of_graph_get_remote_node?
>>>
>>>> +
>>>> + pdata->panel = of_drm_find_panel(panel_node);
>>>> + of_node_put(panel_node);
>>> Or even, even drm_of_find_panel_or_bridge ? :)
>> Ok. i will use drm_of_find_panel_or_bridge() here.
>>
>>>> + if (!pdata->panel) {
>>>> + DRM_ERROR("no panel node found\n");
>>>> + return -EINVAL;
>>> You should probably return -EPROBE_DEFER here.
>>>
>> This API may not be called from probe(), is it ok if we return
>> -EPROBE_DEFER here?
>
> Ahh, OK, but in such case this is incorrect, see below.
>
>>
>>>> + }
>>>> + drm_panel_attach(pdata->panel, &pdata->connector);
>>>> + DRM_DEBUG_KMS("drm panel attached to ti_sn_bridge\n");
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int ti_sn_bridge_attach(struct drm_bridge *bridge)
>>>> +{
>>>> + struct mipi_dsi_host *host;
>>>> + struct mipi_dsi_device *dsi;
>>>> + struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
>>>> + int ret;
>>>> + const struct mipi_dsi_device_info info = { .type = "ti_sn_bridge",
>>>> + .channel = 0,
>>>> + .node = NULL,
>>>> + };
>>>> +
>>>> + if (!bridge->encoder) {
>>>> + DRM_ERROR("Parent encoder object not found\n");
>>>> + return -ENODEV;
>>>> + }
>>>> +
>>>> + /* HPD not supported */
>>>> + pdata->connector.polled = 0;
>>> You can skip this line.
>>>
>> OK.
>>
>>>> +
>>>> + ret = drm_connector_init(bridge->dev, &pdata->connector,
>>>> + &ti_sn_bridge_connector_funcs,
>>>> + DRM_MODE_CONNECTOR_eDP);
>>>> + if (ret) {
>>>> + DRM_ERROR("Failed to initialize connector with drm\n");
>>>> + return ret;
>>>> + }
>>>> +
>>>> + drm_connector_helper_add(&pdata->connector,
>>>> + &ti_sn_bridge_connector_helper_funcs);
>>>> + drm_mode_connector_attach_encoder(&pdata->connector,
>>>> bridge->encoder);
>>>> +
>>>> + host = of_find_mipi_dsi_host_by_node(pdata->host_node);
>>>> + if (!host) {
>>>> + DRM_ERROR("failed to find dsi host\n");
>>>> + return -ENODEV;
>>> Again -EPROBE_DEFER.
>>>
>> This API may not be called from probe(), is it ok if we return
>> -EPROBE_DEFER here?
>
> ditto
>
>>
>>>> + }
>>>> +
>>>> + dsi = mipi_dsi_device_register_full(host, &info);
>>>> + if (IS_ERR(dsi)) {
>>>> + DRM_ERROR("failed to create dsi device\n");
>>>> + ret = PTR_ERR(dsi);
>>>> + return ret;
>>>> + }
>>>> +
>>>> + /* TODO: setting to 4 lanes always for now */
>>>> + dsi->lanes = 4;
>>>> + dsi->format = MIPI_DSI_FMT_RGB888;
>>>> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
>>>> MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
>>>> + MIPI_DSI_MODE_EOT_PACKET | MIPI_DSI_MODE_VIDEO_HSE;
>>>> +
>>>> + ret = mipi_dsi_attach(dsi);
>>>> + if (ret < 0) {
>>>> + DRM_ERROR("failed to attach dsi to host\n");
>>>> + mipi_dsi_device_unregister(dsi);
>>>> + return ret;
>>>> + }
>>>> +
>>>> + pdata->dsi = dsi;
>>>> +
>>>> + DRM_DEBUG_KMS("ti_sn_bridge attached to dsi\n");
>>>> + /* attach panel to bridge */
>>>> + ti_sn_bridge_attach_panel(pdata);
>>>
>>> Function can fail, you should handle it.
>>>
>> This is not fatal, if this function fails then we assume there is no
>> edp
>> panel attached to this bridge.
>
> So it seems wrong to me. You do not have guarantee that panel driver is
> bound at this moment. So in case of different driver binding order you
> will end up with incorrect setup: bridge will work with assumption
> there
> is no panel behind it, but the panel is there, it will be just probed
> later.
>
> I think the proper solution here is to do not advertise bridge (ie call
> drm_bridge_add), until all required resources are present, including
> DSI
> host and panel. And to make it clear, if the panel is defined in
> bindings it means it is required.
>
>
Ok. So i will move this attach code to ti_sn_bridge_probe() and if i
dont get the panel there i will return -EPROBE_DEFER.
Currently HPD is not supported in the driver, so we will rely on the
panel to successfully finish bridge driver's probe.
>>
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static void ti_sn_bridge_mode_set(struct drm_bridge *bridge,
>>>> + struct drm_display_mode *mode,
>>>> + struct drm_display_mode *adj_mode)
>>>> +{
>>>> + struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
>>>> +
>>>> + DRM_DEBUG("mode_set: hdisplay=%d, vdisplay=%d, vrefresh=%d,
>>>> clock=%d\n",
>>>> + adj_mode->hdisplay, adj_mode->vdisplay,
>>>> + adj_mode->vrefresh, adj_mode->clock);
>>>> +
>>>> + drm_mode_copy(&pdata->curr_mode, adj_mode);
>>>> +}
>>> This callback can be dropped, see comment for curr_mode.
>>>
>>>> +
>>>> +static void ti_sn_bridge_disable(struct drm_bridge *bridge)
>>>> +{
>>>> + struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
>>>> + struct drm_panel *panel = pdata->panel;
>>>> +
>>>> + if (panel) {
>>>> + drm_panel_disable(panel);
>>>> + drm_panel_unprepare(panel);
>>>> + }
>>>> +
>>>> + /* disable video stream */
>>>> + regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG,
>>>> + SN_ENABLE_VID_STREAM_BIT, 0);
>>>> + /* semi auto link training mode OFF */
>>>> + regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0);
>>>> + /* disable DP PLL */
>>>> + regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 0);
>>>> +}
>>>> +
>>>> +static u32 ti_sn_bridge_get_dsi_freq(struct ti_sn_bridge *pdata)
>>>> +{
>>>> + u32 bit_rate_khz, clk_freq_khz;
>>>> + struct drm_display_mode *mode = &pdata->curr_mode;
>>>> +
>>>> + bit_rate_khz = mode->clock *
>>>> + mipi_dsi_pixel_format_to_bpp(pdata->dsi->format);
>>>> + clk_freq_khz = bit_rate_khz / (pdata->dsi->lanes * 2);
>>>> +
>>>> + return clk_freq_khz;
>>>> +}
>>>> +
>>>> +#define REFCLK_LUT_SIZE 5
>>>> +
>>>> +/* clk frequencies supported by bridge in Hz in case derived from
>>>> REFCLK pin */
>>>> +static const u32 ti_sn_bridge_refclk_lut[] = {
>>>> + 12000000,
>>>> + 19200000,
>>>> + 26000000,
>>>> + 27000000,
>>>> + 38400000,
>>>> +};
>>>> +
>>>> +/* clk frequencies supported by bridge in Hz in case derived from
>>>> DACP/N pin */
>>>> +static const u32 ti_sn_bridge_dsiclk_lut[] = {
>>>> + 468000000,
>>>> + 384000000,
>>>> + 416000000,
>>>> + 486000000,
>>>> + 460800000,
>>>> +};
>>>> +
>>>> +static void ti_sn_bridge_set_refclk(struct ti_sn_bridge *pdata)
>>>> +{
>>>> + int i = 0;
>>>> + u8 refclk_src;
>>>> + u32 refclk_rate;
>>>> + const u32 *refclk_lut;
>>>> +
>>>> + if (pdata->refclk) {
>>>> + refclk_src = DPPLL_CLK_SRC_REFCLK;
>>>> + refclk_rate = clk_get_rate(pdata->refclk);
>>>> + refclk_lut = ti_sn_bridge_refclk_lut;
>>>> + clk_prepare_enable(pdata->refclk);
>>>> + } else {
>>>> + refclk_src = DPPLL_CLK_SRC_DSICLK;
>>>> + refclk_rate = ti_sn_bridge_get_dsi_freq(pdata) * 1000;
>>>> + refclk_lut = ti_sn_bridge_dsiclk_lut;
>>>> + }
>>>> +
>>>> + /* for i equals to REFCLK_LUT_SIZE means default frequency */
>>>> + for (i = 0; i < REFCLK_LUT_SIZE; i++)
>>>> + if (refclk_lut[i] == refclk_rate)
>>>> + break;
>>>> +
>>>> + regmap_write(pdata->regmap, SN_REFCLK_FREQ_REG,
>>>> + (refclk_src | (i << SN_DSIA_REFCLK_OFFSET)));
>>>> +}
>>>> +
>>>> +/**
>>>> + * LUT index corresponds to register value and
>>>> + * LUT values corresponds to dp data rate supported
>>>> + * by the bridge in Mbps unit.
>>>> + */
>>>> +static const unsigned int ti_sn_bridge_dp_rate_lut[] = {
>>>> + 0, 1620, 2160, 2430, 2700, 3240, 4320, 5400
>>>> +};
>>>> +
>>>> +static void ti_sn_bridge_set_dsi_dp_rate(struct ti_sn_bridge
>>>> *pdata)
>>>> +{
>>>> + unsigned int bit_rate_mhz, clk_freq_mhz, dp_rate_mhz;
>>>> + unsigned int val = 0, i = 0;
>>>> + struct drm_display_mode *mode = &pdata->curr_mode;
>>>> +
>>>> + /* set DSIA clk frequency */
>>>> + bit_rate_mhz = (mode->clock / 1000) *
>>>> + mipi_dsi_pixel_format_to_bpp(pdata->dsi->format);
>>>> + clk_freq_mhz = bit_rate_mhz / (pdata->dsi->lanes * 2);
>>>> +
>>>> + /* for each increment in val, frequency increases by 5MHz */
>>>> + val = (MIN_DSI_CLK_FREQ_MHZ / 5) +
>>>> + (((clk_freq_mhz - MIN_DSI_CLK_FREQ_MHZ) / 5) & 0xFF);
>>>> + regmap_write(pdata->regmap, SN_DSIA_CLK_FREQ_REG, val);
>>>> +
>>>> + /* set DP data rate */
>>>> + dp_rate_mhz = ((bit_rate_mhz / pdata->dsi->lanes) *
>>>> DP_CLK_FUDGE_NUM) /
>>>> + DP_CLK_FUDGE_DEN;
>>>> + for (i = 0; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut); i++)
>>>> + if (ti_sn_bridge_dp_rate_lut[i] > dp_rate_mhz)
>>>> + break;
>>>> + if (i == ARRAY_SIZE(ti_sn_bridge_dp_rate_lut))
>>>> + i--; /* set to maximum possible */
>>> Just use: for (i = 0; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1;
>>> i++)
>>>
>> Ok.
>>
>>>> +
>>>> + regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG,
>>>> + SN_DP_DATA_RATE_BITS, i << SN_DP_DATA_RATE_OFFSET);
>>>> +}
>>>> +
>>>> +static void ti_sn_bridge_set_video_timings(struct ti_sn_bridge
>>>> *pdata)
>>>> +{
>>>> + struct drm_display_mode *mode = &pdata->curr_mode;
>>>> +
>>>> + regmap_write(pdata->regmap, SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG,
>>>> + mode->hdisplay & 0xFF);
>>>> + regmap_write(pdata->regmap, SN_CHA_ACTIVE_LINE_LENGTH_HIGH_REG,
>>>> + (mode->hdisplay >> SN_TIMING_HIGH_OFFSET) & 0xFF);
>>>> + regmap_write(pdata->regmap, SN_CHA_VERTICAL_DISPLAY_SIZE_LOW_REG,
>>>> + mode->vdisplay & 0xFF);
>>>> + regmap_write(pdata->regmap, SN_CHA_VERTICAL_DISPLAY_SIZE_HIGH_REG,
>>>> + (mode->vdisplay >> SN_TIMING_HIGH_OFFSET) & 0xFF);
>>>> + regmap_write(pdata->regmap, SN_CHA_HSYNC_PULSE_WIDTH_LOW_REG,
>>>> + (mode->hsync_end - mode->hsync_start) & 0xFF);
>>>> + regmap_write(pdata->regmap, SN_CHA_HSYNC_PULSE_WIDTH_HIGH_REG,
>>>> + ((mode->hsync_end - mode->hsync_start) >>
>>>> + SN_TIMING_HIGH_OFFSET) & 0xFF);
>>>> + regmap_write(pdata->regmap, SN_CHA_VSYNC_PULSE_WIDTH_LOW_REG,
>>>> + (mode->vsync_end - mode->vsync_start) & 0xFF);
>>>> + regmap_write(pdata->regmap, SN_CHA_VSYNC_PULSE_WIDTH_HIGH_REG,
>>>> + ((mode->vsync_end - mode->vsync_start) >>
>>>> + SN_TIMING_HIGH_OFFSET) & 0xFF);
>>>> + regmap_write(pdata->regmap, SN_CHA_HORIZONTAL_BACK_PORCH_REG,
>>>> + (mode->htotal - mode->hsync_end) & 0xFF);
>>>> + regmap_write(pdata->regmap, SN_CHA_VERTICAL_BACK_PORCH_REG,
>>>> + (mode->vtotal - mode->vsync_end) & 0xFF);
>>>> + regmap_write(pdata->regmap, SN_CHA_HORIZONTAL_FRONT_PORCH_REG,
>>>> + (mode->hsync_start - mode->hdisplay) & 0xFF);
>>>> + regmap_write(pdata->regmap, SN_CHA_VERTICAL_FRONT_PORCH_REG,
>>>> + (mode->vsync_start - mode->vdisplay) & 0xFF);
>>>> + usleep_range(10000, 10500); /* 10ms delay recommended by spec */
>>>> +}
>>>> +
>>>> +static void ti_sn_bridge_enable(struct drm_bridge *bridge)
>>>> +{
>>>> + struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
>>>> + struct drm_panel *panel = pdata->panel;
>>>> + unsigned int val = 0;
>>>> +
>>>> + if (panel) {
>>>> + drm_panel_prepare(panel);
>>>> + /* in case drm_panel is connected then HPD is not supported */
>>>> + regmap_update_bits(pdata->regmap, SN_HPD_DISABLE_REG,
>>>> + SN_HPD_DISABLE_BIT, SN_HPD_DISABLE_BIT);
>>>> + }
>>>> +
>>>> + /* DSI_A lane config */
>>>> + val = (4 - pdata->dsi->lanes) << SN_DSIA_LANE_OFFSET;
>>>> + regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
>>>> + SN_DSIA_NUM_LANES_BITS, val);
>>>> +
>>>> + /* DP lane config */
>>>> + val = (pdata->dsi->lanes - 1) << SN_DP_LANE_OFFSET;
>>>> + regmap_update_bits(pdata->regmap, SN_SSC_CONFIG_REG,
>>>> + SN_DP_NUM_LANES_BITS, val);
>>>> +
>>>> + /* set dsi/dp clk frequency value */
>>>> + ti_sn_bridge_set_dsi_dp_rate(pdata);
>>>> +
>>>> + /* enable DP PLL */
>>>> + regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 1);
>>>> + usleep_range(10000, 10500); /* 10ms delay recommended by spec */
>>>> +
>>>> + /**
>>>> + * The SN65DSI86 only supports ASSR Display Authentication method
>>>> and
>>>> + * this method is enabled by default. An eDP panel must support
>>>> this
>>>> + * authentication method. We need to enable this method in the eDP
>>>> panel
>>>> + * at DisplayPort address 0x0010A prior to link training.
>>>> + */
>>>> + regmap_write(pdata->regmap, SN_AUX_WDATA0_REG, 0x01);
>>>> + regmap_write(pdata->regmap, SN_AUX_ADDR_19_16_REG, 0x00);
>>>> + regmap_write(pdata->regmap, SN_AUX_ADDR_15_8_REG, 0x01);
>>>> + regmap_write(pdata->regmap, SN_AUX_ADDR_7_0_REG, 0x0A);
>>>> + regmap_write(pdata->regmap, SN_AUX_LENGTH_REG, 0x01);
>>>> + regmap_write(pdata->regmap, SN_AUX_CMD_REG, 0x81);
>>>> + usleep_range(10000, 10500); /* 10ms delay recommended by spec */
>>>> +
>>>> + /* Semi auto link training mode */
>>>> + regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
>>>> + msleep(20); /* 20ms delay recommended by spec */
>>>> +
>>>> + /* config video parameters */
>>>> + ti_sn_bridge_set_video_timings(pdata);
>>>> +
>>>> + /* enable video stream */
>>>> + regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG,
>>>> + SN_ENABLE_VID_STREAM_BIT, SN_ENABLE_VID_STREAM_BIT);
>>>> +
>>>> + if (panel)
>>>> + drm_panel_enable(panel);
>>>> +}
>>>> +
>>>> +static void ti_sn_bridge_pre_enable(struct drm_bridge *bridge)
>>>> +{
>>>> + struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
>>>> +
>>>> + pm_runtime_get_sync(pdata->dev);
>>>> +
>>>> + /* configure bridge CLK_SRC and ref_clk */
>>>> + ti_sn_bridge_set_refclk(pdata);
>>>> +}
>>>> +
>>>> +static void ti_sn_bridge_post_disable(struct drm_bridge *bridge)
>>>> +{
>>>> + struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
>>>> +
>>>> + if (pdata->refclk)
>>>> + clk_disable_unprepare(pdata->refclk);
>>>> +
>>>> + pm_runtime_put_sync(pdata->dev);
>>>> +}
>>>> +
>>>> +static const struct drm_bridge_funcs ti_sn_bridge_funcs = {
>>>> + .attach = ti_sn_bridge_attach,
>>>> + .pre_enable = ti_sn_bridge_pre_enable,
>>>> + .enable = ti_sn_bridge_enable,
>>>> + .disable = ti_sn_bridge_disable,
>>>> + .post_disable = ti_sn_bridge_post_disable,
>>>> + .mode_set = ti_sn_bridge_mode_set,
>>>> +};
>>>> +
>>>> +static int ti_sn_bridge_parse_dsi_host(struct ti_sn_bridge *pdata)
>>>> +{
>>>> + struct device_node *np = pdata->dev->of_node;
>>>> + struct device_node *end_node;
>>>> +
>>>> + end_node = of_graph_get_endpoint_by_regs(np, 0, 0);
>>>> + if (!end_node) {
>>>> + DRM_ERROR("remote endpoint not found\n");
>>>> + return -ENODEV;
>>>> + }
>>>> +
>>>> + pdata->host_node = of_graph_get_remote_port_parent(end_node);
>>>> + of_node_put(end_node);
>>>> + if (!pdata->host_node) {
>>>> + DRM_ERROR("remote node not found\n");
>>>> + return -ENODEV;
>>>> + }
>>>> + of_node_put(pdata->host_node);
>>> Why not of_graph_get_remote_node ?
>>>
>> Just for my understanding, is of_graph_get_remote_port_parent not
>> recommended? what is the benefit of using of_graph_get_remote_node()?
>
>
> Because it encapsulates both of_graph_get_endpoint_by_regs and
> of_graph_get_remote_port_parent with correct node reference management.
>
Ok.
>>
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int ti_sn_bridge_probe(struct i2c_client *client,
>>>> + const struct i2c_device_id *id)
>>>> +{
>>>> + struct ti_sn_bridge *pdata;
>>>> + struct device_node *ddc_node;
>>>> + int ret = 0;
>>>> +
>>>> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
>>>> + DRM_ERROR("device doesn't support I2C\n");
>>>> + return -ENODEV;
>>>> + }
>>>> +
>>>> + pdata = devm_kzalloc(&client->dev, sizeof(struct ti_sn_bridge),
>>>> + GFP_KERNEL);
>>>> + if (!pdata)
>>>> + return -ENOMEM;
>>>> +
>>>> + pdata->dev = &client->dev;
>>>> + dev_set_drvdata(&client->dev, pdata);
>>>> +
>>>> + pdata->regmap = devm_regmap_init_i2c(client,
>>>> + &ti_sn_bridge_regmap_config);
>>>> + if (IS_ERR(pdata->regmap)) {
>>>> + DRM_ERROR("regmap i2c init failed\n");
>>>> + return PTR_ERR(pdata->regmap);
>>>> + }
>>>> +
>>>> + pdata->enable_gpio = devm_gpiod_get(pdata->dev,
>>>> + "enable", GPIOD_OUT_LOW);
>>>> + if (IS_ERR(pdata->enable_gpio)) {
>>>> + DRM_ERROR("failed to get enable gpio from DT\n");
>>>> + ret = PTR_ERR(pdata->enable_gpio);
>>>> + return ret;
>>>> + }
>>>> +
>>>> + ret = ti_sn_bridge_parse_regulators(pdata);
>>>> + if (ret) {
>>>> + DRM_ERROR("failed to parse regulators\n");
>>>> + return ret;
>>>> + }
>>>> +
>>>> + ret = ti_sn_bridge_parse_dsi_host(pdata);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + pm_runtime_enable(pdata->dev);
>>>> + pm_runtime_get_sync(pdata->dev);
>>>> + ret = ti_sn_bridge_read_device_rev(pdata);
>>>> + pm_runtime_put_sync(pdata->dev);
>>> I would put it into (pre) enable callbacks, maybe with marking it to
>>> run
>>> only once.
>>>
>> do you mean we should put the ti_sn_bridge_read_device_rev() in pre
>> enable callback?
>
> Yes, to avoid unnecessary switching on/off device.
>
Ok. in that case i have add a rev field in the private data and check
for this be non-zero every time pre_enable is called else read the rev.
> Regards
> Andrzej
>
>>
>>> Regards
>>> Andrzej
>>>
>>>> + if (ret)
>>>> + goto err_rev_read;
>>>> +
>>>> + pdata->refclk = devm_clk_get(pdata->dev, "refclk");
>>>> +
>>>> + ddc_node = of_parse_phandle(pdata->dev->of_node, "ddc-i2c-bus",
>>>> 0);
>>>> + if (ddc_node) {
>>>> + pdata->ddc = of_find_i2c_adapter_by_node(ddc_node);
>>>> + of_node_put(ddc_node);
>>>> + if (!pdata->ddc) {
>>>> + DRM_DEBUG_KMS("failed to read ddc node\n");
>>>> + ret = -EPROBE_DEFER;
>>>> + goto err_rev_read;
>>>> + }
>>>> + } else {
>>>> + DRM_DEBUG_KMS("no ddc property found\n");
>>>> + }
>>>> +
>>>> + i2c_set_clientdata(client, pdata);
>>>> +
>>>> + pdata->bridge.funcs = &ti_sn_bridge_funcs;
>>>> + pdata->bridge.of_node = client->dev.of_node;
>>>> +
>>>> + drm_bridge_add(&pdata->bridge);
>>>> +
>>>> + return 0;
>>>> +
>>>> +err_rev_read:
>>>> + pm_runtime_disable(pdata->dev);
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static int ti_sn_bridge_remove(struct i2c_client *client)
>>>> +{
>>>> + struct ti_sn_bridge *pdata = i2c_get_clientdata(client);
>>>> +
>>>> + if (!pdata)
>>>> + return -EINVAL;
>>>> +
>>>> + mipi_dsi_detach(pdata->dsi);
>>>> + mipi_dsi_device_unregister(pdata->dsi);
>>>> +
>>>> + drm_bridge_remove(&pdata->bridge);
>>>> + pm_runtime_disable(pdata->dev);
>>>> + i2c_put_adapter(pdata->ddc);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static struct i2c_device_id ti_sn_bridge_id[] = {
>>>> + { "ti,sn65dsi86", 0},
>>>> + {},
>>>> +};
>>>> +MODULE_DEVICE_TABLE(i2c, ti_sn_bridge_id);
>>>> +
>>>> +static const struct of_device_id ti_sn_bridge_match_table[] = {
>>>> + {.compatible = "ti,sn65dsi86"},
>>>> + {},
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, ti_sn_bridge_match_table);
>>>> +
>>>> +static struct i2c_driver ti_sn_bridge_driver = {
>>>> + .driver = {
>>>> + .name = "ti_sn65dsi86",
>>>> + .of_match_table = ti_sn_bridge_match_table,
>>>> + .pm = &ti_sn_bridge_pm_ops,
>>>> + },
>>>> + .probe = ti_sn_bridge_probe,
>>>> + .remove = ti_sn_bridge_remove,
>>>> + .id_table = ti_sn_bridge_id,
>>>> +};
>>>> +
>>>> +module_i2c_driver(ti_sn_bridge_driver);
>>>> +MODULE_DESCRIPTION("sn65dsi86 DSI to eDP bridge driver");
>>>> +MODULE_LICENSE("GPL v2");
>>
>>
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply
* [PATCH v5 1/4] drm/rockchip: add transfer function for cdn-dp
From: Lin Huang @ 2018-05-17 9:17 UTC (permalink / raw)
To: seanpaul, airlied, zyw
Cc: dianders, briannorris, linux-rockchip, heiko, daniel.vetter,
jani.nikula, dri-devel, linux-arm-kernel, linux-kernel, eballetbo,
robh+dt, devicetree, Lin Huang
From: Chris Zhong <zyw@rock-chips.com>
We may support training outside firmware, so we need support
dpcd read/write to get the message or do some setting with
display.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Lin Huang <hl@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Enric Balletbo <enric.balletbo@collabora.com>
---
Changes in v2:
- update patch following Enric suggest
Changes in v3:
- None
Changes in v4:
- None
Changes in v5:
- None
drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 +++++++++++++++++++++++----
drivers/gpu/drm/rockchip/cdn-dp-core.h | 1 +
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 69 ++++++++++++++++++++++++++++++----
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 14 ++++++-
4 files changed, 122 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index c6fbdcd..cce64c1 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device *dp, u8 *sink_count)
u8 value;
*sink_count = 0;
- ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, &value, 1);
- if (ret)
+ ret = drm_dp_dpcd_read(&dp->aux, DP_SINK_COUNT, &value, 1);
+ if (ret < 0)
return ret;
*sink_count = DP_GET_SINK_COUNT(value);
@@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct cdn_dp_device *dp)
if (!cdn_dp_check_sink_connection(dp))
return -ENODEV;
- ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
- DP_RECEIVER_CAP_SIZE);
- if (ret) {
+ ret = drm_dp_dpcd_read(&dp->aux, DP_DPCD_REV, dp->dpcd,
+ sizeof(dp->dpcd));
+ if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
return ret;
}
@@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device *dp)
if (!port || !dp->link.rate || !dp->link.num_lanes)
return false;
- if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
- DP_LINK_STATUS_SIZE)) {
+ if (drm_dp_dpcd_read_link_status(&dp->aux, link_status) !=
+ DP_LINK_STATUS_SIZE) {
DRM_ERROR("Failed to get link status\n");
return false;
}
@@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
return NOTIFY_DONE;
}
+static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
+ struct drm_dp_aux_msg *msg)
+{
+ struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, aux);
+ int ret;
+ u8 status;
+
+ switch (msg->request & ~DP_AUX_I2C_MOT) {
+ case DP_AUX_NATIVE_WRITE:
+ case DP_AUX_I2C_WRITE:
+ case DP_AUX_I2C_WRITE_STATUS_UPDATE:
+ ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
+ msg->size);
+ break;
+ case DP_AUX_NATIVE_READ:
+ case DP_AUX_I2C_READ:
+ ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
+ msg->size);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ status = cdn_dp_get_aux_status(dp);
+ if (status == AUX_STATUS_ACK)
+ msg->reply = DP_AUX_NATIVE_REPLY_ACK;
+ else if (status == AUX_STATUS_NACK)
+ msg->reply = DP_AUX_NATIVE_REPLY_NACK;
+ else if (status == AUX_STATUS_DEFER)
+ msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
+
+ return ret;
+}
+
static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
{
struct cdn_dp_device *dp = dev_get_drvdata(dev);
@@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
dp->active = false;
dp->active_port = -1;
dp->fw_loaded = false;
+ dp->aux.name = "DP-AUX";
+ dp->aux.transfer = cdn_dp_aux_transfer;
+ dp->aux.dev = dev;
+
+ ret = drm_dp_aux_register(&dp->aux);
+ if (ret)
+ return ret;
INIT_WORK(&dp->event_work, cdn_dp_pd_event_work);
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index f57e296..46159b2 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -78,6 +78,7 @@ struct cdn_dp_device {
struct platform_device *audio_pdev;
struct work_struct event_work;
struct edid *edid;
+ struct drm_dp_aux aux;
struct mutex lock;
bool connected;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index eb3042c..979355d 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -221,7 +221,12 @@ static int cdn_dp_reg_write_bit(struct cdn_dp_device *dp, u16 addr,
sizeof(field), field);
}
-int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
+/*
+ * Returns the number of bytes transferred on success, or a negative
+ * error code on failure. -ETIMEDOUT is returned if mailbox message was
+ * not send successfully;
+ */
+ssize_t cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
{
u8 msg[5], reg[5];
int ret;
@@ -247,24 +252,41 @@ int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
goto err_dpcd_read;
ret = cdn_dp_mailbox_read_receive(dp, data, len);
+ if (!ret)
+ return len;
err_dpcd_read:
+ DRM_DEV_ERROR(dp->dev, "dpcd read failed: %d\n", ret);
return ret;
}
-int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
+#define CDN_AUX_HEADER_SIZE 5
+#define CDN_AUX_MSG_SIZE 20
+/*
+ * Returns the number of bytes transferred on success, or a negative error
+ * code on failure. -ETIMEDOUT is returned if mailbox message was not send
+ * success; -EINVAL is returned if get the wrong data size after message
+ * is sent
+ */
+ssize_t cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
{
- u8 msg[6], reg[5];
+ u8 msg[CDN_AUX_MSG_SIZE + CDN_AUX_HEADER_SIZE];
+ u8 reg[CDN_AUX_HEADER_SIZE];
int ret;
- msg[0] = 0;
- msg[1] = 1;
+ if (WARN_ON(len > CDN_AUX_MSG_SIZE) || WARN_ON(len <= 0))
+ return -EINVAL;
+
+ msg[0] = (len >> 8) & 0xff;
+ msg[1] = len & 0xff;
msg[2] = (addr >> 16) & 0xff;
msg[3] = (addr >> 8) & 0xff;
msg[4] = addr & 0xff;
- msg[5] = value;
+
+ memcpy(msg + CDN_AUX_HEADER_SIZE, data, len);
+
ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_DP_TX, DPTX_WRITE_DPCD,
- sizeof(msg), msg);
+ CDN_AUX_HEADER_SIZE + len, msg);
if (ret)
goto err_dpcd_write;
@@ -277,8 +299,12 @@ int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
if (ret)
goto err_dpcd_write;
- if (addr != (reg[2] << 16 | reg[3] << 8 | reg[4]))
+ if ((len != (reg[0] << 8 | reg[1])) ||
+ (addr != (reg[2] << 16 | reg[3] << 8 | reg[4]))) {
ret = -EINVAL;
+ } else {
+ return len;
+ }
err_dpcd_write:
if (ret)
@@ -286,6 +312,33 @@ int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
return ret;
}
+int cdn_dp_get_aux_status(struct cdn_dp_device *dp)
+{
+ u8 status;
+ int ret;
+
+ ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_DP_TX,
+ DPTX_GET_LAST_AUX_STAUS, 0, NULL);
+ if (ret)
+ goto err_get_hpd;
+
+ ret = cdn_dp_mailbox_validate_receive(dp, MB_MODULE_ID_DP_TX,
+ DPTX_GET_LAST_AUX_STAUS,
+ sizeof(status));
+ if (ret)
+ goto err_get_hpd;
+
+ ret = cdn_dp_mailbox_read_receive(dp, &status, sizeof(status));
+ if (ret)
+ goto err_get_hpd;
+
+ return status;
+
+err_get_hpd:
+ DRM_DEV_ERROR(dp->dev, "get aux status failed: %d\n", ret);
+ return ret;
+}
+
int cdn_dp_load_firmware(struct cdn_dp_device *dp, const u32 *i_mem,
u32 i_size, const u32 *d_mem, u32 d_size)
{
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.h b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
index c4bbb4a83..6580b11 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
@@ -328,6 +328,13 @@
#define GENERAL_BUS_SETTINGS 0x03
#define GENERAL_TEST_ACCESS 0x04
+/* AUX status*/
+#define AUX_STATUS_ACK 0
+#define AUX_STATUS_NACK 1
+#define AUX_STATUS_DEFER 2
+#define AUX_STATUS_SINK_ERROR 3
+#define AUX_STATUS_BUS_ERROR 4
+
#define DPTX_SET_POWER_MNG 0x00
#define DPTX_SET_HOST_CAPABILITIES 0x01
#define DPTX_GET_EDID 0x02
@@ -469,8 +476,11 @@ int cdn_dp_set_host_cap(struct cdn_dp_device *dp, u8 lanes, bool flip);
int cdn_dp_event_config(struct cdn_dp_device *dp);
u32 cdn_dp_get_event(struct cdn_dp_device *dp);
int cdn_dp_get_hpd_status(struct cdn_dp_device *dp);
-int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value);
-int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len);
+ssize_t cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr,
+ u8 *data, u16 len);
+ssize_t cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr,
+ u8 *data, u16 len);
+int cdn_dp_get_aux_status(struct cdn_dp_device *dp);
int cdn_dp_get_edid_block(void *dp, u8 *edid,
unsigned int block, size_t length);
int cdn_dp_train_link(struct cdn_dp_device *dp);
--
2.7.4
^ permalink raw reply related
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