[PATCH 0/4] Add missing device nodes for Olimex Teres-I

[PATCH 0/4] Add missing device nodes for Olimex Teres-I

[Torsten Duwe]

Hi all,

based on Maxime's sunxi-dt64-for-5.2, here is what I found so far
still missing in the device tree. Those bits and pieces have already
been submitted but were not yet applied. Currently I also have the
uart1 for bluetooth here, but I'm unsure about the bindings for the
in-kernel btuart.

	  Torsten

[PATCH 0/4] Add missing device nodes for Olimex Teres-I

[Torsten Duwe]

Hi all,

based on Maxime's sunxi-dt64-for-5.2, here is what I found so far
still missing in the device tree. Those bits and pieces have already
been submitted but were not yet applied. Currently I also have the
uart1 for bluetooth here, but I'm unsure about the bindings for the
in-kernel btuart.

	  Torsten

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/4] arm64: DTS: allwinner: a64: Add pinmux for RGB666 LCD

[Torsten Duwe]

From: Icenowy Zheng <icenowy@aosc.io>

Allwinner A64's TCON0 can output RGB666 LCD signal.

Add its pinmux.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---

originally: patchwork.kernel.org/patch/10814179

Almost trivial, and obviously correct.
I added the /omit-if-no-ref/.

---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 2abb335145a6..a8bbee84e7da 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -559,6 +559,16 @@
 				function = "i2c1";
 			};

+			/omit-if-no-ref/
+			lcd_rgb666_pins: lcd-rgb666 {
+				pins = "PD0", "PD1", "PD2", "PD3", "PD4",
+				       "PD5", "PD6", "PD7", "PD8", "PD9",
+				       "PD10", "PD11", "PD12", "PD13",
+				       "PD14", "PD15", "PD16", "PD17",
+				       "PD18", "PD19", "PD20", "PD21";
+				function = "lcd0";
+			};
+
 			mmc0_pins: mmc0-pins {
 				pins = "PF0", "PF1", "PF2", "PF3",
 				       "PF4", "PF5";

[PATCH 1/4] arm64: DTS: allwinner: a64: Add pinmux for RGB666 LCD

[Torsten Duwe]

From: Icenowy Zheng <icenowy@aosc.io>

Allwinner A64's TCON0 can output RGB666 LCD signal.

Add its pinmux.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---

originally: patchwork.kernel.org/patch/10814179

Almost trivial, and obviously correct.
I added the /omit-if-no-ref/.

---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 2abb335145a6..a8bbee84e7da 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -559,6 +559,16 @@
 				function = "i2c1";
 			};

+			/omit-if-no-ref/
+			lcd_rgb666_pins: lcd-rgb666 {
+				pins = "PD0", "PD1", "PD2", "PD3", "PD4",
+				       "PD5", "PD6", "PD7", "PD8", "PD9",
+				       "PD10", "PD11", "PD12", "PD13",
+				       "PD14", "PD15", "PD16", "PD17",
+				       "PD18", "PD19", "PD20", "PD21";
+				function = "lcd0";
+			};
+
 			mmc0_pins: mmc0-pins {
 				pins = "PF0", "PF1", "PF2", "PF3",
 				       "PF4", "PF5";

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/4] arm64: DTS: allwinner: a64: Add pinmux for RGB666 LCD

[Torsten Duwe]

From: Icenowy Zheng <icenowy@aosc.io>

Allwinner A64's TCON0 can output RGB666 LCD signal.

Add its pinmux.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---

originally: patchwork.kernel.org/patch/10814179

Almost trivial, and obviously correct.
I added the /omit-if-no-ref/.

---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 2abb335145a6..a8bbee84e7da 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -559,6 +559,16 @@
 				function = "i2c1";
 			};

+			/omit-if-no-ref/
+			lcd_rgb666_pins: lcd-rgb666 {
+				pins = "PD0", "PD1", "PD2", "PD3", "PD4",
+				       "PD5", "PD6", "PD7", "PD8", "PD9",
+				       "PD10", "PD11", "PD12", "PD13",
+				       "PD14", "PD15", "PD16", "PD17",
+				       "PD18", "PD19", "PD20", "PD21";
+				function = "lcd0";
+			};
+
 			mmc0_pins: mmc0-pins {
 				pins = "PF0", "PF1", "PF2", "PF3",
 				       "PF4", "PF5";

Re: [PATCH 1/4] arm64: DTS: allwinner: a64: Add pinmux for RGB666 LCD

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

On Tue, May 14, 2019 at 06:02:25PM +0200, Torsten Duwe wrote:
> From: Icenowy Zheng <icenowy@aosc.io>
>
> Allwinner A64's TCON0 can output RGB666 LCD signal.
>
> Add its pinmux.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
>
> originally: patchwork.kernel.org/patch/10814179
>
> Almost trivial, and obviously correct.
> I added the /omit-if-no-ref/.
>
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 2abb335145a6..a8bbee84e7da 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -559,6 +559,16 @@
>  				function = "i2c1";
>  			};
>
> +			/omit-if-no-ref/
> +			lcd_rgb666_pins: lcd-rgb666 {

This should have the -pins suffix

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 1/4] arm64: DTS: allwinner: a64: Add pinmux for RGB666 LCD

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1077 bytes --]

On Tue, May 14, 2019 at 06:02:25PM +0200, Torsten Duwe wrote:
> From: Icenowy Zheng <icenowy@aosc.io>
>
> Allwinner A64's TCON0 can output RGB666 LCD signal.
>
> Add its pinmux.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
>
> originally: patchwork.kernel.org/patch/10814179
>
> Almost trivial, and obviously correct.
> I added the /omit-if-no-ref/.
>
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 2abb335145a6..a8bbee84e7da 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -559,6 +559,16 @@
>  				function = "i2c1";
>  			};
>
> +			/omit-if-no-ref/
> +			lcd_rgb666_pins: lcd-rgb666 {

This should have the -pins suffix

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 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

[PATCH 2/4] dt-bindings: Add ANX6345 DP/eDP transmitter binding

[Torsten Duwe]

From: Icenowy Zheng <icenowy@aosc.io>

The ANX6345 is an ultra-low power DisplayPort/eDP transmitter designed
for portable devices.

Add a binding document for it.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---

originally: patchwork.kernel.org/patch/10814177

All I did is change the reset polarity, which is evidently active low;
according to the (terse) datasheet. It matches the polarity in the last
patch.

---
 .../bindings/display/bridge/anx6345.txt       | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/anx6345.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.txt b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
new file mode 100644
index 000000000000..e79a11348d11
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
@@ -0,0 +1,56 @@
+Analogix ANX6345 eDP Transmitter
+--------------------------------
+
+The ANX6345 is an ultra-low power Full-HD eDP transmitter designed for
+portable devices.
+
+Required properties:
+
+ - compatible		: "analogix,anx6345"
+ - reg			: I2C address of the device
+ - reset-gpios		: Which GPIO to use for reset
+
+Optional properties:
+
+ - dvdd12-supply	: Regulator for 1.2V digital core power.
+ - dvdd25-supply	: Regulator for 2.5V digital core power.
+ - Video ports for RGB input and eDP output using the DT bindings
+   defined in [1]
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+anx6345: anx6345@38 {
+	compatible = "analogix,anx6345";
+	reg = <0x38>;
+	reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+	dvdd25-supply = <&reg_dldo2>;
+	dvdd12-supply = <&reg_fldo1>;
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		anx6345_in: port@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+			anx6345_in_tcon0: endpoint@0 {
+				reg = <0>;
+				remote-endpoint = <&tcon0_out_anx6345>;
+			};
+		};
+
+		anx6345_out: port@1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+
+			anx6345_out_panel: endpoint@0 {
+				reg = <0>;
+				remote-endpoint = <&panel_in_edp>;
+			};
+		};
+	};
+};

