Commit 026dad47 authored by Bjorn Andersson's avatar Bjorn Andersson
Browse files

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: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
parent 36b72c7d

drivers/remoteproc/Kconfig

+2 −2
Original line number Diff line number Diff line
@@ -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.

drivers/rpmsg/Kconfig

+4 −0
Original line number Diff line number Diff line
@@ -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

drivers/rpmsg/Makefile

+2 −1
Original line number Diff line number Diff line 
obj-$(CONFIG_RPMSG)	+= virtio_rpmsg_bus.o
 
obj-$(CONFIG_RPMSG)		+= rpmsg_core.o

obj-$(CONFIG_RPMSG_VIRTIO)	+= virtio_rpmsg_bus.o

drivers/rpmsg/rpmsg_core.c

0 → 100644
+71 −0
Original line number Diff line number Diff line 
/*

 * 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);

drivers/rpmsg/virtio_rpmsg_bus.c

+0 −48
Original line number Diff line number Diff line
@@ -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,