Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[Jernej Škrabec]

Dne četrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng napisal(a):
> 2016年12月1日 02:49于 Jernej Skrabec <jernej.skrabec@gmail.com>写道：
> 
> > Hi Jean-François,
> > 
> > Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-François Moine 
napisala:
> >> On Tue, 29 Nov 2016 22:59:32 +0100
> >> 
> >> Maxime Ripard <maxime...@free-electrons.com> wrote:
> >> > > > I'm still not sure which pipeline should I use.
> >> > > > 
> >> > > > And, it seems that HDMI Slow Clock is not needed?
> >> > > > 
> >> > > > (seems that it's only for EDID, but simplefb won't use EDID)
> >> > > 
> >> > > So, I don't see how this may work.
> >> > > How can the u-boot know the resolutions of the HDMI display device?
> >> > > 
> >> > > In other words: I have a new H3 board with the last u-boot and
> >> > > kernel.
> >> > > I plug my (rather old or brand new) HDMI display device.
> >> > > After powering on the system, I hope to get something on the screen.
> >> > > How?
> >> > 
> >> > If it works like the driver for the first display engine in U-Boot, it
> >> > will use the preferred mode reported by the EDID, and will fallback to
> >> > 1024x768 if it cannot access it.
> >> 
> >> Icenowy wrote: "simplefb won't use EDID"
> >> 
> >> Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
> >> not work with HDMI (different timings).
> > 
> > U-Boot driver now accept any timings recommended by EDID. So far it
> > was tested with at least following resolutions:
> > - 1920x1080 @ 60 Hz
> > - 1280x1024 @ 60 Hz
> > - 1280x800 @ 60 Hz (slight clock difference)
> > - 800x480 (not sure about frame rate)
> > - 3840x2160 @ 30 Hz (4K)
> 
> I tested on 1024x600 (If my memory is right, it's @ 60Hz)
> 
> > and nobody complained so far. I'm pretty sure 1024x768 would work.
> > 
> >> > Maybe it would be worth exchanging on the EDID code that has been done
> >> > for the u-boot driver too, so that it can be fixed in your driver.
> >> 
> >> The u-boot got my code, and, up to now, I could not fix the random or
> >> permanent failures of EDID reading in some boards.
> > 
> > I only have one OPi2, but as I said, EDID always worked for me. The only
> > code left from you is for DE2. HDMI stuff is basically copied from Rockhip
> > driver (including EDID reading), TCON code is now reverted to the same as
> > it is in sunxi_display.c. I think it is worth to take a look at EDID code
> > and compare it.
> 
> So is the TCON of DE 2.0 identical to the original TCON?
> 
> If so, we should reuse sun4i-tcon ...
> 

Well, TCON is splitted in two parts (two base addresses), one for HDMI and one 
for TV. However, register offsets are same as before, so I guess driver 
reusage make sense. I think that there are few additional registers, but they 
can be ignored for simplefb.

> >  
> > 
> >> --
> >> Ken ar c'hentañ        |              ** Breizh ha Linux atav! **
> >> Jef                |                http://moinejf.free.fr/
> > 
> > Best regards,
> > Jernej Škrabec
> > 
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group. To unsubscribe from this group and stop receiving
> > emails from it, send an email to
> > linux-sunxi+unsubscribe@googlegroups.com. For more options, visit
> > https://groups.google.com/d/optout.

Best regards,
Jernej Škrabec

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[Jean-Francois Moine]

On Wed, 30 Nov 2016 20:14:11 +0100
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:

> Dne četrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng napisal(a):
> > 2016年12月1日 02:49于 Jernej Skrabec <jernej.skrabec@gmail.com>写道：
> > 
> > > Hi Jean-François,
> > > 
> > > Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-François Moine 
> napisala:
> > >> On Tue, 29 Nov 2016 22:59:32 +0100
> > >> 
> > >> Maxime Ripard <maxime...@free-electrons.com> wrote:
> > >> > > > I'm still not sure which pipeline should I use.
> > >> > > > 
> > >> > > > And, it seems that HDMI Slow Clock is not needed?
> > >> > > > 
> > >> > > > (seems that it's only for EDID, but simplefb won't use EDID)
> > >> > > 
> > >> > > So, I don't see how this may work.
> > >> > > How can the u-boot know the resolutions of the HDMI display device?
> > >> > > 
> > >> > > In other words: I have a new H3 board with the last u-boot and
> > >> > > kernel.
> > >> > > I plug my (rather old or brand new) HDMI display device.
> > >> > > After powering on the system, I hope to get something on the screen.
> > >> > > How?
> > >> > 
> > >> > If it works like the driver for the first display engine in U-Boot, it
> > >> > will use the preferred mode reported by the EDID, and will fallback to
> > >> > 1024x768 if it cannot access it.
> > >> 
> > >> Icenowy wrote: "simplefb won't use EDID"
> > >> 
> > >> Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
> > >> not work with HDMI (different timings).
> > > 
> > > U-Boot driver now accept any timings recommended by EDID. So far it
> > > was tested with at least following resolutions:
> > > - 1920x1080 @ 60 Hz
> > > - 1280x1024 @ 60 Hz
> > > - 1280x800 @ 60 Hz (slight clock difference)
> > > - 800x480 (not sure about frame rate)
> > > - 3840x2160 @ 30 Hz (4K)
> > 
> > I tested on 1024x600 (If my memory is right, it's @ 60Hz)
> > 
> > > and nobody complained so far. I'm pretty sure 1024x768 would work.

Check the timings offered by the DRM core.

> > > 
> > >> > Maybe it would be worth exchanging on the EDID code that has been done
> > >> > for the u-boot driver too, so that it can be fixed in your driver.
> > >> 
> > >> The u-boot got my code, and, up to now, I could not fix the random or
> > >> permanent failures of EDID reading in some boards.
> > > 
> > > I only have one OPi2, but as I said, EDID always worked for me.

Happy guy!

> > > The only
> > > code left from you is for DE2. HDMI stuff is basically copied from Rockhip
> > > driver (including EDID reading), TCON code is now reverted to the same as
> > > it is in sunxi_display.c. I think it is worth to take a look at EDID code
> > > and compare it.
> > 
> > So is the TCON of DE 2.0 identical to the original TCON?
> > 
> > If so, we should reuse sun4i-tcon ...
> 
> Well, TCON is splitted in two parts (two base addresses), one for HDMI and one 
> for TV. However, register offsets are same as before, so I guess driver 
> reusage make sense. I think that there are few additional registers, but they 
> can be ignored for simplefb.

The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
clock and I/O area.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[Jernej Škrabec]

Dne sreda, 30. november 2016 ob 20:37:24 CET je Jean-Francois Moine 
napisal(a):
> On Wed, 30 Nov 2016 20:14:11 +0100
> 
> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > Dne četrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng 
napisal(a):
> > > 2016年12月1日 02:49于 Jernej Skrabec <jernej.skrabec@gmail.com>写道：
> > > 
> > > > Hi Jean-François,
> > > > 
> > > > Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-François
> > > > Moine
> > 
> > napisala:
> > > >> On Tue, 29 Nov 2016 22:59:32 +0100
> > > >> 
> > > >> Maxime Ripard <maxime...@free-electrons.com> wrote:
> > > >> > > > I'm still not sure which pipeline should I use.
> > > >> > > > 
> > > >> > > > And, it seems that HDMI Slow Clock is not needed?
> > > >> > > > 
> > > >> > > > (seems that it's only for EDID, but simplefb won't use EDID)
> > > >> > > 
> > > >> > > So, I don't see how this may work.
> > > >> > > How can the u-boot know the resolutions of the HDMI display
> > > >> > > device?
> > > >> > > 
> > > >> > > In other words: I have a new H3 board with the last u-boot and
> > > >> > > kernel.
> > > >> > > I plug my (rather old or brand new) HDMI display device.
> > > >> > > After powering on the system, I hope to get something on the
> > > >> > > screen.
> > > >> > > How?
> > > >> > 
> > > >> > If it works like the driver for the first display engine in U-Boot,
> > > >> > it
> > > >> > will use the preferred mode reported by the EDID, and will fallback
> > > >> > to
> > > >> > 1024x768 if it cannot access it.
> > > >> 
> > > >> Icenowy wrote: "simplefb won't use EDID"
> > > >> 
> > > >> Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
> > > >> not work with HDMI (different timings).
> > > > 
> > > > U-Boot driver now accept any timings recommended by EDID. So far it
> > > > was tested with at least following resolutions:
> > > > - 1920x1080 @ 60 Hz
> > > > - 1280x1024 @ 60 Hz
> > > > - 1280x800 @ 60 Hz (slight clock difference)
> > > > - 800x480 (not sure about frame rate)
> > > > - 3840x2160 @ 30 Hz (4K)
> > > 
> > > I tested on 1024x600 (If my memory is right, it's @ 60Hz)
> > > 
> > > > and nobody complained so far. I'm pretty sure 1024x768 would work.
> 
> Check the timings offered by the DRM core.

I'm not really familiar with DRM code, but my Linux laptop happily works with 
1024x768 @ 75 Hz and other non CEA resolutions through HDMI, so I guess it 
should be possible here too. Isn't function drm_add_edid_modes() designed 
exactly for that?

Anyway, this is off topic for simplefb. Simplefb driver will just take over 
framebuffer set up by U-Boot with some additional info like width, height, 
pitch... It doesn't have to deal with HW directly.

> 
> > > >> > Maybe it would be worth exchanging on the EDID code that has been
> > > >> > done
> > > >> > for the u-boot driver too, so that it can be fixed in your driver.
> > > >> 
> > > >> The u-boot got my code, and, up to now, I could not fix the random or
> > > >> permanent failures of EDID reading in some boards.
> > > > 
> > > > I only have one OPi2, but as I said, EDID always worked for me.
> 
> Happy guy!
> 
> > > > The only
> > > > code left from you is for DE2. HDMI stuff is basically copied from
> > > > Rockhip
> > > > driver (including EDID reading), TCON code is now reverted to the same
> > > > as
> > > > it is in sunxi_display.c. I think it is worth to take a look at EDID
> > > > code
> > > > and compare it.
> > > 
> > > So is the TCON of DE 2.0 identical to the original TCON?
> > > 
> > > If so, we should reuse sun4i-tcon ...
> > 
> > Well, TCON is splitted in two parts (two base addresses), one for HDMI and
> > one for TV. However, register offsets are same as before, so I guess
> > driver reusage make sense. I think that there are few additional
> > registers, but they can be ignored for simplefb.
> 
> The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
> clock and I/O area.
> 

True, H3 user manual can be misleading sometimes. But this doesn't change the 
fact that TCON0 has same register offsets with same meaning.

> --
> Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
> Jef		|		http://moinejf.free.fr/

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[Maxime Ripard]

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

On Wed, Nov 30, 2016 at 09:41:26PM +0100, Jernej Škrabec wrote:
> > > > > The only
> > > > > code left from you is for DE2. HDMI stuff is basically copied from
> > > > > Rockhip
> > > > > driver (including EDID reading), TCON code is now reverted to the same
> > > > > as
> > > > > it is in sunxi_display.c. I think it is worth to take a look at EDID
> > > > > code
> > > > > and compare it.
> > > > 
> > > > So is the TCON of DE 2.0 identical to the original TCON?
> > > > 
> > > > If so, we should reuse sun4i-tcon ...
> > > 
> > > Well, TCON is splitted in two parts (two base addresses), one for HDMI and
> > > one for TV. However, register offsets are same as before, so I guess
> > > driver reusage make sense. I think that there are few additional
> > > registers, but they can be ignored for simplefb.
> > 
> > The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
> > clock and I/O area.
> > 
> 
> True, H3 user manual can be misleading sometimes. But this doesn't change the 
> fact that TCON0 has same register offsets with same meaning.

Then yes, we should definitely share the drivers too. So, in the end,
the only thing that is actually new is the display-engine?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[Maxime Ripard]

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

On Thu, Dec 01, 2016 at 10:02:59AM +0800, Icenowy Zheng wrote:
> 
> 
> 01.12.2016, 04:52, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> > On Wed, Nov 30, 2016 at 09:41:26PM +0100, Jernej Škrabec wrote:
> >>  > > > > The only
> >>  > > > > code left from you is for DE2. HDMI stuff is basically copied from
> >>  > > > > Rockhip
> >>  > > > > driver (including EDID reading), TCON code is now reverted to the same
> >>  > > > > as
> >>  > > > > it is in sunxi_display.c. I think it is worth to take a look at EDID
> >>  > > > > code
> >>  > > > > and compare it.
> >>  > > >
> >>  > > > So is the TCON of DE 2.0 identical to the original TCON?
> >>  > > >
> >>  > > > If so, we should reuse sun4i-tcon ...
> >>  > >
> >>  > > Well, TCON is splitted in two parts (two base addresses), one for HDMI and
> >>  > > one for TV. However, register offsets are same as before, so I guess
> >>  > > driver reusage make sense. I think that there are few additional
> >>  > > registers, but they can be ignored for simplefb.
> >>  >
> >>  > The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
> >>  > clock and I/O area.
> >>  >
> >>
> >>  True, H3 user manual can be misleading sometimes. But this doesn't change the
> >>  fact that TCON0 has same register offsets with same meaning.
> >
> > Then yes, we should definitely share the drivers too. So, in the end,
> > the only thing that is actually new is the display-engine?
> 
> And HDMI PHY on H3 ;-)

Yes, and that one :)

> In my opinion, we should just put sun8i-de2-drm related code into
> drivers/gpu/drm/sun4i/ .  (Or rename the directory to sunxi)

We should definitely reuse the drivers that are already in there for
the TCON and HDMI parts.

I'd have to look at the exact amount of code that would be needed to
support the new display engine, but I guess if it's big, then a
separate folder makes sense, if it isn't, then putting it in sun4i
makes sense (but I'm reluctant to renaming it to sunxi).

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[Chen-Yu Tsai]

On Mon, Nov 28, 2016 at 5:59 PM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
> As there's currently a fork of U-Boot which provides simplefb support

Please add it when its finalized...

> for H3, a simplefb node can be added to the device tree.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
>
> I'm still not sure which pipeline should I use.

You are supposed to add _all_ the pipelines that are available and
supported by U-boot. U-boot is then supposed to enable and update
the one it set up.

ChenYu

>
> And, it seems that HDMI Slow Clock is not needed?
>
> (seems that it's only for EDID, but simplefb won't use EDID)
>
>  arch/arm/boot/dts/sun8i-h3.dtsi | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 75a8654..cacc8dd 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -50,6 +50,22 @@
>  / {
>         interrupt-parent = <&gic>;
>
> +       chosen {
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               ranges;
> +
> +               simplefb_hdmi: framebuffer@0 {
> +                       compatible = "allwinner,simple-framebuffer",
> +                                    "simple-framebuffer";
> +                       allwinner,pipeline = "de0-lcd0-hdmi";
> +                       clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_BUS_DE>,
> +                                <&ccu CLK_BUS_HDMI>, <&ccu CLK_DE>,
> +                                <&ccu CLK_TCON0>, <&ccu CLK_HDMI>;
> +                       status = "disabled";
> +               };
> +       };
> +
>         cpus {
>                 #address-cells = <1>;
>                 #size-cells = <0>;
> --
> 2.10.2
>

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[Chen-Yu Tsai]

On Mon, Nov 28, 2016 at 6:19 PM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
>
>
> 28.11.2016, 18:07, "Chen-Yu Tsai" <wens@csie.org>:
>> On Mon, Nov 28, 2016 at 5:59 PM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
>>>  As there's currently a fork of U-Boot which provides simplefb support
>>
>> Please add it when its finalized...
>>
>>>  for H3, a simplefb node can be added to the device tree.
>>>
>>>  Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>>  ---
>>>
>>>  I'm still not sure which pipeline should I use.
>>
>> You are supposed to add _all_ the pipelines that are available and
>> supported by U-boot. U-boot is then supposed to enable and update
>> the one it set up.
>
> I mean the pipeline string ;-)

Looks good to me. There's no separate frontend/backend in DE 2.0.

ChenYu

>
>>
>> ChenYu
>>
>>>  And, it seems that HDMI Slow Clock is not needed?
>>>
>>>  (seems that it's only for EDID, but simplefb won't use EDID)
>>>
>>>   arch/arm/boot/dts/sun8i-h3.dtsi | 16 ++++++++++++++++
>>>   1 file changed, 16 insertions(+)
>>>
>>>  diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>  index 75a8654..cacc8dd 100644
>>>  --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>  +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>  @@ -50,6 +50,22 @@
>>>   / {
>>>          interrupt-parent = <&gic>;
>>>
>>>  + chosen {
>>>  + #address-cells = <1>;
>>>  + #size-cells = <1>;
>>>  + ranges;
>>>  +
>>>  + simplefb_hdmi: framebuffer@0 {
>>>  + compatible = "allwinner,simple-framebuffer",
>>>  + "simple-framebuffer";
>>>  + allwinner,pipeline = "de0-lcd0-hdmi";
>>>  + clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_BUS_DE>,
>>>  + <&ccu CLK_BUS_HDMI>, <&ccu CLK_DE>,
>>>  + <&ccu CLK_TCON0>, <&ccu CLK_HDMI>;
>>>  + status = "disabled";
>>>  + };
>>>  + };
>>>  +
>>>          cpus {
>>>                  #address-cells = <1>;
>>>                  #size-cells = <0>;
>>>  --
>>>  2.10.2
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3

[Maxime Ripard]

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

On Mon, Nov 28, 2016 at 06:24:24PM +0800, Chen-Yu Tsai wrote:
> On Mon, Nov 28, 2016 at 6:19 PM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
> >
> >
> > 28.11.2016, 18:07, "Chen-Yu Tsai" <wens@csie.org>:
> >> On Mon, Nov 28, 2016 at 5:59 PM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
> >>>  As there's currently a fork of U-Boot which provides simplefb support
> >>
> >> Please add it when its finalized...
> >>
> >>>  for H3, a simplefb node can be added to the device tree.
> >>>
> >>>  Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >>>  ---
> >>>
> >>>  I'm still not sure which pipeline should I use.
> >>
> >> You are supposed to add _all_ the pipelines that are available and
> >> supported by U-boot. U-boot is then supposed to enable and update
> >> the one it set up.
> >
> > I mean the pipeline string ;-)
> 
> Looks good to me. There's no separate frontend/backend in DE 2.0.

It looks good to me too.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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