All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: devicetree@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Jassi Brar <jassisinghbrar@gmail.com>,
	linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Frank Rowand <frowand.list@gmail.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
Date: Wed, 3 Jun 2020 19:28:05 +0100	[thread overview]
Message-ID: <20200603182805.GD23722@bogus> (raw)
In-Reply-To: <20200519012927.GT2165@builder.lan>

Hi Bjorn,

Thanks for the details response.

On Mon, May 18, 2020 at 06:29:27PM -0700, Bjorn Andersson wrote:
> On Thu 14 May 22:17 PDT 2020, Viresh Kumar wrote:
>

[...]

I find this part nicely summarise your response.

> > - With serialization, if we use only one channel as today at every
> >   priority, if there are 5 requests to send signal to the receiver and
> >   the dvfs request is the last one in queue (which may be called from
> >   scheduler's hot path with fast switching), it unnecessarily needs to
> >   wait for the first four transfers to finish due to the software
> >   locking imposed by the mailbox framework. This adds additional delay,
> >   maybe of few ms only, which isn't required by the hardware but just by
> >   the software and few ms can be important in scheduler's hotpath.
> >
>
> So these 5 requests, are they conveyed by the signals [1,2,3,4,5] or
> [BIT(0), BIT(1), BIT(2), BIT(3), BIT(4)]?
>

Latter in this case. IMO it is platform choice on how to use it. It is
equally possible to send 2^31 different signals. But the receiver must
also interpret it in the *exact* same way. In this case, the receiver
which is platform firmware interprets as individual bit signals.

> In the first case you have to serialize things given that e.g. signal 1
> immediately followed by 2 is indistinguishable from 3.
>

Agree and we are not proposing to break that use case. It exists in the
driver/binding today and will continue as is.

> If you signals are single-bit notifications then you don't need any
> serialization.
>

Indeed, we are making use of that.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	Jassi Brar <jassisinghbrar@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
Date: Wed, 3 Jun 2020 19:28:05 +0100	[thread overview]
Message-ID: <20200603182805.GD23722@bogus> (raw)
In-Reply-To: <20200519012927.GT2165@builder.lan>

Hi Bjorn,

Thanks for the details response.

On Mon, May 18, 2020 at 06:29:27PM -0700, Bjorn Andersson wrote:
> On Thu 14 May 22:17 PDT 2020, Viresh Kumar wrote:
>

[...]

I find this part nicely summarise your response.

> > - With serialization, if we use only one channel as today at every
> >   priority, if there are 5 requests to send signal to the receiver and
> >   the dvfs request is the last one in queue (which may be called from
> >   scheduler's hot path with fast switching), it unnecessarily needs to
> >   wait for the first four transfers to finish due to the software
> >   locking imposed by the mailbox framework. This adds additional delay,
> >   maybe of few ms only, which isn't required by the hardware but just by
> >   the software and few ms can be important in scheduler's hotpath.
> >
>
> So these 5 requests, are they conveyed by the signals [1,2,3,4,5] or
> [BIT(0), BIT(1), BIT(2), BIT(3), BIT(4)]?
>

Latter in this case. IMO it is platform choice on how to use it. It is
equally possible to send 2^31 different signals. But the receiver must
also interpret it in the *exact* same way. In this case, the receiver
which is platform firmware interprets as individual bit signals.

> In the first case you have to serialize things given that e.g. signal 1
> immediately followed by 2 is indistinguishable from 3.
>

Agree and we are not proposing to break that use case. It exists in the
driver/binding today and will continue as is.

> If you signals are single-bit notifications then you don't need any
> serialization.
>

Indeed, we are making use of that.

--
Regards,
Sudeep

  parent reply	other threads:[~2020-06-03 18:28 UTC|newest]

Thread overview: 71+ 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  5:17 ` Viresh Kumar
2020-05-15 16:46 ` Jassi Brar
2020-05-15 16:46   ` Jassi Brar
2020-05-18  7:35   ` Viresh Kumar
2020-05-18  7:35     ` Viresh Kumar
2020-05-19  0:53     ` Jassi Brar
2020-05-19  0:53       ` Jassi Brar
2020-05-19  4:39       ` Viresh Kumar
2020-05-19  4:39         ` Viresh Kumar
2020-05-19  1:29 ` Bjorn Andersson
2020-05-19  1:29   ` Bjorn Andersson
2020-05-19  3:40   ` Viresh Kumar
2020-05-19  3:40     ` Viresh Kumar
2020-05-19  4:05     ` Jassi Brar
2020-05-19  4:05       ` Jassi Brar
2020-06-03 18:31       ` Sudeep Holla
2020-06-03 18:31         ` Sudeep Holla
2020-06-03 18:42         ` Jassi Brar
2020-06-03 18:42           ` Jassi Brar
2020-06-03 18:28   ` Sudeep Holla [this message]
2020-06-03 18:28     ` Sudeep Holla
2020-05-28 19:20 ` Rob Herring
2020-05-28 19:20   ` Rob Herring
2020-05-29  4:07   ` Viresh Kumar
2020-05-29  4:07     ` Viresh Kumar
2020-06-03 18:04     ` Sudeep Holla
2020-06-03 18:04       ` Sudeep Holla
2020-06-03 18:17       ` Sudeep Holla
2020-06-03 18:17         ` Sudeep Holla
2020-06-04  5:59         ` Viresh Kumar
2020-06-04  5:59           ` Viresh Kumar
2020-06-04  8:28           ` Sudeep Holla
2020-06-04  8:28             ` Sudeep Holla
2020-06-03 18:32       ` Jassi Brar
2020-06-03 18:32         ` Jassi Brar
2020-06-04  9:20         ` Sudeep Holla
2020-06-04  9:20           ` Sudeep Holla
2020-06-04 15:15           ` Jassi Brar
2020-06-04 15:15             ` Jassi Brar
2020-06-05  4:56             ` Sudeep Holla
2020-06-05  4:56               ` Sudeep Holla
2020-06-05  6:30               ` Jassi Brar
2020-06-05  6:30                 ` Jassi Brar
2020-06-05  8:58                 ` Sudeep Holla
2020-06-05 15:42                   ` Jassi Brar
2020-06-05 15:42                     ` Jassi Brar
2020-06-10  9:33                     ` Viresh Kumar
2020-06-10  9:33                       ` Viresh Kumar
2020-06-11 10:00                       ` Sudeep Holla
2020-06-11 10:00                         ` Sudeep Holla
2020-06-12  0:34                         ` Jassi Brar
2020-06-12  0:34                           ` Jassi Brar
2020-06-12  5:28                           ` Viresh Kumar
2020-06-12  5:28                             ` Viresh Kumar
2020-09-08  9:14                             ` Arnd Bergmann
2020-09-08  9:14                               ` Arnd Bergmann
2020-09-08  9:27                               ` Viresh Kumar
2020-09-08  9:27                                 ` Viresh Kumar
2020-09-08 13:26                               ` Sudeep Holla
2020-09-08 13:26                                 ` Sudeep Holla
2020-09-09  3:23                               ` Jassi Brar
2020-09-09  3:23                                 ` Jassi Brar
2020-09-09  4:46                                 ` Viresh Kumar
2020-09-09  4:46                                   ` Viresh Kumar
2020-09-09  9:31                                 ` Sudeep Holla
2020-09-09  9:31                                   ` Sudeep Holla
2020-05-29  5:20   ` Jassi Brar
2020-05-29  5:20     ` Jassi Brar
2020-05-29  6:27     ` Viresh Kumar
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=20200603182805.GD23722@bogus \
    --to=sudeep.holla@arm.com \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=jassisinghbrar@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.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 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.