From: Sudeep Holla <sudeep.holla@arm.com>
To: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
Rob Herring <robh@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alexey Klimov <alexey.klimov@arm.com>,
Jassi Brar <jaswinder.singh@linaro.org>,
Devicetree List <devicetree@vger.kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>
Subject: Re: [PATCH 2/6] Documentation: devicetree: add bindings to support ARM MHU subchannels
Date: Tue, 9 May 2017 15:20:33 +0100 [thread overview]
Message-ID: <ffc23b4c-d7f5-9bc7-7060-fd77878ef258@arm.com> (raw)
In-Reply-To: <CABb+yY1x=Z2est1jnqnQu=VnmGSpMiJJxVnZ36buh21eJo8ULw@mail.gmail.com>
On 09/05/17 14:29, Jassi Brar wrote:
> On Tue, May 9, 2017 at 6:11 PM, Sudeep Holla <sudeep.holla@arm.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.
>
OK, why are we discussing that here ?
>>> 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)
>
Platform which uses this as single bit doorbell has to just choose the
tuple(bit and the register set) as shown in the example binding
>>>> 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.
>
Yes I can know and can see you have upstreamed the driver. I have spoken
to the ARM MHU hardware IP designers and I know what it's designed for.
And that's why I gave you example to look at STI driver
to help you understand what I am trying to say faster.
>>>> 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.
>
Again for the 3rd time see arm_scpi.c
ARM is now generalizing it with multiple vendors under the new name ARM
SCMI. And Juno is implementing using few doorbell bits on the same
channel as SCPI.
--
Regards,
Sudeep
next prev parent reply other threads:[~2017-05-09 14:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-02 13:55 [PATCH 0/6] mailbox: arm_mhu: add support for subchannels Sudeep Holla
2017-05-02 13:55 ` [PATCH 1/6] mailbox: arm_mhu: reorder header inclusion and drop unneeded ones Sudeep Holla
2017-05-02 13:55 ` [PATCH 2/6] Documentation: devicetree: add bindings to support ARM MHU subchannels Sudeep Holla
2017-05-08 16:10 ` Rob Herring
2017-05-08 16:46 ` Jassi Brar
2017-05-08 17:07 ` Sudeep Holla
2017-05-08 17:52 ` Bjorn Andersson
2017-05-09 9:36 ` Sudeep Holla
2017-05-09 2:50 ` Jassi Brar
2017-05-09 9:58 ` Sudeep Holla
2017-05-09 10:31 ` Jassi Brar
2017-05-09 10:53 ` Sudeep Holla
2017-05-09 11:55 ` Jassi Brar
2017-05-09 12:41 ` Sudeep Holla
2017-05-09 13:29 ` Jassi Brar
2017-05-09 14:20 ` Sudeep Holla [this message]
2017-05-08 16:53 ` Sudeep Holla
2017-05-02 13:55 ` [PATCH 3/6] mailbox: arm_mhu: migrate to threaded irq handler Sudeep Holla
2017-05-02 13:55 ` [PATCH 4/6] mailbox: arm_mhu: re-factor data structure to add subchannel support Sudeep Holla
2017-05-02 13:55 ` [PATCH 5/6] mailbox: arm_mhu: add full support for sub-channels Sudeep Holla
2017-05-02 13:55 ` [PATCH 6/6] mailbox: arm_mhu: add name support to record mbox-name Sudeep Holla
2017-05-03 3:17 ` [PATCH 0/6] mailbox: arm_mhu: add support for subchannels Jassi Brar
2017-05-03 9:21 ` Sudeep Holla
2017-05-05 11:12 ` Jassi Brar
2017-05-05 11:23 ` Sudeep Holla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ffc23b4c-d7f5-9bc7-7060-fd77878ef258@arm.com \
--to=sudeep.holla@arm.com \
--cc=alexey.klimov@arm.com \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jassisinghbrar@gmail.com \
--cc=jaswinder.singh@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).