From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753962AbdEIOUp (ORCPT ); Tue, 9 May 2017 10:20:45 -0400 Received: from foss.arm.com ([217.140.101.70]:55430 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752758AbdEIOUn (ORCPT ); Tue, 9 May 2017 10:20:43 -0400 Subject: Re: [PATCH 2/6] Documentation: devicetree: add bindings to support ARM MHU subchannels To: Jassi Brar References: <1493733353-25812-1-git-send-email-sudeep.holla@arm.com> <1493733353-25812-3-git-send-email-sudeep.holla@arm.com> <20170508161026.5vdqnv52ub7hurwf@rob-hp-laptop> <6bd1e3d5-5e8b-6d02-cd80-9ff2c21de15d@arm.com> Cc: Sudeep Holla , Rob Herring , Linux Kernel Mailing List , Alexey Klimov , Jassi Brar , Devicetree List , Bjorn Andersson From: Sudeep Holla Organization: ARM Message-ID: Date: Tue, 9 May 2017 15:20:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/05/17 14:29, Jassi Brar wrote: > On Tue, May 9, 2017 at 6:11 PM, Sudeep Holla 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