public inbox for linux-remoteproc@vger.kernel.org
 help / color / mirror / Atom feed
From: Arun Kumar Neelakantam <aneela@codeaurora.org>
To: Sricharan R <sricharan@codeaurora.org>,
	ohad@wizery.com, bjorn.andersson@linaro.org,
	linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 04/18] rpmsg: glink: Move the common glink protocol implementation to glink_native.c
Date: Tue, 22 Aug 2017 11:28:54 +0530	[thread overview]
Message-ID: <3f055e52-bef9-c6d6-3d4f-97e4c772f04e@codeaurora.org> (raw)
In-Reply-To: <1502903951-5403-5-git-send-email-sricharan@codeaurora.org>



On 8/16/2017 10:48 PM, Sricharan R wrote:
> +
> +struct glink_msg {
> +	__le16 cmd;
> +	__le16 param1;
> +	__le32 param2;
> +	u8 data[];
> +} __packed;

why we are using extra u8 data[] member here ?

> +
> +/**
> + * struct glink_defer_cmd - deferred incoming control message
> + * @node:	list node
> + * @msg:	message header
> + * data:	payload of the message
> + *
> + * Copy of a received control message, to be added to @rx_queue and processed
> + * by @rx_work of @glink_rpm.
> + */
> +struct glink_defer_cmd {
> +	struct list_head node;
> +
> +	struct glink_msg msg;
> +	u8 data[];
> +};
> +
> +/**
> + * struct glink_rpm - driver context, relates to one remote subsystem

glink_rpm to qcom_glink

> +static int qcom_glink_tx(struct qcom_glink *glink,
> +			 const void *hdr, size_t hlen,
> +			 const void *data, size_t dlen, bool wait)
> +{
> +	unsigned int tlen = hlen + dlen;
> +	int ret;
> +
> +	/* Reject packets that are too big */
> +	if (tlen >= glink->tx_pipe->length)
> +		return -EINVAL;

we need to add support for split packets, in some cases packets may be 
greater than 16K.
> +
> +	if (WARN(tlen % 8, "Unaligned TX request"))
> +		return -EINVAL;
> +
> +	ret = mutex_lock_interruptible(&glink->tx_lock);
> +	if (ret)
> +		return ret;
> +
> +	while (qcom_glink_tx_avail(glink) < tlen) {
> +		if (!wait) {
> +			ret = -ENOMEM;

This condition is either reader is slow or not reading data, should we 
return -EAGAIN here instead of -ENOMEM?
> +			goto out;
> +		}
> +
> +		msleep(10);
> +	}
> +
> +	qcom_glink_tx_write(glink, hdr, hlen, data, dlen);
> +
> +	mbox_send_message(glink->mbox_chan, NULL);
> +	mbox_client_txdone(glink->mbox_chan, 0);
> +
> +out:
> +	mutex_unlock(&glink->tx_lock);
> +
> +	return ret;
> +}
> +


> +/**
> + * qcom_glink_send_open_req() - send a RPM_CMD_OPEN request to the remote
> + * @glink:
> + * @channel:

Missed information for @ glink and @channel
> + *
> + * Allocates a local channel id and sends a RPM_CMD_OPEN message to the remote.
> + * Will return with refcount held, regardless of outcome.
> + *
> + * Returns 0 on success, negative errno otherwise.
> + */
> +static int qcom_glink_send_open_req(struct qcom_glink *glink,
> +				    struct glink_channel *channel)


> +static irqreturn_t qcom_glink_native_intr(int irq, void *data)
> +{
> +	struct qcom_glink *glink = data;
> +	struct glink_msg msg;
> +	unsigned int param1;
> +	unsigned int param2;
> +	unsigned int avail;
> +	unsigned int cmd;
> +	int ret;
> +
> +	for (;;) {
> +		avail = qcom_glink_rx_avail(glink);
> +		if (avail < sizeof(msg))
> +			break;
> +
> +		qcom_glink_rx_peak(glink, &msg, sizeof(msg));
> +
> +		cmd = le16_to_cpu(msg.cmd);
> +		param1 = le16_to_cpu(msg.param1);
> +		param2 = le32_to_cpu(msg.param2);
> +
> +		switch (cmd) {
> +		case RPM_CMD_VERSION:
> +		case RPM_CMD_VERSION_ACK:
> +		case RPM_CMD_CLOSE:
> +		case RPM_CMD_CLOSE_ACK:
> +			ret = qcom_glink_rx_defer(glink, 0);
> +			break;
> +		case RPM_CMD_OPEN_ACK:
> +			ret = qcom_glink_rx_open_ack(glink, param1);
> +			qcom_glink_rx_advance(glink, ALIGN(sizeof(msg), 8));
> +			break;
> +		case RPM_CMD_OPEN:
> +			ret = qcom_glink_rx_defer(glink, param2);
> +			break;
> +		case RPM_CMD_TX_DATA:
> +		case RPM_CMD_TX_DATA_CONT:
> +			ret = qcom_glink_rx_data(glink, avail);
> +			break;
> +		case RPM_CMD_READ_NOTIF:
> +			qcom_glink_rx_advance(glink, ALIGN(sizeof(msg), 8));
> +
> +			mbox_send_message(glink->mbox_chan, NULL);
> +			mbox_client_txdone(glink->mbox_chan, 0);
> +
> +			ret = 0;
> +			break;
> +		default:
> +			dev_err(glink->dev, "unhandled rx cmd: %d\n", cmd);

please add more information in error log to find the remote peripheral 
also other wise after adding SMEM transport it will be difficult to find 
for which peripheral the error came.
> +			ret = -EINVAL;
> +			break;
> +		}
> +
> +		if (ret)
> +			break;
> +	}
> +
> +	return IRQ_HANDLED;
> +}
> +

