* [PATCH 01/17] dt-bindings: remoteproc: Add OMAP remoteproc bindings
[not found] <20191028124238.19224-1-t-kristo@ti.com>
@ 2019-10-28 12:42 ` Tero Kristo
2019-11-06 3:27 ` Rob Herring
2019-11-07 14:05 ` [PATCHv2 " Tero Kristo
0 siblings, 2 replies; 7+ messages in thread
From: Tero Kristo @ 2019-10-28 12:42 UTC (permalink / raw)
To: bjorn.andersson, ohad, linux-remoteproc
Cc: linux-kernel, linux-omap, s-anna, Rob Herring, devicetree,
Tero Kristo
From: Suman Anna <s-anna@ti.com>
Add the device tree bindings document for the IPU and DSP
remote processor devices on OMAP4+ SoCs.
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
.../remoteproc/ti,omap-remoteproc.txt | 205 ++++++++++++++++++
1 file changed, 205 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt
new file mode 100644
index 000000000000..e2bcfcab21c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt
@@ -0,0 +1,205 @@
+OMAP4+ Remoteproc Devices
+=========================
+
+The OMAP family of SoCs usually have one or more slave processor sub-systems
+that are used to offload some of the processor-intensive tasks, or to manage
+other hardware accelerators, for achieving various system level goals.
+
+The processor cores in the sub-system are usually behind an IOMMU, and may
+contain additional sub-modules like Internal RAM and/or ROMs, L1 and/or L2
+caches, an Interrupt Controller, a Cache Controller etc.
+
+The OMAP SoCs usually have a DSP processor sub-system and/or an IPU processor
+sub-system. The DSP processor sub-system can contain any of the TI's C64x,
+C66x or C67x family of DSP cores as the main execution unit. The IPU processor
+sub-system usually contains either a Dual-Core Cortex-M3 or Dual-Core Cortex-M4
+processors.
+
+Remote Processor Node:
+======================
+Each remote processor sub-system is represented as a single DT node. Each node
+has a number of required or optional properties that enable the OS running on
+the host processor (MPU) to perform the device management of the remote
+processor and to communicate with the remote processor. The various properties
+can be classified as constant or variable. The constant properties are dictated
+by the SoC and does not change from one board to another having the same SoC.
+Examples of constant properties include 'iommus', 'reg'. The variable properties
+are dictated by the system integration aspects such as memory on the board, or
+configuration used within the corresponding firmware image. Examples of variable
+properties include 'mboxes', 'memory-region', 'timers', 'watchdog-timers' etc.
+
+Required properties:
+--------------------
+The following are the mandatory properties:
+
+- compatible: Should be one of the following,
+ "ti,omap4-dsp" for DSPs on OMAP4 SoCs
+ "ti,omap5-dsp" for DSPs on OMAP5 SoCs
+ "ti,dra7-dsp" for DSPs on DRA7xx/AM57xx SoCs
+ "ti,omap4-ipu" for IPUs on OMAP4 SoCs
+ "ti,omap5-ipu" for IPUs on OMAP5 SoCs
+ "ti,dra7-ipu" for IPUs on DRA7xx/AM57xx SoCs
+
+- iommus: phandles to OMAP IOMMU nodes, that need to be programmed
+ for this remote processor to access any external RAM memory or
+ other peripheral device address spaces. This property usually
+ has only a single phandle. Multiple phandles are used only in
+ cases where the sub-system has different ports for different
+ sub-modules within the processor sub-system (eg: DRA7 DSPs),
+ and need the same programming in both the MMUs.
+
+- mboxes: OMAP Mailbox specifier denoting the sub-mailbox, to be used for
+ communication with the remote processor. The specifier format is
+ as per the bindings,
+ Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
+ This property should match with the sub-mailbox node used in
+ the firmware image.
+
+Optional properties:
+--------------------
+Some of these properties are mandatory on some SoCs, and some are optional
+depending on the configuration of the firmware image to be executed on the
+remote processor. The conditions are mentioned for each property.
+
+The following are the optional properties:
+- reg: Address space for any remoteproc memories present on
+ the SoC. Should contain an entry for each value in
+ 'reg-names'. These are mandatory for all DSP and IPU
+ processors that have them (OMAP4/OMAP5 DSPs do not have
+ any RAMs)
+
+- reg-names: Required names for each of the address spaces defined in
+ the 'reg' property. Should contain a string from among
+ the following names, each representing the corresponding
+ internal RAM memory region,
+ "l2ram" for L2 RAM,
+ "l1pram" for L1 Program RAM Memory/Cache,
+ "l1dram" for L1 Data RAM Memory/Cache,
+
+ All devices may not have all the above memories.
+
+- syscon-bootreg: Should be a pair of the phandle to the System Control
+ Configuration region that contains the boot address
+ register, and the register offset of the boot address
+ register within the System Control module. This property
+ is required for all the DSP instances on OMAP4, OMAP5
+ and DRA7xx SoCs.
+
+- memory-region: phandle to the reserved memory node to be associated
+ with the remoteproc device. The reserved memory node
+ can be a CMA memory node, and should be defined as
+ per the bindings,
+ Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+
+- mbox-names: Optional names for the OMAP mailbox specifiers mentioned
+ in the 'mboxes' property, one per specifier value
+
+- timers: One or more phandles to OMAP DMTimer nodes, that serve
+ as System/Tick timers for the OS running on the remote
+ processors. This will usually be a single timer if the
+ processor sub-system is running in SMP mode, or one per
+ core in the processor sub-system. This can also be used
+ to reserve specific timers to be dedicated to the
+ remote processors.
+
+ This property is mandatory on remote processors requiring
+ external tick wakeup, and to support Power Management
+ features. The timers to be used should match with the
+ timers used in the firmware image.
+
+- watchdog-timers: One or more phandles to OMAP DMTimer nodes, used to
+ serve as Watchdog timers for the processor cores. This
+ will usually be one per executing processor core, even
+ if the processor sub-system is running a SMP OS.
+
+ The timers to be used should match with the watchdog
+ timers used in the firmware image.
+
+Example:
+--------
+
+1. OMAP4 DSP
+ /* DSP Reserved Memory node */
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dsp_memory_region: dsp-memory@98000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x98000000 0x800000>;
+ reusable;
+ };
+ };
+
+ /* DSP node */
+ ocp {
+ dsp: dsp {
+ compatible = "ti,omap4-dsp";
+ syscon-bootreg = <&scm_conf 0x304>;
+ iommus = <&mmu_dsp>;
+ mboxes = <&mailbox &mbox_dsp>;
+ memory-region = <&dsp_memory_region>;
+ timers = <&timer5>;
+ watchdog-timers = <&timer6>;
+ };
+ };
+
+2. OMAP5 IPU
+ /* IPU Reserved Memory node */
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ipu_memory_region: ipu-memory@95800000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x95800000 0 0x3800000>;
+ reusable;
+ };
+ };
+
+ /* IPU node */
+ ocp {
+ ipu: ipu@55020000 {
+ compatible = "ti,omap5-ipu";
+ reg = <0x55020000 0x10000>;
+ reg-names = "l2ram";
+ iommus = <&mmu_ipu>;
+ mboxes = <&mailbox &mbox_ipu>;
+ memory-region = <&ipu_memory_region>;
+ timers = <&timer3>, <&timer4>;
+ watchdog-timers = <&timer9>, <&timer11>;
+ };
+ };
+
+3. DRA7xx/AM57xx DSP
+ /* DSP1 Reserved Memory node */
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ dsp1_memory_region: dsp1-memory@99000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x99000000 0x0 0x4000000>;
+ reusable;
+ };
+ };
+
+ /* DSP1 node */
+ ocp {
+ dsp1: dsp@40800000 {
+ compatible = "ti,dra7-dsp";
+ reg = <0x40800000 0x48000>,
+ <0x40e00000 0x8000>,
+ <0x40f00000 0x8000>;
+ reg-names = "l2ram", "l1pram", "l1dram";
+ syscon-bootreg = <&scm_conf 0x55c>;
+ iommus = <&mmu0_dsp1>, <&mmu1_dsp1>;
+ mboxes = <&mailbox5 &mbox_dsp1_ipc3x>;
+ memory-region = <&dsp1_memory_region>;
+ timers = <&timer5>;
+ watchdog-timers = <&timer10>;
+ };
+ };
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 01/17] dt-bindings: remoteproc: Add OMAP remoteproc bindings
2019-10-28 12:42 ` [PATCH 01/17] dt-bindings: remoteproc: Add OMAP remoteproc bindings Tero Kristo
@ 2019-11-06 3:27 ` Rob Herring
2019-11-06 12:44 ` Tero Kristo
2019-11-07 14:05 ` [PATCHv2 " Tero Kristo
1 sibling, 1 reply; 7+ messages in thread
From: Rob Herring @ 2019-11-06 3:27 UTC (permalink / raw)
To: Tero Kristo
Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-omap,
s-anna, devicetree
On Mon, Oct 28, 2019 at 02:42:22PM +0200, Tero Kristo wrote:
> From: Suman Anna <s-anna@ti.com>
>
> Add the device tree bindings document for the IPU and DSP
> remote processor devices on OMAP4+ SoCs.
>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> .../remoteproc/ti,omap-remoteproc.txt | 205 ++++++++++++++++++
> 1 file changed, 205 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt
>
Looks to be in pretty good shape, but how about doing a schema.
> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt
> new file mode 100644
> index 000000000000..e2bcfcab21c1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt
> @@ -0,0 +1,205 @@
> +OMAP4+ Remoteproc Devices
> +=========================
> +
> +The OMAP family of SoCs usually have one or more slave processor sub-systems
> +that are used to offload some of the processor-intensive tasks, or to manage
> +other hardware accelerators, for achieving various system level goals.
> +
> +The processor cores in the sub-system are usually behind an IOMMU, and may
> +contain additional sub-modules like Internal RAM and/or ROMs, L1 and/or L2
> +caches, an Interrupt Controller, a Cache Controller etc.
> +
> +The OMAP SoCs usually have a DSP processor sub-system and/or an IPU processor
> +sub-system. The DSP processor sub-system can contain any of the TI's C64x,
> +C66x or C67x family of DSP cores as the main execution unit. The IPU processor
> +sub-system usually contains either a Dual-Core Cortex-M3 or Dual-Core Cortex-M4
> +processors.
> +
> +Remote Processor Node:
> +======================
> +Each remote processor sub-system is represented as a single DT node. Each node
> +has a number of required or optional properties that enable the OS running on
> +the host processor (MPU) to perform the device management of the remote
> +processor and to communicate with the remote processor. The various properties
> +can be classified as constant or variable. The constant properties are dictated
> +by the SoC and does not change from one board to another having the same SoC.
> +Examples of constant properties include 'iommus', 'reg'. The variable properties
> +are dictated by the system integration aspects such as memory on the board, or
> +configuration used within the corresponding firmware image. Examples of variable
> +properties include 'mboxes', 'memory-region', 'timers', 'watchdog-timers' etc.
> +
> +Required properties:
> +--------------------
> +The following are the mandatory properties:
> +
> +- compatible: Should be one of the following,
> + "ti,omap4-dsp" for DSPs on OMAP4 SoCs
> + "ti,omap5-dsp" for DSPs on OMAP5 SoCs
> + "ti,dra7-dsp" for DSPs on DRA7xx/AM57xx SoCs
> + "ti,omap4-ipu" for IPUs on OMAP4 SoCs
> + "ti,omap5-ipu" for IPUs on OMAP5 SoCs
> + "ti,dra7-ipu" for IPUs on DRA7xx/AM57xx SoCs
> +
> +- iommus: phandles to OMAP IOMMU nodes, that need to be programmed
> + for this remote processor to access any external RAM memory or
> + other peripheral device address spaces. This property usually
> + has only a single phandle. Multiple phandles are used only in
> + cases where the sub-system has different ports for different
> + sub-modules within the processor sub-system (eg: DRA7 DSPs),
> + and need the same programming in both the MMUs.
> +
> +- mboxes: OMAP Mailbox specifier denoting the sub-mailbox, to be used for
> + communication with the remote processor. The specifier format is
> + as per the bindings,
> + Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
> + This property should match with the sub-mailbox node used in
> + the firmware image.
> +
> +Optional properties:
> +--------------------
> +Some of these properties are mandatory on some SoCs, and some are optional
> +depending on the configuration of the firmware image to be executed on the
> +remote processor. The conditions are mentioned for each property.
> +
> +The following are the optional properties:
> +- reg: Address space for any remoteproc memories present on
> + the SoC. Should contain an entry for each value in
> + 'reg-names'. These are mandatory for all DSP and IPU
> + processors that have them (OMAP4/OMAP5 DSPs do not have
> + any RAMs)
> +
> +- reg-names: Required names for each of the address spaces defined in
> + the 'reg' property. Should contain a string from among
> + the following names, each representing the corresponding
> + internal RAM memory region,
> + "l2ram" for L2 RAM,
> + "l1pram" for L1 Program RAM Memory/Cache,
> + "l1dram" for L1 Data RAM Memory/Cache,
> +
> + All devices may not have all the above memories.
> +
> +- syscon-bootreg: Should be a pair of the phandle to the System Control
ti,bootreg
> + Configuration region that contains the boot address
> + register, and the register offset of the boot address
> + register within the System Control module. This property
> + is required for all the DSP instances on OMAP4, OMAP5
> + and DRA7xx SoCs.
> +
> +- memory-region: phandle to the reserved memory node to be associated
> + with the remoteproc device. The reserved memory node
> + can be a CMA memory node, and should be defined as
> + per the bindings,
> + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> +
> +- mbox-names: Optional names for the OMAP mailbox specifiers mentioned
> + in the 'mboxes' property, one per specifier value
From the mboxes description, seemed like only one entry?
Need to define the values here.
> +
> +- timers: One or more phandles to OMAP DMTimer nodes, that serve
> + as System/Tick timers for the OS running on the remote
> + processors. This will usually be a single timer if the
> + processor sub-system is running in SMP mode, or one per
> + core in the processor sub-system. This can also be used
> + to reserve specific timers to be dedicated to the
> + remote processors.
> +
> + This property is mandatory on remote processors requiring
> + external tick wakeup, and to support Power Management
> + features. The timers to be used should match with the
> + timers used in the firmware image.
> +
> +- watchdog-timers: One or more phandles to OMAP DMTimer nodes, used to
> + serve as Watchdog timers for the processor cores. This
> + will usually be one per executing processor core, even
> + if the processor sub-system is running a SMP OS.
> +
> + The timers to be used should match with the watchdog
> + timers used in the firmware image.
These 2 are not standard names. Either need 'ti,' prefix or we should
standardize them. There's been some discussion of an input capture
binding and I was wondering if it should be more general to any
timer function.
> +
> +Example:
> +--------
> +
> +1. OMAP4 DSP
> + /* DSP Reserved Memory node */
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + dsp_memory_region: dsp-memory@98000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x98000000 0x800000>;
> + reusable;
> + };
> + };
> +
> + /* DSP node */
> + ocp {
> + dsp: dsp {
> + compatible = "ti,omap4-dsp";
> + syscon-bootreg = <&scm_conf 0x304>;
> + iommus = <&mmu_dsp>;
> + mboxes = <&mailbox &mbox_dsp>;
> + memory-region = <&dsp_memory_region>;
> + timers = <&timer5>;
> + watchdog-timers = <&timer6>;
> + };
> + };
> +
> +2. OMAP5 IPU
> + /* IPU Reserved Memory node */
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + ipu_memory_region: ipu-memory@95800000 {
> + compatible = "shared-dma-pool";
> + reg = <0 0x95800000 0 0x3800000>;
> + reusable;
> + };
> + };
> +
> + /* IPU node */
> + ocp {
> + ipu: ipu@55020000 {
> + compatible = "ti,omap5-ipu";
> + reg = <0x55020000 0x10000>;
> + reg-names = "l2ram";
> + iommus = <&mmu_ipu>;
> + mboxes = <&mailbox &mbox_ipu>;
> + memory-region = <&ipu_memory_region>;
> + timers = <&timer3>, <&timer4>;
> + watchdog-timers = <&timer9>, <&timer11>;
> + };
> + };
> +
> +3. DRA7xx/AM57xx DSP
> + /* DSP1 Reserved Memory node */
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + dsp1_memory_region: dsp1-memory@99000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x0 0x99000000 0x0 0x4000000>;
> + reusable;
> + };
> + };
> +
> + /* DSP1 node */
> + ocp {
> + dsp1: dsp@40800000 {
> + compatible = "ti,dra7-dsp";
> + reg = <0x40800000 0x48000>,
> + <0x40e00000 0x8000>,
> + <0x40f00000 0x8000>;
> + reg-names = "l2ram", "l1pram", "l1dram";
> + syscon-bootreg = <&scm_conf 0x55c>;
> + iommus = <&mmu0_dsp1>, <&mmu1_dsp1>;
> + mboxes = <&mailbox5 &mbox_dsp1_ipc3x>;
> + memory-region = <&dsp1_memory_region>;
> + timers = <&timer5>;
> + watchdog-timers = <&timer10>;
> + };
> + };
> --
> 2.17.1
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 01/17] dt-bindings: remoteproc: Add OMAP remoteproc bindings
2019-11-06 3:27 ` Rob Herring
@ 2019-11-06 12:44 ` Tero Kristo
2019-11-06 13:27 ` Rob Herring
0 siblings, 1 reply; 7+ messages in thread
From: Tero Kristo @ 2019-11-06 12:44 UTC (permalink / raw)
To: Rob Herring
Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-omap,
s-anna, devicetree
On 06/11/2019 05:27, Rob Herring wrote:
> On Mon, Oct 28, 2019 at 02:42:22PM +0200, Tero Kristo wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> Add the device tree bindings document for the IPU and DSP
>> remote processor devices on OMAP4+ SoCs.
>>
>> Cc: Rob Herring <robh@kernel.org>
>> Cc: devicetree@vger.kernel.org
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>> .../remoteproc/ti,omap-remoteproc.txt | 205 ++++++++++++++++++
>> 1 file changed, 205 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt
>>
>
> Looks to be in pretty good shape, but how about doing a schema.
iommu / mailbox is not in schema format, can I just convert this one to
schema without considering those? If yes, I can go ahead and do it.
>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt
>> new file mode 100644
>> index 000000000000..e2bcfcab21c1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt
>> @@ -0,0 +1,205 @@
>> +OMAP4+ Remoteproc Devices
>> +=========================
>> +
>> +The OMAP family of SoCs usually have one or more slave processor sub-systems
>> +that are used to offload some of the processor-intensive tasks, or to manage
>> +other hardware accelerators, for achieving various system level goals.
>> +
>> +The processor cores in the sub-system are usually behind an IOMMU, and may
>> +contain additional sub-modules like Internal RAM and/or ROMs, L1 and/or L2
>> +caches, an Interrupt Controller, a Cache Controller etc.
>> +
>> +The OMAP SoCs usually have a DSP processor sub-system and/or an IPU processor
>> +sub-system. The DSP processor sub-system can contain any of the TI's C64x,
>> +C66x or C67x family of DSP cores as the main execution unit. The IPU processor
>> +sub-system usually contains either a Dual-Core Cortex-M3 or Dual-Core Cortex-M4
>> +processors.
>> +
>> +Remote Processor Node:
>> +======================
>> +Each remote processor sub-system is represented as a single DT node. Each node
>> +has a number of required or optional properties that enable the OS running on
>> +the host processor (MPU) to perform the device management of the remote
>> +processor and to communicate with the remote processor. The various properties
>> +can be classified as constant or variable. The constant properties are dictated
>> +by the SoC and does not change from one board to another having the same SoC.
>> +Examples of constant properties include 'iommus', 'reg'. The variable properties
>> +are dictated by the system integration aspects such as memory on the board, or
>> +configuration used within the corresponding firmware image. Examples of variable
>> +properties include 'mboxes', 'memory-region', 'timers', 'watchdog-timers' etc.
>> +
>> +Required properties:
>> +--------------------
>> +The following are the mandatory properties:
>> +
>> +- compatible: Should be one of the following,
>> + "ti,omap4-dsp" for DSPs on OMAP4 SoCs
>> + "ti,omap5-dsp" for DSPs on OMAP5 SoCs
>> + "ti,dra7-dsp" for DSPs on DRA7xx/AM57xx SoCs
>> + "ti,omap4-ipu" for IPUs on OMAP4 SoCs
>> + "ti,omap5-ipu" for IPUs on OMAP5 SoCs
>> + "ti,dra7-ipu" for IPUs on DRA7xx/AM57xx SoCs
>> +
>> +- iommus: phandles to OMAP IOMMU nodes, that need to be programmed
>> + for this remote processor to access any external RAM memory or
>> + other peripheral device address spaces. This property usually
>> + has only a single phandle. Multiple phandles are used only in
>> + cases where the sub-system has different ports for different
>> + sub-modules within the processor sub-system (eg: DRA7 DSPs),
>> + and need the same programming in both the MMUs.
^ the target of this is not in schema.
>> +
>> +- mboxes: OMAP Mailbox specifier denoting the sub-mailbox, to be used for
>> + communication with the remote processor. The specifier format is
>> + as per the bindings,
>> + Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
>> + This property should match with the sub-mailbox node used in
>> + the firmware image.
^ Neither this one.
>> +
>> +Optional properties:
>> +--------------------
>> +Some of these properties are mandatory on some SoCs, and some are optional
>> +depending on the configuration of the firmware image to be executed on the
>> +remote processor. The conditions are mentioned for each property.
>> +
>> +The following are the optional properties:
>> +- reg: Address space for any remoteproc memories present on
>> + the SoC. Should contain an entry for each value in
>> + 'reg-names'. These are mandatory for all DSP and IPU
>> + processors that have them (OMAP4/OMAP5 DSPs do not have
>> + any RAMs)
>> +
>> +- reg-names: Required names for each of the address spaces defined in
>> + the 'reg' property. Should contain a string from among
>> + the following names, each representing the corresponding
>> + internal RAM memory region,
>> + "l2ram" for L2 RAM,
>> + "l1pram" for L1 Program RAM Memory/Cache,
>> + "l1dram" for L1 Data RAM Memory/Cache,
>> +
>> + All devices may not have all the above memories.
>> +
>> +- syscon-bootreg: Should be a pair of the phandle to the System Control
>
> ti,bootreg
This one I can fix.
>
>> + Configuration region that contains the boot address
>> + register, and the register offset of the boot address
>> + register within the System Control module. This property
>> + is required for all the DSP instances on OMAP4, OMAP5
>> + and DRA7xx SoCs.
>> +
>> +- memory-region: phandle to the reserved memory node to be associated
>> + with the remoteproc device. The reserved memory node
>> + can be a CMA memory node, and should be defined as
>> + per the bindings,
>> + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>> +
>> +- mbox-names: Optional names for the OMAP mailbox specifiers mentioned
>> + in the 'mboxes' property, one per specifier value
>
> From the mboxes description, seemed like only one entry?
>
> Need to define the values here.
I think I can just ditch this. The current driver doesn't care about the
name at all. It is not used in any of the examples / current DT data either.
>
>> +
>> +- timers: One or more phandles to OMAP DMTimer nodes, that serve
>> + as System/Tick timers for the OS running on the remote
>> + processors. This will usually be a single timer if the
>> + processor sub-system is running in SMP mode, or one per
>> + core in the processor sub-system. This can also be used
>> + to reserve specific timers to be dedicated to the
>> + remote processors.
>> +
>> + This property is mandatory on remote processors requiring
>> + external tick wakeup, and to support Power Management
>> + features. The timers to be used should match with the
>> + timers used in the firmware image.
>> +
>> +- watchdog-timers: One or more phandles to OMAP DMTimer nodes, used to
>> + serve as Watchdog timers for the processor cores. This
>> + will usually be one per executing processor core, even
>> + if the processor sub-system is running a SMP OS.
>> +
>> + The timers to be used should match with the watchdog
>> + timers used in the firmware image.
>
> These 2 are not standard names. Either need 'ti,' prefix or we should
> standardize them. There's been some discussion of an input capture
> binding and I was wondering if it should be more general to any
> timer function.
I'll convert these to ti,xyz for now.
-Tero
>
>> +
>> +Example:
>> +--------
>> +
>> +1. OMAP4 DSP
>> + /* DSP Reserved Memory node */
>> + reserved-memory {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>> + dsp_memory_region: dsp-memory@98000000 {
>> + compatible = "shared-dma-pool";
>> + reg = <0x98000000 0x800000>;
>> + reusable;
>> + };
>> + };
>> +
>> + /* DSP node */
>> + ocp {
>> + dsp: dsp {
>> + compatible = "ti,omap4-dsp";
>> + syscon-bootreg = <&scm_conf 0x304>;
>> + iommus = <&mmu_dsp>;
>> + mboxes = <&mailbox &mbox_dsp>;
>> + memory-region = <&dsp_memory_region>;
>> + timers = <&timer5>;
>> + watchdog-timers = <&timer6>;
>> + };
>> + };
>> +
>> +2. OMAP5 IPU
>> + /* IPU Reserved Memory node */
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + ipu_memory_region: ipu-memory@95800000 {
>> + compatible = "shared-dma-pool";
>> + reg = <0 0x95800000 0 0x3800000>;
>> + reusable;
>> + };
>> + };
>> +
>> + /* IPU node */
>> + ocp {
>> + ipu: ipu@55020000 {
>> + compatible = "ti,omap5-ipu";
>> + reg = <0x55020000 0x10000>;
>> + reg-names = "l2ram";
>> + iommus = <&mmu_ipu>;
>> + mboxes = <&mailbox &mbox_ipu>;
>> + memory-region = <&ipu_memory_region>;
>> + timers = <&timer3>, <&timer4>;
>> + watchdog-timers = <&timer9>, <&timer11>;
>> + };
>> + };
>> +
>> +3. DRA7xx/AM57xx DSP
>> + /* DSP1 Reserved Memory node */
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + dsp1_memory_region: dsp1-memory@99000000 {
>> + compatible = "shared-dma-pool";
>> + reg = <0x0 0x99000000 0x0 0x4000000>;
>> + reusable;
>> + };
>> + };
>> +
>> + /* DSP1 node */
>> + ocp {
>> + dsp1: dsp@40800000 {
>> + compatible = "ti,dra7-dsp";
>> + reg = <0x40800000 0x48000>,
>> + <0x40e00000 0x8000>,
>> + <0x40f00000 0x8000>;
>> + reg-names = "l2ram", "l1pram", "l1dram";
>> + syscon-bootreg = <&scm_conf 0x55c>;
>> + iommus = <&mmu0_dsp1>, <&mmu1_dsp1>;
>> + mboxes = <&mailbox5 &mbox_dsp1_ipc3x>;
>> + memory-region = <&dsp1_memory_region>;
>> + timers = <&timer5>;
>> + watchdog-timers = <&timer10>;
>> + };
>> + };
>> --
>> 2.17.1
>>
>> --
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 01/17] dt-bindings: remoteproc: Add OMAP remoteproc bindings
2019-11-06 12:44 ` Tero Kristo
@ 2019-11-06 13:27 ` Rob Herring
2019-11-06 13:50 ` Tero Kristo
0 siblings, 1 reply; 7+ messages in thread
From: Rob Herring @ 2019-11-06 13:27 UTC (permalink / raw)
To: Tero Kristo
Cc: Bjorn Andersson, Ohad Ben-Cohen,
open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM,
linux-kernel@vger.kernel.org, linux-omap, Suman Anna, devicetree
On Wed, Nov 6, 2019 at 6:44 AM Tero Kristo <t-kristo@ti.com> wrote:
>
> On 06/11/2019 05:27, Rob Herring wrote:
> > On Mon, Oct 28, 2019 at 02:42:22PM +0200, Tero Kristo wrote:
> >> From: Suman Anna <s-anna@ti.com>
> >>
> >> Add the device tree bindings document for the IPU and DSP
> >> remote processor devices on OMAP4+ SoCs.
> >>
> >> Cc: Rob Herring <robh@kernel.org>
> >> Cc: devicetree@vger.kernel.org
> >> Signed-off-by: Suman Anna <s-anna@ti.com>
> >> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> >> ---
> >> .../remoteproc/ti,omap-remoteproc.txt | 205 ++++++++++++++++++
> >> 1 file changed, 205 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt
> >>
> >
> > Looks to be in pretty good shape, but how about doing a schema.
>
> iommu / mailbox is not in schema format, can I just convert this one to
> schema without considering those? If yes, I can go ahead and do it.
The client side both have schema (in dt-schema repo).
> >> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt
> >> new file mode 100644
> >> index 000000000000..e2bcfcab21c1
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt
> >> @@ -0,0 +1,205 @@
> >> +OMAP4+ Remoteproc Devices
> >> +=========================
> >> +
> >> +The OMAP family of SoCs usually have one or more slave processor sub-systems
> >> +that are used to offload some of the processor-intensive tasks, or to manage
> >> +other hardware accelerators, for achieving various system level goals.
> >> +
> >> +The processor cores in the sub-system are usually behind an IOMMU, and may
> >> +contain additional sub-modules like Internal RAM and/or ROMs, L1 and/or L2
> >> +caches, an Interrupt Controller, a Cache Controller etc.
> >> +
> >> +The OMAP SoCs usually have a DSP processor sub-system and/or an IPU processor
> >> +sub-system. The DSP processor sub-system can contain any of the TI's C64x,
> >> +C66x or C67x family of DSP cores as the main execution unit. The IPU processor
> >> +sub-system usually contains either a Dual-Core Cortex-M3 or Dual-Core Cortex-M4
> >> +processors.
> >> +
> >> +Remote Processor Node:
> >> +======================
> >> +Each remote processor sub-system is represented as a single DT node. Each node
> >> +has a number of required or optional properties that enable the OS running on
> >> +the host processor (MPU) to perform the device management of the remote
> >> +processor and to communicate with the remote processor. The various properties
> >> +can be classified as constant or variable. The constant properties are dictated
> >> +by the SoC and does not change from one board to another having the same SoC.
> >> +Examples of constant properties include 'iommus', 'reg'. The variable properties
> >> +are dictated by the system integration aspects such as memory on the board, or
> >> +configuration used within the corresponding firmware image. Examples of variable
> >> +properties include 'mboxes', 'memory-region', 'timers', 'watchdog-timers' etc.
> >> +
> >> +Required properties:
> >> +--------------------
> >> +The following are the mandatory properties:
> >> +
> >> +- compatible: Should be one of the following,
> >> + "ti,omap4-dsp" for DSPs on OMAP4 SoCs
> >> + "ti,omap5-dsp" for DSPs on OMAP5 SoCs
> >> + "ti,dra7-dsp" for DSPs on DRA7xx/AM57xx SoCs
> >> + "ti,omap4-ipu" for IPUs on OMAP4 SoCs
> >> + "ti,omap5-ipu" for IPUs on OMAP5 SoCs
> >> + "ti,dra7-ipu" for IPUs on DRA7xx/AM57xx SoCs
> >> +
> >> +- iommus: phandles to OMAP IOMMU nodes, that need to be programmed
> >> + for this remote processor to access any external RAM memory or
> >> + other peripheral device address spaces. This property usually
> >> + has only a single phandle. Multiple phandles are used only in
> >> + cases where the sub-system has different ports for different
> >> + sub-modules within the processor sub-system (eg: DRA7 DSPs),
> >> + and need the same programming in both the MMUs.
>
> ^ the target of this is not in schema.
You mean the OMAP IOMMU binding? That doesn't matter at all.
Rob
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 01/17] dt-bindings: remoteproc: Add OMAP remoteproc bindings
2019-11-06 13:27 ` Rob Herring
@ 2019-11-06 13:50 ` Tero Kristo
0 siblings, 0 replies; 7+ messages in thread
From: Tero Kristo @ 2019-11-06 13:50 UTC (permalink / raw)
To: Rob Herring
Cc: Bjorn Andersson, Ohad Ben-Cohen,
open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM,
linux-kernel@vger.kernel.org, linux-omap, Suman Anna, devicetree
On 06/11/2019 15:27, Rob Herring wrote:
> On Wed, Nov 6, 2019 at 6:44 AM Tero Kristo <t-kristo@ti.com> wrote:
>>
>> On 06/11/2019 05:27, Rob Herring wrote:
>>> On Mon, Oct 28, 2019 at 02:42:22PM +0200, Tero Kristo wrote:
>>>> From: Suman Anna <s-anna@ti.com>
>>>>
>>>> Add the device tree bindings document for the IPU and DSP
>>>> remote processor devices on OMAP4+ SoCs.
>>>>
>>>> Cc: Rob Herring <robh@kernel.org>
>>>> Cc: devicetree@vger.kernel.org
>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>> ---
>>>> .../remoteproc/ti,omap-remoteproc.txt | 205 ++++++++++++++++++
>>>> 1 file changed, 205 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt
>>>>
>>>
>>> Looks to be in pretty good shape, but how about doing a schema.
>>
>> iommu / mailbox is not in schema format, can I just convert this one to
>> schema without considering those? If yes, I can go ahead and do it.
>
> The client side both have schema (in dt-schema repo).
>
>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt
>>>> new file mode 100644
>>>> index 000000000000..e2bcfcab21c1
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.txt
>>>> @@ -0,0 +1,205 @@
>>>> +OMAP4+ Remoteproc Devices
>>>> +=========================
>>>> +
>>>> +The OMAP family of SoCs usually have one or more slave processor sub-systems
>>>> +that are used to offload some of the processor-intensive tasks, or to manage
>>>> +other hardware accelerators, for achieving various system level goals.
>>>> +
>>>> +The processor cores in the sub-system are usually behind an IOMMU, and may
>>>> +contain additional sub-modules like Internal RAM and/or ROMs, L1 and/or L2
>>>> +caches, an Interrupt Controller, a Cache Controller etc.
>>>> +
>>>> +The OMAP SoCs usually have a DSP processor sub-system and/or an IPU processor
>>>> +sub-system. The DSP processor sub-system can contain any of the TI's C64x,
>>>> +C66x or C67x family of DSP cores as the main execution unit. The IPU processor
>>>> +sub-system usually contains either a Dual-Core Cortex-M3 or Dual-Core Cortex-M4
>>>> +processors.
>>>> +
>>>> +Remote Processor Node:
>>>> +======================
>>>> +Each remote processor sub-system is represented as a single DT node. Each node
>>>> +has a number of required or optional properties that enable the OS running on
>>>> +the host processor (MPU) to perform the device management of the remote
>>>> +processor and to communicate with the remote processor. The various properties
>>>> +can be classified as constant or variable. The constant properties are dictated
>>>> +by the SoC and does not change from one board to another having the same SoC.
>>>> +Examples of constant properties include 'iommus', 'reg'. The variable properties
>>>> +are dictated by the system integration aspects such as memory on the board, or
>>>> +configuration used within the corresponding firmware image. Examples of variable
>>>> +properties include 'mboxes', 'memory-region', 'timers', 'watchdog-timers' etc.
>>>> +
>>>> +Required properties:
>>>> +--------------------
>>>> +The following are the mandatory properties:
>>>> +
>>>> +- compatible: Should be one of the following,
>>>> + "ti,omap4-dsp" for DSPs on OMAP4 SoCs
>>>> + "ti,omap5-dsp" for DSPs on OMAP5 SoCs
>>>> + "ti,dra7-dsp" for DSPs on DRA7xx/AM57xx SoCs
>>>> + "ti,omap4-ipu" for IPUs on OMAP4 SoCs
>>>> + "ti,omap5-ipu" for IPUs on OMAP5 SoCs
>>>> + "ti,dra7-ipu" for IPUs on DRA7xx/AM57xx SoCs
>>>> +
>>>> +- iommus: phandles to OMAP IOMMU nodes, that need to be programmed
>>>> + for this remote processor to access any external RAM memory or
>>>> + other peripheral device address spaces. This property usually
>>>> + has only a single phandle. Multiple phandles are used only in
>>>> + cases where the sub-system has different ports for different
>>>> + sub-modules within the processor sub-system (eg: DRA7 DSPs),
>>>> + and need the same programming in both the MMUs.
>>
>> ^ the target of this is not in schema.
>
> You mean the OMAP IOMMU binding? That doesn't matter at all.
Yeah, OMAP IOMMU.
Ok, if it does not matter, I will just convert this all. Will send v2
once I am done.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCHv2 01/17] dt-bindings: remoteproc: Add OMAP remoteproc bindings
2019-10-28 12:42 ` [PATCH 01/17] dt-bindings: remoteproc: Add OMAP remoteproc bindings Tero Kristo
2019-11-06 3:27 ` Rob Herring
@ 2019-11-07 14:05 ` Tero Kristo
2019-11-13 14:25 ` Rob Herring
1 sibling, 1 reply; 7+ messages in thread
From: Tero Kristo @ 2019-11-07 14:05 UTC (permalink / raw)
To: bjorn.andersson, ohad, linux-remoteproc, robh+dt
Cc: linux-kernel, linux-omap, s-anna, devicetree
From: Suman Anna <s-anna@ti.com>
Add the device tree bindings document for the IPU and DSP
remote processor devices on OMAP4+ SoCs.
Signed-off-by: Suman Anna <s-anna@ti.com>
[t-kristo@ti.com: converted to schema]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
.../remoteproc/ti,omap-remoteproc.yaml | 250 ++++++++++++++++++
1 file changed, 250 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
new file mode 100644
index 000000000000..901ccf1024c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
@@ -0,0 +1,249 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,omap-remoteproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OMAP4+ Remoteproc Devices
+
+maintainers:
+ - Suman Anna <s-anna@ti.com>
+
+description:
+ The OMAP family of SoCs usually have one or more slave processor sub-systems
+ that are used to offload some of the processor-intensive tasks, or to manage
+ other hardware accelerators, for achieving various system level goals.
+
+ The processor cores in the sub-system are usually behind an IOMMU, and may
+ contain additional sub-modules like Internal RAM and/or ROMs, L1 and/or L2
+ caches, an Interrupt Controller, a Cache Controller etc.
+
+ The OMAP SoCs usually have a DSP processor sub-system and/or an IPU processor
+ sub-system. The DSP processor sub-system can contain any of the TI's C64x,
+ C66x or C67x family of DSP cores as the main execution unit. The IPU processor
+ sub-system usually contains either a Dual-Core Cortex-M3 or Dual-Core
+ Cortex-M4 processors.
+
+ Each remote processor sub-system is represented as a single DT node. Each node
+ has a number of required or optional properties that enable the OS running on
+ the host processor (MPU) to perform the device management of the remote
+ processor and to communicate with the remote processor. The various properties
+ can be classified as constant or variable. The constant properties are
+ dictated by the SoC and does not change from one board to another having the
+ same SoC. Examples of constant properties include 'iommus', 'reg'. The
+ variable properties are dictated by the system integration aspects such as
+ memory on the board, or configuration used within the corresponding firmware
+ image. Examples of variable properties include 'mboxes', 'memory-region',
+ 'timers', 'watchdog-timers' etc.
+
+properties:
+ compatible:
+ enum:
+ - ti,omap4-dsp
+ - ti,omap5-dsp
+ - ti,dra7-dsp
+ - ti,omap4-ipu
+ - ti,omap5-ipu
+ - ti,dra7-ipu
+
+ iommus:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ phandles to OMAP IOMMU nodes, that need to be programmed
+ for this remote processor to access any external RAM memory or
+ other peripheral device address spaces. This property usually
+ has only a single phandle. Multiple phandles are used only in
+ cases where the sub-system has different ports for different
+ sub-modules within the processor sub-system (eg: DRA7 DSPs),
+ and need the same programming in both the MMUs.
+
+ mboxes:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ OMAP Mailbox specifier denoting the sub-mailbox, to be used for
+ communication with the remote processor. The specifier format is
+ as per the bindings,
+ Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
+ This property should match with the sub-mailbox node used in
+ the firmware image.
+
+# Optional properties:
+# --------------------
+# Some of these properties are mandatory on some SoCs, and some are optional
+# depending on the configuration of the firmware image to be executed on the
+# remote processor. The conditions are mentioned for each property.
+#
+# The following are the optional properties:
+
+ reg:
+ minItems: 1
+ maxItems: 3
+ description: |
+ Address space for any remoteproc memories present on
+ the SoC. Should contain an entry for each value in
+ 'reg-names'. These are mandatory for all DSP and IPU
+ processors that have them (OMAP4/OMAP5 DSPs do not have
+ any RAMs)
+
+ reg-names:
+ description: |
+ Required names for each of the address spaces defined in
+ the 'reg' property. Should contain a string from among
+ the following names, each representing the corresponding
+ internal RAM memory region.
+ minItems: 1
+ maxItems: 3
+ items:
+ - const: l2ram
+ - const: l1pram
+ - const: l1dram
+
+ ti,bootreg:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ Should be a pair of the phandle to the System Control
+ Configuration region that contains the boot address
+ register, and the register offset of the boot address
+ register within the System Control module. This property
+ is required for all the DSP instances on OMAP4, OMAP5
+ and DRA7xx SoCs.
+
+ memory-region:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: |
+ phandle to the reserved memory node to be associated
+ with the remoteproc device. The reserved memory node
+ can be a CMA memory node, and should be defined as
+ per the bindings,
+ Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+
+ ti,timers:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ One or more phandles to OMAP DMTimer nodes, that serve
+ as System/Tick timers for the OS running on the remote
+ processors. This will usually be a single timer if the
+ processor sub-system is running in SMP mode, or one per
+ core in the processor sub-system. This can also be used
+ to reserve specific timers to be dedicated to the
+ remote processors.
+
+ This property is mandatory on remote processors requiring
+ external tick wakeup, and to support Power Management
+ features. The timers to be used should match with the
+ timers used in the firmware image.
+
+ ti,watchdog-timers:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ One or more phandles to OMAP DMTimer nodes, used to
+ serve as Watchdog timers for the processor cores. This
+ will usually be one per executing processor core, even
+ if the processor sub-system is running a SMP OS.
+
+ The timers to be used should match with the watchdog
+ timers used in the firmware image.
+
+required:
+ - compatible
+ - iommus
+ - mboxes
+
+examples:
+ - |
+
+ //Example 1: OMAP4 DSP
+
+ /* DSP Reserved Memory node */
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ dsp_memory_region: dsp-memory@98000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x98000000 0x800000>;
+ reusable;
+ };
+ };
+
+ /* DSP node */
+ ocp {
+ dsp: dsp {
+ compatible = "ti,omap4-dsp";
+ ti,bootreg = <&scm_conf 0x304>;
+ iommus = <&mmu_dsp>;
+ mboxes = <&mailbox &mbox_dsp>;
+ memory-region = <&dsp_memory_region>;
+ ti,timers = <&timer5>;
+ ti,watchdog-timers = <&timer6>;
+ };
+ };
+
+ - |+
+
+ //Example 2: OMAP5 IPU
+
+ /* IPU Reserved Memory node */
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ipu_memory_region: ipu-memory@95800000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x95800000 0 0x3800000>;
+ reusable;
+ };
+ };
+
+ /* IPU node */
+ ocp {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ipu: ipu@55020000 {
+ compatible = "ti,omap5-ipu";
+ reg = <0x55020000 0x10000>;
+ reg-names = "l2ram";
+ iommus = <&mmu_ipu>;
+ mboxes = <&mailbox &mbox_ipu>;
+ memory-region = <&ipu_memory_region>;
+ ti,timers = <&timer3>, <&timer4>;
+ ti,watchdog-timers = <&timer9>, <&timer11>;
+ };
+ };
+
+ - |+
+
+ //Example 3: DRA7xx/AM57xx DSP
+
+ /* DSP1 Reserved Memory node */
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ dsp1_memory_region: dsp1-memory@99000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x99000000 0x0 0x4000000>;
+ reusable;
+ };
+ };
+
+ /* DSP1 node */
+ ocp {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ dsp1: dsp@40800000 {
+ compatible = "ti,dra7-dsp";
+ reg = <0x40800000 0x48000>,
+ <0x40e00000 0x8000>,
+ <0x40f00000 0x8000>;
+ reg-names = "l2ram", "l1pram", "l1dram";
+ ti,bootreg = <&scm_conf 0x55c>;
+ iommus = <&mmu0_dsp1>, <&mmu1_dsp1>;
+ mboxes = <&mailbox5 &mbox_dsp1_ipc3x>;
+ memory-region = <&dsp1_memory_region>;
+ ti,timers = <&timer5>;
+ ti,watchdog-timers = <&timer10>;
+ };
+ };
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCHv2 01/17] dt-bindings: remoteproc: Add OMAP remoteproc bindings
2019-11-07 14:05 ` [PATCHv2 " Tero Kristo
@ 2019-11-13 14:25 ` Rob Herring
0 siblings, 0 replies; 7+ messages in thread
From: Rob Herring @ 2019-11-13 14:25 UTC (permalink / raw)
To: Tero Kristo
Cc: bjorn.andersson, ohad, linux-remoteproc, linux-kernel, linux-omap,
s-anna, devicetree
On Thu, Nov 07, 2019 at 04:05:08PM +0200, Tero Kristo wrote:
> From: Suman Anna <s-anna@ti.com>
>
> Add the device tree bindings document for the IPU and DSP
> remote processor devices on OMAP4+ SoCs.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> [t-kristo@ti.com: converted to schema]
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> .../remoteproc/ti,omap-remoteproc.yaml | 250 ++++++++++++++++++
> 1 file changed, 250 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
> new file mode 100644
> index 000000000000..901ccf1024c2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml
> @@ -0,0 +1,249 @@
> +# SPDX-License-Identifier: GPL-2.0
For new bindings:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/remoteproc/ti,omap-remoteproc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: OMAP4+ Remoteproc Devices
> +
> +maintainers:
> + - Suman Anna <s-anna@ti.com>
> +
> +description:
> + The OMAP family of SoCs usually have one or more slave processor sub-systems
> + that are used to offload some of the processor-intensive tasks, or to manage
> + other hardware accelerators, for achieving various system level goals.
> +
> + The processor cores in the sub-system are usually behind an IOMMU, and may
> + contain additional sub-modules like Internal RAM and/or ROMs, L1 and/or L2
> + caches, an Interrupt Controller, a Cache Controller etc.
> +
> + The OMAP SoCs usually have a DSP processor sub-system and/or an IPU processor
> + sub-system. The DSP processor sub-system can contain any of the TI's C64x,
> + C66x or C67x family of DSP cores as the main execution unit. The IPU processor
> + sub-system usually contains either a Dual-Core Cortex-M3 or Dual-Core
> + Cortex-M4 processors.
> +
> + Each remote processor sub-system is represented as a single DT node. Each node
> + has a number of required or optional properties that enable the OS running on
> + the host processor (MPU) to perform the device management of the remote
> + processor and to communicate with the remote processor. The various properties
> + can be classified as constant or variable. The constant properties are
> + dictated by the SoC and does not change from one board to another having the
> + same SoC. Examples of constant properties include 'iommus', 'reg'. The
> + variable properties are dictated by the system integration aspects such as
> + memory on the board, or configuration used within the corresponding firmware
> + image. Examples of variable properties include 'mboxes', 'memory-region',
> + 'timers', 'watchdog-timers' etc.
> +
> +properties:
> + compatible:
> + enum:
> + - ti,omap4-dsp
> + - ti,omap5-dsp
> + - ti,dra7-dsp
> + - ti,omap4-ipu
> + - ti,omap5-ipu
> + - ti,dra7-ipu
> +
> + iommus:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
The type is already defined. You just need to say how many (with
min/maxItems).
> + description: |
> + phandles to OMAP IOMMU nodes, that need to be programmed
> + for this remote processor to access any external RAM memory or
> + other peripheral device address spaces. This property usually
> + has only a single phandle. Multiple phandles are used only in
> + cases where the sub-system has different ports for different
> + sub-modules within the processor sub-system (eg: DRA7 DSPs),
> + and need the same programming in both the MMUs.
> +
> + mboxes:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
Same here.
> + description: |
> + OMAP Mailbox specifier denoting the sub-mailbox, to be used for
> + communication with the remote processor. The specifier format is
> + as per the bindings,
> + Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
> + This property should match with the sub-mailbox node used in
> + the firmware image.
> +
> +# Optional properties:
> +# --------------------
> +# Some of these properties are mandatory on some SoCs, and some are optional
> +# depending on the configuration of the firmware image to be executed on the
> +# remote processor. The conditions are mentioned for each property.
if/then schema can define which ones are required for specific
compatibles.
> +#
> +# The following are the optional properties:
> +
> + reg:
> + minItems: 1
> + maxItems: 3
> + description: |
> + Address space for any remoteproc memories present on
> + the SoC. Should contain an entry for each value in
> + 'reg-names'. These are mandatory for all DSP and IPU
> + processors that have them (OMAP4/OMAP5 DSPs do not have
> + any RAMs)
> +
> + reg-names:
> + description: |
> + Required names for each of the address spaces defined in
> + the 'reg' property. Should contain a string from among
> + the following names, each representing the corresponding
> + internal RAM memory region.
> + minItems: 1
> + maxItems: 3
> + items:
> + - const: l2ram
> + - const: l1pram
> + - const: l1dram
> +
> + ti,bootreg:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + description: |
> + Should be a pair of the phandle to the System Control
> + Configuration region that contains the boot address
> + register, and the register offset of the boot address
> + register within the System Control module. This property
> + is required for all the DSP instances on OMAP4, OMAP5
> + and DRA7xx SoCs.
> +
> + memory-region:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: |
> + phandle to the reserved memory node to be associated
> + with the remoteproc device. The reserved memory node
> + can be a CMA memory node, and should be defined as
> + per the bindings,
> + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> +
> + ti,timers:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + description: |
> + One or more phandles to OMAP DMTimer nodes, that serve
> + as System/Tick timers for the OS running on the remote
> + processors. This will usually be a single timer if the
> + processor sub-system is running in SMP mode, or one per
> + core in the processor sub-system. This can also be used
> + to reserve specific timers to be dedicated to the
> + remote processors.
> +
> + This property is mandatory on remote processors requiring
> + external tick wakeup, and to support Power Management
> + features. The timers to be used should match with the
> + timers used in the firmware image.
> +
> + ti,watchdog-timers:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + description: |
> + One or more phandles to OMAP DMTimer nodes, used to
> + serve as Watchdog timers for the processor cores. This
> + will usually be one per executing processor core, even
> + if the processor sub-system is running a SMP OS.
> +
> + The timers to be used should match with the watchdog
> + timers used in the firmware image.
> +
> +required:
> + - compatible
> + - iommus
> + - mboxes
> +
> +examples:
> + - |
> +
> + //Example 1: OMAP4 DSP
> +
> + /* DSP Reserved Memory node */
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + dsp_memory_region: dsp-memory@98000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x98000000 0x800000>;
> + reusable;
> + };
> + };
> +
> + /* DSP node */
> + ocp {
> + dsp: dsp {
> + compatible = "ti,omap4-dsp";
> + ti,bootreg = <&scm_conf 0x304>;
> + iommus = <&mmu_dsp>;
> + mboxes = <&mailbox &mbox_dsp>;
> + memory-region = <&dsp_memory_region>;
> + ti,timers = <&timer5>;
> + ti,watchdog-timers = <&timer6>;
> + };
> + };
> +
> + - |+
> +
> + //Example 2: OMAP5 IPU
> +
> + /* IPU Reserved Memory node */
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + ipu_memory_region: ipu-memory@95800000 {
> + compatible = "shared-dma-pool";
> + reg = <0 0x95800000 0 0x3800000>;
> + reusable;
> + };
> + };
> +
> + /* IPU node */
> + ocp {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + ipu: ipu@55020000 {
> + compatible = "ti,omap5-ipu";
> + reg = <0x55020000 0x10000>;
> + reg-names = "l2ram";
> + iommus = <&mmu_ipu>;
> + mboxes = <&mailbox &mbox_ipu>;
> + memory-region = <&ipu_memory_region>;
> + ti,timers = <&timer3>, <&timer4>;
> + ti,watchdog-timers = <&timer9>, <&timer11>;
> + };
> + };
> +
> + - |+
> +
> + //Example 3: DRA7xx/AM57xx DSP
> +
> + /* DSP1 Reserved Memory node */
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + dsp1_memory_region: dsp1-memory@99000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x0 0x99000000 0x0 0x4000000>;
> + reusable;
> + };
> + };
> +
> + /* DSP1 node */
> + ocp {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + dsp1: dsp@40800000 {
> + compatible = "ti,dra7-dsp";
> + reg = <0x40800000 0x48000>,
> + <0x40e00000 0x8000>,
> + <0x40f00000 0x8000>;
> + reg-names = "l2ram", "l1pram", "l1dram";
> + ti,bootreg = <&scm_conf 0x55c>;
> + iommus = <&mmu0_dsp1>, <&mmu1_dsp1>;
> + mboxes = <&mailbox5 &mbox_dsp1_ipc3x>;
> + memory-region = <&dsp1_memory_region>;
> + ti,timers = <&timer5>;
> + ti,watchdog-timers = <&timer10>;
> + };
> + };
> --
> 2.17.1
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-11-13 14:25 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20191028124238.19224-1-t-kristo@ti.com>
2019-10-28 12:42 ` [PATCH 01/17] dt-bindings: remoteproc: Add OMAP remoteproc bindings Tero Kristo
2019-11-06 3:27 ` Rob Herring
2019-11-06 12:44 ` Tero Kristo
2019-11-06 13:27 ` Rob Herring
2019-11-06 13:50 ` Tero Kristo
2019-11-07 14:05 ` [PATCHv2 " Tero Kristo
2019-11-13 14:25 ` Rob Herring
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).