Re: [PATCH 2/5] drivers: gpio: Add support for multiple IPs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux