[linux-sunxi] Re: [PATCH v4 02/13] clk: sunxi: add ahb1 clock for A83T
Hello Maxime,
On Thu, Mar 17, 2016 at 6:40 PM, Maxime Ripard
wrote:
> On Thu, Mar 17, 2016 at 12:04:25AM +0800, Vishnu Patekar wrote:
>> AHB1 on A83T is similar to ahb1 on A31, except parents are different.
>> clock index 0b1x is PLL6.
>>
>> Signed-off-by: Vishnu Patekar
>> Acked-by: Chen-Yu Tsai
>> Acked-by: Rob Herring
>> ---
>> Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
>> drivers/clk/sunxi/clk-sunxi.c | 76
>> +++
>> 2 files changed, 77 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
>> b/Documentation/devicetree/bindings/clock/sunxi.txt
>> index 834436f..cba9fe55 100644
>> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
>> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
>> @@ -30,6 +30,7 @@ Required properties:
>> "allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31
>> "allwinner,sun9i-a80-cpus-clk" - for the CPUS on A80
>> "allwinner,sun6i-a31-ahb1-clk" - for the AHB1 clock on A31
>> + "allwinner,sun8i-a83t-ahb1-clk" - for the AHB1 clock on A83T
>> "allwinner,sun8i-h3-ahb2-clk" - for the AHB2 clock on H3
>> "allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
>> "allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>> index 91de0a0..a7aab65 100644
>> --- a/drivers/clk/sunxi/clk-sunxi.c
>> +++ b/drivers/clk/sunxi/clk-sunxi.c
>> @@ -344,6 +344,67 @@ static void sun6i_ahb1_recalc(struct factors_request
>> *req)
>> req->rate >>= req->p;
>> }
>>
>> +#define SUN8I_A83T_AHB1_PARENT_PLL6 2
>> +/**
>> + * sun8i_a83t_get_ahb_factors() - calculates m, p factors for AHB
>> + * AHB rate is calculated as follows
>> + * rate = parent_rate >> p
>> + *
>> + * if parent is pll6, then
>> + * parent_rate = pll6 rate / (m + 1)
>> + */
>> +
>> +static void sun8i_a83t_get_ahb1_factors(struct factors_request *req)
>> +{
>> + u8 div, calcp, calcm = 1;
>> +
>> + /*
>> + * clock can only divide, so we will never be able to achieve
>> + * frequencies higher than the parent frequency
>> + */
>> + if (req->parent_rate && req->rate > req->parent_rate)
>> + req->rate = req->parent_rate;
>> +
>> + div = DIV_ROUND_UP(req->parent_rate, req->rate);
>> +
>> + /* calculate pre-divider if parent is pll6 */
>> + if (req->parent_index >= SUN8I_A83T_AHB1_PARENT_PLL6) {
>> + if (div < 4)
>> + calcp = 0;
>> + else if (div / 2 < 4)
>> + calcp = 1;
>> + else if (div / 4 < 4)
>> + calcp = 2;
>> + else
>> + calcp = 3;
>> +
>> + calcm = DIV_ROUND_UP(div, 1 << calcp);
>> + } else {
>> + calcp = __roundup_pow_of_two(div);
>> + calcp = calcp > 3 ? 3 : calcp;
>> + }
>> +
>> + req->rate = (req->parent_rate / calcm) >> calcp;
>> + req->p = calcp;
>> + req->m = calcm - 1;
>> +}
>> +
>> +/**
>> +* sun8i_a83t_ahb1_recalc() - calculates AHB clock rate from m, p factors and
>> +* parent index
>> +*/
>> +static void sun8i_a83t_ahb1_recalc(struct factors_request *req)
>> +{
>> + req->rate = req->parent_rate;
>> +
>> +/* apply pre-divider first if parent is pll6 */
>
> The comment indentation is wrong
>
>> + if (req->parent_index >= SUN6I_AHB1_PARENT_PLL6)
>
> And this is not the right define you're using.
>
> I still believe that duplicating the same logic just because of
> different dividers is not the way to go.
>
> You could solve that easily by adding a table for the muxes, and
> associate it with parents and dividers, that you could store in
> clk_factors.
I've similar solution (please ignore a83 specific functions those will
be common for a31 and a83t).
https://github.com/vishnupatekar/linux/commit/f7de5b48d886a672b1f6db112fbfd5d2c9849afa
is it aligned to what you're saying?
Or do you mean we can use mux clock with div clock as composite clock?
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] A10 bring up and DRAM configuration procedure
Hi Piotr, On Sun, 3 Apr 2016 16:26:44 +0200 Piotr Król wrote: > Hi all, > I'm trying to power on custom A10 hardware based on Cubieboard1. DDR3 > modules used are MT41J64M16 [1] - at least FBGA Code D9MNQ match this > hardware. > > I'm using mainline U-Boot built using Buildroot with Cubieboard defconfig. > Unfortunately U-Boot hangs "randomly" at various locations. Farthest I can get > is: > > ## Booting kernel from Legacy Image at 4800 ... >Image Name: Linux-3.4.103 >Image Type: ARM Linux Kernel Image (uncompressed) >Data Size:4358824 Bytes = 4.2 MiB >Load Address: 40008000 >Entry Point: 40008000 >Verifying Checksum ... > > This hangs in crc32_no_comp [2]. Although this is not 100% reproducible. Full > bootlog [5]. > > I made tests using various DRAM parameters configurations and those take > booting process farthest are with CONFIG_DRAM_CLK=240: > > # below gives ~80% chance to get to Verifying Checksum > CONFIG_DRAM_CLK=240 > CONFIG_DRAM_TIMINGS_DDR3_1066F_1333H=y > > # below gives ~85% chance to get to Verifying Checksum > CONFIG_DRAM_CLK=240 > CONFIG_DRAM_TIMINGS_VENDOR_MAGIC=y > > Other configuration like CONFIG_DRAM_CLK=360 give worst results. For > 240MHz I was even able get to "Starting kernel ...", but this is > sporadic. I disabled in U-Boot as much I could, my defconfig is here > [3]. > > From what I was able to found this is result of incorrect DRAM configuration > [4]. Anyone can confirm that this is correct diagnosis ? If not then what test > I can perform to gain better confidence ? If you get somewhat better results depending on the DRAM clock frequency settings, then I would say that it pretty much points to the DRAM related problems. So you are apparently on the right track. > Other question is how to proceed from this point ? I have datasheet for DDR3, > but number of possible parameters to tweak seems to be overwhelming. Also as > sunxi wiki claim timing from datasheet have to be converted to number of > cycles > - I'm not sure how to approach that. Is there any guide where to start ? Well, the standard JEDEC timings are already tabulated in http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/dram_timings_sun4i.h Some DRAM chips may have better timings than mandated by the standard, but this is more like performance tuning. Either way, these timings are a "digital" thing, they specify how many cycles to wait between sending different commands to the DRAM chip. And they are rather unlikely to be related to your reliability problems. It is much more likely that you have "analog" problems and the signal gets distorted too badly on the way from the DRAM controller in the SoC to the DRAM chips. From what I heard, the DDR3 tracks routing is a major PITA, one needs to get both the tracks length and the tracks impedance matched within certain tolerance levels. As you are dealing with a custom hardware design, then maybe the DDR3 routing is a little bit screwed up? The DRAM controller configuration registers allow to configure the delays and drive/termination impedance to correct the PCB imperfection to some extent. In practice, all the "professionally" designed Allwinner devices work with the same generic Allwinner blessed DRAM settings, because the PCB routing is apparently usually done and tested to work fine with these default settings. Also reducing the DRAM clock speed usually improves reliability. It was believed that any A10/A13/A20 device should work stable if we clock the DRAM down to 360MHz. On the hardware side, you can maybe check the ZQ and RZQ resistors (one connected to the SoC and also one extra resistor for each DRAM chip). They should at least exist and be preferably 240 ohm. Some board manufacturers tune the nominal value of these resistors, apparently as a way to fine tune the reliability. That's the configuration knob that is easily available to board manufacturers (they don't dare to touch the DRAM settings in U-boot and probably don't know how to do this). One more thing is the VDD-DLL voltage. It is served from DCDC3 (AXP209 PMIC) and is usually set to 1.250V by default. Increasing this voltage usually improves the DRAM reliability and allows it to be clocked higher. You can try to increase this voltage to 1.300V to check if this helps. Don't go beyond 1.325V on Allwinner A10 though. > sunxi wiki describe calibration, when it is possible to run system, but what > can be done in situation when U-Boot cannot reach that state ? The whole idea of this calibration process is to find good ZQ and TPR3 settings. The settings are assumed to be good if the board is able to pass the lima-memtester reliability test at a higher DRAM clock speed without failing. We exploit the fact that lima-memster is by far more sensitive to DRAM misconfiguration than the usual software. So the borderline unreliable DRAM settings may not exhibit any visible bad effects (the system is able to boot, the usual linux software works fi
[linux-sunxi] A10 bring up and DRAM configuration procedure
Hi all, I'm trying to power on custom A10 hardware based on Cubieboard1. DDR3 modules used are MT41J64M16 [1] - at least FBGA Code D9MNQ match this hardware. I'm using mainline U-Boot built using Buildroot with Cubieboard defconfig. Unfortunately U-Boot hangs "randomly" at various locations. Farthest I can get is: ## Booting kernel from Legacy Image at 4800 ... Image Name: Linux-3.4.103 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4358824 Bytes = 4.2 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... This hangs in crc32_no_comp [2]. Although this is not 100% reproducible. Full bootlog [5]. I made tests using various DRAM parameters configurations and those take booting process farthest are with CONFIG_DRAM_CLK=240: # below gives ~80% chance to get to Verifying Checksum CONFIG_DRAM_CLK=240 CONFIG_DRAM_TIMINGS_DDR3_1066F_1333H=y # below gives ~85% chance to get to Verifying Checksum CONFIG_DRAM_CLK=240 CONFIG_DRAM_TIMINGS_VENDOR_MAGIC=y Other configuration like CONFIG_DRAM_CLK=360 give worst results. For 240MHz I was even able get to "Starting kernel ...", but this is sporadic. I disabled in U-Boot as much I could, my defconfig is here [3]. >From what I was able to found this is result of incorrect DRAM configuration [4]. Anyone can confirm that this is correct diagnosis ? If not then what test I can perform to gain better confidence ? Other question is how to proceed from this point ? I have datasheet for DDR3, but number of possible parameters to tweak seems to be overwhelming. Also as sunxi wiki claim timing from datasheet have to be converted to number of cycles - I'm not sure how to approach that. Is there any guide where to start ? sunxi wiki describe calibration, when it is possible to run system, but what can be done in situation when U-Boot cannot reach that state ? If anyone more experienced can advise what can be done at this point I would appreciate. [1] http://www.micron.com/~/media/Documents/Products/Data%20Sheet/DRAM/DDR3/1Gb_DDR3_SDRAM.pdf [2] http://git.denx.de/?p=u-boot.git;a=blob;f=lib/crc32.c;h=97592124867abb815d576899f8789545c3aef1aa;hb=HEAD#l200 [3] https://gist.github.com/pietrushnic/ea41a4ae38b7af8a6fa456113ce19af8 [4] http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation [5] https://gist.github.com/pietrushnic/d6a3d6c0b4a20a3226dfb67c4d129142 -- Best Regards, Piotr Król Embedded Systems Consultant http://3mdeb.com | @3mdeb_com -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] I have Fix colorfly e708 touchscreen and USB otg driver (sun6i-a31s-colorfly-e708-q1.dts)
I have this tablet since 3 years...
Now i want to use linux in it. I have modidy the u-boot driver in orther to
touchscreen and USB otg work.
I think that the problem was my colorfly as Goodix 911 touchscreen controller,
now touch screen and USB OTG keyboard and mouse works (requiers usb hub witch
power supply), sun6i-a31s-colorfly-e708-q1.dts:
/* jcbarrientos init goodix 911 driver /
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins_a>;
status = "okay";
ctp@5d {
pinctrl-names = "default";
pinctrl-0 = <>911_int_e708_q1>;
compatible = "goodix,gt911";
reg = <0x5d>;
interrupt-parent = <&pio>;
interrupts = <0 3 IRQ_TYPE_LEVEL_HIGH>; /* PA3 */
touchscreen-swapped-x-y;
};
};
&i2c2 {
pinctrl-names = "default";
pinctrl-0 = <&i2c2_pins_a>;
status = "okay";
accelerometer@1c {
pinctrl-names = "default";
pinctrl-0 = <&mma8452_int_e708_q1>;
compatible = "fsl,mma8452";
reg = <0x1c>;
interrupt-parent = <&pio>;
interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>; /* PA9 */
#io-channel-cells = <1>;
};
};
&lradc {
vref-supply = <®_aldo3>;
status = "okay";
button@1000 {
label = "Home";
linux,code = ;
channel = <0>;
voltage = <100>;
};
};
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_e708_q1>;
vmmc-supply = <®_dcdc1>;
bus-width = <4>;
cd-gpios = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */
cd-inverted;
status = "okay";
};
&pio {
gt911_int_e708_q1: gt911_int_pin@0 {
allwinner,pins = "PA3";
allwinner,function = "gpio_in";
allwinner,drive = ;
allwinner,pull = ;
};
/* jcbarrientos end goodix 911 driver /
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] clk: sunxi: Add CSI (camera's Sensors Interface) module clock driver for sun[457]i
On 03/19, Rob Herring wrote: > On Thu, Mar 17, 2016 at 07:43:42PM +1100, yassinjaf...@gmail.com wrote: > > From: Yassin Jaffer > > > > This patch adds a composite clock type consisting of > > a clock gate, mux, configurable dividers, and a reset control. > > > > Signed-off-by: Yassin Jaffer > > --- > > Documentation/devicetree/bindings/clock/sunxi.txt | 1 + > > I wish someone would just add all the sunxi clocks in one pass instead > of one by one. > > Acked-by: Rob Herring Me too! -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 3/4] ARM: dts: Add binding documentation for AXP20x pmic ac power supply
Add binding documentation for the ac power supply part of the AXP20x
pmic.
Signed-off-by: Michael Haas
---
.../bindings/power_supply/axp20x_ac_power.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
diff --git a/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
b/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
new file mode 100644
index 000..1cbdcfb
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
@@ -0,0 +1,34 @@
+AXP20x AC power supply
+
+Required Properties:
+-compatible: "x-powers,axp202-ac-power-supply"
+
+This node is a subnode of the axp20x PMIC.
+
+Example:
+
+axp209: pmic@34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ regulators {
+ x-powers,dcdc-freq = <1500>;
+
+ vdd_cpu: dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <145>;
+ regulator-name = "vdd-cpu";
+ };
+
+ ...
+ };
+
+ ac-power-supply: ac-power-supply {
+ compatible = "x-powers,axp202-ac-power-supply";
+ };
+};
--
2.8.0
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 2/4] ARM: dts: axp209: Add ac_power_supply child node to the ax209 node
Add a node representing the ac power supply part of the axp209 pmic.
Signed-off-by: Michael Haas
---
arch/arm/boot/dts/axp209.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
index 051ab3b..9046f0a 100644
--- a/arch/arm/boot/dts/axp209.dtsi
+++ b/arch/arm/boot/dts/axp209.dtsi
@@ -94,4 +94,10 @@
compatible = "x-powers,axp202-usb-power-supply";
status = "disabled";
};
+
+ ac_power_supply: ac_power_supply {
+ compatible = "x-powers,axp202-ac-power-supply";
+ status = "disabled";
+ };
+
};
--
2.8.0
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 1/4] power: Add an axp20x-ac-power driver
This adds a driver for the ac power_supply bits of the axp20x
PMICs.
This submission is taken directly from Bruno Prémonts 2015 RFC [0].
The original RFC contains drivers for AC, battery and backup
battery. This commit only adds the AC driver for now.
My only change to Bruno's axp20x_ac_power.c is the additional
check on a possible short-circuit between ACIN and VBUS. In this
case, axp20x-ac-power-supply refuses to attach itself to the device
and axp20x-usb-power-supply must be used.
[0] http://permalink.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/17980
Signed-off-by: Michael Haas
---
drivers/mfd/axp20x.c| 11 +++
drivers/power/Makefile | 2 +-
drivers/power/axp20x_ac_power.c | 212
3 files changed, 224 insertions(+), 1 deletion(-)
create mode 100644 drivers/power/axp20x_ac_power.c
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index a57d6e9..9351c0e 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -178,6 +178,12 @@ static struct resource axp288_power_button_resources[] = {
},
};
+static struct resource axp20x_ac_power_supply_resources[] = {
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_PLUGIN, "ACIN_PLUGIN"),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_REMOVAL, "ACIN_REMOVAL"),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_OVER_V, "ACIN_OVER_V"),
+};
+
static struct resource axp288_fuel_gauge_resources[] = {
{
.start = AXP288_IRQ_QWBTU,
@@ -440,6 +446,11 @@ static struct mfd_cell axp20x_cells[] = {
.of_compatible = "x-powers,axp202-usb-power-supply",
.num_resources = ARRAY_SIZE(axp20x_usb_power_supply_resources),
.resources = axp20x_usb_power_supply_resources,
+ }, {
+ .name = "axp20x-ac-power-supply",
+ .of_compatible = "x-powers,axp202-ac-power-supply",
+ .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
+ .resources = axp20x_ac_power_supply_resources,
},
};
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d..3a785cc 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
obj-$(CONFIG_PDA_POWER)+= pda_power.o
obj-$(CONFIG_APM_POWER)+= apm_power.o
-obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o
+obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o axp20x_ac_power.o
obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
obj-$(CONFIG_WM831X_BACKUP)+= wm831x_backup.o
obj-$(CONFIG_WM831X_POWER) += wm831x_power.o
diff --git a/drivers/power/axp20x_ac_power.c b/drivers/power/axp20x_ac_power.c
new file mode 100644
index 000..c5bcbeb
--- /dev/null
+++ b/drivers/power/axp20x_ac_power.c
@@ -0,0 +1,212 @@
+/*
+ * AXP20x PMIC AC power driver
+ *
+ * Copyright 2014-2015 Bruno Prémont
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRVNAME "axp20x-ac-power"
+/* Fields of AXP20X_PWR_INPUT_STATUS */
+#define AXP20X_PWR_STATUS_AC_PRESENT BIT(7)
+#define AXP20X_PWR_STATUS_AC_AVAILABLE BIT(6)
+#define AXP20X_PWR_STATUS_AC_VBUS_SHORT BIT(1)
+#define AXP20X_PWR_STATUS_AC_VBUS_SELBIT(0)
+
+/* Fields of AXP20X_ADC_EN1 */
+#define AXP20X_ADC_EN1_ACIN_VOLT BIT(5)
+#define AXP20X_ADC_EN1_ACIN_CURR BIT(4)
+
+struct axp20x_ac_power {
+ struct regmap *regmap;
+ struct power_supply *supply;
+};
+
+static int axp20x_ac_power_get_property(struct power_supply *psy,
+ enum power_supply_property psp, union power_supply_propval *val)
+{
+ struct axp20x_ac_power *power = power_supply_get_drvdata(psy);
+ unsigned int input;
+ int r;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ r = axp20x_read_variable_width(power->regmap,
+ AXP20X_ACIN_V_ADC_H, 12);
+ if (r < 0)
+ return r;
+
+ val->intval = r * 1700; /* 1 step = 1.7 mV */
+ return 0;
+ case POWER_SUPPLY_PROP_CURRENT_NOW:
+ r = axp20x_read_variable_width(power->regmap,
+ AXP20X_ACIN_I_ADC_H, 12);
+ if (r < 0)
+ return r;
+
+ val->intval = r * 375; /* 1 step = 0.375 mA */
+ return 0;
+ default:
+ break;
+ }
+
+ /* All the properties below need the input-status reg value */
+ r = regmap_read(power->regmap, AXP20X_PWR_INPUT_STATUS, &input);
+ i
[linux-sunxi] [PATCH 4/4] ARM: dts: sunxi: add ac-power to A20 OLinuXino Lime2 board
The A20-olinuxino-lime2 has an AC power input.
This patch enables support for current and voltage monitoring
via the axp20x-ac-power driver.
Signed-off-by: Michael Haas
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index 9303635..ed83365 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -166,6 +166,10 @@
usb_power_supply: usb_power_supply {
compatible = "x-powers,axp202-usb-power-supply";
};
+ ac_power_supply: ac_power_supply {
+ status = "okay";
+ compatible = "x-powers,axp202-ac-power-supply";
+ };
};
};
--
2.8.0
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH sunxi-tools 4/7] fel: Move the backup storage to the SRAM section A1 on H3
>This allows the SRAM section A2 to be exclusively used by >the OpenRISC core. > >There are no substantial differences between H3 and A10/A13/A20. >It just has 64 KiB of SRAM starting at the address 0x0 instead >of 48 KiB. > >Signed-off-by: Siarhei Siamashka >--- Does this mean that the MMU translation table will limit the SPL size to 32K? If so, it might be worth to add a corresponding note. Given that the H3 has 64K SRAM available, what about the area 0xC000 to 0x? Would setting mmu_tt_addr to 0xC000 be feasible, bringing the H3 even closer to A20, in terms of memory layout below that address and maximum SPL size? Regards, B. Nortmann -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
