On Sun, May 18, 2014 at 2:44 AM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > On Thu, May 15, 2014 at 05:10:16PM +0530, Ajay kumar wrote: >> On Thu, May 15, 2014 at 1:43 PM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > [...] >> > I still don't see how controlling the enable GPIO from the panel will be >> > in any way better, or different for that matter, from simply enabling >> > the backlight and let the backlight driver handle the enable GPIO. Have >> > you tried to do that and found that it doesn't work? >> It works, but it gives me glitch when I try to configure video. >> This is because backlight_on(pwm-backlight) happens much before >> I configure video(inside drm), and while configuring video there would >> be a glitch, >> and that glitch would be visible to the user since backlight is already enabled. > > Okay, so this means that your backlight is turned on too early. Instead > of working around that problem by moving control of the backlight enable > GPIO from the backlight driver into the panel driver, the correct way to > fix it is to make sure the backlight stays off until video is ready. Ok. Please suggest an idea how to do the same! I have already suggested a simple idea which conforms to a valid spec. Just because enable_gpio is already a part of pwm_bl.c, I somewhat feel like we are forcing people to handle enable_gpio inside pwm_bl.c. Note that, pwm_bl can still work properly without enabling the backlight GPIO. And, I did point out to a valid datasheet from AUO, which clearly indicates why backlight enable GPIO should be a part of panel driver and not pwm_bl driver. I am not trying to say we should remove enable_gpio from pwm_bl. Provided that its already an optional property, and if someone wants to control it in a panel driver, what is wrong in doing so? Regards, Ajay -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |