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
N�����r��y����b�X��ǧv�^�){.n�+����{����zX����ܨ}���Ơz�&j:+v�������zZ+��+zf���h���~����i���z� �w���?�����&�)ߢf��^jǫy�m��@A�a���
0��h���i
