ARM: AM33xx: hwmod: Add INIT_NO_IDLE flag for debugss hwmod

PATCH New Lokesh Vutla 2 participants 5 messages Apr 9, 2014 – May 7, 2014

Subsystems (4)

Arm (32-bit) Arm sub-architectures OMAP2+ support OMAP hwmod data

lore

Share & tools

lore

Lokesh Vutla

author

2014-04-09 05:47 UTC #0 lore raw

PATCH 1/1 ARM: AM33xx: hwmod: Add INIT_NO_IDLE flag for debugss hwmod

During boot, when hwmod tries to cut clocks for debugss it always gets stuck in transition state and throws the following warning:

[    0.139581] omap_hwmod: debugss: _wait_target_disable failed

As per the information provided by folks, clocks to debugss cannot be cut. So adding HWMOD_INIT_NO_IDLE flag to debugss hwmod.

Signed-off-by Lokesh Vutla <[email protected]>

---
Tested on BeagleBone Black.

 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |    1 +
 1 file changed, 1 insertion(+)

arch/arm/mach-omap2/omap_hwmod_33xx_data.c +1 -0

index 6b406ca..ec18ce0 100644
@@ -222,6 +222,7 @@ static struct omap_hwmod am33xx_debugss_hwmod = {
 	.name		= "debugss",
 	.class		= &am33xx_debugss_hwmod_class,
 	.clkdm_name	= "l3_aon_clkdm",
+	.flags		= HWMOD_INIT_NO_IDLE,
 	.main_clk	= "trace_clk_div_ck",
 	.prcm		= {
 		.omap4	= {

Signature · 1 line

1.7.9.5

Paul Walmsley

maintainer

2014-04-11 18:00 UTC #1 lore raw

PATCH 1/1 ARM: AM33xx: hwmod: Add INIT_NO_IDLE flag for debugss hwmod

Quoted 9 lines · Lokesh Vutla

During boot, when hwmod tries to cut clocks for debugss it always gets stuck in transition state and throws the following warning:
[    0.139581] omap_hwmod: debugss: _wait_target_disable failed
As per the information provided by folks, clocks to debugss cannot be cut. So adding HWMOD_INIT_NO_IDLE flag to debugss hwmod.
Signed-off-by Lokesh Vutla <[email protected]>

Thanks, queued for v3.15-rc.

- Paul

Paul Walmsley

maintainer

2014-04-11 18:09 UTC #2 lore raw

PATCH 1/1 ARM: AM33xx: hwmod: Add INIT_NO_IDLE flag for debugss hwmod

Quoted 5 lines · Paul Walmsley

Quoted 3 lines · Lokesh Vutla
During boot, when hwmod tries to cut clocks for debugss it always gets stuck in transition state and throws the following warning:

Quoted 8 lines

Quoted 6 lines
[    0.139581] omap_hwmod: debugss: _wait_target_disable failed
As per the information provided by folks, clocks to debugss cannot be cut. So adding HWMOD_INIT_NO_IDLE flag to debugss hwmod.
Signed-off-by Lokesh Vutla <[email protected]>
Thanks, queued for v3.15-rc.

Hmmm. On second thought, this doesn't look like the right fix. Could you please comment on the issues raised here:

https://patchwork.kernel.org/patch/2212111/

Looks to me like there should be at least one device driver, either for the entire DEBUGSS, or for the individual IP blocks inside the DEBUGSS.

Dropping this patch for now.

- Paul

Lokesh Vutla

author

2014-04-14 08:29 UTC #3 lore raw

PATCH 1/1 ARM: AM33xx: hwmod: Add INIT_NO_IDLE flag for debugss hwmod

Hi Paul,

Quoted 12 lines · Paul Walmsley

Quoted 10 lines · Paul Walmsley
Quoted 8 lines · Lokesh Vutla
During boot, when hwmod tries to cut clocks for debugss it always gets stuck in transition state and throws the following warning:
[    0.139581] omap_hwmod: debugss: _wait_target_disable failed
As per the information provided by folks, clocks to debugss cannot be cut. So adding HWMOD_INIT_NO_IDLE flag to debugss hwmod.

Quoted 8 lines

Quoted 3 lines
Quoted 1 line
Signed-off-by Lokesh Vutla <[email protected]>
Thanks, queued for v3.15-rc.
Hmmm. On second thought, this doesn't look like the right fix. Could you please comment on the issues raised here:
https://patchwork.kernel.org/patch/2212111/

Yes, I initially created a driver for enabling and disabling clocks for DEBUGSS. But I always see that DEBUGSS is always stuck in transition whenever clocks are cut to DEBUGSS.
During boot also when hwmod tries to cut clocks the following warning comes:

  [    0.139581] omap_hwmod: debugss: _wait_target_disable failed.

As confirmed by the hardware team that this is a bug in silicon that clocks cannot be cut to DEBUGSS.
So I am just adding HWMOD_INIT_NO_IDLE flag to debugss hwmod.

I have also tested suspend-resume with $subject patch with TI internal tree.

Please let me know if I am not clear.

Thanks and regards,
Lokesh

Quoted 9 lines

Looks to me like there should be at least one device driver, either for the entire DEBUGSS, or for the individual IP blocks inside the DEBUGSS.
Dropping this patch for now.
- Paul

Paul Walmsley

maintainer

2014-05-07 23:55 UTC #4 lore raw

PATCH 1/1 ARM: AM33xx: hwmod: Add INIT_NO_IDLE flag for debugss hwmod

Hi Lokesh

Quoted 27 lines · Lokesh Vutla

Quoted 12 lines · Paul Walmsley
Quoted 10 lines · Paul Walmsley
Quoted 8 lines · Lokesh Vutla
During boot, when hwmod tries to cut clocks for debugss it always gets stuck in transition state and throws the following warning:
[    0.139581] omap_hwmod: debugss: _wait_target_disable failed
As per the information provided by folks, clocks to debugss cannot be cut. So adding HWMOD_INIT_NO_IDLE flag to debugss hwmod.
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
Signed-off-by Lokesh Vutla <[email protected]>
Thanks, queued for v3.15-rc.
Hmmm. On second thought, this doesn't look like the right fix. Could you please comment on the issues raised here:
https://patchwork.kernel.org/patch/2212111/
Yes, I initially created a driver for enabling and disabling clocks for DEBUGSS. But I always see that DEBUGSS is always stuck in transition whenever clocks are cut to DEBUGSS.
During boot also when hwmod tries to cut clocks the following warning comes:
  [    0.139581] omap_hwmod: debugss: _wait_target_disable failed.

Quoted 7 lines

As confirmed by the hardware team that this is a bug in silicon that clocks cannot be cut to DEBUGSS.
So I am just adding HWMOD_INIT_NO_IDLE flag to debugss hwmod.
I have also tested suspend-resume with $subject patch with TI internal tree.
Please let me know if I am not clear.

OK, here's my question. Does the DEBUGSS module correctly enter a low-power state when going to suspend, even when the DEBUGSS is still enabled? Or is it the case that we should still disable it in the hwmod code and simply skip the call to _wait_target_disable()?

If the former, then please repost your patch with some comments in the hwmod data to describe this case, and note that the module will still enter a low-power state appropriately when the MPUSS goes into standby (if that is indeed the behavior).

If the latter, then it seems like the right approach is to add a hwmod flag to indicate that we should still disable it, but not wait for the disable to complete.

I guess the most direct way to test this would be to pull out a ammeter and verify that the idle current is the same in both cases.

How does that sound?

- Paul