[PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms

[PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms

[Lee Jones]

ST's platforms often have multiple co-processors (usually ST40s or ST231s)
on-board.  This provides the Linux-side infrastructure to flash and boot
them successfully.
  
This set has been tested on an STiH410-B2120.

v4 => v5:
 - Check for invalid 'count' (command read length) in write fn()s
  
v3 => v4:
 Suggested-by: Suman Anna <s-anna@ti.com>
 - Move to using 'reserved-memory' API
   - New 'reserved-memory' nodes
   - Remove memory locations from RemoteProc's DT node's reg properties
   - Remove C code obtaining/allocating DMA memory
 - Re-order .start() and .stop() ops
 - Add protection around Reset API in error path
 - Explicitly set .has_iommu to false
  
v2 => v3:
 - Generify syscon property (st,syscfg-boot => st,syscfg)
 - Rename IP in DT bindings doc (Remote Processor => Co-Processor)
 - Remove superfluous 'clock-names' property
 - Remove superfluous 'reg-names' property
 - Populate MAINTAINERS
 - Clean-up DTS formatting
 - Use strings in debugfs to control procs ('1|0' => 'start|stop')
 - Align copyright statement with MODULE() macros
 - Rename driver data structure ('st_rproc' => 'ddata')
 - Addition of a full error path in .start()

v1 => v2:
 - Remove Linux implementation specific comment from binding document
 - Force debugfs '0' to shutdown co-processor - rather than !1
 - Supply more detailed commit message
 - Propagate errors back from .stop()
 - Review GPL wording
 - Supply original author's SoBs

Lee Jones (7):
  remoteproc: debugfs: Check of invalid 'count' value
  remoteproc: dt: Provide bindings for ST's Remote Processor Controller
    driver
  remoteproc: debugfs: Add ability to boot remote processor using
    debugfs
  remoteproc: Supply controller driver for ST's Remote Processors
  MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
  ARM: STiH407: Add nodes for RemoteProc
  ARM: STiH407: Move over to using the 'reserved-memory' API for
    obtaining DMA memory

 .../devicetree/bindings/remoteproc/st-rproc.txt    |  41 +++
 MAINTAINERS                                        |   1 +
 arch/arm/boot/dts/stih407-family.dtsi              |  70 +++++
 drivers/remoteproc/Kconfig                         |   9 +
 drivers/remoteproc/Makefile                        |   1 +
 drivers/remoteproc/remoteproc_debugfs.c            |  38 ++-
 drivers/remoteproc/st_remoteproc.c                 | 297 +++++++++++++++++++++
 7 files changed, 455 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
 create mode 100644 drivers/remoteproc/st_remoteproc.c

-- 
1.9.1

[PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms

[Lee Jones]

ST's platforms often have multiple co-processors (usually ST40s or ST231s)
on-board.  This provides the Linux-side infrastructure to flash and boot
them successfully.
  
This set has been tested on an STiH410-B2120.

v4 => v5:
 - Check for invalid 'count' (command read length) in write fn()s
  
v3 => v4:
 Suggested-by: Suman Anna <s-anna@ti.com>
 - Move to using 'reserved-memory' API
   - New 'reserved-memory' nodes
   - Remove memory locations from RemoteProc's DT node's reg properties
   - Remove C code obtaining/allocating DMA memory
 - Re-order .start() and .stop() ops
 - Add protection around Reset API in error path
 - Explicitly set .has_iommu to false
  
v2 => v3:
 - Generify syscon property (st,syscfg-boot => st,syscfg)
 - Rename IP in DT bindings doc (Remote Processor => Co-Processor)
 - Remove superfluous 'clock-names' property
 - Remove superfluous 'reg-names' property
 - Populate MAINTAINERS
 - Clean-up DTS formatting
 - Use strings in debugfs to control procs ('1|0' => 'start|stop')
 - Align copyright statement with MODULE() macros
 - Rename driver data structure ('st_rproc' => 'ddata')
 - Addition of a full error path in .start()

v1 => v2:
 - Remove Linux implementation specific comment from binding document
 - Force debugfs '0' to shutdown co-processor - rather than !1
 - Supply more detailed commit message
 - Propagate errors back from .stop()
 - Review GPL wording
 - Supply original author's SoBs

Lee Jones (7):
  remoteproc: debugfs: Check of invalid 'count' value
  remoteproc: dt: Provide bindings for ST's Remote Processor Controller
    driver
  remoteproc: debugfs: Add ability to boot remote processor using
    debugfs
  remoteproc: Supply controller driver for ST's Remote Processors
  MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
  ARM: STiH407: Add nodes for RemoteProc
  ARM: STiH407: Move over to using the 'reserved-memory' API for
    obtaining DMA memory

 .../devicetree/bindings/remoteproc/st-rproc.txt    |  41 +++
 MAINTAINERS                                        |   1 +
 arch/arm/boot/dts/stih407-family.dtsi              |  70 +++++
 drivers/remoteproc/Kconfig                         |   9 +
 drivers/remoteproc/Makefile                        |   1 +
 drivers/remoteproc/remoteproc_debugfs.c            |  38 ++-
 drivers/remoteproc/st_remoteproc.c                 | 297 +++++++++++++++++++++
 7 files changed, 455 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
 create mode 100644 drivers/remoteproc/st_remoteproc.c

-- 
1.9.1

[PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms

[Lee Jones]

ST's platforms often have multiple co-processors (usually ST40s or ST231s)
on-board.  This provides the Linux-side infrastructure to flash and boot
them successfully.
  
This set has been tested on an STiH410-B2120.

v4 => v5:
 - Check for invalid 'count' (command read length) in write fn()s
  
v3 => v4:
 Suggested-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
 - Move to using 'reserved-memory' API
   - New 'reserved-memory' nodes
   - Remove memory locations from RemoteProc's DT node's reg properties
   - Remove C code obtaining/allocating DMA memory
 - Re-order .start() and .stop() ops
 - Add protection around Reset API in error path
 - Explicitly set .has_iommu to false
  
v2 => v3:
 - Generify syscon property (st,syscfg-boot => st,syscfg)
 - Rename IP in DT bindings doc (Remote Processor => Co-Processor)
 - Remove superfluous 'clock-names' property
 - Remove superfluous 'reg-names' property
 - Populate MAINTAINERS
 - Clean-up DTS formatting
 - Use strings in debugfs to control procs ('1|0' => 'start|stop')
 - Align copyright statement with MODULE() macros
 - Rename driver data structure ('st_rproc' => 'ddata')
 - Addition of a full error path in .start()

v1 => v2:
 - Remove Linux implementation specific comment from binding document
 - Force debugfs '0' to shutdown co-processor - rather than !1
 - Supply more detailed commit message
 - Propagate errors back from .stop()
 - Review GPL wording
 - Supply original author's SoBs

Lee Jones (7):
  remoteproc: debugfs: Check of invalid 'count' value
  remoteproc: dt: Provide bindings for ST's Remote Processor Controller
    driver
  remoteproc: debugfs: Add ability to boot remote processor using
    debugfs
  remoteproc: Supply controller driver for ST's Remote Processors
  MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
  ARM: STiH407: Add nodes for RemoteProc
  ARM: STiH407: Move over to using the 'reserved-memory' API for
    obtaining DMA memory

 .../devicetree/bindings/remoteproc/st-rproc.txt    |  41 +++
 MAINTAINERS                                        |   1 +
 arch/arm/boot/dts/stih407-family.dtsi              |  70 +++++
 drivers/remoteproc/Kconfig                         |   9 +
 drivers/remoteproc/Makefile                        |   1 +
 drivers/remoteproc/remoteproc_debugfs.c            |  38 ++-
 drivers/remoteproc/st_remoteproc.c                 | 297 +++++++++++++++++++++
 7 files changed, 455 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
 create mode 100644 drivers/remoteproc/st_remoteproc.c

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/7] remoteproc: debugfs: Check of invalid 'count' value

[Lee Jones]

If 'count' value is invalid, return early with an error.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/remoteproc/remoteproc_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
index 9d30809..f63464c 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -156,8 +156,8 @@ rproc_recovery_write(struct file *filp, const char __user *user_buf,
 	char buf[10];
 	int ret;
 
-	if (count > sizeof(buf))
-		return count;
+	if (count > sizeof(buf) || count <= 0)
+		return -EINVAL;
 
 	ret = copy_from_user(buf, user_buf, count);
 	if (ret)
-- 
1.9.1

[PATCH v5 1/7] remoteproc: debugfs: Check of invalid 'count' value

[Lee Jones]

If 'count' value is invalid, return early with an error.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/remoteproc/remoteproc_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
index 9d30809..f63464c 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -156,8 +156,8 @@ rproc_recovery_write(struct file *filp, const char __user *user_buf,
 	char buf[10];
 	int ret;
 
-	if (count > sizeof(buf))
-		return count;
+	if (count > sizeof(buf) || count <= 0)
+		return -EINVAL;
 
 	ret = copy_from_user(buf, user_buf, count);
 	if (ret)
-- 
1.9.1

[PATCH v5 1/7] remoteproc: debugfs: Check of invalid 'count' value

[Lee Jones]

If 'count' value is invalid, return early with an error.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/remoteproc/remoteproc_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
index 9d30809..f63464c 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -156,8 +156,8 @@ rproc_recovery_write(struct file *filp, const char __user *user_buf,
 	char buf[10];
 	int ret;
 
-	if (count > sizeof(buf))
-		return count;
+	if (count > sizeof(buf) || count <= 0)
+		return -EINVAL;
 
 	ret = copy_from_user(buf, user_buf, count);
 	if (ret)
-- 
1.9.1

[PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

[Lee Jones]

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 .../devicetree/bindings/remoteproc/st-rproc.txt    | 41 ++++++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt

diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
new file mode 100644
index 0000000..1031bcd
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
@@ -0,0 +1,41 @@
+STMicroelectronics Co-Processor Bindings
+----------------------------------------
+
+This binding provides support for adjunct processors found on ST SoCs.
+
+Co-processors can be controlled from the bootloader or the primary OS. If
+the bootloader starts a co-processor, the primary OS must detect its state
+and act accordingly.
+
+Required properties:
+- compatible		Should be one of:
+				"st,st231-rproc"
+				"st,st40-rproc"
+- memory-region		Reserved memory (See: ../reserved-memory/reserved-memory.txt)
+- resets		Reset lines (See: ../reset/reset.txt)
+- reset-names		Must be "sw_reset" and "pwr_reset"
+- clocks		Clock for co-processor (See: ../clock/clock-bindings.txt)
+- clock-frequency	Clock frequency to set co-processor at if the bootloader
+			hasn't already done so
+- st,syscfg		System configuration register which holds the boot vector
+			for the co-processor
+				1st cell: Phandle to syscon block
+				2nd cell: Boot vector register offset
+
+Example:
+
+	audio_reserved: rproc@42000000 {
+		compatible = "shared-dma-pool";
+		reg = <0x42000000 0x01000000>;
+		no-map;
+	};
+
+	st231-audio {
+		compatible	= "st,st231-rproc";
+		memory-region	= <&audio_reserved>;
+		resets		= <&softreset STIH407_ST231_AUD_SOFTRESET>;
+		reset-names	= "sw_reset";
+		clocks		= <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
+		clock-frequency	= <600000000>;
+		st,syscfg	= <&syscfg_core 0x228>;
+	};
-- 
1.9.1

[PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

[Lee Jones]

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 .../devicetree/bindings/remoteproc/st-rproc.txt    | 41 ++++++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt

diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
new file mode 100644
index 0000000..1031bcd
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
@@ -0,0 +1,41 @@
+STMicroelectronics Co-Processor Bindings
+----------------------------------------
+
+This binding provides support for adjunct processors found on ST SoCs.
+
+Co-processors can be controlled from the bootloader or the primary OS. If
+the bootloader starts a co-processor, the primary OS must detect its state
+and act accordingly.
+
+Required properties:
+- compatible		Should be one of:
+				"st,st231-rproc"
+				"st,st40-rproc"
+- memory-region		Reserved memory (See: ../reserved-memory/reserved-memory.txt)
+- resets		Reset lines (See: ../reset/reset.txt)
+- reset-names		Must be "sw_reset" and "pwr_reset"
+- clocks		Clock for co-processor (See: ../clock/clock-bindings.txt)
+- clock-frequency	Clock frequency to set co-processor at if the bootloader
+			hasn't already done so
+- st,syscfg		System configuration register which holds the boot vector
+			for the co-processor
+				1st cell: Phandle to syscon block
+				2nd cell: Boot vector register offset
+
+Example:
+
+	audio_reserved: rproc at 42000000 {
+		compatible = "shared-dma-pool";
+		reg = <0x42000000 0x01000000>;
+		no-map;
+	};
+
+	st231-audio {
+		compatible	= "st,st231-rproc";
+		memory-region	= <&audio_reserved>;
+		resets		= <&softreset STIH407_ST231_AUD_SOFTRESET>;
+		reset-names	= "sw_reset";
+		clocks		= <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
+		clock-frequency	= <600000000>;
+		st,syscfg	= <&syscfg_core 0x228>;
+	};
-- 
1.9.1

Re: [PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

[Rob Herring]

On Tue, Jan 12, 2016 at 12:46:16PM +0000, Lee Jones wrote:
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  .../devicetree/bindings/remoteproc/st-rproc.txt    | 41 ++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt

Acked-by: Rob Herring <robh@kernel.org>

[PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

[Rob Herring]

On Tue, Jan 12, 2016 at 12:46:16PM +0000, Lee Jones wrote:
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  .../devicetree/bindings/remoteproc/st-rproc.txt    | 41 ++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

[Rob Herring]

On Tue, Jan 12, 2016 at 12:46:16PM +0000, Lee Jones wrote:
> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  .../devicetree/bindings/remoteproc/st-rproc.txt    | 41 ++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

[Lee Jones]

On Tue, 12 Jan 2016, Rob Herring wrote:

> On Tue, Jan 12, 2016 at 12:46:16PM +0000, Lee Jones wrote:
> > Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> >  .../devicetree/bindings/remoteproc/st-rproc.txt    | 41 ++++++++++++++++++++++
> >  1 file changed, 41 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> 
> Acked-by: Rob Herring <robh@kernel.org>

Ah balls.  I've somehow dropped yours and Bjorn's Acks from the set.

Apologies for that.  I did apply them, honest!

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

[Lee Jones]

On Tue, 12 Jan 2016, Rob Herring wrote:

> On Tue, Jan 12, 2016 at 12:46:16PM +0000, Lee Jones wrote:
> > Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> >  .../devicetree/bindings/remoteproc/st-rproc.txt    | 41 ++++++++++++++++++++++
> >  1 file changed, 41 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> 
> Acked-by: Rob Herring <robh@kernel.org>

Ah balls.  I've somehow dropped yours and Bjorn's Acks from the set.

Apologies for that.  I did apply them, honest!

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [STLinux Kernel] [PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

[Peter Griffin]

On Tue, 12 Jan 2016, Lee Jones wrote:

> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  .../devicetree/bindings/remoteproc/st-rproc.txt    | 41 ++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt

Acked-by: Peter Griffin <peter.griffin@linaro.org>

[STLinux Kernel] [PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

[Peter Griffin]

On Tue, 12 Jan 2016, Lee Jones wrote:

> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  .../devicetree/bindings/remoteproc/st-rproc.txt    | 41 ++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt

Acked-by: Peter Griffin <peter.griffin@linaro.org>

[PATCH v5 3/7] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Lee Jones]

This functionality is especially useful during the testing phase.  When
used in conjunction with Mailbox's Test Framework we can trivially conduct
end-to-end testing i.e. boot co-processor, send and receive messages to
the co-processor, then shut it down again (repeat as required).

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/remoteproc/remoteproc_debugfs.c | 34 +++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
index f63464c..2f2ac33 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -88,8 +88,42 @@ static ssize_t rproc_state_read(struct file *filp, char __user *userbuf,
 	return simple_read_from_buffer(userbuf, count, ppos, buf, i);
 }
 
+static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
+				 size_t count, loff_t *ppos)
+{
+	struct rproc *rproc = filp->private_data;
+	char buf[10];
+	int ret;
+
+	if (count > sizeof(buf) || count <= 0)
+		return -EINVAL;
+
+	ret = copy_from_user(buf, userbuf, count);
+	if (ret)
+		return -EFAULT;
+
+	if (buf[count - 1] == '\n')
+		buf[count - 1] = '\0';
+
+	if (!strncmp(buf, "start", count)) {
+		ret = rproc_boot(rproc);
+		if (ret) {
+			dev_err(&rproc->dev, "Boot failed: %d\n", ret);
+			return ret;
+		}
+	} else if (!strncmp(buf, "stop", count)) {
+		rproc_shutdown(rproc);
+	} else {
+		dev_err(&rproc->dev, "Unrecognised option: %s\n", buf);
+		return -EINVAL;
+	}
+
+	return count;
+}
+
 static const struct file_operations rproc_state_ops = {
 	.read = rproc_state_read,
+	.write = rproc_state_write,
 	.open = simple_open,
 	.llseek	= generic_file_llseek,
 };
-- 
1.9.1

[PATCH v5 3/7] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Lee Jones]

This functionality is especially useful during the testing phase.  When
used in conjunction with Mailbox's Test Framework we can trivially conduct
end-to-end testing i.e. boot co-processor, send and receive messages to
the co-processor, then shut it down again (repeat as required).

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/remoteproc/remoteproc_debugfs.c | 34 +++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
index f63464c..2f2ac33 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -88,8 +88,42 @@ static ssize_t rproc_state_read(struct file *filp, char __user *userbuf,
 	return simple_read_from_buffer(userbuf, count, ppos, buf, i);
 }
 
+static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
+				 size_t count, loff_t *ppos)
+{
+	struct rproc *rproc = filp->private_data;
+	char buf[10];
+	int ret;
+
+	if (count > sizeof(buf) || count <= 0)
+		return -EINVAL;
+
+	ret = copy_from_user(buf, userbuf, count);
+	if (ret)
+		return -EFAULT;
+
+	if (buf[count - 1] == '\n')
+		buf[count - 1] = '\0';
+
+	if (!strncmp(buf, "start", count)) {
+		ret = rproc_boot(rproc);
+		if (ret) {
+			dev_err(&rproc->dev, "Boot failed: %d\n", ret);
+			return ret;
+		}
+	} else if (!strncmp(buf, "stop", count)) {
+		rproc_shutdown(rproc);
+	} else {
+		dev_err(&rproc->dev, "Unrecognised option: %s\n", buf);
+		return -EINVAL;
+	}
+
+	return count;
+}
+
 static const struct file_operations rproc_state_ops = {
 	.read = rproc_state_read,
+	.write = rproc_state_write,
 	.open = simple_open,
 	.llseek	= generic_file_llseek,
 };
-- 
1.9.1

[PATCH v5 3/7] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Lee Jones]

This functionality is especially useful during the testing phase.  When
used in conjunction with Mailbox's Test Framework we can trivially conduct
end-to-end testing i.e. boot co-processor, send and receive messages to
the co-processor, then shut it down again (repeat as required).

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/remoteproc/remoteproc_debugfs.c | 34 +++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
index f63464c..2f2ac33 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -88,8 +88,42 @@ static ssize_t rproc_state_read(struct file *filp, char __user *userbuf,
 	return simple_read_from_buffer(userbuf, count, ppos, buf, i);
 }
 
+static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf,
+				 size_t count, loff_t *ppos)
+{
+	struct rproc *rproc = filp->private_data;
+	char buf[10];
+	int ret;
+
+	if (count > sizeof(buf) || count <= 0)
+		return -EINVAL;
+
+	ret = copy_from_user(buf, userbuf, count);
+	if (ret)
+		return -EFAULT;
+
+	if (buf[count - 1] == '\n')
+		buf[count - 1] = '\0';
+
+	if (!strncmp(buf, "start", count)) {
+		ret = rproc_boot(rproc);
+		if (ret) {
+			dev_err(&rproc->dev, "Boot failed: %d\n", ret);
+			return ret;
+		}
+	} else if (!strncmp(buf, "stop", count)) {
+		rproc_shutdown(rproc);
+	} else {
+		dev_err(&rproc->dev, "Unrecognised option: %s\n", buf);
+		return -EINVAL;
+	}
+
+	return count;
+}
+
 static const struct file_operations rproc_state_ops = {
 	.read = rproc_state_read,
+	.write = rproc_state_write,
 	.open = simple_open,
 	.llseek	= generic_file_llseek,
 };
-- 
1.9.1

Re: [STLinux Kernel] [PATCH v5 3/7] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Peter Griffin]

On Tue, 12 Jan 2016, Lee Jones wrote:

> This functionality is especially useful during the testing phase.  When
> used in conjunction with Mailbox's Test Framework we can trivially conduct
> end-to-end testing i.e. boot co-processor, send and receive messages to
> the co-processor, then shut it down again (repeat as required).
> 
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  drivers/remoteproc/remoteproc_debugfs.c | 34 +++++++++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)

Acked-by: Peter Griffin <peter.griffin@linaro.org>

[STLinux Kernel] [PATCH v5 3/7] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Peter Griffin]

On Tue, 12 Jan 2016, Lee Jones wrote:

> This functionality is especially useful during the testing phase.  When
> used in conjunction with Mailbox's Test Framework we can trivially conduct
> end-to-end testing i.e. boot co-processor, send and receive messages to
> the co-processor, then shut it down again (repeat as required).
> 
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  drivers/remoteproc/remoteproc_debugfs.c | 34 +++++++++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)

Acked-by: Peter Griffin <peter.griffin@linaro.org>

Re: [STLinux Kernel] [PATCH v5 3/7] remoteproc: debugfs: Add ability to boot remote processor using debugfs

[Peter Griffin]

On Tue, 12 Jan 2016, Lee Jones wrote:

> This functionality is especially useful during the testing phase.  When
> used in conjunction with Mailbox's Test Framework we can trivially conduct
> end-to-end testing i.e. boot co-processor, send and receive messages to
> the co-processor, then shut it down again (repeat as required).
> 
> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  drivers/remoteproc/remoteproc_debugfs.c | 34 +++++++++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)

Acked-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 4/7] remoteproc: Supply controller driver for ST's Remote Processors

