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-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html