On 10/05/17 01:35, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Tuesday 09 May 2017 10:16:27 Tomi Valkeinen wrote: >> We have been using DRM_MODE_CONNECTOR_Unknown for many of our outputs >> because there has not been a proper connector type for them. >> >> We now have connector type for DPI so let's take it into use. At the >> same time, add better connector types for the remaining outputs too. >> >> This patch sets the following outputs to use the following connector >> types: >> >> DPI -> DPI >> DBI -> DPI (MIPI DBI is very similar to DPI at the bus level) >> SDI -> LVDS (SDI, TI Flatlink 3G, is a type of LVDS) >> VENC -> SVIDEO (it could also be composite, but we don't have that >> information here, so svideo should be quite good match) >> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@xxxxxx> >> --- >> drivers/gpu/drm/omapdrm/omap_drv.c | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c >> b/drivers/gpu/drm/omapdrm/omap_drv.c index e1f47f0b3ccf..16c537837742 >> 100644 >> --- a/drivers/gpu/drm/omapdrm/omap_drv.c >> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c >> @@ -214,6 +214,19 @@ static int get_connector_type(struct omap_dss_device >> *dssdev) return DRM_MODE_CONNECTOR_DVID; >> case OMAP_DISPLAY_TYPE_DSI: >> return DRM_MODE_CONNECTOR_DSI; >> + case OMAP_DISPLAY_TYPE_DPI: >> + case OMAP_DISPLAY_TYPE_DBI: >> + return DRM_MODE_CONNECTOR_DPI; >> + case OMAP_DISPLAY_TYPE_VENC: >> + if (of_device_is_compatible(dssdev->dev->of_node, >> + "omapdss,svideo-connector")) >> + return DRM_MODE_CONNECTOR_SVIDEO; >> + if (of_device_is_compatible(dssdev->dev->of_node, >> + "omapdss,composite-video-connector")) >> + return DRM_MODE_CONNECTOR_Composite; > > Checking the compat string here feels like a bit of a hack to me. Wouldn't it > be simpler and cleaner to add the connector type to the omap_dss_device > structure ? That's more work though, so as a first step I think I could > tolerate this hack if you really feel lazy ;-) Although, maybe we should just > return SVIDEO unconditionally for VENC for now and fix that later. Yes, it looks a bit ugly to me too. I've been reluctant to add more things to omap_dss_device and to the panel/encoder drivers, as I think each thing there will make it more difficult to convert driver the model to more DRM'ish model. So, I think I'll just use the SVIDEO as I had originally. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel