[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-id: <27205114.39211340672223116.JavaMail.weblogic@epv6ml01>
Date: Tue, 26 Jun 2012 00:57:03 +0000 (GMT)
From: MyungJoo Ham <myungjoo.ham@...sung.com>
To: "Tc, Jenny" <jenny.tc@...el.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Anton Vorontsov (cbouatmailru@...il.com)" <cbouatmailru@...il.com>,
"Anton Vorontsov (anton.vorontsov@...aro.org)"
<anton.vorontsov@...aro.org>,
"Pallala, Ramakrishna" <ramakrishna.pallala@...el.com>,
ÃÖÂù¿ì <cw00.choi@...sung.com>,
¹Ú°æ¹Î <kyungmin.park@...sung.com>
Subject: Re: Charger Manager Proposal.
> MyungJoo,
>
> I would like to align with the charger-manager activities and would like to propose few changes for charger-manager. The changes I would like to have in the charger manager is
>
> * Manage charging based on a battery profile - Each battery can have a different profile and the charging should be done based on this profile. So there should be a mechanism inside the charger-manager to read the battery profile. To start with we can make it available as platform data for the charger-manager.
Yes, each instance of charger-manager devices represents a battery (or a set of batteries controlled as a single battery.) Thus, the profile can be described in struct charger_desc. What do you need additionally there?
> * The charge parameters (CC and CV) needs to be changed as per the batter profile. The battery profile will have a different CC and CV for different temperature zone. So charger-manager needs to listen battery Temperature change events (using power_supply_changed events from FG?) and modify the CC and CV.
Then, my suggestion is that
Plan A.
1. Add a pair of CC and CV regulators at struct charger_desc, independently defined in struct charger_desc from charger_desc.charger_regulators as charger_regulators are to enable/disable chargers attached to the battery described by struct charger_desc.
2. Add an array of { temperature (min), CC-value, CV-value, hysterisis-temp } with temperature = - MAX for "default" value.
Plan B.
1. Add an array of { temperature (min), callback, hysterisis-temp}
If CC/CV values are the only ones to be controlled by temperature, Plan A is fine. However, if we are going to need more, Plan B may be more appropriate.
> * It's good to have a hybrid (Software and Hardware mode) full detection logic. This give more flexibility to define the charge full detection thresholds. So charger-manager can listen to charge-full detection from charger-hardware and can start a thread to verify the thresholds from software.
You can do this with cm_notify_event() and fullbatt_vchk() though we may need more parameters to control the behavior of fullbatt_vchk().
> * Need to have a maintenance upper voltage threshold. The upper threshold needs to be less than the Battery FULL voltage threshold and this can part of battery profile. This approach helps to increase the battery life.
Could you please elaborate this one more? What do you do with "upper threshold"?
>
> I would like to start implementing these features for charger manager. But I would like to align with your planned charger-manager activities so that we don't end up in duplicating the effort. Please let me know your suggestions on this.
>
> -jtc
Another update or modification on-going is:
- Integrating with extcon subsystem
- Add current-limit for each charger
You can see the according patches at
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/charger-manager-for-next
Thanks. And sorry for late reply; we had the office moved which cut the internetaccess for a while.
Cheers!
MyungJoo.
Powered by blists - more mailing lists