Re: [PATCHv2 23/27] OMAPDSS: connector-dvi: Add DT support

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

[-- Attachment #1: Type: text/plain, Size: 2606 bytes --]

Hi Tomi,

On Tuesday 17 December 2013 09:15:58 Tomi Valkeinen wrote:
> On 2013-12-17 09:05, Sascha Hauer wrote:
> > On Mon, Dec 16, 2013 at 04:56:30PM +0200, Tomi Valkeinen wrote:
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> >> ---
> >> 
> >>  drivers/video/omap2/displays-new/connector-dvi.c | 43 ++++++++++++++++++
> >>  1 file changed, 43 insertions(+)
> >> 
> >> diff --git a/drivers/video/omap2/displays-new/connector-dvi.c
> >> b/drivers/video/omap2/displays-new/connector-dvi.c index
> >> b6c50904038e..d1204b1c5182 100644
> >> 
> >> +static const struct of_device_id dvic_of_match[] = {
> >> +	{ .compatible = "dvi-connector", },
> > 
> > Either the driver is too specific or the binding is too generic, but
> > having such a generic name for an omap specific driver seems wrong. Same
> > for panel-dpi, svideo-connector, composite-video-connector and
> > hdmi-connector,
>
> Hmm. Good point. I was thinking that the driver is only used on OMAP, but of
> course that's not true, the driver is there for all platforms if the kernel
> just happens to be compiled with the driver.
> 
> And it's not just about those drivers you mention. The same issue is there
> for, say, "ti,tpd12s015". I have an omapdss specific driver for that, but if
> some other platform uses the same chip, they'll have a driver for it also...
> 
> Sigh. I wonder how this should be handled... The only solution that comes to
> my mind is to have all the compatible strings as "ti,...". But that's not
> correct, as they are not TI components, but some are generic ones and some
> from another vendor.
> 
> And even "ti,..." is not good, as there are other TI SoCs with other display
> drivers. So I'd need to prepend the compatible strings with "omapdss,...",
> making the hardware components driver specific.
> 
> The long term plan is to make the drivers generic (or implement the same
> driver for common display framework). But for now I need to have future
> proof DT bindings with omapdss specific drivers...

I'll refrain from mentioning that the problem has been identified more than a 
year ago. Oh, wait, I've metioned it, sorry :-D

We really want to make drivers generic enough to be shared by multiple display 
controllers. I would vote for making the DT bindings generic now already, 
which would be enough to buy some time to fix the problem properly. If we 
start prepending driver-specific prefixes such as "omapdss," to compatible 
string we'll just make the mess even larger and reduce the incentive to fix 
it. It would be the worst decision we could make.

-- 
Regards,

Laurent Pinchart

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]