Re: [PATCH v2 2/6] Documentation: devicetree: add bindings to support ARM MHU doorbells

[Sudeep Holla <sudeep.holla@arm.com>]

On 06/07/17 19:37, Jassi Brar wrote:
> On Thu, Jul 6, 2017 at 10:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>> On 06/07/17 15:37, Jassi Brar wrote:
>>> On Thu, Jul 6, 2017 at 3:03 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
> 
>>> I see no reason why you must have SCPI and SCMI both running.
>>>
>>
>> We can still have 2 different protocols using same MHU channel with
>> different doorbells, what's wrong with that ?
>>
> Only for SCMI and SCPI - both written by same person to achieve the
> same thing - I think it should not be necessary.
> 

Really ? you decide based on that and repeatedly ignore what ARM MHU
specification offers. Wow, I am surprised.

> But yes, SCMI running alongside some complementary protocol (that
> implements what SCMI doesn't provide) is a very solid usecase. And
> that is the reason you need a platform specific 'transport layer'.
> 

The whole SCMI exercise is to reduce such platform specific code.
It's made to work with ACPI using doorbells via PCC channels. Now, you
say for DT we need per platform shim. Mailbox is my transport, why do I
need anything more as I don't care what is sent in mailbox controller as
long as the signal is sent to the other side.

>>> And even then there is a solution - a shim arbitrator. Other
>>> platforms, those share a channel, do that. No big deal.
>>>
>>
>> Example please? Please remember these protocols are generic and we
>> can't add any platform specific code into them.
>>
> You do need to have platform specific glue as I said.
> 

Yes, please propose along bindings to do that as you are objecting the
one in $subject. I have asked you many times the same thing.

>>>  BTW, I hope you realise that we need a 'transport layer' which will
>>> be the platform specific glue between mailbox controller specifics and
>>> the generic SCMI code.
>>
>> Why ?
>>
> Because you should not restrict the usage of SCMI to only platforms
> with mailbox controller that does not require any information to
> trigger a signal on the other side -- what you call "doorbell".
> 

Indeed, it's restricted, read the specification. We have all the
information in the channel shared memory and we just need doorbell
in the transport. It's clear in the specification. You seem to not read
any of the specification and continue to ignore.

> Why shouldn't Rockchip be able to implement SCMI? Just because it uses
> different mechanism to signal the other end?
> 

They can, all we need is just a mailbox channel, we don't care wants
sent in the controller as along as signal is sent. The shared memory has
to be as per the specification. I still don't know what I am missing to
convey you.

> You are actually putting in effort to restrict the usage of SCMI. Its
> like you buy a usb device and the first thing you do is solder it to
> the plug.
> 

I don't think you have read the SCMI specification, sorry.

> 
>> Clearly you have not made a since technical argument so far as why
>> MHU doorbell is not correct way even when MHU specification is clearly
>> allows it. I have given example of ST mailbox which has this doorbell
>> kind of support.
>>
>>> I see your confusion in the form of some issues in the SCMI
>>> implementation, please CC me on the next revision.
>>>
>>
>> Care to elaborate on what's my confusion or at-least what you think so ?
>>
> See me last point.
> 

I think you are just fixiated on one usage of ARM MHU and so hard to
convince otherwise..

>> Also if you have concern on implementation, ok we can discuss further.
>> But can you make it clear as what your objections are for the doorbell
>> MHU binding. How will I get the bit assigned for different protocols
>> which are platform specific ? I still need some binding , right ?
>>
> Sorry, No. I'll try to get lkml fwd me the patchset so I can explain
> there further.
> 

Sure, thanks.

-- 
Regards,
Sudeep