[Lee Jones]

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/remoteproc/Kconfig         |   9 ++
 drivers/remoteproc/Makefile        |   1 +
 drivers/remoteproc/st_remoteproc.c | 297 +++++++++++++++++++++++++++++++++++++
 3 files changed, 307 insertions(+)
 create mode 100644 drivers/remoteproc/st_remoteproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 28c711f..72e97d7 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC
 	  It's safe to say n here if you're not interested in multimedia
 	  offloading.
 
+config ST_REMOTEPROC
+	tristate "ST remoteproc support"
+	depends on ARCH_STI
+	select REMOTEPROC
+	help
+	  Say y here to support ST's adjunct processors via the remote
+	  processor framework.
+	  This can be either built-in or a loadable module.
+
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 81b04d1..279cb2e 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_OMAP_REMOTEPROC)		+= omap_remoteproc.o
 obj-$(CONFIG_STE_MODEM_RPROC)	 	+= ste_modem_rproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)		+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
+obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
diff --git a/drivers/remoteproc/st_remoteproc.c b/drivers/remoteproc/st_remoteproc.c
new file mode 100644
index 0000000..6bb04d4
--- /dev/null
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -0,0 +1,297 @@
+/*
+ * ST's Remote Processor Control Driver
+ *
+ * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
+ *
+ * Author: Ludovic Barre <ludovic.barre@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_reserved_mem.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/remoteproc.h>
+#include <linux/reset.h>
+
+struct st_rproc_config {
+	bool			sw_reset;
+	bool			pwr_reset;
+	unsigned long		bootaddr_mask;
+};
+
+struct st_rproc {
+	struct st_rproc_config	*config;
+	struct reset_control	*sw_reset;
+	struct reset_control	*pwr_reset;
+	struct clk		*clk;
+	u32			clk_rate;
+	struct regmap		*boot_base;
+	u32			boot_offset;
+};
+
+static int st_rproc_start(struct rproc *rproc)
+{
+	struct st_rproc *ddata = rproc->priv;
+	int err;
+
+	regmap_update_bits(ddata->boot_base, ddata->boot_offset,
+			   ddata->config->bootaddr_mask, rproc->bootaddr);
+
+	err = clk_enable(ddata->clk);
+	if (err) {
+		dev_err(&rproc->dev, "Failed to enable clock\n");
+		return err;
+	}
+
+	if (ddata->config->sw_reset) {
+		err = reset_control_deassert(ddata->sw_reset);
+		if (err) {
+			dev_err(&rproc->dev, "Failed to deassert S/W Reset\n");
+			goto sw_reset_fail;
+		}
+	}
+
+	if (ddata->config->pwr_reset) {
+		err = reset_control_deassert(ddata->pwr_reset);
+		if (err) {
+			dev_err(&rproc->dev, "Failed to deassert Power Reset\n");
+			goto pwr_reset_fail;
+		}
+	}
+
+	dev_info(&rproc->dev, "Started from 0x%x\n", rproc->bootaddr);
+
+	return 0;
+
+
+pwr_reset_fail:
+	if (ddata->config->pwr_reset)
+		reset_control_assert(ddata->sw_reset);
+sw_reset_fail:
+	clk_disable(ddata->clk);
+
+	return err;
+}
+
+static int st_rproc_stop(struct rproc *rproc)
+{
+	struct st_rproc *ddata = rproc->priv;
+	int sw_err = 0, pwr_err = 0;
+
+	if (ddata->config->sw_reset) {
+		sw_err = reset_control_assert(ddata->sw_reset);
+		if (sw_err)
+			dev_err(&rproc->dev, "Failed to assert S/W Reset\n");
+	}
+
+	if (ddata->config->pwr_reset) {
+		pwr_err = reset_control_assert(ddata->pwr_reset);
+		if (pwr_err)
+			dev_err(&rproc->dev, "Failed to assert Power Reset\n");
+	}
+
+	clk_disable(ddata->clk);
+
+	return sw_err ?: pwr_err;
+}
+
+static struct rproc_ops st_rproc_ops = {
+	.start		= st_rproc_start,
+	.stop		= st_rproc_stop,
+};
+
+/*
+ * Fetch state of the processor: 0 is off, 1 is on.
+ */
+static int st_rproc_state(struct platform_device *pdev)
+{
+	struct rproc *rproc = platform_get_drvdata(pdev);
+	struct st_rproc *ddata = rproc->priv;
+	int reset_sw = 0, reset_pwr = 0;
+
+	if (ddata->config->sw_reset)
+		reset_sw = reset_control_status(ddata->sw_reset);
+
+	if (ddata->config->pwr_reset)
+		reset_pwr = reset_control_status(ddata->pwr_reset);
+
+	if (reset_sw < 0 || reset_pwr < 0)
+		return -EINVAL;
+
+	return !reset_sw && !reset_pwr;
+}
+
+static const struct st_rproc_config st40_rproc_cfg = {
+	.sw_reset = true,
+	.pwr_reset = true,
+	.bootaddr_mask = GENMASK(28, 1),
+};
+
+static const struct st_rproc_config st231_rproc_cfg = {
+	.sw_reset = true,
+	.pwr_reset = false,
+	.bootaddr_mask = GENMASK(31, 6),
+};
+
+static const struct of_device_id st_rproc_match[] = {
+	{ .compatible = "st,st40-rproc", .data = &st40_rproc_cfg },
+	{ .compatible = "st,st231-rproc", .data = &st231_rproc_cfg },
+	{},
+};
+MODULE_DEVICE_TABLE(of, st_rproc_match);
+
+static int st_rproc_parse_dt(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct rproc *rproc = platform_get_drvdata(pdev);
+	struct st_rproc *ddata = rproc->priv;
+	struct device_node *np = dev->of_node;
+	int err;
+
+	if (ddata->config->sw_reset) {
+		ddata->sw_reset = devm_reset_control_get(dev, "sw_reset");
+		if (IS_ERR(ddata->sw_reset)) {
+			dev_err(dev, "Failed to get S/W Reset\n");
+			return PTR_ERR(ddata->sw_reset);
+		}
+	}
+
+	if (ddata->config->pwr_reset) {
+		ddata->pwr_reset = devm_reset_control_get(dev, "pwr_reset");
+		if (IS_ERR(ddata->pwr_reset)) {
+			dev_err(dev, "Failed to get Power Reset\n");
+			return PTR_ERR(ddata->pwr_reset);
+		}
+	}
+
+	ddata->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(ddata->clk)) {
+		dev_err(dev, "Failed to get clock\n");
+		return PTR_ERR(ddata->clk);
+	}
+
+	err = of_property_read_u32(np, "clock-frequency", &ddata->clk_rate);
+	if (err) {
+		dev_err(dev, "failed to get clock frequency\n");
+		return err;
+	}
+
+	ddata->boot_base = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
+	if (!ddata->boot_base) {
+		dev_err(dev, "Boot base not found\n");
+		return -EINVAL;
+	}
+
+	err = of_property_read_u32_index(np, "st,syscfg", 1,
+					 &ddata->boot_offset);
+	if (err) {
+		dev_err(dev, "Boot offset not found\n");
+		return -EINVAL;
+	}
+
+	err = of_reserved_mem_device_init(dev);
+	if (err) {
+		dev_err(dev, "Failed to obtain shared memory\n");
+		return err;
+	}
+
+	err = clk_prepare(ddata->clk);
+	if (err)
+		dev_err(dev, "failed to get clock\n");
+
+	return err;
+}
+
+static int st_rproc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	const struct of_device_id *match;
+	struct st_rproc *ddata;
+	struct device_node *np = dev->of_node;
+	struct rproc *rproc;
+	int enabled;
+	int ret;
+
+	match = of_match_device(st_rproc_match, dev);
+	if (!match || !match->data) {
+		dev_err(dev, "No device match found\n");
+		return -ENODEV;
+	}
+
+	rproc = rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
+	if (!rproc)
+		return -ENOMEM;
+
+	rproc->has_iommu = false;
+	ddata = rproc->priv;
+	ddata->config = (struct st_rproc_config *)match->data;
+
+	platform_set_drvdata(pdev, rproc);
+
+	ret = st_rproc_parse_dt(pdev);
+	if (ret)
+		goto free_rproc;
+
+	enabled = st_rproc_state(pdev);
+	if (enabled < 0)
+		goto free_rproc;
+
+	if (enabled) {
+		atomic_inc(&rproc->power);
+		rproc->state = RPROC_RUNNING;
+	} else {
+		clk_set_rate(ddata->clk, ddata->clk_rate);
+	}
+
+	ret = rproc_add(rproc);
+	if (ret)
+		goto free_rproc;
+
+	return 0;
+
+free_rproc:
+	rproc_put(rproc);
+	return ret;
+}
+
+static int st_rproc_remove(struct platform_device *pdev)
+{
+	struct rproc *rproc = platform_get_drvdata(pdev);
+	struct st_rproc *ddata = rproc->priv;
+
+	rproc_del(rproc);
+
+	clk_disable_unprepare(ddata->clk);
+
+	of_reserved_mem_device_release(&pdev->dev);
+
+	rproc_put(rproc);
+
+	return 0;
+}
+
+static struct platform_driver st_rproc_driver = {
+	.probe = st_rproc_probe,
+	.remove = st_rproc_remove,
+	.driver = {
+		.name = "st-rproc",
+		.of_match_table = of_match_ptr(st_rproc_match),
+	},
+};
+module_platform_driver(st_rproc_driver);
+
+MODULE_DESCRIPTION("ST Remote Processor Control Driver");
+MODULE_AUTHOR("Ludovic Barre <ludovic.barre@st.com>");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1

[PATCH v5 4/7] remoteproc: Supply controller driver for ST's Remote Processors

[Lee Jones]

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/remoteproc/Kconfig         |   9 ++
 drivers/remoteproc/Makefile        |   1 +
 drivers/remoteproc/st_remoteproc.c | 297 +++++++++++++++++++++++++++++++++++++
 3 files changed, 307 insertions(+)
 create mode 100644 drivers/remoteproc/st_remoteproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 28c711f..72e97d7 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC
 	  It's safe to say n here if you're not interested in multimedia
 	  offloading.
 
+config ST_REMOTEPROC
+	tristate "ST remoteproc support"
+	depends on ARCH_STI
+	select REMOTEPROC
+	help
+	  Say y here to support ST's adjunct processors via the remote
+	  processor framework.
+	  This can be either built-in or a loadable module.
+
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 81b04d1..279cb2e 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_OMAP_REMOTEPROC)		+= omap_remoteproc.o
 obj-$(CONFIG_STE_MODEM_RPROC)	 	+= ste_modem_rproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)		+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
+obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
diff --git a/drivers/remoteproc/st_remoteproc.c b/drivers/remoteproc/st_remoteproc.c
new file mode 100644
index 0000000..6bb04d4
--- /dev/null
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -0,0 +1,297 @@
+/*
+ * ST's Remote Processor Control Driver
+ *
+ * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
+ *
+ * Author: Ludovic Barre <ludovic.barre@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/clk.h>
+#include <linux/dma-mapping.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_reserved_mem.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/remoteproc.h>
+#include <linux/reset.h>
+
+struct st_rproc_config {
+	bool			sw_reset;
+	bool			pwr_reset;
+	unsigned long		bootaddr_mask;
+};
+
+struct st_rproc {
+	struct st_rproc_config	*config;
+	struct reset_control	*sw_reset;
+	struct reset_control	*pwr_reset;
+	struct clk		*clk;
+	u32			clk_rate;
+	struct regmap		*boot_base;
+	u32			boot_offset;
+};
+
+static int st_rproc_start(struct rproc *rproc)
+{
+	struct st_rproc *ddata = rproc->priv;
+	int err;
+
+	regmap_update_bits(ddata->boot_base, ddata->boot_offset,
+			   ddata->config->bootaddr_mask, rproc->bootaddr);
+
+	err = clk_enable(ddata->clk);
+	if (err) {
+		dev_err(&rproc->dev, "Failed to enable clock\n");
+		return err;
+	}
+
+	if (ddata->config->sw_reset) {
+		err = reset_control_deassert(ddata->sw_reset);
+		if (err) {
+			dev_err(&rproc->dev, "Failed to deassert S/W Reset\n");
+			goto sw_reset_fail;
+		}
+	}
+
+	if (ddata->config->pwr_reset) {
+		err = reset_control_deassert(ddata->pwr_reset);
+		if (err) {
+			dev_err(&rproc->dev, "Failed to deassert Power Reset\n");
+			goto pwr_reset_fail;
+		}
+	}
+
+	dev_info(&rproc->dev, "Started from 0x%x\n", rproc->bootaddr);
+
+	return 0;
+
+
+pwr_reset_fail:
+	if (ddata->config->pwr_reset)
+		reset_control_assert(ddata->sw_reset);
+sw_reset_fail:
+	clk_disable(ddata->clk);
+
+	return err;
+}
+
+static int st_rproc_stop(struct rproc *rproc)
+{
+	struct st_rproc *ddata = rproc->priv;
+	int sw_err = 0, pwr_err = 0;
+
+	if (ddata->config->sw_reset) {
+		sw_err = reset_control_assert(ddata->sw_reset);
+		if (sw_err)
+			dev_err(&rproc->dev, "Failed to assert S/W Reset\n");
+	}
+
+	if (ddata->config->pwr_reset) {
+		pwr_err = reset_control_assert(ddata->pwr_reset);
+		if (pwr_err)
+			dev_err(&rproc->dev, "Failed to assert Power Reset\n");
+	}
+
+	clk_disable(ddata->clk);
+
+	return sw_err ?: pwr_err;
+}
+
+static struct rproc_ops st_rproc_ops = {
+	.start		= st_rproc_start,
+	.stop		= st_rproc_stop,
+};
+
+/*
+ * Fetch state of the processor: 0 is off, 1 is on.
+ */
+static int st_rproc_state(struct platform_device *pdev)
+{
+	struct rproc *rproc = platform_get_drvdata(pdev);
+	struct st_rproc *ddata = rproc->priv;
+	int reset_sw = 0, reset_pwr = 0;
+
+	if (ddata->config->sw_reset)
+		reset_sw = reset_control_status(ddata->sw_reset);
+
+	if (ddata->config->pwr_reset)
+		reset_pwr = reset_control_status(ddata->pwr_reset);
+
+	if (reset_sw < 0 || reset_pwr < 0)
+		return -EINVAL;
+
+	return !reset_sw && !reset_pwr;
+}
+
+static const struct st_rproc_config st40_rproc_cfg = {
+	.sw_reset = true,
+	.pwr_reset = true,
+	.bootaddr_mask = GENMASK(28, 1),
+};
+
+static const struct st_rproc_config st231_rproc_cfg = {
+	.sw_reset = true,
+	.pwr_reset = false,
+	.bootaddr_mask = GENMASK(31, 6),
+};
+
+static const struct of_device_id st_rproc_match[] = {
+	{ .compatible = "st,st40-rproc", .data = &st40_rproc_cfg },
+	{ .compatible = "st,st231-rproc", .data = &st231_rproc_cfg },
+	{},
+};
+MODULE_DEVICE_TABLE(of, st_rproc_match);
+
+static int st_rproc_parse_dt(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct rproc *rproc = platform_get_drvdata(pdev);
+	struct st_rproc *ddata = rproc->priv;
+	struct device_node *np = dev->of_node;
+	int err;
+
+	if (ddata->config->sw_reset) {
+		ddata->sw_reset = devm_reset_control_get(dev, "sw_reset");
+		if (IS_ERR(ddata->sw_reset)) {
+			dev_err(dev, "Failed to get S/W Reset\n");
+			return PTR_ERR(ddata->sw_reset);
+		}
+	}
+
+	if (ddata->config->pwr_reset) {
+		ddata->pwr_reset = devm_reset_control_get(dev, "pwr_reset");
+		if (IS_ERR(ddata->pwr_reset)) {
+			dev_err(dev, "Failed to get Power Reset\n");
+			return PTR_ERR(ddata->pwr_reset);
+		}
+	}
+
+	ddata->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(ddata->clk)) {
+		dev_err(dev, "Failed to get clock\n");
+		return PTR_ERR(ddata->clk);
+	}
+
+	err = of_property_read_u32(np, "clock-frequency", &ddata->clk_rate);
+	if (err) {
+		dev_err(dev, "failed to get clock frequency\n");
+		return err;
+	}
+
+	ddata->boot_base = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
+	if (!ddata->boot_base) {
+		dev_err(dev, "Boot base not found\n");
+		return -EINVAL;
+	}
+
+	err = of_property_read_u32_index(np, "st,syscfg", 1,
+					 &ddata->boot_offset);
+	if (err) {
+		dev_err(dev, "Boot offset not found\n");
+		return -EINVAL;
+	}
+
+	err = of_reserved_mem_device_init(dev);
+	if (err) {
+		dev_err(dev, "Failed to obtain shared memory\n");
+		return err;
+	}
+
+	err = clk_prepare(ddata->clk);
+	if (err)
+		dev_err(dev, "failed to get clock\n");
+
+	return err;
+}
+
+static int st_rproc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	const struct of_device_id *match;
+	struct st_rproc *ddata;
+	struct device_node *np = dev->of_node;
+	struct rproc *rproc;
+	int enabled;
+	int ret;
+
+	match = of_match_device(st_rproc_match, dev);
+	if (!match || !match->data) {
+		dev_err(dev, "No device match found\n");
+		return -ENODEV;
+	}
+
+	rproc = rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
+	if (!rproc)
+		return -ENOMEM;
+
+	rproc->has_iommu = false;
+	ddata = rproc->priv;
+	ddata->config = (struct st_rproc_config *)match->data;
+
+	platform_set_drvdata(pdev, rproc);
+
+	ret = st_rproc_parse_dt(pdev);
+	if (ret)
+		goto free_rproc;
+
+	enabled = st_rproc_state(pdev);
+	if (enabled < 0)
+		goto free_rproc;
+
+	if (enabled) {
+		atomic_inc(&rproc->power);
+		rproc->state = RPROC_RUNNING;
+	} else {
+		clk_set_rate(ddata->clk, ddata->clk_rate);
+	}
+
+	ret = rproc_add(rproc);
+	if (ret)
+		goto free_rproc;
+
+	return 0;
+
+free_rproc:
+	rproc_put(rproc);
+	return ret;
+}
+
+static int st_rproc_remove(struct platform_device *pdev)
+{
+	struct rproc *rproc = platform_get_drvdata(pdev);
+	struct st_rproc *ddata = rproc->priv;
+
+	rproc_del(rproc);
+
+	clk_disable_unprepare(ddata->clk);
+
+	of_reserved_mem_device_release(&pdev->dev);
+
+	rproc_put(rproc);
+
+	return 0;
+}
+
+static struct platform_driver st_rproc_driver = {
+	.probe = st_rproc_probe,
+	.remove = st_rproc_remove,
+	.driver = {
+		.name = "st-rproc",
+		.of_match_table = of_match_ptr(st_rproc_match),
+	},
+};
+module_platform_driver(st_rproc_driver);
+
+MODULE_DESCRIPTION("ST Remote Processor Control Driver");
+MODULE_AUTHOR("Ludovic Barre <ludovic.barre@st.com>");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1

