| Message ID | 20190514160241.9EAC768C7B@newverein.lst.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add missing device nodes for Olimex Teres-I | expand |
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 = <®_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 <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 = <®_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 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
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 >
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 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 >
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, 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
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
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 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 >
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>;