Re: [PATCH] OMAP3: GPIO fixes for off-mode

[David Brownell <david-b@pacbell.net>]

On Monday 01 December 2008, Tero Kristo wrote:
> Off mode is now using the omap2 retention fix code for scanning GPIOs
> only during off-mode transitions. All the *non_wakeup_gpios variables
> are now used for off-mode transition tracking on OMAP3. This patch fixes
> cases where GPIO state changes are missed during off-mode.

I second the "no #ifdefs" comment ...

Could you uplevel your description here a bit?  I'm trying to
understand if what this does is complete and correct.

My understanding is that we currently have several mechanisms
interacting to affect things that relate to the OMAP3-only
"off" modes for pins used as GPIOs:

 - irq_chip.set_wake() calls, for GPIOs used as IRQs.
   We should assume that if the IRQ is wake-enabled, that
   applies to OFF mode too.  (AFAICT, this mechanism is
   not handled by this patch.)

 - Hmm, and because a goal is to transparently enter OFF
   modes to save power, rather than only after drivers
   get suspend() calls that tend to trigger set_wake(),
   an un-commented conclusion seems to be that all GPIOs
   used as IRQs implicitly act like set_wake() was called.
   (Something which *is* partially addressed here.)

 - omap_cfg_reg() configuration for any pin can include
   its OFF-mode parameters.  Virtually unused ... and
   not addressed by this patch, so I'm puzzled how pins
   are expected to be kept active with just this patch.

 - OMAP2-specific bug workarounds, some GPIOs can't be
   used for wakeup, ergo bank->non_wakeup_gpios.  This
   is resolved for OMAP3, yes?

When I looked at this issue a while back, I came to believe
that we'd need to map GPIOs to their config registers so
we could diddle the OFF-mode bits.  And I don't see such
a mapping (table) here...

- Dave