ARM: OMAP3: Fix iva2_pwrdm settings for 3703

PATCH New Tony Lindgren 5 participants 16 messages May 15, 2013 – May 22, 2013

Subsystems (4)

Arm (32-bit) Arm sub-architectures OMAP2+ support OMAP power management support

lore

Share & tools

lore

Tony Lindgren

author maintainer

2013-05-15 00:25 UTC #0 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists) changed PM to not access IVA registers on omaps that don't have them. Turns out we still need to idle iva2 as otherwise iva2_pwrdm will stay on and block deeper idle states.

Signed-off-by Tony Lindgren <[email protected]>

---

Paul & Kevin, do you have better ideas for fixing this?

arch/arm/mach-omap2/pm34xx.c +4 -2

@@ -546,8 +546,10 @@ static void __init prcm_setup_regs(void)
 	/* Clear any pending PRCM interrupts */
 	omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
 
-	if (omap3_has_iva())
-		omap3_iva_idle();
+	/*
+	 * We need to idle iva2_pwrdm even on am3703 with no iva2.
+	 */
+	omap3_iva_idle();
 
 	omap3_d2d_idle();
 }

Mark A. Greer

2013-05-15 01:52 UTC #1 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

Quoted 16 lines · Tony Lindgren

Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists) changed PM to not access IVA registers on omaps that don't have them. Turns out we still need to idle iva2 as otherwise iva2_pwrdm will stay on and block deeper idle states.
Signed-off-by Tony Lindgren <[email protected]>
---
Paul & Kevin, do you have better ideas for fixing this?
arch/arm/mach-omap2/pm34xx.c +0 -0
@@ -546,8 +546,10 @@ static void __init prcm_setup_regs(void)
 	/* Clear any pending PRCM interrupts */
 	omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);

arch/arm/mach-omap2/pm34xx.c static void __init prcm_setup_regs(void) · line 555

Quoted 10 lines

arch/arm/mach-omap2/pm34xx.c +4 -2

 
-	if (omap3_has_iva())
-		omap3_iva_idle();
+	/*
+	 * We need to idle iva2_pwrdm even on am3703 with no iva2.
+	 */
+	omap3_iva_idle();
 
 	omap3_d2d_idle();
 }

[Kevin, Paul, some background: Tony discovered that the am3703 needs to have omap3_iva_idle() called even though its not supposed to have an IVA.]

This is potentially bad for other SoC's that don't have an IVA so I don't think its the way to go. My preference would be to set the OMAP3_HAS_IVA flag for the am3703 only since its the one with the bug. Maybe something in id.c:omap3xxx_check_features() but I don't see any existing way to check for an am3703 vs. other am37xx SoCs. Any ideas?

Another option, I suppose, is a dts entry but I don't like that at all.

Mark
--

Tony Lindgren

author maintainer

2013-05-15 17:07 UTC #2 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

Quoted 32 lines · Mark A. Greer

Quoted 16 lines · Tony Lindgren
Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists) changed PM to not access IVA registers on omaps that don't have them. Turns out we still need to idle iva2 as otherwise iva2_pwrdm will stay on and block deeper idle states.
Signed-off-by Tony Lindgren <[email protected]>
---
Paul & Kevin, do you have better ideas for fixing this?
arch/arm/mach-omap2/pm34xx.c +0 -0
@@ -546,8 +546,10 @@ static void __init prcm_setup_regs(void)
 	/* Clear any pending PRCM interrupts */
 	omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
arch/arm/mach-omap2/pm34xx.c static void __init prcm_setup_regs(void) · line 555
Quoted 10 lines
arch/arm/mach-omap2/pm34xx.c +4 -2
 
-	if (omap3_has_iva())
-		omap3_iva_idle();
+	/*
+	 * We need to idle iva2_pwrdm even on am3703 with no iva2.
+	 */
+	omap3_iva_idle();
 
 	omap3_d2d_idle();
 }
[Kevin, Paul, some background: Tony discovered that the am3703 needs to have omap3_iva_idle() called even though its not supposed to have an IVA.]

Quoted 7 lines