[PATCH 2/4] dt-bindings: Add ANX6345 DP/eDP transmitter binding

[Torsten Duwe]

From: Icenowy Zheng <icenowy@aosc.io>

The ANX6345 is an ultra-low power DisplayPort/eDP transmitter designed
for portable devices.

Add a binding document for it.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---

originally: patchwork.kernel.org/patch/10814177

All I did is change the reset polarity, which is evidently active low;
according to the (terse) datasheet. It matches the polarity in the last
patch.

---
 .../bindings/display/bridge/anx6345.txt       | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/anx6345.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.txt b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
new file mode 100644
index 000000000000..e79a11348d11
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
@@ -0,0 +1,56 @@
+Analogix ANX6345 eDP Transmitter
+--------------------------------
+
+The ANX6345 is an ultra-low power Full-HD eDP transmitter designed for
+portable devices.
+
+Required properties:
+
+ - compatible		: "analogix,anx6345"
+ - reg			: I2C address of the device
+ - reset-gpios		: Which GPIO to use for reset
+
+Optional properties:
+
+ - dvdd12-supply	: Regulator for 1.2V digital core power.
+ - dvdd25-supply	: Regulator for 2.5V digital core power.
+ - Video ports for RGB input and eDP output using the DT bindings
+   defined in [1]
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+anx6345: anx6345@38 {
+	compatible = "analogix,anx6345";
+	reg = <0x38>;
+	reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+	dvdd25-supply = <&reg_dldo2>;
+	dvdd12-supply = <&reg_fldo1>;
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		anx6345_in: port@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+			anx6345_in_tcon0: endpoint@0 {
+				reg = <0>;
+				remote-endpoint = <&tcon0_out_anx6345>;
+			};
+		};
+
+		anx6345_out: port@1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+
+			anx6345_out_panel: endpoint@0 {
+				reg = <0>;
+				remote-endpoint = <&panel_in_edp>;
+			};
+		};
+	};
+};

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/4] arm64: DTS: allwinner: a64: Enable audio on Teres-I

[Torsten Duwe]

From: Harald Geyer <harald@ccbib.org>

The TERES-I has internal speakers (left, right), internal microphone
and a headset combo jack (headphones + mic).

The headphone lines are multiplexed with the debug console.
The headphone and mic detect lines of the A64 are connected properly,
but AFAIK currently unsupported by the driver.

Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---

originally: patchwork.kernel.org/patch/10792589

Removed the questionable issues, leaving the unchallenged parts.

---
 .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 53 +++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
index f9eede0a8bd3..d57049fbdaca 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
@@ -70,6 +70,25 @@
 		compatible = "mmc-pwrseq-simple";
 		reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
 	};
+
+	speaker_amp: audio-amplifier {
+		compatible = "simple-audio-amplifier";
+		enable-gpios = <&r_pio 0 12 GPIO_ACTIVE_HIGH>; /* PL12 */
+		sound-name-prefix = "Speaker Amp";
+	};
+};
+
+&codec {
+	status = "okay";
+};
+
+&codec_analog {
+	cpvdd-supply = <&reg_eldo1>;
+	status = "okay";
+};
+
+&dai {
+	status = "okay";
 };
 
 &ehci1 {
@@ -258,6 +286,29 @@
 	vcc-hdmi-supply = <&reg_dldo1>;
 };
 
+&sound {
+	simple-audio-card,aux-devs = <&codec_analog>, <&speaker_amp>;
+	simple-audio-card,widgets = "Headphone", "Headphone Jack",
+				    "Microphone", "Headset Microphone",
+				    "Microphone", "Internal Microphone",
+				    "Speaker", "Internal Speaker";
+	simple-audio-card,routing =
+			"Left DAC", "AIF1 Slot 0 Left",
+			"Right DAC", "AIF1 Slot 0 Right",
+			"AIF1 Slot 0 Left ADC", "Left ADC",
+			"AIF1 Slot 0 Right ADC", "Right ADC",
+			"Headphone Jack", "HP",
+			"Speaker Amp INL", "LINEOUT",
+			"Speaker Amp INR", "LINEOUT",
+			"Internal Speaker", "Speaker Amp OUTL",
+			"Internal Speaker", "Speaker Amp OUTR",
+			"Internal Microphone", "MBIAS",
+			"MIC1", "Internal Microphone",
+			"Headset Microphone", "HBIAS",
+			"MIC2", "Headset Microphone";
+	status = "okay";
+};
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pb_pins>;

[PATCH 3/4] arm64: DTS: allwinner: a64: Enable audio on Teres-I

[Torsten Duwe]

From: Harald Geyer <harald@ccbib.org>

The TERES-I has internal speakers (left, right), internal microphone
and a headset combo jack (headphones + mic).

The headphone lines are multiplexed with the debug console.
The headphone and mic detect lines of the A64 are connected properly,
but AFAIK currently unsupported by the driver.

Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---

originally: patchwork.kernel.org/patch/10792589

Removed the questionable issues, leaving the unchallenged parts.

---
 .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 53 +++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
index f9eede0a8bd3..d57049fbdaca 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
@@ -70,6 +70,25 @@
 		compatible = "mmc-pwrseq-simple";
 		reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
 	};
+
+	speaker_amp: audio-amplifier {
+		compatible = "simple-audio-amplifier";
+		enable-gpios = <&r_pio 0 12 GPIO_ACTIVE_HIGH>; /* PL12 */
+		sound-name-prefix = "Speaker Amp";
+	};
+};
+
+&codec {
+	status = "okay";
+};
+
+&codec_analog {
+	cpvdd-supply = <&reg_eldo1>;
+	status = "okay";
+};
+
+&dai {
+	status = "okay";
 };
 
 &ehci1 {
@@ -258,6 +286,29 @@
 	vcc-hdmi-supply = <&reg_dldo1>;
 };
 
+&sound {
+	simple-audio-card,aux-devs = <&codec_analog>, <&speaker_amp>;
+	simple-audio-card,widgets = "Headphone", "Headphone Jack",
+				    "Microphone", "Headset Microphone",
+				    "Microphone", "Internal Microphone",
+				    "Speaker", "Internal Speaker";
+	simple-audio-card,routing =
+			"Left DAC", "AIF1 Slot 0 Left",
+			"Right DAC", "AIF1 Slot 0 Right",
+			"AIF1 Slot 0 Left ADC", "Left ADC",
+			"AIF1 Slot 0 Right ADC", "Right ADC",
+			"Headphone Jack", "HP",
+			"Speaker Amp INL", "LINEOUT",
+			"Speaker Amp INR", "LINEOUT",
+			"Internal Speaker", "Speaker Amp OUTL",
+			"Internal Speaker", "Speaker Amp OUTR",
+			"Internal Microphone", "MBIAS",
+			"MIC1", "Internal Microphone",
+			"Headset Microphone", "HBIAS",
+			"MIC2", "Headset Microphone";
+	status = "okay";
+};
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pb_pins>;

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Torsten Duwe]

From: Icenowy Zheng <icenowy@aosc.io>

TERES-I has an ANX6345 bridge connected to the RGB666 LCD output, and
the I2C controlling signals are connected to I2C0 bus.

Enable it in the device tree.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---

originally: patchwork.kernel.org/patch/10646867

Changed the reset polarity, which is active low,
according to the (terse) datasheet, Teres-I and pinebook schematics,
and the confusing parts of the linux driver code (not yet included here).
Active low -> no more confusion.

---
 .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 40 +++++++++++++++++--
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
index c455b24dd079..bc1d0d6c0672 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
@@ -72,20 +72,38 @@
 	};
 };
 
