Use DRM component API in tilcdc to connect to tda998x

Remove tilcdc slave support and connect to tda998x trough its component DRM API. For dtb backward compatibility the code creates at boot time a DT overlay based on the earlier binding. The overlay conforms to the new graph based binding.

The first patch is just a bugfix and can be applied or dropped independenty.

Jyri Sarha (6):
drm/tilcdc: Fix module unloading
drm/tilcdc: Remove tilcdc slave support for tda998x driver drm/tilcdc: Add support for external compontised DRM encoder drm/tilcdc: Add DRM_TILCDC_INIT for "ti,tilcdc,slave" binding support drm/tilcdc: Force building of DRM_TILCDC_INIT
ARM: dts: am335x-boneblack: Use new binding for HDMI

 .../devicetree/bindings/drm/tilcdc/slave.txt       |  18 -
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt      |  27 ++
 arch/arm/boot/dts/am335x-boneblack.dts             |  20 +-
 drivers/gpu/drm/Makefile                           |   1 +
 drivers/gpu/drm/tilcdc/Kconfig                     |   6 +
 drivers/gpu/drm/tilcdc/Makefile                    |   4 +-
 drivers/gpu/drm/tilcdc/tilcdc_boot_init.c          | 270 ++++++++++++++
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c               |  36 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c                |  69 ++--
 drivers/gpu/drm/tilcdc/tilcdc_drv.h                |   3 +-
 drivers/gpu/drm/tilcdc/tilcdc_external.c           | 105 ++++++
 drivers/gpu/drm/tilcdc/tilcdc_external.h           |  24 ++
 drivers/gpu/drm/tilcdc/tilcdc_slave.c              | 411 ---------------------
 drivers/gpu/drm/tilcdc/tilcdc_slave.h              |  26 --
 drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts    |  70 ++++
 15 files changed, 601 insertions(+), 489 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_boot_init.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts

1.9.1

Force crtc dpms off before destroying the crtc instead of just checking the dpms state. This fixes warning message and frozen picture after tilcdc module unloading.

---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

index c735884..c2d5980 100644
@@ -135,11 +135,12 @@ static void stop(struct drm_crtc *crtc)
 	tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
 }
 
+static void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode);
 static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
 {
 	struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
 
-	WARN_ON(tilcdc_crtc->dpms == DRM_MODE_DPMS_ON);
+	tilcdc_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
 
 	drm_crtc_cleanup(crtc);
 	drm_flip_work_cleanup(&tilcdc_crtc->unref_work);

1.9.1

Remove tilcdc slave support for tda998x driver. The tilcdc slave support would conflicts with componentized use of tda998x.

---
 .../devicetree/bindings/drm/tilcdc/slave.txt       |  18 -
 drivers/gpu/drm/tilcdc/Makefile                    |   1 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.c                |  13 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.h                |   1 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.c              | 411 ---------------------
 drivers/gpu/drm/tilcdc/tilcdc_slave.h              |  26 --
 6 files changed, 470 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h

deleted file mode 100644
index 3d2c524..0000000
@@ -1,18 +0,0 @@
-Device-Tree bindings for tilcdc DRM encoder slave output driver
-
-Required properties:
- - compatible: value should be "ti,tilcdc,slave".
- - i2c: the phandle for the i2c device the encoder slave is connected to
-
-Recommended properties:
- - pinctrl-names, pinctrl-0: the pincontrol settings to configure
-   muxing properly for pins that connect to TFP410 device
-
-Example:
-
-	hdmi {
-		compatible = "ti,tilcdc,slave";
-		i2c = <&i2c0>;
-		pinctrl-names = "default";
-		pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
-	};

index 7d2eefe..44485f9 100644
@@ -6,7 +6,6 @@ endif
 tilcdc-y := \
 	tilcdc_crtc.o \
 	tilcdc_tfp410.o \
-	tilcdc_slave.o \
 	tilcdc_panel.o \
 	tilcdc_drv.o
 

index 095fca9..0f1e099 100644
@@ -20,13 +20,11 @@
 #include "tilcdc_drv.h"
 #include "tilcdc_regs.h"
 #include "tilcdc_tfp410.h"
-#include "tilcdc_slave.h"
 #include "tilcdc_panel.h"
 
 #include "drm_fb_helper.h"
 
 static LIST_HEAD(module_list);
-static bool slave_probing;
 
 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
 		const struct tilcdc_module_ops *funcs)

