From: Javier Martinez Canillas <javier@dowhile0.org> To: Linus Walleij <linus.walleij@linaro.org> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>, Javier Martinez Canillas <javier.martinez@collabora.co.uk>, Kevin Hilman <khilman@linaro.org>, Tony Lindgren <tony@atomide.com>, Paul Walmsley <paul@pwsan.com>, Aaro Koskinen <aaro.koskinen@iki.fi>, Nishanth Menon <nm@ti.com>, "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>, Linux-OMAP <linux-omap@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 4/5] gpio: omap: convert driver to use gpiolib irqchip Date: Thu, 10 Apr 2014 20:58:31 +0200 [thread overview] Message-ID: <CABxcv=ktiH346PBueYKtitKWVXznjdYOJe=qvOfxfT37MTL_Kw@mail.gmail.com> (raw) In-Reply-To: <CACRpkdazRZvNwZcdkn1EQpv7PEGv83pL+yaFRHA8z0SSXw2gkg@mail.gmail.com> Hello Linus and Santosh, On Thu, Apr 10, 2014 at 7:45 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Thu, Apr 10, 2014 at 7:39 PM, Santosh Shilimkar > <santosh.shilimkar@ti.com> wrote: >> On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote: > >>> +#ifdef CONFIG_ARCH_OMAP1 >>> + /* >>> + * REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop >>> + * irq_alloc_descs() since a base IRQ offset will no longer be needed. >>> + */ >>> + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); >>> + if (irq_base < 0) { >>> + dev_err(bank->dev, "Couldn't allocate IRQ numbers\n"); >>> + return -ENODEV; >>> + } >>> +#endif >>> + >> Do we still need above after first patch ? Would be good >> to get rid of above ugly #ifdef on the middle of the code. When working on this series I tried to remove the #ifdef but as far as I understood is not currently possible until OMAP1 supports sparse irq numbering. Not so long ago the GPIO OMAP driver used the legacy domain mapping for all OMAP SoCs and Jon Hunter converted to use linear domain mapping on commit ede4d7a ("gpio/omap: convert gpio irq domain to linear mapping"). Unfortunately that change caused a regression on OMAP1 platforms as reported by Aaro [0] so I had to partially revert the linear domain mapping for OMAP1 platforms on commit 397ead ("gpio/omap: don't use linear domain mapping for OMAP1") introducing this ugly ifdefery in the middle of the code. > > I don't think so actually, simple irqdomain adds descriptors > for irqbase != 0, and the gpiochip irqchip helpers call > irq_create_mapping() on all offsets. > Looking at irq_domain_add_simple() [1] I see that it only calls irq_alloc_descs() and irq_domain_associate_many() if first_irq > 0 and CONFIG_SPARSE_IRQ is enabled (which is not the case for omap1_defconfig). So, if I got this correctly removing the #ifdef for OMAP1 and calling irq_domain_add_simple() is functionally equivalent to what Jon's patch did that broke omap1. That is would have the same effect that just calling irq_domain_add_linear() [2] for OMAP1. > Preferably a separate patch on top of this removing that code > though so it's bisectable. > If I remember correctly we did that partial revert because we were in a -rc cycle and I didn't have time to investigate why irq_domain_add_linear() does not work on omap1. I could try to do this as a follow up patch but unfortunately I don't have access to any omap1 platform to do further debug. Please let me know if I got something wrong while looking at the code. > Yours, > Linus Walleij > -- Thanks a lot and best regards, Javier [0]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89005.html [1]: http://lxr.free-electrons.com/source/kernel/irq/irqdomain.c#L123 [2]: http://lxr.free-electrons.com/source/include/linux/irqdomain.h#L139
WARNING: multiple messages have this Message-ID (diff)
From: javier@dowhile0.org (Javier Martinez Canillas) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 4/5] gpio: omap: convert driver to use gpiolib irqchip Date: Thu, 10 Apr 2014 20:58:31 +0200 [thread overview] Message-ID: <CABxcv=ktiH346PBueYKtitKWVXznjdYOJe=qvOfxfT37MTL_Kw@mail.gmail.com> (raw) In-Reply-To: <CACRpkdazRZvNwZcdkn1EQpv7PEGv83pL+yaFRHA8z0SSXw2gkg@mail.gmail.com> Hello Linus and Santosh, On Thu, Apr 10, 2014 at 7:45 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Thu, Apr 10, 2014 at 7:39 PM, Santosh Shilimkar > <santosh.shilimkar@ti.com> wrote: >> On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote: > >>> +#ifdef CONFIG_ARCH_OMAP1 >>> + /* >>> + * REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop >>> + * irq_alloc_descs() since a base IRQ offset will no longer be needed. >>> + */ >>> + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); >>> + if (irq_base < 0) { >>> + dev_err(bank->dev, "Couldn't allocate IRQ numbers\n"); >>> + return -ENODEV; >>> + } >>> +#endif >>> + >> Do we still need above after first patch ? Would be good >> to get rid of above ugly #ifdef on the middle of the code. When working on this series I tried to remove the #ifdef but as far as I understood is not currently possible until OMAP1 supports sparse irq numbering. Not so long ago the GPIO OMAP driver used the legacy domain mapping for all OMAP SoCs and Jon Hunter converted to use linear domain mapping on commit ede4d7a ("gpio/omap: convert gpio irq domain to linear mapping"). Unfortunately that change caused a regression on OMAP1 platforms as reported by Aaro [0] so I had to partially revert the linear domain mapping for OMAP1 platforms on commit 397ead ("gpio/omap: don't use linear domain mapping for OMAP1") introducing this ugly ifdefery in the middle of the code. > > I don't think so actually, simple irqdomain adds descriptors > for irqbase != 0, and the gpiochip irqchip helpers call > irq_create_mapping() on all offsets. > Looking at irq_domain_add_simple() [1] I see that it only calls irq_alloc_descs() and irq_domain_associate_many() if first_irq > 0 and CONFIG_SPARSE_IRQ is enabled (which is not the case for omap1_defconfig). So, if I got this correctly removing the #ifdef for OMAP1 and calling irq_domain_add_simple() is functionally equivalent to what Jon's patch did that broke omap1. That is would have the same effect that just calling irq_domain_add_linear() [2] for OMAP1. > Preferably a separate patch on top of this removing that code > though so it's bisectable. > If I remember correctly we did that partial revert because we were in a -rc cycle and I didn't have time to investigate why irq_domain_add_linear() does not work on omap1. I could try to do this as a follow up patch but unfortunately I don't have access to any omap1 platform to do further debug. Please let me know if I got something wrong while looking at the code. > Yours, > Linus Walleij > -- Thanks a lot and best regards, Javier [0]: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg89005.html [1]: http://lxr.free-electrons.com/source/kernel/irq/irqdomain.c#L123 [2]: http://lxr.free-electrons.com/source/include/linux/irqdomain.h#L139
next prev parent reply other threads:[~2014-04-10 18:58 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-04-06 14:58 [PATCH 0/5] GPIO OMAP driver changes for v3.16 Javier Martinez Canillas 2014-04-06 14:58 ` Javier Martinez Canillas 2014-04-06 14:58 ` [PATCH 1/5] gpio: omap: convert to use irq_domain_add_simple() Javier Martinez Canillas 2014-04-06 14:58 ` Javier Martinez Canillas 2014-04-10 17:35 ` Santosh Shilimkar 2014-04-10 17:35 ` Santosh Shilimkar 2014-04-06 14:58 ` [PATCH 2/5] gpio: omap: check gpiochip_add() return value Javier Martinez Canillas 2014-04-06 14:58 ` Javier Martinez Canillas 2014-04-10 17:36 ` Santosh Shilimkar 2014-04-10 17:36 ` Santosh Shilimkar 2014-04-06 14:58 ` [PATCH 3/5] gpio: omap: add a GPIO_OMAP option instead of using ARCH_OMAP Javier Martinez Canillas 2014-04-06 14:58 ` Javier Martinez Canillas 2014-04-10 17:37 ` Santosh Shilimkar 2014-04-10 17:37 ` Santosh Shilimkar 2014-04-06 14:58 ` [PATCH 4/5] gpio: omap: convert driver to use gpiolib irqchip Javier Martinez Canillas 2014-04-06 14:58 ` Javier Martinez Canillas 2014-04-10 17:39 ` Santosh Shilimkar 2014-04-10 17:39 ` Santosh Shilimkar 2014-04-10 17:45 ` Linus Walleij 2014-04-10 17:45 ` Linus Walleij 2014-04-10 18:58 ` Javier Martinez Canillas [this message] 2014-04-10 18:58 ` Javier Martinez Canillas 2014-04-06 14:58 ` [PATCH 5/5] MAINTAINERS: update GPIO OMAP driver entry Javier Martinez Canillas 2014-04-06 14:58 ` Javier Martinez Canillas 2014-04-10 17:29 ` [PATCH 0/5] GPIO OMAP driver changes for v3.16 Linus Walleij 2014-04-10 17:29 ` Linus Walleij 2014-04-10 19:30 ` Aaro Koskinen 2014-04-10 19:30 ` Aaro Koskinen 2014-04-10 20:17 ` Javier Martinez Canillas 2014-04-10 20:17 ` Javier Martinez Canillas 2014-04-10 21:22 ` Aaro Koskinen 2014-04-10 21:22 ` Aaro Koskinen 2014-04-11 15:03 ` Javier Martinez Canillas 2014-04-11 15:03 ` Javier Martinez Canillas 2014-04-22 13:00 ` Linus Walleij 2014-04-22 13:00 ` Linus Walleij 2014-04-23 21:48 ` Javier Martinez Canillas 2014-04-23 21:48 ` Javier Martinez Canillas
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CABxcv=ktiH346PBueYKtitKWVXznjdYOJe=qvOfxfT37MTL_Kw@mail.gmail.com' \ --to=javier@dowhile0.org \ --cc=aaro.koskinen@iki.fi \ --cc=javier.martinez@collabora.co.uk \ --cc=khilman@linaro.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=nm@ti.com \ --cc=paul@pwsan.com \ --cc=santosh.shilimkar@ti.com \ --cc=tony@atomide.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.