Patch: Enable USB power supply driver + I2C on UEXT on -lime2 mainline

[mhaas]

Hi all,

the current DTS that comes with the mainline kernel for the -lime2 (and probably others) does not enable all hardware functionality that I need

Part 1: the USB power driver for the AXP20x PMIC. This will give you some stats like the current power consumption and voltage of the USB part of the power supply. I have submitted a patch to the linux-sunxi ML; it's pending.

Part 2: I2C on the UEXT. Out of the box, the A20-OLinuXino-LIME2-UEXT does not just work [tm] when connecting it to GPIO1. The reason is that the third I2C bus is disabled by default as the pins may have different uses. My patch submission to the linux-sunxi ML was rejected for this reason, probably rightfully so. See the discussion here

The patch I am attaching fixes both issues via the DTS. It's possible it does not apply cleanly as I already have the necessary DTS entries for the AC power supply driver (submission pending).

Code Select Expand


dtc -I dtb -O dts /boot/dtb-4.6.0-rc4+  > /tmp/sun7i-a20-olinuxino-lime2.dts
patch < ~/usb-power_i2c2c.patch /tmp/sun7i-a20-olinuxino-lime2.dts
dtc -I dts -O dtb /tmp/sun7i-a20-olinuxino-lime2.dts  > /tmp/sun7i-a20-olinuxino-lime2.dtb
sudo mv /tmp/sun7i-a20-olinuxino-lime2.dtb /boot/dtb-4.6.0-rc4+


Code Select Expand


laga@ivanov:~$ cat  ~/usb-power_i2c2c.patch
--- sun7i-a20-olinuxino-lime2.dts 2016-05-01 11:12:29.155145355 +0200
+++ sun7i-a20-olinuxino-lime2.dts 2016-05-01 11:17:28.870074642 +0200
@@ -1431,7 +1431,10 @@
regulator-always-on;
};
};
-
+ usb_power_supply {
+ status = "okay";
+ compatible = "x-powers,axp202-usb-power-supply";
+ };
ac_power_supply {
status = "okay";
compatible = "x-powers,axp202-ac-power-supply";
@@ -1462,7 +1465,7 @@
reg = <0x1c2b400 0x400>;
interrupts = <0x0 0x9 0x4>;
clocks = <0x33 0x2>;
- status = "disabled";
+ status = "okay";
#address-cells = <0x1>;
#size-cells = <0x0>;
};


I have a MOD-OLED-128x64 and I need the following change in pyMOD-OLED to get the code to use the third I2C bus:

Code Select Expand

diff --git a/example/Hello_World.py b/example/Hello_World.py
index c00d671..9f743dd 100644
--- a/example/Hello_World.py
+++ b/example/Hello_World.py
@@ -2,8 +2,8 @@ from oled import OLED
from oled import Font
from oled import Graphics

-# Connect to the display on /dev/i2c-0
-dis = OLED(0)
+# Connect to the display on /dev/i2c-2
+dis = OLED(2, address=0x3c)

# Start communication
dis.begin()


Enjoy!

[ealex]

hello

how can i get the updated code ?
i was also working on something like this, and as you, after i had a stand-alone driver i saw the code already done by Bruno Prémont.

what i've implemented:
AC / BAT / VBUS - all features i could map over power supply class
all other registers configurable from device tree
did not touch the regulator related registers.
the code i wrote is here:
https://drive.google.com/folderview?id=0B0CB5A9yU03XbThmVlA2RlVpQzg&usp=drive_web
it's still needs a lot of clean-up. I can upload a newer version on monday. I could not understand how to implement the fuel gauge - the "sunxi" code is reading some registers that are not documented. my idea was to make a rough one based on battery voltage

With the driver present in mainline:
i could not activate the axp202-usb-power-supply driver from 4.6-rc5 - added it to DTB as described here
http://free-electrons.com/kerneldoc/latest/devicetree/bindings/power_supply/axp20x_usb_power.txt

first time looking into the kernel and it's scary
I still can't understand the mfd / platform device driver - who loads what and why, the stand alone driver was easy enough

[mhaas]

Hey there,

Just a quick reply as I am on my phone. I will get back to you tomorrow.

For the usb power supply driver, the patch I posted above should just work on mainline.

As for my updated code, I just submitted v4 of the AC power supply driver this morning and started cleaning up the fuel gauge. This is all Bruno's code, not mine good on you for coming up with your own driver. I started my own implementation of the Ac driver based on the Usb power supply driver. I shelved it once I saw Bruno's work.