Re: [PATCH v5 4/7] remoteproc: Supply controller driver for ST's Remote Processors

[Lee Jones]

On Tue, 12 Jan 2016, Lee Jones wrote:

> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>

This should also have Bjorn's Ack.  Apologies for dropping it.

> ---
>  drivers/remoteproc/Kconfig         |   9 ++
>  drivers/remoteproc/Makefile        |   1 +
>  drivers/remoteproc/st_remoteproc.c | 297 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 307 insertions(+)
>  create mode 100644 drivers/remoteproc/st_remoteproc.c
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 28c711f..72e97d7 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC
>  	  It's safe to say n here if you're not interested in multimedia
>  	  offloading.
>  
> +config ST_REMOTEPROC
> +	tristate "ST remoteproc support"
> +	depends on ARCH_STI
> +	select REMOTEPROC
> +	help
> +	  Say y here to support ST's adjunct processors via the remote
> +	  processor framework.
> +	  This can be either built-in or a loadable module.
> +
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 81b04d1..279cb2e 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_OMAP_REMOTEPROC)		+= omap_remoteproc.o
>  obj-$(CONFIG_STE_MODEM_RPROC)	 	+= ste_modem_rproc.o
>  obj-$(CONFIG_WKUP_M3_RPROC)		+= wkup_m3_rproc.o
>  obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
> +obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
> diff --git a/drivers/remoteproc/st_remoteproc.c b/drivers/remoteproc/st_remoteproc.c
> new file mode 100644
> index 0000000..6bb04d4
> --- /dev/null
> +++ b/drivers/remoteproc/st_remoteproc.c
> @@ -0,0 +1,297 @@
> +/*
> + * ST's Remote Processor Control Driver
> + *
> + * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
> + *
> + * Author: Ludovic Barre <ludovic.barre@st.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/remoteproc.h>
> +#include <linux/reset.h>
> +
> +struct st_rproc_config {
> +	bool			sw_reset;
> +	bool			pwr_reset;
> +	unsigned long		bootaddr_mask;
> +};
> +
> +struct st_rproc {
> +	struct st_rproc_config	*config;
> +	struct reset_control	*sw_reset;
> +	struct reset_control	*pwr_reset;
> +	struct clk		*clk;
> +	u32			clk_rate;
> +	struct regmap		*boot_base;
> +	u32			boot_offset;
> +};
> +
> +static int st_rproc_start(struct rproc *rproc)
> +{
> +	struct st_rproc *ddata = rproc->priv;
> +	int err;
> +
> +	regmap_update_bits(ddata->boot_base, ddata->boot_offset,
> +			   ddata->config->bootaddr_mask, rproc->bootaddr);
> +
> +	err = clk_enable(ddata->clk);
> +	if (err) {
> +		dev_err(&rproc->dev, "Failed to enable clock\n");
> +		return err;
> +	}
> +
> +	if (ddata->config->sw_reset) {
> +		err = reset_control_deassert(ddata->sw_reset);
> +		if (err) {
> +			dev_err(&rproc->dev, "Failed to deassert S/W Reset\n");
> +			goto sw_reset_fail;
> +		}
> +	}
> +
> +	if (ddata->config->pwr_reset) {
> +		err = reset_control_deassert(ddata->pwr_reset);
> +		if (err) {
> +			dev_err(&rproc->dev, "Failed to deassert Power Reset\n");
> +			goto pwr_reset_fail;
> +		}
> +	}
> +
> +	dev_info(&rproc->dev, "Started from 0x%x\n", rproc->bootaddr);
> +
> +	return 0;
> +
> +
> +pwr_reset_fail:
> +	if (ddata->config->pwr_reset)
> +		reset_control_assert(ddata->sw_reset);
> +sw_reset_fail:
> +	clk_disable(ddata->clk);
> +
> +	return err;
> +}
> +
> +static int st_rproc_stop(struct rproc *rproc)
> +{
> +	struct st_rproc *ddata = rproc->priv;
> +	int sw_err = 0, pwr_err = 0;
> +
> +	if (ddata->config->sw_reset) {
> +		sw_err = reset_control_assert(ddata->sw_reset);
> +		if (sw_err)
> +			dev_err(&rproc->dev, "Failed to assert S/W Reset\n");
> +	}
> +
> +	if (ddata->config->pwr_reset) {
> +		pwr_err = reset_control_assert(ddata->pwr_reset);
> +		if (pwr_err)
> +			dev_err(&rproc->dev, "Failed to assert Power Reset\n");
> +	}
> +
> +	clk_disable(ddata->clk);
> +
> +	return sw_err ?: pwr_err;
> +}
> +
> +static struct rproc_ops st_rproc_ops = {
> +	.start		= st_rproc_start,
> +	.stop		= st_rproc_stop,
> +};
> +
> +/*
> + * Fetch state of the processor: 0 is off, 1 is on.
> + */
> +static int st_rproc_state(struct platform_device *pdev)
> +{
> +	struct rproc *rproc = platform_get_drvdata(pdev);
> +	struct st_rproc *ddata = rproc->priv;
> +	int reset_sw = 0, reset_pwr = 0;
> +
> +	if (ddata->config->sw_reset)
> +		reset_sw = reset_control_status(ddata->sw_reset);
> +
> +	if (ddata->config->pwr_reset)
> +		reset_pwr = reset_control_status(ddata->pwr_reset);
> +
> +	if (reset_sw < 0 || reset_pwr < 0)
> +		return -EINVAL;
> +
> +	return !reset_sw && !reset_pwr;
> +}
> +
> +static const struct st_rproc_config st40_rproc_cfg = {
> +	.sw_reset = true,
> +	.pwr_reset = true,
> +	.bootaddr_mask = GENMASK(28, 1),
> +};
> +
> +static const struct st_rproc_config st231_rproc_cfg = {
> +	.sw_reset = true,
> +	.pwr_reset = false,
> +	.bootaddr_mask = GENMASK(31, 6),
> +};
> +
> +static const struct of_device_id st_rproc_match[] = {
> +	{ .compatible = "st,st40-rproc", .data = &st40_rproc_cfg },
> +	{ .compatible = "st,st231-rproc", .data = &st231_rproc_cfg },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, st_rproc_match);
> +
> +static int st_rproc_parse_dt(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct rproc *rproc = platform_get_drvdata(pdev);
> +	struct st_rproc *ddata = rproc->priv;
> +	struct device_node *np = dev->of_node;
> +	int err;
> +
> +	if (ddata->config->sw_reset) {
> +		ddata->sw_reset = devm_reset_control_get(dev, "sw_reset");
> +		if (IS_ERR(ddata->sw_reset)) {
> +			dev_err(dev, "Failed to get S/W Reset\n");
> +			return PTR_ERR(ddata->sw_reset);
> +		}
> +	}
> +
> +	if (ddata->config->pwr_reset) {
> +		ddata->pwr_reset = devm_reset_control_get(dev, "pwr_reset");
> +		if (IS_ERR(ddata->pwr_reset)) {
> +			dev_err(dev, "Failed to get Power Reset\n");
> +			return PTR_ERR(ddata->pwr_reset);
> +		}
> +	}
> +
> +	ddata->clk = devm_clk_get(dev, NULL);
> +	if (IS_ERR(ddata->clk)) {
> +		dev_err(dev, "Failed to get clock\n");
> +		return PTR_ERR(ddata->clk);
> +	}
> +
> +	err = of_property_read_u32(np, "clock-frequency", &ddata->clk_rate);
> +	if (err) {
> +		dev_err(dev, "failed to get clock frequency\n");
> +		return err;
> +	}
> +
> +	ddata->boot_base = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
> +	if (!ddata->boot_base) {
> +		dev_err(dev, "Boot base not found\n");
> +		return -EINVAL;
> +	}
> +
> +	err = of_property_read_u32_index(np, "st,syscfg", 1,
> +					 &ddata->boot_offset);
> +	if (err) {
> +		dev_err(dev, "Boot offset not found\n");
> +		return -EINVAL;
> +	}
> +
> +	err = of_reserved_mem_device_init(dev);
> +	if (err) {
> +		dev_err(dev, "Failed to obtain shared memory\n");
> +		return err;
> +	}
> +
> +	err = clk_prepare(ddata->clk);
> +	if (err)
> +		dev_err(dev, "failed to get clock\n");
> +
> +	return err;
> +}
> +
> +static int st_rproc_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	const struct of_device_id *match;
> +	struct st_rproc *ddata;
> +	struct device_node *np = dev->of_node;
> +	struct rproc *rproc;
> +	int enabled;
> +	int ret;
> +
> +	match = of_match_device(st_rproc_match, dev);
> +	if (!match || !match->data) {
> +		dev_err(dev, "No device match found\n");
> +		return -ENODEV;
> +	}
> +
> +	rproc = rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
> +	if (!rproc)
> +		return -ENOMEM;
> +
> +	rproc->has_iommu = false;
> +	ddata = rproc->priv;
> +	ddata->config = (struct st_rproc_config *)match->data;
> +
> +	platform_set_drvdata(pdev, rproc);
> +
> +	ret = st_rproc_parse_dt(pdev);
> +	if (ret)
> +		goto free_rproc;
> +
> +	enabled = st_rproc_state(pdev);
> +	if (enabled < 0)
> +		goto free_rproc;
> +
> +	if (enabled) {
> +		atomic_inc(&rproc->power);
> +		rproc->state = RPROC_RUNNING;
> +	} else {
> +		clk_set_rate(ddata->clk, ddata->clk_rate);
> +	}
> +
> +	ret = rproc_add(rproc);
> +	if (ret)
> +		goto free_rproc;
> +
> +	return 0;
> +
> +free_rproc:
> +	rproc_put(rproc);
> +	return ret;
> +}
> +
> +static int st_rproc_remove(struct platform_device *pdev)
> +{
> +	struct rproc *rproc = platform_get_drvdata(pdev);
> +	struct st_rproc *ddata = rproc->priv;
> +
> +	rproc_del(rproc);
> +
> +	clk_disable_unprepare(ddata->clk);
> +
> +	of_reserved_mem_device_release(&pdev->dev);
> +
> +	rproc_put(rproc);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver st_rproc_driver = {
> +	.probe = st_rproc_probe,
> +	.remove = st_rproc_remove,
> +	.driver = {
> +		.name = "st-rproc",
> +		.of_match_table = of_match_ptr(st_rproc_match),
> +	},
> +};
> +module_platform_driver(st_rproc_driver);
> +
> +MODULE_DESCRIPTION("ST Remote Processor Control Driver");
> +MODULE_AUTHOR("Ludovic Barre <ludovic.barre@st.com>");
> +MODULE_LICENSE("GPL v2");

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v5 4/7] remoteproc: Supply controller driver for ST's Remote Processors

[Lee Jones]

On Tue, 12 Jan 2016, Lee Jones wrote:

> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>

This should also have Bjorn's Ack.  Apologies for dropping it.

