From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938611AbdEXHaZ (ORCPT ); Wed, 24 May 2017 03:30:25 -0400 Received: from mail.free-electrons.com ([62.4.15.54]:58633 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751871AbdEXHaW (ORCPT ); Wed, 24 May 2017 03:30:22 -0400 Date: Wed, 24 May 2017 09:30:19 +0200 From: Maxime Ripard To: icenowy@aosc.io Cc: Jernej =?utf-8?Q?=C5=A0krabec?= , linux-sunxi@googlegroups.com, wens@csie.org, Rob Herring , dri-devel , devicetree , linux-arm-kernel , linux-kernel , linux-clk Subject: Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC Message-ID: <20170524073019.bl6rojc2srrigalp@flea.home> References: <20170517164354.16399-1-icenowy@aosc.io> <1958057.WDKm0nQKgW@jernej-laptop> <3164416.5xR36OcyjH@jernej-laptop> <20170523125321.t7y7yfrrfokpkzgd@flea.home> <98c3572beee0a81755994b4bdc508b18@aosc.io> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nh63lsvlsuca7ikb" Content-Disposition: inline In-Reply-To: <98c3572beee0a81755994b4bdc508b18@aosc.io> User-Agent: NeoMutt/20170428 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --nh63lsvlsuca7ikb Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 23, 2017 at 09:00:59PM +0800, icenowy@aosc.io wrote: > =E5=9C=A8 2017-05-23 20:53=EF=BC=8CMaxime Ripard =E5=86=99=E9=81=93=EF=BC= =9A > > On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej =C5=A0krabec wrote: > > > Hi, > > >=20 > > > Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai napisal(a): > > > > On Sat, May 20, 2017 at 2:23 AM, Jernej =C5=A0krabec > > > wrote: > > > > > Hi, > > > > > > > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal= (a): > > > > >> =E4=BA=8E 2017=E5=B9=B45=E6=9C=8820=E6=97=A5 GMT+08:00 =E4=B8=8A= =E5=8D=882:03:30, Maxime Ripard > > > > > > > > > electrons.com> =E5=86=99=E5=88=B0: > > > > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: > > > > >> >> Allwinner H3 features a TV encoder similar to the one in earl= ier > > > > >> > > > > > >> >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 lo= w 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 m= e. > > > > > > > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both us= e 27 MHz > > > > > base clock. Further experiments are needed to check if there is a= ny > > > > > possibility to have other resolutions by manipulating clocks and = give > > > > > other proper settings. I plan to do that, but not in very near fu= ture. > > > > > > > > You only have composite video output, and those are the only 2 stan= dard > > > > resolutions that make any sense. > > >=20 > > > Right, other resolutions are for VGA. > > >=20 > > > 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". > >=20 > > That might be just another translation of oversampling :) > >=20 > > I didn't know it could be applied to composite signals though, but I > > guess this is just another analog signal after all. > >=20 > > > 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. > > >=20 > > > Has anyone else any better explanation? > >=20 > > That's already a pretty good one. > >=20 > > 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. >=20 > 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. >=20 > 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 --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --nh63lsvlsuca7ikb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJZJTaLAAoJEBx+YmzsjxAgKKQP/3jEdTA+FMluj1ZbFxPfWx5J 9hovicyPslTagdaqTUTeX9H/+g/3f1ZkGxaU4ASVo/rmkIlRQp5D3EgOYy+IK17c DmWbPWDlZBS0UWrGzNTFB7wPZG9HFZmcrJ1p/UU1MG3nesOHf9yT0zzfjl5sTp25 1NMqIag0dmHKIqBAcYq2iacFxVqu99vgoMGjT9oVaJ4/VuNSd0NgreU2oRrQgBC4 SXJ9gOFIhbLM1JLQLW7Idn+hwx5Itdv8Y2nR0D/eeb1aZBDDPm5IQ/oL84TifZN4 XML8xXQiuTDFlvYZZ8mmcdtXSXjGgHUVSd4xtjC5xdqHxyzrA43rjag0/2+PuJCj B8+eXjWwB1itqfW1tLZoAfjeWF/Ah/dw8DPLIkT+cL35UPgnW5njHnP7JgHD0pWV m4ziCVVlo3skKmsfJtVIsge8BALw8LdvwIHkoH9QKH2D6a6HLA7coCy6kEBVrf/z 3EB7sZ5ucP2u7woYeySDZVoDP5FUdABWWEFzn13yEtLNOWu9TwdNAQ5uujEIvad8 /bGEs9PGDske08VnGs+Exy5v97lga5yuK6nMfrh5oHpz288Xire33xcKdhRQ0H09 6jKVXDIFfRj6MQtQDECCeHA0iU/9/dhkYq0KenhFt0l4oNMVU7K+ZWAKupN9y4cD yktaJoGMR4sfqPdVVDzp =8RGh -----END PGP SIGNATURE----- --nh63lsvlsuca7ikb-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Subject: Re: Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC Date: Wed, 24 May 2017 09:30:19 +0200 Message-ID: <20170524073019.bl6rojc2srrigalp@flea.home> References: <20170517164354.16399-1-icenowy@aosc.io> <1958057.WDKm0nQKgW@jernej-laptop> <3164416.5xR36OcyjH@jernej-laptop> <20170523125321.t7y7yfrrfokpkzgd@flea.home> <98c3572beee0a81755994b4bdc508b18@aosc.io> Reply-To: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nh63lsvlsuca7ikb" Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Content-Disposition: inline In-Reply-To: <98c3572beee0a81755994b4bdc508b18-h8G6r0blFSE@public.gmane.org> List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: icenowy-h8G6r0blFSE@public.gmane.org Cc: Jernej =?utf-8?Q?=C5=A0krabec?= , linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, wens-jdAy2FN1RRM@public.gmane.org, Rob Herring , dri-devel , devicetree , linux-arm-kernel , linux-kernel , linux-clk List-Id: devicetree@vger.kernel.org --nh63lsvlsuca7ikb Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 23, 2017 at 09:00:59PM +0800, icenowy-h8G6r0blFSE@public.gmane.org wrote: > =E5=9C=A8 2017-05-23 20:53=EF=BC=8CMaxime Ripard =E5=86=99=E9=81=93=EF=BC= =9A > > On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej =C5=A0krabec wrote: > > > Hi, > > >=20 > > > Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai napisal(a): > > > > On Sat, May 20, 2017 at 2:23 AM, Jernej =C5=A0krabec > > > wrote: > > > > > Hi, > > > > > > > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal= (a): > > > > >> =E4=BA=8E 2017=E5=B9=B45=E6=9C=8820=E6=97=A5 GMT+08:00 =E4=B8=8A= =E5=8D=882:03:30, Maxime Ripard > > > > > > > > > electrons.com> =E5=86=99=E5=88=B0: > > > > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: > > > > >> >> Allwinner H3 features a TV encoder similar to the one in earl= ier > > > > >> > > > > > >> >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 lo= w 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 m= e. > > > > > > > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both us= e 27 MHz > > > > > base clock. Further experiments are needed to check if there is a= ny > > > > > possibility to have other resolutions by manipulating clocks and = give > > > > > other proper settings. I plan to do that, but not in very near fu= ture. > > > > > > > > You only have composite video output, and those are the only 2 stan= dard > > > > resolutions that make any sense. > > >=20 > > > Right, other resolutions are for VGA. > > >=20 > > > 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". > >=20 > > That might be just another translation of oversampling :) > >=20 > > I didn't know it could be applied to composite signals though, but I > > guess this is just another analog signal after all. > >=20 > > > 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. > > >=20 > > > Has anyone else any better explanation? > >=20 > > That's already a pretty good one. > >=20 > > 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. >=20 > 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. >=20 > 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 --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --=20 You received this message because you are subscribed to the Google Groups "= linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. --nh63lsvlsuca7ikb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJZJTaLAAoJEBx+YmzsjxAgKKQP/3jEdTA+FMluj1ZbFxPfWx5J 9hovicyPslTagdaqTUTeX9H/+g/3f1ZkGxaU4ASVo/rmkIlRQp5D3EgOYy+IK17c DmWbPWDlZBS0UWrGzNTFB7wPZG9HFZmcrJ1p/UU1MG3nesOHf9yT0zzfjl5sTp25 1NMqIag0dmHKIqBAcYq2iacFxVqu99vgoMGjT9oVaJ4/VuNSd0NgreU2oRrQgBC4 SXJ9gOFIhbLM1JLQLW7Idn+hwx5Itdv8Y2nR0D/eeb1aZBDDPm5IQ/oL84TifZN4 XML8xXQiuTDFlvYZZ8mmcdtXSXjGgHUVSd4xtjC5xdqHxyzrA43rjag0/2+PuJCj B8+eXjWwB1itqfW1tLZoAfjeWF/Ah/dw8DPLIkT+cL35UPgnW5njHnP7JgHD0pWV m4ziCVVlo3skKmsfJtVIsge8BALw8LdvwIHkoH9QKH2D6a6HLA7coCy6kEBVrf/z 3EB7sZ5ucP2u7woYeySDZVoDP5FUdABWWEFzn13yEtLNOWu9TwdNAQ5uujEIvad8 /bGEs9PGDske08VnGs+Exy5v97lga5yuK6nMfrh5oHpz288Xire33xcKdhRQ0H09 6jKVXDIFfRj6MQtQDECCeHA0iU/9/dhkYq0KenhFt0l4oNMVU7K+ZWAKupN9y4cD yktaJoGMR4sfqPdVVDzp =8RGh -----END PGP SIGNATURE----- --nh63lsvlsuca7ikb-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: maxime.ripard@free-electrons.com (Maxime Ripard) Date: Wed, 24 May 2017 09:30:19 +0200 Subject: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC In-Reply-To: <98c3572beee0a81755994b4bdc508b18@aosc.io> References: <20170517164354.16399-1-icenowy@aosc.io> <1958057.WDKm0nQKgW@jernej-laptop> <3164416.5xR36OcyjH@jernej-laptop> <20170523125321.t7y7yfrrfokpkzgd@flea.home> <98c3572beee0a81755994b4bdc508b18@aosc.io> Message-ID: <20170524073019.bl6rojc2srrigalp@flea.home> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, May 23, 2017 at 09:00:59PM +0800, icenowy at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: