于 2017年7月18日 GMT+08:00 上午10:58:52, Chen-Yu Tsai <wens@xxxxxxxx> 写到: >On Fri, May 19, 2017 at 4:55 PM, Andre Przywara ><andre.przywara@xxxxxxx> wrote: >> Hi, >> >> On 19/05/17 09:29, Icenowy Zheng wrote: >>> >>> >>> 于 2017年5月19日 GMT+08:00 下午4:27:21, Andre Przywara ><andre.przywara@xxxxxxx> 写到: >>>> 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@xxxxxxx> >>>>> --- >>>>> 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" >>>>> + >>>>> +®_aldo1 { >>>>> + regulator-min-microvolt = <2800000>; >>>>> + regulator-max-microvolt = <2800000>; >>>>> + regulator-name = "vcc-csi"; >>>>> +}; >>>>> + >>>>> +®_aldo2 { >>>>> + regulator-always-on; >>>>> + regulator-min-microvolt = <1800000>; >>>>> + regulator-max-microvolt = <3300000>; >>>>> + regulator-name = "vcc-pl"; >>>>> +}; >>>>> + >>>>> +®_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. > >> >>>>> + >>>>> +®_dc1sw { >>>>> + regulator-name = "vcc-phy"; >>>>> +}; >>>>> + >>>>> +®_dcdc1 { >>>>> + regulator-always-on; >>>>> + regulator-min-microvolt = <3300000>; >>>>> + regulator-max-microvolt = <3300000>; >>>>> + regulator-name = "vcc-3v3"; >>>>> +}; >>>>> + >>>>> +®_dcdc2 { >>>>> + regulator-always-on; >>>>> + regulator-min-microvolt = <1000000>; >>>>> + regulator-max-microvolt = <1300000>; >>>>> + regulator-name = "vdd-cpux"; >>>>> +}; >>>>> + >>>>> +/* DCDC3 is polyphased with DCDC2 */ >>>>> + >>>>> +®_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 ;-) >> >>>>> +®_dcdc6 { >>>>> + regulator-always-on; >>>>> + regulator-min-microvolt = <1100000>; >>>>> + regulator-max-microvolt = <1100000>; >>>>> + regulator-name = "vdd-sys"; >>>>> +}; >>>>> + >>>>> +®_dldo1 { >>>>> + regulator-min-microvolt = <3300000>; >>>>> + regulator-max-microvolt = <3300000>; >>>>> + regulator-name = "vcc-hdmi"; >>>>> +}; >>>>> + >>>>> +®_dldo2 { >>>>> + regulator-min-microvolt = <3300000>; >>>>> + regulator-max-microvolt = <3300000>; >>>>> + regulator-name = "vcc-mipi"; >>>>> +}; >>>>> + >>>>> +®_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... > >>>>> + >>>>> +®_dldo4 { >>>>> + regulator-min-microvolt = <3300000>; >>>>> + regulator-max-microvolt = <3300000>; >>>>> + regulator-name = "vcc-wifi"; >>>>> +}; >>>>> + >>>>> +®_eldo1 { >>>>> + regulator-min-microvolt = <1800000>; >>>>> + regulator-max-microvolt = <1800000>; >>>>> + regulator-name = "cpvdd"; >>>>> +}; >>>>> + >>>>> +®_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. Agree. > >> >>>>> + >>>>> +®_fldo1 { >>>>> + regulator-min-microvolt = <1200000>; >>>>> + regulator-max-microvolt = <1200000>; >>>>> + regulator-name = "vcc-1v2-hsic"; >>>>> +}; >>>>> + >>>>> +®_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. Yes it failed to work, and this seems to be common among SoCs with CPUs power domain. > >ChenYu > >> Cheers, >> Andre. >> >>>>> + regulator-min-microvolt = <1100000>; >>>>> + regulator-max-microvolt = <1100000>; >>>>> + regulator-name = "vdd-cpus"; >>>>> +}; >>>>> + >>>>> +®_rtc_ldo { >>>>> + regulator-name = "vcc-rtc"; >>>>> +}; >>>>> + >>>>> /* On Exp and Euler connectors */ >>>>> &uart0 { >>>>> pinctrl-names = "default"; >>>>> -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html