From: Tc, Jenny<jenny...@intel.com> > > > From: Sebastian Reichel [mailto:s...@kernel.org] > > Sent: Friday, July 18, 2014 7:49 AM > > To: Tc, Jenny > > Cc: linux-kernel@vger.kernel.org; Dmitry Eremin-Solenikov; Pavel Machek; > > Anton > > Vorontsov; David Woodhouse; David Cohen; Pallala, Ramakrishna; > > myungjoo....@samsung.com > > Subject: Re: [PATCH 2/4] power_supply: Introduce generic psy charging driver > > > > Hi Jenny, > > > > On Tue, Jul 08, 2014 at 11:34:19AM +0530, Jenny TC wrote: > > > The Power Supply charging driver connects multiple subsystems to do > > > charging in a generic way. The subsystems involves power_supply, > > > thermal and battery communication subsystems (1wire). With this the > > > charging is handled in a generic way. > > > > > > The driver makes use of different new features - Battery > > > Identification interfaces, pluggable charging algorithms, charger cable > > > arbitrations > > etc. > > > The patch also introduces generic interface for charger cable > > > notifications. > > > Charger cable events and capabilities can be notified using the > > > generic power_supply_notifier chain. > > > > > > Overall this driver removes the charging logic out of the charger chip > > > driver and the charger chip driver can just listen to the request from > > > the power supply charging driver to set the charger properties. This > > > can be implemented by exposing get_property and set property callbacks. > > > > this seems to be a superset of charger-manager, which is already in the > > kernel. I > > would prefer not to have two different charger mangement frameworks in the > > kernel. > > > > I suggest to add features supported by charger-manager to power supply > > charging > > driver and convert users of charger-manager to the improved driver. > > > > I CC'd MyungJoo Ham, who wrote the charger-manager, so that he can also give > > feedback. > > We are back to the initial discussions we had in the list. The initial > proposal > was for the charger manager. The charger manager is more aligned to > regulator framework, use private notification > mechanisms(cm_notify_event,fullbatt_vchk etc) and relies more on > platform data (struct charger_desc). This doesn't seems to be good to support > plug in > charger drivers, charging algorithms, battery identification drivers at > runtime.
Then, the additional requirement is - Online or runtime modification or probe of the platform data (use .ko?) for "plugin chargers & battery identification) - Externally implement charging algorithms. (allow charger-manager to have an external funtion pointer?) > Power supply charger driver is introduced to meet all these requirements by > extending the existing power_supply subsystem features like > power_supply_changed event, power_supply_register, power supply thermal > throttling mechanism so that plugging new driver would be > easy. Also the user interfaces would remain the same as power_supply > subsystem. - Replace (rewrite) charger-manager's private event handlers with power supply changed work? For identifying plugin (external) chargers and feeding such information to charger-manager, extcon might be a good interconnection, which is initially designed for devices supporting differernt external chargers. (USB charger, 1.5A OEM charger, 1.0A 3rd party "popular" charger, ...) > > Able to locate link on the discussion. > http://www.gossamer-threads.com/lists/linux/kernel/1562180. Cheers, MyungJoo ps. CC'd related collegues as well. (Sangjung, Chanwoo, Jonghwa) -- MyungJoo Ham (함명주), PHD Frontier CS Lab, Software Center Samsung Electronics Cell: +82-10-6714-2858
