Re: [RFC] MPIC Bindings and Bindings for AMP Systems

[Meador Inge <meador_inge@mentor.com>]

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-msg@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-block@1400 {
       // Receives messages on registers 1 and 3.
       interrupts = <0xb1 2 0xb3 2>;
       receive-mask = <0xa>;
    };
Core 1:
    mpic-msgr-block@1400 {
       // Receives messages on register 2.
       interrupts = <0xb2 2>;
       receive-mask = <0x4>;
    };
Core 2:
    mpic-msgr-block@1400 {
       // Receives messages on register 0.
       interrupts = <0xb0 2>;
       receive-mask = <0x1>;
    };
Core 3:
    mpic-msgr-block@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