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