Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1643507 > unrolled thread
| Started by | Icenowy Zheng <icenowy@aosc.io> |
|---|---|
| First post | 2017-05-17 18:50 +0200 |
| Last post | 2017-05-17 19:10 +0200 |
| Articles | 20 on this page of 41 — 5 participants |
Back to article view | Back to linux.kernel
[RFC PATCH 00/11] Support for H3 Composite Output support Icenowy Zheng <icenowy@aosc.io> - 2017-05-17 18:50 +0200
[RFC PATCH 11/11] [DO NOT MERGE] ARM: sun8i: h3: enable TV output on Orange Pi PC Icenowy Zheng <icenowy@aosc.io> - 2017-05-17 18:50 +0200
[RFC PATCH 01/11] dt-bindings: update the binding for Allwinner H3 TVE support Icenowy Zheng <icenowy@aosc.io> - 2017-05-17 18:50 +0200
Re: [RFC PATCH 01/11] dt-bindings: update the binding for Allwinner H3 TVE support Icenowy Zheng <icenowy@aosc.io> - 2017-05-19 20:10 +0200
Re: [linux-sunxi] Re: [RFC PATCH 01/11] dt-bindings: update the binding for Allwinner H3 TVE support Chen-Yu Tsai <wens@csie.org> - 2017-05-20 04:10 +0200
Re: [RFC PATCH 01/11] dt-bindings: update the binding for Allwinner H3 TVE support Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-05-19 20:10 +0200
[RFC PATCH 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2 Icenowy Zheng <icenowy@aosc.io> - 2017-05-17 18:50 +0200
Re: [RFC PATCH 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2 Icenowy Zheng <icenowy@aosc.io> - 2017-05-19 20:10 +0200
Re: [RFC PATCH 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2 Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-05-24 10:20 +0200
Re: [RFC PATCH 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2 Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-05-19 20:10 +0200
[RFC PATCH 05/11] drm: sun4i: add compatible for H3 display engine Icenowy Zheng <icenowy@aosc.io> - 2017-05-17 18:50 +0200
[RFC PATCH 02/11] drm: sun4i: add support for H3 mixers Icenowy Zheng <icenowy@aosc.io> - 2017-05-17 18:50 +0200
Re: [linux-sunxi] Re: [RFC PATCH 02/11] drm: sun4i: add support for H3 mixers Icenowy Zheng <icenowy@aosc.io> - 2017-05-19 20:00 +0200
Re: [linux-sunxi] Re: [RFC PATCH 02/11] drm: sun4i: add support for H3 mixers Jernej Škrabec <jernej.skrabec@siol.net> - 2017-05-19 20:20 +0200
Re: [RFC PATCH 02/11] drm: sun4i: add support for H3 mixers Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-05-19 20:00 +0200
[RFC PATCH 04/11] drm: sun4i: add support for H3's TCON0/1 Icenowy Zheng <icenowy@aosc.io> - 2017-05-17 19:00 +0200
[RFC PATCH 09/11] clk: sunxi-ng: export CLK_PLL_DE for H3 Icenowy Zheng <icenowy@aosc.io> - 2017-05-17 19:10 +0200
[RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE Icenowy Zheng <icenowy@aosc.io> - 2017-05-17 19:10 +0200
Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE Jernej Škrabec <jernej.skrabec@siol.net> - 2017-05-17 22:30 +0200
Re: [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-05-19 20:10 +0200
Re: [linux-sunxi] Re: [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE Icenowy Zheng <icenowy@aosc.io> - 2017-05-19 20:30 +0200
Re: [linux-sunxi] Re: [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-05-24 10:30 +0200
Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE Chen-Yu Tsai <wens@csie.org> - 2017-05-24 07:30 +0200
Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE Icenowy Zheng <icenowy@aosc.io> - 2017-05-24 07:30 +0200
Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE Icenowy Zheng <icenowy@aosc.io> - 2017-05-24 07:40 +0200
Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE Chen-Yu Tsai <wens@csie.org> - 2017-05-24 07:40 +0200
[RFC PATCH 06/11] drm: sun4i: add color space correction support for DE2 mixer Icenowy Zheng <icenowy@aosc.io> - 2017-05-17 19:10 +0200
Re: [linux-sunxi] [RFC PATCH 06/11] drm: sun4i: add color space correction support for DE2 mixer Jernej Škrabec <jernej.skrabec@siol.net> - 2017-05-17 22:30 +0200
[RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC Icenowy Zheng <icenowy@aosc.io> - 2017-05-17 19:10 +0200
Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-05-19 20:10 +0200
Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC Icenowy Zheng <icenowy@aosc.io> - 2017-05-19 20:10 +0200
Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC Jernej Škrabec <jernej.skrabec@siol.net> - 2017-05-19 20:30 +0200
Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC Chen-Yu Tsai <wens@csie.org> - 2017-05-20 03:40 +0200
Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC Jernej Škrabec <jernej.skrabec@siol.net> - 2017-05-22 20:00 +0200
Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC Icenowy Zheng <icenowy@aosc.io> - 2017-05-23 15:00 +0200
Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-05-23 15:00 +0200
Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC icenowy@aosc.io - 2017-05-23 15:10 +0200
Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-05-24 09:40 +0200
Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC Icenowy Zheng <icenowy@aosc.io> - 2017-05-24 10:30 +0200
Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC Jernej Škrabec <jernej.skrabec@siol.net> - 2017-05-24 17:30 +0200
[RFC PATCH 08/11] clk: sunxi-ng: allow CLK_DE to set CLK_PLL_DE for H3 Icenowy Zheng <icenowy@aosc.io> - 2017-05-17 19:10 +0200
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | Icenowy Zheng <icenowy@aosc.io> |
|---|---|
| Date | 2017-05-19 20:30 +0200 |
| Subject | Re: [linux-sunxi] Re: [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE |
| Message-ID | <tIUP0-5Wm-3@gated-at.bofh.it> |
| In reply to | #1645819 |
于 2017年5月20日 GMT+08:00 上午2:06:16, Maxime Ripard <maxime.ripard@free-electrons.com> 写到:
>On Thu, May 18, 2017 at 12:43:53AM +0800, Icenowy Zheng wrote:
>> As we have already the support for the TV encoder on Allwinner H3,
>add
>> the display engine pipeline device tree nodes to its DTSI file.
>>
>> The H5 pipeline has some differences and will be enabled later.
>>
>> The currently-unused mixer0 and tcon0 are also needed, for the
>> completement of the pipeline.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> arch/arm/boot/dts/sun8i-h3.dtsi | 189
>++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 189 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index b36f9f423c39..20172ef92415 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -41,6 +41,8 @@
>> */
>>
>> #include "sunxi-h3-h5.dtsi"
>> +#include <dt-bindings/clock/sun8i-de2.h>
>> +#include <dt-bindings/reset/sun8i-de2.h>
>>
>> / {
>> cpus {
>> @@ -72,6 +74,193 @@
>> };
>> };
>>
>> + de: display-engine {
>> + compatible = "allwinner,sun8i-h3-display-engine";
>> + allwinner,pipelines = <&mixer0>,
>> + <&mixer1>;
>> + status = "disabled";
>> + };
>> +
>> + soc {
>> + display_clocks: clock@1000000 {
>> + compatible = "allwinner,sun8i-a83t-de2-clk";
>> + reg = <0x01000000 0x100000>;
>> + clocks = <&ccu CLK_BUS_DE>,
>> + <&ccu CLK_DE>;
>> + clock-names = "bus",
>> + "mod";
>> + resets = <&ccu RST_BUS_DE>;
>> + #clock-cells = <1>;
>> + #reset-cells = <1>;
>> + assigned-clocks = <&ccu CLK_DE>;
>> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
>> + assigned-clock-rates = <432000000>;
>
>This shouldn't be set in the DT, but evaluated at runtime when calling
>clk_set_rate.
Nope, DE2 clock doesn't need evalution, as the clock is decoupled with
DE2 mixers' output signal. (Although it seems that SoCs with larger
plane size will use higher clock.)
And setting it to 432MHz is also needed for properly 216MHz clock to TVE.
>
>> + tve0: tv-encoder@1e00000 {
>> + compatible = "allwinner,sun8i-h3-tv-encoder";
>> + reg = <0x01e00000 0x1000>;
>> + clocks = <&ccu CLK_BUS_TVE>, <&ccu CLK_TVE>;
>> + clock-names = "bus", "mod";
>> + resets = <&ccu RST_BUS_TVE>;
>> + status = "disabled";
>> +
>> + assigned-clocks = <&ccu CLK_TVE>;
>> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
>
>Same thing here. clk_set_rate should just do the right thing.
>
>> + assigned-clock-rates = <216000000>;
>
>And why are you setting it in the driver and in the DT?
>
>Maxime
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-05-24 10:30 +0200 |
| Subject | Re: [linux-sunxi] Re: [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE |
| Message-ID | <tKzQ9-8hN-83@gated-at.bofh.it> |
| In reply to | #1645832 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, May 20, 2017 at 02:10:35AM +0800, Icenowy Zheng wrote:
>
>
> 于 2017年5月20日 GMT+08:00 上午2:06:16, Maxime Ripard <maxime.ripard@free-electrons.com> 写到:
> >On Thu, May 18, 2017 at 12:43:53AM +0800, Icenowy Zheng wrote:
> >> As we have already the support for the TV encoder on Allwinner H3,
> >add
> >> the display engine pipeline device tree nodes to its DTSI file.
> >>
> >> The H5 pipeline has some differences and will be enabled later.
> >>
> >> The currently-unused mixer0 and tcon0 are also needed, for the
> >> completement of the pipeline.
> >>
> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >> ---
> >> arch/arm/boot/dts/sun8i-h3.dtsi | 189
> >++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 189 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
> >b/arch/arm/boot/dts/sun8i-h3.dtsi
> >> index b36f9f423c39..20172ef92415 100644
> >> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> >> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> >> @@ -41,6 +41,8 @@
> >> */
> >>
> >> #include "sunxi-h3-h5.dtsi"
> >> +#include <dt-bindings/clock/sun8i-de2.h>
> >> +#include <dt-bindings/reset/sun8i-de2.h>
> >>
> >> / {
> >> cpus {
> >> @@ -72,6 +74,193 @@
> >> };
> >> };
> >>
> >> + de: display-engine {
> >> + compatible = "allwinner,sun8i-h3-display-engine";
> >> + allwinner,pipelines = <&mixer0>,
> >> + <&mixer1>;
> >> + status = "disabled";
> >> + };
> >> +
> >> + soc {
> >> + display_clocks: clock@1000000 {
> >> + compatible = "allwinner,sun8i-a83t-de2-clk";
> >> + reg = <0x01000000 0x100000>;
> >> + clocks = <&ccu CLK_BUS_DE>,
> >> + <&ccu CLK_DE>;
> >> + clock-names = "bus",
> >> + "mod";
> >> + resets = <&ccu RST_BUS_DE>;
> >> + #clock-cells = <1>;
> >> + #reset-cells = <1>;
> >> + assigned-clocks = <&ccu CLK_DE>;
> >> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
> >> + assigned-clock-rates = <432000000>;
> >
> >This shouldn't be set in the DT, but evaluated at runtime when calling
> >clk_set_rate.
>
> Nope, DE2 clock doesn't need evalution, as the clock is decoupled with
> DE2 mixers' output signal. (Although it seems that SoCs with larger
> plane size will use higher clock.)
So it's the display engine that needs that clock to operate properly?
This is the wrong DT node to set that value then. It should be in the
mixer node, or even better in the mixers' driver.
> And setting it to 432MHz is also needed for properly 216MHz clock to
> TVE.
Just like the parenthood, this can and should be evaluated at runtime.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[toc] | [prev] | [next] | [standalone]
| From | Chen-Yu Tsai <wens@csie.org> |
|---|---|
| Date | 2017-05-24 07:30 +0200 |
| Subject | Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE |
| Message-ID | <tKx1U-6lD-5@gated-at.bofh.it> |
| In reply to | #1643522 |
On Thu, May 18, 2017 at 12:43 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> As we have already the support for the TV encoder on Allwinner H3, add
> the display engine pipeline device tree nodes to its DTSI file.
>
> The H5 pipeline has some differences and will be enabled later.
>
> The currently-unused mixer0 and tcon0 are also needed, for the
> completement of the pipeline.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> arch/arm/boot/dts/sun8i-h3.dtsi | 189 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 189 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index b36f9f423c39..20172ef92415 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -41,6 +41,8 @@
> */
>
> #include "sunxi-h3-h5.dtsi"
> +#include <dt-bindings/clock/sun8i-de2.h>
> +#include <dt-bindings/reset/sun8i-de2.h>
>
> / {
> cpus {
> @@ -72,6 +74,193 @@
> };
> };
>
> + de: display-engine {
> + compatible = "allwinner,sun8i-h3-display-engine";
> + allwinner,pipelines = <&mixer0>,
> + <&mixer1>;
> + status = "disabled";
> + };
> +
> + soc {
> + display_clocks: clock@1000000 {
> + compatible = "allwinner,sun8i-a83t-de2-clk";
> + reg = <0x01000000 0x100000>;
> + clocks = <&ccu CLK_BUS_DE>,
> + <&ccu CLK_DE>;
> + clock-names = "bus",
> + "mod";
> + resets = <&ccu RST_BUS_DE>;
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + assigned-clocks = <&ccu CLK_DE>;
> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
> + assigned-clock-rates = <432000000>;
> + };
> +
> + mixer0: mixer@1100000 {
> + compatible = "allwinner,sun8i-h3-de2-mixer0";
> + reg = <0x01100000 0x100000>;
> + clocks = <&display_clocks CLK_BUS_MIXER0>,
> + <&display_clocks CLK_MIXER0>;
> + clock-names = "bus",
> + "mod";
> + resets = <&display_clocks RST_MIXER0>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mixer0_out: port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + mixer0_out_tcon0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&tcon0_in_mixer0>;
> + };
> +
> + mixer0_out_tcon1: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&tcon1_in_mixer0>;
> + };
> + };
> + };
> + };
> +
> + mixer1: mixer@1200000 {
> + compatible = "allwinner,sun8i-h3-de2-mixer1";
> + reg = <0x01200000 0x100000>;
> + clocks = <&display_clocks CLK_BUS_MIXER1>,
> + <&display_clocks CLK_MIXER1>;
> + clock-names = "bus",
> + "mod";
> + resets = <&display_clocks RST_WB>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mixer1_out: port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + mixer1_out_tcon1: endpoint@0 {
> + reg = <0>;
I would prefer if you could stick to the numbering scheme we're using for
Display Engine 1.0, as in endpoint 0 links to component 0 of whatever type.
We're probably going to stick to that for the R40's incredibly complicated
pipeline. I don't want to have any outliers unless absolutely necessary.
ChenYu
> + remote-endpoint = <&tcon1_in_mixer1>;
> + };
> +
> + mixer1_out_tcon0: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&tcon0_in_mixer1>;
> + };
> + };
> + };
> + };
> +
> + tcon0: lcd-controller@1c0c000 {
> + compatible = "allwinner,sun8i-h3-tcon0";
> + reg = <0x01c0c000 0x1000>;
> + interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_TCON0>,
> + <&ccu CLK_TCON0>;
> + clock-names = "ahb",
> + "tcon-ch1";
> + resets = <&ccu RST_BUS_TCON0>;
> + reset-names = "lcd";
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + tcon0_in: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + tcon0_in_mixer0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&mixer0_out_tcon0>;
> + };
> +
> + tcon0_in_mixer1: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&mixer1_out_tcon0>;
> + };
> + };
> + };
> + };
> +
> + tcon1: lcd-controller@1c0d000 {
> + compatible = "allwinner,sun8i-h3-tcon1";
> + reg = <0x01c0d000 0x1000>;
> + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_TCON1>;
> + clock-names = "ahb";
> + resets = <&ccu RST_BUS_TCON1>;
> + reset-names = "lcd";
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + tcon1_in: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + tcon1_in_mixer1: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&mixer1_out_tcon1>;
> + };
> +
> + tcon1_in_mixer0: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&mixer0_out_tcon1>;
> + };
> + };
> +
> + tcon1_out: port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + tcon1_out_tve0: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&tve0_in_tcon1>;
> + };
> + };
> + };
> + };
> +
> + tve0: tv-encoder@1e00000 {
> + compatible = "allwinner,sun8i-h3-tv-encoder";
> + reg = <0x01e00000 0x1000>;
> + clocks = <&ccu CLK_BUS_TVE>, <&ccu CLK_TVE>;
> + clock-names = "bus", "mod";
> + resets = <&ccu RST_BUS_TVE>;
> + status = "disabled";
> +
> + assigned-clocks = <&ccu CLK_TVE>;
> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
> + assigned-clock-rates = <216000000>;
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + tve0_in_tcon1: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&tcon1_out_tve0>;
> + };
> + };
> + };
> + };
> +
> timer {
> compatible = "arm,armv7-timer";
> interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> --
> 2.12.2
>
> --
> 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 email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
[toc] | [prev] | [next] | [standalone]
| From | Icenowy Zheng <icenowy@aosc.io> |
|---|---|
| Date | 2017-05-24 07:30 +0200 |
| Subject | Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE |
| Message-ID | <tKx1U-6lD-9@gated-at.bofh.it> |
| In reply to | #1649122 |
于 2017年5月24日 GMT+08:00 下午1:24:29, Chen-Yu Tsai <wens@csie.org> 写到:
>On Thu, May 18, 2017 at 12:43 AM, Icenowy Zheng <icenowy@aosc.io>
>wrote:
>> As we have already the support for the TV encoder on Allwinner H3,
>add
>> the display engine pipeline device tree nodes to its DTSI file.
>>
>> The H5 pipeline has some differences and will be enabled later.
>>
>> The currently-unused mixer0 and tcon0 are also needed, for the
>> completement of the pipeline.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> arch/arm/boot/dts/sun8i-h3.dtsi | 189
>++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 189 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index b36f9f423c39..20172ef92415 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -41,6 +41,8 @@
>> */
>>
>> #include "sunxi-h3-h5.dtsi"
>> +#include <dt-bindings/clock/sun8i-de2.h>
>> +#include <dt-bindings/reset/sun8i-de2.h>
>>
>> / {
>> cpus {
>> @@ -72,6 +74,193 @@
>> };
>> };
>>
>> + de: display-engine {
>> + compatible = "allwinner,sun8i-h3-display-engine";
>> + allwinner,pipelines = <&mixer0>,
>> + <&mixer1>;
>> + status = "disabled";
>> + };
>> +
>> + soc {
>> + display_clocks: clock@1000000 {
>> + compatible = "allwinner,sun8i-a83t-de2-clk";
>> + reg = <0x01000000 0x100000>;
>> + clocks = <&ccu CLK_BUS_DE>,
>> + <&ccu CLK_DE>;
>> + clock-names = "bus",
>> + "mod";
>> + resets = <&ccu RST_BUS_DE>;
>> + #clock-cells = <1>;
>> + #reset-cells = <1>;
>> + assigned-clocks = <&ccu CLK_DE>;
>> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
>> + assigned-clock-rates = <432000000>;
>> + };
>> +
>> + mixer0: mixer@1100000 {
>> + compatible = "allwinner,sun8i-h3-de2-mixer0";
>> + reg = <0x01100000 0x100000>;
>> + clocks = <&display_clocks CLK_BUS_MIXER0>,
>> + <&display_clocks CLK_MIXER0>;
>> + clock-names = "bus",
>> + "mod";
>> + resets = <&display_clocks RST_MIXER0>;
>> + status = "disabled";
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + mixer0_out: port@1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + mixer0_out_tcon0: endpoint@0
>{
>> + reg = <0>;
>> + remote-endpoint =
><&tcon0_in_mixer0>;
>> + };
>> +
>> + mixer0_out_tcon1: endpoint@1
>{
>> + reg = <1>;
>> + remote-endpoint =
><&tcon1_in_mixer0>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + mixer1: mixer@1200000 {
>> + compatible = "allwinner,sun8i-h3-de2-mixer1";
>> + reg = <0x01200000 0x100000>;
>> + clocks = <&display_clocks CLK_BUS_MIXER1>,
>> + <&display_clocks CLK_MIXER1>;
>> + clock-names = "bus",
>> + "mod";
>> + resets = <&display_clocks RST_WB>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + mixer1_out: port@1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + mixer1_out_tcon1: endpoint@0
>{
>> + reg = <0>;
>
>I would prefer if you could stick to the numbering scheme we're using
>for
>Display Engine 1.0, as in endpoint 0 links to component 0 of whatever
>type.
If we keep this we will need a ugly id property in mixer node,
otherwise we cannot know which TCON to be bind.
>
>We're probably going to stick to that for the R40's incredibly
>complicated
>pipeline. I don't want to have any outliers unless absolutely
>necessary.
>
>ChenYu
>
>> + remote-endpoint =
><&tcon1_in_mixer1>;
>> + };
>> +
>> + mixer1_out_tcon0: endpoint@1
>{
>> + reg = <1>;
>> + remote-endpoint =
><&tcon0_in_mixer1>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + tcon0: lcd-controller@1c0c000 {
>> + compatible = "allwinner,sun8i-h3-tcon0";
>> + reg = <0x01c0c000 0x1000>;
>> + interrupts = <GIC_SPI 86
>IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&ccu CLK_BUS_TCON0>,
>> + <&ccu CLK_TCON0>;
>> + clock-names = "ahb",
>> + "tcon-ch1";
>> + resets = <&ccu RST_BUS_TCON0>;
>> + reset-names = "lcd";
>> + status = "disabled";
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + tcon0_in: port@0 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0>;
>> +
>> + tcon0_in_mixer0: endpoint@0 {
>> + reg = <0>;
>> + remote-endpoint =
><&mixer0_out_tcon0>;
>> + };
>> +
>> + tcon0_in_mixer1: endpoint@1 {
>> + reg = <1>;
>> + remote-endpoint =
><&mixer1_out_tcon0>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + tcon1: lcd-controller@1c0d000 {
>> + compatible = "allwinner,sun8i-h3-tcon1";
>> + reg = <0x01c0d000 0x1000>;
>> + interrupts = <GIC_SPI 87
>IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&ccu CLK_BUS_TCON1>;
>> + clock-names = "ahb";
>> + resets = <&ccu RST_BUS_TCON1>;
>> + reset-names = "lcd";
>> + status = "disabled";
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + tcon1_in: port@0 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0>;
>> +
>> + tcon1_in_mixer1: endpoint@0 {
>> + reg = <0>;
>> + remote-endpoint =
><&mixer1_out_tcon1>;
>> + };
>> +
>> + tcon1_in_mixer0: endpoint@1 {
>> + reg = <1>;
>> + remote-endpoint =
><&mixer0_out_tcon1>;
>> + };
>> + };
>> +
>> + tcon1_out: port@1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + tcon1_out_tve0: endpoint@1 {
>> + reg = <1>;
>> + remote-endpoint =
><&tve0_in_tcon1>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + tve0: tv-encoder@1e00000 {
>> + compatible = "allwinner,sun8i-h3-tv-encoder";
>> + reg = <0x01e00000 0x1000>;
>> + clocks = <&ccu CLK_BUS_TVE>, <&ccu CLK_TVE>;
>> + clock-names = "bus", "mod";
>> + resets = <&ccu RST_BUS_TVE>;
>> + status = "disabled";
>> +
>> + assigned-clocks = <&ccu CLK_TVE>;
>> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
>> + assigned-clock-rates = <216000000>;
>> +
>> + port {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + tve0_in_tcon1: endpoint@0 {
>> + reg = <0>;
>> + remote-endpoint =
><&tcon1_out_tve0>;
>> + };
>> + };
>> + };
>> + };
>> +
>> timer {
>> compatible = "arm,armv7-timer";
>> interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) |
>IRQ_TYPE_LEVEL_LOW)>,
>> --
>> 2.12.2
>>
>> --
>> 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 email to linux-sunxi+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
[toc] | [prev] | [next] | [standalone]
| From | Icenowy Zheng <icenowy@aosc.io> |
|---|---|
| Date | 2017-05-24 07:40 +0200 |
| Subject | Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE |
| Message-ID | <tKxbA-6pz-9@gated-at.bofh.it> |
| In reply to | #1649123 |
于 2017年5月24日 GMT+08:00 下午1:34:58, Chen-Yu Tsai <wens@csie.org> 写到:
>On Wed, May 24, 2017 at 1:28 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>
>>
>> 于 2017年5月24日 GMT+08:00 下午1:24:29, Chen-Yu Tsai <wens@csie.org> 写到:
>>>On Thu, May 18, 2017 at 12:43 AM, Icenowy Zheng <icenowy@aosc.io>
>>>wrote:
>>>> As we have already the support for the TV encoder on Allwinner H3,
>>>add
>>>> the display engine pipeline device tree nodes to its DTSI file.
>>>>
>>>> The H5 pipeline has some differences and will be enabled later.
>>>>
>>>> The currently-unused mixer0 and tcon0 are also needed, for the
>>>> completement of the pipeline.
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>> ---
>>>> arch/arm/boot/dts/sun8i-h3.dtsi | 189
>>>++++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 189 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>> index b36f9f423c39..20172ef92415 100644
>>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>> @@ -41,6 +41,8 @@
>>>> */
>>>>
>>>> #include "sunxi-h3-h5.dtsi"
>>>> +#include <dt-bindings/clock/sun8i-de2.h>
>>>> +#include <dt-bindings/reset/sun8i-de2.h>
>>>>
>>>> / {
>>>> cpus {
>>>> @@ -72,6 +74,193 @@
>>>> };
>>>> };
>>>>
>>>> + de: display-engine {
>>>> + compatible = "allwinner,sun8i-h3-display-engine";
>>>> + allwinner,pipelines = <&mixer0>,
>>>> + <&mixer1>;
>>>> + status = "disabled";
>>>> + };
>>>> +
>>>> + soc {
>>>> + display_clocks: clock@1000000 {
>>>> + compatible =
>"allwinner,sun8i-a83t-de2-clk";
>>>> + reg = <0x01000000 0x100000>;
>>>> + clocks = <&ccu CLK_BUS_DE>,
>>>> + <&ccu CLK_DE>;
>>>> + clock-names = "bus",
>>>> + "mod";
>>>> + resets = <&ccu RST_BUS_DE>;
>>>> + #clock-cells = <1>;
>>>> + #reset-cells = <1>;
>>>> + assigned-clocks = <&ccu CLK_DE>;
>>>> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
>>>> + assigned-clock-rates = <432000000>;
>>>> + };
>>>> +
>>>> + mixer0: mixer@1100000 {
>>>> + compatible =
>"allwinner,sun8i-h3-de2-mixer0";
>>>> + reg = <0x01100000 0x100000>;
>>>> + clocks = <&display_clocks CLK_BUS_MIXER0>,
>>>> + <&display_clocks CLK_MIXER0>;
>>>> + clock-names = "bus",
>>>> + "mod";
>>>> + resets = <&display_clocks RST_MIXER0>;
>>>> + status = "disabled";
>>>> +
>>>> + ports {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> +
>>>> + mixer0_out: port@1 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + reg = <1>;
>>>> +
>>>> + mixer0_out_tcon0:
>endpoint@0
>>>{
>>>> + reg = <0>;
>>>> + remote-endpoint =
>>><&tcon0_in_mixer0>;
>>>> + };
>>>> +
>>>> + mixer0_out_tcon1:
>endpoint@1
>>>{
>>>> + reg = <1>;
>>>> + remote-endpoint =
>>><&tcon1_in_mixer0>;
>>>> + };
>>>> + };
>>>> + };
>>>> + };
>>>> +
>>>> + mixer1: mixer@1200000 {
>>>> + compatible =
>"allwinner,sun8i-h3-de2-mixer1";
>>>> + reg = <0x01200000 0x100000>;
>>>> + clocks = <&display_clocks CLK_BUS_MIXER1>,
>>>> + <&display_clocks CLK_MIXER1>;
>>>> + clock-names = "bus",
>>>> + "mod";
>>>> + resets = <&display_clocks RST_WB>;
>>>> +
>>>> + ports {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> +
>>>> + mixer1_out: port@1 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + reg = <1>;
>>>> +
>>>> + mixer1_out_tcon1:
>endpoint@0
>>>{
>>>> + reg = <0>;
>>>
>>>I would prefer if you could stick to the numbering scheme we're using
>>>for
>>>Display Engine 1.0, as in endpoint 0 links to component 0 of whatever
>>>type.
>>
>> If we keep this we will need a ugly id property in mixer node,
>> otherwise we cannot know which TCON to be bind.
>
>Why? You can simply change the logic in your driver from:
>
> if (remote_endpoint.id) { continue; }
>
>to:
>
> if (local_endpoint.id != remote_endpoint.id) { continue; }
Thanks, I forgot that there's two endpoint ids...
So silly I am.
>
>I don't see the need for any ID property in the mixer node in this
>case.
>The ID is already encoded into the endpoint IDs.
>
>ChenYu
>
>>>
>>>We're probably going to stick to that for the R40's incredibly
>>>complicated
>>>pipeline. I don't want to have any outliers unless absolutely
>>>necessary.
>>>
>>>ChenYu
>>>
>>>> + remote-endpoint =
>>><&tcon1_in_mixer1>;
>>>> + };
>>>> +
>>>> + mixer1_out_tcon0:
>endpoint@1
>>>{
>>>> + reg = <1>;
>>>> + remote-endpoint =
>>><&tcon0_in_mixer1>;
>>>> + };
>>>> + };
>>>> + };
>>>> + };
>>>> +
>>>> + tcon0: lcd-controller@1c0c000 {
>>>> + compatible = "allwinner,sun8i-h3-tcon0";
>>>> + reg = <0x01c0c000 0x1000>;
>>>> + interrupts = <GIC_SPI 86
>>>IRQ_TYPE_LEVEL_HIGH>;
>>>> + clocks = <&ccu CLK_BUS_TCON0>,
>>>> + <&ccu CLK_TCON0>;
>>>> + clock-names = "ahb",
>>>> + "tcon-ch1";
>>>> + resets = <&ccu RST_BUS_TCON0>;
>>>> + reset-names = "lcd";
>>>> + status = "disabled";
>>>> +
>>>> + ports {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> +
>>>> + tcon0_in: port@0 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + reg = <0>;
>>>> +
>>>> + tcon0_in_mixer0: endpoint@0
>{
>>>> + reg = <0>;
>>>> + remote-endpoint =
>>><&mixer0_out_tcon0>;
>>>> + };
>>>> +
>>>> + tcon0_in_mixer1: endpoint@1
>{
>>>> + reg = <1>;
>>>> + remote-endpoint =
>>><&mixer1_out_tcon0>;
>>>> + };
>>>> + };
>>>> + };
>>>> + };
>>>> +
>>>> + tcon1: lcd-controller@1c0d000 {
>>>> + compatible = "allwinner,sun8i-h3-tcon1";
>>>> + reg = <0x01c0d000 0x1000>;
>>>> + interrupts = <GIC_SPI 87
>>>IRQ_TYPE_LEVEL_HIGH>;
>>>> + clocks = <&ccu CLK_BUS_TCON1>;
>>>> + clock-names = "ahb";
>>>> + resets = <&ccu RST_BUS_TCON1>;
>>>> + reset-names = "lcd";
>>>> + status = "disabled";
>>>> +
>>>> + ports {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> +
>>>> + tcon1_in: port@0 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + reg = <0>;
>>>> +
>>>> + tcon1_in_mixer1: endpoint@0
>{
>>>> + reg = <0>;
>>>> + remote-endpoint =
>>><&mixer1_out_tcon1>;
>>>> + };
>>>> +
>>>> + tcon1_in_mixer0: endpoint@1
>{
>>>> + reg = <1>;
>>>> + remote-endpoint =
>>><&mixer0_out_tcon1>;
>>>> + };
>>>> + };
>>>> +
>>>> + tcon1_out: port@1 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + reg = <1>;
>>>> +
>>>> + tcon1_out_tve0: endpoint@1
>{
>>>> + reg = <1>;
>>>> + remote-endpoint =
>>><&tve0_in_tcon1>;
>>>> + };
>>>> + };
>>>> + };
>>>> + };
>>>> +
>>>> + tve0: tv-encoder@1e00000 {
>>>> + compatible =
>"allwinner,sun8i-h3-tv-encoder";
>>>> + reg = <0x01e00000 0x1000>;
>>>> + clocks = <&ccu CLK_BUS_TVE>, <&ccu
>CLK_TVE>;
>>>> + clock-names = "bus", "mod";
>>>> + resets = <&ccu RST_BUS_TVE>;
>>>> + status = "disabled";
>>>> +
>>>> + assigned-clocks = <&ccu CLK_TVE>;
>>>> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
>>>> + assigned-clock-rates = <216000000>;
>>>> +
>>>> + port {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> +
>>>> + tve0_in_tcon1: endpoint@0 {
>>>> + reg = <0>;
>>>> + remote-endpoint =
>>><&tcon1_out_tve0>;
>>>> + };
>>>> + };
>>>> + };
>>>> + };
>>>> +
>>>> timer {
>>>> compatible = "arm,armv7-timer";
>>>> interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) |
>>>IRQ_TYPE_LEVEL_LOW)>,
>>>> --
>>>> 2.12.2
>>>>
>>>> --
>>>> 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 email to linux-sunxi+unsubscribe@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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 email to linux-sunxi+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
[toc] | [prev] | [next] | [standalone]
| From | Chen-Yu Tsai <wens@csie.org> |
|---|---|
| Date | 2017-05-24 07:40 +0200 |
| Subject | Re: [linux-sunxi] [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE |
| Message-ID | <tKxbA-6pz-11@gated-at.bofh.it> |
| In reply to | #1649123 |
On Wed, May 24, 2017 at 1:28 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
>
>
> 于 2017年5月24日 GMT+08:00 下午1:24:29, Chen-Yu Tsai <wens@csie.org> 写到:
>>On Thu, May 18, 2017 at 12:43 AM, Icenowy Zheng <icenowy@aosc.io>
>>wrote:
>>> As we have already the support for the TV encoder on Allwinner H3,
>>add
>>> the display engine pipeline device tree nodes to its DTSI file.
>>>
>>> The H5 pipeline has some differences and will be enabled later.
>>>
>>> The currently-unused mixer0 and tcon0 are also needed, for the
>>> completement of the pipeline.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> ---
>>> arch/arm/boot/dts/sun8i-h3.dtsi | 189
>>++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 189 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>>b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> index b36f9f423c39..20172ef92415 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> @@ -41,6 +41,8 @@
>>> */
>>>
>>> #include "sunxi-h3-h5.dtsi"
>>> +#include <dt-bindings/clock/sun8i-de2.h>
>>> +#include <dt-bindings/reset/sun8i-de2.h>
>>>
>>> / {
>>> cpus {
>>> @@ -72,6 +74,193 @@
>>> };
>>> };
>>>
>>> + de: display-engine {
>>> + compatible = "allwinner,sun8i-h3-display-engine";
>>> + allwinner,pipelines = <&mixer0>,
>>> + <&mixer1>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + soc {
>>> + display_clocks: clock@1000000 {
>>> + compatible = "allwinner,sun8i-a83t-de2-clk";
>>> + reg = <0x01000000 0x100000>;
>>> + clocks = <&ccu CLK_BUS_DE>,
>>> + <&ccu CLK_DE>;
>>> + clock-names = "bus",
>>> + "mod";
>>> + resets = <&ccu RST_BUS_DE>;
>>> + #clock-cells = <1>;
>>> + #reset-cells = <1>;
>>> + assigned-clocks = <&ccu CLK_DE>;
>>> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
>>> + assigned-clock-rates = <432000000>;
>>> + };
>>> +
>>> + mixer0: mixer@1100000 {
>>> + compatible = "allwinner,sun8i-h3-de2-mixer0";
>>> + reg = <0x01100000 0x100000>;
>>> + clocks = <&display_clocks CLK_BUS_MIXER0>,
>>> + <&display_clocks CLK_MIXER0>;
>>> + clock-names = "bus",
>>> + "mod";
>>> + resets = <&display_clocks RST_MIXER0>;
>>> + status = "disabled";
>>> +
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + mixer0_out: port@1 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <1>;
>>> +
>>> + mixer0_out_tcon0: endpoint@0
>>{
>>> + reg = <0>;
>>> + remote-endpoint =
>><&tcon0_in_mixer0>;
>>> + };
>>> +
>>> + mixer0_out_tcon1: endpoint@1
>>{
>>> + reg = <1>;
>>> + remote-endpoint =
>><&tcon1_in_mixer0>;
>>> + };
>>> + };
>>> + };
>>> + };
>>> +
>>> + mixer1: mixer@1200000 {
>>> + compatible = "allwinner,sun8i-h3-de2-mixer1";
>>> + reg = <0x01200000 0x100000>;
>>> + clocks = <&display_clocks CLK_BUS_MIXER1>,
>>> + <&display_clocks CLK_MIXER1>;
>>> + clock-names = "bus",
>>> + "mod";
>>> + resets = <&display_clocks RST_WB>;
>>> +
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + mixer1_out: port@1 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <1>;
>>> +
>>> + mixer1_out_tcon1: endpoint@0
>>{
>>> + reg = <0>;
>>
>>I would prefer if you could stick to the numbering scheme we're using
>>for
>>Display Engine 1.0, as in endpoint 0 links to component 0 of whatever
>>type.
>
> If we keep this we will need a ugly id property in mixer node,
> otherwise we cannot know which TCON to be bind.
Why? You can simply change the logic in your driver from:
if (remote_endpoint.id) { continue; }
to:
if (local_endpoint.id != remote_endpoint.id) { continue; }
I don't see the need for any ID property in the mixer node in this case.
The ID is already encoded into the endpoint IDs.
ChenYu
>>
>>We're probably going to stick to that for the R40's incredibly
>>complicated
>>pipeline. I don't want to have any outliers unless absolutely
>>necessary.
>>
>>ChenYu
>>
>>> + remote-endpoint =
>><&tcon1_in_mixer1>;
>>> + };
>>> +
>>> + mixer1_out_tcon0: endpoint@1
>>{
>>> + reg = <1>;
>>> + remote-endpoint =
>><&tcon0_in_mixer1>;
>>> + };
>>> + };
>>> + };
>>> + };
>>> +
>>> + tcon0: lcd-controller@1c0c000 {
>>> + compatible = "allwinner,sun8i-h3-tcon0";
>>> + reg = <0x01c0c000 0x1000>;
>>> + interrupts = <GIC_SPI 86
>>IRQ_TYPE_LEVEL_HIGH>;
>>> + clocks = <&ccu CLK_BUS_TCON0>,
>>> + <&ccu CLK_TCON0>;
>>> + clock-names = "ahb",
>>> + "tcon-ch1";
>>> + resets = <&ccu RST_BUS_TCON0>;
>>> + reset-names = "lcd";
>>> + status = "disabled";
>>> +
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + tcon0_in: port@0 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <0>;
>>> +
>>> + tcon0_in_mixer0: endpoint@0 {
>>> + reg = <0>;
>>> + remote-endpoint =
>><&mixer0_out_tcon0>;
>>> + };
>>> +
>>> + tcon0_in_mixer1: endpoint@1 {
>>> + reg = <1>;
>>> + remote-endpoint =
>><&mixer1_out_tcon0>;
>>> + };
>>> + };
>>> + };
>>> + };
>>> +
>>> + tcon1: lcd-controller@1c0d000 {
>>> + compatible = "allwinner,sun8i-h3-tcon1";
>>> + reg = <0x01c0d000 0x1000>;
>>> + interrupts = <GIC_SPI 87
>>IRQ_TYPE_LEVEL_HIGH>;
>>> + clocks = <&ccu CLK_BUS_TCON1>;
>>> + clock-names = "ahb";
>>> + resets = <&ccu RST_BUS_TCON1>;
>>> + reset-names = "lcd";
>>> + status = "disabled";
>>> +
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + tcon1_in: port@0 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <0>;
>>> +
>>> + tcon1_in_mixer1: endpoint@0 {
>>> + reg = <0>;
>>> + remote-endpoint =
>><&mixer1_out_tcon1>;
>>> + };
>>> +
>>> + tcon1_in_mixer0: endpoint@1 {
>>> + reg = <1>;
>>> + remote-endpoint =
>><&mixer0_out_tcon1>;
>>> + };
>>> + };
>>> +
>>> + tcon1_out: port@1 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <1>;
>>> +
>>> + tcon1_out_tve0: endpoint@1 {
>>> + reg = <1>;
>>> + remote-endpoint =
>><&tve0_in_tcon1>;
>>> + };
>>> + };
>>> + };
>>> + };
>>> +
>>> + tve0: tv-encoder@1e00000 {
>>> + compatible = "allwinner,sun8i-h3-tv-encoder";
>>> + reg = <0x01e00000 0x1000>;
>>> + clocks = <&ccu CLK_BUS_TVE>, <&ccu CLK_TVE>;
>>> + clock-names = "bus", "mod";
>>> + resets = <&ccu RST_BUS_TVE>;
>>> + status = "disabled";
>>> +
>>> + assigned-clocks = <&ccu CLK_TVE>;
>>> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
>>> + assigned-clock-rates = <216000000>;
>>> +
>>> + port {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + tve0_in_tcon1: endpoint@0 {
>>> + reg = <0>;
>>> + remote-endpoint =
>><&tcon1_out_tve0>;
>>> + };
>>> + };
>>> + };
>>> + };
>>> +
>>> timer {
>>> compatible = "arm,armv7-timer";
>>> interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) |
>>IRQ_TYPE_LEVEL_LOW)>,
>>> --
>>> 2.12.2
>>>
>>> --
>>> 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 email to linux-sunxi+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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 email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
[toc] | [prev] | [next] | [standalone]
| From | Icenowy Zheng <icenowy@aosc.io> |
|---|---|
| Date | 2017-05-17 19:10 +0200 |
| Subject | [RFC PATCH 06/11] drm: sun4i: add color space correction support for DE2 mixer |
| Message-ID | <tIaCu-5S3-17@gated-at.bofh.it> |
| In reply to | #1643507 |
The DE2 mixer can do color space correction needed by TV Encoder with
its DCSC sub-engine.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 35 +++++++++++++++++++++++++++++++++++
drivers/gpu/drm/sun4i/sun8i_mixer.h | 6 +++++-
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index d658a3a8159a..65f86641eca3 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -29,6 +29,14 @@
#include "sun8i_layer.h"
#include "sunxi_engine.h"
+static const u32 sun8i_rgb2yuv_coef[12] = {
+ 0x00000107, 0x00000204, 0x00000064, 0x00004200,
+ 0x00001f68, 0x00001ed6, 0x000001c2, 0x00020200,
+ 0x000001c2, 0x00001e87, 0x00001fb7, 0x00020200,
+};
+
+static const u32 sun8i_rgb2yuv_dcsc_alpha = 0x00020200;
+
static void sun8i_mixer_commit(struct sunxi_engine *engine)
{
DRM_DEBUG_DRIVER("Committing changes\n");
@@ -37,6 +45,31 @@ static void sun8i_mixer_commit(struct sunxi_engine *engine)
SUN8I_MIXER_GLOBAL_DBUFF_ENABLE);
}
+static void sun8i_mixer_apply_color_correction(struct sunxi_engine *engine)
+{
+ int i;
+
+ DRM_DEBUG_DRIVER("Applying RGB to YUV color correction\n");
+
+ /* Set color correction */
+ regmap_write(engine->regs, SUN8I_MIXER_DCSC_EN, 1);
+
+ for (i = 0; i < 12; i++)
+ regmap_write(engine->regs, SUN8I_MIXER_DCSC_COEF_REG(i),
+ sun8i_rgb2yuv_coef[i]);
+
+ regmap_write(engine->regs, SUN8I_MIXER_DCSC_COEF_ALPHA,
+ sun8i_rgb2yuv_dcsc_alpha);
+}
+
+static void sun8i_mixer_disable_color_correction(struct sunxi_engine *engine)
+{
+ DRM_DEBUG_DRIVER("Disabling color correction\n");
+
+ /* Disable color correction */
+ regmap_write(engine->regs, SUN8I_MIXER_DCSC_EN, 0);
+}
+
void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
int layer, bool enable)
{
@@ -229,6 +262,8 @@ int sun8i_mixer_update_layer_buffer(struct sun8i_mixer *mixer,
static const struct sunxi_engine_ops sun8i_engine_ops = {
.commit = sun8i_mixer_commit,
.layers_init = sun8i_layers_init,
+ .apply_color_correction = sun8i_mixer_apply_color_correction,
+ .disable_color_correction = sun8i_mixer_disable_color_correction,
};
static struct regmap_config sun8i_mixer_regmap_config = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index 4785ac090b8c..d7f7513898b6 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -88,6 +88,11 @@
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_RGB888 (8 << 8)
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_DEF (0xff << 24)
+/* The DCSC sub-engine is used to do color space conversation */
+#define SUN8I_MIXER_DCSC_EN 0xb0000
+#define SUN8I_MIXER_DCSC_COEF_REG(x) (0xb0010 + 0x4 * x)
+#define SUN8I_MIXER_DCSC_COEF_ALPHA 0xb0040
+
/*
* These sub-engines are still unknown now, the EN registers are here only to
* be used to disable these sub-engines.
@@ -102,7 +107,6 @@
#define SUN8I_MIXER_PEAK_EN 0xa6000
#define SUN8I_MIXER_ASE_EN 0xa8000
#define SUN8I_MIXER_FCC_EN 0xaa000
-#define SUN8I_MIXER_DCSC_EN 0xb0000
struct sun8i_mixer_cfg {
int vi_num;
--
2.12.2
[toc] | [prev] | [next] | [standalone]
| From | Jernej Škrabec <jernej.skrabec@siol.net> |
|---|---|
| Date | 2017-05-17 22:30 +0200 |
| Subject | Re: [linux-sunxi] [RFC PATCH 06/11] drm: sun4i: add color space correction support for DE2 mixer |
| Message-ID | <tIdK1-7Nc-7@gated-at.bofh.it> |
| In reply to | #1643523 |
Hi,
Dne sreda, 17. maj 2017 ob 18:43:49 CEST je Icenowy Zheng napisal(a):
> The DE2 mixer can do color space correction needed by TV Encoder with
> its DCSC sub-engine.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 35
> +++++++++++++++++++++++++++++++++++ drivers/gpu/drm/sun4i/sun8i_mixer.h |
> 6 +++++-
> 2 files changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> b/drivers/gpu/drm/sun4i/sun8i_mixer.c index d658a3a8159a..65f86641eca3
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -29,6 +29,14 @@
> #include "sun8i_layer.h"
> #include "sunxi_engine.h"
>
> +static const u32 sun8i_rgb2yuv_coef[12] = {
> + 0x00000107, 0x00000204, 0x00000064, 0x00004200,
> + 0x00001f68, 0x00001ed6, 0x000001c2, 0x00020200,
> + 0x000001c2, 0x00001e87, 0x00001fb7, 0x00020200,
> +};
> +
> +static const u32 sun8i_rgb2yuv_dcsc_alpha = 0x00020200;
> +
There is no need to set/use alpha. BSP code doesn't set it and 0x00020200
value is default.
Best regards,
Jernej
> static void sun8i_mixer_commit(struct sunxi_engine *engine)
> {
> DRM_DEBUG_DRIVER("Committing changes\n");
> @@ -37,6 +45,31 @@ static void sun8i_mixer_commit(struct sunxi_engine
> *engine) SUN8I_MIXER_GLOBAL_DBUFF_ENABLE);
> }
>
> +static void sun8i_mixer_apply_color_correction(struct sunxi_engine *engine)
> +{
> + int i;
> +
> + DRM_DEBUG_DRIVER("Applying RGB to YUV color correction\n");
> +
> + /* Set color correction */
> + regmap_write(engine->regs, SUN8I_MIXER_DCSC_EN, 1);
> +
> + for (i = 0; i < 12; i++)
> + regmap_write(engine->regs, SUN8I_MIXER_DCSC_COEF_REG(i),
> + sun8i_rgb2yuv_coef[i]);
> +
> + regmap_write(engine->regs, SUN8I_MIXER_DCSC_COEF_ALPHA,
> + sun8i_rgb2yuv_dcsc_alpha);
> +}
> +
> +static void sun8i_mixer_disable_color_correction(struct sunxi_engine
> *engine) +{
> + DRM_DEBUG_DRIVER("Disabling color correction\n");
> +
> + /* Disable color correction */
> + regmap_write(engine->regs, SUN8I_MIXER_DCSC_EN, 0);
> +}
> +
> void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
> int layer, bool enable)
> {
> @@ -229,6 +262,8 @@ int sun8i_mixer_update_layer_buffer(struct sun8i_mixer
> *mixer, static const struct sunxi_engine_ops sun8i_engine_ops = {
> .commit = sun8i_mixer_commit,
> .layers_init = sun8i_layers_init,
> + .apply_color_correction = sun8i_mixer_apply_color_correction,
> + .disable_color_correction = sun8i_mixer_disable_color_correction,
> };
>
> static struct regmap_config sun8i_mixer_regmap_config = {
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> b/drivers/gpu/drm/sun4i/sun8i_mixer.h index 4785ac090b8c..d7f7513898b6
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> @@ -88,6 +88,11 @@
> #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_RGB888 (8 << 8)
> #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_DEF (0xff << 24)
>
> +/* The DCSC sub-engine is used to do color space conversation */
> +#define SUN8I_MIXER_DCSC_EN 0xb0000
> +#define SUN8I_MIXER_DCSC_COEF_REG(x) (0xb0010 + 0x4 * x)
> +#define SUN8I_MIXER_DCSC_COEF_ALPHA 0xb0040
> +
> /*
> * These sub-engines are still unknown now, the EN registers are here only
> to * be used to disable these sub-engines.
> @@ -102,7 +107,6 @@
> #define SUN8I_MIXER_PEAK_EN 0xa6000
> #define SUN8I_MIXER_ASE_EN 0xa8000
> #define SUN8I_MIXER_FCC_EN 0xaa000
> -#define SUN8I_MIXER_DCSC_EN 0xb0000
>
> struct sun8i_mixer_cfg {
> int vi_num;
> --
> 2.12.2
>
> --
> 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 email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
[toc] | [prev] | [next] | [standalone]
| From | Icenowy Zheng <icenowy@aosc.io> |
|---|---|
| Date | 2017-05-17 19:10 +0200 |
| Subject | [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC |
| Message-ID | <tIaCu-5S3-21@gated-at.bofh.it> |
| In reply to | #1643507 |
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.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
drivers/gpu/drm/sun4i/sun4i_tv.c | 65 +++++++++++++++++++++++++++++++++++++---
1 file changed, 61 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index a9cad00d4ee8..c9943103f499 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -13,6 +13,7 @@
#include <linux/clk.h>
#include <linux/component.h>
#include <linux/of_address.h>
+#include <linux/of_device.h>
#include <linux/regmap.h>
#include <linux/reset.h>
@@ -169,14 +170,23 @@ struct tv_mode {
const struct resync_parameters *resync_params;
};
+struct sun4i_tv_quirks {
+ bool has_mod_clk;
+ bool fixed_clock;
+ unsigned long fixed_clock_rate;
+};
+
struct sun4i_tv {
struct drm_connector connector;
struct drm_encoder encoder;
struct clk *clk;
+ struct clk *mod_clk;
struct regmap *regs;
struct reset_control *reset;
+ const struct sun4i_tv_quirks *quirks;
+
struct sun4i_drv *drv;
};
@@ -578,6 +588,10 @@ static int sun4i_tv_bind(struct device *dev, struct device *master,
tv->drv = drv;
dev_set_drvdata(dev, tv);
+ tv->quirks = of_device_get_match_data(dev);
+ if (!tv->quirks)
+ return -EINVAL;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(dev, res);
if (IS_ERR(regs)) {
@@ -604,7 +618,10 @@ static int sun4i_tv_bind(struct device *dev, struct device *master,
return ret;
}
- tv->clk = devm_clk_get(dev, NULL);
+ if (tv->quirks->has_mod_clk)
+ tv->clk = devm_clk_get(dev, "bus");
+ else
+ tv->clk = devm_clk_get(dev, NULL);
if (IS_ERR(tv->clk)) {
dev_err(dev, "Couldn't get the TV encoder clock\n");
ret = PTR_ERR(tv->clk);
@@ -612,6 +629,26 @@ static int sun4i_tv_bind(struct device *dev, struct device *master,
}
clk_prepare_enable(tv->clk);
+ if (tv->quirks->has_mod_clk) {
+ tv->mod_clk = devm_clk_get(dev, "mod");
+ if (IS_ERR(tv->mod_clk)) {
+ dev_err(dev, "Couldn't get the TV encoder mod clock\n");
+ ret = PTR_ERR(tv->mod_clk);
+ goto err_disable_clk;
+ };
+
+ if (tv->quirks->fixed_clock) {
+ ret = clk_set_rate(tv->mod_clk,
+ tv->quirks->fixed_clock_rate);
+ if (ret) {
+ dev_err(dev, "Couldn't set TV encoder mod clock rate\n");
+ goto err_disable_clk;
+ }
+ }
+
+ clk_prepare_enable(tv->mod_clk);
+ }
+
drm_encoder_helper_add(&tv->encoder,
&sun4i_tv_helper_funcs);
ret = drm_encoder_init(drm,
@@ -621,14 +658,14 @@ static int sun4i_tv_bind(struct device *dev, struct device *master,
NULL);
if (ret) {
dev_err(dev, "Couldn't initialise the TV encoder\n");
- goto err_disable_clk;
+ goto err_disable_mod_clk;
}
tv->encoder.possible_crtcs = drm_of_find_possible_crtcs(drm,
dev->of_node);
if (!tv->encoder.possible_crtcs) {
ret = -EPROBE_DEFER;
- goto err_disable_clk;
+ goto err_disable_mod_clk;
}
drm_connector_helper_add(&tv->connector,
@@ -649,6 +686,9 @@ static int sun4i_tv_bind(struct device *dev, struct device *master,
err_cleanup_connector:
drm_encoder_cleanup(&tv->encoder);
+err_disable_mod_clk:
+ if (tv->quirks->has_mod_clk)
+ clk_disable_unprepare(tv->mod_clk);
err_disable_clk:
clk_disable_unprepare(tv->clk);
err_assert_reset:
@@ -683,8 +723,25 @@ static int sun4i_tv_remove(struct platform_device *pdev)
return 0;
}
+static const struct sun4i_tv_quirks sun4i_a10_tv_quirks = {
+ /* Nothing special */
+};
+
+static const struct sun4i_tv_quirks sun8i_h3_tv_quirks = {
+ .has_mod_clk = true,
+ .fixed_clock = true,
+ .fixed_clock_rate = 216000000UL,
+};
+
static const struct of_device_id sun4i_tv_of_table[] = {
- { .compatible = "allwinner,sun4i-a10-tv-encoder" },
+ {
+ .compatible = "allwinner,sun4i-a10-tv-encoder",
+ .data = &sun4i_a10_tv_quirks,
+ },
+ {
+ .compatible = "allwinner,sun8i-h3-tv-encoder",
+ .data = &sun8i_h3_tv_quirks,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, sun4i_tv_of_table);
--
2.12.2
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-05-19 20:10 +0200 |
| Subject | Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC |
| Message-ID | <tIUvE-5Pe-3@gated-at.bofh.it> |
| In reply to | #1643524 |
[Multipart message — attachments visible in raw view] — view raw
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? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[toc] | [prev] | [next] | [standalone]
| From | Icenowy Zheng <icenowy@aosc.io> |
|---|---|
| Date | 2017-05-19 20:10 +0200 |
| Subject | Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC |
| Message-ID | <tIUvE-5Pe-11@gated-at.bofh.it> |
| In reply to | #1645808 |
于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard <maxime.ripard@free-electrons.com> 写到: >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: >> Allwinner H3 features a TV encoder similar to the one in earlier >SoCs, >> but with some different points about clocks: >> - It has a mod clock and a bus clock. >> - The mod clock must be at a fixed rate to generate signal. > >Why? It's experiment result by Jernej. The clock rates in BSP kernel is also specially designed (PLL_DE at 432MHz) in order to be able to feed the TVE. > >Maxime
[toc] | [prev] | [next] | [standalone]
| From | Jernej Škrabec <jernej.skrabec@siol.net> |
|---|---|
| Date | 2017-05-19 20:30 +0200 |
| Subject | Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC |
| Message-ID | <tIUP0-5Wm-5@gated-at.bofh.it> |
| In reply to | #1645812 |
Hi, Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a): > 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard <maxime.ripard@free- electrons.com> 写到: > >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: > >> Allwinner H3 features a TV encoder similar to the one in earlier > > > >SoCs, > > > >> but with some different points about clocks: > >> - It has a mod clock and a bus clock. > >> - The mod clock must be at a fixed rate to generate signal. > > > >Why? > > It's experiment result by Jernej. > > The clock rates in BSP kernel is also specially designed > (PLL_DE at 432MHz) in order to be able to feed the TVE. My experiments and search through BSP code showed that TVE seems to have additional fixed predivider 8. So if you want to generate 27 MHz clock, unit has to be feed with 216 MHz. TVE has only one PLL source PLL_DE. And since 216 MHz is a bit low for DE2, BSP defaults to 432 MHz for PLL_DE and use divider 2 to generate 216 MHz. This clock is then divided by 8 internaly to get final 27 MHz. Please note that I don't have any hard evidence to support that, only experimental data. However, only that explanation make sense to me. BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both use 27 MHz base clock. Further experiments are needed to check if there is any possibility to have other resolutions by manipulating clocks and give other proper settings. I plan to do that, but not in very near future. Best regards, Jernej
[toc] | [prev] | [next] | [standalone]
| From | Chen-Yu Tsai <wens@csie.org> |
|---|---|
| Date | 2017-05-20 03:40 +0200 |
| Subject | Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC |
| Message-ID | <tJ1x7-2sf-1@gated-at.bofh.it> |
| In reply to | #1645833 |
On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec <jernej.skrabec@siol.net> wrote: > Hi, > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a): >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard <maxime.ripard@free- > electrons.com> 写到: >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: >> >> Allwinner H3 features a TV encoder similar to the one in earlier >> > >> >SoCs, >> > >> >> but with some different points about clocks: >> >> - It has a mod clock and a bus clock. >> >> - The mod clock must be at a fixed rate to generate signal. >> > >> >Why? >> >> It's experiment result by Jernej. >> >> The clock rates in BSP kernel is also specially designed >> (PLL_DE at 432MHz) in order to be able to feed the TVE. > > My experiments and search through BSP code showed that TVE seems to have > additional fixed predivider 8. So if you want to generate 27 MHz clock, unit > has to be feed with 216 MHz. > > TVE has only one PLL source PLL_DE. And since 216 MHz is a bit low for DE2, > BSP defaults to 432 MHz for PLL_DE and use divider 2 to generate 216 MHz. This > clock is then divided by 8 internaly to get final 27 MHz. > > Please note that I don't have any hard evidence to support that, only > experimental data. However, only that explanation make sense to me. > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both use 27 MHz base > clock. Further experiments are needed to check if there is any possibility to > have other resolutions by manipulating clocks and give other proper settings. > I plan to do that, but not in very near future. You only have composite video output, and those are the only 2 standard resolutions that make any sense. ChenYu
[toc] | [prev] | [next] | [standalone]
| From | Jernej Škrabec <jernej.skrabec@siol.net> |
|---|---|
| Date | 2017-05-22 20:00 +0200 |
| Subject | Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC |
| Message-ID | <tJZMB-gQ-3@gated-at.bofh.it> |
| In reply to | #1646040 |
Hi, Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai napisal(a): > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec <jernej.skrabec@siol.net> wrote: > > Hi, > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a): > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard <maxime.ripard@free- > > > > electrons.com> 写到: > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: > >> >> Allwinner H3 features a TV encoder similar to the one in earlier > >> > > >> >SoCs, > >> > > >> >> but with some different points about clocks: > >> >> - It has a mod clock and a bus clock. > >> >> - The mod clock must be at a fixed rate to generate signal. > >> > > >> >Why? > >> > >> It's experiment result by Jernej. > >> > >> The clock rates in BSP kernel is also specially designed > >> (PLL_DE at 432MHz) in order to be able to feed the TVE. > > > > My experiments and search through BSP code showed that TVE seems to have > > additional fixed predivider 8. So if you want to generate 27 MHz clock, > > unit has to be feed with 216 MHz. > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a bit low for > > DE2, > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to generate 216 MHz. > > This clock is then divided by 8 internaly to get final 27 MHz. > > > > Please note that I don't have any hard evidence to support that, only > > experimental data. However, only that explanation make sense to me. > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both use 27 MHz > > base clock. Further experiments are needed to check if there is any > > possibility to have other resolutions by manipulating clocks and give > > other proper settings. I plan to do that, but not in very near future. > > You only have composite video output, and those are the only 2 standard > resolutions that make any sense. Right, other resolutions are for VGA. Anyway, I did some more digging in A10 and R40 datasheets. I think that H3 TVE unit is something in between. R40 TVE has a setting to select "up sample". 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
[toc] | [prev] | [next] | [standalone]
| From | Icenowy Zheng <icenowy@aosc.io> |
|---|---|
| Date | 2017-05-23 15:00 +0200 |
| Subject | Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC |
| Message-ID | <tKhzP-3jV-3@gated-at.bofh.it> |
| In reply to | #1647223 |
于 2017年5月23日 GMT+08:00 下午8:53:21, Maxime Ripard <maxime.ripard@free-electrons.com> 写到: >On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej Škrabec wrote: >> Hi, >> >> Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai napisal(a): >> > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec ><jernej.skrabec@siol.net> >> wrote: >> > > Hi, >> > > >> > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng >napisal(a): >> > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard ><maxime.ripard@free- >> > > >> > > electrons.com> 写到: >> > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: >> > >> >> Allwinner H3 features a TV encoder similar to the one in >earlier >> > >> > >> > >> >SoCs, >> > >> > >> > >> >> but with some different points about clocks: >> > >> >> - It has a mod clock and a bus clock. >> > >> >> - The mod clock must be at a fixed rate to generate signal. >> > >> > >> > >> >Why? >> > >> >> > >> It's experiment result by Jernej. >> > >> >> > >> The clock rates in BSP kernel is also specially designed >> > >> (PLL_DE at 432MHz) in order to be able to feed the TVE. >> > > >> > > My experiments and search through BSP code showed that TVE seems >to have >> > > additional fixed predivider 8. So if you want to generate 27 MHz >clock, >> > > unit has to be feed with 216 MHz. >> > > >> > > TVE has only one PLL source PLL_DE. And since 216 MHz is a bit >low for >> > > DE2, >> > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to generate >216 MHz. >> > > This clock is then divided by 8 internaly to get final 27 MHz. >> > > >> > > Please note that I don't have any hard evidence to support that, >only >> > > experimental data. However, only that explanation make sense to >me. >> > > >> > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both >use 27 MHz >> > > base clock. Further experiments are needed to check if there is >any >> > > possibility to have other resolutions by manipulating clocks and >give >> > > other proper settings. I plan to do that, but not in very near >future. >> > >> > You only have composite video output, and those are the only 2 >standard >> > resolutions that make any sense. >> >> Right, other resolutions are for VGA. >> >> Anyway, I did some more digging in A10 and R40 datasheets. I think >that H3 TVE >> unit is something in between. R40 TVE has a setting to select "up >sample". > >That might be just another translation of oversampling :) > >I didn't know it could be applied to composite signals though, but I >guess this is just another analog signal after all. > >> Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP driver >on R40 >> has this setting enabled only for PAL and NTSC and it is always 216 >MHz. I >> think that H3 may have this hardwired to 216 MHz and this would be >the reason >> why 216 MHz is needed. >> >> Has anyone else any better explanation? > >That's already a pretty good one. > >Either way, wether this is upsampling, oversampling or just a >pre-divider, this can and should be dealt with in the mode_set >callback, and not in the probe. What should we do for this? Add a hook in TCON driver and let TVE driver affect the clock value (*16, as the dotclock is halfed)? > >Thanks! >Maxime
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-05-23 15:00 +0200 |
| Subject | Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC |
| Message-ID | <tKhzP-3jV-5@gated-at.bofh.it> |
| In reply to | #1647223 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej Škrabec wrote: > Hi, > > Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai napisal(a): > > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec <jernej.skrabec@siol.net> > wrote: > > > Hi, > > > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a): > > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard <maxime.ripard@free- > > > > > > electrons.com> 写到: > > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: > > >> >> Allwinner H3 features a TV encoder similar to the one in earlier > > >> > > > >> >SoCs, > > >> > > > >> >> but with some different points about clocks: > > >> >> - It has a mod clock and a bus clock. > > >> >> - The mod clock must be at a fixed rate to generate signal. > > >> > > > >> >Why? > > >> > > >> It's experiment result by Jernej. > > >> > > >> The clock rates in BSP kernel is also specially designed > > >> (PLL_DE at 432MHz) in order to be able to feed the TVE. > > > > > > My experiments and search through BSP code showed that TVE seems to have > > > additional fixed predivider 8. So if you want to generate 27 MHz clock, > > > unit has to be feed with 216 MHz. > > > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a bit low for > > > DE2, > > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to generate 216 MHz. > > > This clock is then divided by 8 internaly to get final 27 MHz. > > > > > > Please note that I don't have any hard evidence to support that, only > > > experimental data. However, only that explanation make sense to me. > > > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both use 27 MHz > > > base clock. Further experiments are needed to check if there is any > > > possibility to have other resolutions by manipulating clocks and give > > > other proper settings. I plan to do that, but not in very near future. > > > > You only have composite video output, and those are the only 2 standard > > resolutions that make any sense. > > Right, other resolutions are for VGA. > > Anyway, I did some more digging in A10 and R40 datasheets. I think that H3 TVE > unit is something in between. R40 TVE has a setting to select "up sample". That might be just another translation of oversampling :) I didn't know it could be applied to composite signals though, but I guess this is just another analog signal after all. > Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP driver on R40 > has this setting enabled only for PAL and NTSC and it is always 216 MHz. I > think that H3 may have this hardwired to 216 MHz and this would be the reason > why 216 MHz is needed. > > Has anyone else any better explanation? That's already a pretty good one. Either way, wether this is upsampling, oversampling or just a pre-divider, this can and should be dealt with in the mode_set callback, and not in the probe. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[toc] | [prev] | [next] | [standalone]
| From | icenowy@aosc.io |
|---|---|
| Date | 2017-05-23 15:10 +0200 |
| Subject | Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC |
| Message-ID | <tKhJv-3D6-9@gated-at.bofh.it> |
| In reply to | #1648001 |
在 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 <jernej.skrabec@siol.net> >> wrote: >> > > Hi, >> > > >> > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a): >> > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard <maxime.ripard@free- >> > > >> > > electrons.com> 写到: >> > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: >> > >> >> Allwinner H3 features a TV encoder similar to the one in earlier >> > >> > >> > >> >SoCs, >> > >> > >> > >> >> but with some different points about clocks: >> > >> >> - It has a mod clock and a bus clock. >> > >> >> - The mod clock must be at a fixed rate to generate signal. >> > >> > >> > >> >Why? >> > >> >> > >> It's experiment result by Jernej. >> > >> >> > >> The clock rates in BSP kernel is also specially designed >> > >> (PLL_DE at 432MHz) in order to be able to feed the TVE. >> > > >> > > My experiments and search through BSP code showed that TVE seems to have >> > > additional fixed predivider 8. So if you want to generate 27 MHz clock, >> > > unit has to be feed with 216 MHz. >> > > >> > > TVE has only one PLL source PLL_DE. And since 216 MHz is a bit low for >> > > DE2, >> > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to generate 216 MHz. >> > > This clock is then divided by 8 internaly to get final 27 MHz. >> > > >> > > Please note that I don't have any hard evidence to support that, only >> > > experimental data. However, only that explanation make sense to me. >> > > >> > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both use 27 MHz >> > > base clock. Further experiments are needed to check if there is any >> > > possibility to have other resolutions by manipulating clocks and give >> > > other proper settings. I plan to do that, but not in very near future. >> > >> > You only have composite video output, and those are the only 2 standard >> > resolutions that make any sense. >> >> Right, other resolutions are for VGA. >> >> Anyway, I did some more digging in A10 and R40 datasheets. I think >> that H3 TVE >> unit is something in between. R40 TVE has a setting to select "up >> sample". > > That might be just another translation of oversampling :) > > I didn't know it could be applied to composite signals though, but I > guess this is just another analog signal after all. > >> Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP driver >> on R40 >> has this setting enabled only for PAL and NTSC and it is always 216 >> MHz. I >> think that H3 may have this hardwired to 216 MHz and this would be the >> reason >> why 216 MHz is needed. >> >> Has anyone else any better explanation? > > That's already a pretty good one. > > Either way, wether this is upsampling, oversampling or just a > pre-divider, this can and should be dealt with in the mode_set > callback, and not in the probe. 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
[toc] | [prev] | [next] | [standalone]
| From | Maxime Ripard <maxime.ripard@free-electrons.com> |
|---|---|
| Date | 2017-05-24 09:40 +0200 |
| Subject | Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC |
| Message-ID | <tKz3I-7GI-9@gated-at.bofh.it> |
| In reply to | #1648005 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, May 23, 2017 at 09:00:59PM +0800, icenowy@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 <jernej.skrabec@siol.net> > > > wrote: > > > > > Hi, > > > > > > > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a): > > > > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard <maxime.ripard@free- > > > > > > > > > > electrons.com> 写到: > > > > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: > > > > >> >> Allwinner H3 features a TV encoder similar to the one in earlier > > > > >> > > > > > >> >SoCs, > > > > >> > > > > > >> >> but with some different points about clocks: > > > > >> >> - It has a mod clock and a bus clock. > > > > >> >> - The mod clock must be at a fixed rate to generate signal. > > > > >> > > > > > >> >Why? > > > > >> > > > > >> It's experiment result by Jernej. > > > > >> > > > > >> The clock rates in BSP kernel is also specially designed > > > > >> (PLL_DE at 432MHz) in order to be able to feed the TVE. > > > > > > > > > > My experiments and search through BSP code showed that TVE seems to have > > > > > additional fixed predivider 8. So if you want to generate 27 MHz clock, > > > > > unit has to be feed with 216 MHz. > > > > > > > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a bit low for > > > > > DE2, > > > > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to generate 216 MHz. > > > > > This clock is then divided by 8 internaly to get final 27 MHz. > > > > > > > > > > Please note that I don't have any hard evidence to support that, only > > > > > experimental data. However, only that explanation make sense to me. > > > > > > > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both use 27 MHz > > > > > base clock. Further experiments are needed to check if there is any > > > > > possibility to have other resolutions by manipulating clocks and give > > > > > other proper settings. I plan to do that, but not in very near future. > > > > > > > > You only have composite video output, and those are the only 2 standard > > > > resolutions that make any sense. > > > > > > Right, other resolutions are for VGA. > > > > > > Anyway, I did some more digging in A10 and R40 datasheets. I think > > > that H3 TVE > > > unit is something in between. R40 TVE has a setting to select "up > > > sample". > > > > That might be just another translation of oversampling :) > > > > I didn't know it could be applied to composite signals though, but I > > guess this is just another analog signal after all. > > > > > Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP > > > driver on R40 > > > has this setting enabled only for PAL and NTSC and it is always 216 > > > MHz. I > > > think that H3 may have this hardwired to 216 MHz and this would be > > > the reason > > > why 216 MHz is needed. > > > > > > Has anyone else any better explanation? > > > > That's already a pretty good one. > > > > Either way, wether this is upsampling, oversampling or just a > > pre-divider, this can and should be dealt with in the mode_set > > callback, and not in the probe. > > 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
[toc] | [prev] | [next] | [standalone]
| From | Icenowy Zheng <icenowy@aosc.io> |
|---|---|
| Date | 2017-05-24 10:30 +0200 |
| Subject | Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC |
| Message-ID | <tKzQ6-8hN-25@gated-at.bofh.it> |
| In reply to | #1649193 |
于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard <maxime.ripard@free-electrons.com> 写到: >On Tue, May 23, 2017 at 09:00:59PM +0800, icenowy@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 ><jernej.skrabec@siol.net> >> > > wrote: >> > > > > Hi, >> > > > > >> > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng >napisal(a): >> > > > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard ><maxime.ripard@free- >> > > > > >> > > > > electrons.com> 写到: >> > > > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng >wrote: >> > > > >> >> Allwinner H3 features a TV encoder similar to the one in >earlier >> > > > >> > >> > > > >> >SoCs, >> > > > >> > >> > > > >> >> but with some different points about clocks: >> > > > >> >> - It has a mod clock and a bus clock. >> > > > >> >> - The mod clock must be at a fixed rate to generate >signal. >> > > > >> > >> > > > >> >Why? >> > > > >> >> > > > >> It's experiment result by Jernej. >> > > > >> >> > > > >> The clock rates in BSP kernel is also specially designed >> > > > >> (PLL_DE at 432MHz) in order to be able to feed the TVE. >> > > > > >> > > > > My experiments and search through BSP code showed that TVE >seems to have >> > > > > additional fixed predivider 8. So if you want to generate 27 >MHz clock, >> > > > > unit has to be feed with 216 MHz. >> > > > > >> > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a >bit low for >> > > > > DE2, >> > > > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to >generate 216 MHz. >> > > > > This clock is then divided by 8 internaly to get final 27 >MHz. >> > > > > >> > > > > Please note that I don't have any hard evidence to support >that, only >> > > > > experimental data. However, only that explanation make sense >to me. >> > > > > >> > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which >both use 27 MHz >> > > > > base clock. Further experiments are needed to check if there >is any >> > > > > possibility to have other resolutions by manipulating clocks >and give >> > > > > other proper settings. I plan to do that, but not in very >near future. >> > > > >> > > > You only have composite video output, and those are the only 2 >standard >> > > > resolutions that make any sense. >> > > >> > > Right, other resolutions are for VGA. >> > > >> > > Anyway, I did some more digging in A10 and R40 datasheets. I >think >> > > that H3 TVE >> > > unit is something in between. R40 TVE has a setting to select "up >> > > sample". >> > >> > That might be just another translation of oversampling :) >> > >> > I didn't know it could be applied to composite signals though, but >I >> > guess this is just another analog signal after all. >> > >> > > Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP >> > > driver on R40 >> > > has this setting enabled only for PAL and NTSC and it is always >216 >> > > MHz. I >> > > think that H3 may have this hardwired to 216 MHz and this would >be >> > > the reason >> > > why 216 MHz is needed. >> > > >> > > Has anyone else any better explanation? >> > >> > That's already a pretty good one. >> > >> > Either way, wether this is upsampling, oversampling or just a >> > pre-divider, this can and should be dealt with in the mode_set >> > callback, and not in the probe. >> >> 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
[toc] | [prev] | [next] | [standalone]
| From | Jernej Škrabec <jernej.skrabec@siol.net> |
|---|---|
| Date | 2017-05-24 17:30 +0200 |
| Subject | Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC |
| Message-ID | <tKGoy-43s-5@gated-at.bofh.it> |
| In reply to | #1649237 |
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 <maxime.ripard@free- electrons.com> 写到: > >On Tue, May 23, 2017 at 09:00:59PM +0800, icenowy@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 > > > ><jernej.skrabec@siol.net> > > > >> > > wrote: > >> > > > > Hi, > >> > > > > > >> > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng > > > >napisal(a): > >> > > > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard > > > ><maxime.ripard@free- > > > >> > > > > electrons.com> 写到: > >> > > > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng > > > >wrote: > >> > > > >> >> Allwinner H3 features a TV encoder similar to the one in > > > >earlier > > > >> > > > >> >SoCs, > >> > > > >> > > >> > > > >> >> but with some different points about clocks: > >> > > > >> >> - It has a mod clock and a bus clock. > >> > > > >> >> - The mod clock must be at a fixed rate to generate > > > >signal. > > > >> > > > >> >Why? > >> > > > >> > >> > > > >> It's experiment result by Jernej. > >> > > > >> > >> > > > >> The clock rates in BSP kernel is also specially designed > >> > > > >> (PLL_DE at 432MHz) in order to be able to feed the TVE. > >> > > > > > >> > > > > My experiments and search through BSP code showed that TVE > > > >seems to have > > > >> > > > > additional fixed predivider 8. So if you want to generate 27 > > > >MHz clock, > > > >> > > > > unit has to be feed with 216 MHz. > >> > > > > > >> > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a > > > >bit low for > > > >> > > > > DE2, > >> > > > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to > > > >generate 216 MHz. > > > >> > > > > This clock is then divided by 8 internaly to get final 27 > > > >MHz. > > > >> > > > > Please note that I don't have any hard evidence to support > > > >that, only > > > >> > > > > experimental data. However, only that explanation make sense > > > >to me. > > > >> > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which > > > >both use 27 MHz > > > >> > > > > base clock. Further experiments are needed to check if there > > > >is any > > > >> > > > > possibility to have other resolutions by manipulating clocks > > > >and give > > > >> > > > > other proper settings. I plan to do that, but not in very > > > >near future. > > > >> > > > You only have composite video output, and those are the only 2 > > > >standard > > > >> > > > resolutions that make any sense. > >> > > > >> > > Right, other resolutions are for VGA. > >> > > > >> > > Anyway, I did some more digging in A10 and R40 datasheets. I > > > >think > > > >> > > that H3 TVE > >> > > unit is something in between. R40 TVE has a setting to select "up > >> > > sample". > >> > > >> > That might be just another translation of oversampling :) > >> > > >> > I didn't know it could be applied to composite signals though, but > > > >I > > > >> > guess this is just another analog signal after all. > >> > > >> > > Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP > >> > > driver on R40 > >> > > has this setting enabled only for PAL and NTSC and it is always > > > >216 > > > >> > > MHz. I > >> > > think that H3 may have this hardwired to 216 MHz and this would > > > >be > > > >> > > the reason > >> > > why 216 MHz is needed. > >> > > > >> > > Has anyone else any better explanation? > >> > > >> > That's already a pretty good one. > >> > > >> > Either way, wether this is upsampling, oversampling or just a > >> > pre-divider, this can and should be dealt with in the mode_set > >> > callback, and not in the probe. > >> > >> 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
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | linux.kernel
csiph-web