This is potentially bad for other SoC's that don't have an IVA so I don't think its the way to go. My preference would be to set the OMAP3_HAS_IVA flag for the am3703 only since its the one with the bug. Maybe something in id.c:omap3xxx_check_features() but I don't see any existing way to check for an am3703 vs. other am37xx SoCs. Any ideas?
Another option, I suppose, is a dts entry but I don't like that at all.

It seems that iva2_pwrdm is there for all omap3 even if OMAP3_HAS_IVA flag is unset. And if that's the case, iva2 clocks still need to be idled in all cases.

It's possible that not all steps in omap3_iva_idle() are needed though. I can debug further to see which part of the omap3_iva_idle() are needed.

Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with?

Regards,

Tony

Mark A. Greer

2013-05-15 21:50 UTC #3 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

Quoted 39 lines · Tony Lindgren

Quoted 38 lines · Mark A. Greer
Quoted 16 lines · Tony Lindgren
Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists) changed PM to not access IVA registers on omaps that don't have them. Turns out we still need to idle iva2 as otherwise iva2_pwrdm will stay on and block deeper idle states.
Signed-off-by Tony Lindgren <[email protected]>
---
Paul & Kevin, do you have better ideas for fixing this?
arch/arm/mach-omap2/pm34xx.c +0 -0
@@ -546,8 +546,10 @@ static void __init prcm_setup_regs(void)
 	/* Clear any pending PRCM interrupts */
 	omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
arch/arm/mach-omap2/pm34xx.c static void __init prcm_setup_regs(void) · line 555
Quoted 10 lines
arch/arm/mach-omap2/pm34xx.c +4 -2
 
-	if (omap3_has_iva())
-		omap3_iva_idle();
+	/*
+	 * We need to idle iva2_pwrdm even on am3703 with no iva2.
+	 */
+	omap3_iva_idle();
 
 	omap3_d2d_idle();
 }
[Kevin, Paul, some background: Tony discovered that the am3703 needs to have omap3_iva_idle() called even though its not supposed to have an IVA.]
This is potentially bad for other SoC's that don't have an IVA so I don't think its the way to go. My preference would be to set the OMAP3_HAS_IVA flag for the am3703 only since its the one with the bug. Maybe something in id.c:omap3xxx_check_features() but I don't see any existing way to check for an am3703 vs. other am37xx SoCs. Any ideas?

Quoted 5 lines

Quoted 1 line
Another option, I suppose, is a dts entry but I don't like that at all.
It seems that iva2_pwrdm is there for all omap3 even if OMAP3_HAS_IVA flag is unset. And if that's the case, iva2 clocks still need to be idled in all cases.

Ahh, this takes us to the "Great TI Docs Mystery" :) -- its basically impossible to tell because despite what their docs may say, the hardware can be quite different. I'm not sure how to proceed other than trial & error with as many different SoCs as we can find.

Quoted 5 lines

It's possible that not all steps in omap3_iva_idle() are needed though. I can debug further to see which part of the omap3_iva_idle() are needed.
Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with?

I have an am35xx which isn't supposed to have an IVA so I can test with it (although, I'm not sure how well the kernel works on the am35xx these days).

I'm a bit busy today but I'll try booting the am35xx tomorrow and if it comes up, see what I can figure out.

Mark
--

Yegor Yefremov

2013-05-16 10:19 UTC #4 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

Quoted 54 lines · Mark A. Greer

Quoted 39 lines · Tony Lindgren
Quoted 38 lines · Mark A. Greer
Quoted 16 lines · Tony Lindgren
Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists) changed PM to not access IVA registers on omaps that don't have them. Turns out we still need to idle iva2 as otherwise iva2_pwrdm will stay on and block deeper idle states.
Signed-off-by Tony Lindgren <[email protected]>
---
Paul & Kevin, do you have better ideas for fixing this?
arch/arm/mach-omap2/pm34xx.c +0 -0
@@ -546,8 +546,10 @@ static void __init prcm_setup_regs(void)
 	/* Clear any pending PRCM interrupts */
 	omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
arch/arm/mach-omap2/pm34xx.c static void __init prcm_setup_regs(void) · line 555
Quoted 10 lines
arch/arm/mach-omap2/pm34xx.c +4 -2
 
-	if (omap3_has_iva())
-		omap3_iva_idle();
+	/*
+	 * We need to idle iva2_pwrdm even on am3703 with no iva2.
+	 */
+	omap3_iva_idle();
 
 	omap3_d2d_idle();
 }
[Kevin, Paul, some background: Tony discovered that the am3703 needs to have omap3_iva_idle() called even though its not supposed to have an IVA.]
This is potentially bad for other SoC's that don't have an IVA so I don't think its the way to go. My preference would be to set the OMAP3_HAS_IVA flag for the am3703 only since its the one with the bug. Maybe something in id.c:omap3xxx_check_features() but I don't see any existing way to check for an am3703 vs. other am37xx SoCs. Any ideas?
Quoted 5 lines
Quoted 1 line
Another option, I suppose, is a dts entry but I don't like that at all.
It seems that iva2_pwrdm is there for all omap3 even if OMAP3_HAS_IVA flag is unset. And if that's the case, iva2 clocks still need to be idled in all cases.
Ahh, this takes us to the "Great TI Docs Mystery" :) -- its basically impossible to tell because despite what their docs may say, the hardware can be quite different. I'm not sure how to proceed other than trial & error with as many different SoCs as we can find.
Quoted 3 lines
It's possible that not all steps in omap3_iva_idle() are needed though. I can debug further to see which part of the omap3_iva_idle() are needed.

Quoted 8 lines

Quoted 2 lines
Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with?
I have an am35xx which isn't supposed to have an IVA so I can test with it (although, I'm not sure how well the kernel works on the am35xx these days).
I'm a bit busy today but I'll try booting the am35xx tomorrow and if it comes up, see what I can figure out.

I think this issue is relevant to am3517 as you can see from this thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903
I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html

I have such a system running, so if you have any other patches/ideas to test, I would do it.

Yegor

Tony Lindgren

author maintainer

2013-05-16 18:35 UTC #5 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

Quoted 58 lines · Yegor Yefremov

Quoted 57 lines · Mark A. Greer
Quoted 39 lines · Tony Lindgren
Quoted 38 lines · Mark A. Greer
Quoted 16 lines · Tony Lindgren
Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists) changed PM to not access IVA registers on omaps that don't have them. Turns out we still need to idle iva2 as otherwise iva2_pwrdm will stay on and block deeper idle states.
Signed-off-by Tony Lindgren <[email protected]>
---
Paul & Kevin, do you have better ideas for fixing this?
arch/arm/mach-omap2/pm34xx.c +0 -0
@@ -546,8 +546,10 @@ static void __init prcm_setup_regs(void)
 	/* Clear any pending PRCM interrupts */
 	omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
arch/arm/mach-omap2/pm34xx.c static void __init prcm_setup_regs(void) · line 555
Quoted 10 lines
arch/arm/mach-omap2/pm34xx.c +4 -2
 
-	if (omap3_has_iva())
-		omap3_iva_idle();
+	/*
+	 * We need to idle iva2_pwrdm even on am3703 with no iva2.
+	 */
+	omap3_iva_idle();
 
 	omap3_d2d_idle();
 }
[Kevin, Paul, some background: Tony discovered that the am3703 needs to have omap3_iva_idle() called even though its not supposed to have an IVA.]
This is potentially bad for other SoC's that don't have an IVA so I don't think its the way to go. My preference would be to set the OMAP3_HAS_IVA flag for the am3703 only since its the one with the bug. Maybe something in id.c:omap3xxx_check_features() but I don't see any existing way to check for an am3703 vs. other am37xx SoCs. Any ideas?
Quoted 5 lines
Quoted 1 line
Another option, I suppose, is a dts entry but I don't like that at all.
It seems that iva2_pwrdm is there for all omap3 even if OMAP3_HAS_IVA flag is unset. And if that's the case, iva2 clocks still need to be idled in all cases.
Ahh, this takes us to the "Great TI Docs Mystery" :) -- its basically impossible to tell because despite what their docs may say, the hardware can be quite different. I'm not sure how to proceed other than trial & error with as many different SoCs as we can find.
Quoted 5 lines
It's possible that not all steps in omap3_iva_idle() are needed though. I can debug further to see which part of the omap3_iva_idle() are needed.
Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with?

Quoted 8 lines

Quoted 5 lines
I have an am35xx which isn't supposed to have an IVA so I can test with it (although, I'm not sure how well the kernel works on the am35xx these days).
I'm a bit busy today but I'll try booting the am35xx tomorrow and if it comes up, see what I can figure out.
I think this issue is relevant to am3517 as you can see from this thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903
I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html

