From mboxrd@z Thu Jan 1 00:00:00 1970 From: icenowy-h8G6r0blFSE@public.gmane.org Subject: Re: Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC Date: Thu, 01 Jun 2017 22:11:14 +0800 Message-ID: <715e6ab52d8aa0032c9759393ace20dc@aosc.io> References: <20170517164354.16399-1-icenowy@aosc.io> <1958057.WDKm0nQKgW@jernej-laptop> <3164416.5xR36OcyjH@jernej-laptop> <20170523125321.t7y7yfrrfokpkzgd@flea.home> <98c3572beee0a81755994b4bdc508b18@aosc.io> <20170524073019.bl6rojc2srrigalp@flea.home> <98558BA2-BC99-4D0A-A045-571C643875C5@aosc.io> <20170531184306.hzu2em35vr4qi4un@flea.lan> Reply-To: icenowy-h8G6r0blFSE@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: <20170531184306.hzu2em35vr4qi4un-ZC1Zs529Oq4@public.gmane.org> List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org Cc: =?UTF-8?Q?Jernej_=C5=A0krabec?= , linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, wens-jdAy2FN1RRM@public.gmane.org, Rob Herring , dri-devel , devicetree , linux-arm-kernel , linux-kernel , linux-clk List-Id: devicetree@vger.kernel.org =E5=9C=A8 2017-06-01 02:43=EF=BC=8CMaxime Ripard =E5=86=99=E9=81=93=EF=BC= =9A > On Wed, May 24, 2017 at 04:25:46PM +0800, Icenowy Zheng wrote: >>=20 >>=20 >> =E4=BA=8E 2017=E5=B9=B45=E6=9C=8824=E6=97=A5 GMT+08:00 =E4=B8=8B=E5=8D= =883:30:19, Maxime Ripard=20 >> =E5=86=99=E5=88=B0: >> >On Tue, May 23, 2017 at 09:00:59PM +0800, icenowy-h8G6r0blFSE@public.gmane.org wrote: >> >> =E5=9C=A8 2017-05-23 20:53=EF=BC=8CMaxime Ripard =E5=86=99=E9=81=93= =EF=BC=9A >> >> > On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej =C5=A0krabec 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 =C5=A0krabec >> > >> >> > > wrote: >> >> > > > > Hi, >> >> > > > > >> >> > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng >> >napisal(a): >> >> > > > >> =E4=BA=8E 2017=E5=B9=B45=E6=9C=8820=E6=97=A5 GMT+08:00 =E4= =B8=8A=E5=8D=882:03:30, Maxime Ripard >> >> >> > > > > >> >> > > > > electrons.com> =E5=86=99=E5=88=B0: >> >> > > > >> >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. >> >> >> >> 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. >>=20 >> No, I still think it goes to the TVE as: >>=20 >> 1. it's named TVE in datasheet. >=20 > Feel free to come up with a better, more sensible explanation? >=20 >> 2. Generating signal with such a low resolution but such >> a high dotclock is not a good situation. >=20 > 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. So we should create a clock with divider in TVE, and feed it to TCON. >=20 > Maxime >=20 > -- > Maxime Ripard, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com --=20 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 e= mail to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout.