Thread (5 messages) 5 messages, 1 author, 2011-08-01
STALE5420d
Revisions (21)
  1. rfc [diff vs current]
  2. v2 [diff vs current]
  3. v2 [diff vs current]
  4. v2 [diff vs current]
  5. v2 [diff vs current]
  6. v3 [diff vs current]
  7. v3 [diff vs current]
  8. v4 [diff vs current]
  9. v5 [diff vs current]
  10. v6 [diff vs current]
  11. v7 [diff vs current]
  12. v8 [diff vs current]
  13. v8 [diff vs current]
  14. v8 [diff vs current]
  15. v8 [diff vs current]
  16. v9 [diff vs current]
  17. v9 [diff vs current]
  18. v10 current
  19. v11 [diff vs current]
  20. v11 [diff vs current]
  21. v11 [diff vs current]

[RFC PATCH v10 0/4] Consolidating GIC per-cpu interrupts

From: Marc Zyngier <hidden>
Date: 2011-08-01 17:04:16

The current GIC per-cpu interrupts (aka PPIs) suffer from a number of
problems:

- They use a completely separate scheme to handle the interrupts,
  mostly because the PPI concept doesn't really match the kernel view
  of an interrupt.
- PPIs can only be used by the timer code, unless we add more low-level
  assembly code.
- The local timer code can only be used by devices generating PPIs,
  and not SPIs.
- At least one platform (msm) has started implementing its own
  alternative scheme.
- Some low-level code gets duplicated, as usual...

As the previous solution which tried to map PPIs to normal interrupts
has been proved to be buggy, I've opted to a much simpler scheme
(based on Russell's input).

The proposed solution is to handle the interrupt using the same path
as SPIs, with a common handler for all PPIs. Each PPI can be requested
using gic_request_ppi(), similar to request_irq(). The local timer
code is updated to reflect these changes.

Patches against next-20110801, tested on PB11MP. As this patch series
is quite different from the previous one, I've dropped all previous
acks from platform maintainers.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help