> +struct qcom_glink *qcom_glink_native_probe(struct device *dev,
> +					   struct qcom_glink_pipe *rx,
> +					   struct qcom_glink_pipe *tx)
> +{
> +	int irq;
> +	int ret;
> +	struct qcom_glink *glink;
> +
> +	glink = devm_kzalloc(dev, sizeof(*glink), GFP_KERNEL);
> +	if (!glink)
> +		return ERR_PTR(-ENOMEM);
> +
> +	glink->dev = dev;
> +	glink->tx_pipe = tx;
> +	glink->rx_pipe = rx;
> +
> +	mutex_init(&glink->tx_lock);
> +	spin_lock_init(&glink->rx_lock);
> +	INIT_LIST_HEAD(&glink->rx_queue);
> +	INIT_WORK(&glink->rx_work, qcom_glink_work);
> +
> +	mutex_init(&glink->idr_lock);
> +	idr_init(&glink->lcids);
> +	idr_init(&glink->rcids);
> +
> +	glink->mbox_client.dev = dev;
> +	glink->mbox_chan = mbox_request_channel(&glink->mbox_client, 0);
> +	if (IS_ERR(glink->mbox_chan)) {
> +		if (PTR_ERR(glink->mbox_chan) != -EPROBE_DEFER)
> +			dev_err(dev, "failed to acquire IPC channel\n");
> +		return ERR_CAST(glink->mbox_chan);
> +	}
> +
> +	irq = of_irq_get(dev->of_node, 0);
> +	ret = devm_request_irq(dev, irq,
> +			       qcom_glink_native_intr,
> +			       IRQF_NO_SUSPEND | IRQF_SHARED,
> +			       "glink-native", glink);
> +	if (ret) {
> +		dev_err(dev, "failed to request IRQ\n");
> +		return ERR_PTR(ret);
> +	}

These IRQs are wake-up-capable, please use enable_irq_wale() also
> +
> +	ret = qcom_glink_send_version(glink);
> +	if (ret)
> +		return ERR_PTR(ret);
> +
> +	return glink;
> +}
> +

  reply	other threads:[~2017-08-22  5:58 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-16 17:18 [PATCH 00/18] rpmsg: glink: Add glink smem based transport Sricharan R
2017-08-16 17:18 ` [PATCH 01/18] rpmsg: glink: Rename glink_rpm_xx functions to qcom_glink_xx Sricharan R
2017-08-16 17:18 ` [PATCH 02/18] rpmsg: glink: Associate indirections for pipe fifo accessor's Sricharan R
2017-08-16 17:18 ` [PATCH 03/18] rpmsg: glink: Split rpm_probe to reuse the common code Sricharan R
2017-08-16 17:18 ` [PATCH 04/18] rpmsg: glink: Move the common glink protocol implementation to glink_native.c Sricharan R
2017-08-22  5:58   ` Arun Kumar Neelakantam [this message]
2017-08-22 12:27     ` Sricharan R
2017-08-16 17:18 ` [PATCH 05/18] rpmsg: glink: Allow unaligned data access Sricharan R
2017-08-16 17:18 ` [PATCH 06/18] rpmsg: glink: Introduce glink smem based transport Sricharan R
2017-08-16 17:19 ` [PATCH 07/18] rpmsg: glink: Fix default case while handling received commands Sricharan R
2017-08-16 17:19 ` [PATCH 08/18] rpmsg: glink: Add support for transport version negotiation Sricharan R
2017-08-16 17:19 ` [PATCH 09/18] rpmsg: glink: Fix idr_lock from mutex to spinlock Sricharan R
2017-08-16 17:19 ` [PATCH 10/18] rpmsg: glink: Add support for TX intents Sricharan R
2017-08-22  9:12   ` Arun Kumar Neelakantam
2017-08-22 12:35     ` Sricharan R
2017-08-16 17:19 ` [PATCH 11/18] rpmsg: glink: Use the local intents when receiving data Sricharan R
2017-08-22  9:26   ` Arun Kumar Neelakantam
2017-08-22 12:39     ` Sricharan R
2017-08-16 17:19 ` [PATCH 12/18] rpmsg: glink: Make RX FIFO peak accessor to take an offset Sricharan R
2017-08-16 17:19 ` [PATCH 13/18] rpmsg: glink: Add rx done command Sricharan R
2017-08-22 10:25   ` Arun Kumar Neelakantam
2017-08-22 14:16     ` Sricharan R
2017-08-23  4:44       ` Arun Kumar Neelakantam
2017-08-16 17:19 ` [PATCH 14/18] rpmsg: glink: Add announce_create ops and preallocate intents Sricharan R
2017-08-16 17:19 ` [PATCH 15/18] rpmsg: glink: Receive and store the remote intent buffers Sricharan R
2017-08-22 10:41   ` Arun Kumar Neelakantam
2017-08-16 17:19 ` [PATCH 16/18] rpmsg: glink: Use the intents passed by remote Sricharan R
2017-08-16 17:19 ` [PATCH 17/18] rpmsg: glink: Request for intents when unavailable Sricharan R
2017-08-16 17:19 ` [PATCH 18/18] rpmsg: glink: Handle remote rx done command Sricharan R

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=3f055e52-bef9-c6d6-3d4f-97e4c772f04e@codeaurora.org \
    --to=aneela@codeaurora.org \
    --cc=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 \
    --cc=sricharan@codeaurora.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