linux-kernel - Re: [RFC PATCH 0/2] drm/panel: add simple-panel description using DT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140513092002.GN6754@ulmo>
Date:	Tue, 13 May 2014 11:20:04 +0200
From:	Thierry Reding <thierry.reding@...il.com>
To:	Andrzej Hajda <a.hajda@...sung.com>
Cc:	Boris BREZILLON <boris.brezillon@...e-electrons.com>,
	devicetree@...r.kernel.org,
	Jean-Jacques Hiblot <jjhiblot@...phandler.com>,
	linux-doc@...r.kernel.org, Randy Dunlap <rdunlap@...radead.org>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [RFC PATCH 0/2] drm/panel: add simple-panel description using DT

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

Content of type "application/pgp-signature" skipped