+&de {
+	status = "okay";
+};
+
 &ehci1 {
 	status = "okay";
 };
 
 
-/* The ANX6345 eDP-bridge is on i2c0. There is no linux (mainline)
- * driver for this chip at the moment, the bootloader initializes it.
- * However it can be accessed with the i2c-dev driver from user space.
- */
 &i2c0 {
 	clock-frequency = <100000>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&i2c0_pins>;
 	status = "okay";
+
+	anx6345: anx6345@38 {
+		compatible = "analogix,anx6345";
+		reg = <0x38>;
+		reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+		dvdd25-supply = <&reg_dldo2>;
+		dvdd12-supply = <&reg_dldo3>;
+
+		port {
+			anx6345_in: endpoint {
+				remote-endpoint = <&tcon0_out_anx6345>;
+			};
+		};
+	};
+};
+
+&mixer0 {
+	status = "okay";
 };
 
 &mmc0 {
@@ -258,6 +276,20 @@
 	vcc-hdmi-supply = <&reg_dldo1>;
 };
 
+&tcon0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&lcd_rgb666_pins>;
+
+	status = "okay";
+};
+
+&tcon0_out {
+	tcon0_out_anx6345: endpoint@0 {
+		reg = <0>;
+		remote-endpoint = <&anx6345_in>;
+	};
+};
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pb_pins>;

[PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Torsten Duwe]

From: Icenowy Zheng <icenowy@aosc.io>

TERES-I has an ANX6345 bridge connected to the RGB666 LCD output, and
the I2C controlling signals are connected to I2C0 bus.

Enable it in the device tree.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---

originally: patchwork.kernel.org/patch/10646867

Changed the reset polarity, which is active low,
according to the (terse) datasheet, Teres-I and pinebook schematics,
and the confusing parts of the linux driver code (not yet included here).
Active low -> no more confusion.

---
 .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 40 +++++++++++++++++--
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
index c455b24dd079..bc1d0d6c0672 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
@@ -72,20 +72,38 @@
 	};
 };
 
+&de {
+	status = "okay";
+};
+
 &ehci1 {
 	status = "okay";
 };
 
 
-/* The ANX6345 eDP-bridge is on i2c0. There is no linux (mainline)
- * driver for this chip at the moment, the bootloader initializes it.
- * However it can be accessed with the i2c-dev driver from user space.
- */
 &i2c0 {
 	clock-frequency = <100000>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&i2c0_pins>;
 	status = "okay";
+
+	anx6345: anx6345@38 {
+		compatible = "analogix,anx6345";
+		reg = <0x38>;
+		reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+		dvdd25-supply = <&reg_dldo2>;
+		dvdd12-supply = <&reg_dldo3>;
+
+		port {
+			anx6345_in: endpoint {
+				remote-endpoint = <&tcon0_out_anx6345>;
+			};
+		};
+	};
+};
+
+&mixer0 {
+	status = "okay";
 };
 
 &mmc0 {
@@ -258,6 +276,20 @@
 	vcc-hdmi-supply = <&reg_dldo1>;
 };
 
+&tcon0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&lcd_rgb666_pins>;
+
+	status = "okay";
+};
+
+&tcon0_out {
+	tcon0_out_anx6345: endpoint@0 {
+		reg = <0>;
+		remote-endpoint = <&anx6345_in>;
+	};
+};
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pb_pins>;

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Vasily Khoruzhick]

On Tue, May 14, 2019 at 9:03 AM Torsten Duwe <duwe@lst.de> wrote:
>
> From: Icenowy Zheng <icenowy@aosc.io>
>
> TERES-I has an ANX6345 bridge connected to the RGB666 LCD output, and
> the I2C controlling signals are connected to I2C0 bus.
>
> Enable it in the device tree.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
>
> originally: patchwork.kernel.org/patch/10646867
>
> Changed the reset polarity, which is active low,
> according to the (terse) datasheet, Teres-I and pinebook schematics,
> and the confusing parts of the linux driver code (not yet included here).
> Active low -> no more confusion.
>
> ---
>  .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 40 +++++++++++++++++--
>  1 file changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> index c455b24dd079..bc1d0d6c0672 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> @@ -72,20 +72,38 @@
>         };
>  };
>
> +&de {
> +       status = "okay";
> +};
> +
>  &ehci1 {
>         status = "okay";
>  };
>
>
> -/* The ANX6345 eDP-bridge is on i2c0. There is no linux (mainline)
> - * driver for this chip at the moment, the bootloader initializes it.
> - * However it can be accessed with the i2c-dev driver from user space.
> - */
>  &i2c0 {
>         clock-frequency = <100000>;
>         pinctrl-names = "default";
>         pinctrl-0 = <&i2c0_pins>;
>         status = "okay";
> +
> +       anx6345: anx6345@38 {
> +               compatible = "analogix,anx6345";
> +               reg = <0x38>;
> +               reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
> +               dvdd25-supply = <&reg_dldo2>;
> +               dvdd12-supply = <&reg_dldo3>;
> +
> +               port {
> +                       anx6345_in: endpoint {
> +                               remote-endpoint = <&tcon0_out_anx6345>;
> +                       };
> +               };

It doesn't comply with bindings document. You need to add out endpoint
as well, and to do so you need to add bindings for eDP connector first
and then implement panel driver.
See Rob's suggestions here: http://patchwork.ozlabs.org/patch/1042593/

> +       };
> +};
> +
> +&mixer0 {
> +       status = "okay";
>  };
>
>  &mmc0 {
> @@ -258,6 +276,20 @@
>         vcc-hdmi-supply = <&reg_dldo1>;
>  };
>
> +&tcon0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&lcd_rgb666_pins>;
> +
> +       status = "okay";
> +};
> +
> +&tcon0_out {
> +       tcon0_out_anx6345: endpoint@0 {
> +               reg = <0>;
> +               remote-endpoint = <&anx6345_in>;
> +       };
> +};
> +
>  &uart0 {
>         pinctrl-names = "default";
>         pinctrl-0 = <&uart0_pb_pins>;

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Vasily Khoruzhick]

On Tue, May 14, 2019 at 9:03 AM Torsten Duwe <duwe@lst.de> wrote:
>
> From: Icenowy Zheng <icenowy@aosc.io>
>
> TERES-I has an ANX6345 bridge connected to the RGB666 LCD output, and
> the I2C controlling signals are connected to I2C0 bus.
>
> Enable it in the device tree.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
>
> originally: patchwork.kernel.org/patch/10646867
>
> Changed the reset polarity, which is active low,
> according to the (terse) datasheet, Teres-I and pinebook schematics,
> and the confusing parts of the linux driver code (not yet included here).
> Active low -> no more confusion.
>
> ---
>  .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 40 +++++++++++++++++--
>  1 file changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> index c455b24dd079..bc1d0d6c0672 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> @@ -72,20 +72,38 @@
>         };
>  };
>
> +&de {
> +       status = "okay";
> +};
> +
>  &ehci1 {
>         status = "okay";
>  };
>
>
> -/* The ANX6345 eDP-bridge is on i2c0. There is no linux (mainline)
> - * driver for this chip at the moment, the bootloader initializes it.
> - * However it can be accessed with the i2c-dev driver from user space.
> - */
>  &i2c0 {
>         clock-frequency = <100000>;
>         pinctrl-names = "default";
>         pinctrl-0 = <&i2c0_pins>;
>         status = "okay";
> +
> +       anx6345: anx6345@38 {
> +               compatible = "analogix,anx6345";
> +               reg = <0x38>;
> +               reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
> +               dvdd25-supply = <&reg_dldo2>;
> +               dvdd12-supply = <&reg_dldo3>;
> +
> +               port {
> +                       anx6345_in: endpoint {
> +                               remote-endpoint = <&tcon0_out_anx6345>;
> +                       };
> +               };

It doesn't comply with bindings document. You need to add out endpoint
as well, and to do so you need to add bindings for eDP connector first
and then implement panel driver.
See Rob's suggestions here: http://patchwork.ozlabs.org/patch/1042593/

> +       };
> +};
> +
> +&mixer0 {
> +       status = "okay";
>  };
>
>  &mmc0 {
> @@ -258,6 +276,20 @@
>         vcc-hdmi-supply = <&reg_dldo1>;
>  };
>
> +&tcon0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&lcd_rgb666_pins>;
> +
> +       status = "okay";
> +};
> +
> +&tcon0_out {
> +       tcon0_out_anx6345: endpoint@0 {
> +               reg = <0>;
> +               remote-endpoint = <&anx6345_in>;
> +       };
> +};
> +
>  &uart0 {
>         pinctrl-names = "default";
>         pinctrl-0 = <&uart0_pb_pins>;

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Vasily Khoruzhick]

