Hello,
On 26/04/24 22:39, Mathieu Poirier wrote:
Good day, On Wed, Apr 24, 2024 at 06: 35: 03PM +0530, Beleswar Padhi wrote: >
From: Apurva Nandan > > PSC controller has a limitation that
it can only power-up the second core > when the first core is in ON
ZjQcmQRYFpfptBannerStart
This message w
Hi Andrew,
On 30/05/24 19:46, Andrew Davis wrote:
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 a
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 mbox handle later during rproc start/attach. This a
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 mbox handle later during rproc start/attach. This a
Hi Andrew,
On 07/08/24 19:07, Andrew Davis wrote:
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
---
On 07/08/24 19:21, Andrew Davis wrote:
On 8/7/24 1:22 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
Hi Mathieu,
On 14-08-2024 21:22, Mathieu Poirier wrote:
Hi Beleswar, On Thu, Aug 08, 2024 at 01: 11: 26PM +0530, 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
Hi Jan,
On 19-08-2024 22:17, Jan Kiszka wrote:
From: Jan Kiszka
When k3_r5_cluster_rproc_exit is run, core 1 is shutdown and removed
first. When core 0 should then be stopped before its removal, it will
find core1->rproc as NULL already and crashes. Happens on rmmod e.g.
Did you check this
On 20-08-2024 15:09, Jan Kiszka wrote:
On 20.08.24 11:30, Beleswar Prasad Padhi wrote:
Hi Jan,
On 19-08-2024 22:17, Jan Kiszka wrote:
From: Jan Kiszka
When k3_r5_cluster_rproc_exit is run, core 1 is shutdown and removed
first. When core 0 should then be stopped before its removal, it will
On 20-08-2024 19:50, Jan Kiszka wrote:
On 20.08.24 11:48, Beleswar Prasad Padhi wrote:
On 20-08-2024 15:09, Jan Kiszka wrote:
On 20.08.24 11:30, Beleswar Prasad Padhi wrote:
Hi Jan,
On 19-08-2024 22:17, Jan Kiszka wrote:
From: Jan Kiszka
When k3_r5_cluster_rproc_exit is run, core 1 is
On 20-08-2024 20:29, Beleswar Prasad Padhi wrote:
On 20-08-2024 19:50, Jan Kiszka wrote:
On 20.08.24 11:48, Beleswar Prasad Padhi wrote:
On 20-08-2024 15:09, Jan Kiszka wrote:
On 20.08.24 11:30, Beleswar Prasad Padhi wrote:
Hi Jan,
On 19-08-2024 22:17, Jan Kiszka wrote:
From: Jan Kiszka
On 19-08-2024 20:54, Jan Kiszka wrote:
From: Jan Kiszka
By simply bailing out, the driver was violating its rule and internal
Using device lifecycle managed functions to register the rproc
(devm_rproc_add()), bailing out with an error code will work.
assumptions that either both or no
On 21-08-2024 23:40, Jan Kiszka wrote:
On 21.08.24 07:30, Beleswar Prasad Padhi wrote:
On 19-08-2024 20:54, Jan Kiszka wrote:
From: Jan Kiszka
By simply bailing out, the driver was violating its rule and internal
Using device lifecycle managed functions to register the rproc
On 22-08-2024 10:57, Jan Kiszka wrote:
On 22.08.24 07:22, Beleswar Prasad Padhi wrote:
On 21-08-2024 23:40, Jan Kiszka wrote:
On 21.08.24 07:30, Beleswar Prasad Padhi wrote:
On 19-08-2024 20:54, Jan Kiszka wrote:
From: Jan Kiszka
By simply bailing out, the driver was violating its rule
Hi All,
On 22/08/24 21:47, Mathieu Poirier wrote:
Hi Baolu,
Sorry for the late reply, this slipped through the cracks.
On Mon, Aug 12, 2024 at 03:28:11PM +0800, Lu Baolu wrote:
> An iommu domain is allocated in rproc_enable_iommu() and is attached to
> rproc->dev.parent in the same function.
>
Hi Mathieu,
On 20-08-2024 16:20, Beleswar Padhi wrote:
From: Udit Kumar
Few times, core1 was scheduled to boot first before core0, which leads
to error:
'k3_r5_rproc_start: can not start core 1 before core 0'.
This was happening due to some scheduling between prepare and start
callback. The
On 03-09-2024 20:02, Mathieu Poirier wrote:
On Tue, 3 Sept 2024 at 04:15, Beleswar Prasad Padhi wrote:
Hi Mathieu,
On 20-08-2024 16:20, Beleswar Padhi wrote:
From: Udit Kumar
Few times, core1 was scheduled to boot first before core0, which leads
to error:
'k3_r5_rproc_start: ca
Hi Mathieu,
On 06-09-2024 22:17, Mathieu Poirier wrote:
On Fri, Sep 06, 2024 at 03:10:45PM +0530, Beleswar Padhi wrote:
The current implementation of the waiting mechanism in probe() waits for
the 'released_from_reset' flag to be set which is done in
k3_r5_rproc_prepare() as part of rproc_fw_bo
On 07/09/24 15:41, Kumar, Udit wrote:
On 9/6/2024 3:10 PM, Beleswar Padhi wrote:
The current implementation of the waiting mechanism in probe() waits for
the 'released_from_reset' flag to be set which is done in
k3_r5_rproc_prepare() as part of rproc_fw_boot(). This causes unexpected
failures
Hi Mathieu,
On 17/09/24 14:07, Mathieu Poirier wrote:
On Mon, 16 Sept 2024 at 23:20, Kumar, Udit wrote:
On 9/16/2024 8:50 PM, Mathieu Poirier wrote:
On Mon, 16 Sept 2024 at 02:31, Siddharth Vadapalli wrote:
Commit f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during
probe routine
On 29-08-2024 11:47, Beleswar Prasad Padhi wrote:
Hi All,
On 22/08/24 21:47, Mathieu Poirier wrote:
Hi Baolu,
Sorry for the late reply, this slipped through the cracks.
On Mon, Aug 12, 2024 at 03:28:11PM +0800, Lu Baolu wrote:
> An iommu domain is allocated in rproc_enable_iommu() and
On 03/01/25 15:42, Beleswar Padhi wrote:
Inter-Processor Communication is facilitated through mailbox payloads,
which typically contains the index of the triggered virtqueue having the
actual data to be consumed, but the payload can also be used for trivial
communication, like sending an echo m
On 17/12/24 21:33, Andrew Davis wrote:
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
---
Hi Andrew,
On 17/12/24 21:30, Andrew Davis wrote:
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
On 12/19/2024 8:22 PM, Andrew Davis wrote:
On 12/19/24 5:05 AM, Beleswar Padhi wrote:
This series uses various devm_ helpers to simplify device removal
path in
ti_k3_r5_remoteproc driver. This is the first series in the TI K3
Remoteproc refactoring as long planned since [0].
Testing Done:
1.
On 22/01/25 00:17, Andrew Davis wrote:
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
Missed few changelog. Adding below.
On 03/01/25 15:42, 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
On 03/01/25 16:18, Kumar, Udit wrote:
On 12/24/2024 2:44 PM, 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 sta
Hi Andrew,
On 08/01/25 20:33, Andrew Davis wrote:
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.
Hi Hari,
On 27/12/24 20:08, Hari Nagalla wrote:
On 12/24/24 03:14, Beleswar Padhi wrote:
/**
@@ -194,8 +196,11 @@ static void k3_r5_rproc_mbox_callback(struct
mbox_client *client, void *data)
const char *name = kproc->rproc->name;
u32 msg = omap_mbox_message(data);
- /* Do
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
data structure of the R5 remote processor with that of the
31 matches
Mail list logo
