mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-11-24 14:30:58 +07:00
rpmsg: Move rpmsg_device API to new file
Extract the now indirect rpmsg_create_ept() interface to a separate file and start building up a rpmsg core. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
This commit is contained in:
parent
36b72c7dca
commit
026dad47a8
@ -17,7 +17,7 @@ config OMAP_REMOTEPROC
|
||||
select REMOTEPROC
|
||||
select MAILBOX
|
||||
select OMAP2PLUS_MBOX
|
||||
select RPMSG
|
||||
select RPMSG_VIRTIO
|
||||
help
|
||||
Say y here to support OMAP's remote processors (dual M3
|
||||
and DSP on OMAP4) via the remote processor framework.
|
||||
@ -59,7 +59,7 @@ config DA8XX_REMOTEPROC
|
||||
depends on ARCH_DAVINCI_DA8XX
|
||||
select CMA if MMU
|
||||
select REMOTEPROC
|
||||
select RPMSG
|
||||
select RPMSG_VIRTIO
|
||||
help
|
||||
Say y here to support DA8xx/OMAP-L13x remote processors via the
|
||||
remote processor framework.
|
||||
|
@ -3,6 +3,10 @@ menu "Rpmsg drivers"
|
||||
# RPMSG always gets selected by whoever wants it
|
||||
config RPMSG
|
||||
tristate
|
||||
|
||||
config RPMSG_VIRTIO
|
||||
tristate
|
||||
select RPMSG
|
||||
select VIRTIO
|
||||
select VIRTUALIZATION
|
||||
|
||||
|
@ -1 +1,2 @@
|
||||
obj-$(CONFIG_RPMSG) += virtio_rpmsg_bus.o
|
||||
obj-$(CONFIG_RPMSG) += rpmsg_core.o
|
||||
obj-$(CONFIG_RPMSG_VIRTIO) += virtio_rpmsg_bus.o
|
||||
|
71
drivers/rpmsg/rpmsg_core.c
Normal file
71
drivers/rpmsg/rpmsg_core.c
Normal file
@ -0,0 +1,71 @@
|
||||
/*
|
||||
* remote processor messaging bus
|
||||
*
|
||||
* Copyright (C) 2011 Texas Instruments, Inc.
|
||||
* Copyright (C) 2011 Google, Inc.
|
||||
*
|
||||
* Ohad Ben-Cohen <ohad@wizery.com>
|
||||
* Brian Swetland <swetland@google.com>
|
||||
*
|
||||
* This software is licensed under the terms of the GNU General Public
|
||||
* License version 2, as published by the Free Software Foundation, and
|
||||
* may be copied, distributed, and modified under those terms.
|
||||
*
|
||||
* This program is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*/
|
||||
|
||||
#define pr_fmt(fmt) "%s: " fmt, __func__
|
||||
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/rpmsg.h>
|
||||
|
||||
/**
|
||||
* rpmsg_create_ept() - create a new rpmsg_endpoint
|
||||
* @rpdev: rpmsg channel device
|
||||
* @cb: rx callback handler
|
||||
* @priv: private data for the driver's use
|
||||
* @chinfo: channel_info with the local rpmsg address to bind with @cb
|
||||
*
|
||||
* Every rpmsg address in the system is bound to an rx callback (so when
|
||||
* inbound messages arrive, they are dispatched by the rpmsg bus using the
|
||||
* appropriate callback handler) by means of an rpmsg_endpoint struct.
|
||||
*
|
||||
* This function allows drivers to create such an endpoint, and by that,
|
||||
* bind a callback, and possibly some private data too, to an rpmsg address
|
||||
* (either one that is known in advance, or one that will be dynamically
|
||||
* assigned for them).
|
||||
*
|
||||
* Simple rpmsg drivers need not call rpmsg_create_ept, because an endpoint
|
||||
* is already created for them when they are probed by the rpmsg bus
|
||||
* (using the rx callback provided when they registered to the rpmsg bus).
|
||||
*
|
||||
* So things should just work for simple drivers: they already have an
|
||||
* endpoint, their rx callback is bound to their rpmsg address, and when
|
||||
* relevant inbound messages arrive (i.e. messages which their dst address
|
||||
* equals to the src address of their rpmsg channel), the driver's handler
|
||||
* is invoked to process it.
|
||||
*
|
||||
* That said, more complicated drivers might do need to allocate
|
||||
* additional rpmsg addresses, and bind them to different rx callbacks.
|
||||
* To accomplish that, those drivers need to call this function.
|
||||
*
|
||||
* Drivers should provide their @rpdev channel (so the new endpoint would belong
|
||||
* to the same remote processor their channel belongs to), an rx callback
|
||||
* function, an optional private data (which is provided back when the
|
||||
* rx callback is invoked), and an address they want to bind with the
|
||||
* callback. If @addr is RPMSG_ADDR_ANY, then rpmsg_create_ept will
|
||||
* dynamically assign them an available rpmsg address (drivers should have
|
||||
* a very good reason why not to always use RPMSG_ADDR_ANY here).
|
||||
*
|
||||
* Returns a pointer to the endpoint on success, or NULL on error.
|
||||
*/
|
||||
struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev,
|
||||
rpmsg_rx_cb_t cb, void *priv,
|
||||
struct rpmsg_channel_info chinfo)
|
||||
{
|
||||
return rpdev->ops->create_ept(rpdev, cb, priv, chinfo);
|
||||
}
|
||||
EXPORT_SYMBOL(rpmsg_create_ept);
|
@ -242,54 +242,6 @@ static struct rpmsg_endpoint *__rpmsg_create_ept(struct virtproc_info *vrp,
|
||||
return NULL;
|
||||
}
|
||||
|
||||
/**
|
||||
* rpmsg_create_ept() - create a new rpmsg_endpoint
|
||||
* @rpdev: rpmsg channel device
|
||||
* @cb: rx callback handler
|
||||
* @priv: private data for the driver's use
|
||||
* @chinfo: channel_info with the local rpmsg address to bind with @cb
|
||||
*
|
||||
* Every rpmsg address in the system is bound to an rx callback (so when
|
||||
* inbound messages arrive, they are dispatched by the rpmsg bus using the
|
||||
* appropriate callback handler) by means of an rpmsg_endpoint struct.
|
||||
*
|
||||
* This function allows drivers to create such an endpoint, and by that,
|
||||
* bind a callback, and possibly some private data too, to an rpmsg address
|
||||
* (either one that is known in advance, or one that will be dynamically
|
||||
* assigned for them).
|
||||
*
|
||||
* Simple rpmsg drivers need not call rpmsg_create_ept, because an endpoint
|
||||
* is already created for them when they are probed by the rpmsg bus
|
||||
* (using the rx callback provided when they registered to the rpmsg bus).
|
||||
*
|
||||
* So things should just work for simple drivers: they already have an
|
||||
* endpoint, their rx callback is bound to their rpmsg address, and when
|
||||
* relevant inbound messages arrive (i.e. messages which their dst address
|
||||
* equals to the src address of their rpmsg channel), the driver's handler
|
||||
* is invoked to process it.
|
||||
*
|
||||
* That said, more complicated drivers might do need to allocate
|
||||
* additional rpmsg addresses, and bind them to different rx callbacks.
|
||||
* To accomplish that, those drivers need to call this function.
|
||||
*
|
||||
* Drivers should provide their @rpdev channel (so the new endpoint would belong
|
||||
* to the same remote processor their channel belongs to), an rx callback
|
||||
* function, an optional private data (which is provided back when the
|
||||
* rx callback is invoked), and an address they want to bind with the
|
||||
* callback. If @addr is RPMSG_ADDR_ANY, then rpmsg_create_ept will
|
||||
* dynamically assign them an available rpmsg address (drivers should have
|
||||
* a very good reason why not to always use RPMSG_ADDR_ANY here).
|
||||
*
|
||||
* Returns a pointer to the endpoint on success, or NULL on error.
|
||||
*/
|
||||
struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev,
|
||||
rpmsg_rx_cb_t cb, void *priv,
|
||||
struct rpmsg_channel_info chinfo)
|
||||
{
|
||||
return rpdev->ops->create_ept(rpdev, cb, priv, chinfo);
|
||||
}
|
||||
EXPORT_SYMBOL(rpmsg_create_ept);
|
||||
|
||||
static struct rpmsg_endpoint *virtio_rpmsg_create_ept(struct rpmsg_device *rpdev,
|
||||
rpmsg_rx_cb_t cb,
|
||||
void *priv,
|
||||
|
Loading…
Reference in New Issue
Block a user