From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression Date: Mon, 24 Jun 2013 16:53:50 +0100 Message-ID: References: <20130516180933.GG5600@atomide.com> <20130516210006.GA31836@blackmetal.musicnaut.iki.fi> <20130516214430.GN5600@atomide.com> <20130520174621.GI10378@atomide.com> <20130605223355.EDC113E10E4@localhost> <20130606155341.GL3331@atomide.com> <20130623221605.GA3150@blackmetal.musicnaut.iki.fi> <20130623234326.GA20703@blackmetal.musicnaut.iki.fi> <20130624072112.GQ5523@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from mail-ie0-f179.google.com ([209.85.223.179]:62639 "EHLO mail-ie0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750884Ab3FXPyL (ORCPT ); Mon, 24 Jun 2013 11:54:11 -0400 Received: by mail-ie0-f179.google.com with SMTP id c10so25437954ieb.10 for ; Mon, 24 Jun 2013 08:54:10 -0700 (PDT) In-Reply-To: <20130624072112.GQ5523@atomide.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Tony Lindgren Cc: Javier Martinez Canillas , Aaro Koskinen , "linux-arm-kernel@lists.infradead.org" , "linux-omap@vger.kernel.org" , Jon Hunter On Mon, Jun 24, 2013 at 8:21 AM, Tony Lindgren wrote: > * Javier Martinez Canillas [130623 18:08]: >> On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen 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 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. Alright. Sorry I dropped the ball on this one. I've lost track of which patch needs to get applied, but given that it is so late in the cycle, it would be better for someone else to apply the change, test and send a pull request to Linus. I'm okay with it going through the OMAP tree if that is the most expedient. Alternately, send me the pull request and I'll pass it on to Linus. g. From mboxrd@z Thu Jan 1 00:00:00 1970 From: grant.likely@secretlab.ca (Grant Likely) Date: Mon, 24 Jun 2013 16:53:50 +0100 Subject: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression In-Reply-To: <20130624072112.GQ5523@atomide.com> References: <20130516180933.GG5600@atomide.com> <20130516210006.GA31836@blackmetal.musicnaut.iki.fi> <20130516214430.GN5600@atomide.com> <20130520174621.GI10378@atomide.com> <20130605223355.EDC113E10E4@localhost> <20130606155341.GL3331@atomide.com> <20130623221605.GA3150@blackmetal.musicnaut.iki.fi> <20130623234326.GA20703@blackmetal.musicnaut.iki.fi> <20130624072112.GQ5523@atomide.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Jun 24, 2013 at 8:21 AM, Tony Lindgren wrote: > * Javier Martinez Canillas [130623 18:08]: >> On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen 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 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. Alright. Sorry I dropped the ball on this one. I've lost track of which patch needs to get applied, but given that it is so late in the cycle, it would be better for someone else to apply the change, test and send a pull request to Linus. I'm okay with it going through the OMAP tree if that is the most expedient. Alternately, send me the pull request and I'll pass it on to Linus. g.