Jump to content

[WiP] axp209 mainline sysfs interface


Recommended Posts

Thanks Zador,

 

I suppose it should be done by script executed at boot time.

If this parameters are added to sysfs who will make adjustment of axp209 chip?

Does axp209 driver in mainline kernel have or not have a battery charge control at all?

Link to comment
Share on other sites

I suppose it should be done by script executed at boot time.

You can set it once, after that changes will persist until axp209 has at least one power source available. OR you can write scripts to change it on suspend/resume/shutdown too.

 

Does axp209 driver in mainline kernel have or not have a battery charge control at all?

There were at least 2 attempts of writing such driver 1.5 - 2 years ago, but it wasn't mainlined and there is no progress since. So for charging either default values are used, or values left from booting OS with old 3.4.x kernel.

Link to comment
Share on other sites

Thanks Zador

 

You can set it once, after that changes will persist until axp209 has at least one power source available. OR you can write scripts to change it on suspend/resume/shutdown too.

 

There were at least 2 attempts of writing such driver 1.5 - 2 years ago, but it wasn't mainlined and there is no progress since. So for charging either default values are used, or values left from booting OS with old 3.4.x kernel.

 

Unfortunately, using setup left by other OS booting is not acceptable.

 

Is it means that writing values in sysfs will be written in axp209 directly?

Does the file have to be first created if it does not exists?

Or it is enough to issue:

echo 6600 > /sys/class/power_supply/battery/energy_full_design

or something like related to mainline kernel sysfs staff?

Link to comment
Share on other sites

Is it means that writing values in sysfs will be written in axp209 directly?

Yes. In theory it's possible to also use i2cget/i2cset, but you need to be extra careful to not overwrite other settings.

 

Does the file have to be first created if it does not exists?

It's not implemented yet, but if it's needed I can add this today or tomorrow.

Link to comment
Share on other sites

Thanks Zador,

 

Unfortunately, I am working with legacy kernel for now but plan to migrate to mainline one very soon so do not see what and how is available there.

My expectations are to have ability to customize all needed parameters for charging and discharging the battery like in legacy kernel via fex/bin file.

I also need of mechanism to monitor power (DC-IN, USB OTG and battery) status for displaying it.

RPI Monitor is helpful in development process only but I will use own web interface for local control.

It is also required to have clean shut down when battery is reached a given threshold (5% for example).

 

As I understand:

  • power status parameters from axp209 can be monitored via and sysfs like in legacy kernel
  • new calculated status parameters like discussed battery percentage can be added to sysfs
  • clean shut down mechanism based on battery percentage will / could be added in next versions
  • setting up of the battery parameters is not supported in device tree because of driver luck
  • it is not feasible such support to be added soon
  • could be worked around using sysfs
  • probably not all features are supported via sysfs for now
  • you can add none existing features (probably in Armbian development branch patching the kernel)
  • while new features become mainlined patching the kernel can be applied in production branch as well

Is there something wrong and/or missing in the picture above?

 

If so which features are supported in latest:

  • mainline release kernel (not patched)?
  • Armbian production release (with patches)?

 

Is there a process of mainlining of some of the work done around Armbian and what?

Link to comment
Share on other sites

My expectations are to have ability to customize all needed parameters for charging and discharging the battery like in legacy kernel via fex/bin file.

Not possible ATM, you can make configuration for a limited number of properties via sysfs interface or via i2cget/i2cset and some bit arithmetics magic.

 

I also need of mechanism to monitor power (DC-IN, USB OTG and battery) status for displaying it.

RPI Monitor is helpful in development process only but I will use own web interface for local control.

If you want to reinvent the wheel, you can read values from sysfs/i2c bus directly, use data sources provided by "armbianmonitor" (WIP) or read them from RPi-monitor database

 

It is also required to have clean shut down when battery is reached a given threshold (5% for example).

Just write a small daemon that will poll capacity value from userspace and execute shutdown command when value falls below defined threshold

 

