On Tue, May 13, 2014 at 11:09:00AM +0200, Andrzej Hajda wrote: > On 05/13/2014 09:51 AM, Thierry Reding wrote: > > On Fri, May 09, 2014 at 04:16:40PM +0200, Boris BREZILLON wrote: > >> Hello Thierry, > >> > >> I noticed you're describing each new panel with a new entry in the > >> of_platform_match table and a new compatible string. > >> I guess you have a good reason to do it this way, because retrieving > >> panel description from DT would be pretty easy (see this series ;-)). > >> > >> Could tell me why you chose this approach ? > > > > The reason is that devicetree mandates that a device be identified using > > a compatible value and that compatible value should be as specific as > > possible. That compatible value should give the device driver enough > > information to know everything it needs (resolution, timings, physical > > dimension). > > > > Having all of that data in the device tree is redundant. > > > > Many panels I have encountered have no single timings, they accepts > ranges of timings. With 'compatible' approach there is no place to > configure timings specific for particular hw configuration, unless you > abuse somehow compatible string. > > However it seems there are not so many cases the same panel must be used > with different timings on different boards, anyway it is a potential issue. Right. I think it makes sense, and I've said so in the past, to add support for overriding the default timings specified by the driver using a display-timings node in DT. But that should be reserved as a means to override the timings if that's required on some specific configuration, not abused as a means to add support for new panels altogether. Note that there's also the possibility to use the drm_crtc_helper_funcs' .mode_fixup() to adjust a mode's timings if the display hardware doesn't support the mode as-is. Thierry
Attachment:
pgpHpInx_d1X9.pgp
Description: PGP signature
