> -----Original Message----- > From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] > Sent: Wednesday, September 22, 2010 5:48 AM > To: Varadarajan, Charulatha > Cc: tony@xxxxxxxxxxx; linux-omap@xxxxxxxxxxxxxxx; paul@xxxxxxxxx; Cousson, > Benoit; Nayak, Rajendra; Basak, Partha > Subject: Re: [PATCH v6 00/13] OMAP: GPIO: Implement GPIO in hwmod way > > Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> writes: > > > Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> writes: > > > >> "Varadarajan, Charulatha" <charu@xxxxxx> writes: > >> > >>>> > >>>> "Varadarajan, Charulatha" <charu@xxxxxx> writes: > >>>> > >>>> > This patch series makes OMAP2PLUS specific GPIO implemented in > hwmod > >>>> > FW way. This is done by implementing GPIO module in platform device > >>>> model. > >>>> > > >>>> > This patch series is generated on "origin/pm-wip/pm-core" which > >>>> > has Kevin's pm-next series, the runtime PM core patch series, > >>>> > and a collection of hwmod fixes that Paul/Benoit have lined up > >>>> > for 2.6.37. > >>>> > > >>>> > Tested on OMAP2430, OMAP44430, OMAP3430 SDP and zoom3 boards. > >>>> > Also verified that this patch series does not break the OMAP1 build. > >>>> > > >>>> > This patch series is created on top of the following patches: > >>>> > 1. OMAP: HWMOD: Handle opt clocks using clk_add_alias > >>>> > [https://patchwork.kernel.org/patch/124531/] > >>>> > 2. OMAP2+: GPIO: move late PM out of interrupts-disabled idle path > >>>> > [https://patchwork.kernel.org/patch/176172/] > >>>> > 3. OMAP: CPUIDLE: Enable IRQs during device activity check and idle > >>>> management > >>>> > by Kevin > >>>> > > >>>> > This series is tested on OMAP4430 ES2 using the below series > >>>> > http://www.spinics.net/lists/linux-omap/msg36023.html > >>>> > >>>> Hi Charu, > >>>> > >>>> I haven't been fully through the series, but here's some quick > feedback > >>>> based on what I tried today. > >>>> > >>>> Basically, I got stuck because the first board I tried it on was the > >>>> 35xx-based OMAP3EVM platform, which uses a GPIO-based interrupt for > the > >>>> network. My setup uses DHCP + nfsroot, so the GPIO IRQ must be > working > >>>> during boot. > >>>> > >>>> The first thing I noticed, is that GPIO interrupts are not firing > during > >>>> boot, so neither the DHCP or the nfsroot works during boot. I > haven't > >>>> been able to fully debug this, but the 3430SDP should have the same > >>>> issue for its smc91x if you set it up for DHCP + nfsroot. This is > >>>> working fine on my pm-wip/idle-reorg branch which has the > prerequisites > >>>> you mentioned, but didn't work when I applied the clk_alias patch > plus > >>>> this series. > >>> > >>> I tested this GPIO series in pm-wip/idle-reorg branch with clock > >>> add alias patch and I did not see any issues. I tested with DHCP + > nfsroot > >>> on SDP3430. Please provide me some more info on this. > >> > >> Hmm, I don't have many more details yet. All I can see is that the > GPIO > >> bank that has the smc91x interrupt (GPIO6) is loosing interrupts, and > >> thus preventing DHCP and nfsroot from working. > >> > >> Can you test using omap3_defconfig plus > >> > >> # CONFIG_CPU_FREQ is not set > >> CONFIG_CPU_IDLE=y > > > > Some more details. I tried on two different 35xx platforms and it works > > on one (es3.1) and not on the other (es2.1): > > > > [ 0.000000] Machine: Gumstix Overo > > [ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) > > > > but not on omap3evm: > > > > [ 0.000000] Machine: OMAP3 EVM > > [ 0.000000] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp ) > > > > > > Is there any chance you could get your hands on an es2.1 EVM and try > > there? > > > > Please contact Sanjeev Premi in TII and I think he should be able to > > find one for you to use temporarily. I could reproduce this issue on 35xxEVM board (ES3.1). I am debugging the issue. Will get back to you soon in this regard. Machine: OMAP3 EVM Memory policy: ECC disabled, Data cache writeback <6>OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp) > > I also just tested on n900 which has lots of GPIOs configured. On this > platform, suspend doesn't hit RET because both GPIO3 and GPIO4 are still > enabled. > > Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html