OK sounds like Mark's patch as http://www.spinics.net/lists/arm-kernel/msg168865.html
is needed as a fix.

Quoted 1 line

I have such a system running, so if you have any other patches/ideas to test, I would do it.

Well I think my patch does not matter for am3517 as that one has iva2 while am3703 does not.

Regards,

Tony

Tony Lindgren

author maintainer

2013-05-16 18:54 UTC #6 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

Quoted 7 lines · Tony Lindgren

Quoted 3 lines · Yegor Yefremov
I think this issue is relevant to am3517 as you can see from this thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903
I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html
OK sounds like Mark's patch as http://www.spinics.net/lists/arm-kernel/msg168865.html
is needed as a fix.

Yegor, thinking about your boot issue more, I'm thinking that you have your board .init_time = omap3_secure_sync32k_timer_init, or some non-waking gpt timer. And that means the system won't wake to timer events.

The system should still wake to timer events even if you have no wake-up events configred, so Mark's patch probably does not fix the right issue for you.

Regards,

Tony

Mark A. Greer

2013-05-17 18:47 UTC #7 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

In reply to Tony Lindgren

Quoted 62 lines · Tony Lindgren

Quoted 61 lines · Yegor Yefremov
Quoted 60 lines · Mark A. Greer
Quoted 39 lines · Tony Lindgren
Quoted 38 lines · Mark A. Greer
Quoted 16 lines · Tony Lindgren
Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists) changed PM to not access IVA registers on omaps that don't have them. Turns out we still need to idle iva2 as otherwise iva2_pwrdm will stay on and block deeper idle states.
Signed-off-by Tony Lindgren <[email protected]>
---
Paul & Kevin, do you have better ideas for fixing this?
arch/arm/mach-omap2/pm34xx.c +0 -0
@@ -546,8 +546,10 @@ static void __init prcm_setup_regs(void)
 	/* Clear any pending PRCM interrupts */
 	omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
arch/arm/mach-omap2/pm34xx.c static void __init prcm_setup_regs(void) · line 555
Quoted 10 lines
arch/arm/mach-omap2/pm34xx.c +4 -2
 
-	if (omap3_has_iva())
-		omap3_iva_idle();
+	/*
+	 * We need to idle iva2_pwrdm even on am3703 with no iva2.
+	 */
+	omap3_iva_idle();
 
 	omap3_d2d_idle();
 }
[Kevin, Paul, some background: Tony discovered that the am3703 needs to have omap3_iva_idle() called even though its not supposed to have an IVA.]
This is potentially bad for other SoC's that don't have an IVA so I don't think its the way to go. My preference would be to set the OMAP3_HAS_IVA flag for the am3703 only since its the one with the bug. Maybe something in id.c:omap3xxx_check_features() but I don't see any existing way to check for an am3703 vs. other am37xx SoCs. Any ideas?
Quoted 5 lines
Quoted 1 line
Another option, I suppose, is a dts entry but I don't like that at all.
It seems that iva2_pwrdm is there for all omap3 even if OMAP3_HAS_IVA flag is unset. And if that's the case, iva2 clocks still need to be idled in all cases.
Ahh, this takes us to the "Great TI Docs Mystery" :) -- its basically impossible to tell because despite what their docs may say, the hardware can be quite different. I'm not sure how to proceed other than trial & error with as many different SoCs as we can find.
Quoted 5 lines
It's possible that not all steps in omap3_iva_idle() are needed though. I can debug further to see which part of the omap3_iva_idle() are needed.
Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with?
I have an am35xx which isn't supposed to have an IVA so I can test with it (although, I'm not sure how well the kernel works on the am35xx these days).

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
I'm a bit busy today but I'll try booting the am35xx tomorrow and if it comes up, see what I can figure out.
I think this issue is relevant to am3517 as you can see from this thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903
I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html
OK sounds like Mark's patch as http://www.spinics.net/lists/arm-kernel/msg168865.html
is needed as a fix.

FYI, that patch works (until recently, anyway) but is an unacceptable approach.

Quoted 4 lines

