How to keep DM37x GPIO_162 high during off-mode

How to keep DM37x GPIO_162 high during off-mode

[Peter Barada]

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?

Note I can't move to a newer kernel due to scheduling constraints.

Thanks in advance!

-- 
Peter Barada
peter.barada@logicpd.com

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

[Tony Lindgren]

* 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.

Regards,

Tony

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

[Peter Barada]

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!

-- 
Peter Barada
peter.barada@logicpd.com

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

[Grygorii Strashko]

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

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

[Peter Barada]

On 07/11/2013 04:15 PM, Grygorii Strashko wrote:
> 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
Grygoril,

Part of our requirements is to go to OFFMODE during suspend.  I believe
the pin is properly muxed since if I disable OFFMODE then GPIO_162 does
stay high.  From the TRM (if I understand it correctly) the only pins
that will retain OFF-mode state high are those pins that are located in
the WKUP domain.  Given the requirement of OFFMODE and that we can't
spin the hardware to move BT_EN to a gpio pin in the WKUP domain I'm
stuck trying to figure out how to reinit/reload the firmware during resume.

Any suggestions (or gotchas) are appreciated!

-- 
Peter Barada
peter.barada@logicpd.com