@@ -42,11 +40,6 @@ void tilcdc_module_cleanup(struct tilcdc_module *mod)
 	list_del(&mod->list);
 }
 
-void tilcdc_slave_probedefer(bool defered)
-{
-	slave_probing = defered;
-}
-
 static struct of_device_id tilcdc_of_match[];
 
 static struct drm_framebuffer *tilcdc_fb_create(struct drm_device *dev,

@@ -620,10 +613,6 @@ static int tilcdc_pdev_probe(struct platform_device *pdev)
 		return -ENXIO;
 	}
 
-	/* defer probing if slave is in deferred probing */
-	if (slave_probing == true)
-		return -EPROBE_DEFER;
-
 	return drm_platform_init(&tilcdc_driver, pdev);
 }
 

@@ -654,7 +643,6 @@ static int __init tilcdc_drm_init(void)
 {
 	DBG("init");
 	tilcdc_tfp410_init();
-	tilcdc_slave_init();
 	tilcdc_panel_init();
 	return platform_driver_register(&tilcdc_platform_driver);
 }

@@ -664,7 +652,6 @@ static void __exit tilcdc_drm_fini(void)
 	DBG("fini");
 	platform_driver_unregister(&tilcdc_platform_driver);
 	tilcdc_panel_fini();
-	tilcdc_slave_fini();
 	tilcdc_tfp410_fini();
 }
 

index 7596c14..6336512 100644
@@ -116,7 +116,6 @@ struct tilcdc_module {
 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
 		const struct tilcdc_module_ops *funcs);
 void tilcdc_module_cleanup(struct tilcdc_module *mod);
-void tilcdc_slave_probedefer(bool defered);
 
 /* Panel config that needs to be set in the crtc, but is not coming from
  * the mode timings.  The display module is expected to call

deleted file mode 100644
index 2f85048..0000000
@@ -1,26 +0,0 @@
-/*
- * Copyright (C) 2012 Texas Instruments
- * Author: Rob Clark <[email protected]>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-
-#ifndef __TILCDC_SLAVE_H__
-#define __TILCDC_SLAVE_H__
-
-/* sub-module for i2c slave encoder output */
-
-int tilcdc_slave_init(void);
-void tilcdc_slave_fini(void);
-
-#endif /* __TILCDC_SLAVE_H__ */

1.9.1

Add support for an external compontised DRM encoder. The external encoder can be connected to tilcdc trough device tree graph binding. The binding document for tilcdc has been updated. The support has only been tested with tda998x encoder, but other encoders should work too with a little tweaking.

I got the idea and some lines of code from Jean-Francois Moine's "drm/tilcdc: Change the interface with the tda998x driver"-patch.

---
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt      |  27 ++++++
 drivers/gpu/drm/tilcdc/Makefile                    |   1 +
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c               |  33 +++++++
 drivers/gpu/drm/tilcdc/tilcdc_drv.c                |  56 ++++++++---
 drivers/gpu/drm/tilcdc/tilcdc_drv.h                |   2 +
 drivers/gpu/drm/tilcdc/tilcdc_external.c           | 105 +++++++++++++++++++++
 drivers/gpu/drm/tilcdc/tilcdc_external.h           |  24 +++++
 7 files changed, 235 insertions(+), 13 deletions(-)
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h

index fff10da..2136ee8 100644
@@ -18,6 +18,12 @@ Optional properties:
  - max-pixelclock: The maximum pixel clock that can be supported
    by the lcd controller in KHz.
 
+Optional nodes:
+
+ - port/ports: to describe a connection to an external encoder. The
+   binding follows Documentation/devicetree/bindings/graph.txt and
+   suppors a single port with a single endpoint.
+
 Example:
 
 	fb: fb@4830e000 {

@@ -26,4 +32,25 @@ Example:
 		interrupt-parent = <&intc>;
 		interrupts = <36>;
 		ti,hwmods = "lcdc";
+
+		port {
+			lcdc_0: endpoint@0 {
+				remote-endpoint = <&hdmi_0>;
+			};
+		};
+	};
+
+	tda19988: tda19988 {
+		compatible = "nxp,tda998x";
+		reg = <0x70>;
+
+		pinctrl-names = "default", "off";
+		pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
+		pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
+
+		port {
+			hdmi_0: endpoint@0 {
+				remote-endpoint = <&lcdc_0>;
+			};
+		};
 	};

index 44485f9..e1f738b 100644
@@ -7,6 +7,7 @@ tilcdc-y := \
 	tilcdc_crtc.o \
 	tilcdc_tfp410.o \
 	tilcdc_panel.o \
