linux/drivers/rpmsg/Kconfig

41 lines
980 B
Plaintext
Raw Normal View History

menu "Rpmsg drivers"
# RPMSG always gets selected by whoever wants it
config RPMSG
tristate
rpmsg: Driver for user space endpoint interface This driver allows rpmsg instances to expose access to rpmsg endpoints to user space processes. It provides a control interface, allowing userspace to export endpoints and an endpoint interface for each exposed endpoint. The implementation is based on prior art by Texas Instrument, Google, PetaLogix and was derived from a FreeRTOS performance statistics driver written by Michal Simek. The control interface provides a "create endpoint" ioctl, which is fed a name, source and destination address. The three values are used to create the endpoint, in a backend-specific way, and a rpmsg endpoint device is created - with the three parameters are available in sysfs for udev usage. E.g. to create an endpoint device for one of the Qualcomm SMD channel related to DIAG one would issue: struct rpmsg_endpoint_info info = { "DIAG_CNTL", 0, 0 }; int fd = open("/dev/rpmsg_ctrl0", O_RDWR); ioctl(fd, RPMSG_CREATE_EPT_IOCTL, &info); Each created endpoint device shows up as an individual character device in /dev, allowing permission to be controlled on a per-endpoint basis. The rpmsg endpoint will be created and destroyed following the opening and closing of the endpoint device, allowing rpmsg backends to open and close the physical channel, if supported by the wire protocol. Cc: Marek Novak <marek.novak@nxp.com> Cc: Matteo Sartori <matteo.sartori@t3lab.it> Cc: Michal Simek <monstr@monstr.eu> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2017-01-11 22:35:12 +08:00
config RPMSG_CHAR
tristate "RPMSG device interface"
depends on RPMSG
depends on NET
rpmsg: Driver for user space endpoint interface This driver allows rpmsg instances to expose access to rpmsg endpoints to user space processes. It provides a control interface, allowing userspace to export endpoints and an endpoint interface for each exposed endpoint. The implementation is based on prior art by Texas Instrument, Google, PetaLogix and was derived from a FreeRTOS performance statistics driver written by Michal Simek. The control interface provides a "create endpoint" ioctl, which is fed a name, source and destination address. The three values are used to create the endpoint, in a backend-specific way, and a rpmsg endpoint device is created - with the three parameters are available in sysfs for udev usage. E.g. to create an endpoint device for one of the Qualcomm SMD channel related to DIAG one would issue: struct rpmsg_endpoint_info info = { "DIAG_CNTL", 0, 0 }; int fd = open("/dev/rpmsg_ctrl0", O_RDWR); ioctl(fd, RPMSG_CREATE_EPT_IOCTL, &info); Each created endpoint device shows up as an individual character device in /dev, allowing permission to be controlled on a per-endpoint basis. The rpmsg endpoint will be created and destroyed following the opening and closing of the endpoint device, allowing rpmsg backends to open and close the physical channel, if supported by the wire protocol. Cc: Marek Novak <marek.novak@nxp.com> Cc: Matteo Sartori <matteo.sartori@t3lab.it> Cc: Michal Simek <monstr@monstr.eu> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2017-01-11 22:35:12 +08:00
help
Say Y here to export rpmsg endpoints as device files, usually found
in /dev. They make it possible for user-space programs to send and
receive rpmsg packets.
config RPMSG_QCOM_GLINK_RPM
tristate "Qualcomm RPM Glink driver"
select RPMSG
depends on HAS_IOMEM
depends on MAILBOX
help
Say y here to enable support for the GLINK RPM communication driver,
which serves as a channel for communication with the RPM in GLINK
enabled systems.
config RPMSG_QCOM_SMD
tristate "Qualcomm Shared Memory Driver (SMD)"
depends on QCOM_SMEM
select RPMSG
help
Say y here to enable support for the Qualcomm Shared Memory Driver
providing communication channels to remote processors in Qualcomm
platforms.
config RPMSG_VIRTIO
tristate
select RPMSG
select VIRTIO
endmenu