>>-----Original Message----- >>From: Kevin Hilman [mailto:[email protected]] >>Sent: Friday, October 22, 2010 10:08 PM >>To: Gopinath, Thara >>Cc: [email protected]; [email protected]; Cousson, Benoit; Sripathy, >>Vishwanath; Sawant, Anand >>Subject: Re: [PATCH v3 09/11] OMAP3: PM: Smartreflex Class3 initialization >>from board files. >> >>"Gopinath, Thara" <[email protected]> writes: >> >>>>>> This patch enables smartreflex class3 functionality for OMAP3430SDP, >>>>>> OMAP3630SDP, ZOOM2 and ZOOM3 boards. >>>>> >>>>>This patch doesn't touch 3630sdp. >>>>> >>>>>> Signed-off-by: Thara Gopinath <[email protected]> >>>>> >>>>>I'm having some doubts about whether this should be done by board files or >>>>>not. Seems like the general case will be that by default will be SoC >>>>>specific, and only boards that want something other than the default >>>>>class should need to override this. >>>>> >>>>>Thoughts? >>> >>> I agree. I wanted this to be a default initcall and one to enable the >>> menuconfig option for the required class driver.. But Nishant wanted >>> this from board files. >> >>And I want both. :) >> >>> If we have consensus in removing this init from board file, I am cool >>> with it. >> >>I want to suport a kernel that could be built with all possible classes >>supported. e.g. an omap3/4 kernel that has both class 1.5 and class 3 >>support. >> >>If both are enabled in Kconfig, then either could be used. We'll have >>to pick one as the default initcall (e.g. highest class present), but if >>a board file chooses to call a different one, that should override the >>default one.
We can pick class 3 by default and make it a late_initcall. This way if the board files choose to call some other class init, that class ddriver would be registered. Smartreflex driver sr_register_class API will ensure that only one class is registered. The second registeration will fail. What say ?? Regards, Thara -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
