y: Mathieu Poirier
> Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
Thanks,
Arnaud
> ---
> drivers/remoteproc/remoteproc_cdev.c | 6 ++
> drivers/remoteproc/remoteproc_sysfs.c | 6 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/remoteproc/re
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.
>
> Signed-off-by: Mathieu Poirier
> ---
> drivers/remoteproc/remoteproc_cdev.c | 13 +++-
> drivers/remoteproc/remotep
From: Etienne Carriere
Change stm32 remoteproc driver to not generate an error message
when device probe operation is deferred for the reset controller.
Signed-off-by: Etienne Carriere
Signed-off-by: Arnaud Pouliquen
---
drivers/remoteproc/stm32_rproc.c | 4 +++-
1 file changed, 3 insertions
On 12/9/20 3:06 PM, Ahmad Fatoum wrote:
> Hello Arnaud,
>
> On Wed, 2020-12-09 at 14:12 +0100, Arnaud Pouliquen wrote:
>> From: Etienne Carriere
>>
>> Change stm32 remoteproc driver to not generate an error message
>> when device probe operation is
On 12/9/20 10:18 PM, Mathieu Poirier wrote:
> 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,
&g
Hi Mathieu,
On 11/18/20 10:37 PM, 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
> functionatlity transport independent,
From: Arnaud Pouliquen
When possible use dev_err_probe help to properly deal with the
PROBE_DEFER error.
The benefit is that DEFER issue will be logged in the devices_deferred
debugfs file.
Signed-off-by: Arnaud Pouliquen
---
V1 to V2: As suggested by Ahmad Fatoum use dev_err_probe to deal
rm driver is removed.
>
> Signed-off-by: Mathieu Poirier
> Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
Thanks,
Arnaud
> ---
> include/linux/remoteproc.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.
remote processor is already in operation.
>
> Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
Thanks,
Arnaud
> ---
> drivers/remoteproc/remoteproc_cdev.c | 3 ++-
> drivers/remoteproc/remoteproc_sysfs.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions
On 11/26/20 10:06 PM, Mathieu Poirier wrote:
> 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
Thanks,
Arnaud
&
Hi Mathieu,
Just a minor comment, with that
Reviewed-by: Arnaud Pouliquen
On 3/10/21 10:10 PM, Mathieu Poirier wrote:
> If it is possible to detach the remote processor, keep an untouched
> copy of the resource table. That way we can start from the same
> resource table without
rest of the shutdown process.
>> + */
>> +if (rproc->cached_table)
>> +goto out;
>> +
>> +/* Remember where the external entity installed the resource table */
>> +table_ptr = rproc->table_ptr;
>> +
>
> Afaict th
To be coherent with the other functions which are prefixed by
rpmsg_chrdev, rename the rpmsg_char_init function.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/rpmsg_char.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg
e RPMsg devices
[1]: https://patchwork.kernel.org/project/linux-remoteproc/list/?series=435523
Arnaud Pouliquen (6):
rpmsg: char: Rename rpmsg_char_init to rpmsg_chrdev_init
rpmsg: Move RPMSG_ADDR_ANY in user API
rpmsg: Add short description of the IOCTL defined in UAPI.
rpmsg: char: Use
Add a description of the IOCTLs and provide information on the default
value of the source and destination addresses.
Signed-off-by: Arnaud Pouliquen
---
include/uapi/linux/rpmsg.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/rpmsg.h b
As the RPMSG_ADDR_ANY is a valid src or dst address that can be set by
user applications, migrate its definition in user API.
Signed-off-by: Arnaud Pouliquen
---
include/linux/rpmsg.h | 3 +--
include/uapi/linux/rpmsg.h | 2 ++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a
. For these drivers, the rpmsg_send and rpmsg_trysend ops are
preserved to avoid breaking the legacy.
Signed-off-by: Arnaud Pouliquen
---
update vs [1]
squash following patches in one:
rpmsg: glink: add sendto and trysendto ops
rpmsg: smd: add sendto and trysendto ops
rpmsg: char: use sendto
not associated to a channel.
As consequence, the endpoint source and destination addresses have to
been specified and there is no channel creation and no name service
announcement to inform the remote side.
Signed-off-by: Arnaud Pouliquen
---
update vs [1]
- rework the changelog
- remove useless
on the back-end to potentially detect the error.
Without this patch for instance the GLINK driver return -EBUSY while
the virtio bus return -ENOSPC.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/rpmsg_char.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/rpmsg/rpmsg_char.c b
Hi Mathieu,
On 1/22/21 12:52 AM, Mathieu Poirier wrote:
> On Tue, Dec 22, 2020 at 11:57:14AM +0100, Arnaud Pouliquen wrote:
>> Implement the ioctl function that parses the list of
>> rpmsg drivers registered to create an associated device.
>> To be ISO user API,
Hi Mathieu,
On 1/22/21 9:59 PM, Mathieu Poirier wrote:
> On Fri, Jan 22, 2021 at 02:05:27PM +0100, Arnaud POULIQUEN wrote:
>> Hi Mathieu,
>>
>> On 1/22/21 12:52 AM, Mathieu Poirier wrote:
>>> On Tue, Dec 22, 2020 at 11:57:14AM +0100, Arnaud Pouliquen wrote:
>>
Hi Mathieu,
Come back on you series...
On 12/18/20 6:32 PM, Mathieu Poirier wrote:
> 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 n
On 12/18/20 6:32 PM, Mathieu Poirier wrote:
> Introduce function __rproc_detach() to perform the same kind of
> operation as rproc_stop(), but instead of switching off the
> remote processor using rproc->ops->stop(), it uses
> rproc->ops->detach(). That way it is possible for the core
> to rele
BOL(rproc_shutdown);
>
> +/**
> + * rproc_detach() - Detach the remote processor from the
> + * remoteproc core
> + *
> + * @rproc: the remote processor
> + *
> + * Detach a remote processor (previously attached to with rproc_actuate()).
You rename the function to rproc_attach in yo
look good to me
Reviewed-by: Arnaud Pouliquen
On 12/18/20 6:32 PM, Mathieu Poirier wrote:
> 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
Hi Bjorn,
On 1/25/21 4:31 PM, Bjorn Andersson wrote:
> On Fri 15 Jan 03:13 CST 2021, Arnaud POULIQUEN wrote:
>
>> Hi Mathieu,
>>
>>
>> On 1/14/21 8:05 PM, Mathieu Poirier wrote:
>>> On Wed, Jan 06, 2021 at 02:37:14PM +0100, Arnaud Pouliquen wrote:
>&g
Hi Mathieu
On 12/18/20 6:32 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 application p
On 1/5/21 1:34 AM, Bjorn Andersson wrote:
> On Tue 22 Dec 04:57 CST 2020, Arnaud Pouliquen wrote:
>
>> Add API to register a RPMsg service to the control device.
>> The rpmsg_drv_ctrl_info structure links a service to its driver.
>>
>> Signed-off-by: Arnaud Pouli
Hello Bjorn,
On 1/5/21 12:03 AM, Bjorn Andersson wrote:
> On Tue 22 Dec 04:57 CST 2020, Arnaud Pouliquen wrote:
>
>> This series is a restructuring of the RPMsg char driver, to create a generic
>> RPMsg ioctl interface for all rpmsg services.
>>
>> The RPMsg char d
On 1/5/21 1:38 AM, Bjorn Andersson wrote:
> On Tue 22 Dec 04:57 CST 2020, Arnaud Pouliquen wrote:
>
>> By default driver_override should be 0 to avoid to force
>> the channel creation with a specified name.The local variable
>> is not initialized.
>>
&
On 1/5/21 1:54 AM, Bjorn Andersson wrote:
> On Mon 04 Jan 18:47 CST 2021, Bjorn Andersson wrote:
>
>> On Tue 22 Dec 04:57 CST 2020, Arnaud Pouliquen wrote:
>>
>> This patch doesn't "clean up" the class, as described in $subject. It
>> just remo
On 1/5/21 1:59 AM, Bjorn Andersson wrote:
> On Tue 22 Dec 04:57 CST 2020, Arnaud Pouliquen wrote:
>
>> Only one endpoint can be created per device, prevent from multi open.
>>
>
> Having multiple invocations of rpmsg_create_ept() with the same chinfo
> sounds like
On 1/5/21 2:03 AM, Bjorn Andersson wrote:
> On Tue 22 Dec 04:57 CST 2020, Arnaud Pouliquen wrote:
>
>> The name service announcement is not sent if no endpoint is created by
>> default. If the destination address is not precised by the
>> application when creating t
On 1/5/21 2:08 AM, Bjorn Andersson wrote:
> On Tue 22 Dec 04:57 CST 2020, Arnaud Pouliquen wrote:
>
>> Add the new ops introduced by the rpmsg_ns series and used
>> by the rpmsg_ctrl driver to instantiate a new rpmsg channel.
>>
>
> This is nice for completen
On 1/5/21 2:33 AM, Bjorn Andersson wrote:
> On Tue 22 Dec 04:57 CST 2020, Arnaud Pouliquen wrote:
>
>> Implement the ioctl function that parses the list of
>> rpmsg drivers registered to create an associated device.
>> To be ISO user API, in a first step, the driver_ove
point interface")
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/rpmsg_char.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
index 4bbbacdbf3bb..360a1ab0a9c4 100644
--- a/drivers/rpmsg/rpmsg_char.c
+++ b/drivers/rpmsg/rp
On 04/26/2016 01:02 PM, Peter Griffin wrote:
> Hi Mark,
>
> On Thu, 21 Apr 2016, Mark Brown wrote:
>
>> On Thu, Apr 21, 2016 at 12:04:26PM +0100, Peter Griffin wrote:
>>> uniperiph-id, version and mode are ST specific bindings and
>>> need the 'st,' prefix. Update the examples, as otherwise cop
hello Arnd, peter,
On 04/26/2016 01:44 PM, Arnd Bergmann wrote:
> On Tuesday 26 April 2016 12:15:32 Peter Griffin wrote:
>>>
If not what would you recommend instead?
>>>
>>> It's still not clear to me what that bit in the syscfg register
>>> is for. Given the error message about "sti-audio-c
Hello Gabriel,
Tested with success on stih407 family platforms
Reviewed-by: Arnaud Pouliquen
Tested-by: Arnaud Pouliquen
Regards
Arnaud
On 05/18/2016 10:41 AM, Gabriel Fernandez wrote:
> This serie allows to increase video resolutions and make audio
> adjustment during a video pl
On 9/5/19 6:18 PM, Jeffrey Hugo wrote:
On Thu, Sep 5, 2019 at 10:02 AM Arnaud Pouliquen
wrote:
Hi Jeffrey,
On 9/5/19 4:42 PM, Jeffrey Hugo wrote:
On Thu, Sep 5, 2019 at 8:35 AM Arnaud Pouliquen wrote:
Return the rpmsg buffer size for sending message, so rpmsg users
can split a long
Hi Suman,
Sorry for the delay in replying...
On 8/28/19 11:37 PM, Suman Anna wrote:
Hi Arnaud,
On 8/27/19 8:58 AM, Arnaud Pouliquen wrote:
Hi Suman,
On 8/16/19 1:14 AM, Suman Anna wrote:
From: Ohad Ben-Cohen
Add a new description field to the rpmsg bus infrastructure
that can be passed
hi Suman
On 8/29/19 12:34 AM, Suman Anna wrote:
Hi Arnaud,
On 8/28/19 10:19 AM, Arnaud Pouliquen wrote:
Return the rpmsg buffer size for sending message, so rpmsg users
can split a long message in several sub rpmsg buffers.
Thanks for the patch, I also have a need for the same to be able to
Hi Suman
On 9/3/19 6:06 PM, Suman Anna wrote:
Hi Arnaud,
On 9/3/19 4:49 AM, Arnaud Pouliquen wrote:
hi Suman
On 8/29/19 12:34 AM, Suman Anna wrote:
Hi Arnaud,
On 8/28/19 10:19 AM, Arnaud Pouliquen wrote:
Return the rpmsg buffer size for sending message, so rpmsg users
can split a long
Hi Suman,
On 8/16/19 1:14 AM, Suman Anna wrote:
From: Ohad Ben-Cohen
Add a new description field to the rpmsg bus infrastructure
that can be passed onto the rpmsg client drivers for additional
information. The current rpmsg bus client drivers need to have
a fixed id_table for proper matching,
Hi Suman,
Acked-by:Arnaud POULIQUEN
Thanks,
Arnaud
On 8/10/19 12:20 AM, Suman Anna wrote:
This patch adds a sysfs interface that provides the name of the
remote processor to userspace. This allows the userspace to identify
a remote processor as the remoteproc devices themselves are created
ba
pinlock on read
- miscellaneous fixes to improve robustness
Arnaud Pouliquen (2):
rpmsg: core: add API to get message length
tty: add rpmsg driver
Documentation/serial/tty_rpmsg.rst | 45
drivers/rpmsg/rpmsg_core.c | 21 ++
drivers/rpmsg/rpmsg_internal.h | 2 +
Return the rpmsg buffer size for sending message, so rpmsg users
can split a long message in several sub rpmsg buffers.
Signed-off-by: Arnaud Pouliquen
---
V4 to V5 :
- rename rpmsg_get_buf_payload_size to rpmsg_get_mtu
drivers/rpmsg/rpmsg_core.c | 21 +
drivers
This driver exposes a standard tty interface on top of the rpmsg
framework through a rpmsg service.
This driver supports multi-instances, offering a /dev/ttyRPMSGx entry
per rpmsg endpoint.
Signed-off-by: Arnaud Pouliquen
---
V4 to V5 :
- suppress the use of the first byte of the message to
Return the rpmsg buffer size for sending message, so rpmsg users
can split a long message in several sub rpmsg buffers.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/rpmsg_core.c | 21 +
drivers/rpmsg/rpmsg_internal.h | 2 ++
drivers/rpmsg/virtio_rpmsg_bus.c
This driver exposes a standard tty interface on top of the rpmsg
framework through a rpmsg service.
This driver supports multi-instances, offering a /dev/ttyRPMSGx entry
per rpmsg endpoint.
Signed-off-by: Arnaud Pouliquen
Signed-off-by: Fabien Dessenne
---
Documentation/serial/tty_rpmsg.rst
_trysend to not block the write
- suppress useless spinlock on read
- miscellaneous fixes to improve robustness
Arnaud Pouliquen (2):
rpmsg: core: add API to get message length
tty: add rpmsg driver
Documentation/serial/tty_rpmsg.rst | 45
drivers/rpmsg/rpmsg_core.
Hi Suman
On 9/4/19 6:36 PM, Suman Anna wrote:
Hi Arnaud,
On 9/4/19 8:09 AM, Arnaud Pouliquen wrote:
Return the rpmsg buffer size for sending message, so rpmsg users
can split a long message in several sub rpmsg buffers.
Couple more minor comments..
Signed-off-by: Arnaud Pouliquen
Hi Richard,
On 9/5/19 12:50 PM, Richard Genoud wrote:
Hi Arnaud,
Le 04/09/2019 à 15:09, Arnaud Pouliquen a écrit :
This driver exposes a standard tty interface on top of the rpmsg
framework through a rpmsg service.
This driver supports multi-instances, offering a /dev/ttyRPMSGx entry
per
Return the rpmsg buffer size for sending message, so rpmsg users
can split a long message in several sub rpmsg buffers.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/rpmsg_core.c | 21 +
drivers/rpmsg/rpmsg_internal.h | 2 ++
drivers/rpmsg/virtio_rpmsg_bus.c
Implement the get_mtu ops to return the maximum size of
the message that can be sent.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/qcom_smd.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
index 4abbeea782fa..f233f8d85062
don't have device to validate by myself...
Only a compilation check has been executed.
Arnaud Pouliquen (3):
rpmsg: core: add API to get message length
rpmsg: glink: implement get_mtu ops
rpmsg: smd: implement get_mtu ops
drivers/rpmsg/qcom_glink_native.c | 24
Implement the get_mtu ops to return the maximum size of
the message that can be sent.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/qcom_glink_native.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/rpmsg/qcom_glink_native.c
b/drivers/rpmsg
Hi Jeffrey,
On 9/5/19 4:42 PM, Jeffrey Hugo wrote:
On Thu, Sep 5, 2019 at 8:35 AM Arnaud Pouliquen wrote:
Return the rpmsg buffer size for sending message, so rpmsg users
can split a long message in several sub rpmsg buffers.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg
hi Mathieu,
On 4/30/20 9:57 PM, Mathieu Poirier wrote:
> On Tue, Apr 28, 2020 at 07:27:27PM +0200, Arnaud POULIQUEN wrote:
>>
>>
>> On 4/24/20 10:01 PM, Mathieu Poirier wrote:
>>> Call the right core function based on whether we should synchronise
>>>
On 4/30/20 10:23 PM, Mathieu Poirier wrote:
> On Wed, Apr 29, 2020 at 10:19:49AM +0200, Arnaud POULIQUEN wrote:
>>
>>
>> On 4/24/20 10:01 PM, Mathieu Poirier wrote:
>>> The remoteproc core must not allow function rproc_shutdown() to
>>> proceed if currentl
On 4/30/20 10:42 PM, Mathieu Poirier wrote:
> On Wed, Apr 29, 2020 at 11:22:28AM +0200, Arnaud POULIQUEN wrote:
>>
>>
>> On 4/24/20 10:01 PM, Mathieu Poirier wrote:
>>> Introducting function rproc_set_state_machine() to add
>>> operations and a set of fla
On 4/30/20 10:51 PM, Mathieu Poirier wrote:
> On Wed, Apr 29, 2020 at 04:38:54PM +0200, Arnaud POULIQUEN wrote:
>>
>>
>> On 4/29/20 11:22 AM, Arnaud POULIQUEN wrote:
>>>
>>>
>>> On 4/24/20 10:01 PM, Mathieu Poirier wrote:
>>>
Hi Rishabh,
On 4/21/20 8:10 PM, Rishabh Bhatnagar wrote:
> Add the character device interface into remoteproc framework.
> This interface can be used in order to boot/shutdown remote
> subsystems and provides a basic ioctl based interface to implement
> supplementary functionality. An ioctl call
Hi Mathieu,
On 4/24/20 10:01 PM, Mathieu Poirier wrote:
> When synchronizing with a remote processor, it is entirely possible that
> the remoteproc core is not the life cycle manager. In such a case core
> operations don't exist and should not be called.
What about ops in remote_core.c?
Applying
On 4/24/20 10:01 PM, Mathieu Poirier wrote:
> Add a new sync_ops to support use cases where the remoteproc
> core is synchronising with the remote processor. Exactly when to use
> the synchronisation operations is directed by the flags in structure
> rproc_sync_flags.
>
> Signed-off-by: Mathie
On 4/24/20 10:01 PM, Mathieu Poirier wrote:
> Refactor function rproc_trigger_auto_boot() so that it can deal with
> scenarios where the remote processor is already running. As such give
> it a new name to better represent the capabilities and add a call to
> rproc_boot() if instructed by the p
On 4/24/20 10:01 PM, Mathieu Poirier wrote:
> Call the right core function based on whether we should synchronise
> with a remote processor or boot it from scratch.
>
> Signed-off-by: Mathieu Poirier
> ---
> drivers/remoteproc/remoteproc_internal.h | 50
> 1 file chan
Hi Mathieu,
On 4/24/20 10:01 PM, Mathieu Poirier wrote:
> Refactor function rproc_trigger_recovery() in order to avoid
> reloading the firmware image when synchronising with a remote
> processor rather than booting it. Also part of the process,
> properly set the synchronisation flag in order to
On 4/24/20 10:01 PM, Mathieu Poirier wrote:
> The remoteproc core must not allow function rproc_shutdown() to
> proceed if currently synchronising with a remote processor and
> the synchronisation operations of that remote processor does not
> support it. Also part of the process is to set the
On 4/24/20 10:01 PM, Mathieu Poirier wrote:
> This patch prevents the firmware image from being displayed or changed
> when the remoteproc core is synchronising with a remote processor. This
> is needed since there is no guarantee about the nature of the firmware
> image that is loaded by the ex
On 4/24/20 10:01 PM, Mathieu Poirier wrote:
> Introducting function rproc_set_state_machine() to add
> operations and a set of flags to use when synchronising with
> a remote processor.
>
> Signed-off-by: Mathieu Poirier
> ---
> drivers/remoteproc/remoteproc_core.c | 54 ++
Hi Mathieu,
On 4/24/20 10:24 PM, Mathieu Poirier wrote:
> Remove the remote processor from the process of parsing the device tree
> since (1) there is no correlation between them and (2) to use the
> information that was gathered to make a decision on whether to
> synchronise with the M4 or not.
>
On 4/24/20 10:24 PM, Mathieu Poirier wrote:
> Introduce the required mechanic to get the state of the M4 when the
> remoteproc core is initialising.
>
> Mainly based on the work published by Arnaud Pouliquen [1].
>
> [1]. https://patchwork.kernel.org/project/linux-remot
On 4/29/20 11:22 AM, Arnaud POULIQUEN wrote:
>
>
> On 4/24/20 10:01 PM, Mathieu Poirier wrote:
>> Introducting function rproc_set_state_machine() to add
>> operations and a set of flags to use when synchronising with
>> a remote processor.
>>
On 4/24/20 10:25 PM, Mathieu Poirier wrote:
> Set the flags and operations to use if the M4 has been started
> by another entity than the remoteproc core.
>
> Signed-off-by: Mathieu Poirier
> ---
> drivers/remoteproc/stm32_rproc.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 d
On 4/24/20 10:25 PM, Mathieu Poirier wrote:
> Introduce new start functions to be used when synchonising with an MCU.
>
> Mainly based on the work published by Arnaud Pouliquen [1].
>
> [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877
>
> S
On 4/24/20 10:25 PM, Mathieu Poirier wrote:
> Update the M4 co-processor state in function stm32_rproc_stop() so
> that it can be used in synchronisation scenarios.
>
> Mainly based on the work published by Arnaud Pouliquen [1].
>
> [1]. https://patchwork.kernel.org/projec
Hi Mathieu,
On 4/24/20 10:24 PM, Mathieu Poirier wrote:
> This patchset needs to be applied on top of this one [1].
>
> It refactors the STM32 platform code in order to introduce support for
> synchronising with the M4 remote processor that would have been started by
> the boot loader or another
Hello Xiang,
I tested your patch on stm32 platform, no issue.
No remark on you code.
Acked-by:Arnaud POULIQUEN
Thanks,
Arnaud
On 1/31/19 4:41 PM, Xiang Xiao wrote:
> it's useful if the communication throughput is different from each side
>
> Signed-off-by: Xiang Xiao
> ---
> drivers/rpmsg/v
Hello Xiang,
This patch has the opposite effect on my platform as DMA allocation is
aligned on 4k page.
For instance i declared:
- in RX 6 buffers (of 512 bytes)
- in TX 4 buffers ( of 512 bytes)
The result is (kernel trace)
[ 41.915896] virtio_rpmsg_bus virtio0: rx buffers: va ebb5f5ca, dma
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).
Did you see them? Regarding history, patches seem just on hold...
Main differences (except interesting RX/TX size split) seems that you
- don't use the virtio_confi
This driver exposes a standard tty interface on top of the rpmsg
framework through the "rpmsg-tty-channel" rpmsg service.
This driver supports multi-instances, offering a /dev/ttyRPMSGx entry
per rpmsg endpoint.
Signed-off-by: Arnaud Pouliquen
Signed-off-by: Fabien Dessenne
---
Doc
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: Arnaud Pouliquen
Signed-off-by: Fabien Dessenne
---
drivers/rpmsg/rpmsg_core.c | 20
drivers/rpmsg/rpmsg_internal.h | 2
modes that generates non optimized behavior on RPMsg
transfers
- replace rpmsg_send by rpmsg_trysend to not block the write
- suppress useless spinlock on read.
- miscellaneous fixes to improve robustness
Arnaud Pouliquen (2):
rpmsg: core: add possibility to get messa
Add spinlock protection on IPCC register update to avoid race condition.
Without this fix, stm32_ipcc_set_bits and stm32_ipcc_clr_bits can be
called in parallel for different channels. This results in register
corruptions.
Signed-off-by: Arnaud Pouliquen
---
drivers/mailbox/stm32-ipcc.c | 37
Hello Jiri,
On 5/22/19 11:01 AM, Jiri Slaby wrote:
> On 17. 05. 19, 16:27, Arnaud Pouliquen wrote:
>> This driver exposes a standard tty interface on top of the rpmsg
>> framework through the "rpmsg-tty-channel" rpmsg service.
>>
>> This driver supports multi
This driver exposes a standard tty interface on top of the rpmsg
framework through the "rpmsg-tty-channel" rpmsg service.
This driver supports multi-instances, offering a /dev/ttyRPMSGx entry
per rpmsg endpoint.
Signed-off-by: Arnaud Pouliquen
Signed-off-by: Fabien Dessenne
---
Doc
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: Arnaud Pouliquen
Signed-off-by: Fabien Dessenne
---
drivers/rpmsg/rpmsg_core.c | 20
drivers/rpmsg/rpmsg_internal.h | 2
pmsg_trysend to not block the write
- suppress useless spinlock on read
- miscellaneous fixes to improve robustness
Arnaud Pouliquen (2):
rpmsg: core: add possibility to get message payload length
tty: add rpmsg driver
Documentation/serial/tty_rpmsg.rst | 43
drivers/rpm
j-$(CONFIG_GOLDFISH_TTY) += goldfish.o
>> obj-$(CONFIG_MIPS_EJTAG_FDC_TTY) += mips_ejtag_fdc.o
>> obj-$(CONFIG_VCC) += vcc.o
>> +obj-$(CONFIG_RPMSG_TTY)+= rpmsg_tty.o
>>
>> obj-y += ipwireless/
>> diff --git a/dr
This patch fixes the sai driver structure overwriting which results in
a cpu dai name equal NULL.
Fixes: 3e086ed ("ASoC: stm32: add SAI driver")
Signed-off-by: Arnaud Pouliquen
---
sound/soc/stm/stm32_sai_sub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sou
Suppress the useless dynamic allocation of the dai driver structure.
Signed-off-by: Arnaud Pouliquen
---
sound/soc/stm/stm32_sai_sub.c | 43 +--
1 file changed, 9 insertions(+), 34 deletions(-)
diff --git a/sound/soc/stm/stm32_sai_sub.c b/sound/soc/stm
On 4/5/19 12:12 PM, xiang xiao wrote:
> On Fri, Apr 5, 2019 at 12:14 AM Arnaud Pouliquen
> wrote:
>>
>> Hello Xiang,
>>
>>
>> On 4/3/19 2:47 PM, xiang xiao wrote:
>>> On Thu, Mar 21, 2019 at 11:48 PM Fabien Dessenne
>>> wrote:
>>&g
On 4/5/19 4:03 PM, xiang xiao wrote:
> On Fri, Apr 5, 2019 at 8:33 PM Arnaud Pouliquen
> wrote:
>>
>>
>>
>> On 4/5/19 12:12 PM, xiang xiao wrote:
>>> On Fri, Apr 5, 2019 at 12:14 AM Arnaud Pouliquen
>>> wrote:
>>>>
>>
Hello Vinod,
Just a gentle reminder, if you could take a moment to review this patch.
FYI, the patch has already been internally reviewed by Pierre Yves
mordret...
His sign-off is in the commit message.
Thanks,
Arnaud
On 3/27/19 1:21 PM, Arnaud Pouliquen wrote:
> During residue calculat
Suppress the useless dynamic allocation of the dai driver structure.
Signed-off-by: Arnaud Pouliquen
---
V1 to V2:
- add "sai" in commit title to identify the driver
- add reviewed-by
sound/soc/stm/stm32_sai_sub.c | 43 +--
1 file changed, 9
Hi Vinod
On 4/26/19 2:17 PM, Vinod Koul wrote:
> Hi Arnaud,
>
> Sorry for delay in review, the conference travel/vacation plan delayed
> this.
no problem, just a rememder to be sure that you not missed it in the
patch stream.
>
> On 27-03-19, 13:21, Arnaud Pouliquen wrote:
On 4/29/19 7:13 AM, Vinod Koul wrote:
> On 26-04-19, 15:41, Arnaud Pouliquen wrote:
>>>> During residue calculation. the DMA can switch to the next sg. When
>>>> this race condition occurs, the residue returned value is not valid.
>>>> Indeed the positio
On 4/30/19 10:22 AM, Vinod Koul wrote:
> On 29-04-19, 16:52, Arnaud Pouliquen wrote:
>>
>>
>> On 4/29/19 7:13 AM, Vinod Koul wrote:
>>> On 26-04-19, 15:41, Arnaud Pouliquen wrote:
>>>>>> During residue calculation. the DMA can switch to the next
is detected we consider that the DMA has switched to
the beginning of next sg.
Signed-off-by: Arnaud Pouliquen
Signed-off-by: Pierre-Yves MORDRET
---
V1 to V2 update:
Change of the comments to provide better explanation of the race condition.
---
drivers/dma/stm32-dma.c | 90
301 - 400 of 649 matches
Mail list logo
