[PATCHv4] video: backlight: gpio-backlight: Add DT support.

Thierry Reding thierry.reding at gmail.com
Wed Oct 23 16:20:12 EDT 2013


On Wed, Oct 23, 2013 at 05:51:13PM +0100, Stephen Warren wrote:
> On 10/22/2013 09:01 PM, Thierry Reding wrote:
> > On Tue, Oct 22, 2013 at 05:34:45PM +0200, Jean-Christophe
> > PLAGNIOL-VILLARD wrote:
> ...
> >> I'm sorry but the blacklight descibe in DT have nothing to do
> >> with the common pratice that the current driver have today
> > 
> > That's not at all what I said. What I said was that the majority
> > of backlight drivers currently default to turning the backlight on
> > when probed. Therefore I think it would be consistent if this
> > driver did the same.
> > 
> > I also said that I don't think it's a very good default, but at the
> > same time we can't just go and change the default behaviour at will
> > because people may rely on it.
> 
> It may well be reasonable to change the default behaviour for devices
> instantiated from DT. If it's not possible to instantiate the device
> from DT yet, then it's not possible for anyone to be relying on the
> default behaviour yet, since there is none. So, perhaps the default
> could be:
> 
> * If device instantiated from a board file, default to on, for
> backwards-compatibility.
> 
> * If device instantiated from DT, there is no backwards compatibility
> to be concerned with, since this is a new feature, hence default to
> off, since we think that's the correct thing to do.

I actually had a patch to do precisely that. However I then realized
that people have actually been using pwm-backlight in DT for a while
already and therefore may be relying on that behaviour as well.

It also isn't really an issue of DT vs. non-DT. The simple fact is that
besides the backlight driver there's usually no other code that enables
a backlight on boot. The only way to do so that I know of is using the
DRM panel patches that I've been working on.

That said, it is true that the number of DT users of the pwm-backlight
driver is smaller than the number of board file users, and it is much
more likely that people are still actively using them, so if we can get
everyone to agree on changing the default behaviour that might still be
possible.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131023/e82b24c0/attachment-0001.sig>


More information about the linux-arm-kernel mailing list