Quoted 1 line
I have such a system running, so if you have any other patches/ideas to test, I would do it.
Well I think my patch does not matter for am3517 as that one has iva2 while am3703 does not.

To make sure there is no confusion, the am3517 does NOT have an iva2.

Tony was misled by a boot log from an older kernel that didn't have the patch that unsets the IVA feature flag.

Aside: I have so far been unable to get my am3517evm to come up.

Mark
--

Mark A. Greer

2013-05-17 18:56 UTC #8 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

In reply to Yegor Yefremov

Quoted 9 lines · Yegor Yefremov

Quoted 8 lines · Mark A. Greer
Quoted 2 lines · Tony Lindgren
Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with?
I have an am35xx which isn't supposed to have an IVA so I can test with it (although, I'm not sure how well the kernel works on the am35xx these days).

Quoted 7 lines

Quoted 2 lines
I'm a bit busy today but I'll try booting the am35xx tomorrow and if it comes up, see what I can figure out.
I think this issue is relevant to am3517 as you can see from this thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903
I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html
I have such a system running, so if you have any other patches/ideas to test, I would do it.

Yegor, since I've so far been unable to get my am3517evm to fire up, can you play around with the 3517 to see if there appears to be iva registers that can be read/written to safely? In particular, can the code that idles the iva be run safely on an am3517?

Thanks,

Mark
--

Yegor Yefremov

2013-05-17 21:28 UTC #9 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

Quoted 16 lines · Mark A. Greer

Quoted 15 lines · Yegor Yefremov
Quoted 10 lines · Mark A. Greer
Quoted 2 lines · Tony Lindgren
Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with?
I have an am35xx which isn't supposed to have an IVA so I can test with it (although, I'm not sure how well the kernel works on the am35xx these days).
I'm a bit busy today but I'll try booting the am35xx tomorrow and if it comes up, see what I can figure out.
I think this issue is relevant to am3517 as you can see from this thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903
I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html

Quoted 6 lines

Quoted 1 line
I have such a system running, so if you have any other patches/ideas to test, I would do it.
Yegor, since I've so far been unable to get my am3517evm to fire up, can you play around with the 3517 to see if there appears to be iva registers that can be read/written to safely? In particular, can the code that idles the iva be run safely on an am3517?

I'll look into this next week. am3517 and IVA seems to be a really big mystery. In the TI forum will be stated, there is no IVA:
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/150961.aspx, but TRM has various appearances of IVA2 registers, but no real description/explanation of what is IVA and how to eat it.

Yegor

Tony Lindgren

author maintainer

2013-05-20 22:05 UTC #10 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

Quoted 24 lines · Yegor Yefremov

Quoted 16 lines · Mark A. Greer
Quoted 15 lines · Yegor Yefremov
Quoted 10 lines · Mark A. Greer
Quoted 2 lines · Tony Lindgren
Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with?
I have an am35xx which isn't supposed to have an IVA so I can test with it (although, I'm not sure how well the kernel works on the am35xx these days).
I'm a bit busy today but I'll try booting the am35xx tomorrow and if it comes up, see what I can figure out.
I think this issue is relevant to am3517 as you can see from this thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903
I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html
Quoted 6 lines
Quoted 1 line
I have such a system running, so if you have any other patches/ideas to test, I would do it.
Yegor, since I've so far been unable to get my am3517evm to fire up, can you play around with the 3517 to see if there appears to be iva registers that can be read/written to safely? In particular, can the code that idles the iva be run safely on an am3517?

Quoted 5 lines

I'll look into this next week. am3517 and IVA seems to be a really big mystery. In the TI forum will be stated, there is no IVA:
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/150961.aspx, but TRM has various appearances of IVA2 registers, but no real description/explanation of what is IVA and how to eat it.

On 3703 it looks like the whole omap3_iva_idle() reset is needed, except for setting the iva2 bootmode to idle. So I'm planning to merge the following patch with just comments update this week unless somebody has a better fix in mind.

Regards,

Tony

From: Tony Lindgren <[email protected]>
Date: Tue, 14 May 2013 20:28:15 -0700
Subject: [PATCH] ARM: OMAP3: Fix iva2_pwrdm settings for 3703

It seems that the only part of the reset that may not be needed is the setting of the iva2 boot mode to idle. But as that register seems to be there and is harmless if no iva2 is on the SoC, it's probably safest to do the complete reset.

