Thread (47 messages) 47 messages, 4 authors, 2017-06-07

[linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC

From: icenowy@aosc.io (Icenowy Zheng)
Date: 2017-05-23 12:56:30
Also in: dri-devel, linux-clk, linux-devicetree, lkml


? 2017?5?23? GMT+08:00 ??8:53:21, Maxime Ripard [off-list ref] ??:
On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej ?krabec wrote:
quoted
Hi,

Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai napisal(a):
quoted
On Sat, May 20, 2017 at 2:23 AM, Jernej ?krabec
[off-list ref] 
quoted
wrote:
quoted
quoted
Hi,

Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng
napisal(a):
quoted
quoted
quoted
quoted
? 2017?5?20? GMT+08:00 ??2:03:30, Maxime Ripard
<maxime.ripard@free-
quoted
quoted
quoted
electrons.com> ??:
quoted
quoted
On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote:
quoted
Allwinner H3 features a TV encoder similar to the one in
earlier
quoted
quoted
quoted
quoted
quoted
SoCs,
quoted
but with some different points about clocks:
- It has a mod clock and a bus clock.
- The mod clock must be at a fixed rate to generate signal.
Why?
It's experiment result by Jernej.

The clock rates in BSP kernel is also specially designed
(PLL_DE at 432MHz) in order to be able to feed the TVE.
My experiments and search through BSP code showed that TVE seems
to have
quoted
quoted
quoted
additional fixed predivider 8. So if you want to generate 27 MHz
clock,
quoted
quoted
quoted
unit has to be feed with 216 MHz.

TVE has only one PLL source PLL_DE. And since 216 MHz is a bit
low for
quoted
quoted
quoted
DE2,
BSP defaults to 432 MHz for PLL_DE and use divider 2 to generate
216 MHz.
quoted
quoted
quoted
This clock is then divided by 8 internaly to get final 27 MHz.

Please note that I don't have any hard evidence to support that,
only
quoted
quoted
quoted
experimental data. However, only that explanation make sense to
me.
quoted
quoted
quoted
BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both
use 27 MHz
quoted
quoted
quoted
base clock. Further experiments are needed to check if there is
any
quoted
quoted
quoted
possibility to have other resolutions by manipulating clocks and
give
quoted
quoted
quoted
other proper settings. I plan to do that, but not in very near
future.
quoted
quoted
You only have composite video output, and those are the only 2
standard
quoted
quoted
resolutions that make any sense.
Right, other resolutions are for VGA.

Anyway, I did some more digging in A10 and R40 datasheets. I think
that H3 TVE 
quoted
unit is something in between. R40 TVE has a setting to select "up
sample".

That might be just another translation of oversampling :)

I didn't know it could be applied to composite signals though, but I
guess this is just another analog signal after all.
quoted
Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP driver
on R40 
quoted
has this setting enabled only for PAL and NTSC and it is always 216
MHz. I 
quoted
think that H3 may have this hardwired to 216 MHz and this would be
the reason 
quoted
why 216 MHz is needed.

Has anyone else any better explanation?
That's already a pretty good one.

Either way, wether this is upsampling, oversampling or just a
pre-divider, this can and should be dealt with in the mode_set
callback, and not in the probe.
What should we do for this?

Add a hook in TCON driver and let TVE driver affect the clock value (*16, as the dotclock is halfed)?
Thanks!
Maxime
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help