Message-ID: <20170523125321.t7y7yfrrfokpkzgd@flea.home>
Date:   Tue, 23 May 2017 14:53:21 +0200
From:   Maxime Ripard <maxime.ripard@...e-electrons.com>
To:     Jernej Škrabec <jernej.skrabec@...l.net>
Cc:     linux-sunxi@...glegroups.com, wens@...e.org,
        Icenowy Zheng <icenowy@...c.io>,
        Rob Herring <robh+dt@...nel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        devicetree <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-clk <linux-clk@...r.kernel.org>
Subject: Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for
 the TV encoder in H3 SoC

On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej Škrabec wrote:
> Hi,
> 
> Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai napisal(a):
> > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec <jernej.skrabec@...l.net> 
> wrote:
> > > Hi,
> > > 
> > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a):
> > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard <maxime.ripard@...e-
> > > 
> > > electrons.com> 写到:
> > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote:
> > >> >> Allwinner H3 features a TV encoder similar to the one in earlier
> > >> >
> > >> >SoCs,
> > >> >
> > >> >> 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
> > > additional fixed predivider 8. So if you want to generate 27 MHz clock,
> > > 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
> > > DE2,
> > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to generate 216 MHz.
> > > 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
> > > experimental data. However, only that explanation make sense to me.
> > > 
> > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both use 27 MHz
> > > base clock. Further experiments are needed to check if there is any
> > > possibility to have other resolutions by manipulating clocks and give
> > > other proper settings. I plan to do that, but not in very near future.
> > 
> > You only have composite video output, and those are the only 2 standard
> > 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 
> 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.

> 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 216 MHz. I 
> think that H3 may have this hardwired to 216 MHz and this would be 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.

Thanks!
Maxime

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

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)

Powered by blists - more mailing lists