From: Jassi Brar <jassisinghbrar@gmail.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: 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 18:59:03 +0530 [thread overview]
Message-ID: <CABb+yY1x=Z2est1jnqnQu=VnmGSpMiJJxVnZ36buh21eJo8ULw@mail.gmail.com> (raw)
In-Reply-To: <6bd1e3d5-5e8b-6d02-cd80-9ff2c21de15d@arm.com>
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.
>> 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.
next prev parent reply other threads:[~2017-05-09 13:29 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 [this message]
2017-05-09 14:20 ` Sudeep Holla
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='CABb+yY1x=Z2est1jnqnQu=VnmGSpMiJJxVnZ36buh21eJo8ULw@mail.gmail.com' \
--to=jassisinghbrar@gmail.com \
--cc=alexey.klimov@arm.com \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jaswinder.singh@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sudeep.holla@arm.com \
/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).