> ---
>  drivers/remoteproc/Kconfig         |   9 ++
>  drivers/remoteproc/Makefile        |   1 +
>  drivers/remoteproc/st_remoteproc.c | 297 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 307 insertions(+)
>  create mode 100644 drivers/remoteproc/st_remoteproc.c
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 28c711f..72e97d7 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC
>  	  It's safe to say n here if you're not interested in multimedia
>  	  offloading.
>  
> +config ST_REMOTEPROC
> +	tristate "ST remoteproc support"
> +	depends on ARCH_STI
> +	select REMOTEPROC
> +	help
> +	  Say y here to support ST's adjunct processors via the remote
> +	  processor framework.
> +	  This can be either built-in or a loadable module.
> +
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 81b04d1..279cb2e 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_OMAP_REMOTEPROC)		+= omap_remoteproc.o
>  obj-$(CONFIG_STE_MODEM_RPROC)	 	+= ste_modem_rproc.o
>  obj-$(CONFIG_WKUP_M3_RPROC)		+= wkup_m3_rproc.o
>  obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
> +obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
> diff --git a/drivers/remoteproc/st_remoteproc.c b/drivers/remoteproc/st_remoteproc.c
> new file mode 100644
> index 0000000..6bb04d4
> --- /dev/null
> +++ b/drivers/remoteproc/st_remoteproc.c
> @@ -0,0 +1,297 @@
> +/*
> + * ST's Remote Processor Control Driver
> + *
> + * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
> + *
> + * Author: Ludovic Barre <ludovic.barre@st.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/remoteproc.h>
> +#include <linux/reset.h>
> +
> +struct st_rproc_config {
> +	bool			sw_reset;
> +	bool			pwr_reset;
> +	unsigned long		bootaddr_mask;
> +};
> +
> +struct st_rproc {
> +	struct st_rproc_config	*config;
> +	struct reset_control	*sw_reset;
> +	struct reset_control	*pwr_reset;
> +	struct clk		*clk;
> +	u32			clk_rate;
> +	struct regmap		*boot_base;
> +	u32			boot_offset;
> +};
> +
> +static int st_rproc_start(struct rproc *rproc)
> +{
> +	struct st_rproc *ddata = rproc->priv;
> +	int err;
> +
> +	regmap_update_bits(ddata->boot_base, ddata->boot_offset,
> +			   ddata->config->bootaddr_mask, rproc->bootaddr);
> +
> +	err = clk_enable(ddata->clk);
> +	if (err) {
> +		dev_err(&rproc->dev, "Failed to enable clock\n");
> +		return err;
> +	}
> +
> +	if (ddata->config->sw_reset) {
> +		err = reset_control_deassert(ddata->sw_reset);
> +		if (err) {
> +			dev_err(&rproc->dev, "Failed to deassert S/W Reset\n");
> +			goto sw_reset_fail;
> +		}
> +	}
> +
> +	if (ddata->config->pwr_reset) {
> +		err = reset_control_deassert(ddata->pwr_reset);
> +		if (err) {
> +			dev_err(&rproc->dev, "Failed to deassert Power Reset\n");
> +			goto pwr_reset_fail;
> +		}
> +	}
> +
> +	dev_info(&rproc->dev, "Started from 0x%x\n", rproc->bootaddr);
> +
> +	return 0;
> +
> +
> +pwr_reset_fail:
> +	if (ddata->config->pwr_reset)
> +		reset_control_assert(ddata->sw_reset);
> +sw_reset_fail:
> +	clk_disable(ddata->clk);
> +
> +	return err;
> +}
> +
> +static int st_rproc_stop(struct rproc *rproc)
> +{
> +	struct st_rproc *ddata = rproc->priv;
> +	int sw_err = 0, pwr_err = 0;
> +
> +	if (ddata->config->sw_reset) {
> +		sw_err = reset_control_assert(ddata->sw_reset);
> +		if (sw_err)
> +			dev_err(&rproc->dev, "Failed to assert S/W Reset\n");
> +	}
> +
> +	if (ddata->config->pwr_reset) {
> +		pwr_err = reset_control_assert(ddata->pwr_reset);
> +		if (pwr_err)
> +			dev_err(&rproc->dev, "Failed to assert Power Reset\n");
> +	}
> +
> +	clk_disable(ddata->clk);
> +
> +	return sw_err ?: pwr_err;
> +}
> +
> +static struct rproc_ops st_rproc_ops = {
> +	.start		= st_rproc_start,
> +	.stop		= st_rproc_stop,
> +};
> +
> +/*
> + * Fetch state of the processor: 0 is off, 1 is on.
> + */
> +static int st_rproc_state(struct platform_device *pdev)
> +{
> +	struct rproc *rproc = platform_get_drvdata(pdev);
> +	struct st_rproc *ddata = rproc->priv;
> +	int reset_sw = 0, reset_pwr = 0;
> +
> +	if (ddata->config->sw_reset)
> +		reset_sw = reset_control_status(ddata->sw_reset);
> +
> +	if (ddata->config->pwr_reset)
> +		reset_pwr = reset_control_status(ddata->pwr_reset);
> +
> +	if (reset_sw < 0 || reset_pwr < 0)
> +		return -EINVAL;
> +
> +	return !reset_sw && !reset_pwr;
> +}
> +
> +static const struct st_rproc_config st40_rproc_cfg = {
> +	.sw_reset = true,
> +	.pwr_reset = true,
> +	.bootaddr_mask = GENMASK(28, 1),
> +};
> +
> +static const struct st_rproc_config st231_rproc_cfg = {
> +	.sw_reset = true,
> +	.pwr_reset = false,
> +	.bootaddr_mask = GENMASK(31, 6),
> +};
> +
> +static const struct of_device_id st_rproc_match[] = {
> +	{ .compatible = "st,st40-rproc", .data = &st40_rproc_cfg },
> +	{ .compatible = "st,st231-rproc", .data = &st231_rproc_cfg },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, st_rproc_match);
> +
> +static int st_rproc_parse_dt(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct rproc *rproc = platform_get_drvdata(pdev);
> +	struct st_rproc *ddata = rproc->priv;
> +	struct device_node *np = dev->of_node;
> +	int err;
> +
> +	if (ddata->config->sw_reset) {
> +		ddata->sw_reset = devm_reset_control_get(dev, "sw_reset");
> +		if (IS_ERR(ddata->sw_reset)) {
> +			dev_err(dev, "Failed to get S/W Reset\n");
> +			return PTR_ERR(ddata->sw_reset);
> +		}
> +	}
> +
> +	if (ddata->config->pwr_reset) {
> +		ddata->pwr_reset = devm_reset_control_get(dev, "pwr_reset");
> +		if (IS_ERR(ddata->pwr_reset)) {
> +			dev_err(dev, "Failed to get Power Reset\n");
> +			return PTR_ERR(ddata->pwr_reset);
> +		}
> +	}
> +
> +	ddata->clk = devm_clk_get(dev, NULL);
> +	if (IS_ERR(ddata->clk)) {
> +		dev_err(dev, "Failed to get clock\n");
> +		return PTR_ERR(ddata->clk);
> +	}
> +
> +	err = of_property_read_u32(np, "clock-frequency", &ddata->clk_rate);
> +	if (err) {
> +		dev_err(dev, "failed to get clock frequency\n");
> +		return err;
> +	}
> +
> +	ddata->boot_base = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
> +	if (!ddata->boot_base) {
> +		dev_err(dev, "Boot base not found\n");
> +		return -EINVAL;
> +	}
> +
> +	err = of_property_read_u32_index(np, "st,syscfg", 1,
> +					 &ddata->boot_offset);
> +	if (err) {
> +		dev_err(dev, "Boot offset not found\n");
> +		return -EINVAL;
> +	}
> +
> +	err = of_reserved_mem_device_init(dev);
> +	if (err) {
> +		dev_err(dev, "Failed to obtain shared memory\n");
> +		return err;
> +	}
> +
> +	err = clk_prepare(ddata->clk);
> +	if (err)
> +		dev_err(dev, "failed to get clock\n");
> +
> +	return err;
> +}
> +
> +static int st_rproc_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	const struct of_device_id *match;
> +	struct st_rproc *ddata;
> +	struct device_node *np = dev->of_node;
> +	struct rproc *rproc;
> +	int enabled;
> +	int ret;
> +
> +	match = of_match_device(st_rproc_match, dev);
> +	if (!match || !match->data) {
> +		dev_err(dev, "No device match found\n");
> +		return -ENODEV;
> +	}
> +
> +	rproc = rproc_alloc(dev, np->name, &st_rproc_ops, NULL, sizeof(*ddata));
> +	if (!rproc)
> +		return -ENOMEM;
> +
> +	rproc->has_iommu = false;
> +	ddata = rproc->priv;
> +	ddata->config = (struct st_rproc_config *)match->data;
> +
> +	platform_set_drvdata(pdev, rproc);
> +
> +	ret = st_rproc_parse_dt(pdev);
> +	if (ret)
> +		goto free_rproc;
> +
> +	enabled = st_rproc_state(pdev);
> +	if (enabled < 0)
> +		goto free_rproc;
> +
> +	if (enabled) {
> +		atomic_inc(&rproc->power);
> +		rproc->state = RPROC_RUNNING;
> +	} else {
> +		clk_set_rate(ddata->clk, ddata->clk_rate);
> +	}
> +
> +	ret = rproc_add(rproc);
> +	if (ret)
> +		goto free_rproc;
> +
> +	return 0;
> +
> +free_rproc:
> +	rproc_put(rproc);
> +	return ret;
> +}
> +
> +static int st_rproc_remove(struct platform_device *pdev)
> +{
> +	struct rproc *rproc = platform_get_drvdata(pdev);
> +	struct st_rproc *ddata = rproc->priv;
> +
> +	rproc_del(rproc);
> +
> +	clk_disable_unprepare(ddata->clk);
> +
> +	of_reserved_mem_device_release(&pdev->dev);
> +
> +	rproc_put(rproc);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver st_rproc_driver = {
> +	.probe = st_rproc_probe,
> +	.remove = st_rproc_remove,
> +	.driver = {
> +		.name = "st-rproc",
> +		.of_match_table = of_match_ptr(st_rproc_match),
> +	},
> +};
> +module_platform_driver(st_rproc_driver);
> +
> +MODULE_DESCRIPTION("ST Remote Processor Control Driver");
> +MODULE_AUTHOR("Ludovic Barre <ludovic.barre@st.com>");
> +MODULE_LICENSE("GPL v2");

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [STLinux Kernel] [PATCH v5 4/7] remoteproc: Supply controller driver for ST's Remote Processors

[Peter Griffin]

On Tue, 12 Jan 2016, Lee Jones wrote:

> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  drivers/remoteproc/Kconfig         |   9 ++
>  drivers/remoteproc/Makefile        |   1 +
>  drivers/remoteproc/st_remoteproc.c | 297 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 307 insertions(+)
>  create mode 100644 drivers/remoteproc/st_remoteproc.c

Acked-by: Peter Griffin <peter.griffin@linaro.org>

regards,

Peter.

[STLinux Kernel] [PATCH v5 4/7] remoteproc: Supply controller driver for ST's Remote Processors

[Peter Griffin]

On Tue, 12 Jan 2016, Lee Jones wrote:

> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  drivers/remoteproc/Kconfig         |   9 ++
>  drivers/remoteproc/Makefile        |   1 +
>  drivers/remoteproc/st_remoteproc.c | 297 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 307 insertions(+)
>  create mode 100644 drivers/remoteproc/st_remoteproc.c

Acked-by: Peter Griffin <peter.griffin@linaro.org>

regards,

Peter.

[PATCH v5 5/7] MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE

[Lee Jones]

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5f46784..322f5b4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1538,6 +1538,7 @@ F:	drivers/phy/phy-miphy365x.c
 F:	drivers/phy/phy-stih407-usb.c
 F:	drivers/phy/phy-stih41x-usb.c
 F:	drivers/pinctrl/pinctrl-st.c
+F:	drivers/remoteproc/st_remoteproc.c
 F:	drivers/reset/sti/
 F:	drivers/rtc/rtc-st-lpc.c
 F:	drivers/tty/serial/st-asc.c
-- 
1.9.1

[PATCH v5 5/7] MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE

[Lee Jones]

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5f46784..322f5b4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1538,6 +1538,7 @@ F:	drivers/phy/phy-miphy365x.c
 F:	drivers/phy/phy-stih407-usb.c
 F:	drivers/phy/phy-stih41x-usb.c
 F:	drivers/pinctrl/pinctrl-st.c
+F:	drivers/remoteproc/st_remoteproc.c
 F:	drivers/reset/sti/
 F:	drivers/rtc/rtc-st-lpc.c
 F:	drivers/tty/serial/st-asc.c
-- 
1.9.1

[PATCH v5 5/7] MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE

[Lee Jones]

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5f46784..322f5b4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1538,6 +1538,7 @@ F:	drivers/phy/phy-miphy365x.c
 F:	drivers/phy/phy-stih407-usb.c
 F:	drivers/phy/phy-stih41x-usb.c
 F:	drivers/pinctrl/pinctrl-st.c
+F:	drivers/remoteproc/st_remoteproc.c
 F:	drivers/reset/sti/
 F:	drivers/rtc/rtc-st-lpc.c
 F:	drivers/tty/serial/st-asc.c
-- 
1.9.1

Re: [STLinux Kernel] [PATCH v5 5/7] MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE

[Peter Griffin]

On Tue, 12 Jan 2016, Lee Jones wrote:

> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Peter Griffin <peter.griffin@linaro.org>

[STLinux Kernel] [PATCH v5 5/7] MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE

[Peter Griffin]

On Tue, 12 Jan 2016, Lee Jones wrote:

> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Peter Griffin <peter.griffin@linaro.org>

[PATCH v5 6/7] ARM: STiH407: Add nodes for RemoteProc

[Lee Jones]

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 40 +++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 1e4e01925..15c20b6 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -650,5 +650,45 @@
 			mbox-name	= "st231_audio_video";
 			status		= "okay";
 		};
+
+		st231_gp0: st231-gp0@40000000 {
+			compatible	= "st,st231-rproc";
+			reg		= <0x40000000 0x01000000>;
+			resets		= <&softreset STIH407_ST231_GP0_SOFTRESET>;
+			reset-names	= "sw_reset";
+			clocks		= <&clk_s_c0_flexgen CLK_ST231_GP_0>;
+			clock-frequency	= <600000000>;
+			st,syscfg	= <&syscfg_core 0x22c>;
+		};
+
+		st231_gp1: st231-gp1@41000000 {
+			compatible	= "st,st231-rproc";
+			reg		= <0x41000000 0x01000000>;
+			resets		= <&softreset STIH407_ST231_GP1_SOFTRESET>;
+			reset-names	= "sw_reset";
+			clocks		= <&clk_s_c0_flexgen CLK_ST231_GP_1>;
+			clock-frequency = <600000000>;
+			st,syscfg	= <&syscfg_core 0x220>;
+		};
+
+		st231_audio: st231-audio@42000000 {
+			compatible	= "st,st231-rproc";
+			reg		= <0x42000000 0x01000000>;
+			resets		= <&softreset STIH407_ST231_AUD_SOFTRESET>;
+			reset-names	= "sw_reset";
+			clocks		= <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
+			clock-frequency	= <600000000>;
+			st,syscfg	= <&syscfg_core 0x228>;
+		};
+
+		st231_dmu: st231-dmu@43000000 {
+			compatible	= "st,st231-rproc";
+			reg		= <0x43000000 0x01000000>;
+			resets		= <&softreset STIH407_ST231_DMU_SOFTRESET>;
+			reset-names	= "sw_reset";
+			clocks		= <&clk_s_c0_flexgen CLK_ST231_DMU>;
+			clock-frequency	= <600000000>;
+			st,syscfg	= <&syscfg_core 0x224>;
+		};
 	};
 };
-- 
1.9.1

[PATCH v5 6/7] ARM: STiH407: Add nodes for RemoteProc

[Lee Jones]

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 40 +++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 1e4e01925..15c20b6 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -650,5 +650,45 @@
 			mbox-name	= "st231_audio_video";
 			status		= "okay";
 		};
+
+		st231_gp0: st231-gp0 at 40000000 {
+			compatible	= "st,st231-rproc";
+			reg		= <0x40000000 0x01000000>;
+			resets		= <&softreset STIH407_ST231_GP0_SOFTRESET>;
+			reset-names	= "sw_reset";
+			clocks		= <&clk_s_c0_flexgen CLK_ST231_GP_0>;
+			clock-frequency	= <600000000>;
+			st,syscfg	= <&syscfg_core 0x22c>;
+		};
+
+		st231_gp1: st231-gp1 at 41000000 {
+			compatible	= "st,st231-rproc";
+			reg		= <0x41000000 0x01000000>;
+			resets		= <&softreset STIH407_ST231_GP1_SOFTRESET>;
+			reset-names	= "sw_reset";
+			clocks		= <&clk_s_c0_flexgen CLK_ST231_GP_1>;
+			clock-frequency = <600000000>;
+			st,syscfg	= <&syscfg_core 0x220>;
+		};
+
+		st231_audio: st231-audio at 42000000 {
+			compatible	= "st,st231-rproc";
+			reg		= <0x42000000 0x01000000>;
+			resets		= <&softreset STIH407_ST231_AUD_SOFTRESET>;
+			reset-names	= "sw_reset";
+			clocks		= <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
+			clock-frequency	= <600000000>;
+			st,syscfg	= <&syscfg_core 0x228>;
+		};
+
+		st231_dmu: st231-dmu at 43000000 {
+			compatible	= "st,st231-rproc";
+			reg		= <0x43000000 0x01000000>;
+			resets		= <&softreset STIH407_ST231_DMU_SOFTRESET>;
+			reset-names	= "sw_reset";
+			clocks		= <&clk_s_c0_flexgen CLK_ST231_DMU>;
+			clock-frequency	= <600000000>;
+			st,syscfg	= <&syscfg_core 0x224>;
+		};
 	};
 };
-- 
1.9.1

Re: [PATCH v5 6/7] ARM: STiH407: Add nodes for RemoteProc

[Olof Johansson]

Hi,

On Tue, Jan 12, 2016 at 4:46 AM, Lee Jones <lee.jones@linaro.org> wrote:
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 40 +++++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index 1e4e01925..15c20b6 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -650,5 +650,45 @@
>                         mbox-name       = "st231_audio_video";
>                         status          = "okay";
>                 };
> +
> +               st231_gp0: st231-gp0@40000000 {

These node names seem odd. Should probably be more generic
"remoteproc@40000000".

> +                       compatible      = "st,st231-rproc";
> +                       reg             = <0x40000000 0x01000000>;

This isn't what the binding says, it uses a memory region instead.



-Olof

[PATCH v5 6/7] ARM: STiH407: Add nodes for RemoteProc

[Olof Johansson]

Hi,

On Tue, Jan 12, 2016 at 4:46 AM, Lee Jones <lee.jones@linaro.org> wrote:
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 40 +++++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index 1e4e01925..15c20b6 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -650,5 +650,45 @@
>                         mbox-name       = "st231_audio_video";
>                         status          = "okay";
>                 };
> +
> +               st231_gp0: st231-gp0 at 40000000 {

These node names seem odd. Should probably be more generic
"remoteproc at 40000000".

> +                       compatible      = "st,st231-rproc";
> +                       reg             = <0x40000000 0x01000000>;

This isn't what the binding says, it uses a memory region instead.



-Olof

Re: [PATCH v5 6/7] ARM: STiH407: Add nodes for RemoteProc

[Olof Johansson]

Hi,

On Tue, Jan 12, 2016 at 4:46 AM, Lee Jones <lee.jones@linaro.org> wrote:
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 40 +++++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index 1e4e01925..15c20b6 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -650,5 +650,45 @@
>                         mbox-name       = "st231_audio_video";
>                         status          = "okay";
>                 };
> +
> +               st231_gp0: st231-gp0@40000000 {

These node names seem odd. Should probably be more generic
"remoteproc@40000000".

> +                       compatible      = "st,st231-rproc";
> +                       reg             = <0x40000000 0x01000000>;

This isn't what the binding says, it uses a memory region instead.



-Olof

[PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Lee Jones]

Doing so saves quite a bit of code in the driver.

For more information on the 'reserved-memory' bindings see:

  Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt

Suggested-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 46 +++++++++++++++++++++++++++++------
 1 file changed, 38 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 15c20b6..27b8efc 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -15,6 +15,36 @@
 	#address-cells = <1>;
 	#size-cells = <1>;
 
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		gp0_reserved: rproc@40000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x40000000 0x01000000>;
+			no-map;
+		};
+
+		gp1_reserved: rproc@41000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x41000000 0x01000000>;
+			no-map;
+		};
+
+		audio_reserved: rproc@42000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x42000000 0x01000000>;
+			no-map;
+		};
+
+		dmu_reserved: rproc@43000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x43000000 0x01000000>;
+			no-map;
+		};
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
@@ -651,9 +681,9 @@
 			status		= "okay";
 		};
 
-		st231_gp0: st231-gp0@40000000 {
+		st231_gp0: st231-gp0 {
 			compatible	= "st,st231-rproc";
-			reg		= <0x40000000 0x01000000>;
+			memory-region	= <&gp0_reserved>;
 			resets		= <&softreset STIH407_ST231_GP0_SOFTRESET>;
 			reset-names	= "sw_reset";
 			clocks		= <&clk_s_c0_flexgen CLK_ST231_GP_0>;
@@ -661,9 +691,9 @@
 			st,syscfg	= <&syscfg_core 0x22c>;
 		};
 
-		st231_gp1: st231-gp1@41000000 {
+		st231_gp1: st231-gp1 {
 			compatible	= "st,st231-rproc";
-			reg		= <0x41000000 0x01000000>;
+			memory-region	= <&gp1_reserved>;
 			resets		= <&softreset STIH407_ST231_GP1_SOFTRESET>;
 			reset-names	= "sw_reset";
 			clocks		= <&clk_s_c0_flexgen CLK_ST231_GP_1>;
@@ -671,9 +701,9 @@
 			st,syscfg	= <&syscfg_core 0x220>;
 		};
 
-		st231_audio: st231-audio@42000000 {
+		st231_audio: st231-audio {
 			compatible	= "st,st231-rproc";
-			reg		= <0x42000000 0x01000000>;
+			memory-region	= <&audio_reserved>;
 			resets		= <&softreset STIH407_ST231_AUD_SOFTRESET>;
 			reset-names	= "sw_reset";
 			clocks		= <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
@@ -681,9 +711,9 @@
 			st,syscfg	= <&syscfg_core 0x228>;
 		};
 
-		st231_dmu: st231-dmu@43000000 {
+		st231_dmu: st231-dmu {
 			compatible	= "st,st231-rproc";
-			reg		= <0x43000000 0x01000000>;
+			memory-region	= <&dmu_reserved>;
 			resets		= <&softreset STIH407_ST231_DMU_SOFTRESET>;
 			reset-names	= "sw_reset";
 			clocks		= <&clk_s_c0_flexgen CLK_ST231_DMU>;
-- 
1.9.1

[PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Lee Jones]

Doing so saves quite a bit of code in the driver.

For more information on the 'reserved-memory' bindings see:

  Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt

Suggested-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 46 +++++++++++++++++++++++++++++------
 1 file changed, 38 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 15c20b6..27b8efc 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -15,6 +15,36 @@
 	#address-cells = <1>;
 	#size-cells = <1>;
 
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		gp0_reserved: rproc at 40000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x40000000 0x01000000>;
+			no-map;
+		};
+
+		gp1_reserved: rproc at 41000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x41000000 0x01000000>;
+			no-map;
+		};
+
+		audio_reserved: rproc at 42000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x42000000 0x01000000>;
+			no-map;
+		};
+
+		dmu_reserved: rproc at 43000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x43000000 0x01000000>;
+			no-map;
+		};
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
@@ -651,9 +681,9 @@
 			status		= "okay";
 		};
 
-		st231_gp0: st231-gp0 at 40000000 {
+		st231_gp0: st231-gp0 {
 			compatible	= "st,st231-rproc";
-			reg		= <0x40000000 0x01000000>;
+			memory-region	= <&gp0_reserved>;
 			resets		= <&softreset STIH407_ST231_GP0_SOFTRESET>;
 			reset-names	= "sw_reset";
 			clocks		= <&clk_s_c0_flexgen CLK_ST231_GP_0>;
@@ -661,9 +691,9 @@
 			st,syscfg	= <&syscfg_core 0x22c>;
 		};
 
-		st231_gp1: st231-gp1 at 41000000 {
+		st231_gp1: st231-gp1 {
 			compatible	= "st,st231-rproc";
-			reg		= <0x41000000 0x01000000>;
+			memory-region	= <&gp1_reserved>;
 			resets		= <&softreset STIH407_ST231_GP1_SOFTRESET>;
 			reset-names	= "sw_reset";
 			clocks		= <&clk_s_c0_flexgen CLK_ST231_GP_1>;
@@ -671,9 +701,9 @@
 			st,syscfg	= <&syscfg_core 0x220>;
 		};
 
-		st231_audio: st231-audio at 42000000 {
+		st231_audio: st231-audio {
 			compatible	= "st,st231-rproc";
-			reg		= <0x42000000 0x01000000>;
+			memory-region	= <&audio_reserved>;
 			resets		= <&softreset STIH407_ST231_AUD_SOFTRESET>;
 			reset-names	= "sw_reset";
 			clocks		= <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
@@ -681,9 +711,9 @@
 			st,syscfg	= <&syscfg_core 0x228>;
 		};
 
-		st231_dmu: st231-dmu at 43000000 {
+		st231_dmu: st231-dmu {
 			compatible	= "st,st231-rproc";
-			reg		= <0x43000000 0x01000000>;
+			memory-region	= <&dmu_reserved>;
 			resets		= <&softreset STIH407_ST231_DMU_SOFTRESET>;
 			reset-names	= "sw_reset";
 			clocks		= <&clk_s_c0_flexgen CLK_ST231_DMU>;
-- 
1.9.1

Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Peter Griffin]

Hi Lee,

On Tue, 12 Jan 2016, Lee Jones wrote:

> Doing so saves quite a bit of code in the driver.
> 
> For more information on the 'reserved-memory' bindings see:
> 
>   Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> 
> Suggested-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 46 +++++++++++++++++++++++++++++------
>  1 file changed, 38 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index 15c20b6..27b8efc 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -15,6 +15,36 @@
>  	#address-cells = <1>;
>  	#size-cells = <1>;
>  
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		gp0_reserved: rproc@40000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x40000000 0x01000000>;
> +			no-map;
> +		};
> +
> +		gp1_reserved: rproc@41000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x41000000 0x01000000>;
> +			no-map;
> +		};
> +
> +		audio_reserved: rproc@42000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x42000000 0x01000000>;
> +			no-map;
> +		};
> +
> +		dmu_reserved: rproc@43000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x43000000 0x01000000>;
> +			no-map;
> +		};

