[linux-sunxi] [PATCH v2 1/1] dts: sun6i: yones toptech bs1078 v2: Add AXP221 support to dts

[Chen-Yu Tsai]

On Thu, Oct 22, 2015 at 12:15 AM, Lawrence Yu <lyu at micile.com> wrote:
> On Mon, Oct 19, 2015 at 2:59 AM, Chen-Yu Tsai <wens at csie.org> wrote:
>> On Mon, Oct 19, 2015 at 2:07 AM, Lawrence Yu <lyu at micile.com> wrote:
>>> Enable the axp221 PMIC chip in the dts file.
>>>
>>> Allows board to power off correctly from the poweroff command
>>>
>>> This board requires dc1sw to be enabled in order to provide a power source
>>> for the 5V DCDC converter that powers USB2 and the LCD backlight
>>>
>>> This board uses dldo1 for 3.3V wifi power
>>>
>>> This board requires dldo3 to be enabled at 2.8V in order to provide voltage
>>> to the pullup resistors for the i2c0 bus.
>>>
>>> ---
>>>
>>> Changes since v1
>>>
>>> - Use axp22x.dtsi to standardize the register names
>>> - Change wifi power regulator to dldo1 instead of incorrect aldo1
>>> - Remove unnecessary gpio pin PH27 for wifi power, since this board uses
>>>   the axp221 chip to control power to the wifi chip.
>>>
>>> Signed-off-by: Lawrence Yu <lyu at micile.com>
>>> ---
>>>  .../dts/sun6i-a31s-yones-toptech-bs1078-v2.dts     | 98 +++++++++++++++++++---
>>>  1 file changed, 88 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts b/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts
>>> index b199020..98d0a83 100644
>>> --- a/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts
>>> +++ b/arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts
>>> @@ -113,22 +113,100 @@
>>>         allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>>>  };
>>>
>>> -&reg_usb1_vbus {
>>> -       gpio = <&pio 7 27 GPIO_ACTIVE_HIGH>;
>>> +&uart0 {
>>> +       pinctrl-names = "default";
>>> +       pinctrl-0 = <&uart0_pins_a>;
>>>         status = "okay";
>>>  };
>>>
>>> -&usb1_vbus_pin_a {
>>> -       allwinner,pins = "PH27";
>>> +&p2wi {
>>> +       status = "okay";
>>> +
>>> +       axp22x: pmic at 68 {
>>> +               compatible = "x-powers,axp221";
>>> +               reg = <0x68>;
>>> +               interrupt-parent = <&nmi_intc>;
>>> +               interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>>> +       };
>>>  };
>>>
>>> -&usbphy {
>>> -       usb1_vbus-supply = <&reg_usb1_vbus>;
>>> -       status = "okay";
>>> +#include "axp22x.dtsi"
>>> +
>>> +&axp22x {
>>> +       regulators {
>>> +               /* Used by LCD backlight and USB2 */
>>> +               reg_dc1sw: dc1sw {
>>> +                       regulator-name = "dc1sw";
>>> +                       regulator-min-microvolt = <3000000>;
>>> +                       regulator-max-microvolt = <3000000>;
>>> +                       regulator-name = "vcc-dc1sw";
>>
>> I would use "vcc-lcd-usb2". Or just "vcc-lcd" if it proves it has nothing
>> to do with USB. Plus there's 2 "regulator-name" entries here.
>>
>
> I will remove the extra regulator-name (not sure how I did not see
> that) and use "vcc-lcd-usb2" as the regulator name.  I have an
> explanation as to why I believe dc1sw also controls power to usb2
> below.
>
>>> +               };
>>> +       };
>>>  };
>>>
>>> -&uart0 {
>>> -       pinctrl-names = "default";
>>> -       pinctrl-0 = <&uart0_pins_a>;
>>> +&reg_aldo3 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <2700000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "avcc";
>>> +};
>>> +
>>> +&reg_dc5ldo {
>>> +       regulator-min-microvolt = <700000>;
>>> +       regulator-max-microvolt = <1320000>;
>>> +       regulator-name = "vdd-cpus";
>>> +};
>>> +
>>> +&reg_dcdc1 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <3000000>;
>>> +       regulator-max-microvolt = <3000000>;
>>> +       regulator-name = "vcc-3v0";
>>> +};
>>> +
>>> +&reg_dcdc2 {
>>> +       regulator-min-microvolt = <700000>;
>>> +       regulator-max-microvolt = <1320000>;
>>> +       regulator-name = "vdd-gpu";
>>> +};
>>> +
>>> +&reg_dcdc3 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <700000>;
>>> +       regulator-max-microvolt = <1320000>;
>>> +       regulator-name = "vdd-cpu";
>>> +};
>>> +
>>> +&reg_dcdc4 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <700000>;
>>> +       regulator-max-microvolt = <1320000>;
>>> +       regulator-name = "vdd-sys-dll";
>>> +};
>>> +
>>> +&reg_dcdc5 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <1500000>;
>>> +       regulator-max-microvolt = <1500000>;
>>> +       regulator-name = "vcc-dram";
>>> +};
>>> +
>>> +&reg_dldo1 {
>>> +       regulator-min-microvolt = <3300000>;
>>> +       regulator-max-microvolt = <3300000>;
>>> +       regulator-name = "vcc-wifi";
>>> +};
>>> +
>>> +/* Voltage source for I2C pullup resistors for I2C Bus 0 */
>>> +&reg_dldo3 {
>>> +       regulator-always-on;
>>> +       regulator-min-microvolt = <2800000>;
>>> +       regulator-max-microvolt = <2800000>;
>>> +       regulator-name = "vcc-csi";
>>
>> This should probably be named "vddio-csi".
>
> I will change the name of the regulator to "vddio-csi".  I did not
> realize that dldo3 was connected to the io vdd of the cameras until
> you pointed it out, the A31 reference schematic also verifies this.

The FEX file also says so.

>>
>> I think Maxime and Hans were still debating whether the camera VDDIO
>> regulator should be defined independently as "always-on", instead of
>> having the I2C subsystem do some kind of power sequencing.
>>
>
> I propose to remove the regulator-always-on from dldo3 for now to
> match Maxime and Hans' resolution for the protab2-ips9 tablet which
> has similar behavior.  i2c0 is not defined yet for this board so not
> turning on dldo3 should not cause any loss of functionality.
>
>> I wonder if the power domain stuff would work for this.
>
> I defer to Maxime's response about power domain since I have no
> knowledge or experience pertaining to power domains.
>
>>
>>> +};
>>> +
>>> +&usbphy {
>>> +       usb1_vbus-supply = <&reg_dldo1>;
>>> +       usb2_vbus-supply = <&reg_dc1sw>;
>>
>> This looks weird, though I cannot say it is impossible. There is likely
>> a boost regulator after this so the output is proper 5V for USB.
>>
>
> I believe that you are correct that there is a boost regulator to make
> 5V for the USB2.  The power input and/or enable line to the boost
> regulator appears to be connected to the output of dc1sw since if I
> set dc1sw to regulator-always-on or as the usb2_vbus-supply, the USB2
> will provide power to devices plugged into the USB port (LEDs on the
> device light up).  If I do not, then devices attached to USB2 do not
> appear to receive any power.
>
> Enabling or disabling dc1sw also determines whether the LCD backlight
> turns on or not.  From my testing the backlight enable line is
> connected to gpio PA25 so it seems most likely that the input of the
> boost regulator for the LCD backlight is the output of dc1sw.

In most designs, the LCD backlight is powered by a LED boost regulator,
which is powered from IPSOUT of the PMIC. This regulator has its enable
pin connected to a GPIO, PA25 in this case. Often the feedback pin is
also connected to the PWM output (PH13) of the SoC, and there is also a
pull-up from VCC-LCD. Hans speculates this is to prevent flickering.

DC1SW only powers the LCD panel itself, not the backlight. You could
play with the GPIOs and regulator, and see if can get just one of them
to be on.

As for USB2, if the intention is to have the device available when the
user is actively using the tablet, like for a storage or input device,
it makes sense to tie it to the LCD power.

> If there is a more conventional way to have dc1sw enabled for the
> USB2, I can make the change to do that.

I think this is fine, even though we are omitting the boost regulator.
If that is of concern, you can just chain a fixed regulator in between.

>> Also, we only have the FEX file for v1 of this board in sunxi-boards.
>> Would it be possible for you to extract and submit it?
>>
>
> I have the fex file extracted and I will submit a separate patch with
> the fex file to sunxi-boards.

Can you add your signed-off-by to that for the record? No need to resend,
just reply to it.

Thanks
ChenYu

>> Having the FEX file makes reviewing the dts without schematics slightly
>> easier.
>>
>> Thanks
>> ChenYu
>>
>>>         status = "okay";
>>>  };
>>> --
>>> 2.5.3
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.