[PATCH v8 05/12] gpio: pl061: bind pinctrl by gpio request

Haojian Zhuang haojian.zhuang at linaro.org
Thu Feb 14 12:06:15 EST 2013


On 14 February 2013 23:29, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Mon, Feb 11, 2013 at 6:10 PM, Haojian Zhuang
> <haojian.zhuang at linaro.org> wrote:
>
>> Add the pl061_gpio_request() to request pinctrl. Create the logic
>> between pl061 gpio driver and pinctrl (pinctrl-single) driver.
>>
>> While a gpio pin is requested, it will request pinctrl driver to
>> set that pin with gpio function mode. So pinctrl driver should
>> append .gpio_request_enable() in pinmux_ops.
>>
>> Signed-off-by: Haojian Zhuang <haojian.zhuang at linaro.org>
> (...)
>> +static int pl061_gpio_request(struct gpio_chip *chip, unsigned offset)
>> +{
>> +       /*
>> +        * Map back to global GPIO space and request muxing, the direction
>> +        * parameter does not matter for this controller.
>> +        */
>> +       int gpio = chip->base + offset;
>> +
>> +       return pinctrl_request_gpio(gpio);
>> +}
>
> So this will work find if the platform supports pinctrl, and either the
> pin controller can do something with this, or (after the other patch)
> if the GPIO is in some range, but not handled by some
> pin controller.
>
> But what about the case where there is a pin controller on the
> system, but no range matching this pin?
>
> What will happen then? Eternal deferral?
>
> Yours,
> Linus Walleij

If there's a back-end pin controller ready, but no range matching this pin,
it will return 0, not error. This is the purpose that I want to add
pinctrl_overlapped_gpio_range().

Yes, the name is so confusing. Let's figure out a clear name.

Regards
Haojian



More information about the linux-arm-kernel mailing list