Skip to content

OMAP3+: PRCM chain handler

Kevin Hilman linux-arm-kernel linux-omap 3 versions – New

Get series with b4
b4 am [email protected]

Versions newest first · linked by author and title

  1. v12 Latest posting 2/20 of 9 patches 0 repliesNew
  2. v12 posting 1/20 of 9 patches 0 repliesSuperseded
  3. v110 of 8 patches 0 repliesSuperseded

Patches in v12 posting 2/2 No applies recorded yet

None of the 9 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v12 yet.

Read the v12 thread

Cover letter [PATCHv12 0/9] OMAP3+: PRCM chain handler
Quoted 31 lines · Vaibhav

Hi Kevin,

On Tue, Jan 10, 2012 at 06:49:52, Hilman, Kevin wrote:
[...]

Quoted 27 lines
Quoted 8 lines

1. IO and wakeup events are not supported on AM33XX. Since cpu_is_34xx() holds true for AM33XX I ended up adding a !cpu_is_am33xx() check in omap3xxx_prcm_init() to bypass the chain handler registration.

Without such a check we were seeing a crash in USB since USB_CLKCTRL on AM33XX just happens to be at the IRQENABLE_MPU_OFFSET of OMAP3. Hope such cpu_is_*() checks are acceptable.

We try to avoid them, especially when we already have existing feature flag for IO wakeups.

Does something like (completely untested) patch below work for you?

Of course, that implies that that feature flag is initialized correctly for AM33xx.

Kevin

arch/arm/mach-omap2/prm2xxx_3xxx.c +0 -0
index c1c4d86..87451d9 100644
@@ -302,7 +302,7 @@ void omap3xxx_prm_restore_irqen(u32 *saved_mask)
Quoted 12 lines

arch/arm/mach-omap2/prm2xxx_3xxx.c void omap3xxx_prm_restore_irqen(u32 *saved_mask) · line 308

Quoted 8 lines
arch/arm/mach-omap2/prm2xxx_3xxx.c +1 -1
 static int __init omap3xxx_prcm_init(void)
 {
-	if (cpu_is_omap34xx())
+	if (cpu_is_omap34xx() && omap3_has_io_wakeup())
 		return omap_prcm_register_chain_handler(&omap3_prcm_irq_setup);
 	return 0;
 }

I'll try this out once we have feature flag initialized on AM33xx. Can the cpu_is_omap34xx() check be completely dropped in that case? Or is there some other reason for retaining it?

The reason it is there is because that function is called from an initcall. By default, the kernel builds in support for OMAP2/3/4, so that initcall will get called on every SoC. Since it should only happen for OMAP3, the cpu_is_ check is used.

Kevin

Read the cover letter in its thread