On 01/03/2011 02:22 PM, Scott Wood wrote:
On Wed, 22 Dec 2010 23:58:09 -0600
Perhaps a something like this, with "doorbell" being a new standard
hw-independent service with its own binding:
msg1: mpic-...@1400 {
compatible = "fsl,mpic-v3.0-msg";
reg =<0x1400 0x200>;
interrupts<176 2 178 2>;
// We have message registers 0 and 2 for sending,
// and 1 and 3 for receiving.
// If absent, we own all message registers in this block.
fsl,mpic-msg-send-mask =<0x5>;
fsl,mpic-msg-receive-mask =<0xa>;
doorbell-controller;
// split into #doorbell-send-cells and #doorbell-receive-cells?
#doorbell-cells =<1>;
};
some-amp-protocol-thingy {
send-doorbells =<&msg1 0>; // generate messages on MSGR0
receive-doorbells =<&msg1 0>; // receive messages on MSGR1
};
some-other-amp-protocol-thingy {
send-doorbells =<&msg1 1>; // generate messages on MSGR2
receive-doorbells =<&msg1 1>; // receive messages on MSGR3
};
Doorbell capabilities such as passing a 32-bit message can be negotiated
between the drivers for the doorbell controller and the doorbell client.
After thinking about it a little more, I like the idea of having a
'receive-mask' to further partition the message register blocks. This
would also allow us to remove IRQs from the 'interrupts' property that
are not being used on a given node. As for the 'send-mask', why would
we want to block sending messages? It seems to me that it would be
reasonable to allow a node to send a message to any other node.
As an example, consider a four core system. Then we might have
something like (only relevant DTS bits shown):
Core 0:
mpic-msgr-bl...@1400 {
// Receives messages on registers 1 and 3.
interrupts = <0xb1 2 0xb3 2>;
receive-mask = <0xa>;
};
Core 1:
mpic-msgr-bl...@1400 {
// Receives messages on register 2.
interrupts = <0xb2 2>;
receive-mask = <0x4>;
};
Core 2:
mpic-msgr-bl...@1400 {
// Receives messages on register 0.
interrupts = <0xb0 2>;
receive-mask = <0x1>;
};
Core 3:
mpic-msgr-bl...@1400 {
// Receives no messages.
interrupts = <>;
};
Then the API usage, for say core 0, might look something like:
/* Core 0 */
mpic_msgr *reg0 = mpic_get(0);
mpic_msgr *reg1 = mpic_get(1);
assert(mpic_msgr_get(100) == NULL);
u32 value;
/* Send a message on register 0. */
assert(mpic_msgr_write(reg0, 12) == 0);
/* Send a message on register 1. */
assert(mpic_msgr_write(reg1, 12) == 0);
/* Attempt to read a message on register 0, but can't
since it is not owned. */
assert(mpic_msgr_read(reg0, &value) == -ENODEV);
/* Successfully read a message on register 1. */
assert(mpic_msgr_read(reg1, &value) == 0);
The API usage for other cores would look similar. As mentioned in
another thread, this will provide us with the low-level building blocks
and we can layer other protocols, such as the doorbell protocol, on top
later (if needed).
Hollis, how do you feel about this?
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
