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 > -- 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
