2016-11-30 19:14:16

by Jernej Škrabec

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

Dne četrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng napisal(a):
> 2016年12月1日 02:49于 Jernej Skrabec <[email protected]>写道:
>
> > 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 <[email protected]> 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
> > [email protected]. For more options, visit
> > https://groups.google.com/d/optout.

Best regards,
Jernej Škrabec


2016-11-30 19:37:36

by Jean-Francois Moine

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

On Wed, 30 Nov 2016 20:14:11 +0100
Jernej Škrabec <[email protected]> wrote:

> Dne četrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng napisal(a):
> > 2016年12月1日 02:49于 Jernej Skrabec <[email protected]>写道:
> >
> > > 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 <[email protected]> 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/

2016-11-30 20:41:32

by Jernej Škrabec

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

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 <[email protected]> wrote:
> > Dne četrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng
napisal(a):
> > > 2016年12月1日 02:49于 Jernej Skrabec <[email protected]>写道:
> > >
> > > > 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 <[email protected]> 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/



2016-11-30 20:53:14

by Maxime Ripard

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

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


Attachments:
(No filename) (1.27 kB)
signature.asc (801.00 B)
Download all attachments