linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jassi Brar <jassisinghbrar@gmail.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	Rob Herring <robh@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Frank Rowand <frowand.list@gmail.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Devicetree List <devicetree@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
Date: Fri, 5 Jun 2020 01:30:54 -0500	[thread overview]
Message-ID: <CABb+yY2YZ99NjHYNi0=KLGFDsVUeJmqiJD3E25Chwk-THJV4iw@mail.gmail.com> (raw)
In-Reply-To: <20200605045645.GD12397@bogus>

On Thu, Jun 4, 2020 at 11:56 PM Sudeep Holla <sudeep.holla@arm.com> wrote:

>
> > >>     bash-1526  [000]  1149.472553: scmi_xfer_begin:      transfer_id=1538 msg_id=6 protocol_id=21 seq=0 poll=0
> > >>      <idle>-0     [001]  1149.472733: scmi_xfer_begin:      transfer_id=1539 msg_id=7 protocol_id=19 seq=1 poll=1
> > >
> > Here another request is started before the first is finished.
>
> Ah, the prints are when the client requested. It is not when the mailbox
> started it. So this just indicates the beginning of the transfer from the
> client.
>
There maybe condition on a sensor read to finish within 1ms, but there
is no condition for the read to _start_ at this very moment (usually
there are sleeps in the path to sensor requests).

> > If you want this to work you have to serialise access to the single
> > physical channel and/or run the remote firmware in asynchronous mode -
> > that is, the firmware ack the bit as soon as it sees and starts
> > working in the background, so that we return in ~3usec always, while
> > the data returns whenever it is ready.
>
> Yes it does that for few requests like DVFS while it uses synchronous
> mode for few others. While ideally I agree everything in asynchronous
> most is better, I don't know there may be reasons for such design.
>
The reason is that, if the firmware works asynchronously, every call
would return in ~3usec and you won't think you need virtual channels.

You have shared only 'bad' log without serialising access. Please
share log after serialising access to the channel and the 'good' log
with virtual channels.  That should put the topic to rest.

thanks.

  reply	other threads:[~2020-06-05  6:31 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-15  5:17 [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU Viresh Kumar
2020-05-15 16:46 ` Jassi Brar
2020-05-18  7:35   ` Viresh Kumar
2020-05-19  0:53     ` Jassi Brar
2020-05-19  4:39       ` Viresh Kumar
2020-05-19  1:29 ` Bjorn Andersson
2020-05-19  3:40   ` Viresh Kumar
2020-05-19  4:05     ` Jassi Brar
2020-06-03 18:31       ` Sudeep Holla
2020-06-03 18:42         ` Jassi Brar
2020-06-03 18:28   ` Sudeep Holla
2020-05-28 19:20 ` Rob Herring
2020-05-29  4:07   ` Viresh Kumar
2020-06-03 18:04     ` Sudeep Holla
2020-06-03 18:17       ` Sudeep Holla
2020-06-04  5:59         ` Viresh Kumar
2020-06-04  8:28           ` Sudeep Holla
2020-06-03 18:32       ` Jassi Brar
2020-06-04  9:20         ` Sudeep Holla
2020-06-04 15:15           ` Jassi Brar
2020-06-05  4:56             ` Sudeep Holla
2020-06-05  6:30               ` Jassi Brar [this message]
2020-06-05  8:58                 ` Sudeep Holla
2020-06-05 15:42                   ` Jassi Brar
2020-06-10  9:33                     ` Viresh Kumar
2020-06-11 10:00                       ` Sudeep Holla
2020-06-12  0:34                         ` Jassi Brar
2020-06-12  5:28                           ` Viresh Kumar
2020-09-08  9:14                             ` Arnd Bergmann
2020-09-08  9:27                               ` Viresh Kumar
2020-09-08 13:26                               ` Sudeep Holla
2020-09-09  3:23                               ` Jassi Brar
2020-09-09  4:46                                 ` Viresh Kumar
2020-09-09  9:31                                 ` Sudeep Holla
2020-05-29  5:20   ` Jassi Brar
2020-05-29  6:27     ` Viresh Kumar

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='CABb+yY2YZ99NjHYNi0=KLGFDsVUeJmqiJD3E25Chwk-THJV4iw@mail.gmail.com' \
    --to=jassisinghbrar@gmail.com \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.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).