On 05/10/17 14:20, Jassi Brar wrote: > On Wed, Oct 4, 2017 at 5:35 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> On Wed, Oct 4, 2017 at 1:07 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: >>> On 04/10/17 11:50, Arnd Bergmann wrote: >>>> On Thu, Sep 28, 2017 at 3:11 PM, Sudeep Holla <sudeep.holla@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
