| Message ID | 20240117173458.2312669-2-quic_sibis@quicinc.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | firmware: arm_scmi: Qualcomm Vendor Protocol | expand |
On 1/17/24 18:34, Sibi Sankar wrote: > Add devicetree binding for CPUSS Control Processor (CPUCP) mailbox > controller. > > Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> > --- [...] > + - | > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + > + mailbox@17430000 { > + compatible = "qcom,x1e80100-cpucp-mbox", "qcom,cpucp-mbox"; > + reg = <0x17430000 0x10000>, <0x18830000 0x300>; These reg spaces are quite far apart.. On 7280-8550, a similar mailbox exists, although it's dubbed RIMPS-mbox instead. In that case, I separated the mbox into tx (via qcom-apcs-ipc-mailbox.c) and rx (with a simple driver). Still haven't pushed or posted that anywhere, I'd need to access another machine.. On (some of) these SoCs, one of the channels (rx[1], iirc?) clearly bleeds into the CPUFREQ_HW/OSM register region, which gives an impression of misrepresenting the hardware. X1E doesn't have a node for cpufreq_hw defined, so I can't tell whether it's also the case here. Konrad
On Wed, Jan 17, 2024 at 11:04:52PM +0530, Sibi Sankar wrote: > Add devicetree binding for CPUSS Control Processor (CPUCP) mailbox > controller. > > Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> > --- > .../bindings/mailbox/qcom,cpucp-mbox.yaml | 51 +++++++++++++++++++ > 1 file changed, 51 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml > > diff --git a/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml > new file mode 100644 > index 000000000000..2617e5555acb > --- /dev/null > +++ b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml > @@ -0,0 +1,51 @@ > +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mailbox/qcom,cpucp-mbox.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm Technologies, Inc. CPUCP Mailbox Controller > + > +maintainers: > + - Sibi Sankar <quic_sibis@qti.qualcomm.com> > + > +description: > + The CPUSS Control Processor (CPUCP) mailbox controller enables communication > + between AP and CPUCP by acting as a doorbell between them. > + > +properties: > + compatible: > + items: > + - enum: > + - qcom,x1e80100-cpucp-mbox > + - const: qcom,cpucp-mbox A generic fallback implies multiple devices use the same unchanged block. That seems doubtful given you have not defined any others and given Konrad's comments. Rob
On 1/18/24 01:23, Konrad Dybcio wrote: > > > On 1/17/24 18:34, Sibi Sankar wrote: >> Add devicetree binding for CPUSS Control Processor (CPUCP) mailbox >> controller. >> >> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> >> --- > Hey Konrad, Thanks for taking time to review the series. > [...] > >> + - | >> + #include <dt-bindings/interrupt-controller/arm-gic.h> >> + >> + mailbox@17430000 { >> + compatible = "qcom,x1e80100-cpucp-mbox", "qcom,cpucp-mbox"; >> + reg = <0x17430000 0x10000>, <0x18830000 0x300>; > > These reg spaces are quite far apart.. On 7280-8550, a similar > mailbox exists, although it's dubbed RIMPS-mbox instead. In > that case, I separated the mbox into tx (via > qcom-apcs-ipc-mailbox.c) and rx (with a simple driver). Still > haven't pushed or posted that anywhere, I'd need to access > another machine.. > > On (some of) these SoCs, one of the channels (rx[1], iirc?) clearly > bleeds into the CPUFREQ_HW/OSM register region, which gives an > impression of misrepresenting the hardware. X1E doesn't have a > node for cpufreq_hw defined, so I can't tell whether it's also the > case here. I am aware of ^^ discussion and the X1E doesn't have this problem. Both the regions described are only used for mailbox communication. X1E uses the scmi perf protocol for cpu dvfs. -Sibi > > Konrad
On 1/30/24 22:42, Rob Herring wrote: > On Wed, Jan 17, 2024 at 11:04:52PM +0530, Sibi Sankar wrote: >> Add devicetree binding for CPUSS Control Processor (CPUCP) mailbox >> controller. Hey Rob, Thanks for taking time to review the series. >> >> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> >> --- >> .../bindings/mailbox/qcom,cpucp-mbox.yaml | 51 +++++++++++++++++++ >> 1 file changed, 51 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml >> >> diff --git a/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml >> new file mode 100644 >> index 000000000000..2617e5555acb >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml >> @@ -0,0 +1,51 @@ >> +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/mailbox/qcom,cpucp-mbox.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Qualcomm Technologies, Inc. CPUCP Mailbox Controller >> + >> +maintainers: >> + - Sibi Sankar <quic_sibis@qti.qualcomm.com> >> + >> +description: >> + The CPUSS Control Processor (CPUCP) mailbox controller enables communication >> + between AP and CPUCP by acting as a doorbell between them. >> + >> +properties: >> + compatible: >> + items: >> + - enum: >> + - qcom,x1e80100-cpucp-mbox >> + - const: qcom,cpucp-mbox > > A generic fallback implies multiple devices use the same unchanged > block. That seems doubtful given you have not defined any others and > given Konrad's comments. This mbox is expected to be used as is on a number of future SoCs, that's the only reason I added the generic fallback. I can drop it in the next re-spin if you want. -Sibi > > Rob
On 08/02/2024 11:28, Sibi Sankar wrote: >>> +properties: >>> + compatible: >>> + items: >>> + - enum: >>> + - qcom,x1e80100-cpucp-mbox >>> + - const: qcom,cpucp-mbox >> >> A generic fallback implies multiple devices use the same unchanged >> block. That seems doubtful given you have not defined any others and >> given Konrad's comments. > > This mbox is expected to be used as is on a number of future SoCs, > that's the only reason I added the generic fallback. I can drop it > in the next re-spin if you want. Given that, if you ever have compatible devices, just use device-specific compatible as fallback. Best regards, Krzysztof
On 8.02.2024 11:22, Sibi Sankar wrote: > > > On 1/18/24 01:23, Konrad Dybcio wrote: >> >> >> On 1/17/24 18:34, Sibi Sankar wrote: >>> Add devicetree binding for CPUSS Control Processor (CPUCP) mailbox >>> controller. >>> >>> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> >>> --- >> > > Hey Konrad, > > Thanks for taking time to review the series. > >> [...] >> >>> + - | >>> + #include <dt-bindings/interrupt-controller/arm-gic.h> >>> + >>> + mailbox@17430000 { >>> + compatible = "qcom,x1e80100-cpucp-mbox", "qcom,cpucp-mbox"; >>> + reg = <0x17430000 0x10000>, <0x18830000 0x300>; >> >> These reg spaces are quite far apart.. On 7280-8550, a similar >> mailbox exists, although it's dubbed RIMPS-mbox instead. In >> that case, I separated the mbox into tx (via >> qcom-apcs-ipc-mailbox.c) and rx (with a simple driver). Still >> haven't pushed or posted that anywhere, I'd need to access >> another machine.. >> >> On (some of) these SoCs, one of the channels (rx[1], iirc?) clearly >> bleeds into the CPUFREQ_HW/OSM register region, which gives an >> impression of misrepresenting the hardware. X1E doesn't have a >> node for cpufreq_hw defined, so I can't tell whether it's also the >> case here. > > I am aware of ^^ discussion and the X1E doesn't have this problem. > Both the regions described are only used for mailbox communication. > X1E uses the scmi perf protocol for cpu dvfs. Yes, that's clear. I am however asking for something different: I presume the CPUSS IP hasn't changed too much on this SoC, other than having new cores and OSM now being controlled through a different firmware interface, and I'd like to keep the hardware description in our DT as close to the metal as possible. In other words, if the good ol' OSM hardware is indeed there under however many layers of firmware, and if RX does indeed bleed into its register space, I'd prefer there be at least a syscon node describing the actual block, and not a magic hwio entry that's many zeroes away. Konrad
On 2/9/24 04:44, Konrad Dybcio wrote: > On 8.02.2024 11:22, Sibi Sankar wrote: >> >> >> On 1/18/24 01:23, Konrad Dybcio wrote: >>> >>> >>> On 1/17/24 18:34, Sibi Sankar wrote: >>>> Add devicetree binding for CPUSS Control Processor (CPUCP) mailbox >>>> controller. >>>> >>>> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> >>>> --- >>> >> >> Hey Konrad, >> >> Thanks for taking time to review the series. >> >>> [...] >>> >>>> + - | >>>> + #include <dt-bindings/interrupt-controller/arm-gic.h> >>>> + >>>> + mailbox@17430000 { >>>> + compatible = "qcom,x1e80100-cpucp-mbox", "qcom,cpucp-mbox"; >>>> + reg = <0x17430000 0x10000>, <0x18830000 0x300>; >>> >>> These reg spaces are quite far apart.. On 7280-8550, a similar >>> mailbox exists, although it's dubbed RIMPS-mbox instead. In >>> that case, I separated the mbox into tx (via >>> qcom-apcs-ipc-mailbox.c) and rx (with a simple driver). Still >>> haven't pushed or posted that anywhere, I'd need to access >>> another machine.. >>> >>> On (some of) these SoCs, one of the channels (rx[1], iirc?) clearly >>> bleeds into the CPUFREQ_HW/OSM register region, which gives an >>> impression of misrepresenting the hardware. X1E doesn't have a >>> node for cpufreq_hw defined, so I can't tell whether it's also the >>> case here. >> >> I am aware of ^^ discussion and the X1E doesn't have this problem. >> Both the regions described are only used for mailbox communication. >> X1E uses the scmi perf protocol for cpu dvfs. > > Yes, that's clear. > > I am however asking for something different: I presume the CPUSS > IP hasn't changed too much on this SoC, other than having new cores and > OSM now being controlled through a different firmware interface, and I'd > like to keep the hardware description in our DT as close to the metal as > possible. > > In other words, if the good ol' OSM hardware is indeed there under however > many layers of firmware, and if RX does indeed bleed into its register > space, I'd prefer there be at least a syscon node describing the actual > block, and not a magic hwio entry that's many zeroes away. > With the new cores X1E does not have any artifacts from the legacy OSM way that Qualcomm has followed till now. If it indeed existed it would make zero sense to vote for CPU frequencies through a mailbox than vote for it directly. -Sibi > Konrad >
On 1/30/24 18:12, Rob Herring wrote: > On Wed, Jan 17, 2024 at 11:04:52PM +0530, Sibi Sankar wrote: >> Add devicetree binding for CPUSS Control Processor (CPUCP) mailbox >> controller. >> >> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> >> --- >> .../bindings/mailbox/qcom,cpucp-mbox.yaml | 51 +++++++++++++++++++ >> 1 file changed, 51 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml >> >> diff --git a/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml >> new file mode 100644 >> index 000000000000..2617e5555acb >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml >> @@ -0,0 +1,51 @@ >> +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/mailbox/qcom,cpucp-mbox.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Qualcomm Technologies, Inc. CPUCP Mailbox Controller >> + >> +maintainers: >> + - Sibi Sankar <quic_sibis@qti.qualcomm.com> >> + >> +description: >> + The CPUSS Control Processor (CPUCP) mailbox controller enables communication >> + between AP and CPUCP by acting as a doorbell between them. >> + >> +properties: >> + compatible: >> + items: >> + - enum: >> + - qcom,x1e80100-cpucp-mbox >> + - const: qcom,cpucp-mbox > > A generic fallback implies multiple devices use the same unchanged > block. That seems doubtful given you have not defined any others and > given Konrad's comments. FWIW Sibi and I talked about this a bit off-list, this mailbox is apparently new and has nothing to do with what I mentioned on other platforms Konrad
diff --git a/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml new file mode 100644 index 000000000000..2617e5555acb --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/qcom,cpucp-mbox.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. CPUCP Mailbox Controller + +maintainers: + - Sibi Sankar <quic_sibis@qti.qualcomm.com> + +description: + The CPUSS Control Processor (CPUCP) mailbox controller enables communication + between AP and CPUCP by acting as a doorbell between them. + +properties: + compatible: + items: + - enum: + - qcom,x1e80100-cpucp-mbox + - const: qcom,cpucp-mbox + + reg: + items: + - description: CPUCP rx register region + - description: CPUCP tx register region + + interrupts: + maxItems: 1 + + "#mbox-cells": + const: 1 + +required: + - compatible + - reg + - interrupts + - "#mbox-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + mailbox@17430000 { + compatible = "qcom,x1e80100-cpucp-mbox", "qcom,cpucp-mbox"; + reg = <0x17430000 0x10000>, <0x18830000 0x300>; + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>; + #mbox-cells = <1>; + };
Add devicetree binding for CPUSS Control Processor (CPUCP) mailbox controller. Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> --- .../bindings/mailbox/qcom,cpucp-mbox.yaml | 51 +++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/qcom,cpucp-mbox.yaml