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

From: Maxime Ripard <hidden>
Date: 2017-06-02 22:21:52
Also in: dri-devel, linux-arm-kernel, linux-clk, lkml

On Thu, Jun 01, 2017 at 10:11:14PM +0800, icenowy-h8G6r0blFSE@public.gmane.org wrote:

在 2017-06-01 02:43，Maxime Ripard 写道：

quoted

On Wed, May 24, 2017 at 04:25:46PM +0800, Icenowy Zheng wrote:

quoted


于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard
[off-list ref] 写到:

quoted

On Tue, May 23, 2017 at 09:00:59PM +0800, icenowy-h8G6r0blFSE@public.gmane.org wrote:

quoted

在 2017-05-23 20:53，Maxime Ripard 写道：

quoted

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

Hi,

Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng

napisal(a):

quoted

quoted
quoted
quoted
quoted
quoted
于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard

<maxime.ripard@free-

quoted

quoted
quoted
quoted
quoted
electrons.com> 写到:
quoted
quoted
On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng

wrote:

quoted

quoted
quoted
quoted
quoted
quoted
quoted
quoted
Allwinner H3 features a TV encoder similar to the one in

earlier

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.

quoted

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

additional fixed predivider 8. So if you want to generate 27

MHz clock,

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

DE2,
BSP defaults to 432 MHz for PLL_DE and use divider 2 to

generate 216 MHz.

quoted

This clock is then divided by 8 internaly to get final 27

MHz.

quoted

Please note that I don't have any hard evidence to support

that, only

quoted

experimental data. However, only that explanation make sense

to me.

quoted

BTW, BSP H3/H5 TV driver supports only PAL and NTSC which

both use 27 MHz

quoted

base clock. Further experiments are needed to check if there

is any

quoted

possibility to have other resolutions by manipulating clocks

and give

quoted

other proper settings. I plan to do that, but not in very

near future.

quoted

You only have composite video output, and those are the only 2

standard

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

quoted

that H3 TVE
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

quoted

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
has this setting enabled only for PAL and NTSC and it is always

quoted

MHz. I
think that H3 may have this hardwired to 216 MHz and this would

be

quoted

the reason
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.

I got a better idea -- let TVE driver have the CLK_TVE as an
input and create a subclock output with divider 16, and feed this
subclock to TCON lcd-ch1.

This is a model of the real hardware -- the clock divider is in
TVE, not TCON.

That's definitely not a good representation of the hardware. There's
one clock, it goes to the TCON, period.

No, I still think it goes to the TVE as:

1. it's named TVE in datasheet.

Feel free to come up with a better, more sensible explanation?

quoted

2. Generating signal with such a low resolution but such
a high dotclock is not a good situation.

What? What do you mean? The pixel clock is 27MHz, I'm pretty sure we
agree on that.

Yes, so I don't think the TCON code should set the clock to any value
rather than 27MHz.

The pixel clock that matters is what is output on the TV
connector. The intermediate pixel clock don't matter, and in this
case, it seems to be clearly the case that the TCON needs a higher
clock, then let's give it a higher clock.

So we should create a clock with divider in TVE, and feed it to TCON.

I'm sorry, but this still doesn't make much sense. The clock is
provided by the TCON, and there's a divider in the TVE, it's as simple
as that, unless you can provide some other meaningful explanation.

That the TV encoder feeds a clock that would drive the TCON is already
suspicious, and all the precedent designs indicate that this is not
what is going on. Both the explanation and the design is much simpler
that way.

Sometimes the Occam's razor is a better justification than a label on
a datasheet.

Maxime

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

-- 
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.

Attachments

signature.asc [application/pgp-signature] 801 bytes

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help