/imx_rproc.c
> @@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
> struct resource res;
>
> node = of_parse_phandle(np, "memory-region", a);
> + /* Not map vdev region */
> + if (!strcmp(node->na
On Wed, Jan 06, 2021 at 02:37:14PM +0100, Arnaud Pouliquen wrote:
> The rpmsg_create_ept function is invoked when the device is opened.
> As only one endpoint must be created per device. It is not
> possible to open the same device twice.
> The fix consists in returning -EBUSY when device is
On Thu, Jan 14, 2021 at 09:52:13AM +, Peng Fan wrote:
> > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> > regions
> >
> > On Wed, Jan 13, 2021 at 02:19:32AM +, Peng Fan wrote:
> > > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping
> > > > vdev
Hi Bjorn,
On Thu, Jan 07, 2021 at 03:50:53PM -0800, Bjorn Andersson wrote:
> Analog to the issue in the common mdt_loader code the MSS ELF loader
> does not validate that p_filesz bytes will fit in the memory region and
> that the loaded segments are not truncated. Fix this in the same way
> as
Hi Arnaud,
[...]
>
> Arnaud Pouliquen (16):
> rpmsg: introduce RPMsg control driver for channel creation
> rpmsg: add RPMsg control API to register service
> rpmsg: add override field in channel info
> rpmsg: ctrl: implement the ioctl function to create device
> rpmsg: ns: initialize
On Wed, Jan 13, 2021 at 02:19:32AM +, Peng Fan wrote:
> > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> > regions
> >
> > On Tue, Jan 12, 2021 at 09:41:12AM +, Peng Fan wrote:
> > > > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping
> > > > vdev
Hi Martin,
On Sat, Jan 02, 2021 at 09:59:03PM +0100, Martin Blumenstingl wrote:
> Amlogic Meson6, Meson8, Meson8b and Meson8m2 embed an ARC core in the
> Always-On (AO) power-domain. This is typically used for waking up the
> ARM cores after system suspend.
>
> The configuration is spread across
On Tue, Jan 12, 2021 at 05:39:14PM +0800, peng@nxp.com wrote:
> From: Peng Fan
>
> It is using devm_ioremap, so not devm_ioremap_resource. Correct
> the error message and print out sa/size.
>
> Reviewed-by: Bjorn Andersson
> Signed-off-by: Peng Fan
> Revi
On Tue, Jan 12, 2021 at 09:41:12AM +, Peng Fan wrote:
> > Subject: Re: [PATCH V5 7/8] remoteproc: imx_rproc: ignore mapping vdev
> > regions
> >
> > On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng@nxp.com wrote:
> > > From: Peng Fan
> > >
> > > vdev regions are vdev0vring0, vdev0vring1,
On Tue, Dec 29, 2020 at 11:30:18AM +0800, peng@nxp.com wrote:
> From: Peng Fan
>
> vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> They are handled by remoteproc common code, no need to map in imx
> rproc driver.
>
> Signed-off-by: Peng Fan
> ---
>
On Tue, Dec 29, 2020 at 11:30:17AM +0800, peng@nxp.com wrote:
> From: Peng Fan
>
> Add i.MX8MQ dev/sys addr map and configuration data structure
> i.MX8MM share i.MX8MQ settings.
>
> Reviewed-by: Richard Zhu
> Signed-off-by: Peng Fan
> Reviewed-by: Mathieu P
.
>
> Reviewed-by: Oleksij Rempel
> Reviewed-by: Richard Zhu
> Signed-off-by: Peng Fan
> ---
> drivers/remoteproc/imx_rproc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Mathieu Poirier
>
> diff --git a/drivers/remoteproc/imx_rproc.
vers/remoteproc/imx_rproc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Mathieu Poirier
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 6603e00bb6f4..2a093cea4997 100644
> --- a/drivers/remoteproc/imx_rpro
vers/remoteproc/imx_rproc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Mathieu Poirier
>
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 6603e00bb6f4..2a093cea4997 100644
> --- a/drivers/remoteproc/imx_rpro
2 +-
> drivers/remoteproc/st_slim_rproc.c | 2 +-
> drivers/remoteproc/ti_k3_dsp_remoteproc.c | 2 +-
> drivers/remoteproc/ti_k3_r5_remoteproc.c | 2 +-
> drivers/remoteproc/wkup_m3_rproc.c | 2 +-
> include/linux/remoteproc.h | 2 +-
> 20 fil
file changed, 2 insertions(+)
Reviewed-by: Mathieu Poirier
>
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index f28ee75d1005..a5f6d2d9cde2 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -315,6 +315,7 @@ struct rproc;
Hi Leo,
Suzuki and Mike have pointed out a few things to modify and there was a couple
of kernel bot warnings to address as well. As such I will wait for your next
revision before looking at this set.
Thanks,
Mathieu
On Sat, Jan 09, 2021 at 03:44:28PM +0800, Leo Yan wrote:
> This patch series
MTRANS enum values to fix unhandled
> value compilation error. Currently they are ignored.
>
> Increase the minimum version number to v1.0.0 now
> that new enum values are used that are only present
> in this version.
>
> Signed-off-by: James Clark
> Cc: John Garry
> Cc:
Hi Suzuki,
On Thu, Jan 07, 2021 at 12:38:33PM +, Suzuki K Poulose wrote:
> CoreSight ETMv4.4 obsoletes memory mapped access to ETM and
> mandates the system instructions for registers.
> This also implies that they may not be on the amba bus.
> Right now all the CoreSight components are
me. Also enable CONTEXIDR_EL2
> tracing if we are running the kernel at EL2.
>
> Cc: Catalin Marinas
> Cc: Mathieu Poirier
> Cc: Mike Leach
> Cc: Will Deacon
> Signed-off-by: Jonathan Zhou
> [ Move the trace filtering setup etm_init_arch_data() and
> clean ups]
&g
definitions to separate patch
> rename some of the symbols ]
> Signed-off-by: Suzuki K Poulose
Acked-by: Mathieu Poirier
> ---
> arch/arm64/include/asm/sysreg.h | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/ar
hem.
>
> Cc: Mike Leach
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> ---
> Changes since v5:
> - Rebased to accommodate check_arch_features().
>Added comments to explain why we don't pass PID for system
>register based devices.
> C
res. Thus we move the arch feature detection to
> run on the CPU. We cannot always read the PID from the HW (i.e even
> for AMBA devices), as the as the PID could be overridden by DT for
s/as the as the/as the
I made the change.
> broken devices. So, use the PID from AMBA layer if availa
On Thu, Jan 07, 2021 at 12:38:54PM +, Suzuki K Poulose wrote:
> CoreSight ETM with system register access may not have a
> memory mapped i/o access. Refactor the ETM specific probing
> into a common routine to allow reusing the code for such ETMs.
>
> Cc: Mike Leach
> Re
On Thu, Jan 07, 2021 at 12:38:45PM +, Suzuki K Poulose wrote:
> The Software lock is not implemented for system instructions
> based accesses. So, skip the lock register access in such
> cases.
>
> Cc: Mike Leach
> Reviewed-by: Mathieu Poirier
> Signed-off
to preserve the logic of these operations at a
> single place we introduce an abstraction layer for the accesses
> to a given device.
>
> Cc: Mike Leach
> Reviewed-by: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> ---
> Change since v3
> - Dropped csa argument to
On Wed, Jan 06, 2021 at 06:03:25PM -0600, Suman Anna wrote:
> Hi Mathieu,
>
> On 1/6/21 5:27 PM, Mathieu Poirier wrote:
> > On Wed, Dec 16, 2020 at 05:52:34PM +0100, Grzegorz Jaszczyk wrote:
> >> Hi All,
> >>
> >> The Programmable Real-Time Unit and In
On Wed, Dec 16, 2020 at 05:52:34PM +0100, Grzegorz Jaszczyk wrote:
> Hi All,
>
> The Programmable Real-Time Unit and Industrial Communication Subsystem
> (PRU-ICSS or simply PRUSS) on various TI SoCs consists of dual 32-bit
> RISC cores (Programmable Real-Time Units, or PRUs) for program
Adding Suman and Paul - guys please have a look.
On Mon, Jan 04, 2021 at 04:02:53PM -0700, Rob Herring wrote:
> DT properties which can have multiple entries need to specify what the
> entries are and define how many entries there can be. In the case of
> only a single entry, just 'maxItems: 1'
Hi Suzuki,
On Mon, Dec 14, 2020 at 05:37:27PM +, Suzuki K Poulose wrote:
> CoreSight ETM with system register access may not have a
> memory mapped i/o access. Refactor the ETM specific probing
> into a common routine to allow reusing the code for such ETMs.
>
> Cc: Mike Leach
ree bindings for Embedded Trace Extensions.
> > > ETE can be connected to legacy coresight components and thus
> > > could optionally contain a connection graph as described by
> > > the CoreSight bindings.
> > >
> > > Cc: devicet...@vger.kernel.org
&
After discussing with Bjorn, stepping forward to help with the
maintenance of the remoteproc and RPMSG subsystems.
Signed-off-by: Mathieu Poirier
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6eff4f720c72..6fa304038f2d 100644
-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 20 +---
drivers/remoteproc/remoteproc_sysfs.c | 5 +
include/linux/remoteproc.h| 2 --
3 files changed, 2 insertions(+), 25 deletions(-)
diff --git
Add a return value to function rproc_shutdown() in order to
properly deal with error conditions that may occur.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 19 ++-
include/linux/remoteproc.h
This patch introduces the capability to detach a remote processor
that has been attached to or booted by the remoteproc core. For
that to happen a rproc::ops::detach() operation need to be
available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
Add an new detach() operation in order to support scenarios where
the remoteproc core is going away but the remote processor is
kept operating. This could be the case when the system is
rebooted or when the platform driver is removed.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Refactor function rproc_del() and rproc_cdev_release() to take
into account the policy specified in the device tree.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/remoteproc_cdev.c | 18 +++---
drivers/remoteproc/remoteproc_core.c | 36
include/linux
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5 insertions
This patch introduces the capability to stop a remote processor
that has been attached to by the remoteproc core. For that to
happen a rproc::ops::stop() operation need to be available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc
Introduce function rproc_detach() to enable the remoteproc
core to release the resources associated with a remote processor
without stopping its operation.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
---
drivers/remoteproc/remoteproc_core.c | 71 +++-
include
Add an new get_loaded_rsc_table() operation in order to support
scenarios where the remoteproc core has booted a remote processor
and detaches from it. When re-attaching to the remote processor,
the core needs to know where the resource table has been placed
in memory.
Signed-off-by: Mathieu
This patch takes into account scenarios where a remote processor
has been attached to when receiving a "start" command from sysfs.
As with the "running" case, the command can't be carried out if the
remote processor is already in operation.
Signed-off-by: Mathieu Poirier
te processor while
the latter is kept operating.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
---
drivers/remoteproc/remoteproc_core.c | 42
1 file changed, 42 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_
Add a new RPROC_ATTACHED state to take into account scenarios
where the remoteproc core needs to attach to a remote processor
that is booted by another entity.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_sysfs.c | 1
Rename function rproc_actuate() to rproc_attach(). That way it is
easy to understand that it does the opposite of rproc_detach().
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 8
1 file changed, 4
needs to be available
at a later time than the platform driver's probe() function.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/stm32_rproc.c | 147 ---
1 file changed, 74 insertions(+), 73 deletions(-)
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers
The state of the remote processor may have changed between the
time a call to rproc_shutdown() was made and the time it is
executed. To avoid moving forward with an operation that may
have been cancelled, recheck while holding the mutex.
Cc:
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
when in fact it
no longer exist.
Invariably calling rproc_shutdown() is fine since it will return
immediately if the remote processor has already been switched
off.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 4
the external resource table in the core
- Fixed a crash when detaching (Arnaud)
- Fixed error code propagation in rproc_cdev_relase() and rproc_del() (Arnaud)
- Added RB tags
Mathieu Poirier (17):
dt-bindings: remoteproc: Add bindind to support autonomous processors
remoteproc: Re-check state
if "autonomous-on-core-reboot" is specified in the remote
processor DT node, the remoteproc core will detach the remote processor
rather than switching it off.
Signed-off-by: Mathieu Poirier
---
.../bindings/remoteproc/remoteproc-core.yaml | 27 +++
1 file changed, 27
; type."
> > > >
> > > > On i.MX platforms, when elf is loaded to onchip TCM area, the region
> > > > is ioremapped, so "dc zva, dst" will trigger abort. And ioremap_wc()
> > > > on i.MX not able to write correct data
t are determined by the
> > > > memory type."
> > > >
> > > > On i.MX platforms, when elf is loaded to onchip TCM area, the region
> > > > is ioremapped, so "dc zva, dst" will trigger abort. And ioremap_wc()
> > > > on i.MX not abl
On Tue, Nov 10, 2020 at 06:15:08PM +0530, Anshuman Khandual wrote:
> Unlike traditional sink devices, individual TRBE instances are not detected
> via DT or ACPI nodes. Instead TRBE instances are detected during CPU online
> process. Hence a path connecting ETE and TRBE on a given CPU would not
On Fri, Nov 27, 2020 at 10:32:28AM +, Suzuki K Poulose wrote:
> On 11/10/20 12:45 PM, Anshuman Khandual wrote:
> > perf handle structure needs to be shared with the TRBE IRQ handler for
> > capturing trace data and restarting the handle. There is a probability
> > of an undefined reference
On Wed, Dec 09, 2020 at 09:42:20PM +0100, Markus Elfring wrote:
> From: Markus Elfring
> Date: Wed, 9 Dec 2020 21:34:48 +0100
>
> A local variable was used only within an else branch.
> Thus move the definition for the variable “cs_fwnode” into
> the corresponding code block.
>
> This issue was
On Mon, Nov 30, 2020 at 07:57:17AM -0800, Ben Levinsky wrote:
> R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> remotproc driver, we can boot the R5 sub-system in two different
> configurations -
> * Split
> * Lockstep
>
> The Xilinx R5 Remoteproc Driver boots the
On Wed, Dec 09, 2020 at 11:13:07AM +0100, Arnaud POULIQUEN wrote:
>
>
> On 11/26/20 10:06 PM, Mathieu Poirier wrote:
> > Refactor function rproc_del() and rproc_cdev_release() to take
> > into account the policy specified in the device tree.
> >
> &g
On Wed, Dec 09, 2020 at 09:45:32AM +0100, Arnaud POULIQUEN wrote:
>
>
> On 12/9/20 1:53 AM, Mathieu Poirier wrote:
> > On Tue, Dec 08, 2020 at 07:35:18PM +0100, Arnaud POULIQUEN wrote:
> >> Hi Mathieu,
> >>
> >>
> >> On 11/26/20 10:06
+ if (!rsc)
> + return 0;
> +
> + /* currently supporting only type 0 */
> + if (rsc->type != 0) {
> + dev_err(dev, "unsupported rsc type: %d\n", rsc->type);
> + return -EINVAL;
> + }
> +
> + if (rsc->
On Mon, Nov 30, 2020 at 07:57:17AM -0800, Ben Levinsky wrote:
> R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> remotproc driver, we can boot the R5 sub-system in two different
> configurations -
> * Split
> * Lockstep
>
> The Xilinx R5 Remoteproc Driver boots the
On Tue, Dec 08, 2020 at 07:35:18PM +0100, Arnaud POULIQUEN wrote:
> Hi Mathieu,
>
>
> On 11/26/20 10:06 PM, Mathieu Poirier wrote:
> > Introduce function rproc_detach() to enable the remoteproc
> > core to release the resources associated with a remote processor
On Tue, Dec 08, 2020 at 07:35:18PM +0100, Arnaud POULIQUEN wrote:
> Hi Mathieu,
>
>
> On 11/26/20 10:06 PM, Mathieu Poirier wrote:
> > Introduce function rproc_detach() to enable the remoteproc
> > core to release the resources associated with a remote processor
be reduced manually to avoid ETM
overflow.
Reviewed-by: Suzuki K Poulose
Signed-off-by: Qi Liu
[Modified changelog title and Kconfig description]
Signed-off-by: Mathieu Poirier
---
drivers/hwtracing/coresight/Kconfig | 8 ++
.../coresight/coresight-etm4x-core.c | 98
/hwtracing/coresight/coresight-catu.o
Remove all those annotations.
Fixes: 8b0cf82677d1 ("coresight: stm: Allow to build coresight-stm as a module")
Signed-off-by: Arnd Bergmann
Reviewed-by: Stephen Boyd
Signed-off-by: Mathieu Poirier
---
drivers/hwtracing/coresight/coresight-catu.c
er packets when moving
offset forward")
Reported-by: Al Grant
Tested-by: Mike Leach
Cc: Mathieu Poirier
Cc: sta...@vger.kernel.org
Signed-off-by: Suzuki K Poulose
Signed-off-by: Mathieu Poirier
---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 2 +-
1 file changed, 1 insertion(+), 1 del
Good morning,
As expected a few more fixes came late in the cycle - please
see if you can include them in the v5.11 cycle.
Applies cleanly on today's char-misc-next (ee64ed8153ab).
Thanks,
Mathieu
Arnd Bergmann (1):
coresight: remove broken __exit annotations
Qi Liu (1):
coresight: etm4x:
On Tue, Dec 08, 2020 at 03:19:20PM +0800, Qi Liu wrote:
> The ETM device can't keep up with the core pipeline when cpu core
> is at full speed. This may cause overflow within core and its ETM.
> This is a common phenomenon on ETM devices.
>
> On HiSilicon Hip08 platform, a specific feature is
On Mon, Nov 30, 2020 at 07:57:17AM -0800, Ben Levinsky wrote:
> R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> remotproc driver, we can boot the R5 sub-system in two different
> configurations -
> * Split
> * Lockstep
>
> The Xilinx R5 Remoteproc Driver boots the
On Mon, Nov 30, 2020 at 07:57:17AM -0800, Ben Levinsky wrote:
> R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> remotproc driver, we can boot the R5 sub-system in two different
> configurations -
> * Split
> * Lockstep
>
> The Xilinx R5 Remoteproc Driver boots the
Rob Herring is the maintainer of all the yaml files - he is the one this patch
needs to go to. I merely look at them to understand the platform device
implementation.
On Mon, Nov 30, 2020 at 07:57:16AM -0800, Ben Levinsky wrote:
> Add binding for ZynqMP R5 OpenAMP.
>
> Represent the RPU domain
On Fri, Dec 04, 2020 at 09:18:04PM +0100, Grzegorz Jaszczyk wrote:
> The firmware blob can contain optional ELF sections: .resource_table
> section and .pru_irq_map one. The second one contains the PRUSS
> interrupt mapping description, which needs to be setup before powering
> on the PRU core. To
Qi Liu wrote:
> >>>> Hi Mathieu,
> >>>>
> >>>> On 2020/12/5 2:55, Mathieu Poirier wrote:
> >>>>> On Thu, Nov 26, 2020 at 09:34:30PM +0800, Qi Liu wrote:
> >>>>>> The ETM device can't keep up with the core pipeline whe
On Thu, Nov 26, 2020 at 09:34:30PM +0800, Qi Liu wrote:
> The ETM device can't keep up with the core pipeline when cpu core
> is at full speed. This may cause overflow within core and its ETM.
> This is a common phenomenon on ETM devices.
>
> On HiSilicon Hip08 platform, a specific feature is
On Fri, Dec 04, 2020 at 12:11:40AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Functions that are annotated __exit are discarded for built-in drivers,
> but the .remove callback in a device driver must still be kept around
> to allow bind/unbind operations.
>
> There is now a linker
.spinics.net/lists/linux-virtualization/msg43359.html
>
> On Wed, Dec 02, 2020 at 01:39:54PM -0700, Mathieu Poirier wrote:
> > Good day,
> >
> > On Wed, Dec 02, 2020 at 12:05:55PM +0100, Guennadi Liakhovetski wrote:
> > > Hi Mathieu,
> > >
> > > I'
On Fri, Dec 04, 2020 at 03:11:55PM +0100, Grzegorz Jaszczyk wrote:
> Hi Mathieu,
>
> On Wed, 2 Dec 2020 at 23:57, Mathieu Poirier
> wrote:
> >
> > On Thu, Nov 19, 2020 at 03:08:47PM +0100, Grzegorz Jaszczyk wrote:
> > > The firmware blob can contain optio
On Thu, Dec 03, 2020 at 02:39:41PM +0800, Leo Yan wrote:
> Hi Will,
>
> [ + Mathieu ]
>
> On Tue, Dec 01, 2020 at 11:09:36PM +, Will Deacon wrote:
> > On Tue, Dec 01, 2020 at 12:10:40PM +0800, Leo Yan wrote:
> > > On Mon, Nov 30, 2020 at 04:46:51PM +, Will Deacon wrote:
> > > > On Mon,
orz Jaszczyk
> Signed-off-by: Grzegorz Jaszczyk
Reviewed-by: Mathieu Poirier
> ---
> drivers/remoteproc/pru_rproc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
> index 48c1c51e0d42..96f689283a8b 100
s behavior.
> + */
> +static int pru_rproc_memcpy(void *dest, const void *src, size_t count)
> +{
> + const int *s = src;
> + int *d = dest;
> + int size = count / 4;
> + int *tmp_src = NULL;
> +
> + /*
> + * TODO: relax limitation of 4-byte alig
xecuting, cannot print/access debug
> registers.\n");
> + return 0;
> + }
> +
> + for (i = 0; i < nregs; i++) {
> + seq_printf(s, "GPREG%-2d := 0x%08x\tCT_REG%-2d := 0x%08x\n",
> +i, pru_debug_read_reg(pru, PRU_DEB
On Thu, Nov 19, 2020 at 03:08:47PM +0100, Grzegorz Jaszczyk wrote:
> The firmware blob can contain optional ELF sections: .resource_table
> section and .pru_irq_map one. The second one contains the PRUSS
> interrupt mapping description, which needs to be setup before powering
> on the PRU core. To
On Wed, Dec 02, 2020 at 01:53:36PM -0700, Mathieu Poirier wrote:
> On Tue, Dec 01, 2020 at 03:54:36PM -0700, Mathieu Poirier wrote:
> > Hi Grzeg,
> >
> > I have started to review this set - comments will come over the next few
> > days.
> >
> > See belo
On Tue, Dec 01, 2020 at 03:54:36PM -0700, Mathieu Poirier wrote:
> Hi Grzeg,
>
> I have started to review this set - comments will come over the next few days.
>
> See below for a start.
>
> On Thu, Nov 19, 2020 at 03:08:46PM +0100, Grzegorz Jaszczyk wrote:
Guennadi Liakhovetski wrote:
> > Hi Mathieu,
> >
> > Thanks for bringing all the stuff together and for polishing it!
> >
> > For the entire series:
> >
> > Tested-by: Guennadi Liakhovetski
> > Reviewed-by: Guennadi Liakhovetski
> >
Hi Rob,
On Mon, Nov 30, 2020 at 10:33:21AM -0700, Rob Herring wrote:
> On Thu, Nov 26, 2020 at 02:06:28PM -0700, Mathieu Poirier wrote:
> > This patch adds a binding to guide the remoteproc core on how to deal with
> > remote processors in two cases:
> >
> > 1)
Hi Grzeg,
I have started to review this set - comments will come over the next few days.
See below for a start.
On Thu, Nov 19, 2020 at 03:08:46PM +0100, Grzegorz Jaszczyk wrote:
> From: Suman Anna
>
> The Programmable Real-Time Unit Subsystem (PRUSS) consists of
> dual 32-bit RISC cores
tools to use it for identification.
>
> Cc: Mike Leach
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/hwtracing/coresight/coresight-etm4x-sysfs.c | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Mathieu Poirier
>
> diff --git a/drivers/hwtr
On Thu, Nov 19, 2020 at 04:45:38PM +, Suzuki K Poulose wrote:
> In preparation to detect the support for system instruction
> support, move the detection of the device access to the target
> CPU.
>
> Cc: Mathieu Poirier
> Cc: Mike Leach
> Signed-off-by: Suzuki K Pou
ing/coresight/coresight-etm4x.h | 60 ++-
> 2 files changed, 58 insertions(+), 4 deletions(-)
With the above:
Reviewed-by: Mathieu Poirier
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index 2342e72c
++---
> 3 files changed, 60 insertions(+), 46 deletions(-)
>
Reviewed-by: Mathieu Poirier
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index a1f294703c43..2342e72c5016 100644
> --- a/drivers/hwtracing/coresi
R3.EXLEVEL_S field to detect
> the supported levels.
>
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/hwtracing/coresight/coresight-etm4x-core.c | 13 +++--
> drivers/hwtracing/coresight/coresight-etm4x.h | 6 --
> 2 files changed, 7 insertions(+), 12 del
On Thu, Nov 19, 2020 at 04:45:33PM +, Suzuki K Poulose wrote:
> Define the fields of the DEVARCH register for identifying
> a component as an ETMv4.x unit. Going forward, we use the
> DEVARCH register for the component identification, rather
> than the TRCIDR3.
>
> Cc: Mat
On Thu, Nov 19, 2020 at 04:45:28PM +, Suzuki K Poulose wrote:
> Convert the generic CLAIM tag management APIs to use the
> device access layer abstraction.
>
> Cc: Mathieu Poirier
> Cc: Mike Leach
> Signed-off-by: Suzuki K Poulose
> ---
> Changes since V3:
>
On Thu, Nov 19, 2020 at 04:45:27PM +, Suzuki K Poulose wrote:
> Convert the generic routines to use the new access abstraction layer
> gradually, starting with coresigth_timeout.
>
> Cc: Mike Leach
> Reviewed-by: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> -
On Sun, Nov 29, 2020 at 05:20:23PM +, Ben Levinsky wrote:
> Ping for comments
>
I plan on reviewing Grzegorz's PRU set before this one and as such won't get to
yours well into next week or the one after. I noticed Rob found errors in
the DT schema - those need fixing anyway.
>
> >
to preserve the logic of these operations at a
> single place we introduce an abstraction layer for the accesses
> to a given device.
>
> Cc: Mathieu Poirier
> Cc: Mike Leach
> Signed-off-by: Suzuki K Poulose
> ---
> Change since v3
> - Dropped csa argument to read()/writ
RCPDCR. Make sure
> we skip the access during the save/restore.
>
> Found by code inspection.
>
> Fixes: commit 02510a5aa78df45 ("coresight: etm4x: Add support to skip trace
> unit power up")
https://elixir.bootlin.com/linux/v5.10-rc5/source/Documentation/process/su
On Thu, Nov 19, 2020 at 04:45:39PM +, Suzuki K Poulose wrote:
> We have been using TRCIDR1 for detecting the ETM version. This
> is in preparation for the future IP support.
>
> Cc: Mike Leach
> Reviewed-by: Suzuki K Poulose
You have reviewed your own code - that's great!
I had a good
From: Suzuki K Poulose
TRCPROCSELR is not implemented if the TRCIDR3.NUMPROC == 0. Skip
accessing the register in such cases.
Cc: sta...@vger.kernel.org
Cc: Mathieu Poirier
Cc: Mike Leach
Signed-off-by: Suzuki K Poulose
Signed-off-by: Mathieu Poirier
---
drivers/hwtracing/coresight
From: Suzuki K Poulose
TRCVMIDCTRL1 is only implemented only if the TRCIDR4.NUMVMIDC > 4.
We must not touch the register otherwise.
Cc: sta...@vger.kernel.org
Cc: Mathieu Poirier
Cc: Mike Leach
Signed-off-by: Suzuki K Poulose
Signed-off-by: Mathieu Poirier
---
drivers/hwtracing/coresi
501 - 600 of 5417 matches
Mail list logo
