[PATCH v2 0/5] Introduce PRU remoteproc consumer API

[PATCH v2 0/5] Introduce PRU remoteproc consumer API

[Grzegorz Jaszczyk]

Hi All,

The Programmable Real-Time Unit and Industrial Communication Subsystem
(PRU-ICSS or simply PRUSS) on various TI SoCs consists of dual 32-bit
RISC cores (Programmable Real-Time Units, or PRUs) for program execution.

There are 3 foundation components for PRUSS subsystem: the PRUSS platform
driver, the PRUSS INTC driver and the PRUSS remoteproc driver. All were
already merged and can be found under:
1) drivers/soc/ti/pruss.c
   Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
2) drivers/irqchip/irq-pruss-intc.c
   Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
3) drivers/remoteproc/pru_rproc.c
   Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml

The programmable nature of the PRUs provide flexibility to implement custom
peripheral interfaces, fast real-time responses, or specialized data handling.
Example of a PRU consumer drivers will be:
  - Software UART over PRUSS
  - PRU-ICSS Ethernet EMAC

In order to make usage of common PRU resources and allow the consumer drivers to
configure the PRU hardware for specific usage the PRU API is introduced.

Patch #3 of this series depends on one not merged remteproc related patch [1].

Please see the individual patches for exact changes in each patch, following is
the only change from v1:
 - Change the 'prus' property name to 'ti,prus' as suggested by Rob Herring,
 which influences patch #1 and patch #2

[1] https://patchwork.kernel.org/project/linux-remoteproc/patch/20201121030156.22857-3-s-anna@ti.com/

Best regards,
Grzegorz

Roger Quadros (1):
  remoteproc: pru: Add pru_rproc_set_ctable() function

Suman Anna (2):
  dt-bindings: remoteproc: Add PRU consumer bindings
  remoteproc: pru: Deny rproc sysfs ops for PRU client driven boots

Tero Kristo (2):
  remoteproc: pru: Add APIs to get and put the PRU cores
  remoteproc: pru: Configure firmware based on client setup

 .../bindings/remoteproc/ti,pru-consumer.yaml  |  64 +++++
 drivers/remoteproc/pru_rproc.c                | 221 +++++++++++++++++-
 include/linux/pruss.h                         |  78 +++++++
 3 files changed, 360 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
 create mode 100644 include/linux/pruss.h

-- 
2.29.0

[PATCH v2 1/5] dt-bindings: remoteproc: Add PRU consumer bindings

[Grzegorz Jaszczyk]

From: Suman Anna <s-anna@ti.com>

Add a YAML binding document for PRU consumers. The binding includes
all the common properties that can be used by different PRU consumer
or application nodes and supported by the PRU remoteproc driver.
These are used to configure the PRU hardware for specific user
applications.

The application nodes themselves should define their own bindings.

Co-developed-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
---
v1->v2:
- Change the 'prus' property name to 'ti,prus' as suggested by Rob
  Herring.
---
 .../bindings/remoteproc/ti,pru-consumer.yaml  | 64 +++++++++++++++++++
 1 file changed, 64 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml

diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
new file mode 100644
index 000000000000..d6de34f9e6f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,pru-consumer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common TI PRU Consumer Binding
+
+maintainers:
+  - Suman Anna <s-anna@ti.com>
+
+description: |
+  A PRU application/consumer/user node typically uses one or more PRU device
+  nodes to implement a PRU application/functionality. Each application/client
+  node would need a reference to at least a PRU node, and optionally define
+  some properties needed for hardware/firmware configuration. The below
+  properties are a list of common properties supported by the PRU remoteproc
+  infrastructure.
+
+  The application nodes shall define their own bindings like regular platform
+  devices, so below are in addition to each node's bindings.
+
+properties:
+  ti,prus:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description: phandles to the PRU, RTU or Tx_PRU nodes used
+
+  firmware-name:
+    $ref: /schemas/types.yaml#/definitions/string-array
+    description: |
+      firmwares for the PRU cores, the default firmware for the core from
+      the PRU node will be used if not provided. The firmware names should
+      correspond to the PRU cores listed in the 'ti,prus' property
+
+  ti,pruss-gp-mux-sel:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    enum: [0, 1, 2, 3, 4]
+    description: |
+      array of values for the GP_MUX_SEL under PRUSS_GPCFG register for a PRU.
+      This selects the internal muxing scheme for the PRU instance. Values
+      should correspond to the PRU cores listed in the 'ti,prus' property. The
+      GP_MUX_SEL setting is a per-slice setting (one setting for PRU0, RTU0,
+      and Tx_PRU0 on K3 SoCs). Use the same value for all cores within the
+      same slice in the associative array. If the array size is smaller than
+      the size of 'ti,prus' property, the default out-of-reset value (0) for the
+      PRU core is used.
+
+required:
+  - ti,prus
+
+dependencies:
+  firmware-name: [ 'ti,prus' ]
+  ti,pruss-gp-mux-sel: [ 'ti,prus' ]
+
+additionalProperties: true
+
+examples:
+  - |
+    /* PRU application node example */
+    pru-app {
+        ti,prus = <&pru0>, <&pru1>;
+        firmware-name = "pruss-app-fw0", "pruss-app-fw1";
+        ti,pruss-gp-mux-sel = <2>, <1>;
+    };
-- 
2.29.0

[PATCH v2 2/5] remoteproc: pru: Add APIs to get and put the PRU cores

[Grzegorz Jaszczyk]

From: Tero Kristo <t-kristo@ti.com>

Add two new APIs, pru_rproc_get() and pru_rproc_put(), to the PRU
driver to allow client drivers to acquire and release the remoteproc
device associated with a PRU core. The PRU cores are treated as
resources with only one client owning it at a time.

The pru_rproc_get() function returns the rproc handle corresponding
to a PRU core identified by the device tree "ti,prus" property under
the client node. The pru_rproc_put() is the complementary function
to pru_rproc_get().

Co-developed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
---
v1->v2:
- Introduce relevant updates after changing the 'prus' property name to
  'ti,prus' in patch #1 as suggested by Rob Herring.
