Date:   Tue, 9 May 2017 18:59:03 +0530
From:   Jassi Brar <jassisinghbrar@...il.com>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     Rob Herring <robh@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Alexey Klimov <alexey.klimov@....com>,
        Jassi Brar <jaswinder.singh@...aro.org>,
        Devicetree List <devicetree@...r.kernel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>
Subject: Re: [PATCH 2/6] Documentation: devicetree: add bindings to support
 ARM MHU subchannels

On Tue, May 9, 2017 at 6:11 PM, Sudeep Holla <sudeep.holla@....com> wrote:
> On 09/05/17 12:55, Jassi Brar wrote:

>>>>>>
>>>>>> If it is still not clear, please share your client driver. I
>>>>>> will adapt that to work with existing MHU driver & bindings.
>>>>>>
>>>>>
>>>>> Just take example of SCPI in the mainline. Assume there's another
>>>>> protocol SCMI which uses few more bits in the same channel and the
>>>>> remote firmware implements both but both are totally independent
>>>>> and not related/linked. Also be keep in mind that SCPI is used by
>>>>> other platforms and so will be the new protocol. We simply make
>>>>> SCPI or SCMI bindings aligned to ARM MHU. That's ruled out.
>>>>>
>>>> Not sure what you mean by "that's ruled out".
>>>
>>> 1. The mailbox client bindings should be independent of this ARM MHU
>>>    mailbox bindings
>>> 2. All we need in client is a mailbox to point at and not any meta data
>>>    That's what I meant by ruled-out as both client and MHU can be used
>>>    independent of each other and *should not* be linked.
>>>
>> I am shocked at this coming from you.
>>
>> You design SCMI based upon MHU assumption of single bit "doorbell" and
>> then you say a client should be independent of the underlying
>> controller? Do you intend SCMI to work only over MHU?
>>
>
> No, I never said that. What I said is SCMI protocol will be on doorbell
> based.
>
What if a controller does not support your definition of "doorbell"?
Like PL320 from ARM and many others.


>>  What if some controller does not support the simple "doorbell" and
>> expects detailed info? For example, apart from SCMI, the remote also
>> supports platform specific functions like thermal, watchdog, wakeup
>> etc. The SCMI's would just be a subset of the full command set.
>> You/SCMI can not dictate what numerical value the platform assigns to
>> SCMI commands...
>
> What ? That's the whole point of specification. The command set is
> *fixed* and can be implemented on any platform and have generic driver
> for that.
>
The code/value for commands in SHM data packet is SCMI specific. But
what a platform assigns to THIS_IS_SCMI_DOORBELL is going to be
platform specific i.e, not always BIT(x)


>>> On digging more about different mailbox controllers, I found
>>> mailbox-sti.c has exactly similar logic as what I have done in this series.
>>>
>
> Did you look at this driver ?
>
Dude, I merged this driver upstream! I don't remember exactly about
STI controller, but it definitely is different from MHU.


>>> Also don't mix implementation with the binding. I need a simple answer
>>> in this binding. How do I represent specific bits if each bit is
>>> implemented as a doorbell ? That's all. First let's agree on that when
>>> we use this mailbox independently and please *don't mix* with any
>>> client here. It's simple, this controller has 2-3 sets of 32 doorbell
>>> bits. And I am aiming to come up with the binding for that as your
>>> initial bindings didn't consider that.
>>>
>> Please send in whatever changes you plan to do, and I'll modify it so
>> we don't have to bloat the MHU driver and add bindings for a software
>> feature. Until then ... Cheers!
>>
>
> Changes to what ? arm_mhu.c ? This series is complete and implements
> doorbell completely.
>
Send in the user/client driver that you think can not work with
existing driver/bindings.

Powered by blists - more mailing lists