| Message ID | 1383905510-31760-4-git-send-email-prabhakar.csengg@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Nov 8, 2013 at 11:11 AM, Prabhakar Lad <prabhakar.csengg@gmail.com> wrote: > From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com> > > This patch converts the davinci gpio driver to use irqdomain > support. > > Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> (...) > @@ -282,8 +283,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc) > desc->irq_data.chip->irq_ack(&desc->irq_data); > while (1) { > u32 status; > - int n; > - int res; > + int bit; Why is this an int? I think u8 would suffice. > /* now demux them to the right lowlevel handler */ > - n = d->irq_base; > - if (irq & 1) { > - n += 16; > - status >>= 16; > - } > - > while (status) { > - res = ffs(status); > - n += res; > - generic_handle_irq(n - 1); > - status >>= res; > + bit = __ffs(status); > + status &= ~(1 << bit); > + generic_handle_irq(irq_find_mapping(d->irq_domain, > + bit)); This is a nice hunk of the patch. I would use <linux/bitops.h> and do: status &= ~BIT(bit); > @@ -313,10 +307,7 @@ static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset) > { > struct davinci_gpio_controller *d = chip2controller(chip); > > - if (d->irq_base >= 0) > - return d->irq_base + offset; > - else > - return -ENODEV; > + return irq_create_mapping(d->irq_domain, offset); > } I think we recently established that map creating cannot be done in gpio_to_irq* functions as that will not work properly if you request an IRQ from device tree without first obtaining the IRQ from the GPIO number with this function. Instead call irq_create_mapping() on *all* used IRQ lines in the probe function and use irq_find_mapping() here too. > + for (gpio = 0, bank = 0; gpio < ngpio; bank++, bank_irq++, gpio += 16) { > /* disabled by default, enabled only as needed */ > g = gpio2regs(gpio); > writel(~0, &g->clr_falling); > @@ -467,14 +483,6 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev) > */ > irq_set_handler_data(bank_irq, &chips[gpio / 32]); So for example here you could call iurq_create_mapping(); Also: please write a patch that marks the IRQ lines. Call gpio_lock_as_irq(*gpio_chip, offset); in the irqchip startup/shutdown functions. (Can be a separate patch.) Yours, Linus Walleij
On Mon, Nov 18, 2013 at 02:11:32PM +0100, Linus Walleij wrote: > On Fri, Nov 8, 2013 at 11:11 AM, Prabhakar Lad > <prabhakar.csengg@gmail.com> wrote: > > > From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com> > > > > This patch converts the davinci gpio driver to use irqdomain > > support. > > > > Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> > > (...) > > @@ -282,8 +283,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc) > > desc->irq_data.chip->irq_ack(&desc->irq_data); > > while (1) { > > u32 status; > > - int n; > > - int res; > > + int bit; > > Why is this an int? I think u8 would suffice. For local variables, it's better to use "int" or even "unsigned" here rather than u8. u8 tells the compiler that you want the variable to be 8-bit, which seems fine, except the compiler is then at liberty to keep on masking the register back down to 8-bit.
Hi Linus, On 11/18/2013 03:11 PM, Linus Walleij wrote: > On Fri, Nov 8, 2013 at 11:11 AM, Prabhakar Lad > <prabhakar.csengg@gmail.com> wrote: > >> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com> >> >> This patch converts the davinci gpio driver to use irqdomain >> support. >> >> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> > > (...) >> @@ -282,8 +283,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc) >> desc->irq_data.chip->irq_ack(&desc->irq_data); >> while (1) { >> u32 status; >> - int n; >> - int res; >> + int bit; > > Why is this an int? I think u8 would suffice. > >> /* now demux them to the right lowlevel handler */ >> - n = d->irq_base; >> - if (irq & 1) { >> - n += 16; >> - status >>= 16; >> - } >> - >> while (status) { >> - res = ffs(status); >> - n += res; >> - generic_handle_irq(n - 1); >> - status >>= res; >> + bit = __ffs(status); >> + status &= ~(1 << bit); >> + generic_handle_irq(irq_find_mapping(d->irq_domain, >> + bit)); > > This is a nice hunk of the patch. > > I would use <linux/bitops.h> and do: > status &= ~BIT(bit); > > >> @@ -313,10 +307,7 @@ static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset) >> { >> struct davinci_gpio_controller *d = chip2controller(chip); >> >> - if (d->irq_base >= 0) >> - return d->irq_base + offset; >> - else >> - return -ENODEV; >> + return irq_create_mapping(d->irq_domain, offset); >> } > > I think we recently established that map creating cannot be done > in gpio_to_irq* functions as that will not work properly if you request > an IRQ from device tree without first obtaining the IRQ from the GPIO > number with this function. Why? Could you point on corresponding thread, pls? Current call tree is: irq_create_of_mapping() |-hwirq = omain->ops->xlate() |-irq_create_mapping(domain, hwirq) > > Instead call irq_create_mapping() on *all* used IRQ lines in the > probe function and use irq_find_mapping() here too. > >> + for (gpio = 0, bank = 0; gpio < ngpio; bank++, bank_irq++, gpio += 16) { >> /* disabled by default, enabled only as needed */ >> g = gpio2regs(gpio); >> writel(~0, &g->clr_falling); >> @@ -467,14 +483,6 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev) >> */ >> irq_set_handler_data(bank_irq, &chips[gpio / 32]); > > So for example here you could call iurq_create_mapping(); > > Also: please write a patch that marks the IRQ lines. > Call gpio_lock_as_irq(*gpio_chip, offset); in the > irqchip startup/shutdown functions. (Can be a separate > patch.) It seems, some misunderstanding is here. So I'd like to clarify few points and would be very appreciate for your comments: 1) This patch itself will work unless we switch to DT (as in the following patch) 2) After this patch the following object structure will be created during Davinci GPIO driver initialization (DA850 has 144 IRQ lines): - gpio_chip0(0..31) |- irq_domain1 - gpio_chip1(32..63) |- irq_domain2 - gpio_chip2(64..95) |- irq_domain3 - gpio_chip3(96..127) |- irq_domain4 - gpio_chip4(128..143) |- irq_domain5 3) But in case of DT only one GPIO controller node will be created Example: gpio: gpio@1e26000 { compatible = "ti,dm6441-gpio"; gpio-controller; reg = <0x226000 0x1000>; interrupt-parent = <&intc>; interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH 44 IRQ_TYPE_EDGE_BOTH 45 IRQ_TYPE_EDGE_BOTH 46 IRQ_TYPE_EDGE_BOTH 47 IRQ_TYPE_EDGE_BOTH 48 IRQ_TYPE_EDGE_BOTH 49 IRQ_TYPE_EDGE_BOTH 50 IRQ_TYPE_EDGE_BOTH>; interrupt-controller; #interrupt-cells = <2>; ti,ngpio = <144>; ti,davinci-gpio-unbanked = <0>; } 4) As result, to make GPIO bindings/mappings work - we'll need to implement .of_xlate() callback per GPIO chip, which will provide us with valid valid gpio_chip and offset of gpio inside chip (It was discussed before and supposed to be done as next step). For example, gpio_chip3 and offset=15 should be selected: devA { gpios = <&gpio 111 GPIO_ACTIVE_HIGH>; } 5) What should be done to make GPIO IRQ bindings/mappings work? Example: devB { interrupt-parent = <&gpio>; interrupts = <111 IRQ_TYPE_EDGE_BOTH>; } Should we implement one IRQ domain per all GPIO chips (per GPIO controller)? Thanks. Regards, -Grygorii
On Mon, Nov 18, 2013 at 3:34 PM, Grygorii Strashko <grygorii.strashko@ti.com> wrote: > On 11/18/2013 03:11 PM, Linus Walleij wrote: >> I think we recently established that map creating cannot be done >> in gpio_to_irq* functions as that will not work properly if you request >> an IRQ from device tree without first obtaining the IRQ from the GPIO >> number with this function. > > Why? Could you point on corresponding thread, pls? All that contain this: "gpio: interrupt consistency check for OF GPIO IRQs" http://marc.info/?l=linux-kernel&w=2&r=1&s=interrupt+consistency&q=b > Current call tree is: > irq_create_of_mapping() > |-hwirq = omain->ops->xlate() > |-irq_create_mapping(domain, hwirq) OK that works for the pure device-tree scenario so mostly this is OK. The problem that appear is if someone is using platform data-provided IRQs off the irq_chip without calling gpio_to_irq() on the GPIO line first. This has been determined to be legal to do, so preferably create the map when registering the lines. >> Also: please write a patch that marks the IRQ lines. >> Call gpio_lock_as_irq(*gpio_chip, offset); in the >> irqchip startup/shutdown functions. (Can be a separate >> patch.) > > It seems, some misunderstanding is here. So I'd like to clarify few points > and would be very appreciate for your comments: > 1) This patch itself will work unless we switch to DT (as in the following > patch) Sure.... but this does not seem to have much to do with my request to use gpio_lock_as_irq(). > 2) After this patch the following object structure will be created during > Davinci GPIO driver initialization (DA850 has 144 IRQ lines): > - gpio_chip0(0..31) > |- irq_domain1 > - gpio_chip1(32..63) > |- irq_domain2 > - gpio_chip2(64..95) > |- irq_domain3 > - gpio_chip3(96..127) > |- irq_domain4 > - gpio_chip4(128..143) > |- irq_domain5 OK that's nice. > 3) But in case of DT only one GPIO controller node will be created > Example: > gpio: gpio@1e26000 { > compatible = "ti,dm6441-gpio"; > gpio-controller; > reg = <0x226000 0x1000>; > interrupt-parent = <&intc>; > interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH > 44 IRQ_TYPE_EDGE_BOTH 45 IRQ_TYPE_EDGE_BOTH > 46 IRQ_TYPE_EDGE_BOTH 47 IRQ_TYPE_EDGE_BOTH > 48 IRQ_TYPE_EDGE_BOTH 49 IRQ_TYPE_EDGE_BOTH > 50 IRQ_TYPE_EDGE_BOTH>; > interrupt-controller; > #interrupt-cells = <2>; > ti,ngpio = <144>; > ti,davinci-gpio-unbanked = <0>; > } Yep... > 4) As result, to make GPIO bindings/mappings work - we'll need to implement > .of_xlate() callback per GPIO chip, which will provide us with valid valid > gpio_chip and offset of gpio inside chip > (It was discussed before and supposed to be done as next step). Yeah.. this is usually a bit tricky. > For example, gpio_chip3 and offset=15 should be selected: > devA { > gpios = <&gpio 111 GPIO_ACTIVE_HIGH>; > } > > 5) What should be done to make GPIO IRQ bindings/mappings work? > > Example: > devB { > interrupt-parent = <&gpio>; > interrupts = <111 IRQ_TYPE_EDGE_BOTH>; > } > > Should we implement one IRQ domain per all GPIO chips (per GPIO controller)? I don't know, I cannot really see where the problem is. The IRQ domain is for translationg hardware numbers such as bit offsets into Linux IRQ numbers and nothing else, so I'd suggest that as long as the thing you are translating/mapping is something simple like a bit index you're doing the right thing. If it becomes something complex where that index is not just a bit but an index into an array of registers at various locations it is abusing the irqdomain. So I think you should create one irqdomain per GPIO instance or bank or whatever you want to call it: like if there is this one register with 32 bits, then it gets its own IRQdomain. I think you should try to keep the 5 irqdomains, but whatever gives the simplest code is usually the right answer, and divide-and-conquer (split down the problem) is usually a good idea. How the GPIO block(s) are represented in the device tree is another totally separate issue about hardware description, do not let the device tree model your driver structure. Yours, Linus Walleij
On 11/19/2013 01:06 AM, Linus Walleij wrote: > On Mon, Nov 18, 2013 at 3:34 PM, Grygorii Strashko > <grygorii.strashko@ti.com> wrote: >> On 11/18/2013 03:11 PM, Linus Walleij wrote: > >>> I think we recently established that map creating cannot be done >>> in gpio_to_irq* functions as that will not work properly if you request >>> an IRQ from device tree without first obtaining the IRQ from the GPIO >>> number with this function. >> >> Why? Could you point on corresponding thread, pls? > > All that contain this: > "gpio: interrupt consistency check for OF GPIO IRQs" > http://marc.info/?l=linux-kernel&w=2&r=1&s=interrupt+consistency&q=b Thanks. > >> Current call tree is: >> irq_create_of_mapping() >> |-hwirq = omain->ops->xlate() >> |-irq_create_mapping(domain, hwirq) > > OK that works for the pure device-tree scenario so mostly > this is OK. > > The problem that appear is if someone is using platform data-provided > IRQs off the irq_chip without calling gpio_to_irq() on the GPIO line > first. This has been determined to be legal to do, so preferably > create the map when registering the lines. Ok, I understand. It may fail in case if someone will define/calculate IRQ number for device manually in board code, like: dev_irq = (DA850_N_CP_INTC_IRQ + gpioN) Also, looks like It is possible to fail if Main/arch IRQ controller code doesn't make call of irq_alloc_descs() during init, so allocated_irqs will be empty. Actually, the irq_find_mapping() was called before from gpio_to_irq_banked() in v4 of this series - than It was changed according to my comment, to get maximum benefits of using linear IRQ domain. Before recommending that, I've checked Davinci platform code and didn't find any risk places - BUT, Seems my findings need to be confirmed by Sekhar. I purpose to move forward as is if above will be confirmed. Otherwise, we can switch to use irq_domain_add_legacy(). > >>> Also: please write a patch that marks the IRQ lines. >>> Call gpio_lock_as_irq(*gpio_chip, offset); in the >>> irqchip startup/shutdown functions. (Can be a separate >>> patch.) >> >> It seems, some misunderstanding is here. So I'd like to clarify few points >> and would be very appreciate for your comments: >> 1) This patch itself will work unless we switch to DT (as in the following >> patch) > > Sure.... but this does not seem to have much to do > with my request to use gpio_lock_as_irq(). Oh no. Your request about gpio_lock_as_irq() is absolutely valid :) And it has to be added > >> 2) After this patch the following object structure will be created during >> Davinci GPIO driver initialization (DA850 has 144 IRQ lines): >> - gpio_chip0(0..31) >> |- irq_domain1 >> - gpio_chip1(32..63) >> |- irq_domain2 >> - gpio_chip2(64..95) >> |- irq_domain3 >> - gpio_chip3(96..127) >> |- irq_domain4 >> - gpio_chip4(128..143) >> |- irq_domain5 > > OK that's nice. > >> 3) But in case of DT only one GPIO controller node will be created >> Example: >> gpio: gpio@1e26000 { >> compatible = "ti,dm6441-gpio"; >> gpio-controller; >> reg = <0x226000 0x1000>; >> interrupt-parent = <&intc>; >> interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH >> 44 IRQ_TYPE_EDGE_BOTH 45 IRQ_TYPE_EDGE_BOTH >> 46 IRQ_TYPE_EDGE_BOTH 47 IRQ_TYPE_EDGE_BOTH >> 48 IRQ_TYPE_EDGE_BOTH 49 IRQ_TYPE_EDGE_BOTH >> 50 IRQ_TYPE_EDGE_BOTH>; >> interrupt-controller; >> #interrupt-cells = <2>; >> ti,ngpio = <144>; >> ti,davinci-gpio-unbanked = <0>; >> } > > Yep... > >> 4) As result, to make GPIO bindings/mappings work - we'll need to implement >> .of_xlate() callback per GPIO chip, which will provide us with valid valid >> gpio_chip and offset of gpio inside chip >> (It was discussed before and supposed to be done as next step). > > Yeah.. this is usually a bit tricky. > >> For example, gpio_chip3 and offset=15 should be selected: >> devA { >> gpios = <&gpio 111 GPIO_ACTIVE_HIGH>; >> } >> >> 5) What should be done to make GPIO IRQ bindings/mappings work? >> >> Example: >> devB { >> interrupt-parent = <&gpio>; >> interrupts = <111 IRQ_TYPE_EDGE_BOTH>; >> } >> >> Should we implement one IRQ domain per all GPIO chips (per GPIO controller)? > > I don't know, I cannot really see where the problem is. > > The IRQ domain is for translationg hardware numbers such as bit offsets > into Linux IRQ numbers and nothing else, so I'd suggest that as long as > the thing you are translating/mapping is something simple like a bit > index you're doing the right thing. > > If it becomes something complex where that index is not just a bit > but an index into an array of registers at various locations it is > abusing the irqdomain. > > So I think you should create one irqdomain per GPIO instance > or bank or whatever you want to call it: like if there is this one > register with 32 bits, then it gets its own IRQdomain. > > I think you should try to keep the 5 irqdomains, but whatever > gives the simplest code is usually the right answer, and > divide-and-conquer (split down the problem) is usually a good > idea. > > How the GPIO block(s) are represented in the device tree is > another totally separate issue about hardware description, > do not let the device tree model your driver structure. Thanks for you comments, but looks like I have to be more specific :) How irq_find_host() will look for proper IRQ domain in our case? And will it work at all, taking into account that all (5) IRQ domains will have the same value of "of_node" property? of_irq_to_resource() |-irq_of_parse_and_map() |-irq_create_of_mapping() |-irq_find_host(irq_data->np) where np will point on GPIO node. As result my question is about what do DT core frameworks allow or not allow to do? And according to that implementation of driver can be changed. Regards, -grygorii
On Tue, Nov 19, 2013 at 5:22 PM, Grygorii Strashko <grygorii.strashko@ti.com> wrote: > On 11/19/2013 01:06 AM, Linus Walleij wrote: >> The problem that appear is if someone is using platform data-provided >> IRQs off the irq_chip without calling gpio_to_irq() on the GPIO line >> first. This has been determined to be legal to do, so preferably >> create the map when registering the lines. > > Ok, I understand. It may fail in case if someone will define/calculate > IRQ number for device manually in board code, like: > dev_irq = (DA850_N_CP_INTC_IRQ + gpioN) Usually people just hardcode the IRQ value or use some #define, like they have often also done with GPIO numbers ... > Also, looks like It is possible to fail if Main/arch IRQ controller > code doesn't make call of irq_alloc_descs() during init, so > allocated_irqs will be empty. If you use irq_domain_add_simple() the irqdomain core will actually attempt to do this. But if you use a linear domain, you have to create these irqdescs as you go. The simplest way to do this is to call irq_create_mapping() on all IRQs, because that call will also allocate some descriptor. > Before recommending that, I've checked Davinci platform code and didn't > find any risk places - BUT, Seems my findings need to be confirmed by > Sekhar. It's no big deal, but I just want you to be aware that this may cause a problem at some point. >> I think you should try to keep the 5 irqdomains, but whatever >> gives the simplest code is usually the right answer, and >> divide-and-conquer (split down the problem) is usually a good >> idea. >> >> How the GPIO block(s) are represented in the device tree is >> another totally separate issue about hardware description, >> do not let the device tree model your driver structure. > > > Thanks for you comments, but looks like I have to be more specific :) > > How irq_find_host() will look for proper IRQ domain in our case? > And will it work at all, taking into account that all (5) IRQ domains > will have the same value of "of_node" property? > of_irq_to_resource() > |-irq_of_parse_and_map() > |-irq_create_of_mapping() > |-irq_find_host(irq_data->np) > where np will point on GPIO node. > > As result my question is about what do DT core frameworks allow or not > allow to do? And according to that implementation of driver can be > changed. Hm, I'm not like a super-expert on the interrupt core, but maybe you need to create subnodes inside the top node to represent this, then use of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev); to populate them from the main node. Yours, Linus Walleij
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c index ca3d7fd..b149239 100644 --- a/drivers/gpio/gpio-davinci.c +++ b/drivers/gpio/gpio-davinci.c @@ -16,6 +16,7 @@ #include <linux/err.h> #include <linux/io.h> #include <linux/irq.h> +#include <linux/irqdomain.h> #include <linux/platform_device.h> #include <linux/platform_data/gpio-davinci.h> @@ -282,8 +283,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc) desc->irq_data.chip->irq_ack(&desc->irq_data); while (1) { u32 status; - int n; - int res; + int bit; /* ack any irqs */ status = readl(&g->intstat) & mask; @@ -292,17 +292,11 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc) writel(status, &g->intstat); /* now demux them to the right lowlevel handler */ - n = d->irq_base; - if (irq & 1) { - n += 16; - status >>= 16; - } - while (status) { - res = ffs(status); - n += res; - generic_handle_irq(n - 1); - status >>= res; + bit = __ffs(status); + status &= ~(1 << bit); + generic_handle_irq(irq_find_mapping(d->irq_domain, + bit)); } } desc->irq_data.chip->irq_unmask(&desc->irq_data); @@ -313,10 +307,7 @@ static int gpio_to_irq_banked(struct gpio_chip *chip, unsigned offset) { struct davinci_gpio_controller *d = chip2controller(chip); - if (d->irq_base >= 0) - return d->irq_base + offset; - else - return -ENODEV; + return irq_create_mapping(d->irq_domain, offset); } static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset) @@ -354,6 +345,28 @@ static int gpio_irq_type_unbanked(struct irq_data *data, unsigned trigger) return 0; } +static int davinci_gpio_irq_map(struct irq_domain *d, unsigned int irq, + irq_hw_number_t hw) +{ + struct davinci_gpio_controller *chip = d->host_data; + unsigned gpio = chip->chip.base + hw; + struct davinci_gpio_regs __iomem *g = gpio2regs(gpio); + + irq_set_chip_and_handler_name(irq, &gpio_irqchip, handle_simple_irq, + "davinci_gpio"); + irq_set_irq_type(irq, IRQ_TYPE_NONE); + irq_set_chip_data(irq, (__force void *)g); + irq_set_handler_data(irq, (void *)__gpio_mask(gpio)); + set_irq_flags(irq, IRQF_VALID); + + return 0; +} + +static const struct irq_domain_ops davinci_gpio_irq_ops = { + .map = davinci_gpio_irq_map, + .xlate = irq_domain_xlate_onetwocell, +}; + /* * NOTE: for suspend/resume, probably best to make a platform_device with * suspend_late/resume_resume calls hooking into results of the set_wake() @@ -402,9 +415,16 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev) */ for (gpio = 0, bank = 0; gpio < ngpio; bank++, gpio += 32) { chips[bank].chip.to_irq = gpio_to_irq_banked; - chips[bank].irq_base = pdata->gpio_unbanked - ? -EINVAL - : (pdata->intc_irq_num + gpio); + if (!pdata->gpio_unbanked) { + chips[bank].irq_domain = + irq_domain_add_linear(NULL, + chips[bank].chip.ngpio, + &davinci_gpio_irq_ops, + &chips[bank]); + + if (!chips[bank].irq_domain) + return -ENOMEM; + } } /* @@ -447,11 +467,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev) * Or, AINTC can handle IRQs for banks of 16 GPIO IRQs, which we * then chain through our own handler. */ - for (gpio = 0, irq = gpio_to_irq(0), bank = 0; - gpio < ngpio; - bank++, bank_irq++) { - unsigned i; - + for (gpio = 0, bank = 0; gpio < ngpio; bank++, bank_irq++, gpio += 16) { /* disabled by default, enabled only as needed */ g = gpio2regs(gpio); writel(~0, &g->clr_falling); @@ -467,14 +483,6 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev) */ irq_set_handler_data(bank_irq, &chips[gpio / 32]); - for (i = 0; i < 16 && gpio < ngpio; i++, irq++, gpio++) { - irq_set_chip(irq, &gpio_irqchip); - irq_set_chip_data(irq, (__force void *)g); - irq_set_handler_data(irq, (void *)__gpio_mask(gpio)); - irq_set_handler(irq, handle_simple_irq); - set_irq_flags(irq, IRQF_VALID); - } - binten |= BIT(bank); } @@ -485,8 +493,6 @@ done: */ writel(binten, gpio_base + BINTEN); - printk(KERN_INFO "DaVinci: %d gpio irqs\n", irq - gpio_to_irq(0)); - return 0; } diff --git a/include/linux/platform_data/gpio-davinci.h b/include/linux/platform_data/gpio-davinci.h index 6efd202..0c3551b 100644 --- a/include/linux/platform_data/gpio-davinci.h +++ b/include/linux/platform_data/gpio-davinci.h @@ -34,7 +34,7 @@ struct davinci_gpio_platform_data { struct davinci_gpio_controller { struct gpio_chip chip; - int irq_base; + struct irq_domain *irq_domain; /* Serialize access to GPIO registers */ spinlock_t lock; void __iomem *regs;