Document the component used to boot SoCCP on Kaanapali SoC and add
compatible for Glymur SoCCP which could fallback to Kaanapali. Extend
the "qcom,smem-states", "qcom,smem-state-names" in the pas-common.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
.../remoteproc/qcom,kaanapali-soccp-pas.yaml | 154 +++++++++++++++++++++
.../bindings/remoteproc/qcom,pas-common.yaml | 6 +-
2 files changed, 159 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,kaanapali-soccp-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,kaanapali-soccp-pas.yaml
new file mode 100644
index 000000000000..ce18460a949f
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,kaanapali-soccp-pas.yaml
@@ -0,0 +1,154 @@
+# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,kaanapali-soccp-pas.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Kaanapali SoCCP Peripheral Authentication Service
+
+maintainers:
+ - Jingyi Wang <jingyi.wang@oss.qualcomm.com>
+
+description:
+ The SoC Control Processor (SoCCP) is a small RISC-V MCU that controls USB
+ Type-C, battery charging and various other functions on Qualcomm SoCs, somewhat
+ analogous to traditional PC Embedded Controllers. This document describes
+ the Peripheral Authentication Service that loads and boots firmware for SoCCP.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - qcom,glymur-soccp-pas
+ - const: qcom,kaanapali-soccp-pas
+ - enum:
+ - qcom,kaanapali-soccp-pas
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: XO clock
+
+ clock-names:
+ items:
+ - const: xo
+
+ power-domains:
+ items:
+ - description: CX power domain
+ - description: MX power domain
+
+ power-domain-names:
+ items:
+ - const: cx
+ - const: mx
+
+ firmware-name:
+ items:
+ - description: Firmware name of the SoC Control Processor
+ - description: Firmware name of the SoCCP Devicetree
+
+ memory-region:
+ items:
+ - description: Memory region for main Firmware authentication
+ - description: Memory region for Devicetree Firmware authentication
+
+ interrupts:
+ items:
+ - description: Watchdog interrupt
+ - description: Fatal interrupt
+ - description: Ready interrupt
+ - description: Handover interrupt
+ - description: Stop acknowledge interrupt
+ - description: Pong interrupt
+
+ interrupt-names:
+ items:
+ - const: wdog
+ - const: fatal
+ - const: ready
+ - const: handover
+ - const: stop-ack
+ - const: pong
+
+ qcom,smem-states:
+ minItems: 2
+ description: States used by the AP to signal the SoC Control Processor
+
+ qcom,smem-state-names:
+ minItems: 2
+ description: The names of the state bits used for SMP2P output
+
+required:
+ - compatible
+ - reg
+ - memory-region
+ - power-domains
+ - power-domain-names
+
+allOf:
+ - $ref: /schemas/remoteproc/qcom,pas-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #define IPCC_MPROC_SOCCP
+
+ remoteproc@d00000 {
+ compatible = "qcom,kaanapali-soccp-pas";
+ reg = <0x00d00000 0x200000>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ interrupts-extended = <&intc GIC_SPI 167 IRQ_TYPE_EDGE_RISING>,
+ <&soccp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&soccp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&soccp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&soccp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+ <&soccp_smp2p_in 9 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog",
+ "fatal",
+ "ready",
+ "handover",
+ "stop-ack",
+ "pong";
+
+ memory-region = <&soccp_mem>,
+ <&soccp_dtb_mem_mem>;
+
+ firmware-name = "qcom/kaanapali/soccp.mbn",
+ "qcom/kaanapali/soccp_dtb.mbn";
+
+ power-domains = <&rpmhpd RPMHPD_CX>,
+ <&rpmhpd RPMHPD_MX>;
+ power-domain-names = "cx",
+ "mx";
+
+ qcom,smem-states = <&soccp_smp2p_out 0>,
+ <&soccp_smp2p_out 8>;
+ qcom,smem-state-names = "stop",
+ "ping";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_MPROC_SOCCP
+ IPCC_MPROC_SIGNAL_GLINK_QMP
+ IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_MPROC_SOCCP
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "soccp";
+ qcom,remote-pid = <19>;
+
+ /* ... */
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
index dc5a9981c12c..e81ef400555a 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
@@ -46,13 +46,17 @@ properties:
qcom,smem-states:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: States used by the AP to signal the Hexagon core
+ minItems: 1
items:
- - description: Stop the modem
+ - description: Stop the remoteproc
+ - description: ping the remoteproc
qcom,smem-state-names:
description: The names of the state bits used for SMP2P output
+ minItems: 1
items:
- const: stop
+ - const: ping
smd-edge:
$ref: /schemas/remoteproc/qcom,smd-edge.yaml#
--
2.25.1On Tue, Mar 10, 2026 at 03:03:20AM -0700, Jingyi Wang wrote: > Document the component used to boot SoCCP on Kaanapali SoC and add > compatible for Glymur SoCCP which could fallback to Kaanapali. Extend > the "qcom,smem-states", "qcom,smem-state-names" in the pas-common. > > Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> > --- > .../remoteproc/qcom,kaanapali-soccp-pas.yaml | 154 +++++++++++++++++++++ > .../bindings/remoteproc/qcom,pas-common.yaml | 6 +- > 2 files changed, 159 insertions(+), 1 deletion(-) Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Best regards, Krzysztof
On Tue, Mar 10, 2026 at 03:03:20AM -0700, Jingyi Wang wrote: > Document the component used to boot SoCCP on Kaanapali SoC and add > compatible for Glymur SoCCP which could fallback to Kaanapali. Extend > the "qcom,smem-states", "qcom,smem-state-names" in the pas-common. > > Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> > --- > .../remoteproc/qcom,kaanapali-soccp-pas.yaml | 154 +++++++++++++++++++++ > .../bindings/remoteproc/qcom,pas-common.yaml | 6 +- > 2 files changed, 159 insertions(+), 1 deletion(-) With all the changes to pas-common, what is being left in it? Would it be easier to leave it as is for the traditional DSPs and copy necessary functionality into the soccp schema? -- With best wishes Dmitry
On Wed, Mar 11, 2026 at 04:04:09AM +0200, Dmitry Baryshkov wrote: > On Tue, Mar 10, 2026 at 03:03:20AM -0700, Jingyi Wang wrote: > > Document the component used to boot SoCCP on Kaanapali SoC and add > > compatible for Glymur SoCCP which could fallback to Kaanapali. Extend > > the "qcom,smem-states", "qcom,smem-state-names" in the pas-common. > > > > Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> > > --- > > .../remoteproc/qcom,kaanapali-soccp-pas.yaml | 154 +++++++++++++++++++++ > > .../bindings/remoteproc/qcom,pas-common.yaml | 6 +- > > 2 files changed, 159 insertions(+), 1 deletion(-) > > With all the changes to pas-common, what is being left in it? Would it You need place for definition of properties - smd/glink-edge and qcom,smem-states. The latter is actually not properly defined in one place, becuse there are bindings having it but not refencing pas-common. It can also define common order of interrupts, but as you pointed out this does not work for this new device anymore. > be easier to leave it as is for the traditional DSPs and copy necessary > functionality into the soccp schema? Best regards, Krzysztof
gn Wed, Mar 11, 2026 at 07:26:38AM +0100, Krzysztof Kozlowski wrote: > On Wed, Mar 11, 2026 at 04:04:09AM +0200, Dmitry Baryshkov wrote: > > On Tue, Mar 10, 2026 at 03:03:20AM -0700, Jingyi Wang wrote: > > > Document the component used to boot SoCCP on Kaanapali SoC and add > > > compatible for Glymur SoCCP which could fallback to Kaanapali. Extend > > > the "qcom,smem-states", "qcom,smem-state-names" in the pas-common. > > > > > > Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> > > > --- > > > .../remoteproc/qcom,kaanapali-soccp-pas.yaml | 154 +++++++++++++++++++++ > > > .../bindings/remoteproc/qcom,pas-common.yaml | 6 +- > > > 2 files changed, 159 insertions(+), 1 deletion(-) > > > > With all the changes to pas-common, what is being left in it? Would it > > You need place for definition of properties - smd/glink-edge and > qcom,smem-states. The latter is actually not properly defined in one > place, becuse there are bindings having it but not refencing > pas-common. So do we for schemas definig smd-edge. > > It can also define common order of interrupts, but as you pointed out > this does not work for this new device anymore. Nor does it work for SocCP smem-states. I think that having such a pas-common overcomplicates existing schema. What about splitting qcom,dsp-common from qcom,pas-common with the latter keeping properties that are common to existing DSP and SoCCP, while the former being used only for DSPs? > > > be easier to leave it as is for the traditional DSPs and copy necessary > > functionality into the soccp schema? -- With best wishes Dmitry
On 12/03/2026 05:53, Dmitry Baryshkov wrote: > gn Wed, Mar 11, 2026 at 07:26:38AM +0100, Krzysztof Kozlowski wrote: >> On Wed, Mar 11, 2026 at 04:04:09AM +0200, Dmitry Baryshkov wrote: >>> On Tue, Mar 10, 2026 at 03:03:20AM -0700, Jingyi Wang wrote: >>>> Document the component used to boot SoCCP on Kaanapali SoC and add >>>> compatible for Glymur SoCCP which could fallback to Kaanapali. Extend >>>> the "qcom,smem-states", "qcom,smem-state-names" in the pas-common. >>>> >>>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> >>>> --- >>>> .../remoteproc/qcom,kaanapali-soccp-pas.yaml | 154 +++++++++++++++++++++ >>>> .../bindings/remoteproc/qcom,pas-common.yaml | 6 +- >>>> 2 files changed, 159 insertions(+), 1 deletion(-) >>> >>> With all the changes to pas-common, what is being left in it? Would it >> >> You need place for definition of properties - smd/glink-edge and >> qcom,smem-states. The latter is actually not properly defined in one >> place, becuse there are bindings having it but not refencing >> pas-common. > > So do we for schemas definig smd-edge. > >> >> It can also define common order of interrupts, but as you pointed out >> this does not work for this new device anymore. > > Nor does it work for SocCP smem-states. I think that having such a It only does not work in full constraints, but for defining the type it works. > pas-common overcomplicates existing schema. What about splitting > qcom,dsp-common from qcom,pas-common with the latter keeping properties > that are common to existing DSP and SoCCP, while the former being used > only for DSPs? > What would be in the dsp-common then? Best regards, Krzysztof
On Thu, Mar 12, 2026 at 05:08:46PM +0100, Krzysztof Kozlowski wrote: > On 12/03/2026 05:53, Dmitry Baryshkov wrote: > > gn Wed, Mar 11, 2026 at 07:26:38AM +0100, Krzysztof Kozlowski wrote: > >> On Wed, Mar 11, 2026 at 04:04:09AM +0200, Dmitry Baryshkov wrote: > >>> On Tue, Mar 10, 2026 at 03:03:20AM -0700, Jingyi Wang wrote: > >>>> Document the component used to boot SoCCP on Kaanapali SoC and add > >>>> compatible for Glymur SoCCP which could fallback to Kaanapali. Extend > >>>> the "qcom,smem-states", "qcom,smem-state-names" in the pas-common. > >>>> > >>>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> > >>>> --- > >>>> .../remoteproc/qcom,kaanapali-soccp-pas.yaml | 154 +++++++++++++++++++++ > >>>> .../bindings/remoteproc/qcom,pas-common.yaml | 6 +- > >>>> 2 files changed, 159 insertions(+), 1 deletion(-) > >>> > >>> With all the changes to pas-common, what is being left in it? Would it > >> > >> You need place for definition of properties - smd/glink-edge and > >> qcom,smem-states. The latter is actually not properly defined in one > >> place, becuse there are bindings having it but not refencing > >> pas-common. > > > > So do we for schemas definig smd-edge. > > > >> > >> It can also define common order of interrupts, but as you pointed out > >> this does not work for this new device anymore. > > > > Nor does it work for SocCP smem-states. I think that having such a > > It only does not work in full constraints, but for defining the type it > works. > > > pas-common overcomplicates existing schema. What about splitting > > qcom,dsp-common from qcom,pas-common with the latter keeping properties > > that are common to existing DSP and SoCCP, while the former being used > > only for DSPs? > > > > What would be in the dsp-common then? All items that got spread to individual DSP schemas: - single item in smem-states / smem-state-names (and maybe the value of that item) - 6 standard interrupts with minItems:5 - XO clock Ideally after this we can split qcom,adsp.yaml into several smaller schemas de-monstrifying the if-pile. Anyway, current patchset has another issue, I'll comment in a minute. > > Best regards, > Krzysztof -- With best wishes Dmitry
© 2016 - 2026 Red Hat, Inc.