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

[Sudeep Holla]

On 13/10/17 15:12, Jassi Brar wrote:
> On Fri, Oct 13, 2017 at 7:12 PM, Sudeep Holla <sudeep.holla at arm.com> 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 at arm.com> wrote:
>>>>
>>>>
>>>> On 06/10/17 14:47, Jassi Brar wrote:
>>>>> On Fri, Oct 6, 2017 at 7:02 PM, Sudeep Holla <sudeep.holla at arm.com> 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.
> 

Sure and sorry for that.

> 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.
> 

I was not aware of that. Thanks for clarifying the differences.

> IOW, QCom has 32 channels per register whereas MHU has one. The

OK, that depends on how we consider it. As you said yes it just goes to
single target processor, but hardware designers consider it still 32
channels are they can be controller independently without any locking.

> 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.
> 

Sure, that's the reason I have this abstraction now.

-- 
Regards,
Sudeep