devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jon Medhurst (Tixy)" <tixy@linaro.org>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Liviu Dudau <Liviu.Dudau@arm.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <Mark.Rutland@arm.com>,
	Jassi Brar <jassisinghbrar@gmail.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH 1/4] mailbox: add support for System Control and Power Interface(SCPI) protocol
Date: Wed, 29 Apr 2015 13:25:38 +0100	[thread overview]
Message-ID: <1430310338.27241.45.camel@linaro.org> (raw)
In-Reply-To: <1430307828.27241.32.camel@linaro.org>

On Wed, 2015-04-29 at 12:43 +0100, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-04-29 at 11:53 +0100, Sudeep Holla wrote:
> > On 28/04/15 14:54, Jon Medhurst (Tixy) wrote:
> > > On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:
> [...]
> > >> +     int ret;
> > >> +     u8 token, chan;
> > >> +     struct scpi_xfer *msg;
> > >> +     struct scpi_chan *scpi_chan;
> > >> +
> > >> +     chan = atomic_inc_return(&scpi_info->next_chan) % scpi_info->num_chans;
> > >> +     scpi_chan = scpi_info->channels + chan;
> > >> +
> > >> +     msg = get_scpi_xfer(scpi_chan);
> > >> +     if (!msg)
> > >> +             return -ENOMEM;
> > >> +
> > >> +     token = atomic_inc_return(&scpi_chan->token) & CMD_TOKEN_ID_MASK;
> > >
> > > So, this 8 bit token is what's used to 'uniquely' identify a pending
> > > command. But as it's just an incrementing value, then if one command
> > > gets delayed for long enough that 256 more are issued then we will have
> > > a non-unique value and scpi_process_cmd can go wrong.
> > >
> > 
> > IMO by the time 256 message are queued up and serviced we would timeout
> > on the initial command. Moreover the core mailbox has sent the mailbox
> > length to 20(MBOX_TX_QUEUE_LEN) which needs to removed to even get the
> > remote chance of hit the corner case.
> 
> The corner case can be hit even if the queue length is only 2, because
> other processes/cpus can use the other message we don't own here and
> they can send then receive a message using that, 256 times. The corner
> case doesn't require 256 simultaneous outstanding requests.
> 
> That is the reason I suggested that rather than using an incrementing
> value for the 'unique' token, that each message instead contain the
> value of the token to use with it.

Of course, I failed to mention that this solution to this problem makes
thing worse for the situation where we timeout messages, because the
same token will get reused quicker in that case. So, in practice, if we
have timeouts, and a unchangeable protocol limitation of 256 tokens,
then using those tokens in order, for each message sent is probably the
best we can do.

Perhaps that's the clue, generate and add the token to the message, just
before transmission via the MHU, at a point where we know no other
request can overtake us. In scpi_tx_prepare? Perhaps, it might also be
good to only use up a token if we are expecting a response, and use zero
for other messages?

Something like this totally untested patch...

diff --git a/drivers/mailbox/scpi_protocol.c b/drivers/mailbox/scpi_protocol.c
index c74575b..5818d9b 100644
--- a/drivers/mailbox/scpi_protocol.c
+++ b/drivers/mailbox/scpi_protocol.c
@@ -286,14 +286,23 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
 	struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
 	struct scpi_shared_mem *mem = (struct scpi_shared_mem *)ch->tx_payload;
 
-	mem->command = cpu_to_le32(t->cmd);
 	if (t->tx_buf)
 		memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
 	if (t->rx_buf) {
+		int token;
 		spin_lock_irqsave(&ch->rx_lock, flags);
+		/*
+		 * Presumably we can do this token setting outside
+		 * spinlock and still be safe from concurrency?
+		 */
+		do
+			token = (++ch->token) & CMD_TOKEN_ID_MASK;
+		while(!token);
+		t->cmd |= token << CMD_TOKEN_ID_SHIFT;
 		list_add_tail(&t->node, &ch->rx_pending);
 		spin_unlock_irqrestore(&ch->rx_lock, flags);
 	}
+	mem->command = cpu_to_le32(t->cmd);
 }
 
 static struct scpi_xfer *get_scpi_xfer(struct scpi_chan *ch)
@@ -322,7 +331,7 @@ static int
 scpi_send_message(u8 cmd, void *tx_buf, unsigned int len, void *rx_buf)
 {
 	int ret;
-	u8 token, chan;
+	u8 chan;
 	struct scpi_xfer *msg;
 	struct scpi_chan *scpi_chan;
 
@@ -333,10 +342,8 @@ scpi_send_message(u8 cmd, void *tx_buf, unsigned int len, void *rx_buf)
 	if (!msg)
 		return -ENOMEM;
 
-	token = atomic_inc_return(&scpi_chan->token) & CMD_TOKEN_ID_MASK;
-
 	msg->slot = BIT(SCPI_SLOT);
-	msg->cmd = PACK_SCPI_CMD(cmd, token, len);
+	msg->cmd = PACK_SCPI_CMD(cmd, 0, len);
 	msg->tx_buf = tx_buf;
 	msg->tx_len = len;
 	msg->rx_buf = rx_buf;


-- 
Tixy

  reply	other threads:[~2015-04-29 12:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1430134846-24320-1-git-send-email-sudeep.holla@arm.com>
     [not found] ` <1430134846-24320-1-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
2015-04-27 11:40   ` [PATCH 1/4] mailbox: add support for System Control and Power Interface(SCPI) protocol Sudeep Holla
2015-04-28  7:36     ` Paul Bolle
2015-04-28  8:41       ` Sudeep Holla
2015-04-28 13:54     ` Jon Medhurst (Tixy)
2015-04-29 10:53       ` Sudeep Holla
2015-04-29 11:43         ` Jon Medhurst (Tixy)
2015-04-29 12:25           ` Jon Medhurst (Tixy) [this message]
2015-04-29 13:08             ` Sudeep Holla
2015-04-30  8:49             ` Jon Medhurst (Tixy)
2015-04-29 13:01           ` Sudeep Holla
2015-05-13 16:52     ` Jassi Brar
2015-05-13 17:09       ` Sudeep Holla
     [not found]         ` <55538540.1010505-5wv7dgnIgG8@public.gmane.org>
2015-05-14  7:02           ` Jassi Brar
2015-05-14  7:30             ` Jassi Brar
     [not found]               ` <CABb+yY0J1j=wMaKj+1nohU7qJpVS83BD_AX3Mf56T5+6V6+NOA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-05-14  8:25                 ` Sudeep Holla

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=1430310338.27241.45.camel@linaro.org \
    --to=tixy@linaro.org \
    --cc=Liviu.Dudau@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jassisinghbrar@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sudeep.holla@arm.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: 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).