Signed-off-by Tony Lindgren <[email protected]>

arch/arm/mach-omap2/pm34xx.c +4 -2

@@ -546,8 +546,10 @@ static void __init prcm_setup_regs(void)
 	/* Clear any pending PRCM interrupts */
 	omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
 
-	if (omap3_has_iva())
-		omap3_iva_idle();
+	/*
+	 * We need to idle iva2_pwrdm even on am3703 with no iva2.
+	 */
+	omap3_iva_idle();
 
 	omap3_d2d_idle();
 }

Yegor Yefremov

2013-05-21 09:17 UTC #11 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

Quoted 31 lines · Tony Lindgren

Quoted 24 lines · Yegor Yefremov
Quoted 16 lines · Mark A. Greer
Quoted 15 lines · Yegor Yefremov
Quoted 10 lines · Mark A. Greer
Quoted 2 lines · Tony Lindgren
Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with?
I have an am35xx which isn't supposed to have an IVA so I can test with it (although, I'm not sure how well the kernel works on the am35xx these days).
I'm a bit busy today but I'll try booting the am35xx tomorrow and if it comes up, see what I can figure out.
I think this issue is relevant to am3517 as you can see from this thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903
I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html
Quoted 6 lines
Quoted 1 line
I have such a system running, so if you have any other patches/ideas to test, I would do it.
Yegor, since I've so far been unable to get my am3517evm to fire up, can you play around with the 3517 to see if there appears to be iva registers that can be read/written to safely? In particular, can the code that idles the iva be run safely on an am3517?
Quoted 5 lines
I'll look into this next week. am3517 and IVA seems to be a really big mystery. In the TI forum will be stated, there is no IVA:
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/150961.aspx, but TRM has various appearances of IVA2 registers, but no real description/explanation of what is IVA and how to eat it.

Quoted 4 lines

On 3703 it looks like the whole omap3_iva_idle() reset is needed, except for setting the iva2 bootmode to idle. So I'm planning to merge the following patch with just comments update this week unless somebody has a better fix in mind.

calling omap3_iva_idle() made no difference so far. I still can boot 3.10-rc2 with 'nohlt' and omap3_iva_idle() and vice versa, without 'nohlt' I cannot boot whether with or without calling omap3_iva_idle().

BTW Tony I've sent a patch to fix MUSB clock naming. Should I also make a recent including linux-usb mailing list or can we handle this internally on omap/arm list?

Yegor

Mark A. Greer

2013-05-21 15:56 UTC #12 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

In reply to Tony Lindgren

Quoted 62 lines · Tony Lindgren

Quoted 24 lines · Yegor Yefremov
Quoted 16 lines · Mark A. Greer
Quoted 15 lines · Yegor Yefremov
Quoted 10 lines · Mark A. Greer
Quoted 2 lines · Tony Lindgren
Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with?
I have an am35xx which isn't supposed to have an IVA so I can test with it (although, I'm not sure how well the kernel works on the am35xx these days).
I'm a bit busy today but I'll try booting the am35xx tomorrow and if it comes up, see what I can figure out.
I think this issue is relevant to am3517 as you can see from this thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903
I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html
Quoted 6 lines
Quoted 1 line
I have such a system running, so if you have any other patches/ideas to test, I would do it.
Yegor, since I've so far been unable to get my am3517evm to fire up, can you play around with the 3517 to see if there appears to be iva registers that can be read/written to safely? In particular, can the code that idles the iva be run safely on an am3517?
Quoted 5 lines
I'll look into this next week. am3517 and IVA seems to be a really big mystery. In the TI forum will be stated, there is no IVA:
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/150961.aspx, but TRM has various appearances of IVA2 registers, but no real description/explanation of what is IVA and how to eat it.
On 3703 it looks like the whole omap3_iva_idle() reset is needed, except for setting the iva2 bootmode to idle. So I'm planning to merge the following patch with just comments update this week unless somebody has a better fix in mind.
Regards,
Tony
From: Tony Lindgren <[email protected]>
Date: Tue, 14 May 2013 20:28:15 -0700
Subject: [PATCH] ARM: OMAP3: Fix iva2_pwrdm settings for 3703
Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists) changed PM to not access IVA registers on omaps that don't have them. Turns out we still need to idle iva2 as otherwise iva2_pwrdm will stay on and block deeper idle states.
It seems that the only part of the reset that may not be needed is the setting of the iva2 boot mode to idle. But as that register seems to be there and is harmless if no iva2 is on the SoC, it's probably safest to do the complete reset.
Signed-off-by Tony Lindgren <[email protected]>
arch/arm/mach-omap2/pm34xx.c +0 -0
@@ -546,8 +546,10 @@ static void __init prcm_setup_regs(void)
 	/* Clear any pending PRCM interrupts */
 	omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);

