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.
>
>Signed-off-by: Tanmay Shah
Reviewed-by:
On Tue, Jun 10, 2025 at 03:42:57AM +, Junhui Liu wrote:
>Hi Peng,
>Thanks for your review.
>
>On 09/06/2025 16:43, Peng Fan wrote:
>> On Sun, Jun 08, 2025 at 10:37:40AM +0800, Junhui Liu wrote:
>>>Add initial support for the C906L remote processor found in the Sophg
> Subject: Re: [PATCH v4 3/3] remoteproc: imx_rproc: detect and attach
> to pre-booted remote cores
>
> On Wed, Jun 04, 2025 at 03:19:52AM +0000, Peng Fan wrote:
> > > Subject: [PATCH v4 3/3] remoteproc: imx_rproc: detect and attach
> to
> > > pre-booted remote
> Subject: [PATCH] remoteproc: xlnx: allow single core use in split mode
>
> 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.
>
> Signed-off-by: Tanmay Shah
> ---
> drivers/remoteproc/xlnx_r5_remoteproc.c | 3 -
On Sun, Jun 08, 2025 at 10:37:40AM +0800, Junhui Liu wrote:
>Add initial support for the C906L remote processor found in the Sophgo
>CV1800B SoC. The C906L is an asymmetric core typically used to run an
>RTOS. This driver enables firmware loading and start/stop control of the
>C906L processor via t
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 | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/remoteproc
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
Manager(SM) includes vendor extension protocols, Logical Machine
Management(LMM
From: Peng Fan
i.MX95 has a System Manager(SM) core runs the System Control Management
Interface(SCMI) firmware. Vendor extenions are implemented in the
firmware, Logical Machine Management(LMM) protocol to manage
Logical Machines and CPU protocol to manage cores. The documentation
could be
-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_a55 (M7 not under A55 control)
imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all (M7 not under A55 control)
Patchset is re-based on next-20250603.
Thanks for Daniel helping review the patchset before posting out to list.
Signed-off-by: Peng Fan
---
Chang
> Subject: Re: [PATCH 2/3] remoteproc: imx_rproc: Add support for
> System Manager API
>
> Hi Peng,
>
> Thanks a lot for the patches. Comments inline:
>
> On Wed, Jun 4, 2025 at 5:36 AM Peng Fan (OSS)
> wrote:
> >
> > From: Peng Fan
> >
> >
> Subject: [PATCH v4 3/3] remoteproc: imx_rproc: detect and attach to
> pre-booted remote cores
>
> 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 d
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
Manager(SM) includes vendor extension protocols, Logical Machine
Management(LMM
From: Peng Fan
Add imx_rproc_cfg_imx95_m7 and address(TCM and DDR) mapping
Add i.MX95 of_device_id entry
Signed-off-by: Peng Fan
---
drivers/remoteproc/imx_rproc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index
From: Peng Fan
i.MX95 has a System Manager(SM) core runs the System Control Management
Interface(SCMI) firmware. Vendor extenions are implemented in the
firmware, Logical Machine Management(LMM) protocol to manage
Logical Machines and CPU protocol to manage cores. The documentation
could be
pddr5-evk-sd.bin-flash_a55 (M7 not under A55 control)
imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all (M7 not under A55 control)
Patchset is re-based on next-20250603.
Thanks for Daniel helping review the patchset before posting out to list.
Signed-off-by: Peng Fan
---
Peng Fan (3):
dt-bin
> Subject: Re: [PATCH v2 3/3] remoteproc: imx_rproc: add power mode
> check for remote core attachment
>
> On Tue, May 27, 2025 at 10:45:25AM -0300, Hiago De Franco wrote:
>
> [...]
>
> > >
> > > Thanks for the detailed analysis!
> > >
> > > This is a very similar issue as many other genpd provi
On Mon, May 26, 2025 at 09:05:10PM -0300, Hiago De Franco wrote:
>On Mon, May 26, 2025 at 12:07:49PM +0200, Ulf Hansson wrote:
>> On Fri, 23 May 2025 at 21:17, Hiago De Franco wrote:
>> >
>> > Hi Ulf,
>> >
>> > On Wed, May 21, 2025 at 02:11:02PM +0200, Ulf Hansson wrote:
>> > > You should not prov
On Mon, May 19, 2025 at 02:15:11PM -0300, Hiago De Franco wrote:
>From: Hiago De Franco
Let's wait for V2 discussion a bit, then I will give a look if we reach
an agreement on using firmware power API here.
Thanks,
Peng
On Wed, May 21, 2025 at 12:13:06PM +0800, Peng Fan wrote:
>Hi Ulf,
>
>On Tue, May 20, 2025 at 02:21:49PM +0200, Ulf Hansson wrote:
>>On Mon, 19 May 2025 at 19:24, Hiago De Franco wrote:
>>>
>>> Hi Ulf,
>>>
>>> On Mon, May 19, 2025 at 04:33:30PM
it only
>> > > > > > > checks for cores running in different partitions. If the core
>> > > > > > > was kicked
>> > > > > > > by the bootloader, it is in the same partition as Linux and it is
>> > > > > &g
Hi Hiago,
On Wed, May 07, 2025 at 01:00:54PM -0300, Hiago De Franco wrote:
>From: Hiago De Franco
>
>Move imx_sc_get_pd_power() from pmdomain/imx/scu-pd.c to
>firmware/imx/misc.c and rename it to imx_sc_pm_get_resource_power_mode()
>to maintain the same naming logic with other functions in misc.c
it is
>> > > > already up and running.
>> > > >
>> > > > This adds power mode verification through the SCU interface, enabling
>> > > > the driver to detect when the remote core is already running and
>> > > > properly
rface, enabling
>> the driver to detect when the remote core is already running and
>> properly attach to it.
>>
>> Signed-off-by: Hiago De Franco
>> Suggested-by: Peng Fan
>> ---
>> v2: Dropped unecessary include. Removed the imx_rproc_is_on function, as
>
e_wc()
> remoteproc: Use of_reserved_mem_region_* functions for "memory-region"
>
> drivers/of/device.c | 31 +---
> drivers/of/of_reserved_mem.c | 80 +++
> drivers/remoteproc/imx_dsp_rproc.c| 4
: 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(-)
Reviewed-by: Peng Fan
>
>Signed-off-by: Hiago De Franco
>Suggested-by: Peng Fan
>---
> drivers/remoteproc/imx_rproc.c | 23 +++
> 1 file changed, 23 insertions(+)
>
>diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
>index 627e57a88db2..86541d9d8640
ock.
"
You may update if you wanna.
>
>Signed-off-by: Hiago De Franco
>Suggested-by: Peng Fan
-> peng@nxp.com
Thanks,
Peng
>---
> drivers/remoteproc/imx_rproc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/remoteproc
On Mon, May 05, 2025 at 12:48:48PM -0300, Hiago De Franco wrote:
>From: Hiago De Franco
>
>Move imx_sc_get_pd_power() from pmdomain/imx/scu-pd.c to
>firmware/imx/misc.c and rename it to imx_sc_pm_get_resource_power_mode()
>to maintain the same naming logic with other functions in misc.c.
>
>This m
On Wed, Apr 09, 2025 at 02:46:10PM +0800, Peng Fan wrote:
>On Tue, Apr 08, 2025 at 10:59:58AM -0600, Mathieu Poirier wrote:
>>On Tue, 8 Apr 2025 at 09:02, Peng Fan wrote:
>>>
>>> On Thu, Apr 03, 2025 at 10:32:39PM +0800, Peng Fan wrote:
>>> >Hi Bjorn,
&g
On Mon, Apr 28, 2025 at 02:12:57PM -0300, Hiago De Franco wrote:
>On Sat, Apr 26, 2025 at 09:49:58PM +0800, 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 -060
safe.
>>
>> 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
On Sat, Apr 26, 2025 at 03:47:50PM -0600, Mathieu Poirier wrote:
>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,
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 23, 2025 at 12:51:31PM -0300, Hiago De Franco wrote:
>> > From: Hiago De Franco
>> >
>> > The "clocks" device tree
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, otherwise the follo
On Tue, Apr 08, 2025 at 10:59:58AM -0600, Mathieu Poirier wrote:
>On Tue, 8 Apr 2025 at 09:02, Peng Fan wrote:
>>
>> On Thu, Apr 03, 2025 at 10:32:39PM +0800, Peng Fan wrote:
>> >Hi Bjorn,
>> >
>> >
>> >Thanks for replying this thread.
>&
On Thu, Apr 03, 2025 at 10:32:39PM +0800, Peng Fan wrote:
>Hi Bjorn,
>
>
>Thanks for replying this thread.
>
>On Wed, Apr 02, 2025 at 08:48:58AM -0500, Bjorn Andersson wrote:
>>On Wed, Apr 02, 2025 at 09:43:55AM +0800, Peng Fan wrote:
>>> On Tue, Apr 01, 2025 at
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 has similar issue, although no issue reported until no
On Mon, Mar 31, 2025 at 07:22:45PM +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 workqu
Hi Bjorn,
Thanks for replying this thread.
On Wed, Apr 02, 2025 at 08:48:58AM -0500, Bjorn Andersson wrote:
>On Wed, 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 +08
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:
>> 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 F
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 Fri, Mar 28, 2025 at 12:50:12PM +0800, Peng Fan wrote:
>> >> On T
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 has similar issue, although no issue reported until now
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:
>> >Hi,
>> >
>> >On Wed, Mar 26, 2025 at 10:02:14AM +0800, Peng F
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 case as below could trigger kernel dump:
>> Use U-Boot to start remote processor(rproc) with
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 new firmware which doesn't have resource table
,and start rproc.
When sta
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 new firmware which doesn't have resource table
,and start rproc.
When sta
> Reviewed-by: Frank Li
> Signed-off-by: Daniel Baluta
Reviewed-by: Peng Fan
ore reset bits in the
> future.
>
> Reviewed-by: Frank Li
> Signed-off-by: Daniel Baluta
Reviewed-by: Peng Fan
> ---
> Subject: [PATCH v4 3/8] arm64: dts: imx8mp: Use resets property
>
> Add resets property to dsp node in order to be able to control the dsp
> run/stall bit from audio block control.
>
> Reviewed-by: Frank Li
> Signed-off-by: Daniel Baluta
> ---
Reviewed-by: Peng Fan
On Tue, Feb 18, 2025 at 10:57:08AM +0200, Daniel Baluta wrote:
>This adds IMX8MP_AUDIOMIX_ prefix to internal macros
>in order to show that specific macros are related to
>audiomix.
>
>Signed-off-by: Daniel Baluta
Reviewed-by: Peng Fan
On Tue, Feb 18, 2025 at 10:57:12AM +0200, Daniel Baluta wrote:
>Use the reset controller API to control the DSP on i.MX8MP. This way
>we can have a better control of the resources and avoid using a syscon
>to access the audiomix bits.
>
>Signed-off-by: Daniel Baluta
LGTM: Reviewed-by: Peng Fan
n future in case.
If you tend to use bool, also ok to me:
Reviewed-by: Peng Fan
On Tue, Feb 18, 2025 at 10:57:11AM +0200, Daniel Baluta wrote:
>We can Run/Stall the DSP via audio block control bits found in audiomix.
>Implement this functionality using the reset controller and use assert
>for Stall and deassert for Run.
>
>Signed-off-by: Daniel Baluta
>---
> drivers/reset/res
On Tue, Feb 18, 2025 at 10:57:09AM +0200, Daniel Baluta wrote:
>Current code supports EARC PHY Software Reset and EARC Software
>Reset but it is not easily extensible to more reset bits.
>
>So, refactor the code in order to easily allow more reset bits
>in the future.
>
>Signed-off-by: Dani
From: Peng Fan
Address warning: "Function parameter or struct member 'is_iomem' not
described in 'omap_rproc_da_to_va'" with adding comment for is_iomem.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202502161648.wzwrfv7i-...@intel
From: Peng Fan
On some NXP platforms (e.g i.MX7ULP) the poweroff and reboot operations
are done via a separate remote core.
Typically Linux needs to send a message to the remote core and requests
for poweroff or reboot.
By default the communication between Linux core and the remote core is
is
From: Peng Fan
Current mailbox is blocking by default, but there are cases where we don't
need to wait for a response.
Linux just needs to send data to the remote processor, so let's
allow tx_block mode to be set (true/false) depending on usecase.
No functional changes.
Signed-of
tion_timeout. In the
poweroff or restart case, there is no need to wait, because after M4 got
the message, M4 will put A7 to reboot or poweroff.
patch 1 is to support non-blocking tx mailbox channel
patch 2 is to switch to non-blocking tx for system poweroff or restart.
Signed-off-by: Peng Fan
--
> Subject: Re: [PATCH v2 2/2] remoteproc: imx_rproc: handle system off
> for i.MX7ULP
>
> On Fri, Aug 02, 2024 at 04:59:45AM +0000, Peng Fan wrote:
> > > Subject: Re: [PATCH v2 2/2] remoteproc: imx_rproc: handle system
> off
> > > for i.MX7ULP
> > >
>
> 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 Cortex-M4. The
> i.MX7ULP
> > L
> Subject: Re: [PATCH v2 2/2] remoteproc: imx_rproc: handle system off
> for i.MX7ULP
>
> On Tue, Jul 30, 2024 at 08:06:22AM +0000, Peng Fan wrote:
> > > Subject: Re: [PATCH v2 2/2] remoteproc: imx_rproc: handle system
> off
> > > for i.MX7ULP
> > >
>
ers/remoteproc/xlnx_r5_remoteproc.c | 6 +++---
> 3 files changed, 5 insertions(+), 5 deletions(-)
For i.MX:
Acked-by: Peng Fan
> 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 Cortex-M4. The
> i.MX7ULP
> > L
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. No functional changes.
Signed-off-by: Peng Fan
---
drivers/remoteproc/imx_rproc.c
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.
Fixes: 2df7062002d0 ("remoteproc: imx_proc: enable virtio/mailbox")
Signed-off-by: Peng Fan
---
drivers/
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")
Reported-by: Terry Lv
Reviewed-by: Iuliana Prodan
Signed-off-by: Peng Fan
---
drivers/remoteproc/imx_rproc.c | 2 +-
1 file
From: Peng Fan
Merge contiguous TCML/U regions into one to avoid load elf files which
has large sections failure.
Reviewed-by: Iuliana Prodan
Signed-off-by: Peng Fan
---
drivers/remoteproc/imx_rproc.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a
> Subject: Re: [PATCH 3/6] remoteproc: imx_rproc: initialize workqueue
> earlier
>
> 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 in
> Subject: Re: [PATCH 1/6] remoteproc: imx_rproc: correct ddr alias for
> i.MX8M
>
> 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
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-M4 to
configure the i.MX7ULP power controller properly.
However the
tx for system poweroff or restart.
Based on patchset:
https://lore.kernel.org/all/20240719-imx_rproc-v2-0-10d0268c7...@nxp.com/
Signed-off-by: Peng Fan
---
Changes in v2:
- Separated patch 5,6 from v1
- Update commit patch 1 with adding "No functional changes"
- Link to
From: Peng Fan
If there is a resource table device tree node, use the address as
the resource table address, otherwise use the address(where
.resource_table section loaded) inside the Cortex-M elf file.
And there is an update in NXP SDK that Resource Domain Control(RDC)
enabled to protect TCM
/2022011103.403448-1-peng@oss.nxp.com/#25144792
this is just a resend
Patch 3 is to avoid mu interrupt trigger earlier.
Patch 4 is merge small area to support elf that has large section
Signed-off-by: Peng Fan
---
Changes in v2:
- Add R-b for patch 1,2,4
- Add Fixes tag for patch 3
- Drop
> Subject: Re: [PATCH 5/6] remoteproc: imx_rproc: allow tx_block to be
> set
>
> 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 respon
> Subject: Re: [PATCH 4/6] remoteproc: imx_rproc: merge TCML/U
>
> 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 fail
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-M4 to
configure the i.MX7ULP power controller properly.
However the
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.
Reviewed-by: Jacky Bai
Signed-off-by: Peng Fan
---
drivers/remoteproc/imx_rproc.c
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, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b
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
Signed-off-by: Peng Fan
---
drivers/remoteproc/imx_rproc.c | 4 ++--
1 file changed, 2
From: Peng Fan
If there is a resource table device tree node, use the address as
the resource table address, otherwise use the address(where
.resource_table section loaded) inside the Cortex-M elf file.
And there is an update in NXP SDK that Resource Domain Control(RDC)
enabled to protect TCM
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")
Reported-by: Terry Lv
Signed-off-by: Peng Fan
---
drivers/remoteproc/imx_rproc.c | 2 +-
1 file changed, 1 insertion(+),
message.
Signed-off-by: Peng Fan
---
Peng Fan (6):
remoteproc: imx_rproc: correct ddr alias for i.MX8M
remoteproc: imx_rproc: use imx specific hook for find_loaded_rsc_table
remoteproc: imx_rproc: initialize workqueue earlier
remoteproc: imx_rproc: merge TCML/U
From: Peng Fan
Add install target for vsock to make Yocto easy to install the images.
Signed-off-by: Peng Fan
---
V2:
Use VSOCK_INSTALL_PATH, drop INSTALL_PATH
tools/testing/vsock/Makefile | 13 +
1 file changed, 13 insertions(+)
diff --git a/tools/testing/vsock/Makefile b
> Subject: Re: [PATCH] test/vsock: add install target
>
> On Wed, Jul 10, 2024 at 08:11:32AM GMT, Peng Fan wrote:
> >> Subject: Re: [PATCH] test/vsock: add install target
> >>
> >> On Tue, Jul 09, 2024 at 09:50:51PM GMT, Peng Fan (OSS) wrote:
> >> >
> Subject: Re: [PATCH] test/vsock: add install target
>
> On Tue, Jul 09, 2024 at 09:50:51PM GMT, Peng Fan (OSS) wrote:
> >From: Peng Fan
> >
> >Add install target for vsock to make Yocto easy to install the images.
> >
> >Signed-off-by: Peng Fan
>
From: Peng Fan
Add install target for vsock to make Yocto easy to install the images.
Signed-off-by: Peng Fan
---
tools/testing/vsock/Makefile | 12
1 file changed, 12 insertions(+)
diff --git a/tools/testing/vsock/Makefile b/tools/testing/vsock/Makefile
index a7f56a09ca9f
r (linuxtesting.org) with SVACE.
>
> Fixes: a0ff4aa6f010 ("remoteproc: imx_rproc: add a NXP/Freescale imx_rproc
> driver")
> Signed-off-by: Aleksandr Mishin
Anyway LGTM:
Reviewed-by: Peng Fan
Thanks,
Peng.
> Subject: Re: [PATCH] vhost: use pr_err for vq_err
>
> On Thu, May 16, 2024 at 03:46:29PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan
> >
> > Use pr_err to print out error message without enabling DEBUG. This
> > could make people catch error easier
From: Peng Fan
Use pr_err to print out error message without enabling DEBUG. This could
make people catch error easier.
Signed-off-by: Peng Fan
---
drivers/vhost/vhost.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index
eng.
>
> On Thu, Apr 08, 2021 at 09:54:58AM +0800, peng@oss.nxp.com wrote:
> > From: Peng Fan
> >
> > Add i.MX8MN/P remote processor(Cortex-M7) support, we are using ARM
> > SMCCC to start/stop M core, not using regmap interface.
> >
> > Signed-off-
From: Peng Fan
i.MX7ULP A7 core runs under control of M4 core, M4 core starts by ROM
and powers most serivces used by A7 core, so A7 core has no power to
start and stop M4 core. And the M4 core's state is default RPROC_DETACHED
and remoteproc framework not able to stop the M4 core.
Signe
From: Peng Fan
Add i.MX8MN/P remote processor(Cortex-M7) support, we are using ARM
SMCCC to start/stop M core, not using regmap interface.
Signed-off-by: Peng Fan
---
drivers/remoteproc/imx_rproc.c | 87 ++
1 file changed, 80 insertions(+), 7 deletions
From: Peng Fan
To i.MX7ULP, M4 is the master to control everything, no need to provide
clk from Linux side. So make clk optional when method is IMX_RPROC_NONE.
Signed-off-by: Peng Fan
---
drivers/remoteproc/imx_rproc.c | 46 --
1 file changed, 31
From: Peng Fan
Add three methods IMX_RPROC_NONE(no need start/stop), IMX_RPROC_MMIO
(start/stop through mmio) and IMX_RPROC_SMC(start/stop through ARM SMCCC).
The current SoCs supported are all using IMX_RPROC_MMIO, add a restrict
in imx_rproc_detect_mode that only SoCs using IMX_RPROC_MMIO
From: Peng Fan
Parse fsl,auto-boot to indicate whether need remoteproc framework
auto boot or not.
When remote processor is booted before Linux Kernel up, do not parse
fsl,auto-boot, so only need to parse the property when rproc state is
RPROC_DETACHED.
Signed-off-by: Peng Fan
---
drivers
From: Peng Fan
Add i.MX8MN/P remote processor(Cortex-M7) compatible string
Signed-off-by: Peng Fan
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/remoteproc/fsl
From: Peng Fan
Add i.MX7ULP compatible.
We use i.MX7ULP dual mode and in which case i.MX7ULP A7 core runs under
control of M4 core, M4 core starts by ROM and powers most services used
by A7 core, so A7 core has no power to start and stop M4 core. So
clocks and syscon are not required.
Signed
From: Peng Fan
Add an optional property "fsl,auto-boot" to indicate remote processor
auto boot.
Signed-off-by: Peng Fan
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/
From: Peng Fan
V4:
Typo fix
patch 4: take state as a check condition
patch 5: move regmap lookup/attach to imx_rproc_detect_mode
patch 6: add imx_rproc_clk_enable for optional clk
patch 8: use switch/case in imx_rproc_detect_mode
V3:
Add A-b tag for Patch 1/2
Fix the checkpatch warning
> (Was: [PATCH v4 4/4] soc: imx8m: change to use platform driver)
>
> Alice Guo (OSS) wrote on Tue, Mar 30, 2021 at 02:41:23AM +:
> > Thanks for reporting this issue, I'll check and add a fix to handle defer
> > probe.
>
> I haven't seen any follow up on this, have you had a chance to take a
1 - 100 of 873 matches
Mail list logo
