devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [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).