| Message ID | 20240822170951.339492-2-abdellatif.elkhlifi@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | remoteproc: arm64: Introduce remoteproc support for Corstone-1000 External Systems | expand |
On Thu, 22 Aug 2024 18:09:47 +0100, Abdellatif El Khlifi wrote: > Add devicetree binding schema for the External Systems remote processors > > The External Systems remote processors are provided on the Corstone-1000 > IoT Reference Design Platform via the SSE-710 subsystem. > > For more details about the External Systems, please see Corstone SSE-710 > subsystem features [1]. > > [1]: https://developer.arm.com/documentation/102360/0000/Overview-of-Corstone-1000/Corstone-SSE-710-subsystem-features > > Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> > --- > .../remoteproc/arm,sse710-extsys.yaml | 90 +++++++++++++++++++ > 1 file changed, 90 insertions(+) > create mode 100644 Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.example.dtb: /example-0/syscon@1a010000: failed to match any schema with compatible: ['arm,sse710-host-base-sysctrl', 'simple-mfd', 'syscon'] doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240822170951.339492-2-abdellatif.elkhlifi@arm.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
On Thu, Aug 22, 2024 at 06:09:47PM +0100, Abdellatif El Khlifi wrote: > Add devicetree binding schema for the External Systems remote processors > > The External Systems remote processors are provided on the Corstone-1000 > IoT Reference Design Platform via the SSE-710 subsystem. > > For more details about the External Systems, please see Corstone SSE-710 > subsystem features [1]. > Do not attach (thread) your patchsets to some other threads (unrelated or older versions). This buries them deep in the mailbox and might interfere with applying entire sets. > [1]: https://developer.arm.com/documentation/102360/0000/Overview-of-Corstone-1000/Corstone-SSE-710-subsystem-features > > Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> > --- > .../remoteproc/arm,sse710-extsys.yaml | 90 +++++++++++++++++++ > 1 file changed, 90 insertions(+) > create mode 100644 Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml > > diff --git a/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml b/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml > new file mode 100644 > index 000000000000..827ba8d962f1 > --- /dev/null > +++ b/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml > @@ -0,0 +1,90 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/remoteproc/arm,sse710-extsys.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: SSE-710 External System Remote Processor > + > +maintainers: > + - Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> > + - Hugues Kamba Mpiana <hugues.kambampiana@arm.com> > + > +description: | dt-preserve-formatting > + SSE-710 is an heterogeneous subsystem supporting up to two remote > + processors aka the External Systems. > + > +properties: > + compatible: > + enum: > + - arm,sse710-extsys > + > + firmware-name: > + description: > + The default name of the firmware to load to the remote processor. > + > + '#extsys-id': '#' is not correct for sure, that's not a cell specifier. But anyway, we do not accept in general instance IDs. > + description: > + The External System ID. This tells me nothing. You basically copied property name. > + enum: [0, 1] > + > + mbox-names: > + items: > + - const: txes0 > + - const: rxes0 > + > + mboxes: > + description: > + The list of Message Handling Unit (MHU) channels used for bidirectional > + communication. This property is only required if the virtio-based Rpmsg > + messaging bus is used. For more details see the Arm MHUv2 Mailbox > + Controller at devicetree/bindings/mailbox/arm,mhuv2.yaml > + Drop blank line > + minItems: 2 This is redundant if equals to maxItemns, drop. > + maxItems: 2 > + > + memory-region: > + description: > + If present, a phandle for a reserved memory area that used for vdev > + buffer, resource table, vring region and others used by the remote > + processor. > + minItems: 2 > + maxItems: 32 > + > +required: > + - compatible > + - firmware-name > + - '#extsys-id' > + > +additionalProperties: false > + > +examples: > + - | > + reserved-memory { > + #address-cells = <2>; > + #size-cells = <2>; > + > + extsys0_vring0: vdev0vring0@82001000 { > + reg = <0 0x82001000 0 0x8000>; > + no-map; > + }; > + > + extsys0_vring1: vdev0vring1@82009000 { > + reg = <0 0x82009000 0 0x8000>; > + no-map; > + }; > + }; Drop, it is fairly common. > + > + syscon@1a010000 { > + compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; > + reg = <0x1a010000 0x1000>; So this is a part of other block? Then make one complete example in the parent device bindings. > + > + extsys0 { Node names should be generic. See also an explanation and list of examples (not exhaustive) in DT specification: https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation e.g. remoteproc > + compatible = "arm,sse710-extsys"; > + #extsys-id = <0>; > + firmware-name = "es_flashfw.elf"; > + mbox-names = "txes0", "rxes0"; > + mboxes = <&mhu0_hes0 0 1>, <&mhu0_es0h 0 1>; First go mboxes, then mbox-names. The same in the binding, BTW. Best regards, Krzysztof
Hi Krzysztof, > > Add devicetree binding schema for the External Systems remote processors > > > > The External Systems remote processors are provided on the Corstone-1000 > > IoT Reference Design Platform via the SSE-710 subsystem. > > > > For more details about the External Systems, please see Corstone SSE-710 > > subsystem features [1]. > > > > Do not attach (thread) your patchsets to some other threads (unrelated > or older versions). This buries them deep in the mailbox and might > interfere with applying entire sets. > > > [1]: https://developer.arm.com/documentation/102360/0000/Overview-of-Corstone-1000/Corstone-SSE-710-subsystem-features > > > > Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> > > --- > > .../remoteproc/arm,sse710-extsys.yaml | 90 +++++++++++++++++++ > > 1 file changed, 90 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml > > > > diff --git a/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml b/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml > > new file mode 100644 > > index 000000000000..827ba8d962f1 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml > > @@ -0,0 +1,90 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/remoteproc/arm,sse710-extsys.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: SSE-710 External System Remote Processor > > + > > +maintainers: > > + - Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> > > + - Hugues Kamba Mpiana <hugues.kambampiana@arm.com> > > + > > +description: | > > dt-preserve-formatting Do you mean I should remove the '|' please ? (I didn't find examples of use of dt-preserve-formatting in Documentation/devicetree/bindings/) > > > + SSE-710 is an heterogeneous subsystem supporting up to two remote > > + processors aka the External Systems. > > + > > +properties: > > + compatible: > > + enum: > > + - arm,sse710-extsys > > + > > + firmware-name: > > + description: > > + The default name of the firmware to load to the remote processor. > > + > > + '#extsys-id': > > '#' is not correct for sure, that's not a cell specifier. > > But anyway, we do not accept in general instance IDs. I'm happy to replace the instance ID with another solution. In our case the remoteproc instance does not have a base address to use. So, we can't put remoteproc@address What do you recommend in this case please ? Kind regards, Abdellatif
On 19/09/2024 11:35, Abdellatif El Khlifi wrote: > Hi Krzysztof, > >>> Add devicetree binding schema for the External Systems remote processors >>> >>> The External Systems remote processors are provided on the Corstone-1000 >>> IoT Reference Design Platform via the SSE-710 subsystem. >>> >>> For more details about the External Systems, please see Corstone SSE-710 >>> subsystem features [1]. >>> >> >> Do not attach (thread) your patchsets to some other threads (unrelated >> or older versions). This buries them deep in the mailbox and might >> interfere with applying entire sets. >> >>> [1]: https://developer.arm.com/documentation/102360/0000/Overview-of-Corstone-1000/Corstone-SSE-710-subsystem-features >>> >>> Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> >>> --- >>> .../remoteproc/arm,sse710-extsys.yaml | 90 +++++++++++++++++++ >>> 1 file changed, 90 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml b/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml >>> new file mode 100644 >>> index 000000000000..827ba8d962f1 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml >>> @@ -0,0 +1,90 @@ >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/remoteproc/arm,sse710-extsys.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: SSE-710 External System Remote Processor >>> + >>> +maintainers: >>> + - Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> >>> + - Hugues Kamba Mpiana <hugues.kambampiana@arm.com> >>> + >>> +description: | >> >> dt-preserve-formatting > > Do you mean I should remove the '|' please ? (I didn't find examples of use of > dt-preserve-formatting in Documentation/devicetree/bindings/) > >> >>> + SSE-710 is an heterogeneous subsystem supporting up to two remote >>> + processors aka the External Systems. >>> + >>> +properties: >>> + compatible: >>> + enum: >>> + - arm,sse710-extsys >>> + >>> + firmware-name: >>> + description: >>> + The default name of the firmware to load to the remote processor. >>> + >>> + '#extsys-id': >> >> '#' is not correct for sure, that's not a cell specifier. >> >> But anyway, we do not accept in general instance IDs. > > I'm happy to replace the instance ID with another solution. > In our case the remoteproc instance does not have a base address > to use. So, we can't put remoteproc@address > > What do you recommend in this case please ? Waiting one month to respond is a great way to drop all context from my memory. The emails are not even available for me - gone from inbox. Bus addressing could note it. Or you have different devices, so different compatibles. Tricky to say, because you did not describe the hardware really and it's one month later... Best regards, Krzysztof
Hi Krzysztof, > >>> + '#extsys-id': > >> > >> '#' is not correct for sure, that's not a cell specifier. > >> > >> But anyway, we do not accept in general instance IDs. > > > > I'm happy to replace the instance ID with another solution. > > In our case the remoteproc instance does not have a base address > > to use. So, we can't put remoteproc@address > > > > What do you recommend in this case please ? > > Waiting one month to respond is a great way to drop all context from my > memory. The emails are not even available for me - gone from inbox. > > Bus addressing could note it. Or you have different devices, so > different compatibles. Tricky to say, because you did not describe the > hardware really and it's one month later... > Sorry for waiting. I was in holidays. I'll add more documentation about the external system for more clarity [1]. Basically, Linux runs on the Cortex-A35. The External system is a Cortex-M core. The Cortex-A35 can not access the memory of the Cortex-M. It can only control Cortex-M core using the reset control and status registers mapped in the memory space of the Cortex-A35. I'll make sure this explanation is added to the binding and commit log for more clarity. Thanks for the suggestion regarding supporting multiple instances of the External system. I will send a new version shortly addressing all comments. [1]: paragraph 2.3, https://developer.arm.com/documentation/dai0550/D/?lang=en Kind regards Abdellatif
On 19/09/2024 16:57, Abdellatif El Khlifi wrote: > Hi Krzysztof, > >>>>> + '#extsys-id': >>>> >>>> '#' is not correct for sure, that's not a cell specifier. >>>> >>>> But anyway, we do not accept in general instance IDs. >>> >>> I'm happy to replace the instance ID with another solution. >>> In our case the remoteproc instance does not have a base address >>> to use. So, we can't put remoteproc@address >>> >>> What do you recommend in this case please ? >> >> Waiting one month to respond is a great way to drop all context from my >> memory. The emails are not even available for me - gone from inbox. >> >> Bus addressing could note it. Or you have different devices, so >> different compatibles. Tricky to say, because you did not describe the >> hardware really and it's one month later... >> > > Sorry for waiting. I was in holidays. > > I'll add more documentation about the external system for more clarity [1]. > > Basically, Linux runs on the Cortex-A35. The External system is a > Cortex-M core. The Cortex-A35 can not access the memory of the Cortex-M. > It can only control Cortex-M core using the reset control and status registers mapped > in the memory space of the Cortex-A35. That's pretty standard. It does not explain me why bus addressing or different compatible are not sufficient here. Best regards, Krzysztof
Hi Krzysztof, > >>>>> + '#extsys-id': > >>>> > >>>> '#' is not correct for sure, that's not a cell specifier. > >>>> > >>>> But anyway, we do not accept in general instance IDs. > >>> > >>> I'm happy to replace the instance ID with another solution. > >>> In our case the remoteproc instance does not have a base address > >>> to use. So, we can't put remoteproc@address > >>> > >>> What do you recommend in this case please ? > >> > >> Waiting one month to respond is a great way to drop all context from my > >> memory. The emails are not even available for me - gone from inbox. > >> > >> Bus addressing could note it. Or you have different devices, so > >> different compatibles. Tricky to say, because you did not describe the > >> hardware really and it's one month later... > >> > > > > Sorry for waiting. I was in holidays. > > > > I'll add more documentation about the external system for more clarity [1]. > > > > Basically, Linux runs on the Cortex-A35. The External system is a > > Cortex-M core. The Cortex-A35 can not access the memory of the Cortex-M. > > It can only control Cortex-M core using the reset control and status registers mapped > > in the memory space of the Cortex-A35. > > That's pretty standard. > > It does not explain me why bus addressing or different compatible are > not sufficient here. Using an instance ID was a design choice. I'm happy to replace it with the use of compatible and match data (WIP). The match data will be pointing to a data structure containing the right offsets to be used with regmap APIs. syscon node is used to represent the Host Base System Control register area [1] where the external system reset registers are mapped (EXT_SYS*). The nodes will look like this: syscon@1a010000 { compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; reg = <0x1a010000 0x1000>; #address-cells = <1>; #size-cells = <1>; remoteproc@310 { compatible = "arm,sse710-extsys0"; reg = <0x310 4>; ... } remoteproc@318 { compatible = "arm,sse710-extsys1"; reg = <0x318 4>; ... } [1]: https://developer.arm.com/documentation/102342/0000/Programmers-model/Register-descriptions/Host-Base-System-Control-register-summary Cheers Abdellatif
On 20/09/2024 16:19, Abdellatif El Khlifi wrote: > Hi Krzysztof, > >>>>>>> + '#extsys-id': >>>>>> >>>>>> '#' is not correct for sure, that's not a cell specifier. >>>>>> >>>>>> But anyway, we do not accept in general instance IDs. >>>>> >>>>> I'm happy to replace the instance ID with another solution. >>>>> In our case the remoteproc instance does not have a base address >>>>> to use. So, we can't put remoteproc@address >>>>> >>>>> What do you recommend in this case please ? >>>> >>>> Waiting one month to respond is a great way to drop all context from my >>>> memory. The emails are not even available for me - gone from inbox. >>>> >>>> Bus addressing could note it. Or you have different devices, so >>>> different compatibles. Tricky to say, because you did not describe the >>>> hardware really and it's one month later... >>>> >>> >>> Sorry for waiting. I was in holidays. >>> >>> I'll add more documentation about the external system for more clarity [1]. >>> >>> Basically, Linux runs on the Cortex-A35. The External system is a >>> Cortex-M core. The Cortex-A35 can not access the memory of the Cortex-M. >>> It can only control Cortex-M core using the reset control and status registers mapped >>> in the memory space of the Cortex-A35. >> >> That's pretty standard. >> >> It does not explain me why bus addressing or different compatible are >> not sufficient here. > > Using an instance ID was a design choice. > I'm happy to replace it with the use of compatible and match data (WIP). > > The match data will be pointing to a data structure containing the right offsets > to be used with regmap APIs. > > syscon node is used to represent the Host Base System Control register area [1] > where the external system reset registers are mapped (EXT_SYS*). > > The nodes will look like this: > > syscon@1a010000 { > compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; > reg = <0x1a010000 0x1000>; > > #address-cells = <1>; > #size-cells = <1>; > > remoteproc@310 { > compatible = "arm,sse710-extsys0"; > reg = <0x310 4>; Uh, why do you create device nodes for one word? This really suggests it is part of parent device and your split is artificial. Best regards, Krzysztof
Hi Krzysztof, > >>>>>>> + '#extsys-id': > >>>>>> > >>>>>> '#' is not correct for sure, that's not a cell specifier. > >>>>>> > >>>>>> But anyway, we do not accept in general instance IDs. > >>>>> > >>>>> I'm happy to replace the instance ID with another solution. > >>>>> In our case the remoteproc instance does not have a base address > >>>>> to use. So, we can't put remoteproc@address > >>>>> > >>>>> What do you recommend in this case please ? > >>>> > >>>> Waiting one month to respond is a great way to drop all context from my > >>>> memory. The emails are not even available for me - gone from inbox. > >>>> > >>>> Bus addressing could note it. Or you have different devices, so > >>>> different compatibles. Tricky to say, because you did not describe the > >>>> hardware really and it's one month later... > >>>> > >>> > >>> Sorry for waiting. I was in holidays. > >>> > >>> I'll add more documentation about the external system for more clarity [1]. > >>> > >>> Basically, Linux runs on the Cortex-A35. The External system is a > >>> Cortex-M core. The Cortex-A35 can not access the memory of the Cortex-M. > >>> It can only control Cortex-M core using the reset control and status registers mapped > >>> in the memory space of the Cortex-A35. > >> > >> That's pretty standard. > >> > >> It does not explain me why bus addressing or different compatible are > >> not sufficient here. > > > > Using an instance ID was a design choice. > > I'm happy to replace it with the use of compatible and match data (WIP). > > > > The match data will be pointing to a data structure containing the right offsets > > to be used with regmap APIs. > > > > syscon node is used to represent the Host Base System Control register area [1] > > where the external system reset registers are mapped (EXT_SYS*). > > > > The nodes will look like this: > > > > syscon@1a010000 { > > compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; > > reg = <0x1a010000 0x1000>; > > > > #address-cells = <1>; > > #size-cells = <1>; > > > > remoteproc@310 { > > compatible = "arm,sse710-extsys0"; > > reg = <0x310 4>; > > Uh, why do you create device nodes for one word? This really suggests it > is part of parent device and your split is artificial. The external system registers (described by the remoteproc node) are part of the parent device (the Host Base System Control register area) described by syscon. In case of the external system 0 , its registers are located at offset 0x310 (physical address: 0x1a010310) When instantiating the devices without @address, the DTC compiler detects 2 nodes with the same name (remoteproc). syscon@1a010000 { ... remoteproc { compatible = "arm,sse710-extsys0"; ... } remoteproc { compatible = "arm,sse710-extsys1"; ... } Cheers Abdellatif
On 20/09/2024 18:38, Abdellatif El Khlifi wrote: > Hi Krzysztof, > >>>>>>>>> + '#extsys-id': >>>>>>>> >>>>>>>> '#' is not correct for sure, that's not a cell specifier. >>>>>>>> >>>>>>>> But anyway, we do not accept in general instance IDs. >>>>>>> >>>>>>> I'm happy to replace the instance ID with another solution. >>>>>>> In our case the remoteproc instance does not have a base address >>>>>>> to use. So, we can't put remoteproc@address >>>>>>> >>>>>>> What do you recommend in this case please ? >>>>>> >>>>>> Waiting one month to respond is a great way to drop all context from my >>>>>> memory. The emails are not even available for me - gone from inbox. >>>>>> >>>>>> Bus addressing could note it. Or you have different devices, so >>>>>> different compatibles. Tricky to say, because you did not describe the >>>>>> hardware really and it's one month later... >>>>>> >>>>> >>>>> Sorry for waiting. I was in holidays. >>>>> >>>>> I'll add more documentation about the external system for more clarity [1]. >>>>> >>>>> Basically, Linux runs on the Cortex-A35. The External system is a >>>>> Cortex-M core. The Cortex-A35 can not access the memory of the Cortex-M. >>>>> It can only control Cortex-M core using the reset control and status registers mapped >>>>> in the memory space of the Cortex-A35. >>>> >>>> That's pretty standard. >>>> >>>> It does not explain me why bus addressing or different compatible are >>>> not sufficient here. >>> >>> Using an instance ID was a design choice. >>> I'm happy to replace it with the use of compatible and match data (WIP). >>> >>> The match data will be pointing to a data structure containing the right offsets >>> to be used with regmap APIs. >>> >>> syscon node is used to represent the Host Base System Control register area [1] >>> where the external system reset registers are mapped (EXT_SYS*). >>> >>> The nodes will look like this: >>> >>> syscon@1a010000 { >>> compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; >>> reg = <0x1a010000 0x1000>; >>> >>> #address-cells = <1>; >>> #size-cells = <1>; >>> >>> remoteproc@310 { >>> compatible = "arm,sse710-extsys0"; >>> reg = <0x310 4>; >> >> Uh, why do you create device nodes for one word? This really suggests it >> is part of parent device and your split is artificial. > > The external system registers (described by the remoteproc node) are part > of the parent device (the Host Base System Control register area) described > by syscon. > > In case of the external system 0 , its registers are located at offset 0x310 > (physical address: 0x1a010310) > > When instantiating the devices without @address, the DTC compiler > detects 2 nodes with the same name (remoteproc). There should be no children at all. DT is not for instantiating your drivers. I claim you have only one device and that's arm,sse710-host-base-sysctrl. If you create child node for one word, that's not a device. Best regards, Krzysztof
On 19/09/2024 11:35, Abdellatif El Khlifi wrote: > Hi Krzysztof, > >>> Add devicetree binding schema for the External Systems remote processors >>> >>> The External Systems remote processors are provided on the Corstone-1000 >>> IoT Reference Design Platform via the SSE-710 subsystem. >>> >>> For more details about the External Systems, please see Corstone SSE-710 >>> subsystem features [1]. >>> >> >> Do not attach (thread) your patchsets to some other threads (unrelated >> or older versions). This buries them deep in the mailbox and might >> interfere with applying entire sets. >> >>> [1]: https://developer.arm.com/documentation/102360/0000/Overview-of-Corstone-1000/Corstone-SSE-710-subsystem-features >>> >>> Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> >>> --- >>> .../remoteproc/arm,sse710-extsys.yaml | 90 +++++++++++++++++++ >>> 1 file changed, 90 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml b/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml >>> new file mode 100644 >>> index 000000000000..827ba8d962f1 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml >>> @@ -0,0 +1,90 @@ >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/remoteproc/arm,sse710-extsys.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: SSE-710 External System Remote Processor >>> + >>> +maintainers: >>> + - Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> >>> + - Hugues Kamba Mpiana <hugues.kambampiana@arm.com> >>> + >>> +description: | >> >> dt-preserve-formatting > > Do you mean I should remove the '|' please ? (I didn't find examples of use of > dt-preserve-formatting in Documentation/devicetree/bindings/) I am sorry, it was supposed to be expanded from VIM snippet, but I did not finish the expansion. The point was to remove '|' because it is not needed. Best regards, Krzysztof
Hi Krzysztof, > >>>>>>>>> + '#extsys-id': > >>>>>>>> > >>>>>>>> '#' is not correct for sure, that's not a cell specifier. > >>>>>>>> > >>>>>>>> But anyway, we do not accept in general instance IDs. > >>>>>>> > >>>>>>> I'm happy to replace the instance ID with another solution. > >>>>>>> In our case the remoteproc instance does not have a base address > >>>>>>> to use. So, we can't put remoteproc@address > >>>>>>> > >>>>>>> What do you recommend in this case please ? > >>>>>> > >>>>>> Waiting one month to respond is a great way to drop all context from my > >>>>>> memory. The emails are not even available for me - gone from inbox. > >>>>>> > >>>>>> Bus addressing could note it. Or you have different devices, so > >>>>>> different compatibles. Tricky to say, because you did not describe the > >>>>>> hardware really and it's one month later... > >>>>>> > >>>>> > >>>>> Sorry for waiting. I was in holidays. > >>>>> > >>>>> I'll add more documentation about the external system for more clarity [1]. > >>>>> > >>>>> Basically, Linux runs on the Cortex-A35. The External system is a > >>>>> Cortex-M core. The Cortex-A35 can not access the memory of the Cortex-M. > >>>>> It can only control Cortex-M core using the reset control and status registers mapped > >>>>> in the memory space of the Cortex-A35. > >>>> > >>>> That's pretty standard. > >>>> > >>>> It does not explain me why bus addressing or different compatible are > >>>> not sufficient here. > >>> > >>> Using an instance ID was a design choice. > >>> I'm happy to replace it with the use of compatible and match data (WIP). > >>> > >>> The match data will be pointing to a data structure containing the right offsets > >>> to be used with regmap APIs. > >>> > >>> syscon node is used to represent the Host Base System Control register area [1] > >>> where the external system reset registers are mapped (EXT_SYS*). > >>> > >>> The nodes will look like this: > >>> > >>> syscon@1a010000 { > >>> compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; > >>> reg = <0x1a010000 0x1000>; > >>> > >>> #address-cells = <1>; > >>> #size-cells = <1>; > >>> > >>> remoteproc@310 { > >>> compatible = "arm,sse710-extsys0"; > >>> reg = <0x310 4>; > >> > >> Uh, why do you create device nodes for one word? This really suggests it > >> is part of parent device and your split is artificial. > > > > The external system registers (described by the remoteproc node) are part > > of the parent device (the Host Base System Control register area) described > > by syscon. > > > > In case of the external system 0 , its registers are located at offset 0x310 > > (physical address: 0x1a010310) > > > > When instantiating the devices without @address, the DTC compiler > > detects 2 nodes with the same name (remoteproc). > > There should be no children at all. DT is not for instantiating your > drivers. I claim you have only one device and that's > arm,sse710-host-base-sysctrl. If you create child node for one word, > that's not a device. The Host Base System Control [3] is the big block containing various functionalities (MMIO registers). Among the functionalities, the two remote cores registers (aka External system 0 and 1). The remote cores have two registers each. 1/ In the v1 patchset, a valid point was made by the community: Right now it seems somewhat tenuous to describe two consecutive 32-bit registers as separate "reg" entries, but *maybe* it's OK if that's all there ever is. However if it's actually going to end up needing several more additional MMIO and/or memory regions for other functionality, then describing each register and location individually is liable to get unmanageable really fast, and a higher-level functional grouping (e.g. these reset-related registers together as a single 8-byte region) would likely be a better design. The Exernal system registers are part of a bigger block with other functionality in place. MFD/syscon might be better way to use these registers. You never know in future you might want to use another set of 2-4 registers with a different functionality in another driver. I would see if it makes sense to put together a single binding for this "Host Base System Control" register (not sure what exactly that means). Use MFD/regmap you access parts of this block. The remoteproc driver can then be semi-generic (meaning applicable to group of similar platforms) based on the platform compatible and use this regmap to provide the functionality needed. 2/ There are many examples in the kernel that use syscon as a parent node of child nodes for devices located at an offset from the syscon base address. Please see these two examples [1][2]. I'm trying to follow a similar design if that makes sense. 3/ Since there are two registers for each remote core. I'm suggesting to set the size in the reg property to 8. The driver will read the match data to get the right offset to be used with regmap APIs. Suggested nodes: syscon@1a010000 { compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; reg = <0x1a010000 0x1000>; #address-cells = <1>; #size-cells = <1>; remoteproc@310 { compatible = "arm,sse710-extsys0"; reg = <0x310 8>; firmware-name = "es_flashfw.elf"; mboxes = <&mhu0_hes0 0 1>, <&mhu0_es0h 0 1>; mbox-names = "txes0", "rxes0"; memory-region = <&extsys0_vring0>, <&extsys0_vring1>; }; remoteproc@318 { compatible = "arm,sse710-extsys1"; reg = <0x318 8>; firmware-name = "es_flashfw.elf"; mboxes = <&mhu0_hes1 0 1>, <&mhu0_es1h 0 1>; mbox-names = "txes0", "rxes0"; memory-region = <&extsys1_vring0>, <&extsys1_vring1>; }; }; [1]: Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml syscon@20e00000 { compatible = "sprd,sc9863a-glbregs", "syscon", "simple-mfd"; reg = <0x20e00000 0x4000>; #address-cells = <1>; #size-cells = <1>; ranges = <0 0x20e00000 0x4000>; apahb_gate: apahb-gate@0 { compatible = "sprd,sc9863a-apahb-gate"; reg = <0x0 0x1020>; #clock-cells = <1>; }; }; [2]: Documentation/devicetree/bindings/arm/arm,juno-fpga-apb-regs.yaml: syscon@10000 { compatible = "arm,juno-fpga-apb-regs", "syscon", "simple-mfd"; reg = <0x010000 0x1000>; ranges = <0x0 0x10000 0x1000>; #address-cells = <1>; #size-cells = <1>; led@8,0 { compatible = "register-bit-led"; reg = <0x08 0x04>; offset = <0x08>; mask = <0x01>; label = "vexpress:0"; linux,default-trigger = "heartbeat"; default-state = "on"; }; }; [3]: https://developer.arm.com/documentation/102342/0000/Programmers-model/Register-descriptions/Host-Base-System-Control-register-summary Cheers, Abdellatif
On 23/09/2024 13:49, Abdellatif El Khlifi wrote: > Hi Krzysztof, > >>>>>>>>>>> + '#extsys-id': >>>>>>>>>> >>>>>>>>>> '#' is not correct for sure, that's not a cell specifier. >>>>>>>>>> >>>>>>>>>> But anyway, we do not accept in general instance IDs. >>>>>>>>> >>>>>>>>> I'm happy to replace the instance ID with another solution. >>>>>>>>> In our case the remoteproc instance does not have a base address >>>>>>>>> to use. So, we can't put remoteproc@address >>>>>>>>> >>>>>>>>> What do you recommend in this case please ? >>>>>>>> >>>>>>>> Waiting one month to respond is a great way to drop all context from my >>>>>>>> memory. The emails are not even available for me - gone from inbox. >>>>>>>> >>>>>>>> Bus addressing could note it. Or you have different devices, so >>>>>>>> different compatibles. Tricky to say, because you did not describe the >>>>>>>> hardware really and it's one month later... >>>>>>>> >>>>>>> >>>>>>> Sorry for waiting. I was in holidays. >>>>>>> >>>>>>> I'll add more documentation about the external system for more clarity [1]. >>>>>>> >>>>>>> Basically, Linux runs on the Cortex-A35. The External system is a >>>>>>> Cortex-M core. The Cortex-A35 can not access the memory of the Cortex-M. >>>>>>> It can only control Cortex-M core using the reset control and status registers mapped >>>>>>> in the memory space of the Cortex-A35. >>>>>> >>>>>> That's pretty standard. >>>>>> >>>>>> It does not explain me why bus addressing or different compatible are >>>>>> not sufficient here. >>>>> >>>>> Using an instance ID was a design choice. >>>>> I'm happy to replace it with the use of compatible and match data (WIP). >>>>> >>>>> The match data will be pointing to a data structure containing the right offsets >>>>> to be used with regmap APIs. >>>>> >>>>> syscon node is used to represent the Host Base System Control register area [1] >>>>> where the external system reset registers are mapped (EXT_SYS*). >>>>> >>>>> The nodes will look like this: >>>>> >>>>> syscon@1a010000 { >>>>> compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; >>>>> reg = <0x1a010000 0x1000>; >>>>> >>>>> #address-cells = <1>; >>>>> #size-cells = <1>; >>>>> >>>>> remoteproc@310 { >>>>> compatible = "arm,sse710-extsys0"; >>>>> reg = <0x310 4>; >>>> >>>> Uh, why do you create device nodes for one word? This really suggests it >>>> is part of parent device and your split is artificial. >>> >>> The external system registers (described by the remoteproc node) are part >>> of the parent device (the Host Base System Control register area) described >>> by syscon. >>> >>> In case of the external system 0 , its registers are located at offset 0x310 >>> (physical address: 0x1a010310) >>> >>> When instantiating the devices without @address, the DTC compiler >>> detects 2 nodes with the same name (remoteproc). >> >> There should be no children at all. DT is not for instantiating your >> drivers. I claim you have only one device and that's >> arm,sse710-host-base-sysctrl. If you create child node for one word, >> that's not a device. > > The Host Base System Control [3] is the big block containing various functionalities (MMIO registers). > Among the functionalities, the two remote cores registers (aka External system 0 and 1). > The remote cores have two registers each. > > 1/ In the v1 patchset, a valid point was made by the community: > > Right now it seems somewhat tenuous to describe two consecutive > 32-bit registers as separate "reg" entries, but *maybe* it's OK if that's ARM is not special, neither this hardware is. Therefore: 1. Each register as reg: nope, for obvious reasons. 2. One device for entire syscon: quite common, why do you think it is somehow odd? 3. If you quote other person, please provide the lore link, so I won't spend useless 5 minutes to find who said that or if it was even said... > all there ever is. However if it's actually going to end up needing several > more additional MMIO and/or memory regions for other functionality, then > describing each register and location individually is liable to get > unmanageable really fast, and a higher-level functional grouping (e.g. these > reset-related registers together as a single 8-byte region) would likely be > a better design. > > The Exernal system registers are part of a bigger block with other functionality in place. > MFD/syscon might be better way to use these registers. You never know in > future you might want to use another set of 2-4 registers with a different > functionality in another driver. > > I would see if it makes sense to put together a single binding for > this "Host Base System Control" register (not sure what exactly that means). > Use MFD/regmap you access parts of this block. The remoteproc driver can > then be semi-generic (meaning applicable to group of similar platforms) > based on the platform compatible and use this regmap to provide the > functionality needed. I don't understand how this lengthy semi-quote answers my concerns. Please write concise points as arguments to my questions. For example, I don't care what your remote proc driver does and it should not matter in the terms of this binding. > > 2/ There are many examples in the kernel that use syscon as a parent node of > child nodes for devices located at an offset from the syscon base address. > Please see these two examples [1][2]. I'm trying to follow a similar design if that > makes sense. Yeah, for separate devices. If you have two words without any resources, I claim you might not have here any separate devices or "not separate enough", because all this is somehow fluid. Remote core sounds like separate device, but all your arguments about need of extid which cannot be used in reg does not support this case. The example in the binding is also not complete - missing rest of devices - which does not help. > > 3/ Since there are two registers for each remote core. I'm suggesting to set the > size in the reg property to 8. How is this related? > The driver will read the match data to get the right > offset to be used with regmap APIs. Sorry, no talks about driver. Don't care, at least in this context. You can completely omit address space from children in DT and everything will work fine and look fine from bindings point of view. > > Suggested nodes: > > > syscon@1a010000 { > compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; > reg = <0x1a010000 0x1000>; > > #address-cells = <1>; > #size-cells = <1>; > > remoteproc@310 { > compatible = "arm,sse710-extsys0"; > reg = <0x310 8>; > firmware-name = "es_flashfw.elf"; > mboxes = <&mhu0_hes0 0 1>, <&mhu0_es0h 0 1>; > mbox-names = "txes0", "rxes0"; > memory-region = <&extsys0_vring0>, <&extsys0_vring1>; > }; > > remoteproc@318 { > compatible = "arm,sse710-extsys1"; > reg = <0x318 8>; > firmware-name = "es_flashfw.elf"; Same firmware? Always or only depends? > mboxes = <&mhu0_hes1 0 1>, <&mhu0_es1h 0 1>; > mbox-names = "txes0", "rxes0"; > memory-region = <&extsys1_vring0>, <&extsys1_vring1>; The rest of resources support the idea of two children but I still have doubts about need of identifying remote instances. Looking at your driver it is totally not needed. Your driver just duplicates the regs here, so it's a proof that you are not using DT correctly. > }; > }; > > > [1]: Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml > > syscon@20e00000 { > compatible = "sprd,sc9863a-glbregs", "syscon", "simple-mfd"; > reg = <0x20e00000 0x4000>; > #address-cells = <1>; > #size-cells = <1>; > ranges = <0 0x20e00000 0x4000>; > > apahb_gate: apahb-gate@0 { > compatible = "sprd,sc9863a-apahb-gate"; > reg = <0x0 0x1020>; Well, size 1020, but please never use sprd as an example. You can as well point to a buggy code and say that "I can implement bugs as well, because there are bugs already". Same for few other almost abandoned, poorly maintained platforms. > #clock-cells = <1>; > }; > }; > > > [2]: Documentation/devicetree/bindings/arm/arm,juno-fpga-apb-regs.yaml: > > syscon@10000 { > compatible = "arm,juno-fpga-apb-regs", "syscon", "simple-mfd"; > reg = <0x010000 0x1000>; > ranges = <0x0 0x10000 0x1000>; > #address-cells = <1>; > #size-cells = <1>; > > led@8,0 { > compatible = "register-bit-led"; register-bit-led... what do you want to prove? You will find clocks-per-reg and try to implement them? That's known no-go. Best regards, Krzysztof
Hi Krzysztof, > >>>>>>>>>>> + '#extsys-id': > >>>>>>>>>> > >>>>>>>>>> '#' is not correct for sure, that's not a cell specifier. > >>>>>>>>>> > >>>>>>>>>> But anyway, we do not accept in general instance IDs. > >>>>>>>>> > >>>>>>>>> I'm happy to replace the instance ID with another solution. > >>>>>>>>> In our case the remoteproc instance does not have a base address > >>>>>>>>> to use. So, we can't put remoteproc@address > >>>>>>>>> > >>>>>>>>> What do you recommend in this case please ? > >>>>>>>> > >>>>>>>> Waiting one month to respond is a great way to drop all context from my > >>>>>>>> memory. The emails are not even available for me - gone from inbox. > >>>>>>>> > >>>>>>>> Bus addressing could note it. Or you have different devices, so > >>>>>>>> different compatibles. Tricky to say, because you did not describe the > >>>>>>>> hardware really and it's one month later... > >>>>>>>> > >>>>>>> > >>>>>>> Sorry for waiting. I was in holidays. > >>>>>>> > >>>>>>> I'll add more documentation about the external system for more clarity [1]. > >>>>>>> > >>>>>>> Basically, Linux runs on the Cortex-A35. The External system is a > >>>>>>> Cortex-M core. The Cortex-A35 can not access the memory of the Cortex-M. > >>>>>>> It can only control Cortex-M core using the reset control and status registers mapped > >>>>>>> in the memory space of the Cortex-A35. > >>>>>> > >>>>>> That's pretty standard. > >>>>>> > >>>>>> It does not explain me why bus addressing or different compatible are > >>>>>> not sufficient here. > >>>>> > >>>>> Using an instance ID was a design choice. > >>>>> I'm happy to replace it with the use of compatible and match data (WIP). > >>>>> > >>>>> The match data will be pointing to a data structure containing the right offsets > >>>>> to be used with regmap APIs. > >>>>> > >>>>> syscon node is used to represent the Host Base System Control register area [1] > >>>>> where the external system reset registers are mapped (EXT_SYS*). > >>>>> > >>>>> The nodes will look like this: > >>>>> > >>>>> syscon@1a010000 { > >>>>> compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; > >>>>> reg = <0x1a010000 0x1000>; > >>>>> > >>>>> #address-cells = <1>; > >>>>> #size-cells = <1>; > >>>>> > >>>>> remoteproc@310 { > >>>>> compatible = "arm,sse710-extsys0"; > >>>>> reg = <0x310 4>; > >>>> > >>>> Uh, why do you create device nodes for one word? This really suggests it > >>>> is part of parent device and your split is artificial. > >>> > >>> The external system registers (described by the remoteproc node) are part > >>> of the parent device (the Host Base System Control register area) described > >>> by syscon. > >>> > >>> In case of the external system 0 , its registers are located at offset 0x310 > >>> (physical address: 0x1a010310) > >>> > >>> When instantiating the devices without @address, the DTC compiler > >>> detects 2 nodes with the same name (remoteproc). > >> > >> There should be no children at all. DT is not for instantiating your > >> drivers. I claim you have only one device and that's > >> arm,sse710-host-base-sysctrl. If you create child node for one word, > >> that's not a device. > > > > The Host Base System Control [3] is the big block containing various functionalities (MMIO registers). > > Among the functionalities, the two remote cores registers (aka External system 0 and 1). > > The remote cores have two registers each. > > > > 1/ In the v1 patchset, a valid point was made by the community: > > > > Right now it seems somewhat tenuous to describe two consecutive > > 32-bit registers as separate "reg" entries, but *maybe* it's OK if that's > > ARM is not special, neither this hardware is. Therefore: > 1. Each register as reg: nope, for obvious reasons. > 2. One device for entire syscon: quite common, why do you think it is > somehow odd? > 3. If you quote other person, please provide the lore link, so I won't > spend useless 5 minutes to find who said that or if it was even said... Please have a look at this lore link [1]. The idea is to add syscon and regmap support which I did in the v2 patchset. [1]: https://lore.kernel.org/all/ZfMVcQsmgQUXXcef@bogus/ > > > all there ever is. However if it's actually going to end up needing several > > more additional MMIO and/or memory regions for other functionality, then > > describing each register and location individually is liable to get > > unmanageable really fast, and a higher-level functional grouping (e.g. these > > reset-related registers together as a single 8-byte region) would likely be > > a better design. > > > > The Exernal system registers are part of a bigger block with other functionality in place. > > MFD/syscon might be better way to use these registers. You never know in > > future you might want to use another set of 2-4 registers with a different > > functionality in another driver. > > > > I would see if it makes sense to put together a single binding for > > this "Host Base System Control" register (not sure what exactly that means). > > Use MFD/regmap you access parts of this block. The remoteproc driver can > > then be semi-generic (meaning applicable to group of similar platforms) > > based on the platform compatible and use this regmap to provide the > > functionality needed. > > I don't understand how this lengthy semi-quote answers my concerns. > Please write concise points as arguments to my questions. > > For example, I don't care what your remote proc driver does and it > should not matter in the terms of this binding. I just wanted to show why we are using syscon based on the arguments of other reviewers. > > > > > 2/ There are many examples in the kernel that use syscon as a parent node of > > child nodes for devices located at an offset from the syscon base address. > > Please see these two examples [1][2]. I'm trying to follow a similar design if that > > makes sense. > > Yeah, for separate devices. If you have two words without any resources, > I claim you might not have here any separate devices or "not separate > enough", because all this is somehow fluid. Remote core sounds like > separate device, but all your arguments about need of extid which cannot > be used in reg does not support this case. > > The example in the binding is also not complete - missing rest of > devices - which does not help. Here I would like to explain the current suggestion and suggest an alternative solution. 1/ For more clarity, here is a complete example of use of both remote cores at the same time: syscon@1a010000 { compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; reg = <0x1a010000 0x1000>; #address-cells = <1>; #size-cells = <1>; remoteproc@310 { compatible = "arm,sse710-extsys0"; reg = <0x310 8>; firmware-name = "es0_flashfw.elf"; mboxes = <&mhu0_hes0 0 1>, <&mhu0_es0h 0 1>; mbox-names = "txes0", "rxes0"; memory-region = <&extsys0_vring0>, <&extsys0_vring1>; }; remoteproc@318 { compatible = "arm,sse710-extsys1"; reg = <0x318 8>; firmware-name = "es1_flashfw.elf"; mboxes = <&mhu0_hes1 0 1>, <&mhu0_es1h 0 1>; mbox-names = "txes0", "rxes0"; memory-region = <&extsys1_vring0>, <&extsys1_vring1>; }; }; Here we have 2 cores, each one have 2 registers mapped respectively at 0x1a010310 and 0x1a010318. Definetly these cores have seperate HW resources associated with them which are the MHUs (mailboxes HW). There are 2 pairs of MHUs associated with each core. These mailbox peripherals are obviously seperate. Furthermore, the vring buffers used for communication are seperate. Moreover, the remote cores are independent. They are not SMP cores of one processor. They can have different default firmware to use. In this example es0_flashfw.elf and es1_flashfw.elf The current HW implementation (Corstone-1000) provides one remote core only. However, the second core control registers are at 0x1a010318 do exist. Support for a second core is taken into consideration in this work to help end users who want to add a second core to their HW. 2/ Here I'm suggesting an alternative solution by using one remoteproc node for both cores as follows: syscon@1a010000 { compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; reg = <0x1a010000 0x1000>; remoteproc { compatible = "arm,sse710-extsys"; firmware-name = "es0_flashfw.elf"; mboxes = <&mhu0_hes0 0 1>, <&mhu0_es0h 0 1>, <&mhu0_hes1 0 1>, <&mhu0_es1h 0 1>; mbox-names = "txes0", "rxes0", "txes1", "rxes1"; memory-region = <&extsys0_vring0>, <&extsys0_vring1>, <&extsys1_vring0>, <&extsys1_vring1>; }; }; Does this meet your expectations please ? > > > > > 3/ Since there are two registers for each remote core. I'm suggesting to set the > > size in the reg property to 8. > > How is this related? > > > The driver will read the match data to get the right > > offset to be used with regmap APIs. > > Sorry, no talks about driver. Don't care, at least in this context. > > You can completely omit address space from children in DT and everything > will work fine and look fine from bindings point of view. > > > > > Suggested nodes: > > > > > > syscon@1a010000 { > > compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; > > reg = <0x1a010000 0x1000>; > > > > #address-cells = <1>; > > #size-cells = <1>; > > > > remoteproc@310 { > > compatible = "arm,sse710-extsys0"; > > reg = <0x310 8>; > > firmware-name = "es_flashfw.elf"; > > mboxes = <&mhu0_hes0 0 1>, <&mhu0_es0h 0 1>; > > mbox-names = "txes0", "rxes0"; > > memory-region = <&extsys0_vring0>, <&extsys0_vring1>; > > }; > > > > remoteproc@318 { > > compatible = "arm,sse710-extsys1"; > > reg = <0x318 8>; > > firmware-name = "es_flashfw.elf"; > > Same firmware? Always or only depends? The firmware of the second core depends on the end user choice. Currently the second core is not implemented in the HW. Users who want to tweak Corstone-1000 HW can add a second core. Kind regards Abdellatif
On 23/09/2024 19:19, Abdellatif El Khlifi wrote: >>> >>> The Host Base System Control [3] is the big block containing various functionalities (MMIO registers). >>> Among the functionalities, the two remote cores registers (aka External system 0 and 1). >>> The remote cores have two registers each. >>> >>> 1/ In the v1 patchset, a valid point was made by the community: >>> >>> Right now it seems somewhat tenuous to describe two consecutive >>> 32-bit registers as separate "reg" entries, but *maybe* it's OK if that's >> >> ARM is not special, neither this hardware is. Therefore: >> 1. Each register as reg: nope, for obvious reasons. >> 2. One device for entire syscon: quite common, why do you think it is >> somehow odd? >> 3. If you quote other person, please provide the lore link, so I won't >> spend useless 5 minutes to find who said that or if it was even said... > > Please have a look at this lore link [1]. The idea is to add syscon > and regmap support which I did in the v2 patchset. > > [1]: https://lore.kernel.org/all/ZfMVcQsmgQUXXcef@bogus/ There is nothing there about DT bindings. We do not talk here about drivers. MFD and regmap are Linux driver stuff, not bindings. I said nothing about not using MFD, regmap or whatever driver stuff you want. We talk *only* about bindings. Syscon is mentioned there but I am sorry - that quite a stretch to call a block syscon just because you want regmap. > >> >>> all there ever is. However if it's actually going to end up needing several >>> more additional MMIO and/or memory regions for other functionality, then >>> describing each register and location individually is liable to get >>> unmanageable really fast, and a higher-level functional grouping (e.g. these >>> reset-related registers together as a single 8-byte region) would likely be >>> a better design. >>> >>> The Exernal system registers are part of a bigger block with other functionality in place. >>> MFD/syscon might be better way to use these registers. You never know in >>> future you might want to use another set of 2-4 registers with a different >>> functionality in another driver. >>> >>> I would see if it makes sense to put together a single binding for >>> this "Host Base System Control" register (not sure what exactly that means). >>> Use MFD/regmap you access parts of this block. The remoteproc driver can >>> then be semi-generic (meaning applicable to group of similar platforms) >>> based on the platform compatible and use this regmap to provide the >>> functionality needed. >> >> I don't understand how this lengthy semi-quote answers my concerns. >> Please write concise points as arguments to my questions. >> >> For example, I don't care what your remote proc driver does and it >> should not matter in the terms of this binding. > > I just wanted to show why we are using syscon based on the arguments > of other reviewers. > >> >>> >>> 2/ There are many examples in the kernel that use syscon as a parent node of >>> child nodes for devices located at an offset from the syscon base address. >>> Please see these two examples [1][2]. I'm trying to follow a similar design if that >>> makes sense. >> >> Yeah, for separate devices. If you have two words without any resources, >> I claim you might not have here any separate devices or "not separate >> enough", because all this is somehow fluid. Remote core sounds like >> separate device, but all your arguments about need of extid which cannot >> be used in reg does not support this case. >> >> The example in the binding is also not complete - missing rest of >> devices - which does not help. > > Here I would like to explain the current suggestion and suggest an alternative solution. > > 1/ For more clarity, here is a complete example of use of both remote cores > at the same time: > > syscon@1a010000 { > compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; > reg = <0x1a010000 0x1000>; > > #address-cells = <1>; > #size-cells = <1>; > > remoteproc@310 { > compatible = "arm,sse710-extsys0"; > reg = <0x310 8>; > firmware-name = "es0_flashfw.elf"; > mboxes = <&mhu0_hes0 0 1>, <&mhu0_es0h 0 1>; > mbox-names = "txes0", "rxes0"; > memory-region = <&extsys0_vring0>, <&extsys0_vring1>; > }; > > remoteproc@318 { > compatible = "arm,sse710-extsys1"; > reg = <0x318 8>; > firmware-name = "es1_flashfw.elf"; > mboxes = <&mhu0_hes1 0 1>, <&mhu0_es1h 0 1>; > mbox-names = "txes0", "rxes0"; > memory-region = <&extsys1_vring0>, <&extsys1_vring1>; > }; > }; > > Here we have 2 cores, each one have 2 registers mapped respectively > at 0x1a010310 and 0x1a010318. All this looks fine, resources are indeed reasonable, except that I still do not understand why do you need to call them 0 and 1 (now via compatible). Your driver code shows this nicely - it is entirely redundant! The 'reg' - so the base - is already there! You just duplicate it with the extsys_id, instead of relying on the base. So think what is the point of 'reg' property if you do not use it? > > Definetly these cores have seperate HW resources associated with them > which are the MHUs (mailboxes HW). There are 2 pairs of MHUs associated > with each core. These mailbox peripherals are obviously seperate. > Furthermore, the vring buffers used for communication are seperate. > > Moreover, the remote cores are independent. They are not SMP cores of one processor. > > They can have different default firmware to use. In this example es0_flashfw.elf > and es1_flashfw.elf > > The current HW implementation (Corstone-1000) provides one remote core only. > However, the second core control registers are at 0x1a010318 do exist. > > Support for a second core is taken into consideration in this work to help > end users who want to add a second core to their HW. > > 2/ Here I'm suggesting an alternative solution by using one remoteproc node for both cores as > follows: > > syscon@1a010000 { > compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; > reg = <0x1a010000 0x1000>; > > remoteproc { > compatible = "arm,sse710-extsys"; > firmware-name = "es0_flashfw.elf"; > mboxes = <&mhu0_hes0 0 1>, <&mhu0_es0h 0 1>, <&mhu0_hes1 0 1>, <&mhu0_es1h 0 1>; > mbox-names = "txes0", "rxes0", "txes1", "rxes1"; > memory-region = <&extsys0_vring0>, <&extsys0_vring1>, <&extsys1_vring0>, <&extsys1_vring1>; > }; > }; > > Does this meet your expectations please ? > >> >>> >>> 3/ Since there are two registers for each remote core. I'm suggesting to set the >>> size in the reg property to 8. >> >> How is this related? >> >>> The driver will read the match data to get the right >>> offset to be used with regmap APIs. >> >> Sorry, no talks about driver. Don't care, at least in this context. >> >> You can completely omit address space from children in DT and everything >> will work fine and look fine from bindings point of view. >> >>> >>> Suggested nodes: >>> >>> >>> syscon@1a010000 { >>> compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; >>> reg = <0x1a010000 0x1000>; >>> >>> #address-cells = <1>; >>> #size-cells = <1>; >>> >>> remoteproc@310 { >>> compatible = "arm,sse710-extsys0"; >>> reg = <0x310 8>; >>> firmware-name = "es_flashfw.elf"; >>> mboxes = <&mhu0_hes0 0 1>, <&mhu0_es0h 0 1>; >>> mbox-names = "txes0", "rxes0"; >>> memory-region = <&extsys0_vring0>, <&extsys0_vring1>; >>> }; >>> >>> remoteproc@318 { >>> compatible = "arm,sse710-extsys1"; >>> reg = <0x318 8>; >>> firmware-name = "es_flashfw.elf"; >> >> Same firmware? Always or only depends? > > The firmware of the second core depends on the end user choice. > Currently the second core is not implemented in the HW. > Users who want to tweak Corstone-1000 HW can add > a second core. Two cores make more sense in such case. Best regards, Krzysztof
On 22/08/2024 6:09 pm, Abdellatif El Khlifi wrote: > Add devicetree binding schema for the External Systems remote processors > > The External Systems remote processors are provided on the Corstone-1000 > IoT Reference Design Platform via the SSE-710 subsystem. > > For more details about the External Systems, please see Corstone SSE-710 > subsystem features [1]. > > [1]: https://developer.arm.com/documentation/102360/0000/Overview-of-Corstone-1000/Corstone-SSE-710-subsystem-features > > Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> > --- > .../remoteproc/arm,sse710-extsys.yaml | 90 +++++++++++++++++++ > 1 file changed, 90 insertions(+) > create mode 100644 Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml > > diff --git a/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml b/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml > new file mode 100644 > index 000000000000..827ba8d962f1 > --- /dev/null > +++ b/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml > @@ -0,0 +1,90 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/remoteproc/arm,sse710-extsys.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: SSE-710 External System Remote Processor Thing is, this is not describing SSE-710. As far as I can work out, it is describing the firmware and hardware that a particular example implementation of the Corstone-1000 kit has chosen to put in the "external system" hole in the SSE-710 within that kit. If I license SSE-710 alone or even the Corstone-1000 kit, I can put whatever I want in *my* implementation of those subsystems, so there clearly cannot possibly be a common binding for that. For instance what if I decide to combine a Cortex-M core plus a radio and some other glue as my external subsystem? Do we have dozens of remoteproc bindings and drivers for weird fixed-function remoteprocs whose "firmware-name" implies a Bluetooth protocol stack? No, we treat them as Bluetooth controller devices. Look at devicetree/bindings/sound/fsl,rpmsg.yaml - it's even unashamedly an rpmsg client, but it's still not abusing the remoteproc subsystem because its function to the host OS is as an audio controller, not an arbitrarily configurable processor. As I said before, all SSE-710 actually implements is a reset mechanism, so it only seems logical to model it as a reset controller, e.g. something like: hbsys: syscon@xyz { compatible = "arm,sse710-host-base-sysctrl", "syscon"; reg = <xyz>; #reset-cells = <1>; }; something { ... resets = <&hbsys 0>; }; something-else { ... resets = <&hbsys 1>; }; Then if there is actually any meaningful functionality in the default extsys0 firmware preloaded on the FPGA setup then define a binding for "arm,corstone1000-an550-extsys0" to describe whatever that actually does. If a user chooses to create and load their own different firmware, they're going to need their own binding and driver for whatever *that* firmware does. FWIW, driver-wise the mapping to the reset API seems straightforward - .assert hits RST_REQ, .deassert clears CPUWAIT (.status is possibly a combination of CPUWAIT and RST_ACK?) Thanks, Robin. > + > +maintainers: > + - Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> > + - Hugues Kamba Mpiana <hugues.kambampiana@arm.com> > + > +description: | > + SSE-710 is an heterogeneous subsystem supporting up to two remote > + processors aka the External Systems. > + > +properties: > + compatible: > + enum: > + - arm,sse710-extsys > + > + firmware-name: > + description: > + The default name of the firmware to load to the remote processor. > + > + '#extsys-id': > + description: > + The External System ID. > + enum: [0, 1] > + > + mbox-names: > + items: > + - const: txes0 > + - const: rxes0 > + > + mboxes: > + description: > + The list of Message Handling Unit (MHU) channels used for bidirectional > + communication. This property is only required if the virtio-based Rpmsg > + messaging bus is used. For more details see the Arm MHUv2 Mailbox > + Controller at devicetree/bindings/mailbox/arm,mhuv2.yaml > + > + minItems: 2 > + maxItems: 2 > + > + memory-region: > + description: > + If present, a phandle for a reserved memory area that used for vdev > + buffer, resource table, vring region and others used by the remote > + processor. > + minItems: 2 > + maxItems: 32 > + > +required: > + - compatible > + - firmware-name > + - '#extsys-id' > + > +additionalProperties: false > + > +examples: > + - | > + reserved-memory { > + #address-cells = <2>; > + #size-cells = <2>; > + > + extsys0_vring0: vdev0vring0@82001000 { > + reg = <0 0x82001000 0 0x8000>; > + no-map; > + }; > + > + extsys0_vring1: vdev0vring1@82009000 { > + reg = <0 0x82009000 0 0x8000>; > + no-map; > + }; > + }; > + > + syscon@1a010000 { > + compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; > + reg = <0x1a010000 0x1000>; > + > + extsys0 { > + compatible = "arm,sse710-extsys"; > + #extsys-id = <0>; > + firmware-name = "es_flashfw.elf"; > + mbox-names = "txes0", "rxes0"; > + mboxes = <&mhu0_hes0 0 1>, <&mhu0_es0h 0 1>; > + memory-region = <&extsys0_vring0>, <&extsys0_vring1>; > + }; > + };
Hello folks, > On 22/08/2024 6:09 pm, Abdellatif El Khlifi wrote: > > Add devicetree binding schema for the External Systems remote processors > > > > The External Systems remote processors are provided on the Corstone-1000 > > IoT Reference Design Platform via the SSE-710 subsystem. > > > > For more details about the External Systems, please see Corstone SSE-710 > > subsystem features [1]. > > > > [1]: https://developer.arm.com/documentation/102360/0000/Overview-of-Corstone-1000/Corstone-SSE-710-subsystem-features > > > > Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> > > --- > > .../remoteproc/arm,sse710-extsys.yaml | 90 +++++++++++++++++++ > > 1 file changed, 90 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml > > > > diff --git a/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml b/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml > > new file mode 100644 > > index 000000000000..827ba8d962f1 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml > > @@ -0,0 +1,90 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/remoteproc/arm,sse710-extsys.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: SSE-710 External System Remote Processor > > Thing is, this is not describing SSE-710. As far as I can work out, it is > describing the firmware and hardware that a particular example > implementation of the Corstone-1000 kit has chosen to put in the "external > system" hole in the SSE-710 within that kit. > > If I license SSE-710 alone or even the Corstone-1000 kit, I can put whatever > I want in *my* implementation of those subsystems, so there clearly cannot > possibly be a common binding for that. > > For instance what if I decide to combine a Cortex-M core plus a radio and > some other glue as my external subsystem? Do we have dozens of remoteproc > bindings and drivers for weird fixed-function remoteprocs whose > "firmware-name" implies a Bluetooth protocol stack? No, we treat them as > Bluetooth controller devices. Look at > devicetree/bindings/sound/fsl,rpmsg.yaml - it's even unashamedly an rpmsg > client, but it's still not abusing the remoteproc subsystem because its > function to the host OS is as an audio controller, not an arbitrarily > configurable processor. > > As I said before, all SSE-710 actually implements is a reset mechanism, so > it only seems logical to model it as a reset controller, e.g. something > like: > > hbsys: syscon@xyz { > compatible = "arm,sse710-host-base-sysctrl", "syscon"; > reg = <xyz>; > #reset-cells = <1>; > }; > > something { > ... > resets = <&hbsys 0>; > }; > > something-else { > ... > resets = <&hbsys 1>; > }; > > > Then if there is actually any meaningful functionality in the default > extsys0 firmware preloaded on the FPGA setup then define a binding for > "arm,corstone1000-an550-extsys0" to describe whatever that actually does. If > a user chooses to create and load their own different firmware, they're > going to need their own binding and driver for whatever *that* firmware > does. > > FWIW, driver-wise the mapping to the reset API seems straightforward - > .assert hits RST_REQ, .deassert clears CPUWAIT (.status is possibly a > combination of CPUWAIT and RST_ACK?) We are happy to follow what Robin recommended. This can be summarized in two parts: Part 1: Writing an SSE-710 reset controller driver An SSE-710 reset controller driver that switches on/off the external system. The driver will be helpful for products using SSE-710. So whoever licenses Corstone-1000 or SSE-710 will find the reset controller driver helpful. They can use it with their implementation of the external system. Note: It's likely that the external systems the end user will be using in their products will be different from the Corstone-1000 external system given as an example. Differences in the memory configuration, subsystem involved, boot roms configurations, ... These differences mean that the end user will need to write their own driver which might or might not be a remoteproc driver (e.g: Bluetooth, audio, ...). Part 2: Corstone-1000 remoteproc driver Corstone-1000 HW is being upgraded to support memory sharing between the Cortex-A35 (Linux) and the external system (Cortex-M3). Once the HW is ready, we can write a Corstone-1000 remoteproc driver able to reload the external system firmware and doing communication with the MHUs. This remoteproc driver can use the reset subsystem APIs to call the SSE-710 reset controller driver to switch on/off the external system (already developed in part 1). Impact on the current patchset: - The current remoteproc patchset will be paused until the HW is upgraded. - In CY25Q1, I'll send to the mailing list the SSE-710 reset controller bindings and a driver under the Reset Controller subsystem. Thank you for your support and expertise. Cheers, Abdellatif
diff --git a/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml b/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml new file mode 100644 index 000000000000..827ba8d962f1 --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/arm,sse710-extsys.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SSE-710 External System Remote Processor + +maintainers: + - Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> + - Hugues Kamba Mpiana <hugues.kambampiana@arm.com> + +description: | + SSE-710 is an heterogeneous subsystem supporting up to two remote + processors aka the External Systems. + +properties: + compatible: + enum: + - arm,sse710-extsys + + firmware-name: + description: + The default name of the firmware to load to the remote processor. + + '#extsys-id': + description: + The External System ID. + enum: [0, 1] + + mbox-names: + items: + - const: txes0 + - const: rxes0 + + mboxes: + description: + The list of Message Handling Unit (MHU) channels used for bidirectional + communication. This property is only required if the virtio-based Rpmsg + messaging bus is used. For more details see the Arm MHUv2 Mailbox + Controller at devicetree/bindings/mailbox/arm,mhuv2.yaml + + minItems: 2 + maxItems: 2 + + memory-region: + description: + If present, a phandle for a reserved memory area that used for vdev + buffer, resource table, vring region and others used by the remote + processor. + minItems: 2 + maxItems: 32 + +required: + - compatible + - firmware-name + - '#extsys-id' + +additionalProperties: false + +examples: + - | + reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + + extsys0_vring0: vdev0vring0@82001000 { + reg = <0 0x82001000 0 0x8000>; + no-map; + }; + + extsys0_vring1: vdev0vring1@82009000 { + reg = <0 0x82009000 0 0x8000>; + no-map; + }; + }; + + syscon@1a010000 { + compatible = "arm,sse710-host-base-sysctrl", "simple-mfd", "syscon"; + reg = <0x1a010000 0x1000>; + + extsys0 { + compatible = "arm,sse710-extsys"; + #extsys-id = <0>; + firmware-name = "es_flashfw.elf"; + mbox-names = "txes0", "rxes0"; + mboxes = <&mhu0_hes0 0 1>, <&mhu0_es0h 0 1>; + memory-region = <&extsys0_vring0>, <&extsys0_vring1>; + }; + };
Add devicetree binding schema for the External Systems remote processors The External Systems remote processors are provided on the Corstone-1000 IoT Reference Design Platform via the SSE-710 subsystem. For more details about the External Systems, please see Corstone SSE-710 subsystem features [1]. [1]: https://developer.arm.com/documentation/102360/0000/Overview-of-Corstone-1000/Corstone-SSE-710-subsystem-features Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> --- .../remoteproc/arm,sse710-extsys.yaml | 90 +++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 Documentation/devicetree/bindings/remoteproc/arm,sse710-extsys.yaml