[PATCH 1/6] arm: sa1100: h3100: refactor LCD GPIO handling

Linus Walleij linus.walleij at linaro.org
Tue Nov 26 07:31:49 EST 2013


On Tue, Nov 26, 2013 at 10:07 AM, Dmitry Eremin-Solenikov
<dbaryshkov at gmail.com> wrote:
> On Tue, Nov 26, 2013 at 12:52 PM, Linus Walleij
> <linus.walleij at linaro.org> wrote:
>> On Thu, Nov 21, 2013 at 4:40 PM, Dmitry Eremin-Solenikov
>> <dbaryshkov at gmail.com> wrote:
>>
>>> +static bool h3100_lcd_request(void)
>>> +{
>>> +       static bool h3100_lcd_ok;
>>> +       int rc;
>>> +
>>> +       if (h3100_lcd_ok)
>>> +               return true;
>>> +
>>> +       rc = gpio_request_array(h3100_lcd_gpio, ARRAY_SIZE(h3100_lcd_gpio));
>>> +       if (rc)
>>> +               pr_err("%s: can't request GPIOs\n", __func__);
>>> +       else
>>> +               h3100_lcd_ok = true;
>>> +
>>> +       return h3100_lcd_ok;
>>> +}
>>
>> Hm hm this design pattern is somewhat strange, a run-once
>> construct, but OK then.
>> Acked-by: Linus Walleij <linus.walleij at linaro.org>
>
> Another possibility would be to extend sa11x0-fb driver to also
> provide lcd_init and lcd_shutdown callbacks (to request GPIOs).
> Would it be better to do so?
>
> It is really unfortunate that lcd_class drivers are not directly controlled
> from fbdev drivers. Hopefully CDF can solve that.

Hm it looks like there are no good solutions as long as LCDs
are no separate devices. :-(

Nominally you would use the new gpiod* interface and tie the
GPIOs to a struct device * in this case the LCD, and since that
currently has no struct device, this is OK for now...

Yours,
Linus Walleij



More information about the linux-arm-kernel mailing list