[lkml]   [2020]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
On Fri, May 15, 2020 at 12:17 AM Viresh Kumar <> wrote:
> - The hardware gives us the capability to write the register in
> parallel, i.e. we can write 0x800 and 0x400 together without any
> software locks, and so these 32 bits should be considered as separate
> channel even if only one interrupt is issued by the hardware finally.
> This shouldn't be called as virtualization of the channels, as the
> hardware supports this (as clearly mentioned in the TRM) and it takes
> care of handling the signal properly.
I'll leave this one open to bikeshed arguments.

> - 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.
As I asked you yesterday over the call, it may help if you could share
some numbers to back up the doomsday scenario.
I don't believe mailbox will be a bottleneck, unless you send commands
in a while(1) ... but even then you have to compare against the
virtual-channel implementation. (Not to forget one usually doesn't
need/want the dvfs, power, clock, hotplug all happening at the _same_

Please note, SCMI... lets not pretend it is not about making scmi work
with mhu :) ... itself uses shared-memory transfers and
wait_for_completion_timeout in scmi_do_xfer(). If some platform
_really-really_ faced speed bottlenecks, it would come to want to
exchange 32-bit encoded command/response over the mhu register,
asynchronously and totally bypassing shmem... which is possible only

> - With the current approach it isn't possible to assign different bits
> (or doorbell numbers) to clients from DT and the only way of doing
> that without adding new bindings is by extending #mbox-cells to accept
> a value of 2 as done in this patch.
I am afraid you are confused. You can use bit/doorbell-6 by passing
0x40 to mhu as the data to send.


 \ /
  Last update: 2020-05-15 18:47    [W:0.203 / U:0.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site