[PATCH 2/7] OMAP2+: mux: Enable wakeup for wakeup enable requested pads
khilman at ti.com
Tue Mar 8 13:31:26 EST 2011
Tony Lindgren <tony at atomide.com> writes:
> * Govindraj <govindraj.ti at gmail.com> [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.
More information about the linux-arm-kernel