---
 drivers/remoteproc/pru_rproc.c | 125 ++++++++++++++++++++++++++++++++-
 include/linux/pruss.h          |  56 +++++++++++++++
 2 files changed, 178 insertions(+), 3 deletions(-)
 create mode 100644 include/linux/pruss.h

diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
index 2667919d76b3..568286040bc4 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -16,6 +16,7 @@
 #include <linux/module.h>
 #include <linux/of_device.h>
 #include <linux/of_irq.h>
+#include <linux/pruss.h>
 #include <linux/pruss_driver.h>
 #include <linux/remoteproc.h>
 
@@ -111,6 +112,8 @@ struct pru_private_data {
  * @rproc: remoteproc pointer for this PRU core
  * @data: PRU core specific data
  * @mem_regions: data for each of the PRU memory regions
+ * @client_np: client device node
+ * @lock: mutex to protect client usage
  * @fw_name: name of firmware image used during loading
  * @mapped_irq: virtual interrupt numbers of created fw specific mapping
  * @pru_interrupt_map: pointer to interrupt mapping description (firmware)
@@ -126,6 +129,8 @@ struct pru_rproc {
 	struct rproc *rproc;
 	const struct pru_private_data *data;
 	struct pruss_mem_region mem_regions[PRU_IOMEM_MAX];
+	struct device_node *client_np;
+	struct mutex lock; /* client access lock */
 	const char *fw_name;
 	unsigned int *mapped_irq;
 	struct pru_irq_rsc *pru_interrupt_map;
@@ -146,6 +151,119 @@ void pru_control_write_reg(struct pru_rproc *pru, unsigned int reg, u32 val)
 	writel_relaxed(val, pru->mem_regions[PRU_IOMEM_CTRL].va + reg);
 }
 
+static struct rproc *__pru_rproc_get(struct device_node *np, int index)
+{
+	struct device_node *rproc_np = NULL;
+	struct platform_device *pdev;
+	struct rproc *rproc;
+
+	rproc_np = of_parse_phandle(np, "ti,prus", index);
+	if (!rproc_np || !of_device_is_available(rproc_np))
+		return ERR_PTR(-ENODEV);
+
+	pdev = of_find_device_by_node(rproc_np);
+	of_node_put(rproc_np);
+
+	if (!pdev)
+		/* probably PRU not yet probed */
+		return ERR_PTR(-EPROBE_DEFER);
+
+	/* make sure it is PRU rproc */
+	if (!is_pru_rproc(&pdev->dev)) {
+		put_device(&pdev->dev);
+		return ERR_PTR(-ENODEV);
+	}
+
+	rproc = platform_get_drvdata(pdev);
+	put_device(&pdev->dev);
+	if (!rproc)
+		return ERR_PTR(-EPROBE_DEFER);
+
+	get_device(&rproc->dev);
+
+	return rproc;
+}
+
+/**
+ * pru_rproc_get() - get the PRU rproc instance from a device node
+ * @np: the user/client device node
+ * @index: index to use for the ti,prus property
+ * @pru_id: optional pointer to return the PRU remoteproc processor id
+ *
+ * This function looks through a client device node's "ti,prus" property at
+ * index @index and returns the rproc handle for a valid PRU remote processor if
+ * found. The function allows only one user to own the PRU rproc resource at a
+ * time. Caller must call pru_rproc_put() when done with using the rproc, not
+ * required if the function returns a failure.
+ *
+ * When optional @pru_id pointer is passed the PRU remoteproc processor id is
+ * returned.
+ *
+ * Return: rproc handle on success, and an ERR_PTR on failure using one
+ * of the following error values
+ *    -ENODEV if device is not found
+ *    -EBUSY if PRU is already acquired by anyone
+ *    -EPROBE_DEFER is PRU device is not probed yet
+ */
+struct rproc *pru_rproc_get(struct device_node *np, int index,
+			    enum pruss_pru_id *pru_id)
+{
+	struct rproc *rproc;
+	struct pru_rproc *pru;
+	struct device *dev;
+
+	rproc = __pru_rproc_get(np, index);
+	if (IS_ERR(rproc))
+		return rproc;
+
+	pru = rproc->priv;
+	dev = &rproc->dev;
+
+	mutex_lock(&pru->lock);
+
+	if (pru->client_np) {
+		mutex_unlock(&pru->lock);
+		put_device(dev);
+		return ERR_PTR(-EBUSY);
+	}
+
+	pru->client_np = np;
+
+	mutex_unlock(&pru->lock);
+
+	if (pru_id)
+		*pru_id = pru->id;
+
+	return rproc;
+}
+EXPORT_SYMBOL_GPL(pru_rproc_get);
+
+/**
+ * pru_rproc_put() - release the PRU rproc resource
+ * @rproc: the rproc resource to release
+ *
+ * Releases the PRU rproc resource and makes it available to other
+ * users.
+ */
+void pru_rproc_put(struct rproc *rproc)
+{
+	struct pru_rproc *pru;
+
+	if (IS_ERR_OR_NULL(rproc) || !is_pru_rproc(rproc->dev.parent))
+		return;
+
+	pru = rproc->priv;
+	if (!pru->client_np)
+		return;
+
+	mutex_lock(&pru->lock);
+	pru->client_np = NULL;
+	mutex_unlock(&pru->lock);
+
+	put_device(&rproc->dev);
+}
+EXPORT_SYMBOL_GPL(pru_rproc_put);
+
 static inline u32 pru_debug_read_reg(struct pru_rproc *pru, unsigned int reg)
 {
 	return readl_relaxed(pru->mem_regions[PRU_IOMEM_DEBUG].va + reg);
@@ -706,14 +824,14 @@ static int pru_rproc_set_id(struct pru_rproc *pru)
 	case RTU0_IRAM_ADDR_MASK:
 		fallthrough;
 	case PRU0_IRAM_ADDR_MASK:
-		pru->id = 0;
+		pru->id = PRUSS_PRU0;
 		break;
 	case TX_PRU1_IRAM_ADDR_MASK:
 		fallthrough;
 	case RTU1_IRAM_ADDR_MASK:
 		fallthrough;
 	case PRU1_IRAM_ADDR_MASK:
-		pru->id = 1;
+		pru->id = PRUSS_PRU1;
 		break;
 	default:
 		ret = -EINVAL;
@@ -775,6 +893,7 @@ static int pru_rproc_probe(struct platform_device *pdev)
 	pru->pruss = platform_get_drvdata(ppdev);
 	pru->rproc = rproc;
 	pru->fw_name = fw_name;
+	mutex_init(&pru->lock);
 
 	for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
 		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
@@ -859,7 +978,7 @@ MODULE_DEVICE_TABLE(of, pru_rproc_match);
 
 static struct platform_driver pru_rproc_driver = {
 	.driver = {
-		.name   = "pru-rproc",
+		.name = PRU_RPROC_DRVNAME,
 		.of_match_table = pru_rproc_match,
 		.suppress_bind_attrs = true,
 	},
diff --git a/include/linux/pruss.h b/include/linux/pruss.h
new file mode 100644
index 000000000000..43cb5c2eed08
--- /dev/null
+++ b/include/linux/pruss.h
@@ -0,0 +1,56 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/**
+ * PRU-ICSS Subsystem user interfaces
+ *
+ * Copyright (C) 2015-2020 Texas Instruments Incorporated - http://www.ti.com
+ *	Suman Anna <s-anna@ti.com>
+ */
+
+#ifndef __LINUX_PRUSS_H
+#define __LINUX_PRUSS_H
+
+#include <linux/device.h>
+#include <linux/types.h>
+
+#define PRU_RPROC_DRVNAME "pru-rproc"
+
+/*
+ * enum pruss_pru_id - PRU core identifiers
+ */
+enum pruss_pru_id {
+	PRUSS_PRU0 = 0,
+	PRUSS_PRU1,
+	PRUSS_NUM_PRUS,
+};
+
+struct device_node;
+
+#if IS_ENABLED(CONFIG_PRU_REMOTEPROC)
+
+struct rproc *pru_rproc_get(struct device_node *np, int index,
+			    enum pruss_pru_id *pru_id);
+void pru_rproc_put(struct rproc *rproc);
+
+#else
+
+static inline struct rproc *
+pru_rproc_get(struct device_node *np, int index, enum pruss_pru_id *pru_id)
+{
+	return ERR_PTR(-ENOTSUPP);
+}
+
+static inline void pru_rproc_put(struct rproc *rproc) { }
+
+#endif /* CONFIG_PRU_REMOTEPROC */
+
+static inline bool is_pru_rproc(struct device *dev)
+{
+	const char *drv_name = dev_driver_string(dev);
+
+	if (strncmp(drv_name, PRU_RPROC_DRVNAME, sizeof(PRU_RPROC_DRVNAME)))
+		return false;
+
+	return true;
+}
+
+#endif /* __LINUX_PRUSS_H */
-- 
2.29.0

[PATCH v2 3/5] remoteproc: pru: Deny rproc sysfs ops for PRU client driven boots

[Grzegorz Jaszczyk]

From: Suman Anna <s-anna@ti.com>

The PRU remoteproc driver is not configured for 'auto-boot' by default,
and allows to be booted either by in-kernel PRU client drivers or by
userspace using the generic remoteproc sysfs interfaces. The sysfs
interfaces should not be permitted to change the remoteproc firmwares
or states when a PRU is being managed by an in-kernel client driver.
Use the newly introduced remoteproc generic 'deny_sysfs_ops' flag to
provide these restrictions by setting and clearing it appropriately
during the PRU acquire and release steps.

Signed-off-by: Suman Anna <s-anna@ti.com>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
---
 drivers/remoteproc/pru_rproc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
index 568286040bc4..3ffd49f77cfc 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -228,6 +228,7 @@ struct rproc *pru_rproc_get(struct device_node *np, int index,
 	}
 
 	pru->client_np = np;
+	rproc->deny_sysfs_ops = true;
 
 	mutex_unlock(&pru->lock);
 
@@ -258,6 +259,7 @@ void pru_rproc_put(struct rproc *rproc)
 
 	mutex_lock(&pru->lock);
 	pru->client_np = NULL;
+	rproc->deny_sysfs_ops = false;
 	mutex_unlock(&pru->lock);
 
 	put_device(&rproc->dev);
-- 
2.29.0

[PATCH v2 4/5] remoteproc: pru: Add pru_rproc_set_ctable() function

[Grzegorz Jaszczyk]

From: Roger Quadros <rogerq@ti.com>

Some firmwares expect the OS drivers to configure the CTABLE
entries publishing dynamically allocated memory regions. For
example, the PRU Ethernet firmwares use the C28 and C30 entries
for retrieving the Shared RAM and System SRAM (OCMC) areas
allocated by the PRU Ethernet client driver.

Provide a way for users to do that through a new API,
pru_rproc_set_ctable(). The API returns 0 on success and
a negative value on error.

NOTE:
The programmable CTABLE entries are typically re-programmed by
the PRU firmwares when dealing with a certain block of memory
during block processing. This API provides an interface to the
PRU client drivers to publish a dynamically allocated memory
block with the PRU firmware using a CTABLE entry instead of a
negotiated address in shared memory. Additional synchronization
may be needed between the PRU client drivers and firmwares if
different addresses needs to be published at run-time reusing
the same CTABLE entry.

Co-developed-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Co-developed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
---
 drivers/remoteproc/pru_rproc.c | 59 ++++++++++++++++++++++++++++++++++
 include/linux/pruss.h          | 22 +++++++++++++
 2 files changed, 81 insertions(+)

diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
index 3ffd49f77cfc..a37c3f5838ea 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -118,6 +118,7 @@ struct pru_private_data {
  * @mapped_irq: virtual interrupt numbers of created fw specific mapping
  * @pru_interrupt_map: pointer to interrupt mapping description (firmware)
  * @pru_interrupt_map_sz: pru_interrupt_map size
+ * @rmw_lock: lock for read, modify, write operations on registers
  * @dbg_single_step: debug state variable to set PRU into single step mode
  * @dbg_continuous: debug state variable to restore PRU execution mode
  * @evt_count: number of mapped events
@@ -135,6 +136,7 @@ struct pru_rproc {
 	unsigned int *mapped_irq;
 	struct pru_irq_rsc *pru_interrupt_map;
 	size_t pru_interrupt_map_sz;
+	spinlock_t rmw_lock; /* register access lock */
 	u32 dbg_single_step;
 	u32 dbg_continuous;
 	u8 evt_count;
@@ -151,6 +153,23 @@ void pru_control_write_reg(struct pru_rproc *pru, unsigned int reg, u32 val)
 	writel_relaxed(val, pru->mem_regions[PRU_IOMEM_CTRL].va + reg);
 }
 
+static inline
+void pru_control_set_reg(struct pru_rproc *pru, unsigned int reg,
+			 u32 mask, u32 set)
+{
+	u32 val;
+	unsigned long flags;
+
+	spin_lock_irqsave(&pru->rmw_lock, flags);
+
+	val = pru_control_read_reg(pru, reg);
+	val &= ~mask;
+	val |= (set & mask);
+	pru_control_write_reg(pru, reg, val);
+
+	spin_unlock_irqrestore(&pru->rmw_lock, flags);
+}
+
 static struct rproc *__pru_rproc_get(struct device_node *np, int index)
 {
 	struct device_node *rproc_np = NULL;
@@ -266,6 +285,45 @@ void pru_rproc_put(struct rproc *rproc)
 }
 EXPORT_SYMBOL_GPL(pru_rproc_put);
 
+/**
+ * pru_rproc_set_ctable() - set the constant table index for the PRU
+ * @rproc: the rproc instance of the PRU
+ * @c: constant table index to set
+ * @addr: physical address to set it to
+ *
+ * Return: 0 on success, or errno in error case.
+ */
+int pru_rproc_set_ctable(struct rproc *rproc, enum pru_ctable_idx c, u32 addr)
+{
+	struct pru_rproc *pru = rproc->priv;
+	unsigned int reg;
+	u32 mask, set;
+	u16 idx;
+	u16 idx_mask;
+
+	if (IS_ERR_OR_NULL(rproc))
+		return -EINVAL;
+
+	if (!rproc->dev.parent || !is_pru_rproc(rproc->dev.parent))
+		return -ENODEV;
+
+	/* pointer is 16 bit and index is 8-bit so mask out the rest */
+	idx_mask = (c >= PRU_C28) ? 0xFFFF : 0xFF;
+
+	/* ctable uses bit 8 and upwards only */
+	idx = (addr >> 8) & idx_mask;
+
+	/* configurable ctable (i.e. C24) starts at PRU_CTRL_CTBIR0 */
+	reg = PRU_CTRL_CTBIR0 + 4 * (c >> 1);
+	mask = idx_mask << (16 * (c & 1));
+	set = idx << (16 * (c & 1));
+
+	pru_control_set_reg(pru, reg, mask, set);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pru_rproc_set_ctable);
+
 static inline u32 pru_debug_read_reg(struct pru_rproc *pru, unsigned int reg)
 {
 	return readl_relaxed(pru->mem_regions[PRU_IOMEM_DEBUG].va + reg);
@@ -895,6 +953,7 @@ static int pru_rproc_probe(struct platform_device *pdev)
 	pru->pruss = platform_get_drvdata(ppdev);
 	pru->rproc = rproc;
 	pru->fw_name = fw_name;
+	spin_lock_init(&pru->rmw_lock);
 	mutex_init(&pru->lock);
 
 	for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
diff --git a/include/linux/pruss.h b/include/linux/pruss.h
index 43cb5c2eed08..903d0c0b75be 100644
--- a/include/linux/pruss.h
+++ b/include/linux/pruss.h
@@ -23,13 +23,29 @@ enum pruss_pru_id {
 	PRUSS_NUM_PRUS,
 };
 
+/*
+ * enum pru_ctable_idx - Configurable Constant table index identifiers
+ */
+enum pru_ctable_idx {
+	PRU_C24 = 0,
+	PRU_C25,
+	PRU_C26,
+	PRU_C27,
+	PRU_C28,
+	PRU_C29,
+	PRU_C30,
+	PRU_C31,
+};
+
 struct device_node;
+struct rproc;
 
 #if IS_ENABLED(CONFIG_PRU_REMOTEPROC)
 
 struct rproc *pru_rproc_get(struct device_node *np, int index,
 			    enum pruss_pru_id *pru_id);
 void pru_rproc_put(struct rproc *rproc);
+int pru_rproc_set_ctable(struct rproc *rproc, enum pru_ctable_idx c, u32 addr);
 
 #else
 
@@ -41,6 +57,12 @@ pru_rproc_get(struct device_node *np, int index, enum pruss_pru_id *pru_id)
 
 static inline void pru_rproc_put(struct rproc *rproc) { }
 
+static inline int pru_rproc_set_ctable(struct rproc *rproc,
+				       enum pru_ctable_idx c, u32 addr)
+{
+	return -ENOTSUPP;
+}
+
 #endif /* CONFIG_PRU_REMOTEPROC */
 
 static inline bool is_pru_rproc(struct device *dev)
-- 
2.29.0

[PATCH v2 5/5] remoteproc: pru: Configure firmware based on client setup

[Grzegorz Jaszczyk]

From: Tero Kristo <t-kristo@ti.com>

Client device node property firmware-name is now used to configure
firmware for the PRU instances. The default firmware is also
restored once releasing the PRU resource.

Co-developed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
---
 drivers/remoteproc/pru_rproc.c | 35 ++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
index a37c3f5838ea..4a9c7973bf3a 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -170,6 +170,23 @@ void pru_control_set_reg(struct pru_rproc *pru, unsigned int reg,
 	spin_unlock_irqrestore(&pru->rmw_lock, flags);
 }
 
+/**
+ * pru_rproc_set_firmware() - set firmware for a pru core
+ * @rproc: the rproc instance of the PRU
+ * @fw_name: the new firmware name, or NULL if default is desired
+ *
+ * Return: 0 on success, or errno in error case.
+ */
+static int pru_rproc_set_firmware(struct rproc *rproc, const char *fw_name)
+{
+	struct pru_rproc *pru = rproc->priv;
+
+	if (!fw_name)
+		fw_name = pru->fw_name;
+
+	return rproc_set_firmware(rproc, fw_name);
+}
+
 static struct rproc *__pru_rproc_get(struct device_node *np, int index)
 {
 	struct device_node *rproc_np = NULL;
@@ -230,6 +247,8 @@ struct rproc *pru_rproc_get(struct device_node *np, int index,
 	struct rproc *rproc;
 	struct pru_rproc *pru;
 	struct device *dev;
+	const char *fw_name;
+	int ret;
 
 	rproc = __pru_rproc_get(np, index);
 	if (IS_ERR(rproc))
@@ -254,7 +273,21 @@ struct rproc *pru_rproc_get(struct device_node *np, int index,
 	if (pru_id)
 		*pru_id = pru->id;
 
+	ret = of_property_read_string_index(np, "firmware-name", index,
+					    &fw_name);
+	if (!ret) {
+		ret = pru_rproc_set_firmware(rproc, fw_name);
+		if (ret) {
+			dev_err(dev, "failed to set firmware: %d\n", ret);
+			goto err;
+		}
+	}
+
 	return rproc;
+
+err:
+	pru_rproc_put(rproc);
+	return ERR_PTR(ret);
 }
 EXPORT_SYMBOL_GPL(pru_rproc_get);
 
@@ -276,6 +309,8 @@ void pru_rproc_put(struct rproc *rproc)
 	if (!pru->client_np)
 		return;
 
+	pru_rproc_set_firmware(rproc, NULL);
+
 	mutex_lock(&pru->lock);
 	pru->client_np = NULL;
 	rproc->deny_sysfs_ops = false;
-- 
2.29.0

Re: [PATCH v2 0/5] Introduce PRU remoteproc consumer API

[David Lechner]

> Please see the individual patches for exact changes in each patch, following is
> the only change from v1:
>  - Change the 'prus' property name to 'ti,prus' as suggested by Rob Herring,
>  which influences patch #1 and patch #2

It looks like "soc: ti: pruss: Add pruss_{request, release}_mem_region() API"
was also dropped in v2. Was this intentional?

Re: [PATCH v2 2/5] remoteproc: pru: Add APIs to get and put the PRU cores

[David Lechner]

> 
> @@ -706,14 +824,14 @@ static int pru_rproc_set_id(struct pru_rproc *pru)
>  	case RTU0_IRAM_ADDR_MASK:
>  		fallthrough;
>  	case PRU0_IRAM_ADDR_MASK:
> -		pru->id = 0;
> +		pru->id = PRUSS_PRU0;
>  		break;
>  	case TX_PRU1_IRAM_ADDR_MASK:
>  		fallthrough;
>  	case RTU1_IRAM_ADDR_MASK:
>  		fallthrough;
>  	case PRU1_IRAM_ADDR_MASK:
> -		pru->id = 1;
> +		pru->id = PRUSS_PRU1;
>  		break;
>  	default:
>  		ret = -EINVAL;



There is a similar opportunity for using PRUSS_PRU1 in pru_d_da_to_va()

Re: [PATCH v2 0/5] Introduce PRU remoteproc consumer API

[Suman Anna]

Hi David,

On 1/4/21 2:11 PM, David Lechner wrote:
> 
>> Please see the individual patches for exact changes in each patch, following is
>> the only change from v1:
>>  - Change the 'prus' property name to 'ti,prus' as suggested by Rob Herring,
>>  which influences patch #1 and patch #2
> 
> It looks like "soc: ti: pruss: Add pruss_{request, release}_mem_region() API"
> was also dropped in v2. Was this intentional?

No, it is not dropped. That patch is part of a different similarly titled
"Introduce PRU platform consumer API" series [1], which is dependent on this
series and is against a different folder (maintainer): drivers/soc/ti.

regards
Suman

[1] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=400787

Re: [PATCH v2 0/5] Introduce PRU remoteproc consumer API

[Mathieu Poirier]

On Wed, Dec 16, 2020 at 05:52:34PM +0100, Grzegorz Jaszczyk wrote:
> Hi All,
> 
> The Programmable Real-Time Unit and Industrial Communication Subsystem
> (PRU-ICSS or simply PRUSS) on various TI SoCs consists of dual 32-bit
> RISC cores (Programmable Real-Time Units, or PRUs) for program execution.
> 
> There are 3 foundation components for PRUSS subsystem: the PRUSS platform
> driver, the PRUSS INTC driver and the PRUSS remoteproc driver. All were
> already merged and can be found under:
> 1) drivers/soc/ti/pruss.c
>    Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
> 2) drivers/irqchip/irq-pruss-intc.c
>    Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
> 3) drivers/remoteproc/pru_rproc.c
>    Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
> 
> The programmable nature of the PRUs provide flexibility to implement custom
> peripheral interfaces, fast real-time responses, or specialized data handling.
> Example of a PRU consumer drivers will be:
>   - Software UART over PRUSS
>   - PRU-ICSS Ethernet EMAC
> 
> In order to make usage of common PRU resources and allow the consumer drivers to
> configure the PRU hardware for specific usage the PRU API is introduced.
> 
> Patch #3 of this series depends on one not merged remteproc related patch [1].
> 
> Please see the individual patches for exact changes in each patch, following is
> the only change from v1:
>  - Change the 'prus' property name to 'ti,prus' as suggested by Rob Herring,
>  which influences patch #1 and patch #2
> 
> [1] https://patchwork.kernel.org/project/linux-remoteproc/patch/20201121030156.22857-3-s-anna@ti.com/
> 
> Best regards,
> Grzegorz
> 
> Roger Quadros (1):
>   remoteproc: pru: Add pru_rproc_set_ctable() function
> 
> Suman Anna (2):
>   dt-bindings: remoteproc: Add PRU consumer bindings
>   remoteproc: pru: Deny rproc sysfs ops for PRU client driven boots
> 
> Tero Kristo (2):
>   remoteproc: pru: Add APIs to get and put the PRU cores
>   remoteproc: pru: Configure firmware based on client setup
> 
>  .../bindings/remoteproc/ti,pru-consumer.yaml  |  64 +++++
>  drivers/remoteproc/pru_rproc.c                | 221 +++++++++++++++++-
>  include/linux/pruss.h                         |  78 +++++++

This patchset is giving checkpatch.pl errors and as such will not go further
with this revision.

>  3 files changed, 360 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
>  create mode 100644 include/linux/pruss.h
> 
> -- 
> 2.29.0
> 

Re: [PATCH v2 0/5] Introduce PRU remoteproc consumer API

[Suman Anna]

Hi Mathieu,

On 1/6/21 5:27 PM, Mathieu Poirier wrote:
> On Wed, Dec 16, 2020 at 05:52:34PM +0100, Grzegorz Jaszczyk wrote:
>> Hi All,
>>
>> The Programmable Real-Time Unit and Industrial Communication Subsystem
>> (PRU-ICSS or simply PRUSS) on various TI SoCs consists of dual 32-bit
>> RISC cores (Programmable Real-Time Units, or PRUs) for program execution.
>>
>> There are 3 foundation components for PRUSS subsystem: the PRUSS platform
>> driver, the PRUSS INTC driver and the PRUSS remoteproc driver. All were
>> already merged and can be found under:
>> 1) drivers/soc/ti/pruss.c
>>    Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
>> 2) drivers/irqchip/irq-pruss-intc.c
>>    Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
>> 3) drivers/remoteproc/pru_rproc.c
>>    Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
>>
>> The programmable nature of the PRUs provide flexibility to implement custom
>> peripheral interfaces, fast real-time responses, or specialized data handling.
>> Example of a PRU consumer drivers will be:
>>   - Software UART over PRUSS
>>   - PRU-ICSS Ethernet EMAC
>>
>> In order to make usage of common PRU resources and allow the consumer drivers to
>> configure the PRU hardware for specific usage the PRU API is introduced.
>>
>> Patch #3 of this series depends on one not merged remteproc related patch [1].
>>
>> Please see the individual patches for exact changes in each patch, following is
>> the only change from v1:
>>  - Change the 'prus' property name to 'ti,prus' as suggested by Rob Herring,
>>  which influences patch #1 and patch #2
>>
>> [1] https://patchwork.kernel.org/project/linux-remoteproc/patch/20201121030156.22857-3-s-anna@ti.com/
>>
>> Best regards,
>> Grzegorz
>>
>> Roger Quadros (1):
>>   remoteproc: pru: Add pru_rproc_set_ctable() function
>>
>> Suman Anna (2):
>>   dt-bindings: remoteproc: Add PRU consumer bindings
>>   remoteproc: pru: Deny rproc sysfs ops for PRU client driven boots
>>
>> Tero Kristo (2):
>>   remoteproc: pru: Add APIs to get and put the PRU cores
>>   remoteproc: pru: Configure firmware based on client setup
>>
>>  .../bindings/remoteproc/ti,pru-consumer.yaml  |  64 +++++
>>  drivers/remoteproc/pru_rproc.c                | 221 +++++++++++++++++-
>>  include/linux/pruss.h                         |  78 +++++++
> 
> This patchset is giving checkpatch.pl errors and as such will not go further
> with this revision.

Yeah, I am aware of those. Greg has intentionally skipped the checkpatch
warnings around ENOTSUPP, based on some similar discussion on a different patch,
https://lkml.org/lkml/2020/11/10/764.

Let me know if you prefer that we change these to EOPNOTSUPP.

regards
Suman

> 
>>  3 files changed, 360 insertions(+), 3 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
>>  create mode 100644 include/linux/pruss.h
>>
>> -- 
>> 2.29.0
>>

Re: [PATCH v2 0/5] Introduce PRU remoteproc consumer API

[Mathieu Poirier]

On Wed, Jan 06, 2021 at 06:03:25PM -0600, Suman Anna wrote:
> Hi Mathieu,
> 
> On 1/6/21 5:27 PM, Mathieu Poirier wrote:
> > On Wed, Dec 16, 2020 at 05:52:34PM +0100, Grzegorz Jaszczyk wrote:
> >> Hi All,
> >>
> >> The Programmable Real-Time Unit and Industrial Communication Subsystem
> >> (PRU-ICSS or simply PRUSS) on various TI SoCs consists of dual 32-bit
> >> RISC cores (Programmable Real-Time Units, or PRUs) for program execution.
> >>
> >> There are 3 foundation components for PRUSS subsystem: the PRUSS platform
> >> driver, the PRUSS INTC driver and the PRUSS remoteproc driver. All were
> >> already merged and can be found under:
> >> 1) drivers/soc/ti/pruss.c
> >>    Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
> >> 2) drivers/irqchip/irq-pruss-intc.c
> >>    Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
> >> 3) drivers/remoteproc/pru_rproc.c
> >>    Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
> >>
> >> The programmable nature of the PRUs provide flexibility to implement custom
> >> peripheral interfaces, fast real-time responses, or specialized data handling.
> >> Example of a PRU consumer drivers will be:
> >>   - Software UART over PRUSS
> >>   - PRU-ICSS Ethernet EMAC
> >>
> >> In order to make usage of common PRU resources and allow the consumer drivers to
> >> configure the PRU hardware for specific usage the PRU API is introduced.
> >>
> >> Patch #3 of this series depends on one not merged remteproc related patch [1].
> >>
> >> Please see the individual patches for exact changes in each patch, following is
> >> the only change from v1:
> >>  - Change the 'prus' property name to 'ti,prus' as suggested by Rob Herring,
> >>  which influences patch #1 and patch #2
> >>
> >> [1] https://patchwork.kernel.org/project/linux-remoteproc/patch/20201121030156.22857-3-s-anna@ti.com/
> >>
> >> Best regards,
> >> Grzegorz
> >>
> >> Roger Quadros (1):
> >>   remoteproc: pru: Add pru_rproc_set_ctable() function
> >>
> >> Suman Anna (2):
> >>   dt-bindings: remoteproc: Add PRU consumer bindings
> >>   remoteproc: pru: Deny rproc sysfs ops for PRU client driven boots
> >>
> >> Tero Kristo (2):
> >>   remoteproc: pru: Add APIs to get and put the PRU cores
> >>   remoteproc: pru: Configure firmware based on client setup
> >>
> >>  .../bindings/remoteproc/ti,pru-consumer.yaml  |  64 +++++
> >>  drivers/remoteproc/pru_rproc.c                | 221 +++++++++++++++++-
> >>  include/linux/pruss.h                         |  78 +++++++
> > 
> > This patchset is giving checkpatch.pl errors and as such will not go further
> > with this revision.
> 
> Yeah, I am aware of those. Greg has intentionally skipped the checkpatch
> warnings around ENOTSUPP, based on some similar discussion on a different patch,
> https://lkml.org/lkml/2020/11/10/764.

