Re: [PATCHv9 2/4] mailbox: Introduce framework for mailbox

On 01/08/14 13:28, Jassi Brar wrote:

On 1 August 2014 15:09, Sudeep Holla [off-list ref] wrote:

quoted

On 31/07/14 18:58, Jassi Brar wrote:

quoted

quoted

quoted

Probably this is discussed already, but again I missed to find it
in archives, so asking here. If the protocol has some payload associated
with the message and controller expects it to be in place before calling
send_data, we essentially end up not using this queue at all by waiting
in the protocol layer(may be in it's own queue)

Why essentially?
    The 'data' is a void *  i.o.w the packet format is a completely
internal understanding between a controller and a client. The 'data'
can point to a copy of payload that the controller driver sets up in
the shared payload region as the first thing in send_data() callback.
OR, like my 'server' type platform, where the access is serialized to
the shared payload region.

Yes that's exactly what I have now. But based on your driver I thought
that the shared memory should not be associated with the mailbox controller
and should be completely handled in the protocol/client.

Also to handle async packet from remote, controller has to pass shared
memory pointer always to the client to read the data as the buffer won't
to ready in such case. So I thought it's good idea to handle shared memory
completely in client/protocol.

Again ur platform has the freedom. The async client should have a free
packet to copy the data as soon as it arrives.
My platform divides the SHM into two parts - one for each direction.

I understand that, but I wanted to know what's the general
recommendation for mailbox controller drivers. Do they need to be
associated with the shared memory or is it left the protocol ?

The main reason I am asking is that the MHU driver you had didn't
deal with any shared memory. That's fine and if we want to make that
common/generic we need to know if we are going to handle shared
memory in there or leave it to client/protocol implementations.

Regards.
Sudeep