[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