+	tilcdc_external.o \
 	tilcdc_drv.o
 
 obj-$(CONFIG_DRM_TILCDC)	+= tilcdc.o

index c2d5980..7d07733 100644
@@ -37,6 +37,9 @@ struct tilcdc_crtc {
 
 	/* for deferred fb unref's: */
 	struct drm_flip_work unref_work;
+
+	/* Only set if an external encoder is connected */
+	bool simulate_vesa_sync;
 };
 #define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)
 

@@ -214,6 +217,28 @@ static bool tilcdc_crtc_mode_fixup(struct drm_crtc *crtc,
 		const struct drm_display_mode *mode,
 		struct drm_display_mode *adjusted_mode)
 {
+	struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+	if (!tilcdc_crtc->simulate_vesa_sync)
+		return true;
+
+	/*
+	 * tilcdc does not generate VESA-compliant sync but aligns
+	 * VS on the second edge of HS instead of first edge.
+	 * We use adjusted_mode, to fixup sync by aligning both rising
+	 * edges and add HSKEW offset to fix the sync.
+	 */
+	adjusted_mode->hskew = mode->hsync_end - mode->hsync_start;
+	adjusted_mode->flags |= DRM_MODE_FLAG_HSKEW;
+
+	if (mode->flags & DRM_MODE_FLAG_NHSYNC) {
+		adjusted_mode->flags |= DRM_MODE_FLAG_PHSYNC;
+		adjusted_mode->flags &= ~DRM_MODE_FLAG_NHSYNC;
+	} else {
+		adjusted_mode->flags |= DRM_MODE_FLAG_NHSYNC;
+		adjusted_mode->flags &= ~DRM_MODE_FLAG_PHSYNC;
+	}
+
 	return true;
 }
 

@@ -534,6 +559,14 @@ void tilcdc_crtc_set_panel_info(struct drm_crtc *crtc,
 	tilcdc_crtc->info = info;
 }
 
+void tilcdc_crtc_set_simulate_vesa_sync(struct drm_crtc *crtc,
+					bool simulate_vesa_sync)
+{
+	struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+	tilcdc_crtc->simulate_vesa_sync = simulate_vesa_sync;
+}
+
 void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
 {
 	struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);

index 6336512..70a06c7 100644
@@ -165,6 +165,8 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc);
 void tilcdc_crtc_update_clk(struct drm_crtc *crtc);
 void tilcdc_crtc_set_panel_info(struct drm_crtc *crtc,
 		const struct tilcdc_panel_info *info);
+void tilcdc_crtc_set_simulate_vesa_sync(struct drm_crtc *crtc,
+					bool simulate_vesa_sync);
 int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct drm_display_mode *mode);
 int tilcdc_crtc_max_width(struct drm_crtc *crtc);
 

new file mode 100644
index 0000000..8acf3a1
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2015 Texas Instruments
+ * Author: Jyri Sarha <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __TILCDC_EXTERNAL_H__
+#define __TILCDC_EXTERNAL_H__
+
+int tilcdc_add_external_encoders(struct drm_device *dev, int *bpp);
+int tilcdc_add_external_components(struct device *master, struct master *m);
+
+#endif /* __TILCDC_SLAVE_H__ */

1.9.1

<snip>

Will remove.

That is otherwise fine, but with the match code it not possible to implement a master that may not have any components.

Would it be Ok to add a check that master->ops->add_components is defined, before calling it in find_componets() (drivers/base/component.c:120) and return 0 if it is not?

Best regards,
Jyri

No:

http://ftp.arm.linux.org.uk/cgit/linux-arm.git/commit/?h=8c4e8764a7e3

also:

http://ftp.arm.linux.org.uk/cgit/linux-arm.git/log/?h=11eda5aaf41e

is what's planned to be merged when I can get a round tuit, and people stop using the old methods.

FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Ok, but could it still be allowed to add a master without any components (match == NULL)?

Or do I have to handle the configurations without any components separately?

Best regards,
Jyri

That's not a decision I want to make in my current state. Give me a couple of week or two and re-ping me.

http://archive.arm.linux.org.uk/lurker/message/20150306.102749.fcabd2bf.en.html

(and the reason becomes self-evident when you realise that message did not go to the right list on Tuesday evening when it was meant to.)

FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Adds a DRM_TILCDC_INIT module for "ti,tilcdc,slave" node conversion. The implementation is in tilcdc_boot_init.c and it uses tilcdc_slave_convert.dts as a basis for creating a DTS overlay. The DTS overlay adds an external tda998x encoder to tilcdc that corresponds to the old tda998x based slave encoder.

---
 drivers/gpu/drm/tilcdc/Kconfig                  |   6 +
 drivers/gpu/drm/tilcdc/Makefile                 |   2 +
 drivers/gpu/drm/tilcdc/tilcdc_boot_init.c       | 270 ++++++++++++++++++++++++
 drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts |  70 ++++++
 4 files changed, 348 insertions(+)
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_boot_init.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts

index 8394a0b..c35d088 100644
@@ -1,3 +1,8 @@
+config DRM_TILCDC_INIT
+	select OF_RESOLVE
+	select OF_OVERLAY
+	bool
+
 config DRM_TILCDC
 	tristate "DRM Support for TI LCDC Display Controller"
 	depends on DRM && OF && ARM && HAVE_DMA_ATTRS

@@ -8,6 +13,7 @@ config DRM_TILCDC
 	select VIDEOMODE_HELPERS
 	select BACKLIGHT_CLASS_DEVICE
 	select BACKLIGHT_LCD_SUPPORT
+	select DRM_TILCDC_INIT
 	help
 	  Choose this option if you have an TI SoC with LCDC display
 	  controller, for example AM33xx in beagle-bone, DA8xx, or

index e1f738b..fa184a5 100644
@@ -3,6 +3,8 @@ ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
 	ccflags-y += -Werror
 endif
 
+obj-$(CONFIG_DRM_TILCDC_INIT) += tilcdc_boot_init.o tilcdc_slave_convert.dtb.o
+
 tilcdc-y := \
 	tilcdc_crtc.o \
 	tilcdc_tfp410.o \

1.9.1

All this is needed to support the old bindings, right? So I would suggest scratching "DRM_TILCDC_INIT", and create "DRM_TILCDC_COMPAT_SLAVE" or whatever, which would be a user visible option, enabled by default.

This way one can just disable all this compatibility stuff if it's not needed.

Tomi

If I read Documentation/kbuild/makefiles.txt section 3.6 right, this patch should not be needed. However, without this patch the objects needed for DRM_TILCDC_INIT are not linked, if DRM_TILCDC is built as module.

---
 drivers/gpu/drm/Makefile | 1 +
 1 file changed, 1 insertion(+)

index 2c239b9..62c6158 100644
@@ -60,6 +60,7 @@ obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
 obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
 obj-$(CONFIG_DRM_OMAP)	+= omapdrm/
 obj-$(CONFIG_DRM_TILCDC)	+= tilcdc/
+obj-$(CONFIG_DRM_TILCDC_INIT)	+= tilcdc/
 obj-$(CONFIG_DRM_QXL) += qxl/
 obj-$(CONFIG_DRM_BOCHS) += bochs/
 obj-$(CONFIG_DRM_MSM) += msm/

1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

I also think there's something funny either with the documentation or the kernel build system.