I don't believe these reserved memory ranges are correct for audio_reserved and dmu_reserved.

For example my vid_firmware-stih407.elf is linked at 0x41c00000 base address and my
audio_firmware-bd-stih407.elf is linked at 0x40c00000.

So with all the st231 rproc nodes enabled I guess it would still work. But
currently I think st231_gp0 is reserving the memory region for st231_audio,
and st231-gp1 is reserving the memory region for st231_dmu.

regards,

Peter.

[STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Peter Griffin]

Hi Lee,

On Tue, 12 Jan 2016, Lee Jones wrote:

> Doing so saves quite a bit of code in the driver.
> 
> For more information on the 'reserved-memory' bindings see:
> 
>   Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> 
> Suggested-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 46 +++++++++++++++++++++++++++++------
>  1 file changed, 38 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index 15c20b6..27b8efc 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -15,6 +15,36 @@
>  	#address-cells = <1>;
>  	#size-cells = <1>;
>  
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		gp0_reserved: rproc at 40000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x40000000 0x01000000>;
> +			no-map;
> +		};
> +
> +		gp1_reserved: rproc at 41000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x41000000 0x01000000>;
> +			no-map;
> +		};
> +
> +		audio_reserved: rproc at 42000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x42000000 0x01000000>;
> +			no-map;
> +		};
> +
> +		dmu_reserved: rproc at 43000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x43000000 0x01000000>;
> +			no-map;
> +		};

I don't believe these reserved memory ranges are correct for audio_reserved and dmu_reserved.

For example my vid_firmware-stih407.elf is linked at 0x41c00000 base address and my
audio_firmware-bd-stih407.elf is linked at 0x40c00000.

So with all the st231 rproc nodes enabled I guess it would still work. But
currently I think st231_gp0 is reserving the memory region for st231_audio,
and st231-gp1 is reserving the memory region for st231_dmu.

regards,

Peter.

Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Peter Griffin]

Hi Lee,

On Tue, 12 Jan 2016, Lee Jones wrote:

> Doing so saves quite a bit of code in the driver.
> 
> For more information on the 'reserved-memory' bindings see:
> 
>   Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> 
> Suggested-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 46 +++++++++++++++++++++++++++++------
>  1 file changed, 38 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index 15c20b6..27b8efc 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -15,6 +15,36 @@
>  	#address-cells = <1>;
>  	#size-cells = <1>;
>  
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		gp0_reserved: rproc@40000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x40000000 0x01000000>;
> +			no-map;
> +		};
> +
> +		gp1_reserved: rproc@41000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x41000000 0x01000000>;
> +			no-map;
> +		};
> +
> +		audio_reserved: rproc@42000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x42000000 0x01000000>;
> +			no-map;
> +		};
> +
> +		dmu_reserved: rproc@43000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x43000000 0x01000000>;
> +			no-map;
> +		};

I don't believe these reserved memory ranges are correct for audio_reserved and dmu_reserved.

For example my vid_firmware-stih407.elf is linked at 0x41c00000 base address and my
audio_firmware-bd-stih407.elf is linked at 0x40c00000.

So with all the st231 rproc nodes enabled I guess it would still work. But
currently I think st231_gp0 is reserving the memory region for st231_audio,
and st231-gp1 is reserving the memory region for st231_dmu.

regards,

Peter.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Lee Jones]

On Wed, 16 Mar 2016, Peter Griffin wrote:

> Hi Lee,
> 
> On Tue, 12 Jan 2016, Lee Jones wrote:
> 
> > Doing so saves quite a bit of code in the driver.
> > 
> > For more information on the 'reserved-memory' bindings see:
> > 
> >   Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> > 
> > Suggested-by: Suman Anna <s-anna@ti.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> >  arch/arm/boot/dts/stih407-family.dtsi | 46 +++++++++++++++++++++++++++++------
> >  1 file changed, 38 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> > index 15c20b6..27b8efc 100644
> > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > @@ -15,6 +15,36 @@
> >  	#address-cells = <1>;
> >  	#size-cells = <1>;
> >  
> > +	reserved-memory {
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		ranges;
> > +
> > +		gp0_reserved: rproc@40000000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x40000000 0x01000000>;
> > +			no-map;
> > +		};
> > +
> > +		gp1_reserved: rproc@41000000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x41000000 0x01000000>;
> > +			no-map;
> > +		};
> > +
> > +		audio_reserved: rproc@42000000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x42000000 0x01000000>;
> > +			no-map;
> > +		};
> > +
> > +		dmu_reserved: rproc@43000000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x43000000 0x01000000>;
> > +			no-map;
> > +		};
> 
> I don't believe these reserved memory ranges are correct for audio_reserved and dmu_reserved.
> 
> For example my vid_firmware-stih407.elf is linked at 0x41c00000 base address and my
> audio_firmware-bd-stih407.elf is linked at 0x40c00000.
> 
> So with all the st231 rproc nodes enabled I guess it would still work. But
> currently I think st231_gp0 is reserving the memory region for st231_audio,
> and st231-gp1 is reserving the memory region for st231_dmu.

These addresses are taken from internally tested code.  I don't have
access to the LMI layout documentation (if it even exists) so can't
check for myself.  Isn't this just DDR anyway?  So in theory we can
configure each devices' slice where ever we feel is appropriate?  How
is memory allocated to the DMU and Audio drivers?  Do you have scripts
which link the aforementioned binaries?

If you think there is an issue, I suggest the best thing to do is ping
Ludovic, since he is the author of the original code.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Lee Jones]

On Wed, 16 Mar 2016, Peter Griffin wrote:

> Hi Lee,
> 
> On Tue, 12 Jan 2016, Lee Jones wrote:
> 
> > Doing so saves quite a bit of code in the driver.
> > 
> > For more information on the 'reserved-memory' bindings see:
> > 
> >   Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> > 
> > Suggested-by: Suman Anna <s-anna@ti.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> >  arch/arm/boot/dts/stih407-family.dtsi | 46 +++++++++++++++++++++++++++++------
> >  1 file changed, 38 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> > index 15c20b6..27b8efc 100644
> > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > @@ -15,6 +15,36 @@
> >  	#address-cells = <1>;
> >  	#size-cells = <1>;
> >  
> > +	reserved-memory {
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		ranges;
> > +
> > +		gp0_reserved: rproc at 40000000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x40000000 0x01000000>;
> > +			no-map;
> > +		};
> > +
> > +		gp1_reserved: rproc at 41000000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x41000000 0x01000000>;
> > +			no-map;
> > +		};
> > +
> > +		audio_reserved: rproc at 42000000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x42000000 0x01000000>;
> > +			no-map;
> > +		};
> > +
> > +		dmu_reserved: rproc at 43000000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x43000000 0x01000000>;
> > +			no-map;
> > +		};
> 
> I don't believe these reserved memory ranges are correct for audio_reserved and dmu_reserved.
> 
> For example my vid_firmware-stih407.elf is linked at 0x41c00000 base address and my
> audio_firmware-bd-stih407.elf is linked at 0x40c00000.
> 
> So with all the st231 rproc nodes enabled I guess it would still work. But
> currently I think st231_gp0 is reserving the memory region for st231_audio,
> and st231-gp1 is reserving the memory region for st231_dmu.

These addresses are taken from internally tested code.  I don't have
access to the LMI layout documentation (if it even exists) so can't
check for myself.  Isn't this just DDR anyway?  So in theory we can
configure each devices' slice where ever we feel is appropriate?  How
is memory allocated to the DMU and Audio drivers?  Do you have scripts
which link the aforementioned binaries?

If you think there is an issue, I suggest the best thing to do is ping
Ludovic, since he is the author of the original code.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Lee Jones]

On Wed, 16 Mar 2016, Peter Griffin wrote:

> Hi Lee,
> 
> On Tue, 12 Jan 2016, Lee Jones wrote:
> 
> > Doing so saves quite a bit of code in the driver.
> > 
> > For more information on the 'reserved-memory' bindings see:
> > 
> >   Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> > 
> > Suggested-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
> > Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > ---
> >  arch/arm/boot/dts/stih407-family.dtsi | 46 +++++++++++++++++++++++++++++------
> >  1 file changed, 38 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> > index 15c20b6..27b8efc 100644
> > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > @@ -15,6 +15,36 @@
> >  	#address-cells = <1>;
> >  	#size-cells = <1>;
> >  
> > +	reserved-memory {
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		ranges;
> > +
> > +		gp0_reserved: rproc@40000000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x40000000 0x01000000>;
> > +			no-map;
> > +		};
> > +
> > +		gp1_reserved: rproc@41000000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x41000000 0x01000000>;
> > +			no-map;
> > +		};
> > +
> > +		audio_reserved: rproc@42000000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x42000000 0x01000000>;
> > +			no-map;
> > +		};
> > +
> > +		dmu_reserved: rproc@43000000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0x43000000 0x01000000>;
> > +			no-map;
> > +		};
> 
> I don't believe these reserved memory ranges are correct for audio_reserved and dmu_reserved.
> 
> For example my vid_firmware-stih407.elf is linked at 0x41c00000 base address and my
> audio_firmware-bd-stih407.elf is linked at 0x40c00000.
> 
> So with all the st231 rproc nodes enabled I guess it would still work. But
> currently I think st231_gp0 is reserving the memory region for st231_audio,
> and st231-gp1 is reserving the memory region for st231_dmu.

These addresses are taken from internally tested code.  I don't have
access to the LMI layout documentation (if it even exists) so can't
check for myself.  Isn't this just DDR anyway?  So in theory we can
configure each devices' slice where ever we feel is appropriate?  How
is memory allocated to the DMU and Audio drivers?  Do you have scripts
which link the aforementioned binaries?

If you think there is an issue, I suggest the best thing to do is ping
Ludovic, since he is the author of the original code.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Peter Griffin]

Hi Lee,

On Wed, 16 Mar 2016, Lee Jones wrote:

> On Wed, 16 Mar 2016, Peter Griffin wrote:
> 
> > Hi Lee,
> > 
> > On Tue, 12 Jan 2016, Lee Jones wrote:
> > 
> > > Doing so saves quite a bit of code in the driver.
> > > 
> > > For more information on the 'reserved-memory' bindings see:
> > > 
> > >   Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> > > 
> > > Suggested-by: Suman Anna <s-anna@ti.com>
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > ---
> > >  arch/arm/boot/dts/stih407-family.dtsi | 46 +++++++++++++++++++++++++++++------
> > >  1 file changed, 38 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> > > index 15c20b6..27b8efc 100644
> > > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > > @@ -15,6 +15,36 @@
> > >  	#address-cells = <1>;
> > >  	#size-cells = <1>;
> > >  
> > > +	reserved-memory {
> > > +		#address-cells = <1>;
> > > +		#size-cells = <1>;
> > > +		ranges;
> > > +
> > > +		gp0_reserved: rproc@40000000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x40000000 0x01000000>;
> > > +			no-map;
> > > +		};
> > > +
> > > +		gp1_reserved: rproc@41000000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x41000000 0x01000000>;
> > > +			no-map;
> > > +		};
> > > +
> > > +		audio_reserved: rproc@42000000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x42000000 0x01000000>;
> > > +			no-map;
> > > +		};
> > > +
> > > +		dmu_reserved: rproc@43000000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x43000000 0x01000000>;
> > > +			no-map;
> > > +		};
> > 
> > I don't believe these reserved memory ranges are correct for audio_reserved and dmu_reserved.
> > 
> > For example my vid_firmware-stih407.elf is linked at 0x41c00000 base address and my
> > audio_firmware-bd-stih407.elf is linked at 0x40c00000.
> > 
> > So with all the st231 rproc nodes enabled I guess it would still work. But
> > currently I think st231_gp0 is reserving the memory region for st231_audio,
> > and st231-gp1 is reserving the memory region for st231_dmu.
> 
> These addresses are taken from internally tested code. 

Yes I did check the internal kernel, it would appear to be wrong there as
well. One of the joys of mailing list code review I guess :-)

> I don't have
> access to the LMI layout documentation (if it even exists) so can't
> check for myself.

>  Isn't this just DDR anyway? 

Yes it is DDR

> So in theory we can
> configure each devices' slice where ever we feel is appropriate? 

Nope. The st231 audio and video firmwares are provided by ST as binary blobs and
aren't AFAIK compiled as position independent code. So the reserved-memory region
needs to match where the firmware has been linked to run from.

> How
> is memory allocated to the DMU and Audio drivers?  Do you have scripts
> which link the aforementioned binaries?

I don't have any scripts, firmware source code or even a st200 toolset.

> 
> If you think there is an issue, I suggest the best thing to do is ping
> Ludovic, since he is the author of the original code.

Ok I will ping Ludovic and point him at this thread.

I think maybe the internal kernel rproc driver was only used to reserve memory,
manage clocks, and co-processor reset / power lines, and multicom actually
loaded the firmware elf file.

The reason for coming to that conclusion is that if rproc driver was loading the
firmware I can't see how you would end up with a correctly booted co-processor
with a reserved-memory node which doesn't match up with where the firmware is linked to
run from.

Did you manage to boot audio or video co-pro successfully with the dt nodes as
they currently are in this patch?

regards,

Peter.

[STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Peter Griffin]

Hi Lee,

On Wed, 16 Mar 2016, Lee Jones wrote:

> On Wed, 16 Mar 2016, Peter Griffin wrote:
> 
> > Hi Lee,
> > 
> > On Tue, 12 Jan 2016, Lee Jones wrote:
> > 
> > > Doing so saves quite a bit of code in the driver.
> > > 
> > > For more information on the 'reserved-memory' bindings see:
> > > 
> > >   Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> > > 
> > > Suggested-by: Suman Anna <s-anna@ti.com>
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > ---
> > >  arch/arm/boot/dts/stih407-family.dtsi | 46 +++++++++++++++++++++++++++++------
> > >  1 file changed, 38 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> > > index 15c20b6..27b8efc 100644
> > > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > > @@ -15,6 +15,36 @@
> > >  	#address-cells = <1>;
> > >  	#size-cells = <1>;
> > >  
> > > +	reserved-memory {
> > > +		#address-cells = <1>;
> > > +		#size-cells = <1>;
> > > +		ranges;
> > > +
> > > +		gp0_reserved: rproc at 40000000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x40000000 0x01000000>;
> > > +			no-map;
> > > +		};
> > > +
> > > +		gp1_reserved: rproc at 41000000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x41000000 0x01000000>;
> > > +			no-map;
> > > +		};
> > > +
> > > +		audio_reserved: rproc at 42000000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x42000000 0x01000000>;
> > > +			no-map;
> > > +		};
> > > +
> > > +		dmu_reserved: rproc at 43000000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x43000000 0x01000000>;
> > > +			no-map;
> > > +		};
> > 
> > I don't believe these reserved memory ranges are correct for audio_reserved and dmu_reserved.
> > 
> > For example my vid_firmware-stih407.elf is linked at 0x41c00000 base address and my
> > audio_firmware-bd-stih407.elf is linked at 0x40c00000.
> > 
> > So with all the st231 rproc nodes enabled I guess it would still work. But
> > currently I think st231_gp0 is reserving the memory region for st231_audio,
> > and st231-gp1 is reserving the memory region for st231_dmu.
> 
> These addresses are taken from internally tested code. 

Yes I did check the internal kernel, it would appear to be wrong there as
well. One of the joys of mailing list code review I guess :-)

> I don't have
> access to the LMI layout documentation (if it even exists) so can't
> check for myself.

>  Isn't this just DDR anyway? 

Yes it is DDR

> So in theory we can
> configure each devices' slice where ever we feel is appropriate? 

Nope. The st231 audio and video firmwares are provided by ST as binary blobs and
aren't AFAIK compiled as position independent code. So the reserved-memory region
needs to match where the firmware has been linked to run from.

> How
> is memory allocated to the DMU and Audio drivers?  Do you have scripts
> which link the aforementioned binaries?

I don't have any scripts, firmware source code or even a st200 toolset.

> 
> If you think there is an issue, I suggest the best thing to do is ping
> Ludovic, since he is the author of the original code.

Ok I will ping Ludovic and point him at this thread.

I think maybe the internal kernel rproc driver was only used to reserve memory,
manage clocks, and co-processor reset / power lines, and multicom actually
loaded the firmware elf file.

The reason for coming to that conclusion is that if rproc driver was loading the
firmware I can't see how you would end up with a correctly booted co-processor
with a reserved-memory node which doesn't match up with where the firmware is linked to
run from.

Did you manage to boot audio or video co-pro successfully with the dt nodes as
they currently are in this patch?

regards,

Peter.

Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Peter Griffin]

Hi Lee,

On Wed, 16 Mar 2016, Lee Jones wrote:

> On Wed, 16 Mar 2016, Peter Griffin wrote:
> 
> > Hi Lee,
> > 
> > On Tue, 12 Jan 2016, Lee Jones wrote:
> > 
> > > Doing so saves quite a bit of code in the driver.
> > > 
> > > For more information on the 'reserved-memory' bindings see:
> > > 
> > >   Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> > > 
> > > Suggested-by: Suman Anna <s-anna@ti.com>
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > ---
> > >  arch/arm/boot/dts/stih407-family.dtsi | 46 +++++++++++++++++++++++++++++------
> > >  1 file changed, 38 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> > > index 15c20b6..27b8efc 100644
> > > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > > @@ -15,6 +15,36 @@
> > >  	#address-cells = <1>;
> > >  	#size-cells = <1>;
> > >  
> > > +	reserved-memory {
> > > +		#address-cells = <1>;
> > > +		#size-cells = <1>;
> > > +		ranges;
> > > +
> > > +		gp0_reserved: rproc@40000000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x40000000 0x01000000>;
> > > +			no-map;
> > > +		};
> > > +
> > > +		gp1_reserved: rproc@41000000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x41000000 0x01000000>;
> > > +			no-map;
> > > +		};
> > > +
> > > +		audio_reserved: rproc@42000000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x42000000 0x01000000>;
> > > +			no-map;
> > > +		};
> > > +
> > > +		dmu_reserved: rproc@43000000 {
> > > +			compatible = "shared-dma-pool";
> > > +			reg = <0x43000000 0x01000000>;
> > > +			no-map;
> > > +		};
> > 
> > I don't believe these reserved memory ranges are correct for audio_reserved and dmu_reserved.
> > 
> > For example my vid_firmware-stih407.elf is linked at 0x41c00000 base address and my
> > audio_firmware-bd-stih407.elf is linked at 0x40c00000.
> > 
> > So with all the st231 rproc nodes enabled I guess it would still work. But
> > currently I think st231_gp0 is reserving the memory region for st231_audio,
> > and st231-gp1 is reserving the memory region for st231_dmu.
> 
> These addresses are taken from internally tested code. 

Yes I did check the internal kernel, it would appear to be wrong there as
well. One of the joys of mailing list code review I guess :-)

> I don't have
> access to the LMI layout documentation (if it even exists) so can't
> check for myself.

>  Isn't this just DDR anyway? 

Yes it is DDR

> So in theory we can
> configure each devices' slice where ever we feel is appropriate? 

Nope. The st231 audio and video firmwares are provided by ST as binary blobs and
aren't AFAIK compiled as position independent code. So the reserved-memory region
needs to match where the firmware has been linked to run from.

> How
> is memory allocated to the DMU and Audio drivers?  Do you have scripts
> which link the aforementioned binaries?

I don't have any scripts, firmware source code or even a st200 toolset.

