On 07/09/2013 11:55 AM, Tony Lindgren wrote: > * Peter Barada <peter.barada@xxxxxxxxxxx> [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@xxxxxxxxxxx -- 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
