On Fri, Dec 13, 2019 at 03:04:35PM +0000, Mike Leach wrote:
- type: object
- description:
A trigger connections child node which describes the trigger signalsbetween this CTI and another hardware device. This device may be a CPU,CoreSight device, any other hardware device or simple external IO lines.The connection may have both input and output triggers, or only one or theother.- properties:
arm,trig-in-sigs:allOf:- $ref: /schemas/types.yaml#/definitions/uint32-arrayminItems: 1maxItems: 32description:List of CTI trigger in signal numbers in use by a trig-conns node.arm,trig-in-types:allOf:- $ref: /schemas/types.yaml#/definitions/uint32-arrayminItems: 1maxItems: 32description:List of constants representing the types for the CTI trigger insignals. Types in this array match to the corresponding signal in thearm,trig-in-sigs array. If the -types array is smaller, or omittedcompletely, then the types will default to GEN_IO.arm,trig-out-sigs:allOf:- $ref: /schemas/types.yaml#/definitions/uint32-arrayminItems: 1maxItems: 32description:List of CTI trigger out signal numbers in use by a trig-conns node.arm,trig-out-types:allOf:- $ref: /schemas/types.yaml#/definitions/uint32-arrayminItems: 1maxItems: 32description:List of constants representing the types for the CTI trigger outsignals. Types in this array match to the corresponding signalin the arm,trig-out-sigs array. If the "-types" array is smaller,or omitted completely, then the types will default to GEN_IO.arm,trig-filters:allOf:- $ref: /schemas/types.yaml#/definitions/uint32-arrayminItems: 1maxItems: 32description:List of CTI trigger out signals that will be blocked from becomingactive, unless filtering is disabled on the driver.arm,trig-conn-name:allOf:- $ref: /schemas/types.yaml#/definitions/stringdescription:Defines a connection name that will be displayed, if the cpu orarm,cs-dev-assoc properties are not being used in this connection.Principle use for CTI that are connected to non-CoreSight devices, orexternal IO.- anyOf:
- required:- arm,trig-in-sigs- required:- arm,trig-out-sigs- oneOf:
- required:- arm,trig-conn-name- required:- cpu- required:- arm,cs-dev-assocThis would mean that either arm,trig-conn-name, cpu xor arm,cs-dev-assoc is required in the trig_conn child nodes, but they don't seem to be defined at this level but in the parent node?
cpu and rm,cs-dev-assoc can appear in the parent node if the arm,coresight-cti-v8-arch compatible string is used - hence declared at that level. See the examples for the v8 compatible layout.
+required:
- compatible
- reg
- clocks
- clock-names
+examples:
- # minimum CTI definition. DEVID register used to set number of triggers.
- |
- cti@20020000 {
compatible = "arm,coresight-cti", "arm,primecell";reg = <0x20020000 0x1000>;clocks = <&soc_smc50mhz>;clock-names = "apb_pclk";- };
- # v8 architecturally defined CTI - CPU + ETM connections generated by the
- # driver according to the v8 architecture specification.
- |
- cti@859000 {
compatible = "arm,coresight-cti-v8-arch", "arm,coresight-cti","arm,primecell";reg = <0x859000 0x1000>;clocks = <&soc_smc50mhz>;clock-names = "apb_pclk";cpu = <&CPU1>;arm,cs-dev-assoc = <&etm1>;and it looks like arm,cs-dev-assoc and cpu can be combined?
Absolutely - a CTI can and is connected to both the CPU and an optional ETM attached to the CPU in a v8 architecture system.
That's not what
- oneOf:
- required:- arm,trig-conn-name- required:- cpu- required:- arm,cs-dev-assoc
Is saying though. oneOf is a xor, you can have one of the three schemas that are valid, but not more than that.
- };
- # Implementation defined CTI - CPU + ETM connections explicitly defined..
- # Shows use of type constants from dt-bindings/arm/coresight-cti-dt.h
- |
- #include <dt-bindings/arm/coresight-cti-dt.h>
- cti@858000 {
compatible = "arm,coresight-cti", "arm,primecell";reg = <0x858000 0x1000>;clocks = <&soc_smc50mhz>;clock-names = "apb_pclk";arm,cti-ctm-id = <1>;trig-conns@0 {So, what I think happened here is that your patternProperties doesn't match anything (underscore vs dash), and since you don't have additionalProperties set to false, it doesn't warn that there's properties that aren't defined in the binding. Meaning that none of the child nodes in the bindings are effectively validated.
OK - fixing the name should fix this. I can't use additionalProperties as this is prohibited for bindings that use ref: (according to the example-schema.yaml)
Ah right, I missed that one, sorry. In this case, you can use the keyword unevaluatedProperties instead. As its name suggests, it will report an error if there's a property that hasn't been validated by any schemas.
Note that this is a keyword introduced by the latest schemas spec (draft 2019-09) which isn't supported by the DT tools yet. But putting it into your schema will at least allow to have that check when the tools will support it.
arm,trig-in-sigs = <4 5 6 7>;arm,trig-in-types = <ETM_EXTOUTETM_EXTOUTETM_EXTOUTETM_EXTOUT>;arm,trig-out-sigs = <4 5 6 7>;arm,trig-out-types = <ETM_EXTINETM_EXTINETM_EXTINETM_EXTIN>;arm,cs-dev-assoc = <&etm0>;};Nodes with unit-address must have a matching reg property. This will generate a dtc warning too.
That's interesting - I don't get any dtc warnings when compiling or when running make dt_binding_checl
Linux disables a lot of DTC warnings. You can see all (I think?) the warnings by passing W=1 in the environment when you compile the device trees.
Is this rule documented anywhere? I cannot see it in the 0.2 spec version from devicetree.org or any of the examples / docs in the kernel tree.
The commit adding it to DTC is this one https://git.kernel.org/pub/scm/utils/dtc/dtc.git/commit/?id=852e9ecbe1976927...
It just seems that while valid, it's against best practices.
Maxime