> 
> If you think there is an issue, I suggest the best thing to do is ping
> Ludovic, since he is the author of the original code.

Ok I will ping Ludovic and point him at this thread.

I think maybe the internal kernel rproc driver was only used to reserve memory,
manage clocks, and co-processor reset / power lines, and multicom actually
loaded the firmware elf file.

The reason for coming to that conclusion is that if rproc driver was loading the
firmware I can't see how you would end up with a correctly booted co-processor
with a reserved-memory node which doesn't match up with where the firmware is linked to
run from.

Did you manage to boot audio or video co-pro successfully with the dt nodes as
they currently are in this patch?

regards,

Peter.

RE: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Loic PALLARDY]

Hi Lee, Pete,

The coprocessor memory map defined below is for test. Addresses have been arbitrary fixed.
The audio and video firmware you want to use are for product configuration.
For sure memory mapping must be adapted or firmware recompiled.

About coherency between firmware characteristics (linked address, position independent or not, size) and DT definition, you're right, some checks are missing in this version. It shouldn't be possible to load/start a firmware if DT reserved memory is not aligned with firmware resource table and firmware start address.

Lee, I propose to have a short discussion during next ST LT weekly meeting to list missing features and identify ST internal remoteproc patches for upstream.

Regards,
Loic

> -----Original Message-----
> From: Peter Griffin [mailto:peter.griffin@linaro.org]
> Sent: Wednesday, March 16, 2016 9:11 PM
> To: Lee Jones <lee.jones@linaro.org>
> Cc: ohad@wizery.com; devicetree@vger.kernel.org; f.fainelli@gmail.com;
> kernel@stlinux.com; Nathan_Lynch@mentor.com; linux-
> kernel@vger.kernel.org; s-anna@ti.com; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to
> using the 'reserved-memory' API for obtaining DMA memory
> 
> Hi Lee,
> 
> On Wed, 16 Mar 2016, Lee Jones wrote:
> 
> > On Wed, 16 Mar 2016, Peter Griffin wrote:
> >
> > > Hi Lee,
> > >
> > > On Tue, 12 Jan 2016, Lee Jones wrote:
> > >
> > > > Doing so saves quite a bit of code in the driver.
> > > >
> > > > For more information on the 'reserved-memory' bindings see:
> > > >
> > > >
> > > > Documentation/devicetree/bindings/reserved-memory/reserved-
> memory.
> > > > txt
> > > >
> > > > Suggested-by: Suman Anna <s-anna@ti.com>
> > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > > ---
> > > >  arch/arm/boot/dts/stih407-family.dtsi | 46
> > > > +++++++++++++++++++++++++++++------
> > > >  1 file changed, 38 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/arch/arm/boot/dts/stih407-family.dtsi
> > > > b/arch/arm/boot/dts/stih407-family.dtsi
> > > > index 15c20b6..27b8efc 100644
> > > > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > > > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > > > @@ -15,6 +15,36 @@
> > > >  	#address-cells = <1>;
> > > >  	#size-cells = <1>;
> > > >
> > > > +	reserved-memory {
> > > > +		#address-cells = <1>;
> > > > +		#size-cells = <1>;
> > > > +		ranges;
> > > > +
> > > > +		gp0_reserved: rproc@40000000 {
> > > > +			compatible = "shared-dma-pool";
> > > > +			reg = <0x40000000 0x01000000>;
> > > > +			no-map;
> > > > +		};
> > > > +
> > > > +		gp1_reserved: rproc@41000000 {
> > > > +			compatible = "shared-dma-pool";
> > > > +			reg = <0x41000000 0x01000000>;
> > > > +			no-map;
> > > > +		};
> > > > +
> > > > +		audio_reserved: rproc@42000000 {
> > > > +			compatible = "shared-dma-pool";
> > > > +			reg = <0x42000000 0x01000000>;
> > > > +			no-map;
> > > > +		};
> > > > +
> > > > +		dmu_reserved: rproc@43000000 {
> > > > +			compatible = "shared-dma-pool";
> > > > +			reg = <0x43000000 0x01000000>;
> > > > +			no-map;
> > > > +		};
> > >
> > > I don't believe these reserved memory ranges are correct for
> audio_reserved and dmu_reserved.
> > >
> > > For example my vid_firmware-stih407.elf is linked at 0x41c00000 base
> > > address and my audio_firmware-bd-stih407.elf is linked at 0x40c00000.
> > >
> > > So with all the st231 rproc nodes enabled I guess it would still
> > > work. But currently I think st231_gp0 is reserving the memory region
> > > for st231_audio, and st231-gp1 is reserving the memory region for
> st231_dmu.
> >
> > These addresses are taken from internally tested code.
> 
> Yes I did check the internal kernel, it would appear to be wrong there as well.
> One of the joys of mailing list code review I guess :-)
> 
> > I don't have
> > access to the LMI layout documentation (if it even exists) so can't
> > check for myself.
> 
> >  Isn't this just DDR anyway?
> 
> Yes it is DDR
> 
> > So in theory we can
> > configure each devices' slice where ever we feel is appropriate?
> 
> Nope. The st231 audio and video firmwares are provided by ST as binary
> blobs and aren't AFAIK compiled as position independent code. So the
> reserved-memory region needs to match where the firmware has been
> linked to run from.
> 
> > How
> > is memory allocated to the DMU and Audio drivers?  Do you have scripts
> > which link the aforementioned binaries?
> 
> I don't have any scripts, firmware source code or even a st200 toolset.
> 
> >
> > If you think there is an issue, I suggest the best thing to do is ping
> > Ludovic, since he is the author of the original code.
> 
> Ok I will ping Ludovic and point him at this thread.
> 
> I think maybe the internal kernel rproc driver was only used to reserve
> memory, manage clocks, and co-processor reset / power lines, and multicom
> actually loaded the firmware elf file.
> 
> The reason for coming to that conclusion is that if rproc driver was loading the
> firmware I can't see how you would end up with a correctly booted co-
> processor with a reserved-memory node which doesn't match up with
> where the firmware is linked to run from.
> 
> Did you manage to boot audio or video co-pro successfully with the dt nodes
> as they currently are in this patch?
> 
> regards,
> 
> Peter.
> 
> _______________________________________________
> Kernel mailing list
> Kernel@stlinux.com
> http://www.stlinux.com/mailman/listinfo/kernel

[STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Loic PALLARDY]

Hi Lee, Pete,

The coprocessor memory map defined below is for test. Addresses have been arbitrary fixed.
The audio and video firmware you want to use are for product configuration.
For sure memory mapping must be adapted or firmware recompiled.

About coherency between firmware characteristics (linked address, position independent or not, size) and DT definition, you're right, some checks are missing in this version. It shouldn't be possible to load/start a firmware if DT reserved memory is not aligned with firmware resource table and firmware start address.

Lee, I propose to have a short discussion during next ST LT weekly meeting to list missing features and identify ST internal remoteproc patches for upstream.

Regards,
Loic

> -----Original Message-----
> From: Peter Griffin [mailto:peter.griffin at linaro.org]
> Sent: Wednesday, March 16, 2016 9:11 PM
> To: Lee Jones <lee.jones@linaro.org>
> Cc: ohad at wizery.com; devicetree at vger.kernel.org; f.fainelli at gmail.com;
> kernel at stlinux.com; Nathan_Lynch at mentor.com; linux-
> kernel at vger.kernel.org; s-anna at ti.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to
> using the 'reserved-memory' API for obtaining DMA memory
> 
> Hi Lee,
> 
> On Wed, 16 Mar 2016, Lee Jones wrote:
> 
> > On Wed, 16 Mar 2016, Peter Griffin wrote:
> >
> > > Hi Lee,
> > >
> > > On Tue, 12 Jan 2016, Lee Jones wrote:
> > >
> > > > Doing so saves quite a bit of code in the driver.
> > > >
> > > > For more information on the 'reserved-memory' bindings see:
> > > >
> > > >
> > > > Documentation/devicetree/bindings/reserved-memory/reserved-
> memory.
> > > > txt
> > > >
> > > > Suggested-by: Suman Anna <s-anna@ti.com>
> > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > > ---
> > > >  arch/arm/boot/dts/stih407-family.dtsi | 46
> > > > +++++++++++++++++++++++++++++------
> > > >  1 file changed, 38 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/arch/arm/boot/dts/stih407-family.dtsi
> > > > b/arch/arm/boot/dts/stih407-family.dtsi
> > > > index 15c20b6..27b8efc 100644
> > > > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > > > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > > > @@ -15,6 +15,36 @@
> > > >  	#address-cells = <1>;
> > > >  	#size-cells = <1>;
> > > >
> > > > +	reserved-memory {
> > > > +		#address-cells = <1>;
> > > > +		#size-cells = <1>;
> > > > +		ranges;
> > > > +
> > > > +		gp0_reserved: rproc at 40000000 {
> > > > +			compatible = "shared-dma-pool";
> > > > +			reg = <0x40000000 0x01000000>;
> > > > +			no-map;
> > > > +		};
> > > > +
> > > > +		gp1_reserved: rproc at 41000000 {
> > > > +			compatible = "shared-dma-pool";
> > > > +			reg = <0x41000000 0x01000000>;
> > > > +			no-map;
> > > > +		};
> > > > +
> > > > +		audio_reserved: rproc at 42000000 {
> > > > +			compatible = "shared-dma-pool";
> > > > +			reg = <0x42000000 0x01000000>;
> > > > +			no-map;
> > > > +		};
> > > > +
> > > > +		dmu_reserved: rproc at 43000000 {
> > > > +			compatible = "shared-dma-pool";
> > > > +			reg = <0x43000000 0x01000000>;
> > > > +			no-map;
> > > > +		};
> > >
> > > I don't believe these reserved memory ranges are correct for
> audio_reserved and dmu_reserved.
> > >
> > > For example my vid_firmware-stih407.elf is linked at 0x41c00000 base
> > > address and my audio_firmware-bd-stih407.elf is linked at 0x40c00000.
> > >
> > > So with all the st231 rproc nodes enabled I guess it would still
> > > work. But currently I think st231_gp0 is reserving the memory region
> > > for st231_audio, and st231-gp1 is reserving the memory region for
> st231_dmu.
> >
> > These addresses are taken from internally tested code.
> 
> Yes I did check the internal kernel, it would appear to be wrong there as well.
> One of the joys of mailing list code review I guess :-)
> 
> > I don't have
> > access to the LMI layout documentation (if it even exists) so can't
> > check for myself.
> 
> >  Isn't this just DDR anyway?
> 
> Yes it is DDR
> 
> > So in theory we can
> > configure each devices' slice where ever we feel is appropriate?
> 
> Nope. The st231 audio and video firmwares are provided by ST as binary
> blobs and aren't AFAIK compiled as position independent code. So the
> reserved-memory region needs to match where the firmware has been
> linked to run from.
> 
> > How
> > is memory allocated to the DMU and Audio drivers?  Do you have scripts
> > which link the aforementioned binaries?
> 
> I don't have any scripts, firmware source code or even a st200 toolset.
> 
> >
> > If you think there is an issue, I suggest the best thing to do is ping
> > Ludovic, since he is the author of the original code.
> 
> Ok I will ping Ludovic and point him at this thread.
> 
> I think maybe the internal kernel rproc driver was only used to reserve
> memory, manage clocks, and co-processor reset / power lines, and multicom
> actually loaded the firmware elf file.
> 
> The reason for coming to that conclusion is that if rproc driver was loading the
> firmware I can't see how you would end up with a correctly booted co-
> processor with a reserved-memory node which doesn't match up with
> where the firmware is linked to run from.
> 
> Did you manage to boot audio or video co-pro successfully with the dt nodes
> as they currently are in this patch?
> 
> regards,
> 
> Peter.
> 
> _______________________________________________
> Kernel mailing list
> Kernel at stlinux.com
> http://www.stlinux.com/mailman/listinfo/kernel

RE: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Loic PALLARDY]

Hi Lee, Pete,

The coprocessor memory map defined below is for test. Addresses have been arbitrary fixed.
The audio and video firmware you want to use are for product configuration.
For sure memory mapping must be adapted or firmware recompiled.

About coherency between firmware characteristics (linked address, position independent or not, size) and DT definition, you're right, some checks are missing in this version. It shouldn't be possible to load/start a firmware if DT reserved memory is not aligned with firmware resource table and firmware start address.

Lee, I propose to have a short discussion during next ST LT weekly meeting to list missing features and identify ST internal remoteproc patches for upstream.

Regards,
Loic

> -----Original Message-----
> From: Peter Griffin [mailto:peter.griffin@linaro.org]
> Sent: Wednesday, March 16, 2016 9:11 PM
> To: Lee Jones <lee.jones@linaro.org>
> Cc: ohad@wizery.com; devicetree@vger.kernel.org; f.fainelli@gmail.com;
> kernel@stlinux.com; Nathan_Lynch@mentor.com; linux-
> kernel@vger.kernel.org; s-anna@ti.com; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to
> using the 'reserved-memory' API for obtaining DMA memory
> 
> Hi Lee,
> 
> On Wed, 16 Mar 2016, Lee Jones wrote:
> 
> > On Wed, 16 Mar 2016, Peter Griffin wrote:
> >
> > > Hi Lee,
> > >
> > > On Tue, 12 Jan 2016, Lee Jones wrote:
> > >
> > > > Doing so saves quite a bit of code in the driver.
> > > >
> > > > For more information on the 'reserved-memory' bindings see:
> > > >
> > > >
> > > > Documentation/devicetree/bindings/reserved-memory/reserved-
> memory.
> > > > txt
> > > >
> > > > Suggested-by: Suman Anna <s-anna@ti.com>
> > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > > ---
> > > >  arch/arm/boot/dts/stih407-family.dtsi | 46
> > > > +++++++++++++++++++++++++++++------
> > > >  1 file changed, 38 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/arch/arm/boot/dts/stih407-family.dtsi
> > > > b/arch/arm/boot/dts/stih407-family.dtsi
> > > > index 15c20b6..27b8efc 100644
> > > > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > > > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > > > @@ -15,6 +15,36 @@
> > > >  	#address-cells = <1>;
> > > >  	#size-cells = <1>;
> > > >
> > > > +	reserved-memory {
> > > > +		#address-cells = <1>;
> > > > +		#size-cells = <1>;
> > > > +		ranges;
> > > > +
> > > > +		gp0_reserved: rproc@40000000 {
> > > > +			compatible = "shared-dma-pool";
> > > > +			reg = <0x40000000 0x01000000>;
> > > > +			no-map;
> > > > +		};
> > > > +
> > > > +		gp1_reserved: rproc@41000000 {
> > > > +			compatible = "shared-dma-pool";
> > > > +			reg = <0x41000000 0x01000000>;
> > > > +			no-map;
> > > > +		};
> > > > +
> > > > +		audio_reserved: rproc@42000000 {
> > > > +			compatible = "shared-dma-pool";
> > > > +			reg = <0x42000000 0x01000000>;
> > > > +			no-map;
> > > > +		};
> > > > +
> > > > +		dmu_reserved: rproc@43000000 {
> > > > +			compatible = "shared-dma-pool";
> > > > +			reg = <0x43000000 0x01000000>;
> > > > +			no-map;
> > > > +		};
> > >
> > > I don't believe these reserved memory ranges are correct for
> audio_reserved and dmu_reserved.
> > >
> > > For example my vid_firmware-stih407.elf is linked at 0x41c00000 base
> > > address and my audio_firmware-bd-stih407.elf is linked at 0x40c00000.
> > >
> > > So with all the st231 rproc nodes enabled I guess it would still
> > > work. But currently I think st231_gp0 is reserving the memory region
> > > for st231_audio, and st231-gp1 is reserving the memory region for
> st231_dmu.
> >
> > These addresses are taken from internally tested code.
> 
> Yes I did check the internal kernel, it would appear to be wrong there as well.
> One of the joys of mailing list code review I guess :-)
> 
> > I don't have
> > access to the LMI layout documentation (if it even exists) so can't
> > check for myself.
> 
> >  Isn't this just DDR anyway?
> 
> Yes it is DDR
> 
> > So in theory we can
> > configure each devices' slice where ever we feel is appropriate?
> 
> Nope. The st231 audio and video firmwares are provided by ST as binary
> blobs and aren't AFAIK compiled as position independent code. So the
> reserved-memory region needs to match where the firmware has been
> linked to run from.
> 
> > How
> > is memory allocated to the DMU and Audio drivers?  Do you have scripts
> > which link the aforementioned binaries?
> 
> I don't have any scripts, firmware source code or even a st200 toolset.
> 
> >
> > If you think there is an issue, I suggest the best thing to do is ping
> > Ludovic, since he is the author of the original code.
> 
> Ok I will ping Ludovic and point him at this thread.
> 
> I think maybe the internal kernel rproc driver was only used to reserve
> memory, manage clocks, and co-processor reset / power lines, and multicom
> actually loaded the firmware elf file.
> 
> The reason for coming to that conclusion is that if rproc driver was loading the
> firmware I can't see how you would end up with a correctly booted co-
> processor with a reserved-memory node which doesn't match up with
> where the firmware is linked to run from.
> 
> Did you manage to boot audio or video co-pro successfully with the dt nodes
> as they currently are in this patch?
> 
> regards,
> 
> Peter.
> 
> _______________________________________________
> Kernel mailing list
> Kernel@stlinux.com
> http://www.stlinux.com/mailman/listinfo/kernel

Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Lee Jones]

On Thu, 17 Mar 2016, Loic PALLARDY wrote:

> Hi Lee, Pete,
> 
> The coprocessor memory map defined below is for test. Addresses have
> been arbitrary fixed.
> The audio and video firmware you want to use are for product
> configuration.
> For sure memory mapping must be adapted or firmware recompiled.
> 
> About coherency between firmware characteristics (linked address,
> position independent or not, size) and DT definition, you're right,
> some checks are missing in this version. It shouldn't be possible to
> load/start a firmware if DT reserved memory is not aligned with
> firmware resource table and firmware start address.
> 
> Lee, I propose to have a short discussion during next ST LT weekly
> meeting to list missing features and identify ST internal remoteproc
> patches for upstream.

Sounds good to me.

FYI: This is only the first patch-set submission, which only provides
basic support.  There are subsequent sets, which I will start to
refine after the merge-window closes.  Perhaps the internal patches
you speak of are already part of this set?

