On Fri, May 25, 2012 at 6:23 PM, Cousson, Benoit [off-list ref] wrote:

Hi Eduardo,


On 5/25/2012 10:25 AM, Eduardo Valentin wrote:

quoted

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<redacted>
---
?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.

Regards
Santosh