I only see input from Andy and Lars in the thread you point out, nothing from
Greg.  I have also taken a look at the patch [1] that made checkpatch complain
about ENOTSUPP.  From what I see in that commit log the goal is to prevent new
additions of ENOTSUPP to the kernel.

Please modify and resend, otherwise I'm sure someone will send another patch to
fix it before the end of the cycle.

Thanks,
Mathieu

[1]. 6b9ea5ff5abd checkpatch: warn about uses of ENOTSUPP
> 
> Let me know if you prefer that we change these to EOPNOTSUPP.
> 
> regards
> Suman
> 
> > 
> >>  3 files changed, 360 insertions(+), 3 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> >>  create mode 100644 include/linux/pruss.h
> >>
> >> -- 
> >> 2.29.0
> >>
> 

Re: [PATCH v2 0/5] Introduce PRU remoteproc consumer API

[Suman Anna]

On 1/7/21 4:44 PM, Mathieu Poirier wrote:
> On Wed, Jan 06, 2021 at 06:03:25PM -0600, Suman Anna wrote:
>> Hi Mathieu,
>>
>> On 1/6/21 5:27 PM, Mathieu Poirier wrote:
>>> On Wed, Dec 16, 2020 at 05:52:34PM +0100, Grzegorz Jaszczyk wrote:
>>>> Hi All,
>>>>
>>>> The Programmable Real-Time Unit and Industrial Communication Subsystem
>>>> (PRU-ICSS or simply PRUSS) on various TI SoCs consists of dual 32-bit
>>>> RISC cores (Programmable Real-Time Units, or PRUs) for program execution.
>>>>
>>>> There are 3 foundation components for PRUSS subsystem: the PRUSS platform
>>>> driver, the PRUSS INTC driver and the PRUSS remoteproc driver. All were
>>>> already merged and can be found under:
>>>> 1) drivers/soc/ti/pruss.c
>>>>    Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
>>>> 2) drivers/irqchip/irq-pruss-intc.c
>>>>    Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
>>>> 3) drivers/remoteproc/pru_rproc.c
>>>>    Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
>>>>
>>>> The programmable nature of the PRUs provide flexibility to implement custom
>>>> peripheral interfaces, fast real-time responses, or specialized data handling.
>>>> Example of a PRU consumer drivers will be:
>>>>   - Software UART over PRUSS
>>>>   - PRU-ICSS Ethernet EMAC
>>>>
>>>> In order to make usage of common PRU resources and allow the consumer drivers to
>>>> configure the PRU hardware for specific usage the PRU API is introduced.
>>>>
>>>> Patch #3 of this series depends on one not merged remteproc related patch [1].
>>>>
>>>> Please see the individual patches for exact changes in each patch, following is
>>>> the only change from v1:
>>>>  - Change the 'prus' property name to 'ti,prus' as suggested by Rob Herring,
>>>>  which influences patch #1 and patch #2
>>>>
>>>> [1] https://patchwork.kernel.org/project/linux-remoteproc/patch/20201121030156.22857-3-s-anna@ti.com/
>>>>
>>>> Best regards,
>>>> Grzegorz
>>>>
>>>> Roger Quadros (1):
>>>>   remoteproc: pru: Add pru_rproc_set_ctable() function
>>>>
>>>> Suman Anna (2):
>>>>   dt-bindings: remoteproc: Add PRU consumer bindings
>>>>   remoteproc: pru: Deny rproc sysfs ops for PRU client driven boots
>>>>
>>>> Tero Kristo (2):
>>>>   remoteproc: pru: Add APIs to get and put the PRU cores
>>>>   remoteproc: pru: Configure firmware based on client setup
>>>>
>>>>  .../bindings/remoteproc/ti,pru-consumer.yaml  |  64 +++++
>>>>  drivers/remoteproc/pru_rproc.c                | 221 +++++++++++++++++-
>>>>  include/linux/pruss.h                         |  78 +++++++
>>>
>>> This patchset is giving checkpatch.pl errors and as such will not go further
>>> with this revision.
>>
>> Yeah, I am aware of those. Greg has intentionally skipped the checkpatch
>> warnings around ENOTSUPP, based on some similar discussion on a different patch,
>> https://lkml.org/lkml/2020/11/10/764.
> 
> I only see input from Andy and Lars in the thread you point out, nothing from
> Greg.  I have also taken a look at the patch [1] that made checkpatch complain
> about ENOTSUPP.  From what I see in that commit log the goal is to prevent new
> additions of ENOTSUPP to the kernel.
> 
> Please modify and resend, otherwise I'm sure someone will send another patch to
> fix it before the end of the cycle.