arch/arm/mach-omap2/pm34xx.c static void __init prcm_setup_regs(void) · line 555

Quoted 10 lines

arch/arm/mach-omap2/pm34xx.c +4 -2

 
-	if (omap3_has_iva())
-		omap3_iva_idle();
+	/*
+	 * We need to idle iva2_pwrdm even on am3703 with no iva2.
+	 */
+	omap3_iva_idle();
 
 	omap3_d2d_idle();
 }

I think that patch will work fine. That's basically how that piece of code was before a819c4f16 (ARM: OMAP3: PM: Only access IVA if one exists) which ran fine on the am3517 and am3703 (AFAIK). In addition, Yegor has verified that the am3517 still works so...

Acked-by Mark A. Greer <[email protected]>

Kevin Hilman

2013-05-21 18:20 UTC #13 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

In reply to Tony Lindgren

Quoted 51 lines · Tony Lindgren

Quoted 25 lines · Yegor Yefremov
Quoted 17 lines · Mark A. Greer
Quoted 16 lines · Yegor Yefremov
Quoted 10 lines · Mark A. Greer
Quoted 2 lines · Tony Lindgren
Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with?
I have an am35xx which isn't supposed to have an IVA so I can test with it (although, I'm not sure how well the kernel works on the am35xx these days).
I'm a bit busy today but I'll try booting the am35xx tomorrow and if it comes up, see what I can figure out.
I think this issue is relevant to am3517 as you can see from this
thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903
I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html
Quoted 6 lines
Quoted 1 line
I have such a system running, so if you have any other patches/ideas to test, I would do it.
Yegor, since I've so far been unable to get my am3517evm to fire up, can you play around with the 3517 to see if there appears to be iva registers that can be read/written to safely? In particular, can the code that idles the iva be run safely on an am3517?
Quoted 5 lines
I'll look into this next week. am3517 and IVA seems to be a really big mystery. In the TI forum will be stated, there is no IVA:
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/150961.aspx, but TRM has various appearances of IVA2 registers, but no real description/explanation of what is IVA and how to eat it.
On 3703 it looks like the whole omap3_iva_idle() reset is needed, except for setting the iva2 bootmode to idle. So I'm planning to merge the following patch with just comments update this week unless somebody has a better fix in mind.
Regards,
Tony
From: Tony Lindgren <[email protected]>
Date: Tue, 14 May 2013 20:28:15 -0700
Subject: [PATCH] ARM: OMAP3: Fix iva2_pwrdm settings for 3703
Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists) changed PM to not access IVA registers on omaps that don't have them. Turns out we still need to idle iva2 as otherwise iva2_pwrdm will stay on and block deeper idle states.

Quoted 6 lines

It seems that the only part of the reset that may not be needed is the setting of the iva2 boot mode to idle. But as that register seems to be there and is harmless if no iva2 is on the SoC, it's probably safest to do the complete reset.
Signed-off-by Tony Lindgren <[email protected]>

Acked-by Kevin Hilman <[email protected]>

Quoted 15 lines

arch/arm/mach-omap2/pm34xx.c +4 -2

@@ -546,8 +546,10 @@ static void __init prcm_setup_regs(void)
 	/* Clear any pending PRCM interrupts */
 	omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
 
-	if (omap3_has_iva())
-		omap3_iva_idle();
+	/*
+	 * We need to idle iva2_pwrdm even on am3703 with no iva2.
+	 */
+	omap3_iva_idle();
 
 	omap3_d2d_idle();
 }

Yegor Yefremov

2013-05-22 08:09 UTC #14 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

Quoted 53 lines · Kevin Hilman