On Tue, May 14, 2019 at 9:03 AM Torsten Duwe <duwe@lst.de> wrote:
>
> From: Icenowy Zheng <icenowy@aosc.io>
>
> TERES-I has an ANX6345 bridge connected to the RGB666 LCD output, and
> the I2C controlling signals are connected to I2C0 bus.
>
> Enable it in the device tree.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
>
> originally: patchwork.kernel.org/patch/10646867
>
> Changed the reset polarity, which is active low,
> according to the (terse) datasheet, Teres-I and pinebook schematics,
> and the confusing parts of the linux driver code (not yet included here).
> Active low -> no more confusion.
>
> ---
>  .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 40 +++++++++++++++++--
>  1 file changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> index c455b24dd079..bc1d0d6c0672 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> @@ -72,20 +72,38 @@
>         };
>  };
>
> +&de {
> +       status = "okay";
> +};
> +
>  &ehci1 {
>         status = "okay";
>  };
>
>
> -/* The ANX6345 eDP-bridge is on i2c0. There is no linux (mainline)
> - * driver for this chip at the moment, the bootloader initializes it.
> - * However it can be accessed with the i2c-dev driver from user space.
> - */
>  &i2c0 {
>         clock-frequency = <100000>;
>         pinctrl-names = "default";
>         pinctrl-0 = <&i2c0_pins>;
>         status = "okay";
> +
> +       anx6345: anx6345@38 {
> +               compatible = "analogix,anx6345";
> +               reg = <0x38>;
> +               reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
> +               dvdd25-supply = <&reg_dldo2>;
> +               dvdd12-supply = <&reg_dldo3>;
> +
> +               port {
> +                       anx6345_in: endpoint {
> +                               remote-endpoint = <&tcon0_out_anx6345>;
> +                       };
> +               };

It doesn't comply with bindings document. You need to add out endpoint
as well, and to do so you need to add bindings for eDP connector first
and then implement panel driver.
See Rob's suggestions here: http://patchwork.ozlabs.org/patch/1042593/

> +       };
> +};
> +
> +&mixer0 {
> +       status = "okay";
>  };
>
>  &mmc0 {
> @@ -258,6 +276,20 @@
>         vcc-hdmi-supply = <&reg_dldo1>;
>  };
>
> +&tcon0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&lcd_rgb666_pins>;
> +
> +       status = "okay";
> +};
> +
> +&tcon0_out {
> +       tcon0_out_anx6345: endpoint@0 {
> +               reg = <0>;
> +               remote-endpoint = <&anx6345_in>;
> +       };
> +};
> +
>  &uart0 {
>         pinctrl-names = "default";
>         pinctrl-0 = <&uart0_pb_pins>;
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Torsten Duwe]

On Tue, 14 May 2019 10:48:40 -0700
Vasily Khoruzhick <anarsoul@gmail.com> wrote:

> > +       anx6345: anx6345@38 {
> > +               compatible = "analogix,anx6345";
> > +               reg = <0x38>;
> > +               reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24
> > */
> > +               dvdd25-supply = <&reg_dldo2>;
> > +               dvdd12-supply = <&reg_dldo3>;
> > +
> > +               port {
> > +                       anx6345_in: endpoint {
> > +                               remote-endpoint =
> > <&tcon0_out_anx6345>;
> > +                       };
> > +               };
> 
> It doesn't comply with bindings document. You need to add out endpoint

It does comply with the bindings. The ports are all optional.
As far as DT is concerned, the signal path ends here. This is also the
final component _required_ to get the Linux kernel DRI up and running.

> as well, and to do so you need to add bindings for eDP connector first
> and then implement panel driver.
> See Rob's suggestions here: http://patchwork.ozlabs.org/patch/1042593/

Well, one *could* extend the hardware description down to the actual
panel if necessary, but on the Teres-I it is not. I assume the panel
they ship provides proper EDID to the anx6345, because the display
works fine here with this DT.

Do I understand this correctly that the (3 different?) pinebook panels
are not that easy to handle? I try to include the pinebook wherever
possible, just because it's so similar, but here I'm a bit lost, so I
had to omit these parts.

Should I also have added a Tested-by: ? ;-)

	Torsten

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Torsten Duwe]

On Tue, 14 May 2019 10:48:40 -0700
Vasily Khoruzhick <anarsoul@gmail.com> wrote:

> > +       anx6345: anx6345@38 {
> > +               compatible = "analogix,anx6345";
> > +               reg = <0x38>;
> > +               reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24
> > */
> > +               dvdd25-supply = <&reg_dldo2>;
> > +               dvdd12-supply = <&reg_dldo3>;
> > +
> > +               port {
> > +                       anx6345_in: endpoint {
> > +                               remote-endpoint =
> > <&tcon0_out_anx6345>;
> > +                       };
> > +               };
> 
> It doesn't comply with bindings document. You need to add out endpoint

It does comply with the bindings. The ports are all optional.
As far as DT is concerned, the signal path ends here. This is also the
final component _required_ to get the Linux kernel DRI up and running.

> as well, and to do so you need to add bindings for eDP connector first
> and then implement panel driver.
> See Rob's suggestions here: http://patchwork.ozlabs.org/patch/1042593/

Well, one *could* extend the hardware description down to the actual
panel if necessary, but on the Teres-I it is not. I assume the panel
they ship provides proper EDID to the anx6345, because the display
works fine here with this DT.

Do I understand this correctly that the (3 different?) pinebook panels
are not that easy to handle? I try to include the pinebook wherever
possible, just because it's so similar, but here I'm a bit lost, so I
had to omit these parts.

Should I also have added a Tested-by: ? ;-)

	Torsten

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Vasily Khoruzhick]

