* [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).