于 2017年5月23日 GMT+08:00 下午8:53:21, Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx> 写到: >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@xxxxxxxx> >> 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@free- >> > > >> > > 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. 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