On Wed, May 15, 2019 at 12:32 AM Torsten Duwe <duwe@lst.de> wrote:
>
> On Tue, 14 May 2019 10:48:40 -0700
> Vasily Khoruzhick <anarsoul@gmail.com> wrote:
>
> > > +       anx6345: anx6345@38 {
> > > +               compatible = "analogix,anx6345";
> > > +               reg = <0x38>;
> > > +               reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24
> > > */
> > > +               dvdd25-supply = <&reg_dldo2>;
> > > +               dvdd12-supply = <&reg_dldo3>;
> > > +
> > > +               port {
> > > +                       anx6345_in: endpoint {
> > > +                               remote-endpoint =
> > > <&tcon0_out_anx6345>;
> > > +                       };
> > > +               };
> >
> > It doesn't comply with bindings document. You need to add out endpoint
>
> It does comply with the bindings. The ports are all optional.
> As far as DT is concerned, the signal path ends here. This is also the
> final component _required_ to get the Linux kernel DRI up and running.

Ugh, then bindings should be fixed. It's not optional. It may work if
bootloader enables power for you, but it won't if you disable display
driver in u-boot.

> > as well, and to do so you need to add bindings for eDP connector first
> > and then implement panel driver.
> > See Rob's suggestions here: http://patchwork.ozlabs.org/patch/1042593/
>
> Well, one *could* extend the hardware description down to the actual
> panel if necessary, but on the Teres-I it is not. I assume the panel
> they ship provides proper EDID to the anx6345, because the display
> works fine here with this DT.

I guess you're testing it with older version of anx6345. Newer version
that supports power management [1] needs startup delay for panel.
Another issue that you're seeing is that backlight is not disabled on
DPMS events. All in all, you need to describe panel in dts.

[1] https://github.com/anarsoul/linux-2.6/commit/2fbf9c242419c8bda698e8331a02d4312143ae2c


> Do I understand this correctly that the (3 different?) pinebook panels
> are not that easy to handle? I try to include the pinebook wherever
> possible, just because it's so similar, but here I'm a bit lost, so I
> had to omit these parts.
>
> Should I also have added a Tested-by: ? ;-)

I don't have Teres, so I haven't tested these.

>
>         Torsten

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Vasily Khoruzhick]

On Wed, May 15, 2019 at 12:32 AM Torsten Duwe <duwe@lst.de> wrote:
>
> On Tue, 14 May 2019 10:48:40 -0700
> Vasily Khoruzhick <anarsoul@gmail.com> wrote:
>
> > > +       anx6345: anx6345@38 {
> > > +               compatible = "analogix,anx6345";
> > > +               reg = <0x38>;
> > > +               reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24
> > > */
> > > +               dvdd25-supply = <&reg_dldo2>;
> > > +               dvdd12-supply = <&reg_dldo3>;
> > > +
> > > +               port {
> > > +                       anx6345_in: endpoint {
> > > +                               remote-endpoint =
> > > <&tcon0_out_anx6345>;
> > > +                       };
> > > +               };
> >
> > It doesn't comply with bindings document. You need to add out endpoint
>
> It does comply with the bindings. The ports are all optional.
> As far as DT is concerned, the signal path ends here. This is also the
> final component _required_ to get the Linux kernel DRI up and running.

Ugh, then bindings should be fixed. It's not optional. It may work if
bootloader enables power for you, but it won't if you disable display
driver in u-boot.

> > as well, and to do so you need to add bindings for eDP connector first
> > and then implement panel driver.
> > See Rob's suggestions here: http://patchwork.ozlabs.org/patch/1042593/
>
> Well, one *could* extend the hardware description down to the actual
> panel if necessary, but on the Teres-I it is not. I assume the panel
> they ship provides proper EDID to the anx6345, because the display
> works fine here with this DT.

I guess you're testing it with older version of anx6345. Newer version
that supports power management [1] needs startup delay for panel.
Another issue that you're seeing is that backlight is not disabled on
DPMS events. All in all, you need to describe panel in dts.

[1] https://github.com/anarsoul/linux-2.6/commit/2fbf9c242419c8bda698e8331a02d4312143ae2c


> Do I understand this correctly that the (3 different?) pinebook panels
> are not that easy to handle? I try to include the pinebook wherever
> possible, just because it's so similar, but here I'm a bit lost, so I
> had to omit these parts.
>
> Should I also have added a Tested-by: ? ;-)

I don't have Teres, so I haven't tested these.

>
>         Torsten

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Torsten Duwe]

On Wed, May 15, 2019 at 08:08:57AM -0700, Vasily Khoruzhick wrote:
> On Wed, May 15, 2019 at 12:32 AM Torsten Duwe <duwe@lst.de> wrote:
> >
> > It does comply with the bindings. The ports are all optional.
> > As far as DT is concerned, the signal path ends here. This is also the
> > final component _required_ to get the Linux kernel DRI up and running.
> 
> Ugh, then bindings should be fixed. It's not optional. It may work if
> bootloader enables power for you, but it won't if you disable display
> driver in u-boot.

I double-checked. On the Teres-I, mentioning the panel _is_ optional.
PD23 powers down panel and backlight as much as possible, see
24bd5d2cb93bc arm64: dts: allwinner: a64: teres-i: enable backlight
(currently only in Maxime's repo) and the Teres-I schematics...

And the driver in your repo neatly guards all accesses with
"if (anx6345->panel)" -- good!
But I found the Vdds are required, so I added them as such.

> I guess you're testing it with older version of anx6345. Newer version
> that supports power management [1] needs startup delay for panel.
> Another issue that you're seeing is that backlight is not disabled on
> DPMS events. All in all, you need to describe panel in dts.
> 
> [1] https://github.com/anarsoul/linux-2.6/commit/2fbf9c242419c8bda698e8331a02d4312143ae2c

> > Should I also have added a Tested-by: ? ;-)
> 
> I don't have Teres, so I haven't tested these.

*I* have one, and this works. I'll retest with your newer driver,
just in case. Nonetheless, the changes in this series should be fine.
Sending out v2 in a moment...

	Torsten

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Torsten Duwe]

On Wed, May 15, 2019 at 08:08:57AM -0700, Vasily Khoruzhick wrote:
> On Wed, May 15, 2019 at 12:32 AM Torsten Duwe <duwe@lst.de> wrote:
> >
> > It does comply with the bindings. The ports are all optional.
> > As far as DT is concerned, the signal path ends here. This is also the
> > final component _required_ to get the Linux kernel DRI up and running.
> 
> Ugh, then bindings should be fixed. It's not optional. It may work if
> bootloader enables power for you, but it won't if you disable display
> driver in u-boot.

I double-checked. On the Teres-I, mentioning the panel _is_ optional.
PD23 powers down panel and backlight as much as possible, see
24bd5d2cb93bc arm64: dts: allwinner: a64: teres-i: enable backlight
(currently only in Maxime's repo) and the Teres-I schematics...

And the driver in your repo neatly guards all accesses with
"if (anx6345->panel)" -- good!
But I found the Vdds are required, so I added them as such.

> I guess you're testing it with older version of anx6345. Newer version
> that supports power management [1] needs startup delay for panel.
> Another issue that you're seeing is that backlight is not disabled on
> DPMS events. All in all, you need to describe panel in dts.
> 
> [1] https://github.com/anarsoul/linux-2.6/commit/2fbf9c242419c8bda698e8331a02d4312143ae2c

> > Should I also have added a Tested-by: ? ;-)
> 
> I don't have Teres, so I haven't tested these.

*I* have one, and this works. I'll retest with your newer driver,
just in case. Nonetheless, the changes in this series should be fine.
Sending out v2 in a moment...

	Torsten


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Vasily Khoruzhick]

On Thu, May 16, 2019 at 8:48 AM Torsten Duwe <duwe@lst.de> wrote:
>
> On Wed, May 15, 2019 at 08:08:57AM -0700, Vasily Khoruzhick wrote:
> > On Wed, May 15, 2019 at 12:32 AM Torsten Duwe <duwe@lst.de> wrote:
> > >
> > > It does comply with the bindings. The ports are all optional.
> > > As far as DT is concerned, the signal path ends here. This is also the
> > > final component _required_ to get the Linux kernel DRI up and running.
> >
> > Ugh, then bindings should be fixed. It's not optional. It may work if
> > bootloader enables power for you, but it won't if you disable display
> > driver in u-boot.
>
> I double-checked. On the Teres-I, mentioning the panel _is_ optional.

It's not. See power on sequence in
https://www.olimex.com/Products/DIY-Laptop/SPARE-PARTS/TERES-015-LCD11-6/resources/N116BGE-EA2.pdf

