lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 18 Jul 2017 10:58:52 +0800
From:   Chen-Yu Tsai <wens@...e.org>
To:     Icenowy Zheng <icenowy@...c.io>
Cc:     Andre Przywara <andre.przywara@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Marc Zyngier <marc.zyngier@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>,
        Chen-Yu Tsai <wens@...e.org>, Lee Jones <lee.jones@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-sunxi <linux-sunxi@...glegroups.com>
Subject: Re: [linux-sunxi] [PATCH v6 8/9] arm64: allwinner: a64: enable AXP803
 regulators for Pine64

On Fri, May 19, 2017 at 4:55 PM, Andre Przywara <andre.przywara@....com> wrote:
> Hi,
>
> On 19/05/17 09:29, Icenowy Zheng wrote:
>>
>>
>> 于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara <andre.przywara@....com> 写到:
>>> Hi,
>>>
>>> On 18/05/17 08:16, Icenowy Zheng wrote:
>>>> Add support of AXP803 regulators in the Pine64 device tree, in order
>>> to
>>>> enable many future functionalities, e.g. Wi-Fi.
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy@...c.io>
>>>> ---
>>>> Changes in v6:
>>>> - Rebased on next-20170517.
>>>>
>>>>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>>> +++++++++++++++++++++
>>>>  1 file changed, 109 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> index 36001884ed33..40921bacb39c 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> @@ -118,6 +118,115 @@
>>>>     };
>>>>  };
>>>>
>>>> +#include "axp803.dtsi"
>>>> +
>>>> +&reg_aldo1 {
>>>> +   regulator-min-microvolt = <2800000>;
>>>> +   regulator-max-microvolt = <2800000>;
>>>> +   regulator-name = "vcc-csi";
>>>> +};
>>>> +
>>>> +&reg_aldo2 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1800000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-pl";
>>>> +};
>>>> +
>>>> +&reg_aldo3 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <2700000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-pll-avcc";
>>>> +};
>
> The schematic puts this at a fixed 3.0V, so why the range here? Are we
> expected to tune the voltage of the PLLs?

Normally these would describe the operating limits. We did this
in the past for most boards. I'm fine with fixing it to 3.0V
though.

>
>>>> +
>>>> +&reg_dc1sw {
>>>> +   regulator-name = "vcc-phy";
>>>> +};
>>>> +
>>>> +&reg_dcdc1 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-3v3";
>>>> +};
>>>> +
>>>> +&reg_dcdc2 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1000000>;
>>>> +   regulator-max-microvolt = <1300000>;
>>>> +   regulator-name = "vdd-cpux";
>>>> +};
>>>> +
>>>> +/* DCDC3 is polyphased with DCDC2 */
>>>> +
>>>> +&reg_dcdc5 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1500000>;
>>>> +   regulator-max-microvolt = <1500000>;
>>>> +   regulator-name = "vcc-dram";
>>>> +};
>>>
>>> I think I mentioned this before, but the Pine64 has DDR3L DRAM, which
>>> is
>>> specified to run at 1.35V (1.36V with the 20mV granularity of the AXP).
>>> The reset value is even (wrongly?) configured to 1.24V.
>>>
>>> So is there any reason you set the voltage to 1.5V? Is that what the
>>> BSP
>>> does? Or did you see any problems with 1.36V?
>>
>> I just set it based on the schematics.
>
> I wouldn't trust the schematics too much. They are rather generic, see
> the Ethernet page, for instance, showing *different* PHYs, not just the
> ones used.
> For the DRAM the Pine64 schematic does not even tell the DRAM chip used,
> the name under the chip is just describing the package.
>
>> And 1.35v cannot be accurately achieved by dcdc5 and it's a problem whether to use 1.34v or 1.36v ;-)
>
> Well, as I wrote above, 1.36V is the voltage to go with. I think 10mV
> more is well within the tolerance ;-)
>
>>>> +&reg_dcdc6 {
>>>> +   regulator-always-on;
>>>> +   regulator-min-microvolt = <1100000>;
>>>> +   regulator-max-microvolt = <1100000>;
>>>> +   regulator-name = "vdd-sys";
>>>> +};
>>>> +
>>>> +&reg_dldo1 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-hdmi";
>>>> +};
>>>> +
>>>> +&reg_dldo2 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-mipi";
>>>> +};
>>>> +
>>>> +&reg_dldo3 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "avdd-csi";
>>>> +};
>
> If you stick to the schematic, this should be 2.8V.

Agreed. But...

>>>> +
>>>> +&reg_dldo4 {
>>>> +   regulator-min-microvolt = <3300000>;
>>>> +   regulator-max-microvolt = <3300000>;
>>>> +   regulator-name = "vcc-wifi";
>>>> +};
>>>> +
>>>> +&reg_eldo1 {
>>>> +   regulator-min-microvolt = <1800000>;
>>>> +   regulator-max-microvolt = <1800000>;
>>>> +   regulator-name = "cpvdd";
>>>> +};
>>>> +
>>>> +&reg_eldo3 {
>>>> +   regulator-min-microvolt = <1800000>;
>>>> +   regulator-max-microvolt = <1800000>;
>>>> +   regulator-name = "vdd-1v8-csi";
>>>> +};
>
> The schematic lists 1.2V/1.5V/1.8V here, so should we have a range?

This and avdd-csi really depends on the camera module used.
Maybe this should be left to an overlay.

>
>>>> +
>>>> +&reg_fldo1 {
>>>> +   regulator-min-microvolt = <1200000>;
>>>> +   regulator-max-microvolt = <1200000>;
>>>> +   regulator-name = "vcc-1v2-hsic";
>>>> +};
>>>> +
>>>> +&reg_fldo2 {
>>>> +   regulator-always-on;
>
> Why do we need to turn this on? Upstream firmware does not use the
> arisc, so it can stay off.
> Also in general I think Linux should not tinker with the management
> processor at all.

I'm not sure, but I think at least one SoC had failed to work without
this powered on. If that is the case with the A64, then please leave
a comment saying so. Otherwise let it stay off.

ChenYu

> Cheers,
> Andre.
>
>>>> +   regulator-min-microvolt = <1100000>;
>>>> +   regulator-max-microvolt = <1100000>;
>>>> +   regulator-name = "vdd-cpus";
>>>> +};
>>>> +
>>>> +&reg_rtc_ldo {
>>>> +   regulator-name = "vcc-rtc";
>>>> +};
>>>> +
>>>>  /* On Exp and Euler connectors */
>>>>  &uart0 {
>>>>     pinctrl-names = "default";
>>>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