Yeah ok. I will send out a v3.

regards
Suman

> 
> Thanks,
> Mathieu
> 
> [1]. 6b9ea5ff5abd checkpatch: warn about uses of ENOTSUPP
>>
>> Let me know if you prefer that we change these to EOPNOTSUPP.
>>
>> regards
>> Suman
>>
>>>
>>>>  3 files changed, 360 insertions(+), 3 deletions(-)
>>>>  create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
>>>>  create mode 100644 include/linux/pruss.h
>>>>
>>>> -- 
>>>> 2.29.0
>>>>
>>

Re: [PATCH v2 0/5] Introduce PRU remoteproc consumer API

[santosh.shilimkar]

Hi Suman, Mathieu,

On 1/7/21 2:49 PM, Suman Anna wrote:
> On 1/7/21 4:44 PM, Mathieu Poirier wrote:
>> On Wed, Jan 06, 2021 at 06:03:25PM -0600, Suman Anna wrote:
>>> Hi Mathieu,
>>>
[...]
>> I only see input from Andy and Lars in the thread you point out, nothing from
>> Greg.  I have also taken a look at the patch [1] that made checkpatch complain
>> about ENOTSUPP.  From what I see in that commit log the goal is to prevent new
>> additions of ENOTSUPP to the kernel.
>>
>> Please modify and resend, otherwise I'm sure someone will send another patch to
>> fix it before the end of the cycle.
> 
> Yeah ok. I will send out a v3.
> 
I haven't seen v3 of this series yet. Please post it
if you would like to include it for 5.12.

