Thread (19 messages) 19 messages, 4 authors, 2018-02-15

Re: [PATCH 3/6] rpmsg: glink: Add support for rpmsg glink chrdev

From: Bjorn Andersson <hidden>
Date: 2018-02-15 18:29:01
Also in: linux-devicetree, linux-remoteproc, lkml

On Mon 18 Dec 14:02 PST 2017, Chris Lew wrote:
quoted hunk ↗ jump to hunk
RPMSG provides a char device interface to userspace. Probe the rpmsg
chrdev channel to enable the rpmsg_ctrl device creation on glink
transports.

Signed-off-by: Chris Lew <redacted>
---
 drivers/rpmsg/qcom_glink_native.c | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c
index 179132226dc2..786f2eca01f1 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -132,6 +132,13 @@ enum {
 	GLINK_STATE_CLOSING,
 };
 
+struct qcom_glink_device {
+	struct rpmsg_device rpdev;
+	struct qcom_glink *glink;
+};
+
+#define to_glink_device(_x) container_of(_x, struct qcom_glink_device, rpdev)
+
 /**
  * struct glink_channel - internal representation of a channel
  * @rpdev:	rpdev reference, only used for primary endpoints
@@ -1339,6 +1346,10 @@ static struct device_node *qcom_glink_match_channel(struct device_node *node,
 	return NULL;
 }
 
+static const struct rpmsg_device_ops glink_chrdev_ops = {
+	.create_ept = qcom_glink_create_ept,
+};
I can't remember and I see no apparent reason why we don't just
advertise the intents as the last step of create_ept, meaning that the
difference in ops would go away.

This would also make sure that we do advertise some intents for channels
associated with the rpmsg_char - and even if we don't have an attached
driver we can override the intent sizes on a channel.
quoted hunk ↗ jump to hunk
+
 static const struct rpmsg_device_ops glink_device_ops = {
 	.create_ept = qcom_glink_create_ept,
 	.announce_create = qcom_glink_announce_create,
@@ -1547,6 +1558,30 @@ static void qcom_glink_work(struct work_struct *work)
 	}
 }
 
+static void qcom_glink_device_release(struct device *dev)
+{
+	struct rpmsg_device *rpdev = to_rpmsg_device(dev);
+	struct qcom_glink_device *gdev = to_glink_device(rpdev);
+
+	kfree(gdev);
+}
+
+static int qcom_glink_create_chrdev(struct qcom_glink *glink)
+{
+	struct qcom_glink_device *gdev;
+
+	gdev = kzalloc(sizeof(*gdev), GFP_KERNEL);
+	if (!gdev)
+		return -ENOMEM;
+
+	gdev->glink = glink;
+	gdev->rpdev.ops = &glink_chrdev_ops;
+	gdev->rpdev.dev.parent = glink->dev;
+	gdev->rpdev.dev.release = qcom_glink_device_release;
+
+	return rpmsg_chrdev_register_device(&gdev->rpdev);
This rpdev will end up being the first parameter to
qcom_glink_create_ept() where we do:

	container_of(rpdev->ept, struct glink_channel, ept)

to get the struct glink_channel that backs the endpoint of the passed
rpmsg_device. So the registered rpdev must reference a rpmsg_endpoint
that is contained within a glink_channel.


So I think you need to create two objects here; a glink_channel with
the glink pointer referencing the glink instance and a rpmsg_device
referencing the rpmsg_endpoint of the channel.

You can get a initialized (and dangling) glink_channel by calling
qcom_glink_alloc_channel(). Note though that this element won't be freed
automagically (the rpmsg_device will).
+}
+
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help