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?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
