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

[Maxime Ripard]

On Sun, Jun 04, 2017 at 10:29:29PM +0800, icen...@aosc.io wrote:
> 在 2017-05-24 15:30，Maxime Ripard 写道：
> > On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
> > > 在 2017-05-23 20:53，Maxime Ripard 写道：
> > > > 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 
> > > > > > 
> > > > > 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 
> > > > > > >>  > > > > > >
> > > > > > > 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.
> > > 
> > > 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.
> > 
> > However, the TV encoder has a constraint on that clock rate. This can
> > be easily implemented using a custom encoder state where you'd set the
> > multiplier to set on that clock, and the TCON will use it.
> 
> P.S. how to do such a custom state?
> 
> Should I do the multiplying in sun4i_tv_mode_to_drm_mode?

You have an example of that in ebd14afe8fa7, but it basically boils
down to:
  - Create a structure subclassing drm_connector_state
  - Adding your own reset and atomic_duplicate_state callback
  - In the atomic_check, change the state to set the pre-divider, and
then use it in TCON's mode_set.

Maxime

-- 
Maxime Ripard, Free 

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

[Maxime Ripard]

On Sun, Jun 04, 2017 at 10:29:29PM +0800, icen...@aosc.io wrote:
> 在 2017-05-24 15:30，Maxime Ripard 写道：
> > On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
> > > 在 2017-05-23 20:53，Maxime Ripard 写道：
> > > > 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 
> > > > > > 
> > > > > 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 
> > > > > > >>  > > > > > >
> > > > > > > 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.
> > > 
> > > 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.
> > 
> > However, the TV encoder has a constraint on that clock rate. This can
> > be easily implemented using a custom encoder state where you'd set the
> > multiplier to set on that clock, and the TCON will use it.
> 
> P.S. how to do such a custom state?
> 
> Should I do the multiplying in sun4i_tv_mode_to_drm_mode?

You have an example of that in ebd14afe8fa7, but it basically boils
down to:
  - Create a structure subclassing drm_connector_state
  - Adding your own reset and atomic_duplicate_state callback
  - In the atomic_check, change the state to set the pre-divider, and
then use it in TCON's mode_set.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel 

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

[icenowy]

在 2017-05-24 15:30，Maxime Ripard 写道：

On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:

在 2017-05-23 20:53，Maxime Ripard 写道：
> 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 
> > 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  > > >
> > > > 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.

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.

However, the TV encoder has a constraint on that clock rate. This can
be easily implemented using a custom encoder state where you'd set the
multiplier to set on that clock, and the TCON will use it.


P.S. how to do such a custom state?

Should I do the multiplying in sun4i_tv_mode_to_drm_mode?



Maxime

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[icenowy]

在 2017-05-24 15:30，Maxime Ripard 写道：

On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:

在 2017-05-23 20:53，Maxime Ripard 写道：
> 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 
> > 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  > > >
> > > > 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.

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.

However, the TV encoder has a constraint on that clock rate. This can
be easily implemented using a custom encoder state where you'd set the
multiplier to set on that clock, and the TCON will use it.


P.S. how to do such a custom state?

Should I do the multiplying in sun4i_tv_mode_to_drm_mode?



Maxime

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Maxime Ripard]

On Thu, Jun 01, 2017 at 10:11:14PM +0800, icen...@aosc.io wrote:
> 在 2017-06-01 02:43，Maxime Ripard 写道：
> > On Wed, May 24, 2017 at 04:25:46PM +0800, Icenowy Zheng wrote:
> > > 
> > > 
> > > 于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard
> > >  写到:
> > > >On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
> > > >> 在 2017-05-23 20:53，Maxime Ripard 写道：
> > > >> > 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
> > > >
> > > >> > > 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
> > > > > > >> > > > >
> > > >> > > > > 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.
> > > >>
> > > >> 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?
> > 
> > > 2. Generating signal with such a low resolution but such
> > > a high dotclock is not a good 

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

[Maxime Ripard]

On Thu, Jun 01, 2017 at 10:11:14PM +0800, icen...@aosc.io wrote:
> 在 2017-06-01 02:43，Maxime Ripard 写道：
> > On Wed, May 24, 2017 at 04:25:46PM +0800, Icenowy Zheng wrote:
> > > 
> > > 
> > > 于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard
> > >  写到:
> > > >On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
> > > >> 在 2017-05-23 20:53，Maxime Ripard 写道：
> > > >> > 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
> > > >
> > > >> > > 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
> > > > > > >> > > > >
> > > >> > > > > 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.
> > > >>
> > > >> 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?
> > 
> > > 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 

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

[icenowy]

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

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



于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard 
 写到:

>On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
>> 在 2017-05-23 20:53，Maxime Ripard 写道：
>> > 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
>
>> > > 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
>> > > > >
>> > > > > 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.
>>
>> 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?


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.

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



Maxime

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

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

[icenowy]

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

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



于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard 
 写到:

>On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
>> 在 2017-05-23 20:53，Maxime Ripard 写道：
>> > 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
>
>> > > 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
>> > > > >
>> > > > > 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.
>>
>> 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?


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.

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



Maxime

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

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

[Maxime Ripard]

On Wed, May 24, 2017 at 04:25:46PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard 
>  写到:
> >On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
> >> 在 2017-05-23 20:53，Maxime Ripard 写道：
> >> > 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
> >
> >> > > 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
> > >> > > > >
> >> > > > > 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.
> >> 
> >> 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?

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

Maxime

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


signature.asc
Description: PGP signature

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

[Maxime Ripard]

On Wed, May 24, 2017 at 04:25:46PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard 
>  写到:
> >On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
> >> 在 2017-05-23 20:53，Maxime Ripard 写道：
> >> > 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
> >
> >> > > 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
> > >> > > > >
> >> > > > > 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.
> >> 
> >> 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?

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

Maxime

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


signature.asc
Description: PGP signature

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

[Jernej Škrabec]

Hi,

Dne sreda, 24. maj 2017 ob 10:25:46 CEST je Icenowy Zheng napisal(a):
> 于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard  写到:
> >On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
> >> 在 2017-05-23 20:53，Maxime Ripard 写道：
> >> 
> >> > 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
> >
> >
> >
> >> > > 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
> >
> > >
> >> > > > > 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.
> >> 
> >> 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.

If we are talking about HW divider, it is 8 (216 / 27 = 8).

Slightly offtopic, reason why DE2 is hardcoded to 432 might be that for 4K 
resolution you need at least 297 MHz. So next dividable frequency is taken 
(432 MHz). That way you can have 4K HDMI display and composite TV connected at 
the same time, although this sounds a bit weird.

Best regards,
Jernej

> >
> >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.
> 2. Generating signal with such a low resolution but such
> a high dotclock is not a good situation.
> 
> >However, the TV encoder has a constraint on that clock rate. This can
> >be easily implemented using a custom encoder state where you'd set the
> >multiplier to set on 

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

[Jernej Škrabec]

Hi,

Dne sreda, 24. maj 2017 ob 10:25:46 CEST je Icenowy Zheng napisal(a):
> 于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard  写到:
> >On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
> >> 在 2017-05-23 20:53，Maxime Ripard 写道：
> >> 
> >> > 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
> >
> >
> >
> >> > > 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
> >
> > >
> >> > > > > 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.
> >> 
> >> 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.

If we are talking about HW divider, it is 8 (216 / 27 = 8).

Slightly offtopic, reason why DE2 is hardcoded to 432 might be that for 4K 
resolution you need at least 297 MHz. So next dividable frequency is taken 
(432 MHz). That way you can have 4K HDMI display and composite TV connected at 
the same time, although this sounds a bit weird.

Best regards,
Jernej

> >
> >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.
> 2. Generating signal with such a low resolution but such
> a high dotclock is not a good situation.
> 
> >However, the TV encoder has a constraint on that clock rate. This can
> >be easily implemented using a custom encoder state where you'd set the
> >multiplier to set on that clock, and the TCON will use it.
> >
> >Maxime

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

[Icenowy Zheng]

于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard 
 写到:
>On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
>> 在 2017-05-23 20:53，Maxime Ripard 写道：
>> > 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
>
>> > > 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
>> > > > >
>> > > > > 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.
>> 
>> 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.
2. Generating signal with such a low resolution but such
a high dotclock is not a good situation.

>
>However, the TV encoder has a constraint on that clock rate. This can
>be easily implemented using a custom encoder state where you'd set the
>multiplier to set on that clock, and the TCON will use it.
>
>Maxime

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

[Icenowy Zheng]

于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard 
 写到:
>On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
>> 在 2017-05-23 20:53，Maxime Ripard 写道：
>> > 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
>
>> > > 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
>> > > > >
>> > > > > 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.
>> 
>> 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.
2. Generating signal with such a low resolution but such
a high dotclock is not a good situation.

>
>However, the TV encoder has a constraint on that clock rate. This can
>be easily implemented using a custom encoder state where you'd set the
>multiplier to set on that clock, and the TCON will use it.
>
>Maxime

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

[Maxime Ripard]

On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
> 在 2017-05-23 20:53，Maxime Ripard 写道：
> > 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 
> > > > 
> > > 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  > > > >
> > > > > 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.
> 
> 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.

However, the TV encoder has a constraint on that clock rate. This can
be easily implemented using a custom encoder state where you'd set the
multiplier to set on that clock, and the TCON will use it.

Maxime

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


signature.asc
Description: PGP signature

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

[Maxime Ripard]

On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
> 在 2017-05-23 20:53，Maxime Ripard 写道：
> > 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 
> > > > 
> > > 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  > > > >
> > > > > 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.
> 
> 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.

However, the TV encoder has a constraint on that clock rate. This can
be easily implemented using a custom encoder state where you'd set the
multiplier to set on that clock, and the TCON will use it.

Maxime

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


signature.asc
Description: PGP signature

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

[icenowy]

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

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


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.



Thanks!
Maxime

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

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

[icenowy]

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

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


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.



Thanks!
Maxime

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

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

[Icenowy Zheng]

于 2017年5月23日 GMT+08:00 下午8:53:21, Maxime Ripard 
 写到:
>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
> 
>> 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
>> > > 
>> > > 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

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

[Icenowy Zheng]

于 2017年5月23日 GMT+08:00 下午8:53:21, Maxime Ripard 
 写到:
>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
> 
>> 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
>> > > 
>> > > 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

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

[Maxime Ripard]

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


signature.asc
Description: PGP signature

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

[Maxime Ripard]

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


signature.asc
Description: PGP signature

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

[Jernej Škrabec]

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

Best regards,
Jernej

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

[Jernej Škrabec]

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

Best regards,
Jernej

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

[Chen-Yu Tsai]

On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec  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  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.

ChenYu

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

[Chen-Yu Tsai]

On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec  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  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.

ChenYu

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

[Jernej Škrabec]

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  写到:
> >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.

Best regards,
Jernej

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

[Jernej Škrabec]

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  写到:
> >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.

Best regards,
Jernej