On Tue, Oct 07, 2014 at 02:47:53PM +0530, Ajay kumar wrote: > On Tue, Oct 7, 2014 at 2:37 PM, Markus Pargmann <mpa@xxxxxxxxxxxxxx> wrote: > > Hi, > > > > On Tue, Oct 07, 2014 at 10:35:49AM +0200, Thierry Reding wrote: > >> On Mon, Oct 06, 2014 at 09:22:44PM +0200, Markus Pargmann wrote: > >> > The backlight will be enabled by the panel again if it is used. So we > >> > can save the default brightness and disable the pwm backlight when > >> > probing. > >> > > >> > Signed-off-by: Markus Pargmann <mpa@xxxxxxxxxxxxxx> > >> > --- > >> > drivers/video/backlight/pwm_bl.c | 4 +++- > >> > 1 file changed, 3 insertions(+), 1 deletion(-) > >> > > >> > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c > >> > index 336b83be7e2d..b4f433a6f106 100644 > >> > --- a/drivers/video/backlight/pwm_bl.c > >> > +++ b/drivers/video/backlight/pwm_bl.c > >> > @@ -317,9 +317,11 @@ static int pwm_backlight_probe(struct platform_device *pdev) > >> > data->dft_brightness = data->max_brightness; > >> > } > >> > > >> > - bl->props.brightness = data->dft_brightness; > >> > + bl->props.brightness = 0; > >> > backlight_update_status(bl); > >> > > >> > + bl->props.brightness = data->dft_brightness; > >> > + > >> > platform_set_drvdata(pdev, bl); > >> > return 0; > >> > > >> > >> It would be nice if it was that easy. But we can't do this, because it > >> will regress for users of this driver that don't use a panel or DRM. If > >> the PWM backlight driver is used for example in conjunction with a plain > >> fbdev driver it isn't necessarily hooked up with anything and won't be > >> enabled automatically. That's really bad if fbdev is the only output you > >> have since you'd have to blindly type the commands to enable the > >> backlight. Furthermore disabling backlight isn't always what you want to > >> do. For example if the bootloader already turned it on and you hand over > >> from bootloader to kernel in a seamless way, then you absolutely want to > >> keep backlight on all the time. > >> > >> See also[0] for a different proposal to solve the same problem. Back at > >> the time that received only a very few replies, but it would be nice if > >> Lee and Bryan could look at it again and see if we can come up with some > >> way to deal with this situation. > > > > Yes your proposal looks a lot better to handle the different use cases. > > The DT-binding is not a hardware description but I don't see any better > > way of passing that information. So it would be good to get your > > solution mainline. > +1 > And, I have already tested Thierry's proposal on Exynos5800 peach_pi. I also tested Thierry's patch on i.MX6s now and it works fine. Regards, Markus -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: Digital signature
