[PATCH] ARM: OMAP: hwmod: Fix error handling in functions used OMAP4 onwards
From: Hiremath, Vaibhav <hidden>
Date: 2012-03-30 07:14:52
Also in:
linux-omap
On Thu, Mar 29, 2012 at 20:33:17, Hunter, Jon wrote:
Hi Viabhav, On 3/29/2012 3:56, Hiremath, Vaibhav wrote:quoted
On Thu, Mar 29, 2012 at 11:42:34, Nayak, Rajendra wrote:quoted
On Wednesday 28 March 2012 12:02 PM, Hiremath, Vaibhav wrote:quoted
On Tue, Mar 27, 2012 at 15:28:31, Nayak, Rajendra wrote:quoted
Some functions like _omap4_disable_module() and _omap4_wait_target_disable() are (will be) used on all OMAPs OMAP4 and beyond which support module level control. Fix the error checks in these functions to return if called on any platform pre OMAP4 (i.e OMAP2 and OMAP3) instead of checking for !cpu_is_omap44xx(). This avoids having to update the error check with a '&& !cpu_is_omap54xx()' when OMAP5 is introduced and possibly similar updates when further OMAP generations are added.Let me add some flavor here :) AM33xx, which has module level control, but falls under OMAP3 family of devices. cpu_is_omap34xx() is true for AM33xx device and we have to add check in all these functions. And I am sure we will have many of such devices in the future. Can we use some flag based option here, instead of cpu_is_xxx() check?The intent of this patch was to make the error handling uniform across all modules control functions in hwmod, and it atleast addresses one problem of having to update these checks every time a new OMAP gets added. The problem that you bring up with AM33xx is regardless of this patch (you would still need to go update every !cpu_is_omap44xx() check)Indeed, in any of cpu_is_xxx() check implementation, I have to add check for cpu_is_am33xx().I hope we can avoid adding more cpu_is_amXXXX. That should be a last resort.
Yes, indeed; adding cpu_is_xxx check would be my last option. Thanks, Vaibhav
Jon