lkml.org 
[lkml]   [2012]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: RE: Charger Manager Proposal.
Date
Anton,


> Hm. So Myungjoo thinks that some of the features are compatible. Which do
> you guys think are not compatible? Is this because charger manager does
> everything using a regulator framework? That is, quoting you:
>
> "The challenge I see in implementing the above requirements in charger
> manager is, some of the above requirements are not supported by
> the regulator framework."
>
> So, maybe the part of the solution would be enhancing the regulators
> framework?..

I think modifying the regulator framework will not give a cleaner solution. The charger has more properties than that can be handled by a regulator framework (Like controlling the charger path, CC and CV etc. ). Also wanted to make the charger algorithm event based. So keeping it with power_supply subsystem gives more flexibility to handle events. For example battery temperature change, voltage change, charger/battery status change etc can be easily hooked to the power_supply_changed_work.

>
> > The outcome of all the above changes would be that, a set of charging
> algorithms would be available in the mainline and chargers can make use of
> the algorithms without making much modifications to the charger driver
> code. Also this would give a standard framework for monitoring and
> controlling battery charging.
>
> The idea of plug-in charging algorithms sounds great. So that we could
> choose the algo based on the battery type, charger type etc.
> This is awesome. But do you think you really need a new subsystem for that?
> And if so, will it complement charger manager, compete or substitute it?

The idea is to enhance the power_supply subsystem to plugin charging algorithms. It is not a substitute solution for charger-manager.
>
> I would have no problem with complementary subsystem, or just
> evolutionary/incrementally changing the charger-manger (this is surely
> preferred). If you think there is no way for incrementally modifying charger-
> manager for your needs, and you want a "from scratch" solution, this is also
> doable but following requirements are must-have:
>
> 1. You can prove (on technical merits) that your new charger manager
> is a complete superset of the old one, and adds some vital features
> not available before (and these would be hard to implement in
> terms of the old subsystem);
> 2. You'll have a defined roadmap to convert all charger-manager
> users to a new subsystem (preferably w/ patches ready).
>

The new solution is not intended to replace the charger-manager framework. So I think the charger-manager users can continue to use the charger-manager without any change.

> From the past experience, I can tell you that modifying an existing subsystem
> is a much easier way. :-) And the biggest advantage of the current code is
> that it is already well-tested, and incremental changes are easy to bisect.
>

I agree to your point. We wanted to make use of the power_supply subsystem features as much as possible rather than having a completely new subsystem.

Thanks
-jtc
\
 
 \ /
  Last update: 2012-07-19 14:01    [W:0.041 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site