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: Wed, 08 Oct 2014 15:47:06 -0600 Message-ID: <5435B0DA.1000707@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> <542B39BD.3030208@codeaurora.org> <20141001000846.GZ28481@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: <20141001000846.GZ28481@sonymobile.com> Sender: linux-arm-msm-owner@vger.kernel.org To: Bjorn Andersson Cc: Kumar Gala , 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 6:08 PM, Bjorn Andersson wrote: > On Tue 30 Sep 16:16 PDT 2014, Jeffrey Hugo wrote: > >> 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.t= xt 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= system to vote >>>>> +for state of the system resources, such as clocks, regulators an= d 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= how >>>> what we do here for compat and distinguish the A-family RPM suppor= t 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 s= pecific. >>> >>> I'm not sure what you mean with distinguish the A and B family, the= y are >>> completely different and there are no overlap in compatibles or imp= lementation. >>> >>> The overlap is in how children are communicating with the rpm, but = this is an >>> implementation detail - and noted in that patch as a future improve= ment. >>> >>> >>> I forgot to add Jeff, but did send him a separate email asking for = his 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 ar= ea >> of expertise, but I have some familiarity with it as it is a SMD cli= ent. >> Internally we have a singular compat for all of B family, but I >> haven't been able to figure out how that works to expose all of the >> resources. I'll talk to my contact later in the week to see what th= e >> differences are. >> > > That's right, because you have these tables in devicetree in the caf = version. > You have to have this information somewhere! True, it must exist somewhere. However since its information tied=20 directly to the hardware, it seems like its information that would fit=20 right in DT. I talked to my contact, and it seems like the table attributes vary mor= e=20 than I thought, target to target, so the single table design seems less= =20 plausible. Its my understanding you've had an offline discussion with=20 him and some of our regulator guys to discuss the specifics of our=20 needs. I'll let them take over as the experts. > >> Is the per target compat the way to do this though? The way its >> currently done means we'll have atleast a dozen tables in >> qcom-smd-rpm.c, and I can't imagine they will have anything more tha= n >> minor differences from the msm8x74_resource_table that currently exi= sts >> in patch 6 of the series. Why wouldn't one table that is a superset= of >> all supported targets work? >> > > It would work as long as e.g. QCOM_RPM_PM8941_MVS1 always is vsa numb= er 4. > > But sure, it's a much better fit than the family a and this rpm would= reject > invalid resources, so it might work. But this works without us knowin= g about > all possible platforms. > > > But if the case is that multiple platforms expose the same table we c= an always > tie the same table to multiple compatibles. > > Regards, > Bjorn > --=20 Jeffrey Hugo Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a=20 Linux Foundation Collaborative Project