* [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms
@ 2016-01-12 12:46 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: kernel, maxime.coquelin, ohad, devicetree, Nathan_Lynch,
f.fainelli, ludovic.barre, s-anna, 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms
@ 2016-01-12 12:46 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: kernel-F5mvAk5X5gdBDgjK7y7TUQ, maxime.coquelin-qxv4g6HH51o,
ohad-Ix1uc/W3ht7QT0dZR+AlfA, devicetree-u79uwXL29TY76Z2rM5mHXA,
Nathan_Lynch-nmGgyN9QBj3QT0dZR+AlfA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, ludovic.barre-qxv4g6HH51o,
s-anna-l0cyMroinI0, 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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms
@ 2016-01-12 12:46 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v5 1/7] remoteproc: debugfs: Check of invalid 'count' value
2016-01-12 12:46 ` Lee Jones
(?)
@ 2016-01-12 12:46 ` Lee Jones
-1 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: kernel, maxime.coquelin, ohad, devicetree, Nathan_Lynch,
f.fainelli, ludovic.barre, s-anna, 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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 1/7] remoteproc: debugfs: Check of invalid 'count' value
@ 2016-01-12 12:46 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: ohad, devicetree, f.fainelli, kernel, Nathan_Lynch, Lee Jones,
ludovic.barre, maxime.coquelin
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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 1/7] remoteproc: debugfs: Check of invalid 'count' value
@ 2016-01-12 12:46 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver
2016-01-12 12:46 ` Lee Jones
@ 2016-01-12 12:46 ` Lee Jones
-1 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: kernel, maxime.coquelin, ohad, devicetree, Nathan_Lynch,
f.fainelli, ludovic.barre, s-anna, 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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver
@ 2016-01-12 12:46 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 3/7] remoteproc: debugfs: Add ability to boot remote processor using debugfs
2016-01-12 12:46 ` Lee Jones
(?)
@ 2016-01-12 12:46 ` Lee Jones
-1 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: kernel, maxime.coquelin, ohad, devicetree, Nathan_Lynch,
f.fainelli, ludovic.barre, s-anna, 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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 3/7] remoteproc: debugfs: Add ability to boot remote processor using debugfs
@ 2016-01-12 12:46 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: ohad, devicetree, f.fainelli, kernel, Nathan_Lynch, Lee Jones,
ludovic.barre, maxime.coquelin
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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 3/7] remoteproc: debugfs: Add ability to boot remote processor using debugfs
@ 2016-01-12 12:46 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 4/7] remoteproc: Supply controller driver for ST's Remote Processors
2016-01-12 12:46 ` Lee Jones
@ 2016-01-12 12:46 ` Lee Jones
-1 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: kernel, maxime.coquelin, ohad, devicetree, Nathan_Lynch,
f.fainelli, ludovic.barre, s-anna, 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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 4/7] remoteproc: Supply controller driver for ST's Remote Processors
@ 2016-01-12 12:46 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 5/7] MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
2016-01-12 12:46 ` Lee Jones
(?)
@ 2016-01-12 12:46 ` Lee Jones
-1 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: kernel, maxime.coquelin, ohad, devicetree, Nathan_Lynch,
f.fainelli, ludovic.barre, s-anna, 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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 5/7] MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
@ 2016-01-12 12:46 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: ohad, devicetree, f.fainelli, kernel, Nathan_Lynch, Lee Jones,
ludovic.barre, maxime.coquelin
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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 5/7] MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
@ 2016-01-12 12:46 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 6/7] ARM: STiH407: Add nodes for RemoteProc
2016-01-12 12:46 ` Lee Jones
@ 2016-01-12 12:46 ` Lee Jones
-1 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: kernel, maxime.coquelin, ohad, devicetree, Nathan_Lynch,
f.fainelli, ludovic.barre, s-anna, 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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 6/7] ARM: STiH407: Add nodes for RemoteProc
@ 2016-01-12 12:46 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
2016-01-12 12:46 ` Lee Jones
@ 2016-01-12 12:46 ` Lee Jones
-1 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: kernel, maxime.coquelin, ohad, devicetree, Nathan_Lynch,
f.fainelli, ludovic.barre, s-anna, 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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
@ 2016-01-12 12:46 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 12:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 61+ messages in thread
* Re: [PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver
@ 2016-01-12 14:33 ` Rob Herring
0 siblings, 0 replies; 61+ messages in thread
From: Rob Herring @ 2016-01-12 14:33 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, kernel, maxime.coquelin, ohad,
devicetree, Nathan_Lynch, f.fainelli, ludovic.barre, s-anna
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>
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver
@ 2016-01-12 14:33 ` Rob Herring
0 siblings, 0 replies; 61+ messages in thread
From: Rob Herring @ 2016-01-12 14:33 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-F5mvAk5X5gdBDgjK7y7TUQ, maxime.coquelin-qxv4g6HH51o,
ohad-Ix1uc/W3ht7QT0dZR+AlfA, devicetree-u79uwXL29TY76Z2rM5mHXA,
Nathan_Lynch-nmGgyN9QBj3QT0dZR+AlfA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, ludovic.barre-qxv4g6HH51o,
s-anna-l0cyMroinI0
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver
@ 2016-01-12 14:33 ` Rob Herring
0 siblings, 0 replies; 61+ messages in thread
From: Rob Herring @ 2016-01-12 14:33 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver
2016-01-12 14:33 ` Rob Herring
@ 2016-01-12 14:46 ` Lee Jones
-1 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 14:46 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel, linux-kernel, kernel, maxime.coquelin, ohad,
devicetree, Nathan_Lynch, f.fainelli, ludovic.barre, s-anna
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver
@ 2016-01-12 14:46 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 14:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v5 4/7] remoteproc: Supply controller driver for ST's Remote Processors
2016-01-12 12:46 ` Lee Jones
@ 2016-01-12 14:47 ` Lee Jones
-1 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 14:47 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: kernel, maxime.coquelin, ohad, devicetree, Nathan_Lynch,
f.fainelli, ludovic.barre, s-anna
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v5 4/7] remoteproc: Supply controller driver for ST's Remote Processors
@ 2016-01-12 14:47 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-12 14:47 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms
@ 2016-01-27 7:31 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-27 7:31 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: kernel, maxime.coquelin, ohad, devicetree, Nathan_Lynch,
f.fainelli, ludovic.barre, s-anna
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms
@ 2016-01-27 7:31 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-27 7:31 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: kernel-F5mvAk5X5gdBDgjK7y7TUQ, maxime.coquelin-qxv4g6HH51o,
ohad-Ix1uc/W3ht7QT0dZR+AlfA, devicetree-u79uwXL29TY76Z2rM5mHXA,
Nathan_Lynch-nmGgyN9QBj3QT0dZR+AlfA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, ludovic.barre-qxv4g6HH51o,
s-anna-l0cyMroinI0
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms
@ 2016-01-27 7:31 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-01-27 7:31 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms
2016-01-27 7:31 ` Lee Jones
@ 2016-01-27 19:19 ` Bjorn Andersson
-1 siblings, 0 replies; 61+ messages in thread
From: Bjorn Andersson @ 2016-01-27 19:19 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, kernel, Maxime Coquelin,
Ohad Ben-Cohen, Nathan Lynch, Florian Fainelli, ludovic.barre,
Suman Anna
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms
@ 2016-01-27 19:19 ` Bjorn Andersson
0 siblings, 0 replies; 61+ messages in thread
From: Bjorn Andersson @ 2016-01-27 19:19 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms
2016-01-27 19:19 ` Bjorn Andersson
@ 2016-03-02 15:43 ` Lee Jones
-1 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-03-02 15:43 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-arm-kernel, linux-kernel, kernel, Maxime Coquelin,
Ohad Ben-Cohen, Nathan Lynch, Florian Fainelli, ludovic.barre,
Suman Anna
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms
@ 2016-03-02 15:43 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-03-02 15:43 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
@ 2016-03-16 16:35 ` Peter Griffin
0 siblings, 0 replies; 61+ messages in thread
From: Peter Griffin @ 2016-03-16 16:35 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, ohad, devicetree, f.fainelli,
kernel, Nathan_Lynch, s-anna
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.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
@ 2016-03-16 16:35 ` Peter Griffin
0 siblings, 0 replies; 61+ messages in thread
From: Peter Griffin @ 2016-03-16 16:35 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ohad-Ix1uc/W3ht7QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, kernel-F5mvAk5X5gdBDgjK7y7TUQ,
Nathan_Lynch-nmGgyN9QBj3QT0dZR+AlfA, s-anna-l0cyMroinI0
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
@ 2016-03-16 16:35 ` Peter Griffin
0 siblings, 0 replies; 61+ messages in thread
From: Peter Griffin @ 2016-03-16 16:35 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [STLinux Kernel] [PATCH v5 4/7] remoteproc: Supply controller driver for ST's Remote Processors
2016-01-12 12:46 ` Lee Jones
@ 2016-03-16 16:38 ` Peter Griffin
-1 siblings, 0 replies; 61+ messages in thread
From: Peter Griffin @ 2016-03-16 16:38 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, ohad, devicetree, f.fainelli,
kernel, Nathan_Lynch, s-anna
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.
^ permalink raw reply [flat|nested] 61+ messages in thread
* [STLinux Kernel] [PATCH v5 4/7] remoteproc: Supply controller driver for ST's Remote Processors
@ 2016-03-16 16:38 ` Peter Griffin
0 siblings, 0 replies; 61+ messages in thread
From: Peter Griffin @ 2016-03-16 16:38 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [STLinux Kernel] [PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver
2016-01-12 12:46 ` Lee Jones
@ 2016-03-16 16:39 ` Peter Griffin
-1 siblings, 0 replies; 61+ messages in thread
From: Peter Griffin @ 2016-03-16 16:39 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, ohad, devicetree, f.fainelli,
kernel, Nathan_Lynch, s-anna
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>
^ permalink raw reply [flat|nested] 61+ messages in thread
* [STLinux Kernel] [PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver
@ 2016-03-16 16:39 ` Peter Griffin
0 siblings, 0 replies; 61+ messages in thread
From: Peter Griffin @ 2016-03-16 16:39 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [STLinux Kernel] [PATCH v5 5/7] MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
2016-01-12 12:46 ` Lee Jones
@ 2016-03-16 16:40 ` Peter Griffin
-1 siblings, 0 replies; 61+ messages in thread
From: Peter Griffin @ 2016-03-16 16:40 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, ohad, devicetree, f.fainelli,
kernel, Nathan_Lynch, s-anna
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>
^ permalink raw reply [flat|nested] 61+ messages in thread
* [STLinux Kernel] [PATCH v5 5/7] MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE
@ 2016-03-16 16:40 ` Peter Griffin
0 siblings, 0 replies; 61+ messages in thread
From: Peter Griffin @ 2016-03-16 16:40 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [STLinux Kernel] [PATCH v5 3/7] remoteproc: debugfs: Add ability to boot remote processor using debugfs
@ 2016-03-16 16:44 ` Peter Griffin
0 siblings, 0 replies; 61+ messages in thread
From: Peter Griffin @ 2016-03-16 16:44 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, ohad, devicetree, f.fainelli,
kernel, Nathan_Lynch, s-anna
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>
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [STLinux Kernel] [PATCH v5 3/7] remoteproc: debugfs: Add ability to boot remote processor using debugfs
@ 2016-03-16 16:44 ` Peter Griffin
0 siblings, 0 replies; 61+ messages in thread
From: Peter Griffin @ 2016-03-16 16:44 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ohad-Ix1uc/W3ht7QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, kernel-F5mvAk5X5gdBDgjK7y7TUQ,
Nathan_Lynch-nmGgyN9QBj3QT0dZR+AlfA, s-anna-l0cyMroinI0
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [STLinux Kernel] [PATCH v5 3/7] remoteproc: debugfs: Add ability to boot remote processor using debugfs
@ 2016-03-16 16:44 ` Peter Griffin
0 siblings, 0 replies; 61+ messages in thread
From: Peter Griffin @ 2016-03-16 16:44 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
2016-03-16 16:35 ` Peter Griffin
(?)
@ 2016-03-16 16:55 ` Lee Jones
-1 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-03-16 16:55 UTC (permalink / raw)
To: Peter Griffin
Cc: linux-arm-kernel, linux-kernel, ohad, devicetree, f.fainelli,
kernel, Nathan_Lynch, s-anna
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
@ 2016-03-16 16:55 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-03-16 16:55 UTC (permalink / raw)
To: Peter Griffin
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ohad-Ix1uc/W3ht7QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, kernel-F5mvAk5X5gdBDgjK7y7TUQ,
Nathan_Lynch-nmGgyN9QBj3QT0dZR+AlfA, s-anna-l0cyMroinI0
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
@ 2016-03-16 16:55 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-03-16 16:55 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
2016-03-16 16:55 ` Lee Jones
(?)
@ 2016-03-16 20:10 ` Peter Griffin
-1 siblings, 0 replies; 61+ messages in thread
From: Peter Griffin @ 2016-03-16 20:10 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, ohad, devicetree, f.fainelli,
kernel, Nathan_Lynch, s-anna
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.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
@ 2016-03-16 20:10 ` Peter Griffin
0 siblings, 0 replies; 61+ messages in thread
From: Peter Griffin @ 2016-03-16 20:10 UTC (permalink / raw)
To: Lee Jones
Cc: ohad, devicetree, f.fainelli, kernel, Nathan_Lynch, linux-kernel,
linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 61+ messages in thread
* [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
@ 2016-03-16 20:10 ` Peter Griffin
0 siblings, 0 replies; 61+ messages in thread
From: Peter Griffin @ 2016-03-16 20:10 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 61+ messages in thread
* RE: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
2016-03-16 20:10 ` Peter Griffin
(?)
@ 2016-03-17 9:05 ` Loic PALLARDY
-1 siblings, 0 replies; 61+ messages in thread
From: Loic PALLARDY @ 2016-03-17 9:05 UTC (permalink / raw)
To: Peter Griffin, Lee Jones
Cc: ohad, devicetree, f.fainelli, kernel, Nathan_Lynch, linux-kernel,
s-anna, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* RE: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
@ 2016-03-17 9:05 ` Loic PALLARDY
0 siblings, 0 replies; 61+ messages in thread
From: Loic PALLARDY @ 2016-03-17 9:05 UTC (permalink / raw)
To: Peter Griffin, Lee Jones
Cc: ohad, devicetree, f.fainelli, kernel, Nathan_Lynch, linux-kernel,
s-anna, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
@ 2016-03-17 9:05 ` Loic PALLARDY
0 siblings, 0 replies; 61+ messages in thread
From: Loic PALLARDY @ 2016-03-17 9:05 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
2016-03-17 9:05 ` Loic PALLARDY
(?)
@ 2016-03-17 10:18 ` Lee Jones
-1 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-03-17 10:18 UTC (permalink / raw)
To: Loic PALLARDY
Cc: Peter Griffin, ohad, devicetree, f.fainelli, kernel,
Nathan_Lynch, linux-kernel, s-anna, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
@ 2016-03-17 10:18 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-03-17 10:18 UTC (permalink / raw)
To: Loic PALLARDY
Cc: Peter Griffin, ohad, devicetree, f.fainelli, kernel,
Nathan_Lynch, linux-kernel, s-anna, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [STLinux Kernel] [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory
@ 2016-03-17 10:18 ` Lee Jones
0 siblings, 0 replies; 61+ messages in thread
From: Lee Jones @ 2016-03-17 10:18 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v5 6/7] ARM: STiH407: Add nodes for RemoteProc
2016-01-12 12:46 ` Lee Jones
(?)
@ 2016-04-13 22:04 ` Olof Johansson
-1 siblings, 0 replies; 61+ messages in thread
From: Olof Johansson @ 2016-04-13 22:04 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, kernel, Maxime Coquelin,
Ohad Ben-Cohen, devicetree, Nathan Lynch, Florian Fainelli,
ludovic.barre, Suman Anna
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v5 6/7] ARM: STiH407: Add nodes for RemoteProc
@ 2016-04-13 22:04 ` Olof Johansson
0 siblings, 0 replies; 61+ messages in thread
From: Olof Johansson @ 2016-04-13 22:04 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, kernel, Maxime Coquelin,
Ohad Ben-Cohen, devicetree, Nathan Lynch, Florian Fainelli,
ludovic.barre, Suman Anna
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
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v5 6/7] ARM: STiH407: Add nodes for RemoteProc
@ 2016-04-13 22:04 ` Olof Johansson
0 siblings, 0 replies; 61+ messages in thread
From: Olof Johansson @ 2016-04-13 22:04 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 61+ messages in thread
end of thread, other threads:[~2016-04-13 22:04 UTC | newest]
Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-12 12:46 [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms Lee Jones
2016-01-12 12:46 ` Lee Jones
2016-01-12 12:46 ` Lee Jones
2016-01-12 12:46 ` [PATCH v5 1/7] remoteproc: debugfs: Check of invalid 'count' value Lee Jones
2016-01-12 12:46 ` Lee Jones
2016-01-12 12:46 ` Lee Jones
2016-01-12 12:46 ` [PATCH v5 2/7] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver Lee Jones
2016-01-12 12:46 ` Lee Jones
2016-01-12 14:33 ` Rob Herring
2016-01-12 14:33 ` Rob Herring
2016-01-12 14:33 ` Rob Herring
2016-01-12 14:46 ` Lee Jones
2016-01-12 14:46 ` Lee Jones
2016-03-16 16:39 ` [STLinux Kernel] " Peter Griffin
2016-03-16 16:39 ` Peter Griffin
2016-01-12 12:46 ` [PATCH v5 3/7] remoteproc: debugfs: Add ability to boot remote processor using debugfs Lee Jones
2016-01-12 12:46 ` Lee Jones
2016-01-12 12:46 ` Lee Jones
2016-03-16 16:44 ` [STLinux Kernel] " Peter Griffin
2016-03-16 16:44 ` Peter Griffin
2016-03-16 16:44 ` Peter Griffin
2016-01-12 12:46 ` [PATCH v5 4/7] remoteproc: Supply controller driver for ST's Remote Processors Lee Jones
2016-01-12 12:46 ` Lee Jones
2016-01-12 14:47 ` Lee Jones
2016-01-12 14:47 ` Lee Jones
2016-03-16 16:38 ` [STLinux Kernel] " Peter Griffin
2016-03-16 16:38 ` Peter Griffin
2016-01-12 12:46 ` [PATCH v5 5/7] MAINTAINERS: Add ST's Remote Processor Driver to ARM/STI ARCHITECTURE Lee Jones
2016-01-12 12:46 ` Lee Jones
2016-01-12 12:46 ` Lee Jones
2016-03-16 16:40 ` [STLinux Kernel] " Peter Griffin
2016-03-16 16:40 ` Peter Griffin
2016-01-12 12:46 ` [PATCH v5 6/7] ARM: STiH407: Add nodes for RemoteProc Lee Jones
2016-01-12 12:46 ` Lee Jones
2016-04-13 22:04 ` Olof Johansson
2016-04-13 22:04 ` Olof Johansson
2016-04-13 22:04 ` Olof Johansson
2016-01-12 12:46 ` [PATCH v5 7/7] ARM: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory Lee Jones
2016-01-12 12:46 ` Lee Jones
2016-03-16 16:35 ` [STLinux Kernel] " Peter Griffin
2016-03-16 16:35 ` Peter Griffin
2016-03-16 16:35 ` Peter Griffin
2016-03-16 16:55 ` Lee Jones
2016-03-16 16:55 ` Lee Jones
2016-03-16 16:55 ` Lee Jones
2016-03-16 20:10 ` Peter Griffin
2016-03-16 20:10 ` Peter Griffin
2016-03-16 20:10 ` Peter Griffin
2016-03-17 9:05 ` Loic PALLARDY
2016-03-17 9:05 ` Loic PALLARDY
2016-03-17 9:05 ` Loic PALLARDY
2016-03-17 10:18 ` Lee Jones
2016-03-17 10:18 ` Lee Jones
2016-03-17 10:18 ` Lee Jones
2016-01-27 7:31 ` [PATCH v5 0/7] remoteproc: Add driver for STMicroelectronics platforms Lee Jones
2016-01-27 7:31 ` Lee Jones
2016-01-27 7:31 ` Lee Jones
2016-01-27 19:19 ` Bjorn Andersson
2016-01-27 19:19 ` Bjorn Andersson
2016-03-02 15:43 ` Lee Jones
2016-03-02 15:43 ` Lee Jones
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.