From: Tony Lindgren <tony@atomide.com> To: Javier Martinez Canillas <martinez.javier@gmail.com> Cc: Aaro Koskinen <aaro.koskinen@iki.fi>, Grant Likely <grant.likely@secretlab.ca>, linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org, Jon Hunter <jgchunter@gmail.com> Subject: Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression Date: Mon, 24 Jun 2013 00:21:12 -0700 [thread overview] Message-ID: <20130624072112.GQ5523@atomide.com> (raw) In-Reply-To: <CAAwP0s00RwP7jCMF1O8j8Ndhu=VfD2dMA5fzr6jWvQ7PziXBCw@mail.gmail.com> * Javier Martinez Canillas <martinez.javier@gmail.com> [130623 18:08]: > On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > > Hi, > > > > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: > >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO > >> > IRQs are still broken on OMAP1. > > > > [...] > > > >> There is a problem with this patch. > > > > [...] > > > >> So I think that the correct solution is to add SPARSE_IRQ support to > >> omap1 and not reverting Jon's patch. Of course this may not be > >> possible since we are so close to 3.10 and most OMAP patches already > >> merged for 3.11 but we should definitely try to have this at least for > >> 3.12. Otherwise we won't be able to move to DT-only booting for > >> OMAP2+. > > > > OMAP1 does not use DT. So we could put this code under #ifdef > > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ > > work should not regress OMAP1. > > > > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before > > these changes were made. It's not reasonable to assume such things can > > be made during rc-cycle. Also, now, I don't think it's reasonable to > > wait for that to be done, as it would take until 3.12 or even later to > > get OMAP1 functional again. > > > > A. > > Hi, > > Yes, since we are so late in the -rc cycle and OMAP1 is currently > broken I agree that the only sensible solution is to revert the patch > for now. Agreed. > I just wanted to point out the issue that keeping the OMAP GPIO driver > using legacy mapping domain represents a blocker to have GPIO-IRQ > working with Device Tree for OMAP2+ Yes. We can do the ifdef Aaro suggested, and let's also plan on converting omap1 to use SPARSE_IRQ. But with the ifdef we can cut away the dependency between these two. Regards, Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren) To: linux-arm-kernel@lists.infradead.org Subject: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression Date: Mon, 24 Jun 2013 00:21:12 -0700 [thread overview] Message-ID: <20130624072112.GQ5523@atomide.com> (raw) In-Reply-To: <CAAwP0s00RwP7jCMF1O8j8Ndhu=VfD2dMA5fzr6jWvQ7PziXBCw@mail.gmail.com> * Javier Martinez Canillas <martinez.javier@gmail.com> [130623 18:08]: > On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > > Hi, > > > > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: > >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO > >> > IRQs are still broken on OMAP1. > > > > [...] > > > >> There is a problem with this patch. > > > > [...] > > > >> So I think that the correct solution is to add SPARSE_IRQ support to > >> omap1 and not reverting Jon's patch. Of course this may not be > >> possible since we are so close to 3.10 and most OMAP patches already > >> merged for 3.11 but we should definitely try to have this at least for > >> 3.12. Otherwise we won't be able to move to DT-only booting for > >> OMAP2+. > > > > OMAP1 does not use DT. So we could put this code under #ifdef > > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ > > work should not regress OMAP1. > > > > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before > > these changes were made. It's not reasonable to assume such things can > > be made during rc-cycle. Also, now, I don't think it's reasonable to > > wait for that to be done, as it would take until 3.12 or even later to > > get OMAP1 functional again. > > > > A. > > Hi, > > Yes, since we are so late in the -rc cycle and OMAP1 is currently > broken I agree that the only sensible solution is to revert the patch > for now. Agreed. > I just wanted to point out the issue that keeping the OMAP GPIO driver > using legacy mapping domain represents a blocker to have GPIO-IRQ > working with Device Tree for OMAP2+ Yes. We can do the ifdef Aaro suggested, and let's also plan on converting omap1 to use SPARSE_IRQ. But with the ifdef we can cut away the dependency between these two. Regards, Tony
next prev parent reply other threads:[~2013-06-24 7:21 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-05-13 20:53 [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression Aaro Koskinen 2013-05-13 20:53 ` Aaro Koskinen 2013-05-16 18:09 ` Tony Lindgren 2013-05-16 18:09 ` Tony Lindgren 2013-05-16 21:00 ` Aaro Koskinen 2013-05-16 21:00 ` Aaro Koskinen 2013-05-16 21:44 ` Tony Lindgren 2013-05-16 21:44 ` Tony Lindgren 2013-05-20 17:46 ` Tony Lindgren 2013-05-20 17:46 ` Tony Lindgren 2013-05-21 17:39 ` Aaro Koskinen 2013-05-21 17:39 ` Aaro Koskinen 2013-05-21 19:37 ` Jon Hunter 2013-05-21 19:37 ` Jon Hunter 2013-05-22 21:20 ` Aaro Koskinen 2013-05-22 21:20 ` Aaro Koskinen 2013-05-23 19:02 ` Jon Hunter 2013-05-23 19:02 ` Jon Hunter 2013-05-23 20:13 ` Aaro Koskinen 2013-05-23 20:13 ` Aaro Koskinen 2013-05-28 18:41 ` Jon Hunter 2013-05-28 18:41 ` Jon Hunter 2013-05-26 19:07 ` Aaro Koskinen 2013-05-26 19:07 ` Aaro Koskinen 2013-05-28 18:42 ` Jon Hunter 2013-05-28 18:42 ` Jon Hunter 2013-05-29 18:55 ` Aaro Koskinen 2013-05-29 18:55 ` Aaro Koskinen 2013-05-29 21:29 ` Jon Hunter 2013-05-29 21:29 ` Jon Hunter 2013-05-29 22:41 ` Jon Hunter 2013-05-29 22:41 ` Jon Hunter 2013-06-05 22:33 ` Grant Likely 2013-06-05 22:33 ` Grant Likely 2013-06-06 15:53 ` Tony Lindgren 2013-06-06 15:53 ` Tony Lindgren 2013-06-23 22:16 ` Aaro Koskinen 2013-06-23 22:16 ` Aaro Koskinen 2013-06-23 23:06 ` Javier Martinez Canillas 2013-06-23 23:06 ` Javier Martinez Canillas 2013-06-23 23:43 ` Aaro Koskinen 2013-06-23 23:43 ` Aaro Koskinen 2013-06-24 1:01 ` Javier Martinez Canillas 2013-06-24 1:01 ` Javier Martinez Canillas 2013-06-24 7:21 ` Tony Lindgren [this message] 2013-06-24 7:21 ` Tony Lindgren 2013-06-24 15:35 ` Javier Martinez Canillas 2013-06-24 15:35 ` Javier Martinez Canillas 2013-06-25 18:14 ` Aaro Koskinen 2013-06-25 18:14 ` Aaro Koskinen 2013-06-24 15:53 ` Grant Likely 2013-06-24 15:53 ` Grant Likely 2013-06-25 7:04 ` Tony Lindgren 2013-06-25 7:04 ` Tony Lindgren 2013-06-25 11:49 ` Grant Likely 2013-06-25 11:49 ` Grant Likely 2013-06-26 7:06 ` Tony Lindgren 2013-06-26 7:06 ` Tony Lindgren
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=20130624072112.GQ5523@atomide.com \ --to=tony@atomide.com \ --cc=aaro.koskinen@iki.fi \ --cc=grant.likely@secretlab.ca \ --cc=jgchunter@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=martinez.javier@gmail.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.