Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
On Mon, Aug 19, 2024 at 10:54:11AM -0500, Andrew Davis wrote: > On 8/19/24 10:39 AM, Krzysztof Kozlowski wrote: > > On 19/08/2024 17:32, Mathieu Poirier wrote: > > > > > > > > Please remove. > > > > > Forget this comment since it would cause an error in __rproc_detach(). > > > > > > > > > > > Other than the above I'm good with this driver. That said I can't > > > > > > move forward > > > > > > without a nod from the DT crew. I also noticed a fair amount of > > > > > > code > > > > > > duplication with the k3_r5 and k3_dsp drivers. Dealing with that > > > > > > should not be > > > > > > part of the current work but will need to be done before another k3 > > > > > > driver can > > > > > > be merged. > > > > > > > > > > > > > > > The above still apply though. > > > > > > > > Me or Nishanth will pick up the SoC DT patches via TI SoC tree, once the > > > > driver patches are merged. Feel free to ignore those but queue > > > > dt-bindings (already has DT maintainers ack) and driver patches via > > > > rproc tree. > > > > > > > > > > Can you provide a link where the DT maintainers have acknowledged the > > > bindings? > > > > The reviewed-by tag serves as acknowledgment as well and the binding > > patch has it. Conor gave it on some earlier version of the patchset. I > > did not check if there were any significant changes in the meantime, though. > > > > Was reviewed in v8: > https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240424190612.17349-2-...@ti.com/#3302840 > I didn't notice Conor had joined the DT crew and as such was expecting something from either Rob or Krzysztof. I am applying this set. Thanks, Mathieu > If there was any significant changes since I would have dropped the tag. > > Andrew > > > > > Best regards, > > Krzysztof > >
Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
On 8/19/24 10:39 AM, Krzysztof Kozlowski wrote: On 19/08/2024 17:32, Mathieu Poirier wrote: Please remove. Forget this comment since it would cause an error in __rproc_detach(). Other than the above I'm good with this driver. That said I can't move forward without a nod from the DT crew. I also noticed a fair amount of code duplication with the k3_r5 and k3_dsp drivers. Dealing with that should not be part of the current work but will need to be done before another k3 driver can be merged. The above still apply though. Me or Nishanth will pick up the SoC DT patches via TI SoC tree, once the driver patches are merged. Feel free to ignore those but queue dt-bindings (already has DT maintainers ack) and driver patches via rproc tree. Can you provide a link where the DT maintainers have acknowledged the bindings? The reviewed-by tag serves as acknowledgment as well and the binding patch has it. Conor gave it on some earlier version of the patchset. I did not check if there were any significant changes in the meantime, though. Was reviewed in v8: https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240424190612.17349-2-...@ti.com/#3302840 If there was any significant changes since I would have dropped the tag. Andrew Best regards, Krzysztof
Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
On 19/08/2024 17:32, Mathieu Poirier wrote: Please remove. >>> Forget this comment since it would cause an error in __rproc_detach(). >>> Other than the above I'm good with this driver. That said I can't move forward without a nod from the DT crew. I also noticed a fair amount of code duplication with the k3_r5 and k3_dsp drivers. Dealing with that should not be part of the current work but will need to be done before another k3 driver can be merged. >> >>> The above still apply though. >> >> Me or Nishanth will pick up the SoC DT patches via TI SoC tree, once the >> driver patches are merged. Feel free to ignore those but queue >> dt-bindings (already has DT maintainers ack) and driver patches via >> rproc tree. >> > > Can you provide a link where the DT maintainers have acknowledged the > bindings? The reviewed-by tag serves as acknowledgment as well and the binding patch has it. Conor gave it on some earlier version of the patchset. I did not check if there were any significant changes in the meantime, though. Best regards, Krzysztof
Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
Hey Vignesh.
On Mon, Aug 19, 2024 at 02:02:31PM +0530, Vignesh Raghavendra wrote:
> [...]
>
> Hi Mathieu
>
> On 16/08/24 20:06, Mathieu Poirier wrote:
> >>> +/*
> >>> + * Attach to a running M4 remote processor (IPC-only mode)
> >>> + *
> >>> + * The remote processor is already booted, so there is no need to issue
> >>> any
> >>> + * TI-SCI commands to boot the M4 core. This callback is used only in
> >>> IPC-only
> >>> + * mode.
> >>> + */
> >>> +static int k3_m4_rproc_attach(struct rproc *rproc)
> >>> +{
> >>> + struct k3_m4_rproc *kproc = rproc->priv;
> >>> + int ret;
> >>> +
> >>> + ret = k3_m4_rproc_ping_mbox(kproc);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +/*
> >>> + * Detach from a running M4 remote processor (IPC-only mode)
> >>> + *
> >>> + * This rproc detach callback performs the opposite operation to attach
> >>> + * callback, the M4 core is not stopped and will be left to continue to
> >>> + * run its booted firmware. This callback is invoked only in IPC-only
> >>> mode.
> >>> + */
> >>> +static int k3_m4_rproc_detach(struct rproc *rproc)
> >>> +{
> >>> + return 0;
> >>> +}
> >> Please remove.
> > Forget this comment since it would cause an error in __rproc_detach().
> >
> >> Other than the above I'm good with this driver. That said I can't move
> >> forward
> >> without a nod from the DT crew. I also noticed a fair amount of code
> >> duplication with the k3_r5 and k3_dsp drivers. Dealing with that should
> >> not be
> >> part of the current work but will need to be done before another k3 driver
> >> can
> >> be merged.
> >>
>
> > The above still apply though.
>
> Me or Nishanth will pick up the SoC DT patches via TI SoC tree, once the
> driver patches are merged. Feel free to ignore those but queue
> dt-bindings (already has DT maintainers ack) and driver patches via
> rproc tree.
>
Can you provide a link where the DT maintainers have acknowledged the bindings?
>
> --
> Regards
> Vignesh
Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
Am 02.08.24 um 17:21 schrieb Andrew Davis:
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
Tested-by: Wadim Egorov
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 667 +++
3 files changed, 681 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index dda2ada215b7c..0f0862e20a932 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -340,6 +340,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+ tristate "TI K3 M4 remoteproc support"
+ depends on ARCH_K3 || COMPILE_TEST
+ select MAILBOX
+ select OMAP2PLUS_MBOX
+ help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)+= ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..09f0484a90e10
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,667 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+#define K3_M4_IRAM_DEV_ADDR 0x0
+#define K3_M4_DRAM_DEV_ADDR 0x3
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+ const char *name;
+ const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc - k3 remote processor driver structure
+ * @dev: cached device pointer
+ * @mem: internal memory regions data
+ * @num_mems: number of internal memory regions
+ * @rmem: reserved memory regions data
+ * @num_rmems: number of reserved memory regions
+ * @reset: reset control handle
+ * @tsp: TI-SCI processor control handle
+ * @ti_sci: TI-SCI handle
+ * @ti_sci_id: TI-SCI device identifier
+ * @mbox: mailbox channel handle
+ * @client: mailbox client to request
Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
[...]
Hi Mathieu
On 16/08/24 20:06, Mathieu Poirier wrote:
>>> +/*
>>> + * Attach to a running M4 remote processor (IPC-only mode)
>>> + *
>>> + * The remote processor is already booted, so there is no need to issue any
>>> + * TI-SCI commands to boot the M4 core. This callback is used only in
>>> IPC-only
>>> + * mode.
>>> + */
>>> +static int k3_m4_rproc_attach(struct rproc *rproc)
>>> +{
>>> + struct k3_m4_rproc *kproc = rproc->priv;
>>> + int ret;
>>> +
>>> + ret = k3_m4_rproc_ping_mbox(kproc);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/*
>>> + * Detach from a running M4 remote processor (IPC-only mode)
>>> + *
>>> + * This rproc detach callback performs the opposite operation to attach
>>> + * callback, the M4 core is not stopped and will be left to continue to
>>> + * run its booted firmware. This callback is invoked only in IPC-only mode.
>>> + */
>>> +static int k3_m4_rproc_detach(struct rproc *rproc)
>>> +{
>>> + return 0;
>>> +}
>> Please remove.
> Forget this comment since it would cause an error in __rproc_detach().
>
>> Other than the above I'm good with this driver. That said I can't move
>> forward
>> without a nod from the DT crew. I also noticed a fair amount of code
>> duplication with the k3_r5 and k3_dsp drivers. Dealing with that should not
>> be
>> part of the current work but will need to be done before another k3 driver
>> can
>> be merged.
>>
> The above still apply though.
Me or Nishanth will pick up the SoC DT patches via TI SoC tree, once the
driver patches are merged. Feel free to ignore those but queue
dt-bindings (already has DT maintainers ack) and driver patches via
rproc tree.
--
Regards
Vignesh
Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
On Thu, Aug 15, 2024 at 10:46:41AM -0600, Mathieu Poirier wrote:
> Hi,
>
> On Fri, Aug 02, 2024 at 10:21:03AM -0500, Andrew Davis wrote:
> > From: Martyn Welch
> >
> > The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
> > the MCU domain. This core is typically used for safety applications in a
> > stand alone mode. However, some application (non safety related) may
> > want to use the M4F core as a generic remote processor with IPC to the
> > host processor. The M4F core has internal IRAM and DRAM memories and are
> > exposed to the system bus for code and data loading.
> >
> > A remote processor driver is added to support this subsystem, including
> > being able to load and boot the M4F core. Loading includes to M4F
> > internal memories and predefined external code/data memories. The
> > carve outs for external contiguous memory is defined in the M4F device
> > node and should match with the external memory declarations in the M4F
> > image binary. The M4F subsystem has two resets. One reset is for the
> > entire subsystem i.e including the internal memories and the other, a
> > local reset is only for the M4F processing core. When loading the image,
> > the driver first releases the subsystem reset, loads the firmware image
> > and then releases the local reset to let the M4F processing core run.
> >
> > Signed-off-by: Martyn Welch
> > Signed-off-by: Hari Nagalla
> > Signed-off-by: Andrew Davis
> > ---
> > drivers/remoteproc/Kconfig | 13 +
> > drivers/remoteproc/Makefile | 1 +
> > drivers/remoteproc/ti_k3_m4_remoteproc.c | 667 +++
> > 3 files changed, 681 insertions(+)
> > create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
> >
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index dda2ada215b7c..0f0862e20a932 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -340,6 +340,19 @@ config TI_K3_DSP_REMOTEPROC
> > It's safe to say N here if you're not interested in utilizing
> > the DSP slave processors.
> >
> > +config TI_K3_M4_REMOTEPROC
> > + tristate "TI K3 M4 remoteproc support"
> > + depends on ARCH_K3 || COMPILE_TEST
> > + select MAILBOX
> > + select OMAP2PLUS_MBOX
> > + help
> > + Say m here to support TI's M4 remote processor subsystems
> > + on various TI K3 family of SoCs through the remote processor
> > + framework.
> > +
> > + It's safe to say N here if you're not interested in utilizing
> > + a remote processor.
> > +
> > config TI_K3_R5_REMOTEPROC
> > tristate "TI K3 R5 remoteproc support"
> > depends on ARCH_K3
> > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > index 91314a9b43cef..5ff4e2fee4abd 100644
> > --- a/drivers/remoteproc/Makefile
> > +++ b/drivers/remoteproc/Makefile
> > @@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) +=
> > st_remoteproc.o
> > obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
> > obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
> > obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
> > +obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
> > obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
> > obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
> > diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
> > b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> > new file mode 100644
> > index 0..09f0484a90e10
> > --- /dev/null
> > +++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> > @@ -0,0 +1,667 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * TI K3 Cortex-M4 Remote Processor(s) driver
> > + *
> > + * Copyright (C) 2021-2024 Texas Instruments Incorporated -
> > https://www.ti.com/
> > + * Hari Nagalla
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "omap_remoteproc.h"
> > +#include "remoteproc_internal.h"
> > +#include "ti_sci_proc.h"
> > +
> > +#define K3_M4_IRAM_DEV_ADDR 0x0
> > +#define K3_M4_DRAM_DEV_ADDR 0x3
> > +
> > +/**
> > + * struct k3_m4_rproc_mem - internal memory structure
> > + * @cpu_addr: MPU virtual address of the memory region
> > + * @bus_addr: Bus address used to access the memory region
> > + * @dev_addr: Device address of the memory region from remote processor
> > view
> > + * @size: Size of the memory region
> > + */
> > +struct k3_m4_rproc_mem {
> > + void __iomem *cpu_addr;
> > + phys_addr_t bus_addr;
> > + u32 dev_addr;
> > + size_t size;
> > +};
> > +
> > +/**
> > + * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
> > + * @name: name for this memory entry
> > + * @dev_addr: device address for the memory entry
> > + */
> > +struct k3_m4_rproc_mem_data {
> > + const char *name;
> > + const u32 dev_addr;
> > +};
> > +
> > +/**
> > + * struct k3_m4_rproc - k3 remo
Re: [PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
Hi,
On Fri, Aug 02, 2024 at 10:21:03AM -0500, Andrew Davis wrote:
> From: Martyn Welch
>
> The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
> the MCU domain. This core is typically used for safety applications in a
> stand alone mode. However, some application (non safety related) may
> want to use the M4F core as a generic remote processor with IPC to the
> host processor. The M4F core has internal IRAM and DRAM memories and are
> exposed to the system bus for code and data loading.
>
> A remote processor driver is added to support this subsystem, including
> being able to load and boot the M4F core. Loading includes to M4F
> internal memories and predefined external code/data memories. The
> carve outs for external contiguous memory is defined in the M4F device
> node and should match with the external memory declarations in the M4F
> image binary. The M4F subsystem has two resets. One reset is for the
> entire subsystem i.e including the internal memories and the other, a
> local reset is only for the M4F processing core. When loading the image,
> the driver first releases the subsystem reset, loads the firmware image
> and then releases the local reset to let the M4F processing core run.
>
> Signed-off-by: Martyn Welch
> Signed-off-by: Hari Nagalla
> Signed-off-by: Andrew Davis
> ---
> drivers/remoteproc/Kconfig | 13 +
> drivers/remoteproc/Makefile | 1 +
> drivers/remoteproc/ti_k3_m4_remoteproc.c | 667 +++
> 3 files changed, 681 insertions(+)
> create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index dda2ada215b7c..0f0862e20a932 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -340,6 +340,19 @@ config TI_K3_DSP_REMOTEPROC
> It's safe to say N here if you're not interested in utilizing
> the DSP slave processors.
>
> +config TI_K3_M4_REMOTEPROC
> + tristate "TI K3 M4 remoteproc support"
> + depends on ARCH_K3 || COMPILE_TEST
> + select MAILBOX
> + select OMAP2PLUS_MBOX
> + help
> + Say m here to support TI's M4 remote processor subsystems
> + on various TI K3 family of SoCs through the remote processor
> + framework.
> +
> + It's safe to say N here if you're not interested in utilizing
> + a remote processor.
> +
> config TI_K3_R5_REMOTEPROC
> tristate "TI K3 R5 remoteproc support"
> depends on ARCH_K3
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 91314a9b43cef..5ff4e2fee4abd 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
> obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
> obj-$(CONFIG_STM32_RPROC)+= stm32_rproc.o
> obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
> +obj-$(CONFIG_TI_K3_M4_REMOTEPROC)+= ti_k3_m4_remoteproc.o
> obj-$(CONFIG_TI_K3_R5_REMOTEPROC)+= ti_k3_r5_remoteproc.o
> obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
> diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
> b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> new file mode 100644
> index 0..09f0484a90e10
> --- /dev/null
> +++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> @@ -0,0 +1,667 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * TI K3 Cortex-M4 Remote Processor(s) driver
> + *
> + * Copyright (C) 2021-2024 Texas Instruments Incorporated -
> https://www.ti.com/
> + * Hari Nagalla
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "omap_remoteproc.h"
> +#include "remoteproc_internal.h"
> +#include "ti_sci_proc.h"
> +
> +#define K3_M4_IRAM_DEV_ADDR 0x0
> +#define K3_M4_DRAM_DEV_ADDR 0x3
> +
> +/**
> + * struct k3_m4_rproc_mem - internal memory structure
> + * @cpu_addr: MPU virtual address of the memory region
> + * @bus_addr: Bus address used to access the memory region
> + * @dev_addr: Device address of the memory region from remote processor view
> + * @size: Size of the memory region
> + */
> +struct k3_m4_rproc_mem {
> + void __iomem *cpu_addr;
> + phys_addr_t bus_addr;
> + u32 dev_addr;
> + size_t size;
> +};
> +
> +/**
> + * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
> + * @name: name for this memory entry
> + * @dev_addr: device address for the memory entry
> + */
> +struct k3_m4_rproc_mem_data {
> + const char *name;
> + const u32 dev_addr;
> +};
> +
> +/**
> + * struct k3_m4_rproc - k3 remote processor driver structure
> + * @dev: cached device pointer
> + * @mem: internal memory regions data
> + * @num_mems: number of internal memory regions
> + * @rmem: reserved memory regions data
> + * @num_rmems: number of reserved memory regions
> + * @reset: reset control han
[PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 667 +++
3 files changed, 681 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index dda2ada215b7c..0f0862e20a932 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -340,6 +340,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+ tristate "TI K3 M4 remoteproc support"
+ depends on ARCH_K3 || COMPILE_TEST
+ select MAILBOX
+ select OMAP2PLUS_MBOX
+ help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..09f0484a90e10
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,667 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+#define K3_M4_IRAM_DEV_ADDR 0x0
+#define K3_M4_DRAM_DEV_ADDR 0x3
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+ const char *name;
+ const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc - k3 remote processor driver structure
+ * @dev: cached device pointer
+ * @mem: internal memory regions data
+ * @num_mems: number of internal memory regions
+ * @rmem: reserved memory regions data
+ * @num_rmems: number of reserved memory regions
+ * @reset: reset control handle
+ * @tsp: TI-SCI processor control handle
+ * @ti_sci: TI-SCI handle
+ * @ti_sci_id: TI-SCI device identifier
+ * @mbox: mailbox channel handle
+ * @client: mailbox client to request the mailbox channel
+ */
+struct k3_m4_rproc {
+ struct device *dev;
+ st
