On 5/13/25 10:52 AM, Bjorn Andersson wrote:
Clearing the table_sz on cleanup seemed reasonable, but further
discussions concluded that this merely working around the issue
and that the fix is incomplete.
As such, revert commit efdde3d73ab2 ("remoteproc: core: Clear table_sz
when rproc_shutdown")
ally got around to looking through the last 12 patches, all seem
rather straight forward code factoring. I've already reviewed the
previous ones before this, so for the whole series,
Reviewed-by: Andrew Davis
NOTE:
This series supersedes below series:
https://lore.kernel.org/all/20250219091042
On 4/22/25 12:53 AM, Beleswar Prasad Padhi wrote:
Hi Andrew,
On 21/04/25 20:12, Andrew Davis wrote:
On 4/17/25 1:19 PM, Beleswar Padhi wrote:
The rproc_reset() implementations in TI K3 DSP and M4 remoteproc drivers
assert reset in the same way. Refactor the above function into the
this patch is just a refactor and since
it was already in every driver you are factoring this out from I'd suggest
fixing it in a later patch.
For this patch,
Acked-by: Andrew Davis
+void k3_rproc_kick(struct rproc *rproc, int vqid)
+{
+ struct k3_rproc *kproc = rproc->priv;
+ str
On 4/17/25 1:19 PM, Beleswar Padhi wrote:
The rproc_reset() implementations in TI K3 DSP and M4 remoteproc drivers
assert reset in the same way. Refactor the above function into the
ti_k3_common.c driver as k3_rproc_reset() and use it throughout DSP and
M4 drivers for resetting the remote process
On 3/17/25 7:06 AM, Beleswar Padhi wrote:
The existing implementation of the waiting mechanism in
"k3_r5_cluster_rproc_init()" waits for the "released_from_reset" flag to
be set as part of the firmware boot process in "k3_r5_rproc_start()".
The "k3_r5_cluster_rproc_init()" function is invoked in
On 3/17/25 7:06 AM, Beleswar Padhi wrote:
The ti_k3_m4_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_rproc_mem_data
structure to store memory information. This aligns with DSP and R5
drivers, and can be refactored out later.
Signed-o
On 3/17/25 7:06 AM, Beleswar Padhi wrote:
Introduce a void pointer in the k3_{m4/dsp}_rproc internal data
structure which can be used to point to any private data needed by the
driver. Currently, the M4/DSP drivers do not have any private data, so
the pointer can be left pointing to NULL. Additio
.
Signed-off-by: Beleswar Padhi
---
Reviewed-by: Andrew Davis
drivers/remoteproc/ti_k3_r5_remoteproc.c | 65
1 file changed, 56 insertions(+), 9 deletions(-)
diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index
On 3/17/25 7:05 AM, Beleswar Padhi wrote:
Currently, struct members such as mem, num_mems, reset, tsp, ti_sci and
ti_sci_id are part of the k3_r5_core structure. To align the rproc->priv
data structure of the R5 remote processor with that of the DSP and M4,
move the above members from k3_r5_core
On 3/17/25 7:05 AM, Beleswar Padhi wrote:
The core's internal memory data structure will be refactored to be part
of the k3_r5_rproc structure in a future commit. As a result, internal
memory initialization will need to be performed inside
k3_r5_cluster_rproc_init() after rproc_alloc().
Therefor
On 3/17/25 7:06 AM, Beleswar Padhi wrote:
From: Siddharth Vadapalli
Commit f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during
probe routine") introduced a check in the "k3_r5_rproc_mbox_callback()"
and "k3_r5_rproc_kick()" callbacks, causing them to exit if the remote
core's state
On 2/26/25 9:30 AM, Beleswar Prasad Padhi wrote:
Hi Andrew,
On 26/02/25 20:14, Andrew Davis wrote:
On 2/19/25 3:10 AM, Beleswar Padhi wrote:
Currently, struct members such as mem, num_mems, reset, tsp, ti_sci and
ti_sci_id are part of the k3_r5_core structure. To align the rproc->priv
d
On 2/19/25 3:10 AM, Beleswar Padhi wrote:
Currently, struct members such as mem, num_mems, reset, tsp, ti_sci and
ti_sci_id are part of the k3_r5_core structure. To align the rproc->priv
data structure of the R5 remote processor with that of the DSP and M4,
move the above members from k3_r5_core
On 12/24/24 3:14 AM, Beleswar Padhi wrote:
Commit f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during
probe routine") introduced a check in the "k3_r5_rproc_mbox_callback()"
and "k3_r5_rproc_kick()" callbacks to exit if the remote core's state
was "RPROC_DETACHED". However, this cause
On 1/3/25 4:12 AM, Beleswar Padhi wrote:
This series refactors a lot of functions & callbacks from ti_k3_dsp_remoteproc.c
and ti_k3_m4_remoteproc.c drivers. This is the third and final series as part of
the refactoring of K3 remoteproc drivers. The patches for internal refactoring
and bug fixes o
series generates no new warnings/errors.
Was that with `make W=1 C=1`? Sparse checks will be done during -next
testing so good to check for those too.
Otherwise patches all look good to me, for the series:
Reviewed-by: Andrew Davis
v2: Changelog:
1. Re-ordered patches in the series to use devm
On 12/4/24 5:11 AM, Beleswar Padhi wrote:
Use a device lifecycle managed ioremap helper function. This helps
prevent mistakes like unmapping out of order in cleanup functions and
forgetting to unmap on all error paths.
Signed-off-by: Beleswar Padhi
---
drivers/remoteproc/ti_k3_r5_remoteproc.c
On 12/4/24 5:11 AM, Beleswar Padhi wrote:
Use a device lifecycle managed action to release tsp ti_sci_proc handle.
This helps prevent mistakes like releasing out of order in cleanup
functions and forgetting to release on error paths.
Signed-off-by: Beleswar Padhi
---
drivers/remoteproc/ti_k3_
On 10/15/24 1:00 PM, Richard Weinberger wrote:
Am Dienstag, 15. Oktober 2024, 19:56:08 CEST schrieb Mathieu Poirier:
In my opinion the real fix here is to get TI to use the standard message
announcement structure. The ->desc field doesn't seem to be that useful since
it gets discarted.
This i
On 8/11/24 4:59 PM, Mathieu Poirier wrote:
Hi Andrew,
On Mon, Jul 29, 2024 at 11:45:27AM -0500, Andrew Davis wrote:
Module aliases are used by userspace to identify the correct module to
load for a detected hardware. The currently supported RPMSG device IDs for
this module include "rpms
Use device life-cycle managed runtime enable function to simplify probe
and exit paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/wkup_m3_rproc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/wkup_m3_rproc.c
b/drivers/remoteproc
Use the device lifecycle managed add function. This helps prevent mistakes
like deleting out of order in cleanup functions and forgetting to delete
on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/wkup_m3_rproc.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/wkup_m3_rproc.c | 28
1 file changed, 8
This helps prevent mistakes like putting out of order in cleanup functions
and forgetting to put sync on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/wkup_m3_rproc.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers
Use device life-cycle managed GPIO get function to simplify probe
and exit paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/remoteproc/keystone_remoteproc.c
b/drivers
This helps prevent mistakes like freeing out of order in cleanup functions
and forgetting to free on error paths.
Signed-off-by: Andrew Davis
---
Changes for v2:
- Keep `goto disable_clk` for this patch to prevent git-bisect issues
drivers/remoteproc/keystone_remoteproc.c | 17
This helps prevent mistakes like putting out of order in cleanup functions
and forgetting to put sync on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 36
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers
Use the device lifecycle managed add function. This helps prevent mistakes
like deleting out of order in cleanup functions and forgetting to delete
on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 12 +---
1 file changed, 1 insertion(+), 11
Use device life-cycle managed runtime enable function to simplify probe
and exit paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/remoteproc/keystone_remoteproc.c
b/drivers
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/da8xx_remoteproc.c | 15 ++-
1 file changed, 6 insertions(+), 9
Use the device lifecycle managed add function. This helps prevent mistakes
like deleting out of order in cleanup functions and forgetting to delete
on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/da8xx_remoteproc.c | 20 +---
1 file changed, 1 insertion(+), 19
This helps prevent mistakes like freeing out of order in cleanup functions
and forgetting to free on error paths.
Signed-off-by: Andrew Davis
---
Changes for v2:
- Fix unused var "dev" warning
drivers/remoteproc/da8xx_remoteproc.c | 30 +--
1 file c
While it should be safe to use normal memset() on these memories as they
are mapped as Normal Non-Cached, using the memset_io() provides stronger
guarantees on access alignment and fixes a sparse check warning. Switch
to memset_io() here.
Signed-off-by: Andrew Davis
---
drivers/remoteproc
These memory regions are mapped as Normal Non-Cached which on
does not have the normal IO address space limitations and so this
cast is safe. Add '__force' to explicitly specify that the cast is
intentional to remove a sparse check warning.
Signed-off-by: Andrew Davis
---
drivers/
These memory regions are mapped as Normal Non-Cached which on
does not have the normal IO address space limitations and so this
cast is safe. Add '__force' to explicitly specify that the cast is
intentional to remove a sparse check warning.
Signed-off-by: Andrew Davis
---
drivers/
On 10/16/24 11:41 AM, Andrew Davis wrote:
This driver can be compile tested on non-K3 architectures as long
as TI_SCI_PROTOCOL is not compiled as a module. Enable this here
to improve this driver's build coverage.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 3 ++-
1
On 10/16/24 11:02 AM, Mathieu Poirier wrote:
On Wed, Oct 16, 2024 at 10:37:35AM -0500, Andrew Davis wrote:
On 10/16/24 10:26 AM, Mathieu Poirier wrote:
On Mon, Oct 14, 2024 at 09:56:11AM -0500, Andrew Davis wrote:
On 10/7/24 8:23 AM, Arnd Bergmann wrote:
From: Arnd Bergmann
The k3-m4
Hello all,
This is a follow up to [0] that adds the same for the other two K3
RemoteProc drivers. Series is based on rproc-next branch.
Thanks,
Andrew
[0] https://lore.kernel.org/lkml/20241007132441.2732215-1-a...@kernel.org/
Andrew Davis (2):
remoteproc: k3-dsp: Add compile testing support
This driver can be compile tested on non-K3 architectures as long
as TI_SCI_PROTOCOL is not compiled as a module. Enable this here
to improve this driver's build coverage.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
This driver can be compile tested on non-K3 architectures as long
as TI_SCI_PROTOCOL is not compiled as a module. Enable this here
to improve this driver's build coverage.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
On 10/16/24 10:26 AM, Mathieu Poirier wrote:
On Mon, Oct 14, 2024 at 09:56:11AM -0500, Andrew Davis wrote:
On 10/7/24 8:23 AM, Arnd Bergmann wrote:
From: Arnd Bergmann
The k3-m4 remoteproc driver was merged with incorrect dependencies.
Despite multiple people trying to fix this, the version
On 10/14/24 11:52 AM, Nishanth Menon wrote:
On 15:43-20241014, Arnd Bergmann wrote:
On Mon, Oct 14, 2024, at 14:56, Andrew Davis wrote:
On 10/7/24 8:23 AM, Arnd Bergmann wrote:
config TI_K3_M4_REMOTEPROC
tristate "TI K3 M4 remoteproc support"
- depends on ARCH
On 10/7/24 8:23 AM, Arnd Bergmann wrote:
From: Arnd Bergmann
The k3-m4 remoteproc driver was merged with incorrect dependencies.
Despite multiple people trying to fix this, the version 6.12-rc2
remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m
when the driver is built-in.
On 9/24/24 7:43 AM, Markus Elfring wrote:
From: Markus Elfring
Date: Tue, 24 Sep 2024 14:28:35 +0200
An of_node_put(rmem_np) call was immediately used after a pointer check
for a of_reserved_mem_lookup() call in three function implementations.
Thus call such a function only once instead directl
le = omap_mailbox_of_match,
We could have done this in its own series. Someday we need to
check everywhere for of_match being unconditionally defined but
still using of_match_ptr(). Coccinelle might help here..
Anyway, LGTM
Reviewed-by: Andrew Davis
},
};
module_platform_driver
new devm_add_action_or_reset() and
simplify the .remove() function.
Your patch subject is messed up, otherwise LGTM.
Reviewed-by: Andrew Davis
Fixes: ea1d6fb5b571 ("remoteproc: k3-dsp: Acquire mailbox handle during probe
routine")
Signed-off-by: Christophe JAILLET
---
Compile t
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
On 8/8/24 2:41 AM, Beleswar Padhi wrote:
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting
to free on error paths.
Signed-off-by: Beleswar Padhi
---
LGTM
Reviewed-by: Andrew Davis
drivers
ng the mailbox after probe has
been the case since the first version of this driver.
Rest of the patch LGTM,
Acked-by: Andrew Davis
BTW, I've folded this change (getting mbox in probe) into the new
K3 M4 driver[0] I just posted, so we should be aligned here accross
all K3 rpr
On 8/7/24 1:22 AM, Beleswar Padhi wrote:
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting
to free on error paths.
Signed-off-by: Beleswar Padhi
---
drivers/remoteproc/ti_k3_r5_remoteproc.c | 6 ++---
Use device life-cycle managed runtime enable function to simplify probe
and exit paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/remoteproc/keystone_remoteproc.c
b/drivers
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 15 +--
1 file changed, 5 insertions
This helps prevent mistakes like freeing out of order in cleanup functions
and forgetting to free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc
Use device life-cycle managed GPIO get function to simplify probe
and exit paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/remoteproc/keystone_remoteproc.c
b/drivers
Use the device lifecycle managed add function. This helps prevent mistakes
like deleting out of order in cleanup functions and forgetting to delete
on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 12 +---
1 file changed, 1 insertion(+), 11
This is simpler and removes the need to assume the id length to be 1
digit, which then removes a W=1 compile warning about the same.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers
This helps prevent mistakes like putting out of order in cleanup functions
and forgetting to put sync on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 34
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers
the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am642-evm.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index
From: Hari Nagalla
Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build
the M4 remote proc driver as a module for these platforms.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch
this node is not complete until mailbox data
is provided in the board level DT.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
b/arch
the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
.../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
b/arch/arm64/boot/dts/ti/k3-am62x-sk
-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
g
and starting the M4F subsystems.
The YAML binding document provides the various node properties to be
configured by the consumers of the M4F subsystem.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
Reviewed-by: Conor Dooley
---
.../bindings/remoteproc/ti,k
ml text in [1/5]
- Split dts patch into one for SoC and one for board enable
- Corrected DT property order and formatting [4/5][5/5]
Andrew Davis (1):
remoteproc: k3: Factor out TI-SCI processor control OF get function
Hari Nagalla (7):
dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am642-sk.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index
Building the TSP structure is common for users of the TI-SCI processor
control interface. Factor out this function and put it with the rest
of the TI-SCI processor control functions.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/ti_k3_dsp_remoteproc.c | 28 +--
drivers
this node is not complete until mailbox data
is provided in the board level DT.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
b/arch
ID. This was the ID used for
this driver before it was upstreamed (as reflected by the module alias).
Signed-off-by: Andrew Davis
---
drivers/rpmsg/rpmsg_char.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
index e
On 6/26/24 2:14 PM, Garrett Giordano wrote:
Driver was logging information as errors. Changed dev_err to dev_dbg
where appropriate.
Signed-off-by: Garrett Giordano
---
Acked-by: Andrew Davis
-v2
- Change from dev_info to dev_dbg
- Drop k3-r5 PATCH
---
drivers/remoteproc
On 6/21/24 10:00 AM, Richard Genoud wrote:
Introduce software IPC handshake between the K3-R5 remote proc driver
and the R5 MCU to gracefully stop/reset the remote core.
Upon a stop request, K3-R5 remote proc driver sends a RP_MBOX_SHUTDOWN
mailbox message to the remote R5 core.
The remote core
On 6/26/24 9:39 AM, Dominic Rath wrote:
On 13.06.2024 14:22, Andrew Davis wrote:
We looked into this some time ago, and noticed that the IRQ approach caused
problems in the virtio/rpmsg code. I'd like to understand if your change was
for the same reason, or something else we missed b
On 6/21/24 6:14 AM, Beleswar Prasad Padhi wrote:
Hi Andrew,
On 04/06/24 22:40, Andrew Davis wrote:
On 6/4/24 12:17 AM, Beleswar Padhi wrote:
Acquire the mailbox handle during device probe and do not release handle
in stop/detach routine or error paths. This removes the redundant
requests for
On 6/18/24 12:05 PM, Mathieu Poirier wrote:
Good morning,
On Mon, Jun 10, 2024 at 01:06:09PM -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
On 6/13/24 2:58 AM, Dominic Rath wrote:
Hello Andrew,
On 10.04.2024 15:59, Andrew Davis wrote:
Changes for v2:
- Use threaded irq as suggested by Hari and to
fix possible "scheduling while atomic" issue
sorry for beeing late, I noticed this already got merged.
I was wond
-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 760 +++
3 files changed, 774 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff
the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am642-sk.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index
From: Hari Nagalla
Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build
the M4 remote proc driver as a module for these platforms.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch
the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am642-evm.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index
this node is not complete until mailbox data
is provided in the board level DT.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
b/arch
the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
.../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
b/arch/arm64/boot/dts/ti/k3-am62x-sk
Hello all,
This is the continuation of the M4F RProc support series from here[0].
I'm helping out with the upstream task for Hari and so versions (v8+)
is a little different than the previous(v7-) postings[0]. Most notable
change I've introduced being the patches factoring out common support
from
g
and starting the M4F subsystems.
The YAML binding document provides the various node properties to be
configured by the consumers of the M4F subsystem.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
Reviewed-by: Conor Dooley
---
.../bindings/remoteproc/ti,k
this node is not complete until mailbox data
is provided in the board level DT.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
b/arch
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/omap_remoteproc.c | 20
1 file changed, 8 insertions
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/da8xx_remoteproc.c | 15 ++-
1 file changed, 6 insertions(+), 9
This helps prevent mistakes like freeing out of order in cleanup functions
and forgetting to free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/omap_remoteproc.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/remoteproc
This helps prevent mistakes like freeing out of order in cleanup functions
and forgetting to free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/da8xx_remoteproc.c | 29 +--
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers
Use the device lifecycle managed add function. This helps prevent mistakes
like deleting out of order in cleanup functions and forgetting to delete
on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/da8xx_remoteproc.c | 21 +
1 file changed, 1 insertion
Use the device lifecycle managed add function. This helps prevent mistakes
like deleting out of order in cleanup functions and forgetting to delete
on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/omap_remoteproc.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions
On 6/4/24 12:17 AM, Beleswar Padhi wrote:
Acquire the mailbox handle during device probe and do not release handle
in stop/detach routine or error paths. This removes the redundant
requests for mbox handle later during rproc start/attach. This also
allows to defer remoteproc driver's probe if mai
On 5/30/24 4:07 AM, Beleswar Padhi wrote:
Acquire the mailbox handle during device probe and do not release handle
in stop/detach routine or error paths. This removes the redundant
requests for mbox handle later during rproc start/attach. This also
allows to defer remoteproc driver's probe if mai
On 5/9/24 10:32 AM, Mathieu Poirier wrote:
On Wed, 8 May 2024 at 10:54, Andrew Davis wrote:
On 5/7/24 3:36 PM, Mathieu Poirier wrote:
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the
On 5/9/24 10:22 AM, Mathieu Poirier wrote:
On Wed, 8 May 2024 at 09:36, Andrew Davis wrote:
On 5/6/24 3:46 PM, Mathieu Poirier wrote:
Good day,
I have started reviewing this patchset. Comments will be scattered over
multiple days and as such, I will explicitly inform you when am done with
On 5/7/24 3:36 PM, Mathieu Poirier wrote:
On Fri, Apr 26, 2024 at 02:18:08PM -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
On 5/6/24 3:46 PM, Mathieu Poirier wrote:
Good day,
I have started reviewing this patchset. Comments will be scattered over
multiple days and as such, I will explicitly inform you when am done with the
review.
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
From: Martyn Welch
-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
3 files changed, 799 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff
Hello all,
This is the continuation of the M4F RProc support series from here[0].
I'm helping out with the upstream task for Hari and so this version(v8)
is a little different than the previous(v7) postings[0]. Most notable
change I've introduced being the patches factoring out common support
from
this node is not complete until mailbox data
is provided in the board level DT.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
b/arch
From: Hari Nagalla
Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build
the M4 remote proc driver as a module for these platforms.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch
1 - 100 of 177 matches
Mail list logo