To summarize (Jyri correct me if I'm wrong):

We enter tilcdc directory using "obj-$(CONFIG_DRM_TILCDC)", and CONFIG_DRM_TILCDC is either y or m. Inside the directory we have the necessary makefile and code to build the driver as module or built-in. And this works fine.

But now Jyri added new piece of code to tilcdc directory, which is always built-in, even if the tilcdc driver itself is a module. So now if we enter the directory with "obj-m", and inside the tilcdc/Makefile we do "obj-y += foo.o" line, the result is that foo.o is compiled, but it is not linked either to the kernel image nor to the tilcdc.ko.

The doc says:

"Kbuild only uses this information to decide that it needs to visit the directory, it is the Makefile in the subdirectory that specifies what is modular and what is built-in."

which doesn't seem to work for us.

Use new binding for the external tda19988 HDMI encoder.

---
 arch/arm/boot/dts/am335x-boneblack.dts | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

index 5c42d25..eadbba3 100644
@@ -68,16 +68,26 @@
 
 &lcdc {
 	status = "okay";
+	port {
+		lcdc_0: endpoint@0 {
+			remote-endpoint = <&hdmi_0>;
+		};
+	};
 };
 
-/ {
-	hdmi {
-		compatible = "ti,tilcdc,slave";
-		i2c = <&i2c0>;
+&i2c0 {
+	tda19988 {
+		compatible = "nxp,tda998x";
+		reg = <0x70>;
 		pinctrl-names = "default", "off";
 		pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
 		pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
-		status = "okay";
+
+		port {
+			hdmi_0: endpoint@0 {
+				remote-endpoint = <&lcdc_0>;
+			};
+		};
 	};
 };
 

1.9.1

We don't have that kind of level of modelling in DRM right now - as far as DRM is concerned, the tda998x is both the encoder _and_ the connector since it supplies both functionalities.

We did discuss this ages ago, but afaik no concensus was reached how to model physical connectors in DT, so it never moved forward in DRM (and besides, everyone seems to be off doing their own thing when it comes to writing DT descriptions for video hardware.)

FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

That's fine, but these are DT bindings which should reflect the hardware, not the SW stack.

I don't know about consensus, but omapdss is using connectors in DT, and they were discussed in lists, and everyone seemed to be ok with that model (Documentation/devicetree/bindings/video/hdmi-connector.txt). If I recall right, the only real question was how the links should be modeled (two way, one way, something else), but that's not specific to connectors.

So while it's open how they should be implemented in the DRM, I don't see why we couldn't/shouldn't specify them in the .dts.

That said, if and when DRM supports connectors defined in .dts, we can just assume that if tda998x does not have an output defined in the .dts, it's connected to a HDMI connector. So we should do just fine even if we end up not defining the connectors at this time.

Yep... I've been trying to push the video ports/endpoints system which afaik covers about all the use cases that have been raised. But the counter argument usually is that "it's too complex".

Tomi

I still don't buy your argument. The principle is right, but I think you're taking it too far.

Look at ePAPR for a moment, and consider a serial port. A serial UART can be physically connected to a 9-pin or a 25-pin connector, which may be male or female. These details are not included in the DT description. Even when the serial port control signals are provided by GPIOs rather than the UART, we don't model the connector - we wrap the GPIOs directly into the UART driver.

Arguably, that's not following the hardware, it's following the software representation - it's following the software representation of what a serial port _should_ look like to a non-specific OS.

Consider an ethernet port. You'll find the same thing applies - the physical connector itself is not specified.

Yet, somehow, we're wanting to specify the physical connector for _all_ video devices? I don't see why that should be mandatory when it's not mandatory for other subsystems.

If we want to take this to the extreme, we should be specifying the power connectors in DT and how they're wired up along with their controls. We don't though, we specify the control devices and the function of those (eg, via a charger chip.)

To take this to the extreme, what about a device powered via PoE? Should the PoE connector be modelled in DT?

When we say "DT should follow the hardware" we're not talking about making DT be an alternative to the hardware's schematic.

FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

<snip>

I agree, and that's not what I'm suggesting. We should only model HW in the DT when it makes sense, when it gives us something.

A HDMI connector can have (at least) two functionalities that the driver for it may need to handle: HPD and +5V. On some SoCs/boards those are handled by the HDMI encoder, but I have boards where they are not. So we need to have the data somewhere, and a HDMI connector node at the end of the video path is a logical choice.

The HDMI connector node is also a good place for a symbolic name which can be shown to the user.

In this particular board, the HDMI encoder handles the HPD and the +5V is always enabled, so there's no strict need to have the HDMI connector node.

However, I still feel it's better to have the HDMI connector in .dts:

1) It's not said that a HDMI encoder always has a HDMI connector as the next component. The next component could be a integrated panel, needing a specific driver and there's no HDMI connector at all. Or there could be something else, as is the case on some OMAP boards which have an ESD protection chip (that requires controlling, i.e. a driver) between the encoder and the connector.

2) I like that the beginning and the end of the video pipeline are clearly defined. A video pipeline starts at a display controller, and ends at a panel or a connector. This makes it easier to understand the .dts as you know what to expect.

In the SW side these mean that every encoder (or whatever is doing this stuff) should be able to handle any component after the encoder, be it a connector, panel or something else.

If we allow leaving out the connector node, the code also needs to handle the case when there's nothing after the encoder, which probably means fabricating some connector data (at least if and when DRM can handle arbitrary video pipelines).

But as I said earlier, we can do just fine without the HDMI connector node on boards where the connector "just works". We can handle that in the drivers with some extra code.

So if people think it's a big chore to add the connectors and don't see the benefit in them (and they don't want the symbolic labels that could be added there), I'm fine with having them optional.

Tomi

Hi Rob,

You weren't cc'd to this series. I don't know if you're still interested in tilcdc, but if you are, any comments appreciated =).

Tomi