On Thursday, July 31, 2014 8:55 PM, Thierry Reding wrote: > On Thu, Jul 31, 2014 at 01:42:50PM +0200, Thierry Reding wrote: > [...] > > @@ -317,6 +319,12 @@ static int pwm_backlight_probe(struct platform_device *pdev) > > } > > > > bl->props.brightness = data->dft_brightness; > > + > > + if (data->boot_off) > > + bl->props.power = FB_BLANK_POWERDOWN; > > + else > > + bl->props.power = FB_BLANK_UNBLANK; > > + > > backlight_update_status(bl); > > Looking at this again, perhaps a more sensible thing to do would be to > not call backlight_update_status() in the first place. For example if > the board defines that backlight should be kept off at boot, but the > bootloader had already enabled it, then this would effectively turn off > the backlight again. (+cc Ajay Kumar) Personally, I prefer not to call backlight_update_status(), when the backlight was already turned on by bootloader. Also, it would be better for subsystems such as DRM to handle the power of panel. > > I think it's safe to assume that if the bootloader sets up the backlight > then it would also set up the display. Therefore not touching the > backlight state at all at probe time seems like the safest default. > > Of course that doesn't help people who use some dumb framebuffer driver > and therefore nothing explicitly enables the backlight. So it would > still be changing behaviour for people for whom the bootloader doesn't > set up the backlight at all and who therefore rely on the kernel to turn > it on. > > We could perhaps alleviate that pain a little by making this dependent > on whether or not the board is booted using DT on the assumption that > anything that uses DT would be "modern" enough to provide a means to > automatically enable the backlight at the right moment. I also agree with the way to use DT. Best regards, Jingoo Han > > Thierry -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
