| Message ID | 20211220161155.32564-1-arnaud.pouliquen@foss.st.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] ARM: multi_v7_defconfig: Enable CONFIG_RPMSG_TTY | expand |
On Mon, Dec 20, 2021 at 05:11:55PM +0100, Arnaud Pouliquen wrote: > The RPMsg TTY implements an inter-processor communication with a standard > TTY interface on top of the RPMsg framework. > This driver is a generic RPMsg client that can run on different platforms. > > By enabling the RPMSG_TTY driver as module in multi_v7_defconfig, it makes > possible to automatically probe the rpmsg_tty driver by the RPMsg bus, > when the support of the RPMsg service is dynamically requested by the > co-processor firmware. > > Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> > --- > delta vs V1: > add > --- "add"? What does that mean? Do all v7 chips have this hardware? thanks, greg k-h
On 12/20/21 5:58 PM, Greg Kroah-Hartman wrote: > On Mon, Dec 20, 2021 at 05:11:55PM +0100, Arnaud Pouliquen wrote: >> The RPMsg TTY implements an inter-processor communication with a standard >> TTY interface on top of the RPMsg framework. >> This driver is a generic RPMsg client that can run on different platforms. >> >> By enabling the RPMSG_TTY driver as module in multi_v7_defconfig, it makes >> possible to automatically probe the rpmsg_tty driver by the RPMsg bus, >> when the support of the RPMsg service is dynamically requested by the >> co-processor firmware. >> >> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> >> --- >> delta vs V1: >> add >> --- > > "add"? What does that mean? Oops, sorry, part of my sentence has disappeared "Add more description in commit message to detail the objective ". > > Do all v7 chips have this hardware? I would say yes and no No - As mainly used today for hardware system integrating a main and a coprocessor in a single chip. Yes - as that depends on the RPMsg back-end The RPMsg is divided in 3 layers - the service layer that implement a service on top of the RPmsg A parallel could be done between this layer and the Virtio devices such as the "Virtio-Console". => the rpmsg _tty is part of this layer => rpmsg_char is another one ( already enabled in some configs) - the transport layer in charge of the RPmsg protocol - the back-end layer that is the hardware abstraction layer - The main back-end used is the RPMsg VirtIO back-end which implements the RPMSg over VirtIO. - There are also some platform specific backends (e.g. QCOM, MediaTek) - We have also some demos that implement the RPMsg protocol on top of a serial link back-end allowing communication with an external processor. Not up-streamed yet. Thanks, Arnaud > > thanks, > > greg k-h >
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index c951aeed2138..370ca4ae3981 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -372,6 +372,7 @@ CONFIG_SERIAL_ST_ASC_CONSOLE=y CONFIG_SERIAL_STM32=y CONFIG_SERIAL_STM32_CONSOLE=y CONFIG_SERIAL_OWL=y +CONFIG_RPMSG_TTY=m CONFIG_SERIAL_DEV_BUS=y CONFIG_VIRTIO_CONSOLE=y CONFIG_ASPEED_KCS_IPMI_BMC=m
The RPMsg TTY implements an inter-processor communication with a standard TTY interface on top of the RPMsg framework. This driver is a generic RPMsg client that can run on different platforms. By enabling the RPMSG_TTY driver as module in multi_v7_defconfig, it makes possible to automatically probe the rpmsg_tty driver by the RPMsg bus, when the support of the RPMsg service is dynamically requested by the co-processor firmware. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> --- delta vs V1: add --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+)