On Wed, May 22, 2024 at 09:36:26AM -0500, Tanmay Shah wrote:
>
>
> On 5/21/24 12:56 PM, Mathieu Poirier wrote:
> > Hi Tanmay,
> >
> > On Fri, May 10, 2024 at 05:51:25PM -0700, Tanmay Shah wrote:
> >> It is possible that remote processor is already running
Hi Tanmay,
On Fri, May 10, 2024 at 05:51:25PM -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
On Fri, May 17, 2024 at 06:56:54PM +0200, Arnaud Pouliquen wrote:
> Add missing @ tags for some rpmsg_eptdev structure parameters.
>
> This fixes warning messages on build:
> drivers/rpmsg/rpmsg_char.c:75: warning: Function parameter or struct member
> 'remote_flow_restricted' not described in
On Mon, May 20, 2024 at 01:27:24PM +0200, AngeloGioacchino Del Regno wrote:
> In scp_ipi_handler(), instead of zeroing out the entire shared
> buffer, which may be as large as 600 bytes, overwrite it with the
> received data, then zero out only the remaining bytes.
>
> Signed-off-by:
On Sat, 18 May 2024 at 04:44, Christophe JAILLET
wrote:
>
> Le 30/04/2024 à 12:53, Beleswar Padhi a écrit :
> > PSC controller has a limitation that it can only power-up the second
> > core when the first core is in ON state. Power-state for core0 should be
> > equal to or higher than core1.
> >
On Thu, May 09, 2024 at 10:54:51AM -0500, Andrew Davis wrote:
> On 5/9/24 10:22 AM, Mathieu Poirier wrote:
> > On Wed, 8 May 2024 at 09:36, Andrew Davis wrote:
> > >
> > > On 5/6/24 3:46 PM, Mathieu Poirier wrote:
> > > > Good day,
> > > &
On Wed, 8 May 2024 at 10:54, Andrew Davis wrote:
>
> On 5/7/24 3:36 PM, Mathieu Poirier wrote:
> > On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
> >> From: Martyn Welch
> >>
> >> The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F
On Wed, 8 May 2024 at 09:36, Andrew Davis wrote:
>
> On 5/6/24 3:46 PM, Mathieu Poirier wrote:
> > Good day,
> >
> > I have started reviewing this patchset. Comments will be scattered over
> > multiple days and as such, I will explicitly inform you when am
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
> From: Martyn Welch
>
> The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
> the MCU domain. This core is typically used for safety applications in a
> stand alone mode. However, some application (non safety
Good day,
I have started reviewing this patchset. Comments will be scattered over
multiple days and as such, I will explicitly inform you when am done with the
review.
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
> From: Martyn Welch
>
> The AM62x and AM64x SoCs of the TI K3
On Mon, May 06, 2024 at 07:48:49PM +0530, Beleswar Padhi wrote:
> In case of errors during core start operation from sysfs, the driver
> directly returns with the -EPERM error code. Fix this to ensure that
> mailbox channels are freed on error before returning by jumping to the
> 'put_mbox' error
On Tue, Apr 30, 2024 at 04:23:05PM +0530, Beleswar Padhi wrote:
> PSC controller has a limitation that it can only power-up the second core
> when the first core is in ON state. Power-state for core0 should be equal
> to or higher than core1, else the kernel is seen hanging during rproc
> loading.
On Tue, Apr 30, 2024 at 09:15:30AM +0800, Olivia Wen wrote:
> Change in v4:
> Updating the description of PATCH v4 4/4.
>
> Olivia Wen (4):
> dt-bindings: remoteproc: mediatek: Support MT8188 dual-core SCP
> remoteproc: mediatek: Support MT8188 SCP core 1
> remoteproc: mediatek: Support
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 state. Power-state for core0 should be equal
> to or higher than core1, else the kernel is
On Wed, Apr 24, 2024 at 12:04:54PM +0200, AngeloGioacchino Del Regno wrote:
> Il 24/04/24 12:02, AngeloGioacchino Del Regno ha scritto:
> > Il 24/04/24 05:03, Olivia Wen ha scritto:
> > > Integrate the imgsys core architecture driver for image processing on
> > > the MT8188 platform.
> > >
> > >
On Tue, Apr 23, 2024 at 10:02:11AM -0700, Tanmay Shah wrote:
> Fix following warning for clang compiler with W=1 option:
> initialize the variable 'ret' to silence this warning
> 907 | int ret, i;
> |^
> | = 0
>
> Fixes: a6b974b40f94
On Thu, Apr 18, 2024 at 03:01:25PM -0700, Tanmay Shah wrote:
> AMD-Xilinx Versal platform is successor of ZynqMP platform.
> Real-time Processing Unit R5 cluster IP on Versal is same as
> of ZynqMP Platform. Power-domains ids for Versal platform is
> different than ZynqMP.
>
> AMD-Xilinx
Hi Olivia,
On Fri, Apr 19, 2024 at 04:42:11PM +0800, Olivia Wen wrote:
> From: "olivia.wen"
>
> There are three primary modifications.
>
> 1. The struct mtk_scp_of_data usage on MT8188
> MT8192 functions are unsuitable for the dual-core MT8188 SCP,
> which has two RISC-V cores similar to
On Fri, Apr 12, 2024 at 11:37:04AM -0700, Tanmay Shah wrote:
> Tightly-Coupled Memories(TCMs) are low-latency memory that provides
> predictable instruction execution and predictable data load/store
> timing. Each Cortex-R5F processor contains exclusive two 64 KB memory
> banks on the ATCM and
gt;
> Signed-off-by: Tanmay Shah
> ---
> .../boot/dts/xilinx/zynqmp-zcu102-rev1.0.dts | 8 +++
> arch/arm64/boot/dts/xilinx/zynqmp.dtsi| 67 +--
> 2 files changed, 70 insertions(+), 5 deletions(-)
>
Reviewed-by: Mathieu Poirier
> diff --git a/arch/ar
On Wed, Apr 10, 2024 at 05:36:30PM -0500, Tanmay Shah wrote:
>
>
> On 4/10/24 11:59 AM, Mathieu Poirier wrote:
> > On Mon, Apr 08, 2024 at 01:53:14PM -0700, Tanmay Shah wrote:
> >> ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
> >> is av
On Mon, Apr 08, 2024 at 01:53:14PM -0700, Tanmay Shah wrote:
> ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
> is available in device-tree. Parse TCM information in driver
> as per new bindings.
>
> Signed-off-by: Tanmay Shah
> ---
>
> Changes in v14:
> - Add Versal
On Tue, 2 Apr 2024 at 03:56, AngeloGioacchino Del Regno
wrote:
>
> Il 28/03/24 15:38, Mathieu Poirier ha scritto:
> > On Wed, Mar 27, 2024 at 01:49:58PM +0100, AngeloGioacchino Del Regno wrote:
> >> Il 21/03/24 16:27, Mathieu Poirier ha scritto:
> >>> On Thu,
On Thu, Mar 28, 2024 at 11:26:24AM -0500, Andrew Davis wrote:
> On 3/28/24 10:28 AM, Mathieu Poirier wrote:
> > Hi Andrew,
> >
> > On Mon, Mar 25, 2024 at 11:58:06AM -0500, Andrew Davis wrote:
> > > The type of message sent using omap-mailbox is always u32. The
On Fri, Mar 29, 2024 at 09:58:11AM +0100, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 3/27/24 18:07, Mathieu Poirier wrote:
> > On Tue, Mar 26, 2024 at 08:18:23PM +0100, Arnaud POULIQUEN wrote:
> >> Hello Mathieu,
> >>
> >> On 3/25/24 17:46, Mathieu
On Fri, Mar 29, 2024 at 11:57:43AM +0100, Arnaud POULIQUEN wrote:
>
>
> On 3/27/24 18:14, Mathieu Poirier wrote:
> > On Tue, Mar 26, 2024 at 08:31:33PM +0100, Arnaud POULIQUEN wrote:
> >>
> >>
> >> On 3/25/24 17:51, Mathieu Poirier wrote:
> >>
Hi Andrew,
On Mon, Mar 25, 2024 at 11:58:06AM -0500, Andrew Davis wrote:
> The type of message sent using omap-mailbox is always u32. The definition
> of mbox_msg_t is uintptr_t which is wrong as that type changes based on
> the architecture (32bit vs 64bit). Use u32 unconditionally and remove
>
On Wed, Mar 27, 2024 at 01:49:58PM +0100, AngeloGioacchino Del Regno wrote:
> Il 21/03/24 16:27, Mathieu Poirier ha scritto:
> > On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
> > > When probing multi-core SCP, this driver is parsing all sub-node
On Tue, Mar 26, 2024 at 08:31:33PM +0100, Arnaud POULIQUEN wrote:
>
>
> On 3/25/24 17:51, Mathieu Poirier wrote:
> > On Fri, Mar 08, 2024 at 03:47:08PM +0100, Arnaud Pouliquen wrote:
> >> The new TEE remoteproc device is used to manage remote firmware in a
> >>
On Tue, Mar 26, 2024 at 08:18:23PM +0100, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 3/25/24 17:46, Mathieu Poirier wrote:
> > On Fri, Mar 08, 2024 at 03:47:05PM +0100, Arnaud Pouliquen wrote:
> >> Add a remoteproc TEE (Trusted Execution Environment) driver
On Mon, 25 Mar 2024 at 11:13, Abdellatif El Khlifi
wrote:
>
> Hi Mathieu,
>
> > > > > > > > > This is an initial patchset for allowing to turn on and off
> > > > > > > > > the remote processor.
> > > > > > > > > The FW is already loaded before the Corstone-1000 SoC is
> > > > > > > > > powered
On Fri, Mar 08, 2024 at 03:47:07PM +0100, Arnaud Pouliquen wrote:
> To prepare for the support of TEE remoteproc, create sub-functions
> that can be used in both cases, with and without TEE support.
>
> Signed-off-by: Arnaud Pouliquen
> ---
> drivers/remoteproc/stm32_rproc.c | 84
On Fri, Mar 08, 2024 at 03:47:08PM +0100, Arnaud Pouliquen wrote:
> The new TEE remoteproc device 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
On Fri, Mar 08, 2024 at 03:47:05PM +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 device offers a client
Device or driver? I thought I
On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
> When probing multi-core SCP, this driver is parsing all sub-nodes of
> the scp-cluster node, but one of those could be not an actual SCP core
> and that would make the entire SCP cluster to fail probing for no good
>
Good day,
On Thu, Mar 21, 2024 at 09:46:13AM +0100, AngeloGioacchino Del Regno wrote:
> The IPI buffer location is read from the firmware that we load to the
> System Companion Processor, and it's not granted that both the SRAM
> (L2TCM) size that is defined in the devicetree node is large enough
On Thu, 14 Mar 2024 at 08:59, Sudeep Holla wrote:
>
> On Thu, Mar 14, 2024 at 08:52:59AM -0600, Mathieu Poirier wrote:
> > On Wed, Mar 13, 2024 at 05:17:56PM +, Abdellatif El Khlifi wrote:
> > > Hi Mathieu,
> > >
> > > On Wed, Mar 13, 2024 at
On Wed, Mar 13, 2024 at 05:17:56PM +, Abdellatif El Khlifi wrote:
> Hi Mathieu,
>
> On Wed, Mar 13, 2024 at 10:25:32AM -0600, Mathieu Poirier wrote:
> > On Tue, Mar 12, 2024 at 05:32:52PM +, Abdellatif El Khlifi wrote:
> > > Hi Mathieu,
> > >
> &g
On Tue, Mar 12, 2024 at 05:32:52PM +, Abdellatif El Khlifi wrote:
> Hi Mathieu,
>
> On Tue, Mar 12, 2024 at 10:29:52AM -0600, Mathieu Poirier wrote:
> > > This is an initial patchset for allowing to turn on and off the remote
> > > processor.
> >
On Mon, 11 Mar 2024 at 05:44, Abdellatif El Khlifi
wrote:
>
> Hi Mathieu,
>
> On Fri, Mar 08, 2024 at 09:44:26AM -0700, Mathieu Poirier wrote:
> > On Thu, 7 Mar 2024 at 12:40, Abdellatif El Khlifi
> > wrote:
> > >
> > > Hi Mathieu,
> > >
> &g
Hi Ricardo,
On Tue, Mar 05, 2024 at 04:40:23PM -0300, Ricardo B. Marliere wrote:
> Since commit 43a7206b0963 ("driver core: class: make class_register() take
> a const *"), the driver core allows for struct class to be in read-only
> memory, so move the rproc_class structure to be declared at
On Thu, 7 Mar 2024 at 12:40, Abdellatif El Khlifi
wrote:
>
> Hi Mathieu,
>
> > > + do {
> > > + state_reg = readl(priv->reset_cfg.state_reg);
> > > + *rst_ack = EXTSYS_RST_ST_RST_ACK(state_reg);
> > > +
> > > + if (*rst_ack == EXTSYS_RST_ACK_RESERVED) {
> > > +
Good day Abdellatif,
On Fri, Mar 01, 2024 at 04:42:25PM +, abdellatif.elkhl...@arm.com wrote:
> From: Abdellatif El Khlifi
>
> introduce remoteproc support for Arm remote processors
>
> The supported remote processors are those that come with a reset
> control register and a reset status
Good morning,
On Wed, Feb 28, 2024 at 09:20:28AM +0100, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
>
> On 2/23/24 19:27, Mathieu Poirier wrote:
> > On Wed, Feb 14, 2024 at 06:21:21PM +0100, Arnaud Pouliquen wrote:
> >> From: Arnaud Pouliquen
> >>
> >
On Wed, 28 Feb 2024 at 12:24, Tanmay Shah wrote:
>
>
> On 2/28/24 11:08 AM, Mathieu Poirier wrote:
> > On Mon, Feb 19, 2024 at 09:44:34AM -0800, Tanmay Shah wrote:
> > > In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
> > > mode memory
On Mon, Feb 19, 2024 at 09:44:34AM -0800, Tanmay Shah wrote:
> In lockstep mode, r5 core0 uses TCM of R5 core1. Following is lockstep
> mode memory region as per hardware reference manual.
>
> | *TCM* | *R5 View* | *Linux view* |
> | R5_0 ATCM (128 KB) | 0x_ |
On Mon, Feb 19, 2024 at 09:44:37AM -0800, Tanmay Shah wrote:
> ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
> is available in device-tree. Parse TCM information in driver
> as per new bindings.
>
> Signed-off-by: Tanmay Shah
> ---
>
> Changes in v11:
> - Remove
Good day,
On Fri, Feb 16, 2024 at 03:29:56PM -0800, noman pouigt wrote:
> mailbox to dsp_1 is currently modeling platform pcm driver.
> mailbox to dsp_2 is also doing the same.
>
> Platform driver callbacks cause IPC to be sent to dsp's.
> Lifecycle of two dsp's are managed by separate
roc/ti,davinci-rproc.txt
> @@ -1,9 +1,6 @@
> TI Davinci DSP devices
> ===
>
> -Binding status: Unstable - Subject to changes for DT representation of clocks
> -and resets
> -
Reviewed-by: Mathieu Poirier
> The TI Davinci family of SoC
On Fri, Feb 23, 2024 at 02:54:13PM +0100, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 2/22/24 20:02, Mathieu Poirier wrote:
> > Hi,
> >
> > On Wed, Feb 14, 2024 at 06:21:27PM +0100, Arnaud Pouliquen wrote:
> >> The new TEE remoteproc device is used to man
On Wed, Feb 14, 2024 at 06:21:23PM +0100, Arnaud Pouliquen wrote:
> Add a check on the optional rproc->cached_table to perform the memory
> copy only if it is not null.
>
> 2 use cases to support:
> - starting on boot, in which case rproc->cached_table can be null,
> - starting on crash recovery,
On Wed, Feb 14, 2024 at 06:21:21PM +0100, Arnaud Pouliquen wrote:
> From: Arnaud Pouliquen
>
> 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 device offers a client
>
Hi,
On Wed, Feb 14, 2024 at 06:21:27PM +0100, Arnaud Pouliquen wrote:
> The new TEE remoteproc device 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
Good morning,
On Wed, Feb 14, 2024 at 06:21:21PM +0100, Arnaud Pouliquen wrote:
> From: Arnaud Pouliquen
>
> 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 device offers a
Good morning,
On Tue, Feb 13, 2024 at 09:54:50AM -0800, Tanmay Shah wrote:
> ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
> is available in device-tree. Parse TCM information in driver
> as per new bindings.
>
> Signed-off-by: Tanmay Shah
> ---
>
> Changes in v10:
>
On Tue, 13 Feb 2024 at 08:48, Arnaud POULIQUEN
wrote:
>
> Hello Mathieu,
>
> On 2/5/24 10:13, Arnaud POULIQUEN wrote:
> >
> >
> > On 2/2/24 20:53, Mathieu Poirier wrote:
> >> On Thu, Feb 01, 2024 at 07:33:35PM +0100, Arnaud POULIQUEN wrote:
> >>>
45 ++--
> 1 file changed, 12 insertions(+), 133 deletions(-)
>
I am happy with this patch but won't apply it because I want to see what comes
next. Please include it in your next patchet.
Reviewed-by: Mathieu Poirier
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.
On Sun, Feb 04, 2024 at 05:32:05PM -0300, Ricardo B. Marliere wrote:
> Now that the driver core can properly handle constant struct bus_type,
> move the rpmsg_bus variable to be a constant structure as well,
> placing it into read-only memory which can not be modified at runtime.
>
> Cc: Greg
On Mon, Feb 05, 2024 at 12:27:48PM -0600, Andrew Davis wrote:
> Hello all,
>
> This series uses various devm_ helpers to simplify the device
> removal path.
>
> Removing an unused var "ret1" got squashed into the wrong patch in
> the v1 series causing a bisectability error. v2 is based on -next
On Thu, Feb 01, 2024 at 07:33:35PM +0100, Arnaud POULIQUEN wrote:
>
>
> On 2/1/24 17:02, Mathieu Poirier wrote:
> > On Thu, Feb 01, 2024 at 04:06:37PM +0100, Arnaud POULIQUEN wrote:
> >> hello Mathieu,
> >>
> >> On 1/31/24 19:52, Mathieu Poirier wrote
On Tue, Jan 23, 2024 at 12:46:32PM -0600, 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
> ---
>
Hi Andrew,
On Tue, Jan 23, 2024 at 12:49:09PM -0600, Andrew Davis wrote:
> Use the device lifecycle managed TI-SCI get() function. This helps prevent
> mistakes like not put()'ing in the wrong order in cleanup functions and
> forgetting to put() on error paths.
>
> Signed-off-by: Andrew Davis
>
On Thu, Feb 01, 2024 at 04:06:37PM +0100, Arnaud POULIQUEN wrote:
> hello Mathieu,
>
> On 1/31/24 19:52, Mathieu Poirier wrote:
> > On Tue, Jan 30, 2024 at 10:13:48AM +0100, Arnaud POULIQUEN wrote:
> >>
> >>
> >> On 1/26/24 18:11, Mathieu Poirier wrote
On Tue, Jan 30, 2024 at 10:13:48AM +0100, Arnaud POULIQUEN wrote:
>
>
> On 1/26/24 18:11, Mathieu Poirier wrote:
> > On Thu, Jan 18, 2024 at 11:04:33AM +0100, Arnaud Pouliquen wrote:
> >> The new TEE remoteproc device is used to manage remote firmware in a
> >>
On Tue, Jan 30, 2024 at 02:47:07PM -0600, Tanmay Shah wrote:
>
> On 1/17/24 12:58 PM, Mathieu Poirier wrote:
> > Alright, I spent several hours looking at this patchset and the driver as a
> > whole. I certainly salute your efforts to heed my advice and make the code
&g
On Thu, Jan 18, 2024 at 11:04:30AM +0100, Arnaud Pouliquen wrote:
> From: Arnaud Pouliquen
>
> Add a remoteproc TEE (Trusted Execution Environment) device
> that will be probed by the TEE bus. If the associated Trusted
> application is supported on secure part this device offers a client
>
On Thu, Jan 18, 2024 at 11:04:30AM +0100, Arnaud Pouliquen wrote:
> From: Arnaud Pouliquen
>
> Add a remoteproc TEE (Trusted Execution Environment) device
> that will be probed by the TEE bus. If the associated Trusted
> application is supported on secure part this device offers a client
>
On Thu, Jan 18, 2024 at 11:04:33AM +0100, Arnaud Pouliquen wrote:
> The new TEE remoteproc device 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
On Fri, Jan 26, 2024 at 02:39:33PM +0100, Arnaud POULIQUEN wrote:
> Hi Mathieu,
>
> On 1/25/24 19:55, Mathieu Poirier wrote:
> > Hi Arnaud,
> >
> > On Thu, Jan 18, 2024 at 11:04:30AM +0100, Arnaud Pouliquen wrote:
> >> From: Arnaud Pouliquen
> >>
Hi Arnaud,
On Thu, Jan 18, 2024 at 11:04:30AM +0100, Arnaud Pouliquen wrote:
> From: Arnaud Pouliquen
>
> Add a remoteproc TEE (Trusted Execution Environment) device
Device or driver? Seems to be the latter...
> that will be probed by the TEE bus. If the associated Trusted
> application is
On Wed, Jan 17, 2024 at 02:53:10PM +0100, Arnaud Pouliquen wrote:
> Fix warnings reported by sparse using make option "C=1"
>
> Arnaud Pouliquen (2):
> remoteproc: stm32: Fix incorrect type in assignment for va
> remoteproc: stm32: Fix incorrect type assignment returned by
>
On Mon, Jan 22, 2024 at 01:02:08PM -0700, Mathieu Poirier wrote:
> On Mon, 22 Jan 2024 at 10:51, Iuliana Prodan wrote:
> >
> > On 1/5/2024 6:01 PM, Ulf Hansson wrote:
> > > Let's avoid the boilerplate code to manage the multiple PM domain case, by
> > > convertin
On Mon, 22 Jan 2024 at 10:51, Iuliana Prodan wrote:
>
> On 1/5/2024 6:01 PM, Ulf Hansson wrote:
> > Let's avoid the boilerplate code to manage the multiple PM domain case, by
> > converting into using dev_pm_domain_attach|detach_list().
> >
> > Cc: Mathieu Poirier
&
Alright, I spent several hours looking at this patchset and the driver as a
whole. I certainly salute your efforts to heed my advice and make the code less
brittle but I'm afraid we are not there.
See below for a different way to proceed.
On Wed, Jan 10, 2024 at 01:35:05PM -0800, Tanmay Shah
sztof Kozlowski
> ---
> Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 4 ++--
For the above:
Reviewed-by: Mathieu Poirier
> .../devicetree/bindings/remoteproc/qcom,qcs404-pas.yaml | 2 +-
> .../devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml | 2 +-
Hi Christophe,
On Sun, Jan 14, 2024 at 10:37:43AM +0100, Christophe JAILLET wrote:
> ida_alloc() and ida_free() should be preferred to the deprecated
> ida_simple_get() and ida_simple_remove().
>
> Note that the upper limit of ida_simple_get() is exclusive, but the one of
> ida_alloc_max() is
Hi Tanmay,
Thanks for the refactoring, this is in line with what Bjorn and I have talked
about at Plumbers. Please see my comments below.
On Wed, Jan 03, 2024 at 02:11:24PM -0800, Tanmay Shah wrote:
> From: Mathieu Poirier
>
> Multi-cluster remoteproc designs typically have the fol
Good day Joakim,
On Sun, Dec 17, 2023 at 01:36:59PM +0800, joakim.zh...@cixtech.com wrote:
> From: Joakim Zhang
>
> Recovery remote processor failed when wdg irq received:
> [0.842574] remoteproc remoteproc0: crash detected in cix-dsp-rproc: type
> watchdog
> [0.842750] remoteproc
On Thu, 4 Jan 2024 at 09:14, Tanmay Shah wrote:
>
>
> On 1/3/24 12:17 PM, Mathieu Poirier wrote:
> > On Fri, Dec 15, 2023 at 03:57:25PM -0800, Tanmay Shah wrote:
> > > ZynqMP TCM information is fixed in driver. Now ZynqMP TCM information
> >
> > s/"
On Fri, Dec 15, 2023 at 03:57:25PM -0800, Tanmay Shah wrote:
> ZynqMP TCM information is fixed in driver. Now ZynqMP TCM information
s/"is fixed in driver"/"was fixed in driver"
> is available in device-tree. Parse TCM information in driver
> as per new bindings.
>
> Signed-off-by: Tanmay Shah
Hi Tanmay,
On Fri, Dec 15, 2023 at 03:57:24PM -0800, Tanmay Shah wrote:
> Add properties as per new bindings in zynqmp remoteproc node
> to represent TCM address and size.
>
> This patch also adds alternative remoteproc node to represent
> remoteproc cluster in split mode. By default lockstep
On Wed, 3 Jan 2024 at 03:11, Ulf Hansson wrote:
>
> On Tue, 2 Jan 2024 at 19:41, Mathieu Poirier
> wrote:
> >
> > Hi Ulf,
> >
> > I'm in agreement with the modifications done to imx_rproc.c and
> > imx_dsp_rproc.c.
> > There is one thing I am am
On Wed, Dec 20, 2023 at 08:47:19AM -0600, Tanmay Shah wrote:
>
> On 11/14/23 10:23 AM, Mathieu Poirier wrote:
> > On Tue, 14 Nov 2023 at 08:22, Bjorn Andersson wrote:
> > >
> > > On Sat, Oct 14, 2023 at 04:15:47PM -0700, Tanmay Shah wrote:
> > > > Fr
erting into using dev_pm_domain_attach|detach_list().
>
> Cc: Mathieu Poirier
> Cc: Bjorn Andersson
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc:
> Signed-off-by: Ulf Hansson
> ---
> drivers/remoteproc/imx_rproc.c | 73 +-
> 1 file ch
On Wed, 20 Dec 2023 at 07:45, Tanmay Shah wrote:
>
>
> On 12/20/23 7:14 AM, Michal Simek wrote:
> >
> > On 12/16/23 00:57, Tanmay Shah wrote:
> > > Add properties as per new bindings in zynqmp remoteproc node
> > > to represent TCM address and size.
> > >
> > > This patch also adds alternative
On Fri, Dec 15, 2023 at 10:00:49AM +0800, Xiaolei Wang wrote:
> free driver_override when rpmsg_remove(), otherwise
> the following memory leak will occur:
>
> unreferenced object 0xd55d7080 (size 128):
> comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s)
> hex dump (first
On Wed, Dec 06, 2023 at 12:06:45PM -0600, Tanmay Shah wrote:
>
> On 12/6/23 9:43 AM, Mathieu Poirier wrote:
> > On Fri, 1 Dec 2023 at 11:10, Tanmay Shah wrote:
> > >
> > >
> > > On 11/29/23 11:10 AM, Mathieu Poirier wrote:
> > > > On Mon,
On Fri, 1 Dec 2023 at 11:10, Tanmay Shah wrote:
>
>
> On 11/29/23 11:10 AM, Mathieu Poirier wrote:
> > On Mon, Nov 27, 2023 at 10:33:05AM -0600, Tanmay Shah wrote:
> > >
> > > On 11/23/23 12:11 PM, Mathieu Poirier wrote:
> > > > On Wed, Nov 22
ulator/mps,mpq7920.yaml| 4 ++--
> .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 8
Reviewed-by: Mathieu Poirier
> 14 files changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
> b/D
On Wed, Nov 22, 2023 at 03:00:36PM -0600, Tanmay Shah wrote:
> Hi Mathieu,
>
> Please find my comments below.
>
> On 11/21/23 4:59 PM, Mathieu Poirier wrote:
> > Hi,
> >
> > On Fri, Nov 17, 2023 at 09:42:37AM -0800, Tanmay Shah wrote:
> > > Use
On Wed, Nov 22, 2023 at 10:51:08AM -0700, Mathieu Poirier wrote:
> On Fri, Nov 17, 2023 at 09:42:38AM -0800, Tanmay Shah wrote:
> > ZynqMP TCM information is fixed in driver. Now ZynqMP TCM information
> > is available in device-tree. Parse TCM information in driver
> >
On Fri, Nov 17, 2023 at 09:42:38AM -0800, Tanmay Shah wrote:
> ZynqMP TCM information is fixed in driver. Now ZynqMP TCM information
> is available in device-tree. Parse TCM information in driver
> as per new bindings.
>
> Signed-off-by: Tanmay Shah
> ---
>
> Changes in v7:
> - move checking
On Fri, Nov 17, 2023 at 09:42:37AM -0800, Tanmay Shah wrote:
> Use TCM pm domains extracted from device-tree
> to power on/off TCM using general pm domain framework.
>
> Signed-off-by: Tanmay Shah
> ---
>
> Changes in v7:
> - %s/pm_dev1/pm_dev_core0/r
> - %s/pm_dev_link1/pm_dev_core0_link/r
Hi,
On Fri, Nov 17, 2023 at 09:42:37AM -0800, Tanmay Shah wrote:
> Use TCM pm domains extracted from device-tree
> to power on/off TCM using general pm domain framework.
>
> Signed-off-by: Tanmay Shah
> ---
>
> Changes in v7:
> - %s/pm_dev1/pm_dev_core0/r
> -
On Fri, Oct 13, 2023 at 06:27:29PM +0300, Iuliana Prodan (OSS) wrote:
> From: Iuliana Prodan
>
> These patches are needed in order to support rpmsg on DSP when a
> resource table is available.
>
> Changes since v3:
> - add reserve-memory nodes in imx8mp-evk.dts rather than .dtsi (patch 2/2)
>
On Tue, 14 Nov 2023 at 08:22, Bjorn Andersson wrote:
>
> On Sat, Oct 14, 2023 at 04:15:47PM -0700, Tanmay Shah wrote:
> > From: Mathieu Poirier
> >
> > Multi-cluster remoteproc designs typically have the following DT
> > declaration:
&g
Hi Jan,
On Thu, Nov 02, 2023 at 11:07:45AM +0100, Jan Kiszka wrote:
> On 13.02.22 21:12, Suman Anna wrote:
> > Add support to the K3 R5F remoteproc driver to configure all the R5F
> > cores to be either in IPC-only mode or the traditional remoteproc mode.
> > The IPC-only mode expects that the
Hey guys,
On Fri, Oct 13, 2023 at 06:27:31PM +0300, Iuliana Prodan (OSS) wrote:
> From: Iuliana Prodan
>
> Add the reserve-memory nodes used by DSP when the rpmsg
> feature is enabled.
>
> Signed-off-by: Iuliana Prodan
> ---
> arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 22
Good morning,
On Thu, Oct 12, 2023 at 09:22:28PM -0700, Tanmay Shah wrote:
> Use TCM pm domains extracted from device-tree
> to power on/off TCM using general pm domain framework.
>
> Signed-off-by: Tanmay Shah
> ---
>
> Changes in v6:
> - Remove spurious change
> - Handle errors in
te processor (e.g. remoteproc firmware and carveouts, rpmsg
>vrings, ...).
> - (see ../reserved-memory/reserved-memory.yaml)
> + (see reserved-memory/reserved-memory.yaml in dtschema project)
Reviewed-by: Mathieu Poirier
>
> required:
>- compatib
1 - 100 of 5361 matches
Mail list logo
