From: Icenowy Zheng <[email protected]>
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 <[email protected]>
Signed-off-by: Torsten Duwe <[email protected]>
---
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 = <®_dldo2>;
+ dvdd12-supply = <®_dldo3>;
+
+ port {
+ anx6345_in: endpoint {
+ remote-endpoint = <&tcon0_out_anx6345>;
+ };
+ };
+ };
+};
+
+&mixer0 {
+ status = "okay";
};
&mmc0 {
@@ -258,6 +276,20 @@
vcc-hdmi-supply = <®_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>;
On Tue, May 14, 2019 at 9:03 AM Torsten Duwe <[email protected]> wrote:
>
> From: Icenowy Zheng <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Torsten Duwe <[email protected]>
> ---
>
> 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 = <®_dldo2>;
> + dvdd12-supply = <®_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 = <®_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>;
On Tue, 14 May 2019 10:48:40 -0700
Vasily Khoruzhick <[email protected]> wrote:
> > + anx6345: anx6345@38 {
> > + compatible = "analogix,anx6345";
> > + reg = <0x38>;
> > + reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24
> > */
> > + dvdd25-supply = <®_dldo2>;
> > + dvdd12-supply = <®_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
On Wed, May 15, 2019 at 12:32 AM Torsten Duwe <[email protected]> wrote:
>
> On Tue, 14 May 2019 10:48:40 -0700
> Vasily Khoruzhick <[email protected]> wrote:
>
> > > + anx6345: anx6345@38 {
> > > + compatible = "analogix,anx6345";
> > > + reg = <0x38>;
> > > + reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24
> > > */
> > > + dvdd25-supply = <®_dldo2>;
> > > + dvdd12-supply = <®_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
On Thu, May 16, 2019 at 8:48 AM Torsten Duwe <[email protected]> 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 <[email protected]> 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
>
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
On Wed, May 15, 2019 at 08:08:57AM -0700, Vasily Khoruzhick wrote:
> On Wed, May 15, 2019 at 12:32 AM Torsten Duwe <[email protected]> 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
On Thu, May 16, 2019 at 9:49 AM Torsten Duwe <[email protected]> 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
>
On Fri, 17 May 2019 09:27:38 +0200
Maxime Ripard <[email protected]> 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
On Fri, May 17, 2019 at 10:14:18AM +0200, Torsten Duwe wrote:
> On Fri, 17 May 2019 09:27:38 +0200
> Maxime Ripard <[email protected]> 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
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
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
On Fri, May 17, 2019 at 2:47 AM Torsten Duwe <[email protected]> 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
>