From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751778AbdFIPu1 (ORCPT ); Fri, 9 Jun 2017 11:50:27 -0400 Received: from foss.arm.com ([217.140.101.70]:43116 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751534AbdFIPuZ (ORCPT ); Fri, 9 Jun 2017 11:50:25 -0400 Cc: Sudeep Holla , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , Roy Franz , Harb Abdulhamid , Nishanth Menon , Arnd Bergmann , Mark Rutland Subject: Re: [RFC PATCH 1/8] Documentation: add DT binding for ARM System Control and Management Interface(SCMI) protocol To: Rob Herring References: <1496851812-19623-1-git-send-email-sudeep.holla@arm.com> <1496851812-19623-2-git-send-email-sudeep.holla@arm.com> <20170609141632.eni4k3c4aiyvbkfk@rob-hp-laptop> <8d17f317-510c-b98e-4c42-c4ad2a8f0c63@arm.com> From: Sudeep Holla Organization: ARM Message-ID: <36fb6868-18ef-d1ce-de83-008da8d454e4@arm.com> Date: Fri, 9 Jun 2017 16:50:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/06/17 16:39, Rob Herring wrote: > On Fri, Jun 9, 2017 at 9:47 AM, Sudeep Holla wrote: >> >> >> On 09/06/17 15:16, Rob Herring wrote: >>> On Wed, Jun 07, 2017 at 05:10:05PM +0100, Sudeep Holla wrote: >>>> This patch adds devicetree binding for System Control and Management >>>> Interface (SCMI) Message Protocol used between the Application Cores(AP) >>>> and the System Control Processor(SCP). The MHU peripheral provides a >>>> mechanism for inter-processor communication between SCP's M3 processor >>>> and AP. >>>> >>>> SCP offers control and management of the core/cluster power states, >>>> various power domain DVFS including the core/cluster, certain system >>>> clocks configuration, thermal sensors and many others. >>>> >>>> SCMI protocol is developed as better replacement to the existing SCPI >>>> which is not flexible and easily extensible. >>>> >>>> Cc: Rob Herring >>>> Cc: Mark Rutland >>>> Signed-off-by: Sudeep Holla >>>> --- >>>> Documentation/devicetree/bindings/arm/arm,scmi.txt | 193 +++++++++++++++++++++ >>>> 1 file changed, 193 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/arm/arm,scmi.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt >>>> new file mode 100644 >>>> index 000000000000..d6e4b7eff199 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt >>>> @@ -0,0 +1,193 @@ >>>> +System Control and Management Interface (SCMI) Message Protocol >>>> +---------------------------------------------------------- >>>> + >>>> +The SCMI is intended to allow agents such as OSPM to manage various functions >>>> +that are provided by the hardware platform it is running on, including power >>>> +and performance functions. >>>> + >>>> +This binding is intended to define the interface the firmware implementing >>>> +the SCMI as described in ARM document number ARM DUI 0922B ("ARM System Control >>>> +and Management Interface Platform Design Document")[0] provide for OSPM in >>>> +the device tree. >>>> + >>>> +Required properties: >>>> + >>>> +- compatible : shall be "arm,scmi" >>> >>> Convince me that this genericish string is specific enough. >>> >> >> Now that you raised this point, I think we generate so many 4 letter >> acronyms that it can collide. How about "arm,sys-ctl-mgmt-if" > > I was more concerned about needing versioning or vendor specific > compatible strings that we needed with SCPI. Is there a spec version > or is that discoverable? > Ah ok, it's discoverable and each protocol must implement PROTOCOL_VERSION. We have specification version implemented, vendor id and firmware implementation version all of which is mandatory. >>>> +- method : The method of calling the SCMI firmware. Only permitted value >>>> + currently is: >>>> + "mailbox-doorbell" : When mailbox doorbell is used as a mechanism >>>> + to alert the presence of a messages and/or >>>> + notification >>>> +- mboxes: List of phandle and mailbox channel specifiers. It should contain >>>> + exactly one or two mailboxes, one for transmitting messages("tx") >>>> + and another optional for receiving the notifications("rx") if >>>> + supported. >>>> +- mbox-names: shall be "tx" or "rx" >>> >>> ...and optionally "rx" >>> >> >> OK >> >>>> +- shmem : List of phandle pointing to the shared memory(SHM) area between the >>>> + processors using these mailboxes for IPC, one for each mailbox >>>> + SHM can be any memory reserved for the purpose of this communication >>>> + between the processors. >>> >>> Maybe the mailbox binding should have a standard property for this? >>> >> >> Do you mean as part of it's client binding ? If so, agreed. I can come >> up with that proposal. > > Yes. Thanks, will do. -- Regards, Sudeep