[RFC V3 2/3] drm/bridge: add a dummy panel driver to support lvds bridges

[Ajay kumar]

On Sun, May 18, 2014 at 2:44 AM, Thierry Reding
<thierry.reding at gmail.com> 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 at gmail.com> 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