This is the v4 of the patch series [1]. The v3 had some comments
on the DT patch that have been addressed here. The 6th patch in this
series was missed in the previous versions, so, it has been added now.
I have posted two more patch series that depend on this series, one to
the soc tree and another to the networking tree. I had sent all the 3
series, including this one as RFC [2] to get comments and to explain the
dependencies.
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.
[1] https://patchwork.kernel.org/project/linux-remoteproc/cover/[email protected]/
[2] https://patchwork.kernel.org/project/linux-remoteproc/cover/[email protected]/
Thanks and Regards,
Puranjay Mohan
Roger Quadros (1):
remoteproc: pru: Add pru_rproc_set_ctable() function
Suman Anna (2):
dt-bindings: remoteproc: Add PRU consumer bindings
remoteproc: pru: Make sysfs entries read-only for PRU client driven
boots
Tero Kristo (3):
remoteproc: pru: Add APIs to get and put the PRU cores
remoteproc: pru: Configure firmware based on client setup
remoteproc: pru: add support for configuring GPMUX based on client
setup
.../bindings/remoteproc/ti,pru-consumer.yaml | 69 +++++
drivers/remoteproc/pru_rproc.c | 254 +++++++++++++++++-
include/linux/pruss.h | 78 ++++++
3 files changed, 396 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
create mode 100644 include/linux/pruss.h
--
2.17.1
From: Suman Anna <[email protected]>
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 <[email protected]>
Signed-off-by: Tero Kristo <[email protected]>
Signed-off-by: Suman Anna <[email protected]>
Co-developed-by: Grzegorz Jaszczyk <[email protected]>
Signed-off-by: Grzegorz Jaszczyk <[email protected]>
Signed-off-by: Puranjay Mohan <[email protected]>
---
V3->V4:
* Addressed Rob's comments regarding max and min Items.
* removed the dependencies tag as it was redundant.
---
.../bindings/remoteproc/ti,pru-consumer.yaml | 69 +++++++++++++++++++
1 file changed, 69 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..df384b44259b
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
@@ -0,0 +1,69 @@
+# 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 <[email protected]>
+
+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
+ minItems: 1
+ maxItems: 6
+ items:
+ maxItems: 1
+
+ firmware-name:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ minItems: 1
+ maxItems: 6
+ 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
+ minItems: 1
+ maxItems: 6
+ items:
+ 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
+
+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.17.1
From: Suman Anna <[email protected]>
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 'sysfs_read_only' flag to
provide these restrictions by setting and clearing it appropriately
during the PRU acquire and release steps.
Signed-off-by: Suman Anna <[email protected]>
Co-developed-by: Grzegorz Jaszczyk <[email protected]>
Signed-off-by: Grzegorz Jaszczyk <[email protected]>
Signed-off-by: Puranjay Mohan <[email protected]>
---
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 7a35b400287a..9fed3e0372d3 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -231,6 +231,7 @@ struct rproc *pru_rproc_get(struct device_node *np, int index,
}
pru->client_np = np;
+ rproc->sysfs_read_only = true;
mutex_unlock(&pru->lock);
@@ -265,6 +266,7 @@ void pru_rproc_put(struct rproc *rproc)
}
pru->client_np = NULL;
+ rproc->sysfs_read_only = false;
mutex_unlock(&pru->lock);
put_device(&rproc->dev);
--
2.17.1
From: Roger Quadros <[email protected]>
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 <[email protected]>
Signed-off-by: Andrew F. Davis <[email protected]>
Co-developed-by: Suman Anna <[email protected]>
Signed-off-by: Suman Anna <[email protected]>
Signed-off-by: Roger Quadros <[email protected]>
Co-developed-by: Grzegorz Jaszczyk <[email protected]>
Signed-off-by: Grzegorz Jaszczyk <[email protected]>
Signed-off-by: Puranjay Mohan <[email protected]>
---
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 9fed3e0372d3..d06b763e995e 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -119,6 +119,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
@@ -136,6 +137,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;
@@ -152,6 +154,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;
@@ -273,6 +292,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);
@@ -944,6 +1002,7 @@ static int pru_rproc_probe(struct platform_device *pdev)
pru->rproc = rproc;
pru->fw_name = fw_name;
pru->client_np = NULL;
+ 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 fdc719b43db0..d830e20056c7 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 -EOPNOTSUPP;
+}
+
#endif /* CONFIG_PRU_REMOTEPROC */
static inline bool is_pru_rproc(struct device *dev)
--
2.17.1
From: Tero Kristo <[email protected]>
Client device node property ti,pruss-gp-mux-sel can now be used to
configure the GPMUX config value for PRU.
Signed-off-by: Tero Kristo <[email protected]>
[[email protected]: simplify the pru id usage]
Signed-off-by: Suman Anna <[email protected]>
Signed-off-by: Puranjay Mohan <[email protected]>
---
drivers/remoteproc/pru_rproc.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
index 2977eb50631b..b532069fe259 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -123,6 +123,7 @@ struct pru_private_data {
* @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
+ * @gpmux_save: saved value for gpmux config
*/
struct pru_rproc {
int id;
@@ -141,6 +142,7 @@ struct pru_rproc {
u32 dbg_single_step;
u32 dbg_continuous;
u8 evt_count;
+ u8 gpmux_save;
};
static inline u32 pru_control_read_reg(struct pru_rproc *pru, unsigned int reg)
@@ -250,6 +252,7 @@ struct rproc *pru_rproc_get(struct device_node *np, int index,
struct device *dev;
const char *fw_name;
int ret;
+ u32 mux;
try_module_get(THIS_MODULE);
@@ -273,6 +276,22 @@ struct rproc *pru_rproc_get(struct device_node *np, int index,
mutex_unlock(&pru->lock);
+ ret = pruss_cfg_get_gpmux(pru->pruss, pru->id, &pru->gpmux_save);
+ if (ret) {
+ dev_err(dev, "failed to get cfg gpmux: %d\n", ret);
+ goto err;
+ }
+
+ ret = of_property_read_u32_index(np, "ti,pruss-gp-mux-sel", index,
+ &mux);
+ if (!ret) {
+ ret = pruss_cfg_set_gpmux(pru->pruss, pru->id, mux);
+ if (ret) {
+ dev_err(dev, "failed to set cfg gpmux: %d\n", ret);
+ goto err;
+ }
+ }
+
if (pru_id)
*pru_id = pru->id;
@@ -310,6 +329,7 @@ void pru_rproc_put(struct rproc *rproc)
pru = rproc->priv;
+ pruss_cfg_set_gpmux(pru->pruss, pru->id, pru->gpmux_save);
pru_rproc_set_firmware(rproc, NULL);
mutex_lock(&pru->lock);
--
2.17.1
From: Tero Kristo <[email protected]>
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 <[email protected]>
Signed-off-by: Suman Anna <[email protected]>
Signed-off-by: Tero Kristo <[email protected]>
Co-developed-by: Grzegorz Jaszczyk <[email protected]>
Signed-off-by: Grzegorz Jaszczyk <[email protected]>
Signed-off-by: Puranjay Mohan <[email protected]>
---
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 d06b763e995e..2977eb50631b 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -171,6 +171,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;
@@ -231,6 +248,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;
try_module_get(THIS_MODULE);
@@ -257,7 +276,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);
@@ -277,6 +310,8 @@ void pru_rproc_put(struct rproc *rproc)
pru = rproc->priv;
+ pru_rproc_set_firmware(rproc, NULL);
+
mutex_lock(&pru->lock);
if (!pru->client_np) {
--
2.17.1
On Fri, 03 Jun 2022 17:45:15 +0530, Puranjay Mohan wrote:
> From: Suman Anna <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Tero Kristo <[email protected]>
> Signed-off-by: Suman Anna <[email protected]>
> Co-developed-by: Grzegorz Jaszczyk <[email protected]>
> Signed-off-by: Grzegorz Jaszczyk <[email protected]>
> Signed-off-by: Puranjay Mohan <[email protected]>
> ---
> V3->V4:
> * Addressed Rob's comments regarding max and min Items.
> * removed the dependencies tag as it was redundant.
> ---
> .../bindings/remoteproc/ti,pru-consumer.yaml | 69 +++++++++++++++++++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
>
Reviewed-by: Rob Herring <[email protected]>
I have started to review this set, comments will come over the next few days. I
will clearly inform you when I am done reviewing.
Thanks,
Mathieu
On Fri, Jun 03, 2022 at 05:45:14PM +0530, Puranjay Mohan wrote:
> This is the v4 of the patch series [1]. The v3 had some comments
> on the DT patch that have been addressed here. The 6th patch in this
> series was missed in the previous versions, so, it has been added now.
>
> I have posted two more patch series that depend on this series, one to
> the soc tree and another to the networking tree. I had sent all the 3
> series, including this one as RFC [2] to get comments and to explain the
> dependencies.
>
> 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.
>
> [1] https://patchwork.kernel.org/project/linux-remoteproc/cover/[email protected]/
> [2] https://patchwork.kernel.org/project/linux-remoteproc/cover/[email protected]/
>
> Thanks and Regards,
> Puranjay Mohan
>
> Roger Quadros (1):
> remoteproc: pru: Add pru_rproc_set_ctable() function
>
> Suman Anna (2):
> dt-bindings: remoteproc: Add PRU consumer bindings
> remoteproc: pru: Make sysfs entries read-only for PRU client driven
> boots
>
> Tero Kristo (3):
> remoteproc: pru: Add APIs to get and put the PRU cores
> remoteproc: pru: Configure firmware based on client setup
> remoteproc: pru: add support for configuring GPMUX based on client
> setup
>
> .../bindings/remoteproc/ti,pru-consumer.yaml | 69 +++++
> drivers/remoteproc/pru_rproc.c | 254 +++++++++++++++++-
> include/linux/pruss.h | 78 ++++++
> 3 files changed, 396 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> create mode 100644 include/linux/pruss.h
>
> --
> 2.17.1
>
On Mon, Jun 06, 2022 at 09:56:12AM -0600, Mathieu Poirier wrote:
> I have started to review this set, comments will come over the next few days. I
> will clearly inform you when I am done reviewing.
This patch is giving me several checkpatch warnings that should have been caught
before sending the patches out to the mailing list. As such I will not review
this work and seriously considering adding your next revision at the very bottom
of my queue.
>
> Thanks,
> Mathieu
>
> On Fri, Jun 03, 2022 at 05:45:14PM +0530, Puranjay Mohan wrote:
> > This is the v4 of the patch series [1]. The v3 had some comments
> > on the DT patch that have been addressed here. The 6th patch in this
> > series was missed in the previous versions, so, it has been added now.
> >
> > I have posted two more patch series that depend on this series, one to
> > the soc tree and another to the networking tree. I had sent all the 3
> > series, including this one as RFC [2] to get comments and to explain the
> > dependencies.
> >
> > 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.
> >
> > [1] https://patchwork.kernel.org/project/linux-remoteproc/cover/[email protected]/
> > [2] https://patchwork.kernel.org/project/linux-remoteproc/cover/[email protected]/
> >
> > Thanks and Regards,
> > Puranjay Mohan
> >
> > Roger Quadros (1):
> > remoteproc: pru: Add pru_rproc_set_ctable() function
> >
> > Suman Anna (2):
> > dt-bindings: remoteproc: Add PRU consumer bindings
> > remoteproc: pru: Make sysfs entries read-only for PRU client driven
> > boots
> >
> > Tero Kristo (3):
> > remoteproc: pru: Add APIs to get and put the PRU cores
> > remoteproc: pru: Configure firmware based on client setup
> > remoteproc: pru: add support for configuring GPMUX based on client
> > setup
> >
> > .../bindings/remoteproc/ti,pru-consumer.yaml | 69 +++++
> > drivers/remoteproc/pru_rproc.c | 254 +++++++++++++++++-
> > include/linux/pruss.h | 78 ++++++
> > 3 files changed, 396 insertions(+), 5 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> > create mode 100644 include/linux/pruss.h
> >
> > --
> > 2.17.1
> >
Hi Mathieu,
On 06/06/22 21:45, Mathieu Poirier wrote:
> On Mon, Jun 06, 2022 at 09:56:12AM -0600, Mathieu Poirier wrote:
>> I have started to review this set, comments will come over the next few days. I
>> will clearly inform you when I am done reviewing.
>
> This patch is giving me several checkpatch warnings that should have been caught
> before sending the patches out to the mailing list. As such I will not review
> this work and seriously considering adding your next revision at the very bottom
> of my queue.
I am sorry for this. I had introduced the 6th patch in v4 and it is
giving these errors. I have fixed them and sent a v5. Please don't move
the v5 to the bottom of the queue. I will be extra cautious from next time.
Thanks,
Puranjay Mohan
>
>>
>> Thanks,
>> Mathieu
>>
>> On Fri, Jun 03, 2022 at 05:45:14PM +0530, Puranjay Mohan wrote:
>>> This is the v4 of the patch series [1]. The v3 had some comments
>>> on the DT patch that have been addressed here. The 6th patch in this
>>> series was missed in the previous versions, so, it has been added now.
>>>
>>> I have posted two more patch series that depend on this series, one to
>>> the soc tree and another to the networking tree. I had sent all the 3
>>> series, including this one as RFC [2] to get comments and to explain the
>>> dependencies.
>>>
>>> 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.
>>>
>>> [1] https://patchwork.kernel.org/project/linux-remoteproc/cover/[email protected]/
>>> [2] https://patchwork.kernel.org/project/linux-remoteproc/cover/[email protected]/
>>>
>>> Thanks and Regards,
>>> Puranjay Mohan
>>>
>>> Roger Quadros (1):
>>> remoteproc: pru: Add pru_rproc_set_ctable() function
>>>
>>> Suman Anna (2):
>>> dt-bindings: remoteproc: Add PRU consumer bindings
>>> remoteproc: pru: Make sysfs entries read-only for PRU client driven
>>> boots
>>>
>>> Tero Kristo (3):
>>> remoteproc: pru: Add APIs to get and put the PRU cores
>>> remoteproc: pru: Configure firmware based on client setup
>>> remoteproc: pru: add support for configuring GPMUX based on client
>>> setup
>>>
>>> .../bindings/remoteproc/ti,pru-consumer.yaml | 69 +++++
>>> drivers/remoteproc/pru_rproc.c | 254 +++++++++++++++++-
>>> include/linux/pruss.h | 78 ++++++
>>> 3 files changed, 396 insertions(+), 5 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
>>> create mode 100644 include/linux/pruss.h
>>>
>>> --
>>> 2.17.1
>>>