public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: MyungJoo Ham <myungjoo.ham@samsung.com>
To: "Tc, Jenny" <jenny.tc@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Anton Vorontsov (cbouatmailru@gmail.com)"
	<cbouatmailru@gmail.com>,
	"Anton Vorontsov (anton.vorontsov@linaro.org)"
	<anton.vorontsov@linaro.org>,
	"Pallala, Ramakrishna" <ramakrishna.pallala@intel.com>,
	최찬우 <cw00.choi@samsung.com>, 박경민 <kyungmin.park@samsung.com>
Subject: Re: Charger Manager Proposal.
Date: Tue, 26 Jun 2012 00:57:03 +0000 (GMT)	[thread overview]
Message-ID: <27205114.39211340672223116.JavaMail.weblogic@epv6ml01> (raw)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=euc-kr, Size: 3236 bytes --]

> 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.

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

             reply	other threads:[~2012-06-26  0:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-26  0:57 MyungJoo Ham [this message]
2012-07-01 12:22 ` Charger Manager Proposal Tc, Jenny
  -- strict thread matches above, loose matches on Subject: below --
2012-06-20  9:41 Tc, Jenny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27205114.39211340672223116.JavaMail.weblogic@epv6ml01 \
    --to=myungjoo.ham@samsung.com \
    --cc=anton.vorontsov@linaro.org \
    --cc=cbouatmailru@gmail.com \
    --cc=cw00.choi@samsung.com \
    --cc=jenny.tc@intel.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ramakrishna.pallala@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox