* [PATCH v2 2/9] ARM64: dts: meson-gxbb-p201: add the ethernet PHY's reset GPIO
From: Martin Blumenstingl @ 2017-01-20 13:26 UTC (permalink / raw)
To: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, will.deacon-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, narmstrong-rdvid1DuHRBWk0Htik3J/w,
jbrunet-rdvid1DuHRBWk0Htik3J/w, Martin Blumenstingl
In-Reply-To: <20170120132650.9784-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state.
While here also specify the phy-handle of the ethmac node to make the
PHY configuration similar to the one we have on GXL devices. This will
allow us to specify OF-properties for the PHY itself.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
index 39bb037a3e47..5d2cd2ecfdc4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
@@ -50,3 +50,27 @@
compatible = "amlogic,p201", "amlogic,meson-gxbb";
model = "Amlogic Meson GXBB P201 Development Board";
};
+
+ðmac {
+ status = "okay";
+ pinctrl-0 = <ð_rgmii_pins>;
+ pinctrl-names = "default";
+ phy-handle = <ð_phy0>;
+ phy-mode = "rgmii";
+
+ snps,reset-gpio = <&gpio GPIOZ_14 0>;
+ snps,reset-delays-us = <0 10000 1000000>;
+ snps,reset-active-low;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-id0022.1620",
+ "ethernet-phy-ieee802.3-c22";
+ reg = <3>;
+ };
+ };
+};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 3/9] ARM64: dts: meson-gxbb-vega-s95: add the ethernet PHY's reset GPIO
From: Martin Blumenstingl @ 2017-01-20 13:26 UTC (permalink / raw)
To: linux-amlogic, khilman, carlo
Cc: mark.rutland, devicetree, narmstrong, Martin Blumenstingl,
catalin.marinas, will.deacon, robh+dt, linux-arm-kernel, jbrunet
In-Reply-To: <20170120132650.9784-1-martin.blumenstingl@googlemail.com>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state.
While here also specify the phy-handle of the ethmac node to make the
PHY configuration similar to the one we have on GXL devices. This will
allow us to specify OF-properties for the PHY itself.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index 86709929fd20..358ab5159bd5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -128,6 +128,24 @@
status = "okay";
pinctrl-0 = <ð_rgmii_pins>;
pinctrl-names = "default";
+ phy-handle = <ð_phy0>;
+ phy-mode = "rgmii";
+
+ snps,reset-gpio = <&gpio GPIOZ_14 0>;
+ snps,reset-delays-us = <0 10000 1000000>;
+ snps,reset-active-low;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-id001c.c916",
+ "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+ };
};
&usb0_phy {
--
2.11.0
^ permalink raw reply related
* [PATCH v2 4/9] ARM64: dts: meson-gxbb-nexbox-a95x: add the ethernet PHY's reset GPIO
From: Martin Blumenstingl @ 2017-01-20 13:26 UTC (permalink / raw)
To: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, will.deacon-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, narmstrong-rdvid1DuHRBWk0Htik3J/w,
jbrunet-rdvid1DuHRBWk0Htik3J/w, Martin Blumenstingl
In-Reply-To: <20170120132650.9784-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state.
While here also specify the phy-handle of the ethmac node to make the
PHY configuration similar to the one we have on GXL devices. This will
allow us to specify OF-properties for the PHY itself.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 4cbd626a9e88..c7e3ea008566 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -164,7 +164,24 @@
status = "okay";
pinctrl-0 = <ð_rmii_pins>;
pinctrl-names = "default";
+ phy-handle = <ð_phy0>;
phy-mode = "rmii";
+
+ snps,reset-gpio = <&gpio GPIOZ_14 0>;
+ snps,reset-delays-us = <0 10000 1000000>;
+ snps,reset-active-low;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-id0243.0c54",
+ "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+ };
};
&ir {
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 5/9] ARM64: dts: meson-gxbb-wetek-hub: add the ethernet PHY's reset GPIO
From: Martin Blumenstingl @ 2017-01-20 13:26 UTC (permalink / raw)
To: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, will.deacon-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, narmstrong-rdvid1DuHRBWk0Htik3J/w,
jbrunet-rdvid1DuHRBWk0Htik3J/w, Martin Blumenstingl
In-Reply-To: <20170120132650.9784-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state.
While here also specify the phy-handle of the ethmac node to make the
PHY configuration similar to the one we have on GXL devices. This will
allow us to specify OF-properties for the PHY itself.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
.../boot/dts/amlogic/meson-gxbb-wetek-hub.dts | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
index 56f855901262..47fe4e444f33 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
@@ -64,3 +64,27 @@
status = "disabled";
};
};
+
+ðmac {
+ status = "okay";
+ pinctrl-0 = <ð_rgmii_pins>;
+ pinctrl-names = "default";
+ phy-handle = <ð_phy0>;
+ phy-mode = "rgmii";
+
+ snps,reset-gpio = <&gpio GPIOZ_14 0>;
+ snps,reset-delays-us = <0 10000 1000000>;
+ snps,reset-active-low;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-id001c.c916",
+ "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+ };
+};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 6/9] ARM64: dts: meson-gxbb-wetek-play2: add the ethernet PHY's reset GPIO
From: Martin Blumenstingl @ 2017-01-20 13:26 UTC (permalink / raw)
To: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, will.deacon-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, narmstrong-rdvid1DuHRBWk0Htik3J/w,
jbrunet-rdvid1DuHRBWk0Htik3J/w, Martin Blumenstingl
In-Reply-To: <20170120132650.9784-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state.
While here also specify the phy-handle of the ethmac node to make the
PHY configuration similar to the one we have on GXL devices. This will
allow us to specify OF-properties for the PHY itself.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
.../boot/dts/amlogic/meson-gxbb-wetek-play2.dts | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
index ea79fdd2c248..9a8e2f492b97 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
@@ -87,6 +87,30 @@
};
};
+ðmac {
+ status = "okay";
+ pinctrl-0 = <ð_rgmii_pins>;
+ pinctrl-names = "default";
+ phy-handle = <ð_phy0>;
+ phy-mode = "rgmii";
+
+ snps,reset-gpio = <&gpio GPIOZ_14 0>;
+ snps,reset-delays-us = <0 10000 1000000>;
+ snps,reset-active-low;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-id001c.c916",
+ "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+ };
+};
+
&i2c_A {
status = "okay";
pinctrl-0 = <&i2c_a_pins>;
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 7/9] ARM64: dts: meson-gxbb-p20x: remove the ethernet node
From: Martin Blumenstingl @ 2017-01-20 13:26 UTC (permalink / raw)
To: linux-amlogic, khilman, carlo
Cc: mark.rutland, devicetree, narmstrong, Martin Blumenstingl,
catalin.marinas, will.deacon, robh+dt, linux-arm-kernel, jbrunet
In-Reply-To: <20170120132650.9784-1-martin.blumenstingl@googlemail.com>
This efficively disables ethernet on the meson-gxbb-p200 board.
Amlogic's own .dts specifies that the P200 board uses a RMII PHY,
however our own P200 board .dts does not override the PHY-mode (meaning
that it takes the default from meson-gx, which is RGMII mode).
This prevents people from thinking that ethernet is actually supported
on the P200 boards. People with access to such a board can simply
provide a patch which re-enables the ethmac node and adds the required
properties.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 6 ------
1 file changed, 6 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 4a96e0f6f926..17ebe46e48d4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -144,12 +144,6 @@
pinctrl-names = "default";
};
-ðmac {
- status = "okay";
- pinctrl-0 = <ð_rgmii_pins>;
- pinctrl-names = "default";
-};
-
&ir {
status = "okay";
pinctrl-0 = <&remote_input_ao_pins>;
--
2.11.0
^ permalink raw reply related
* [PATCH v2 8/9] ARM64: dts: amlogic: add the ethernet TX delay configuration
From: Martin Blumenstingl @ 2017-01-20 13:26 UTC (permalink / raw)
To: linux-amlogic, khilman, carlo
Cc: mark.rutland, devicetree, narmstrong, Martin Blumenstingl,
catalin.marinas, will.deacon, robh+dt, linux-arm-kernel, jbrunet
In-Reply-To: <20170120132650.9784-1-martin.blumenstingl@googlemail.com>
This adds the amlogic,tx-delay-ns property with the old (hardcoded)
default value of 2ns to all boards which are using an RGMII ethernet
PHY.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 ++
arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts | 2 ++
8 files changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 6b5579522587..e63ed98d6c25 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -154,6 +154,8 @@
phy-handle = <ð_phy0>;
phy-mode = "rgmii";
+ amlogic,tx-delay-ns = <2>;
+
snps,reset-gpio = <&gpio GPIOZ_14 0>;
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
index 5d2cd2ecfdc4..70a7108b4b16 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
@@ -58,6 +58,8 @@
phy-handle = <ð_phy0>;
phy-mode = "rgmii";
+ amlogic,tx-delay-ns = <2>;
+
snps,reset-gpio = <&gpio GPIOZ_14 0>;
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index 358ab5159bd5..4301ad860a76 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -131,6 +131,8 @@
phy-handle = <ð_phy0>;
phy-mode = "rgmii";
+ amlogic,tx-delay-ns = <2>;
+
snps,reset-gpio = <&gpio GPIOZ_14 0>;
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
index 47fe4e444f33..f6d8c70a26a2 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
@@ -72,6 +72,8 @@
phy-handle = <ð_phy0>;
phy-mode = "rgmii";
+ amlogic,tx-delay-ns = <2>;
+
snps,reset-gpio = <&gpio GPIOZ_14 0>;
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
index 9a8e2f492b97..1a222ce60a30 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
@@ -94,6 +94,8 @@
phy-handle = <ð_phy0>;
phy-mode = "rgmii";
+ amlogic,tx-delay-ns = <2>;
+
snps,reset-gpio = <&gpio GPIOZ_14 0>;
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
index f66939cacd37..7663d6775823 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
@@ -59,6 +59,8 @@
/* Select external PHY by default */
phy-handle = <&external_phy>;
+ amlogic,tx-delay-ns = <2>;
+
/* External PHY reset is shared with internal PHY Led signals */
snps,reset-gpio = <&gpio GPIOZ_14 0>;
snps,reset-delays-us = <0 10000 1000000>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index 5a337d339df1..a0bc746adb42 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -162,6 +162,8 @@
/* Select external PHY by default */
phy-handle = <&external_phy>;
+ amlogic,tx-delay-ns = <2>;
+
snps,reset-gpio = <&gpio GPIOZ_14 0>;
snps,reset-delays-us = <0 10000 1000000>;
snps,reset-active-low;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts
index 5dbc66088355..e6ac39b712b7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts
@@ -59,6 +59,8 @@
/* Select external PHY by default */
phy-handle = <&external_phy>;
+ amlogic,tx-delay-ns = <2>;
+
/* External PHY reset is shared with internal PHY Led signals */
snps,reset-gpio = <&gpio GPIOZ_14 0>;
snps,reset-delays-us = <0 10000 1000000>;
--
2.11.0
^ permalink raw reply related
* [PATCH v2 9/9] ARM64: dts: meson-gx: remove the phy-mode property from meson-gx
From: Martin Blumenstingl @ 2017-01-20 13:26 UTC (permalink / raw)
To: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, will.deacon-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, narmstrong-rdvid1DuHRBWk0Htik3J/w,
jbrunet-rdvid1DuHRBWk0Htik3J/w, Martin Blumenstingl
In-Reply-To: <20170120132650.9784-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
The ethmac node has to be configured for each board due to different
pinctrl nodes for RGMII/RMII. Thus the phy-mode should be specified at
the same place (= in the board .dts), making it easier to read the board
.dts file (because the phy-mode is stated explicitly, without requiring
developers to read all "parent" .dtsi as well).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index c1291007b37c..85bce028c76e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -395,7 +395,6 @@
0x0 0xc8834540 0x0 0x4>;
interrupts = <0 8 1>;
interrupt-names = "macirq";
- phy-mode = "rgmii";
status = "disabled";
};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v5 00/14] ARM: da850-lcdk: add SATA support
From: Tejun Heo @ 2017-01-20 13:28 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Rob Herring, Mark Rutland, Russell King, David Lechner,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484911325-23425-1-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Fri, Jan 20, 2017 at 12:21:51PM +0100, Bartosz Golaszewski wrote:
> This series contains all the changes necessary to make SATA work on
> the da850-lcdk board.
>
> The first patch adds DT bindings for the ahci-da850 driver.
>
> The second enables relevant modules in davinci_all_defconfig.
>
> Patches 03/14-06/14 modify the way the clocks are handled regarding
> SATA on the da850 platform. We modify the ahci driver to retrieve
> the clock via con_id and model the external SATA oscillator as
> a real clock.
>
> Patches 07/14-11/14 extend the ahci-da850 driver. Add DT support,
> implement workarounds necessary to make SATA work on the da850-lcdk
> board and un-hardcode the external clock multiplier.
Please feel free to add
Acked-by: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
to the all libata patches. Please let me know how the patches should
be routed once other parts are settled.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/9] ARM64: dts: meson-gxbb-p201: add the ethernet PHY's reset GPIO
From: Neil Armstrong @ 2017-01-20 13:31 UTC (permalink / raw)
To: Martin Blumenstingl,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, will.deacon-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, jbrunet-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <20170120132650.9784-3-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On 01/20/2017 02:26 PM, Martin Blumenstingl wrote:
> This resets the ethernet PHY during boot to get the PHY into a "clean"
> state.
> While here also specify the phy-handle of the ethmac node to make the
> PHY configuration similar to the one we have on GXL devices. This will
> allow us to specify OF-properties for the PHY itself.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
> index 39bb037a3e47..5d2cd2ecfdc4 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
> @@ -50,3 +50,27 @@
> compatible = "amlogic,p201", "amlogic,meson-gxbb";
> model = "Amlogic Meson GXBB P201 Development Board";
> };
> +
> +ðmac {
> + status = "okay";
> + pinctrl-0 = <ð_rgmii_pins>;
> + pinctrl-names = "default";
> + phy-handle = <ð_phy0>;
> + phy-mode = "rgmii";
> +
> + snps,reset-gpio = <&gpio GPIOZ_14 0>;
> + snps,reset-delays-us = <0 10000 1000000>;
> + snps,reset-active-low;
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + eth_phy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-id0022.1620",
> + "ethernet-phy-ieee802.3-c22";
> + reg = <3>;
> + };
> + };
> +};
>
Hi Martin,
It seems you mismatched the p200 and the p201, it's the p201 nobody has and uses a rmii link.
Neil
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 01/14] devicetree: bindings: add bindings for ahci-da850
From: Sekhar Nori @ 2017-01-20 13:32 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Patrick Titiano,
Michael Turquette, Tejun Heo, Rob Herring, Mark Rutland,
Russell King, David Lechner
Cc: linux-ide, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1484911325-23425-2-git-send-email-bgolaszewski@baylibre.com>
Hi Rob,
On Friday 20 January 2017 04:51 PM, Bartosz Golaszewski wrote:
> Add DT bindings for the TI DA850 AHCI SATA controller.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Could you ack this binding?
Thanks,
Sekhar
> ---
> Documentation/devicetree/bindings/ata/ahci-da850.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt
>
> diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt b/Documentation/devicetree/bindings/ata/ahci-da850.txt
> new file mode 100644
> index 0000000..268fe87
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ata/ahci-da850.txt
> @@ -0,0 +1,15 @@
> +Device tree binding for the TI DA850 AHCI SATA Controller
> +---------------------------------------------------------
> +
> +Required properties:
> + - compatible: must be "ti,da850-ahci"
> + - reg: physical base addresses and sizes of the controller's register areas
> + - interrupts: interrupt specifier (refer to the interrupt binding)
> +
> +Example:
> +
> + sata: sata@218000 {
> + compatible = "ti,da850-ahci";
> + reg = <0x218000 0x2000>, <0x22c018 0x4>;
> + interrupts = <67>;
> + };
>
^ permalink raw reply
* Re: [PATCH v2 2/9] ARM64: dts: meson-gxbb-p201: add the ethernet PHY's reset GPIO
From: Martin Blumenstingl @ 2017-01-20 13:33 UTC (permalink / raw)
To: Neil Armstrong
Cc: mark.rutland, devicetree, khilman, will.deacon, robh+dt,
catalin.marinas, carlo, linux-amlogic, linux-arm-kernel, jbrunet
In-Reply-To: <8a0b6c29-38f0-8474-34a2-8e3df4a5a239@baylibre.com>
On Fri, Jan 20, 2017 at 2:31 PM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> On 01/20/2017 02:26 PM, Martin Blumenstingl wrote:
>> This resets the ethernet PHY during boot to get the PHY into a "clean"
>> state.
>> While here also specify the phy-handle of the ethmac node to make the
>> PHY configuration similar to the one we have on GXL devices. This will
>> allow us to specify OF-properties for the PHY itself.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 24 ++++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
>> index 39bb037a3e47..5d2cd2ecfdc4 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
>> @@ -50,3 +50,27 @@
>> compatible = "amlogic,p201", "amlogic,meson-gxbb";
>> model = "Amlogic Meson GXBB P201 Development Board";
>> };
>> +
>> +ðmac {
>> + status = "okay";
>> + pinctrl-0 = <ð_rgmii_pins>;
>> + pinctrl-names = "default";
>> + phy-handle = <ð_phy0>;
>> + phy-mode = "rgmii";
>> +
>> + snps,reset-gpio = <&gpio GPIOZ_14 0>;
>> + snps,reset-delays-us = <0 10000 1000000>;
>> + snps,reset-active-low;
>> +
>> + mdio {
>> + compatible = "snps,dwmac-mdio";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + eth_phy0: ethernet-phy@0 {
>> + compatible = "ethernet-phy-id0022.1620",
>> + "ethernet-phy-ieee802.3-c22";
>> + reg = <3>;
>> + };
>> + };
>> +};
>>
>
> Hi Martin,
>
> It seems you mismatched the p200 and the p201, it's the p201 nobody has and uses a rmii link.
ouch, good catch.
I'll send a fix for that later - thanks for spotting!
^ permalink raw reply
* Re: [PATCH 1/3 v2] ahci: qoriq: added a condition to enable dma coherence
From: Tejun Heo @ 2017-01-20 13:34 UTC (permalink / raw)
To: yuantian.tang
Cc: mark.rutland, devicetree, mathieu.poirier, linux-kernel,
linux-ide, robh+dt, robin.murphy, linux-arm-kernel
In-Reply-To: <1484895576-40379-1-git-send-email-yuantian.tang@nxp.com>
On Fri, Jan 20, 2017 at 02:59:34PM +0800, yuantian.tang@nxp.com wrote:
> From: Tang Yuantian <Yuantian.Tang@nxp.com>
>
> Enable DMA coherence in SATA controller on condition that
> dma-coherent property exists in sata node in DTS.
>
> Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
Applied to libata/for-4.11.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH net-next v4 2/2] net: stmmac: dwmac-meson8b: make the RGMII TX delay configurable
From: Martin Blumenstingl @ 2017-01-20 13:47 UTC (permalink / raw)
To: David Miller
Cc: mark.rutland, devicetree, alexandre.torgue, netdev,
peppe.cavallaro, robh+dt, khilman, carlo, linux-amlogic,
linux-arm-kernel
In-Reply-To: <CAFBinCDZ_mqt8q2rG6zDy8ke5sX6L+4sVYOOhWUdO3apwFiRYw@mail.gmail.com>
Hi David,
On Sun, Dec 18, 2016 at 5:13 PM, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> On Sun, Dec 18, 2016 at 4:49 PM, David Miller <davem@davemloft.net> wrote:
>> From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> Date: Sat, 17 Dec 2016 19:21:19 +0100
>>
>>> Prior to this patch we were using a hardcoded RGMII TX clock delay of
>>> 2ns (= 1/4 cycle of the 125MHz RGMII TX clock). This value works for
>>> many boards, but unfortunately not for all (due to the way the actual
>>> circuit is designed, sometimes because the TX delay is enabled in the
>>> PHY, etc.). Making the TX delay on the MAC side configurable allows us
>>> to support all possible hardware combinations.
>>>
>>> This allows fixing a compatibility issue on some boards, where the
>>> RTL8211F PHY is configured to generate the TX delay. We can now turn
>>> off the TX delay in the MAC, because otherwise we would be applying the
>>> delay twice (which results in non-working TX traffic).
>>>
>>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>>> Tested-by: Neil Armstrong <narmstrong@baylibre.com>
>>
>> Is this really the safest thing to do?
>>
>> If you say the existing hard-coded setting of 1/4 cycle works on most
>> boards, and what you're trying to do is override it with an OF
>> property value for boards where the existing setting does not work,
>> then you _must_ use a default value that corresponds to what the
>> existing code does not when you don't see this new OF property.
> it's a bit more complicated in reality: 1/4 cycle works when the TX
> delay of the RTL8211F PHY is turned off (until recently it was always
> enabled for phy-mode RGMII).
>
>> So please retain the current behavior of the 1/4 cycle TX delay
>> setting when you don't see the amlogic,tx-delay-ns property.
>>
>> I really think you risk breaking existing boards by not doing so,
>> unless you can have this patch tested on every such board that exists
>> and I don't think you really can feasibly and rigorously do that.
> there's a patch in my follow-up series which adds the 2ns to the .dts
> for all RGMII based boards: [0] (and I would keep these even if we had
> a default value, just to make it explicit and thus easier to
> understand for other people).
> however, we can add the 2ns default back (I can do this if you want -
> Rob Herring was unhappy with the missing documentation of this default
> value [1] - so note to myself: take care of that as well). but then we
> have to decide when to apply this default value: only when we're in
> RGMII mode or also in any of the RGMII_*ID modes?
could you please let me know if I should add a a fallback (2ns which
was the old hardcoded value) to the driver or if I should simply leave
it out (that's the way it is right now).
I'm fine with either way, I would just like to avoid duplicate work.
So please let me know how you prefer it.
Regards,
Martin
^ permalink raw reply
* Re: [PATCH v3 00/24] i.MX Media Driver
From: Hans Verkuil @ 2017-01-20 13:52 UTC (permalink / raw)
To: Steve Longerbeam, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, fabio.estevam-3arQi8VN3Tc,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
nick-gcszYUEDH4VrovVCs/uTlw, markus.heiser-O6JHGLzbNUwb1SvskN2V4Q,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw,
bparrot-l0cyMroinI0, geert-Td1EMuHUCqxL1ZNQvxDV9g,
arnd-r2nGTMty4D4, sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w,
minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w,
tiffany.lin-NuS5LvNUpcJWk0Htik3J/w,
jean-christophe.trotin-qxv4g6HH51o,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw,
robert.jarzmik-GANU6spQydw, songjun.wu-UWL1GkI3JZL3oGB3hsPCZA,
andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, Steve Longerbeam
In-Reply-To: <1483755102-24785-1-git-send-email-steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Hi Steve, Philipp,
On 01/07/2017 03:11 AM, Steve Longerbeam wrote:
> In version 3:
>
> Changes suggested by Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>
> - prepended FIM node properties with vendor prefix "fsl,".
>
> - make mipi csi-2 receiver compatible string SoC specific:
> "fsl,imx6-mipi-csi2" instead of "fsl,imx-mipi-csi2".
>
> - redundant "_clk" removed from mipi csi-2 receiver clock-names property.
>
> - removed board-specific info from the media driver binding doc. These
> were all related to sensor bindings, which already are (adv7180)
> or will be (ov564x) covered in separate binding docs. All reference
> board info not related to DT bindings has been moved to
> Documentation/media/v4l-drivers/imx.rst.
>
> - removed "_mipi" from the OV5640 compatible string.
>
> Changes suggested by Vladimir Zapolskiy <vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>:
>
> Mostly cosmetic/non-functional changes which I won't list here, except
> for the following:
>
> - spin_lock_irqsave() changed to spin_lock() in a couple interrupt handlers.
>
> - fixed some unnecessary of_node_put()'s in for_each_child_of_node() loops.
>
> - check/handle return code from required reg property of CSI port nodes.
>
> - check/handle return code from clk_prepare_enable().
>
> Changes suggested by Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
> - switch to VGEN3 Analog Vdd supply assuming rev. C SabreSD boards.
>
> - finally got around to passing valid IOMUX pin config values to the
> pin groups.
>
> Other changes:
>
> - removed the FIM properties that overrided the v4l2 FIM control defaults
> values. This was left-over from a requirement of a customer and is not
> necessary here.
>
> - The FIM must be explicitly enabled in the fim child node under the CSI
> port nodes, using the status property. If not enabled, FIM v4l2 controls
> will not appear in the video capture driver.
>
> - brought in additional media types patch from Philipp Zabel. Use new
> MEDIA_ENT_F_VID_IF_BRIDGE in mipi csi-2 receiver subdev.
>
> - brought in latest platform generic video multiplexer subdevice driver
> from Philipp Zabel (squashed with patch that uses new MEDIA_ENT_F_MUX).
>
> - removed imx-media-of.h, moved those prototypes into imx-media.h.
Based on the discussion on the mailinglist it seems everyone agrees that this
is the preferred driver, correct?
There are a bunch of review comments, so I will wait for a v4. I plan to merge
that staging driver unless there are major issues with it.
I am not sure if I would merge those sensor drivers in staging, I'll have to
take a closer look at those once v4 is posted.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 12/24] add mux and video interface bridge entity functions
From: Hans Verkuil @ 2017-01-20 13:56 UTC (permalink / raw)
To: Steve Longerbeam, robh+dt, mark.rutland, shawnguo, kernel,
fabio.estevam, linux, mchehab, nick, markus.heiser, p.zabel,
laurent.pinchart+renesas, bparrot, geert, arnd, sudipm.mukherjee,
minghsiu.tsai, tiffany.lin, jean-christophe.trotin, horms+renesas,
niklas.soderlund+renesas, robert.jarzmik, songjun.wu,
andrew-ct.chen, gregkh
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-media, devel
In-Reply-To: <1483755102-24785-13-git-send-email-steve_longerbeam@mentor.com>
On 01/07/2017 03:11 AM, Steve Longerbeam wrote:
> From: Philipp Zabel <p.zabel@pengutronix.de>
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> Documentation/media/uapi/mediactl/media-types.rst | 22 ++++++++++++++++++++++
> include/uapi/linux/media.h | 6 ++++++
> 2 files changed, 28 insertions(+)
>
> diff --git a/Documentation/media/uapi/mediactl/media-types.rst b/Documentation/media/uapi/mediactl/media-types.rst
> index 3e03dc2..023be29 100644
> --- a/Documentation/media/uapi/mediactl/media-types.rst
> +++ b/Documentation/media/uapi/mediactl/media-types.rst
> @@ -298,6 +298,28 @@ Types and flags used to represent the media graph elements
> received on its sink pad and outputs the statistics data on
> its source pad.
>
> + - .. row 29
> +
> + .. _MEDIA-ENT-F-MUX:
> +
> + - ``MEDIA_ENT_F_MUX``
I would prefer MEDIA_ENT_F_VID_MUX since this is video specific.
Regards,
Hans
> +
> + - Video multiplexer. An entity capable of multiplexing must have at
> + least two sink pads and one source pad, and must pass the video
> + frame(s) received from the active sink pad to the source pad. Video
> + frame(s) from the inactive sink pads are discarded.
> +
> + - .. row 30
> +
> + .. _MEDIA-ENT-F-VID-IF-BRIDGE:
> +
> + - ``MEDIA_ENT_F_VID_IF_BRIDGE``
> +
> + - Video interface bridge. A video interface bridge entity must have at
> + least one sink pad and one source pad. It receives video frame(s) on
> + its sink pad in one bus format (HDMI, eDP, MIPI CSI-2, ...) and
> + converts them and outputs them on its source pad in another bus format
> + (eDP, MIPI CSI-2, parallel, ...).
>
> .. tabularcolumns:: |p{5.5cm}|p{12.0cm}|
>
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index 4890787..08a8bfa 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -105,6 +105,12 @@ struct media_device_info {
> #define MEDIA_ENT_F_PROC_VIDEO_STATISTICS (MEDIA_ENT_F_BASE + 0x4006)
>
> /*
> + * Switch and bridge entitites
> + */
> +#define MEDIA_ENT_F_MUX (MEDIA_ENT_F_BASE + 0x5001)
> +#define MEDIA_ENT_F_VID_IF_BRIDGE (MEDIA_ENT_F_BASE + 0x5002)
> +
> +/*
> * Connectors
> */
> /* It is a responsibility of the entity drivers to add connectors and links */
>
^ permalink raw reply
* Re: [PATCH v5 00/14] ARM: da850-lcdk: add SATA support
From: Sekhar Nori @ 2017-01-20 13:56 UTC (permalink / raw)
To: Tejun Heo, Bartosz Golaszewski
Cc: Mark Rutland, devicetree, David Lechner, Kevin Hilman,
Michael Turquette, Russell King, linux-kernel, linux-ide,
Rob Herring, Patrick Titiano, linux-arm-kernel
In-Reply-To: <20170120132843.GA31487@mtj.duckdns.org>
Hi Tejun,
On Friday 20 January 2017 06:58 PM, Tejun Heo wrote:
> On Fri, Jan 20, 2017 at 12:21:51PM +0100, Bartosz Golaszewski wrote:
>> This series contains all the changes necessary to make SATA work on
>> the da850-lcdk board.
>>
>> The first patch adds DT bindings for the ahci-da850 driver.
>>
>> The second enables relevant modules in davinci_all_defconfig.
>>
>> Patches 03/14-06/14 modify the way the clocks are handled regarding
>> SATA on the da850 platform. We modify the ahci driver to retrieve
>> the clock via con_id and model the external SATA oscillator as
>> a real clock.
>>
>> Patches 07/14-11/14 extend the ahci-da850 driver. Add DT support,
>> implement workarounds necessary to make SATA work on the da850-lcdk
>> board and un-hardcode the external clock multiplier.
>
> Please feel free to add
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> to the all libata patches. Please let me know how the patches should
> be routed once other parts are settled.
I believe you can queue the libata patches independently (patches 1, 4,
7, 8, 9, 10, 11). It looks like they have been written such that driver
continues to work with existing platform code (Bartosz, please disagree
if I am wrong). 1/14 still needs the ack from DT maintainers.
I would like to queue the platform parts (rest of the patches) through
ARM-SoC since they will likely clash with code I have queued.
Thanks,
Sekhar
^ permalink raw reply
* Re: [RFC v2 4/5] DT bindings documentation for Synopsys UDC platform driver
From: Rob Herring @ 2017-01-20 13:58 UTC (permalink / raw)
To: Florian Fainelli, Scott Branden
Cc: Ray Jui, Florian Fainelli, Raviteja Garimella, Mark Rutland,
Greg Kroah-Hartman, Felipe Balbi, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
bcm-kernel-feedback-list@broadcom.com, Linux USB List
In-Reply-To: <5ec22ba3-6753-3f62-77b0-1715a53e8fea@broadcom.com>
On Thu, Jan 19, 2017 at 4:56 PM, Florian Fainelli
<florian.fainelli@broadcom.com> wrote:
> On 01/19/2017 02:36 PM, Scott Branden wrote:
>>>>> The driver stands alone from the SoC and does not need compatibility
>>>>> strings per SoC. New SoCs will use the exact same block.
>>>>
>>>> Even if you take the exact same block and put it in a different SoC,
>>>> that's still an integration work that 99% of the time goes just fine
>>>> because the validation worked great, and the 1% of the time where you
>>>> need to capture an integration bug, you are glad this SoC-specific
>>>> compatible string exists such that you can work around it in the driver.
>>>
>>> That's a very conservative estimate. Based on my experience, it's more
>>> like 50/50, i.e., roughly half of the time we found SoC integration
>>> specific quirks or workaround are needed.
>>>
>> 50% is an exaggeration for sure. Maybe a driver you are has that issue
>> but that is not the case with most drivers. We have many IP blocks in
>> the SoC - both internal and externally sourced IP. We integrate SP805
>> timer driver into many SoCs and never specify a SoC specific
>> compatibility string with it (nor should we).
Even if it was only 10%, that's still reason to do it.
> Well, that's a good example where in premise, each SoC vendor
> integrating such a peripheral from a third party should actually have
> defined its own SoC/vendor compatible string to document the
> integration. And you can sometimes see some vendors having to workaround
> such essential peripherals and ending-up documenting compatible strings
> (or close enough in the example at [1]).
ARM peripherals are a bit unique because they have ID registers and
vendors tend to change them if they change the IP. And we can also set
the ID in the DT.
It's also a huge difference between a timer and a USB controller.
There's very little in a timer that vendors can f*ck up as well as few
revisions and config options. Experience has shown that USB always
gets integrated in different ways. We can't even get the number of
clocks right on licensed IP blocks. Like many things, there is a
judgement call here.
> [1]: http://www.spinics.net/lists/devicetree/msg159585.html
>
> It's a bad example though in that it's an IP that came from ARM, so the
> confidence level in getting the integration right is just higher
> (typically above level 9000), because ripping apart a third party is
> governed by strict architecture licensing agreements that usually
> prevents people suffering from the Not Invented Here syndrome from
> making damage.
>
>>
>> That being said - if your driver needs to know SoC specifics is should
>> not need to have an SoC specific compatibility string added per driver.
>> Why can your driver just not query that information from the upper level
>> SoC specific info already present in device tree?
>
> You could do that, but that just does not happen to be a common or
> recommended practice AFAICT, although I could be just wrong here of course.
We did a lot of work to get rid machine_is_X(). Let's say you have 10
SoCs and 5 have a quirk in a device and 5 don't. You need 2 device
compatible strings to match in that case. If you check at the top
level you may have to check 5 strings because you can't claim all 5
SoCs to be compatible with each other (that only works for
sub/supersets). You would also have to update the driver for new SoCs
depending if they had the quirk or not.
>> Each SoC is already specified in device tree at the upper level already.
>> Example:
>> arch/arm/boot/dts/bcm7445.dtsi has this compatibility info already
>> present in its device tree:
>>
>> compatible = "brcm,bcm7445", "brcm,brcmstb";
>>
>> If needed, a driver should query this info rather than adding SoC
>> specific compatibility strings to every single device tree entry.
>
> Or you could just put it in the compatible string list for a given
> peripheral, and yes, this is a repetition of information that is already
> there at a higher level from that particular node, but, it has the
> advantage of making all this information self contained within that
> node's context, and that's a good design goal.
>
>>
>> We should only add driver revision numbers as needed, not SoC specific
>> names. That way drivers don't change when the (same revision) of the IP
>> block is added to a new SoCs. And then if a SoC specific workaround is
>> needed the upper level compatibility string can be queried should be
>> utilized. It already exists today and is available for use to all drivers.
>
> The point is to plan ahead for information that you *may*, but *wish*
> you did not need.
>
> Quite frankly, I don't think you are going to win any argument where you
> don't add a SoC compatible string to the binding, because there are tons
> of precedents and good practices that suggest doing it. You might as
> well just do it, it's documented, it's there, if you end up using it or
> not, that's totally up to the driver author.
Right.
Rob
^ permalink raw reply
* Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Ulf Hansson @ 2017-01-20 14:00 UTC (permalink / raw)
To: Rob Herring, Kevin Hilman
Cc: Tero Kristo, Dave Gerlach, Rafael J . Wysocki,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Nishanth Menon, Keerthy, Russell King, Sudeep Holla,
Santosh Shilimkar, Lokesh Vutla
In-Reply-To: <CAL_Jsq+Vp8iYrAUmuSRzeeY_G6CUqFqG6XB6erDxo1RYo3g4=g@mail.gmail.com>
+ Sudeep
On 19 January 2017 at 00:03, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Tue, Jan 17, 2017 at 6:07 PM, Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
>> Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org> writes:
>>> On 17/01/17 00:12, Dave Gerlach wrote:
>>>> On 01/13/2017 08:40 PM, Rob Herring wrote:
>>>>> On Fri, Jan 13, 2017 at 2:28 PM, Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> wrote:
>
> [...]
>
>>>>>> My ti,sci-id is not an index into a list of power domains, so it
>>>>>> should not
>>>>>> go in the power-domains cells and go against what the power-domains
>>>>>> binding
>>>>>> says that the cell expects. We have one single power domain, and the new
>>>>>> ti,sci-id binding is not something the genpd framework itself is
>>>>>> concerned
>>>>>> with as it's our property to identify a device inside a power domain,
>>>>>> not to
>>>>>> identify which power domain it is associated with.
>>>>>
>>>>> What is the id used for? I can understand why you need to know what
>>>>> power domain a device is in (as power-domains identifies), but not
>>>>> what devices are in a power domain.
>>>>
>>>> We have a system control processor that provides power management
>>>> services to the OS and it responsible for handling the power state of
>>>> each device. This control happens over a communication interface we have
>>>> called TI SCI (implemented at drivers/firmware/ti-sci.c). The
>>>> communication protocol uses these ids to identify each device within the
>>>> power domain so that the control processor can do what is necessary to
>>>> enable that device.
>>>
>>> I think a minor detail here that Rob might be missing right now is,
>>> that the ti,sci-id is only controlling the PM runtime handling, and
>>> providing the ID per-device for this purpose only. AFAIK, it is not
>>> really connected to the power domain anymore as such, as we don't have
>>> power-domains / per device anymore as was the case in some earlier
>>> revision of this work.
>>
>> I think this gets to the heart of things. IMO The confusion arises
>> because we're throwing around the term "power domain" when there isn't
>> an actual hardware power domain here.
>
> I thought there was 1.
>
>> Unfortunately, the genpd bindings have used the terminology power-domain
>> when in fact genpd is more generic than that and can be used not just
>> for hardware power domains, but for arbitrary grouping of devices that
>> have common PM properties. That's why genpd actually stands for generic
>> PM domain, not power domain. Unfortunately, the bindings have grown
>> primarily out of the usage for hardware power domains.
>
> Now it makes some sense.
>
> So the question is does this PM domain grouping need to be described
> in DT or not, and if so what does that look like?
Yes, it's needed and already being done. For example, we have clock
domains for several Renesas platforms.
>
> We could continue to use the power domain binding (maybe we already
> are and that ship has sailed). I'm not totally against the idea even
> if there is no power domain, but I'm not sold on it either. If we do
> go this route, then I still say the id should be a cell in the
> power-domain phandle.
>
> Another option is create something new either common or TI SCI
> specific. It could be just a table of ids and phandles in the SCI
> node. I'm much more comfortable with an isolated property in one node
> than something scattered throughout the DT.
To me, this seems like the best possible solution.
However, perhaps we should also consider the SCPI Generic power domain
(drivers/firmware/scpi_pm_domain.c), because I believe it's closely
related.
To change the power state of a device, this PM domain calls
scpi_device_set|get_power_state() (drivers/firmware/arm_scpi.c), which
also needs a device id as a parameter. Very similar to our case with
the TI SCI domain.
Currently these SCPI device ids lacks corresponding DT bindings, so
the scpi_pm_domain tries to work around it by assigning ids
dynamically at genpd creation time.
That makes me wonder, whether we should think of something common/generic?
[...]
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 0/7] Add support for Video Data Order Adapter
From: Michael Tretter @ 2017-01-20 14:00 UTC (permalink / raw)
To: linux-media
Cc: Philipp Zabel, devicetree, Hans Verkuil, Mauro Carvalho Chehab,
kernel, Michael Tretter
Hello,
This is v4 of a patch series that adds support for the Video Data Order
Adapter (VDOA) that can be found on Freescale i.MX6. It converts the
macroblock tiled format produced by the CODA 960 video decoder to a
raster-ordered format for scanout.
Changes since v3:
- Patch 2/7: Add my copyright to vdoa copyright header
- Patch 2/7: Fix offset of chroma plane to be page-aligned
- Patch 6/7: Fix oops when releasing the coda driver by destroying vdoa
context after removing all buffers
- Patch 6/7: Fix missing vdoa disable when switching from tiled to linear
format
Changes since v2:
- Patch 1/7: Update commit message to include binding change; fix
spelling/style in binding documentation
Changes since v1:
- Dropped patch 8/9 of v1
- Patch 1/7: Add devicetree binding documentation for fsl-vdoa
- Patch 6/7: I merged patch 5/9 and patch 8/9 of v1 into a single patch
- Patch 6/7: Use dt compatible instead of a phandle to find VDOA device
- Patch 6/7: Always check VDOA availability even if disabled via module
parameter and do not print a message if VDOA cannot be found
- Patch 6/7: Do not change the CODA context in coda_try_fmt()
- Patch 6/7: Allocate an additional internal frame if the VDOA is in use
Michael Tretter (3):
[media] coda: fix frame index to returned error
[media] coda: use VDOA for un-tiling custom macroblock format
[media] coda: support YUYV output if VDOA is used
Philipp Zabel (4):
[media] dt-bindings: Add a binding for Video Data Order Adapter
[media] coda: add i.MX6 VDOA driver
[media] coda: correctly set capture compose rectangle
[media] coda: add debug output about tiling
.../devicetree/bindings/media/fsl-vdoa.txt | 21 ++
arch/arm/boot/dts/imx6qdl.dtsi | 2 +
drivers/media/platform/Kconfig | 3 +
drivers/media/platform/coda/Makefile | 1 +
drivers/media/platform/coda/coda-bit.c | 93 ++++--
drivers/media/platform/coda/coda-common.c | 175 ++++++++++-
drivers/media/platform/coda/coda.h | 3 +
drivers/media/platform/coda/imx-vdoa.c | 338 +++++++++++++++++++++
drivers/media/platform/coda/imx-vdoa.h | 58 ++++
9 files changed, 652 insertions(+), 42 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt
create mode 100644 drivers/media/platform/coda/imx-vdoa.c
create mode 100644 drivers/media/platform/coda/imx-vdoa.h
--
2.11.0
^ permalink raw reply
* [PATCH v4 1/7] [media] dt-bindings: Add a binding for Video Data Order Adapter
From: Michael Tretter @ 2017-01-20 14:00 UTC (permalink / raw)
To: linux-media-u79uwXL29TY76Z2rM5mHXA
Cc: Philipp Zabel, devicetree-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil,
Mauro Carvalho Chehab, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Philipp Zabel, Michael Tretter
In-Reply-To: <20170120140025.3338-1-m.tretter-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
From: Philipp Zabel <philipp.zabel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Add a DT binding documentation for the Video Data Order Adapter (VDOA)
of the Freescale i.MX6 SoC.
Also, add the compatible property and correct clock to the device tree
to match the documentation.
Signed-off-by: Philipp Zabel <philipp.zabel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Michael Tretter <m.tretter-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/media/fsl-vdoa.txt | 21 +++++++++++++++++++++
arch/arm/boot/dts/imx6qdl.dtsi | 2 ++
2 files changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt
diff --git a/Documentation/devicetree/bindings/media/fsl-vdoa.txt b/Documentation/devicetree/bindings/media/fsl-vdoa.txt
new file mode 100644
index 000000000000..6c5628530bb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl-vdoa.txt
@@ -0,0 +1,21 @@
+Freescale Video Data Order Adapter
+==================================
+
+The Video Data Order Adapter (VDOA) is present on the i.MX6q. Its sole purpose
+is to reorder video data from the macroblock tiled order produced by the CODA
+960 VPU to the conventional raster-scan order for scanout.
+
+Required properties:
+- compatible: must be "fsl,imx6q-vdoa"
+- reg: the register base and size for the device registers
+- interrupts: the VDOA interrupt
+- clocks: the vdoa clock
+
+Example:
+
+vdoa@21e4000 {
+ compatible = "fsl,imx6q-vdoa";
+ reg = <0x021e4000 0x4000>;
+ interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_VDOA>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 89b834f3fa17..a227e8be5378 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1158,8 +1158,10 @@
};
vdoa@021e4000 {
+ compatible = "fsl,imx6q-vdoa";
reg = <0x021e4000 0x4000>;
interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_VDOA>;
};
uart2: serial@021e8000 {
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 2/7] [media] coda: add i.MX6 VDOA driver
From: Michael Tretter @ 2017-01-20 14:00 UTC (permalink / raw)
To: linux-media
Cc: Philipp Zabel, devicetree, Hans Verkuil, Mauro Carvalho Chehab,
kernel, Philipp Zabel, Michael Tretter
In-Reply-To: <20170120140025.3338-1-m.tretter@pengutronix.de>
From: Philipp Zabel <philipp.zabel@gmail.com>
The i.MX6 Video Data Order Adapter's (VDOA) sole purpose is to convert
from a custom macroblock tiled format produced by the CODA960 decoder
into linear formats that can be used for scanout.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
---
drivers/media/platform/Kconfig | 3 +
drivers/media/platform/coda/Makefile | 1 +
drivers/media/platform/coda/imx-vdoa.c | 338 +++++++++++++++++++++++++++++++++
drivers/media/platform/coda/imx-vdoa.h | 58 ++++++
4 files changed, 400 insertions(+)
create mode 100644 drivers/media/platform/coda/imx-vdoa.c
create mode 100644 drivers/media/platform/coda/imx-vdoa.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index d944421e392d..595652613db9 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -162,6 +162,9 @@ config VIDEO_CODA
Coda is a range of video codec IPs that supports
H.264, MPEG-4, and other video formats.
+config VIDEO_IMX_VDOA
+ def_tristate VIDEO_CODA if SOC_IMX6Q || COMPILE_TEST
+
config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/coda/Makefile b/drivers/media/platform/coda/Makefile
index 9342ac57b230..858284328af9 100644
--- a/drivers/media/platform/coda/Makefile
+++ b/drivers/media/platform/coda/Makefile
@@ -3,3 +3,4 @@ ccflags-y += -I$(src)
coda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o coda-jpeg.o
obj-$(CONFIG_VIDEO_CODA) += coda.o
+obj-$(CONFIG_VIDEO_IMX_VDOA) += imx-vdoa.o
diff --git a/drivers/media/platform/coda/imx-vdoa.c b/drivers/media/platform/coda/imx-vdoa.c
new file mode 100644
index 000000000000..f61baf7dcbc1
--- /dev/null
+++ b/drivers/media/platform/coda/imx-vdoa.c
@@ -0,0 +1,338 @@
+/*
+ * i.MX6 Video Data Order Adapter (VDOA)
+ *
+ * Copyright (C) 2014 Philipp Zabel
+ * Copyright (C) 2016 Pengutronix, Michael Tretter <kernel@pengutronix.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/dma-mapping.h>
+#include <linux/platform_device.h>
+#include <linux/videodev2.h>
+#include <linux/slab.h>
+
+#include "imx-vdoa.h"
+
+#define VDOA_NAME "imx-vdoa"
+
+#define VDOAC 0x00
+#define VDOASRR 0x04
+#define VDOAIE 0x08
+#define VDOAIST 0x0c
+#define VDOAFP 0x10
+#define VDOAIEBA00 0x14
+#define VDOAIEBA01 0x18
+#define VDOAIEBA02 0x1c
+#define VDOAIEBA10 0x20
+#define VDOAIEBA11 0x24
+#define VDOAIEBA12 0x28
+#define VDOASL 0x2c
+#define VDOAIUBO 0x30
+#define VDOAVEBA0 0x34
+#define VDOAVEBA1 0x38
+#define VDOAVEBA2 0x3c
+#define VDOAVUBO 0x40
+#define VDOASR 0x44
+
+#define VDOAC_ISEL BIT(6)
+#define VDOAC_PFS BIT(5)
+#define VDOAC_SO BIT(4)
+#define VDOAC_SYNC BIT(3)
+#define VDOAC_NF BIT(2)
+#define VDOAC_BNDM_MASK 0x3
+#define VDOAC_BAND_HEIGHT_8 0x0
+#define VDOAC_BAND_HEIGHT_16 0x1
+#define VDOAC_BAND_HEIGHT_32 0x2
+
+#define VDOASRR_START BIT(1)
+#define VDOASRR_SWRST BIT(0)
+
+#define VDOAIE_EITERR BIT(1)
+#define VDOAIE_EIEOT BIT(0)
+
+#define VDOAIST_TERR BIT(1)
+#define VDOAIST_EOT BIT(0)
+
+#define VDOAFP_FH_MASK (0x1fff << 16)
+#define VDOAFP_FW_MASK (0x3fff)
+
+#define VDOASL_VSLY_MASK (0x3fff << 16)
+#define VDOASL_ISLY_MASK (0x7fff)
+
+#define VDOASR_ERRW BIT(4)
+#define VDOASR_EOB BIT(3)
+#define VDOASR_CURRENT_FRAME (0x3 << 1)
+#define VDOASR_CURRENT_BUFFER BIT(1)
+
+enum {
+ V4L2_M2M_SRC = 0,
+ V4L2_M2M_DST = 1,
+};
+
+struct vdoa_data {
+ struct vdoa_ctx *curr_ctx;
+ struct device *dev;
+ struct clk *vdoa_clk;
+ void __iomem *regs;
+ int irq;
+};
+
+struct vdoa_q_data {
+ unsigned int width;
+ unsigned int height;
+ unsigned int bytesperline;
+ unsigned int sizeimage;
+ u32 pixelformat;
+};
+
+struct vdoa_ctx {
+ struct vdoa_data *vdoa;
+ struct completion completion;
+ struct vdoa_q_data q_data[2];
+};
+
+static irqreturn_t vdoa_irq_handler(int irq, void *data)
+{
+ struct vdoa_data *vdoa = data;
+ struct vdoa_ctx *curr_ctx;
+ u32 val;
+
+ /* Disable interrupts */
+ writel(0, vdoa->regs + VDOAIE);
+
+ curr_ctx = vdoa->curr_ctx;
+ if (!curr_ctx) {
+ dev_dbg(vdoa->dev,
+ "Instance released before the end of transaction\n");
+ return IRQ_HANDLED;
+ }
+
+ val = readl(vdoa->regs + VDOAIST);
+ writel(val, vdoa->regs + VDOAIST);
+ if (val & VDOAIST_TERR) {
+ val = readl(vdoa->regs + VDOASR) & VDOASR_ERRW;
+ dev_err(vdoa->dev, "AXI %s error\n", val ? "write" : "read");
+ } else if (!(val & VDOAIST_EOT)) {
+ dev_warn(vdoa->dev, "Spurious interrupt\n");
+ }
+ complete(&curr_ctx->completion);
+
+ return IRQ_HANDLED;
+}
+
+void vdoa_device_run(struct vdoa_ctx *ctx, dma_addr_t dst, dma_addr_t src)
+{
+ struct vdoa_q_data *src_q_data, *dst_q_data;
+ struct vdoa_data *vdoa = ctx->vdoa;
+ u32 val;
+
+ vdoa->curr_ctx = ctx;
+
+ src_q_data = &ctx->q_data[V4L2_M2M_SRC];
+ dst_q_data = &ctx->q_data[V4L2_M2M_DST];
+
+ /* Progressive, no sync, 1 frame per run */
+ if (dst_q_data->pixelformat == V4L2_PIX_FMT_YUYV)
+ val = VDOAC_PFS;
+ else
+ val = 0;
+ writel(val, vdoa->regs + VDOAC);
+
+ writel(dst_q_data->height << 16 | dst_q_data->width,
+ vdoa->regs + VDOAFP);
+
+ val = dst;
+ writel(val, vdoa->regs + VDOAIEBA00);
+
+ writel(src_q_data->bytesperline << 16 | dst_q_data->bytesperline,
+ vdoa->regs + VDOASL);
+
+ if (dst_q_data->pixelformat == V4L2_PIX_FMT_NV12 ||
+ dst_q_data->pixelformat == V4L2_PIX_FMT_NV21)
+ val = dst_q_data->bytesperline * dst_q_data->height;
+ else
+ val = 0;
+ writel(val, vdoa->regs + VDOAIUBO);
+
+ val = src;
+ writel(val, vdoa->regs + VDOAVEBA0);
+ val = round_up(src_q_data->bytesperline * src_q_data->height, 4096);
+ writel(val, vdoa->regs + VDOAVUBO);
+
+ /* Enable interrupts and start transfer */
+ writel(VDOAIE_EITERR | VDOAIE_EIEOT, vdoa->regs + VDOAIE);
+ writel(VDOASRR_START, vdoa->regs + VDOASRR);
+}
+EXPORT_SYMBOL(vdoa_device_run);
+
+int vdoa_wait_for_completion(struct vdoa_ctx *ctx)
+{
+ struct vdoa_data *vdoa = ctx->vdoa;
+
+ if (!wait_for_completion_timeout(&ctx->completion,
+ msecs_to_jiffies(300))) {
+ dev_err(vdoa->dev,
+ "Timeout waiting for transfer result\n");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(vdoa_wait_for_completion);
+
+struct vdoa_ctx *vdoa_context_create(struct vdoa_data *vdoa)
+{
+ struct vdoa_ctx *ctx;
+ int err;
+
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return NULL;
+
+ err = clk_prepare_enable(vdoa->vdoa_clk);
+ if (err) {
+ kfree(ctx);
+ return NULL;
+ }
+
+ init_completion(&ctx->completion);
+ ctx->vdoa = vdoa;
+
+ return ctx;
+}
+EXPORT_SYMBOL(vdoa_context_create);
+
+void vdoa_context_destroy(struct vdoa_ctx *ctx)
+{
+ struct vdoa_data *vdoa = ctx->vdoa;
+
+ clk_disable_unprepare(vdoa->vdoa_clk);
+ kfree(ctx);
+}
+EXPORT_SYMBOL(vdoa_context_destroy);
+
+int vdoa_context_configure(struct vdoa_ctx *ctx,
+ unsigned int width, unsigned int height,
+ u32 pixelformat)
+{
+ struct vdoa_q_data *src_q_data;
+ struct vdoa_q_data *dst_q_data;
+
+ if (width < 16 || width > 8192 || width % 16 != 0 ||
+ height < 16 || height > 4096 || height % 16 != 0)
+ return -EINVAL;
+
+ if (pixelformat != V4L2_PIX_FMT_YUYV &&
+ pixelformat != V4L2_PIX_FMT_NV12)
+ return -EINVAL;
+
+ /* If no context is passed, only check if the format is valid */
+ if (!ctx)
+ return 0;
+
+ src_q_data = &ctx->q_data[V4L2_M2M_SRC];
+ dst_q_data = &ctx->q_data[V4L2_M2M_DST];
+
+ src_q_data->width = width;
+ src_q_data->height = height;
+ src_q_data->bytesperline = width;
+ src_q_data->sizeimage =
+ round_up(src_q_data->bytesperline * height, 4096) +
+ src_q_data->bytesperline * height / 2;
+
+ dst_q_data->width = width;
+ dst_q_data->height = height;
+ dst_q_data->pixelformat = pixelformat;
+ switch (pixelformat) {
+ case V4L2_PIX_FMT_YUYV:
+ dst_q_data->bytesperline = width * 2;
+ dst_q_data->sizeimage = dst_q_data->bytesperline * height;
+ break;
+ case V4L2_PIX_FMT_NV12:
+ default:
+ dst_q_data->bytesperline = width;
+ dst_q_data->sizeimage =
+ dst_q_data->bytesperline * height * 3 / 2;
+ break;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(vdoa_context_configure);
+
+static int vdoa_probe(struct platform_device *pdev)
+{
+ struct vdoa_data *vdoa;
+ struct resource *res;
+
+ dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+
+ vdoa = devm_kzalloc(&pdev->dev, sizeof(*vdoa), GFP_KERNEL);
+ if (!vdoa)
+ return -ENOMEM;
+
+ vdoa->dev = &pdev->dev;
+
+ vdoa->vdoa_clk = devm_clk_get(vdoa->dev, NULL);
+ if (IS_ERR(vdoa->vdoa_clk)) {
+ dev_err(vdoa->dev, "Failed to get clock\n");
+ return PTR_ERR(vdoa->vdoa_clk);
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ vdoa->regs = devm_ioremap_resource(vdoa->dev, res);
+ if (IS_ERR(vdoa->regs))
+ return PTR_ERR(vdoa->regs);
+
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ vdoa->irq = devm_request_threaded_irq(&pdev->dev, res->start, NULL,
+ vdoa_irq_handler, IRQF_ONESHOT,
+ "vdoa", vdoa);
+ if (vdoa->irq < 0) {
+ dev_err(vdoa->dev, "Failed to get irq\n");
+ return vdoa->irq;
+ }
+
+ platform_set_drvdata(pdev, vdoa);
+
+ return 0;
+}
+
+static int vdoa_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct of_device_id vdoa_dt_ids[] = {
+ { .compatible = "fsl,imx6q-vdoa" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, vdoa_dt_ids);
+
+static struct platform_driver vdoa_driver = {
+ .probe = vdoa_probe,
+ .remove = vdoa_remove,
+ .driver = {
+ .name = VDOA_NAME,
+ .of_match_table = vdoa_dt_ids,
+ },
+};
+
+module_platform_driver(vdoa_driver);
+
+MODULE_DESCRIPTION("Video Data Order Adapter");
+MODULE_AUTHOR("Philipp Zabel <philipp.zabel@gmail.com>");
+MODULE_ALIAS("platform:imx-vdoa");
+MODULE_LICENSE("GPL");
diff --git a/drivers/media/platform/coda/imx-vdoa.h b/drivers/media/platform/coda/imx-vdoa.h
new file mode 100644
index 000000000000..967576b2a06a
--- /dev/null
+++ b/drivers/media/platform/coda/imx-vdoa.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2016 Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef IMX_VDOA_H
+#define IMX_VDOA_H
+
+struct vdoa_data;
+struct vdoa_ctx;
+
+#if (defined CONFIG_VIDEO_IMX_VDOA || defined CONFIG_VIDEO_IMX_VDOA_MODULE)
+
+struct vdoa_ctx *vdoa_context_create(struct vdoa_data *vdoa);
+int vdoa_context_configure(struct vdoa_ctx *ctx,
+ unsigned int width, unsigned int height,
+ u32 pixelformat);
+void vdoa_context_destroy(struct vdoa_ctx *ctx);
+
+void vdoa_device_run(struct vdoa_ctx *ctx, dma_addr_t dst, dma_addr_t src);
+int vdoa_wait_for_completion(struct vdoa_ctx *ctx);
+
+#else
+
+static inline struct vdoa_ctx *vdoa_context_create(struct vdoa_data *vdoa)
+{
+ return NULL;
+}
+
+static inline int vdoa_context_configure(struct vdoa_ctx *ctx,
+ unsigned int width,
+ unsigned int height,
+ u32 pixelformat)
+{
+ return 0;
+}
+
+static inline void vdoa_context_destroy(struct vdoa_ctx *ctx) { };
+
+static inline void vdoa_device_run(struct vdoa_ctx *ctx,
+ dma_addr_t dst, dma_addr_t src) { };
+
+static inline int vdoa_wait_for_completion(struct vdoa_ctx *ctx)
+{
+ return 0;
+};
+
+#endif
+
+#endif /* IMX_VDOA_H */
--
2.11.0
^ permalink raw reply related
* [PATCH v4 3/7] [media] coda: correctly set capture compose rectangle
From: Michael Tretter @ 2017-01-20 14:00 UTC (permalink / raw)
To: linux-media-u79uwXL29TY76Z2rM5mHXA
Cc: Philipp Zabel, devicetree-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil,
Mauro Carvalho Chehab, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Michael Tretter
In-Reply-To: <20170120140025.3338-1-m.tretter-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
From: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Correctly store the rectangle of valid video data in the destination
q_data before rounding up to macroblock size. This fixes the output
of VIDIOC_G_SELECTION for the capture side compose rectangle.
Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Signed-off-by: Michael Tretter <m.tretter-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
drivers/media/platform/coda/coda-common.c | 37 ++++++++++++++++++++++++-------
1 file changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c
index 9e6bdafa16f5..fa3ed74af116 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -566,7 +566,8 @@ static int coda_try_fmt_vid_out(struct file *file, void *priv,
return coda_try_fmt(ctx, codec, f);
}
-static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f)
+static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f,
+ struct v4l2_rect *r)
{
struct coda_q_data *q_data;
struct vb2_queue *vq;
@@ -589,10 +590,14 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f)
q_data->height = f->fmt.pix.height;
q_data->bytesperline = f->fmt.pix.bytesperline;
q_data->sizeimage = f->fmt.pix.sizeimage;
- q_data->rect.left = 0;
- q_data->rect.top = 0;
- q_data->rect.width = f->fmt.pix.width;
- q_data->rect.height = f->fmt.pix.height;
+ if (r) {
+ q_data->rect = *r;
+ } else {
+ q_data->rect.left = 0;
+ q_data->rect.top = 0;
+ q_data->rect.width = f->fmt.pix.width;
+ q_data->rect.height = f->fmt.pix.height;
+ }
switch (f->fmt.pix.pixelformat) {
case V4L2_PIX_FMT_NV12:
@@ -621,27 +626,37 @@ static int coda_s_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_format *f)
{
struct coda_ctx *ctx = fh_to_ctx(priv);
+ struct coda_q_data *q_data_src;
+ struct v4l2_rect r;
int ret;
ret = coda_try_fmt_vid_cap(file, priv, f);
if (ret)
return ret;
- return coda_s_fmt(ctx, f);
+ q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+ r.left = 0;
+ r.top = 0;
+ r.width = q_data_src->width;
+ r.height = q_data_src->height;
+
+ return coda_s_fmt(ctx, f, &r);
}
static int coda_s_fmt_vid_out(struct file *file, void *priv,
struct v4l2_format *f)
{
struct coda_ctx *ctx = fh_to_ctx(priv);
+ struct coda_q_data *q_data_src;
struct v4l2_format f_cap;
+ struct v4l2_rect r;
int ret;
ret = coda_try_fmt_vid_out(file, priv, f);
if (ret)
return ret;
- ret = coda_s_fmt(ctx, f);
+ ret = coda_s_fmt(ctx, f, NULL);
if (ret)
return ret;
@@ -657,7 +672,13 @@ static int coda_s_fmt_vid_out(struct file *file, void *priv,
if (ret)
return ret;
- return coda_s_fmt(ctx, &f_cap);
+ q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+ r.left = 0;
+ r.top = 0;
+ r.width = q_data_src->width;
+ r.height = q_data_src->height;
+
+ return coda_s_fmt(ctx, &f_cap, &r);
}
static int coda_reqbufs(struct file *file, void *priv,
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 4/7] [media] coda: add debug output about tiling
From: Michael Tretter @ 2017-01-20 14:00 UTC (permalink / raw)
To: linux-media
Cc: Philipp Zabel, devicetree, Hans Verkuil, Mauro Carvalho Chehab,
kernel, Michael Tretter
In-Reply-To: <20170120140025.3338-1-m.tretter@pengutronix.de>
From: Philipp Zabel <p.zabel@pengutronix.de>
In order to make the VDOA work correctly, the CODA must produce frames
in tiled format. Print this information in the debug output.
Also print the color format in fourcc instead of the numeric value.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
---
drivers/media/platform/coda/coda-common.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c
index fa3ed74af116..b23fe0f0fb56 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -616,8 +616,10 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f,
}
v4l2_dbg(1, coda_debug, &ctx->dev->v4l2_dev,
- "Setting format for type %d, wxh: %dx%d, fmt: %d\n",
- f->type, q_data->width, q_data->height, q_data->fourcc);
+ "Setting format for type %d, wxh: %dx%d, fmt: %4.4s %c\n",
+ f->type, q_data->width, q_data->height,
+ (char *)&q_data->fourcc,
+ (ctx->tiled_map_type == GDI_LINEAR_FRAME_MAP) ? 'L' : 'T');
return 0;
}
--
2.11.0
^ permalink raw reply related
* [PATCH v4 5/7] [media] coda: fix frame index to returned error
From: Michael Tretter @ 2017-01-20 14:00 UTC (permalink / raw)
To: linux-media-u79uwXL29TY76Z2rM5mHXA
Cc: Philipp Zabel, devicetree-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil,
Mauro Carvalho Chehab, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Michael Tretter
In-Reply-To: <20170120140025.3338-1-m.tretter-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
display_idx refers to the frame that will be returned in the next round.
The currently processed frame is ctx->display_idx and errors should be
reported for this frame.
Signed-off-by: Michael Tretter <m.tretter-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
drivers/media/platform/coda/coda-bit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/coda/coda-bit.c b/drivers/media/platform/coda/coda-bit.c
index b6625047250d..309eb4eb5ad1 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -2057,7 +2057,7 @@ static void coda_finish_decode(struct coda_ctx *ctx)
}
vb2_set_plane_payload(&dst_buf->vb2_buf, 0, payload);
- coda_m2m_buf_done(ctx, dst_buf, ctx->frame_errors[display_idx] ?
+ coda_m2m_buf_done(ctx, dst_buf, ctx->frame_errors[ctx->display_idx] ?
VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
v4l2_dbg(1, coda_debug, &dev->v4l2_dev,
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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