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 [off-list ref] wrote:

quoted

Dne četrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng 

napisal(a):

quoted

quoted

2016年12月1日 02:49于 Jernej Skrabec [off-list ref]写道：

quoted

Hi Jean-François,

Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-François
Moine

napisala:

quoted

quoted

quoted

On Tue, 29 Nov 2016 22:59:32 +0100

Maxime Ripard [off-list ref] wrote:

quoted

quoted

quoted

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)

quoted

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.

quoted

quoted

quoted

quoted

quoted

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!

quoted

quoted

quoted

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/

-- 
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.