Hello, There have been a few discussions over the few months about how to properly use omap_hwmod to manage certain IPs that have the interface clock as the functional clock (e.g. OMAP3 GPIOs.) The goal of this RFC is to come to a conclusion about what should be done, and how to go about implementing it. In the initial conversion of the GPIO core to omap_hwmod, main_clk was left NULL so that hwmod was not managing the clock on every hwmod enable/disable. This behavior matched current mainline GPIO code, which does not dynamically disable/enable GPIO iclks after init time. Instead, it relies on the module-level auto idle feature in HW. However, without dynamically managing the clock in hwmod, this meant that there were no autodeps tracked for GPIO and thus the PER powerdomain could transition independently of MPU/CORE. The initial solution to this was to set the iclk to be the main_clk of the hwmod, such that autodeps were managed dynamically as well. This led to a change in functionality in current code, since the iclk was now being manually enabled/disabled at runtime instead of being left for HW to manage by module autoidle. It also led to problems in correctly handling asynchronous GPIO wakeups. In some off-list discussions, one proposal to address this was to change the omap_hwmod core to check the module autoidle before disabling the clock. If the module autoidle is enabled, then hwmod would not directly manage the clock during hwmod_enable/disable. The question is: is this an acceptable solution? the clock framework currently has no knowledge of module auto-idle, where the hwmod core does, so it seems hwmod is (currently) the best place to handle this. Alternatively, would it make sense to do something different with autodeps, such that modules like this that don't have a separate functional clock still have autodeps handled, possibly by using an optional clock? Does extending autodeps make sense since, IIUC, we won't really need them after all devices are using hwmod? Anyways... this is to get the discussion going so we can come to a conclusion on this matter and finialize the hwmod conversions for some of these "special" IPs. Thanks, 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