As I understand:

  • power status parameters from axp209 can be monitored via and sysfs like in legacy kernel
  • new calculated status parameters like discussed battery percentage can be added to sysfs
  • clean shut down mechanism based on battery percentage will / could be added in next versions
  • setting up of the battery parameters is not supported in device tree because of driver luck
  • it is not feasible such support to be added soon
  • could be worked around using sysfs
  • probably not all features are supported via sysfs for now
  • you can add none existing features (probably in Armbian development branch patching the kernel)
  • while new features become mainlined patching the kernel can be applied in production branch as well
  • yes, just sysfs paths and property list are different
  • I don't see any reasons to add complicated calculations to kernel space code, for displaying battery percentage changing OCV table should be enough to get better results. However new properties (like charging current control) may appear if needed
  • it's better to implement "clean" shutdown logic in userspace, by writing a daemon that will poll battery capacity value
  • yes
  • doesn't look like it
  • yes
  • all major features are supported
  • this patch is already present in sunxi-next branch (since new kernel branch v4.6 introduces changes to axp driver, this patch will be temporarily removed from dev branch)
  • I'll try to maintain this patch to work with newer kernel branches
Link to comment
Share on other sites

Thanks Zador for your prompt answer,

 

I definitely do not like to invent the wheel. That is why I ask all these questions.

 

My feeling is that I am not alone with above requirements and there is a clever group of people working on all of them.

 

I am grateful to your responsiveness for answering my questions (stupid some times) and willingness to help.

 

Best regards

Chris

Link to comment
Share on other sites

Hi Zador,

 

Sorry, I wasn't clear, I meant that RPi-monitor should be enough for monitoring stuff, and you don't need to reinvent "own web interface for local control"

 

You are right for the general purpose devices like server or desktop boxes.

 

I am working on project with distributed application having its own web based interface using browser staff like HTML5, Canvas, Web Workers, Web Sockets etc.

It will be the only user interface (GUI) and battery and other power staff will not be more then one displayed on the top status line of tablets and mobile devices.

The system itself has to work without any user assistance and completely autonomously. Root FS will be read only and minimal package staff will be installed.

 

RPI Monitor is a perfect for development and testing purposes but it is not appropriate for production.

Armbian Monitor is the right solution for getting needed status information which will be displayed by the only user GUI.

Battery control, clean shut down etc. system functions will be supported by corresponding daemons and have to work autonomously.

Link to comment
Share on other sites

Hey,

 

I would like to know if there is any fresh news about the battery management on vanilla Kernel ?

 

I would like also to use the last kernel but I could not so far...

 

Does the patch for 4.6 solve the issue ?

 

Thanks

Link to comment
Share on other sites

I would like to know if there is any fresh news about the battery management on vanilla Kernel ?

Not yet, only AC input driver will be added soon AFAIK.

 

Does the patch for 4.6 solve the issue ?

Depends on your issue. Using battery for providing power to the board is more or less useable even with default settings.

Link to comment
Share on other sites

Thanks Zador for replaying,

 

I have basic need for the battery, I need to set the max capacity and the charging current.

 

Currently in sun7i-a20-olinuxino-lime2.dtb theire is nothing about the battery setting, except this

 

        axp_ipsout {
                compatible = "regulator-fixed";
                regulator-name = "axp-ipsout";
                regulator-min-microvolt = <0x4c4b40>;
                regulator-max-microvolt = <0x4c4b40>;
                regulator-always-on;
                linux,phandle = <0x36>;
                phandle = <0x36>;
        };
 

How can I do this ?

Link to comment
Share on other sites

        axp_ipsout {

                compatible = "regulator-fixed";

                regulator-name = "axp-ipsout";

                regulator-min-microvolt = <0x4c4b40>;

                regulator-max-microvolt = <0x4c4b40>;

                regulator-always-on;

                linux,phandle = <0x36>;

                phandle = <0x36>;

        };

This is not for battery, this is describing "IPS" output of PMU and it doesn't have any configurable settings.

 

Setting battery parameters in DT is not supported - as I said, there is no driver for battery charger part yet.

 

Setting capacity is required only for estimating remaining time when charging/discharging, so you don't need to worry about it.

 

Default charging current is 1200mA, so if it is acceptable for your battery, you don't have to worry about it either.

Link to comment
Share on other sites

 

Setting battery parameters in DT is not supported - as I said, there is no driver for battery charger part yet.

Ok, DT is not really clear for me yet, do you have any links where I can fellow the developpement ?

 

 

Setting capacity is required only for estimating remaining time when charging/discharging, so you don't need to worry about it.

That would have been quite nice to estimate the battery percentage as I need to show how full/empty is the battery...

From your point of view, there is no way to damage the battery if those settings are not set ?

My battery is 3.7v 7800mAh...http://fr.farnell.com/ansmann/2447-3034/batt-li-ion-rechargeable-3-7v/dp/2484233?ost=2484233

Link to comment
Share on other sites

Ok, DT is not really clear for me yet, do you have any links where I can fellow the developpement ?

Here you can find patches sent for review before they are included into kernel. Here is the overall progress for mainlining sunxi-related drivers.

 

That would have been quite nice to estimate the battery percentage as I need to show how full/empty is the battery...

Reading status (%) is possible in current Armbian kernel (manually, from command line, or in RPi-Monitor web UI).

By "estimated time" I meant things like "battery will be fully charged in 10 minutes" or "remaining time before full discharge is 40 minutes" - this is calculated based on battery capacity (in mAh).

 

From your point of view, there is no way to damage the battery if those settings are not set ?

My battery is 3.7v 7800mAh...http://fr.farnell.com/ansmann/2447-3034/batt-li-ion-rechargeable-3-7v/dp/2484233?ost=2484233

Datasheet characteristics (charging current, target charging voltage and maximum discharge current) look OK for default settings, and it says that battery pack has internal protection board, so it should be safe.

Just make sure you are using default PMU values (disconnect all power sources from the board and wait ~10 minutes before connecting power to board again).

Link to comment
Share on other sites

Thanks Zador for the links, I will keep an eye the mailing list

 

 

Reading status (%) is possible in current Armbian kernel (manually, from command line, or in RPi-Monitor web UI).

By "estimated time" I meant things like "battery will be fully charged in 10 minutes" or "remaining time before full discharge is 40 minutes" - this is calculated based on battery capacity (in mAh).

I can read status (% remaining), but it seems to be wrong...How does the AXP knows about the mAh available in the battery ?

Link to comment
Share on other sites

I can read status (% remaining), but it seems to be wrong...How does the AXP knows about the mAh available in the battery ?

It doesn't know about mAh, it can only read voltage and current, and provide estimated status (%) based on voltage (3.0V = empty, 4.2V = full).

Other parameters should be calculated by driver based on readings from PMU.

Link to comment
Share on other sites

Yeah, with the new version the value changes and looks interesting. Current idea: Use /etc/armbianmonitor/datasources/battery_charge symlinked to /sys/power/axp_pmu/battery/charge and /etc/armbianmonitor/datasources/battery_peak that contains the battery/charge peak value from the last charge cycle. Therefore battery_peak will be maintained by a daemon and remains always at the highest value when discharging starts. And then I try to use a simple forumula to calculate percentage:

 

 

I have manually create all the datasources and the templates (I've tried to use armbianmonitor-daemon without success with also the commands . /etc/init.d/armhwinfo query and env) but I don't find any information about how to create and maintain battery_peak.

I've just made a link to /etc/armbianmonitor/datasources/battery_charge so I don't see the undefined value to battery.

 

There is a tutorial with all the stuff in one place?

Link to comment
Share on other sites

I checked the datasheet and not register 0x34 but 0x33 is responsible for charging current. However it has been already set to maximum value 1200mAh. To get status of register I run command i2cget -y -f 0 0x34 0x33. Because the value 1001 for bit 0-3 has been reported back, there was nothing to adjust to get higher charging current.

binary 1001 => decimal 9, 9*100mAh + 300mAh=1200mAh

I found useful script, see link below, reporting charging values and status of both registers 0x33 and 0x34 (default values: 0xCX and 0x45).

 

https://gist.github.com/tstellanova/b726545cc9bd2a01bb553f34509a5c96

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines