On Fri, May 15, 2020 at 12:17 AM Viresh Kumar <viresh.kumar@xxxxxxxxxx> 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_ time) 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 now. > - 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. Cheers!