Regards,
Santosh

Re: [PATCH v2 0/5] Introduce PRU remoteproc consumer API

[Suman Anna]

Hi Santosh,

On 1/24/21 10:34 PM, santosh.shilimkar@oracle.com wrote:
> Hi Suman, Mathieu,
> 
> On 1/7/21 2:49 PM, Suman Anna wrote:
>> On 1/7/21 4:44 PM, Mathieu Poirier wrote:
>>> On Wed, Jan 06, 2021 at 06:03:25PM -0600, Suman Anna wrote:
>>>> Hi Mathieu,
>>>>
> [...]
>>> I only see input from Andy and Lars in the thread you point out, nothing from
>>> Greg.  I have also taken a look at the patch [1] that made checkpatch complain
>>> about ENOTSUPP.  From what I see in that commit log the goal is to prevent new
>>> additions of ENOTSUPP to the kernel.
>>>
>>> Please modify and resend, otherwise I'm sure someone will send another patch to
>>> fix it before the end of the cycle.
>>
>> Yeah ok. I will send out a v3.
>>
> I haven't seen v3 of this series yet. Please post it
> if you would like to include it for 5.12.

This series is dependent on couple of patches that would have to come through
the remoteproc tree first, and I need to post the next versions of those as
well. So, let me sort out those first. You can drop this from your queue for 5.12.

regards
Suman

Re: [External] : Re: [PATCH v2 0/5] Introduce PRU remoteproc consumer API

[Santosh Shilimkar]

On Jan 25, 2021, at 7:43 AM, Suman Anna <s-anna@ti.com> wrote:
> 
> Hi Santosh,
> 
> On 1/24/21 10:34 PM, santosh.shilimkar@oracle.com wrote:
>> Hi Suman, Mathieu,
>> 
>> On 1/7/21 2:49 PM, Suman Anna wrote:
>>> On 1/7/21 4:44 PM, Mathieu Poirier wrote:
>>>> On Wed, Jan 06, 2021 at 06:03:25PM -0600, Suman Anna wrote:
>>>>> Hi Mathieu,
>>>>> 
>> [...]
>>>> I only see input from Andy and Lars in the thread you point out, nothing from
>>>> Greg.  I have also taken a look at the patch [1] that made checkpatch complain
>>>> about ENOTSUPP.  From what I see in that commit log the goal is to prevent new
>>>> additions of ENOTSUPP to the kernel.
>>>> 
>>>> Please modify and resend, otherwise I'm sure someone will send another patch to
>>>> fix it before the end of the cycle.
>>> 
>>> Yeah ok. I will send out a v3.
>>> 
>> I haven't seen v3 of this series yet. Please post it
>> if you would like to include it for 5.12.
> 
> This series is dependent on couple of patches that would have to come through
> the remoteproc tree first, and I need to post the next versions of those as
> well. So, let me sort out those first. You can drop this from your queue for 5.12.
> 
Sounds good.

