Re: How to keep DM37x GPIO_162 high during off-mode

[Grygorii Strashko <grygorii.strashko@ti.com>]

Hi Peter,

On 07/11/2013 10:00 PM, Peter Barada wrote:
> On 07/09/2013 11:55 AM, Tony Lindgren wrote:
>> * Peter Barada <peter.barada@logicpd.com> [130709 08:14]:
>>> I'm working with a 3.0.8 kernel in Android ICS and have run into a
>>> problem using wl12xx bluetooth after a suspend/resume cycle.
>>>
>>> GPIO_162 in this design is connected to the BT_EN pin of the wl12xx and
>>> needs to be held high to keep the bluetooth core from resetting while
>>> the DM37x goes into off mode.
>>>
>>> I've tried muxing the pin using OMAP_PIN_OUTPUT |
>>> OMAP_PIN_OFF_OUTPUT_HIGH, but the pin goes low when the chip goes into
>>> off mode.  If I disable off mode via "echo 0 >
>>> /sys/kernel/debug/pm_debug/enable_off_mode" the pin remains high while
>>> the chip goes into retention and the bluetooth core works after resume.
>>>
>>> Any ideas why GPIO_162 would go low during suspend to off mode?
>> Unless the GPIO is in a GPIO bank that's connected to the WKUP
>> power domain, the GPIO bank context will be lost. So there's a short
>> period where the  GPIO bank is in an uninitialized state between waking
>> from off-idle and before the context to the GPIO bank gets restored in
>> omap_gpio_runtime_resume().
>>
>> If there's a pull on the line, the period is long enough to change
>> the line.
>>
>> Unless the TI people know some magic tricks that I'm not aware of,
>> there's no way around it, except to use external pulls to keep
>> the GPIO line in desired state, or move the GPIO somewhere else,
>> like TWL.
>>
>>
> Unfortunately the hardware doesn't have an external pullup, and
> re-spinning it to route BT_EN to a GPIO pin that's in the WKUP domain
> isn't an option at this time...
>
> Unless there's some TI-magic to keep GPIO_162 high during OFF mode I'll
> have to solve this the hard way by reinitializing the BT/GPS core during
> resume using deferred work.  Unfirtuantely I don't have a clear
> understanding of the userspace interaction to know if this is doable.
>
> Mechanically it doesn't look too difficult to use the guts of
> st_register/st_kim_start to reinitialize the GT/GPS core and download
> its firmware, but the userspace interactions (and the time it takes to
> load the firmware) is what makes coming up with a good solution difficult.
>
> Any suggestions on how to approach solving this are most appreciated!
>

The recommended way is to configure it as INPUT + PULL_UP
and don't use OFFMODE feature if the 1 value is needed on port during 
off-mode.

You need to check if you have valid pin-cfg right before call to
omap4_enter_lowpower() ->omap4_cpu_suspend(cpu, save_state);

I recommend you to ask you questions here:
  http://e2e.ti.com/support/omap/default.aspx

Regards,
- grygorii