On Fri, Sep 26, 2025 at 08:33:14PM +0800, Peng Fan wrote:
> Tested on
> i.MX8MP-EVK, i.MX8MM-EVK, i.MX93-11x11-EVK, i.MX8QXP-MEK, and i.MX8ULP-EVK.
>
> Retested all the patches for V3 on above platforms. And pass build
> with patch incremental applied with ARM64 defconfig. pass build for
> imx_v6_
On Thu, Sep 25, 2025 at 04:31:15AM +0800, Peng Fan wrote:
> On Wed, Sep 24, 2025 at 11:10:33AM -0600, Mathieu Poirier wrote:
> >On Wed, 24 Sept 2025 at 09:35, Peng Fan wrote:
> >>
> ...
> >> Sorry for early ping - I just wanted to check if there's any chance
On Wed, Sep 17, 2025 at 09:19:16PM +0800, Peng Fan wrote:
> Replace separate calls to devm_clk_get() and clk_prepare_enable() with
> devm_clk_get_enabled(), which combines clock acquisition and enabling
> into a single managed step. Simplify the probe logic and remove the need
> for manual clock di
On Wed, Sep 17, 2025 at 09:19:13PM +0800, Peng Fan wrote:
> The order of runtime PM API calls in the remove path is wrong.
> pm_runtime_put() should be called before pm_runtime_disable(), per the
> runtime PM guidelines.
Where is this mentioned? I have looked in [1] and couldn't find anything.
[
On Fri, Sep 12, 2025 at 12:34:01PM +0200, AngeloGioacchino Del Regno wrote:
> Il 12/09/25 11:51, Matthias Brugger ha scritto:
> >
> >
> > On 12/09/2025 10:45, AngeloGioacchino Del Regno wrote:
> > > Il 12/09/25 09:01, Matthias Brugger ha scritto:
> > > >
> > > >
> > > > On 11/09/2025 16:00, Ang
On Fri, Sep 12, 2025 at 02:11:20PM +0800, Peng Fan wrote:
> On Thu, Sep 11, 2025 at 01:13:59AM +, Peng Fan wrote:
> >Hi Frank,
> >>
> >> Can you remove 'method' in data struct also?
> >
> >The method is used in other places and other purpose, imx_rproc_detach
> >imx_rproc_put_scu, imx_rproc_re
On Fri, Sep 12, 2025 at 12:34:01PM +0200, AngeloGioacchino Del Regno wrote:
> Il 12/09/25 11:51, Matthias Brugger ha scritto:
> >
> >
> > On 12/09/2025 10:45, AngeloGioacchino Del Regno wrote:
> > > Il 12/09/25 09:01, Matthias Brugger ha scritto:
> > > >
> > > >
> > > > On 11/09/2025 16:00, Ang
On Fri, 12 Sept 2025 at 10:04, Arnaud POULIQUEN
wrote:
>
> Hello BJorn, Mathieu,
>
> Do you think, you could find time to review this series before the
> next merge window.
>
> Regarding the discussion between Harshal and Sumit, I did not notice any
> comments requesting immediate updates; the con
On Wed, Sep 10, 2025 at 03:11:44PM +0800, Peng Fan wrote:
> This patchset serves as a preparing patchset for i.MX95 support.
>
> The current code logic is complicated, with mix the usage of switch-case
> and if-else.
>
> To simplify the code logic:
> Introduce struct imx_rproc_plat_ops to wrap p
On Mon, 9 Jun 2025 at 09:15, Dawei Li wrote:
>
> Hi,
>
> This is V4 of series which introduce new uAPI(RPMSG_CREATE_EPT_FD_IOCTL)
> for rpmsg subsystem.
>
> Current uAPI implementation for rpmsg ctrl & char device manipulation is
> abstracted in procedures below:
> - fd = open("/dev/rpmsg_ctrlX")
On Mon, Sep 08, 2025 at 09:07:39PM +0800, Peng Fan wrote:
> With the switch-case in imx_rproc_{start,stop}{} removed, simplify
> the code logic by removing 'goto'. The last switch-case in
> imx_rproc_detect_mode() are no longer needed and can be removed.
>
> This cleanup improves code readability
On Wed, 3 Sept 2025 at 01:20, Daniel Baluta wrote:
>
>
>
> > >Please give detailed suggestions, but not a general comment.
> >
> >
> > @Daniel, @Frank — since you've reviewed and R-b'd this patchset, do you
> > have thoughts on the latest feedback from Mathieu? Would you agree that
> > further si
On Tue, 2 Sept 2025 at 23:28, Peng Fan wrote:
>
> On Wed, Sep 03, 2025 at 12:56:11PM +0800, Peng Fan wrote:
> >On Tue, Sep 02, 2025 at 10:38:49AM -0600, Mathieu Poirier wrote:
> >>On Sat, Aug 30, 2025 at 08:52:09PM +0800, Peng Fan wrote:
> >>> On Fri, Aug 29,
On Sat, Aug 30, 2025 at 08:52:09PM +0800, Peng Fan wrote:
> On Fri, Aug 29, 2025 at 10:00:04AM -0600, Mathieu Poirier wrote:
> >Good day,
> >
> >On Thu, Aug 21, 2025 at 05:05:05PM +0800, Peng Fan wrote:
> >> i.MX95 features a Cortex-M33 core, six Cortex-A55 cores, an
On Sun, Aug 24, 2025 at 09:52:37PM +0200, Christophe JAILLET wrote:
> If an error occurs after a successful k3_rproc_request_mbox() call,
> mbox_free_channel() should be called to avoid a leak.
>
> Such a call is missing in the error handling path of k3_dsp_rproc_probe().
> It is also missing both
On Wed, Aug 27, 2025 at 01:13:52PM +0300, Claudiu wrote:
> From: Claudiu Beznea
>
> Starting with commit f99508074e78 ("PM: domains: Detach on
> device_unbind_cleanup()"), there is no longer a need to call
> dev_pm_domain_detach() in the bus remove function. The
> device_unbind_cleanup() function
Good day,
On Thu, Aug 21, 2025 at 05:05:05PM +0800, Peng Fan wrote:
> i.MX95 features a Cortex-M33 core, six Cortex-A55 cores, and
> one Cortex-M7 core. The System Control Management Interface(SCMI)
> firmware runs on the M33 core. The i.MX95 SCMI firmware named System
> Manager(SM) includes vendo
On Mon, Aug 25, 2025 at 01:29:26PM -0500, Andrew Davis wrote:
> On 8/25/25 12:04 PM, Mathieu Poirier wrote:
> > On Thu, Aug 14, 2025 at 08:55:31AM -0500, Andrew Davis wrote:
> > > This helps prevent mistakes like freeing out of order in cleanup functions
> > > and forget
On Thu, Aug 14, 2025 at 08:55:31AM -0500, Andrew Davis wrote:
> 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 | 30 +--
> 1
On Thu, Aug 14, 2025 at 08:55:30AM -0500, Andrew Davis 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: Andrew Davis
> ---
> drivers/remoteproc/d
Did you send me a patchset that doesn't clear checkpatch.pl?
On Mon, Aug 18, 2025 at 03:44:16PM -0500, Shenwei Wang wrote:
> Support the remote devices on the remote processor via the RPMSG bus on
> i.MX platform.
>
> The expected DTS layout structure is following:
>
> cm33: remoteproc-cm33
On Wed, Aug 06, 2025 at 02:48:17PM -0300, Hiago De Franco wrote:
> From: Hiago De Franco
>
> As of today, pinging the remote processor during k3_rproc_request_mbox()
> does not have any functional effect. This behavior was originally based on
> the OMAP remoteproc driver, where the idea was to se
Hi,
On Tue, Jul 29, 2025 at 10:31:13AM +0800, Huayu Zong wrote:
> Add SCP support for mt8189.
>
> Signed-off-by: Huayu Zong
> ---
> drivers/remoteproc/mtk_common.h | 11 ++
> drivers/remoteproc/mtk_scp.c| 37 ++---
> 2 files changed, 45 insertions(+), 3 d
Hi Beleswar,
On Thu, Jul 24, 2025 at 07:01:44PM +0530, Beleswar Padhi wrote:
> When attaching to a remote processor, it is implied that the rproc was
> booted by an external entity. Thus, it's carveout and devmem resources
> would already have been processed by the external entity during boot.
>
On Mon, Jul 28, 2025 at 01:39:38PM +0300, Daniel Baluta wrote:
> On Tue, Jul 22, 2025 at 11:16 AM Shengjiu Wang wrote:
> >
> > When enabled FW recovery, but is broken because software reset is missed
> > in this recovery flow. So move software reset from
> > imx_dsp_runtime_resume() to .load() and
On Mon, Jul 21, 2025 at 11:37:23AM -0500, Tanmay Shah wrote:
>
>
> On 7/21/25 10:24 AM, Mathieu Poirier wrote:
> > Good morning,
> >
> > On Wed, Jul 16, 2025 at 02:30:47PM -0700, Tanmay Shah wrote:
> > > AMD-Xilinx platform driver does not support iommu or r
On Mon, Jul 21, 2025 at 02:57:24PM +0800, Peng Fan wrote:
> On Wed, Jul 16, 2025 at 02:30:47PM -0700, Tanmay Shah wrote:
> >AMD-Xilinx platform driver does not support iommu or recovery mechanism
> >yet. Disable both features in platform driver.
> >
> >Signed-off-by: Tanmay Shah
> >---
> > drivers
Good morning,
On Wed, Jul 16, 2025 at 02:30:47PM -0700, Tanmay Shah wrote:
> AMD-Xilinx platform driver does not support iommu or recovery mechanism
> yet. Disable both features in platform driver.
>
> Signed-off-by: Tanmay Shah
> ---
> drivers/remoteproc/xlnx_r5_remoteproc.c | 2 ++
> 1 file c
On Sun, 20 Jul 2025 at 21:08, Peng Fan wrote:
>
> On Fri, Jul 18, 2025 at 11:06:04AM -0600, Mathieu Poirier wrote:
> >On Fri, Jul 18, 2025 at 04:20:34PM +0800, Peng Fan wrote:
> >> On Thu, Jul 17, 2025 at 08:48:43AM -0600, Mathieu Poirier wrote:
> >> >On Mon,
On Fri, Jul 18, 2025 at 04:20:34PM +0800, Peng Fan wrote:
> On Thu, Jul 17, 2025 at 08:48:43AM -0600, Mathieu Poirier wrote:
> >On Mon, Jul 14, 2025 at 11:52:05AM +, Peng Fan wrote:
> >> > Subject: Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95
> >> >
On Mon, Jul 14, 2025 at 11:52:05AM +, Peng Fan wrote:
> > Subject: Re: [PATCH v4 0/5] remoteproc: imx_rproc: Support i.MX95
> >
> [...]
> > New warnings running 'make CHECK_DTBS=y for
> > arch/arm64/boot/dts/freescale/' for 20250710-imx95-rproc-1-v4-0-
> > a7123e857...@nxp.com:
> >
> > arch/
the kernel.
>
> Suggested-by: Ulf Hansson
> Reviewed-by: Ulf Hansson
> Reviewed-by: Peng Fan
> Signed-off-by: Hiago De Franco
Reviewed-by: Mathieu Poirier
> ---
> Hi Mathieu, Ulf,
>
> This is the v8 of patch3 from the patch series:
> https://lore.kernel.org/all/20
On Wed, Jul 16, 2025 at 10:25:52AM -0300, Hiago De Franco wrote:
> Hi Mathieu, Ulf,
>
> On Tue, Jul 15, 2025 at 09:32:44AM -0600, Mathieu Poirier wrote:
> > On Sun, Jun 29, 2025 at 02:25:12PM -0300, Hiago De Franco wrote:
> > > From: Hiago De Franco
> > >
>
On Sun, Jun 29, 2025 at 02:25:12PM -0300, Hiago De Franco wrote:
> From: Hiago De Franco
>
> When the Cortex-M remote core is started and already running before
> Linux boots (typically by the Cortex-A bootloader using a command like
> bootaux), the current driver is unable to attach to it. This
Hi,
On Tue, Jul 15, 2025 at 01:49:42PM +0200, Ulf Hansson wrote:
> Hi Mathieu,
>
> On Thu, 3 Jul 2025 at 18:45, Mathieu Poirier
> wrote:
> >
> > Hi Hiago,
> >
> > Many thanks for re-working the changelog and comments in this patchset,
> > thing
On Fri, Jul 04, 2025 at 01:25:29PM +0800, Shengjiu Wang wrote:
> Add call rproc_coredump_set_elf_info() to initialize the elf info for
> coredump, otherwise coredump will report error "ELF class is not set".
>
> Signed-off-by: Shengjiu Wang
> ---
> drivers/remoteproc/imx_dsp_rproc.c | 2 ++
> 1
On Fri, Jul 04, 2025 at 01:25:28PM +0800, Shengjiu Wang wrote:
> When recovery is triggered, rproc_stop() is called first then
> rproc_start(), but there is no rproc_unprepare_device() and
> rproc_prepare_device() in the flow. As the software reset is needed
> before DSP starts, so move software re
On Wed, Jul 09, 2025 at 05:02:31PM +0800, Peng Fan wrote:
> Hi Mathieu,
>
> On Tue, Jul 08, 2025 at 10:32:34AM -0600, Mathieu Poirier wrote:
> >Good day,
>
> Thanks, good day.
>
> >
> >On Wed, Jun 25, 2025 at 10:23:28AM +0800, Peng Fan (OSS) wrote:
&g
On Wed, Jul 09, 2025 at 03:49:40PM +0800, Peng Fan wrote:
> Hi Mathieu,
>
> On Tue, Jul 08, 2025 at 10:39:55AM -0600, Mathieu Poirier wrote:
> >On Wed, Jun 25, 2025 at 10:23:29AM +0800, Peng Fan (OSS) wrote:
> >> From: Peng Fan
> >>
> >> Add imx_
On Wed, Jun 25, 2025 at 10:23:29AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> Add imx_rproc_cfg_imx95_m7 and address(TCM and DDR) mapping.
> Add i.MX95 of_device_id entry.
>
> Reviewed-by: Daniel Baluta
> Signed-off-by: Peng Fan
> ---
> drivers/remoteproc/imx_rproc.c | 25 +
Good day,
On Wed, Jun 25, 2025 at 10:23:28AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> i.MX95 features a Cortex-M33 core, six Cortex-A55 cores, and
> one Cortex-M7 core. The System Control Management Interface(SCMI)
> firmware runs on the M33 core. The i.MX95 SCMI firmware named System
>
On Fri, Jul 04, 2025 at 04:08:16PM -0300, Hiago De Franco wrote:
> Hi Mathieu,
>
> On Fri, Jul 04, 2025 at 10:25:19AM -0600, Mathieu Poirier wrote:
> > Good morning,
> >
> > On Thu, Jul 03, 2025 at 10:08:31AM -0300, Hiago De Franco wrote:
> > > From: Hia
Good morning,
On Thu, Jul 03, 2025 at 10:08:31AM -0300, Hiago De Franco wrote:
> From: Hiago De Franco
>
> Merge the contiguous ITCM and DTCM regions into a single region to
> prevent failures when loading ELF files with large sections:
>
> remoteproc remoteproc0: powering up imx-rproc
> remote
s/i2c/i2c-core-base.c | 2 +-
> drivers/mmc/core/sdio_bus.c | 2 +-
> drivers/rpmsg/rpmsg_core.c | 2 +-
Reviewed-by: Mathieu Poirier
> drivers/soundwire/bus_type.c | 2 +-
> drivers/spi/spi.c| 2 +-
> drive
Hi Hiago,
Many thanks for re-working the changelog and comments in this patchset, things
are much clearer now.
Thanks,
Mathieu
On Sun, Jun 29, 2025 at 02:25:09PM -0300, Hiago De Franco wrote:
> From: Hiago De Franco
>
> This patch series depends on Ulf's patches that are currently under
> re
Andrew, Hari and Beleswar - please test this on your side and get back to me
with the results.
Thanks,
Mathieu
On Fri, Jun 27, 2025 at 11:42:33PM +0200, Christophe JAILLET wrote:
> IF an error occurs after a successful k3_rproc_request_mbox() call,
> mbox_free_channel() should be called to avoid
On Fri, Jun 20, 2025 at 12:57:28PM -0700, Tanmay Shah wrote:
> In case of kexec call, each driver's shutdown callback is called. Handle
> this call for rproc driver and shutdown/detach each core that was powered
> on before. This is needed for proper Life Cycle Management of remote
> processor. Oth
On Tue, Jul 01, 2025 at 10:28:33AM +0800, Shengjiu Wang wrote:
> On Tue, Jul 1, 2025 at 1:05 AM Mathieu Poirier
> wrote:
> >
> > On Wed, Jun 18, 2025 at 02:26:44PM +0800, Shengjiu Wang wrote:
> > > Add call rproc_coredump_set_elf_info() to initialize the elf info fo
On Tue, Jul 01, 2025 at 10:16:21AM +0800, Shengjiu Wang wrote:
> On Tue, Jul 1, 2025 at 12:49 AM Mathieu Poirier
> wrote:
> >
> > On Thu, Jun 26, 2025 at 09:32:06AM +0800, Shengjiu Wang wrote:
> > > On Wed, Jun 25, 2025 at 10:39 PM Mathieu Poirier
> > > wrote:
On Wed, Jun 18, 2025 at 02:26:44PM +0800, Shengjiu Wang wrote:
> Add call rproc_coredump_set_elf_info() to initialize the elf info for
> coredump, otherwise coredump will report an error "ELF class is not set".
>
> Remove the DSP IRAM and DRAM segment in coredump list, because after
> stop, DSP po
On Thu, Jun 26, 2025 at 09:32:06AM +0800, Shengjiu Wang wrote:
> On Wed, Jun 25, 2025 at 10:39 PM Mathieu Poirier
> wrote:
> >
> > On Tue, 24 Jun 2025 at 21:25, Shengjiu Wang wrote:
> > >
> > > On Mon, Jun 23, 2025 at 11:11 PM Mathieu Poirier
&g
On Fri, 27 Jun 2025 at 08:50, Hiago De Franco wrote:
>
> On Fri, Jun 27, 2025 at 08:31:20AM -0600, Mathieu Poirier wrote:
> > On Thu, 26 Jun 2025 at 15:59, Hiago De Franco wrote:
> > >
> > > From: Hiago De Franco
> > >
> > > This patch series d
On Thu, 26 Jun 2025 at 15:59, Hiago De Franco wrote:
>
> From: Hiago De Franco
>
> This patch series depends on Ulf's patches that are currently under
> review, "pmdomain: Add generic ->sync_state() support to genpd" [1].
> Without them, this series is not going to work.
>
I thought we agreed to
On Wed, Jun 25, 2025 at 12:12:03PM -0500, Andrew Davis wrote:
> On 6/25/25 11:13 AM, Mathieu Poirier wrote:
> > Good day,
> >
> > On Thu, Jun 19, 2025 at 03:57:22PM -0500, Andrew Davis wrote:
> > > Module aliases are used by userspace to identify the correct modul
Good day,
On Thu, Jun 19, 2025 at 03:57:22PM -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 "rpmsg-raw", but the module alias is "rpmsg_chrdev".
>
On Tue, 24 Jun 2025 at 21:25, Shengjiu Wang wrote:
>
> On Mon, Jun 23, 2025 at 11:11 PM Mathieu Poirier
> wrote:
> >
> > Good day,
> >
> > On Wed, Jun 18, 2025 at 02:26:43PM +0800, Shengjiu Wang wrote:
> > > when recovery is triggered, rproc_stop() is
On Wed, Jun 18, 2025 at 11:19:33AM -0700, Tanmay Shah wrote:
> When operating in split mode, it is a valid usecase to have
> only one core enabled in the cluster. Remove exact core count
> expecatation from the driver.
>
> Signed-off-by: Tanmay Shah
> ---
>
> Changes in v3:
> - Fix commit mess
On Tue, Jun 17, 2025 at 04:34:47PM -0300, Hiago De Franco wrote:
> From: Hiago De Franco
>
> This patch series depends on Ulf's patches that are currently under
> review, "pmdomain: Add generic ->sync_state() support to genpd" [1].
> Without them, this series is not going to work.
Please resend
On Tue, Jun 17, 2025 at 04:34:50PM -0300, Hiago De Franco wrote:
> From: Hiago De Franco
>
> When the remote core is started before Linux boots (e.g., by the
> bootloader), the driver currently is not able to attach because it only
> checks for cores running in different partitions. If the core w
Hi Hiago,
On Tue, Jun 17, 2025 at 04:34:49PM -0300, Hiago De Franco wrote:
> From: Hiago De Franco
>
> For the i.MX8X and i.MX8 family SoCs, when the M-core is powered up
> by the bootloader, M-core and Linux are in same SCFW (System Controller
> Firmware) partition, so linux has permission to c
Good day,
On Wed, Jun 18, 2025 at 02:26:43PM +0800, Shengjiu Wang wrote:
> when recovery is triggered, rproc_stop() is called first then
> rproc_start(), but there is no rproc_unprepare_device() and
> rproc_prepare_device() in the flow.
>
> So power enablement needs to be moved from prepare callb
Good day,
On Tue, Jun 10, 2025 at 12:27:38PM -0700, Tanmay Shah wrote:
> It's a valid use case to have only one core enabled in cluster in split
> mode. Remove exact core count expecatation from the driver.
I suggest:
"When operating in split mode, it is a valid usecase to have only one core
ena
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
Good morning,
On Tue, Jun 03, 2025 at 12:08:04PM +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 the secure part, this driver offers a client interface to load
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 determine who will continue
> revie
Good day,
On Fri, Jun 06, 2025 at 09:55:13AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> i.MX95 features a Cortex-M33 core, six Cortex-A55 cores, and
> one Cortex-M7 core. The System Control Management Interface(SCMI)
> firmware runs on the M33 core. The i.MX95 SCMI firmware named System
>
Good day,
On Wed, May 21, 2025 at 10:24:03PM +0800, Wentao Liang wrote:
> In mt8195_scp_c1_irq_handler(), only the IPC interrupt bit
> (MT8192_SCP_IPC_INT_BIT) was checked., but does not handle
> when this bit is not set. This could lead to unhandled watchdog
> events. This could lead to unhandled
On Tue, May 13, 2025 at 11:14:34AM +0530, Beleswar Padhi wrote:
> This series refactors a lot of functions & callbacks from
> ti_k3_dsp_remoteproc.c, ti_k3_r5_remoteproc.c and ti_k3_m4_remoteproc.c
> drivers. This is a consolidated and final series as part of the
> refactoring of K3 remoteproc driv
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
> > >
On Tue, May 13, 2025 at 11:14:38AM +0530, Beleswar Padhi wrote:
> The rproc_detach() function invokes __rproc_detach() before
> rproc_unprepare_device(). The __rproc_detach() function sets the
> rproc->state to "RPROC_DETACHED".
>
> However, the TI K3 M4 driver erroneously looks for "RPROC_ATTACHE
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("
On Tue, May 13, 2025 at 04:52:46PM +0100, 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 t
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
On Tue, May 06, 2025 at 09:59:44AM -0700, Tanmay Shah wrote:
> Powering off RPU using force_pwrdwn call results in system failure
> if there are multiple users of that RPU node. Better mechanism is to use
> request_node and release_node EEMI calls. With use of these EEMI calls,
> platform managemen
On Fri, Apr 25, 2025 at 04:11:00PM +0530, Beleswar Padhi wrote:
> This series refactors a lot of functions & callbacks from
> ti_k3_dsp_remoteproc.c, ti_k3_r5_remoteproc.c and ti_k3_m4_remoteproc.c
> drivers. This is a consolidated and final series as part of the
> refactoring of K3 remoteproc driv
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
On Fri, Apr 25, 2025 at 04:11:07PM +0530, Beleswar Padhi wrote:
> The ti_k3_r5_remoteproc.c driver previously hardcoded device memory
> region addresses and names. Change this to use the k3_r5_rproc_mem_data
> structure to store memory information. This aligns with K3 DSP and M4
> drivers, and can
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
On Wed, Apr 30, 2025 at 05:20:41PM +0800, Xiaolei Wang wrote:
> In the rproc_attach() function, if rproc_handle_resources() returns
> failure, the resources requested in imx_rproc_prepare() should be
> released, since almost the same thing is done in imx_rproc_prepare() and
> rproc_resource_cleanup
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 lot of functions
On Tue, 29 Apr 2025 at 04:46, Thorsten Blum wrote:
>
> kzalloc() already zero-initializes the destination buffer, making
> strscpy() sufficient for safely copying the name. The additional NUL-
> padding performed by strscpy_pad() is unnecessary.
>
> The size parameter is optional, and strscpy() au
On Mon, 28 Apr 2025 at 20:20, Xiaolei Wang wrote:
>
>
> On 4/26/25 14:53, Xiaolei Wang wrote:
> > When rproc->state = RPROC_DETACHED is attached to remote processor
> > through rproc_attach(), if rproc_handle_resources() returns failure,
> > then the clean table should be released, otherwise the f
Hi Xiaolei,
On Sat, Apr 26, 2025 at 02:53:47PM +0800, Xiaolei Wang wrote:
> When rproc->state = RPROC_DETACHED and rproc_attach() is used
> to attach to the remote processor, if rproc_handle_resources()
> returns a failure, the resources allocated by rproc_prepare_device()
> should be released, ot
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
On Thu, Apr 24, 2025 at 08:22:51PM +0800, Xiaolei Wang wrote:
> Release all carveouts under imx_rproc after rproc_attach() fails to solve
> the following kmemleak:
>
Please provide more details on the steps needed to reproduce this problem and
where in rproc_attach() the original failure occured.
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 regions, there's not anything
Good morning,
On Wed, Apr 23, 2025 at 12:51:31PM -0300, Hiago De Franco wrote:
> From: Hiago De Franco
>
> The "clocks" device tree property is not mandatory, and if not provided
> Linux will shut down the remote processor power domain during boot if it
> is not present, even if it is running (e
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
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 failure
> if there are multiple users of that RPU node. Better mechanism is to use
> request_node and release_node EEMI calls. With use of these EEMI calls,
> pla
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
> >>
&
1 - 100 of 1162 matches
Mail list logo
