[U-Boot] [PATCH v2 0/4] sunxi: video: Add support for TV (composite) output on H3/H5

[U-Boot] [PATCH v2 0/4] sunxi: video: Add support for TV (composite) output on H3/H5

[Jernej Skrabec]

This series implements support for composite output. Driver is
implemented using DM video framework and heavily reuse code written for
older SoCs. Additionally, driver also implements plug detection.

All patches in first version were merged except the last one. Because
this version only split one patch into multiple and doesn't do any code
change, I didn't write any changelog.

Patch 1 renames tve.c to tve_common.c to better describe it's intention.

Patch 2 adds TVE base address.

Patch 3 adds support for TVE to DE2 driver.

Patch 4 finally adds TVE driver for H3 and H5.

Everything was tested on H3 (OrangePi 2) and H5 (OrangePi PC2) board.
Since this series changes video driver for old SoCs, I would kindly ask
that someone tests if everything still works as expected.

Best regards,
Jernej


Jernej Skrabec (4):
  sunxi: video: Rename tve.c to tve_common.c
  sunxi: Add base address for TV encoder
  sunxi: video: Add support for CSC and TVE to DE2 driver
  sunxi: video: Add H3/H5 TV out driver

 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h |  10 ++
 arch/arm/include/asm/arch-sunxi/display2.h  |  17 +++
 arch/arm/include/asm/arch-sunxi/tve.h       |  17 ++-
 drivers/video/sunxi/Makefile                |   4 +-
 drivers/video/sunxi/sunxi_de2.c             |  60 ++++++++---
 drivers/video/sunxi/sunxi_tve.c             | 156 ++++++++++++++++++++++++++++
 drivers/video/sunxi/{tve.c => tve_common.c} |   6 +-
 7 files changed, 252 insertions(+), 18 deletions(-)
 create mode 100644 drivers/video/sunxi/sunxi_tve.c
 rename drivers/video/sunxi/{tve.c => tve_common.c} (95%)

-- 
2.13.0

[U-Boot] [PATCH v2 1/4] sunxi: video: Rename tve.c to tve_common.c

[Jernej Skrabec]

In order to avoid future confusion with similary named files, rename
tve.c to tve_common.c. New name better represents the fact that this file
holds code which can be and will be shared between multiple drivers.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---

 drivers/video/sunxi/Makefile                | 2 +-
 drivers/video/sunxi/{tve.c => tve_common.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/video/sunxi/{tve.c => tve_common.c} (100%)

diff --git a/drivers/video/sunxi/Makefile b/drivers/video/sunxi/Makefile
index dbaab61b59..0d64c2021f 100644
--- a/drivers/video/sunxi/Makefile
+++ b/drivers/video/sunxi/Makefile
@@ -5,5 +5,5 @@
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
-obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o lcdc.o tve.o ../videomodes.o
+obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o lcdc.o tve_common.o ../videomodes.o
 obj-$(CONFIG_VIDEO_DE2) += sunxi_de2.o sunxi_dw_hdmi.o lcdc.o ../dw_hdmi.o
diff --git a/drivers/video/sunxi/tve.c b/drivers/video/sunxi/tve_common.c
similarity index 100%
rename from drivers/video/sunxi/tve.c
rename to drivers/video/sunxi/tve_common.c
-- 
2.13.0

[U-Boot] [PATCH v2 1/4] sunxi: video: Rename tve.c to tve_common.c

[Maxime Ripard]

On Fri, May 19, 2017 at 05:41:14PM +0200, Jernej Skrabec wrote:
> In order to avoid future confusion with similary named files, rename
> tve.c to tve_common.c. New name better represents the fact that this file
> holds code which can be and will be shared between multiple drivers.
> 
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Thanks!
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: <http://lists.denx.de/pipermail/u-boot/attachments/20170522/6a25930b/attachment.sig>

[U-Boot] [PATCH v2 1/4] sunxi: video: Rename tve.c to tve_common.c

[Simon Glass]

On 19 May 2017 at 09:41, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> In order to avoid future confusion with similary named files, rename
> tve.c to tve_common.c. New name better represents the fact that this file
> holds code which can be and will be shared between multiple drivers.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
>
>  drivers/video/sunxi/Makefile                | 2 +-
>  drivers/video/sunxi/{tve.c => tve_common.c} | 0
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  rename drivers/video/sunxi/{tve.c => tve_common.c} (100%)
>

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH v2 1/4] sunxi: video: Rename tve.c to tve_common.c

[Anatolij Gustschin]

Hi Jernej,

On Fri, 19 May 2017 17:41:14 +0200
Jernej Skrabec jernej.skrabec at siol.net wrote:

> In order to avoid future confusion with similary named files, rename
> tve.c to tve_common.c. New name better represents the fact that this file
> holds code which can be and will be shared between multiple drivers.
> 
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> 
>  drivers/video/sunxi/Makefile                | 2 +-
>  drivers/video/sunxi/{tve.c => tve_common.c} | 0
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  rename drivers/video/sunxi/{tve.c => tve_common.c} (100%)

applied to u-boot-video/master, thanks!

--
Anatolij

[U-Boot] [PATCH v2 2/4] sunxi: Add base address for TV encoder

[Jernej Skrabec]

This commit adds TVE base address for Allwinner H3 and H5 SoCs.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---

 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index 6aa5e91ada..2419062d45 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -34,7 +34,9 @@
 #define SUNXI_MS_BASE			0x01c07000
 #define SUNXI_TVD_BASE			0x01c08000
 #define SUNXI_CSI0_BASE			0x01c09000
+#ifndef CONFIG_MACH_SUNXI_H3_H5
 #define SUNXI_TVE0_BASE			0x01c0a000
+#endif
 #define SUNXI_EMAC_BASE			0x01c0b000
 #define SUNXI_LCD0_BASE			0x01c0C000
 #define SUNXI_LCD1_BASE			0x01c0d000
@@ -161,10 +163,18 @@ defined(CONFIG_MACH_SUN50I)
 /* module sram */
 #define SUNXI_SRAM_C_BASE		0x01d00000
 
+#ifndef CONFIG_MACH_SUN8I_H3
 #define SUNXI_DE_FE0_BASE		0x01e00000
+#else
+#define SUNXI_TVE0_BASE			0x01e00000
+#endif
 #define SUNXI_DE_FE1_BASE		0x01e20000
 #define SUNXI_DE_BE0_BASE		0x01e60000
+#ifndef CONFIG_MACH_SUN50I_H5
 #define SUNXI_DE_BE1_BASE		0x01e40000
+#else
+#define SUNXI_TVE0_BASE			0x01e40000
+#endif
 #define SUNXI_MP_BASE			0x01e80000
 #define SUNXI_AVG_BASE			0x01ea0000
 
-- 
2.13.0

[U-Boot] [PATCH v2 2/4] sunxi: Add base address for TV encoder

[Maxime Ripard]

On Fri, May 19, 2017 at 05:41:15PM +0200, Jernej Skrabec wrote:
> This commit adds TVE base address for Allwinner H3 and H5 SoCs.
> 
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

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: <http://lists.denx.de/pipermail/u-boot/attachments/20170522/e1973afc/attachment.sig>

[U-Boot] [PATCH v2 2/4] sunxi: Add base address for TV encoder

[Anatolij Gustschin]

On Fri, 19 May 2017 17:41:15 +0200
Jernej Skrabec jernej.skrabec at siol.net wrote:

> This commit adds TVE base address for Allwinner H3 and H5 SoCs.
> 
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> 
>  arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 10 ++++++++++
>  1 file changed, 10 insertions(+)

applied to u-boot-video/master, thanks!

--
Anatolij

[U-Boot] [PATCH v2 3/4] sunxi: video: Add support for CSC and TVE to DE2 driver

[Jernej Skrabec]

Extend DE2 driver with support for TVE driver, which will be added in
next commit. TVE unit expects data to be in YUV format, so CSC support
is also added here.

Note that HDMI driver has higher priority, so TV out is not probed if
HDMI monitor is detected.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---

 arch/arm/include/asm/arch-sunxi/display2.h | 17 +++++++++
 drivers/video/sunxi/sunxi_de2.c            | 60 ++++++++++++++++++++++++------
 2 files changed, 65 insertions(+), 12 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/display2.h b/arch/arm/include/asm/arch-sunxi/display2.h
index b5875f9605..359cacd90b 100644
--- a/arch/arm/include/asm/arch-sunxi/display2.h
+++ b/arch/arm/include/asm/arch-sunxi/display2.h
@@ -90,6 +90,23 @@ struct de_ui {
 	u32 ovl_size;
 };
 
+struct de_csc {
+	u32 csc_ctl;
+	u8 res[0xc];
+	u32 coef11;
+	u32 coef12;
+	u32 coef13;
+	u32 coef14;
+	u32 coef21;
+	u32 coef22;
+	u32 coef23;
+	u32 coef24;
+	u32 coef31;
+	u32 coef32;
+	u32 coef33;
+	u32 coef34;
+};
+
 /*
  * DE register constants.
  */
diff --git a/drivers/video/sunxi/sunxi_de2.c b/drivers/video/sunxi/sunxi_de2.c
index 9a32c3a020..ee67764ac5 100644
--- a/drivers/video/sunxi/sunxi_de2.c
+++ b/drivers/video/sunxi/sunxi_de2.c
@@ -56,7 +56,7 @@ static void sunxi_de2_composer_init(void)
 }
 
 static void sunxi_de2_mode_set(int mux, const struct display_timing *mode,
-			       int bpp, ulong address)
+			       int bpp, ulong address, bool is_composite)
 {
 	ulong de_mux_base = (mux == 0) ?
 			    SUNXI_DE2_MUX0_BASE : SUNXI_DE2_MUX1_BASE;
@@ -72,6 +72,9 @@ static void sunxi_de2_mode_set(int mux, const struct display_timing *mode,
 		(struct de_ui *)(de_mux_base +
 				 SUNXI_DE2_MUX_CHAN_REGS +
 				 SUNXI_DE2_MUX_CHAN_SZ * 1);
+	struct de_csc * const de_csc_regs =
+		(struct de_csc *)(de_mux_base +
+				  SUNXI_DE2_MUX_DCSC_REGS);
 	u32 size = SUNXI_DE2_WH(mode->hactive.typ, mode->vactive.typ);
 	int channel;
 	u32 format;
@@ -128,7 +131,27 @@ static void sunxi_de2_mode_set(int mux, const struct display_timing *mode,
 	writel(0, de_mux_base + SUNXI_DE2_MUX_PEAK_REGS);
 	writel(0, de_mux_base + SUNXI_DE2_MUX_ASE_REGS);
 	writel(0, de_mux_base + SUNXI_DE2_MUX_FCC_REGS);
-	writel(0, de_mux_base + SUNXI_DE2_MUX_DCSC_REGS);
+
+	if (is_composite) {
+		/* set CSC coefficients */
+		writel(0x107, &de_csc_regs->coef11);
+		writel(0x204, &de_csc_regs->coef12);
+		writel(0x64, &de_csc_regs->coef13);
+		writel(0x4200, &de_csc_regs->coef14);
+		writel(0x1f68, &de_csc_regs->coef21);
+		writel(0x1ed6, &de_csc_regs->coef22);
+		writel(0x1c2, &de_csc_regs->coef23);
+		writel(0x20200, &de_csc_regs->coef24);
+		writel(0x1c2, &de_csc_regs->coef31);
+		writel(0x1e87, &de_csc_regs->coef32);
+		writel(0x1fb7, &de_csc_regs->coef33);
+		writel(0x20200, &de_csc_regs->coef34);
+
+		/* enable CSC unit */
+		writel(1, &de_csc_regs->csc_ctl);
+	} else {
+		writel(0, &de_csc_regs->csc_ctl);
+	}
 
 	switch (bpp) {
 	case 16:
@@ -153,7 +176,7 @@ static void sunxi_de2_mode_set(int mux, const struct display_timing *mode,
 
 static int sunxi_de2_init(struct udevice *dev, ulong fbbase,
 			  enum video_log2_bpp l2bpp,
-			  struct udevice *disp, int mux)
+			  struct udevice *disp, int mux, bool is_composite)
 {
 	struct video_priv *uc_priv = dev_get_uclass_priv(dev);
 	struct display_timing timing;
@@ -183,7 +206,7 @@ static int sunxi_de2_init(struct udevice *dev, ulong fbbase,
 	}
 
 	sunxi_de2_composer_init();
-	sunxi_de2_mode_set(mux, &timing, 1 << l2bpp, fbbase);
+	sunxi_de2_mode_set(mux, &timing, 1 << l2bpp, fbbase, is_composite);
 
 	ret = display_enable(disp, 1 << l2bpp, &timing);
 	if (ret) {
@@ -204,7 +227,6 @@ static int sunxi_de2_probe(struct udevice *dev)
 	struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
 	struct udevice *disp;
 	int ret;
-	int mux;
 
 	/* Before relocation we don't need to do anything */
 	if (!(gd->flags & GD_FLG_RELOC))
@@ -212,17 +234,31 @@ static int sunxi_de2_probe(struct udevice *dev)
 
 	ret = uclass_find_device_by_name(UCLASS_DISPLAY,
 					 "sunxi_dw_hdmi", &disp);
+	if (!ret) {
+		int mux;
+		if (IS_ENABLED(CONFIG_MACH_SUNXI_H3_H5))
+			mux = 0;
+		else
+			mux = 1;
+
+		ret = sunxi_de2_init(dev, plat->base, VIDEO_BPP32, disp, mux,
+				     false);
+		if (!ret) {
+			video_set_flush_dcache(dev, 1);
+			return 0;
+		}
+	}
+
+	debug("%s: hdmi display not found (ret=%d)\n", __func__, ret);
+
+	ret = uclass_find_device_by_name(UCLASS_DISPLAY,
+					"sunxi_tve", &disp);
 	if (ret) {
-		debug("%s: hdmi display not found (ret=%d)\n", __func__, ret);
+		debug("%s: tv not found (ret=%d)\n", __func__, ret);
 		return ret;
 	}
 
-	if (IS_ENABLED(CONFIG_MACH_SUNXI_H3_H5))
-		mux = 0;
-	else
-		mux = 1;
-
-	ret = sunxi_de2_init(dev, plat->base, VIDEO_BPP32, disp, mux);
+	ret = sunxi_de2_init(dev, plat->base, VIDEO_BPP32, disp, 1, true);
 	if (ret)
 		return ret;
 
-- 
2.13.0

[U-Boot] [PATCH v2 3/4] sunxi: video: Add support for CSC and TVE to DE2 driver

[Maxime Ripard]

On Fri, May 19, 2017 at 05:41:16PM +0200, Jernej Skrabec wrote:
> Extend DE2 driver with support for TVE driver, which will be added in
> next commit. TVE unit expects data to be in YUV format, so CSC support
> is also added here.
> 
> Note that HDMI driver has higher priority, so TV out is not probed if
> HDMI monitor is detected.
> 
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Thanks!
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: <http://lists.denx.de/pipermail/u-boot/attachments/20170522/b976b6a6/attachment.sig>

[U-Boot] [PATCH v2 3/4] sunxi: video: Add support for CSC and TVE to DE2 driver

[Simon Glass]

On 19 May 2017 at 09:41, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> Extend DE2 driver with support for TVE driver, which will be added in
> next commit. TVE unit expects data to be in YUV format, so CSC support
> is also added here.
>
> Note that HDMI driver has higher priority, so TV out is not probed if
> HDMI monitor is detected.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
>
>  arch/arm/include/asm/arch-sunxi/display2.h | 17 +++++++++
>  drivers/video/sunxi/sunxi_de2.c            | 60 ++++++++++++++++++++++++------
>  2 files changed, 65 insertions(+), 12 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH v2 3/4] sunxi: video: Add support for CSC and TVE to DE2 driver

[Anatolij Gustschin]

On Fri, 19 May 2017 17:41:16 +0200
Jernej Skrabec jernej.skrabec at siol.net wrote:

> Extend DE2 driver with support for TVE driver, which will be added in
> next commit. TVE unit expects data to be in YUV format, so CSC support
> is also added here.
> 
> Note that HDMI driver has higher priority, so TV out is not probed if
> HDMI monitor is detected.
> 
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> 
>  arch/arm/include/asm/arch-sunxi/display2.h | 17 +++++++++
>  drivers/video/sunxi/sunxi_de2.c            | 60 ++++++++++++++++++++++++------
>  2 files changed, 65 insertions(+), 12 deletions(-)

applied to u-boot-video/master, thanks!

--
Anatolij

[U-Boot] [PATCH v2 4/4] sunxi: video: Add H3/H5 TV out driver

[Jernej Skrabec]

This commit adds support for TV (composite) output.

Because there is no mechanism to select TV standard, PAL is hardcoded.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---

 arch/arm/include/asm/arch-sunxi/tve.h |  17 +++-
 drivers/video/sunxi/Makefile          |   2 +-
 drivers/video/sunxi/sunxi_tve.c       | 156 ++++++++++++++++++++++++++++++++++
 drivers/video/sunxi/tve_common.c      |   6 +-
 4 files changed, 176 insertions(+), 5 deletions(-)
 create mode 100644 drivers/video/sunxi/sunxi_tve.c

diff --git a/arch/arm/include/asm/arch-sunxi/tve.h b/arch/arm/include/asm/arch-sunxi/tve.h
index 41a14a68e4..ff34bbbc12 100644
--- a/arch/arm/include/asm/arch-sunxi/tve.h
+++ b/arch/arm/include/asm/arch-sunxi/tve.h
@@ -45,7 +45,9 @@ struct sunxi_tve_reg {
 	u32 csc_reg1;			/* 0x044 */
 	u32 csc_reg2;			/* 0x048 */
 	u32 csc_reg3;			/* 0x04c */
-	u8 res1[0xb0];			/* 0x050 */
+	u8 res1[0xa8];			/* 0x050 */
+	u32 auto_detect_cfg0;		/* 0x0f8 */
+	u32 auto_detect_cfg1;		/* 0x0fc */
 	u32 color_burst;		/* 0x100 */
 	u32 vsync_num;			/* 0x104 */
 	u32 notch_freq;			/* 0x108 */
@@ -62,6 +64,10 @@ struct sunxi_tve_reg {
 	u32 slave_para;			/* 0x134 */
 	u32 cfg1;			/* 0x138 */
 	u32 cfg2;			/* 0x13c */
+	u8 res2[0x1c4];			/* 0x140 */
+	u32 calibration;		/* 0x304 */
+	u8 res3[0x4];			/* 0x308 */
+	u32 unknown3;			/* 0x30c */
 };
 
 /*
@@ -79,12 +85,14 @@ struct sunxi_tve_reg {
 #define SUNXI_TVE_CFG0_PAL			0x07030001
 #define SUNXI_TVE_CFG0_NTSC			0x07030000
 #define SUNXI_TVE_DAC_CFG0_VGA			0x403e1ac7
-#ifdef CONFIG_MACH_SUN5I
+#if defined(CONFIG_MACH_SUN5I) || defined(CONFIG_MACH_SUNXI_H3_H5)
 #define SUNXI_TVE_DAC_CFG0_COMPOSITE		0x433f0009
 #else
 #define SUNXI_TVE_DAC_CFG0_COMPOSITE		0x403f0008
 #endif
+#define SUNXI_TVE_DAC_CFG0_DETECTION		0x433f0289
 #define SUNXI_TVE_FILTER_COMPOSITE		0x00000120
+#define SUNXI_TVE_CHROMA_FREQ_PAL		0x2a098acb
 #define SUNXI_TVE_CHROMA_FREQ_PAL_M		0x21e6efe3
 #define SUNXI_TVE_CHROMA_FREQ_PAL_NC		0x21f69446
 #define SUNXI_TVE_PORCH_NUM_PAL			0x008a0018
@@ -105,6 +113,8 @@ struct sunxi_tve_reg {
 #define SUNXI_TVE_AUTO_DETECT_STATUS_SHORT_GND	3
 #define SUNXI_TVE_AUTO_DETECT_DEBOUNCE_SHIFT(d)	((d) * 8)
 #define SUNXI_TVE_AUTO_DETECT_DEBOUNCE_MASK(d)	(0xf << ((d) * 8))
+#define SUNXI_TVE_AUTO_DETECT_CFG0		0x00000280
+#define SUNXI_TVE_AUTO_DETECT_CFG1		0x028F00FF
 #define SUNXI_TVE_CSC_REG0_ENABLE		(1 << 31)
 #define SUNXI_TVE_CSC_REG0			0x08440832
 #define SUNXI_TVE_CSC_REG1			0x3b6dace1
@@ -124,6 +134,9 @@ struct sunxi_tve_reg {
 #define SUNXI_TVE_RESYNC_NUM_PAL		0x800d000c
 #define SUNXI_TVE_RESYNC_NUM_NTSC		0x000e000c
 #define SUNXI_TVE_SLAVE_PARA_COMPOSITE		0x00000000
+#define SUNXI_TVE_CALIBRATION_H3		0x02000c00
+#define SUNXI_TVE_CALIBRATION_H5		0x02850000
+#define SUNXI_TVE_UNKNOWN3_H5			0x00101110
 
 void tvencoder_mode_set(struct sunxi_tve_reg * const tve, enum tve_mode mode);
 void tvencoder_enable(struct sunxi_tve_reg * const tve);
diff --git a/drivers/video/sunxi/Makefile b/drivers/video/sunxi/Makefile
index 0d64c2021f..e63c1d65bc 100644
--- a/drivers/video/sunxi/Makefile
+++ b/drivers/video/sunxi/Makefile
@@ -6,4 +6,4 @@
 #
 
 obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o lcdc.o tve_common.o ../videomodes.o
-obj-$(CONFIG_VIDEO_DE2) += sunxi_de2.o sunxi_dw_hdmi.o lcdc.o ../dw_hdmi.o
+obj-$(CONFIG_VIDEO_DE2) += sunxi_de2.o sunxi_dw_hdmi.o sunxi_tve.o lcdc.o tve_common.o ../dw_hdmi.o
diff --git a/drivers/video/sunxi/sunxi_tve.c b/drivers/video/sunxi/sunxi_tve.c
new file mode 100644
index 0000000000..95f54bbaf7
--- /dev/null
+++ b/drivers/video/sunxi/sunxi_tve.c
@@ -0,0 +1,156 @@
+/*
+ * Allwinner TVE driver
+ *
+ * (C) Copyright 2017 Jernej Skrabec <jernej.skrabec@siol.net>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+#include <display.h>
+#include <dm.h>
+#include <asm/io.h>
+#include <asm/arch/clock.h>
+#include <asm/arch/lcdc.h>
+#include <asm/arch/tve.h>
+
+static int sunxi_tve_get_plug_in_status(void)
+{
+	struct sunxi_tve_reg * const tve =
+		(struct sunxi_tve_reg *)SUNXI_TVE0_BASE;
+	u32 status;
+
+	status = readl(&tve->auto_detect_status) &
+		SUNXI_TVE_AUTO_DETECT_STATUS_MASK(0);
+
+	return status == SUNXI_TVE_AUTO_DETECT_STATUS_CONNECTED;
+}
+
+static int sunxi_tve_wait_for_hpd(void)
+{
+	struct sunxi_tve_reg * const tve =
+		(struct sunxi_tve_reg *)SUNXI_TVE0_BASE;
+	ulong start;
+
+	/* enable auto detection */
+	writel(SUNXI_TVE_DAC_CFG0_DETECTION, &tve->dac_cfg0);
+	writel(SUNXI_TVE_AUTO_DETECT_CFG0, &tve->auto_detect_cfg0);
+	writel(SUNXI_TVE_AUTO_DETECT_CFG1, &tve->auto_detect_cfg1);
+	writel(9 << SUNXI_TVE_AUTO_DETECT_DEBOUNCE_SHIFT(0),
+	       &tve->auto_detect_debounce);
+	writel(SUNXI_TVE_AUTO_DETECT_EN_DET_EN(0), &tve->auto_detect_en);
+
+	start = get_timer(0);
+	do {
+		if (sunxi_tve_get_plug_in_status())
+			return 0;
+		udelay(100);
+	} while (get_timer(start) < 300);
+
+	return -1;
+}
+
+static void sunxi_tve_lcdc_init(const struct display_timing *edid, int bpp)
+{
+	struct sunxi_ccm_reg * const ccm =
+		(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+	struct sunxi_lcdc_reg * const lcdc =
+		(struct sunxi_lcdc_reg *)SUNXI_LCD1_BASE;
+
+	/* Reset off */
+	setbits_le32(&ccm->ahb_reset1_cfg, 1 << AHB_RESET_OFFSET_LCD1);
+
+	/* Clock on */
+	setbits_le32(&ccm->ahb_gate1, 1 << AHB_GATE_OFFSET_LCD1);
+
+	lcdc_init(lcdc);
+	lcdc_tcon1_mode_set(lcdc, edid, false, true);
+	lcdc_enable(lcdc, bpp);
+}
+
+static int sunxi_tve_read_timing(struct udevice *dev,
+				 struct display_timing *timing)
+{
+	/* PAL resolution */
+	timing->pixelclock.typ = 27000000;
+
+	timing->hactive.typ = 720;
+	timing->hfront_porch.typ = 5;
+	timing->hback_porch.typ = 137;
+	timing->hsync_len.typ = 2;
+
+	timing->vactive.typ = 576;
+	timing->vfront_porch.typ = 27;
+	timing->vback_porch.typ = 20;
+	timing->vsync_len.typ = 2;
+
+	timing->flags = DISPLAY_FLAGS_INTERLACED;
+
+	return 0;
+}
+
+static int sunxi_tve_enable(struct udevice *dev, int panel_bpp,
+			    const struct display_timing *edid)
+{
+	struct sunxi_tve_reg * const tve =
+		(struct sunxi_tve_reg *)SUNXI_TVE0_BASE;
+
+	sunxi_tve_lcdc_init(edid, panel_bpp);
+
+	tvencoder_mode_set(tve, tve_mode_composite_pal);
+	tvencoder_enable(tve);
+
+	return 0;
+}
+
+static int sunxi_tve_probe(struct udevice *dev)
+{
+	struct sunxi_ccm_reg * const ccm =
+		(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+	struct sunxi_tve_reg * const tve =
+		(struct sunxi_tve_reg *)SUNXI_TVE0_BASE;
+	int ret;
+
+	/* make sure that clock is active */
+	clock_set_pll10(432000000);
+
+	/* Reset off */
+	setbits_le32(&ccm->ahb_reset1_cfg, 1 << AHB_RESET_OFFSET_TVE);
+
+	/* Clock on */
+	setbits_le32(&ccm->ahb_gate1, 1 << AHB_GATE_OFFSET_TVE);
+	writel(CCM_TVE_CTRL_GATE | CCM_TVE_CTRL_M(2), &ccm->tve_clk_cfg);
+
+#ifdef CONFIG_MACH_SUN50I_H5
+	writel(SUNXI_TVE_CALIBRATION_H5, &tve->calibration);
+	writel(SUNXI_TVE_UNKNOWN3_H5, &tve->unknown3);
+#else
+	writel(SUNXI_TVE_CALIBRATION_H3, &tve->calibration);
+#endif
+
+	ret = sunxi_tve_wait_for_hpd();
+	if (ret < 0) {
+		debug("tve can not get hpd signal\n");
+		return -1;
+	}
+
+	return 0;
+}
+
+static const struct dm_display_ops sunxi_tve_ops = {
+	.read_timing = sunxi_tve_read_timing,
+	.enable = sunxi_tve_enable,
+};
+
+U_BOOT_DRIVER(sunxi_tve) = {
+	.name	= "sunxi_tve",
+	.id	= UCLASS_DISPLAY,
+	.ops	= &sunxi_tve_ops,
+	.probe	= sunxi_tve_probe,
+};
+
+#ifdef CONFIG_MACH_SUNXI_H3_H5
+U_BOOT_DEVICE(sunxi_tve) = {
+	.name = "sunxi_tve"
+};
+#endif
diff --git a/drivers/video/sunxi/tve_common.c b/drivers/video/sunxi/tve_common.c
index adea78a69a..ef99c111e3 100644
--- a/drivers/video/sunxi/tve_common.c
+++ b/drivers/video/sunxi/tve_common.c
@@ -25,8 +25,6 @@ void tvencoder_mode_set(struct sunxi_tve_reg * const tve, enum tve_mode mode)
 		writel(SUNXI_TVE_UNKNOWN1_VGA, &tve->unknown1);
 		break;
 	case tve_mode_composite_pal_nc:
-		writel(SUNXI_TVE_CHROMA_FREQ_PAL_NC, &tve->chroma_freq);
-		/* Fall through */
 	case tve_mode_composite_pal:
 		writel(SUNXI_TVE_GCTRL_DAC_INPUT(0, 1) |
 		       SUNXI_TVE_GCTRL_DAC_INPUT(1, 2) |
@@ -35,6 +33,10 @@ void tvencoder_mode_set(struct sunxi_tve_reg * const tve, enum tve_mode mode)
 		writel(SUNXI_TVE_CFG0_PAL, &tve->cfg0);
 		writel(SUNXI_TVE_DAC_CFG0_COMPOSITE, &tve->dac_cfg0);
 		writel(SUNXI_TVE_FILTER_COMPOSITE, &tve->filter);
+		if (mode == tve_mode_composite_pal)
+			writel(SUNXI_TVE_CHROMA_FREQ_PAL, &tve->chroma_freq);
+		else
+			writel(SUNXI_TVE_CHROMA_FREQ_PAL_NC, &tve->chroma_freq);
 		writel(SUNXI_TVE_PORCH_NUM_PAL, &tve->porch_num);
 		writel(SUNXI_TVE_LINE_NUM_PAL, &tve->line_num);
 		writel(SUNXI_TVE_BLANK_BLACK_LEVEL_PAL,
-- 
2.13.0

[U-Boot] [PATCH v2 4/4] sunxi: video: Add H3/H5 TV out driver

[Maxime Ripard]

On Fri, May 19, 2017 at 05:41:17PM +0200, Jernej Skrabec wrote:
> This commit adds support for TV (composite) output.
> 
> Because there is no mechanism to select TV standard, PAL is
> hardcoded.

I'd rather use a consistent mechanism with the old driver (even if we
only support PAL right now and reject any other option), and using
composite-pal as monitor.

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: <http://lists.denx.de/pipermail/u-boot/attachments/20170522/2a5a8ae4/attachment.sig>

[U-Boot] [PATCH v2 4/4] sunxi: video: Add H3/H5 TV out driver

[Jernej Škrabec]

Hi Maxime,

Dne ponedeljek, 22. maj 2017 ob 09:35:56 CEST je Maxime Ripard napisal(a):
> On Fri, May 19, 2017 at 05:41:17PM +0200, Jernej Skrabec wrote:
> > This commit adds support for TV (composite) output.
> > 
> > Because there is no mechanism to select TV standard, PAL is
> > hardcoded.
> 
> I'd rather use a consistent mechanism with the old driver (even if we
> only support PAL right now and reject any other option), and using
> composite-pal as monitor.
> 

I have few arguments against that:

1. Code for parsing that env variable is in videomodes.[c|h], which is clearly 
a part of an older video framework (ctfb). I didn't want to include any legacy 
code.

2. Even if this code is used for parsing, it would bring a lot of confusion. 
For now, we can say that docs/README.video does not apply to H3 and newer 
SoCs. If we implement this only partially, we would need to describe in 
details which of each setting is honored with the new driver and which not. 
Even then, a lot of users would skip that description and complain anyway.

3. If anything is done in this direction, I think that it is better to extend 
DM video framework so other drivers would benefit from that work too.

Best regards,
Jernej

[U-Boot] [PATCH v2 4/4] sunxi: video: Add H3/H5 TV out driver

[Maxime Ripard]

Hi Jernej,

On Mon, May 22, 2017 at 08:49:57PM +0200, Jernej Å krabec wrote:
> Dne ponedeljek, 22. maj 2017 ob 09:35:56 CEST je Maxime Ripard napisal(a):
> > On Fri, May 19, 2017 at 05:41:17PM +0200, Jernej Skrabec wrote:
> > > This commit adds support for TV (composite) output.
> > > 
> > > Because there is no mechanism to select TV standard, PAL is
> > > hardcoded.
> > 
> > I'd rather use a consistent mechanism with the old driver (even if we
> > only support PAL right now and reject any other option), and using
> > composite-pal as monitor.
> > 
> 
> I have few arguments against that:
> 
> 1. Code for parsing that env variable is in videomodes.[c|h], which is clearly 
> a part of an older video framework (ctfb). I didn't want to include any legacy 
> code.
> 
> 2. Even if this code is used for parsing, it would bring a lot of confusion. 
> For now, we can say that docs/README.video does not apply to H3 and newer 
> SoCs. If we implement this only partially, we would need to describe in 
> details which of each setting is honored with the new driver and which not. 
> Even then, a lot of users would skip that description and complain anyway.

The issue with this, and we've been bitten very hard on this one with
the CHIP, is that you don't really have a clear majority on that
one. If you support only PAL, half the world will be left out, and
same thing with NTSC (for some reason, we never needed to support the
less common ones like PAL-M or NTSC-J, but that just might be because
it never really sold that well in those countries, I don't have any
numbers on that).

The point is, if you just hardcode PAL for now, you will have half
your users complain, and then, when we will introduce NTSC support
eventually, we'll have to introduce some mechanism to switch between
the two, then we'll probably break the behaviour our users relied on
before, making the other half of our users pissed.

I'm not sure this is something we should just discard, or at least the
second part. Having the selection mechanism in place, even if we don't
support all the settings and just report an error in the logs in such
a case address the latter issue.

You'll also need to address how to setup the overscan, since this is
really something you want to have very quick.

> 3. If anything is done in this direction, I think that it is better
> to extend DM video framework so other drivers would benefit from
> that work too.

That makes sense, but again, this is a pre-requisite for me. And it's
not that hard to support the video modelines with a device model
driver, Linux does it, and you have a string identifier at the
beginning of it. It just has to be deterministic, but I don't think
this is an issue with U-Boot's DM.

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: <http://lists.denx.de/pipermail/u-boot/attachments/20170523/7de354ba/attachment.sig>

[U-Boot] [PATCH v2 4/4] sunxi: video: Add H3/H5 TV out driver

[Jernej Škrabec]

Hi,

Dne torek, 23. maj 2017 ob 22:22:14 CEST je Maxime Ripard napisal(a):
> Hi Jernej,
> 
> On Mon, May 22, 2017 at 08:49:57PM +0200, Jernej Å krabec wrote:
> > Dne ponedeljek, 22. maj 2017 ob 09:35:56 CEST je Maxime Ripard napisal(a):
> > > On Fri, May 19, 2017 at 05:41:17PM +0200, Jernej Skrabec wrote:
> > > > This commit adds support for TV (composite) output.
> > > > 
> > > > Because there is no mechanism to select TV standard, PAL is
> > > > hardcoded.
> > > 
> > > I'd rather use a consistent mechanism with the old driver (even if we
> > > only support PAL right now and reject any other option), and using
> > > composite-pal as monitor.
> > 
> > I have few arguments against that:
> > 
> > 1. Code for parsing that env variable is in videomodes.[c|h], which is
> > clearly a part of an older video framework (ctfb). I didn't want to
> > include any legacy code.
> > 
> > 2. Even if this code is used for parsing, it would bring a lot of
> > confusion. For now, we can say that docs/README.video does not apply to
> > H3 and newer SoCs. If we implement this only partially, we would need to
> > describe in details which of each setting is honored with the new driver
> > and which not. Even then, a lot of users would skip that description and
> > complain anyway.
> The issue with this, and we've been bitten very hard on this one with
> the CHIP, is that you don't really have a clear majority on that
> one. If you support only PAL, half the world will be left out, and
> same thing with NTSC (for some reason, we never needed to support the
> less common ones like PAL-M or NTSC-J, but that just might be because
> it never really sold that well in those countries, I don't have any
> numbers on that).
> 
> The point is, if you just hardcode PAL for now, you will have half
> your users complain, and then, when we will introduce NTSC support
> eventually, we'll have to introduce some mechanism to switch between
> the two, then we'll probably break the behaviour our users relied on
> before, making the other half of our users pissed.
> 
> I'm not sure this is something we should just discard, or at least the
> second part. Having the selection mechanism in place, even if we don't
> support all the settings and just report an error in the logs in such
> a case address the latter issue.
> 
> You'll also need to address how to setup the overscan, since this is
> really something you want to have very quick.

Ok, I'm prepared to tackle this. Do you think it is worth to delay driver 
merge?

> 
> > 3. If anything is done in this direction, I think that it is better
> > to extend DM video framework so other drivers would benefit from
> > that work too.
> 
> That makes sense, but again, this is a pre-requisite for me. And it's
> not that hard to support the video modelines with a device model
> driver, Linux does it, and you have a string identifier at the
> beginning of it. It just has to be deterministic, but I don't think
> this is an issue with U-Boot's DM.
> 

Ok, so how do you think we should implement this? If only composite modes are 
supported in the string, someone might try to set hdmi monitor. Should we just 
ignore such settings and maybe print a warning?

Also the question for Simon, how should I merge code for parsing video string 
from drivers/video/videomodes.c to DM video in a way to be useful to most 
drivers?

I guess this is the first time to support analog video output in DM video 
driver and there are some things missing such as a way to select TV standard 
and define overscan.

Or alternatively, I could make just quick edit to sunxi_tve.c driver and 
directly use old functions as they are. That way we could get something 
working very quickly, but I don't like much such approach.

Best regards,
Jernej 

[U-Boot] [PATCH v2 4/4] sunxi: video: Add H3/H5 TV out driver

[Maxime Ripard]

On Wed, May 24, 2017 at 05:34:52PM +0200, Jernej Škrabec wrote:
> Hi,
> 
> Dne torek, 23. maj 2017 ob 22:22:14 CEST je Maxime Ripard napisal(a):
> > Hi Jernej,
> > 
> > On Mon, May 22, 2017 at 08:49:57PM +0200, Jernej Škrabec wrote:
> > > Dne ponedeljek, 22. maj 2017 ob 09:35:56 CEST je Maxime Ripard napisal(a):
> > > > On Fri, May 19, 2017 at 05:41:17PM +0200, Jernej Skrabec wrote:
> > > > > This commit adds support for TV (composite) output.
> > > > > 
> > > > > Because there is no mechanism to select TV standard, PAL is
> > > > > hardcoded.
> > > > 
> > > > I'd rather use a consistent mechanism with the old driver (even if we
> > > > only support PAL right now and reject any other option), and using
> > > > composite-pal as monitor.
> > > 
> > > I have few arguments against that:
> > > 
> > > 1. Code for parsing that env variable is in videomodes.[c|h], which is
> > > clearly a part of an older video framework (ctfb). I didn't want to
> > > include any legacy code.
> > > 
> > > 2. Even if this code is used for parsing, it would bring a lot of
> > > confusion. For now, we can say that docs/README.video does not apply to
> > > H3 and newer SoCs. If we implement this only partially, we would need to
> > > describe in details which of each setting is honored with the new driver
> > > and which not. Even then, a lot of users would skip that description and
> > > complain anyway.
> > The issue with this, and we've been bitten very hard on this one with
> > the CHIP, is that you don't really have a clear majority on that
> > one. If you support only PAL, half the world will be left out, and
> > same thing with NTSC (for some reason, we never needed to support the
> > less common ones like PAL-M or NTSC-J, but that just might be because
> > it never really sold that well in those countries, I don't have any
> > numbers on that).
> > 
> > The point is, if you just hardcode PAL for now, you will have half
> > your users complain, and then, when we will introduce NTSC support
> > eventually, we'll have to introduce some mechanism to switch between
> > the two, then we'll probably break the behaviour our users relied on
> > before, making the other half of our users pissed.
> > 
> > I'm not sure this is something we should just discard, or at least the
> > second part. Having the selection mechanism in place, even if we don't
> > support all the settings and just report an error in the logs in such
> > a case address the latter issue.
> > 
> > You'll also need to address how to setup the overscan, since this is
> > really something you want to have very quick.
> 
> Ok, I'm prepared to tackle this. Do you think it is worth to delay driver 
> merge?

Not per se, but that should definitely be part of the same release, so
if you can make it by then, then we can merge that right now, and
merge the rest later. If you can't, then we'll have to postpone it a
bit.

> > > 3. If anything is done in this direction, I think that it is better
> > > to extend DM video framework so other drivers would benefit from
> > > that work too.
> > 
> > That makes sense, but again, this is a pre-requisite for me. And it's
> > not that hard to support the video modelines with a device model
> > driver, Linux does it, and you have a string identifier at the
> > beginning of it. It just has to be deterministic, but I don't think
> > this is an issue with U-Boot's DM.
> 
> Ok, so how do you think we should implement this? If only composite
> modes are supported in the string, someone might try to set hdmi
> monitor. Should we just ignore such settings and maybe print a
> warning?

I'm not sure it was your question, but I would just reject any
improper configuration, and not display anything in such a case.

> Also the question for Simon, how should I merge code for parsing
> video string from drivers/video/videomodes.c to DM video in a way to
> be useful to most drivers?
> 
> I guess this is the first time to support analog video output in DM
> video driver and there are some things missing such as a way to
> select TV standard and define overscan.

I think it can be done in the same way linux does it here:
http://elixir.free-electrons.com/linux/latest/source/drivers/video/fbdev/core/fb_cmdline.c#L35

You basically check first that there is a string matching what your
driver expects, and then get the options.

We could imagine having some extra function to parse that string and
give back a structure filled with whatever was set in that command
line. We could imagine having the common custom properties to be
parsed at that same time.

> Or alternatively, I could make just quick edit to sunxi_tve.c driver
> and directly use old functions as they are. That way we could get
> something working very quickly, but I don't like much such approach.

That's another approach, I'm fine with it as a temporary measure, but
I'm not sure how Simon feels about 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: <http://lists.denx.de/pipermail/u-boot/attachments/20170530/43e95896/attachment.sig>

[U-Boot] [PATCH v2 4/4] sunxi: video: Add H3/H5 TV out driver

[Simon Glass]

Hi Maxime,

On 30 May 2017 at 14:41, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Wed, May 24, 2017 at 05:34:52PM +0200, Jernej Škrabec wrote:
>> Hi,
>>
>> Dne torek, 23. maj 2017 ob 22:22:14 CEST je Maxime Ripard napisal(a):
>> > Hi Jernej,
>> >
>> > On Mon, May 22, 2017 at 08:49:57PM +0200, Jernej Škrabec wrote:
>> > > Dne ponedeljek, 22. maj 2017 ob 09:35:56 CEST je Maxime Ripard napisal(a):
>> > > > On Fri, May 19, 2017 at 05:41:17PM +0200, Jernej Skrabec wrote:
>> > > > > This commit adds support for TV (composite) output.
>> > > > >
>> > > > > Because there is no mechanism to select TV standard, PAL is
>> > > > > hardcoded.
>> > > >
>> > > > I'd rather use a consistent mechanism with the old driver (even if we
>> > > > only support PAL right now and reject any other option), and using
>> > > > composite-pal as monitor.
>> > >
>> > > I have few arguments against that:
>> > >
>> > > 1. Code for parsing that env variable is in videomodes.[c|h], which is
>> > > clearly a part of an older video framework (ctfb). I didn't want to
>> > > include any legacy code.
>> > >
>> > > 2. Even if this code is used for parsing, it would bring a lot of
>> > > confusion. For now, we can say that docs/README.video does not apply to
>> > > H3 and newer SoCs. If we implement this only partially, we would need to
>> > > describe in details which of each setting is honored with the new driver
>> > > and which not. Even then, a lot of users would skip that description and
>> > > complain anyway.
>> > The issue with this, and we've been bitten very hard on this one with
>> > the CHIP, is that you don't really have a clear majority on that
>> > one. If you support only PAL, half the world will be left out, and
>> > same thing with NTSC (for some reason, we never needed to support the
>> > less common ones like PAL-M or NTSC-J, but that just might be because
>> > it never really sold that well in those countries, I don't have any
>> > numbers on that).
>> >
>> > The point is, if you just hardcode PAL for now, you will have half
>> > your users complain, and then, when we will introduce NTSC support
>> > eventually, we'll have to introduce some mechanism to switch between
>> > the two, then we'll probably break the behaviour our users relied on
>> > before, making the other half of our users pissed.
>> >
>> > I'm not sure this is something we should just discard, or at least the
>> > second part. Having the selection mechanism in place, even if we don't
>> > support all the settings and just report an error in the logs in such
>> > a case address the latter issue.
>> >
>> > You'll also need to address how to setup the overscan, since this is
>> > really something you want to have very quick.
>>
>> Ok, I'm prepared to tackle this. Do you think it is worth to delay driver
>> merge?
>
> Not per se, but that should definitely be part of the same release, so
> if you can make it by then, then we can merge that right now, and
> merge the rest later. If you can't, then we'll have to postpone it a
> bit.
>
>> > > 3. If anything is done in this direction, I think that it is better
>> > > to extend DM video framework so other drivers would benefit from
>> > > that work too.
>> >
>> > That makes sense, but again, this is a pre-requisite for me. And it's
>> > not that hard to support the video modelines with a device model
>> > driver, Linux does it, and you have a string identifier at the
>> > beginning of it. It just has to be deterministic, but I don't think
>> > this is an issue with U-Boot's DM.
>>
>> Ok, so how do you think we should implement this? If only composite
>> modes are supported in the string, someone might try to set hdmi
>> monitor. Should we just ignore such settings and maybe print a
>> warning?
>
> I'm not sure it was your question, but I would just reject any
> improper configuration, and not display anything in such a case.
>
>> Also the question for Simon, how should I merge code for parsing
>> video string from drivers/video/videomodes.c to DM video in a way to
>> be useful to most drivers?
>>
>> I guess this is the first time to support analog video output in DM
>> video driver and there are some things missing such as a way to
>> select TV standard and define overscan.
>
> I think it can be done in the same way linux does it here:
> http://elixir.free-electrons.com/linux/latest/source/drivers/video/fbdev/core/fb_cmdline.c#L35
>
> You basically check first that there is a string matching what your
> driver expects, and then get the options.
>
> We could imagine having some extra function to parse that string and
> give back a structure filled with whatever was set in that command
> line. We could imagine having the common custom properties to be
> parsed at that same time.
>
>> Or alternatively, I could make just quick edit to sunxi_tve.c driver
>> and directly use old functions as they are. That way we could get
>> something working very quickly, but I don't like much such approach.
>
> That's another approach, I'm fine with it as a temporary measure, but
> I'm not sure how Simon feels about it.

Well how about a function that decodes the string into a struct? That
function could be called by any drivers that need it.

Regards,
Simon


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

[U-Boot] [PATCH v2 4/4] sunxi: video: Add H3/H5 TV out driver

[Maxime Ripard]

On Wed, May 31, 2017 at 09:11:15PM -0600, Simon Glass wrote:
> Hi Maxime,
> 
> On 30 May 2017 at 14:41, Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> > On Wed, May 24, 2017 at 05:34:52PM +0200, Jernej Škrabec wrote:
> >> Hi,
> >>
> >> Dne torek, 23. maj 2017 ob 22:22:14 CEST je Maxime Ripard napisal(a):
> >> > Hi Jernej,
> >> >
> >> > On Mon, May 22, 2017 at 08:49:57PM +0200, Jernej Škrabec wrote:
> >> > > Dne ponedeljek, 22. maj 2017 ob 09:35:56 CEST je Maxime Ripard napisal(a):
> >> > > > On Fri, May 19, 2017 at 05:41:17PM +0200, Jernej Skrabec wrote:
> >> > > > > This commit adds support for TV (composite) output.
> >> > > > >
> >> > > > > Because there is no mechanism to select TV standard, PAL is
> >> > > > > hardcoded.
> >> > > >
> >> > > > I'd rather use a consistent mechanism with the old driver (even if we
> >> > > > only support PAL right now and reject any other option), and using
> >> > > > composite-pal as monitor.
> >> > >
> >> > > I have few arguments against that:
> >> > >
> >> > > 1. Code for parsing that env variable is in videomodes.[c|h], which is
> >> > > clearly a part of an older video framework (ctfb). I didn't want to
> >> > > include any legacy code.
> >> > >
> >> > > 2. Even if this code is used for parsing, it would bring a lot of
> >> > > confusion. For now, we can say that docs/README.video does not apply to
> >> > > H3 and newer SoCs. If we implement this only partially, we would need to
> >> > > describe in details which of each setting is honored with the new driver
> >> > > and which not. Even then, a lot of users would skip that description and
> >> > > complain anyway.
> >> > The issue with this, and we've been bitten very hard on this one with
> >> > the CHIP, is that you don't really have a clear majority on that
> >> > one. If you support only PAL, half the world will be left out, and
> >> > same thing with NTSC (for some reason, we never needed to support the
> >> > less common ones like PAL-M or NTSC-J, but that just might be because
> >> > it never really sold that well in those countries, I don't have any
> >> > numbers on that).
> >> >
> >> > The point is, if you just hardcode PAL for now, you will have half
> >> > your users complain, and then, when we will introduce NTSC support
> >> > eventually, we'll have to introduce some mechanism to switch between
> >> > the two, then we'll probably break the behaviour our users relied on
> >> > before, making the other half of our users pissed.
> >> >
> >> > I'm not sure this is something we should just discard, or at least the
> >> > second part. Having the selection mechanism in place, even if we don't
> >> > support all the settings and just report an error in the logs in such
> >> > a case address the latter issue.
> >> >
> >> > You'll also need to address how to setup the overscan, since this is
> >> > really something you want to have very quick.
> >>
> >> Ok, I'm prepared to tackle this. Do you think it is worth to delay driver
> >> merge?
> >
> > Not per se, but that should definitely be part of the same release, so
> > if you can make it by then, then we can merge that right now, and
> > merge the rest later. If you can't, then we'll have to postpone it a
> > bit.
> >
> >> > > 3. If anything is done in this direction, I think that it is better
> >> > > to extend DM video framework so other drivers would benefit from
> >> > > that work too.
> >> >
> >> > That makes sense, but again, this is a pre-requisite for me. And it's
> >> > not that hard to support the video modelines with a device model
> >> > driver, Linux does it, and you have a string identifier at the
> >> > beginning of it. It just has to be deterministic, but I don't think
> >> > this is an issue with U-Boot's DM.
> >>
> >> Ok, so how do you think we should implement this? If only composite
> >> modes are supported in the string, someone might try to set hdmi
> >> monitor. Should we just ignore such settings and maybe print a
> >> warning?
> >
> > I'm not sure it was your question, but I would just reject any
> > improper configuration, and not display anything in such a case.
> >
> >> Also the question for Simon, how should I merge code for parsing
> >> video string from drivers/video/videomodes.c to DM video in a way to
> >> be useful to most drivers?
> >>
> >> I guess this is the first time to support analog video output in DM
> >> video driver and there are some things missing such as a way to
> >> select TV standard and define overscan.
> >
> > I think it can be done in the same way linux does it here:
> > http://elixir.free-electrons.com/linux/latest/source/drivers/video/fbdev/core/fb_cmdline.c#L35
> >
> > You basically check first that there is a string matching what your
> > driver expects, and then get the options.
> >
> > We could imagine having some extra function to parse that string and
> > give back a structure filled with whatever was set in that command
> > line. We could imagine having the common custom properties to be
> > parsed at that same time.
> >
> >> Or alternatively, I could make just quick edit to sunxi_tve.c driver
> >> and directly use old functions as they are. That way we could get
> >> something working very quickly, but I don't like much such approach.
> >
> > That's another approach, I'm fine with it as a temporary measure, but
> > I'm not sure how Simon feels about it.
> 
> Well how about a function that decodes the string into a struct? That
> function could be called by any drivers that need it.

That was my first suggestion, so I'm fine with that :)

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: <http://lists.denx.de/pipermail/u-boot/attachments/20170601/ec58bb59/attachment.sig>