it have to be core0?
Is the code in the driver ready to handle this configuration?
The inline comments you already have to explain the possible configurations
need to be update to address this new usecase.
Thanks,
Mathieu
>
> base-commit: dc8417021bcd01914a416bf8bab811a6c5e7d99a
> --
> 2.34.1
>
On Mon, 9 Jun 2025 at 10:33, Arnaud POULIQUEN
wrote:
>
> Hello Mathieu,
>
> On 6/9/25 17:23, Mathieu Poirier wrote:
> > On Tue, Jun 03, 2025 at 12:08:02PM +0200, Arnaud Pouliquen wrote:
> >> Hello Bjorn and Mathieu,
> >>
> >> I am resending this
t; + return -EINVAL;
> +
> + rproc_tee_prepare_args(trproc, TA_RPROC_FW_CMD_STOP, &arg, param, 0);
> +
> + ret = tee_client_invoke_func(rproc_tee_ctx.tee_ctx, &arg, param);
> + if (ret < 0 || arg.ret != 0) {
> + dev_err(rproc_tee_ctx.
On Tue, Jun 03, 2025 at 12:08:02PM +0200, Arnaud Pouliquen wrote:
> Hello Bjorn and Mathieu,
>
> I am resending this series after waiting for over two months for Bjorn's
> feedback, despite a prior reminder.
>
> Please could you coordinate between yourselves to dete
+-
> drivers/remoteproc/imx_rproc.h | 2 +
> 2 files changed, 127 insertions(+), 2 deletions(-)
>
I will look at this patch when either Daniel or Iuliana have given their R-B.
Thanks,
Mathieu
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
>
p_ipi_handler(scp);
> + else
> + scp_wdt_handler(scp, scp_to_host);
I would much rather see a test for the watchdog bit than just assuming it is
a watchdog interrupt. And while at it, please refactor the bit definition to be
platform agnostic rather than reusing 8192 def
t
> later in sysfs, able to load firmware into a remotecore and start it. [R5Fs]
> 6. Tested that each patch in this series generates no new warnings/errors.
> 7. Tested IPC on AM64x EVM Device. [Thanks to Judith].
> 8. Tested compilation of the remoteproc drivers as modules.
>
On Sat, May 17, 2025 at 06:53:29PM +0530, Beleswar Prasad Padhi wrote:
>
> On 5/16/2025 9:15 PM, Mathieu Poirier wrote:
> > On Tue, May 13, 2025 at 11:14:38AM +0530, Beleswar Padhi wrote:
> > > The rproc_detach() function invokes __rproc_detach() before
> > >
pply
this set without this patch - you can then work on fixing this bug.
Thanks,
Mathieu
> Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F
> subsystem")
> Signed-off-by: Beleswar Padhi
> ---
> v12: Changelog:
> 1. New patch. Fixup a state detectio
On Fri, May 09, 2025 at 11:59:26PM +0800, Dawei Li wrote:
> Introduce new eptdev abstraction based on anon inode. The new API is
> exactly same with legacy one except:
>
> - It's anonymous and devnode/path free.
> - Its fops->open() is empty.
>
> Signed-off-by: Dawei Li
> ---
> drivers/rpmsg/rp
Hi,
On Fri, May 09, 2025 at 11:59:25PM +0800, Dawei Li wrote:
> Current uAPI implementation for rpmsg ctrl & char device manipulation is
> abstracted in procedures below:
>
> Current uAPI implementation for rpmsg ctrl & char device manipulation is
> abstracted in procedures below:
> - fd = open("
oteproc: core: Clear table_sz
> when rproc_shutdown") to avoid carrying a partial fix.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/remoteproc/remoteproc_core.c | 1 -
> 1 file changed, 1 deletion(-)
>
I have applied this patch.
Thanks,
Mathieu
> diff --git a/
On Thu, May 15, 2025 at 12:21:14PM -0500, Andrew Davis wrote:
> 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, r
ivers/remoteproc/xlnx_r5_remoteproc.c | 34 -
> 1 file changed, 33 insertions(+), 1 deletion(-)
>
I have applied this patch.
Thanks,
Mathieu
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
> b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 5aeedeaf3c41..1af89782e116 10064
|4 +-
> drivers/remoteproc/ti_k3_common.c | 547 +++
> drivers/remoteproc/ti_k3_common.h | 113 +++
> drivers/remoteproc/ti_k3_dsp_remoteproc.c | 616 +
> drivers/remoteproc/ti_k3_m4_remoteproc.c | 583 +---
> drivers/remoteproc/ti_k3_r5_remoteproc.c | 1012 +++--
I am done reviewing this set. The work done herein is a textbook example on how
refactoring should be done and I commend you for it.
Mathieu
> 6 files changed, 1072 insertions(+), 1803 deletions(-)
> create mode 100644 drivers/remoteproc/ti_k3_common.c
> create mode 100644 drivers/remoteproc/ti_k3_common.h
>
> --
> 2.34.1
>
On Fri, Apr 25, 2025 at 04:11:12PM +0530, Beleswar Padhi wrote:
> The mailbox .rx_callback implementations in TI K3 R5, DSP and M4
> remoteproc drivers handle inbound mailbox messages in the same way.
> Introduce a common driver 'ti_k3_common.c' and refactor the
> implementations into a common func
ev->dev;
> struct k3_r5_core *core = kproc->priv;
> struct resource *res;
> int num_mems;
> int i;
>
> - num_mems = ARRAY_SIZE(mem_names);
> - kproc->mem = devm_kcalloc(dev, num_mems, sizeof(*kproc->mem),
> GFP_KERNEL);
>
On Fri, Apr 25, 2025 at 04:11:10PM +0530, 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 ref
On Fri, Apr 25, 2025 at 04:11:10PM +0530, 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 ref
> remoteproc: cleanup acquired resources when rproc_handle_resources()
> fails in rproc_attach()
> remoteproc: core: release rproc->clean_table after rproc_attach()
> fails
>
> drivers/remoteproc/remoteproc_core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
I have applied this patchset.
Thanks,
Mathieu
> --
> 2.25.1
>
On Tue, May 06, 2025 at 09:36:19AM -0300, Hiago De Franco wrote:
> Hi Peng,
>
> On Tue, May 06, 2025 at 12:38:35PM +0800, Peng Fan wrote:
> > On Mon, May 05, 2025 at 12:48:47PM -0300, Hiago De Franco wrote:
> > >From: Hiago De Franco
> > >
> > >For the i.MX8X and i.MX8 family SoCs, when the M-cor
I have started reviewing this patchset but due to its size, it will
take me several days or weeks, depending on workload and other patches
on this list. I will advise when I am done.
Thanks,
Mathieu
On Fri, 25 Apr 2025 at 04:41, Beleswar Padhi wrote:
>
> This series refactors a
-by: Thorsten Blum
> ---
> drivers/rpmsg/qcom_glink_native.c | 2 +-
> drivers/rpmsg/qcom_smd.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
I will let Bjorn take care of this one.
Thanks,
Mathieu
>
> diff --git a/drivers/rpmsg/qcom_glink_native.c
> b/drivers/rpms
_core.c
> > b/drivers/remoteproc/remoteproc_core.c
> > index b21eedefff87..6226e2d12a97 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -1656,6 +1656,7 @@ static int rproc_attach(struct rproc *rproc)
> >
; +
I have reflected long and hard on this. The problem with the above approach is
that we do almost the same thing in imx_rproc_prepare() and
rproc_resource_cleanup(). Function rproc_resource_cleanup() is able to deal
with empty lists so I think it is better to fix the "goto" statements in
rproc
On Sat, 26 Apr 2025 at 07:46, xiaolei wang wrote:
>
>
> On 4/26/25 21:18, Peng Fan wrote:
> > CAUTION: This email comes from a non Wind River email account!
> > Do not click links or open attachments unless you recognize the sender and
> > know the content is safe.
> >
> > On Sat, Apr 26, 2025 at
On Sat, 26 Apr 2025 at 06:41, Peng Fan wrote:
>
> On Wed, Apr 23, 2025 at 04:21:56PM -0300, Hiago De Franco wrote:
> >Hi Mathieu,
> >
> >On Wed, Apr 23, 2025 at 11:14:17AM -0600, Mathieu Poirier wrote:
> >> Good morning,
> >>
> >> On Wed, Apr
e occured.
Thanks,
Mathieu
> unreferenced object 0x861c5d00 (size 128):
> comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 02 88 0
On Wed, 23 Apr 2025 at 13:22, Hiago De Franco wrote:
>
> Hi Mathieu,
>
> On Wed, Apr 23, 2025 at 11:14:17AM -0600, Mathieu Poirier wrote:
> > Good morning,
> >
> > On Wed, Apr 23, 2025 at 12:51:31PM -0300, Hiago De Franco wrote:
> > > From: Hiago De Franc
Arnaud, Daniel, Iuliana, Andrew and Tanmay - please test this patchset
on the platforms you are working on.
Thanks,
Mathieu
On Wed, 23 Apr 2025 at 13:42, Rob Herring (Arm) wrote:
>
> While there's a common function to parse "memory-region" properties for
> DMA pool regio
priv->clk = devm_clk_get_optional(dev, NULL);
If my understanding of the problem is correct (see above), I think the real fix
for this is to make the "clocks" property mandatory in the bindings.
Daniel and Iuliana, I'd like to have your opinions on this.
Thanks,
Mathieu
>
On Tue, 22 Apr 2025 at 12:30, Tanmay Shah wrote:
>
>
>
> On 4/22/25 12:49 PM, Mathieu Poirier wrote:
> > On Tue, 22 Apr 2025 at 10:10, Tanmay Shah wrote:
> >>
> >>
> >>
> >> On 4/22/25 10:59 AM, Mathieu Poirier wrote:
> >>>
On Tue, 22 Apr 2025 at 10:10, Tanmay Shah wrote:
>
>
>
> On 4/22/25 10:59 AM, Mathieu Poirier wrote:
> > Good morning,
> >
> > On Mon, Apr 14, 2025 at 11:46:01AM -0700, Tanmay Shah wrote:
> >> Powering off RPU using force_pwrdwn call results in system fail
PM_FORCE_POWERDOWN);
> + return -EOPNOTSUPP;
> + }
Here I have to guess, because it is not documented, that it is the check to see
if zynqmp_pm_force_pwrdwn() is available. I'm not sure why it is needed because
zynqmp_pm_force_pwrdwn() returns and error code.
sc callback to handle resource table parsing and to
> process DSP-specific resource, to determine if waiting is needed.
>
> Update imx_dsp_rproc_start() to handle this condition accordingly.
>
> Signed-off-by: Iuliana Prodan
Applied.
Thanks,
Mathieu
> ---
> Changes in v5:
>
On Tue, 15 Apr 2025 at 05:04, Iuliana Prodan wrote:
>
> On 4/14/2025 6:41 PM, Mathieu Poirier wrote:
> > On Thu, Apr 10, 2025 at 12:30:30AM +0300, Iuliana Prodan (OSS) wrote:
> >> From: Iuliana Prodan
> >>
> >> Some DSP firmware requires a FW_READY signal
sc callback to handle resource table parsing and to
> process DSP-specific resource, to determine if waiting is needed.
>
> Update imx_dsp_rproc_start() to handle this condition accordingly.
>
> Signed-off-by: Iuliana Prodan
> ---
> Changes in v4:
> - Reviews from Mathieu Poiri
d, Apr 02, 2025 at 09:43:55AM +0800, Peng Fan wrote:
> >>> On Tue, Apr 01, 2025 at 10:05:03AM -0600, Mathieu Poirier wrote:
> >>> >On Tue, Apr 01, 2025 at 09:41:24AM +0800, Peng Fan wrote:
> >>...
> >>> >
> >>> >The core is already che
On Tue, 8 Apr 2025 at 02:47, Iuliana Prodan wrote:
>
> Hello Mathieu,
>
> On 4/7/2025 7:17 PM, Mathieu Poirier wrote:
> > Good morning,
> >
> > On Thu, Apr 03, 2025 at 01:01:24PM +0300, Iuliana Prodan (OSS) wrote:
> >> From: Iuliana Prodan
> >>
&
t handle_rsc callback to handle resource table parsing and to
> process DSP-specific resource, to determine if waiting is needed.
>
> Update imx_dsp_rproc_start() to handle this condition accordingly.
>
> Signed-off-by: Iuliana Prodan
> ---
> Changes in v3:
> - Reviews
On Sat, Mar 29, 2025 at 08:56:29PM +0800, Peng Fan wrote:
> On Fri, Mar 28, 2025 at 08:14:41AM -0600, Mathieu Poirier wrote:
> >On Fri, Mar 28, 2025 at 12:50:12PM +0800, Peng Fan wrote:
> >> On Thu, Mar 27, 2025 at 11:46:33AM -0600, Mathieu Poirier wrote:
> >> >H
ged, 2221 insertions(+)
Please break this patch in smaller ones. In most cases a patch should be at
most 300 lines.
Thanks,
Mathieu
> create mode 100644 drivers/remoteproc/mtk_vcp_common.c
> create mode 100644 drivers/remoteproc/mtk_vcp_common.h
> create mode 100644 drivers/remotep
On Tue, Apr 01, 2025 at 09:41:24AM +0800, Peng Fan wrote:
> On Mon, Mar 31, 2025 at 09:40:41AM -0600, Mathieu Poirier wrote:
> >On Sat, Mar 29, 2025 at 08:56:29PM +0800, Peng Fan wrote:
> >> On Fri, Mar 28, 2025 at 08:14:41AM -0600, Mathieu Poirier wrote:
> >> >On F
On Tue, Apr 01, 2025 at 10:04:02PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> Same as commit 47e6ab07018e ("remoteproc: imx_dsp_rproc: Add mutex
> protection for workqueue") and commit 35bdafda40cc ("remoteproc:
> stm32_rproc: Add mutex protection for workqueue"), imx_rproc driver
> also h
On Fri, Mar 28, 2025 at 12:50:12PM +0800, Peng Fan wrote:
> On Thu, Mar 27, 2025 at 11:46:33AM -0600, Mathieu Poirier wrote:
> >Hi,
> >
> >On Wed, Mar 26, 2025 at 10:02:14AM +0800, Peng Fan (OSS) wrote:
> >> From: Peng Fan
> >>
> >> There is cas
Hi,
On Wed, Mar 26, 2025 at 10:02:14AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> There is case as below could trigger kernel dump:
> Use U-Boot to start remote processor(rproc) with resource table
> published to a fixed address by rproc. After Kernel boots up,
> stop the rproc, load a ne
Implement handle_rsc callback to handle resource table parsing and to
> process DSP-specific resource, to determine if waiting is needed.
>
> Update imx_dsp_rproc_start() to handle this condition accordingly.
>
> Signed-off-by: Iuliana Prodan
> ---
> Changes in v2:
> - R
Jiri Slaby (SUSE)
> Cc: Bjorn Andersson
> Cc: Mathieu Poirier
> Cc: linux-remotep...@vger.kernel.org
> ---
> drivers/remoteproc/pru_rproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rpr
On Fri, Mar 14, 2025 at 05:17:19PM +0200, Daniel Baluta wrote:
> Add documentation for 'run_stall' imx_dsp_rproc struct member.
> This also fixes the following warning:
>
> warning: Function parameter or struct member 'run_stall'
> not described in 'imx_dsp_rproc'
>
> Fixes: 0184b4fdbad1 ("imx_ds
from IMX DSP
> remoteproc driver because there is no Device Tree users.
>
> Changes since v4:
> https://lore.kernel.org/lkml/20250305100037.373782-3-daniel.bal...@nxp.com/T/
> - picked-up R-b tags from Frank Li and Peng Fan
> - reworded commit message of patch 8/8 as p
centrate
on _why_ we are moving from the current design to using the reset controller
API.
This can go in the 6.15 merge window if you send me a V5 fast enough.
Thanks,
Mathieu
>
> [1]
> https://patchwork.kernel.org/project/imx/patch/20250212085222.107102-6-daniel.bal...@nxp.com/
>
>
Thanks for the re-spin. I will wait for Shawn and Sascha to review their
respective bits before picking up this set.
Mathieu
On Tue, Mar 11, 2025 at 10:58:03AM +0200, Daniel Baluta wrote:
> This patch series adds support to control the Run/Stall DSP bits found on
> i.MX8MP via the
do above means the resource table in the FW
image needs to be mofidied. As such, you could take advantage of the vendor
specific resource table entry already supported by the remoteproc framework [3].
>From there you provide a resource handler specific to the iMX DSP driv
ported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202502161648.wzwrfv7i-...@intel.com/
> Cc: Andrew Davis
> Signed-off-by: Peng Fan
> ---
> drivers/remoteproc/omap_remoteproc.c | 1 +
> 1 file changed, 1 insertion(+)
>
Applied - thanks,
Mathieu
>
rsion
of it renamed to something more meaningful) from
__rseq_handle_notify_resume() ? By combining time_before() checks from
the scheduler tick and at return to userspace after preemption, AFAIU
we'd be handling the periodic workload correctly, and therefore this
test for mm_cid compaction could check for m
ead should see 0 as mm_cid, if that
doesn't happen, the compaction mechanism didn't work and the test fails.
The test never fails if only 1 core is available, in which case, we
cannot test anything as the only available mm_cid is 0.
To: Mathieu Desnoyers
Reviewed-by: Mathieu Desnoye
On 2025-01-15 12:57, Shuah Khan wrote:
On 1/14/25 17:45, Mathieu Desnoyers wrote:
On 2025-01-14 19:14, Shuah Khan wrote:
On 1/14/25 07:51, Mathieu Desnoyers wrote:
When porting librseq commit:
commit c7b45750fa85 ("Adapt to glibc __rseq_size feature detection")
from librseq to
drivers/remoteproc/keystone_remoteproc.c | 17 +++---
> drivers/remoteproc/omap_remoteproc.c | 7 ++---
> drivers/remoteproc/st_remoteproc.c | 54
> +---
> 3 files changed, 28 insertions(+), 50 deletions(-)
I have applied this set.
Thanks,
Mathieu
>
On 2025-01-14 19:14, Shuah Khan wrote:
On 1/14/25 07:51, Mathieu Desnoyers wrote:
When porting librseq commit:
commit c7b45750fa85 ("Adapt to glibc __rseq_size feature detection")
from librseq to the kernel selftests, the following line was missed
at the end of rseq_init():
on")
Fixes: 73a4f5a704a2 ("selftests/rseq: Fix mm_cid test failure")
Signed-off-by: Mathieu Desnoyers
Cc: Raghavendra Rao Ananta
Cc: Shuah Khan
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: "Paul E. McKenney"
Cc: Carlos O'Donell
Cc: Florian Weimer
Cc: Michael Jeanson
On 2025-01-14 09:07, Mathieu Desnoyers wrote:
On 2025-01-13 18:06, Shuah Khan wrote:
On 12/10/24 15:44, Raghavendra Rao Ananta wrote:
Currently the rseq constructor, rseq_init(), assumes that glibc always
has the support for rseq symbols (__rseq_size for instance). However,
glibc supports rseq
atch. I need to review it carefully
to make sure it does not break anything else moving forward.
Please wait before merging.
Thanks,
Mathieu
thanks,
-- Shuah
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
quot; constraint.
I have compile tested this only for riscv. However, the same fixes I
use in the OpenRISC rseq selftests and everything passes with no issues.
Signed-off-by: Stafford Horne
Reviewed-by: Mathieu Desnoyers
---
tools/testing/selftests/rseq/rseq-riscv-bits.h | 6 +++---
tool
Linux: Linux buildroot 6.13.0-rc2-5-g1fa73dd6c2d3-dirty #213 SMP
Sat Dec 28 22:18:39 GMT 2024 openrisc GNU/Linux
Glibc: 2024-12-13 e4e49583d9 Stafford Horne or1k: Update
libm-test-ulps
Signed-off-by: Stafford Horne
Thanks!
Reviewed-by: Mathieu Desnoyers
---
tools
erved memory
> remoteproc: k3-r5: Use devm_kcalloc() helper
> remoteproc: k3-r5: Use devm_ioremap_wc() helper
> remoteproc: k3-r5: Use devm_rproc_add() helper
> remoteproc: k3-r5: Add devm action to release tsp
>
> drivers/remoteproc/ti_k3_r5_remoteproc.c | 88 ++--
> 1 file changed, 35 insertions(+), 53 deletions(-
I have applied this set.
Thanks,
Mathieu
>
> --
> 2.34.1
>
i_k3_r5_remoteproc.c | 86 ++--
> 1 file changed, 34 insertions(+), 52 deletions(-)
>
Please note that I am looking for an R-B and T-B tag from two
different people (for now one of each will suffice) before looking at
patches.
Thanks,
Mathieu
> --
> 2.34.1
>
Tinghan Shen
> Signed-off-by: Chen-Yu Tsai
> ---
> Changes since v1:
> - Fix commit subject: populate devices *for* SCP cores
> ---
> drivers/remoteproc/mtk_scp.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
I have applied this patch.
Thanks,
Mathie
pthread_setaffinity_np(tinfo[j], sizeof(test_affinity),
+ &test_affinity);
It would be better that each thread set their own affinity when
they start rather than having the main thread set each created thread
affinity while the
best effort.
If best effort, then this corner-case is not worthy of a "Fix" tag.
Otherwise, we should identify which commit it fixes and introduce a
"Fix" tag.
Thanks,
Mathieu
Signed-off-by: Gabriele Monaco
---
include/linux/mm_types.h | 11 +
include/linux/s
On 2024-12-13 04:54, Gabriele Monaco wrote:
From: Mathieu Desnoyers
When a process reduces its number of threads or clears bits in its CPU
affinity mask, the mm_cid allocation should eventually converge towards
smaller values.
I target v6.13 for this patch. As it fixes a commit which was
nates but before its
mm is freed.
Can you fold it in patch 1/4 ?
Thanks,
Mathieu
Signed-off-by: Gabriele Monaco
---
include/linux/mm_types.h | 7 ---
kernel/sched/core.c | 19 +++
2 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/include/linux/mm_ty
On Fri, 6 Dec 2024 at 10:05, Mathieu Poirier wrote:
>
> On Thu, 5 Dec 2024 at 11:22, Arnaud POULIQUEN
> wrote:
> >
> > Hello Mathieu,
> >
> > Thanks for the review!
> > I just need to clarify a point below before preparing the next revision.
> >
On Thu, 5 Dec 2024 at 11:22, Arnaud POULIQUEN
wrote:
>
> Hello Mathieu,
>
> Thanks for the review!
> I just need to clarify a point below before preparing the next revision.
>
> On 12/3/24 18:22, Mathieu Poirier wrote:
> > On Thu, Nov 28, 2024 at 09:42:10AM +0
> @@ -1379,6 +1386,7 @@ static void scp_remove(struct platform_device *pdev)
> rproc_del(scp->rproc);
> scp_free(scp);
> }
> + of_platform_depopulate(&pdev->dev);
This looks like a sensible addition to me but I'll give Angelo some time to
chime in.
Regards,
Mathieu
> mutex_destroy(&scp_cluster->cluster_lock);
> }
>
> --
> 2.47.0.338.g60cca15819-goog
>
F segments into memory.
> Rename this to a more explicit name: load_segments().
This is introducing more code churn than is worth it. Please enhance the usage
comment for ->load() as part of the previous patch and drop this one.
I am done reviewing this set.
Thanks,
Mathieu
>
> Su
On Thu, Nov 28, 2024 at 09:42:12AM +0100, Arnaud Pouliquen wrote:
> The two methods to load the firmware to memory should be exclusive.
>
> - make load_segments optional returning 0 if not set in
> rproc_load_segments(),
> - ensure that load_segments() and load_fw() are not both set,
> - do not
On Thu, Nov 28, 2024 at 09:42:10AM +0100, Arnaud Pouliquen wrote:
> This patch updates the rproc_ops structures to include two new optional
> operations.
>
> - The load_fw() op is responsible for loading the remote processor
> non-ELF firmware image before starting the boot sequence. This ops will
panic at least the returned number of milliseconds
> * @coredump: collect firmware dump after the subsystem is shutdown
> + * @load_fw: optional function to load non-ELF firmware image to memory,
> where the remote
Round this down to 80 characters please. Here having a
Good morning,
On Thu, Nov 28, 2024 at 09:42:09AM +0100, Arnaud Pouliquen wrote:
> Add a remoteproc TEE (Trusted Execution Environment) driver
> that will be probed by the TEE bus. If the associated Trusted
> application is supported on secure part this driver offers a client
> interface to load a
= &curr->rcu;
Why is it OK to re-use the task struct rcu field ? Where else is it
used, and is there a risk of being inserted twice ?
Thanks,
Mathieu
unsigned long now = jiffies;
if (!curr->mm || (curr->flags & (PF_EXITING | PF_KTHREAD)) ||
- work->
3 +2503,6 @@ struct rproc *rproc_alloc(struct device *dev, const
> char *name,
> if (rproc_alloc_ops(rproc, ops))
> goto put_device;
>
> - /* Assign a unique device index and name */
> - rproc->index = ida_alloc(&rproc_dev_index, GFP_KERNEL);
&g
On Wed, 20 Nov 2024 at 09:39, Arnaud POULIQUEN
wrote:
>
>
>
> On 11/20/24 17:04, Mathieu Poirier wrote:
> > On Tue, 19 Nov 2024 at 13:38, Mathieu Poirier
> > wrote:
> >>
> >> On Tue, 19 Nov 2024 at 11:14, Arnaud POULIQUEN
> >> wrote:
>
On Tue, 19 Nov 2024 at 13:38, Mathieu Poirier
wrote:
>
> On Tue, 19 Nov 2024 at 11:14, Arnaud POULIQUEN
> wrote:
> >
> > Hello Mathieu,
> >
> > On 11/18/24 18:52, Mathieu Poirier wrote:
> > > On Mon, Nov 04, 2024 at 02:35:12PM +0100, Arnaud Poul
On Tue, 19 Nov 2024 at 11:14, Arnaud POULIQUEN
wrote:
>
> Hello Mathieu,
>
> On 11/18/24 18:52, Mathieu Poirier wrote:
> > On Mon, Nov 04, 2024 at 02:35:12PM +0100, Arnaud Pouliquen wrote:
> >> This patch updates the rproc_ops struct to include an optional
> >>
if rproc_start() fails.
4) Take rproc_tee_load_fw() out of rproc_tee_parse_fw(). It will now be called
in rproc_load_fw().
5) As stated above function rproc_release_fw() now calls rproc_tee_release_fw().
The former is already called in rproc_shutdown() so we are good in that front.
With the above the
t; struct firmware *fw)
> unprepare_subdevices:
> rproc_unprepare_subdevices(rproc);
> reset_table_ptr:
> + if (rproc->ops->release_fw)
> + rproc->ops->release_fw(rproc);
I always thought that looked hackish and brittle. I am trying to find a
On Mon, Nov 04, 2024 at 02:35:10PM +0100, Arnaud Pouliquen wrote:
> Add a remoteproc TEE (Trusted Execution Environment) driver
> that will be probed by the TEE bus. If the associated Trusted
> application is supported on secure part this driver offers a client
> interface to load a firmware by the
I have applied all 3 patches in this set.
Thanks,
Mathieu
On Mon, Oct 21, 2024 at 03:45:55PM -0500, Andrew Davis wrote:
> 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 Fri, Oct 25, 2024 at 01:40:45PM +0530, Mukesh Ojha wrote:
> On Mon, Oct 21, 2024 at 09:12:47AM -0600, Mathieu Poirier wrote:
> > Hi Mukesh,
> >
> > On Wed, Oct 16, 2024 at 10:25:46AM +0530, Mukesh Ojha wrote:
> > > Multiple call to glink_subdev_stop() for
Good day,
On Wed, Oct 23, 2024 at 12:21:11PM -0400, Laurentiu Mihalcea wrote:
> From: Laurentiu Mihalcea
>
> Add new compatible for imx95's CM7 with SOF.
>
> Signed-off-by: Laurentiu Mihalcea
> ---
> .../bindings/remoteproc/fsl,imx-rproc.yaml| 58 +--
> 1 file changed, 53
very, with exactly this kind of
use case in mind. I think it is the only way to move forward with this
feature, though it is a big job that requires a lot of community interactions.
Regards,
Mathieu
> +
> + ret = idr_alloc(&rproc->notifyids, rvring, start, end, GFP_KERNEL);
>
c_itf);
> +
If I read Bjorn's comment properly, this should probably be:
rproc_tee_unregister(rproc);
with the if() inside the function.
> return ret;
> }
>
> @@ -933,6 +987,9 @@ static void stm32_rproc_remove(struct platform_device
> *pdev)
> dev_pm_clear_wake_irq(dev);
> device_init_wakeup(dev, false);
> }
> + if (rproc->tee_rproc_itf)
> + tee_rproc_unregister(rproc->tee_rproc_itf);
> +
Same here.
I am done reviewing this set.
Thanks,
Mathieu
> }
>
> static int stm32_rproc_suspend(struct device *dev)
> --
> 2.25.1
>
On Wed, Oct 09, 2024 at 10:01:05AM +0200, Arnaud Pouliquen wrote:
> This patch updates the rproc_ops struct to include an optional
> release_fw function.
>
> The release_fw ops is responsible for releasing the remote processor
> firmware image. The ops is called in the following cases:
>
> - An
On Wed, Oct 09, 2024 at 10:01:03AM +0200, Arnaud Pouliquen wrote:
> Add a remoteproc TEE (Trusted Execution Environment) driver
> that will be probed by the TEE bus. If the associated Trusted
> application is supported on secure part this driver offers a client
> interface to load a firmware by the
ot;, ret);
> return ret;
> }
> @@ -1839,7 +1840,7 @@ int rproc_trigger_recovery(struct rproc *rproc)
> return ret;
>
> /* State could have changed before we got the mutex */
> - if (rproc->state != RPROC_CRASHED)
> +
/20241007132441.2732215-1-a...@kernel.org/
>
> Andrew Davis (2):
> remoteproc: k3-dsp: Add compile testing support
> remoteproc: k3-r5: Add compile testing support
>
I have applied this set.
Thanks,
Mathieu
> drivers/remoteproc/Kconfig | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> --
> 2.39.2
>
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
> > >
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 6.12-rc2
> > remains broken and
On Tue, Oct 15, 2024 at 06:58:33PM +0200, Richard Weinberger wrote:
> Mathieu,
>
> Am Dienstag, 15. Oktober 2024, 18:48:08 CEST schrieb Mathieu Poirier:
> > Good morning Richard,
> >
> > On Fri, Oct 11, 2024 at 02:39:22PM +0200, Richard Weinberger wrote:
> > >
Simplify with dev_err_probe()
> remoteproc: ti_k3_r5: Simplify with dev_err_probe()
> remoteproc: ti_k3_r5: Simplify with scoped for each OF child loop
I have applied patches 1 to 4. I will let Bjorn do the QC ones.
Thanks,
Mathieu
> remoteproc: qcom_q6
1 - 100 of 3197 matches
Mail list logo
