[PATCH v3 02/22] dt-bindings: arm: add support for ARM System Control and Management Interface(SCMI) protocol

[Sudeep Holla]

On 05/10/17 14:20, Jassi Brar wrote:
> On Wed, Oct 4, 2017 at 5:35 AM, Arnd Bergmann <arnd at arndb.de> wrote:
>> On Wed, Oct 4, 2017 at 1:07 PM, Sudeep Holla <sudeep.holla at arm.com> wrote:
>>> On 04/10/17 11:50, Arnd Bergmann wrote:
>>>> On Thu, Sep 28, 2017 at 3:11 PM, Sudeep Holla <sudeep.holla at arm.com> wrote:
> 
>>
>>>>> +- shmem : List of phandle pointing to the shared memory(SHM) area as per
>>>>> +         generic mailbox client binding.
>>>>> +
>>>>> +See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
>>>>> +about the generic mailbox controller and client driver bindings.
>>>>> +
>>>>> +The mailbox is the only permitted method of calling the SCMI firmware.
>>>>> +Mailbox doorbell is used as a mechanism to alert the presence of a
>>>>> +messages and/or notification.
>>>>
>>>> This looks odd: why not make the message itself part of the mailbox
>>>> protocol here, and leave the shmem as a implementation detail of the
>>>> mailbox driver?
>>>>
>>>
>>> I am not sure if I follow you here. But generally shmem can be memory
>>> carved out of anything in the system and it's dependent on the protocol
>>> and the remote firmware rather than the mailbox hardware itself.
>>
>> I think the problem is the way we use the mailbox API in Linux, which
>> is completely abstract at the moment: it could be a pure doorbell, a
>> single-register for a data, some structured memory, or a
>> variable-length message. The assumption today is that the mailbox
>> user and the mailbox driver agree on the interpretation of that
>> void pointer.
>>
> The way controllers and remote firmwares are paired there is no other
> way to write reusable code.
> 
>> This breaks down here, as you require the message to be a
>> variable-length message in a fixed physical location, but assume that
>> the mailbox serves only as a doorbell.
>>
> That is a valid usecase, already supported. There's an optional
> callback provided by the api to fill SHMEM
> mbox_chan->mbox_client->tx_prepare()
> 

Thanks, I missed to mention this earlier. But the point here is to avoid
the shim layer with each protocol for most common use case like doorbell.

But what I understood from Arnd's suggestion is to have another API
which just *sends signal* _rather_than_ *send data" to identify between
the two.
-- 
Regards,
Sudeep