[lkml]   [2020]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
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.


 \ /
  Last update: 2020-06-03 20:29    [W:0.221 / U:0.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site