Skip to content

arm: omap: irq: cleanup INTC driver

Felipe Balbi linux-arm-kernel linux-omap 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest0 of 31 patches 0 repliesNew

Patches in v1 No applies recorded yet

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

Reviews trailers per patch

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

Read the v1 thread

Cover letter [RFT/RFC/PATCH 00/31] arm: omap: irq: cleanup INTC driver

Hi,

Quoted 8 lines · Felipe Balbi
Quoted 7 lines · Tony Lindgren
Quoted 6 lines · Felipe Balbi
Quoted 5 lines · Tony Lindgren
Quoted 2 lines · Felipe Balbi

Afte these patches, we're very close to being able
to move arch/arm/mach-omap2/irq.c to drivers/irqchip/irq-intc.c

That would be nice :)

added a few patches on top of my branch removing all arch/arm/ dependencies and moving the driver to drivers/irqchip/irq-omap-intc.c

Quoted 18 lines
Quoted 18 lines
Quoted 17 lines
Quoted 10 lines
Quoted 4 lines

Note that I have only boot tested these on AM335x Bone Black (with a small fix for fixed regulator which should be in the mailing list already), so I'd need help testing all other impacted platforms, specially when it comes to PM.

Sorry have not had much of a chance to test these with PM with all the fixes needed for omap3 DT mode. Tried testing these just now, but I get:

arch/arm/mach-omap2/board-generic.c:134: error: ?omap_intc_of_init? undeclared here (not in a function)

some of your other changes messed it up, I have not references of omap_intc_of_init() in my branch, because that's one of the things I'm dropping from DT-based boots.

Can you see which patch added a new omap_intc_of_init() call ? Or maybe tell me which branch I should rebase on top of ?

Quoted 8 lines
Quoted 5 lines

OK I tried against v3.13-rc4, it's the 3517 changes that caused it. Looks like that can be just removed, and then there are some trivial n8x0 merge conflicts. And n8x0 boots too.

But looks like omap3 off-idle hangs after hitting idle with these,

could it be we're racing between irq_chip.suspend() and hwmod's _disable() calls ?

So there are a few possibilities here (and having an OMAP3 platform at home would help a lot):

a. We're either killing INTC inside hwmod before irq_chip suspend is
called.

b. We could be calling irq_chip's resume before INTC is enabled again

c. We're loosing interrupts (??)

I might have a really old beagleboard somewhere around, if I do, I'll try to to boot it up again and track down this regression. Would be great to see these patches reaching mainline.

Quoted 4 lines
Quoted 2 lines

so a bit more work is needed. Maybe also rebase these against omap-for-v3.14/dt too?

Will do.

Rebased on top of omap-for-v3.14/omap3-board-removal. Patches are on my k.org tree:

git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git wip/omap-fix-intc

cheers

Signature · 8 lines
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140102/b38f0700/attachment.sig>

Read the cover letter in its thread