Tony Lindgren <tony@xxxxxxxxxxx> writes: > * Govindraj <govindraj.ti@xxxxxxxxx> [110308 03:43]: >> >> I am not sure whether now we can control read/writes to pad_mux from any driver >> interface and I think we have to go through mux framework for any >> read/writes to mux. > > Sure, the drivers should not mess with those registers directly. > >> with this I cant control pad wake up capabilities with sysfs as done >> earlier in serial.c >> now control to read/write to pad is outside scope of the driver >> interface as omap_hwmod_mux >> is the one that takes decision for driver with mux values provided >> during omap_hwmod_mux_init. > > The sysfs interface to control this should still be from the drivers. > Sounds like we need some way to set the wakeup flags before pm_runtime_put > is called. Exactly. Driver's can currently check device_may_wakeup(dev) to determine if they *should* set wakeup flags, but currently, we don't have a clean way to pass the info down to core code. One possible option (albeit hacky) is for the omap_hwmod_mux code to check device_may_wakeup() itself, and set the bits accordingly. This means drivers don't have to do anything, but drivers also loose control of enabling/disabling wakeups. I think what we need are two omap_device-level APIs for wakeups. One for enable/disable of wakeups (both module-level and IO-ring, the driver should not care about the difference between the two): int omap_device_[enable|disable](struct platform_device *pdev); bool omap_device_wakeup_occured(struct platform_device *pdev); As OMAP-specific APIs, both of these should of course be called through pdata function pointers. Kevin -- 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
