From: Bjorn Andersson <bjorn.andersson@linaro.org> To: Ohad Ben-Cohen <ohad@wizery.com>, Bjorn Andersson <bjorn.andersson@linaro.org> Cc: linux-remoteproc@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.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
WARNING: multiple messages have this Message-ID (diff)
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: 68+ 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 ` Bjorn Andersson 2016-09-01 22:27 ` [PATCH v2 01/17] rpmsg: Enable matching devices with drivers based on DT Bjorn Andersson 2016-09-01 22:27 ` Bjorn Andersson 2016-09-01 22:27 ` Bjorn Andersson 2016-09-08 1:46 ` spjoshi 2016-09-08 1:46 ` spjoshi at codeaurora.org 2016-09-09 4:30 ` Bjorn Andersson 2016-09-09 4:30 ` Bjorn Andersson 2016-09-09 22:07 ` Sarangdhar Joshi 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-01 22:27 ` Bjorn Andersson 2016-09-01 22:27 ` Bjorn Andersson 2016-09-08 1:46 ` spjoshi 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 ` 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 ` Bjorn Andersson 2016-09-01 22:27 ` 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 ` Bjorn Andersson 2016-09-01 22:27 ` 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 2016-09-01 22:27 ` Bjorn Andersson [this message] 2016-09-01 22:27 ` [PATCH v2 07/17] rpmsg: Move rpmsg_device API to new file Bjorn Andersson 2016-09-01 22:28 ` [PATCH v2 08/17] rpmsg: Indirection table for rpmsg_endpoint operations Bjorn Andersson 2016-09-01 22:28 ` 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 ` 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 ` 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 ` 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 ` Bjorn Andersson 2016-09-01 22:28 ` [PATCH v2 13/17] rpmsg: Hide rpmsg indirection tables Bjorn Andersson 2016-09-01 22:28 ` 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 ` 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 ` Bjorn Andersson 2016-09-01 22:28 ` [PATCH v2 16/17] rpmsg: Allow callback to return errors Bjorn Andersson 2016-09-01 22:28 ` Bjorn Andersson 2016-09-01 22:28 ` [PATCH v2 17/17] rpmsg: Introduce Qualcomm SMD backend Bjorn Andersson 2016-09-01 22:28 ` Bjorn Andersson 2016-09-12 16:52 ` [PATCH v2 00/17] Make rpmsg a framework Lina Iyer 2016-09-12 16:52 ` Lina Iyer 2016-09-12 18:00 ` Bjorn Andersson 2016-09-12 18:00 ` Bjorn Andersson 2016-09-12 18:13 ` Jeffrey Hugo 2016-09-12 18:13 ` Jeffrey Hugo 2016-09-12 18:49 ` Bjorn Andersson 2016-09-12 18:49 ` Bjorn Andersson 2016-09-12 19:21 ` Jeffrey Hugo 2016-09-12 19:21 ` Jeffrey Hugo 2016-09-12 19:58 ` Bjorn Andersson 2016-09-12 19:58 ` Bjorn Andersson 2016-09-12 21:36 ` Karthikeyan Ramasubramanian 2016-09-12 21:36 ` Karthikeyan Ramasubramanian 2016-09-12 21:53 ` Bjorn Andersson 2016-09-12 21:53 ` Bjorn Andersson 2016-09-12 22:22 ` Lina Iyer 2016-09-12 22:22 ` Lina Iyer 2016-09-12 22:58 ` Bjorn Andersson 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 \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-remoteproc@vger.kernel.org \ --cc=ohad@wizery.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.