pt., 26 sie 2022 o 07:52 Matti Vaittinen <mazziesaccount@xxxxxxxxx> napisał(a):
>
> On 8/25/22 18:37, Chris Morgan wrote:
> > On Thu, Aug 25, 2022 at 03:54:06PM +0300, Matti Vaittinen wrote:
> >> On 8/23/22 22:30, Chris Morgan wrote:
> >>> From: Chris Morgan <macromorgan@xxxxxxxxxxx>
> >>>
> >>> Add support for the Rockchip rk817 battery charger integrated into the
> >>> rk817 PMIC.
> >>>
> >>> Signed-off-by: Chris Morgan <macromorgan@xxxxxxxxxxx>
> >>> Signed-off-by: Maya Matuszczyk <maccraft123mc@xxxxxxxxx>
> >>> ---
> >>> drivers/power/supply/Kconfig | 6 +
> >>> drivers/power/supply/Makefile | 1 +
> >>> drivers/power/supply/rk817_charger.c | 1157 ++++++++++++++++++++++++++
> >>> 3 files changed, 1164 insertions(+)
> >>> create mode 100644 drivers/power/supply/rk817_charger.c
> >>>
> >>> +
> >>> +static void rk817_charging_monitor(struct work_struct *work)
> >>> +{
> >>> + struct rk817_charger *charger;
> >>> +
> >>> + charger = container_of(work, struct rk817_charger, work.work);
> >>> +
> >>> + rk817_read_props(charger);
> >>> +
> >>> + /* Run every 8 seconds like the BSP driver did. */
> >>> + queue_delayed_work(system_wq, &charger->work, msecs_to_jiffies(8000));
> >>> +}
> >>
> >> I really think we would benefit from some more framework code which could
> >> handle the periodic polling tasks and the coulomb counter drift corrections
> >> when battery is full/relaxed. I think I might revive the simple-gauge patch
> >> series...
> >
> > Possibly, does such exist or is that a future endeavor?
>
> No. Such a feature does not exist upstream. It was just some babbling I
> did here :) I started drafting something "generic" that would do polling
> of coulomb counter / battery state (full/relaxed) and then perform some
> 'CC resetting' to correct drifitng error and compute the SOC based on CC
> values. That would obviously just be a machinery that calls driver
> callbacks. I did support for two ROHM chargers using this concept but I
> had to switch to some urgent tasks before I managed to do proper
> testing. Might get back to that later though (depending on the other
> duties).
>
> > I'm only really
> > doing the polling because that's how the BSP driver was set up (and I
> > think it makes sense to not repeatedly check for teeny-tiny changes all
> > the time).
>
> I am far from being and expert on the chargers so I can't say if this is
> the "de-facto" way of doing things. I just have a feeling this (this
> meaning periodic reading from HW and then returning the 'cached' values
> to user-space) is quite common (I may be wrong though, many others
> including Sebastian and Linus W have _much_ more insight into how
> chargers/charger drivers/user-space operate). Caching/polling sounds
> like a task that could be implemented in the framework code rather than
> in many individual drivers. (This comment does not mean I would expect
> You to write such a framework for this driver - as I said, I am just
> pondering aloud and waiting to see how others think of this :] )
>
> > If there's an existing framework let me know, otherwise I'll
> > keep my eye out in the future and revise this if I can when it's live.
>
> So no existing framework and please, don't hold your breath waiting for
> one ;) It's still great to know that you can be pinged if I manage to
> cook-up something.
Feel free to ping me too, I started the work on mainline rk817 charger
driver and I've got device with battery connected to rk818 chip just
laying around and I assume that it's quite similar to rk817.
Best Regards,
Maya Matuszczyk
