Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Sebastian Reichel <sre@kernel.org>]

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

Hi,

On Wed, May 21, 2014 at 04:05:56PM +0300, Tomi Valkeinen wrote:
> I'll try and see how the other options work, which are:
> 
> - Bailing out from module_init in each display driver. The reason I
> don't like this (although I haven't tried it) is that all the display
> drivers need the modification, and because I need to catch the
> module_init, I cannot use the helpers like module_platform_driver(), so
> it adds multiple lines to every driver.

You could create your own omapdss_driver() define for that.
This can be replaced more simply once no longer needed and
creates less bloat.

I see one more disadvantage for this approach:

assumed situation (some future 3.16+x kernel):
 * The kernel has an common display framework (CDF)
 * The kernel has an panel driver using CDF
 * There also exists omapdss driver for the same panel
 * omapdss does not (yet) adopt CDF
 * CDF and omapdss are enabled in .config
 * Kernel is booted from an OMAP system

This would result in both drivers being loaded using the same
DT compatible string. The same scenario works using the rewriting
method, since the common display framework would only see the
rewritten compatible string.

Of course this scenario only happens when omapdss is not adopted
to the common display framework from the start on.

> - Traveling the video graph, starting from omapdss. This one is possibly
> better performance-wise than my original version, as we only need to
> search for the omapdss node and can then follow the links. But the code
> will be more complex.

I think the main advantage is the missing lookup table/whitelist,
which adds redundancy. Not having it has some advantages:

* new drivers don't need to touch any existing files (making
  rebasing etc. easier)
* table can get out of sync (though that shouldn't happen anyway,
  since the binding is supposed to be stable)

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]