rpmsg: Move rpmsg_device API to new file (026dad47) · Commits · e / devices / android_kernel_teracube_mt6765

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,