Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
On 11/29/18 2:49 AM, Roger Quadros wrote: David, On 28/11/18 17:42, David Lechner wrote: On 11/27/18 9:15 AM, Roger Quadros wrote: On 26/11/18 23:14, David Lechner wrote: On 11/22/18 5:38 AM, Roger Quadros wrote: From: Suman Anna This patch adds the bindings for the Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS) present on various TI SoCs. The IP is present on multiple TI SoC architecture families including the OMAP architecture SoCs such as AM33xx, AM437x and AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is also present on the Davinci based OMAPL138 SoCs and K3 architecture based AM65x SoCs as well (not covered for now). Details have been added to include bindings for various core sub-modules like the PRU Cores, the PRUSS Interrupt Controller, and other sub-modules used for Industrial Communication purposes, covering the MDIO, MII_RT and the IEP sub-modules. The binding mostly uses standard DT properties. Signed-off-by: Suman Anna Signed-off-by: Roger Quadros --- .../devicetree/bindings/soc/ti/ti,pruss.txt| 360 + 1 file changed, 360 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.txt diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt new file mode 100644 index 000..24fedad --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt ... + +PRU-ICSS SoC Bus Parent Node += +This node represents the integration of the PRU-ICSS IP into a SoC, and is +required for all SoCs. The PRU-ICSS parent nodes need to be defined as child +nodes of this node. + +Required Properties: + +- compatible : should be one of, + "ti,am3356-pruss-soc-bus" for AM335x family of SoCs + "ti,am4376-pruss-soc-bus" for AM437x family of SoCs + "ti,am5728-pruss-soc-bus" for AM57xx family of SoCs + "ti,k2g-pruss-soc-bus" for 66AK2G family of SoCs +- reg: address and size of the PRUSS CFG sub-module registers + dictating the interconnect configuration I haven't looked into Tony's suggestion of using ti-sysc yet, so this may be a moot point, but how will this work with AM18xx that does not have a PRUSS CFG register? It seems to me that reg here should be the address and size of the entire PRUSS IP block and the CFG register should be a syscon node or something like that. The reg property description is incorrect in the patch. It should have been reg: address of SYSCFG register. The SYSCFG register is used to enable and reset the module. But based on Tony's suggestion this wrapper driver will change to ti,sysc for OMAP like SoCs. For AM18xx it could be a simple wrapper driver that just populates the children? I suppose that could work. I will look into it (perhaps after seeing what you come up with in v2). +- #address-cells : should be 1 +- #size-cells: should be 1 +- ranges : standard ranges definition + ... + +PRUSS INTC Child Node +== +Each PRUSS has a single interrupt controller instance that is common to both +the PRU cores. Each interrupt controller can detect 64 input events which are +then mapped to 10 possible output interrupts through two levels of mapping. The +input events can be triggered by either the PRUs and/or various other PRUSS +internal and external peripherals. The first 2 output interrupts are fed +exclusively to the internal PRU cores, with the remaining 8 connected to +external interrupt controllers including the MPU. FYI, on AM18xx, there is a PRUSSEVTSEL bit in CFGCHIP3[3] (already a syscon node in the device tree) that allows selecting one of two groups of 32 input events out of this group of 64. This is perhaps getting out of the scope of this patch series, but I just want to make sure we end up with something that can be easily extended for this case. For example, I was thinking that this binding could be modified so that #interrupt-cells could be 1 or 2. If it is 2, then the first cell specifies the PRUSSEVTSEL value and the second value is the event number. this is da850.dtsi correct? Yes. As PRUSSEVTSEL is not SYSEVENT specific but applies to all the SYSEVENTs at a time. I don't think interrupt-cells is the right place to specify this. Can it be set in DT in the board file? But this can't change once booted so maybe restrictive. I guess the way I see this is that it is like specifying the bank and index for a GPIO. If you only specify the system event number, then it is not clear which event you mean - it could be one of two events. You have to also specify the PRUSSEVTSEL value (one could call this the bank or group, I suppose) to fully describe the system event. But this PRUSSEVTSEL is not present on most SoCs. I think it is only on the
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
On 11/29/18 2:49 AM, Roger Quadros wrote: David, On 28/11/18 17:42, David Lechner wrote: On 11/27/18 9:15 AM, Roger Quadros wrote: On 26/11/18 23:14, David Lechner wrote: On 11/22/18 5:38 AM, Roger Quadros wrote: From: Suman Anna This patch adds the bindings for the Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS) present on various TI SoCs. The IP is present on multiple TI SoC architecture families including the OMAP architecture SoCs such as AM33xx, AM437x and AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is also present on the Davinci based OMAPL138 SoCs and K3 architecture based AM65x SoCs as well (not covered for now). Details have been added to include bindings for various core sub-modules like the PRU Cores, the PRUSS Interrupt Controller, and other sub-modules used for Industrial Communication purposes, covering the MDIO, MII_RT and the IEP sub-modules. The binding mostly uses standard DT properties. Signed-off-by: Suman Anna Signed-off-by: Roger Quadros --- .../devicetree/bindings/soc/ti/ti,pruss.txt| 360 + 1 file changed, 360 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.txt diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt new file mode 100644 index 000..24fedad --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt ... + +PRU-ICSS SoC Bus Parent Node += +This node represents the integration of the PRU-ICSS IP into a SoC, and is +required for all SoCs. The PRU-ICSS parent nodes need to be defined as child +nodes of this node. + +Required Properties: + +- compatible : should be one of, + "ti,am3356-pruss-soc-bus" for AM335x family of SoCs + "ti,am4376-pruss-soc-bus" for AM437x family of SoCs + "ti,am5728-pruss-soc-bus" for AM57xx family of SoCs + "ti,k2g-pruss-soc-bus" for 66AK2G family of SoCs +- reg: address and size of the PRUSS CFG sub-module registers + dictating the interconnect configuration I haven't looked into Tony's suggestion of using ti-sysc yet, so this may be a moot point, but how will this work with AM18xx that does not have a PRUSS CFG register? It seems to me that reg here should be the address and size of the entire PRUSS IP block and the CFG register should be a syscon node or something like that. The reg property description is incorrect in the patch. It should have been reg: address of SYSCFG register. The SYSCFG register is used to enable and reset the module. But based on Tony's suggestion this wrapper driver will change to ti,sysc for OMAP like SoCs. For AM18xx it could be a simple wrapper driver that just populates the children? I suppose that could work. I will look into it (perhaps after seeing what you come up with in v2). +- #address-cells : should be 1 +- #size-cells: should be 1 +- ranges : standard ranges definition + ... + +PRUSS INTC Child Node +== +Each PRUSS has a single interrupt controller instance that is common to both +the PRU cores. Each interrupt controller can detect 64 input events which are +then mapped to 10 possible output interrupts through two levels of mapping. The +input events can be triggered by either the PRUs and/or various other PRUSS +internal and external peripherals. The first 2 output interrupts are fed +exclusively to the internal PRU cores, with the remaining 8 connected to +external interrupt controllers including the MPU. FYI, on AM18xx, there is a PRUSSEVTSEL bit in CFGCHIP3[3] (already a syscon node in the device tree) that allows selecting one of two groups of 32 input events out of this group of 64. This is perhaps getting out of the scope of this patch series, but I just want to make sure we end up with something that can be easily extended for this case. For example, I was thinking that this binding could be modified so that #interrupt-cells could be 1 or 2. If it is 2, then the first cell specifies the PRUSSEVTSEL value and the second value is the event number. this is da850.dtsi correct? Yes. As PRUSSEVTSEL is not SYSEVENT specific but applies to all the SYSEVENTs at a time. I don't think interrupt-cells is the right place to specify this. Can it be set in DT in the board file? But this can't change once booted so maybe restrictive. I guess the way I see this is that it is like specifying the bank and index for a GPIO. If you only specify the system event number, then it is not clear which event you mean - it could be one of two events. You have to also specify the PRUSSEVTSEL value (one could call this the bank or group, I suppose) to fully describe the system event. But this PRUSSEVTSEL is not present on most SoCs. I think it is only on the
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
David, On 28/11/18 17:42, David Lechner wrote: > On 11/27/18 9:15 AM, Roger Quadros wrote: >> >> On 26/11/18 23:14, David Lechner wrote: >>> On 11/22/18 5:38 AM, Roger Quadros wrote: From: Suman Anna This patch adds the bindings for the Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS) present on various TI SoCs. The IP is present on multiple TI SoC architecture families including the OMAP architecture SoCs such as AM33xx, AM437x and AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is also present on the Davinci based OMAPL138 SoCs and K3 architecture based AM65x SoCs as well (not covered for now). Details have been added to include bindings for various core sub-modules like the PRU Cores, the PRUSS Interrupt Controller, and other sub-modules used for Industrial Communication purposes, covering the MDIO, MII_RT and the IEP sub-modules. The binding mostly uses standard DT properties. Signed-off-by: Suman Anna Signed-off-by: Roger Quadros --- .../devicetree/bindings/soc/ti/ti,pruss.txt| 360 + 1 file changed, 360 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.txt diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt new file mode 100644 index 000..24fedad --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt >>> >>> ... >>> + +PRU-ICSS SoC Bus Parent Node += +This node represents the integration of the PRU-ICSS IP into a SoC, and is +required for all SoCs. The PRU-ICSS parent nodes need to be defined as child +nodes of this node. + +Required Properties: + +- compatible : should be one of, + "ti,am3356-pruss-soc-bus" for AM335x family of SoCs + "ti,am4376-pruss-soc-bus" for AM437x family of SoCs + "ti,am5728-pruss-soc-bus" for AM57xx family of SoCs + "ti,k2g-pruss-soc-bus" for 66AK2G family of SoCs +- reg: address and size of the PRUSS CFG sub-module registers + dictating the interconnect configuration >>> >>> I haven't looked into Tony's suggestion of using ti-sysc yet, so this may >>> be a >>> moot point, but how will this work with AM18xx that does not have a PRUSS >>> CFG >>> register? It seems to me that reg here should be the address and size of the >>> entire PRUSS IP block and the CFG register should be a syscon node or >>> something >>> like that. >> >> The reg property description is incorrect in the patch. It should have been >> >> reg: address of SYSCFG register. >> >> The SYSCFG register is used to enable and reset the module. >> >> But based on Tony's suggestion this wrapper driver will change to ti,sysc for >> OMAP like SoCs. >> >> For AM18xx it could be a simple wrapper driver that just populates the >> children? > > I suppose that could work. I will look into it (perhaps after seeing what you > come up with in v2). > >> >>> +- #address-cells : should be 1 +- #size-cells: should be 1 +- ranges : standard ranges definition + >>> >>> ... >>> + +PRUSS INTC Child Node +== +Each PRUSS has a single interrupt controller instance that is common to both +the PRU cores. Each interrupt controller can detect 64 input events which are +then mapped to 10 possible output interrupts through two levels of mapping. The +input events can be triggered by either the PRUs and/or various other PRUSS +internal and external peripherals. The first 2 output interrupts are fed +exclusively to the internal PRU cores, with the remaining 8 connected to +external interrupt controllers including the MPU. >>> >>> FYI, on AM18xx, there is a PRUSSEVTSEL bit in CFGCHIP3[3] (already a syscon >>> node >>> in the device tree) that allows selecting one of two groups of 32 input >>> events >>> out of this group of 64. This is perhaps getting out of the scope of this >>> patch >>> series, but I just want to make sure we end up with something that can be >>> easily >>> extended for this case. For example, I was thinking that this binding could >>> be >>> modified so that #interrupt-cells could be 1 or 2. If it is 2, then the >>> first >>> cell specifies the PRUSSEVTSEL value and the second value is the event >>> number. >>> >> >> this is da850.dtsi correct? > > Yes. > >> >> As PRUSSEVTSEL is not SYSEVENT specific but applies to all the SYSEVENTs at >> a time. >> I don't think interrupt-cells is the right place to specify this. >> >> Can it be set in DT in the board file? But this can't
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
David, On 28/11/18 17:42, David Lechner wrote: > On 11/27/18 9:15 AM, Roger Quadros wrote: >> >> On 26/11/18 23:14, David Lechner wrote: >>> On 11/22/18 5:38 AM, Roger Quadros wrote: From: Suman Anna This patch adds the bindings for the Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS) present on various TI SoCs. The IP is present on multiple TI SoC architecture families including the OMAP architecture SoCs such as AM33xx, AM437x and AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is also present on the Davinci based OMAPL138 SoCs and K3 architecture based AM65x SoCs as well (not covered for now). Details have been added to include bindings for various core sub-modules like the PRU Cores, the PRUSS Interrupt Controller, and other sub-modules used for Industrial Communication purposes, covering the MDIO, MII_RT and the IEP sub-modules. The binding mostly uses standard DT properties. Signed-off-by: Suman Anna Signed-off-by: Roger Quadros --- .../devicetree/bindings/soc/ti/ti,pruss.txt| 360 + 1 file changed, 360 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.txt diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt new file mode 100644 index 000..24fedad --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt >>> >>> ... >>> + +PRU-ICSS SoC Bus Parent Node += +This node represents the integration of the PRU-ICSS IP into a SoC, and is +required for all SoCs. The PRU-ICSS parent nodes need to be defined as child +nodes of this node. + +Required Properties: + +- compatible : should be one of, + "ti,am3356-pruss-soc-bus" for AM335x family of SoCs + "ti,am4376-pruss-soc-bus" for AM437x family of SoCs + "ti,am5728-pruss-soc-bus" for AM57xx family of SoCs + "ti,k2g-pruss-soc-bus" for 66AK2G family of SoCs +- reg: address and size of the PRUSS CFG sub-module registers + dictating the interconnect configuration >>> >>> I haven't looked into Tony's suggestion of using ti-sysc yet, so this may >>> be a >>> moot point, but how will this work with AM18xx that does not have a PRUSS >>> CFG >>> register? It seems to me that reg here should be the address and size of the >>> entire PRUSS IP block and the CFG register should be a syscon node or >>> something >>> like that. >> >> The reg property description is incorrect in the patch. It should have been >> >> reg: address of SYSCFG register. >> >> The SYSCFG register is used to enable and reset the module. >> >> But based on Tony's suggestion this wrapper driver will change to ti,sysc for >> OMAP like SoCs. >> >> For AM18xx it could be a simple wrapper driver that just populates the >> children? > > I suppose that could work. I will look into it (perhaps after seeing what you > come up with in v2). > >> >>> +- #address-cells : should be 1 +- #size-cells: should be 1 +- ranges : standard ranges definition + >>> >>> ... >>> + +PRUSS INTC Child Node +== +Each PRUSS has a single interrupt controller instance that is common to both +the PRU cores. Each interrupt controller can detect 64 input events which are +then mapped to 10 possible output interrupts through two levels of mapping. The +input events can be triggered by either the PRUs and/or various other PRUSS +internal and external peripherals. The first 2 output interrupts are fed +exclusively to the internal PRU cores, with the remaining 8 connected to +external interrupt controllers including the MPU. >>> >>> FYI, on AM18xx, there is a PRUSSEVTSEL bit in CFGCHIP3[3] (already a syscon >>> node >>> in the device tree) that allows selecting one of two groups of 32 input >>> events >>> out of this group of 64. This is perhaps getting out of the scope of this >>> patch >>> series, but I just want to make sure we end up with something that can be >>> easily >>> extended for this case. For example, I was thinking that this binding could >>> be >>> modified so that #interrupt-cells could be 1 or 2. If it is 2, then the >>> first >>> cell specifies the PRUSSEVTSEL value and the second value is the event >>> number. >>> >> >> this is da850.dtsi correct? > > Yes. > >> >> As PRUSSEVTSEL is not SYSEVENT specific but applies to all the SYSEVENTs at >> a time. >> I don't think interrupt-cells is the right place to specify this. >> >> Can it be set in DT in the board file? But this can't
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
On 11/27/18 9:15 AM, Roger Quadros wrote: On 26/11/18 23:14, David Lechner wrote: On 11/22/18 5:38 AM, Roger Quadros wrote: From: Suman Anna This patch adds the bindings for the Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS) present on various TI SoCs. The IP is present on multiple TI SoC architecture families including the OMAP architecture SoCs such as AM33xx, AM437x and AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is also present on the Davinci based OMAPL138 SoCs and K3 architecture based AM65x SoCs as well (not covered for now). Details have been added to include bindings for various core sub-modules like the PRU Cores, the PRUSS Interrupt Controller, and other sub-modules used for Industrial Communication purposes, covering the MDIO, MII_RT and the IEP sub-modules. The binding mostly uses standard DT properties. Signed-off-by: Suman Anna Signed-off-by: Roger Quadros --- .../devicetree/bindings/soc/ti/ti,pruss.txt| 360 + 1 file changed, 360 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.txt diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt new file mode 100644 index 000..24fedad --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt ... + +PRU-ICSS SoC Bus Parent Node += +This node represents the integration of the PRU-ICSS IP into a SoC, and is +required for all SoCs. The PRU-ICSS parent nodes need to be defined as child +nodes of this node. + +Required Properties: + +- compatible : should be one of, + "ti,am3356-pruss-soc-bus" for AM335x family of SoCs + "ti,am4376-pruss-soc-bus" for AM437x family of SoCs + "ti,am5728-pruss-soc-bus" for AM57xx family of SoCs + "ti,k2g-pruss-soc-bus" for 66AK2G family of SoCs +- reg: address and size of the PRUSS CFG sub-module registers + dictating the interconnect configuration I haven't looked into Tony's suggestion of using ti-sysc yet, so this may be a moot point, but how will this work with AM18xx that does not have a PRUSS CFG register? It seems to me that reg here should be the address and size of the entire PRUSS IP block and the CFG register should be a syscon node or something like that. The reg property description is incorrect in the patch. It should have been reg : address of SYSCFG register. The SYSCFG register is used to enable and reset the module. But based on Tony's suggestion this wrapper driver will change to ti,sysc for OMAP like SoCs. For AM18xx it could be a simple wrapper driver that just populates the children? I suppose that could work. I will look into it (perhaps after seeing what you come up with in v2). +- #address-cells : should be 1 +- #size-cells: should be 1 +- ranges : standard ranges definition + ... + +PRUSS INTC Child Node +== +Each PRUSS has a single interrupt controller instance that is common to both +the PRU cores. Each interrupt controller can detect 64 input events which are +then mapped to 10 possible output interrupts through two levels of mapping. The +input events can be triggered by either the PRUs and/or various other PRUSS +internal and external peripherals. The first 2 output interrupts are fed +exclusively to the internal PRU cores, with the remaining 8 connected to +external interrupt controllers including the MPU. FYI, on AM18xx, there is a PRUSSEVTSEL bit in CFGCHIP3[3] (already a syscon node in the device tree) that allows selecting one of two groups of 32 input events out of this group of 64. This is perhaps getting out of the scope of this patch series, but I just want to make sure we end up with something that can be easily extended for this case. For example, I was thinking that this binding could be modified so that #interrupt-cells could be 1 or 2. If it is 2, then the first cell specifies the PRUSSEVTSEL value and the second value is the event number. this is da850.dtsi correct? Yes. As PRUSSEVTSEL is not SYSEVENT specific but applies to all the SYSEVENTs at a time. I don't think interrupt-cells is the right place to specify this. Can it be set in DT in the board file? But this can't change once booted so maybe restrictive. I guess the way I see this is that it is like specifying the bank and index for a GPIO. If you only specify the system event number, then it is not clear which event you mean - it could be one of two events. You have to also specify the PRUSSEVTSEL value (one could call this the bank or group, I suppose) to fully describe the system event. If runtime change is required it can only be done before a PRU boots. How about providing this info in the resource table and/or application DT node? This seems like
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
On 11/27/18 9:15 AM, Roger Quadros wrote: On 26/11/18 23:14, David Lechner wrote: On 11/22/18 5:38 AM, Roger Quadros wrote: From: Suman Anna This patch adds the bindings for the Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS) present on various TI SoCs. The IP is present on multiple TI SoC architecture families including the OMAP architecture SoCs such as AM33xx, AM437x and AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is also present on the Davinci based OMAPL138 SoCs and K3 architecture based AM65x SoCs as well (not covered for now). Details have been added to include bindings for various core sub-modules like the PRU Cores, the PRUSS Interrupt Controller, and other sub-modules used for Industrial Communication purposes, covering the MDIO, MII_RT and the IEP sub-modules. The binding mostly uses standard DT properties. Signed-off-by: Suman Anna Signed-off-by: Roger Quadros --- .../devicetree/bindings/soc/ti/ti,pruss.txt| 360 + 1 file changed, 360 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.txt diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt new file mode 100644 index 000..24fedad --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt ... + +PRU-ICSS SoC Bus Parent Node += +This node represents the integration of the PRU-ICSS IP into a SoC, and is +required for all SoCs. The PRU-ICSS parent nodes need to be defined as child +nodes of this node. + +Required Properties: + +- compatible : should be one of, + "ti,am3356-pruss-soc-bus" for AM335x family of SoCs + "ti,am4376-pruss-soc-bus" for AM437x family of SoCs + "ti,am5728-pruss-soc-bus" for AM57xx family of SoCs + "ti,k2g-pruss-soc-bus" for 66AK2G family of SoCs +- reg: address and size of the PRUSS CFG sub-module registers + dictating the interconnect configuration I haven't looked into Tony's suggestion of using ti-sysc yet, so this may be a moot point, but how will this work with AM18xx that does not have a PRUSS CFG register? It seems to me that reg here should be the address and size of the entire PRUSS IP block and the CFG register should be a syscon node or something like that. The reg property description is incorrect in the patch. It should have been reg : address of SYSCFG register. The SYSCFG register is used to enable and reset the module. But based on Tony's suggestion this wrapper driver will change to ti,sysc for OMAP like SoCs. For AM18xx it could be a simple wrapper driver that just populates the children? I suppose that could work. I will look into it (perhaps after seeing what you come up with in v2). +- #address-cells : should be 1 +- #size-cells: should be 1 +- ranges : standard ranges definition + ... + +PRUSS INTC Child Node +== +Each PRUSS has a single interrupt controller instance that is common to both +the PRU cores. Each interrupt controller can detect 64 input events which are +then mapped to 10 possible output interrupts through two levels of mapping. The +input events can be triggered by either the PRUs and/or various other PRUSS +internal and external peripherals. The first 2 output interrupts are fed +exclusively to the internal PRU cores, with the remaining 8 connected to +external interrupt controllers including the MPU. FYI, on AM18xx, there is a PRUSSEVTSEL bit in CFGCHIP3[3] (already a syscon node in the device tree) that allows selecting one of two groups of 32 input events out of this group of 64. This is perhaps getting out of the scope of this patch series, but I just want to make sure we end up with something that can be easily extended for this case. For example, I was thinking that this binding could be modified so that #interrupt-cells could be 1 or 2. If it is 2, then the first cell specifies the PRUSSEVTSEL value and the second value is the event number. this is da850.dtsi correct? Yes. As PRUSSEVTSEL is not SYSEVENT specific but applies to all the SYSEVENTs at a time. I don't think interrupt-cells is the right place to specify this. Can it be set in DT in the board file? But this can't change once booted so maybe restrictive. I guess the way I see this is that it is like specifying the bank and index for a GPIO. If you only specify the system event number, then it is not clear which event you mean - it could be one of two events. You have to also specify the PRUSSEVTSEL value (one could call this the bank or group, I suppose) to fully describe the system event. If runtime change is required it can only be done before a PRU boots. How about providing this info in the resource table and/or application DT node? This seems like
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
On 26/11/18 23:14, David Lechner wrote: > On 11/22/18 5:38 AM, Roger Quadros wrote: >> From: Suman Anna >> >> This patch adds the bindings for the Programmable Real-Time Unit >> and Industrial Communication Subsystem (PRU-ICSS) present on various >> TI SoCs. The IP is present on multiple TI SoC architecture families >> including the OMAP architecture SoCs such as AM33xx, AM437x and >> AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is >> also present on the Davinci based OMAPL138 SoCs and K3 architecture >> based AM65x SoCs as well (not covered for now). Details have been >> added to include bindings for various core sub-modules like the PRU >> Cores, the PRUSS Interrupt Controller, and other sub-modules used >> for Industrial Communication purposes, covering the MDIO, MII_RT >> and the IEP sub-modules. The binding mostly uses standard DT >> properties. >> >> Signed-off-by: Suman Anna >> Signed-off-by: Roger Quadros >> --- >> .../devicetree/bindings/soc/ti/ti,pruss.txt| 360 >> + >> 1 file changed, 360 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.txt >> >> diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt >> b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt >> new file mode 100644 >> index 000..24fedad >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt > > ... > >> + >> +PRU-ICSS SoC Bus Parent Node >> += >> +This node represents the integration of the PRU-ICSS IP into a SoC, and is >> +required for all SoCs. The PRU-ICSS parent nodes need to be defined as child >> +nodes of this node. >> + >> +Required Properties: >> + >> +- compatible : should be one of, >> + "ti,am3356-pruss-soc-bus" for AM335x family of SoCs >> + "ti,am4376-pruss-soc-bus" for AM437x family of SoCs >> + "ti,am5728-pruss-soc-bus" for AM57xx family of SoCs >> + "ti,k2g-pruss-soc-bus" for 66AK2G family of SoCs >> +- reg: address and size of the PRUSS CFG sub-module registers >> + dictating the interconnect configuration > > I haven't looked into Tony's suggestion of using ti-sysc yet, so this may be a > moot point, but how will this work with AM18xx that does not have a PRUSS CFG > register? It seems to me that reg here should be the address and size of the > entire PRUSS IP block and the CFG register should be a syscon node or > something > like that. The reg property description is incorrect in the patch. It should have been reg : address of SYSCFG register. The SYSCFG register is used to enable and reset the module. But based on Tony's suggestion this wrapper driver will change to ti,sysc for OMAP like SoCs. For AM18xx it could be a simple wrapper driver that just populates the children? > >> +- #address-cells : should be 1 >> +- #size-cells: should be 1 >> +- ranges : standard ranges definition >> + > > ... > >> + >> +PRUSS INTC Child Node >> +== >> +Each PRUSS has a single interrupt controller instance that is common to both >> +the PRU cores. Each interrupt controller can detect 64 input events which >> are >> +then mapped to 10 possible output interrupts through two levels of mapping. >> The >> +input events can be triggered by either the PRUs and/or various other PRUSS >> +internal and external peripherals. The first 2 output interrupts are fed >> +exclusively to the internal PRU cores, with the remaining 8 connected to >> +external interrupt controllers including the MPU. > > FYI, on AM18xx, there is a PRUSSEVTSEL bit in CFGCHIP3[3] (already a syscon > node > in the device tree) that allows selecting one of two groups of 32 input events > out of this group of 64. This is perhaps getting out of the scope of this > patch > series, but I just want to make sure we end up with something that can be > easily > extended for this case. For example, I was thinking that this binding could be > modified so that #interrupt-cells could be 1 or 2. If it is 2, then the first > cell specifies the PRUSSEVTSEL value and the second value is the event number. > this is da850.dtsi correct? As PRUSSEVTSEL is not SYSEVENT specific but applies to all the SYSEVENTs at a time. I don't think interrupt-cells is the right place to specify this. Can it be set in DT in the board file? But this can't change once booted so maybe restrictive. If runtime change is required it can only be done before a PRU boots. How about providing this info in the resource table and/or application DT node? > >> + >> +Required Properties: >> + >> +- compatible : should be one of, >> + "ti,am3356-pruss-intc" for AM335x family of >> SoCs >> + "ti,am4376-pruss-intc" for AM437x family of >> SoCs >> +
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
On 26/11/18 23:14, David Lechner wrote: > On 11/22/18 5:38 AM, Roger Quadros wrote: >> From: Suman Anna >> >> This patch adds the bindings for the Programmable Real-Time Unit >> and Industrial Communication Subsystem (PRU-ICSS) present on various >> TI SoCs. The IP is present on multiple TI SoC architecture families >> including the OMAP architecture SoCs such as AM33xx, AM437x and >> AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is >> also present on the Davinci based OMAPL138 SoCs and K3 architecture >> based AM65x SoCs as well (not covered for now). Details have been >> added to include bindings for various core sub-modules like the PRU >> Cores, the PRUSS Interrupt Controller, and other sub-modules used >> for Industrial Communication purposes, covering the MDIO, MII_RT >> and the IEP sub-modules. The binding mostly uses standard DT >> properties. >> >> Signed-off-by: Suman Anna >> Signed-off-by: Roger Quadros >> --- >> .../devicetree/bindings/soc/ti/ti,pruss.txt| 360 >> + >> 1 file changed, 360 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.txt >> >> diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt >> b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt >> new file mode 100644 >> index 000..24fedad >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt > > ... > >> + >> +PRU-ICSS SoC Bus Parent Node >> += >> +This node represents the integration of the PRU-ICSS IP into a SoC, and is >> +required for all SoCs. The PRU-ICSS parent nodes need to be defined as child >> +nodes of this node. >> + >> +Required Properties: >> + >> +- compatible : should be one of, >> + "ti,am3356-pruss-soc-bus" for AM335x family of SoCs >> + "ti,am4376-pruss-soc-bus" for AM437x family of SoCs >> + "ti,am5728-pruss-soc-bus" for AM57xx family of SoCs >> + "ti,k2g-pruss-soc-bus" for 66AK2G family of SoCs >> +- reg: address and size of the PRUSS CFG sub-module registers >> + dictating the interconnect configuration > > I haven't looked into Tony's suggestion of using ti-sysc yet, so this may be a > moot point, but how will this work with AM18xx that does not have a PRUSS CFG > register? It seems to me that reg here should be the address and size of the > entire PRUSS IP block and the CFG register should be a syscon node or > something > like that. The reg property description is incorrect in the patch. It should have been reg : address of SYSCFG register. The SYSCFG register is used to enable and reset the module. But based on Tony's suggestion this wrapper driver will change to ti,sysc for OMAP like SoCs. For AM18xx it could be a simple wrapper driver that just populates the children? > >> +- #address-cells : should be 1 >> +- #size-cells: should be 1 >> +- ranges : standard ranges definition >> + > > ... > >> + >> +PRUSS INTC Child Node >> +== >> +Each PRUSS has a single interrupt controller instance that is common to both >> +the PRU cores. Each interrupt controller can detect 64 input events which >> are >> +then mapped to 10 possible output interrupts through two levels of mapping. >> The >> +input events can be triggered by either the PRUs and/or various other PRUSS >> +internal and external peripherals. The first 2 output interrupts are fed >> +exclusively to the internal PRU cores, with the remaining 8 connected to >> +external interrupt controllers including the MPU. > > FYI, on AM18xx, there is a PRUSSEVTSEL bit in CFGCHIP3[3] (already a syscon > node > in the device tree) that allows selecting one of two groups of 32 input events > out of this group of 64. This is perhaps getting out of the scope of this > patch > series, but I just want to make sure we end up with something that can be > easily > extended for this case. For example, I was thinking that this binding could be > modified so that #interrupt-cells could be 1 or 2. If it is 2, then the first > cell specifies the PRUSSEVTSEL value and the second value is the event number. > this is da850.dtsi correct? As PRUSSEVTSEL is not SYSEVENT specific but applies to all the SYSEVENTs at a time. I don't think interrupt-cells is the right place to specify this. Can it be set in DT in the board file? But this can't change once booted so maybe restrictive. If runtime change is required it can only be done before a PRU boots. How about providing this info in the resource table and/or application DT node? > >> + >> +Required Properties: >> + >> +- compatible : should be one of, >> + "ti,am3356-pruss-intc" for AM335x family of >> SoCs >> + "ti,am4376-pruss-intc" for AM437x family of >> SoCs >> +
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
* David Lechner [181126 21:14]: > I haven't looked into Tony's suggestion of using ti-sysc yet, so this may be a > moot point, but how will this work with AM18xx that does not have a PRUSS CFG > register? It seems to me that reg here should be the address and size of the > entire PRUSS IP block and the CFG register should be a syscon node or > something > like that. The SoC specific wrapper IP is probably different on am18xx compared to omaps, it might be TIPB like on omap1? If am18xx has something simlar to omaps, there would be revision, sysconfig and sysstatus registers typically at offsets 0x00, 0x10 and 0x14. The wrapper IP code should be independent of the PRU code and just provide services to the PRU. For a minimal wrapper IP driver example that might work for am18xx see for drivers/usb/musb/musb_am335x.c. Regards, Tony
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
* David Lechner [181126 21:14]: > I haven't looked into Tony's suggestion of using ti-sysc yet, so this may be a > moot point, but how will this work with AM18xx that does not have a PRUSS CFG > register? It seems to me that reg here should be the address and size of the > entire PRUSS IP block and the CFG register should be a syscon node or > something > like that. The SoC specific wrapper IP is probably different on am18xx compared to omaps, it might be TIPB like on omap1? If am18xx has something simlar to omaps, there would be revision, sysconfig and sysstatus registers typically at offsets 0x00, 0x10 and 0x14. The wrapper IP code should be independent of the PRU code and just provide services to the PRU. For a minimal wrapper IP driver example that might work for am18xx see for drivers/usb/musb/musb_am335x.c. Regards, Tony
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
On 11/22/18 5:38 AM, Roger Quadros wrote: From: Suman Anna This patch adds the bindings for the Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS) present on various TI SoCs. The IP is present on multiple TI SoC architecture families including the OMAP architecture SoCs such as AM33xx, AM437x and AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is also present on the Davinci based OMAPL138 SoCs and K3 architecture based AM65x SoCs as well (not covered for now). Details have been added to include bindings for various core sub-modules like the PRU Cores, the PRUSS Interrupt Controller, and other sub-modules used for Industrial Communication purposes, covering the MDIO, MII_RT and the IEP sub-modules. The binding mostly uses standard DT properties. Signed-off-by: Suman Anna Signed-off-by: Roger Quadros --- .../devicetree/bindings/soc/ti/ti,pruss.txt| 360 + 1 file changed, 360 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.txt diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt new file mode 100644 index 000..24fedad --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt ... + +PRU-ICSS SoC Bus Parent Node += +This node represents the integration of the PRU-ICSS IP into a SoC, and is +required for all SoCs. The PRU-ICSS parent nodes need to be defined as child +nodes of this node. + +Required Properties: + +- compatible : should be one of, + "ti,am3356-pruss-soc-bus" for AM335x family of SoCs + "ti,am4376-pruss-soc-bus" for AM437x family of SoCs + "ti,am5728-pruss-soc-bus" for AM57xx family of SoCs + "ti,k2g-pruss-soc-bus" for 66AK2G family of SoCs +- reg: address and size of the PRUSS CFG sub-module registers + dictating the interconnect configuration I haven't looked into Tony's suggestion of using ti-sysc yet, so this may be a moot point, but how will this work with AM18xx that does not have a PRUSS CFG register? It seems to me that reg here should be the address and size of the entire PRUSS IP block and the CFG register should be a syscon node or something like that. +- #address-cells : should be 1 +- #size-cells: should be 1 +- ranges : standard ranges definition + ... + +PRUSS INTC Child Node +== +Each PRUSS has a single interrupt controller instance that is common to both +the PRU cores. Each interrupt controller can detect 64 input events which are +then mapped to 10 possible output interrupts through two levels of mapping. The +input events can be triggered by either the PRUs and/or various other PRUSS +internal and external peripherals. The first 2 output interrupts are fed +exclusively to the internal PRU cores, with the remaining 8 connected to +external interrupt controllers including the MPU. FYI, on AM18xx, there is a PRUSSEVTSEL bit in CFGCHIP3[3] (already a syscon node in the device tree) that allows selecting one of two groups of 32 input events out of this group of 64. This is perhaps getting out of the scope of this patch series, but I just want to make sure we end up with something that can be easily extended for this case. For example, I was thinking that this binding could be modified so that #interrupt-cells could be 1 or 2. If it is 2, then the first cell specifies the PRUSSEVTSEL value and the second value is the event number. + +Required Properties: + +- compatible : should be one of, + "ti,am3356-pruss-intc" for AM335x family of SoCs + "ti,am4376-pruss-intc" for AM437x family of SoCs + "ti,am5728-pruss-intc" for AM57xx family of SoCs + "ti,k2g-pruss-intc" for 66AK2G family of SoCs +- reg : base address and size for the PRUSS INTC sub-module +- reg-names: should contain the string "intc" +- interrupt-controller : mark this node as an interrupt controller +- #interrupt-cells : should be 1. Client users shall use the PRU System + event number (the interrupt source that the client + is interested in) as the value of the interrupts + property in their node + + +PRU Child Node +=== +Each PRUSS has dual PRU cores, each represented by a PRU child node. Each node +can optionally be rendered inactive by using the standard DT string property, +"status". + +Required Properties: + +- compatible : should be + "ti,am3356-pru" for AM335x family of SoCs + "ti,am4376-pru" for AM437x family of SoCs + "ti,am5728-pru" for AM57xx family
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
On 11/22/18 5:38 AM, Roger Quadros wrote: From: Suman Anna This patch adds the bindings for the Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS) present on various TI SoCs. The IP is present on multiple TI SoC architecture families including the OMAP architecture SoCs such as AM33xx, AM437x and AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is also present on the Davinci based OMAPL138 SoCs and K3 architecture based AM65x SoCs as well (not covered for now). Details have been added to include bindings for various core sub-modules like the PRU Cores, the PRUSS Interrupt Controller, and other sub-modules used for Industrial Communication purposes, covering the MDIO, MII_RT and the IEP sub-modules. The binding mostly uses standard DT properties. Signed-off-by: Suman Anna Signed-off-by: Roger Quadros --- .../devicetree/bindings/soc/ti/ti,pruss.txt| 360 + 1 file changed, 360 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.txt diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt new file mode 100644 index 000..24fedad --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt ... + +PRU-ICSS SoC Bus Parent Node += +This node represents the integration of the PRU-ICSS IP into a SoC, and is +required for all SoCs. The PRU-ICSS parent nodes need to be defined as child +nodes of this node. + +Required Properties: + +- compatible : should be one of, + "ti,am3356-pruss-soc-bus" for AM335x family of SoCs + "ti,am4376-pruss-soc-bus" for AM437x family of SoCs + "ti,am5728-pruss-soc-bus" for AM57xx family of SoCs + "ti,k2g-pruss-soc-bus" for 66AK2G family of SoCs +- reg: address and size of the PRUSS CFG sub-module registers + dictating the interconnect configuration I haven't looked into Tony's suggestion of using ti-sysc yet, so this may be a moot point, but how will this work with AM18xx that does not have a PRUSS CFG register? It seems to me that reg here should be the address and size of the entire PRUSS IP block and the CFG register should be a syscon node or something like that. +- #address-cells : should be 1 +- #size-cells: should be 1 +- ranges : standard ranges definition + ... + +PRUSS INTC Child Node +== +Each PRUSS has a single interrupt controller instance that is common to both +the PRU cores. Each interrupt controller can detect 64 input events which are +then mapped to 10 possible output interrupts through two levels of mapping. The +input events can be triggered by either the PRUs and/or various other PRUSS +internal and external peripherals. The first 2 output interrupts are fed +exclusively to the internal PRU cores, with the remaining 8 connected to +external interrupt controllers including the MPU. FYI, on AM18xx, there is a PRUSSEVTSEL bit in CFGCHIP3[3] (already a syscon node in the device tree) that allows selecting one of two groups of 32 input events out of this group of 64. This is perhaps getting out of the scope of this patch series, but I just want to make sure we end up with something that can be easily extended for this case. For example, I was thinking that this binding could be modified so that #interrupt-cells could be 1 or 2. If it is 2, then the first cell specifies the PRUSSEVTSEL value and the second value is the event number. + +Required Properties: + +- compatible : should be one of, + "ti,am3356-pruss-intc" for AM335x family of SoCs + "ti,am4376-pruss-intc" for AM437x family of SoCs + "ti,am5728-pruss-intc" for AM57xx family of SoCs + "ti,k2g-pruss-intc" for 66AK2G family of SoCs +- reg : base address and size for the PRUSS INTC sub-module +- reg-names: should contain the string "intc" +- interrupt-controller : mark this node as an interrupt controller +- #interrupt-cells : should be 1. Client users shall use the PRU System + event number (the interrupt source that the client + is interested in) as the value of the interrupts + property in their node + + +PRU Child Node +=== +Each PRUSS has dual PRU cores, each represented by a PRU child node. Each node +can optionally be rendered inactive by using the standard DT string property, +"status". + +Required Properties: + +- compatible : should be + "ti,am3356-pru" for AM335x family of SoCs + "ti,am4376-pru" for AM437x family of SoCs + "ti,am5728-pru" for AM57xx family
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
* Roger Quadros [181126 07:48]:
> Not the PHY driver but the Ethernet driver. The PHY driver will be
> a davinci-MDIO device node (not yet in this series). I should probably
> add merge that with this series.
>
> The Ethernet device tree node will reference to these syscon nodes.
> e.g.
> pruss2_eth {
> compatible = "ti,am57-prueth";
> prus = <_0>, <_1>;
> firmware-name = "ti-pruss/am57xx-pru0-prueth-fw.elf",
> "ti-pruss/am57xx-pru1-prueth-fw.elf";
> sram = <>;
> interrupt-parent = <_intc>;
> --> mii-rt = <_mii_rt>;
> --> iep = <_iep>;
> }
>
> Do you see any issues with that?
Well maybe take a look at Grygorii's series adding proper
PHY driver for CPSW and see if it affects this too.
Regards,
Tony
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
* Roger Quadros [181126 07:48]:
> Not the PHY driver but the Ethernet driver. The PHY driver will be
> a davinci-MDIO device node (not yet in this series). I should probably
> add merge that with this series.
>
> The Ethernet device tree node will reference to these syscon nodes.
> e.g.
> pruss2_eth {
> compatible = "ti,am57-prueth";
> prus = <_0>, <_1>;
> firmware-name = "ti-pruss/am57xx-pru0-prueth-fw.elf",
> "ti-pruss/am57xx-pru1-prueth-fw.elf";
> sram = <>;
> interrupt-parent = <_intc>;
> --> mii-rt = <_mii_rt>;
> --> iep = <_iep>;
> }
>
> Do you see any issues with that?
Well maybe take a look at Grygorii's series adding proper
PHY driver for CPSW and see if it affects this too.
Regards,
Tony
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
Hi,
On 23/11/18 18:24, Tony Lindgren wrote:
> Hi,
>
> * Roger Quadros [181122 11:39]:
>> From: Suman Anna
>> +Example:
>> +
>> +1. /* AM33xx PRU-ICSS */
>> +pruss_soc_bus: pruss_soc_bus@4a326004 {
>> +compatible = "ti,am3356-pruss-soc-bus";
>> +ti,hwmods = "pruss";
>> +reg = <0x4a326004 0x4>;
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges;
>
> The top level interconnect target module driver should be just ti-sysc
> as documented in Documentation/devicetree/bindings/bus/ti-sysc.txt.
> AFAIK there is nothing PRU specific there. So let's not add yet
> another custom interconnect target module handling code to deal with.
>
> I also posted a patch a while back for using reset-simple with
> ti-sysc as "[PATCHv2] reset: ti-rstctrl: use the reset-simple driver".
>
Cool. I will try that out.
>> +pruss_cfg: cfg@4a326000 {
>> +compatible = "syscon";
>> +reg = <0x4a326000 0x2000>;
>> +};
>> +
>> +pruss_iep: iep@4a32e000 {
>> +compatible = "syscon";
>> +reg = <0x4a32e000 0x31c>;
>> +};
>> +
>> +pruss_mii_rt: mii_rt@4a332000 {
>> +compatible = "syscon";
>> +reg = <0x4a332000 0x58>;
>> +};
>
> Hmm what are these syscon register actually doing? Sseems like
> they should be just handled by a phy driver nowadays?
Not the PHY driver but the Ethernet driver. The PHY driver will be
a davinci-MDIO device node (not yet in this series). I should probably
add merge that with this series.
The Ethernet device tree node will reference to these syscon nodes.
e.g.
pruss2_eth {
compatible = "ti,am57-prueth";
prus = <_0>, <_1>;
firmware-name = "ti-pruss/am57xx-pru0-prueth-fw.elf",
"ti-pruss/am57xx-pru1-prueth-fw.elf";
sram = <>;
interrupt-parent = <_intc>;
--> mii-rt = <_mii_rt>;
--> iep = <_iep>;
}
Do you see any issues with that?
>
> Other than that the binding looks OK to me. Good to finally
> see some activity in getting the PRU support merged :)
Thanks :)
cheers,
-roger
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
Hi,
On 23/11/18 18:24, Tony Lindgren wrote:
> Hi,
>
> * Roger Quadros [181122 11:39]:
>> From: Suman Anna
>> +Example:
>> +
>> +1. /* AM33xx PRU-ICSS */
>> +pruss_soc_bus: pruss_soc_bus@4a326004 {
>> +compatible = "ti,am3356-pruss-soc-bus";
>> +ti,hwmods = "pruss";
>> +reg = <0x4a326004 0x4>;
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges;
>
> The top level interconnect target module driver should be just ti-sysc
> as documented in Documentation/devicetree/bindings/bus/ti-sysc.txt.
> AFAIK there is nothing PRU specific there. So let's not add yet
> another custom interconnect target module handling code to deal with.
>
> I also posted a patch a while back for using reset-simple with
> ti-sysc as "[PATCHv2] reset: ti-rstctrl: use the reset-simple driver".
>
Cool. I will try that out.
>> +pruss_cfg: cfg@4a326000 {
>> +compatible = "syscon";
>> +reg = <0x4a326000 0x2000>;
>> +};
>> +
>> +pruss_iep: iep@4a32e000 {
>> +compatible = "syscon";
>> +reg = <0x4a32e000 0x31c>;
>> +};
>> +
>> +pruss_mii_rt: mii_rt@4a332000 {
>> +compatible = "syscon";
>> +reg = <0x4a332000 0x58>;
>> +};
>
> Hmm what are these syscon register actually doing? Sseems like
> they should be just handled by a phy driver nowadays?
Not the PHY driver but the Ethernet driver. The PHY driver will be
a davinci-MDIO device node (not yet in this series). I should probably
add merge that with this series.
The Ethernet device tree node will reference to these syscon nodes.
e.g.
pruss2_eth {
compatible = "ti,am57-prueth";
prus = <_0>, <_1>;
firmware-name = "ti-pruss/am57xx-pru0-prueth-fw.elf",
"ti-pruss/am57xx-pru1-prueth-fw.elf";
sram = <>;
interrupt-parent = <_intc>;
--> mii-rt = <_mii_rt>;
--> iep = <_iep>;
}
Do you see any issues with that?
>
> Other than that the binding looks OK to me. Good to finally
> see some activity in getting the PRU support merged :)
Thanks :)
cheers,
-roger
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
Hi,
* Roger Quadros [181122 11:39]:
> From: Suman Anna
> +Example:
> +
> +1. /* AM33xx PRU-ICSS */
> + pruss_soc_bus: pruss_soc_bus@4a326004 {
> + compatible = "ti,am3356-pruss-soc-bus";
> + ti,hwmods = "pruss";
> + reg = <0x4a326004 0x4>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
The top level interconnect target module driver should be just ti-sysc
as documented in Documentation/devicetree/bindings/bus/ti-sysc.txt.
AFAIK there is nothing PRU specific there. So let's not add yet
another custom interconnect target module handling code to deal with.
I also posted a patch a while back for using reset-simple with
ti-sysc as "[PATCHv2] reset: ti-rstctrl: use the reset-simple driver".
> + pruss_cfg: cfg@4a326000 {
> + compatible = "syscon";
> + reg = <0x4a326000 0x2000>;
> + };
> +
> + pruss_iep: iep@4a32e000 {
> + compatible = "syscon";
> + reg = <0x4a32e000 0x31c>;
> + };
> +
> + pruss_mii_rt: mii_rt@4a332000 {
> + compatible = "syscon";
> + reg = <0x4a332000 0x58>;
> + };
Hmm what are these syscon register actually doing? Sseems like
they should be just handled by a phy driver nowadays?
Other than that the binding looks OK to me. Good to finally
see some activity in getting the PRU support merged :)
Regards,
Tony
Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
Hi,
* Roger Quadros [181122 11:39]:
> From: Suman Anna
> +Example:
> +
> +1. /* AM33xx PRU-ICSS */
> + pruss_soc_bus: pruss_soc_bus@4a326004 {
> + compatible = "ti,am3356-pruss-soc-bus";
> + ti,hwmods = "pruss";
> + reg = <0x4a326004 0x4>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
The top level interconnect target module driver should be just ti-sysc
as documented in Documentation/devicetree/bindings/bus/ti-sysc.txt.
AFAIK there is nothing PRU specific there. So let's not add yet
another custom interconnect target module handling code to deal with.
I also posted a patch a while back for using reset-simple with
ti-sysc as "[PATCHv2] reset: ti-rstctrl: use the reset-simple driver".
> + pruss_cfg: cfg@4a326000 {
> + compatible = "syscon";
> + reg = <0x4a326000 0x2000>;
> + };
> +
> + pruss_iep: iep@4a32e000 {
> + compatible = "syscon";
> + reg = <0x4a32e000 0x31c>;
> + };
> +
> + pruss_mii_rt: mii_rt@4a332000 {
> + compatible = "syscon";
> + reg = <0x4a332000 0x58>;
> + };
Hmm what are these syscon register actually doing? Sseems like
they should be just handled by a phy driver nowadays?
Other than that the binding looks OK to me. Good to finally
see some activity in getting the PRU support merged :)
Regards,
Tony
[PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
From: Suman Anna This patch adds the bindings for the Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS) present on various TI SoCs. The IP is present on multiple TI SoC architecture families including the OMAP architecture SoCs such as AM33xx, AM437x and AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is also present on the Davinci based OMAPL138 SoCs and K3 architecture based AM65x SoCs as well (not covered for now). Details have been added to include bindings for various core sub-modules like the PRU Cores, the PRUSS Interrupt Controller, and other sub-modules used for Industrial Communication purposes, covering the MDIO, MII_RT and the IEP sub-modules. The binding mostly uses standard DT properties. Signed-off-by: Suman Anna Signed-off-by: Roger Quadros --- .../devicetree/bindings/soc/ti/ti,pruss.txt| 360 + 1 file changed, 360 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.txt diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt new file mode 100644 index 000..24fedad --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt @@ -0,0 +1,360 @@ +PRU-ICSS on TI SoCs +=== + +The Programmable Real-Time Unit and Industrial Communication Subsystem +(PRU-ICSS) is present on various TI SoCs such as AM335x or AM437x or a +Keystone 66AK2G. A PRUSS consists of dual 32-bit RISC cores (Programmable +Real-Time Units, or PRUs), shared RAM, data and instruction RAMs, some +internal peripheral modules to facilitate industrial communication, and +an interrupt controller. The programmable nature of the PRUs provide +flexibility to implement custom peripheral interfaces, fast real-time +responses, or specialized data handling. The common peripheral modules +include the following, + - an Ethernet MII_RT module with two MII ports + - an MDIO port to control external Ethernet PHYs + - an Industrial Ethernet Peripheral (IEP) to manage/generate Industrial +Ethernet functions + - an Enhanced Capture Module (eCAP) + - an Industrial Ethernet Timer with 7/9 capture and 16 compare events + - a 16550-compatible UART to support PROFIBUS + +A PRU-ICSS subsystem can have up to three shared data memories. A PRU core +acts on a primary Data RAM (there are usually 2 Data RAMs) at its address +0x0, but also has access to a secondary Data RAM (primary to the other PRU +core) at its address 0x2000. A shared Data RAM, if present, can be accessed +by both the PRU cores. The Interrupt Controller (INTC) and a CFG module are +common to both the PRU cores. Each PRU core also has a private instruction RAM, +and specific register spaces for Control and Debug functionalities. + +Various sub-modules within a PRU-ICSS subsystem are represented as individual +nodes and are defined using a parent-child hierarchy depending on their +integration within the IP and the SoC. These nodes are described in the +following sections. + + +PRU-ICSS SoC Bus Parent Node += +This node represents the integration of the PRU-ICSS IP into a SoC, and is +required for all SoCs. The PRU-ICSS parent nodes need to be defined as child +nodes of this node. + +Required Properties: + +- compatible : should be one of, + "ti,am3356-pruss-soc-bus" for AM335x family of SoCs + "ti,am4376-pruss-soc-bus" for AM437x family of SoCs + "ti,am5728-pruss-soc-bus" for AM57xx family of SoCs + "ti,k2g-pruss-soc-bus" for 66AK2G family of SoCs +- reg: address and size of the PRUSS CFG sub-module registers + dictating the interconnect configuration +- #address-cells : should be 1 +- #size-cells: should be 1 +- ranges : standard ranges definition + +SoC-specific Required properties: +- + +The following are mandatory properties for all OMAP-architecture based SoCs: +- ti,hwmods : name of the hwmod associated with the PRUSS instance + +The following properties are _required_ only for Keystone 2 66AK2G SoCs only: +- power-domains : Should contain a phandle to a PM domain provider node and an + args specifier containing the PRUSS SCI device id value. This + property is as per the binding, + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + + +PRU-ICSS Parent Node += +Each PRU-ICSS subsystem instance is represented as a child node of +the PRUSS SoC bus node, with the individual PRU processor cores, a +memories node, an INTC node and an MDIO node represented as child nodes +within this parent PRUSS node. + +Required Properties: + +- compatible : should be one of, + "ti,am3356-pruss" for AM335x family of SoCs +
[PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
From: Suman Anna This patch adds the bindings for the Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS) present on various TI SoCs. The IP is present on multiple TI SoC architecture families including the OMAP architecture SoCs such as AM33xx, AM437x and AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is also present on the Davinci based OMAPL138 SoCs and K3 architecture based AM65x SoCs as well (not covered for now). Details have been added to include bindings for various core sub-modules like the PRU Cores, the PRUSS Interrupt Controller, and other sub-modules used for Industrial Communication purposes, covering the MDIO, MII_RT and the IEP sub-modules. The binding mostly uses standard DT properties. Signed-off-by: Suman Anna Signed-off-by: Roger Quadros --- .../devicetree/bindings/soc/ti/ti,pruss.txt| 360 + 1 file changed, 360 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.txt diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt new file mode 100644 index 000..24fedad --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.txt @@ -0,0 +1,360 @@ +PRU-ICSS on TI SoCs +=== + +The Programmable Real-Time Unit and Industrial Communication Subsystem +(PRU-ICSS) is present on various TI SoCs such as AM335x or AM437x or a +Keystone 66AK2G. A PRUSS consists of dual 32-bit RISC cores (Programmable +Real-Time Units, or PRUs), shared RAM, data and instruction RAMs, some +internal peripheral modules to facilitate industrial communication, and +an interrupt controller. The programmable nature of the PRUs provide +flexibility to implement custom peripheral interfaces, fast real-time +responses, or specialized data handling. The common peripheral modules +include the following, + - an Ethernet MII_RT module with two MII ports + - an MDIO port to control external Ethernet PHYs + - an Industrial Ethernet Peripheral (IEP) to manage/generate Industrial +Ethernet functions + - an Enhanced Capture Module (eCAP) + - an Industrial Ethernet Timer with 7/9 capture and 16 compare events + - a 16550-compatible UART to support PROFIBUS + +A PRU-ICSS subsystem can have up to three shared data memories. A PRU core +acts on a primary Data RAM (there are usually 2 Data RAMs) at its address +0x0, but also has access to a secondary Data RAM (primary to the other PRU +core) at its address 0x2000. A shared Data RAM, if present, can be accessed +by both the PRU cores. The Interrupt Controller (INTC) and a CFG module are +common to both the PRU cores. Each PRU core also has a private instruction RAM, +and specific register spaces for Control and Debug functionalities. + +Various sub-modules within a PRU-ICSS subsystem are represented as individual +nodes and are defined using a parent-child hierarchy depending on their +integration within the IP and the SoC. These nodes are described in the +following sections. + + +PRU-ICSS SoC Bus Parent Node += +This node represents the integration of the PRU-ICSS IP into a SoC, and is +required for all SoCs. The PRU-ICSS parent nodes need to be defined as child +nodes of this node. + +Required Properties: + +- compatible : should be one of, + "ti,am3356-pruss-soc-bus" for AM335x family of SoCs + "ti,am4376-pruss-soc-bus" for AM437x family of SoCs + "ti,am5728-pruss-soc-bus" for AM57xx family of SoCs + "ti,k2g-pruss-soc-bus" for 66AK2G family of SoCs +- reg: address and size of the PRUSS CFG sub-module registers + dictating the interconnect configuration +- #address-cells : should be 1 +- #size-cells: should be 1 +- ranges : standard ranges definition + +SoC-specific Required properties: +- + +The following are mandatory properties for all OMAP-architecture based SoCs: +- ti,hwmods : name of the hwmod associated with the PRUSS instance + +The following properties are _required_ only for Keystone 2 66AK2G SoCs only: +- power-domains : Should contain a phandle to a PM domain provider node and an + args specifier containing the PRUSS SCI device id value. This + property is as per the binding, + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + + +PRU-ICSS Parent Node += +Each PRU-ICSS subsystem instance is represented as a child node of +the PRUSS SoC bus node, with the individual PRU processor cores, a +memories node, an INTC node and an MDIO node represented as child nodes +within this parent PRUSS node. + +Required Properties: + +- compatible : should be one of, + "ti,am3356-pruss" for AM335x family of SoCs +
