On Fri, Oct 09, 2015 at 09:16:28AM -0700, Tony Lindgren wrote:
> * Ben Tucker <benjamint@xxxxxxxxxxx> [151009 03:20]:
> > On Thu, Oct 08, 2015 at 11:40:06PM -0700, Tony Lindgren wrote:
> > > * Ben Tucker <benjamint@xxxxxxxxxxx> [151008 06:09]:
> > > > The OFFOUTENABLE bit of the omap PADCONF registers is active low.
> > > > The mux code assumed that it was active high and this patch fixes this
> > > > problem.
> > > >
> > > > Tested on an AM37x device.
> > >
> > > Hmm what are the test cases you're using to validate this so
> > > I can try to reproduce?
> >
> > I have a GSM modem connected to the omap via uart. The modem will only
> > enter a low power sleep mode when is RXD is pulled low, so by using the
> > OFFOUTENABLE signal I am able to automatically activate low power in the
> > modem when suspending to off.
> > I have a test setup which allows me to measure the combined power used by the
> > omap+modem and I can see a saving of around 45mA in suspend with this
> > patch. This is consistent with the literature on the modem device.
>
> OK that pin may be then glitchy because of 1.158 :)
>
> > Our custom hardware is based on omap3beagle and not available to you. My
> > thoughts as to reproducing this would be to use a beagle and setup so
> > that it is able to suspend right down to CORE Off. Then set up the pin
> > muxing for the UART TX signal to output low in off mode. It should be
> > possible to measure the level on the TX signal in suspend.
>
> Hmm well UART will be powered off, but I can use any GPIO pin for
> that.
>
> > I appreciate that this is a lot of work. I would be happy to do this
> > but it will take some time. Would you be able to help get things up and
> > running?
> >
> > >
> > > AFAIK because of erratum 1.158 for GPIO pins needing to be
> > > muxed temporarly for input + pull + safe mode for off mode,
> > > so I'm wondering in which cases the OFFOUTENABLE can be used.
> >
> > In my scenario the pin is muxed to the uart function (TxD), but I am
> > interested in this issue as well. First off, I want to read the erratum
> > 1.158 you speak of.
> > I see that the errata document for OMAP35xx has:
> > Advisory 3.1.1.158 Pull-up not maintained on pin corresponding to
> > GPIO_28/29 during padconf restore
> > Is this what you are referring to?
>
> Hmm I believe it has some different TI external number. Maybe search
> for 1.158 and Tero Kristo and you come up with an older patch
> implementing the workaround. I have not seen the errata description
> either.
Yes, I found that patch or a variant of it before. I think it most
closely matches the TI advisories:
- sprz278f.pdf (omap35xx)
Advisory 3.1.1.160 GPIO Pad Glitch/Spike Upon Wake-Up From System OFF Mode
- sprz318f.pdf (am37x)
Advisory 1.45 GPIO Pad Spurious Transition (Glitch/Spike) During Wake Up
Entering or Exiting System OFF Mode
>From my understanding both of these advisories include the work around
to switch to off mode input and pull up or down to mimic the gpio output level
(which is fine so long as the pin is lightly loaded). Looks like this is
what the patch does.
>
> > > I have a patch in works for 1.158 using gpio-ranges, and the
> > > test case I'm using is the reset of WLAN that happens in off
> > > mode as the enable GPIO glitches when returning from off mode.
> >
> > I will now go away and have a look through all the places that we use
> > GPIO and asses the impact of glitches on the signals in our design.
> > Thankyou.
>
> Yup, I've verified it happens on a scope earlier. If you have
> external pulls you may not experience this issue.
>
> > > Also.. I'm wondring why this has not been caught earlier?
> > > Maybe because 1.158 is needed on omap3?
> >
> > Maybe. Also the use of OFFOUTENABLE in combination with peripherals
> > other than GPIO, I guess, is pretty rare.
>
> Right, I guess it has not been used :)
>
> Hmm so what's the use case for PIN_OFF_INPUT* then?
On the face of it if the peripheral behind the pin is powered off which
will be the case when we have powered the domains off, then it cannot
process any input values.
However there are two uses for input off mode I can think of:
1- the pin is not connected, in which case you want to make it an input
so that there is no driver enabled for it. I am guessing this would save
a little power even though the pin has no load. Note an internal pull
resister should be enabled in this case to avoid the pin acting like a
aerial and switching internal logic, which again would be a source of
power draw.
(Having just read the TRM, I see that the safe-mode can be used for most
N/C pins)
2- we want to enable a wakeup of the system on the pin
Something else you may want to look out for is the fact that the omap4
mux config is has the same active low OFFOUTENABLE as omap3. I do not
know if the same problem exists in the omap4 mux control code. I do not
think it is shared with the omap3 mux control code.
(Just my 2p worth)
Thanks,
Ben
--
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
