Thread (33 messages) 33 messages, 5 authors, 2011-07-11
DORMANTno replies

[PATCH v8 14/14] ARM: gic: add gic_ppi_map_on_cpu()

From: Marc Zyngier <hidden>
Date: 2011-07-11 12:36:27

On 11/07/11 12:38, Russell King - ARM Linux wrote:
On Mon, Jul 11, 2011 at 12:14:36PM +0100, Marc Zyngier wrote:
quoted
And that's exactly what it does:
http://www.mail-archive.com/devicetree-discuss at lists.ozlabs.org/msg05026.html

What I was trying to explain (and obviously failed to) is that the
_Linux_ DT _code_ will try to resolve the PPI number and convert it to a
_Linux_ IRQ number. Unless of course you don't encode it as an interrupt
at all, which seems to be what you're aiming for.
I'm not aiming for anything.  I'm trying to get you to fully understand
the issue I've raised with your patches.  So, let's try a new scenario
based on your statement above.

You have a device which happens to use a PPI.  You obtain its IRQ number
from DT, which tells you IRQ 9, because the DT information said PPI 2
CPU 1.  So you pass IRQ 9 into the IRQ request function, but as you're
running on CPU 3, you have no access to the hardware for IRQ 9.

Please describe in detail how, with your patches, PPI 2 CPU 1 gets enabled
rather than PPI 2 CPU 3 when IRQ 9 is requested.
You simply do not do that. You store the mapping for later use on the
right CPU. My code is buggy as I didn't think of the requesting thread
being preempted, but I never intended to do this sort of cross-CPU request.
-- 
Jazz is not dead. It just smells funny...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help