Keerthy,
On 27/10/16 06:42, Keerthy wrote:
>
>
> On Sunday 23 October 2016 04:02 PM, Linus Walleij wrote:
>> On Wed, Oct 19, 2016 at 7:33 AM, Keerthy <j-keerthy@xxxxxx> wrote:
>>
>>> From: Lokesh Vutla <lokeshvutla@xxxxxx>
>>>
>>> Update GPIO driver to support Multiple GPIO IPs.
>>>
>>> Signed-off-by: Lokesh Vutla <lokeshvutla@xxxxxx>
>>> Signed-off-by: Keerthy <j-keerthy@xxxxxx>
>>
>> This commit message is not at all describing what the patch is doing.
>>
>> What it does is bumping the GPIO pin offset in the Linux global
>> GPIO number space with 32 for each new controller.
>>
>>> + static int bank_base;
>>>
>>> pdata = davinci_gpio_get_pdata(pdev);
>>> if (!pdata) {
>>> @@ -226,7 +227,8 @@ static int davinci_gpio_probe(struct platform_device *pdev)
>>> chips[i].chip.direction_output = davinci_direction_out;
>>> chips[i].chip.set = davinci_gpio_set;
>>>
>>> - chips[i].chip.base = base;
>>> + chips[i].chip.base = bank_base;
>>> + bank_base += 32;
>>
>> Why can you not rewrite the driver to pass -1 as base and
>> get a dynamic allocation of GPIO numbers instead? Then
>> you won't have this hairy problem.
>
> Ok i will try that.
>
> In case of k2g. There are 2 big GPIO modules GPIO0 and GPIO1.
> GPIO0 comprises of 144 GPIOs
> and GPIO1 has about 68 GPIOs. Wanted feedback from you on how this is being modeled.
>
> I am creating a controller for every 32 GPIOs under the big module each containing a gpio_chip. Each 32 GPIOs chip has 2 banks of 16 GPIOs each.
> Each 16 GPIO bank has an interrupt.
>
> Is this modeling fine or do you think creating one chip with 144 pins and another with 68 pins is a better way?
If GPIO0 has 144 GPIOs, why don't we model it as a gpiochip with 144 GPIOs?
What is the benefit of partitioning it into gpiochips of 32 GPIOs each?
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
