On 7/1/19 7:31 AM, Bjorn Andersson wrote:
> On Fri 10 May 08:02 PDT 2019, Arnaud Pouliquen wrote:
>
>> Return the rpmsg buffer payload size for sending message, so rpmsg users
>> can split a long message in several sub rpmsg buffers.
>>
>> Signed-off-by: Arna
Hi Bjorn,
On 7/1/19 8:00 AM, Bjorn Andersson wrote:
> On Fri 10 May 08:02 PDT 2019, Arnaud Pouliquen wrote:
>
>> This driver exposes a standard tty interface on top of the rpmsg
>> framework through the "rpmsg-tty-channel" rpmsg service.
>>
>> This dri
Standardize dump presentation for va, dma and da dumps by adding
"0x" prefix for virtual address.
Fixes: 276ec9934231("remoteproc: replace "%p" with "%pK"")
Signed-off-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_debugfs.c | 2 +-
1 file chan
Hello Xiang
On 2/16/19 8:37 PM, Xiang Xiao wrote:
> From: Yanlin Zhu
>
> which could redirect clk API from remote to the kernel
>
> Signed-off-by: Yanlin Zhu
> ---
> drivers/rpmsg/Kconfig | 10 ++
> drivers/rpmsg/Makefile| 1 +
> drivers/rpmsg/rpmsg_clk.c | 284
> +
Hello Xiang,
On 2/12/19 8:13 AM, Xiang Xiao wrote:
> From: QianWenfa
>
> the two phase handsake make the client could initiate the transfer
> immediately without the server side send any dummy message first.
As discussed on OpenAMP mailing list, the first point (from my pov) is
to figure out i
Hi Suman
On 09/25/2018 02:25 AM, Suman Anna wrote:
> Hi Srinivas,
>
> On 06/15/2018 04:59 AM, Srinivas Kandagatla wrote:
>> Some of the rpmsg devices need to switch on power domains to communicate
>> with remote processor. For example on Qualcomm DB820c platform LPASS
>> power domain needs to swi
if (rproc->state != RPROC_RUNNING)
> return -EINVAL;
>
> rproc_shutdown(rproc);
> + if (!rproc->auto_boot)
> + module_put(dev->parent->driver->owner);
> } else {
> dev_err(&rproc->dev, "Unrecognised option: %s\n", buf);
> ret = -EINVAL;
>
Looks good for me, i tested on ST platform and did not detect any
regression.
Acked-by: Arnaud Pouliquen
Regards
Arnaud
red percent sure that it is relevant, as it treats only a
part of the problem. But it's fine with me if it is accepted.
Tested-by: Arnaud Pouliquen
Regards
Arnaud
>
> p = kstrndup(buf, len, GFP_KERNEL);
> if (!p) {
>
Hi Suman,
On 09/15/2018 02:37 AM, Suman Anna wrote:
> The remoteproc framework provides sysfs interfaces for changing
> the firmware name and for starting/stopping a remote processor
> through the sysfs files 'state' and 'firmware'. These interfaces
> are currently allowed irrespective of how the
On 06/06/2018 11:47 AM, Takashi Iwai wrote:
> On Wed, 06 Jun 2018 11:31:45 +0200,
> Arnaud Pouliquen wrote:
>>
>>
>>
>> On 06/05/2018 08:29 PM, Takashi Iwai wrote:
>> > On Tue, 05 Jun 2018 17:50:57 +0200,
>> > Arnaud Pouliquen wrote:
>>
Hello,
For the series:
Acked-by: Arnaud Pouliquen
Thanks,
Arnaud
On 03/13/2018 03:23 PM, Fabrice Gasnier wrote:
> This series brings fixes to STM32 DFSDM ADC driver.
>
> Fabrice Gasnier (2):
> iio: adc: stm32-dfsdm: fix successive oversampling settings
> iio: adc: stm32-df
king on getting their code accepted in main
> line. I have been trying to get my tda998x patches reviewed for some
> time now, but not lately, because I have been busy with my other tasks.
>
> The two others are Philipp Zabel and Arnaud Pouliquen, both in cc. Not
> sure if they
Hi Peter,
On 05/25/2016 06:06 PM, Peter Griffin wrote:
> This patch enables the STi ALSA drivers found on STi platforms
> as well as the simple-card driver which is a dependency to have
> working sound.
>
> Signed-off-by: Peter Griffin
> Cc: arnaud.pouliq...@st.com
> Cc: broo...@kernel.org
> ---
On 05/25/2016 06:06 PM, Peter Griffin wrote:
> This patch adds the dt node for the internal audio
> codec IP.
>
> Signed-off-by: Peter Griffin
> ---
> arch/arm/boot/dts/stih407-family.dtsi | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi
On 05/25/2016 06:06 PM, Peter Griffin wrote:
> This patch adds the DT nodes for the uniperif player
> IP blocks found on STiH407 family silicon.
>
> Signed-off-by: Peter Griffin
> ---
> arch/arm/boot/dts/stih407-family.dtsi | 76
> +++
> 1 file changed, 76 inse
On 05/25/2016 06:06 PM, Peter Griffin wrote:
> This patch adds the DT node for the uniperif reader
> IP block found on STiH407 family silicon.
>
> Signed-off-by: Peter Griffin
> ---
> arch/arm/boot/dts/stih407-family.dtsi | 28
> 1 file changed, 28 insertions(+)
>
On 05/25/2016 06:06 PM, Peter Griffin wrote:
> This patch enables the uniperif players 2 & 3 for b2120 boards
> and also adds the "simple-audio-card" device node to interconnect
> the SoC sound device and the codec.
>
> Signed-off-by: Peter Griffin
> ---
> arch/arm/boot/dts/stihxxx-b2120.dtsi
On 6/30/20 7:38 AM, Siddharth Gupta wrote:
>
> On 6/17/2020 1:44 AM, Arnaud POULIQUEN wrote:
>>
>> On 6/16/20 9:56 PM, risha...@codeaurora.org wrote:
>>> On 2020-04-30 01:30, Arnaud POULIQUEN wrote:
>>>> Hi Rishabh,
>>>>
>>>>
Hi Pierre-Louis,
On 7/7/20 9:16 PM, Pierre-Louis Bossart wrote:
> Fix W=1 warning. The table uni_tdm_hw is declared in a header included
> by multiple C file. This isn't really a good practice but for now
> using __maybe_unused makes the following warning go away.
>
> sound/soc/sti/sti_uniperif.c
not only known, it's intentional.
>
> Fixes the following W=1 kernel build warning(s):
>
> sound/soc/sti/uniperif.h:1351:38: warning: ‘uni_tdm_hw’ defined but not used
> [-Wunused-const-variable=]
> 1351 | static const struct snd_pcm_hardware uni_tdm_hw = {
> | ^~
hi
On 7/8/20 2:55 PM, Pierre-Louis Bossart wrote:
>
>
> On 7/8/20 4:11 AM, Arnaud POULIQUEN wrote:
>> Hi Pierre-Louis,
>>
>> On 7/7/20 9:16 PM, Pierre-Louis Bossart wrote:
>>> Fix W=1 warning. The table uni_tdm_hw is declared in a header included
>>>
Hi,
On 6/11/20 11:17 PM, Suman Anna wrote:
> On 6/10/20 11:39 PM, Bjorn Andersson wrote:
>> On Wed 10 Jun 02:40 PDT 2020, Paul Cercueil wrote:
>>
>>> Hi,
>>>
>>> Le lun. 8 juin 2020 à 18:10, Suman Anna a écrit :
Hi Paul,
On 6/8/20 5:46 PM, Paul Cercueil wrote:
> Hi Suman,
On 9/30/20 10:11 AM, Arnaud POULIQUEN wrote:
>
>
> On 9/29/20 12:17 AM, Rishabh Bhatnagar wrote:
>> Move recovery configuration from debugfs to sysfs.This will
>> allow usage of this configuration feature in production
>> devices where access to debugfs might be l
On 9/30/20 8:35 AM, Guennadi Liakhovetski wrote:
> On Mon, Sep 21, 2020 at 06:09:52PM -0600, Mathieu Poirier wrote:
>> From: Arnaud Pouliquen
>>
>> Add the channel creation API as a first step to be able to define the
>> name service announcement as a rpmsg driver
On 9/30/20 9:09 AM, Guennadi Liakhovetski wrote:
> On Mon, Sep 21, 2020 at 06:09:56PM -0600, Mathieu Poirier wrote:
>> From: Arnaud Pouliquen
>>
>> Make the RPMSG name service announcement a stand alone driver so that it
>> can be reused by other subsystems. I
Hi Mathieu
Thanks for the review! please find few comments below.
On 8/25/20 12:47 AM, Mathieu Poirier wrote:
> On Fri, Jul 31, 2020 at 01:47:28PM +0200, Arnaud Pouliquen wrote:
>> The name service announcement should not be linked to the RPMsg virtio bus
>> but to the RPMsg
On 8/25/20 12:48 AM, Mathieu Poirier wrote:
> On Fri, Jul 31, 2020 at 01:47:29PM +0200, Arnaud Pouliquen wrote:
>> As generic NS driver is available, rely on it for NS management instead of
>> managing it in RPMsg virtio bus.
>>
>> Signed-off-by: Arnaud Poulique
service announcement.
This first patch only implements the probe and the RPMsg endpoint to
manage create and release channels remote requests.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/Kconfig | 8 ++
drivers/rpmsg/Makefile | 1 +
drivers/rpmsg/rpmsg_internal.h | 17
Rename the internal function as it is internal, and as
the name will be used in rpmsg_core.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/virtio_rpmsg_bus.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg
Implement the create and release of the RPMsg channel
for the RPMsg virtio bus.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/virtio_rpmsg_bus.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg
Use the new rpmsg_ns API to send the name service announcements if
the VIRTIO_RPMSG_F_NS is set, else just not implement the ops.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/virtio_rpmsg_bus.c | 94 +---
1 file changed, 13 insertions(+), 81 deletions(-)
diff
The address 53 is reserved for the dynamic RPMsg device management
on name service announcement.
Define this address in a reserved enum list.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/virtio_rpmsg_bus.c | 3 ---
include/linux/rpmsg.h| 9 +
2 files changed, 9
corresponding to the ept created.
RPMSG_NS_ADDR as source address make sense as we want to send a message
belonging to the NS announcement service and the created ept address is
already in the message payload.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/rpmsg_internal.h | 3 +++
drivers/rpmsg
As generic NS driver is available, rely on it for NS management instead of
managing it in RPMsg virtio bus.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/Kconfig| 1 +
drivers/rpmsg/virtio_rpmsg_bus.c | 86
2 files changed, 21 insertions(+), 66
"[9/9] rpmsg: ns: name service announcement endianness"
in other pathes.
V1: https://patchwork.kernel.org/project/linux-remoteproc/list/?series=327257
Arnaud Pouliquen (8):
rpmsg: virtio: rename rpmsg_create_channel
rpmsg: core: add channel creation internal API
rpmsg: virtio: ad
Add the channel creation API as a first step to be able to define the
name service announcement as a rpmsg driver independent from the RPMsg
virtio bus.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/rpmsg_core.c | 45 ++
drivers/rpmsg/rpmsg_internal.h
Hi mathieu,
I Sent my V2 few seconds before receiving your comment :)
Please find my answer below
On 8/25/20 6:54 PM, Mathieu Poirier wrote:
> Hi Arnaud,
>
> On Fri, Jul 31, 2020 at 01:47:31PM +0200, Arnaud Pouliquen wrote:
>> Use the new rpmsg_ns API to send the name service a
On 8/27/20 12:10 AM, Mathieu Poirier wrote:
> I had another very long look at this... I haven't had the time to look in
> your
> next serie so the end result is not yet clear in my head. But...
>
> In __rpmsg_create_channel() the new code is testing for VIRTIO_RPMSG_F_NS in
> order to alloca
Add new properties description used to attach to a pre-loaded
firmware according to the commit 9276536f455b3
("remoteproc: stm32: Parse syscon that will manage M4 synchronisation")
which updates the driver part.
Signed-off-by: Arnaud Pouliquen
---
.../bindings/remoteproc/st,stm32-
Since commit ad440432d1f9 ("dt-bindings: mfd: Ensure 'syscon' has a
more specific compatible")
It is required to provide at least 2 compatibles string for syscon node.
This patch documents the new compatible for stm32 SoC to support
TAMP registers access.
Signed-off-
9276536f455b3
("remoteproc: stm32: Parse syscon that will manage M4 synchronisation").
Signed-off-by: Arnaud Pouliquen
---
arch/arm/boot/dts/stm32mp151.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp151.dtsi
b/arch/arm/boot/dts/stm32mp151.dtsi
index bf
This series implements the DT part associated to the commit 9276536f455b3
("remoteproc: stm32: Parse syscon that will manage M4 synchronisation")
Arnaud Pouliquen (3):
dt-bindings: arm: stm32: Add compatible for syscon tamp node
dt-bindings: remoteproc: stm32_rproc: update fo
On 9/29/20 12:17 AM, Rishabh Bhatnagar wrote:
> From Android R onwards Google has restricted access to debugfs in user
> and user-debug builds. This restricts access to most of the features
> exposed through debugfs. 'Coredump' and 'Recovery' are critical
> interfaces that are required for remot
On 9/29/20 4:33 PM, Bjorn Andersson wrote:
> On Tue 29 Sep 03:44 CDT 2020, Arnaud POULIQUEN wrote:
>
>>
>>
>> On 9/29/20 12:17 AM, Rishabh Bhatnagar wrote:
>>> From Android R onwards Google has restricted access to debugfs in user
>>> and user-debug bu
On 9/29/20 12:17 AM, Rishabh Bhatnagar wrote:
> Move recovery configuration from debugfs to sysfs.This will
> allow usage of this configuration feature in production
> devices where access to debugfs might be limited.
>
> Signed-off-by: Rishabh Bhatnagar
> ---
> Documentation/ABI/testing/sysf
Hi Bjorn,
On 9/26/20 5:31 AM, Bjorn Andersson wrote:
> On Tue 15 Sep 02:51 PDT 2020, Arnaud POULIQUEN wrote:
>
>> Hi Rishabh,
>>
>> On 8/27/20 9:48 PM, Rishabh Bhatnagar wrote:
>>> From Android R onwards Google has restricted access to debugfs in user
>>
Hi Mathieu,
On 5/4/20 11:58 PM, Mathieu Poirier wrote:
> After adding support for rpmsg device name extension, this patch
> provides a function that returns the extension portion of an rpmsg
> device name. That way users of the name extension functionality don't
> have to write the same boiler
On 5/6/20 12:03 AM, Mathieu Poirier wrote:
> On Mon, May 04, 2020 at 01:34:43PM +0200, Arnaud POULIQUEN wrote:
>>
>>
>> On 4/30/20 10:23 PM, Mathieu Poirier wrote:
>>> On Wed, Apr 29, 2020 at 10:19:49AM +0200, Arnaud POULIQUEN wrote:
>>>>
>>&g
Hi Mathieu,
On 6/1/20 7:51 PM, Mathieu Poirier wrote:
> This patch prevents the firmware image name from being displayed when
> the remoteproc core is attaching to a remote processor. This is needed
> needed since there is no guarantee about the nature of the firmware
> image that is loaded by the
Hi Mathieu,
On 6/1/20 7:51 PM, Mathieu Poirier wrote:
> This fourth iteration implements a solution that is fairly different from
> what was proposed in V3 and earlier versions. Three aspects have been
> revisited:
>
> 1) Only the scenario where the remoteproc core is attaching to the remote
>
on to construct the "Hello" message...
Acked-by: Arnaud Pouliquen
Regards,
Arnaud
> ---
> drivers/rpmsg/rpmsg_core.c | 95 ++
> include/linux/rpmsg.h | 13 ++
> 2 files changed, 108 insertions(+)
>
> diff --git a/drivers/r
Hi Mathieu,
On 9/4/20 1:00 AM, Mathieu Poirier wrote:
> On Tue, Aug 25, 2020 at 06:49:04PM +0200, Arnaud Pouliquen wrote:
>> The name service announcement should not be linked to the RPMsg virtio bus
>> but to the RPMsg protocol itself.
>>
>> This patch proposes to br
Hi Mathieu,
On 8/26/20 6:45 PM, Mathieu Poirier wrote:
> Following the work done here [1] this set provides support for the
> remoteproc core to release resources associated with a remote processor
> without having to switch it off. That way a platform driver can be removed
> or the applcation pro
-by: Mathieu Poirier
Acked-by: Arnaud Pouliquen
Thanks,
Arnaud
> ---
> drivers/remoteproc/stm32_rproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/stm32_rproc.c
> b/drivers/remoteproc/stm32_rproc.c
> index f4da42fc0ee
9276536f455b3
("remoteproc: stm32: Parse syscon that will manage M4 synchronisation").
Signed-off-by: Arnaud Pouliquen
---
arch/arm/boot/dts/stm32mp151.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp151.dtsi
b/arch/arm/boot/dts/stm32mp151.dtsi
index bf
Since commit ad440432d1f9 ("dt-bindings: mfd: Ensure 'syscon' has a
more specific compatible")
It is required to provide at least 2 compatibles string for syscon node.
This patch documents the new compatible for stm32 SoC to support
TAMP registers access.
Signed-off-by: Arnaud
Align other syscon descriptions with st,syscfg-m4-state and
st,syscfg-rsc-tbl descriptions by suppressing the cells
description.
Signed-off-by: Arnaud Pouliquen
---
.../devicetree/bindings/remoteproc/st,stm32-rproc.yaml | 6 --
1 file changed, 6 deletions(-)
diff --git a/Documentation
kernel.org/project/linux-arm-kernel/list/?series=339339
Arnaud Pouliquen (4):
dt-bindings: arm: stm32: Add compatible for syscon tamp node
dt-bindings: remoteproc: stm32_rproc: update for firmware
synchronization
dt-bindings: remoteproc: stm32_rproc: update syscon descriptions
ARM: dts: stm
Add new properties description used to attach to a pre-loaded
firmware according to the commit 9276536f455b3
("remoteproc: stm32: Parse syscon that will manage M4 synchronisation")
which updates the driver part.
Signed-off-by: Arnaud Pouliquen
---
.../bindings/remoteproc/st,stm32-
@@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Follows implementation found in linux/virtio_byteorder.h
> + */
> +#ifndef _LINUX_RPMSG_BYTEORDER_H
> +#define _LINUX_RPMSG_BYTEORDER_H
> +#include
> +#include
> +
> +static inline bool rpmsg_is_little_endian(v
On 10/14/20 1:25 AM, Mathieu Poirier wrote:
> Use rpmsg byte conversion functions in order for the RPMSG
> headers and generic functions to be used by external entities.
>
> Signed-off-by: Mathieu Poirier
> ---
> drivers/rpmsg/virtio_rpmsg_bus.c | 60 +++-
> 1 file
Hi Mathieu,
On 10/14/20 1:25 AM, Mathieu Poirier wrote:
> Move structures rpmsg_hdr and rpmsg_ns_msg to their own header file
> so that they can be used by other entities.
>
> Signed-off-by: Mathieu Poirier
> ---
> drivers/rpmsg/virtio_rpmsg_bus.c | 58 ++
> include/
nregister_rpmsg_device(struct rpmsg_device *dev)
> +static inline int rpmsg_unregister_device(struct device *parent,
> + struct rpmsg_channel_info *chinfo)
> {
> /* This shouldn't be possible */
> WARN_ON(1);
> +
> + return -ENXIO;
> }
>
> static inline int __register_rpmsg_driver(struct rpmsg_driver *drv,
>
Reviewed-by: Arnaud Pouliquen
Thanks,
Arnaud
@ -59,8 +79,6 @@ struct rpmsg_device {
> const struct rpmsg_device_ops *ops;
> };
>
> -typedef int (*rpmsg_rx_cb_t)(struct rpmsg_device *, void *, int, void *,
> u32);
> -
> /**
> * struct rpmsg_endpoint - binds a local rpmsg address to its user
> * @rpdev: rpmsg channel device
>
Reviewed-by: Arnaud Pouliquen
Thanks,
Arnaud
> Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
Thanks,
Arnaud
> ---
> include/linux/rpmsg.h| 51
> include/linux/rpmsg_byteorder.h | 67
> include/uapi/linux/rpmsg_types.h | 11 ++
>
On 10/19/20 10:34 PM, Mathieu Poirier wrote:
> Use rpmsg byte conversion functions in order for the RPMSG
> headers and generic functions to be used by external entities.
>
> Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
Thanks,
Arnaud
> ---
&
On 10/19/20 10:34 PM, Mathieu Poirier wrote:
> Move structure rpmsg_ns_msg to its own header file so that
> it can be used by other entities.
>
> Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
Thanks,
Arnaud
> ---
> drivers/rpmsg/virti
5
>
> ---
> New for V3:
> - Using rpmsg_device::little_endian variable rather than an operation
> - Fix an implementation problem that would have prevented git bisect to work
>
>
> Arnaud Pouliquen (4):
> rpmsg: virtio: Rename rpmsg_create_channel
> rpmsg: c
proc core is attaching
> to a remote processor that has already been started by another
> entity.
>
> Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
Thanks,
Arnaud
> ---
> drivers/remoteproc/remoteproc_core.c | 59 +++-
> 1 file chan
On 7/7/20 11:00 PM, Mathieu Poirier wrote:
> Add a new function to assert the general health of the remote
> processor before handing it to the remoteproc core.
>
> Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
Thanks,
Arnaud
> ---
> drivers/remoteproc
oaded by the external entity.
>
> Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
Thanks,
Arnaud
> ---
> drivers/remoteproc/remoteproc_core.c | 18 ++
> drivers/remoteproc/remoteproc_sysfs.c | 16 ++--
> include/linux/remoteproc.h
Hi Mathieu,
On 7/7/20 11:31 PM, Mathieu Poirier wrote:
> Introduce the required mechanic to set the state of the M4 in order
> to properly deal with scenarios where the co-processor has been
> started by another entity.
>
> Mainly based on the work published by Arnaud Pouliqu
te processor.
>
> Mainly based on the work published by Arnaud Pouliquen [1].
>
> [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877
>
> Signed-off-by: Mathieu Poirier
> ---
> drivers/remoteproc/stm32_rproc.c | 23 ---
> 1 file
h 04.
> 3) Used a 'case' statement in patch 05.
>
> Patches that need to be reviewed: 4, 5 and 9.
>
> Applies cleanly on rproc-next (49cff1256879)
I tested the series in different modes, no issue observed.
Tested-by: Arnaud Pouliquen
Thanks for your work!
Arnaud
---
> include/linux/remoteproc.h | 1 +
> 3 files changed, 198 insertions(+), 20 deletions(-)
>
I tested the series with the [1]
Minor remarks on patch 6 & 8. After fixing them, for the series:
Acked-by: Arnaud Pouliquen
Thank you very much for your work on this feature.
Arnaud
On 10/15/20 9:32 PM, Mathieu Poirier wrote:
> Good day,
>
> On Wed, Oct 14, 2020 at 06:31:49PM +0200, Arnaud POULIQUEN wrote:
>> Hi Mathieu,
>>
>> On 10/14/20 1:25 AM, Mathieu Poirier wrote:
>>> Introduce __rpmsg{16|32|64} types along with byte order
On 10/15/20 10:19 PM, Mathieu Poirier wrote:
> On Thu, Oct 15, 2020 at 10:33:25AM +0200, Arnaud POULIQUEN wrote:
>> Hi Mathieu,
>>
>> On 10/14/20 1:25 AM, Mathieu Poirier wrote:
>>> Move structures rpmsg_hdr and rpmsg_ns_msg to their own header file
>>
Hi Mathieu, Guennadi,
On 11/9/20 6:55 PM, Mathieu Poirier wrote:
> On Mon, Nov 09, 2020 at 11:20:24AM +0100, Guennadi Liakhovetski wrote:
>> Hi Arnaud,
>>
>> On Mon, Nov 09, 2020 at 09:48:37AM +0100, Arnaud POULIQUEN wrote:
>>> Hi Guennadi, Mathieu,
>>>
On 11/11/20 1:37 AM, Mathieu Poirier wrote:
> On Tue, 10 Nov 2020 at 11:18, Arnaud POULIQUEN
> wrote:
>>
>> Hi Mathieu, Guennadi,
>>
>> On 11/9/20 6:55 PM, Mathieu Poirier wrote:
>>> On Mon, Nov 09, 2020 at 11:20:24AM +0100, Guennadi Liakhovetski wrote
Hi Guennadi,
On 11/11/20 3:49 PM, Guennadi Liakhovetski wrote:
> Hi Arnaud,
>
> On Tue, Nov 10, 2020 at 07:18:45PM +0100, Arnaud POULIQUEN wrote:
>> Hi Mathieu, Guennadi,
>>
>> On 11/9/20 6:55 PM, Mathieu Poirier wrote:
>>> On Mon, Nov 09, 2020 at 11:20:24A
On 11/12/20 12:51 PM, Guennadi Liakhovetski wrote:
> Hi Arnaud,
>
> On Thu, Nov 12, 2020 at 11:17:54AM +0100, Arnaud POULIQUEN wrote:
>> Hi Guennadi,
>>
>> On 11/11/20 3:49 PM, Guennadi Liakhovetski wrote:
>>> Hi Arnaud,
>
> [snip]
>
>>
Hi Guennadi, Mathieu,
On 11/12/20 2:27 PM, Arnaud POULIQUEN wrote:
>
>
> On 11/12/20 12:51 PM, Guennadi Liakhovetski wrote:
>> Hi Arnaud,
>>
>> On Thu, Nov 12, 2020 at 11:17:54AM +0100, Arnaud POULIQUEN wrote:
>>> Hi Guennadi,
>>>
>>> On
Hi Guennadi,
On 11/16/20 4:10 PM, Guennadi Liakhovetski wrote:
> Hi Arnaud,
>
> On Mon, Nov 16, 2020 at 03:43:35PM +0100, Arnaud POULIQUEN wrote:
>> Hi Guennadi, Mathieu,
>
> [snip]
>
>> I tried the find_module API, it's quite simple and seems to work well.
Hi Mathieu,
On 11/16/20 11:40 PM, Mathieu Poirier wrote:
> On Mon, Nov 16, 2020 at 04:51:52PM +0100, Arnaud POULIQUEN wrote:
>> Hi Guennadi,
>>
>> On 11/16/20 4:10 PM, Guennadi Liakhovetski wrote:
[snip]
> I did a lot of probing, went deep in the bowels of the user mod
On 11/16/20 5:39 PM, Christoph Hellwig wrote:
> Btw, I also still don't understand why remoteproc is using
> dma_declare_coherent_memory to start with. The virtio code has exactly
> one call to dma_alloc_coherent vring_alloc_queue, a function that
> already switches between two different alloca
Hi all,
On 11/16/20 10:19 AM, Christoph Hellwig wrote:
> I just noticed this showing up in Linus' tree and I'm not happy.
>
> This whole model of the DMA subdevices in remoteproc is simply broken.
>
> We really need to change the virtio code pass an expicit DMA device (
> similar to what e.g. th
5, 2020 at 03:50:28PM -0700, Mathieu Poirier wrote:
>>>> From: Arnaud Pouliquen
>>>>
>>>> Make the RPMSG name service announcement a stand alone driver so that it
>>>> can be reused by other subsystems. It is also the first step in making the
>>
start,
> .stop = stm32_rproc_stop,
> .attach = stm32_rproc_attach,
>
acked-by: Arnaud Pouliquen
Thanks,
Arnaud
Hi Mathieu
> -Original Message-
> From: Mathieu Poirier
> Sent: mardi 14 juillet 2020 22:05
> To: o...@wizery.com; bjorn.anders...@linaro.org; Loic PALLARDY
> ; Arnaud POULIQUEN ;
> mcoquelin.st...@gmail.com; Alexandre TORGUE
>
> Cc: linux-remotep...@vger.
On 3/24/20 6:04 PM, Arnaud Pouliquen wrote:
> This patch set introduces a TTY console on top of the RPMsg framework which
> enables the following use cases:
> - Provide a console to communicate easily with the remote processor
> application.
> - Provide an interface to get the r
Hi mathieu,
On 9/19/20 1:10 AM, Mathieu Poirier wrote:
> Hey Arnaud,
>
> On Tue, Aug 25, 2020 at 06:49:04PM +0200, Arnaud Pouliquen wrote:
>> The name service announcement should not be linked to the RPMsg virtio bus
>> but to the RPMsg protocol itself.
>>
>>
Hi Rob,
On 9/9/20 10:22 PM, Rob Herring wrote:
> On Thu, Aug 27, 2020 at 09:21:00AM +0200, Arnaud Pouliquen wrote:
>> Add new properties description used to attach to a pre-loaded
>> firmware according to the commit 9276536f455b3
>> ("remoteproc: stm32: Parse
Hi Rishabh,
On 8/27/20 9:48 PM, Rishabh Bhatnagar wrote:
> From Android R onwards Google has restricted access to debugfs in user
> and user-debug builds. This restricts access to most of the features
> exposed through debugfs. This patch series adds a configurable option
> to move the recovery/co
Hi Ahmad,
On 9/24/20 7:45 AM, Ahmad Fatoum wrote:
> Hello Arnaud,
>
> On 8/27/20 9:21 AM, Arnaud Pouliquen wrote:
>> Two backup registers are used to store the Cortex-M4 state and the resource
>> table address.
>> Declare the tamp node and add associated properties i
On 9/22/20 2:09 AM, Mathieu Poirier wrote:
> Move structure virtiproc_info and virtio_rpmsg_channel to rpmsg_internal.h
> so that they can be used by rpmsg_ns.c
>
> Signed-off-by: Mathieu Poirier
> ---
> drivers/rpmsg/rpmsg_internal.h | 62
> drivers/rpmsg/v
On 9/22/20 2:09 AM, Mathieu Poirier wrote:
> Add RPMSG device specific byte conversion operations as a first
> step to separate the RPMSG name space service from the virtIO
> transport layer.
>
> Signed-off-by: Mathieu Poirier
> ---
> drivers/rpmsg/rpmsg_core.c | 51 ++
Hi Mathieu,
On 9/22/20 2:09 AM, Mathieu Poirier wrote:
> From: Guennadi Liakhovetski
>
> virtio_rpmsg_bus.c keeps RPMsg protocol structure declarations and
> common defines like the ones, needed for name-space announcements,
> internal. Move them to common headers instead.
>
> Signed-off-by: Gu
Hi Rob,
Gentle reminder.
As I'm not sure to well understand your comment I would appreciate if you could
confirm your expectation before I sent a v2.
Thanks in advance,
Arnaud
On 9/11/20 3:49 PM, Arnaud POULIQUEN wrote:
> Hi Rob,
>
> On 9/9/20 10:22 PM, Rob Herring wrote:
>
On 7/1/20 12:02 AM, Siddharth Gupta wrote:
>
> On 6/30/2020 12:43 AM, Arnaud POULIQUEN wrote:
>>
>> On 6/30/20 7:38 AM, Siddharth Gupta wrote:
>>> On 6/17/2020 1:44 AM, Arnaud POULIQUEN wrote:
>>>> On 6/16/20 9:56 PM, risha...@codeaurora.org wrote:
>
Hello Xiang,
On 5/9/19 3:00 PM, xiang xiao wrote:
> On Thu, May 9, 2019 at 8:36 PM Arnaud Pouliquen
> wrote:
>>
>> Hello Xiang,
>>
>> Similar mechanism has been proposed by Loic 2 years ago (link to the
>> series here https://lkml.org/lkml/2017/3/28/349
401 - 500 of 649 matches
Mail list logo
