Hello, On Mon, May 28, 2012 at 03:32:50PM +0530, Shilimkar, Santosh wrote: > On Fri, May 25, 2012 at 6:23 PM, Cousson, Benoit <b-cousson@xxxxxx> wrote: > > Hi Eduardo, > > > > > > On 5/25/2012 10:25 AM, Eduardo Valentin wrote: > >> > >> OMAP system control module can be probed early, then > >> omap_type is safe to use its APIs. > >> > >> TODO: add support for other omap versions > >> > >> Signed-off-by: Eduardo Valentin<eduardo.valentin@xxxxxx> > >> --- > >> arch/arm/mach-omap2/id.c | 16 +++++++++++++++- > >> 1 files changed, 15 insertions(+), 1 deletions(-) > >> > >> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c > >> index 5bb9746..acfd698 100644 > >> --- a/arch/arm/mach-omap2/id.c > >> +++ b/arch/arm/mach-omap2/id.c > >> @@ -18,6 +18,7 @@ > >> #include<linux/kernel.h> > >> #include<linux/init.h> > >> #include<linux/io.h> > >> +#include<linux/mfd/omap_control.h> > >> > >> #include<asm/cputype.h> > >> > >> @@ -40,8 +41,14 @@ EXPORT_SYMBOL(omap_rev); > >> > >> int omap_type(void) > >> { > >> + struct device *scm; > >> + int ret = 0; > >> u32 val = 0; > >> > >> + scm = omap_control_get(); > >> + if (IS_ERR_OR_NULL(scm)) > >> + return 0; > >> + > >> if (cpu_is_omap24xx()) { > > > > > > OK, not really related to that patch, but the previous cpu_is_omap24xx makes > > me think of that :-) > > > > What about the omap<X>_check_revision used by cpu_is_XXX? > > > > This call is the very first one to require the control module access in > > order to get the ID_CODE inside the control module. > > > > So far it still use that ugly hard coded phys -> virtual address macro that > > is sued for that. > > > Agree with Benoits comment. One way to deal with this is, > store the register offset with init and then just use it here. > > That way you can get rid of all cpu_is_XXXX() from this function. I see. I need to check how this storing would look like. Probably we can do the storing when the early device gets probed. > > Regards > Santosh -- 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