Date:	Thu, 23 Dec 2010 08:17:39 +0000 (GMT)
From:	MyungJoo Ham <myungjoo.ham@...sung.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	¹Ú°æ¹Î <kyungmin.park@...sung.com>,
	½ÉÁØ¿µ <jy0922.shim@...sung.com>,
	Lukasz Majewski <l.majewski@...sung.com>,
	myungjoo.ham@...il.com
Subject: Re: Re: [PATCH v2 5/6] MFD MAX8998/LP3974: Charger Support

Sender : Mark Brown<broonie@...nsource.wolfsonmicro.com>
> On Thu, Dec 23, 2010 at 11:10:41AM +0900, MyungJoo Ham wrote:
> > On Wed, Dec 22, 2010 at 10:33 PM, Mark Brown
> > > On Wed, Dec 22, 2010 at 03:23:10PM +0900, MyungJoo Ham wrote:
> 
> > > Normally I'd expect a battery charger to be exposed via the power supply
> > > API - I'd at least expect to see a consumer in the power supply API
> 
> > The "CHARGER" regulator is to give the charger control to the user,
> > which consists of switching (turn on/off) and current limit, which is
> > what a current regulator does. On the contrary, when the charger
> > control is implemented by power supply API, we do not have explicit
> > control over such features (current limit and turn on/off).
> 
> Sure, like I say I'd just expect to see some power supply API visibility
> - that could be a driver that provides the control that's needed to
> userspace by controlling a current regulator, for example.

Alright. In the next patch release, I'll use power supply API with MAX8998
driver to show some status values. It appears that it's easier for me to
write charger controllers with it. :)

> 
> > Furthermore, a board may need to support multiple types of
> > charger(USB, ACDC-5V-2A, ACDC-5V-1A, ...), which have various current
> > limits. Thus, we need to adjust charger current limit out of PMIC
> > driver unless the PMIC can detect every type of supported chargers,
> > which MAX8998/LP3974 cannot.
> 
> Interesting system design - I've not seen that before.  With the system
> designs I usually look at the current limiting from the wall/charger
> supply is done on the primary system power rail which supplies both
> thehcarger and the rest of the system (since the current drains from the
> rest of the system also needs to be limited).  Similarly for the
> temperature monitoring, I've usually seen that managed by hardware.

Yes.. I'd be haapy if they design boards like that for me, too. :D
But, somehow, they attached a thermistor directly to an ADC port of CPU
and CPU needs to determine charge current.

> 
> > That's why I have implemented charger in regulator framework. In the
> > environment described above, the power supply consumer is going to be
> > implemented over PMIC driver, USB/TA select driver (e.g., FSA9480),
> > and Thermistor driver (e.g., NTC Thermistor). It appears that such a
> > consumer driver is going to be a board or policy specification; (or
> > full or callbacks that is going to be filled by a mach/board file)
> 
> I agree - it'd be a bit like the current GPIO power supply driver, I
> think.  It'd probably also specify things like callbacks for voltage
> monitoring via auxiliary ADCs in the PMIC or CPU.  My main point was
> that it was surprising that the regulator driver for the charger didn't
> come along with such a consuner driver, the split does make sense.

Thanks!

 MyungJoo Ham (ÇÔ¸íÁÖ)
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: +82-10-6714-2858 / office: +82-31-279-8033

Powered by blists - more mailing lists