Re: [PATCH v3 16/22] firmware: arm_scmi: add arm_mhu specific mailbox interface

[Jassi Brar]

On Fri, Oct 13, 2017 at 7:12 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
>
> Hi Bjorn,
>
> Thanks for taking a look at this. Much appreciated.
>
> On 12/10/17 22:03, Bjorn Andersson wrote:
>> On Fri, Oct 6, 2017 at 6:51 AM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
>>>
>>>
>>> On 06/10/17 14:47, Jassi Brar wrote:
>>>> On Fri, Oct 6, 2017 at 7:02 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
>> [..]
>>>>> Again that's not the point, doorbell is more common feature and that can
>>>>> be supported. As SCMI expects doorbell feature in the specification, it
>>>>> just need to support that class of controllers.
>>>>>
>>>> NO.  All SCMI expects is SHMEM and a signal reaching the other end.
>>>> The signal mechanism need not necessarily be "doorbell".
>>>>
>>>
>>> Agreed, but creating an abstraction ro do something as generic as
>>> doorbell and writing shim layer for each controller to use SCMI also
>>> sounds bad.
>>>
>>
>> In the Qualcomm platform we have a single register that exposes 32
>> doorbells, wired to interrupts on the various processors/co-processors
>> in the SoC.
>>
>
> It's exactly same even on ARM MHU controller.
>
This has been a big problem in our communication. You start with
"exactly same..." and go on telling the difference.
And that difference is important.

In MHU the 32bits are tied together and all go to one target
processor. Whereas on QCom, each bit corresponds to independent signal
going to a different target processor.

IOW, QCom has 32 channels per register whereas MHU has one. The
current drivers reflect that reality and hence I am against any change
in MHU driver.  Not to mean even changing the MHU driver will fix the
core issue - which is https://lkml.org/lkml/2017/7/7/465 and this
patchset tries to address that.