* [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
@ 2018-11-22 11:38 ` Roger Quadros
2018-11-23 16:24 ` Tony Lindgren
2018-11-26 21:14 ` David Lechner
2018-11-22 11:38 ` [PATCH 02/17] soc: ti: pruss: Define platform data for PRUSS bus driver Roger Quadros
` (16 subsequent siblings)
17 siblings, 2 replies; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:38 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
From: Suman Anna <s-anna@ti.com>
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 <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
.../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 0000000..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
+ "ti,am4376-pruss" for AM437x family of SoCs
+ "ti,am5728-pruss" for AM57xx family of SoCs
+ "ti,k2g-pruss" for 66AK2G family of SoCs
+- reg : base address and size of the entire PRU-ICSS space
+- interrupts : all the interrupts generated towards the main host
+ processor in the SoC. The format depends on the
+ interrupt specifier for the particular SoC's MPU
+ parent interrupt controller
+- interrupt-names: should use one of the following names for each interrupt,
+ the name should match the corresponding host interrupt
+ number,
+ "host2", "host3", "host4", "host5", "host6",
+ "host7", "host8" or "host9"
+ NOTE: AM437x and 66AK2G SoCs do not have "host7" interrupt
+ connected to MPU
+- #address-cells : should be 1
+- #size-cells : should be 1
+- ranges : no specific range translations required, child nodes have the
+ same address view as the parent, so should be mentioned without
+ any value for the property
+
+
+PRU-ICSS Memories Node
+=======================
+The various Data RAMs within a PRU-ICSS are represented as a single
+node with the name 'memories'.
+
+Required Properties:
+--------------------
+- reg : base address and size for each of the Data RAMs as
+ mentioned in reg-names, and in the same order as the
+ reg-names
+- reg-names : should contain a string(s) from among the following names,
+ each representing a specific Data RAM region. A PRU-ICSS may
+ not have all of the Data RAMs. The binding is agnostic
+ of the order of these reg-names
+ "dram0" for Data RAM0,
+ "dram1" for Data RAM1,
+ "shrdram2" for Shared Data RAM,
+
+
+PRU-ICSS SysCon Nodes
+======================
+The individual sub-modules CFG, IEP and MII_RT are represented as a syscon
+node each for now with specific node names as below:
+ "cfg" for CFG sub-module,
+ "iep" for IEP sub-module,
+ "mii_rt" for MII-RT sub-module,
+
+
+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.
+
+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 of SoCs
+ "ti,k2g-pru" for 66AK2G family of SoCs
+- reg : base address and size for each of the 3 sub-module address
+ spaces as mentioned in reg-names, and in the same order as
+ the reg-names
+- reg-names : should contain each of the following 3 names, the binding is
+ agnostic of the order of these reg-names
+ "iram" for Instruction RAM,
+ "control" for the CTRL sub-module registers,
+ "debug" for the Debug sub-module registers,
+- firmware-name : should contain the name of the default firmware image file
+ located on the firmware search path
+
+
+MDIO Child Node
+================
+Each PRUSS has an MDIO module that can be used to control external PHYs. The
+MDIO module used within the PRU-ICSS is an instance of the MDIO Controller
+used in TI Davinci SoCs. Please refer to the corresponding binding document,
+Documentation/devicetree/bindings/net/davinci-mdio.txt for details.
+
+
+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;
+
+ pruss: pruss@4a300000 {
+ compatible = "ti,am3356-pruss";
+ reg = <0x4a300000 0x80000>;
+ interrupts = <20 21 22 23 24 25 26 27>;
+ interrupt-names = "host2", "host3", "host4",
+ "host5", "host6", "host7",
+ "host8", "host9";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pruss_mem: memories@4a300000 {
+ reg = <0x4a300000 0x2000>,
+ <0x4a302000 0x2000>,
+ <0x4a310000 0x3000>;
+ reg-names = "dram0", "dram1", "shrdram2";
+ };
+
+ 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>;
+ };
+
+ pruss_intc: intc@4a320000 {
+ compatible = "ti,am3356-pruss-intc";
+ reg = <0x4a320000 0x2000>;
+ reg-names = "intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ pru0: pru@4a334000 {
+ compatible = "ti,am3356-pru";
+ reg = <0x4a334000 0x2000>,
+ <0x4a322000 0x400>,
+ <0x4a322400 0x100>;
+ reg-names = "iram", "control", "debug";
+ firmware-name = "am335x-pru0-fw";
+ };
+
+ pru1: pru@4a338000 {
+ compatible = "ti,am3356-pru";
+ reg = <0x4a338000 0x2000>,
+ <0x4a324000 0x400>,
+ <0x4a324400 0x100>;
+ reg-names = "iram", "control", "debug";
+ firmware-name = "am335x-pru1-fw";
+ };
+
+ pruss_mdio: mdio@4a332400 {
+ compatible = "ti,davinci_mdio";
+ reg = <0x4a332400 0x90>;
+ clocks = <&dpll_core_m4_ck>;
+ clock-names = "fck";
+ bus_freq = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+
+2. /* AM43xx PRU-ICSS with PRUSS1 node (PRUSS0 not shown completely) */
+ pruss_soc_bus: pruss_soc_bus@54426004 {
+ compatible = "ti,am4376-pruss-soc-bus";
+ reg = <0x54426004 0x4>;
+ ti,hwmods = "pruss";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pruss1: pruss@54400000 {
+ compatible = "ti,am4376-pruss";
+ reg = <0x54400000 0x40000>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "host2", "host3", "host4",
+ "host5", "host6", "host8",
+ "host9";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pruss1_mem: memories@54400000 {
+ reg = <0x54400000 0x2000>,
+ <0x54402000 0x2000>,
+ <0x54410000 0x8000>;
+ reg-names = "dram0", "dram1", "shrdram2";
+ };
+
+ pruss1_cfg: cfg@54426000 {
+ compatible = "syscon";
+ reg = <0x54426000 0x2000>;
+ };
+
+ pruss1_iep: iep@5442e000 {
+ compatible = "syscon";
+ reg = <0x5442e000 0x31c>;
+ };
+
+ pruss1_mii_rt: mii_rt@54432000 {
+ compatible = "syscon";
+ reg = <0x54432000 0x58>;
+ };
+
+ pruss1_intc: intc@54420000 {
+ compatible = "ti,am4376-pruss-intc";
+ reg = <0x54420000 0x2000>;
+ reg-names = "intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ pru1_0: pru@54434000 {
+ compatible = "ti,am4376-pru";
+ reg = <0x54434000 0x3000>,
+ <0x54422000 0x400>,
+ <0x54422400 0x100>;
+ reg-names = "iram", "control", "debug";
+ firmware-name = "am437x-pru1_0-fw";
+ };
+
+ pru1_1: pru@54438000 {
+ compatible = "ti,am4376-pru";
+ reg = <0x54438000 0x3000>,
+ <0x54424000 0x400>,
+ <0x54424400 0x100>;
+ reg-names = "iram", "control", "debug";
+ firmware-name = "am437x-pru1_1-fw";
+ };
+
+ pruss1_mdio: mdio@54432400 {
+ compatible = "ti,davinci_mdio";
+ reg = <0x54432400 0x90>;
+ clocks = <&dpll_core_m4_ck>;
+ clock-names = "fck";
+ bus_freq = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+ };
+
+ pruss0: pruss@54440000 {
+ compatible = "ti,am4376-pruss";
+ reg = <0x54440000 0x40000>;
+ ...
+ };
+ };
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
2018-11-22 11:38 ` [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings Roger Quadros
@ 2018-11-23 16:24 ` Tony Lindgren
2018-11-26 7:47 ` Roger Quadros
2018-11-26 21:14 ` David Lechner
1 sibling, 1 reply; 53+ messages in thread
From: Tony Lindgren @ 2018-11-23 16:24 UTC (permalink / raw)
To: Roger Quadros
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
Hi,
* Roger Quadros <rogerq@ti.com> [181122 11:39]:
> From: Suman Anna <s-anna@ti.com>
> +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
^ permalink raw reply [flat|nested] 53+ messages in thread* Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
2018-11-23 16:24 ` Tony Lindgren
@ 2018-11-26 7:47 ` Roger Quadros
2018-11-26 19:35 ` Tony Lindgren
0 siblings, 1 reply; 53+ messages in thread
From: Roger Quadros @ 2018-11-26 7:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
Hi,
On 23/11/18 18:24, Tony Lindgren wrote:
> Hi,
>
> * Roger Quadros <rogerq@ti.com> [181122 11:39]:
>> From: Suman Anna <s-anna@ti.com>
>> +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 = <&pru2_0>, <&pru2_1>;
firmware-name = "ti-pruss/am57xx-pru0-prueth-fw.elf",
"ti-pruss/am57xx-pru1-prueth-fw.elf";
sram = <&ocmcram1>;
interrupt-parent = <&pruss2_intc>;
--> mii-rt = <&pruss2_mii_rt>;
--> iep = <&pruss2_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
^ permalink raw reply [flat|nested] 53+ messages in thread* Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
2018-11-26 7:47 ` Roger Quadros
@ 2018-11-26 19:35 ` Tony Lindgren
0 siblings, 0 replies; 53+ messages in thread
From: Tony Lindgren @ 2018-11-26 19:35 UTC (permalink / raw)
To: Roger Quadros
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, Grygorii Strashko
* Roger Quadros <rogerq@ti.com> [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 = <&pru2_0>, <&pru2_1>;
> firmware-name = "ti-pruss/am57xx-pru0-prueth-fw.elf",
> "ti-pruss/am57xx-pru1-prueth-fw.elf";
> sram = <&ocmcram1>;
> interrupt-parent = <&pruss2_intc>;
> --> mii-rt = <&pruss2_mii_rt>;
> --> iep = <&pruss2_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
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
2018-11-22 11:38 ` [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings Roger Quadros
2018-11-23 16:24 ` Tony Lindgren
@ 2018-11-26 21:14 ` David Lechner
2018-11-26 23:41 ` Tony Lindgren
2018-11-27 15:15 ` Roger Quadros
1 sibling, 2 replies; 53+ messages in thread
From: David Lechner @ 2018-11-26 21:14 UTC (permalink / raw)
To: Roger Quadros, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
On 11/22/18 5:38 AM, Roger Quadros wrote:
> From: Suman Anna <s-anna@ti.com>
>
> 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 <s-anna@ti.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> .../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 0000000..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 of SoCs
> + "ti,k2g-pru" for 66AK2G family of SoCs
> +- reg : base address and size for each of the 3 sub-module address
> + spaces as mentioned in reg-names, and in the same order as
> + the reg-names
> +- reg-names : should contain each of the following 3 names, the binding is
> + agnostic of the order of these reg-names
> + "iram" for Instruction RAM,
> + "control" for the CTRL sub-module registers,
> + "debug" for the Debug sub-module registers,
> +- firmware-name : should contain the name of the default firmware image file
> + located on the firmware search path
What does the default firmware do? It doesn't seem like this could be useful
since the PRU doesn't have a definite purpose.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
2018-11-26 21:14 ` David Lechner
@ 2018-11-26 23:41 ` Tony Lindgren
2018-11-27 15:15 ` Roger Quadros
1 sibling, 0 replies; 53+ messages in thread
From: Tony Lindgren @ 2018-11-26 23:41 UTC (permalink / raw)
To: David Lechner
Cc: Roger Quadros, robh+dt, bcousson, ssantosh, ohad,
bjorn.andersson, s-anna, nsekhar, t-kristo, nsaulnier, jreeder,
m-karicheri2, woods.technical, linux-omap, linux-remoteproc,
linux-kernel, devicetree
* David Lechner <david@lechnology.com> [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
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
2018-11-26 21:14 ` David Lechner
2018-11-26 23:41 ` Tony Lindgren
@ 2018-11-27 15:15 ` Roger Quadros
2018-11-28 15:42 ` David Lechner
1 sibling, 1 reply; 53+ messages in thread
From: Roger Quadros @ 2018-11-27 15:15 UTC (permalink / raw)
To: David Lechner, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
On 26/11/18 23:14, David Lechner wrote:
> On 11/22/18 5:38 AM, Roger Quadros wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> 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 <s-anna@ti.com>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>> .../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 0000000..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
>> + "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 of SoCs
>> + "ti,k2g-pru" for 66AK2G family of SoCs
>> +- reg : base address and size for each of the 3 sub-module address
>> + spaces as mentioned in reg-names, and in the same order as
>> + the reg-names
>> +- reg-names : should contain each of the following 3 names, the binding is
>> + agnostic of the order of these reg-names
>> + "iram" for Instruction RAM,
>> + "control" for the CTRL sub-module registers,
>> + "debug" for the Debug sub-module registers,
>> +- firmware-name : should contain the name of the default firmware image file
>> + located on the firmware search path
>
> What does the default firmware do? It doesn't seem like this could be useful
> since the PRU doesn't have a definite purpose.
There is no such firmware. I think I'll drop "default" from the description.
cheers,
-roger
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
2018-11-27 15:15 ` Roger Quadros
@ 2018-11-28 15:42 ` David Lechner
2018-11-29 8:49 ` Roger Quadros
0 siblings, 1 reply; 53+ messages in thread
From: David Lechner @ 2018-11-28 15:42 UTC (permalink / raw)
To: Roger Quadros, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
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 <s-anna@ti.com>
>>>
>>> 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 <s-anna@ti.com>
>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>> ---
>>> .../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 0000000..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 this would make it easy to end up with a broken interrupts
if you accidentally try to use interrupts from both groups. Instead this
could be implemented in the irqchip driver such that the first interrupt
(system event) requested gets to select the group. If any interrupts from
the other group are requested later, they can just return an error. Any
interrupts in the same group as the first can be requested successfully.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
2018-11-28 15:42 ` David Lechner
@ 2018-11-29 8:49 ` Roger Quadros
2018-11-29 16:18 ` David Lechner
0 siblings, 1 reply; 53+ messages in thread
From: Roger Quadros @ 2018-11-29 8:49 UTC (permalink / raw)
To: David Lechner, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
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 <s-anna@ti.com>
>>>>
>>>> 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 <s-anna@ti.com>
>>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>>> ---
>>>> .../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 0000000..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 AM18xx and OMAP-L13x SoCs.
How about modelling this as a linear map of 64 events and decode this internally in INTC driver.
i.e. 0 to 31 set PRUSSEVTSEL to 0 and 32 to 63 set PRUSSEVTSEL to 1.
If any interrupt map provides sysevents from both groups simultaneously then we complain and error out.
This should keep the dt-binding and resource table format identical across all SoCs.
>
>>
>> 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 this would make it easy to end up with a broken interrupts
> if you accidentally try to use interrupts from both groups. Instead this
> could be implemented in the irqchip driver such that the first interrupt
> (system event) requested gets to select the group. If any interrupts from
> the other group are requested later, they can just return an error. Any
> interrupts in the same group as the first can be requested successfully.
cheers,
-roger
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings
2018-11-29 8:49 ` Roger Quadros
@ 2018-11-29 16:18 ` David Lechner
0 siblings, 0 replies; 53+ messages in thread
From: David Lechner @ 2018-11-29 16:18 UTC (permalink / raw)
To: Roger Quadros, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
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 <s-anna@ti.com>
>>>>>
>>>>> 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 <s-anna@ti.com>
>>>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>>>> ---
>>>>> .../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 0000000..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 AM18xx and OMAP-L13x SoCs.
>
> How about modelling this as a linear map of 64 events and decode this internally in INTC driver.
> i.e. 0 to 31 set PRUSSEVTSEL to 0 and 32 to 63 set PRUSSEVTSEL to 1.
>
> If any interrupt map provides sysevents from both groups simultaneously then we complain and error out.
>
> This should keep the dt-binding and resource table format identical across all SoCs.
This sounds reasonable to me.
>
>>
>>>
>>> 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 this would make it easy to end up with a broken interrupts
>> if you accidentally try to use interrupts from both groups. Instead this
>> could be implemented in the irqchip driver such that the first interrupt
>> (system event) requested gets to select the group. If any interrupts from
>> the other group are requested later, they can just return an error. Any
>> interrupts in the same group as the first can be requested successfully.
>
> cheers,
> -roger
>
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 02/17] soc: ti: pruss: Define platform data for PRUSS bus driver
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
2018-11-22 11:38 ` [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings Roger Quadros
@ 2018-11-22 11:38 ` Roger Quadros
2018-11-22 11:38 ` [PATCH 03/17] soc: ti: pruss: Add pruss_soc_bus platform driver Roger Quadros
` (15 subsequent siblings)
17 siblings, 0 replies; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:38 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
From: Suman Anna <s-anna@ti.com>
The PRUSS can have a PRCM reset line associated with the IP on
some OMAP architecture based SoCs. The reset needs to be programmed
properly before accessing any of the internal registers in the PRUSS.
This functionality is achieved through the omap_device layer, which
is not exposed outside of mach-omap2 layer. Define a platform data
structure for PRUSS so that this API can be invoked through platform
data ops from the driver.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
include/linux/platform_data/ti-pruss.h | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 include/linux/platform_data/ti-pruss.h
diff --git a/include/linux/platform_data/ti-pruss.h b/include/linux/platform_data/ti-pruss.h
new file mode 100644
index 0000000..96a66cc
--- /dev/null
+++ b/include/linux/platform_data/ti-pruss.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Platform data for PRUSS on TI SoCs
+ *
+ * Copyright (C) 2014-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#ifndef _PLAT_TI_PRUSS_H
+#define _PLAT_TI_PRUSS_H
+
+struct platform_device;
+
+/**
+ * struct pruss_platform_data - PRUSS platform data
+ * @reset_name: name of the reset
+ * @assert_reset: PRU-specific handler for putting the device in reset
+ * @deassert_reset: PRU-specific handler for releasing the device from reset
+ */
+struct pruss_platform_data {
+ const char *reset_name;
+ int (*assert_reset)(struct platform_device *pdev, const char *name);
+ int (*deassert_reset)(struct platform_device *pdev, const char *name);
+};
+
+#endif /* _PLAT_TI_PRUSS_H */
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* [PATCH 03/17] soc: ti: pruss: Add pruss_soc_bus platform driver
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
2018-11-22 11:38 ` [PATCH 01/17] dt-bindings: remoteproc: Add TI PRUSS bindings Roger Quadros
2018-11-22 11:38 ` [PATCH 02/17] soc: ti: pruss: Define platform data for PRUSS bus driver Roger Quadros
@ 2018-11-22 11:38 ` Roger Quadros
2018-11-22 11:39 ` [PATCH 04/17] soc: ti: pruss: Fix system suspend/MStandby config issues Roger Quadros
` (14 subsequent siblings)
17 siblings, 0 replies; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:38 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
From: Suman Anna <s-anna@ti.com>
The Programmable Real-Time Unit - Industrial Communication
Subsystem (PRU-ICSS) is present of various TI SoCs such as
AM335x or AM437x or the Keystone 66AK2G. Each SoC can have
one or more PRUSS instances that may or may not be identical.
For example, AM335x SoCs have a single PRUSS, while AM437x has
two PRUSS instances PRUSS1 and PRUSS0, with the PRUSS0 being
a cut-down version of the PRUSS1.
The PRUSS consists of dual 32-bit RISC cores called the
Programmable Real-Time Units (PRUs), some shared, data and
instruction memories, some internal peripheral modules, 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 PRU-ICSS functionality is achieved through four different
modules, each implementing a platform driver addressing a
specific portion of the PRUSS. Some sub-modules of the PRU-ICSS
IP reuse some of the existing drivers (like davinci mdio driver
or the generic syscon driver). The pruss_soc_bus driver deals
with the SoC integration aspects of the PRUSS IP(s) and manages
the common clock, reset and interconnect configuration and
creates the child PRUSS devices. The second pruss driver is
responsible for the creation and deletion of various platform
devices for the child PRU device and other child devices. A third
driver manages the PRUSS interrupt controller and implements an
irqchip driver to provide a Linux standard way of interrupt
management to PRU clients. The fourth platform driver is a
remoteproc driver and performs the individual PRU RISC cores
management. This design provides flexibility in representing
the different modules of PRUSS accordingly.
This patch introduces the first part i.e. pruss_soc_bus driver.
The driver currently supports the AM335x SoC.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/soc/ti/Kconfig | 11 ++++
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/pruss_soc_bus.c | 142 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 154 insertions(+)
create mode 100644 drivers/soc/ti/pruss_soc_bus.c
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index be4570b..d1ea6da 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -73,4 +73,15 @@ config TI_SCI_PM_DOMAINS
called ti_sci_pm_domains. Note this is needed early in boot before
rootfs may be available.
+config TI_PRUSS
+ tristate "TI PRU-ICSS Subsystem Platform drivers"
+ depends on SOC_AM33XX
+ default n
+ help
+ TI PRU-ICSS Subsystem platform specific support.
+
+ Say Y or M here to support the Programmable Realtime Unit (PRU)
+ processors on various TI SoCs. It's safe to say N here if you're
+ not interested in the PRU or if you are unsure.
+
endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index a22edc0..ac6b695 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
obj-$(CONFIG_AMX3_PM) += pm33xx.o
obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
+obj-$(CONFIG_TI_PRUSS) += pruss_soc_bus.o
diff --git a/drivers/soc/ti/pruss_soc_bus.c b/drivers/soc/ti/pruss_soc_bus.c
new file mode 100644
index 0000000..16b4802
--- /dev/null
+++ b/drivers/soc/ti/pruss_soc_bus.c
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PRU-ICSS SoC bus driver for various TI SoCs
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Suman Anna <s-anna@ti.com>
+ * Keerthy <j-keerthy@ti.com>
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+
+#include <linux/platform_data/ti-pruss.h>
+
+/**
+ * struct pruss_soc_bus - PRUSS SoC bus structure
+ * @syscfg: kernel mapped address for SYSCFG register
+ * @has_reset: cached variable for storing global module reset flag
+ */
+struct pruss_soc_bus {
+ void __iomem *syscfg;
+ bool has_reset;
+};
+
+/**
+ * struct pruss_soc_bus_match_data - PRUSS SoC bus driver match data
+ * @has_reset: flag to indicate the presence of global module reset
+ */
+struct pruss_soc_bus_match_data {
+ bool has_reset;
+};
+
+static int pruss_soc_bus_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *node = dev->of_node;
+ struct pruss_platform_data *pdata = dev_get_platdata(dev);
+ struct pruss_soc_bus *psoc_bus;
+ const struct pruss_soc_bus_match_data *data;
+ int ret;
+
+ psoc_bus = devm_kzalloc(dev, sizeof(*psoc_bus), GFP_KERNEL);
+ if (!psoc_bus)
+ return -ENOMEM;
+
+ psoc_bus->syscfg = of_iomap(node, 0);
+ if (!psoc_bus->syscfg)
+ return -ENOMEM;
+
+ data = of_device_get_match_data(dev);
+ if (!data) {
+ dev_err(dev, "missing match data\n");
+ return -ENODEV;
+ }
+
+ if (data->has_reset && (!pdata || !pdata->deassert_reset ||
+ !pdata->assert_reset || !pdata->reset_name)) {
+ dev_err(dev, "platform data (reset configuration information) missing\n");
+ return -ENODEV;
+ }
+ psoc_bus->has_reset = data->has_reset;
+ platform_set_drvdata(pdev, psoc_bus);
+
+ if (psoc_bus->has_reset) {
+ ret = pdata->deassert_reset(pdev, pdata->reset_name);
+ if (ret) {
+ dev_err(dev, "deassert_reset failed: %d\n", ret);
+ goto fail_reset;
+ }
+ }
+
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(dev);
+ goto fail_clock;
+ }
+
+ ret = of_platform_populate(node, NULL, NULL, dev);
+ if (ret)
+ goto fail_of;
+
+ return 0;
+
+fail_of:
+ pm_runtime_put_sync(dev);
+fail_clock:
+ pm_runtime_disable(dev);
+ if (psoc_bus->has_reset)
+ pdata->assert_reset(pdev, pdata->reset_name);
+fail_reset:
+ iounmap(psoc_bus->syscfg);
+ return ret;
+}
+
+static int pruss_soc_bus_remove(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct pruss_platform_data *pdata = dev_get_platdata(dev);
+ struct pruss_soc_bus *psoc_bus = platform_get_drvdata(pdev);
+
+ of_platform_depopulate(dev);
+
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
+
+ if (psoc_bus->has_reset)
+ pdata->assert_reset(pdev, pdata->reset_name);
+ iounmap(psoc_bus->syscfg);
+
+ return 0;
+}
+
+/* instance-specific driver private data */
+static const struct pruss_soc_bus_match_data am335x_data = {
+ .has_reset = true,
+};
+
+static const struct of_device_id pruss_soc_bus_of_match[] = {
+ { .compatible = "ti,am3356-pruss-soc-bus", .data = &am335x_data, },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, pruss_soc_bus_of_match);
+
+static struct platform_driver pruss_soc_bus_driver = {
+ .driver = {
+ .name = "pruss-soc-bus",
+ .of_match_table = pruss_soc_bus_of_match,
+ },
+ .probe = pruss_soc_bus_probe,
+ .remove = pruss_soc_bus_remove,
+};
+module_platform_driver(pruss_soc_bus_driver);
+
+MODULE_AUTHOR("Suman Anna <s-anna@ti.com>");
+MODULE_AUTHOR("Keerthy <j-keerthy@ti.com>");
+MODULE_DESCRIPTION("PRU-ICSS SoC Bus Driver for TI SoCs");
+MODULE_LICENSE("GPL v2");
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* [PATCH 04/17] soc: ti: pruss: Fix system suspend/MStandby config issues
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
` (2 preceding siblings ...)
2018-11-22 11:38 ` [PATCH 03/17] soc: ti: pruss: Add pruss_soc_bus platform driver Roger Quadros
@ 2018-11-22 11:39 ` Roger Quadros
2018-11-22 11:39 ` [PATCH 05/17] soc: ti: pruss: Configure SYSCFG properly during probe/remove Roger Quadros
` (13 subsequent siblings)
17 siblings, 0 replies; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:39 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
From: Suman Anna <s-anna@ti.com>
The PRU-ICSS subsystem has a separate PRUSS_CFG module that contains
various configuration registers. This includes a control bit STANDBY_INIT
in PRUSS_CFG register to initiate a Standby sequence (when set) and
trigger a MStandby request to the SoC's PRCM module. This same bit is
also used to enable the OCP master ports (when cleared). The system
suspend/resume functionality on AM33xx/AM437x/AM57xx SoCs requires
all initiators to assert their MStandby signal properly inorder to
successfully enter suspend, and resume on a wakeup event.
Certain firmwares can enable the OCP master ports through the
STANDBY_INIT programming on the firmware side in order to access
peripherals or memories external to the PRUSS. This causes a hang
in the resume sequence on AM33xx/AM437x boards and requires a
board reset to come out of the hang.
This patch adds the preliminary System PM callbacks in the PRUSS SoC
bus driver, and fixes this system resume hang by setting the STANDBY_INIT
in the PM system suspend callback and resetting it back in the PM system
resume callback, if so configured. The clearing of the STANDBY_INIT
during resume requires an acknowledgment from PRCM and is done through
the monitoring of the PRUSS_SYSCFG.SUB_MWAIT bit.
NOTE:
1. This patch only adds the PM callbacks with code to fix the System
Suspend/Resume hang issue on AM33xx/AM437x SoCs, but does not
implement the full context save and restore required for the PRUSS
drivers to work across system suspend/resume when the power domain
is switched off (L4PER domain is switched OFF on AM335x/AM437x
during system suspend/resume, so PRUSS modules do lose context).
2. The PRUSS driver functionality on AM57xx SoCs is not affected that
much because the PER power domain to which the PRUSS IPs belong is
not switched OFF during suspend/resume.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/soc/ti/pruss_soc_bus.c | 85 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 85 insertions(+)
diff --git a/drivers/soc/ti/pruss_soc_bus.c b/drivers/soc/ti/pruss_soc_bus.c
index 16b4802..d4da55d2 100644
--- a/drivers/soc/ti/pruss_soc_bus.c
+++ b/drivers/soc/ti/pruss_soc_bus.c
@@ -7,6 +7,7 @@
* Keerthy <j-keerthy@ti.com>
*/
+#include <linux/delay.h>
#include <linux/io.h>
#include <linux/module.h>
#include <linux/of_platform.h>
@@ -16,13 +17,18 @@
#include <linux/platform_data/ti-pruss.h>
+#define SYSCFG_STANDBY_INIT BIT(4)
+#define SYSCFG_SUB_MWAIT_READY BIT(5)
+
/**
* struct pruss_soc_bus - PRUSS SoC bus structure
* @syscfg: kernel mapped address for SYSCFG register
+ * @in_standby: flag for storing standby status
* @has_reset: cached variable for storing global module reset flag
*/
struct pruss_soc_bus {
void __iomem *syscfg;
+ bool in_standby;
bool has_reset;
};
@@ -34,6 +40,81 @@ struct pruss_soc_bus_match_data {
bool has_reset;
};
+static inline void pruss_soc_bus_rmw(void __iomem *reg, u32 mask, u32 set)
+{
+ u32 val;
+
+ val = readl_relaxed(reg);
+ val &= ~mask;
+ val |= (set & mask);
+ writel_relaxed(val, reg);
+}
+
+/*
+ * This function programs the PRUSS_SYSCFG.STANDBY_INIT bit to achieve dual
+ * functionalities - one is to deassert the MStandby signal to the device
+ * PRCM, and the other is to enable OCP master ports to allow accesses
+ * outside of the PRU-ICSS. The function has to wait for the PRCM to
+ * acknowledge through the monitoring of the PRUSS_SYSCFG.SUB_MWAIT bit.
+ */
+static
+int __maybe_unused pruss_soc_bus_enable_ocp_master_ports(struct device *dev)
+{
+ struct pruss_soc_bus *psoc_bus = dev_get_drvdata(dev);
+ u32 syscfg_val, i;
+ bool ready = false;
+
+ pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_STANDBY_INIT, 0);
+
+ /* wait till we are ready for transactions - delay is arbitrary */
+ for (i = 0; i < 10; i++) {
+ syscfg_val = readl_relaxed(psoc_bus->syscfg);
+ ready = !(syscfg_val & SYSCFG_SUB_MWAIT_READY);
+ if (ready)
+ break;
+ udelay(5);
+ }
+
+ if (!ready) {
+ dev_err(dev, "timeout waiting for SUB_MWAIT_READY\n");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+static int __maybe_unused pruss_soc_bus_suspend(struct device *dev)
+{
+ struct pruss_soc_bus *psoc_bus = dev_get_drvdata(dev);
+ u32 syscfg_val;
+
+ syscfg_val = readl_relaxed(psoc_bus->syscfg);
+ psoc_bus->in_standby = syscfg_val & SYSCFG_STANDBY_INIT;
+
+ /* initiate MStandby, undo the MStandby config in probe */
+ if (!psoc_bus->in_standby) {
+ pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_STANDBY_INIT,
+ SYSCFG_STANDBY_INIT);
+ }
+
+ return 0;
+}
+
+static int __maybe_unused pruss_soc_bus_resume(struct device *dev)
+{
+ struct pruss_soc_bus *psoc_bus = dev_get_drvdata(dev);
+ int ret = 0;
+
+ /* re-enable OCP master ports/disable MStandby */
+ if (!psoc_bus->in_standby) {
+ ret = pruss_soc_bus_enable_ocp_master_ports(dev);
+ if (ret)
+ dev_err(dev, "%s failed\n", __func__);
+ }
+
+ return ret;
+}
+
static int pruss_soc_bus_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -126,9 +207,13 @@ static const struct of_device_id pruss_soc_bus_of_match[] = {
};
MODULE_DEVICE_TABLE(of, pruss_soc_bus_of_match);
+static SIMPLE_DEV_PM_OPS(pruss_soc_bus_pm_ops,
+ pruss_soc_bus_suspend, pruss_soc_bus_resume);
+
static struct platform_driver pruss_soc_bus_driver = {
.driver = {
.name = "pruss-soc-bus",
+ .pm = &pruss_soc_bus_pm_ops,
.of_match_table = pruss_soc_bus_of_match,
},
.probe = pruss_soc_bus_probe,
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* [PATCH 05/17] soc: ti: pruss: Configure SYSCFG properly during probe/remove
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
` (3 preceding siblings ...)
2018-11-22 11:39 ` [PATCH 04/17] soc: ti: pruss: Fix system suspend/MStandby config issues Roger Quadros
@ 2018-11-22 11:39 ` Roger Quadros
2018-11-23 16:26 ` Tony Lindgren
2018-11-22 11:39 ` [PATCH 06/17] soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs Roger Quadros
` (12 subsequent siblings)
17 siblings, 1 reply; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:39 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
From: Suman Anna <s-anna@ti.com>
The PRUSS CFG module's SYSCFG register is used for managing the
PRCM clock management settings at the PRU-ICSS subsystem level.
Add two helper functions pruss_{enable/disable}_module() that
programs this SYSCFG register during probe and remove. The
register is currently programmed for the default Smart-Idle
and Smart-Standby always during probe. The MStandby is enabled
during remove to undo the settings in probe to properly configure
the SYSCFG in the case that a firmware has disabled MStandby.
This is needed on SoCs like AM57xx that do not have a reset line
and so cannot reset the register properly.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/soc/ti/pruss_soc_bus.c | 60 +++++++++++++++++++++++++++++++++++++-----
1 file changed, 54 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/ti/pruss_soc_bus.c b/drivers/soc/ti/pruss_soc_bus.c
index d4da55d2..46dfb7a 100644
--- a/drivers/soc/ti/pruss_soc_bus.c
+++ b/drivers/soc/ti/pruss_soc_bus.c
@@ -20,6 +20,16 @@
#define SYSCFG_STANDBY_INIT BIT(4)
#define SYSCFG_SUB_MWAIT_READY BIT(5)
+#define SYSCFG_STANDBY_MODE_FORCE (0 << 2)
+#define SYSCFG_STANDBY_MODE_NO (1 << 2)
+#define SYSCFG_STANDBY_MODE_SMART (2 << 2)
+#define SYSCFG_STANDBY_MODE_MASK (3 << 2)
+
+#define SYSCFG_IDLE_MODE_FORCE 0
+#define SYSCFG_IDLE_MODE_NO 1
+#define SYSCFG_IDLE_MODE_SMART 2
+#define SYSCFG_IDLE_MODE_MASK 3
+
/**
* struct pruss_soc_bus - PRUSS SoC bus structure
* @syscfg: kernel mapped address for SYSCFG register
@@ -115,6 +125,44 @@ static int __maybe_unused pruss_soc_bus_resume(struct device *dev)
return ret;
}
+/* firmware must be idle when calling this function */
+static void pruss_disable_module(struct device *dev)
+{
+ struct pruss_soc_bus *psoc_bus = dev_get_drvdata(dev);
+
+ /* configure Smart Standby */
+ pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_STANDBY_MODE_MASK,
+ SYSCFG_STANDBY_MODE_SMART);
+
+ /* initiate MStandby */
+ pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_STANDBY_INIT,
+ SYSCFG_STANDBY_INIT);
+
+ /* tell PRCM to initiate IDLE request */
+ pm_runtime_put_sync(dev);
+}
+
+static int pruss_enable_module(struct device *dev)
+{
+ struct pruss_soc_bus *psoc_bus = dev_get_drvdata(dev);
+ int ret;
+
+ /* tell PRCM to de-assert IDLE request */
+ ret = pm_runtime_get_sync(dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(dev);
+ return ret;
+ }
+
+ /* configure for Smart Idle & Smart Standby */
+ pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_IDLE_MODE_MASK,
+ SYSCFG_IDLE_MODE_SMART);
+ pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_STANDBY_MODE_MASK,
+ SYSCFG_STANDBY_MODE_SMART);
+
+ return ret;
+}
+
static int pruss_soc_bus_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -155,10 +203,10 @@ static int pruss_soc_bus_probe(struct platform_device *pdev)
}
pm_runtime_enable(dev);
- ret = pm_runtime_get_sync(dev);
+ ret = pruss_enable_module(dev);
if (ret < 0) {
- pm_runtime_put_noidle(dev);
- goto fail_clock;
+ dev_err(dev, "couldn't enable module\n");
+ goto fail_module;
}
ret = of_platform_populate(node, NULL, NULL, dev);
@@ -168,8 +216,8 @@ static int pruss_soc_bus_probe(struct platform_device *pdev)
return 0;
fail_of:
- pm_runtime_put_sync(dev);
-fail_clock:
+ pruss_disable_module(dev);
+fail_module:
pm_runtime_disable(dev);
if (psoc_bus->has_reset)
pdata->assert_reset(pdev, pdata->reset_name);
@@ -186,7 +234,7 @@ static int pruss_soc_bus_remove(struct platform_device *pdev)
of_platform_depopulate(dev);
- pm_runtime_put_sync(dev);
+ pruss_disable_module(dev);
pm_runtime_disable(dev);
if (psoc_bus->has_reset)
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* Re: [PATCH 05/17] soc: ti: pruss: Configure SYSCFG properly during probe/remove
2018-11-22 11:39 ` [PATCH 05/17] soc: ti: pruss: Configure SYSCFG properly during probe/remove Roger Quadros
@ 2018-11-23 16:26 ` Tony Lindgren
0 siblings, 0 replies; 53+ messages in thread
From: Tony Lindgren @ 2018-11-23 16:26 UTC (permalink / raw)
To: Roger Quadros
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
* Roger Quadros <rogerq@ti.com> [181122 11:39]:
> +/* firmware must be idle when calling this function */
> +static void pruss_disable_module(struct device *dev)
> +{
> + struct pruss_soc_bus *psoc_bus = dev_get_drvdata(dev);
> +
> + /* configure Smart Standby */
> + pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_STANDBY_MODE_MASK,
> + SYSCFG_STANDBY_MODE_SMART);
> +
> + /* initiate MStandby */
> + pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_STANDBY_INIT,
> + SYSCFG_STANDBY_INIT);
> +
> + /* tell PRCM to initiate IDLE request */
> + pm_runtime_put_sync(dev);
> +}
> +
> +static int pruss_enable_module(struct device *dev)
> +{
> + struct pruss_soc_bus *psoc_bus = dev_get_drvdata(dev);
> + int ret;
> +
> + /* tell PRCM to de-assert IDLE request */
> + ret = pm_runtime_get_sync(dev);
> + if (ret < 0) {
> + pm_runtime_put_noidle(dev);
> + return ret;
> + }
> +
> + /* configure for Smart Idle & Smart Standby */
> + pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_IDLE_MODE_MASK,
> + SYSCFG_IDLE_MODE_SMART);
> + pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_STANDBY_MODE_MASK,
> + SYSCFG_STANDBY_MODE_SMART);
> +
> + return ret;
> +}
Yeah so nothing PRU specific here, this you should be able to
handle in a generic way with drivers/bus/ti-sysc.c.
Regards,
Tony
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 06/17] soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
` (4 preceding siblings ...)
2018-11-22 11:39 ` [PATCH 05/17] soc: ti: pruss: Configure SYSCFG properly during probe/remove Roger Quadros
@ 2018-11-22 11:39 ` Roger Quadros
2018-11-26 21:15 ` David Lechner
2018-11-22 11:39 ` [PATCH 07/17] soc: ti: pruss: enable OCP master ports in SYSCFG always Roger Quadros
` (11 subsequent siblings)
17 siblings, 1 reply; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:39 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
From: Suman Anna <s-anna@ti.com>
The PRUSS platform driver deals with the overall PRUSS and is
used for managing the subsystem level resources like various
memories. It is responsible for the creation and deletion of
the platform devices for the child PRU devices and other child
devices (Interrupt Controller or MDIO node or some syscon nodes)
so that they can be managed by specific platform drivers.
This design provides flexibility in representing the different
modules of PRUSS accordingly, and at the same time allowing the
PRUSS driver to add some instance specific configuration within
an SoC.
The driver currently supports the AM335x SoC.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/soc/ti/Makefile | 2 +-
drivers/soc/ti/pruss.c | 116 ++++++++++++++++++++++++++++++++++++++++++++++++
drivers/soc/ti/pruss.h | 44 ++++++++++++++++++
3 files changed, 161 insertions(+), 1 deletion(-)
create mode 100644 drivers/soc/ti/pruss.c
create mode 100644 drivers/soc/ti/pruss.h
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index ac6b695..5a0c89d 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -8,4 +8,4 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
obj-$(CONFIG_AMX3_PM) += pm33xx.o
obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
-obj-$(CONFIG_TI_PRUSS) += pruss_soc_bus.o
+obj-$(CONFIG_TI_PRUSS) += pruss_soc_bus.o pruss.o
diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c
new file mode 100644
index 0000000..0840b59
--- /dev/null
+++ b/drivers/soc/ti/pruss.c
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PRU-ICSS platform driver for various TI SoCs
+ *
+ * Copyright (C) 2014-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Suman Anna <s-anna@ti.com>
+ * Andrew F. Davis <afd@ti.com>
+ */
+
+#include <linux/dma-mapping.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+
+#include "pruss.h"
+
+static int pruss_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *node = dev->of_node;
+ struct device_node *np;
+ struct pruss *pruss;
+ struct resource res;
+ int ret, i, index;
+ const char *mem_names[PRUSS_MEM_MAX] = { "dram0", "dram1", "shrdram2" };
+
+ if (!node) {
+ dev_err(dev, "Non-DT platform device not supported\n");
+ return -ENODEV;
+ }
+
+ ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
+ if (ret) {
+ dev_err(dev, "dma_set_coherent_mask: %d\n", ret);
+ return ret;
+ }
+
+ pruss = devm_kzalloc(dev, sizeof(*pruss), GFP_KERNEL);
+ if (!pruss)
+ return -ENOMEM;
+
+ pruss->dev = dev;
+
+ np = of_get_child_by_name(node, "memories");
+ if (!np)
+ return -ENODEV;
+
+ for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
+ index = of_property_match_string(np, "reg-names", mem_names[i]);
+ if (index < 0) {
+ of_node_put(np);
+ return index;
+ }
+
+ if (of_address_to_resource(np, index, &res)) {
+ of_node_put(np);
+ return -EINVAL;
+ }
+
+ pruss->mem_regions[i].va = devm_ioremap(dev, res.start,
+ resource_size(&res));
+ if (!pruss->mem_regions[i].va) {
+ dev_err(dev, "failed to parse and map memory resource %d %s\n",
+ i, mem_names[i]);
+ of_node_put(np);
+ return -ENOMEM;
+ }
+ pruss->mem_regions[i].pa = res.start;
+ pruss->mem_regions[i].size = resource_size(&res);
+
+ dev_dbg(dev, "memory %8s: pa %pa size 0x%zx va %p\n",
+ mem_names[i], &pruss->mem_regions[i].pa,
+ pruss->mem_regions[i].size, pruss->mem_regions[i].va);
+ }
+ of_node_put(np);
+
+ platform_set_drvdata(pdev, pruss);
+
+ dev_info(&pdev->dev, "creating PRU cores and other child platform devices\n");
+ ret = of_platform_populate(node, NULL, NULL, &pdev->dev);
+ if (ret)
+ dev_err(dev, "of_platform_populate failed\n");
+
+ return ret;
+}
+
+static int pruss_remove(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+
+ dev_info(dev, "remove PRU cores and other child platform devices\n");
+ of_platform_depopulate(dev);
+
+ return 0;
+}
+
+static const struct of_device_id pruss_of_match[] = {
+ { .compatible = "ti,am3356-pruss", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, pruss_of_match);
+
+static struct platform_driver pruss_driver = {
+ .driver = {
+ .name = "pruss",
+ .of_match_table = pruss_of_match,
+ },
+ .probe = pruss_probe,
+ .remove = pruss_remove,
+};
+module_platform_driver(pruss_driver);
+
+MODULE_AUTHOR("Suman Anna <s-anna@ti.com>");
+MODULE_DESCRIPTION("PRU-ICSS Subsystem Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/soc/ti/pruss.h b/drivers/soc/ti/pruss.h
new file mode 100644
index 0000000..dbdf475
--- /dev/null
+++ b/drivers/soc/ti/pruss.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * PRU-ICSS sub-system specific definitions
+ *
+ * Copyright (C) 2014-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Suman Anna <s-anna@ti.com>
+ */
+
+#ifndef _PRUSS_H_
+#define _PRUSS_H_
+
+/**
+ * enum pruss_mem - PRUSS memory range identifiers
+ */
+enum pruss_mem {
+ PRUSS_MEM_DRAM0 = 0,
+ PRUSS_MEM_DRAM1,
+ PRUSS_MEM_SHRD_RAM2,
+ PRUSS_MEM_MAX,
+};
+
+/**
+ * struct pruss_mem_region - PRUSS memory region structure
+ * @va: kernel virtual address of the PRUSS memory region
+ * @pa: physical (bus) address of the PRUSS memory region
+ * @size: size of the PRUSS memory region
+ */
+struct pruss_mem_region {
+ void __iomem *va;
+ phys_addr_t pa;
+ size_t size;
+};
+
+/**
+ * struct pruss - PRUSS parent structure
+ * @dev: pruss device pointer
+ * @mem_regions: data for each of the PRUSS memory regions
+ */
+struct pruss {
+ struct device *dev;
+ struct pruss_mem_region mem_regions[PRUSS_MEM_MAX];
+};
+
+#endif /* _PRUSS_H_ */
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* Re: [PATCH 06/17] soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs
2018-11-22 11:39 ` [PATCH 06/17] soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs Roger Quadros
@ 2018-11-26 21:15 ` David Lechner
2018-11-27 15:17 ` Roger Quadros
0 siblings, 1 reply; 53+ messages in thread
From: David Lechner @ 2018-11-26 21:15 UTC (permalink / raw)
To: Roger Quadros, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
On 11/22/18 5:39 AM, Roger Quadros wrote:
> From: Suman Anna <s-anna@ti.com>
>
> The PRUSS platform driver deals with the overall PRUSS and is
> used for managing the subsystem level resources like various
> memories. It is responsible for the creation and deletion of
> the platform devices for the child PRU devices and other child
> devices (Interrupt Controller or MDIO node or some syscon nodes)
> so that they can be managed by specific platform drivers.
>
> This design provides flexibility in representing the different
> modules of PRUSS accordingly, and at the same time allowing the
> PRUSS driver to add some instance specific configuration within
> an SoC.
>
> The driver currently supports the AM335x SoC.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> drivers/soc/ti/Makefile | 2 +-
> drivers/soc/ti/pruss.c | 116 ++++++++++++++++++++++++++++++++++++++++++++++++
> drivers/soc/ti/pruss.h | 44 ++++++++++++++++++
> 3 files changed, 161 insertions(+), 1 deletion(-)
> create mode 100644 drivers/soc/ti/pruss.c
> create mode 100644 drivers/soc/ti/pruss.h
>
...
> diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c
> new file mode 100644
> index 0000000..0840b59
> --- /dev/null
> +++ b/drivers/soc/ti/pruss.c
> @@ -0,0 +1,116 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PRU-ICSS platform driver for various TI SoCs
> + *
> + * Copyright (C) 2014-2018 Texas Instruments Incorporated - http://www.ti.com/
> + * Suman Anna <s-anna@ti.com>
> + * Andrew F. Davis <afd@ti.com>
> + */
> +
> +#include <linux/dma-mapping.h>
> +#include <linux/module.h>
alphabetical order?
> +#include <linux/io.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +
> +#include "pruss.h"
> +
> +static int pruss_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *node = dev->of_node;
> + struct device_node *np;
> + struct pruss *pruss;
> + struct resource res;
> + int ret, i, index;
> + const char *mem_names[PRUSS_MEM_MAX] = { "dram0", "dram1", "shrdram2" };
> +
> + if (!node) {
> + dev_err(dev, "Non-DT platform device not supported\n");
> + return -ENODEV;
> + }
> +
> + ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
> + if (ret) {
> + dev_err(dev, "dma_set_coherent_mask: %d\n", ret);
> + return ret;
> + }
> +
> + pruss = devm_kzalloc(dev, sizeof(*pruss), GFP_KERNEL);
> + if (!pruss)
> + return -ENOMEM;
> +
> + pruss->dev = dev;
> +
> + np = of_get_child_by_name(node, "memories");
> + if (!np)
error message?
> + return -ENODEV;
> +
> + for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
> + index = of_property_match_string(np, "reg-names", mem_names[i]);
> + if (index < 0) {
> + of_node_put(np);
> + return index;
> + }
> +
> + if (of_address_to_resource(np, index, &res)) {
> + of_node_put(np);
> + return -EINVAL;
> + }
> +
> + pruss->mem_regions[i].va = devm_ioremap(dev, res.start,
> + resource_size(&res));
> + if (!pruss->mem_regions[i].va) {
> + dev_err(dev, "failed to parse and map memory resource %d %s\n",
> + i, mem_names[i]);
> + of_node_put(np);
> + return -ENOMEM;
> + }
> + pruss->mem_regions[i].pa = res.start;
> + pruss->mem_regions[i].size = resource_size(&res);
> +
> + dev_dbg(dev, "memory %8s: pa %pa size 0x%zx va %p\n",
> + mem_names[i], &pruss->mem_regions[i].pa,
> + pruss->mem_regions[i].size, pruss->mem_regions[i].va);
> + }
> + of_node_put(np);
> +
> + platform_set_drvdata(pdev, pruss);
> +
> + dev_info(&pdev->dev, "creating PRU cores and other child platform devices\n");
Is this really needed? Or dev_dbg instead?
> + ret = of_platform_populate(node, NULL, NULL, &pdev->dev);
> + if (ret)
> + dev_err(dev, "of_platform_populate failed\n");
> +
> + return ret;
> +}
> +
> +static int pruss_remove(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> +
> + dev_info(dev, "remove PRU cores and other child platform devices\n");
same here... looks like debug message
> + of_platform_depopulate(dev);
> +
> + return 0;
> +}
> +
^ permalink raw reply [flat|nested] 53+ messages in thread* Re: [PATCH 06/17] soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs
2018-11-26 21:15 ` David Lechner
@ 2018-11-27 15:17 ` Roger Quadros
0 siblings, 0 replies; 53+ messages in thread
From: Roger Quadros @ 2018-11-27 15:17 UTC (permalink / raw)
To: David Lechner, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
On 26/11/18 23:15, David Lechner wrote:
> On 11/22/18 5:39 AM, Roger Quadros wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> The PRUSS platform driver deals with the overall PRUSS and is
>> used for managing the subsystem level resources like various
>> memories. It is responsible for the creation and deletion of
>> the platform devices for the child PRU devices and other child
>> devices (Interrupt Controller or MDIO node or some syscon nodes)
>> so that they can be managed by specific platform drivers.
>>
>> This design provides flexibility in representing the different
>> modules of PRUSS accordingly, and at the same time allowing the
>> PRUSS driver to add some instance specific configuration within
>> an SoC.
>>
>> The driver currently supports the AM335x SoC.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>> drivers/soc/ti/Makefile | 2 +-
>> drivers/soc/ti/pruss.c | 116 ++++++++++++++++++++++++++++++++++++++++++++++++
>> drivers/soc/ti/pruss.h | 44 ++++++++++++++++++
>> 3 files changed, 161 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/soc/ti/pruss.c
>> create mode 100644 drivers/soc/ti/pruss.h
>>
>
> ...
>
>> diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c
>> new file mode 100644
>> index 0000000..0840b59
>> --- /dev/null
>> +++ b/drivers/soc/ti/pruss.c
>> @@ -0,0 +1,116 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * PRU-ICSS platform driver for various TI SoCs
>> + *
>> + * Copyright (C) 2014-2018 Texas Instruments Incorporated - http://www.ti.com/
>> + * Suman Anna <s-anna@ti.com>
>> + * Andrew F. Davis <afd@ti.com>
>> + */
>> +
>> +#include <linux/dma-mapping.h>
>> +#include <linux/module.h>
>
> alphabetical order?
ok.
>
>> +#include <linux/io.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_device.h>
>> +
>> +#include "pruss.h"
>> +
>> +static int pruss_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct device_node *node = dev->of_node;
>> + struct device_node *np;
>> + struct pruss *pruss;
>> + struct resource res;
>> + int ret, i, index;
>> + const char *mem_names[PRUSS_MEM_MAX] = { "dram0", "dram1", "shrdram2" };
>> +
>> + if (!node) {
>> + dev_err(dev, "Non-DT platform device not supported\n");
>> + return -ENODEV;
>> + }
>> +
>> + ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
>> + if (ret) {
>> + dev_err(dev, "dma_set_coherent_mask: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + pruss = devm_kzalloc(dev, sizeof(*pruss), GFP_KERNEL);
>> + if (!pruss)
>> + return -ENOMEM;
>> +
>> + pruss->dev = dev;
>> +
>> + np = of_get_child_by_name(node, "memories");
>> + if (!np)
>
> error message?
Yes.
>
>> + return -ENODEV;
>> +
>> + for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
>> + index = of_property_match_string(np, "reg-names", mem_names[i]);
>> + if (index < 0) {
>> + of_node_put(np);
>> + return index;
>> + }
>> +
>> + if (of_address_to_resource(np, index, &res)) {
>> + of_node_put(np);
>> + return -EINVAL;
>> + }
>> +
>> + pruss->mem_regions[i].va = devm_ioremap(dev, res.start,
>> + resource_size(&res));
>> + if (!pruss->mem_regions[i].va) {
>> + dev_err(dev, "failed to parse and map memory resource %d %s\n",
>> + i, mem_names[i]);
>> + of_node_put(np);
>> + return -ENOMEM;
>> + }
>> + pruss->mem_regions[i].pa = res.start;
>> + pruss->mem_regions[i].size = resource_size(&res);
>> +
>> + dev_dbg(dev, "memory %8s: pa %pa size 0x%zx va %p\n",
>> + mem_names[i], &pruss->mem_regions[i].pa,
>> + pruss->mem_regions[i].size, pruss->mem_regions[i].va);
>> + }
>> + of_node_put(np);
>> +
>> + platform_set_drvdata(pdev, pruss);
>> +
>> + dev_info(&pdev->dev, "creating PRU cores and other child platform devices\n");
>
> Is this really needed? Or dev_dbg instead?
>
>> + ret = of_platform_populate(node, NULL, NULL, &pdev->dev);
>> + if (ret)
>> + dev_err(dev, "of_platform_populate failed\n");
>> +
>> + return ret;
>> +}
>> +
>> +static int pruss_remove(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> +
>> + dev_info(dev, "remove PRU cores and other child platform devices\n");
>
> same here... looks like debug message
Yes for both.
>
>> + of_platform_depopulate(dev);
>> +
>> + return 0;
>> +}
>> +
cheers,
-roger
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 07/17] soc: ti: pruss: enable OCP master ports in SYSCFG always
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
` (5 preceding siblings ...)
2018-11-22 11:39 ` [PATCH 06/17] soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs Roger Quadros
@ 2018-11-22 11:39 ` Roger Quadros
2018-11-23 16:35 ` Tony Lindgren
2018-11-22 11:39 ` [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts Roger Quadros
` (10 subsequent siblings)
17 siblings, 1 reply; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:39 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
From: Suman Anna <s-anna@ti.com>
The PRUSS CFG module's SYSCFG register is used for managing the
PRCM clock management settings at the PRU-ICSS subsystem level,
and is being programmed for the PRCM Idle/Standby protocol properly
during probe and remove. The register is also programmed to enable
the OCP master ports (disable MStandby) by default during probe now
to allow the PRUs access to on-chip memories and peripherals outside
the PRUSS without having to do it in firmware (primarily for the PRU
Ethernet usecase currently, the firmware is not programming this
register).
NOTE:
1. The AM57xx TRM suggests to enable "No Standby" during the
Idle + Standby state to an Active/Normal state, but this
sequence is not documented in either of AM33xx and AM437x
SoCs. Furthermore, it did not have an impact on the working
of Ethernet Rx, so is left out.
2. This has an impact on the PM suspend/resume operation usually
(same bit is used to trigger PRU standby), and even when the
PRU cores are in halted state. The STANDBY_INIT has to be
re-programmed to initiate a standby sequence and have the PM
suspend/resume functional when PRUs are halted. This is already
handled in commit b7e68ab66385 ("remoteproc/pruss_soc: fix system
suspend/MStandby config issues").
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/soc/ti/pruss_soc_bus.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/ti/pruss_soc_bus.c b/drivers/soc/ti/pruss_soc_bus.c
index 46dfb7a..f477168 100644
--- a/drivers/soc/ti/pruss_soc_bus.c
+++ b/drivers/soc/ti/pruss_soc_bus.c
@@ -67,8 +67,7 @@ static inline void pruss_soc_bus_rmw(void __iomem *reg, u32 mask, u32 set)
* outside of the PRU-ICSS. The function has to wait for the PRCM to
* acknowledge through the monitoring of the PRUSS_SYSCFG.SUB_MWAIT bit.
*/
-static
-int __maybe_unused pruss_soc_bus_enable_ocp_master_ports(struct device *dev)
+static int pruss_soc_bus_enable_ocp_master_ports(struct device *dev)
{
struct pruss_soc_bus *psoc_bus = dev_get_drvdata(dev);
u32 syscfg_val, i;
@@ -160,6 +159,11 @@ static int pruss_enable_module(struct device *dev)
pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_STANDBY_MODE_MASK,
SYSCFG_STANDBY_MODE_SMART);
+ /* enable OCP master ports/disable MStandby */
+ ret = pruss_soc_bus_enable_ocp_master_ports(dev);
+ if (ret)
+ pruss_disable_module(dev);
+
return ret;
}
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* Re: [PATCH 07/17] soc: ti: pruss: enable OCP master ports in SYSCFG always
2018-11-22 11:39 ` [PATCH 07/17] soc: ti: pruss: enable OCP master ports in SYSCFG always Roger Quadros
@ 2018-11-23 16:35 ` Tony Lindgren
0 siblings, 0 replies; 53+ messages in thread
From: Tony Lindgren @ 2018-11-23 16:35 UTC (permalink / raw)
To: Roger Quadros
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
* Roger Quadros <rogerq@ti.com> [181122 11:39]:
> @@ -160,6 +159,11 @@ static int pruss_enable_module(struct device *dev)
> pruss_soc_bus_rmw(psoc_bus->syscfg, SYSCFG_STANDBY_MODE_MASK,
> SYSCFG_STANDBY_MODE_SMART);
>
> + /* enable OCP master ports/disable MStandby */
> + ret = pruss_soc_bus_enable_ocp_master_ports(dev);
> + if (ret)
> + pruss_disable_module(dev);
> +
> return ret;
Seems like all you should need to do here with ti-sysc is to
leave out SYSC_IDLE_SMART and SYSC_IDLE_SMART_WKUP in the dts
for ti,sysc-midle property for am335x.
Regards,
Tony
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
` (6 preceding siblings ...)
2018-11-22 11:39 ` [PATCH 07/17] soc: ti: pruss: enable OCP master ports in SYSCFG always Roger Quadros
@ 2018-11-22 11:39 ` Roger Quadros
2018-11-23 16:37 ` Tony Lindgren
2018-11-26 21:17 ` David Lechner
2018-11-22 11:39 ` [PATCH 09/17] soc: ti: pruss: add pruss_{request,release}_mem_region() API Roger Quadros
` (9 subsequent siblings)
17 siblings, 2 replies; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:39 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
From: Suman Anna <s-anna@ti.com>
The Programmable Real-Time Unit Subsystem (PRUSS) contains an
interrupt controller (INTC) that can handle various system input
events and post interrupts back to the device-level initiators.
The INTC can support upto 64 input events with individual control
configuration and hardware prioritization. These events are mapped
onto 10 interrupt signals through two levels of many-to-one mapping
support. Different interrupt signals are routed to the individual
PRU cores or to the host CPU.
The PRUSS INTC platform driver manages this PRUSS interrupt
controller and implements an irqchip driver to provide a Linux
standard way for the PRU client users to enable/disable/ack/
re-trigger a PRUSS system event. The system events to interrupt
channels and host interrupts relies on the mapping configuration
provided through a firmware resource table for now. This will be
revisited and enhanced in the future for a better interface. The
mappings will currently be programmed during the boot/shutdown
of the PRU.
The PRUSS INTC module is reference counted during the interrupt
setup phase through the irqchip's irq_request_resources() and
irq_release_resources() ops. This restricts the module from being
removed as long as there are active interrupt users.
The driver currently supports the AM335x SoC.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/soc/ti/Makefile | 2 +-
drivers/soc/ti/pruss.h | 29 +++
drivers/soc/ti/pruss_intc.c | 572 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 602 insertions(+), 1 deletion(-)
create mode 100644 drivers/soc/ti/pruss_intc.c
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index 5a0c89d..71626a0 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -8,4 +8,4 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
obj-$(CONFIG_AMX3_PM) += pm33xx.o
obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
-obj-$(CONFIG_TI_PRUSS) += pruss_soc_bus.o pruss.o
+obj-$(CONFIG_TI_PRUSS) += pruss_soc_bus.o pruss.o pruss_intc.o
diff --git a/drivers/soc/ti/pruss.h b/drivers/soc/ti/pruss.h
index dbdf475..a5a0667 100644
--- a/drivers/soc/ti/pruss.h
+++ b/drivers/soc/ti/pruss.h
@@ -9,6 +9,18 @@
#ifndef _PRUSS_H_
#define _PRUSS_H_
+/* maximum number of system events */
+#define MAX_PRU_SYS_EVENTS 64
+
+/* maximum number of interrupt channels */
+#define MAX_PRU_CHANNELS 10
+
+/* minimum starting host interrupt number for MPU */
+#define MIN_PRU_HOST_INT 2
+
+/* maximum number of host interrupts */
+#define MAX_PRU_HOST_INT 10
+
/**
* enum pruss_mem - PRUSS memory range identifiers
*/
@@ -32,13 +44,30 @@ struct pruss_mem_region {
};
/**
+ * struct pruss_intc_config - INTC configuration info
+ * @sysev_to_ch: system events to channel mapping information
+ * @ch_to_host: interrupt channel to host interrupt information
+ */
+struct pruss_intc_config {
+ s8 sysev_to_ch[MAX_PRU_SYS_EVENTS];
+ s8 ch_to_host[MAX_PRU_CHANNELS];
+};
+
+/**
* struct pruss - PRUSS parent structure
* @dev: pruss device pointer
* @mem_regions: data for each of the PRUSS memory regions
+ * @host_mask: indicate which HOST IRQs are enabled
*/
struct pruss {
struct device *dev;
struct pruss_mem_region mem_regions[PRUSS_MEM_MAX];
+ u32 host_mask;
};
+int pruss_intc_configure(struct pruss *pruss,
+ struct pruss_intc_config *intc_config);
+int pruss_intc_unconfigure(struct pruss *pruss,
+ struct pruss_intc_config *intc_config);
+
#endif /* _PRUSS_H_ */
diff --git a/drivers/soc/ti/pruss_intc.c b/drivers/soc/ti/pruss_intc.c
new file mode 100644
index 0000000..dde054b
--- /dev/null
+++ b/drivers/soc/ti/pruss_intc.c
@@ -0,0 +1,572 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PRU-ICSS INTC IRQChip driver for various TI SoCs
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis <afd@ti.com>
+ * Suman Anna <s-anna@ti.com>
+ */
+
+#include <linux/irq.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+
+#include "pruss.h"
+
+/*
+ * Number of host interrupts reaching the main MPU sub-system. Note that this
+ * is not the same as the total number of host interrupts supported by the PRUSS
+ * INTC instance
+ */
+#define MAX_HOST_NUM_IRQS 8
+
+/* PRU_ICSS_INTC registers */
+#define PRU_INTC_REVID 0x0000
+#define PRU_INTC_CR 0x0004
+#define PRU_INTC_GER 0x0010
+#define PRU_INTC_GNLR 0x001C
+#define PRU_INTC_SISR 0x0020
+#define PRU_INTC_SICR 0x0024
+#define PRU_INTC_EISR 0x0028
+#define PRU_INTC_EICR 0x002C
+#define PRU_INTC_HIEISR 0x0034
+#define PRU_INTC_HIDISR 0x0038
+#define PRU_INTC_GPIR 0x0080
+#define PRU_INTC_SRSR0 0x0200
+#define PRU_INTC_SRSR1 0x0204
+#define PRU_INTC_SECR0 0x0280
+#define PRU_INTC_SECR1 0x0284
+#define PRU_INTC_ESR0 0x0300
+#define PRU_INTC_ESR1 0x0304
+#define PRU_INTC_ECR0 0x0380
+#define PRU_INTC_ECR1 0x0384
+#define PRU_INTC_CMR(x) (0x0400 + (x) * 4)
+#define PRU_INTC_HMR(x) (0x0800 + (x) * 4)
+#define PRU_INTC_HIPIR(x) (0x0900 + (x) * 4)
+#define PRU_INTC_SIPR0 0x0D00
+#define PRU_INTC_SIPR1 0x0D04
+#define PRU_INTC_SITR0 0x0D80
+#define PRU_INTC_SITR1 0x0D84
+#define PRU_INTC_HINLR(x) (0x1100 + (x) * 4)
+#define PRU_INTC_HIER 0x1500
+
+/* HIPIR register bit-fields */
+#define INTC_HIPIR_NONE_HINT 0x80000000
+
+static const char * const irq_names[] = {
+ "host2", "host3", "host4", "host5", "host6", "host7", "host8", "host9",
+};
+
+/**
+ * struct pruss_intc - PRUSS interrupt controller structure
+ * @pruss: back-reference to parent PRUSS structure
+ * @irqs: kernel irq numbers corresponding to PRUSS host interrupts
+ * @mem: kernel-mapping data for the INTC register space
+ * @irqchip: irq chip for this interrupt controller
+ * @domain: irq domain for this interrupt controller
+ * @config_map: stored INTC configuration mapping data
+ * @lock: mutex to serialize access to INTC
+ */
+struct pruss_intc {
+ struct pruss *pruss;
+ unsigned int irqs[MAX_HOST_NUM_IRQS];
+ struct pruss_mem_region mem;
+ struct irq_chip *irqchip;
+ struct irq_domain *domain;
+ struct pruss_intc_config config_map;
+ struct mutex lock; /* PRUSS INTC lock */
+};
+
+static inline u32 pruss_intc_read_reg(struct pruss_intc *intc, unsigned int reg)
+{
+ return readl_relaxed(intc->mem.va + reg);
+}
+
+static inline void pruss_intc_write_reg(struct pruss_intc *intc,
+ unsigned int reg, u32 val)
+{
+ writel_relaxed(val, intc->mem.va + reg);
+}
+
+static int pruss_intc_check_write(struct pruss_intc *intc, unsigned int reg,
+ unsigned int sysevent)
+{
+ if (!intc)
+ return -EINVAL;
+
+ if (sysevent >= MAX_PRU_SYS_EVENTS)
+ return -EINVAL;
+
+ pruss_intc_write_reg(intc, reg, sysevent);
+
+ return 0;
+}
+
+static struct pruss_intc *to_pruss_intc(struct pruss *pruss)
+{
+ struct device_node *parent = pruss->dev->of_node;
+ struct device_node *np;
+ struct platform_device *pdev;
+ struct pruss_intc *intc = NULL;
+
+ np = of_get_child_by_name(parent, "intc");
+ if (!np) {
+ dev_err(pruss->dev, "pruss does not have an intc node\n");
+ return NULL;
+ }
+
+ pdev = of_find_device_by_node(np);
+ if (!pdev) {
+ dev_err(pruss->dev, "no associated platform device\n");
+ goto out;
+ }
+
+ intc = platform_get_drvdata(pdev);
+out:
+ of_node_put(np);
+ return intc;
+}
+
+/**
+ * pruss_intc_configure() - configure the PRUSS INTC
+ * @pruss: the pruss instance
+ * @intc_config: PRU core-specific INTC configuration
+ *
+ * Configures the PRUSS INTC with the provided configuration from
+ * a PRU core. Any existing event to channel mappings or channel to
+ * host interrupt mappings are checked to make sure there are no
+ * conflicting configuration between both the PRU cores. The function
+ * is intended to be used only by the PRU remoteproc driver.
+ *
+ * Returns 0 on success, or a suitable error code otherwise
+ */
+int pruss_intc_configure(struct pruss *pruss,
+ struct pruss_intc_config *intc_config)
+{
+ struct device *dev = pruss->dev;
+ struct pruss_intc *intc = to_pruss_intc(pruss);
+ int i, idx, ret;
+ s8 ch, host;
+ u64 sysevt_mask = 0;
+ u32 ch_mask = 0;
+ u32 host_mask = 0;
+ u32 val;
+
+ if (!intc)
+ return -EINVAL;
+
+ mutex_lock(&intc->lock);
+
+ /*
+ * configure channel map registers - each register holds map info
+ * for 4 events, with each event occupying the lower nibble in
+ * a register byte address in little-endian fashion
+ */
+ for (i = 0; i < ARRAY_SIZE(intc_config->sysev_to_ch); i++) {
+ ch = intc_config->sysev_to_ch[i];
+ if (ch < 0)
+ continue;
+
+ /* check if sysevent already assigned */
+ if (intc->config_map.sysev_to_ch[i] != -1) {
+ dev_err(dev, "event %d (req. channel %d) already assigned to channel %d\n",
+ i, ch, intc->config_map.sysev_to_ch[i]);
+ ret = -EEXIST;
+ goto unlock;
+ }
+
+ intc->config_map.sysev_to_ch[i] = ch;
+
+ idx = i / 4;
+ val = pruss_intc_read_reg(intc, PRU_INTC_CMR(idx));
+ val |= ch << ((i & 3) * 8);
+ pruss_intc_write_reg(intc, PRU_INTC_CMR(idx), val);
+ sysevt_mask |= BIT_ULL(i);
+ ch_mask |= BIT(ch);
+
+ dev_dbg(dev, "SYSEV%d -> CH%d (CMR%d 0x%08x)\n", i, ch, idx,
+ pruss_intc_read_reg(intc, PRU_INTC_CMR(idx)));
+ }
+
+ /*
+ * set host map registers - each register holds map info for
+ * 4 channels, with each channel occupying the lower nibble in
+ * a register byte address in little-endian fashion
+ */
+ for (i = 0; i < ARRAY_SIZE(intc_config->ch_to_host); i++) {
+ host = intc_config->ch_to_host[i];
+ if (host < 0)
+ continue;
+
+ /* check if channel already assigned */
+ if (intc->config_map.ch_to_host[i] != -1) {
+ dev_err(dev, "channel %d (req. intr_no %d) already assigned to intr_no %d\n",
+ i, host, intc->config_map.ch_to_host[i]);
+ ret = -EEXIST;
+ goto unlock;
+ }
+
+ /* check if host intr is already in use by other PRU */
+ if (pruss->host_mask & (1U << host)) {
+ dev_err(dev, "%s: host intr %d already in use\n",
+ __func__, host);
+ ret = -EEXIST;
+ goto unlock;
+ }
+
+ intc->config_map.ch_to_host[i] = host;
+
+ idx = i / 4;
+
+ val = pruss_intc_read_reg(intc, PRU_INTC_HMR(idx));
+ val |= host << ((i & 3) * 8);
+ pruss_intc_write_reg(intc, PRU_INTC_HMR(idx), val);
+
+ ch_mask |= BIT(i);
+ host_mask |= BIT(host);
+
+ dev_dbg(dev, "CH%d -> HOST%d (HMR%d 0x%08x)\n", i, host, idx,
+ pruss_intc_read_reg(intc, PRU_INTC_HMR(idx)));
+ }
+
+ dev_info(dev, "configured system_events = 0x%016llx intr_channels = 0x%08x host_intr = 0x%08x\n",
+ sysevt_mask, ch_mask, host_mask);
+
+ /* enable system events, writing 0 has no-effect */
+ pruss_intc_write_reg(intc, PRU_INTC_ESR0, lower_32_bits(sysevt_mask));
+ pruss_intc_write_reg(intc, PRU_INTC_SECR0, lower_32_bits(sysevt_mask));
+ pruss_intc_write_reg(intc, PRU_INTC_ESR1, upper_32_bits(sysevt_mask));
+ pruss_intc_write_reg(intc, PRU_INTC_SECR1, upper_32_bits(sysevt_mask));
+
+ /* enable host interrupts */
+ for (i = 0; i < MAX_PRU_HOST_INT; i++) {
+ if (host_mask & BIT(i))
+ pruss_intc_write_reg(intc, PRU_INTC_HIEISR, i);
+ }
+
+ /* global interrupt enable */
+ pruss_intc_write_reg(intc, PRU_INTC_GER, 1);
+
+ pruss->host_mask |= host_mask;
+
+ mutex_unlock(&intc->lock);
+ return 0;
+
+unlock:
+ mutex_unlock(&intc->lock);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pruss_intc_configure);
+
+/**
+ * pruss_intc_unconfigure() - unconfigure the PRUSS INTC
+ * @pruss: the pruss instance
+ * @intc_config: PRU core specific INTC configuration
+ *
+ * Undo whatever was done in pruss_intc_configure() for a PRU core.
+ * It should be sufficient to just mark the resources free in the
+ * global map and disable the host interrupts and sysevents.
+ */
+int pruss_intc_unconfigure(struct pruss *pruss,
+ struct pruss_intc_config *intc_config)
+{
+ struct device *dev = pruss->dev;
+ struct pruss_intc *intc = to_pruss_intc(pruss);
+ int i;
+ s8 ch, host;
+ u64 sysevt_mask = 0;
+ u32 host_mask = 0;
+
+ if (!intc)
+ return -EINVAL;
+
+ mutex_lock(&intc->lock);
+
+ for (i = 0; i < ARRAY_SIZE(intc_config->sysev_to_ch); i++) {
+ ch = intc_config->sysev_to_ch[i];
+ if (ch < 0)
+ continue;
+
+ /* mark sysevent free in global map */
+ intc->config_map.sysev_to_ch[i] = -1;
+ sysevt_mask |= BIT_ULL(i);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(intc_config->ch_to_host); i++) {
+ host = intc_config->ch_to_host[i];
+ if (host < 0)
+ continue;
+
+ /* mark channel free in global map */
+ intc->config_map.ch_to_host[i] = -1;
+ host_mask |= BIT(host);
+ }
+
+ dev_info(dev, "unconfigured system_events = 0x%016llx host_intr = 0x%08x\n",
+ sysevt_mask, host_mask);
+
+ /* disable system events, writing 0 has no-effect */
+ pruss_intc_write_reg(intc, PRU_INTC_ECR0, lower_32_bits(sysevt_mask));
+ pruss_intc_write_reg(intc, PRU_INTC_ECR1, upper_32_bits(sysevt_mask));
+ /* clear any pending status */
+ pruss_intc_write_reg(intc, PRU_INTC_SECR0, lower_32_bits(sysevt_mask));
+ pruss_intc_write_reg(intc, PRU_INTC_SECR1, upper_32_bits(sysevt_mask));
+
+ /* disable host interrupts */
+ for (i = 0; i < MAX_PRU_HOST_INT; i++) {
+ if (host_mask & BIT(i))
+ pruss_intc_write_reg(intc, PRU_INTC_HIDISR, i);
+ }
+
+ pruss->host_mask &= ~host_mask;
+ mutex_unlock(&intc->lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pruss_intc_unconfigure);
+
+static void pruss_intc_init(struct pruss_intc *intc)
+{
+ int i;
+
+ /* configure polarity to active high for all system interrupts */
+ pruss_intc_write_reg(intc, PRU_INTC_SIPR0, 0xffffffff);
+ pruss_intc_write_reg(intc, PRU_INTC_SIPR1, 0xffffffff);
+
+ /* configure type to pulse interrupt for all system interrupts */
+ pruss_intc_write_reg(intc, PRU_INTC_SITR0, 0);
+ pruss_intc_write_reg(intc, PRU_INTC_SITR1, 0);
+
+ /* clear all 16 interrupt channel map registers */
+ for (i = 0; i < 16; i++)
+ pruss_intc_write_reg(intc, PRU_INTC_CMR(i), 0);
+
+ /* clear all 3 host interrupt map registers */
+ for (i = 0; i < 3; i++)
+ pruss_intc_write_reg(intc, PRU_INTC_HMR(i), 0);
+}
+
+static void pruss_intc_irq_ack(struct irq_data *data)
+{
+ struct pruss_intc *intc = irq_data_get_irq_chip_data(data);
+ unsigned int hwirq = data->hwirq;
+
+ pruss_intc_check_write(intc, PRU_INTC_SICR, hwirq);
+}
+
+static void pruss_intc_irq_mask(struct irq_data *data)
+{
+ struct pruss_intc *intc = irq_data_get_irq_chip_data(data);
+ unsigned int hwirq = data->hwirq;
+
+ pruss_intc_check_write(intc, PRU_INTC_EICR, hwirq);
+}
+
+static void pruss_intc_irq_unmask(struct irq_data *data)
+{
+ struct pruss_intc *intc = irq_data_get_irq_chip_data(data);
+ unsigned int hwirq = data->hwirq;
+
+ pruss_intc_check_write(intc, PRU_INTC_EISR, hwirq);
+}
+
+static int pruss_intc_irq_retrigger(struct irq_data *data)
+{
+ struct pruss_intc *intc = irq_data_get_irq_chip_data(data);
+ unsigned int hwirq = data->hwirq;
+
+ return pruss_intc_check_write(intc, PRU_INTC_SISR, hwirq);
+}
+
+static int pruss_intc_irq_reqres(struct irq_data *data)
+{
+ if (!try_module_get(THIS_MODULE))
+ return -ENODEV;
+
+ return 0;
+}
+
+static void pruss_intc_irq_relres(struct irq_data *data)
+{
+ module_put(THIS_MODULE);
+}
+
+static int pruss_intc_irq_domain_map(struct irq_domain *d, unsigned int virq,
+ irq_hw_number_t hw)
+{
+ struct pruss_intc *intc = d->host_data;
+
+ irq_set_chip_data(virq, intc);
+ irq_set_chip_and_handler(virq, intc->irqchip, handle_level_irq);
+
+ return 0;
+}
+
+static void pruss_intc_irq_domain_unmap(struct irq_domain *d, unsigned int virq)
+{
+ irq_set_chip_and_handler(virq, NULL, NULL);
+ irq_set_chip_data(virq, NULL);
+}
+
+static const struct irq_domain_ops pruss_intc_irq_domain_ops = {
+ .xlate = irq_domain_xlate_onecell,
+ .map = pruss_intc_irq_domain_map,
+ .unmap = pruss_intc_irq_domain_unmap,
+};
+
+static void pruss_intc_irq_handler(struct irq_desc *desc)
+{
+ unsigned int irq = irq_desc_get_irq(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct pruss_intc *intc = irq_get_handler_data(irq);
+ u32 hipir;
+ unsigned int virq;
+ int i, hwirq;
+
+ chained_irq_enter(chip, desc);
+
+ /* find our host irq number */
+ for (i = 0; i < MAX_HOST_NUM_IRQS; i++)
+ if (intc->irqs[i] == irq)
+ break;
+ if (i == MAX_HOST_NUM_IRQS)
+ goto err;
+
+ i += MIN_PRU_HOST_INT;
+
+ /* get highest priority pending PRUSS system event */
+ hipir = pruss_intc_read_reg(intc, PRU_INTC_HIPIR(i));
+ while (!(hipir & BIT(31))) {
+ hwirq = hipir & GENMASK(9, 0);
+ virq = irq_linear_revmap(intc->domain, hwirq);
+
+ /*
+ * XXX: manually ACK any system events that do not have a
+ * handler mapped yet
+ */
+ if (unlikely(!virq))
+ pruss_intc_check_write(intc, PRU_INTC_SICR, hwirq);
+ else
+ generic_handle_irq(virq);
+
+ /* get next system event */
+ hipir = pruss_intc_read_reg(intc, PRU_INTC_HIPIR(i));
+ }
+err:
+ chained_irq_exit(chip, desc);
+}
+
+static int pruss_intc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct platform_device *ppdev = to_platform_device(dev->parent);
+ struct pruss_intc *intc;
+ struct resource *res;
+ struct irq_chip *irqchip;
+ int i, irq;
+
+ intc = devm_kzalloc(dev, sizeof(*intc), GFP_KERNEL);
+ if (!intc)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, intc);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "intc");
+ intc->mem.va = devm_ioremap_resource(dev, res);
+ if (IS_ERR(intc->mem.va)) {
+ dev_err(dev, "failed to parse and map intc memory resource\n");
+ return PTR_ERR(intc->mem.va);
+ }
+ intc->mem.pa = res->start;
+ intc->mem.size = resource_size(res);
+
+ dev_dbg(dev, "intc memory: pa %pa size 0x%zx va %p\n", &intc->mem.pa,
+ intc->mem.size, intc->mem.va);
+
+ mutex_init(&intc->lock);
+
+ for (i = 0; i < ARRAY_SIZE(intc->config_map.sysev_to_ch); i++)
+ intc->config_map.sysev_to_ch[i] = -1;
+
+ for (i = 0; i < ARRAY_SIZE(intc->config_map.ch_to_host); i++)
+ intc->config_map.ch_to_host[i] = -1;
+
+ intc->pruss = platform_get_drvdata(ppdev);
+ pruss_intc_init(intc);
+
+ irqchip = devm_kzalloc(dev, sizeof(*irqchip), GFP_KERNEL);
+ if (!irqchip)
+ return -ENOMEM;
+
+ irqchip->irq_ack = pruss_intc_irq_ack;
+ irqchip->irq_mask = pruss_intc_irq_mask;
+ irqchip->irq_unmask = pruss_intc_irq_unmask;
+ irqchip->irq_retrigger = pruss_intc_irq_retrigger;
+ irqchip->irq_request_resources = pruss_intc_irq_reqres;
+ irqchip->irq_release_resources = pruss_intc_irq_relres;
+ irqchip->name = dev_name(dev);
+ intc->irqchip = irqchip;
+
+ /* always 64 events */
+ intc->domain = irq_domain_add_linear(dev->of_node, MAX_PRU_SYS_EVENTS,
+ &pruss_intc_irq_domain_ops, intc);
+ if (!intc->domain)
+ return -ENOMEM;
+
+ for (i = 0; i < MAX_HOST_NUM_IRQS; i++) {
+ irq = platform_get_irq_byname(ppdev, irq_names[i]);
+ if (irq < 0) {
+ dev_err(dev->parent, "platform_get_irq_byname failed for %s : %d\n",
+ irq_names[i], irq);
+ goto fail_irq;
+ }
+
+ intc->irqs[i] = irq;
+ irq_set_handler_data(irq, intc);
+ irq_set_chained_handler(irq, pruss_intc_irq_handler);
+ }
+
+ return 0;
+
+fail_irq:
+ irq_domain_remove(intc->domain);
+ return irq;
+}
+
+static int pruss_intc_remove(struct platform_device *pdev)
+{
+ struct pruss_intc *intc = platform_get_drvdata(pdev);
+ unsigned int hwirq;
+
+ if (intc->domain) {
+ for (hwirq = 0; hwirq < MAX_PRU_SYS_EVENTS; hwirq++)
+ irq_dispose_mapping(irq_find_mapping(intc->domain,
+ hwirq));
+ irq_domain_remove(intc->domain);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id pruss_intc_of_match[] = {
+ { .compatible = "ti,am3356-pruss-intc", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, pruss_intc_of_match);
+
+static struct platform_driver pruss_intc_driver = {
+ .driver = {
+ .name = "pruss-intc",
+ .of_match_table = pruss_intc_of_match,
+ },
+ .probe = pruss_intc_probe,
+ .remove = pruss_intc_remove,
+};
+module_platform_driver(pruss_intc_driver);
+
+MODULE_AUTHOR("Andrew F. Davis <afd@ti.com>");
+MODULE_AUTHOR("Suman Anna <s-anna@ti.com>");
+MODULE_DESCRIPTION("PRU-ICSS INTC Driver");
+MODULE_LICENSE("GPL v2");
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* Re: [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts
2018-11-22 11:39 ` [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts Roger Quadros
@ 2018-11-23 16:37 ` Tony Lindgren
2018-11-26 8:09 ` Roger Quadros
2018-11-26 8:09 ` Roger Quadros
2018-11-26 21:17 ` David Lechner
1 sibling, 2 replies; 53+ messages in thread
From: Tony Lindgren @ 2018-11-23 16:37 UTC (permalink / raw)
To: Roger Quadros
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
* Roger Quadros <rogerq@ti.com> [181122 11:39]:
> The PRUSS INTC module is reference counted during the interrupt
> setup phase through the irqchip's irq_request_resources() and
> irq_release_resources() ops. This restricts the module from being
> removed as long as there are active interrupt users.
So are there any reasons why this could not be just a regular
drivers/irqchip driver nowadays?
Regards,
Tony
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts
2018-11-23 16:37 ` Tony Lindgren
@ 2018-11-26 8:09 ` Roger Quadros
2018-11-26 19:33 ` Tony Lindgren
2018-11-26 8:09 ` Roger Quadros
1 sibling, 1 reply; 53+ messages in thread
From: Roger Quadros @ 2018-11-26 8:09 UTC (permalink / raw)
To: Tony Lindgren
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
Tony,
On 23/11/18 18:37, Tony Lindgren wrote:
> * Roger Quadros <rogerq@ti.com> [181122 11:39]:
>> The PRUSS INTC module is reference counted during the interrupt
>> setup phase through the irqchip's irq_request_resources() and
>> irq_release_resources() ops. This restricts the module from being
>> removed as long as there are active interrupt users.
>
> So are there any reasons why this could not be just a regular
> drivers/irqchip driver nowadays?
This is a reqular irqchip driver. Do you mean it should be moved
to drivers/irqchip directory?
cheers,
-roger
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts
2018-11-26 8:09 ` Roger Quadros
@ 2018-11-26 19:33 ` Tony Lindgren
2018-12-12 15:48 ` Roger Quadros
0 siblings, 1 reply; 53+ messages in thread
From: Tony Lindgren @ 2018-11-26 19:33 UTC (permalink / raw)
To: Roger Quadros
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
* Roger Quadros <rogerq@ti.com> [181126 08:09]:
> Tony,
>
> On 23/11/18 18:37, Tony Lindgren wrote:
> > * Roger Quadros <rogerq@ti.com> [181122 11:39]:
> >> The PRUSS INTC module is reference counted during the interrupt
> >> setup phase through the irqchip's irq_request_resources() and
> >> irq_release_resources() ops. This restricts the module from being
> >> removed as long as there are active interrupt users.
> >
> > So are there any reasons why this could not be just a regular
> > drivers/irqchip driver nowadays?
>
> This is a reqular irqchip driver. Do you mean it should be moved
> to drivers/irqchip directory?
I think so, is there something preventing doing it?
Also, is this maybe the same INTC that we already have a
driver for in drivers/irqchip/irq-omap-intc.c?
Regards,
Tony
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts
2018-11-26 19:33 ` Tony Lindgren
@ 2018-12-12 15:48 ` Roger Quadros
2018-12-12 17:25 ` Tony Lindgren
0 siblings, 1 reply; 53+ messages in thread
From: Roger Quadros @ 2018-12-12 15:48 UTC (permalink / raw)
To: Tony Lindgren
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
Tony,
On 26/11/18 21:33, Tony Lindgren wrote:
> * Roger Quadros <rogerq@ti.com> [181126 08:09]:
>> Tony,
>>
>> On 23/11/18 18:37, Tony Lindgren wrote:
>>> * Roger Quadros <rogerq@ti.com> [181122 11:39]:
>>>> The PRUSS INTC module is reference counted during the interrupt
>>>> setup phase through the irqchip's irq_request_resources() and
>>>> irq_release_resources() ops. This restricts the module from being
>>>> removed as long as there are active interrupt users.
>>>
>>> So are there any reasons why this could not be just a regular
>>> drivers/irqchip driver nowadays?
>>
>> This is a reqular irqchip driver. Do you mean it should be moved
>> to drivers/irqchip directory?
>
> I think so, is there something preventing doing it?
>
No.
> Also, is this maybe the same INTC that we already have a
> driver for in drivers/irqchip/irq-omap-intc.c?
No, it is completely different.
cheers,
-roger
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts
2018-12-12 15:48 ` Roger Quadros
@ 2018-12-12 17:25 ` Tony Lindgren
0 siblings, 0 replies; 53+ messages in thread
From: Tony Lindgren @ 2018-12-12 17:25 UTC (permalink / raw)
To: Roger Quadros
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
* Roger Quadros <rogerq@ti.com> [181212 15:48]:
> On 26/11/18 21:33, Tony Lindgren wrote:
> >>> So are there any reasons why this could not be just a regular
> >>> drivers/irqchip driver nowadays?
> >>
> >> This is a reqular irqchip driver. Do you mean it should be moved
> >> to drivers/irqchip directory?
> >
> > I think so, is there something preventing doing it?
> >
> No.
OK great.
> > Also, is this maybe the same INTC that we already have a
> > driver for in drivers/irqchip/irq-omap-intc.c?
>
> No, it is completely different.
OK thanks for checking that.
Regards,
Tony
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts
2018-11-23 16:37 ` Tony Lindgren
2018-11-26 8:09 ` Roger Quadros
@ 2018-11-26 8:09 ` Roger Quadros
1 sibling, 0 replies; 53+ messages in thread
From: Roger Quadros @ 2018-11-26 8:09 UTC (permalink / raw)
To: Tony Lindgren
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
Tony,
On 23/11/18 18:37, Tony Lindgren wrote:
> * Roger Quadros <rogerq@ti.com> [181122 11:39]:
>> The PRUSS INTC module is reference counted during the interrupt
>> setup phase through the irqchip's irq_request_resources() and
>> irq_release_resources() ops. This restricts the module from being
>> removed as long as there are active interrupt users.
>
> So are there any reasons why this could not be just a regular
> drivers/irqchip driver nowadays?
This is a regular irqchip driver. Do you mean it should be moved
to drivers/irqchip directory?
cheers,
-roger
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts
2018-11-22 11:39 ` [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts Roger Quadros
2018-11-23 16:37 ` Tony Lindgren
@ 2018-11-26 21:17 ` David Lechner
2018-11-27 15:39 ` Roger Quadros
1 sibling, 1 reply; 53+ messages in thread
From: David Lechner @ 2018-11-26 21:17 UTC (permalink / raw)
To: Roger Quadros, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
On 11/22/18 5:39 AM, Roger Quadros wrote:
> From: Suman Anna <s-anna@ti.com>
>
> The Programmable Real-Time Unit Subsystem (PRUSS) contains an
> interrupt controller (INTC) that can handle various system input
> events and post interrupts back to the device-level initiators.
> The INTC can support upto 64 input events with individual control
> configuration and hardware prioritization. These events are mapped
> onto 10 interrupt signals through two levels of many-to-one mapping
> support. Different interrupt signals are routed to the individual
> PRU cores or to the host CPU.
>
> The PRUSS INTC platform driver manages this PRUSS interrupt
> controller and implements an irqchip driver to provide a Linux
> standard way for the PRU client users to enable/disable/ack/
> re-trigger a PRUSS system event. The system events to interrupt
> channels and host interrupts relies on the mapping configuration
> provided through a firmware resource table for now. This will be
> revisited and enhanced in the future for a better interface. The
> mappings will currently be programmed during the boot/shutdown
> of the PRU.
Does this mapping table take up space in the PRU IRAM or DRAM? If
so, that can be a problem on the AM18xx because it has such limited
resources - every byte counts.
Perhaps one way to simplify the mapping is to take out one of the
two levels of mapping. All of the TRMs say that it is highly
recommended to have a 1:1 mapping from channels to host interrupts.
This part of the mapping could just be hard-coded in this driver.
Then the mapping tables would just effectively mapping PRU system
events to host interrupts.
>
> The PRUSS INTC module is reference counted during the interrupt
> setup phase through the irqchip's irq_request_resources() and
> irq_release_resources() ops. This restricts the module from being
> removed as long as there are active interrupt users.
>
> The driver currently supports the AM335x SoC.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> drivers/soc/ti/Makefile | 2 +-
> drivers/soc/ti/pruss.h | 29 +++
> drivers/soc/ti/pruss_intc.c | 572 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 602 insertions(+), 1 deletion(-)
> create mode 100644 drivers/soc/ti/pruss_intc.c
>
...
> diff --git a/drivers/soc/ti/pruss_intc.c b/drivers/soc/ti/pruss_intc.c
> new file mode 100644
> index 0000000..dde054b
> --- /dev/null
> +++ b/drivers/soc/ti/pruss_intc.c
> @@ -0,0 +1,572 @@
...
> +int pruss_intc_configure(struct pruss *pruss,
> + struct pruss_intc_config *intc_config)
> +{
> + struct device *dev = pruss->dev;
> + struct pruss_intc *intc = to_pruss_intc(pruss);
> + int i, idx, ret;
> + s8 ch, host;
> + u64 sysevt_mask = 0;
> + u32 ch_mask = 0;
> + u32 host_mask = 0;
> + u32 val;
> +
> + if (!intc)
> + return -EINVAL;
> +
> + mutex_lock(&intc->lock);
> +
> + /*
> + * configure channel map registers - each register holds map info
> + * for 4 events, with each event occupying the lower nibble in
> + * a register byte address in little-endian fashion
> + */
> + for (i = 0; i < ARRAY_SIZE(intc_config->sysev_to_ch); i++) {
> + ch = intc_config->sysev_to_ch[i];
> + if (ch < 0)
> + continue;
> +
> + /* check if sysevent already assigned */
> + if (intc->config_map.sysev_to_ch[i] != -1) {
Perhaps define a macro for -1 so we know what it means?
^ permalink raw reply [flat|nested] 53+ messages in thread* Re: [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts
2018-11-26 21:17 ` David Lechner
@ 2018-11-27 15:39 ` Roger Quadros
2018-11-28 15:46 ` David Lechner
0 siblings, 1 reply; 53+ messages in thread
From: Roger Quadros @ 2018-11-27 15:39 UTC (permalink / raw)
To: David Lechner, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
On 26/11/18 23:17, David Lechner wrote:
> On 11/22/18 5:39 AM, Roger Quadros wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> The Programmable Real-Time Unit Subsystem (PRUSS) contains an
>> interrupt controller (INTC) that can handle various system input
>> events and post interrupts back to the device-level initiators.
>> The INTC can support upto 64 input events with individual control
>> configuration and hardware prioritization. These events are mapped
>> onto 10 interrupt signals through two levels of many-to-one mapping
>> support. Different interrupt signals are routed to the individual
>> PRU cores or to the host CPU.
>>
>> The PRUSS INTC platform driver manages this PRUSS interrupt
>> controller and implements an irqchip driver to provide a Linux
>> standard way for the PRU client users to enable/disable/ack/
>> re-trigger a PRUSS system event. The system events to interrupt
>> channels and host interrupts relies on the mapping configuration
>> provided through a firmware resource table for now. This will be
>> revisited and enhanced in the future for a better interface. The
>> mappings will currently be programmed during the boot/shutdown
>> of the PRU.
>
> Does this mapping table take up space in the PRU IRAM or DRAM? If
> so, that can be a problem on the AM18xx because it has such limited
> resources - every byte counts.
Currently the entire resource table is being placed in DRAM.
But that is only because the current rpmsg vdev implementation depends on the
rpmsg channel information and vring buffers to be in DRAM.
I think the right way is to split up the 2 things.
i.e. separate out rpmgs channel DRAM allocation from resource table
and don't copy the resource table to DRAM.
This way if there is no rpmsg channel in the resource table we won't eat
any DRAM.
I'm not sure if there are any bottlenecks. I will only know when I work on it.
>
> Perhaps one way to simplify the mapping is to take out one of the
> two levels of mapping. All of the TRMs say that it is highly
> recommended to have a 1:1 mapping from channels to host interrupts.
> This part of the mapping could just be hard-coded in this driver.
> Then the mapping tables would just effectively mapping PRU system
> events to host interrupts.
We don't have to go this route if INTC map is not loaded in DRAM.
>
>>
>> The PRUSS INTC module is reference counted during the interrupt
>> setup phase through the irqchip's irq_request_resources() and
>> irq_release_resources() ops. This restricts the module from being
>> removed as long as there are active interrupt users.
>>
>> The driver currently supports the AM335x SoC.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>> drivers/soc/ti/Makefile | 2 +-
>> drivers/soc/ti/pruss.h | 29 +++
>> drivers/soc/ti/pruss_intc.c | 572 ++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 602 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/soc/ti/pruss_intc.c
>>
>
> ...
>
>> diff --git a/drivers/soc/ti/pruss_intc.c b/drivers/soc/ti/pruss_intc.c
>> new file mode 100644
>> index 0000000..dde054b
>> --- /dev/null
>> +++ b/drivers/soc/ti/pruss_intc.c
>> @@ -0,0 +1,572 @@
>
> ...
>
>> +int pruss_intc_configure(struct pruss *pruss,
>> + struct pruss_intc_config *intc_config)
>> +{
>> + struct device *dev = pruss->dev;
>> + struct pruss_intc *intc = to_pruss_intc(pruss);
>> + int i, idx, ret;
>> + s8 ch, host;
>> + u64 sysevt_mask = 0;
>> + u32 ch_mask = 0;
>> + u32 host_mask = 0;
>> + u32 val;
>> +
>> + if (!intc)
>> + return -EINVAL;
>> +
>> + mutex_lock(&intc->lock);
>> +
>> + /*
>> + * configure channel map registers - each register holds map info
>> + * for 4 events, with each event occupying the lower nibble in
>> + * a register byte address in little-endian fashion
>> + */
>> + for (i = 0; i < ARRAY_SIZE(intc_config->sysev_to_ch); i++) {
>> + ch = intc_config->sysev_to_ch[i];
>> + if (ch < 0)
>> + continue;
>> +
>> + /* check if sysevent already assigned */
>> + if (intc->config_map.sysev_to_ch[i] != -1) {
>
> Perhaps define a macro for -1 so we know what it means?
sure.
cheers,
-roger
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 53+ messages in thread* Re: [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts
2018-11-27 15:39 ` Roger Quadros
@ 2018-11-28 15:46 ` David Lechner
0 siblings, 0 replies; 53+ messages in thread
From: David Lechner @ 2018-11-28 15:46 UTC (permalink / raw)
To: Roger Quadros, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
On 11/27/18 9:39 AM, Roger Quadros wrote:
>
> On 26/11/18 23:17, David Lechner wrote:
>> On 11/22/18 5:39 AM, Roger Quadros wrote:
>>> From: Suman Anna <s-anna@ti.com>
>>>
>>> The Programmable Real-Time Unit Subsystem (PRUSS) contains an
>>> interrupt controller (INTC) that can handle various system input
>>> events and post interrupts back to the device-level initiators.
>>> The INTC can support upto 64 input events with individual control
>>> configuration and hardware prioritization. These events are mapped
>>> onto 10 interrupt signals through two levels of many-to-one mapping
>>> support. Different interrupt signals are routed to the individual
>>> PRU cores or to the host CPU.
>>>
>>> The PRUSS INTC platform driver manages this PRUSS interrupt
>>> controller and implements an irqchip driver to provide a Linux
>>> standard way for the PRU client users to enable/disable/ack/
>>> re-trigger a PRUSS system event. The system events to interrupt
>>> channels and host interrupts relies on the mapping configuration
>>> provided through a firmware resource table for now. This will be
>>> revisited and enhanced in the future for a better interface. The
>>> mappings will currently be programmed during the boot/shutdown
>>> of the PRU.
>>
>> Does this mapping table take up space in the PRU IRAM or DRAM? If
>> so, that can be a problem on the AM18xx because it has such limited
>> resources - every byte counts.
>
> Currently the entire resource table is being placed in DRAM.
> But that is only because the current rpmsg vdev implementation depends on the
> rpmsg channel information and vring buffers to be in DRAM.
>
> I think the right way is to split up the 2 things.
> i.e. separate out rpmgs channel DRAM allocation from resource table
> and don't copy the resource table to DRAM.
>
> This way if there is no rpmsg channel in the resource table we won't eat
> any DRAM.
>
> I'm not sure if there are any bottlenecks. I will only know when I work on it.
Sounds good to me.
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 09/17] soc: ti: pruss: add pruss_{request,release}_mem_region() API
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
` (7 preceding siblings ...)
2018-11-22 11:39 ` [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts Roger Quadros
@ 2018-11-22 11:39 ` Roger Quadros
2018-11-26 21:18 ` David Lechner
2018-11-22 11:39 ` [PATCH 10/17] soc: ti: pruss_intc: Add API to trigger a PRU sysevent Roger Quadros
` (8 subsequent siblings)
17 siblings, 1 reply; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:39 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
From: "Andrew F. Davis" <afd@ti.com>
Add two new API - pruss_request_mem_region() & pruss_release_mem_region(),
to the PRUSS platform driver to allow client drivers to acquire and release
the common memory resources present within a PRU-ICSS subsystem. This
allows the client drivers to directly manipulate the respective memories,
as per their design contract with the associated firmware.
Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: rename functions, add error checking, comments]
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/soc/ti/pruss.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
drivers/soc/ti/pruss.h | 26 +++------------
drivers/soc/ti/pruss_intc.c | 1 +
include/linux/pruss.h | 61 ++++++++++++++++++++++++++++++++++
4 files changed, 147 insertions(+), 22 deletions(-)
create mode 100644 include/linux/pruss.h
diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c
index 0840b59..c2271c4 100644
--- a/drivers/soc/ti/pruss.c
+++ b/drivers/soc/ti/pruss.c
@@ -12,9 +12,89 @@
#include <linux/io.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
+#include <linux/pruss.h>
#include "pruss.h"
+/**
+ * pruss_request_mem_region() - request a memory resource
+ * @pruss: the pruss instance
+ * @mem_id: the memory resource id
+ * @region: pointer to memory region structure to be filled in
+ *
+ * This function allows a client driver to request a memory resource,
+ * and if successful, will let the client driver own the particular
+ * memory region until released using the pruss_release_mem_region()
+ * API.
+ *
+ * Returns the memory region if requested resource is available, an
+ * error otherwise
+ */
+int pruss_request_mem_region(struct pruss *pruss, enum pruss_mem mem_id,
+ struct pruss_mem_region *region)
+{
+ if (!pruss || !region)
+ return -EINVAL;
+
+ if (mem_id >= PRUSS_MEM_MAX)
+ return -EINVAL;
+
+ mutex_lock(&pruss->lock);
+
+ if (pruss->mem_in_use[mem_id]) {
+ mutex_unlock(&pruss->lock);
+ return -EBUSY;
+ }
+
+ *region = pruss->mem_regions[mem_id];
+ pruss->mem_in_use[mem_id] = region;
+
+ mutex_unlock(&pruss->lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pruss_request_mem_region);
+
+/**
+ * pruss_release_mem_region() - release a memory resource
+ * @pruss: the pruss instance
+ * @region: the memory region to release
+ *
+ * This function is the complimentary function to
+ * pruss_request_mem_region(), and allows the client drivers to
+ * release back a memory resource.
+ *
+ * Returns 0 on success, an error code otherwise
+ */
+int pruss_release_mem_region(struct pruss *pruss,
+ struct pruss_mem_region *region)
+{
+ int id;
+
+ if (!pruss || !region)
+ return -EINVAL;
+
+ mutex_lock(&pruss->lock);
+
+ /* find out the memory region being released */
+ for (id = 0; id < PRUSS_MEM_MAX; id++) {
+ if (pruss->mem_in_use[id] == region)
+ break;
+ }
+
+ if (id == PRUSS_MEM_MAX) {
+ mutex_unlock(&pruss->lock);
+ return -EINVAL;
+ }
+
+ pruss->mem_in_use[id] = NULL;
+
+ mutex_unlock(&pruss->lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pruss_release_mem_region);
+
static int pruss_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -41,6 +121,7 @@ static int pruss_probe(struct platform_device *pdev)
return -ENOMEM;
pruss->dev = dev;
+ mutex_init(&pruss->lock);
np = of_get_child_by_name(node, "memories");
if (!np)
diff --git a/drivers/soc/ti/pruss.h b/drivers/soc/ti/pruss.h
index a5a0667..f8878c2 100644
--- a/drivers/soc/ti/pruss.h
+++ b/drivers/soc/ti/pruss.h
@@ -22,28 +22,6 @@
#define MAX_PRU_HOST_INT 10
/**
- * enum pruss_mem - PRUSS memory range identifiers
- */
-enum pruss_mem {
- PRUSS_MEM_DRAM0 = 0,
- PRUSS_MEM_DRAM1,
- PRUSS_MEM_SHRD_RAM2,
- PRUSS_MEM_MAX,
-};
-
-/**
- * struct pruss_mem_region - PRUSS memory region structure
- * @va: kernel virtual address of the PRUSS memory region
- * @pa: physical (bus) address of the PRUSS memory region
- * @size: size of the PRUSS memory region
- */
-struct pruss_mem_region {
- void __iomem *va;
- phys_addr_t pa;
- size_t size;
-};
-
-/**
* struct pruss_intc_config - INTC configuration info
* @sysev_to_ch: system events to channel mapping information
* @ch_to_host: interrupt channel to host interrupt information
@@ -57,12 +35,16 @@ struct pruss_intc_config {
* struct pruss - PRUSS parent structure
* @dev: pruss device pointer
* @mem_regions: data for each of the PRUSS memory regions
+ * @mem_in_use: to indicate if memory resource is in use
* @host_mask: indicate which HOST IRQs are enabled
+ * @lock: mutex to serialize access to resources
*/
struct pruss {
struct device *dev;
struct pruss_mem_region mem_regions[PRUSS_MEM_MAX];
+ struct pruss_mem_region *mem_in_use[PRUSS_MEM_MAX];
u32 host_mask;
+ struct mutex lock; /* PRU resource lock */
};
int pruss_intc_configure(struct pruss *pruss,
diff --git a/drivers/soc/ti/pruss_intc.c b/drivers/soc/ti/pruss_intc.c
index dde054b..df6b83b 100644
--- a/drivers/soc/ti/pruss_intc.c
+++ b/drivers/soc/ti/pruss_intc.c
@@ -13,6 +13,7 @@
#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
+#include <linux/pruss.h>
#include "pruss.h"
diff --git a/include/linux/pruss.h b/include/linux/pruss.h
new file mode 100644
index 0000000..198ae25
--- /dev/null
+++ b/include/linux/pruss.h
@@ -0,0 +1,61 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/**
+ * PRU-ICSS Subsystem user interfaces
+ *
+ * Copyright (C) 2015-2018 Texas Instruments Incorporated - http://www.ti.com
+ * Suman Anna <s-anna@ti.com>
+ * Tero Kristo <t-kristo@ti.com>
+ */
+
+#ifndef __LINUX_PRUSS_H
+#define __LINUX_PRUSS_H
+
+/**
+ * enum pruss_mem - PRUSS memory range identifiers
+ */
+enum pruss_mem {
+ PRUSS_MEM_DRAM0 = 0,
+ PRUSS_MEM_DRAM1,
+ PRUSS_MEM_SHRD_RAM2,
+ PRUSS_MEM_MAX,
+};
+
+/**
+ * struct pruss_mem_region - PRUSS memory region structure
+ * @va: kernel virtual address of the PRUSS memory region
+ * @pa: physical (bus) address of the PRUSS memory region
+ * @size: size of the PRUSS memory region
+ */
+struct pruss_mem_region {
+ void __iomem *va;
+ phys_addr_t pa;
+ size_t size;
+};
+
+struct pruss;
+
+#if IS_ENABLED(CONFIG_TI_PRUSS)
+
+int pruss_request_mem_region(struct pruss *pruss, enum pruss_mem mem_id,
+ struct pruss_mem_region *region);
+int pruss_release_mem_region(struct pruss *pruss,
+ struct pruss_mem_region *region);
+
+#else
+
+static inline int pruss_request_mem_region(struct pruss *pruss,
+ enum pruss_mem mem_id,
+ struct pruss_mem_region *region)
+{
+ return -ENOTSUPP;
+}
+
+static inline int pruss_release_mem_region(struct pruss *pruss,
+ struct pruss_mem_region *region)
+{
+ return -ENOTSUPP;
+}
+
+#endif /* CONFIG_TI_PRUSS */
+
+#endif /* __LINUX_PRUSS_H */
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* Re: [PATCH 09/17] soc: ti: pruss: add pruss_{request,release}_mem_region() API
2018-11-22 11:39 ` [PATCH 09/17] soc: ti: pruss: add pruss_{request,release}_mem_region() API Roger Quadros
@ 2018-11-26 21:18 ` David Lechner
0 siblings, 0 replies; 53+ messages in thread
From: David Lechner @ 2018-11-26 21:18 UTC (permalink / raw)
To: Roger Quadros, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
On 11/22/18 5:39 AM, Roger Quadros wrote:
> From: "Andrew F. Davis" <afd@ti.com>
>
> Add two new API - pruss_request_mem_region() & pruss_release_mem_region(),
> to the PRUSS platform driver to allow client drivers to acquire and release
> the common memory resources present within a PRU-ICSS subsystem. This
> allows the client drivers to directly manipulate the respective memories,
> as per their design contract with the associated firmware.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> [s-anna@ti.com: rename functions, add error checking, comments]
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> diff --git a/drivers/soc/ti/pruss.h b/drivers/soc/ti/pruss.h
> index a5a0667..f8878c2 100644
> --- a/drivers/soc/ti/pruss.h
> +++ b/drivers/soc/ti/pruss.h
> @@ -22,28 +22,6 @@
> #define MAX_PRU_HOST_INT 10
>
> /**
> - * enum pruss_mem - PRUSS memory range identifiers
> - */
> -enum pruss_mem {
> - PRUSS_MEM_DRAM0 = 0,
> - PRUSS_MEM_DRAM1,
> - PRUSS_MEM_SHRD_RAM2,
> - PRUSS_MEM_MAX,
> -};
> -
> -/**
> - * struct pruss_mem_region - PRUSS memory region structure
> - * @va: kernel virtual address of the PRUSS memory region
> - * @pa: physical (bus) address of the PRUSS memory region
> - * @size: size of the PRUSS memory region
> - */
> -struct pruss_mem_region {
> - void __iomem *va;
> - phys_addr_t pa;
> - size_t size;
> -};
Why don't we just put these definitions in the correct header file
to start with when they are introduced earlier in this series?
> diff --git a/include/linux/pruss.h b/include/linux/pruss.h
> new file mode 100644
> index 0000000..198ae25
> --- /dev/null
> +++ b/include/linux/pruss.h
> @@ -0,0 +1,61 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/**
> + * PRU-ICSS Subsystem user interfaces
> + *
> + * Copyright (C) 2015-2018 Texas Instruments Incorporated - http://www.ti.com
> + * Suman Anna <s-anna@ti.com>
> + * Tero Kristo <t-kristo@ti.com>
> + */
> +
> +#ifndef __LINUX_PRUSS_H
> +#define __LINUX_PRUSS_H
> +
> +/**
> + * enum pruss_mem - PRUSS memory range identifiers
> + */
> +enum pruss_mem {
> + PRUSS_MEM_DRAM0 = 0,
> + PRUSS_MEM_DRAM1,
> + PRUSS_MEM_SHRD_RAM2,
> + PRUSS_MEM_MAX,
> +};
> +
> +/**
> + * struct pruss_mem_region - PRUSS memory region structure
> + * @va: kernel virtual address of the PRUSS memory region
> + * @pa: physical (bus) address of the PRUSS memory region
> + * @size: size of the PRUSS memory region
> + */
> +struct pruss_mem_region {
> + void __iomem *va;
> + phys_addr_t pa;
> + size_t size;
> +};
> +
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 10/17] soc: ti: pruss_intc: Add API to trigger a PRU sysevent
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
` (8 preceding siblings ...)
2018-11-22 11:39 ` [PATCH 09/17] soc: ti: pruss: add pruss_{request,release}_mem_region() API Roger Quadros
@ 2018-11-22 11:39 ` Roger Quadros
2018-11-26 21:18 ` David Lechner
2018-11-22 11:39 ` [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API Roger Quadros
` (7 subsequent siblings)
17 siblings, 1 reply; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:39 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
From: Suman Anna <s-anna@ti.com>
The PRUSS INTC can generate an interrupt to various processor
subsystems on the SoC through a set of 64 possible PRU system
events. These system events can be used by PRU client drivers
or applications for event notifications/signalling between PRUs
and MPU or other processors. A new API, pruss_intc_trigger() is
provided to MPU-side PRU client drivers/applications to be able
to trigger an event/interrupt using IRQ numbers provided by the
PRUSS-INTC irqdomain chip.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/soc/ti/pruss_intc.c | 31 +++++++++++++++++++++++++++++++
include/linux/pruss.h | 7 +++++++
2 files changed, 38 insertions(+)
diff --git a/drivers/soc/ti/pruss_intc.c b/drivers/soc/ti/pruss_intc.c
index df6b83b..6158b63 100644
--- a/drivers/soc/ti/pruss_intc.c
+++ b/drivers/soc/ti/pruss_intc.c
@@ -395,6 +395,37 @@ static void pruss_intc_irq_relres(struct irq_data *data)
module_put(THIS_MODULE);
}
+/**
+ * pruss_intc_trigger() - trigger a PRU system event
+ * @irq: linux IRQ number associated with a PRU system event
+ *
+ * Trigger an interrupt by signalling a specific PRU system event.
+ * This can be used by PRUSS client users to raise/send an event to
+ * a PRU or any other core that is listening on the host interrupt
+ * mapped to that specific PRU system event. The @irq variable is the
+ * Linux IRQ number associated with a specific PRU system event that
+ * a client user/application uses. The interrupt mappings for this is
+ * provided by the PRUSS INTC irqchip instance.
+ *
+ * Returns 0 on success, or an error value upon failure.
+ */
+int pruss_intc_trigger(unsigned int irq)
+{
+ struct irq_desc *desc;
+
+ if (irq <= 0)
+ return -EINVAL;
+
+ desc = irq_to_desc(irq);
+ if (!desc)
+ return -EINVAL;
+
+ pruss_intc_irq_retrigger(&desc->irq_data);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pruss_intc_trigger);
+
static int pruss_intc_irq_domain_map(struct irq_domain *d, unsigned int virq,
irq_hw_number_t hw)
{
diff --git a/include/linux/pruss.h b/include/linux/pruss.h
index 198ae25..768b698 100644
--- a/include/linux/pruss.h
+++ b/include/linux/pruss.h
@@ -41,6 +41,8 @@ int pruss_request_mem_region(struct pruss *pruss, enum pruss_mem mem_id,
int pruss_release_mem_region(struct pruss *pruss,
struct pruss_mem_region *region);
+int pruss_intc_trigger(unsigned int irq);
+
#else
static inline int pruss_request_mem_region(struct pruss *pruss,
@@ -56,6 +58,11 @@ static inline int pruss_release_mem_region(struct pruss *pruss,
return -ENOTSUPP;
}
+static inline int pruss_intc_trigger(unsigned int irq)
+{
+ return -ENOTSUPP;
+}
+
#endif /* CONFIG_TI_PRUSS */
#endif /* __LINUX_PRUSS_H */
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* Re: [PATCH 10/17] soc: ti: pruss_intc: Add API to trigger a PRU sysevent
2018-11-22 11:39 ` [PATCH 10/17] soc: ti: pruss_intc: Add API to trigger a PRU sysevent Roger Quadros
@ 2018-11-26 21:18 ` David Lechner
0 siblings, 0 replies; 53+ messages in thread
From: David Lechner @ 2018-11-26 21:18 UTC (permalink / raw)
To: Roger Quadros, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
On 11/22/18 5:39 AM, Roger Quadros wrote:
> From: Suman Anna <s-anna@ti.com>
>
> The PRUSS INTC can generate an interrupt to various processor
> subsystems on the SoC through a set of 64 possible PRU system
> events. These system events can be used by PRU client drivers
> or applications for event notifications/signalling between PRUs
> and MPU or other processors. A new API, pruss_intc_trigger() is
> provided to MPU-side PRU client drivers/applications to be able
> to trigger an event/interrupt using IRQ numbers provided by the
> PRUSS-INTC irqdomain chip.
Could we just use something like this:
irq_set_irqchip_state(irq, IRQCHIP_STATE_PENDING, true);
instead of introducing a new API?
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
` (9 preceding siblings ...)
2018-11-22 11:39 ` [PATCH 10/17] soc: ti: pruss_intc: Add API to trigger a PRU sysevent Roger Quadros
@ 2018-11-22 11:39 ` Roger Quadros
2018-11-23 2:47 ` kbuild test robot
` (2 more replies)
2018-11-22 11:39 ` [PATCH 12/17] soc: ti: pruss: add pruss_cfg_read()/update() API Roger Quadros
` (6 subsequent siblings)
17 siblings, 3 replies; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:39 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
From: Tero Kristo <t-kristo@ti.com>
Add two new get and put API, pruss_get() and pruss_put(), to the
PRUSS platform driver to allow client drivers to request a handle
to a PRUSS device. This handle will be used by client drivers to
request various operations of the PRUSS platform driver through
additional API that will be added in the following patches.
The pruss_get() function returns the pruss handle corresponding
to a PRUSS device referenced by a PRU remoteproc instance. The
pruss_put() is the complimentary function to pruss_get().
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: various fixups and cleanups]
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/soc/ti/pruss.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/pruss.h | 10 +++++++++
2 files changed, 67 insertions(+)
diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c
index c2271c4..90ee5b9 100644
--- a/drivers/soc/ti/pruss.c
+++ b/drivers/soc/ti/pruss.c
@@ -13,10 +13,67 @@
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/pruss.h>
+#include <linux/remoteproc.h>
#include "pruss.h"
/**
+ * pruss_get() - get the pruss for a given PRU remoteproc
+ * @rproc: remoteproc handle of a PRU instance
+ *
+ * Finds the parent pruss device for a PRU given the @rproc handle of the
+ * PRU remote processor. This function increments the pruss device's refcount,
+ * so always use pruss_put() to decrement it back once pruss isn't needed
+ * anymore.
+ *
+ * Returns the pruss handle on success, and an ERR_PTR on failure using one
+ * of the following error values
+ * -EINVAL if invalid parameter
+ * -ENODEV if PRU device or PRUSS device is not found
+ */
+struct pruss *pruss_get(struct rproc *rproc)
+{
+ struct pruss *pruss;
+ struct device *dev;
+ struct platform_device *ppdev;
+
+ if (IS_ERR_OR_NULL(rproc))
+ return ERR_PTR(-EINVAL);
+
+ dev = &rproc->dev;
+ if (!dev->parent)
+ return ERR_PTR(-ENODEV);
+
+ /* rudimentary check to make sure rproc handle is for a PRU */
+ if (!strstr(dev_name(dev->parent), "pru"))
+ return ERR_PTR(-ENODEV);
+
+ ppdev = to_platform_device(dev->parent->parent);
+ pruss = platform_get_drvdata(ppdev);
+ if (pruss)
+ get_device(pruss->dev);
+
+ return pruss ? pruss : ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(pruss_get);
+
+/**
+ * pruss_put() - decrement pruss device's usecount
+ * @pruss: pruss handle
+ *
+ * Complimentary function for pruss_get(). Needs to be called
+ * after the PRUSS is used, and only if the pruss_get() succeeds.
+ */
+void pruss_put(struct pruss *pruss)
+{
+ if (IS_ERR_OR_NULL(pruss))
+ return;
+
+ put_device(pruss->dev);
+}
+EXPORT_SYMBOL_GPL(pruss_put);
+
+/**
* pruss_request_mem_region() - request a memory resource
* @pruss: the pruss instance
* @mem_id: the memory resource id
diff --git a/include/linux/pruss.h b/include/linux/pruss.h
index 768b698..b9135d6 100644
--- a/include/linux/pruss.h
+++ b/include/linux/pruss.h
@@ -36,6 +36,9 @@ struct pruss;
#if IS_ENABLED(CONFIG_TI_PRUSS)
+struct pruss *pruss_get(struct rproc *rproc);
+void pruss_put(struct pruss *pruss);
+
int pruss_request_mem_region(struct pruss *pruss, enum pruss_mem mem_id,
struct pruss_mem_region *region);
int pruss_release_mem_region(struct pruss *pruss,
@@ -45,6 +48,13 @@ int pruss_intc_trigger(unsigned int irq);
#else
+static inline struct pruss *pruss_get(struct rproc *rproc)
+{
+ return ERR_PTR(-ENOTSUPP);
+}
+
+static inline void pruss_put(struct pruss *pruss) { }
+
static inline int pruss_request_mem_region(struct pruss *pruss,
enum pruss_mem mem_id,
struct pruss_mem_region *region)
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* Re: [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API
2018-11-22 11:39 ` [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API Roger Quadros
@ 2018-11-23 2:47 ` kbuild test robot
2018-11-23 9:41 ` Roger Quadros
2018-11-23 8:20 ` Arnd Bergmann
2018-11-26 21:18 ` David Lechner
2 siblings, 1 reply; 53+ messages in thread
From: kbuild test robot @ 2018-11-23 2:47 UTC (permalink / raw)
To: Roger Quadros
Cc: kbuild-all, tony, robh+dt, bcousson, ssantosh, ohad,
bjorn.andersson, s-anna, nsekhar, t-kristo, nsaulnier, jreeder,
m-karicheri2, woods.technical, linux-omap, linux-remoteproc,
linux-kernel, devicetree, rogerq
[-- Attachment #1: Type: text/plain, Size: 6384 bytes --]
Hi Tero,
I love your patch! Yet something to improve:
[auto build test ERROR on keystone/next]
[also build test ERROR on v4.20-rc3 next-20181122]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Roger-Quadros/Add-support-for-TI-PRU-ICSS/20181123-083903
base: https://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
In file included from drivers/soc/ti/pruss_intc.c:16:0:
>> include/linux/pruss.h:39:32: warning: 'struct rproc' declared inside parameter list will not be visible outside of this definition or declaration
struct pruss *pruss_get(struct rproc *rproc);
^~~~~
--
In file included from drivers/soc/ti/pruss.c:15:0:
>> include/linux/pruss.h:39:32: warning: 'struct rproc' declared inside parameter list will not be visible outside of this definition or declaration
struct pruss *pruss_get(struct rproc *rproc);
^~~~~
>> drivers/soc/ti/pruss.c:34:15: error: conflicting types for 'pruss_get'
struct pruss *pruss_get(struct rproc *rproc)
^~~~~~~~~
In file included from drivers/soc/ti/pruss.c:15:0:
include/linux/pruss.h:39:15: note: previous declaration of 'pruss_get' was here
struct pruss *pruss_get(struct rproc *rproc);
^~~~~~~~~
In file included from include/linux/linkage.h:7:0,
from include/linux/kernel.h:7,
from include/linux/list.h:9,
from include/linux/kobject.h:19,
from include/linux/device.h:16,
from include/linux/dma-mapping.h:7,
from drivers/soc/ti/pruss.c:10:
drivers/soc/ti/pruss.c:58:19: error: conflicting types for 'pruss_get'
EXPORT_SYMBOL_GPL(pruss_get);
^
include/linux/export.h:79:21: note: in definition of macro '___EXPORT_SYMBOL'
extern typeof(sym) sym; \
^~~
>> drivers/soc/ti/pruss.c:58:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL'
EXPORT_SYMBOL_GPL(pruss_get);
^~~~~~~~~~~~~~~~~
In file included from drivers/soc/ti/pruss.c:15:0:
include/linux/pruss.h:39:15: note: previous declaration of 'pruss_get' was here
struct pruss *pruss_get(struct rproc *rproc);
^~~~~~~~~
--
In file included from drivers/soc//ti/pruss.c:15:0:
>> include/linux/pruss.h:39:32: warning: 'struct rproc' declared inside parameter list will not be visible outside of this definition or declaration
struct pruss *pruss_get(struct rproc *rproc);
^~~~~
drivers/soc//ti/pruss.c:34:15: error: conflicting types for 'pruss_get'
struct pruss *pruss_get(struct rproc *rproc)
^~~~~~~~~
In file included from drivers/soc//ti/pruss.c:15:0:
include/linux/pruss.h:39:15: note: previous declaration of 'pruss_get' was here
struct pruss *pruss_get(struct rproc *rproc);
^~~~~~~~~
In file included from include/linux/linkage.h:7:0,
from include/linux/kernel.h:7,
from include/linux/list.h:9,
from include/linux/kobject.h:19,
from include/linux/device.h:16,
from include/linux/dma-mapping.h:7,
from drivers/soc//ti/pruss.c:10:
drivers/soc//ti/pruss.c:58:19: error: conflicting types for 'pruss_get'
EXPORT_SYMBOL_GPL(pruss_get);
^
include/linux/export.h:79:21: note: in definition of macro '___EXPORT_SYMBOL'
extern typeof(sym) sym; \
^~~
drivers/soc//ti/pruss.c:58:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL'
EXPORT_SYMBOL_GPL(pruss_get);
^~~~~~~~~~~~~~~~~
In file included from drivers/soc//ti/pruss.c:15:0:
include/linux/pruss.h:39:15: note: previous declaration of 'pruss_get' was here
struct pruss *pruss_get(struct rproc *rproc);
^~~~~~~~~
vim +/pruss_get +34 drivers/soc/ti/pruss.c
> 10 #include <linux/dma-mapping.h>
11 #include <linux/module.h>
12 #include <linux/io.h>
13 #include <linux/of_address.h>
14 #include <linux/of_device.h>
> 15 #include <linux/pruss.h>
16 #include <linux/remoteproc.h>
17
18 #include "pruss.h"
19
20 /**
21 * pruss_get() - get the pruss for a given PRU remoteproc
22 * @rproc: remoteproc handle of a PRU instance
23 *
24 * Finds the parent pruss device for a PRU given the @rproc handle of the
25 * PRU remote processor. This function increments the pruss device's refcount,
26 * so always use pruss_put() to decrement it back once pruss isn't needed
27 * anymore.
28 *
29 * Returns the pruss handle on success, and an ERR_PTR on failure using one
30 * of the following error values
31 * -EINVAL if invalid parameter
32 * -ENODEV if PRU device or PRUSS device is not found
33 */
> 34 struct pruss *pruss_get(struct rproc *rproc)
35 {
36 struct pruss *pruss;
37 struct device *dev;
38 struct platform_device *ppdev;
39
40 if (IS_ERR_OR_NULL(rproc))
41 return ERR_PTR(-EINVAL);
42
43 dev = &rproc->dev;
44 if (!dev->parent)
45 return ERR_PTR(-ENODEV);
46
47 /* rudimentary check to make sure rproc handle is for a PRU */
48 if (!strstr(dev_name(dev->parent), "pru"))
49 return ERR_PTR(-ENODEV);
50
51 ppdev = to_platform_device(dev->parent->parent);
52 pruss = platform_get_drvdata(ppdev);
53 if (pruss)
54 get_device(pruss->dev);
55
56 return pruss ? pruss : ERR_PTR(-ENODEV);
57 }
> 58 EXPORT_SYMBOL_GPL(pruss_get);
59
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 67069 bytes --]
^ permalink raw reply [flat|nested] 53+ messages in thread* Re: [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API
2018-11-23 2:47 ` kbuild test robot
@ 2018-11-23 9:41 ` Roger Quadros
0 siblings, 0 replies; 53+ messages in thread
From: Roger Quadros @ 2018-11-23 9:41 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, tony, robh+dt, bcousson, ssantosh, ohad,
bjorn.andersson, s-anna, nsekhar, t-kristo, nsaulnier, jreeder,
m-karicheri2, woods.technical, linux-omap, linux-remoteproc,
linux-kernel, devicetree
On 23/11/18 04:47, kbuild test robot wrote:
> Hi Tero,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on keystone/next]
> [also build test ERROR on v4.20-rc3 next-20181122]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Roger-Quadros/Add-support-for-TI-PRU-ICSS/20181123-083903
> base: https://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git next
> config: arm-allmodconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=arm
>
> All error/warnings (new ones prefixed by >>):
>
> In file included from drivers/soc/ti/pruss_intc.c:16:0:
>>> include/linux/pruss.h:39:32: warning: 'struct rproc' declared inside parameter list will not be visible outside of this definition or declaration
> struct pruss *pruss_get(struct rproc *rproc);
> ^~~~~
This was my bad due to re-ordering of patches. Fixed now.
cheers,
-roger
> --
> In file included from drivers/soc/ti/pruss.c:15:0:
>>> include/linux/pruss.h:39:32: warning: 'struct rproc' declared inside parameter list will not be visible outside of this definition or declaration
> struct pruss *pruss_get(struct rproc *rproc);
> ^~~~~
>>> drivers/soc/ti/pruss.c:34:15: error: conflicting types for 'pruss_get'
> struct pruss *pruss_get(struct rproc *rproc)
> ^~~~~~~~~
> In file included from drivers/soc/ti/pruss.c:15:0:
> include/linux/pruss.h:39:15: note: previous declaration of 'pruss_get' was here
> struct pruss *pruss_get(struct rproc *rproc);
> ^~~~~~~~~
> In file included from include/linux/linkage.h:7:0,
> from include/linux/kernel.h:7,
> from include/linux/list.h:9,
> from include/linux/kobject.h:19,
> from include/linux/device.h:16,
> from include/linux/dma-mapping.h:7,
> from drivers/soc/ti/pruss.c:10:
> drivers/soc/ti/pruss.c:58:19: error: conflicting types for 'pruss_get'
> EXPORT_SYMBOL_GPL(pruss_get);
> ^
> include/linux/export.h:79:21: note: in definition of macro '___EXPORT_SYMBOL'
> extern typeof(sym) sym; \
> ^~~
>>> drivers/soc/ti/pruss.c:58:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL'
> EXPORT_SYMBOL_GPL(pruss_get);
> ^~~~~~~~~~~~~~~~~
> In file included from drivers/soc/ti/pruss.c:15:0:
> include/linux/pruss.h:39:15: note: previous declaration of 'pruss_get' was here
> struct pruss *pruss_get(struct rproc *rproc);
> ^~~~~~~~~
> --
> In file included from drivers/soc//ti/pruss.c:15:0:
>>> include/linux/pruss.h:39:32: warning: 'struct rproc' declared inside parameter list will not be visible outside of this definition or declaration
> struct pruss *pruss_get(struct rproc *rproc);
> ^~~~~
> drivers/soc//ti/pruss.c:34:15: error: conflicting types for 'pruss_get'
> struct pruss *pruss_get(struct rproc *rproc)
> ^~~~~~~~~
> In file included from drivers/soc//ti/pruss.c:15:0:
> include/linux/pruss.h:39:15: note: previous declaration of 'pruss_get' was here
> struct pruss *pruss_get(struct rproc *rproc);
> ^~~~~~~~~
> In file included from include/linux/linkage.h:7:0,
> from include/linux/kernel.h:7,
> from include/linux/list.h:9,
> from include/linux/kobject.h:19,
> from include/linux/device.h:16,
> from include/linux/dma-mapping.h:7,
> from drivers/soc//ti/pruss.c:10:
> drivers/soc//ti/pruss.c:58:19: error: conflicting types for 'pruss_get'
> EXPORT_SYMBOL_GPL(pruss_get);
> ^
> include/linux/export.h:79:21: note: in definition of macro '___EXPORT_SYMBOL'
> extern typeof(sym) sym; \
> ^~~
> drivers/soc//ti/pruss.c:58:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL'
> EXPORT_SYMBOL_GPL(pruss_get);
> ^~~~~~~~~~~~~~~~~
> In file included from drivers/soc//ti/pruss.c:15:0:
> include/linux/pruss.h:39:15: note: previous declaration of 'pruss_get' was here
> struct pruss *pruss_get(struct rproc *rproc);
> ^~~~~~~~~
>
> vim +/pruss_get +34 drivers/soc/ti/pruss.c
>
> > 10 #include <linux/dma-mapping.h>
> 11 #include <linux/module.h>
> 12 #include <linux/io.h>
> 13 #include <linux/of_address.h>
> 14 #include <linux/of_device.h>
> > 15 #include <linux/pruss.h>
> 16 #include <linux/remoteproc.h>
> 17
> 18 #include "pruss.h"
> 19
> 20 /**
> 21 * pruss_get() - get the pruss for a given PRU remoteproc
> 22 * @rproc: remoteproc handle of a PRU instance
> 23 *
> 24 * Finds the parent pruss device for a PRU given the @rproc handle of the
> 25 * PRU remote processor. This function increments the pruss device's refcount,
> 26 * so always use pruss_put() to decrement it back once pruss isn't needed
> 27 * anymore.
> 28 *
> 29 * Returns the pruss handle on success, and an ERR_PTR on failure using one
> 30 * of the following error values
> 31 * -EINVAL if invalid parameter
> 32 * -ENODEV if PRU device or PRUSS device is not found
> 33 */
> > 34 struct pruss *pruss_get(struct rproc *rproc)
> 35 {
> 36 struct pruss *pruss;
> 37 struct device *dev;
> 38 struct platform_device *ppdev;
> 39
> 40 if (IS_ERR_OR_NULL(rproc))
> 41 return ERR_PTR(-EINVAL);
> 42
> 43 dev = &rproc->dev;
> 44 if (!dev->parent)
> 45 return ERR_PTR(-ENODEV);
> 46
> 47 /* rudimentary check to make sure rproc handle is for a PRU */
> 48 if (!strstr(dev_name(dev->parent), "pru"))
> 49 return ERR_PTR(-ENODEV);
> 50
> 51 ppdev = to_platform_device(dev->parent->parent);
> 52 pruss = platform_get_drvdata(ppdev);
> 53 if (pruss)
> 54 get_device(pruss->dev);
> 55
> 56 return pruss ? pruss : ERR_PTR(-ENODEV);
> 57 }
> > 58 EXPORT_SYMBOL_GPL(pruss_get);
> 59
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API
2018-11-22 11:39 ` [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API Roger Quadros
2018-11-23 2:47 ` kbuild test robot
@ 2018-11-23 8:20 ` Arnd Bergmann
2018-11-23 8:58 ` Tero Kristo
2018-11-23 9:40 ` Roger Quadros
2018-11-26 21:18 ` David Lechner
2 siblings, 2 replies; 53+ messages in thread
From: Arnd Bergmann @ 2018-11-23 8:20 UTC (permalink / raw)
To: Roger Quadros
Cc: Tony Lindgren, Rob Herring, Beno??t Cousson, Santosh Shilimkar,
Ohad Ben-Cohen, Bjorn Andersson, Suman Anna, Sekhar Nori,
Tero Kristo, nsaulnier, jreeder, Murali Karicheri,
woods.technical, linux-omap, linux-remoteproc,
Linux Kernel Mailing List, DTML
On Thu, Nov 22, 2018 at 12:41 PM Roger Quadros <rogerq@ti.com> wrote:
> +
> + if (IS_ERR_OR_NULL(rproc))
> + return ERR_PTR(-EINVAL);
Any usage of IS_ERR_OR_NULL() tends to be an indication of a badly
designed API. Please change this to allow only one of the two to be passed
around.
Arnd
^ permalink raw reply [flat|nested] 53+ messages in thread* Re: [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API
2018-11-23 8:20 ` Arnd Bergmann
@ 2018-11-23 8:58 ` Tero Kristo
2018-11-23 9:40 ` Roger Quadros
1 sibling, 0 replies; 53+ messages in thread
From: Tero Kristo @ 2018-11-23 8:58 UTC (permalink / raw)
To: Arnd Bergmann, Roger Quadros
Cc: Tony Lindgren, Rob Herring, Beno??t Cousson, Santosh Shilimkar,
Ohad Ben-Cohen, Bjorn Andersson, Suman Anna, Sekhar Nori,
nsaulnier, jreeder, Murali Karicheri, woods.technical,
linux-omap, linux-remoteproc, Linux Kernel Mailing List, DTML
On 23/11/2018 10:20, Arnd Bergmann wrote:
> On Thu, Nov 22, 2018 at 12:41 PM Roger Quadros <rogerq@ti.com> wrote:
>
>> +
>> + if (IS_ERR_OR_NULL(rproc))
>> + return ERR_PTR(-EINVAL);
>
>
> Any usage of IS_ERR_OR_NULL() tends to be an indication of a badly
> designed API. Please change this to allow only one of the two to be passed
> around.
Should this be deprecated then?
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API
2018-11-23 8:20 ` Arnd Bergmann
2018-11-23 8:58 ` Tero Kristo
@ 2018-11-23 9:40 ` Roger Quadros
1 sibling, 0 replies; 53+ messages in thread
From: Roger Quadros @ 2018-11-23 9:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Tony Lindgren, Rob Herring, Beno??t Cousson, Santosh Shilimkar,
Ohad Ben-Cohen, Bjorn Andersson, Suman Anna, Sekhar Nori,
Tero Kristo, nsaulnier, jreeder, Murali Karicheri,
woods.technical, linux-omap, linux-remoteproc,
Linux Kernel Mailing List, DTML
On 23/11/18 10:20, Arnd Bergmann wrote:
> On Thu, Nov 22, 2018 at 12:41 PM Roger Quadros <rogerq@ti.com> wrote:
>
>> +
>> + if (IS_ERR_OR_NULL(rproc))
>> + return ERR_PTR(-EINVAL);
>
>
> Any usage of IS_ERR_OR_NULL() tends to be an indication of a badly
> designed API. Please change this to allow only one of the two to be passed
> around.
The user of this API has to call pru_rproc_get() which never returns NULL.
So IS_ERR() should suffice here.
>
> Arnd
>
cheers,
-roger
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API
2018-11-22 11:39 ` [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API Roger Quadros
2018-11-23 2:47 ` kbuild test robot
2018-11-23 8:20 ` Arnd Bergmann
@ 2018-11-26 21:18 ` David Lechner
2 siblings, 0 replies; 53+ messages in thread
From: David Lechner @ 2018-11-26 21:18 UTC (permalink / raw)
To: Roger Quadros, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
On 11/22/18 5:39 AM, Roger Quadros wrote:
> + pruss = platform_get_drvdata(ppdev);
> + if (pruss)
> + get_device(pruss->dev);
> +
> + return pruss ? pruss : ERR_PTR(-ENODEV);
> +}
This might be a bit easier to follow if we handle the error
path first:
if (!pruss)
return ERR_PTR(-ENODEV);
get_device(pruss->dev);
return pruss;
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 12/17] soc: ti: pruss: add pruss_cfg_read()/update() API
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
` (10 preceding siblings ...)
2018-11-22 11:39 ` [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API Roger Quadros
@ 2018-11-22 11:39 ` Roger Quadros
2018-11-22 11:39 ` [PATCH 13/17] soc: ti: pruss: export pruss_intc_configure/unconfigure APIs Roger Quadros
` (5 subsequent siblings)
17 siblings, 0 replies; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:39 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
Add two new APIs pruss_cfg_read() and pruss_cfg_update()
to the PRUSS platform driver to allow other drivers to read and
update the registers in the CFG submodule within the PRUSS.
This interface provides a simple way for client drivers
without having them to include and parse these syscon nodes within
their respective device nodes.
The register definitions for the CFG registors have also been added.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/soc/ti/Kconfig | 1 +
drivers/soc/ti/pruss.c | 52 +++++++++++++++++++++++++
drivers/soc/ti/pruss.h | 2 +
include/linux/pruss.h | 101 +++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 156 insertions(+)
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index d1ea6da..d239996 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -76,6 +76,7 @@ config TI_SCI_PM_DOMAINS
config TI_PRUSS
tristate "TI PRU-ICSS Subsystem Platform drivers"
depends on SOC_AM33XX
+ select MFD_SYSCON
default n
help
TI PRU-ICSS Subsystem platform specific support.
diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c
index 90ee5b9..63c7d8c 100644
--- a/drivers/soc/ti/pruss.c
+++ b/drivers/soc/ti/pruss.c
@@ -10,9 +10,11 @@
#include <linux/dma-mapping.h>
#include <linux/module.h>
#include <linux/io.h>
+#include <linux/mfd/syscon.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/pruss.h>
+#include <linux/regmap.h>
#include <linux/remoteproc.h>
#include "pruss.h"
@@ -152,6 +154,47 @@ int pruss_release_mem_region(struct pruss *pruss,
}
EXPORT_SYMBOL_GPL(pruss_release_mem_region);
+/**
+ * pruss_cfg_read() - read a PRUSS CFG register
+ * @pruss: the pruss instance handle
+ * @reg: register offset within the CFG sub-module
+ * @val: pointer to return the value in
+ *
+ * Reads a given register within CFG module of PRUSS
+ * and returns it through the passed-in @val pointer
+ *
+ * Returns 0 on success, or an error code otherwise
+ */
+int pruss_cfg_read(struct pruss *pruss, unsigned int reg, unsigned int *val)
+{
+ if (IS_ERR_OR_NULL(pruss))
+ return -EINVAL;
+
+ return regmap_read(pruss->cfg, reg, val);
+}
+EXPORT_SYMBOL_GPL(pruss_cfg_read);
+
+/**
+ * pruss_cfg_update() - update a PRUSS CFG register
+ * @pruss: the pruss instance handle
+ * @reg: register offset within the CFG sub-module
+ * @mask: bit mask to use for programming the @val
+ * @val: value to write
+ *
+ * Updates a given register within CFG sub-module of PRUSS
+ *
+ * Returns 0 on success, or an error code otherwise
+ */
+int pruss_cfg_update(struct pruss *pruss, unsigned int reg,
+ unsigned int mask, unsigned int val)
+{
+ if (IS_ERR_OR_NULL(pruss))
+ return -EINVAL;
+
+ return regmap_update_bits(pruss->cfg, reg, mask, val);
+}
+EXPORT_SYMBOL_GPL(pruss_cfg_update);
+
static int pruss_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -180,6 +223,15 @@ static int pruss_probe(struct platform_device *pdev)
pruss->dev = dev;
mutex_init(&pruss->lock);
+ np = of_get_child_by_name(node, "cfg");
+ if (!np)
+ return -ENODEV;
+
+ pruss->cfg = syscon_node_to_regmap(np);
+ of_node_put(np);
+ if (IS_ERR(pruss->cfg))
+ return -ENODEV;
+
np = of_get_child_by_name(node, "memories");
if (!np)
return -ENODEV;
diff --git a/drivers/soc/ti/pruss.h b/drivers/soc/ti/pruss.h
index f8878c2..45de1be 100644
--- a/drivers/soc/ti/pruss.h
+++ b/drivers/soc/ti/pruss.h
@@ -34,6 +34,7 @@ struct pruss_intc_config {
/**
* struct pruss - PRUSS parent structure
* @dev: pruss device pointer
+ * @cfg: regmap for config region
* @mem_regions: data for each of the PRUSS memory regions
* @mem_in_use: to indicate if memory resource is in use
* @host_mask: indicate which HOST IRQs are enabled
@@ -41,6 +42,7 @@ struct pruss_intc_config {
*/
struct pruss {
struct device *dev;
+ struct regmap *cfg;
struct pruss_mem_region mem_regions[PRUSS_MEM_MAX];
struct pruss_mem_region *mem_in_use[PRUSS_MEM_MAX];
u32 host_mask;
diff --git a/include/linux/pruss.h b/include/linux/pruss.h
index b9135d6..3ed175a 100644
--- a/include/linux/pruss.h
+++ b/include/linux/pruss.h
@@ -10,6 +10,92 @@
#ifndef __LINUX_PRUSS_H
#define __LINUX_PRUSS_H
+/*
+ * PRU_ICSS_CFG registers
+ * SYSCFG, ISRP, ISP, IESP, IECP, SCRP applicable on AMxxxx devices only
+ */
+#define PRUSS_CFG_REVID 0x00
+#define PRUSS_CFG_SYSCFG 0x04
+#define PRUSS_CFG_GPCFG(x) (0x08 + (x) * 4)
+#define PRUSS_CFG_CGR 0x10
+#define PRUSS_CFG_ISRP 0x14
+#define PRUSS_CFG_ISP 0x18
+#define PRUSS_CFG_IESP 0x1C
+#define PRUSS_CFG_IECP 0x20
+#define PRUSS_CFG_SCRP 0x24
+#define PRUSS_CFG_PMAO 0x28
+#define PRUSS_CFG_MII_RT 0x2C
+#define PRUSS_CFG_IEPCLK 0x30
+#define PRUSS_CFG_SPP 0x34
+#define PRUSS_CFG_PIN_MX 0x40
+
+/* PRUSS_GPCFG register bits */
+#define PRUSS_GPCFG_PRU_GPO_SH_SEL BIT(25)
+
+#define PRUSS_GPCFG_PRU_DIV1_SHIFT 20
+#define PRUSS_GPCFG_PRU_DIV1_MASK GENMASK(24, 20)
+
+#define PRUSS_GPCFG_PRU_DIV0_SHIFT 15
+#define PRUSS_GPCFG_PRU_DIV0_MASK GENMASK(15, 19)
+
+#define PRUSS_GPCFG_PRU_GPO_MODE BIT(14)
+#define PRUSS_GPCFG_PRU_GPO_MODE_DIRECT 0
+#define PRUSS_GPCFG_PRU_GPO_MODE_SERIAL BIT(14)
+
+#define PRUSS_GPCFG_PRU_GPI_SB BIT(13)
+
+#define PRUSS_GPCFG_PRU_GPI_DIV1_SHIFT 8
+#define PRUSS_GPCFG_PRU_GPI_DIV1_MASK GENMASK(12, 8)
+
+#define PRUSS_GPCFG_PRU_GPI_DIV0_SHIFT 3
+#define PRUSS_GPCFG_PRU_GPI_DIV0_MASK GENMASK(7, 3)
+
+#define PRUSS_GPCFG_PRU_GPI_CLK_MODE_POSITIVE 0
+#define PRUSS_GPCFG_PRU_GPI_CLK_MODE_NEGATIVE BIT(2)
+#define PRUSS_GPCFG_PRU_GPI_CLK_MODE BIT(2)
+
+#define PRUSS_GPCFG_PRU_GPI_MODE_MASK GENMASK(1, 0)
+#define PRUSS_GPCFG_PRU_GPI_MODE_SHIFT 0
+
+#define PRUSS_GPCFG_PRU_MUX_SEL_SHIFT 26
+#define PRUSS_GPCFG_PRU_MUX_SEL_MASK GENMASK(29, 26)
+
+/* PRUSS_MII_RT register bits */
+#define PRUSS_MII_RT_EVENT_EN BIT(0)
+
+/* PRUSS_SPP register bits */
+#define PRUSS_SPP_XFER_SHIFT_EN BIT(1)
+#define PRUSS_SPP_PRU1_PAD_HP_EN BIT(0)
+
+/**
+ * enum pruss_gp_mux_sel - PRUSS GPI/O Mux modes for the
+ * PRUSS_GPCFG0/1 registers
+ *
+ * NOTE: The below defines are the most common values, but there
+ * are some exceptions like on 66AK2G, where the RESERVED and MII2
+ * values are interchanged. Also, this bit-field does not exist on
+ * AM335x SoCs
+ */
+enum pruss_gp_mux_sel {
+ PRUSS_GP_MUX_SEL_GP = 0,
+ PRUSS_GP_MUX_SEL_ENDAT,
+ PRUSS_GP_MUX_SEL_RESERVED,
+ PRUSS_GP_MUX_SEL_SD,
+ PRUSS_GP_MUX_SEL_MII2,
+ PRUSS_GP_MUX_SEL_MAX,
+};
+
+/**
+ * enum pruss_gpi_mode - PRUSS GPI configuration modes, used
+ * to program the PRUSS_GPCFG0/1 registers
+ */
+enum pruss_gpi_mode {
+ PRUSS_GPI_MODE_DIRECT = 0,
+ PRUSS_GPI_MODE_PARALLEL,
+ PRUSS_GPI_MODE_28BIT_SHIFT,
+ PRUSS_GPI_MODE_MII,
+};
+
/**
* enum pruss_mem - PRUSS memory range identifiers
*/
@@ -46,6 +132,10 @@ int pruss_release_mem_region(struct pruss *pruss,
int pruss_intc_trigger(unsigned int irq);
+int pruss_cfg_read(struct pruss *pruss, unsigned int reg, unsigned int *val);
+int pruss_cfg_update(struct pruss *pruss, unsigned int reg,
+ unsigned int mask, unsigned int val);
+
#else
static inline struct pruss *pruss_get(struct rproc *rproc)
@@ -73,6 +163,17 @@ static inline int pruss_intc_trigger(unsigned int irq)
return -ENOTSUPP;
}
+int pruss_cfg_read(struct pruss *pruss, unsigned int reg, unsigned int *val)
+{
+ return -ENOTSUPP;
+}
+
+int pruss_cfg_update(struct pruss *pruss, unsigned int reg,
+ unsigned int mask, unsigned int val)
+{
+ return -ENOTSUPP;
+}
+
#endif /* CONFIG_TI_PRUSS */
#endif /* __LINUX_PRUSS_H */
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* [PATCH 13/17] soc: ti: pruss: export pruss_intc_configure/unconfigure APIs
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
` (11 preceding siblings ...)
2018-11-22 11:39 ` [PATCH 12/17] soc: ti: pruss: add pruss_cfg_read()/update() API Roger Quadros
@ 2018-11-22 11:39 ` Roger Quadros
2018-11-26 21:19 ` David Lechner
2018-11-22 11:39 ` [PATCH 14/17] ARM: OMAP2+: use pdata quirks for PRUSS reset lines on AM335x Roger Quadros
` (4 subsequent siblings)
17 siblings, 1 reply; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:39 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
The PRU remoteproc driver will need to configure the
Interrupt controller based on the application specific
interrupt map.
Export pruss_intc_configure() and pruss_intc_unconfigure()
to linux/pruss.h
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/soc/ti/pruss.h | 21 -------------------
include/linux/pruss.h | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 56 insertions(+), 21 deletions(-)
diff --git a/drivers/soc/ti/pruss.h b/drivers/soc/ti/pruss.h
index 45de1be..ce3f96a 100644
--- a/drivers/soc/ti/pruss.h
+++ b/drivers/soc/ti/pruss.h
@@ -9,12 +9,6 @@
#ifndef _PRUSS_H_
#define _PRUSS_H_
-/* maximum number of system events */
-#define MAX_PRU_SYS_EVENTS 64
-
-/* maximum number of interrupt channels */
-#define MAX_PRU_CHANNELS 10
-
/* minimum starting host interrupt number for MPU */
#define MIN_PRU_HOST_INT 2
@@ -22,16 +16,6 @@
#define MAX_PRU_HOST_INT 10
/**
- * struct pruss_intc_config - INTC configuration info
- * @sysev_to_ch: system events to channel mapping information
- * @ch_to_host: interrupt channel to host interrupt information
- */
-struct pruss_intc_config {
- s8 sysev_to_ch[MAX_PRU_SYS_EVENTS];
- s8 ch_to_host[MAX_PRU_CHANNELS];
-};
-
-/**
* struct pruss - PRUSS parent structure
* @dev: pruss device pointer
* @cfg: regmap for config region
@@ -49,9 +33,4 @@ struct pruss {
struct mutex lock; /* PRU resource lock */
};
-int pruss_intc_configure(struct pruss *pruss,
- struct pruss_intc_config *intc_config);
-int pruss_intc_unconfigure(struct pruss *pruss,
- struct pruss_intc_config *intc_config);
-
#endif /* _PRUSS_H_ */
diff --git a/include/linux/pruss.h b/include/linux/pruss.h
index 3ed175a..c797fb1 100644
--- a/include/linux/pruss.h
+++ b/include/linux/pruss.h
@@ -118,6 +118,22 @@ struct pruss_mem_region {
size_t size;
};
+/* maximum number of system events */
+#define MAX_PRU_SYS_EVENTS 64
+
+/* maximum number of interrupt channels */
+#define MAX_PRU_CHANNELS 10
+
+/**
+ * struct pruss_intc_config - INTC configuration info
+ * @sysev_to_ch: system events to channel mapping information
+ * @ch_to_host: interrupt channel to host interrupt information
+ */
+struct pruss_intc_config {
+ s8 sysev_to_ch[MAX_PRU_SYS_EVENTS];
+ s8 ch_to_host[MAX_PRU_CHANNELS];
+};
+
struct pruss;
#if IS_ENABLED(CONFIG_TI_PRUSS)
@@ -136,6 +152,34 @@ int pruss_cfg_read(struct pruss *pruss, unsigned int reg, unsigned int *val);
int pruss_cfg_update(struct pruss *pruss, unsigned int reg,
unsigned int mask, unsigned int val);
+/**
+ * pruss_intc_configure() - configure the PRUSS INTC
+ * @pruss: the pruss instance
+ * @intc_config: PRU core-specific INTC configuration
+ *
+ * Configures the PRUSS INTC with the provided configuration from
+ * a PRU core. Any existing event to channel mappings or channel to
+ * host interrupt mappings are checked to make sure there are no
+ * conflicting configuration between both the PRU cores. The function
+ * is intended to be used only by the PRU remoteproc driver.
+ *
+ * Returns 0 on success, or a suitable error code otherwise
+ */
+int pruss_intc_configure(struct pruss *pruss,
+ struct pruss_intc_config *intc_config);
+
+/**
+ * pruss_intc_unconfigure() - unconfigure the PRUSS INTC
+ * @pruss: the pruss instance
+ * @intc_config: PRU core specific INTC configuration
+ *
+ * Undo whatever was done in pruss_intc_configure() for a PRU core.
+ * It should be sufficient to just mark the resources free in the
+ * global map and disable the host interrupts and sysevents.
+ */
+int pruss_intc_unconfigure(struct pruss *pruss,
+ struct pruss_intc_config *intc_config);
+
#else
static inline struct pruss *pruss_get(struct rproc *rproc)
@@ -174,6 +218,18 @@ int pruss_cfg_update(struct pruss *pruss, unsigned int reg,
return -ENOTSUPP;
}
+int pruss_intc_configure(struct pruss *pruss,
+ struct pruss_intc_config *intc_config)
+{
+ return -ENOTSUPP;
+}
+
+int pruss_intc_unconfigure(struct pruss *pruss,
+ struct pruss_intc_config *intc_config)
+{
+ return -ENOTSUPP;
+}
+
#endif /* CONFIG_TI_PRUSS */
#endif /* __LINUX_PRUSS_H */
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* Re: [PATCH 13/17] soc: ti: pruss: export pruss_intc_configure/unconfigure APIs
2018-11-22 11:39 ` [PATCH 13/17] soc: ti: pruss: export pruss_intc_configure/unconfigure APIs Roger Quadros
@ 2018-11-26 21:19 ` David Lechner
0 siblings, 0 replies; 53+ messages in thread
From: David Lechner @ 2018-11-26 21:19 UTC (permalink / raw)
To: Roger Quadros, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
On 11/22/18 5:39 AM, Roger Quadros wrote:
> The PRU remoteproc driver will need to configure the
> Interrupt controller based on the application specific
> interrupt map.
>
> Export pruss_intc_configure() and pruss_intc_unconfigure()
> to linux/pruss.h
Do we really need a patch just to move things around in header
files and make these public? It seems like this could have just
been done in the first place when these functions were introduced.
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> drivers/soc/ti/pruss.h | 21 -------------------
> include/linux/pruss.h | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 56 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/soc/ti/pruss.h b/drivers/soc/ti/pruss.h
> index 45de1be..ce3f96a 100644
> --- a/drivers/soc/ti/pruss.h
> +++ b/drivers/soc/ti/pruss.h
...
> +/**
> + * pruss_intc_configure() - configure the PRUSS INTC
> + * @pruss: the pruss instance
> + * @intc_config: PRU core-specific INTC configuration
> + *
> + * Configures the PRUSS INTC with the provided configuration from
> + * a PRU core. Any existing event to channel mappings or channel to
> + * host interrupt mappings are checked to make sure there are no
> + * conflicting configuration between both the PRU cores. The function
> + * is intended to be used only by the PRU remoteproc driver.
If this can only be used by the remoteproc driver, then how are other
drivers supposed to configure the interrupt mapping?
> + *
> + * Returns 0 on success, or a suitable error code otherwise
> + */
> +int pruss_intc_configure(struct pruss *pruss,
> + struct pruss_intc_config *intc_config);
> +
> +/**
> + * pruss_intc_unconfigure() - unconfigure the PRUSS INTC
> + * @pruss: the pruss instance
> + * @intc_config: PRU core specific INTC configuration
> + *
> + * Undo whatever was done in pruss_intc_configure() for a PRU core.
> + * It should be sufficient to just mark the resources free in the
> + * global map and disable the host interrupts and sysevents.
I don't understand the second sentence of this comment. Perhaps it needs
more explanation.
> + */
> +int pruss_intc_unconfigure(struct pruss *pruss,
> + struct pruss_intc_config *intc_config);
> +
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 14/17] ARM: OMAP2+: use pdata quirks for PRUSS reset lines on AM335x
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
` (12 preceding siblings ...)
2018-11-22 11:39 ` [PATCH 13/17] soc: ti: pruss: export pruss_intc_configure/unconfigure APIs Roger Quadros
@ 2018-11-22 11:39 ` Roger Quadros
2018-11-23 16:40 ` Tony Lindgren
2018-11-22 11:39 ` [PATCH 15/17] ARM: dts: AM33xx: Add the PRU-ICSS DT nodes Roger Quadros
` (3 subsequent siblings)
17 siblings, 1 reply; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:39 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
From: Suman Anna <s-anna@ti.com>
The omap_device API is needed to perform the reset management for
any IP instances with PRCM RSTCTRL registers (hard reset lines).
This API is limited to the mach-omap2 layer, and cannot be exposed
to drivers layer directly. So use platform data ops and pdata quirks
for the PRUSS IP in AM335x SoCs to plumb the required omap_device
API. The PRUSS SoC bus driver can then use these pdata ops to
achieve the required reset functionality.
This is being implemented this way as there is no separate reset
driver at the moment.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
arch/arm/mach-omap2/pdata-quirks.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index 9fec5f8..97fc5a2 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -26,6 +26,7 @@
#include <linux/platform_data/hsmmc-omap.h>
#include <linux/platform_data/iommu-omap.h>
#include <linux/platform_data/ti-sysc.h>
+#include <linux/platform_data/ti-pruss.h>
#include <linux/platform_data/wkup_m3.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
@@ -438,6 +439,14 @@ static struct wkup_m3_platform_data wkup_m3_data = {
};
#endif
+#ifdef CONFIG_SOC_AM33XX
+static struct pruss_platform_data pruss_pdata = {
+ .reset_name = "pruss",
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
+#endif
+
#ifdef CONFIG_SOC_OMAP5
static void __init omap5_uevm_legacy_init(void)
{
@@ -580,6 +589,8 @@ static struct of_dev_auxdata omap_auxdata_lookup[] = {
#ifdef CONFIG_SOC_AM33XX
OF_DEV_AUXDATA("ti,am3352-wkup-m3", 0x44d00000, "44d00000.wkup_m3",
&wkup_m3_data),
+ OF_DEV_AUXDATA("ti,am3356-pruss-soc-bus", 0x4a326004,
+ "4a326004.pruss-soc-bus", &pruss_pdata),
#endif
#ifdef CONFIG_SOC_AM43XX
OF_DEV_AUXDATA("ti,am4372-wkup-m3", 0x44d00000, "44d00000.wkup_m3",
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* Re: [PATCH 14/17] ARM: OMAP2+: use pdata quirks for PRUSS reset lines on AM335x
2018-11-22 11:39 ` [PATCH 14/17] ARM: OMAP2+: use pdata quirks for PRUSS reset lines on AM335x Roger Quadros
@ 2018-11-23 16:40 ` Tony Lindgren
0 siblings, 0 replies; 53+ messages in thread
From: Tony Lindgren @ 2018-11-23 16:40 UTC (permalink / raw)
To: Roger Quadros
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
* Roger Quadros <rogerq@ti.com> [181122 11:40]:
> From: Suman Anna <s-anna@ti.com>
>
> The omap_device API is needed to perform the reset management for
> any IP instances with PRCM RSTCTRL registers (hard reset lines).
> This API is limited to the mach-omap2 layer, and cannot be exposed
> to drivers layer directly. So use platform data ops and pdata quirks
> for the PRUSS IP in AM335x SoCs to plumb the required omap_device
> API. The PRUSS SoC bus driver can then use these pdata ops to
> achieve the required reset functionality.
>
> This is being implemented this way as there is no separate reset
> driver at the moment.
If the reset-simple approach has issues we can certainly do
this until the issues are fixed. I believe Suman had an issue
where we need to prevent the related clockdomain from idling.
Regards,
Tony
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 15/17] ARM: dts: AM33xx: Add the PRU-ICSS DT nodes
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
` (13 preceding siblings ...)
2018-11-22 11:39 ` [PATCH 14/17] ARM: OMAP2+: use pdata quirks for PRUSS reset lines on AM335x Roger Quadros
@ 2018-11-22 11:39 ` Roger Quadros
2018-11-26 16:37 ` David Lechner
2018-11-22 11:39 ` [PATCH 16/17] ARM: dts: AM33xx: Add PRU system events for virtio Roger Quadros
` (2 subsequent siblings)
17 siblings, 1 reply; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:39 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
From: Suman Anna <s-anna@ti.com>
Add the DT nodes for the PRU-ICSS on AM33xx family of SoCs. The
AM33xx SoCs contain a single PRU-ICSS instance and is represented
by the pruss-soc-bus node and a child PRUSS node. PRU-ICSS is not
supported on AM3352 SoC though in the AM33xx family, so the nodes
are added in disabled state to the common am33xx dtsi file. They
should be enabled in only those derivative board files that use
a SoC containing PRU-ICSS.
The PRUSS subsystem node contains the entire address space and
the various interrupts generated towards the main MPU. The various
sub-modules of the PRU-ICSS are represented as individual child
nodes (so platform devices themselves) of the PRUSS subsystem node.
These include the two PRU cores and the interrupt controller. The
Industrial Ethernet Peripheral (IEP), the Real Time Media Independent
Interface controller (MII_RT), and the CFG sub-module are represented
as syscon nodes. All the Data RAMs are represented within a child
node of its own named 'memories' without any compatible.
The DT nodes use all standard properties. The regs property in
the PRU nodes define the addresses for the Instruction RAM, the
Debug and Control sub-modules for that PRU core. The firmware for
each PRU core is defined through a 'firmware-name' property.
The default names for the firmware images for each PRU core are
defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
PRU-ICSS PRU0 Core: am335x-pru1_0-fw
PRU-ICSS PRU1 Core: am335x-pru1_1-fw
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/am33xx.dtsi | 72 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index d3dd6a1..ce42cd9 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -924,6 +924,78 @@
};
};
+ pruss_soc_bus: pruss_soc_bus@4a326004 {
+ compatible = "ti,am3356-pruss-soc-bus";
+ reg = <0x4a326004 0x4>;
+ ti,hwmods = "pruss";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ status = "disabled";
+
+ pruss: pruss@4a300000 {
+ compatible = "ti,am3356-pruss";
+ reg = <0x4a300000 0x80000>;
+ interrupts = <20 21 22 23 24 25 26 27>;
+ interrupt-names = "host2", "host3", "host4",
+ "host5", "host6", "host7",
+ "host8", "host9";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ status = "disabled";
+
+ pruss_mem: memories@4a300000 {
+ reg = <0x4a300000 0x2000>,
+ <0x4a302000 0x2000>,
+ <0x4a310000 0x3000>;
+ reg-names = "dram0", "dram1",
+ "shrdram2";
+ };
+
+ 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>;
+ };
+
+ pruss_intc: intc@4a320000 {
+ compatible = "ti,am3356-pruss-intc";
+ reg = <0x4a320000 0x2000>;
+ reg-names = "intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ pru0: pru@4a334000 {
+ compatible = "ti,am3356-pru";
+ reg = <0x4a334000 0x2000>,
+ <0x4a322000 0x400>,
+ <0x4a322400 0x100>;
+ reg-names = "iram", "control", "debug";
+ firmware-name = "am335x-pru0-fw";
+ };
+
+ pru1: pru@4a338000 {
+ compatible = "ti,am3356-pru";
+ reg = <0x4a338000 0x2000>,
+ <0x4a324000 0x400>,
+ <0x4a324400 0x100>;
+ reg-names = "iram", "control", "debug";
+ firmware-name = "am335x-pru1-fw";
+ };
+ };
+ };
+
elm: elm@48080000 {
compatible = "ti,am3352-elm";
reg = <0x48080000 0x2000>;
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* Re: [PATCH 15/17] ARM: dts: AM33xx: Add the PRU-ICSS DT nodes
2018-11-22 11:39 ` [PATCH 15/17] ARM: dts: AM33xx: Add the PRU-ICSS DT nodes Roger Quadros
@ 2018-11-26 16:37 ` David Lechner
0 siblings, 0 replies; 53+ messages in thread
From: David Lechner @ 2018-11-26 16:37 UTC (permalink / raw)
To: Roger Quadros, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
On 11/22/18 5:39 AM, Roger Quadros wrote:
> From: Suman Anna <s-anna@ti.com>
>
> Add the DT nodes for the PRU-ICSS on AM33xx family of SoCs. The
> AM33xx SoCs contain a single PRU-ICSS instance and is represented
> by the pruss-soc-bus node and a child PRUSS node. PRU-ICSS is not
> supported on AM3352 SoC though in the AM33xx family, so the nodes
> are added in disabled state to the common am33xx dtsi file. They
> should be enabled in only those derivative board files that use
> a SoC containing PRU-ICSS.
>
> The PRUSS subsystem node contains the entire address space and
> the various interrupts generated towards the main MPU. The various
> sub-modules of the PRU-ICSS are represented as individual child
> nodes (so platform devices themselves) of the PRUSS subsystem node.
> These include the two PRU cores and the interrupt controller. The
> Industrial Ethernet Peripheral (IEP), the Real Time Media Independent
> Interface controller (MII_RT), and the CFG sub-module are represented
> as syscon nodes. All the Data RAMs are represented within a child
> node of its own named 'memories' without any compatible.
>
> The DT nodes use all standard properties. The regs property in
> the PRU nodes define the addresses for the Instruction RAM, the
> Debug and Control sub-modules for that PRU core. The firmware for
> each PRU core is defined through a 'firmware-name' property.
>
> The default names for the firmware images for each PRU core are
> defined as follows (these can be adjusted either in derivative
> board dts files or through sysfs at runtime if required):
> PRU-ICSS PRU0 Core: am335x-pru1_0-fw
> PRU-ICSS PRU1 Core: am335x-pru1_1-fw
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> arch/arm/boot/dts/am33xx.dtsi | 72 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index d3dd6a1..ce42cd9 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -924,6 +924,78 @@
> };
> };
>
> + pruss_soc_bus: pruss_soc_bus@4a326004 {
> + compatible = "ti,am3356-pruss-soc-bus";
> + reg = <0x4a326004 0x4>;
> + ti,hwmods = "pruss";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + status = "disabled";
> +
> + pruss: pruss@4a300000 {
<snip>
> +
> elm: elm@48080000 {
> compatible = "ti,am3352-elm";
> reg = <0x48080000 0x2000>;
>
This doesn't apply cleanly to next-20181126. elm: elm@48080000 node
is not there. If it was, it seems like the pruss node should be after
instead of before to keep things sorted since 4a300000 > 48080000.
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 16/17] ARM: dts: AM33xx: Add PRU system events for virtio
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
` (14 preceding siblings ...)
2018-11-22 11:39 ` [PATCH 15/17] ARM: dts: AM33xx: Add the PRU-ICSS DT nodes Roger Quadros
@ 2018-11-22 11:39 ` Roger Quadros
2018-11-22 11:39 ` [PATCH 17/17] ARM: dts: am335x-*: Enable PRU-ICSS nodes Roger Quadros
2018-12-03 2:04 ` [PATCH 00/17] Add support for TI PRU ICSS Derald D. Woods
17 siblings, 0 replies; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:39 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
From: Suman Anna <s-anna@ti.com>
Two PRU system events "vring" and "kick" have been added to each
of the PRU nodes in the PRU-ICSS remote processor subsystem to
enable the virtio/rpmsg communication between MPU and that PRU
core. The additions are done in the base am33xx.dtsi file, and
so are inherited by all the AM33xx boards. Do note that PRUSS
is not available on all AM335x SoCs.
The PRU system events is the preferred approach over using OMAP
mailboxes, as it eliminates an external peripheral access from
the PRU-side, and keeps the interrupt generation internal to the
PRUSS. The difference from MPU would be minimal in using one
versus the other.
Mailboxes can still be used if desired. Either approach would
require that an appropriate firmware image is loaded/booted on
the PRU.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index ce42cd9..b7e3f69 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -983,6 +983,9 @@
<0x4a322400 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am335x-pru0-fw";
+ interrupt-parent = <&pruss_intc>;
+ interrupts = <16>, <17>;
+ interrupt-names = "vring", "kick";
};
pru1: pru@4a338000 {
@@ -992,6 +995,9 @@
<0x4a324400 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am335x-pru1-fw";
+ interrupt-parent = <&pruss_intc>;
+ interrupts = <18>, <19>;
+ interrupt-names = "vring", "kick";
};
};
};
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* [PATCH 17/17] ARM: dts: am335x-*: Enable PRU-ICSS nodes
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
` (15 preceding siblings ...)
2018-11-22 11:39 ` [PATCH 16/17] ARM: dts: AM33xx: Add PRU system events for virtio Roger Quadros
@ 2018-11-22 11:39 ` Roger Quadros
2018-11-26 16:45 ` David Lechner
2018-12-03 2:04 ` [PATCH 00/17] Add support for TI PRU ICSS Derald D. Woods
17 siblings, 1 reply; 53+ messages in thread
From: Roger Quadros @ 2018-11-22 11:39 UTC (permalink / raw)
To: tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree, rogerq
From: Suman Anna <s-anna@ti.com>
The PRU-ICSS processor bus node and subsystem nodes were left in
disabled state in the base am33xx.dtsi file. PRU-ICSS is supported
on these AM335x boards so enable the PRUSS node.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 8 ++++++++
arch/arm/boot/dts/am335x-evm.dts | 8 ++++++++
arch/arm/boot/dts/am335x-evmsk.dts | 8 ++++++++
arch/arm/boot/dts/am335x-icev2.dts | 8 ++++++++
4 files changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 9e5e75e..ea0e869 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -422,3 +422,11 @@
clocks = <&clk_32768_ck>, <&l4_per_clkctrl AM3_CLKDIV32K_CLKCTRL 0>;
clock-names = "ext-clk", "int-clk";
};
+
+&pruss_soc_bus {
+ status = "okay";
+
+ pruss: pruss@4a300000 {
+ status = "okay";
+ };
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 98ec9c3..0e07160 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -800,3 +800,11 @@
clocks = <&clk_32768_ck>, <&l4_per_clkctrl AM3_CLKDIV32K_CLKCTRL 0>;
clock-names = "ext-clk", "int-clk";
};
+
+&pruss_soc_bus {
+ status = "okay";
+
+ pruss: pruss@4a300000 {
+ status = "okay";
+ };
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index 245868f..f152c15 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -741,3 +741,11 @@
clocks = <&clk_32768_ck>, <&l4_per_clkctrl AM3_CLKDIV32K_CLKCTRL 0>;
clock-names = "ext-clk", "int-clk";
};
+
+&pruss_soc_bus {
+ status = "okay";
+
+ pruss: pruss@4a300000 {
+ status = "okay";
+ };
+};
diff --git a/arch/arm/boot/dts/am335x-icev2.dts b/arch/arm/boot/dts/am335x-icev2.dts
index f2005ec..7d2fff2e 100644
--- a/arch/arm/boot/dts/am335x-icev2.dts
+++ b/arch/arm/boot/dts/am335x-icev2.dts
@@ -504,3 +504,11 @@
reg = <3>;
};
};
+
+&pruss_soc_bus {
+ status = "okay";
+
+ pruss: pruss@4a300000 {
+ status = "okay";
+ };
+};
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 53+ messages in thread* Re: [PATCH 17/17] ARM: dts: am335x-*: Enable PRU-ICSS nodes
2018-11-22 11:39 ` [PATCH 17/17] ARM: dts: am335x-*: Enable PRU-ICSS nodes Roger Quadros
@ 2018-11-26 16:45 ` David Lechner
0 siblings, 0 replies; 53+ messages in thread
From: David Lechner @ 2018-11-26 16:45 UTC (permalink / raw)
To: Roger Quadros, tony
Cc: robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2,
woods.technical, linux-omap, linux-remoteproc, linux-kernel,
devicetree
On 11/22/18 5:39 AM, Roger Quadros wrote:
> From: Suman Anna <s-anna@ti.com>
>
> The PRU-ICSS processor bus node and subsystem nodes were left in
> disabled state in the base am33xx.dtsi file. PRU-ICSS is supported
> on these AM335x boards so enable the PRUSS node.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
This does not apply cleanly to next-20181126. It looks like you
could be missing "ARM: dts: am33xx: convert to use new clkctrl
layout" from your development branch.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 00/17] Add support for TI PRU ICSS
2018-11-22 11:38 [PATCH 00/17] Add support for TI PRU ICSS Roger Quadros
` (16 preceding siblings ...)
2018-11-22 11:39 ` [PATCH 17/17] ARM: dts: am335x-*: Enable PRU-ICSS nodes Roger Quadros
@ 2018-12-03 2:04 ` Derald D. Woods
17 siblings, 0 replies; 53+ messages in thread
From: Derald D. Woods @ 2018-12-03 2:04 UTC (permalink / raw)
To: Roger Quadros
Cc: tony, robh+dt, bcousson, ssantosh, ohad, bjorn.andersson, s-anna,
nsekhar, t-kristo, nsaulnier, jreeder, m-karicheri2, linux-omap,
linux-remoteproc, linux-kernel, devicetree
On Thu, Nov 22, 2018 at 01:38:56PM +0200, Roger Quadros wrote:
> Hi,
>
> The Programmable Real-Time Unit and Industrial Communication Subsystem
> (PRU-ICSS) is present on various TI SoCs such as AM335x, AM437x, AM57x,
> Keystone 66AK2G, etc. A PRUSS consists of dual 32-bit RISC cores (Programmable
> Real-Time Units, or PRUs), data and instruction RAMs, shard RAM, and
> interrupt controller and some internal peripheral modules to facilitate
> industrial communication. 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 MII_RT module with two MII ports for Ethernet
> - an MDIO port for 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 typical usage scenario would be to load the application firmware into
> one or more of the PRU cores, initialize one or more of the peripherals
> and perform I/O through shared RAM (or MSMC RAM) from either a Kernel driver
> or directly from userspace.
>
> With this two-part series we should be able to use the kernel RPMSG driver
> along with firmware and user-space examples in the
> pru-software-support-package [1].
>
> We will also be able to get Dual Ethernet functionality using a kernel driver
> which will be posted later.
>
> The kernel code will be split into the following sections
>
> 1) soc: pruss_soc_bus: The sole purpose of this driver is to handle platform
> specific Power management quirks and allow the child node (i.e entire PRUSS)
> to be unbound from the default kernel driver and bound to something else. e.g. uio_pruss,
> while allowing to manage PM in the kernel.
>
> 2) soc: pruss: This is the driver for the entire ICSS. Its main purpose is
> to populate the different modules and handle platform specific quirks.
> It will also manage the interrupt controller and provide kernel APIs to
> change ICSS specific knobs in the CFG space e.g. GP_MUX.
>
> 3) remoteproc: pru: This provides a remoteproc interface for the PRU cores.
> With this we can load firmware, start/stop PRU from kernel or userspace.
> It adds support for virtio RPMSG. It also provides some kernel APIs
> (e.g. pru_rproc_set_ctable()) that are PRU specific and required for
> in-kernel applications (e.g. ethernet)
>
> 4) ARM: OMAP: DTS:
> Platform data and device tree files.
>
> Due to the large number of patches patches are split this into 2 email threads.
> This thread covers (1), (3) and (4).
>
> A second thread will cover the remoteproc driver (3).
>
> The series only adds platform support for AM335x to keep patch count small.
> Support for other platforms (AM43x, AM57x, K2G) will be added later.
>
> Testing:
> To test the code with example firmware you can try the LAB5 tutorial
> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_5:_RPMsg_Communication_between_ARM_and_PRU
> with the pru-software-support package at [2] and the sample rpmsg-client driver.
> NOTE: you no longer need to build and run PRU_Halt example as shown in the tutorial.
>
> cheers,
> -roger
>
> [1] https://git.ti.com/pru-software-support-package
> NOTE: The repo needs update to the INTC resource data structures
> The updates that are required are listed in the below repo with one example fixed.
> [2] https://github.com/rogerq/pru-software-support-package/commits/upstream/pruss
>
Per Roger's instructions, I was able test both patch series on the
am335x-pocketbeagle, based on linux v4.20-rc4, with the following
additional 'rpmsg_pru' patches:
https://github.com/beagleboard/linux/commit/2b013313cae8659f2cbd659c314e471a71f1623c
https://github.com/beagleboard/linux/commit/b894d492a35aa43a7b54512b971a04b9aec17814
Tested-by: Derald D. Woods <woods.technical@gmail.com>
> Andrew F. Davis (1):
> soc: ti: pruss: add pruss_{request,release}_mem_region() API
>
> Roger Quadros (2):
> soc: ti: pruss: add pruss_cfg_read()/update() API
> soc: ti: pruss: export pruss_intc_configure/unconfigure APIs
>
> Suman Anna (13):
> dt-bindings: remoteproc: Add TI PRUSS bindings
> soc: ti: pruss: Define platform data for PRUSS bus driver
> soc: ti: pruss: Add pruss_soc_bus platform driver
> soc: ti: pruss: Fix system suspend/MStandby config issues
> soc: ti: pruss: Configure SYSCFG properly during probe/remove
> soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs
> soc: ti: pruss: enable OCP master ports in SYSCFG always
> soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts
> soc: ti: pruss_intc: Add API to trigger a PRU sysevent
> ARM: OMAP2+: use pdata quirks for PRUSS reset lines on AM335x
> ARM: dts: AM33xx: Add the PRU-ICSS DT nodes
> ARM: dts: AM33xx: Add PRU system events for virtio
> ARM: dts: am335x-*: Enable PRU-ICSS nodes
>
> Tero Kristo (1):
> soc: ti: pruss: add pruss_get()/put() API
>
> .../devicetree/bindings/soc/ti/ti,pruss.txt | 360 ++++++++++++
> arch/arm/boot/dts/am335x-bone-common.dtsi | 8 +
> arch/arm/boot/dts/am335x-evm.dts | 8 +
> arch/arm/boot/dts/am335x-evmsk.dts | 8 +
> arch/arm/boot/dts/am335x-icev2.dts | 8 +
> arch/arm/boot/dts/am33xx.dtsi | 78 +++
> arch/arm/mach-omap2/pdata-quirks.c | 11 +
> drivers/soc/ti/Kconfig | 12 +
> drivers/soc/ti/Makefile | 1 +
> drivers/soc/ti/pruss.c | 306 +++++++++++
> drivers/soc/ti/pruss.h | 36 ++
> drivers/soc/ti/pruss_intc.c | 604 +++++++++++++++++++++
> drivers/soc/ti/pruss_soc_bus.c | 279 ++++++++++
> include/linux/platform_data/ti-pruss.h | 25 +
> include/linux/pruss.h | 235 ++++++++
> 15 files changed, 1979 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.txt
> create mode 100644 drivers/soc/ti/pruss.c
> create mode 100644 drivers/soc/ti/pruss.h
> create mode 100644 drivers/soc/ti/pruss_intc.c
> create mode 100644 drivers/soc/ti/pruss_soc_bus.c
> create mode 100644 include/linux/platform_data/ti-pruss.h
> create mode 100644 include/linux/pruss.h
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
^ permalink raw reply [flat|nested] 53+ messages in thread