Battery vendors like UER suggest to program Low Charge Voltage in case
of high or low temperatures. So a battery can have different charge profile
with in the battery operating temperature limits.
Next, there could be events like drop or rise in VBUS voltage in that case
we might have to adjust the charge current to stabilize VBUS voltage.
This patch allows the Charger-Manager to adjust the charging parameters
upon events like VBUS rise or drop and allows batteries to have multiple
charge profiles for different temperature zones.
Signed-off-by: Ramakrishna Pallala <[email protected]>
---
Documentation/power/charger-manager.txt | 10 ++++++++++
drivers/power/charger-manager.c | 6 +++++-
include/linux/power/charger-manager.h | 5 +++++
3 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/Documentation/power/charger-manager.txt b/Documentation/power/charger-manager.txt
index b4f7f4b..6fa2a10 100644
--- a/Documentation/power/charger-manager.txt
+++ b/Documentation/power/charger-manager.txt
@@ -50,6 +50,15 @@ Charger Manager supports the following:
restarts charging. This check is also performed while suspended by
setting wakeup time accordingly and using suspend_again.
+* Support for adjusting charging parameters
+ Batteries can have different charge profiles with in the battery
+ operating temperature limits. And events like drop or rise in VBUS
+ voltage require adjustment of charge current to stabilize VBUS voltage.
+
+ Charger Manager provides a function pointer "charging_zone_changed" which
+ can be implemented by platform/core drivers and Charger Manager checks
+ this function to update the charger.
+
* Support for uevent-notify
With the charger-related events, the device sends
notification to users with UEVENT.
@@ -169,6 +178,7 @@ char *psy_fuel_gauge;
: Power-supply-class name of the fuel gauge.
int (*temperature_out_of_range)(int *mC);
+bool (*charging_zone_changed)(int mC);
bool measure_battery_temp;
: This callback returns 0 if the temperature is safe for charging,
a positive number if it is too hot to charge, and a negative number
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 86935ec..9f46353 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -424,13 +424,17 @@ static void fullbatt_vchk(struct work_struct *work)
static bool _cm_monitor(struct charger_manager *cm)
{
struct charger_desc *desc = cm->desc;
+ bool update_charger = false;
int temp = desc->temperature_out_of_range(&cm->last_temp_mC);
dev_dbg(cm->dev, "monitoring (%2.2d.%3.3dC)\n",
cm->last_temp_mC / 1000, cm->last_temp_mC % 1000);
+ if (desc->charging_zone_changed)
+ update_charger = desc->charging_zone_changed(cm->last_temp_mC);
+
/* It has been stopped or charging already */
- if (!!temp == !!cm->emergency_stop)
+ if ((!!temp == !!cm->emergency_stop) && !update_charger)
return false;
if (temp) {
diff --git a/include/linux/power/charger-manager.h b/include/linux/power/charger-manager.h
index 241065c..302107d 100644
--- a/include/linux/power/charger-manager.h
+++ b/include/linux/power/charger-manager.h
@@ -90,6 +90,10 @@ struct charger_global_desc {
* return_value > 0: overheat
* return_value == 0: normal
* return_value < 0: cold
+ * @charging_zone_changed:
+ * Determine whether charge profile need an update
+ * return_value true if charge profile update required
+ * return_value false if charge profile update is not required
* @measure_battery_temp:
* true: measure battery temperature
* false: measure ambient temperature
@@ -114,6 +118,7 @@ struct charger_desc {
char *psy_fuel_gauge;
int (*temperature_out_of_range)(int *mC);
+ bool (*charging_zone_changed)(int mC);
bool measure_battery_temp;
};
--
1.7.0.4
> Battery vendors like UER suggest to program Low Charge Voltage in case
> of high or low temperatures. So a battery can have different charge profile
> with in the battery operating temperature limits.
>
> Next, there could be events like drop or rise in VBUS voltage in that case
> we might have to adjust the charge current to stabilize VBUS voltage.
>
> This patch allows the Charger-Manager to adjust the charging parameters
> upon events like VBUS rise or drop and allows batteries to have multiple
> charge profiles for different temperature zones.
>
> Signed-off-by: Ramakrishna Pallala <[email protected]>
I don't see how the parameters are changed when update_charger is true.
Are you intending to do it at userspace after getting uevent_notify()? (I don't think it's good)
If the intension is to update some of the charger-manager internal parameters (struct charger_manager's struct charger_desc) according to the temperature, we'd need a more general method that can also update values in the charger-manager context.
For example, instead of simply putting a callback to determine whether an update is required or not, a table of (including hysterisis) temperatures and values to be updated (or callbacks to update charger_desc based on the temperature) might be a starting point. You may also need to consider using notifier chain w/ temperatures.
Cheers!
MyungJoo.
> ---
> Documentation/power/charger-manager.txt | 10 ++++++++++
> drivers/power/charger-manager.c | 6 +++++-
> include/linux/power/charger-manager.h | 5 +++++
> 3 files changed, 20 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/power/charger-manager.txt b/Documentation/power/charger-manager.txt
> index b4f7f4b..6fa2a10 100644
> --- a/Documentation/power/charger-manager.txt
> +++ b/Documentation/power/charger-manager.txt
> @@ -50,6 +50,15 @@ Charger Manager supports the following:
> restarts charging. This check is also performed while suspended by
> setting wakeup time accordingly and using suspend_again.
>
> +* Support for adjusting charging parameters
> + Batteries can have different charge profiles with in the battery
> + operating temperature limits. And events like drop or rise in VBUS
> + voltage require adjustment of charge current to stabilize VBUS voltage.
> +
> + Charger Manager provides a function pointer "charging_zone_changed" which
> + can be implemented by platform/core drivers and Charger Manager checks
> + this function to update the charger.
> +
> * Support for uevent-notify
> With the charger-related events, the device sends
> notification to users with UEVENT.
> @@ -169,6 +178,7 @@ char *psy_fuel_gauge;
> : Power-supply-class name of the fuel gauge.
>
> int (*temperature_out_of_range)(int *mC);
> +bool (*charging_zone_changed)(int mC);
> bool measure_battery_temp;
> : This callback returns 0 if the temperature is safe for charging,
> a positive number if it is too hot to charge, and a negative number
> diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
> index 86935ec..9f46353 100644
> --- a/drivers/power/charger-manager.c
> +++ b/drivers/power/charger-manager.c
> @@ -424,13 +424,17 @@ static void fullbatt_vchk(struct work_struct *work)
> static bool _cm_monitor(struct charger_manager *cm)
> {
> struct charger_desc *desc = cm->desc;
> + bool update_charger = false;
> int temp = desc->temperature_out_of_range(&cm->last_temp_mC);
>
> dev_dbg(cm->dev, "monitoring (%2.2d.%3.3dC)\n",
> cm->last_temp_mC / 1000, cm->last_temp_mC % 1000);
>
> + if (desc->charging_zone_changed)
> + update_charger = desc->charging_zone_changed(cm->last_temp_mC);
> +
> /* It has been stopped or charging already */
> - if (!!temp == !!cm->emergency_stop)
> + if ((!!temp == !!cm->emergency_stop) && !update_charger)
> return false;
>
> if (temp) {
> diff --git a/include/linux/power/charger-manager.h b/include/linux/power/charger-manager.h
> index 241065c..302107d 100644
> --- a/include/linux/power/charger-manager.h
> +++ b/include/linux/power/charger-manager.h
> @@ -90,6 +90,10 @@ struct charger_global_desc {
> * return_value > 0: overheat
> * return_value == 0: normal
> * return_value < 0: cold
> + * @charging_zone_changed:
> + * Determine whether charge profile need an update
> + * return_value true if charge profile update required
> + * return_value false if charge profile update is not required
> * @measure_battery_temp:
> * true: measure battery temperature
> * false: measure ambient temperature
> @@ -114,6 +118,7 @@ struct charger_desc {
> char *psy_fuel_gauge;
>
> int (*temperature_out_of_range)(int *mC);
> + bool (*charging_zone_changed)(int mC);
> bool measure_battery_temp;
> };
>
> --
> 1.7.0.4
>
>
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
> > This patch allows the Charger-Manager to adjust the charging
> > parameters upon events like VBUS rise or drop and allows batteries to
> > have multiple charge profiles for different temperature zones.
> >
> > Signed-off-by: Ramakrishna Pallala <[email protected]>
>
> I don't see how the parameters are changed when update_charger is true.
My initial thought was to keep these details hide from CM.
> Are you intending to do it at userspace after getting uevent_notify()? (I don't think
> it's good)
No, we will do it from driver only.
> If the intension is to update some of the charger-manager internal parameters (struct
> charger_manager's struct charger_desc) according to the temperature, we'd need a more
> general method that can also update values in the charger-manager context.
>
> For example, instead of simply putting a callback to determine whether an update is
> required or not, a table of (including hysterisis) temperatures and values to be updated
> (or callbacks to update charger_desc based on the temperature) might be a starting
> point. You may also need to consider using notifier chain w/ temperatures.
>
Yes I agree, I will submit another patch with these changes.
As part of charge enablement we generally program charge current, charge voltage
into the charger chip.
We can pass the charging parameters CC and CV in two ways.
1. Add these params in charger_desc struct and the charger regulator can get these
params using container_of() call? but becomes complex.
2. use regulator_set_voltage()/regulator_set_current_limit() functions to set the CV and CC params.
but not suitable as is, we have add support in regulator framework
3. use regulator_get_drvdata()/regulator_set_drvdata() to set CC & CV params. These functions
allow us to add more params in future if required.
I am thinking of using option 3.
Let me know your feedback.
Thanks,
Ram
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
> > > This patch allows the Charger-Manager to adjust the charging
> > > parameters upon events like VBUS rise or drop and allows batteries
> > > to have multiple charge profiles for different temperature zones.
> > >
> > > Signed-off-by: Ramakrishna Pallala <[email protected]>
> >
> > I don't see how the parameters are changed when update_charger is true.
> My initial thought was to keep these details hide from CM.
>
> > Are you intending to do it at userspace after getting uevent_notify()?
> > (I don't think it's good)
> No, we will do it from driver only.
>
> > If the intension is to update some of the charger-manager internal
> > parameters (struct charger_manager's struct charger_desc) according to
> > the temperature, we'd need a more general method that can also update
> values in the charger-manager context.
> >
> > For example, instead of simply putting a callback to determine whether
> > an update is required or not, a table of (including hysterisis)
> > temperatures and values to be updated (or callbacks to update
> > charger_desc based on the temperature) might be a starting point. You
> may also need to consider using notifier chain w/ temperatures.
> >
> Yes I agree, I will submit another patch with these changes.
>
> As part of charge enablement we generally program charge current, charge
> voltage into the charger chip.
>
> We can pass the charging parameters CC and CV in two ways.
> 1. Add these params in charger_desc struct and the charger regulator can get
> these params using container_of() call? but becomes complex.
>
> 2. use regulator_set_voltage()/regulator_set_current_limit() functions to set
> the CV and CC params.
> but not suitable as is, we have add support in regulator framework
>
regulator_ops has support for set_current_limit and set_voltage. Can we use the same for setting CC and CV?
> 3. use regulator_get_drvdata()/regulator_set_drvdata() to set CC & CV
> params. These functions allow us to add more params in future if required.
>
> I am thinking of using option 3.
>
> Let me know your feedback.
>
> Thanks,
> Ram
>
> N떑꿩?툤y鉉싕b쾊Ф푤v??頻{.n?돴쪐{콗喩zX㎍썳變
> }찠꼿쟺?j:+v돣?쳭喩zZ+?zf＂톒쉱?넮녬i鎬z?췿ⅱ?솳鈺??刪
> f뷌^j푹y쬶끷@A첺뛴
>
> 0띠h??i
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
> >
> > As part of charge enablement we generally program charge current,
> > charge voltage into the charger chip.
> >
> > We can pass the charging parameters CC and CV in two ways.
> > 1. Add these params in charger_desc struct and the charger regulator
> > can get these params using container_of() call? but becomes complex.
> >
> > 2. use regulator_set_voltage()/regulator_set_current_limit() functions
> > to set the CV and CC params.
> > but not suitable as is, we have add support in regulator framework
> >
>
> regulator_ops has support for set_current_limit and set_voltage. Can we use the same for
> setting CC and CV?
I feel set_voltage()/set_current_limit() is more suitable to control input source current and
voltage, but CC and CV are more like output parameters from charger.
Thanks,
Ram
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
> > > This patch allows the Charger-Manager to adjust the charging
> > > parameters upon events like VBUS rise or drop and allows batteries to
> > > have multiple charge profiles for different temperature zones.
> > >
> > > Signed-off-by: Ramakrishna Pallala <[email protected]>
> >
> > I don't see how the parameters are changed when update_charger is true.
> My initial thought was to keep these details hide from CM.
We are integrating charger max current configuration with charger status:
e.g., whether "TA" is connected, "USB" is connected, or "Solar" is connected
should determine the current configuration. In our testbed system, if "TA" is
connected, it becomes (regulator_set_current_limit) < 1A and it becomes 500mA
if "USB 2.0" is connected.
Such information is given to the charger manager instance via charger_desc along
with current limit. We will release the patchset after applying and testing in
our testbed.
Thus, the details may/should be in CM; we will be controlling them in CM anyway.
The data structure will look like this (this is an abstract and psuedo):
struct charger_cable {
const char *extcon_dev_name;
const char *extcon_cable_name;
unsigned long current_uA;
};
struct charger {
const char *regulator_name;
ARRAY of struct charger_cable;
};
struct charger_desc {
...
ARRAY of struct charger;
};
I'm not sure whether the final value will be max(enabled_cable_uA) or
sum(enabled_cable_uA). And we might need another "current_limit_uA"
in struct charger.
>
> > Are you intending to do it at userspace after getting uevent_notify()? (I don't think
> > it's good)
> No, we will do it from driver only.
Fine.
>
> > If the intension is to update some of the charger-manager internal parameters (struct
> > charger_manager's struct charger_desc) according to the temperature, we'd need a more
> > general method that can also update values in the charger-manager context.
> >
> > For example, instead of simply putting a callback to determine whether an update is
> > required or not, a table of (including hysterisis) temperatures and values to be updated
> > (or callbacks to update charger_desc based on the temperature) might be a starting
> > point. You may also need to consider using notifier chain w/ temperatures.
> >
> Yes I agree, I will submit another patch with these changes.
>
> As part of charge enablement we generally program charge current, charge voltage
> into the charger chip.
>
> We can pass the charging parameters CC and CV in two ways.
> 1. Add these params in charger_desc struct and the charger regulator can get these
> params using container_of() call? but becomes complex.
>
> 2. use regulator_set_voltage()/regulator_set_current_limit() functions to set the CV and CC params.
> but not suitable as is, we have add support in regulator framework
>
> 3. use regulator_get_drvdata()/regulator_set_drvdata() to set CC & CV params. These functions
> allow us to add more params in future if required.
>
> I am thinking of using option 3.
>
> Let me know your feedback.
I'd suggest you to do option 2 with the following interface.
Anyway, (reading another mails from this thread) it appears that it may look
like this, assuming that the charger_current control regarding the charger-type
based on Extcon cannot be applied to this:
struct charger_temp_notify {
bool high; /* true: notifies if it goes higher from lower */
int notify_mC;
int recovery_mC;
struct notifier_block nb;
struct charger_desc *desc; /* CM will automatically set this */
};
struct charger_desc {
...
ARRAY of struct charger_temp_notify;
};
If you want to alarm at 80C and turn it off at 75C;
{ high = true, notify_mC = 80000, recovery_mc = 75000, ... };
Then you can handle temperature-based events at your own charger device driver.
Cheers!
MyungJoo.
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Mon, May 07, 2012 at 11:28:05PM +0530, Ramakrishna Pallala wrote:
> Battery vendors like UER suggest to program Low Charge Voltage in case
> of high or low temperatures. So a battery can have different charge profile
> with in the battery operating temperature limits.
>
> Next, there could be events like drop or rise in VBUS voltage in that case
> we might have to adjust the charge current to stabilize VBUS voltage.
>
> This patch allows the Charger-Manager to adjust the charging parameters
> upon events like VBUS rise or drop and allows batteries to have multiple
> charge profiles for different temperature zones.
>
> Signed-off-by: Ramakrishna Pallala <[email protected]>
> ---
Applied, thanks a lot!
--
Anton Vorontsov
Email: [email protected]
On Tue, Jun 19, 2012 at 04:50:22PM -0700, Anton Vorontsov wrote:
> On Mon, May 07, 2012 at 11:28:05PM +0530, Ramakrishna Pallala wrote:
> > Battery vendors like UER suggest to program Low Charge Voltage in case
> > of high or low temperatures. So a battery can have different charge profile
> > with in the battery operating temperature limits.
> >
> > Next, there could be events like drop or rise in VBUS voltage in that case
> > we might have to adjust the charge current to stabilize VBUS voltage.
> >
> > This patch allows the Charger-Manager to adjust the charging parameters
> > upon events like VBUS rise or drop and allows batteries to have multiple
> > charge profiles for different temperature zones.
> >
> > Signed-off-by: Ramakrishna Pallala <[email protected]>
> > ---
>
> Applied, thanks a lot!
Oh, actually. I see the feature is still under discussion. I really
need some kind of OK/Ack from charger-manager folks before applying.
Thanks,
--
Anton Vorontsov
Email: [email protected]
> > On Mon, May 07, 2012 at 11:28:05PM +0530, Ramakrishna Pallala wrote:
> > > Battery vendors like UER suggest to program Low Charge Voltage in
> > > case of high or low temperatures. So a battery can have different
> > > charge profile with in the battery operating temperature limits.
> > >
> > > Next, there could be events like drop or rise in VBUS voltage in
> > > that case we might have to adjust the charge current to stabilize VBUS
> voltage.
> > >
> > > This patch allows the Charger-Manager to adjust the charging
> > > parameters upon events like VBUS rise or drop and allows batteries
> > > to have multiple charge profiles for different temperature zones.
> > >
> > > Signed-off-by: Ramakrishna Pallala <[email protected]>
> > > ---
> >
> > Applied, thanks a lot!
>
> Oh, actually. I see the feature is still under discussion. I really need some kind of
> OK/Ack from charger-manager folks before applying.
I will come with new patch once we come to a conclusion.
Thanks,
Ram
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?