From: bjorn.andersson@linaro.org (Bjorn Andersson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 07/17] rpmsg: Move rpmsg_device API to new file
Date: Thu, 1 Sep 2016 15:27:59 -0700 [thread overview]
Message-ID: <1472768889-3906-8-git-send-email-bjorn.andersson@linaro.org> (raw)
In-Reply-To: <1472768889-3906-1-git-send-email-bjorn.andersson@linaro.org>
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>
---
Changes since v1:
- Extracted the big move into several smaller patches
drivers/remoteproc/Kconfig | 4 +--
drivers/rpmsg/Kconfig | 4 +++
drivers/rpmsg/Makefile | 3 +-
drivers/rpmsg/rpmsg_core.c | 71 ++++++++++++++++++++++++++++++++++++++++
drivers/rpmsg/virtio_rpmsg_bus.c | 48 ---------------------------
5 files changed, 79 insertions(+), 51 deletions(-)
create mode 100644 drivers/rpmsg/rpmsg_core.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 1a8bf76a925f..70ec8130622d 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -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.
diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
index 69a219387582..40614be88c97 100644
--- a/drivers/rpmsg/Kconfig
+++ b/drivers/rpmsg/Kconfig
@@ -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
diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
index 7617fcb8259f..c48ea55ad380 100644
--- a/drivers/rpmsg/Makefile
+++ b/drivers/rpmsg/Makefile
@@ -1 +1,2 @@
-obj-$(CONFIG_RPMSG) += virtio_rpmsg_bus.o
+obj-$(CONFIG_RPMSG) += rpmsg_core.o
+obj-$(CONFIG_RPMSG_VIRTIO) += virtio_rpmsg_bus.o
diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
new file mode 100644
index 000000000000..c511b5d64f89
--- /dev/null
+++ b/drivers/rpmsg/rpmsg_core.c
@@ -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);
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 088203ed1df8..605e09c96d65 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -242,54 +242,6 @@ free_ept:
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,
--
2.5.0
next prev parent reply other threads:[~2016-09-01 22:27 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-01 22:27 [PATCH v2 00/17] Make rpmsg a framework Bjorn Andersson
2016-09-01 22:27 ` [PATCH v2 01/17] rpmsg: Enable matching devices with drivers based on DT Bjorn Andersson
2016-09-08 1:46 ` spjoshi at codeaurora.org
2016-09-09 4:30 ` Bjorn Andersson
2016-09-09 22:07 ` Sarangdhar Joshi
2016-09-01 22:27 ` [PATCH v2 02/17] rpmsg: Name rpmsg devices based on channel id Bjorn Andersson
2016-09-08 1:46 ` spjoshi at codeaurora.org
2016-09-01 22:27 ` [PATCH v2 03/17] rpmsg: rpmsg_send() operations takes rpmsg_endpoint Bjorn Andersson
2016-09-01 22:27 ` [PATCH v2 04/17] rpmsg: Make rpmsg_create_ept() take channel_info struct Bjorn Andersson
2016-09-01 22:27 ` [PATCH v2 05/17] rpmsg: Clean up rpmsg device vs channel naming Bjorn Andersson
2016-09-01 22:27 ` [PATCH v2 06/17] rpmsg: Introduce indirection table for rpmsg_device operations Bjorn Andersson
2016-09-01 22:27 ` Bjorn Andersson [this message]
2016-09-01 22:28 ` [PATCH v2 08/17] rpmsg: Indirection table for rpmsg_endpoint operations Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 09/17] rpmsg: Move endpoint related interface to rpmsg core Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 10/17] rpmsg: Move helper for finding rpmsg devices to core Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 11/17] rpmsg: Split off generic tail of create_channel() Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 12/17] rpmsg: Split rpmsg core and virtio backend Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 13/17] rpmsg: Hide rpmsg indirection tables Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 14/17] rpmsg: virtio: Hide vrp pointer from the public API Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 15/17] rpmsg: Move virtio specifics from public header Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 16/17] rpmsg: Allow callback to return errors Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 17/17] rpmsg: Introduce Qualcomm SMD backend Bjorn Andersson
2016-09-12 16:52 ` [PATCH v2 00/17] Make rpmsg a framework Lina Iyer
2016-09-12 18:00 ` Bjorn Andersson
2016-09-12 18:13 ` Jeffrey Hugo
2016-09-12 18:49 ` Bjorn Andersson
2016-09-12 19:21 ` Jeffrey Hugo
2016-09-12 19:58 ` Bjorn Andersson
2016-09-12 21:36 ` Karthikeyan Ramasubramanian
2016-09-12 21:53 ` Bjorn Andersson
2016-09-12 22:22 ` Lina Iyer
2016-09-12 22:58 ` Bjorn Andersson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1472768889-3906-8-git-send-email-bjorn.andersson@linaro.org \
--to=bjorn.andersson@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).