From: Daniele Alessandrelli <[email protected]>
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.
Cc: Rob Herring <[email protected]>
Cc: [email protected]
Reviewed-by: Mark Gross <[email protected]>
Signed-off-by: Daniele Alessandrelli <[email protected]>
Signed-off-by: Mark Gross <[email protected]>
---
.../bindings/soc/intel/intel,keembay-ipc.yaml | 45 +++++++++++++++++++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml
diff --git a/Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml b/Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml
new file mode 100644
index 000000000000..586fe73f4cd4
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2020 Intel Corporation
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/intel/intel,keembay-ipc.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Keem Bay IPC
+
+maintainers:
+ - Daniele Alessandrelli <[email protected]>
+
+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.
+
+properties:
+ compatible:
+ const: intel,keembay-ipc
+
+ memory-region:
+ items:
+ - description:
+ Reserved memory region used by the CPU to allocate IPC packets.
+ - description:
+ Reserved memory region used by the VPU to allocate IPC packets.
+
+ mboxes:
+ description: VPU IPC Mailbox.
+
+required:
+ - compatible
+ - memory-region
+ - mboxes
+
+additionalProperties: false
+
+examples:
+ - |
+ ipc {
+ compatible = "intel,keembay-ipc";
+ memory-region = <&ipc_cpu_reserved>, <&ipc_vpu_reserved>;
+ mboxes = <&vpu_ipc_mbox 0>;
+ };
--
2.17.1
On Fri, Feb 12, 2021 at 02:22:34PM -0800, [email protected] wrote:
> From: Daniele Alessandrelli <[email protected]>
>
> Add DT binding documentation for the Intel Keem Bay IPC driver, which
Bindings are for h/w blocks, not drivers. From a binding perspective, I
don't really care what the driver architecture for some OS looks like. I
continue to not understand what this h/w looks like. A block diagram
would help as would understanding what blocks have multiple clients
(mailboxes and xlink in particular).
> enables communication between the Computing Sub-System (CSS) and the
> Multimedia Sub-System (MSS) of the Intel Movidius SoC code named Keem
> Bay.
>
> Cc: Rob Herring <[email protected]>
> Cc: [email protected]
> Reviewed-by: Mark Gross <[email protected]>
> Signed-off-by: Daniele Alessandrelli <[email protected]>
> Signed-off-by: Mark Gross <[email protected]>
> ---
> .../bindings/soc/intel/intel,keembay-ipc.yaml | 45 +++++++++++++++++++
> 1 file changed, 45 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml
>
> diff --git a/Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml b/Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml
> new file mode 100644
> index 000000000000..586fe73f4cd4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2020 Intel Corporation
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/soc/intel/intel,keembay-ipc.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Keem Bay IPC
> +
> +maintainers:
> + - Daniele Alessandrelli <[email protected]>
> +
> +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.
> +
> +properties:
> + compatible:
> + const: intel,keembay-ipc
> +
> + memory-region:
> + items:
> + - description:
> + Reserved memory region used by the CPU to allocate IPC packets.
> + - description:
> + Reserved memory region used by the VPU to allocate IPC packets.
> +
> + mboxes:
> + description: VPU IPC Mailbox.
> +
> +required:
> + - compatible
> + - memory-region
> + - mboxes
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + ipc {
> + compatible = "intel,keembay-ipc";
> + memory-region = <&ipc_cpu_reserved>, <&ipc_vpu_reserved>;
> + mboxes = <&vpu_ipc_mbox 0>;
> + };
> --
> 2.17.1
>
On Fri, Mar 05, 2021 at 03:01:40PM -0600, Rob Herring wrote:
> On Fri, Feb 12, 2021 at 02:22:34PM -0800, [email protected] wrote:
> > From: Daniele Alessandrelli <[email protected]>
> >
> > Add DT binding documentation for the Intel Keem Bay IPC driver, which
>
> Bindings are for h/w blocks, not drivers. From a binding perspective, I
> don't really care what the driver architecture for some OS looks like. I
> continue to not understand what this h/w looks like. A block diagram
> would help as would understanding what blocks have multiple clients
> (mailboxes and xlink in particular).
I'm working to gather this info.
thanks!
--mark
>
> > enables communication between the Computing Sub-System (CSS) and the
> > Multimedia Sub-System (MSS) of the Intel Movidius SoC code named Keem
> > Bay.
> >
> > Cc: Rob Herring <[email protected]>
> > Cc: [email protected]
> > Reviewed-by: Mark Gross <[email protected]>
> > Signed-off-by: Daniele Alessandrelli <[email protected]>
> > Signed-off-by: Mark Gross <[email protected]>
> > ---
> > .../bindings/soc/intel/intel,keembay-ipc.yaml | 45 +++++++++++++++++++
> > 1 file changed, 45 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml b/Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml
> > new file mode 100644
> > index 000000000000..586fe73f4cd4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml
> > @@ -0,0 +1,45 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +# Copyright (C) 2020 Intel Corporation
> > +%YAML 1.2
> > +---
> > +$id: "http://devicetree.org/schemas/soc/intel/intel,keembay-ipc.yaml#"
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> > +
> > +title: Keem Bay IPC
> > +
> > +maintainers:
> > + - Daniele Alessandrelli <[email protected]>
> > +
> > +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.
> > +
> > +properties:
> > + compatible:
> > + const: intel,keembay-ipc
> > +
> > + memory-region:
> > + items:
> > + - description:
> > + Reserved memory region used by the CPU to allocate IPC packets.
> > + - description:
> > + Reserved memory region used by the VPU to allocate IPC packets.
> > +
> > + mboxes:
> > + description: VPU IPC Mailbox.
> > +
> > +required:
> > + - compatible
> > + - memory-region
> > + - mboxes
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + ipc {
> > + compatible = "intel,keembay-ipc";
> > + memory-region = <&ipc_cpu_reserved>, <&ipc_vpu_reserved>;
> > + mboxes = <&vpu_ipc_mbox 0>;
> > + };
> > --
> > 2.17.1
> >
On Mon, Mar 8, 2021 at 2:20 PM mark gross <[email protected]> wrote:
>
> On Fri, Mar 05, 2021 at 03:01:40PM -0600, Rob Herring wrote:
> > On Fri, Feb 12, 2021 at 02:22:34PM -0800, [email protected] wrote:
> > > From: Daniele Alessandrelli <[email protected]>
> > >
> > > Add DT binding documentation for the Intel Keem Bay IPC driver, which
> >
> > Bindings are for h/w blocks, not drivers. From a binding perspective, I
> > don't really care what the driver architecture for some OS looks like. I
> > continue to not understand what this h/w looks like. A block diagram
> > would help as would understanding what blocks have multiple clients
> > (mailboxes and xlink in particular).
> I'm working to gather this info.
>
Do I pick the mailbox related patches (and which ones exactly) ?
thanks.
On Mon, Apr 12, 2021 at 04:24:41PM -0500, Jassi Brar wrote:
> On Mon, Mar 8, 2021 at 2:20 PM mark gross <[email protected]> wrote:
> >
> > On Fri, Mar 05, 2021 at 03:01:40PM -0600, Rob Herring wrote:
> > > On Fri, Feb 12, 2021 at 02:22:34PM -0800, [email protected] wrote:
> > > > From: Daniele Alessandrelli <[email protected]>
> > > >
> > > > Add DT binding documentation for the Intel Keem Bay IPC driver, which
> > >
> > > Bindings are for h/w blocks, not drivers. From a binding perspective, I
> > > don't really care what the driver architecture for some OS looks like. I
> > > continue to not understand what this h/w looks like. A block diagram
> > > would help as would understanding what blocks have multiple clients
> > > (mailboxes and xlink in particular).
> > I'm working to gather this info.
> >
> Do I pick the mailbox related patches (and which ones exactly) ?
v6-0002-dt-bindings-mailbox-Add-Intel-VPU-IPC-mailbox-bin.patch
and
v6-0003-mailbox-vpu-ipc-mailbox-Add-support-for-Intel-VPU.patch
--mark
On Tue, Apr 20, 2021 at 03:14:59PM -0700, mark gross wrote:
> On Mon, Apr 12, 2021 at 04:24:41PM -0500, Jassi Brar wrote:
> > On Mon, Mar 8, 2021 at 2:20 PM mark gross <[email protected]> wrote:
> > >
> > > On Fri, Mar 05, 2021 at 03:01:40PM -0600, Rob Herring wrote:
> > > > On Fri, Feb 12, 2021 at 02:22:34PM -0800, [email protected] wrote:
> > > > > From: Daniele Alessandrelli <[email protected]>
> > > > >
> > > > > Add DT binding documentation for the Intel Keem Bay IPC driver, which
> > > >
> > > > Bindings are for h/w blocks, not drivers. From a binding perspective, I
> > > > don't really care what the driver architecture for some OS looks like. I
> > > > continue to not understand what this h/w looks like. A block diagram
> > > > would help as would understanding what blocks have multiple clients
> > > > (mailboxes and xlink in particular).
> > > I'm working to gather this info.
> > >
> > Do I pick the mailbox related patches (and which ones exactly) ?
>
> v6-0002-dt-bindings-mailbox-Add-Intel-VPU-IPC-mailbox-bin.patch
> and
> v6-0003-mailbox-vpu-ipc-mailbox-Add-support-for-Intel-VPU.patch
>
Sorry for the confusion and delay. It seems there are some internal requests
to change the name of this part of the VPU driver stack to avoid possible future
namespace collisions.
We will rename the vpu-ipc-mailbox with something more specific to KMB on the
next posting. That looks like will have to be against v5.13-rc1 at this point.
Sigh.
Thanks,
--mark
On Wed, Apr 21, 2021 at 8:55 AM mark gross <[email protected]> wrote:
>
> On Tue, Apr 20, 2021 at 03:14:59PM -0700, mark gross wrote:
> > On Mon, Apr 12, 2021 at 04:24:41PM -0500, Jassi Brar wrote:
> > > On Mon, Mar 8, 2021 at 2:20 PM mark gross <[email protected]> wrote:
> > > >
> > > > On Fri, Mar 05, 2021 at 03:01:40PM -0600, Rob Herring wrote:
> > > > > On Fri, Feb 12, 2021 at 02:22:34PM -0800, [email protected] wrote:
> > > > > > From: Daniele Alessandrelli <[email protected]>
> > > > > >
> > > > > > Add DT binding documentation for the Intel Keem Bay IPC driver, which
> > > > >
> > > > > Bindings are for h/w blocks, not drivers. From a binding perspective, I
> > > > > don't really care what the driver architecture for some OS looks like. I
> > > > > continue to not understand what this h/w looks like. A block diagram
> > > > > would help as would understanding what blocks have multiple clients
> > > > > (mailboxes and xlink in particular).
> > > > I'm working to gather this info.
> > > >
> > > Do I pick the mailbox related patches (and which ones exactly) ?
> >
> > v6-0002-dt-bindings-mailbox-Add-Intel-VPU-IPC-mailbox-bin.patch
> > and
> > v6-0003-mailbox-vpu-ipc-mailbox-Add-support-for-Intel-VPU.patch
> >
> Sorry for the confusion and delay. It seems there are some internal requests
> to change the name of this part of the VPU driver stack to avoid possible future
> namespace collisions.
>
> We will rename the vpu-ipc-mailbox with something more specific to KMB on the
> next posting. That looks like will have to be against v5.13-rc1 at this point.
> Sigh.
>
Ok, I will dequeue the patches.
-j
On Wed, 2021-04-21 at 09:05 -0500, Jassi Brar wrote:
> On Wed, Apr 21, 2021 at 8:55 AM mark gross <[email protected]> wrote:
> > On Tue, Apr 20, 2021 at 03:14:59PM -0700, mark gross wrote:
> > > On Mon, Apr 12, 2021 at 04:24:41PM -0500, Jassi Brar wrote:
> > > > On Mon, Mar 8, 2021 at 2:20 PM mark gross <[email protected]> wrote:
> > > > > On Fri, Mar 05, 2021 at 03:01:40PM -0600, Rob Herring wrote:
> > > > > > On Fri, Feb 12, 2021 at 02:22:34PM -0800, [email protected] wrote:
> > > > > > > From: Daniele Alessandrelli <[email protected]>
> > > > > > >
> > > > > > > Add DT binding documentation for the Intel Keem Bay IPC driver, which
> > > > > >
> > > > > > Bindings are for h/w blocks, not drivers. From a binding perspective, I
> > > > > > don't really care what the driver architecture for some OS looks like. I
> > > > > > continue to not understand what this h/w looks like. A block diagram
> > > > > > would help as would understanding what blocks have multiple clients
> > > > > > (mailboxes and xlink in particular).
> > > > > I'm working to gather this info.
> > > > >
> > > > Do I pick the mailbox related patches (and which ones exactly) ?
> > >
> > > v6-0002-dt-bindings-mailbox-Add-Intel-VPU-IPC-mailbox-bin.patch
> > > and
> > > v6-0003-mailbox-vpu-ipc-mailbox-Add-support-for-Intel-VPU.patch
> > >
> > Sorry for the confusion and delay. It seems there are some internal requests
> > to change the name of this part of the VPU driver stack to avoid possible future
> > namespace collisions.
> >
> > We will rename the vpu-ipc-mailbox with something more specific to KMB on the
> > next posting. That looks like will have to be against v5.13-rc1 at this point.
> > Sigh.
> >
> Ok, I will dequeue the patches.
I actually have the renamed driver ready (the new name is keembay-ipc-
mailbox, to align it with the other drivers in the series).
Jassi, I can send the two updated patches as a separate patchset if you
have time to re-review them and, in case pick them. Would that be okay
with you? Or is it too late for that?
>
> -j