| Message ID | 20220213195832.27932-5-cristian.marussi@arm.com |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | None | expand |
| Context | Check | Description |
|---|---|---|
| robh/patch-applied | success | |
| robh/checkpatch | success | |
| robh/dtbs-check | success | |
| robh/dt-meta-schema | fail | build log |
On Sun, Feb 13, 2022 at 07:58:28PM +0000, Cristian Marussi wrote: > SCMI protocols in the platform can optionally signal to the OSPM agent > the expected execution latency for a specific resource/operation pair. > > Introduce an SCMI system wide optional property to describe a global time > threshold which can be configured on a per-platform base to determine the > opportunity, or not, for an SCMI command advertised to have a higher > latency than the threshold, to be considered for atomic operations: > high-latency SCMI synchronous commands should be preferably issued in the > usual non-atomic mode. > > Cc: Rob Herring <robh+dt@kernel.org> > Cc: devicetree@vger.kernel.org > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > --- > v3 --> v4 > - renamed property to atomic-threshold-us > v1 --> v2 > - rephrased the property description > --- > .../devicetree/bindings/firmware/arm,scmi.yaml | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > index eae15df36eef..3ffa669b91af 100644 > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > @@ -81,6 +81,15 @@ properties: > '#size-cells': > const: 0 > Hi Rob, gentle ping ... any feedback on this SCMI DT addition ? (beside the brain-dead error of mine down below in the example still to be fixed...my bad) > + atomic-threshold-us: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: > + An optional time value, expressed in microseconds, representing, on this > + platform, the threshold above which any SCMI command, advertised to have > + an higher-than-threshold execution latency, should not be considered for > + atomic mode of operation, even if requested. > + If left unconfigured defaults to zero. > + > arm,smc-id: > $ref: /schemas/types.yaml#/definitions/uint32 > description: > @@ -264,6 +273,8 @@ examples: > #address-cells = <1>; > #size-cells = <0>; > > + atomic_threshold = <10000>; > + ...this example clearly still needs to be renamed to 'atomic-threshold-us' Thanks, Cristian
On Sun, 13 Feb 2022 19:58:28 +0000, Cristian Marussi wrote: > SCMI protocols in the platform can optionally signal to the OSPM agent > the expected execution latency for a specific resource/operation pair. > > Introduce an SCMI system wide optional property to describe a global time > threshold which can be configured on a per-platform base to determine the > opportunity, or not, for an SCMI command advertised to have a higher > latency than the threshold, to be considered for atomic operations: > high-latency SCMI synchronous commands should be preferably issued in the > usual non-atomic mode. > > Cc: Rob Herring <robh+dt@kernel.org> > Cc: devicetree@vger.kernel.org > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > --- > v3 --> v4 > - renamed property to atomic-threshold-us > v1 --> v2 > - rephrased the property description > --- > .../devicetree/bindings/firmware/arm,scmi.yaml | 11 +++++++++++ > 1 file changed, 11 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/firmware/arm,scmi.yaml: properties:atomic-threshold-us: '$ref' should not be valid under {'const': '$ref'} hint: Standard unit suffix properties don't need a type $ref from schema $id: http://devicetree.org/meta-schemas/core.yaml# /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/firmware/arm,scmi.yaml: ignoring, error in schema: properties: atomic-threshold-us Documentation/devicetree/bindings/firmware/arm,scmi.example.dt.yaml:0:0: /example-0/firmware/scmi: failed to match any schema with compatible: ['arm,scmi'] Documentation/devicetree/bindings/firmware/arm,scmi.example.dt.yaml:0:0: /example-1/firmware/scmi: failed to match any schema with compatible: ['arm,scmi-smc'] Documentation/devicetree/bindings/mailbox/arm,mhu.example.dt.yaml:0:0: /example-1/firmware/scmi: failed to match any schema with compatible: ['arm,scmi'] doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/1592136 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. 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.
On Sun, Feb 13, 2022 at 07:58:28PM +0000, Cristian Marussi wrote: > SCMI protocols in the platform can optionally signal to the OSPM agent > the expected execution latency for a specific resource/operation pair. > > Introduce an SCMI system wide optional property to describe a global time > threshold which can be configured on a per-platform base to determine the > opportunity, or not, for an SCMI command advertised to have a higher > latency than the threshold, to be considered for atomic operations: > high-latency SCMI synchronous commands should be preferably issued in the > usual non-atomic mode. > > Cc: Rob Herring <robh+dt@kernel.org> > Cc: devicetree@vger.kernel.org > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > --- > v3 --> v4 > - renamed property to atomic-threshold-us > v1 --> v2 > - rephrased the property description > --- > .../devicetree/bindings/firmware/arm,scmi.yaml | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > index eae15df36eef..3ffa669b91af 100644 > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > @@ -81,6 +81,15 @@ properties: > '#size-cells': > const: 0 > > + atomic-threshold-us: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: > + An optional time value, expressed in microseconds, representing, on this > + platform, the threshold above which any SCMI command, advertised to have > + an higher-than-threshold execution latency, should not be considered for > + atomic mode of operation, even if requested. > + If left unconfigured defaults to zero. This can be expressed as 'default: 0'. > + > arm,smc-id: > $ref: /schemas/types.yaml#/definitions/uint32 > description: > @@ -264,6 +273,8 @@ examples: > #address-cells = <1>; > #size-cells = <0>; > > + atomic_threshold = <10000>; > + > scmi_devpd: protocol@11 { > reg = <0x11>; > #power-domain-cells = <1>; > -- > 2.17.1 > >
On Tue, Feb 15, 2022 at 03:03:52PM -0600, Rob Herring wrote: > On Sun, Feb 13, 2022 at 07:58:28PM +0000, Cristian Marussi wrote: > > SCMI protocols in the platform can optionally signal to the OSPM agent > > the expected execution latency for a specific resource/operation pair. > > > > Introduce an SCMI system wide optional property to describe a global time > > threshold which can be configured on a per-platform base to determine the > > opportunity, or not, for an SCMI command advertised to have a higher > > latency than the threshold, to be considered for atomic operations: > > high-latency SCMI synchronous commands should be preferably issued in the > > usual non-atomic mode. > > > > Cc: Rob Herring <robh+dt@kernel.org> > > Cc: devicetree@vger.kernel.org > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > > --- > > v3 --> v4 > > - renamed property to atomic-threshold-us > > v1 --> v2 > > - rephrased the property description > > --- > > .../devicetree/bindings/firmware/arm,scmi.yaml | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > index eae15df36eef..3ffa669b91af 100644 > > --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml > > @@ -81,6 +81,15 @@ properties: > > '#size-cells': > > const: 0 > > > > + atomic-threshold-us: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: > > + An optional time value, expressed in microseconds, representing, on this > > + platform, the threshold above which any SCMI command, advertised to have > > + an higher-than-threshold execution latency, should not be considered for > > + atomic mode of operation, even if requested. > > > + If left unconfigured defaults to zero. > > This can be expressed as 'default: 0'. > Thanks, I'll fix next V5 together with the warnings/errors fixes exposed by your DT check bot (I had an obsoleted dtschema package indeed...) Possibly tomorrow I'll send a v5. Thanks, Cristian
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index eae15df36eef..3ffa669b91af 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -81,6 +81,15 @@ properties: '#size-cells': const: 0 + atomic-threshold-us: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + An optional time value, expressed in microseconds, representing, on this + platform, the threshold above which any SCMI command, advertised to have + an higher-than-threshold execution latency, should not be considered for + atomic mode of operation, even if requested. + If left unconfigured defaults to zero. + arm,smc-id: $ref: /schemas/types.yaml#/definitions/uint32 description: @@ -264,6 +273,8 @@ examples: #address-cells = <1>; #size-cells = <0>; + atomic_threshold = <10000>; + scmi_devpd: protocol@11 { reg = <0x11>; #power-domain-cells = <1>;
SCMI protocols in the platform can optionally signal to the OSPM agent the expected execution latency for a specific resource/operation pair. Introduce an SCMI system wide optional property to describe a global time threshold which can be configured on a per-platform base to determine the opportunity, or not, for an SCMI command advertised to have a higher latency than the threshold, to be considered for atomic operations: high-latency SCMI synchronous commands should be preferably issued in the usual non-atomic mode. Cc: Rob Herring <robh+dt@kernel.org> Cc: devicetree@vger.kernel.org Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> --- v3 --> v4 - renamed property to atomic-threshold-us v1 --> v2 - rephrased the property description --- .../devicetree/bindings/firmware/arm,scmi.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+)