> > The CC,CV and restart threshold would vary based on the battery temperature
> > So I would suggest to have temperature zone table as part of battery info
> > along with other attributes.
> >
> > int iterm; //charge termination current (used to stop charging)
> > int temp_zone_count; // number of temperature zone tables present
> > struct batt_temp_mon_table temp_mon_tbl[MAX_TEMP_MON_TABLE];
> //temperature zone table array
> >
> > struct batt_temp_mon_table {
> > short int temp_max;
> > short int cc;
> > short int cv;
> > short int vbat_vchk_drop_uv;
> > short int temp_min;
> > };
> >
>
>
> IMO, throttling cc/cv according the temperature can be done via thermal fw
> interface. However voltage drop and charging termination current can be added
> here.
The CC/CV for each battery temperature zone is defined as part of battery spec.
This is
as per the JEITA/PSE standards. So IMO, this is a battery charging information
(charging object) rather than a thermal throttling information.
Also the battery information may not fit into a standard format. Different
standards have
different format for charging object. So I would suggest to make it flexible
enough to
support different charging object format. For example MIPI BIF charging object
format
(https://members.mipi.org/wg/BIF/document/11518) and MIPI BIF Rule based
charging algorithm
(http://mipi.org/sites/default/files/mipi_BIF_rule-based-charging_white-paper_1.pdf)
has different charging object format. This is why the patch
https://lkml.org/lkml/2014/8/13/355
has option to support different charging objects and different charging
algorithms.
-Jenny
N�����r��y����b�X��ǧv�^�){.n�+����{����zX����ܨ}���Ơz�&j:+v�������zZ+��+zf���h���~����i���z� �w���?�����&�)ߢf��^jǫy�m��@A�a���
0��h���i