Driver can talk to the panel over AUX channel only after t1+t3, t1 is
up to 10ms, t3 is up to 200ms. It works with older version of driver
that keeps panel always on because it takes a while between driver
probe and pipeline start.

It'll likely break with newer version of driver that turns on panel
only when bridge is active. You'll see AUX timeouts - it won't be able
to probe EDID in some cases. Problem can be intermittent and device
dependent.

All in all - you don't need panel timings since there's EDID but you
still need panel delays. Anyway, it's up to you and maintainers.

> PD23 powers down panel and backlight as much as possible, see
> 24bd5d2cb93bc arm64: dts: allwinner: a64: teres-i: enable backlight
> (currently only in Maxime's repo) and the Teres-I schematics...
>
> And the driver in your repo neatly guards all accesses with
> "if (anx6345->panel)" -- good!
> But I found the Vdds are required, so I added them as such.
>
> > I guess you're testing it with older version of anx6345. Newer version
> > that supports power management [1] needs startup delay for panel.
> > Another issue that you're seeing is that backlight is not disabled on
> > DPMS events. All in all, you need to describe panel in dts.
> >
> > [1] https://github.com/anarsoul/linux-2.6/commit/2fbf9c242419c8bda698e8331a02d4312143ae2c
>
> > > Should I also have added a Tested-by: ? ;-)
> >
> > I don't have Teres, so I haven't tested these.
>
> *I* have one, and this works. I'll retest with your newer driver,
> just in case. Nonetheless, the changes in this series should be fine.
> Sending out v2 in a moment...
>
>         Torsten
>

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Vasily Khoruzhick]

On Thu, May 16, 2019 at 8:48 AM Torsten Duwe <duwe@lst.de> wrote:
>
> On Wed, May 15, 2019 at 08:08:57AM -0700, Vasily Khoruzhick wrote:
> > On Wed, May 15, 2019 at 12:32 AM Torsten Duwe <duwe@lst.de> wrote:
> > >
> > > It does comply with the bindings. The ports are all optional.
> > > As far as DT is concerned, the signal path ends here. This is also the
> > > final component _required_ to get the Linux kernel DRI up and running.
> >
> > Ugh, then bindings should be fixed. It's not optional. It may work if
> > bootloader enables power for you, but it won't if you disable display
> > driver in u-boot.
>
> I double-checked. On the Teres-I, mentioning the panel _is_ optional.

It's not. See power on sequence in
https://www.olimex.com/Products/DIY-Laptop/SPARE-PARTS/TERES-015-LCD11-6/resources/N116BGE-EA2.pdf

Driver can talk to the panel over AUX channel only after t1+t3, t1 is
up to 10ms, t3 is up to 200ms. It works with older version of driver
that keeps panel always on because it takes a while between driver
probe and pipeline start.

It'll likely break with newer version of driver that turns on panel
only when bridge is active. You'll see AUX timeouts - it won't be able
to probe EDID in some cases. Problem can be intermittent and device
dependent.

All in all - you don't need panel timings since there's EDID but you
still need panel delays. Anyway, it's up to you and maintainers.

> PD23 powers down panel and backlight as much as possible, see
> 24bd5d2cb93bc arm64: dts: allwinner: a64: teres-i: enable backlight
> (currently only in Maxime's repo) and the Teres-I schematics...
>
> And the driver in your repo neatly guards all accesses with
> "if (anx6345->panel)" -- good!
> But I found the Vdds are required, so I added them as such.
>
> > I guess you're testing it with older version of anx6345. Newer version
> > that supports power management [1] needs startup delay for panel.
> > Another issue that you're seeing is that backlight is not disabled on
> > DPMS events. All in all, you need to describe panel in dts.
> >
> > [1] https://github.com/anarsoul/linux-2.6/commit/2fbf9c242419c8bda698e8331a02d4312143ae2c
>
> > > Should I also have added a Tested-by: ? ;-)
> >
> > I don't have Teres, so I haven't tested these.
>
> *I* have one, and this works. I'll retest with your newer driver,
> just in case. Nonetheless, the changes in this series should be fine.
> Sending out v2 in a moment...
>
>         Torsten
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Torsten Duwe]

On Thu, May 16, 2019 at 09:06:41AM -0700, Vasily Khoruzhick wrote:
> 
> Driver can talk to the panel over AUX channel only after t1+t3, t1 is
> up to 10ms, t3 is up to 200ms.

This is after power-on. The boot loader needs to deal with this.

> It works with older version of driver
> that keeps panel always on because it takes a while between driver
> probe and pipeline start.

No lid switch, no USB, no WiFi, no MMC. If you disable DCDC1 you'll
run out of wakeup-sources ;-) IOW: I see no practical way any OS
driver can switch this panel voltage off and survive...

> All in all - you don't need panel timings since there's EDID but you
> still need panel delays. Anyway, it's up to you and maintainers.

Let's give it a try.

	Torsten

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Torsten Duwe]

On Thu, May 16, 2019 at 09:06:41AM -0700, Vasily Khoruzhick wrote:
> 
> Driver can talk to the panel over AUX channel only after t1+t3, t1 is
> up to 10ms, t3 is up to 200ms.

This is after power-on. The boot loader needs to deal with this.

> It works with older version of driver
> that keeps panel always on because it takes a while between driver
> probe and pipeline start.

No lid switch, no USB, no WiFi, no MMC. If you disable DCDC1 you'll
run out of wakeup-sources ;-) IOW: I see no practical way any OS
driver can switch this panel voltage off and survive...

> All in all - you don't need panel timings since there's EDID but you
> still need panel delays. Anyway, it's up to you and maintainers.

Let's give it a try.

	Torsten


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Vasily Khoruzhick]

On Thu, May 16, 2019 at 9:49 AM Torsten Duwe <duwe@lst.de> wrote:
>
> On Thu, May 16, 2019 at 09:06:41AM -0700, Vasily Khoruzhick wrote:
> >
> > Driver can talk to the panel over AUX channel only after t1+t3, t1 is
> > up to 10ms, t3 is up to 200ms.
>
> This is after power-on. The boot loader needs to deal with this.

Actually panel driver has to deal with it and not bootloader.

> > It works with older version of driver
> > that keeps panel always on because it takes a while between driver
> > probe and pipeline start.
>
> No lid switch, no USB, no WiFi, no MMC. If you disable DCDC1 you'll
> run out of wakeup-sources ;-) IOW: I see no practical way any OS
> driver can switch this panel voltage off and survive...

Ouch, looks like someone made a huge mistake in HW design?

> > All in all - you don't need panel timings since there's EDID but you
> > still need panel delays. Anyway, it's up to you and maintainers.
>
> Let's give it a try.
>
>         Torsten
>

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Vasily Khoruzhick]

On Thu, May 16, 2019 at 9:49 AM Torsten Duwe <duwe@lst.de> wrote:
>
> On Thu, May 16, 2019 at 09:06:41AM -0700, Vasily Khoruzhick wrote:
> >
> > Driver can talk to the panel over AUX channel only after t1+t3, t1 is
> > up to 10ms, t3 is up to 200ms.
>
> This is after power-on. The boot loader needs to deal with this.

Actually panel driver has to deal with it and not bootloader.

> > It works with older version of driver
> > that keeps panel always on because it takes a while between driver
> > probe and pipeline start.
>
> No lid switch, no USB, no WiFi, no MMC. If you disable DCDC1 you'll
> run out of wakeup-sources ;-) IOW: I see no practical way any OS
> driver can switch this panel voltage off and survive...

Ouch, looks like someone made a huge mistake in HW design?

