Add the physical client ids and binding for Kaanapali platform. Physical
client IDs instead of virtual client IDs are used for qcom new platforms
in the Inter Process Communication Controller (IPCC) driver as virtual to
physical mapping logic is removed in HW.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
.../devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 +
include/dt-bindings/mailbox/qcom,kaanapali-ipcc.h | 58 ++++++++++++++++++++++
2 files changed, 59 insertions(+)
diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
index e5c423130db6..ee3fe093e3ca 100644
--- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
+++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
@@ -24,6 +24,7 @@ properties:
compatible:
items:
- enum:
+ - qcom,kaanapali-ipcc
- qcom,milos-ipcc
- qcom,qcs8300-ipcc
- qcom,qdu1000-ipcc
diff --git a/include/dt-bindings/mailbox/qcom,kaanapali-ipcc.h b/include/dt-bindings/mailbox/qcom,kaanapali-ipcc.h
new file mode 100644
index 000000000000..b6208ad155ad
--- /dev/null
+++ b/include/dt-bindings/mailbox/qcom,kaanapali-ipcc.h
@@ -0,0 +1,58 @@
+/* SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#ifndef __DT_BINDINGS_MAILBOX_IPCC_KAANAPALI_H
+#define __DT_BINDINGS_MAILBOX_IPCC_KAANAPALI_H
+
+/* Physical client IDs */
+#define IPCC_MPROC_AOP 0
+#define IPCC_MPROC_TZ 1
+#define IPCC_MPROC_MPSS 2
+#define IPCC_MPROC_LPASS 3
+#define IPCC_MPROC_SDC 4
+#define IPCC_MPROC_CDSP 5
+#define IPCC_MPROC_APSS 6
+#define IPCC_MPROC_SOCCP 13
+#define IPCC_MPROC_DCP 14
+#define IPCC_MPROC_SPSS 15
+#define IPCC_MPROC_TME 16
+#define IPCC_MPROC_WPSS 17
+
+#define IPCC_COMPUTE_L0_CDSP 2
+#define IPCC_COMPUTE_L0_APSS 3
+#define IPCC_COMPUTE_L0_GPU 4
+#define IPCC_COMPUTE_L0_CVP 8
+#define IPCC_COMPUTE_L0_CAM 9
+#define IPCC_COMPUTE_L0_CAM1 10
+#define IPCC_COMPUTE_L0_DCP 11
+#define IPCC_COMPUTE_L0_VPU 12
+#define IPCC_COMPUTE_L0_SOCCP 16
+
+#define IPCC_COMPUTE_L1_CDSP 2
+#define IPCC_COMPUTE_L1_APSS 3
+#define IPCC_COMPUTE_L1_GPU 4
+#define IPCC_COMPUTE_L1_CVP 8
+#define IPCC_COMPUTE_L1_CAM 9
+#define IPCC_COMPUTE_L1_CAM1 10
+#define IPCC_COMPUTE_L1_DCP 11
+#define IPCC_COMPUTE_L1_VPU 12
+#define IPCC_COMPUTE_L1_SOCCP 16
+
+#define IPCC_PERIPH_CDSP 2
+#define IPCC_PERIPH_APSS 3
+#define IPCC_PERIPH_PCIE0 4
+#define IPCC_PERIPH_PCIE1 5
+
+#define IPCC_FENCE_CDSP 2
+#define IPCC_FENCE_APSS 3
+#define IPCC_FENCE_GPU 4
+#define IPCC_FENCE_CVP 8
+#define IPCC_FENCE_CAM 8
+#define IPCC_FENCE_CAM1 10
+#define IPCC_FENCE_DCP 11
+#define IPCC_FENCE_VPU 20
+#define IPCC_FENCE_SOCCP 24
+
+#endif
--
2.25.1On Wed, Oct 29, 2025 at 01:15:09AM -0700, Jingyi Wang wrote: > Add the physical client ids and binding for Kaanapali platform. Physical > client IDs instead of virtual client IDs are used for qcom new platforms > in the Inter Process Communication Controller (IPCC) driver as virtual to > physical mapping logic is removed in HW. Happy to see the description of what changed wrt physical vs virtual client IDs, but you're leaving the task of figuring out how this explanation is applicable to the imagination of the reader. Nobody knows that the values in dt-bindings/mailbox/qcom-ipcc.h are "virtual client IDs", so it's not clear that you're trying to provide an explanation to why a new, platform-specific, header file is needed here. Change looks good, but please update the commit message. Regards, Bjorn > > Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> > --- > .../devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 + > include/dt-bindings/mailbox/qcom,kaanapali-ipcc.h | 58 ++++++++++++++++++++++ > 2 files changed, 59 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml > index e5c423130db6..ee3fe093e3ca 100644 > --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml > +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml > @@ -24,6 +24,7 @@ properties: > compatible: > items: > - enum: > + - qcom,kaanapali-ipcc > - qcom,milos-ipcc > - qcom,qcs8300-ipcc > - qcom,qdu1000-ipcc > diff --git a/include/dt-bindings/mailbox/qcom,kaanapali-ipcc.h b/include/dt-bindings/mailbox/qcom,kaanapali-ipcc.h > new file mode 100644 > index 000000000000..b6208ad155ad > --- /dev/null > +++ b/include/dt-bindings/mailbox/qcom,kaanapali-ipcc.h > @@ -0,0 +1,58 @@ > +/* SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */ > +/* > + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. > + */ > + > +#ifndef __DT_BINDINGS_MAILBOX_IPCC_KAANAPALI_H > +#define __DT_BINDINGS_MAILBOX_IPCC_KAANAPALI_H > + > +/* Physical client IDs */ > +#define IPCC_MPROC_AOP 0 > +#define IPCC_MPROC_TZ 1 > +#define IPCC_MPROC_MPSS 2 > +#define IPCC_MPROC_LPASS 3 > +#define IPCC_MPROC_SDC 4 > +#define IPCC_MPROC_CDSP 5 > +#define IPCC_MPROC_APSS 6 > +#define IPCC_MPROC_SOCCP 13 > +#define IPCC_MPROC_DCP 14 > +#define IPCC_MPROC_SPSS 15 > +#define IPCC_MPROC_TME 16 > +#define IPCC_MPROC_WPSS 17 > + > +#define IPCC_COMPUTE_L0_CDSP 2 > +#define IPCC_COMPUTE_L0_APSS 3 > +#define IPCC_COMPUTE_L0_GPU 4 > +#define IPCC_COMPUTE_L0_CVP 8 > +#define IPCC_COMPUTE_L0_CAM 9 > +#define IPCC_COMPUTE_L0_CAM1 10 > +#define IPCC_COMPUTE_L0_DCP 11 > +#define IPCC_COMPUTE_L0_VPU 12 > +#define IPCC_COMPUTE_L0_SOCCP 16 > + > +#define IPCC_COMPUTE_L1_CDSP 2 > +#define IPCC_COMPUTE_L1_APSS 3 > +#define IPCC_COMPUTE_L1_GPU 4 > +#define IPCC_COMPUTE_L1_CVP 8 > +#define IPCC_COMPUTE_L1_CAM 9 > +#define IPCC_COMPUTE_L1_CAM1 10 > +#define IPCC_COMPUTE_L1_DCP 11 > +#define IPCC_COMPUTE_L1_VPU 12 > +#define IPCC_COMPUTE_L1_SOCCP 16 > + > +#define IPCC_PERIPH_CDSP 2 > +#define IPCC_PERIPH_APSS 3 > +#define IPCC_PERIPH_PCIE0 4 > +#define IPCC_PERIPH_PCIE1 5 > + > +#define IPCC_FENCE_CDSP 2 > +#define IPCC_FENCE_APSS 3 > +#define IPCC_FENCE_GPU 4 > +#define IPCC_FENCE_CVP 8 > +#define IPCC_FENCE_CAM 8 > +#define IPCC_FENCE_CAM1 10 > +#define IPCC_FENCE_DCP 11 > +#define IPCC_FENCE_VPU 20 > +#define IPCC_FENCE_SOCCP 24 > + > +#endif > > -- > 2.25.1 > >
On 29/10/2025 16:16, Bjorn Andersson wrote: > On Wed, Oct 29, 2025 at 01:15:09AM -0700, Jingyi Wang wrote: >> Add the physical client ids and binding for Kaanapali platform. Physical >> client IDs instead of virtual client IDs are used for qcom new platforms >> in the Inter Process Communication Controller (IPCC) driver as virtual to >> physical mapping logic is removed in HW. > > Happy to see the description of what changed wrt physical vs virtual > client IDs, but you're leaving the task of figuring out how this > explanation is applicable to the imagination of the reader. > > Nobody knows that the values in dt-bindings/mailbox/qcom-ipcc.h are > "virtual client IDs", so it's not clear that you're trying to provide an > explanation to why a new, platform-specific, header file is needed here. > > Physical or virtual, standard expectation is that they are used by the driver. This does not happen here, so what do they exactly represent? Which part of SW ABI? Best regards, Krzysztof
On Wed, Oct 29, 2025 at 04:47:17PM +0100, Krzysztof Kozlowski wrote: > On 29/10/2025 16:16, Bjorn Andersson wrote: > > On Wed, Oct 29, 2025 at 01:15:09AM -0700, Jingyi Wang wrote: > >> Add the physical client ids and binding for Kaanapali platform. Physical > >> client IDs instead of virtual client IDs are used for qcom new platforms > >> in the Inter Process Communication Controller (IPCC) driver as virtual to > >> physical mapping logic is removed in HW. > > > > Happy to see the description of what changed wrt physical vs virtual > > client IDs, but you're leaving the task of figuring out how this > > explanation is applicable to the imagination of the reader. > > > > Nobody knows that the values in dt-bindings/mailbox/qcom-ipcc.h are > > "virtual client IDs", so it's not clear that you're trying to provide an > > explanation to why a new, platform-specific, header file is needed here. > > > > > > > Physical or virtual, standard expectation is that they are used by the > driver. This does not happen here, so what do they exactly represent? > Which part of SW ABI? > I was under the impression that they would be used only in DeviceTree source, and the driver simply uses the values it reads at runtime. But perhaps my memory is failing me, it's been a while since we discussed this internally. Either way, the commit message should document this, so I don't have to remember... Regards, Bjorn > Best regards, > Krzysztof
On 29/10/2025 17:15, Bjorn Andersson wrote: > On Wed, Oct 29, 2025 at 04:47:17PM +0100, Krzysztof Kozlowski wrote: >> On 29/10/2025 16:16, Bjorn Andersson wrote: >>> On Wed, Oct 29, 2025 at 01:15:09AM -0700, Jingyi Wang wrote: >>>> Add the physical client ids and binding for Kaanapali platform. Physical >>>> client IDs instead of virtual client IDs are used for qcom new platforms >>>> in the Inter Process Communication Controller (IPCC) driver as virtual to >>>> physical mapping logic is removed in HW. >>> >>> Happy to see the description of what changed wrt physical vs virtual >>> client IDs, but you're leaving the task of figuring out how this >>> explanation is applicable to the imagination of the reader. >>> >>> Nobody knows that the values in dt-bindings/mailbox/qcom-ipcc.h are >>> "virtual client IDs", so it's not clear that you're trying to provide an >>> explanation to why a new, platform-specific, header file is needed here. >>> >>> >> >> >> Physical or virtual, standard expectation is that they are used by the >> driver. This does not happen here, so what do they exactly represent? >> Which part of SW ABI? >> > > I was under the impression that they would be used only in DeviceTree > source, and the driver simply uses the values it reads at runtime. And uses them for what? What do the values mean for the driver, how does it use them? If I change some entry from "1" to "2" does Linux code behave differently? Best regards, Krzysztof
© 2016 - 2025 Red Hat, Inc.