> > -----Original Message-----
> > From: Peter Griffin [mailto:peter.griffin@linaro.org]
> > Sent: Wednesday, March 16, 2016 9:11 PM
> > To: Lee Jones <lee.jones@linaro.org>
> > Cc: ohad@wizery.com; devicetree@vger.kernel.org; f.fainelli@gmail.com;
> > kernel@stlinux.com; Nathan_Lynch@mentor.com; linux-
> > kernel@vger.kernel.org; s-anna@ti.com; linux-arm-
> > kernel@lists.infradead.org
> > Subject: Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to
> > using the 'reserved-memory' API for obtaining DMA memory
> > 
> > Hi Lee,
> > 
> > On Wed, 16 Mar 2016, Lee Jones wrote:
> > 
> > > On Wed, 16 Mar 2016, Peter Griffin wrote:
> > >
> > > > Hi Lee,
> > > >
> > > > On Tue, 12 Jan 2016, Lee Jones wrote:
> > > >
> > > > > Doing so saves quite a bit of code in the driver.
> > > > >
> > > > > For more information on the 'reserved-memory' bindings see:
> > > > >
> > > > >
> > > > > Documentation/devicetree/bindings/reserved-memory/reserved-
> > memory.
> > > > > txt
> > > > >
> > > > > Suggested-by: Suman Anna <s-anna@ti.com>
> > > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > > > ---
> > > > >  arch/arm/boot/dts/stih407-family.dtsi | 46
> > > > > +++++++++++++++++++++++++++++------
> > > > >  1 file changed, 38 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm/boot/dts/stih407-family.dtsi
> > > > > b/arch/arm/boot/dts/stih407-family.dtsi
> > > > > index 15c20b6..27b8efc 100644
> > > > > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > > > > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > > > > @@ -15,6 +15,36 @@
> > > > >  	#address-cells = <1>;
> > > > >  	#size-cells = <1>;
> > > > >
> > > > > +	reserved-memory {
> > > > > +		#address-cells = <1>;
> > > > > +		#size-cells = <1>;
> > > > > +		ranges;
> > > > > +
> > > > > +		gp0_reserved: rproc@40000000 {
> > > > > +			compatible = "shared-dma-pool";
> > > > > +			reg = <0x40000000 0x01000000>;
> > > > > +			no-map;
> > > > > +		};
> > > > > +
> > > > > +		gp1_reserved: rproc@41000000 {
> > > > > +			compatible = "shared-dma-pool";
> > > > > +			reg = <0x41000000 0x01000000>;
> > > > > +			no-map;
> > > > > +		};
> > > > > +
> > > > > +		audio_reserved: rproc@42000000 {
> > > > > +			compatible = "shared-dma-pool";
> > > > > +			reg = <0x42000000 0x01000000>;
> > > > > +			no-map;
> > > > > +		};
> > > > > +
> > > > > +		dmu_reserved: rproc@43000000 {
> > > > > +			compatible = "shared-dma-pool";
> > > > > +			reg = <0x43000000 0x01000000>;
> > > > > +			no-map;
> > > > > +		};
> > > >
> > > > I don't believe these reserved memory ranges are correct for
> > audio_reserved and dmu_reserved.
> > > >
> > > > For example my vid_firmware-stih407.elf is linked at 0x41c00000 base
> > > > address and my audio_firmware-bd-stih407.elf is linked at 0x40c00000.
> > > >
> > > > So with all the st231 rproc nodes enabled I guess it would still
> > > > work. But currently I think st231_gp0 is reserving the memory region
> > > > for st231_audio, and st231-gp1 is reserving the memory region for
> > st231_dmu.
> > >
> > > These addresses are taken from internally tested code.
> > 
> > Yes I did check the internal kernel, it would appear to be wrong there as well.
> > One of the joys of mailing list code review I guess :-)
> > 
> > > I don't have
> > > access to the LMI layout documentation (if it even exists) so can't
> > > check for myself.
> > 
> > >  Isn't this just DDR anyway?
> > 
> > Yes it is DDR
> > 
> > > So in theory we can
> > > configure each devices' slice where ever we feel is appropriate?
> > 
> > Nope. The st231 audio and video firmwares are provided by ST as binary
> > blobs and aren't AFAIK compiled as position independent code. So the
> > reserved-memory region needs to match where the firmware has been
> > linked to run from.
> > 
> > > How
> > > is memory allocated to the DMU and Audio drivers?  Do you have scripts
> > > which link the aforementioned binaries?
> > 
> > I don't have any scripts, firmware source code or even a st200 toolset.
> > 
> > >
> > > If you think there is an issue, I suggest the best thing to do is ping
> > > Ludovic, since he is the author of the original code.
> > 
> > Ok I will ping Ludovic and point him at this thread.
> > 
> > I think maybe the internal kernel rproc driver was only used to reserve
> > memory, manage clocks, and co-processor reset / power lines, and multicom
> > actually loaded the firmware elf file.
> > 
> > The reason for coming to that conclusion is that if rproc driver was loading the
> > firmware I can't see how you would end up with a correctly booted co-
> > processor with a reserved-memory node which doesn't match up with
> > where the firmware is linked to run from.
> > 
> > Did you manage to boot audio or video co-pro successfully with the dt nodes
> > as they currently are in this patch?
> > 
> > regards,
> > 
> > Peter.
> > 
> > _______________________________________________
> > Kernel mailing list
> > Kernel@stlinux.com
> > http://www.stlinux.com/mailman/listinfo/kernel

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Lee Jones]

On Thu, 17 Mar 2016, Loic PALLARDY wrote:

> Hi Lee, Pete,
> 
> The coprocessor memory map defined below is for test. Addresses have
> been arbitrary fixed.
> The audio and video firmware you want to use are for product
> configuration.
> For sure memory mapping must be adapted or firmware recompiled.
> 
> About coherency between firmware characteristics (linked address,
> position independent or not, size) and DT definition, you're right,
> some checks are missing in this version. It shouldn't be possible to
> load/start a firmware if DT reserved memory is not aligned with
> firmware resource table and firmware start address.
> 
> Lee, I propose to have a short discussion during next ST LT weekly
> meeting to list missing features and identify ST internal remoteproc
> patches for upstream.

Sounds good to me.

FYI: This is only the first patch-set submission, which only provides
basic support.  There are subsequent sets, which I will start to
refine after the merge-window closes.  Perhaps the internal patches
you speak of are already part of this set?

> > -----Original Message-----
> > From: Peter Griffin [mailto:peter.griffin at linaro.org]
> > Sent: Wednesday, March 16, 2016 9:11 PM
> > To: Lee Jones <lee.jones@linaro.org>
> > Cc: ohad at wizery.com; devicetree at vger.kernel.org; f.fainelli at gmail.com;
> > kernel at stlinux.com; Nathan_Lynch at mentor.com; linux-
> > kernel at vger.kernel.org; s-anna at ti.com; linux-arm-
> > kernel at lists.infradead.org
> > Subject: Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to
> > using the 'reserved-memory' API for obtaining DMA memory
> > 
> > Hi Lee,
> > 
> > On Wed, 16 Mar 2016, Lee Jones wrote:
> > 
> > > On Wed, 16 Mar 2016, Peter Griffin wrote:
> > >
> > > > Hi Lee,
> > > >
> > > > On Tue, 12 Jan 2016, Lee Jones wrote:
> > > >
> > > > > Doing so saves quite a bit of code in the driver.
> > > > >
> > > > > For more information on the 'reserved-memory' bindings see:
> > > > >
> > > > >
> > > > > Documentation/devicetree/bindings/reserved-memory/reserved-
> > memory.
> > > > > txt
> > > > >
> > > > > Suggested-by: Suman Anna <s-anna@ti.com>
> > > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > > > ---
> > > > >  arch/arm/boot/dts/stih407-family.dtsi | 46
> > > > > +++++++++++++++++++++++++++++------
> > > > >  1 file changed, 38 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm/boot/dts/stih407-family.dtsi
> > > > > b/arch/arm/boot/dts/stih407-family.dtsi
> > > > > index 15c20b6..27b8efc 100644
> > > > > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > > > > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > > > > @@ -15,6 +15,36 @@
> > > > >  	#address-cells = <1>;
> > > > >  	#size-cells = <1>;
> > > > >
> > > > > +	reserved-memory {
> > > > > +		#address-cells = <1>;
> > > > > +		#size-cells = <1>;
> > > > > +		ranges;
> > > > > +
> > > > > +		gp0_reserved: rproc at 40000000 {
> > > > > +			compatible = "shared-dma-pool";
> > > > > +			reg = <0x40000000 0x01000000>;
> > > > > +			no-map;
> > > > > +		};
> > > > > +
> > > > > +		gp1_reserved: rproc at 41000000 {
> > > > > +			compatible = "shared-dma-pool";
> > > > > +			reg = <0x41000000 0x01000000>;
> > > > > +			no-map;
> > > > > +		};
> > > > > +
> > > > > +		audio_reserved: rproc at 42000000 {
> > > > > +			compatible = "shared-dma-pool";
> > > > > +			reg = <0x42000000 0x01000000>;
> > > > > +			no-map;
> > > > > +		};
> > > > > +
> > > > > +		dmu_reserved: rproc at 43000000 {
> > > > > +			compatible = "shared-dma-pool";
> > > > > +			reg = <0x43000000 0x01000000>;
> > > > > +			no-map;
> > > > > +		};
> > > >
> > > > I don't believe these reserved memory ranges are correct for
> > audio_reserved and dmu_reserved.
> > > >
> > > > For example my vid_firmware-stih407.elf is linked at 0x41c00000 base
> > > > address and my audio_firmware-bd-stih407.elf is linked at 0x40c00000.
> > > >
> > > > So with all the st231 rproc nodes enabled I guess it would still
> > > > work. But currently I think st231_gp0 is reserving the memory region
> > > > for st231_audio, and st231-gp1 is reserving the memory region for
> > st231_dmu.
> > >
> > > These addresses are taken from internally tested code.
> > 
> > Yes I did check the internal kernel, it would appear to be wrong there as well.
> > One of the joys of mailing list code review I guess :-)
> > 
> > > I don't have
> > > access to the LMI layout documentation (if it even exists) so can't
> > > check for myself.
> > 
> > >  Isn't this just DDR anyway?
> > 
> > Yes it is DDR
> > 
> > > So in theory we can
> > > configure each devices' slice where ever we feel is appropriate?
> > 
> > Nope. The st231 audio and video firmwares are provided by ST as binary
> > blobs and aren't AFAIK compiled as position independent code. So the
> > reserved-memory region needs to match where the firmware has been
> > linked to run from.
> > 
> > > How
> > > is memory allocated to the DMU and Audio drivers?  Do you have scripts
> > > which link the aforementioned binaries?
> > 
> > I don't have any scripts, firmware source code or even a st200 toolset.
> > 
> > >
> > > If you think there is an issue, I suggest the best thing to do is ping
> > > Ludovic, since he is the author of the original code.
> > 
> > Ok I will ping Ludovic and point him at this thread.
> > 
> > I think maybe the internal kernel rproc driver was only used to reserve
> > memory, manage clocks, and co-processor reset / power lines, and multicom
> > actually loaded the firmware elf file.
> > 
> > The reason for coming to that conclusion is that if rproc driver was loading the
> > firmware I can't see how you would end up with a correctly booted co-
> > processor with a reserved-memory node which doesn't match up with
> > where the firmware is linked to run from.
> > 
> > Did you manage to boot audio or video co-pro successfully with the dt nodes
> > as they currently are in this patch?
> > 
> > regards,
> > 
> > Peter.
> > 
> > _______________________________________________
> > Kernel mailing list
> > Kernel at stlinux.com
> > http://www.stlinux.com/mailman/listinfo/kernel

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

[Lee Jones]

On Thu, 17 Mar 2016, Loic PALLARDY wrote:

> Hi Lee, Pete,
> 
> The coprocessor memory map defined below is for test. Addresses have
> been arbitrary fixed.
> The audio and video firmware you want to use are for product
> configuration.
> For sure memory mapping must be adapted or firmware recompiled.
> 
> About coherency between firmware characteristics (linked address,
> position independent or not, size) and DT definition, you're right,
> some checks are missing in this version. It shouldn't be possible to
> load/start a firmware if DT reserved memory is not aligned with
> firmware resource table and firmware start address.
> 
> Lee, I propose to have a short discussion during next ST LT weekly
> meeting to list missing features and identify ST internal remoteproc
> patches for upstream.

Sounds good to me.

FYI: This is only the first patch-set submission, which only provides
basic support.  There are subsequent sets, which I will start to
refine after the merge-window closes.  Perhaps the internal patches
you speak of are already part of this set?

> > -----Original Message-----
> > From: Peter Griffin [mailto:peter.griffin@linaro.org]
> > Sent: Wednesday, March 16, 2016 9:11 PM
> > To: Lee Jones <lee.jones@linaro.org>
> > Cc: ohad@wizery.com; devicetree@vger.kernel.org; f.fainelli@gmail.com;
> > kernel@stlinux.com; Nathan_Lynch@mentor.com; linux-
> > kernel@vger.kernel.org; s-anna@ti.com; linux-arm-
> > kernel@lists.infradead.org
> > Subject: Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to
> > using the 'reserved-memory' API for obtaining DMA memory
> > 
> > Hi Lee,
> > 
> > On Wed, 16 Mar 2016, Lee Jones wrote:
> > 
> > > On Wed, 16 Mar 2016, Peter Griffin wrote:
> > >
> > > > Hi Lee,
> > > >
> > > > On Tue, 12 Jan 2016, Lee Jones wrote:
> > > >
> > > > > Doing so saves quite a bit of code in the driver.
> > > > >
> > > > > For more information on the 'reserved-memory' bindings see:
> > > > >
> > > > >
> > > > > Documentation/devicetree/bindings/reserved-memory/reserved-
> > memory.
> > > > > txt
> > > > >
> > > > > Suggested-by: Suman Anna <s-anna@ti.com>
> > > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > > > ---
> > > > >  arch/arm/boot/dts/stih407-family.dtsi | 46
> > > > > +++++++++++++++++++++++++++++------
> > > > >  1 file changed, 38 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm/boot/dts/stih407-family.dtsi
> > > > > b/arch/arm/boot/dts/stih407-family.dtsi
> > > > > index 15c20b6..27b8efc 100644
> > > > > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > > > > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > > > > @@ -15,6 +15,36 @@
> > > > >  	#address-cells = <1>;
> > > > >  	#size-cells = <1>;
> > > > >
> > > > > +	reserved-memory {
> > > > > +		#address-cells = <1>;
> > > > > +		#size-cells = <1>;
> > > > > +		ranges;
> > > > > +
> > > > > +		gp0_reserved: rproc@40000000 {
> > > > > +			compatible = "shared-dma-pool";
> > > > > +			reg = <0x40000000 0x01000000>;
> > > > > +			no-map;
> > > > > +		};
> > > > > +
> > > > > +		gp1_reserved: rproc@41000000 {
> > > > > +			compatible = "shared-dma-pool";
> > > > > +			reg = <0x41000000 0x01000000>;
> > > > > +			no-map;
> > > > > +		};
> > > > > +
> > > > > +		audio_reserved: rproc@42000000 {
> > > > > +			compatible = "shared-dma-pool";
> > > > > +			reg = <0x42000000 0x01000000>;
> > > > > +			no-map;
> > > > > +		};
> > > > > +
> > > > > +		dmu_reserved: rproc@43000000 {
> > > > > +			compatible = "shared-dma-pool";
> > > > > +			reg = <0x43000000 0x01000000>;
> > > > > +			no-map;
> > > > > +		};
> > > >
> > > > I don't believe these reserved memory ranges are correct for
> > audio_reserved and dmu_reserved.
> > > >
> > > > For example my vid_firmware-stih407.elf is linked at 0x41c00000 base
> > > > address and my audio_firmware-bd-stih407.elf is linked at 0x40c00000.
> > > >
> > > > So with all the st231 rproc nodes enabled I guess it would still
> > > > work. But currently I think st231_gp0 is reserving the memory region
> > > > for st231_audio, and st231-gp1 is reserving the memory region for
> > st231_dmu.
> > >
> > > These addresses are taken from internally tested code.
> > 
> > Yes I did check the internal kernel, it would appear to be wrong there as well.
> > One of the joys of mailing list code review I guess :-)
> > 
> > > I don't have
> > > access to the LMI layout documentation (if it even exists) so can't
> > > check for myself.
> > 
> > >  Isn't this just DDR anyway?
> > 
> > Yes it is DDR
> > 
> > > So in theory we can
> > > configure each devices' slice where ever we feel is appropriate?
> > 
> > Nope. The st231 audio and video firmwares are provided by ST as binary
> > blobs and aren't AFAIK compiled as position independent code. So the
> > reserved-memory region needs to match where the firmware has been
> > linked to run from.
> > 
> > > How
> > > is memory allocated to the DMU and Audio drivers?  Do you have scripts
> > > which link the aforementioned binaries?
> > 
> > I don't have any scripts, firmware source code or even a st200 toolset.
> > 
> > >
> > > If you think there is an issue, I suggest the best thing to do is ping
> > > Ludovic, since he is the author of the original code.
> > 
> > Ok I will ping Ludovic and point him at this thread.
> > 
> > I think maybe the internal kernel rproc driver was only used to reserve
> > memory, manage clocks, and co-processor reset / power lines, and multicom
> > actually loaded the firmware elf file.
> > 
> > The reason for coming to that conclusion is that if rproc driver was loading the
> > firmware I can't see how you would end up with a correctly booted co-
> > processor with a reserved-memory node which doesn't match up with
> > where the firmware is linked to run from.
> > 
> > Did you manage to boot audio or video co-pro successfully with the dt nodes
> > as they currently are in this patch?
> > 
> > regards,
> > 
> > Peter.
> > 
> > _______________________________________________
> > Kernel mailing list
> > Kernel@stlinux.com
> > http://www.stlinux.com/mailman/listinfo/kernel

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms

[Lee Jones]

Apologies for ping (I hate doing that), but I haven't heard anything
from you.  Do you want me to re-submit this set, or are you willing to
take this and apply the relevant Acks?

> ST's platforms often have multiple co-processors (usually ST40s or ST231s)
> on-board.  This provides the Linux-side infrastructure to flash and boot
> them successfully.
>   
> This set has been tested on an STiH410-B2120.
> 
> v4 => v5:
>  - Check for invalid 'count' (command read length) in write fn()s
>   
> v3 => v4:
>  Suggested-by: Suman Anna <s-anna@ti.com>
>  - Move to using 'reserved-memory' API
>    - New 'reserved-memory' nodes
>    - Remove memory locations from RemoteProc's DT node's reg properties
>    - Remove C code obtaining/allocating DMA memory
>  - Re-order .start() and .stop() ops
>  - Add protection around Reset API in error path
>  - Explicitly set .has_iommu to false
>   
> v2 => v3:
>  - Generify syscon property (st,syscfg-boot => st,syscfg)
>  - Rename IP in DT bindings doc (Remote Processor => Co-Processor)
>  - Remove superfluous 'clock-names' property
>  - Remove superfluous 'reg-names' property
>  - Populate MAINTAINERS
>  - Clean-up DTS formatting
>  - Use strings in debugfs to control procs ('1|0' => 'start|stop')
>  - Align copyright statement with MODULE() macros
>  - Rename driver data structure ('st_rproc' => 'ddata')
>  - Addition of a full error path in .start()
> 
> v1 => v2:
>  - Remove Linux implementation specific comment from binding document
>  - Force debugfs '0' to shutdown co-processor - rather than !1
>  - Supply more detailed commit message
>  - Propagate errors back from .stop()
>  - Review GPL wording
>  - Supply original author's SoBs
> 
> Lee Jones (7):
>   remoteproc: debugfs: Check of invalid 'count' value
>   remoteproc: dt: Provide bindings for ST's Remote Processor Controller
>     driver
>   remoteproc: debugfs: Add ability to boot remote processor using
>     debugfs
>   remoteproc: Supply controller driver for ST's Remote Processors
>   MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
>   ARM: STiH407: Add nodes for RemoteProc
>   ARM: STiH407: Move over to using the 'reserved-memory' API for
>     obtaining DMA memory
> 
>  .../devicetree/bindings/remoteproc/st-rproc.txt    |  41 +++
>  MAINTAINERS                                        |   1 +
>  arch/arm/boot/dts/stih407-family.dtsi              |  70 +++++
>  drivers/remoteproc/Kconfig                         |   9 +
>  drivers/remoteproc/Makefile                        |   1 +
>  drivers/remoteproc/remoteproc_debugfs.c            |  38 ++-
>  drivers/remoteproc/st_remoteproc.c                 | 297 +++++++++++++++++++++
>  7 files changed, 455 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
>  create mode 100644 drivers/remoteproc/st_remoteproc.c
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms

[Lee Jones]

Apologies for ping (I hate doing that), but I haven't heard anything
from you.  Do you want me to re-submit this set, or are you willing to
take this and apply the relevant Acks?

