| Message ID | 1425356740-26285-2-git-send-email-bjorn.andersson@sonymobile.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Mon, Mar 02, 2015 at 08:25:37PM -0800, Bjorn Andersson wrote: > +- compatible: > + Usage: required > + Value type: <string> > + Definition: must be one of: > + "qcom,rpm-pm8058-regulators" > + "qcom,rpm-pm8901-regulators" > + "qcom,rpm-pm8921-regulators" Why do these subnodes have a compatible - do they ever appear except as a child of a parent of the same type of device?
On Tue 03 Mar 04:47 PST 2015, Mark Brown wrote: > On Mon, Mar 02, 2015 at 08:25:37PM -0800, Bjorn Andersson wrote: > > > +- compatible: > > + Usage: required > > + Value type: <string> > > + Definition: must be one of: > > + "qcom,rpm-pm8058-regulators" > > + "qcom,rpm-pm8901-regulators" > > + "qcom,rpm-pm8921-regulators" > > Why do these subnodes have a compatible - do they ever appear except as > a child of a parent of the same type of device? The relationship with the parent node is 1:M; in the case of 8960/8064 there is only one PMIC controlled by the RPM, hence the dt will look like: rpm { compatible = "qcom,rpm-apq8960"; regulators { compatible = "qcom,rpm-pm8921-regulators"; ... }; }; But for 8660, and later for e.g. 8974 we have something like: rpm { compatible = "qcom,rpm-msm8660"; pm8058-regulators { compatible = "qcom,rpm-pm8058-regulators"; vdd_xxx-supply = <&pm8058_s4>; ... }; pm8901-regulators { compatible = "qcom,rpm-pm8901-regulators"; ... }; }; I intended to match these by name, having one rpm-regulator device instance and using desc->regulators_node to match regulators in the right node - with of_node being the rpm node. But this doesn't really map to reality, as supplies are a property of pm8058 and pm8901 and not of the rpm. I ended up writing some custom device registering code to instantiate the right number of regulator children and give each of them the right of_node etc. But as several other of-based platforms have a compatible in their regulators node I consider that a viable and cleaner solution. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/02/15 20:25, Bjorn Andersson wrote: > > += SUBNODES > + > +The RPM exposes resources to its subnodes. The below bindings specify the set > +of valid subnodes that can operate on these resources. > + > +== Regulators > + > +Regulator notes are identified by their compatible: > + > +- compatible: > + Usage: required > + Value type: <string> > + Definition: must be one of: > + "qcom,rpm-pm8058-regulators" > + "qcom,rpm-pm8901-regulators" > + "qcom,rpm-pm8921-regulators" > + > +- vdd_l0_l1_lvs-supply: > +- vdd_l10-supply: > +- vdd_l13_l16-supply: > +- vdd_l14_l15-supply: > +- vdd_l17_l18-supply: > +- vdd_l19_l20-supply: > +- vdd_l21-supply: > +- vdd_l22-supply: > +- vdd_l23_l24_l25-supply: > +- vdd_l2_l11_l12-supply: > +- vdd_l3_l4_l5-supply: > +- vdd_l6_l7-supply: > +- vdd_l8-supply: > +- vdd_l9-supply: > +- vdd_ncp-supply: > +- vdd_s0-supply: > +- vdd_s1-supply: > +- vdd_s2-supply: > +- vdd_s3-supply: > +- vdd_s4-supply: > + Usage: optional (pm8058 only) > + Value type: <phandle> > + Definition: reference to regulator supplying the input pin, as > + described in the data sheet > + > +- vdd_l0-supply: > +- vdd_l1-supply: > +- vdd_l2-supply: > +- vdd_l3-supply: > +- vdd_l4-supply: > +- vdd_l5-supply: > +- vdd_l6-supply: > +- vdd_s0-supply: > +- vdd_s1-supply: > +- vdd_s2-supply: > +- vdd_s3-supply: > +- vdd_s4-supply: > +- lvs0_in-supply: > +- lvs1_in-supply: > +- lvs2_in-supply: > +- lvs3_in-supply: > +- mvs_in-supply: > + Usage: optional (pm8901 only) > + Value type: <phandle> > + Definition: reference to regulator supplying the input pin, as > + described in the data sheet > + > +- vin_l1_l2_l12_l18-supply: > +- vin_l24-supply: > +- vin_l25-supply: > +- vin_l27-supply: > +- vin_l28-supply: > +- vin_lvs_1_3_6-supply: > +- vin_lvs2-supply: > +- vin_lvs_4_5_7-supply: > +- vin_ncp-supply: Can you also include vin_s1,vin_s2, etc. for the rest of the supplies I left out? It looks like you've covered all the inputs for the other pmics. > + Usage: optional (pm8921 only) > + Value type: <phandle> > + Definition: reference to regulator supplying the input pin, as > + described in the data sheet > + > +The regulator node houses sub-nodes for each regulator within the device. Each > +sub-node is identified using the node's name, with valid values listed for each > +of the pmics below. > +
On Tue 03 Mar 10:53 PST 2015, Stephen Boyd wrote: > On 03/02/15 20:25, Bjorn Andersson wrote: [..] > > + > > +- vin_l1_l2_l12_l18-supply: > > +- vin_l24-supply: > > +- vin_l25-supply: > > +- vin_l27-supply: > > +- vin_l28-supply: > > +- vin_lvs_1_3_6-supply: > > +- vin_lvs2-supply: > > +- vin_lvs_4_5_7-supply: > > +- vin_ncp-supply: > > Can you also include vin_s1,vin_s2, etc. for the rest of the supplies I > left out? It looks like you've covered all the inputs for the other pmics. > Sorry, I had problems finding the information in the rather sparse documentation I have for the 8921, so I just assumed that I could steal your list. I finally managed to find the pinout diagram, so the correct list for pm8921 seems to be: - vdd_l1_2_12_18-supply - vdd_l3_15_17-supply - vdd_l5_8_16-supply - vdd_l6_7-supply - vdd_l9_11-supply - vdd_l10_22-supply - vdd_l21_23_29-supply - vdd_l24-supply - vdd_l25-supply - vdd_l26-supply - vdd_l27-supply - vdd_l28-supply - vdd_ncp-supply - vdd_s1-supply - vdd_s2-supply - vdd_s4-supply - vdd_s5-supply - vdd_s6-supply - vdd_s7-supply - vdd_s8-supply - vin_lvs1_3_6-supply - vin_lvs2-supply - vin_lvs4_5_7-supply I will send out an updated patch with these. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/03/15 13:54, Bjorn Andersson wrote: > On Tue 03 Mar 10:53 PST 2015, Stephen Boyd wrote: > >> On 03/02/15 20:25, Bjorn Andersson wrote: > [..] >>> + >>> +- vin_l1_l2_l12_l18-supply: >>> +- vin_l24-supply: >>> +- vin_l25-supply: >>> +- vin_l27-supply: >>> +- vin_l28-supply: >>> +- vin_lvs_1_3_6-supply: >>> +- vin_lvs2-supply: >>> +- vin_lvs_4_5_7-supply: >>> +- vin_ncp-supply: >> Can you also include vin_s1,vin_s2, etc. for the rest of the supplies I >> left out? It looks like you've covered all the inputs for the other pmics. >> > Sorry, I had problems finding the information in the rather sparse > documentation I have for the 8921, so I just assumed that I could steal > your list. > > I finally managed to find the pinout diagram, so the correct list for > pm8921 seems to be: > > - vdd_l1_2_12_18-supply > - vdd_l3_15_17-supply > - vdd_l5_8_16-supply vin_l4-supply? > - vdd_l6_7-supply > - vdd_l9_11-supply > - vdd_l10_22-supply > - vdd_l21_23_29-supply Also these seem to be vin_l21_l23_l29 where "l" precedes all numbers (for all the LDOs). > - vdd_l24-supply > - vdd_l25-supply > - vdd_l26-supply > - vdd_l27-supply > - vdd_l28-supply > - vdd_ncp-supply > - vdd_s1-supply > - vdd_s2-supply > - vdd_s4-supply > - vdd_s5-supply > - vdd_s6-supply > - vdd_s7-supply > - vdd_s8-supply > - vin_lvs1_3_6-supply > - vin_lvs2-supply > - vin_lvs4_5_7-supply > > I will send out an updated patch with these. s/vdd/vin/ seems to match my datasheet.
On Tue 03 Mar 14:02 PST 2015, Stephen Boyd wrote: > On 03/03/15 13:54, Bjorn Andersson wrote: > > On Tue 03 Mar 10:53 PST 2015, Stephen Boyd wrote: > > > >> On 03/02/15 20:25, Bjorn Andersson wrote: > > [..] > >>> + > >>> +- vin_l1_l2_l12_l18-supply: > >>> +- vin_l24-supply: > >>> +- vin_l25-supply: > >>> +- vin_l27-supply: > >>> +- vin_l28-supply: > >>> +- vin_lvs_1_3_6-supply: > >>> +- vin_lvs2-supply: > >>> +- vin_lvs_4_5_7-supply: > >>> +- vin_ncp-supply: > >> Can you also include vin_s1,vin_s2, etc. for the rest of the supplies I > >> left out? It looks like you've covered all the inputs for the other pmics. > >> > > Sorry, I had problems finding the information in the rather sparse > > documentation I have for the 8921, so I just assumed that I could steal > > your list. > > > > I finally managed to find the pinout diagram, so the correct list for > > pm8921 seems to be: > > > > - vdd_l1_2_12_18-supply > > - vdd_l3_15_17-supply > > - vdd_l5_8_16-supply > > vin_l4-supply? > Ahh, right, I missed the vdd_l4_l14 pad. > > - vdd_l6_7-supply > > - vdd_l9_11-supply > > - vdd_l10_22-supply > > - vdd_l21_23_29-supply > > Also these seem to be vin_l21_l23_l29 where "l" precedes all numbers > (for all the LDOs). > The other pmics name their inputs like that; should we just pick that naming scheme for all these supplies and be happy? > > - vdd_l24-supply > > - vdd_l25-supply > > - vdd_l26-supply > > - vdd_l27-supply > > - vdd_l28-supply > > - vdd_ncp-supply > > - vdd_s1-supply > > - vdd_s2-supply > > - vdd_s4-supply > > - vdd_s5-supply > > - vdd_s6-supply > > - vdd_s7-supply > > - vdd_s8-supply > > - vin_lvs1_3_6-supply > > - vin_lvs2-supply > > - vin_lvs4_5_7-supply > > > > I will send out an updated patch with these. > > s/vdd/vin/ seems to match my datasheet. > For all of these? Same with the other pmics? These are the documented pad names that I have, nice to see that they are named differently in different documents. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/03/15 14:17, Bjorn Andersson wrote: > On Tue 03 Mar 14:02 PST 2015, Stephen Boyd wrote: > >> On 03/03/15 13:54, Bjorn Andersson wrote: >>> On Tue 03 Mar 10:53 PST 2015, Stephen Boyd wrote: >>> >>>> On 03/02/15 20:25, Bjorn Andersson wrote: >>> [..] >>>>> + >>>>> +- vin_l1_l2_l12_l18-supply: >>>>> +- vin_l24-supply: >>>>> +- vin_l25-supply: >>>>> +- vin_l27-supply: >>>>> +- vin_l28-supply: >>>>> +- vin_lvs_1_3_6-supply: >>>>> +- vin_lvs2-supply: >>>>> +- vin_lvs_4_5_7-supply: >>>>> +- vin_ncp-supply: >>>> Can you also include vin_s1,vin_s2, etc. for the rest of the supplies I >>>> left out? It looks like you've covered all the inputs for the other pmics. >>>> >>> Sorry, I had problems finding the information in the rather sparse >>> documentation I have for the 8921, so I just assumed that I could steal >>> your list. >>> >>> I finally managed to find the pinout diagram, so the correct list for >>> pm8921 seems to be: >>> >>> - vdd_l1_2_12_18-supply >>> - vdd_l3_15_17-supply >>> - vdd_l5_8_16-supply >> vin_l4-supply? >> > Ahh, right, I missed the vdd_l4_l14 pad. > >>> - vdd_l6_7-supply >>> - vdd_l9_11-supply >>> - vdd_l10_22-supply >>> - vdd_l21_23_29-supply >> Also these seem to be vin_l21_l23_l29 where "l" precedes all numbers >> (for all the LDOs). >> > The other pmics name their inputs like that; should we just pick that > naming scheme for all these supplies and be happy? Ok. >>> - vdd_l24-supply >>> - vdd_l25-supply >>> - vdd_l26-supply >>> - vdd_l27-supply >>> - vdd_l28-supply >>> - vdd_ncp-supply >>> - vdd_s1-supply >>> - vdd_s2-supply >>> - vdd_s4-supply >>> - vdd_s5-supply >>> - vdd_s6-supply >>> - vdd_s7-supply >>> - vdd_s8-supply >>> - vin_lvs1_3_6-supply >>> - vin_lvs2-supply >>> - vin_lvs4_5_7-supply >>> >>> I will send out an updated patch with these. >> s/vdd/vin/ seems to match my datasheet. >> > For all of these? Same with the other pmics? > > These are the documented pad names that I have, nice to see that they > are named differently in different documents. Oh. I seem to have been looking at some pre-published doc that was still laying around. vdd seems to match the official documentation so that sounds good to me.
On Tue, Mar 03, 2015 at 08:02:51AM -0800, Bjorn Andersson wrote: > rpm { > compatible = "qcom,rpm-apq8960"; > > regulators { > compatible = "qcom,rpm-pm8921-regulators"; Oh, so what you're saying is that the pm8921 is not actually a MFD at all? Why name it like a MFD component then?
diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt index 85e3198..92bcd19 100644 --- a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt +++ b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt @@ -31,16 +31,6 @@ frequencies. Value type: <string-array> Definition: must be the three strings "ack", "err" and "wakeup", in order -- #address-cells: - Usage: required - Value type: <u32> - Definition: must be 1 - -- #size-cells: - Usage: required - Value type: <u32> - Definition: must be 0 - - qcom,ipc: Usage: required Value type: <prop-encoded-array> @@ -52,6 +42,172 @@ frequencies. - u32 representing the ipc bit within the register += SUBNODES + +The RPM exposes resources to its subnodes. The below bindings specify the set +of valid subnodes that can operate on these resources. + +== Regulators + +Regulator notes are identified by their compatible: + +- compatible: + Usage: required + Value type: <string> + Definition: must be one of: + "qcom,rpm-pm8058-regulators" + "qcom,rpm-pm8901-regulators" + "qcom,rpm-pm8921-regulators" + +- vdd_l0_l1_lvs-supply: +- vdd_l10-supply: +- vdd_l13_l16-supply: +- vdd_l14_l15-supply: +- vdd_l17_l18-supply: +- vdd_l19_l20-supply: +- vdd_l21-supply: +- vdd_l22-supply: +- vdd_l23_l24_l25-supply: +- vdd_l2_l11_l12-supply: +- vdd_l3_l4_l5-supply: +- vdd_l6_l7-supply: +- vdd_l8-supply: +- vdd_l9-supply: +- vdd_ncp-supply: +- vdd_s0-supply: +- vdd_s1-supply: +- vdd_s2-supply: +- vdd_s3-supply: +- vdd_s4-supply: + Usage: optional (pm8058 only) + Value type: <phandle> + Definition: reference to regulator supplying the input pin, as + described in the data sheet + +- vdd_l0-supply: +- vdd_l1-supply: +- vdd_l2-supply: +- vdd_l3-supply: +- vdd_l4-supply: +- vdd_l5-supply: +- vdd_l6-supply: +- vdd_s0-supply: +- vdd_s1-supply: +- vdd_s2-supply: +- vdd_s3-supply: +- vdd_s4-supply: +- lvs0_in-supply: +- lvs1_in-supply: +- lvs2_in-supply: +- lvs3_in-supply: +- mvs_in-supply: + Usage: optional (pm8901 only) + Value type: <phandle> + Definition: reference to regulator supplying the input pin, as + described in the data sheet + +- vin_l1_l2_l12_l18-supply: +- vin_l24-supply: +- vin_l25-supply: +- vin_l27-supply: +- vin_l28-supply: +- vin_lvs_1_3_6-supply: +- vin_lvs2-supply: +- vin_lvs_4_5_7-supply: +- vin_ncp-supply: + Usage: optional (pm8921 only) + Value type: <phandle> + Definition: reference to regulator supplying the input pin, as + described in the data sheet + +The regulator node houses sub-nodes for each regulator within the device. Each +sub-node is identified using the node's name, with valid values listed for each +of the pmics below. + +pm8058: + l0, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, + l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, s0, s1, s2, s3, s4, + lvs0, lvs1, ncp + +pm8901: + l0, l1, l2, l3, l4, l5, l6, s0, s1, s2, s3, s4, lvs0, lvs1, lvs2, lvs3, + mvs + +pm8921: + s1, s2, s3, s4, s7, s8, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, + l12, l14, l15, l16, l17, l18, l21, l22, l23, l24, l25, l26, l27, l28, + l29, lvs1, lvs2, lvs3, lvs4, lvs5, lvs6, lvs7, usb-switch, hdmi-switch, + ncp + +The content of each sub-node is defined by the standard binding for regulators - +see regulator.txt - with additional custom properties described below: + +=== Switch-mode Power Supply regulator custom properties + +- bias-pull-down: + Usage: optional + Value type: <empty> + Definition: enable pull down of the regulator when inactive + +- qcom,switch-mode-frequency: + Usage: required + Value type: <u32> + Definition: Frequency (Hz) of the switch-mode power supply; + must be one of: + 19200000, 9600000, 6400000, 4800000, 3840000, 3200000, + 2740000, 2400000, 2130000, 1920000, 1750000, 1600000, + 1480000, 1370000, 1280000, 1200000 + +- qcom,force-mode: + Usage: optional (default if no other qcom,force-mode is specified) + Value type: <u32> + Defintion: indicates that the regulator should be forced to a + particular mode, valid values are: + QCOM_RPM_FORCE_MODE_NONE - do not force any mode + QCOM_RPM_FORCE_MODE_LPM - force into low power mode + QCOM_RPM_FORCE_MODE_HPM - force into high power mode + QCOM_RPM_FORCE_MODE_AUTO - allow regulator to automatically + select its own mode based on + realtime current draw, only for: + pm8921 smps and ftsmps + +- qcom,power-mode-hysteretic: + Usage: optional + Value type: <empty> + Definition: select that the power supply should operate in hysteretic + mode, instead of the default pwm mode + +=== Low-dropout regulator custom properties + +- bias-pull-down: + Usage: optional + Value type: <empty> + Definition: enable pull down of the regulator when inactive + +- qcom,force-mode: + Usage: optional + Value type: <u32> + Defintion: indicates that the regulator should not be forced to any + particular mode, valid values are: + QCOM_RPM_FORCE_MODE_NONE - do not force any mode + QCOM_RPM_FORCE_MODE_LPM - force into low power mode + QCOM_RPM_FORCE_MODE_HPM - force into high power mode + QCOM_RPM_FORCE_MODE_BYPASS - set regulator to use bypass + mode, i.e. to act as a switch + and not regulate, only for: + pm8921 pldo, nldo and nldo1200 + +=== Negative Charge Pump custom properties + +- qcom,switch-mode-frequency: + Usage: required + Value type: <u32> + Definition: Frequency (Hz) of the swith mode power supply; + must be one of: + 19200000, 9600000, 6400000, 4800000, 3840000, 3200000, + 2740000, 2400000, 2130000, 1920000, 1750000, 1600000, + 1480000, 1370000, 1280000, 1200000 + = EXAMPLE #include <dt-bindings/mfd/qcom-rpm.h> @@ -64,7 +220,28 @@ frequencies. interrupts = <0 19 0>, <0 21 0>, <0 22 0>; interrupt-names = "ack", "err", "wakeup"; - #address-cells = <1>; - #size-cells = <0>; + regulators { + compatible = "qcom,rpm-pm8921-regulators"; + vin_l1_l2_l12_l18-supply = <&pm8921_s4>; + + s1 { + regulator-min-microvolt = <1225000>; + regulator-max-microvolt = <1225000>; + + bias-pull-down; + + qcom,switch-mode-frequency = <3200000>; + }; + + pm8921_s4: s4 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + + qcom,switch-mode-frequency = <1600000>; + bias-pull-down; + + qcom,force-mode = <QCOM_RPM_FORCE_MODE_AUTO>; + }; + }; };
Add the regulator subnodes to the Qualcomm RPM MFD device tree bindings. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> --- As the previously accepted binding didn't cover any functionality but registering the mfd core there is no users, hence it's fine to drop the two required fields at this time. Documentation/devicetree/bindings/mfd/qcom-rpm.txt | 201 +++++++++++++++++++-- 1 file changed, 189 insertions(+), 12 deletions(-)