On 08-09-20, 22:23, Jassi Brar wrote: > From the test case Sudeep last shared, the scmi usage on mhu doesn't > not even hit any bottleneck ... the test "failed" because of the too > small hardcoded timeout value. Otherwise the current code actually > shows better numbers. Its not important on why the test failed there, but the fact that there were requests in queue which have to be completed one by one and the last ones in the queue will always pay the penalty. > We need some synthetic tests to bring the limitation to the surface. I > agree that there may be such a test case, however fictitious. For that > reason, I am ok with the doorbell mode. > > I totally agree with one compat-string for one hardware. However, as > you said, unlike other device classes, the mailbox driver runs the > sumtotal of hardware and the remote firmware behaviour. Also the > implementations wouldn't share much, so I think a separate file+dt > will be better. > But I wanna get rid of this toothache that flares up > every season, so whatever. I can't agree more :) So to conclude the thread, if I have understood correctly, we are going to implement another doorbell driver for this hardware which will use a different compatible string and #mbox-cells value. I will try to refresh the bindings soon, which will be followed by the driver implementation. Thanks everyone. -- viresh
