Skip to contentSkip to conversation

OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP

PATCH New Maximilian Schwerin 5 participants 12 messages Mar 14, 2012 – Mar 20, 2012

Subsystems (3)
Arm (32-bit) Arm sub-architectures OMAP2+ support
lore
Share & tools
lore

Maximilian Schwerin

author
#0 lore raw

PATCH 1/1 OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP

From: Steve Sakoman <[email protected]>

Don't try to add IVA OPPs for OMAP3 versions not containing an IVA subsystem, as this would make omap_init_opp_table fail.

Signed-off-by Steve Sakoman <[email protected]>
Signed-off-by Maximilian Schwerin <[email protected]>
---
 arch/arm/mach-omap2/opp.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/opp.c +4 -0
index 9262a6b..414f2ec 100644
@@ -62,6 +62,10 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
 				__func__, i);
 			return -EINVAL;
 		}
+
+		if ((strcmp(opp_def->hwmod_name,"iva") == 0) && !omap3_has_iva())
+			continue;
+
 		oh = omap_hwmod_lookup(opp_def->hwmod_name);
 		if (!oh || !oh->od) {
 			pr_warn("%s: no hwmod or odev for %s, [%d] "
Signature · 1 line
1.7.0.4
#1 lore raw

PATCH 1/1 OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP

Quoted 7 lines · Maximilian Schwerin

From: Steve Sakoman <[email protected]>

Don't try to add IVA OPPs for OMAP3 versions not containing an IVA subsystem, as this would make omap_init_opp_table fail.

Signed-off-by Steve Sakoman <[email protected]>
Signed-off-by Maximilian Schwerin <[email protected]>

Minor: patch subjects for arch/arm/* core code need to have the ARM:
prefix also.

Also, please run scripts/checkpatch.pl on your patch and fix the warnings.

Quoted 9 lines
---
 arch/arm/mach-omap2/opp.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/opp.c +0 -0
index 9262a6b..414f2ec 100644

arch/arm/mach-omap2/opp.c int __init omap_init_opp_table(struct omap_opp_def *opp_def, · line 71

Quoted 10 lines
arch/arm/mach-omap2/opp.c +4 -0
@@ -62,6 +62,10 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
 				__func__, i);
 			return -EINVAL;
 		}
+
+		if ((strcmp(opp_def->hwmod_name,"iva") == 0) && !omap3_has_iva())
+			continue;
+
 		oh = omap_hwmod_lookup(opp_def->hwmod_name);
 		if (!oh || !oh->od) {
 			pr_warn("%s: no hwmod or odev for %s, [%d] "

Wouldn't the one-liner below do the same thing?

Actually, your patch makes it less noisy at boot time, avoiding the pr_warn(), so is probably better.

Kevin

arch/arm/mach-omap2/opp.c +1 -1
index 9262a6b..d3d4fa2 100644
@@ -67,7 +67,7 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
 			pr_warn("%s: no hwmod or odev for %s, [%d] "
 				"cannot add OPPs.\n", __func__,
 				opp_def->hwmod_name, i);
-			return -EINVAL;
+			continue;
 		}
 		dev = &oh->od->pdev->dev;
#2 lore raw

PATCH 1/1 OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP

Quoted 38 lines · Kevin Hilman
Quoted 7 lines · Maximilian Schwerin

From: Steve Sakoman <[email protected]>

Don't try to add IVA OPPs for OMAP3 versions not containing an IVA subsystem, as this would make omap_init_opp_table fail.

Signed-off-by Steve Sakoman <[email protected]>
Signed-off-by Maximilian Schwerin <[email protected]>

Minor: patch subjects for arch/arm/* core code need to have the ARM:
prefix also.

Also, please run scripts/checkpatch.pl on your patch and fix the warnings.

Quoted 18 lines

---
?arch/arm/mach-omap2/opp.c | ? ?4 ++++
?1 files changed, 4 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/opp.c +4 -0
index 9262a6b..414f2ec 100644
@@ -62,6 +62,10 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? __func__, i);
 ? ? ? ? ? ? ? ? ? ? ? return -EINVAL;
 ? ? ? ? ? ? ? }
+
+ ? ? ? ? ? ? if ((strcmp(opp_def->hwmod_name,"iva") == 0) && !omap3_has_iva())
+ ? ? ? ? ? ? ? ? ? ? continue;
+
 ? ? ? ? ? ? ? oh = omap_hwmod_lookup(opp_def->hwmod_name);
 ? ? ? ? ? ? ? if (!oh || !oh->od) {
Quoted 1 line

? ? ? ? ? ? ? ? ? ? ? pr_warn("%s: no hwmod or odev for %s, [%d] "

Wouldn't the one-liner below do the same thing?

Quoted 2 lines

Actually, your patch makes it less noisy at boot time, avoiding the pr_warn(), so is probably better.

The only issue i have with current patch is that it focusses to solve a specific device IVA.
we could have similar variances if we had SGX/AESS device etc registered in the common
table. a generic solution might be preferable - could we reduce the severity of pr_warn to pr_debug and do a continue instead?

Quoted 8 lines

Kevin

arch/arm/mach-omap2/opp.c +0 -0
index 9262a6b..d3d4fa2 100644
@@ -67,7 +67,7 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
Quoted 7 lines

? ? ? ? ? ? ? ? ? ? ? ?pr_warn("%s: no hwmod or odev for %s, [%d] " ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"cannot add OPPs.\n", __func__, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?opp_def->hwmod_name, i);
- ? ? ? ? ? ? ? ? ? ? ? return -EINVAL;
+ ? ? ? ? ? ? ? ? ? ? ? continue;
? ? ? ? ? ? ? ?}
? ? ? ? ? ? ? ?dev = &oh->od->pdev->dev;

Regards,
Nishanth Menon

#3 lore raw

PATCH 1/1 OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP

Quoted 42 lines · Nishanth
Quoted 38 lines · Kevin Hilman
Quoted 7 lines · Maximilian Schwerin

From: Steve Sakoman <[email protected]>

Don't try to add IVA OPPs for OMAP3 versions not containing an IVA subsystem, as this would make omap_init_opp_table fail.

Signed-off-by Steve Sakoman <[email protected]>
Signed-off-by Maximilian Schwerin <[email protected]>

Minor: patch subjects for arch/arm/* core code need to have the ARM:
prefix also.

Also, please run scripts/checkpatch.pl on your patch and fix the warnings.

Quoted 18 lines

---
 arch/arm/mach-omap2/opp.c |    4 ++++

 1 files changed, 4 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/opp.c +4 -0
index 9262a6b..414f2ec 100644
@@ -62,6 +62,10 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
                               __func__, i);
                       return -EINVAL;
               }
+
+             if ((strcmp(opp_def->hwmod_name,"iva") == 0) && !omap3_has_iva())
+                     continue;
+
               oh = omap_hwmod_lookup(opp_def->hwmod_name);
               if (!oh || !oh->od) {
Quoted 1 line

                      pr_warn("%s: no hwmod or odev for %s, [%d] "

Wouldn't the one-liner below do the same thing?

Quoted 2 lines

Actually, your patch makes it less noisy at boot time, avoiding the pr_warn(), so is probably better.

Quoted 6 lines

The only issue i have with current patch is that it focusses to solve a specific device IVA.
we could have similar variances if we had SGX/AESS device etc registered in the common
table. a generic solution might be preferable - could we reduce the severity of pr_warn to pr_debug and do a continue instead?

I agree, that would be a better generic solution.

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

#4 lore raw
Quoted 57 lines

Von: Kevin Hilman [mailto:khilman at ti.com]

Quoted 5 lines · Nishanth
Quoted 4 lines · Kevin Hilman
Quoted 2 lines · Maximilian Schwerin

From: Steve Sakoman <[email protected]>

Quoted 7 lines
Quoted 7 lines
Quoted 5 lines

Don't try to add IVA OPPs for OMAP3 versions not containing an IVA subsystem, as this would make omap_init_opp_table fail.

Signed-off-by Steve Sakoman <[email protected]>
Signed-off-by Maximilian Schwerin <[email protected]>

Minor: patch subjects for arch/arm/* core code need to

have the ARM:

Quoted 9 lines
Quoted 9 lines

prefix also.

Also, please run scripts/checkpatch.pl on your patch and fix the warnings.

Quoted 4 lines

---
?arch/arm/mach-omap2/opp.c | ? ?4 ++++
?1 files changed, 4 insertions(+), 0 deletions(-)

Quoted 5 lines
Quoted 5 lines

arch/arm/mach-omap2/opp.c int __init omap_init_opp_table(struct

Quoted 5 lines
arch/arm/mach-omap2/opp.c +0 -0
index 9262a6b..414f2ec 100644
@@ -62,6 +62,10 @@ int __init omap_init_opp_table(struct

omap_opp_def *opp_def,

Quoted 5 lines
Quoted 5 lines

arch/arm/mach-omap2/opp.c int __init omap_init_opp_table(struct · line 66

Quoted 5 lines
arch/arm/mach-omap2/opp.c +2 -0
 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? __func__, i);
 ? ? ? ? ? ? ? ? ? ? ? return -EINVAL;
 ? ? ? ? ? ? ? }
+
+ ? ? ? ? ? ? if ((strcmp(opp_def->hwmod_name,"iva") ==

0) && !omap3_has_iva())

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
arch/arm/mach-omap2/opp.c +2 -0
+ ? ? ? ? ? ? ? ? ? ? continue;
+
 ? ? ? ? ? ? ? oh = omap_hwmod_lookup(opp_def->hwmod_name);
 ? ? ? ? ? ? ? if (!oh || !oh->od) {

? ? ? ? ? ? ? ? ? ? ? pr_warn("%s: no hwmod or odev for %s, [%d] "

Quoted 6 lines
Quoted 4 lines

Wouldn't the one-liner below do the same thing?

Actually, your patch makes it less noisy at boot time, avoiding the pr_warn(), so is probably better.

The only issue i have with current patch is that it

focusses to solve

Quoted 5 lines

a specific device IVA.
we could have similar variances if we had SGX/AESS device etc registered in the common
table. a generic solution might be preferable - could we reduce the severity of pr_warn to pr_debug and do a continue instead?

Quoted 4 lines

I agree, that would be a better generic solution.

Kevin

This is a pragmatic and simple solution for a well understood problem with no side effects. Why not fix the problem now and do the generic solution later on?

I'm not a fulltime kernel dev. I have about two weeks to get my new board out to my customer... Every time I set up a new board, I have to fix problems using known patches that are sometimes years old. Every patch I have to find costs me hours of time I really don't have.

Just my two cents (euro cents of course :-), Maximilian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120316/16737b2b/attachment.sig>

#5 lore raw

PATCH 1/1 OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP

On 10:26-20120316, Maximilian Schwerin wrote:
[...]

Quoted 24 lines
Quoted 24 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

+
+ ? ? ? ? ? ? if ((strcmp(opp_def->hwmod_name,"iva") ==

0) && !omap3_has_iva())

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines

+ ? ? ? ? ? ? ? ? ? ? continue;
+
? ? ? ? ? ? ? oh = omap_hwmod_lookup(opp_def->hwmod_name); ? ? ? ? ? ? ? if (!oh || !oh->od) {
? ? ? ? ? ? ? ? ? ? ? pr_warn("%s: no hwmod or odev for %s, [%d] "

Quoted 6 lines
Quoted 4 lines

Wouldn't the one-liner below do the same thing?

Actually, your patch makes it less noisy at boot time, avoiding the pr_warn(), so is probably better.

The only issue i have with current patch is that it

focusses to solve

Quoted 5 lines

a specific device IVA.
we could have similar variances if we had SGX/AESS device etc registered in the common
table. a generic solution might be preferable - could we reduce the severity of pr_warn to pr_debug and do a continue instead?

I agree, that would be a better generic solution.

Quoted 8 lines
Quoted 2 lines

Kevin

This is a pragmatic and simple solution for a well understood problem with no side effects. Why not fix the problem now and do the generic solution later on?

I'm not a fulltime kernel dev. I have about two weeks to get my new board out to my customer... Every time I set up a new board, I have to fix problems using known patches that are sometimes years old. Every patch I have to find costs me hours of time I really don't have.

Just my two cents (euro cents of course :-), Maximilian

ok, so lets fix it generically - here is the patch for it. Let us know if this works for you

Quoted 1 line

From 5275d09c9f1a16c8f0814745e1c313c6cca049f6 Mon Sep 17 00:00:00 2001

From: Nishanth Menon <[email protected]>
Date: Fri, 16 Mar 2012 09:13:24 -0500
Subject: [PATCH] OMAP2+: OPP: allow OPP enumeration to continue if device is not present

On platforms such as OMAP3, certain variants may not have IVA, SGX or some specific component. We currently have a check to aid fixing wrong population of OPP entries for issues such as typos. This however causes a conflict with valid requirement where the SoC variant does not actually have the module present.

So, reduce the severity of the print to a debug statement and skip registering that specific OPP, but continue down the list.

Reported-by Steve Sakoman <[email protected]>
Reported-by Maximilian Schwerin <[email protected]>
Signed-off-by Nishanth Menon <[email protected]>
---
 arch/arm/mach-omap2/opp.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
arch/arm/mach-omap2/opp.c +2 -2
index 9262a6b..de6d464 100644
@@ -64,10 +64,10 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
 		}
 		oh = omap_hwmod_lookup(opp_def->hwmod_name);
 		if (!oh || !oh->od) {
-			pr_warn("%s: no hwmod or odev for %s, [%d] "
+			pr_debug("%s: no hwmod or odev for %s, [%d] "
 				"cannot add OPPs.\n", __func__,
 				opp_def->hwmod_name, i);
-			return -EINVAL;
+			continue;
 		}
 		dev = &oh->od->pdev->dev;
Signature · 6 lines
1.7.0.4


-- 
Regards,
Nishanth Menon
#6 lore raw
Quoted 103 lines

-----Urspr?ngliche Nachricht-----
Von: Nishanth Menon [mailto:nm at ti.com]
Gesendet: Freitag, 16. M?rz 2012 15:21
An: Maximilian Schwerin
Cc: Kevin Hilman; linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Steve Sakoman
Betreff: Re: [PATCH] OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP

On 10:26-20120316, Maximilian Schwerin wrote:
[...]

Quoted 8 lines
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

+
+ ? ? ? ? ? ? if ((strcmp(opp_def->hwmod_name,"iva") ==

0) && !omap3_has_iva())

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines

+ ? ? ? ? ? ? ? ? ? ? continue;
+
? ? ? ? ? ? ? oh = omap_hwmod_lookup(opp_def->hwmod_name); ? ? ? ? ? ? ? if (!oh || !oh->od) {
? ? ? ? ? ? ? ? ? ? ? pr_warn("%s: no hwmod or odev

for %s, [%d] "

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

Wouldn't the one-liner below do the same thing?

Actually, your patch makes it less noisy at boot time,

avoiding the

Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Quoted 1 line

pr_warn(), so is probably better.

The only issue i have with current patch is that it

focusses to solve

Quoted 4 lines

a specific device IVA.
we could have similar variances if we had SGX/AESS device etc registered in the common
table. a generic solution might be preferable - could

we reduce the

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

severity of pr_warn to pr_debug and do a continue instead?

I agree, that would be a better generic solution.

Kevin

This is a pragmatic and simple solution for a well

understood problem with no side effects. Why not fix the problem now and do the generic solution later on?

Quoted 2 lines

I'm not a fulltime kernel dev. I have about two weeks to

get my new board out to my customer... Every time I set up a new board, I have to fix problems using known patches that are sometimes years old. Every patch I have to find costs me hours of time I really don't have.

Quoted 2 lines

Just my two cents (euro cents of course :-), Maximilian

ok, so lets fix it generically - here is the patch for it. Let us know if this works for you

From 5275d09c9f1a16c8f0814745e1c313c6cca049f6 Mon Sep 17 00:00:00 2001
From: Nishanth Menon <[email protected]>
Date: Fri, 16 Mar 2012 09:13:24 -0500
Subject: [PATCH] OMAP2+: OPP: allow OPP enumeration to continue if device is not present

On platforms such as OMAP3, certain variants may not have IVA, SGX or some specific component. We currently have a check to aid fixing wrong population of OPP entries for issues such as typos. This however causes a conflict with valid requirement where the SoC variant does not actually have the module present.

So, reduce the severity of the print to a debug statement and skip registering that specific OPP, but continue down the list.

Reported-by Steve Sakoman <[email protected]>
Reported-by Maximilian Schwerin <[email protected]>
Signed-off-by Nishanth Menon <[email protected]>
---
 arch/arm/mach-omap2/opp.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
arch/arm/mach-omap2/opp.c +2 -2
index 9262a6b..de6d464 100644
@@ -64,10 +64,10 @@ int __init omap_init_opp_table(struct 
 omap_opp_def *opp_def,
 		}
 		oh = omap_hwmod_lookup(opp_def->hwmod_name);
 		if (!oh || !oh->od) {
-			pr_warn("%s: no hwmod or odev for %s, [%d] "
+			pr_debug("%s: no hwmod or odev for %s, [%d] "
 				"cannot add OPPs.\n", __func__,
 				opp_def->hwmod_name, i);
-			return -EINVAL;
+			continue;
 		}
 		dev = &oh->od->pdev->dev;
Signature · 7 lines
-- 
1.7.0.4


-- 
Regards,
Nishanth Menon

Hi,

sorry my fault! This was not what I was thinking of as generic. Works as expected!

Thanks, m.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120316/3c333903/attachment.sig>

#7 lore raw

PATCH 1/1 OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP

Quoted 3 lines · Maximilian Schwerin

sorry my fault! This was not what I was thinking of as generic. Works as expected!

Can i take it as an acked-by?

Regards,
Nishanth Menon

#8 lore raw

PATCH 1/1 OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP

In reply to Nishanth Menon
Quoted 39 lines · Nishanth Menon

From 5275d09c9f1a16c8f0814745e1c313c6cca049f6 Mon Sep 17 00:00:00 2001
From: Nishanth Menon <[email protected]>
Date: Fri, 16 Mar 2012 09:13:24 -0500
Subject: [PATCH] OMAP2+: OPP: allow OPP enumeration to continue if device is not present

On platforms such as OMAP3, certain variants may not have IVA, SGX or some specific component. We currently have a check to aid fixing wrong population of OPP entries for issues such as typos. This however causes a conflict with valid requirement where the SoC variant does not actually have the module present.

So, reduce the severity of the print to a debug statement and skip registering that specific OPP, but continue down the list.

Reported-by Steve Sakoman <[email protected]>
Reported-by Maximilian Schwerin <[email protected]>
Signed-off-by Nishanth Menon <[email protected]>

---
?arch/arm/mach-omap2/opp.c | ? ?4 ++--
?1 files changed, 2 insertions(+), 2 deletions(-)

arch/arm/mach-omap2/opp.c +2 -3
index 9262a6b..de6d464 100644
@@ -64,10 +64,10 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
 ? ? ? ? ? ? ? ?}
 ? ? ? ? ? ? ? ?oh = omap_hwmod_lookup(opp_def->hwmod_name);
 ? ? ? ? ? ? ? ?if (!oh || !oh->od) {
- ? ? ? ? ? ? ? ? ? ? ? pr_warn("%s: no hwmod or odev for %s, [%d] "
+ ? ? ? ? ? ? ? ? ? ? ? pr_debug("%s: no hwmod or odev for %s, [%d] "
 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"cannot add OPPs.\n", __func__,
 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?opp_def->hwmod_name, i);
- ? ? ? ? ? ? ? ? ? ? ? return -EINVAL;
+ ? ? ? ? ? ? ? ? ? ? ? continue;
 ? ? ? ? ? ? ? ?}
 ? ? ? ? ? ? ? ?dev = &oh->od->pdev->dev;
 
--
Quoted 1 line

1.7.0.4

Acked-by Steve Sakoman <[email protected]>
#9 lore raw

PATCH 1/1 OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP

In reply to Nishanth Menon
Quoted 66 lines · Nishanth Menon

On 10:26-20120316, Maximilian Schwerin wrote:
[...]

Quoted 24 lines
Quoted 24 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

+
+             if ((strcmp(opp_def->hwmod_name,"iva") ==

0) && !omap3_has_iva())

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines

+                     continue;
+
              oh = omap_hwmod_lookup(opp_def->hwmod_name); if (!oh || !oh->od) {
                      pr_warn("%s: no hwmod or odev for %s, [%d] "

Quoted 6 lines
Quoted 4 lines

Wouldn't the one-liner below do the same thing?

Actually, your patch makes it less noisy at boot time, avoiding the pr_warn(), so is probably better.

The only issue i have with current patch is that it

focusses to solve

Quoted 5 lines

a specific device IVA.
we could have similar variances if we had SGX/AESS device etc registered in the common
table. a generic solution might be preferable - could we reduce the severity of pr_warn to pr_debug and do a continue instead?

I agree, that would be a better generic solution.

Quoted 8 lines
Quoted 2 lines

Kevin

This is a pragmatic and simple solution for a well understood problem with no side effects. Why not fix the problem now and do the generic solution later on?

I'm not a fulltime kernel dev. I have about two weeks to get my new board out to my customer... Every time I set up a new board, I have to fix problems using known patches that are sometimes years old. Every patch I have to find costs me hours of time I really don't have.

Just my two cents (euro cents of course :-), Maximilian

ok, so lets fix it generically - here is the patch for it. Let us know if this works for you

From 5275d09c9f1a16c8f0814745e1c313c6cca049f6 Mon Sep 17 00:00:00 2001
From: Nishanth Menon <[email protected]>
Date: Fri, 16 Mar 2012 09:13:24 -0500
Subject: [PATCH] OMAP2+: OPP: allow OPP enumeration to continue if device is not present

On platforms such as OMAP3, certain variants may not have IVA, SGX or some specific component. We currently have a check to aid fixing wrong population of OPP entries for issues such as typos. This however causes a conflict with valid requirement where the SoC variant does not actually have the module present.

So, reduce the severity of the print to a debug statement and skip registering that specific OPP, but continue down the list.

Reported-by Steve Sakoman <[email protected]>
Reported-by Maximilian Schwerin <[email protected]>
Signed-off-by Nishanth Menon <[email protected]>
---
 arch/arm/mach-omap2/opp.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
arch/arm/mach-omap2/opp.c +0 -0
index 9262a6b..de6d464 100644
@@ -64,10 +64,10 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
 		}
 		oh = omap_hwmod_lookup(opp_def->hwmod_name);

arch/arm/mach-omap2/opp.c int __init omap_init_opp_table(struct omap_opp_def *opp_def, · line 73

Quoted 10 lines
arch/arm/mach-omap2/opp.c +2 -2
 		if (!oh || !oh->od) {
-			pr_warn("%s: no hwmod or odev for %s, [%d] "
+			pr_debug("%s: no hwmod or odev for %s, [%d] "
 				"cannot add OPPs.\n", __func__,
 				opp_def->hwmod_name, i);
-			return -EINVAL;
+			continue;
 		}
 		dev = &oh->od->pdev->dev;

Yes, thanks for doing this more genericly.

Nishanth, can you collect the acks/tested-bys and repost and official patch.

I'll queue this up.

Thanks,

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

#11 lore raw

PATCH 1/1 OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP

Quoted 8 lines · Nishanth

Kevin,
[...]

Quoted 4 lines

Nishanth, can you collect the acks/tested-bys and repost and official patch.

I'll queue this up.

Thanks. This is already done:
http://marc.info/?l=linux-omap&m=133191481703750&w=2

Yeah, sorry for the noise. I saw it after I sent this request.

Kevin