Quoted 51 lines · Tony Lindgren
Quoted 25 lines · Yegor Yefremov
Quoted 17 lines · Mark A. Greer
Quoted 16 lines · Yegor Yefremov
Quoted 10 lines · Mark A. Greer
Quoted 2 lines · Tony Lindgren
Mark, do you have some omap3 with no iva (other than am3703) to test the idle states with?
I have an am35xx which isn't supposed to have an IVA so I can test with it (although, I'm not sure how well the kernel works on the am35xx these days).
I'm a bit busy today but I'll try booting the am35xx tomorrow and if it comes up, see what I can figure out.
I think this issue is relevant to am3517 as you can see from this
thread: http://thread.gmane.org/gmane.linux.ports.arm.omap/97903
I could boot only with your patch http://www.spinics.net/lists/arm-kernel/msg168865.html
Quoted 6 lines
Quoted 1 line
I have such a system running, so if you have any other patches/ideas to test, I would do it.
Yegor, since I've so far been unable to get my am3517evm to fire up, can you play around with the 3517 to see if there appears to be iva registers that can be read/written to safely? In particular, can the code that idles the iva be run safely on an am3517?
Quoted 5 lines
I'll look into this next week. am3517 and IVA seems to be a really big mystery. In the TI forum will be stated, there is no IVA:
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/150961.aspx, but TRM has various appearances of IVA2 registers, but no real description/explanation of what is IVA and how to eat it.
On 3703 it looks like the whole omap3_iva_idle() reset is needed, except for setting the iva2 bootmode to idle. So I'm planning to merge the following patch with just comments update this week unless somebody has a better fix in mind.
Regards,
Tony
From: Tony Lindgren <[email protected]>
Date: Tue, 14 May 2013 20:28:15 -0700
Subject: [PATCH] ARM: OMAP3: Fix iva2_pwrdm settings for 3703
Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists) changed PM to not access IVA registers on omaps that don't have them. Turns out we still need to idle iva2 as otherwise iva2_pwrdm will stay on and block deeper idle states.

Quoted 8 lines

Quoted 6 lines
It seems that the only part of the reset that may not be needed is the setting of the iva2 boot mode to idle. But as that register seems to be there and is harmless if no iva2 is on the SoC, it's probably safest to do the complete reset.
Signed-off-by Tony Lindgren <[email protected]>
Acked-by Kevin Hilman <[email protected]>

Tested-by Yegor Yefremov <[email protected]>

Mark A. Greer

2013-05-17 21:05 UTC #15 lore raw

PATCH 1/1 ARM: OMAP3: Fix iva2_pwrdm settings for 3703

In reply to Mark A. Greer

Quoted 25 lines · Mark A. Greer

Quoted 24 lines · Tony Lindgren
Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists) changed PM to not access IVA registers on omaps that don't have them. Turns out we still need to idle iva2 as otherwise iva2_pwrdm will stay on and block deeper idle states.
Signed-off-by Tony Lindgren <[email protected]>
---
Paul & Kevin, do you have better ideas for fixing this?
arch/arm/mach-omap2/pm34xx.c +4 -2
@@ -546,8 +546,10 @@ static void __init prcm_setup_regs(void)
 	/* Clear any pending PRCM interrupts */
 	omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
 
-	if (omap3_has_iva())
-		omap3_iva_idle();
+	/*
+	 * We need to idle iva2_pwrdm even on am3703 with no iva2.
+	 */
+	omap3_iva_idle();
 

Quoted 8 lines

arch/arm/mach-omap2/pm34xx.c static void __init prcm_setup_regs(void) · line 555
Quoted 2 lines
arch/arm/mach-omap2/pm34xx.c +0 -0
 	omap3_d2d_idle();
 }
This is potentially bad for other SoC's that don't have an IVA so I don't think its the way to go. My preference would be to set the OMAP3_HAS_IVA flag for the am3703 only since its the one with the bug. Maybe something in id.c:omap3xxx_check_features() but I don't see any existing way to check for an am3703 vs. other am37xx SoCs. Any ideas?

As I think about it more, I may have been overly dramatic here.

Before the check that's being removed existed, omap3_iva_idle() was always called and nobody complained (including am3517). So, I'd still like to hear what Yegor can figure out but I have to believe that this patch is safe.

Mark
--