Regards,
Santosh

Re: [PATCH v2 0/5] Introduce PRU remoteproc consumer API

[Christian Gmeiner]

HI all,

Am Di., 26. Jan. 2021 um 06:58 Uhr schrieb Suman Anna <s-anna@ti.com>:
>
> Hi Santosh,
>
> On 1/24/21 10:34 PM, santosh.shilimkar@oracle.com wrote:
> > Hi Suman, Mathieu,
> >
> > On 1/7/21 2:49 PM, Suman Anna wrote:
> >> On 1/7/21 4:44 PM, Mathieu Poirier wrote:
> >>> On Wed, Jan 06, 2021 at 06:03:25PM -0600, Suman Anna wrote:
> >>>> Hi Mathieu,
> >>>>
> > [...]
> >>> I only see input from Andy and Lars in the thread you point out, nothing from
> >>> Greg.  I have also taken a look at the patch [1] that made checkpatch complain
> >>> about ENOTSUPP.  From what I see in that commit log the goal is to prevent new
> >>> additions of ENOTSUPP to the kernel.
> >>>
> >>> Please modify and resend, otherwise I'm sure someone will send another patch to
> >>> fix it before the end of the cycle.
> >>
> >> Yeah ok. I will send out a v3.
> >>
> > I haven't seen v3 of this series yet. Please post it
> > if you would like to include it for 5.12.
>
> This series is dependent on couple of patches that would have to come through
> the remoteproc tree first, and I need to post the next versions of those as
> well. So, let me sort out those first. You can drop this from your queue for 5.12.
>

Is there any update on this patch series?

-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info/privacypolicy