| Message ID | 1391516352-32359-3-git-send-email-mporter@linaro.org |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Tue, Feb 04, 2014 at 07:19:08AM -0500, Matt Porter wrote: > Add a DT binding for the BCM59056 PMU. The binding inherits from > the generic regulator bindings. Is this really only a regulator - does the chip have no other functions? > +- regulators: This is the list of child nodes that specify the regulator > + initialization data for defined regulators. Generic regulator bindings > + are described in regulator/regulator.txt. The regulators property should always be optional, the driver should be able to start up and read back the hardware state without any further configuration.
On Tue, Feb 04, 2014 at 05:23:09PM +0000, Mark Brown wrote: > On Tue, Feb 04, 2014 at 07:19:08AM -0500, Matt Porter wrote: > > Add a DT binding for the BCM59056 PMU. The binding inherits from > > the generic regulator bindings. > > Is this really only a regulator - does the chip have no other functions? It's your average multi-function device with other functions as you are suspecting. Buried in the the MFD driver comments is me admitting that I need to split this into two bindings. The base device, "bcm59056" and then "bcm59056-reg". So point noted, I'll updated with the appropriate binding for each. > > +- regulators: This is the list of child nodes that specify the regulator > > + initialization data for defined regulators. Generic regulator bindings > > + are described in regulator/regulator.txt. > > The regulators property should always be optional, the driver should be > able to start up and read back the hardware state without any further > configuration. Ahh, ok. I will make it so. Thanks, Matt -- 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 Tue, Feb 04, 2014 at 04:16:38PM -0500, Matt Porter wrote: > On Tue, Feb 04, 2014 at 05:23:09PM +0000, Mark Brown wrote: > > Is this really only a regulator - does the chip have no other functions? > It's your average multi-function device with other functions as you are > suspecting. Buried in the the MFD driver comments is me admitting that > I need to split this into two bindings. The base device, "bcm59056" and > then "bcm59056-reg". So point noted, I'll updated with the appropriate > binding for each. It doesn't need to be two bindings - just move it to the MFD section and document it there. The existing binding is totally fine from a regulator standpoint and should continue to be so as other functions are added.
diff --git a/Documentation/devicetree/bindings/regulator/bcm59056.txt b/Documentation/devicetree/bindings/regulator/bcm59056.txt new file mode 100644 index 0000000..bf6b633 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/bcm59056.txt @@ -0,0 +1,37 @@ +BCM59056 Power Management Unit + +Required properties: +- compatible: "brcm,bcm59056" +- reg: I2C slave address +- interrupts: interrupt for the PMU. Generic interrupt client node bindings + are described in interrupt-controller/interrupts.txt +- regulators: This is the list of child nodes that specify the regulator + initialization data for defined regulators. Generic regulator bindings + are described in regulator/regulator.txt. + + The valid regulator-compatible values are: + rfldo, camldo1, camldo2, simldo1, simlso2, sdldo, sdxldo, + mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo, + csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr + +Example: + pmu: bcm59056@8 { + compatible = "brcm,bcm59056"; + reg = <0x08>; + interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>; + regulators { + #address-cells = <1>; + #size-cells = <0>; + + rfldo_reg: regulator@0 { + reg = <0>; + regulator-compatible = "rfldo"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + regulator-boot-on; + }; + + ... + }; + };