[PATCH] ARM: OMAP: hwmod: Fix error handling in functions used OMAP4 onwards
Hiremath, Vaibhav
hvaibhav at ti.com
Fri Mar 30 03:14:52 EDT 2012
On Thu, Mar 29, 2012 at 20:33:17, Hunter, Jon wrote:
> 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.
>
Yes, indeed; adding cpu_is_xxx check would be my last option.
Thanks,
Vaibhav
> Jon
>
More information about the linux-arm-kernel
mailing list