Regarding the fuel gauge registers: there is a very short note about the proper registers in the datasheet I have. I guess I should check if Bruno's driver uses additional registers.

Are you on the linux-sunxi mailing.list? There are some points in Bruno's fuel gauge implementation I would like to discuss with someone.

Michael

[ealex]

i am not on the sunxi mailing list, i will register over there.
are you pointing to axp288_fuel_gauge.c ?

[mhaas]

i am not on the sunxi mailing list, i will register over there.

Cool!

are you pointing to axp288_fuel_gauge.c ?

No. Let me break down the various components and their support in the linux-sunxi tree in the sunxi-next branch:

• axp20x-usb-power-supply: has been in Linus' mainline kernel for a while. You can enable it for your board using the DTS changing I described in my first posting. It was submitted by Hans de Goede, uisng some of Bruno Prémonts code.
• axp20x-ac-power: Brunos code, has been floating around the web for a while. I have performed some minor cleanups and submitted it to the linux-sunxi mailing list (and all relevant maintainers) for inclusion (see this thread). It is currently pending review and will hopefully be included in the linux-sunxi tree soon or go to Linus' tree via some other tree. I am unsure about the details.
• axp20x-fuel-gauge: Brunos code. I am currently cleaning this up and will hopefully submit it to the linux-sunxi mailing list soon. You can find the current version in my github in the axp209-charger branch: axp20x_fuel_gauge.c. Note the TODOs on top. I just started yesterday. The branch also contains the axp20x-ac-power driver.
• axp20x-rtc-power: charger for the RTC backup battery. Bruno's code. I don't have the means to test this, but I will submit it eventually.
  

first time looking into the kernel and it's scary

It's extremely impressive you made your own driver then

I still can't understand the mfd / platform device driver - who loads what and why, the stand alone driver was easy enough

Yeah, I am not sure about that either As far as I can tell, the driver gets activated by the presence of its device nodes. Regarding your standalone driver: yeah, that is easier, of course. But the AXP20x provides power regulators, input keys, power supplies etc which all go to different kernel subsystem. It is (apparently) problematic to have multiple drivers talking to the same device, hence the MFD entry point.

I have added some TODO items to the axp20x_fuel_gauge.c I linked above. If you have some time, you could look into these. Alternatively, it would probably be good if someone could just test the exact patch I submitted to the linux-sunxi ML for the AC power supply and reported a Tested-By (or perhaps a Reviewed-By, since you know the device). Don't forget the DTS changes

Does your device have an RTC battery?

edit: Just looked at your driver for a couple of minutes (I have to leave soon for today). There is some cool stuff in there. It seems like you are configuring the CHGLED from the DTS. That's something missing from Bruno's driver. Is your driver based on the original allwinner code dump?

[ealex]

i'm beginning to understand.

my code is written from scratch - just with AXP's datasheet in front + ds27... as a starting point

i have a board with a 1F/5V cap connected to the RTC battery so i can tests it.
i'll look at the fuel gauge code on monday, no time sooner and the board is at work.

i think at least charging related parameters should be configured from DTS so they are properly configured as soon as possible : my power supply almost caught fire as the default charging current is 1.8A and the psu does not have over-current protection ( simple iron-core transformer - using it for galvanic isolation )

i've also prepared a 3000mA battery, so i can run full charge / discharge tests in a decent amount of time.

[JohnS]

I'm puzzled why anyone would design a dangerous default charging current.  Please explain.

John

[ealex]

hello

the chip's default charging current is not dangerous by itself - 1800mA is quite decent for it's original purpose - tablet / mobile phone, etc.

it was dangerous in my setup - a high charging current and an unprotected power supply that just got hot instead of shutting down or blowing a fuse.

the purpose of having those parameters loaded as soon as possible is to enable some special operating modes that will not be normally used:
- setting the upper charge voltage to a lower value than normal
- setting a low charge current - protect a weak power supply or protect a weak battery
- set the discharge limit for the battery
- configure the battery thermal limits - trying to charge a very cold LiPo will kill it, etc

AXP209 is quite nice if properly configured - it's able to detect faults and properly shutdown.

[JohnS]

The usual way seems to be to design that in the worst situation (CPU lock up, CPU death, short circuit, bad software, or whatever) it would still not be even slightly dangerous.

John