lkml.org 
[lkml]   [2017]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v3 02/22] dt-bindings: arm: add support for ARM System Control and Management Interface(SCMI) protocol
    From
    Date


    On 05/10/17 14:20, Jassi Brar wrote:
    > On Wed, Oct 4, 2017 at 5:35 AM, Arnd Bergmann <arnd@arndb.de> wrote:
    >> On Wed, Oct 4, 2017 at 1:07 PM, Sudeep Holla <sudeep.holla@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@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

    \
     
     \ /
      Last update: 2017-10-05 16:11    [W:4.469 / U:0.648 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site