[PATCH] ARM: OMAP: hwmod: Fix error handling in functions used OMAP4 onwards

[Jon Hunter]

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