Hi Viabhav,
On 3/29/2012 3:56, Hiremath, Vaibhav wrote:
On Thu, Mar 29, 2012 at 11:42:34, Nayak, Rajendra wrote:
On Wednesday 28 March 2012 12:02 PM, Hiremath, Vaibhav wrote:
On Tue, Mar 27, 2012 at 15:28:31, Nayak, Rajendra wrote:
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.
Jon
--
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