> ST's platforms often have multiple co-processors (usually ST40s or ST231s)
> on-board.  This provides the Linux-side infrastructure to flash and boot
> them successfully.
>   
> This set has been tested on an STiH410-B2120.
> 
> v4 => v5:
>  - Check for invalid 'count' (command read length) in write fn()s
>   
> v3 => v4:
>  Suggested-by: Suman Anna <s-anna@ti.com>
>  - Move to using 'reserved-memory' API
>    - New 'reserved-memory' nodes
>    - Remove memory locations from RemoteProc's DT node's reg properties
>    - Remove C code obtaining/allocating DMA memory
>  - Re-order .start() and .stop() ops
>  - Add protection around Reset API in error path
>  - Explicitly set .has_iommu to false
>   
> v2 => v3:
>  - Generify syscon property (st,syscfg-boot => st,syscfg)
>  - Rename IP in DT bindings doc (Remote Processor => Co-Processor)
>  - Remove superfluous 'clock-names' property
>  - Remove superfluous 'reg-names' property
>  - Populate MAINTAINERS
>  - Clean-up DTS formatting
>  - Use strings in debugfs to control procs ('1|0' => 'start|stop')
>  - Align copyright statement with MODULE() macros
>  - Rename driver data structure ('st_rproc' => 'ddata')
>  - Addition of a full error path in .start()
> 
> v1 => v2:
>  - Remove Linux implementation specific comment from binding document
>  - Force debugfs '0' to shutdown co-processor - rather than !1
>  - Supply more detailed commit message
>  - Propagate errors back from .stop()
>  - Review GPL wording
>  - Supply original author's SoBs
> 
> Lee Jones (7):
>   remoteproc: debugfs: Check of invalid 'count' value
>   remoteproc: dt: Provide bindings for ST's Remote Processor Controller
>     driver
>   remoteproc: debugfs: Add ability to boot remote processor using
>     debugfs
>   remoteproc: Supply controller driver for ST's Remote Processors
>   MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
>   ARM: STiH407: Add nodes for RemoteProc
>   ARM: STiH407: Move over to using the 'reserved-memory' API for
>     obtaining DMA memory
> 
>  .../devicetree/bindings/remoteproc/st-rproc.txt    |  41 +++
>  MAINTAINERS                                        |   1 +
>  arch/arm/boot/dts/stih407-family.dtsi              |  70 +++++
>  drivers/remoteproc/Kconfig                         |   9 +
>  drivers/remoteproc/Makefile                        |   1 +
>  drivers/remoteproc/remoteproc_debugfs.c            |  38 ++-
>  drivers/remoteproc/st_remoteproc.c                 | 297 +++++++++++++++++++++
>  7 files changed, 455 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
>  create mode 100644 drivers/remoteproc/st_remoteproc.c
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms

[Lee Jones]

Apologies for ping (I hate doing that), but I haven't heard anything
from you.  Do you want me to re-submit this set, or are you willing to
take this and apply the relevant Acks?

> ST's platforms often have multiple co-processors (usually ST40s or ST231s)
> on-board.  This provides the Linux-side infrastructure to flash and boot
> them successfully.
>   
> This set has been tested on an STiH410-B2120.
> 
> v4 => v5:
>  - Check for invalid 'count' (command read length) in write fn()s
>   
> v3 => v4:
>  Suggested-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
>  - Move to using 'reserved-memory' API
>    - New 'reserved-memory' nodes
>    - Remove memory locations from RemoteProc's DT node's reg properties
>    - Remove C code obtaining/allocating DMA memory
>  - Re-order .start() and .stop() ops
>  - Add protection around Reset API in error path
>  - Explicitly set .has_iommu to false
>   
> v2 => v3:
>  - Generify syscon property (st,syscfg-boot => st,syscfg)
>  - Rename IP in DT bindings doc (Remote Processor => Co-Processor)
>  - Remove superfluous 'clock-names' property
>  - Remove superfluous 'reg-names' property
>  - Populate MAINTAINERS
>  - Clean-up DTS formatting
>  - Use strings in debugfs to control procs ('1|0' => 'start|stop')
>  - Align copyright statement with MODULE() macros
>  - Rename driver data structure ('st_rproc' => 'ddata')
>  - Addition of a full error path in .start()
> 
> v1 => v2:
>  - Remove Linux implementation specific comment from binding document
>  - Force debugfs '0' to shutdown co-processor - rather than !1
>  - Supply more detailed commit message
>  - Propagate errors back from .stop()
>  - Review GPL wording
>  - Supply original author's SoBs
> 
> Lee Jones (7):
>   remoteproc: debugfs: Check of invalid 'count' value
>   remoteproc: dt: Provide bindings for ST's Remote Processor Controller
>     driver
>   remoteproc: debugfs: Add ability to boot remote processor using
>     debugfs
>   remoteproc: Supply controller driver for ST's Remote Processors
>   MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
>   ARM: STiH407: Add nodes for RemoteProc
>   ARM: STiH407: Move over to using the 'reserved-memory' API for
>     obtaining DMA memory
> 
>  .../devicetree/bindings/remoteproc/st-rproc.txt    |  41 +++
>  MAINTAINERS                                        |   1 +
>  arch/arm/boot/dts/stih407-family.dtsi              |  70 +++++
>  drivers/remoteproc/Kconfig                         |   9 +
>  drivers/remoteproc/Makefile                        |   1 +
>  drivers/remoteproc/remoteproc_debugfs.c            |  38 ++-
>  drivers/remoteproc/st_remoteproc.c                 | 297 +++++++++++++++++++++
>  7 files changed, 455 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
>  create mode 100644 drivers/remoteproc/st_remoteproc.c
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms

[Bjorn Andersson]

On Tue, Jan 26, 2016 at 11:31 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> Apologies for ping (I hate doing that), but I haven't heard anything
> from you.  Do you want me to re-submit this set, or are you willing to
> take this and apply the relevant Acks?
>

I had a chat with Ohad and offered my assistance with his work. So I
will pick up the role as co-maintainer of his subsystems.

I will pick up patch 1-4 of your v5 as soon as I've sorted out the
practicalities around this, no need to resubmit them.

Sorry for the delay!

Regards,
Bjorn

> > ST's platforms often have multiple co-processors (usually ST40s or ST231s)
> > on-board.  This provides the Linux-side infrastructure to flash and boot
> > them successfully.
> >
> > This set has been tested on an STiH410-B2120.
> >
> > v4 => v5:
> >  - Check for invalid 'count' (command read length) in write fn()s
> >
> > v3 => v4:
> >  Suggested-by: Suman Anna <s-anna@ti.com>
> >  - Move to using 'reserved-memory' API
> >    - New 'reserved-memory' nodes
> >    - Remove memory locations from RemoteProc's DT node's reg properties
> >    - Remove C code obtaining/allocating DMA memory
> >  - Re-order .start() and .stop() ops
> >  - Add protection around Reset API in error path
> >  - Explicitly set .has_iommu to false
> >
> > v2 => v3:
> >  - Generify syscon property (st,syscfg-boot => st,syscfg)
> >  - Rename IP in DT bindings doc (Remote Processor => Co-Processor)
> >  - Remove superfluous 'clock-names' property
> >  - Remove superfluous 'reg-names' property
> >  - Populate MAINTAINERS
> >  - Clean-up DTS formatting
> >  - Use strings in debugfs to control procs ('1|0' => 'start|stop')
> >  - Align copyright statement with MODULE() macros
> >  - Rename driver data structure ('st_rproc' => 'ddata')
> >  - Addition of a full error path in .start()
> >
> > v1 => v2:
> >  - Remove Linux implementation specific comment from binding document
> >  - Force debugfs '0' to shutdown co-processor - rather than !1
> >  - Supply more detailed commit message
> >  - Propagate errors back from .stop()
> >  - Review GPL wording
> >  - Supply original author's SoBs
> >
> > Lee Jones (7):
> >   remoteproc: debugfs: Check of invalid 'count' value
> >   remoteproc: dt: Provide bindings for ST's Remote Processor Controller
> >     driver
> >   remoteproc: debugfs: Add ability to boot remote processor using
> >     debugfs
> >   remoteproc: Supply controller driver for ST's Remote Processors
> >   MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
> >   ARM: STiH407: Add nodes for RemoteProc
> >   ARM: STiH407: Move over to using the 'reserved-memory' API for
> >     obtaining DMA memory
> >
> >  .../devicetree/bindings/remoteproc/st-rproc.txt    |  41 +++
> >  MAINTAINERS                                        |   1 +
> >  arch/arm/boot/dts/stih407-family.dtsi              |  70 +++++
> >  drivers/remoteproc/Kconfig                         |   9 +
> >  drivers/remoteproc/Makefile                        |   1 +
> >  drivers/remoteproc/remoteproc_debugfs.c            |  38 ++-
> >  drivers/remoteproc/st_remoteproc.c                 | 297 +++++++++++++++++++++
> >  7 files changed, 455 insertions(+), 2 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> >  create mode 100644 drivers/remoteproc/st_remoteproc.c
> >
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms

[Bjorn Andersson]

On Tue, Jan 26, 2016 at 11:31 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> Apologies for ping (I hate doing that), but I haven't heard anything
> from you.  Do you want me to re-submit this set, or are you willing to
> take this and apply the relevant Acks?
>

I had a chat with Ohad and offered my assistance with his work. So I
will pick up the role as co-maintainer of his subsystems.

I will pick up patch 1-4 of your v5 as soon as I've sorted out the
practicalities around this, no need to resubmit them.

Sorry for the delay!

Regards,
Bjorn

> > ST's platforms often have multiple co-processors (usually ST40s or ST231s)
> > on-board.  This provides the Linux-side infrastructure to flash and boot
> > them successfully.
> >
> > This set has been tested on an STiH410-B2120.
> >
> > v4 => v5:
> >  - Check for invalid 'count' (command read length) in write fn()s
> >
> > v3 => v4:
> >  Suggested-by: Suman Anna <s-anna@ti.com>
> >  - Move to using 'reserved-memory' API
> >    - New 'reserved-memory' nodes
> >    - Remove memory locations from RemoteProc's DT node's reg properties
> >    - Remove C code obtaining/allocating DMA memory
> >  - Re-order .start() and .stop() ops
> >  - Add protection around Reset API in error path
> >  - Explicitly set .has_iommu to false
> >
> > v2 => v3:
> >  - Generify syscon property (st,syscfg-boot => st,syscfg)
> >  - Rename IP in DT bindings doc (Remote Processor => Co-Processor)
> >  - Remove superfluous 'clock-names' property
> >  - Remove superfluous 'reg-names' property
> >  - Populate MAINTAINERS
> >  - Clean-up DTS formatting
> >  - Use strings in debugfs to control procs ('1|0' => 'start|stop')
> >  - Align copyright statement with MODULE() macros
> >  - Rename driver data structure ('st_rproc' => 'ddata')
> >  - Addition of a full error path in .start()
> >
> > v1 => v2:
> >  - Remove Linux implementation specific comment from binding document
> >  - Force debugfs '0' to shutdown co-processor - rather than !1
> >  - Supply more detailed commit message
> >  - Propagate errors back from .stop()
> >  - Review GPL wording
> >  - Supply original author's SoBs
> >
> > Lee Jones (7):
> >   remoteproc: debugfs: Check of invalid 'count' value
> >   remoteproc: dt: Provide bindings for ST's Remote Processor Controller
> >     driver
> >   remoteproc: debugfs: Add ability to boot remote processor using
> >     debugfs
> >   remoteproc: Supply controller driver for ST's Remote Processors
> >   MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
> >   ARM: STiH407: Add nodes for RemoteProc
> >   ARM: STiH407: Move over to using the 'reserved-memory' API for
> >     obtaining DMA memory
> >
> >  .../devicetree/bindings/remoteproc/st-rproc.txt    |  41 +++
> >  MAINTAINERS                                        |   1 +
> >  arch/arm/boot/dts/stih407-family.dtsi              |  70 +++++
> >  drivers/remoteproc/Kconfig                         |   9 +
> >  drivers/remoteproc/Makefile                        |   1 +
> >  drivers/remoteproc/remoteproc_debugfs.c            |  38 ++-
> >  drivers/remoteproc/st_remoteproc.c                 | 297 +++++++++++++++++++++
> >  7 files changed, 455 insertions(+), 2 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> >  create mode 100644 drivers/remoteproc/st_remoteproc.c
> >
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms

[Lee Jones]

On Wed, 27 Jan 2016, Bjorn Andersson wrote:

> On Tue, Jan 26, 2016 at 11:31 PM, Lee Jones <lee.jones@linaro.org> wrote:
> >
> > Apologies for ping (I hate doing that), but I haven't heard anything
> > from you.  Do you want me to re-submit this set, or are you willing to
> > take this and apply the relevant Acks?
> >
> 
> I had a chat with Ohad and offered my assistance with his work. So I
> will pick up the role as co-maintainer of his subsystems.
> 
> I will pick up patch 1-4 of your v5 as soon as I've sorted out the
> practicalities around this, no need to resubmit them.
> 
> Sorry for the delay!

Any news on this?  We're nearing the merge window.

> > > ST's platforms often have multiple co-processors (usually ST40s or ST231s)
> > > on-board.  This provides the Linux-side infrastructure to flash and boot
> > > them successfully.
> > >
> > > This set has been tested on an STiH410-B2120.
> > >
> > > v4 => v5:
> > >  - Check for invalid 'count' (command read length) in write fn()s
> > >
> > > v3 => v4:
> > >  Suggested-by: Suman Anna <s-anna@ti.com>
> > >  - Move to using 'reserved-memory' API
> > >    - New 'reserved-memory' nodes
> > >    - Remove memory locations from RemoteProc's DT node's reg properties
> > >    - Remove C code obtaining/allocating DMA memory
> > >  - Re-order .start() and .stop() ops
> > >  - Add protection around Reset API in error path
> > >  - Explicitly set .has_iommu to false
> > >
> > > v2 => v3:
> > >  - Generify syscon property (st,syscfg-boot => st,syscfg)
> > >  - Rename IP in DT bindings doc (Remote Processor => Co-Processor)
> > >  - Remove superfluous 'clock-names' property
> > >  - Remove superfluous 'reg-names' property
> > >  - Populate MAINTAINERS
> > >  - Clean-up DTS formatting
> > >  - Use strings in debugfs to control procs ('1|0' => 'start|stop')
> > >  - Align copyright statement with MODULE() macros
> > >  - Rename driver data structure ('st_rproc' => 'ddata')
> > >  - Addition of a full error path in .start()
> > >
> > > v1 => v2:
> > >  - Remove Linux implementation specific comment from binding document
> > >  - Force debugfs '0' to shutdown co-processor - rather than !1
> > >  - Supply more detailed commit message
> > >  - Propagate errors back from .stop()
> > >  - Review GPL wording
> > >  - Supply original author's SoBs
> > >
> > > Lee Jones (7):
> > >   remoteproc: debugfs: Check of invalid 'count' value
> > >   remoteproc: dt: Provide bindings for ST's Remote Processor Controller
> > >     driver
> > >   remoteproc: debugfs: Add ability to boot remote processor using
> > >     debugfs
> > >   remoteproc: Supply controller driver for ST's Remote Processors
> > >   MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
> > >   ARM: STiH407: Add nodes for RemoteProc
> > >   ARM: STiH407: Move over to using the 'reserved-memory' API for
> > >     obtaining DMA memory
> > >
> > >  .../devicetree/bindings/remoteproc/st-rproc.txt    |  41 +++
> > >  MAINTAINERS                                        |   1 +
> > >  arch/arm/boot/dts/stih407-family.dtsi              |  70 +++++
> > >  drivers/remoteproc/Kconfig                         |   9 +
> > >  drivers/remoteproc/Makefile                        |   1 +
> > >  drivers/remoteproc/remoteproc_debugfs.c            |  38 ++-
> > >  drivers/remoteproc/st_remoteproc.c                 | 297 +++++++++++++++++++++
> > >  7 files changed, 455 insertions(+), 2 deletions(-)
> > >  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> > >  create mode 100644 drivers/remoteproc/st_remoteproc.c
> > >
> >

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms

[Lee Jones]

On Wed, 27 Jan 2016, Bjorn Andersson wrote:

> On Tue, Jan 26, 2016 at 11:31 PM, Lee Jones <lee.jones@linaro.org> wrote:
> >
> > Apologies for ping (I hate doing that), but I haven't heard anything
> > from you.  Do you want me to re-submit this set, or are you willing to
> > take this and apply the relevant Acks?
> >
> 
> I had a chat with Ohad and offered my assistance with his work. So I
> will pick up the role as co-maintainer of his subsystems.
> 
> I will pick up patch 1-4 of your v5 as soon as I've sorted out the
> practicalities around this, no need to resubmit them.
> 
> Sorry for the delay!

Any news on this?  We're nearing the merge window.

> > > ST's platforms often have multiple co-processors (usually ST40s or ST231s)
> > > on-board.  This provides the Linux-side infrastructure to flash and boot
> > > them successfully.
> > >
> > > This set has been tested on an STiH410-B2120.
> > >
> > > v4 => v5:
> > >  - Check for invalid 'count' (command read length) in write fn()s
> > >
> > > v3 => v4:
> > >  Suggested-by: Suman Anna <s-anna@ti.com>
> > >  - Move to using 'reserved-memory' API
> > >    - New 'reserved-memory' nodes
> > >    - Remove memory locations from RemoteProc's DT node's reg properties
> > >    - Remove C code obtaining/allocating DMA memory
> > >  - Re-order .start() and .stop() ops
> > >  - Add protection around Reset API in error path
> > >  - Explicitly set .has_iommu to false
> > >
> > > v2 => v3:
> > >  - Generify syscon property (st,syscfg-boot => st,syscfg)
> > >  - Rename IP in DT bindings doc (Remote Processor => Co-Processor)
> > >  - Remove superfluous 'clock-names' property
> > >  - Remove superfluous 'reg-names' property
> > >  - Populate MAINTAINERS
> > >  - Clean-up DTS formatting
> > >  - Use strings in debugfs to control procs ('1|0' => 'start|stop')
> > >  - Align copyright statement with MODULE() macros
> > >  - Rename driver data structure ('st_rproc' => 'ddata')
> > >  - Addition of a full error path in .start()
> > >
> > > v1 => v2:
> > >  - Remove Linux implementation specific comment from binding document
> > >  - Force debugfs '0' to shutdown co-processor - rather than !1
> > >  - Supply more detailed commit message
> > >  - Propagate errors back from .stop()
> > >  - Review GPL wording
> > >  - Supply original author's SoBs
> > >
> > > Lee Jones (7):
> > >   remoteproc: debugfs: Check of invalid 'count' value
> > >   remoteproc: dt: Provide bindings for ST's Remote Processor Controller
> > >     driver
> > >   remoteproc: debugfs: Add ability to boot remote processor using
> > >     debugfs
> > >   remoteproc: Supply controller driver for ST's Remote Processors
> > >   MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
> > >   ARM: STiH407: Add nodes for RemoteProc
> > >   ARM: STiH407: Move over to using the 'reserved-memory' API for
> > >     obtaining DMA memory
> > >
> > >  .../devicetree/bindings/remoteproc/st-rproc.txt    |  41 +++
> > >  MAINTAINERS                                        |   1 +
> > >  arch/arm/boot/dts/stih407-family.dtsi              |  70 +++++
> > >  drivers/remoteproc/Kconfig                         |   9 +
> > >  drivers/remoteproc/Makefile                        |   1 +
> > >  drivers/remoteproc/remoteproc_debugfs.c            |  38 ++-
> > >  drivers/remoteproc/st_remoteproc.c                 | 297 +++++++++++++++++++++
> > >  7 files changed, 455 insertions(+), 2 deletions(-)
> > >  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> > >  create mode 100644 drivers/remoteproc/st_remoteproc.c
> > >
> >

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog