About Android Battery Management system (i) Linux drivers section

I. OverviewThe driver for the battery portion of the Android system inherits the power supply driver architecture from the traditional Linux system, and the battery driver generates the appropriate SYS file system via the power supply driver. This provides the interface to the user space for various properties of the battery. LinuxThe standard Power supply driver uses a file system path of:/sys/class/power_supply, where each subdirectory represents an energy supply device.

second, the drive head file

Power Supply Driver header file Kernel/include/linux/power_supply.h, the functions for registering and unregistering drivers are as follows:

Intpower_supply_register (struct device *parent,struct power_supply *psy);

Voidpower_supply_unregister (struct power_supply *psy);

structpower_supply {

Constchar *name; /* Device Name */

Enumpower_supply_type type; /* Type */

Enumpower_supply_property *properties; /* Property pointer */

Size_tnum_properties; /* Number of attributes */

char**supplied_to;

size_tnum_supplicants;

Int (*get_property) (struct power_supply *psy,/* Get Properties */

Enumpower_supply_property PSP,

Unionpower_supply_propval *val);

void (*external_power_changed) (struct power_supply *psy);

/* ...... Omit part of content */

};

third, power supply core

Corresponding driver: power_supply

Let's take a look at this power_supply_sysfs.c file. This is primarily to create uevent! for power device properties such as the following

These uevent nodes are not necessarily created, and node creation is also related to the num_properties and properties of specific power device drivers, which can be easily seen in creating uevent function Power_supply_uevent:

Iv. Battery Driver

The current project (T808, T828) used in the battery detection and management method is the POC ADC mode, the corresponding driver file is:

Mediatek/kernel/drivers/power/battery_common.c

The probe function in this file has the following contents:

As you can see, the AC, USB, and battery three power supply devices are registered in the power supply core, and the corresponding global structure variables ac_main, Usb_main, and battery_main are defined as follows:

The uevent nodes that each power supply needs to create are determined by the incoming xx_props, which is defined as follows:

Discover: AC and USB create only one online property, the upper app can know what device is charging the current system by judging the online status of AC and USB, while battery creates such as: status, health, present, Capacity, Batt_vol, and many other battery-related properties, the top-level app can monitor the battery's current working state with these battery properties uevent.

Take a look at the status update for AC online, as an example of how the status of these properties is changed to send an update message to the system.

This function is called when the show property is in power supply SYSFS, and Ac_online's unique properties as AC power are updated in Ac_update:

Ac_update will eventually be round-robin in the Bat_thread_kthread, where there is a global bmt_status, as the entire power supply device of various properties conveyed! Also look at Charging_control battery_charging_control This global function pointer, the prototype is defined as follows:

The Chr_control_interface function is prototyped as follows:

corresponding file path:

Mediatek/platform/mt6572/kernel/drivers/power/charging_hw_pmic.c

The CHARGING_FUNC function pointer array is defined as follows:

It can be seen through the following call relationships:

Will eventually be called to by:

These enumeration types are one by one corresponding functions, such as the above call relationship Charging_cmd_get_charger_type, is to get CHARGER type, the function prototype is as follows:

This is where the hardware status of the pmic gets the appropriate information.

v. Correction of charge error

The ideal battery is free of internal resistance, and the battery voltage consumption is on the external load.

But this is not the case, due to the existence of the battery internal resistance, through the direct measurement of the battery voltage (ADC) of the battery will have a certain error, regardless of whether the battery is in the state of power or discharge, this error will exist, especially when the battery is full, This error is easily perceived by the user when the battery is empty and the power off is charged, resulting in a bad user experience.

The error caused by the internal resistance of the battery can be corrected mathematically.

By knowing the internal resistance of the battery, it is easy to correct this error. But the internal resistance of the battery is not constant, but with the change in battery power changes, different models of the battery, this feature is not the same, then to get more accurate battery power, it is necessary to let the battery factory to provide a complete set of battery voltage and battery resistance of the relationship table!

Correction code of the error in charge and discharge process:

Mediatek/kernel/drivers/power/battery_meter.c

The following code is in the Oam_run:

The function mtk_imp_tracking is a v correction for the voltage drop caused by the internal resistance of the battery during charging and discharging.

Another is, due to the battery characteristics, the switch on the time of the problem of power jump, in the system using the power off the UI to save to the RTC, in the next boot process with the actual detected battery value and saved to the RTC in the UI battery value to compare, because the user may replace the battery, The difference between the two is controlled in the range of 20%, that is to say: The actual detected battery value in the RTC saved in the UI power value of 20% in the context of the UI saved in the RTC value as the current battery power value, if the actual detected power value exceeds the RTC in the UI power value of 20%, The user is considered to have replaced the battery, using the actual detected battery value as the current battery power value.

The corresponding judgment code is as follows:

In the header file:

Mediate/custiom/mt6572/kernel/battery/battery/cust_battery_meter.h

is defined in the following

The properties of each energy device are summarized as follows:

/sys/class/power_supply/ac/online AC power Connection Status

/sys/class/power_supply/usb/online USB Power Connection Status

/sys/class/power_supply/battery/status Charging Status

/sys/class/power_supply/battery/health Battery Status

/sys/class/power_supply/battery/present usage Status

/sys/class/power_supply/battery/capacity Battery level

/sys/class/power_supply/battery/batt_vol Battery Voltage

/sys/class/power_supply/battery/batt_temp Battery Temperature

/sys/class/power_supply/battery/technology Battery Technology

Driver updates these files when the state of the power supply is changed

About Android Battery Management system (i) Linux drivers section