Hello all,
On 03/31/2016 09:06 AM, Bruno Prémont wrote:
> Currently I don't have enough spare time to (actively) work on the patch
> set, so feel free to pick up!
>
> With recent additions of support for other AXP variants some porting
> work has to be done (not sure I published my latest porting attempts
> with some rework to adapt to Hans's axp20x_usb_power.c) and I won't have
> time/access to right device to check before mid April.
I have applied your patch to my local tree. No conflicts! I'll be
cleaning this up and submit it as a series.
The latest patch I found [0] mentions that it's a port "on top of Hans'
work".
>
>>>> CC'ing Hans as he implemented axp20x_usb_power.c.
>>> IIRC, Hans previously said that the acin and vbus supplies should be handled
>>> by separate power supply drivers. ACIN is easy to do. Just port the VBUS
>>> one.
>>>
>> Yeah, that is very straightforward.
> Just remember that some devices short-cut ACIN and VBUS, thus the ACIN
> driver should only load when the AXP status bit indicates they are
> distinct (maybe also having device-tree flag to indicate connector
> presence when not short-cutted).
I have added a check for the short-cut bit in the power status register.
Regarding device-tree flag: if the device short-cuts ACIN and VBUS, the
dts file should only contain the VBUS node.
>
>>> The charger would likely be another separate driver, either combined or
>>> separate from the fuel gauge (charge level) driver.
> One thing I explicitly left aside was "estimating battery capacity", the
> original 3.4.x code included some heuristics for that with saving
> intermediate values to AXP's registers (data registers kept alive as
> long as power was present).
In any case, I'd rather not get too fancy here. Maybe I'll take a stab
at this in a second iteration.
It looks like the "estimating battery capacity" bit would be exposed via
CHARGE_FULL and
CHARGE_EMPTY attributes. Getting that right is probably not that easy as
you have to go
through at least a single charge/discharge cycle.
>
> Gauge and charger should be a single driver, especially when capacity
> estimation comes into play. Interesting is the part of adjusting charge
> current based on AC/VBUS power source and taking VBUS's max-current into
> account.
Doesn't the AXP209 do that automatically?
>
> The RTC battery charger though can be a mostly hidden driver as all it
> needs is some settings from device-tree (voltage/current) and has no
> data to report. Letting the user tune voltage/current or enable/disable
> the charger is a matter of taste. From my cubietruck's behavior it seems
> as if charger enablement might have an impact of rtc battery's
> discharge rate while device is powered-off.
Do you mean that the RTC battery discharges faster when the charger is
disabled
and the device is powered off (and disconnected from power)?
Two questions about your original patch at [0]:
1) In axp20x_fuel_gauge.c, there is lots of code commented out in
axp20x_power_probe().
It seems to me that the commented out functionality is actually
implemented above. Is that correct?
2) Do you remember what's missing from the power management in
axp20x_fuel_gauge, e.g. in
axp20x_power_suspend()? You noted that as a TODO and the references
to those functions are commented out.
Thanks for the input so far!
Michael
[0] https://groups.google.com/forum/#!topic/linux-sunxi/_XIjwZfEi2U
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
