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 access alig
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
Hello Daniel,
On Fri, Oct 18, 2024 at 02:09:29PM +0300, Daniel Baluta wrote:
> Currently we generate notifyids in the linux kernel and override
> those found in rsc_table.
>
> This doesn't play well with users expecting to use the exact ids
> from rsc_table.
>
> So, use predefined notifyids foun
On Wed, Oct 09, 2024 at 10:01:08AM +0200, Arnaud Pouliquen wrote:
> The new TEE remoteproc driver is used to manage remote firmware in a
> secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
> introduced to delegate the loading of the firmware to the trusted
> execution context. In s
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
Hi Mukesh,
On Wed, Oct 16, 2024 at 10:25:46AM +0530, Mukesh Ojha wrote:
> Multiple call to glink_subdev_stop() for the same remoteproc can happen
> if rproc_stop() fails from Process-A that leaves the rproc state to
> RPROC_CRASHED state later a call to recovery_store from user space in
> Process
On Wed, Oct 16, 2024 at 11:41:39AM -0500, Andrew Davis wrote:
> 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...@ke
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:
> > >
On Fri, Oct 11, 2024 at 03:09:08PM +0200, Krzysztof Kozlowski wrote:
> Simplify drivers in few places around probe function.
>
> Best regards,
> Krzysztof
>
> ---
> Krzysztof Kozlowski (10):
> remoteproc: da8xx: Handle deferred probe
> remoteproc: da8xx: Simplify with dev_err_probe()
Good morning Richard,
On Fri, Oct 11, 2024 at 02:39:22PM +0200, Richard Weinberger wrote:
> Texas Instruments ships a patch in their vendor kernels,
> which adds a new NS message that includes a description field.
> While TI is free to do whatever they want in their copy of the kernel,
> it become
Hi Arnd,
On Mon, Oct 07, 2024 at 01:23:57PM +, 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_
>From hereon and starting with this version, I will not review patchets that
don't pass the compilation bots.
Mathieu
On Tue, Oct 08, 2024 at 07:07:40PM +0800, kernel test robot wrote:
> Hi Arnaud,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on 9852d
On Mon, Oct 07, 2024 at 01:23:57PM +, 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
On Tue, 1 Oct 2024 at 07:35, Jason Gunthorpe wrote:
>
> On Mon, Sep 30, 2024 at 10:40:30AM -0600, Mathieu Poirier wrote:
> > 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
> > >
On Fri, Sep 27, 2024 at 02:51:38AM +, Mark-PK Tsai (蔡沛剛) wrote:
> Hi,
>
> Could someone help to review it or provide suggestions?
> Any comments are welcome.
>
> This patch is intended to allow the rproc driver to handle the
> following use-after-free issue:
>
>
> ### UAF log
What does "UA
On Tue, Sep 24, 2024 at 02:43:40PM +0200, 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 fu
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.
>
> Use iommu_paging_domain_alloc() to make it explicit.
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Jason Gunthorpe
> Lin
On Tue, Sep 24, 2024 at 12:52:42PM -0700, Linus Torvalds wrote:
> On Tue, 24 Sept 2024 at 12:31, Linus Torvalds
> wrote:
> >
> > It's in my tree now, but please fix asap.
>
> Argh, now that I noticed it, I can no longer unsee it.
>
> So I did this
>
> - depends on ARCH_K3 || COMPILE_TEST
On Wed, Sep 18, 2024 at 04:43:32PM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 8/30/24 11:51, Arnaud Pouliquen wrote:
> > Add support for releasing remote processor firmware through
> > the Trusted Execution Environment (TEE) interface.
> >
> > The tee_rproc_release_fw() function is ca
On Tue, Sep 17, 2024 at 06:56:58PM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 9/12/24 17:26, Mathieu Poirier wrote:
> > On Fri, Aug 30, 2024 at 11:51:44AM +0200, Arnaud Pouliquen wrote:
> >> Add support for releasing remote processor firmware through
&g
On Tue, 17 Sept 2024 at 03:13, Kumar, Udit wrote:
>
> Hi Mathieu,
>
> On 9/17/2024 2:07 PM, 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 0
s
On Tue, 17 Sept 2024 at 03:40, Beleswar Prasad Padhi wrote:
>
> 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
On Wed, 18 Sept 2024 at 09:40, Abdellatif El Khlifi
wrote:
>
> Hi Mathieu,
>
> > Introduce remoteproc support for Corstone-1000 external systems
> >
> > The Corstone-1000 IoT Reference Design Platform supports up to two
> > external systems processors. These processors can be switched on or off
>
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
> >>
On Sun, 15 Sept 2024 at 08:09, Jason Gunthorpe wrote:
>
> On Thu, Aug 22, 2024 at 01:24:25PM -0300, Jason Gunthorpe wrote:
> > On Thu, Aug 22, 2024 at 10:17:56AM -0600, Mathieu Poirier wrote:
> >
> > > > - domain = iommu_domain_alloc(dev->bus);
> >
On Mon, 16 Sept 2024 at 02:31, Siddharth Vadapalli 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, causing them to exit if the remote core's
> state is
Hi Valentina,
On Thu, 12 Sept 2024 at 10:48, Valentina Fernandez
wrote:
>
> Hello all,
>
> This series adds support for the Microchip Inter-Processor Communication
> (IPC) mailbox controller, as well as an IPC remoteproc platform driver.
>
> Microchip's family of RISC-V SoCs typically has one or
On Fri, Aug 30, 2024 at 11:51:47AM +0200, Arnaud Pouliquen wrote:
> The new TEE remoteproc driver is used to manage remote firmware in a
> secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
> introduced to delegate the loading of the firmware to the trusted
> execution context. In s
On Fri, Aug 30, 2024 at 11:51:42AM +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
Hi Valentina,
On Thu, 12 Sept 2024 at 10:48, Valentina Fernandez
wrote:
>
> Hello all,
>
> This series adds support for the Microchip Inter-Processor Communication
> (IPC) mailbox controller, as well as an IPC remoteproc platform driver.
>
> Microchip's family of RISC-V SoCs typically has one or
On Fri, Aug 30, 2024 at 11:51:46AM +0200, Arnaud Pouliquen wrote:
> To prepare for the support of TEE remoteproc, create sub-functions
> that can be used in both cases, with and without remoteproc TEE support.
>
> Signed-off-by: Arnaud Pouliquen
> ---
> drivers/remoteproc/stm32_rproc.c | 84
On Fri, Aug 30, 2024 at 11:51:44AM +0200, Arnaud Pouliquen wrote:
> Add support for releasing remote processor firmware through
> the Trusted Execution Environment (TEE) interface.
>
> The tee_rproc_release_fw() function is called in the following cases:
>
> - An error occurs in rproc_start() bet
On Fri, Aug 30, 2024 at 11:51:44AM +0200, Arnaud Pouliquen wrote:
> Add support for releasing remote processor firmware through
> the Trusted Execution Environment (TEE) interface.
>
> The tee_rproc_release_fw() function is called in the following cases:
>
> - An error occurs in rproc_start() bet
On Fri, Aug 30, 2024 at 11:51:42AM +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
On Fri, Aug 30, 2024 at 11:51:43AM +0200, Arnaud Pouliquen wrote:
> This patch centralizing the cleanup of the resource table into a new
> helper function rproc_release_fw().
>
Sure, but you did not explain _why_ the change is needed.
> Suggested-by: Mathieu Poirier
> Signed
On Fri, Aug 30, 2024 at 11:51:42AM +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
On Sat, Sep 07, 2024 at 08:33:36AM +0200, Christophe JAILLET wrote:
> If an error occurs after the k3_dsp_rproc_request_mbox() call,
> mbox_free_channel() must be called, as already done in the remove function.
>
> Instead of adding an error handling path in the probe and changing all
> error hand
ixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F
> subsystem")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/mailbox/Kconfig | 2 +-
> drivers/mailbox/omap-mailbox.c | 2 +-
> drivers/remoteproc/Kconfig | 10 --
For the remot
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_boot(). This causes unexpected
If you are looking at rp
ence sending email form
> different email
> client and so not formatted as expected. This will be fixed soon (before
> sending anymore patches).
>
> Thanks,
> Tanmay
>
> On 9/4/24, 11:21 AM, "Mathieu Poirier" <mailto:mathieu.poir...@linaro.org>> wrote
On Thu, Sep 05, 2024 at 02:54:17AM +0800, Liu Jing wrote:
> devm_ioremap_resource already contains error message, so remove
> the redundant dev_err message
>
> Signed-off-by: Liu Jing
>
> diff --git a/drivers/remoteproc/da8xx_remoteproc.c
> b/drivers/remoteproc/da8xx_remoteproc.c
> index 9041a0
Good morning,
On Fri, Aug 30, 2024 at 10:37:36AM -0700, Tanmay Shah wrote:
> AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
> R5 cores can access OCM and access is faster than DDR memory but slower
> than TCM memories available. Sram region can have optional multiple
> power-domain
Hi,
There are several other instances such as these in the remoteproc subsystem.
Please send another revision that is addressing them all.
Thanks,
Mathieu
On Wed, Sep 04, 2024 at 10:09:49AM +0800, Liu Jing wrote:
> devm_ioremap_resource already contains error message, so remove
> the redundant d
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: can not start core 1 before core
On Thu, Aug 22, 2024 at 10:52:40AM +0530, 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 violat
Good morning,
First and foremost the overall structure of your code has improved immensely and
I commend you for that.
On Mon, Aug 19, 2024 at 10:09:38AM -0700, Tanmay Shah wrote:
> AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
> R5 cores can access OCM and access is faster than
On Thu, Aug 22, 2024 at 09:48:48PM +0800, Peng Fan (OSS) wrote:
> The i.MX7ULP Cortex-A7 is under control of Cortex-M4. The i.MX7ULP Linux
> poweroff and restart rely on rpmsg driver to send a message to Cortex-M4
> firmware. Then Cortex-A7 could poweroff or restart by Cortex-M4 to
> configure the
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.
>
> Use iommu_paging_domain_alloc() to make it explic
On Mon, Aug 19, 2024 at 10:54:11AM -0500, Andrew Davis wrote:
> On 8/19/24 10:39 AM, Krzysztof Kozlowski wrote:
> > On 19/08/2024 17:32, Mathieu Poirier wrote:
> >
> > > > > > Please remove.
> > > > > Forget this comment
On Wed, 21 Aug 2024 at 02:32, Daniel Baluta wrote:
>
> Hello Mathieu,
>
> I've talked to Peng and if my understanding is correct I think the patch is
> OK.
> Maybe we can split the patch in two:
> * first, adding the power off callback with explanations.
> * second, adding the restart callback wi
On Fri, Aug 09, 2024 at 11:31:32AM +0530, 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 an
Hey Vignesh.
On Mon, Aug 19, 2024 at 02:02:31PM +0530, Vignesh Raghavendra wrote:
> [...]
>
> Hi Mathieu
>
> On 16/08/24 20:06, Mathieu Poirier wrote:
> >>> +/*
> >>> + * Attach to a running M4 remote processor (IPC-only mode)
> >>> + *
> &g
On Fri, Aug 16, 2024 at 01:23:59PM +0530, Beleswar Prasad Padhi wrote:
> 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 prob
On Thu, Aug 15, 2024 at 10:46:41AM -0600, Mathieu Poirier wrote:
> Hi,
>
> On Fri, Aug 02, 2024 at 10:21:03AM -0500, Andrew Davis wrote:
> > From: Martyn Welch
> >
> > The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
> > the MCU domain
Hi,
On Fri, Aug 02, 2024 at 10:21:03AM -0500, Andrew Davis wrote:
> From: Martyn Welch
>
> The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
> the MCU domain. This core is typically used for safety applications in a
> stand alone mode. However, some application (non safety re
On Thu, Aug 08, 2024 at 01:11:27PM +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 mbox handle later during rproc start/attach. This also
> allows to defer remo
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 mbox handle later during rproc start/attach. This also
> allows
On Fri, Aug 02, 2024 at 04:59:45AM +, Peng Fan wrote:
> > Subject: Re: [PATCH v2 2/2] remoteproc: imx_rproc: handle system off
> > for i.MX7ULP
> >
> > On Tue, Jul 30, 2024 at 08:06:22AM +, Peng Fan wrote:
> > > > Subject: Re: [PATCH v2 2/2] remoteproc: imx_rproc: handle system
> > off
> >
On Thu, Aug 08, 2024 at 02:56:20AM +, Peng Fan wrote:
> > Subject: Re: [PATCH 6/6] remoteproc: imx_rproc: handle system off for
> > i.MX7ULP
> >
> > On Fri, Jul 12, 2024 at 04:34:59PM +0800, Peng Fan (OSS) wrote:
> > > From: Peng Fan
> > >
> > > The i.MX7ULP Cortex-A7 is under control of Cort
On Fri, Aug 02, 2024 at 01:22:56PM -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/keystone_remoteproc.c | 17 ++---
> 1 file ch
On Sun, Aug 11, 2024 at 05:34:38PM +0200, Krzysztof Kozlowski wrote:
> All nodes need an explicit additionalProperties or unevaluatedProperties
> unless a $ref has one that's false. Add missing additionalProperties
> to fix dt_binding_check warning:
>
> xlnx,zynqmp-r5fss.yaml: ^r(.*)@[0-9a-f]+$
On Wed, Jul 31, 2024 at 01:12:45PM -0600, Rob Herring (Arm) wrote:
> Use of_property_present() to test for property presence rather than
> of_(find|get)_property(). This is part of a larger effort to remove
> callers of of_find_property() and similar functions. of_find_property()
> leaks the DT str
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 "rpmsg-raw", but the module alias is "rpmsg_chrdev".
On Tue, Jul 30, 2024 at 08:06:22AM +, Peng Fan wrote:
> > Subject: Re: [PATCH v2 2/2] remoteproc: imx_rproc: handle system off
> > for i.MX7ULP
> >
> > On Fri, Jul 19, 2024 at 04:49:04PM +0800, Peng Fan (OSS) wrote:
> > > From: Peng Fan
> > >
> > > The i.MX7ULP Cortex-A7 is under control of C
On Fri, Jul 19, 2024 at 04:49:04PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> The i.MX7ULP Cortex-A7 is under control of Cortex-M4. The i.MX7ULP Linux
> poweroff and restart rely on rpmsg driver to send a message to Cortex-M4
> firmware. Then Cortex-A7 could poweroff or restart by Cortex-M
On Fri, Jul 19, 2024 at 04:36:10PM +0800, Peng Fan (OSS) wrote:
> This patchset is to upstream a few patches that in NXP downstream for
> quite sometime. For patches directly cherry-picked from NXP downstream,
> I keep the R-b tags.
>
> Patch 1 is a minor fix to DDR alias.
> Patch 2 was sent out b
On Wed, 24 Jul 2024 at 16:04, Tanmay Shah wrote:
>
> Hello Mathieu,
>
> Thanks for reviews.
>
> All the comments looks good, I will send next revision addressing them all.
>
> On 7/22/24 11:39 AM, Mathieu Poirier wrote:
> > Good morning,
> >
> > On Mon
Good morning,
On Mon, Jul 15, 2024 at 06:39:54PM -0700, Tanmay Shah wrote:
> AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
> R5 cores can access OCM and access is faster than DDR memory but slower
> than TCM memories available. Sram region can have optional multiple
> power-domain
On Tue, Jul 16, 2024 at 06:49:39PM +0300, Iuliana Prodan wrote:
> Hi Mathieu,
>
> On 7/16/2024 6:16 PM, Mathieu Poirier wrote:
> > Good morning,
> >
> > On Fri, Jul 12, 2024 at 04:34:54PM +0800, Peng Fan (OSS) wrote:
> > > From: Peng Fan
> > >
>
On Fri, Jul 12, 2024 at 04:34:59PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> The i.MX7ULP Cortex-A7 is under control of Cortex-M4. The i.MX7ULP Linux
> poweroff and restart rely on rpmsg driver to send a message to Cortex-M4
> firmware. Then Cortex-A7 could poweroff or restart by Cortex-M
On Fri, Jul 12, 2024 at 04:34:58PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> Current tx_block is set to true, but there is case that no need to wait
> response. Linux just needs to send data to remote processor, so let's
> allow tx_block could be set to false.
Ok, maybe - but this patch
On Fri, Jul 12, 2024 at 04:34:57PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> Merge contiguous TCML/U regions into one to avoid load elf files which
> has large sections failure.
>
> Signed-off-by: Peng Fan
> ---
> drivers/remoteproc/imx_rproc.c | 18 ++
> 1 file changed
On Fri, Jul 12, 2024 at 04:34:56PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> Initialize workqueue before requesting mailbox channel, otherwise if
> mailbox interrupt comes before workqueue ready, the imx_rproc_rx_callback
> will trigger issue.
>
> Reviewed-by: Richard Zhu
All reviews s
Good morning,
On Fri, Jul 12, 2024 at 04:34:54PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> The DDR Alias address should be 0x4000 according to RM, so correct
> it.
>
> Fixes: 4ab8f9607aad ("remoteproc: imx_rproc: support i.MX8MQ/M")
This commit was merged more than 3 years ago...
On Wed, 10 Jul 2024 at 02:42, Shun-yi Wang wrote:
>
> From: "shun-yi.wang"
>
> In order to reserve specific Contiguous Memory Allocator (CMA) regions
> for hardware use. When the name of the reserved region contains "cma",
> then a corresponding CMA heap is added.
>
> Signed-off-by: shun-yi.wang
On Wed, Jul 03, 2024 at 07:53:08PM +0800, Shun-yi Wang wrote:
> From: "shun-yi.wang"
>
> SCP supports multiple reserved memory regions, intended for
> specific hardwards.
>
> Signed-off-by: shun-yi.wang
> ---
> drivers/remoteproc/mtk_scp.c | 25 +
> 1 file changed, 17 in
Good morning,
On Wed, Jul 03, 2024 at 07:53:07PM +0800, Shun-yi Wang wrote:
> From: "shun-yi.wang"
>
> Besides the reserved memory region for SCP, there are additional
> reserved memory regions for specific hardware use.
> Currently, only a single memory region is supported.
> Modifications are
1 ("virtio-balloon: add support for providing free page
> reports to host")
> Cc: "Alexander Duyck"
> Signed-off-by: Michael S. Tsirkin
> ---
> arch/um/drivers/virtio_uml.c | 4 ++--
> drivers/remoteproc/remoteproc_virtio.c | 4 ++--
Reviewed-b
On Wed, Jul 03, 2024 at 11:05:59AM +0200, AngeloGioacchino Del Regno wrote:
> Il 03/07/24 05:44, Jason Chen ha scritto:
> > The current DRAM size is insufficient for the HEVC feature, which
> > requires more memory for proper functionality. This change ensures the
> > feature has the necessary reso
On Fri, Jul 05, 2024 at 09:33:55AM +0200, Arnaud POULIQUEN wrote:
>
>
> On 7/4/24 17:32, Mathieu Poirier wrote:
> > On Thu, Jul 04, 2024 at 10:05:24AM +0200, Arnaud POULIQUEN wrote:
> >>
> >>
> >> On 7/3/24 17:14, Mathieu Poirier wrote:
> >>
On Thu, Jun 27, 2024 at 10:29:38AM -0700, Tanmay Shah wrote:
> It is possible that remote processor is already running before
> linux boot or remoteproc platform driver probe. Implement required
> remoteproc framework ops to provide resource table address and
> connect or disconnect with remote pro
On Wed, Jun 26, 2024 at 12:14:38PM -0700, Garrett Giordano wrote:
> Driver was logging information as errors. Changed dev_err to dev_dbg
> where appropriate.
>
> Signed-off-by: Garrett Giordano
> ---
> -v2
> - Change from dev_info to dev_dbg
> - Drop k3-r5 PATCH
> ---
> drivers/remoteproc/ti
On Thu, Jul 04, 2024 at 10:05:24AM +0200, Arnaud POULIQUEN wrote:
>
>
> On 7/3/24 17:14, Mathieu Poirier wrote:
> > On Wed, Jul 03, 2024 at 09:19:44AM +0200, Arnaud POULIQUEN wrote:
> >> Hello Mathieu
> >>
> >> On 7/2/24 18:44, Mathieu Poirier wrote:
&
On Fri, Jun 21, 2024 at 04:37:56PM +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
On Wed, Jul 03, 2024 at 09:19:44AM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu
>
> On 7/2/24 18:44, Mathieu Poirier wrote:
> > Good morning,
> >
> > On Fri, Jun 21, 2024 at 04:37:56PM +0200, Arnaud Pouliquen wrote:
> >> Add a remoteproc TEE (Trusted Exe
On Fri, Jun 21, 2024 at 04:37:59PM +0200, Arnaud Pouliquen wrote:
> The new TEE remoteproc device is used to manage remote firmware in a
Device or driver?
> secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
> introduced to delegate the loading of the firmware to the trusted
> exe
Good morning,
On Fri, Jun 21, 2024 at 04:37:56PM +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
On Mon, Jul 01, 2024 at 04:13:00AM -0500, Hari Nagalla wrote:
> On 6/28/24 14:58, Mathieu Poirier wrote:
> > > This could lead in an incorrect IPC-only mode detection if reset line is
> > > asserted (so reset_control_status() return > 0) and c_state != 0 and
> > >
On Mon, Jul 01, 2024 at 10:03:22AM +0200, Richard GENOUD wrote:
> Le 28/06/2024 à 23:18, Mathieu Poirier a écrit :
> > On Fri, Jun 21, 2024 at 05:00:57PM +0200, Richard Genoud wrote:
> > > In the next commit, a RP_MBOX_SHUTDOWN message will be sent in
> > > k3_r5_rpro
On Fri, 21 Jun 2024 at 09:01, Richard Genoud wrote:
>
> This series enables the suspend to ram with R5F remote processors on TI K3
> platform.
>
> The 1st patch is actually a fix, independent from the others
>
> The 2nd patch introduces the suspend/resume handlers.
> On suspend, the running rprocs
On Fri, Jun 21, 2024 at 05:00:58PM +0200, 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 rem
On Fri, Jun 21, 2024 at 05:00:57PM +0200, Richard Genoud wrote:
> In the next commit, a RP_MBOX_SHUTDOWN message will be sent in
> k3_r5_rproc_stop() to the remote proc (in lockstep on not)
> Thus, the sanity check "do not allow core 0 to stop before core 1"
> should be moved at the beginning of th
On Fri, Jun 21, 2024 at 05:00:56PM +0200, Richard Genoud wrote:
> This patch adds the support for system suspend/resume to the ti_k3_R5
> remoteproc driver.
>
> In order to save maximum power, the approach here is to shutdown
> completely the cores that were started by the kernel (i.e. those in
>
Nishanth, Vignesh, Hari and Andrew - please have a look at this patch.
Thanks,
Mathieu
On Fri, 28 Jun 2024 at 13:53, Mathieu Poirier
wrote:
>
> Good day,
>
> On Fri, Jun 21, 2024 at 05:00:55PM +0200, Richard Genoud wrote:
> > ret variable was used to test rese
Good day,
On Fri, Jun 21, 2024 at 05:00:55PM +0200, Richard Genoud wrote:
> ret variable was used to test reset status, get from
> reset_control_status() call. But this variable was overwritten by
> ti_sci_proc_get_status() a few lines bellow.
> And as ti_sci_proc_get_status() returns 0 or a negat
On Thu, Jun 27, 2024 at 05:20:55PM -0400, Nícolas F. R. A. Prado wrote:
> The current code doesn't check whether platform_get_resource_byname()
> succeeded to get the l1tcm memory, which is optional, before attempting
> to map it. This results in the following error message when it is
> missing:
>
1 - 100 of 1028 matches
Mail list logo
