linux-kernel - Re: [PATCH v2 5/6] MFD MAX8998/LP3974: Charger Support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTimhfUTD0ze8VaBz9BtkuEMx9sutc-1VvsXfH-ot@mail.gmail.com>
Date:	Thu, 23 Dec 2010 11:10:41 +0900
From:	MyungJoo Ham <myungjoo.ham@...sung.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	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 <kyungmin.park@...sung.com>,
	Joonyoung Shim <jy0922.shim@...sung.com>,
	Lukasz Majewski <l.majewski@...sung.com>
Subject: Re: [PATCH v2 5/6] MFD MAX8998/LP3974: Charger Support

On Wed, Dec 22, 2010 at 10:33 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Wed, Dec 22, 2010 at 03:23:10PM +0900, MyungJoo Ham wrote:
>> With the new regulator, "CHARGER", users can control charging
>> current and turn on and off the charger. Note that the charger
>> specification of LP3974 is different from that of MAX8998.
>>
>> "CHARGER_ONLINE" monitors the charger status, which can be
>> different from the status "CHARGER"; e.g., users allowed the charger
>> to charge, but the MAX8998 chip decided not to do so.
>>
>> "BATTERY_ONLINE" monitors the battery status (the existence of the
>> battery).
>
> 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
> which manages the charger and given the amount of automation you usually
> see in chargers integrated into PMICs (things like automatically
> starting and stopping themselves) it's not entirely clear that they map
> on that well to the regulator 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).

Yes, PMICs including MAX8998/LP3974 can turn the charger on/off
automatically; however, users (or board designers) still want explicit
control over charger.

For example, there could be a thermistor attached on a board (out of
PMIC) reading battery temperature, which is used to cut the charger
off if it's too hot or cold; then, we cannot rely on PMIC's automatic
control unless we put thermistor drivers into PMIC driver.
MAX8998/LP3974 has a thermistor in it; however, it measures the chip
core temperature, not the ambient temperature.

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.

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)

Thanks.

- MyungJoo

-- 
MyungJoo Ham (함명주), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/