> > All in all - you don't need panel timings since there's EDID but you
> > still need panel delays. Anyway, it's up to you and maintainers.
>
> Let's give it a try.
>
>         Torsten
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

On Thu, May 16, 2019 at 06:48:59PM +0200, Torsten Duwe wrote:
> On Thu, May 16, 2019 at 09:06:41AM -0700, Vasily Khoruzhick wrote:
> >
> > Driver can talk to the panel over AUX channel only after t1+t3, t1 is
> > up to 10ms, t3 is up to 200ms.
>
> This is after power-on. The boot loader needs to deal with this.

The bootloader can deal with it, but the kernel will also need to. The
bootloader might not be doing this because it's not been updated, the
regulator might have been disabled between the time the kernel was
started and the time the bridge driver probes, etc.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 667 bytes --]

On Thu, May 16, 2019 at 06:48:59PM +0200, Torsten Duwe wrote:
> On Thu, May 16, 2019 at 09:06:41AM -0700, Vasily Khoruzhick wrote:
> >
> > Driver can talk to the panel over AUX channel only after t1+t3, t1 is
> > up to 10ms, t3 is up to 200ms.
>
> This is after power-on. The boot loader needs to deal with this.

The bootloader can deal with it, but the kernel will also need to. The
bootloader might not be doing this because it's not been updated, the
regulator might have been disabled between the time the kernel was
started and the time the bridge driver probes, etc.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 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

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 667 bytes --]

On Thu, May 16, 2019 at 06:48:59PM +0200, Torsten Duwe wrote:
> On Thu, May 16, 2019 at 09:06:41AM -0700, Vasily Khoruzhick wrote:
> >
> > Driver can talk to the panel over AUX channel only after t1+t3, t1 is
> > up to 10ms, t3 is up to 200ms.
>
> This is after power-on. The boot loader needs to deal with this.

The bootloader can deal with it, but the kernel will also need to. The
bootloader might not be doing this because it's not been updated, the
regulator might have been disabled between the time the kernel was
started and the time the bridge driver probes, etc.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Torsten Duwe]

On Fri, 17 May 2019 09:27:38 +0200
Maxime Ripard <maxime.ripard@bootlin.com> wrote:

> On Thu, May 16, 2019 at 06:48:59PM +0200, Torsten Duwe wrote:
> > On Thu, May 16, 2019 at 09:06:41AM -0700, Vasily Khoruzhick wrote:
> > >
> > > Driver can talk to the panel over AUX channel only after t1+t3,
> > > t1 is up to 10ms, t3 is up to 200ms.
> >
> > This is after power-on. The boot loader needs to deal with this.
> 
> The bootloader can deal with it, but the kernel will also need to. The
> bootloader might not be doing this because it's not been updated, the
> regulator might have been disabled between the time the kernel was
> started and the time the bridge driver probes, etc.

No, you cannot practically switch off this voltage. It supports _all_
the devices I mentioned. In fact, the PMIC needs to enable it initially,
and then it takes some time before the SoC can access the MMC and read
the SPL from it, just because of exactly these 3.3V. Then the boot
loader starts, and later the eDP bridge gets initialised.

In *theory*, albeit a very daring one, I could imagine a very deep
sleep mode that can only be ended by pressing the power button, which
should still work without DCDC1. Only then, a description of the panel
would be required. But I probably missed something and even this does
not work.

So for all current practical purposes, we can assume the Teres-I panel
to be powered properly and providing valid EDID; nothing to worry about
in software.

HTH,
	Torsten

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Torsten Duwe]

On Fri, 17 May 2019 09:27:38 +0200
Maxime Ripard <maxime.ripard@bootlin.com> wrote:

> On Thu, May 16, 2019 at 06:48:59PM +0200, Torsten Duwe wrote:
> > On Thu, May 16, 2019 at 09:06:41AM -0700, Vasily Khoruzhick wrote:
> > >
> > > Driver can talk to the panel over AUX channel only after t1+t3,
> > > t1 is up to 10ms, t3 is up to 200ms.
> >
> > This is after power-on. The boot loader needs to deal with this.
> 
> The bootloader can deal with it, but the kernel will also need to. The
> bootloader might not be doing this because it's not been updated, the
> regulator might have been disabled between the time the kernel was
> started and the time the bridge driver probes, etc.

No, you cannot practically switch off this voltage. It supports _all_
the devices I mentioned. In fact, the PMIC needs to enable it initially,
and then it takes some time before the SoC can access the MMC and read
the SPL from it, just because of exactly these 3.3V. Then the boot
loader starts, and later the eDP bridge gets initialised.

In *theory*, albeit a very daring one, I could imagine a very deep
sleep mode that can only be ended by pressing the power button, which
should still work without DCDC1. Only then, a description of the panel
would be required. But I probably missed something and even this does
not work.

So for all current practical purposes, we can assume the Teres-I panel
to be powered properly and providing valid EDID; nothing to worry about
in software.

HTH,
	Torsten

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]

On Fri, May 17, 2019 at 10:14:18AM +0200, Torsten Duwe wrote:
> On Fri, 17 May 2019 09:27:38 +0200
> Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> > On Thu, May 16, 2019 at 06:48:59PM +0200, Torsten Duwe wrote:
> > > On Thu, May 16, 2019 at 09:06:41AM -0700, Vasily Khoruzhick wrote:
> > > >
> > > > Driver can talk to the panel over AUX channel only after t1+t3,
> > > > t1 is up to 10ms, t3 is up to 200ms.
> > >
> > > This is after power-on. The boot loader needs to deal with this.
> >
> > The bootloader can deal with it, but the kernel will also need to. The
> > bootloader might not be doing this because it's not been updated, the
> > regulator might have been disabled between the time the kernel was
> > started and the time the bridge driver probes, etc.
>
> No, you cannot practically switch off this voltage. It supports _all_
> the devices I mentioned. In fact, the PMIC needs to enable it initially,
> and then it takes some time before the SoC can access the MMC and read
> the SPL from it, just because of exactly these 3.3V. Then the boot
> loader starts, and later the eDP bridge gets initialised.

All these devices can be unused, disabled, or compiled as modules.

> In *theory*, albeit a very daring one, I could imagine a very deep
> sleep mode that can only be ended by pressing the power button, which
> should still work without DCDC1. Only then, a description of the panel
> would be required. But I probably missed something and even this does
> not work.
>
> So for all current practical purposes, we can assume the Teres-I panel
> to be powered properly and providing valid EDID; nothing to worry about
> in software.

You're creating a generic binding for all the users of that bridge,
while considering only the specific case of the Teres-I.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1874 bytes --]

On Fri, May 17, 2019 at 10:14:18AM +0200, Torsten Duwe wrote:
> On Fri, 17 May 2019 09:27:38 +0200
> Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> > On Thu, May 16, 2019 at 06:48:59PM +0200, Torsten Duwe wrote:
> > > On Thu, May 16, 2019 at 09:06:41AM -0700, Vasily Khoruzhick wrote:
> > > >
> > > > Driver can talk to the panel over AUX channel only after t1+t3,
> > > > t1 is up to 10ms, t3 is up to 200ms.
> > >
> > > This is after power-on. The boot loader needs to deal with this.
> >
> > The bootloader can deal with it, but the kernel will also need to. The
> > bootloader might not be doing this because it's not been updated, the
> > regulator might have been disabled between the time the kernel was
> > started and the time the bridge driver probes, etc.
>
> No, you cannot practically switch off this voltage. It supports _all_
> the devices I mentioned. In fact, the PMIC needs to enable it initially,
> and then it takes some time before the SoC can access the MMC and read
> the SPL from it, just because of exactly these 3.3V. Then the boot
> loader starts, and later the eDP bridge gets initialised.

All these devices can be unused, disabled, or compiled as modules.

