linux-kernel - Re: [PATCH 02/22] dt-bindings: Add bindings for Keem Bay IPC driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABb+yY1Qm4G5rHmRbt8Pyno8h4X6EqesLv1=ybup0fHJ+rnPww@mail.gmail.com>
Date:   Mon, 7 Dec 2020 14:31:37 -0600
From:   Jassi Brar <jassisinghbrar@...il.com>
To:     Daniele Alessandrelli <daniele.alessandrelli@...ux.intel.com>
Cc:     Rob Herring <robh@...nel.org>, mgross@...ux.intel.com,
        Daniele Alessandrelli <daniele.alessandrelli@...el.com>,
        markgross@...nel.org, "arnd@...db.de" <arnd@...db.de>, bp@...e.de,
        damien.lemoal@....com, Greg KH <gregkh@...uxfoundation.org>,
        Jonathan Corbet <corbet@....net>,
        Leonard Crestez <leonard.crestez@....com>,
        palmerdabbelt@...gle.com, paul.walmsley@...ive.com,
        Peng Fan <peng.fan@....com>, Shawn Guo <shawnguo@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Devicetree List <devicetree@...r.kernel.org>
Subject: Re: [PATCH 02/22] dt-bindings: Add bindings for Keem Bay IPC driver

On Mon, Dec 7, 2020 at 12:43 PM Daniele Alessandrelli
<daniele.alessandrelli@...ux.intel.com> wrote:
>
> Hi Rob,
>
> Thanks for the feedback.
>
> On Mon, 2020-12-07 at 10:01 -0600, Rob Herring wrote:
> > On Tue, Dec 01, 2020 at 02:34:51PM -0800, mgross@...ux.intel.com wrote:
> > > From: Daniele Alessandrelli <daniele.alessandrelli@...el.com>
> > >
> > > Add DT binding documentation for the Intel Keem Bay IPC driver, which
> > > enables communication between the Computing Sub-System (CSS) and the
> > > Multimedia Sub-System (MSS) of the Intel Movidius SoC code named Keem
> > > Bay.
> > >
>
> [cut]
>
> > > +
> > > +description:
> > > +  The Keem Bay IPC driver enables Inter-Processor Communication (IPC) with the
> > > +  Visual Processor Unit (VPU) embedded in the Intel Movidius SoC code named
> > > +  Keem Bay.
> >
> > Sounds like a mailbox.
>
> We did consider using the mailbox framework, but eventually decided
> against it; mainly because of the following two reasons:
>
> 1. The channel concept in the Mailbox framework is different than the
>    channel concept in Keem Bay IPC:
>
>    a. My understanding is that Mailbox channels are meant to be SW
>       representation of physical HW channels, while in Keem Bay IPC
>       channels are software abstractions to achieve communication
>       multiplexing over a single HW link
>
In mailbox api, that would be a physical channel shared between various clients.

>    b. Additionally, Keem Bay IPC has two different classes of channels
>       (high-speed channels and general-purpose channels) that need to
>       access the same HW link with different priorities.
>
If the priorities are hard (programmed into some register), you could
do that via dt during channel population.
If they are soft, that would be handled in the shared channel implementation.

> 2. The blocking / non-blocking TX behavior of mailbox channels is
>    defined at channel creation time (by the tx_block value of the
>    mailbox client passed to mbox_request_channel();
>
No, that is checked at mbox_send_message()

> my understanding
>    is that the tx_block value cannot be modified after the channel is
>    created),
>
Again no. If you don't queue more than one message at any time you can
change it between transfers. To be safe you can always change it
between channel release - request calls.

>  while in Keem Bay IPC the same channel can be used for
>    both blocking and non-blocking TX (behavior is controlled by the
>    timeout argument passed to keembay_ipc_send()).
>
> Having said that, I guess that it could be possible to create a Mailbox
> driver implementing the core communication mechanism used by the Keem
> Bay IPC and then build our API around it (basically having two
> drivers). But I'm not sure that would make the code simpler or easier
> to maintain. Any thoughts on this?
>
I think so. Most of KeemBay specific behaviour would be implemented in
the shared channel above the mailbox api.

cheers!