> -----Original Message-----
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Wednesday, September 22, 2010 5:48 AM
> To: Varadarajan, Charulatha
> Cc: t...@atomide.com; linux-omap@vger.kernel.org; p...@pwsan.com; Cousson,
> Benoit; Nayak, Rajendra; Basak, Partha
> Subject: Re: [PATCH v6 00/13] OMAP: GPIO: Implement GPIO in hwmod way
> 
> Kevin Hilman <khil...@deeprootsystems.com> writes:
> 
> > Kevin Hilman <khil...@deeprootsystems.com> writes:
> >
> >> "Varadarajan, Charulatha" <ch...@ti.com> writes:
> >>
> >>>>
> >>>> "Varadarajan, Charulatha" <ch...@ti.com> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to