On 26/04/14 02:53, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@xxxxxx> [140424 02:53]:
>> On 18/04/14 18:51, Tony Lindgren wrote:
>>
>>>> + gpio = of_get_gpio(node, 0);
>>>> + if (gpio_is_valid(gpio) || gpio == -ENOENT) {
>>>> + ddata->enable_gpio = gpio;
>>>> + } else {
>>>> + dev_err(&pdev->dev, "failed to parse enable gpio\n");
>>>> + return gpio;
>>>> + }
>>>
>>> We should set the GPIO polarity based on the OF_GPIO_ACTIVE_LOW like
>>> gpio_backlight_probe_dt is doing.
>>
>> Instead of doing it with the old gpio API, and checking the 'active'
>> flag everywhere, I think we can use the new gpiod API which handles the
>> polarity automatically.
>>
>> I attached prototype patches (based on -rc2) for panel dpi using that
>> approach. It's a bit messier than I'd like, because for non-DT boot we
>> need to request the gpio using the old API, and then convert it to
>> gpio_desc. We can remove that code when all the boards use DT.
>>
>> I've compiled tested this only, as I don't have DPI panels I could use.
>> I did try similar approach for TFP410, and it seemed to work fine.
>
> Got these working by updating my test patch to use enable-gpios instead
> of gpios, and had to change from GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH.
> Are we now also breaking legacy booting by reversing the polarity?
I don't think so. The GPIOs should be active-high by default, if I'm not
mistaken, so the polarities should be the same for legacy boot with or
without those patches. Of course, I don't have the boards so I have no
idea if the polarities have been correct even before.
debugfs/gpio shows the actual value of the gpio, so you could check from
there what it is.
> In any case, looks like we have some duplicate panel code.. Turns
> out most panel dpi users for omap3 board-*.c files are just
> sharp-ls037v7dw01 panels but configured in QVGA mode. At least for
> EVM and and LDP based on looking at the pictures and the configuration
Hmm, true, board-ldp.c's panel looks very much like sharp-ls037v7dw01.
Which EVM are you talking about?
> pins (using the names kernel):
>
> QVGA = lcd MO
> reset = lcd RESB
> ...
>
> Then the enable_gpio should be just a GPIO controlled 3.3V regulator
> in most cases. I suggest we move them over to ls037v7dw01 and allow
> configuring them both for VGA and QVGA depending on the orientation.
Looking at the panel spec, it has the following pins:
RESB - reset
MO - VGA/QVGA
UD - vertical scanning direction
LR - horizontal scanning direction
INI - power on control
And it needs 3.3V power.
Are you saying that on some boards the gpio used for enable_gpio is
actually used to switch on a 3.3V regulator?
> I guess you do have some device with ls037v7dw01 since you've been
> patching it?
No, I don't have any boards with that panel.
Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
