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

[Sudeep Holla <sudeep.holla@arm.com>]

Hi Jassi,

Sorry for late response.

On 02/08/14 04:58, Jassi Brar wrote:
> On 1 August 2014 23:03, Sudeep Holla <sudeep.holla@arm.com> wrote:

[...]
>>
>> Sorry I have no intention to delay this getting merged(I too need it
>> ASAP) as long as the APIs can be extended if needed in future(which I
>> think should be).
>>
>> Now coming back to my original question: If the protocol/client manage
>> the SHM and assume there's some payload associated with a message and
>> controller expects it to be in place before calling send_data, then
>> how can you achieve this without blocking for one command to complete
>> before copying the payload for the next. If you wait in the protocol
>> to update payload before queueing the request, you end-up with no use of
>> Tx queue in mailbox.c
>>
> 1) When you say Client/Protocol manages the SHM, then they should be
> responsible for laying out the SHM with payloads. Not the controller
> driver.  (I hope you don't mean the prepare_data for the client,
> because that would mean even after submitting a packet for
> transmission the client has to respond to yet another call before the
> packet is actually put on the bus.)
>

Agreed even I don't think that's good idea, but ....

> 2) Considering ur example anyway ... Mailbox api queues "void *data"
> which could point to a payload structure on client's temporary buffer
> (like stack). When the packet's turn comes up, the controller driver
> may copy the payload data as the first thing in send_data() and then
> continue to trigger it as usual. Where does the client have to block?
>

That wouldn't help as controller has no idea where is your shared
memory, so it can't do anything with copied data. Anyway, it's better to
take up this when we hit this scenario.

Regards,
Sudeep