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

[Peter Barada <peter.barada@logicpd.com>]

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