[PATCH v3 4/9] ARM: dts: sun7i: cubieboard2: add axp209 regulator nodes
Chen-Yu Tsai
wens at csie.org
Mon Jan 12 01:38:12 PST 2015
Hi,
On Mon, Jan 12, 2015 at 5:06 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> Hi Chen-Yu,
>
> On Mon, Jan 12, 2015 at 12:34:04PM +0800, Chen-Yu Tsai wrote:
>> This patch adds the regulator nodes for the axp209 by including
>> the axp209 dtsi. As the inputs of these regulators are from the
>> axp209's PS output, which is basically just a mux over the 2
>> inputs, it is considered to be unregulated. Thus we do not provide
>> input supply properties for them.
>>
>> The regulator names and constraints are based on the board
>> schematics and the SoC datasheet.
>>
>> DCDC2 is used as the cpu power supply. This patch also references
>> it from the cpu node.
>>
>> Also get rid of axp209 properties already set in axp209.dtsi.
>>
>> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
>> ---
>>
>> changes since v2
>>
>> none
>>
>> changes since v1:
>>
>> - Use preprocessor include for axp209.dtsi
>> - Remove incorrectly squashed axp209.dtsi patch
>>
>> ---
>> arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 35 +++++++++++++++++++++++++----
>> 1 file changed, 31 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
>> index 18fc5db9c976..ec1fc2c8b3e3 100644
>> --- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
>> +++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
>> @@ -88,13 +88,9 @@
>> status = "okay";
>>
>> axp209: pmic at 34 {
>> - compatible = "x-powers,axp209";
>> reg = <0x34>;
>> interrupt-parent = <&nmi_intc>;
>> interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>> -
>> - interrupt-controller;
>> - #interrupt-cells = <1>;
>> };
>> };
>>
>> @@ -145,3 +141,34 @@
>> status = "okay";
>> };
>> };
>> +
>> +#include "axp209.dtsi"
>> +
>> +&cpu0 {
>> + cpu-supply = <®_dcdc2>;
>> +};
>> +
>> +®_dcdc2 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <1000000>;
>> + regulator-max-microvolt = <1450000>;
>> + regulator-name = "vdd-cpu";
>> +};
>> +
>> +®_dcdc3 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <1000000>;
>> + regulator-max-microvolt = <1400000>;
>> + regulator-name = "vdd-int-dll";
>> +};
>> +
>> +®_ldo1 {
>> + regulator-name = "vdd-rtc";
>> +};
>> +
>> +®_ldo2 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <3000000>;
>> + regulator-max-microvolt = <3000000>;
>> + regulator-name = "avcc";
>> +};
>
> How do reg_vcc3v3 and the other reg used in this DT (ahci, USB) fit
> into that?
The following applies to boards that use AXP209.
reg_vcc3v3 or reg_vcc3v0 is an external buck regulator with it's
enable pin tied to EXTEN on the AXP. This pin is controllable,
but we do not have the driver for it. It is possible that multiple
regulators are tied to this pin. I suggest not touching it without
the correct schematics.
The source for usb and ahci regulators, or reg_vcc5v if you will,
is either the unregulated 5v from the power supply or the usb otg
port. For the Cubietruck, there's an additional uncontrollable
boost regulator that boosts the lipo battery's power up to 5v.
On some of the Olimex boards that use higher input voltages, they
use an uncontrollable buck regulator to step down the voltage to
5v. The Olinuxino-Micro also has a boost regulator for the battery,
tied to EXTEN.
The AXP209 simply does not have enough outputs for all the needed
voltages.
You could probably chain the regulators in the DT via xxx-supply
if it helps. But beyond that, it is hard to do anything meaningful
at this point. Modeling them as fixed regulators beyond our control
is simpler. We also do not have an IPSOUT regulator for the AXP.
> Eventually, I think we would be able to remove
> sunxi-common-regulators.dtsi, or at least, expose the proper regulator
> hierarchy.
The USB and SATA regulators are just GPIO enabled switches (MOSFETs)
or current limiters. I think these will always exist because of the
reference designs. Or do you want to move them back into the board
dts files? FWIW, I like it the way it is now. Not that I don't like
it to be accurate.
ChenYu
More information about the linux-arm-kernel
mailing list