From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey Hugo Subject: Re: [RFC 3/7] mfd: devicetree: bindings: Add Qualcomm SMD based RPM DT binding Date: Tue, 30 Sep 2014 17:16:13 -0600 Message-ID: <542B39BD.3030208@codeaurora.org> References: <1412037291-16880-1-git-send-email-bjorn.andersson@sonymobile.com> <1412037291-16880-4-git-send-email-bjorn.andersson@sonymobile.com> <85C5C172-D309-41B4-B511-7820BAFDA017@codeaurora.org> <20140930143740.GK28481@sonymobile.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20140930143740.GK28481@sonymobile.com> Sender: linux-arm-msm-owner@vger.kernel.org To: Bjorn Andersson , Kumar Gala Cc: Andy Gross , Arnd Bergmann , Grant Likely , Ian Campbell , Lee Jones , Liam Girdwood , Mark Brown , Mark Rutland , Pawel Moll , Rob Herring , Samuel Ortiz , "open list:OPEN FIRMWARE AND..." , "linux-arm-kernel@lists.infradead.org" , linux-arm-msm , "linux-kernel@vger.kernel.org" List-Id: devicetree@vger.kernel.org On 9/30/2014 8:37 AM, Bjorn Andersson wrote: > On Tue 30 Sep 06:46 PDT 2014, Kumar Gala wrote: > >> >> On Sep 29, 2014, at 7:34 PM, Bjorn Andersson wrote: >> >>> diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt= b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt >>> new file mode 100644 >>> index 0000000..a846101 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt >>> @@ -0,0 +1,122 @@ >>> +Qualcomm Resource Power Manager (RPM) over SMD >>> + >>> +This driver is used to interface with the Resource Power Manager (= RPM) found in >>> +various Qualcomm platforms. The RPM allows each component in the s= ystem to vote >>> +for state of the system resources, such as clocks, regulators and = bus >>> +frequencies. >>> + >>> +- compatible: >>> + Usage: required >>> + Value type: >>> + Definition: must be one of: >>> + "qcom,rpm-msm8974=94 >> >> Why not =93qcom,rpm-smd=94. I=92d like to get Jeff H=92s input on h= ow >> what we do here for compat and distinguish the A-family RPM support = vs >> B-family/RPM-SMD support. >> > > I don't see anything indicating changes in the actual communication, = but as > this also encodes what resources are exposed we have to keep this spe= cific. > > I'm not sure what you mean with distinguish the A and B family, they = are > completely different and there are no overlap in compatibles or imple= mentation. > > The overlap is in how children are communicating with the rpm, but th= is is an > implementation detail - and noted in that patch as a future improveme= nt. > > > I forgot to add Jeff, but did send him a separate email asking for hi= s input on > all this. > Yep. I saw the series. Still doing a deep dive. The rpm-smd driver (and the A family equivalent) is outside of my area=20 of expertise, but I have some familiarity with it as it is a SMD client= =2E=20 Internally we have a singular compat for all of B family, but I=20 haven't been able to figure out how that works to expose all of the=20 resources. I'll talk to my contact later in the week to see what the=20 differences are. Is the per target compat the way to do this though? The way its=20 currently done means we'll have atleast a dozen tables in=20 qcom-smd-rpm.c, and I can't imagine they will have anything more than=20 minor differences from the msm8x74_resource_table that currently exists= =20 in patch 6 of the series. Why wouldn't one table that is a superset of= =20 all supported targets work? >>> + >>> +- qcom,smd-channels: >>> + Usage: required >>> + Value type: >>> + Definition: Shared Memory Channel used for communication with the= RPM >>> + >> >> This needs more details. >> > > Not sure what more to add here. It should contain the name of the cha= nnel used > for communication with the rpm. For all current platforms this would = be > "rpm_requests". > >>> +- #address-cells: >>> + Usage: required >>> + Value type: >>> + Definition: must be 1 >>> + >>> +- #size-cells: >>> + Usage: required >>> + Value type: >>> + Definition: must be 0 >>> + >>> +=3D SUBDEVICES >> >> As I mentioned for the the RPM binding on a-family, we should split = out the >> devices into their own binding specs. >> > > Please actually read https://lkml.org/lkml/2014/3/10/567, it's now th= e third > time I send you that link. If you don't like it then ask Rob to revis= e his > statement. > > For me it makes sense to consolidate the RPM binding in one document = rather > than spreading it out in 10 different documents with some implicit > dependencies. > > Regards, > Bjorn > Jeffrey Hugo --=20 The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,=20 hosted by The Linux Foundation.