> In *theory*, albeit a very daring one, I could imagine a very deep
> sleep mode that can only be ended by pressing the power button, which
> should still work without DCDC1. Only then, a description of the panel
> would be required. But I probably missed something and even this does
> not work.
>
> So for all current practical purposes, we can assume the Teres-I panel
> to be powered properly and providing valid EDID; nothing to worry about
> in software.

You're creating a generic binding for all the users of that bridge,
while considering only the specific case of the Teres-I.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 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

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1874 bytes --]

On Fri, May 17, 2019 at 10:14:18AM +0200, Torsten Duwe wrote:
> On Fri, 17 May 2019 09:27:38 +0200
> Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> > On Thu, May 16, 2019 at 06:48:59PM +0200, Torsten Duwe wrote:
> > > On Thu, May 16, 2019 at 09:06:41AM -0700, Vasily Khoruzhick wrote:
> > > >
> > > > Driver can talk to the panel over AUX channel only after t1+t3,
> > > > t1 is up to 10ms, t3 is up to 200ms.
> > >
> > > This is after power-on. The boot loader needs to deal with this.
> >
> > The bootloader can deal with it, but the kernel will also need to. The
> > bootloader might not be doing this because it's not been updated, the
> > regulator might have been disabled between the time the kernel was
> > started and the time the bridge driver probes, etc.
>
> No, you cannot practically switch off this voltage. It supports _all_
> the devices I mentioned. In fact, the PMIC needs to enable it initially,
> and then it takes some time before the SoC can access the MMC and read
> the SPL from it, just because of exactly these 3.3V. Then the boot
> loader starts, and later the eDP bridge gets initialised.

All these devices can be unused, disabled, or compiled as modules.

> In *theory*, albeit a very daring one, I could imagine a very deep
> sleep mode that can only be ended by pressing the power button, which
> should still work without DCDC1. Only then, a description of the panel
> would be required. But I probably missed something and even this does
> not work.
>
> So for all current practical purposes, we can assume the Teres-I panel
> to be powered properly and providing valid EDID; nothing to worry about
> in software.

You're creating a generic binding for all the users of that bridge,
while considering only the specific case of the Teres-I.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Torsten Duwe]

On Fri, May 17, 2019 at 11:08:45AM +0200, Maxime Ripard wrote:
> >
> > So for all current practical purposes, we can assume the Teres-I panel
> > to be powered properly and providing valid EDID; nothing to worry about
> > in software.
> 
> You're creating a generic binding for all the users of that bridge,
> while considering only the specific case of the Teres-I.

All I'm saying is that _this_ usage is also valid. Nothing keeps other
users from defining the output panel; on the contrary: the driver at hand
already considers an _optional_ panel and handles it, conditionally. So
driver and binding spec are 100% in sync here.

This is much more straightforward than requiring an output and making up
some dummy code and params because it cannot reasonably be handled.
(Remember, if there is an output, the driver will make calls to the
"attached device" driver.)

	Torsten

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Torsten Duwe]

On Fri, May 17, 2019 at 11:08:45AM +0200, Maxime Ripard wrote:
> >
> > So for all current practical purposes, we can assume the Teres-I panel
> > to be powered properly and providing valid EDID; nothing to worry about
> > in software.
> 
> You're creating a generic binding for all the users of that bridge,
> while considering only the specific case of the Teres-I.

All I'm saying is that _this_ usage is also valid. Nothing keeps other
users from defining the output panel; on the contrary: the driver at hand
already considers an _optional_ panel and handles it, conditionally. So
driver and binding spec are 100% in sync here.

This is much more straightforward than requiring an output and making up
some dummy code and params because it cannot reasonably be handled.
(Remember, if there is an output, the driver will make calls to the
"attached device" driver.)

	Torsten


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Vasily Khoruzhick]

On Fri, May 17, 2019 at 2:47 AM Torsten Duwe <duwe@lst.de> wrote:
>
> On Fri, May 17, 2019 at 11:08:45AM +0200, Maxime Ripard wrote:
> > >
> > > So for all current practical purposes, we can assume the Teres-I panel
> > > to be powered properly and providing valid EDID; nothing to worry about
> > > in software.
> >
> > You're creating a generic binding for all the users of that bridge,
> > while considering only the specific case of the Teres-I.
>
> All I'm saying is that _this_ usage is also valid. Nothing keeps other
> users from defining the output panel; on the contrary: the driver at hand
> already considers an _optional_ panel and handles it, conditionally. So
> driver and binding spec are 100% in sync here.

Well, endpoint is not necessarily a panel. It can be another bridge or
connector - that's why panel can be optional in driver. But it don't
think that you can just omit an endpoint.

> This is much more straightforward than requiring an output and making up
> some dummy code and params because it cannot reasonably be handled.
> (Remember, if there is an output, the driver will make calls to the
> "attached device" driver.)

They aren't dummy. Moreover you have to attach backlight somewhere (to
panel) so it can be disabled when output is disabled.

Try 'xrandr --output eDP-1 --off' on teres with your current code and
see that backlight stays on.

>
>         Torsten
>

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Vasily Khoruzhick]

On Fri, May 17, 2019 at 2:47 AM Torsten Duwe <duwe@lst.de> wrote:
>
> On Fri, May 17, 2019 at 11:08:45AM +0200, Maxime Ripard wrote:
> > >
> > > So for all current practical purposes, we can assume the Teres-I panel
> > > to be powered properly and providing valid EDID; nothing to worry about
> > > in software.
> >
> > You're creating a generic binding for all the users of that bridge,
> > while considering only the specific case of the Teres-I.
>
> All I'm saying is that _this_ usage is also valid. Nothing keeps other
> users from defining the output panel; on the contrary: the driver at hand
> already considers an _optional_ panel and handles it, conditionally. So
> driver and binding spec are 100% in sync here.

Well, endpoint is not necessarily a panel. It can be another bridge or
connector - that's why panel can be optional in driver. But it don't
think that you can just omit an endpoint.

> This is much more straightforward than requiring an output and making up
> some dummy code and params because it cannot reasonably be handled.
> (Remember, if there is an output, the driver will make calls to the
> "attached device" driver.)

They aren't dummy. Moreover you have to attach backlight somewhere (to
panel) so it can be disabled when output is disabled.

Try 'xrandr --output eDP-1 --off' on teres with your current code and
see that backlight stays on.

>
>         Torsten
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I

[Vasily Khoruzhick]

On Fri, May 17, 2019 at 2:47 AM Torsten Duwe <duwe@lst.de> wrote:
>
> On Fri, May 17, 2019 at 11:08:45AM +0200, Maxime Ripard wrote:
> > >
> > > So for all current practical purposes, we can assume the Teres-I panel
> > > to be powered properly and providing valid EDID; nothing to worry about
> > > in software.
> >
> > You're creating a generic binding for all the users of that bridge,
> > while considering only the specific case of the Teres-I.
>
> All I'm saying is that _this_ usage is also valid. Nothing keeps other
> users from defining the output panel; on the contrary: the driver at hand
> already considers an _optional_ panel and handles it, conditionally. So
> driver and binding spec are 100% in sync here.

Well, endpoint is not necessarily a panel. It can be another bridge or
connector - that's why panel can be optional in driver. But it don't
think that you can just omit an endpoint.

> This is much more straightforward than requiring an output and making up
> some dummy code and params because it cannot reasonably be handled.
> (Remember, if there is an output, the driver will make calls to the
> "attached device" driver.)

They aren't dummy. Moreover you have to attach backlight somewhere (to
panel) so it can be disabled when output is disabled.

Try 'xrandr --output eDP-1 --off' on teres with your current code and
see that backlight stays on.

>
>         Torsten
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel