Hello Josua, On Thu, Apr 25, 2024 at 11:23:35AM +0000, Josua Mayer wrote: > I came across your generic gpio-charger driver while looking at a > design using ltc4041 charging a super-capacitor that is providing > a few seconds of backup power. Since the charger only reports > status via gpios, it seems like a fit. First of all - In case you haven't noticed - Mike Looijmans is currently working on driver support for ltc3350 (which is also for capacitors): https://lore.kernel.org/linux-pm/20240416121818.543896-1-mike.looijmans@xxxxxxxx > At a closer look however none of my signals match exactly. > I want to explore possibility of extending your driver, > please can you comment if this driver is a suitable place > for achieving below goals?: > > (Relevant) Signals: > - PFO: Power-Fail, reports losing mains > - CAPGD: Super-Capacitor Power-Good, > reports whether capacitor is >= 92.5% > - CAPFLT: Super-Capacitor Fault Status, > effectively reports if charging stopped > - CHGEN: Enable/Disable charging > > Intended use-case: > Kernel should detect losing mains (or better !CAPGD), > then either generate event for user-space to perform > graceful shutdown, or trigger shutdown by itself. > > So far we have abused gpio-keys monitored from userspace. > > I think two properties from existing dt-bindings can match: > gpios: <&PFO>; > charge-status-gpios: <&CAPFLT>; As far as I can see it can signal things to be fine without the capacitors actually being charged (e.g. because of the disable), so that's not an acceptable thing upstream. > In my opinion driver is missing: > 1. disable-gpio: <&CHGEN>; > 2. something to describe battery charge level. > E.g. I have CAPGD signal which says either: > - 0: level < 92.5% > - 1: level >= 92.5% > This could be simplified to 0% and 92.5% The battery charge level should not be exposed by a charger device. Instead a second power-supply device of type POWER_SUPPLY_TYPE_BATTERY should be created. That device should set POWER_SUPPLY_PROP_TECHNOLOGY to the POWER_SUPPLY_TECHNOLOGY_CAPACITOR type, which is currently added by Mike (see link from above). Then the battery charge level can be exposed via POWER_SUPPLY_PROP_CAPACITY_LEVEL. For example when CAPGD is low, you set POWER_SUPPLY_CAPACITY_LEVEL_LOW and when it is high you set POWER_SUPPLY_CAPACITY_LEVEL_HIGH. For stopping the charging there are two ways. The cleaner one is adding support for POWER_SUPPLY_CHARGE_BEHAVIOUR_INHIBIT_CHARGE to the battery device. All things considered, I believe think a dedicated driver makes sense. It should be quite simple considering it only needs to handle a few GPIOs. Something like compatible = "ltc,ltc4041"; system-good-gpios = <&gpio>; capacitor-good-gpios = <&gpio>; charge-enable-gpios = <&gpio>; capacitor-fault-gpios = <&gpio>; Then you should have 1 charger device and 1 battery device exposed to userspace. The charger device should supply the battery device. Charger exposes POWER_SUPPLY_PROP_ONLINE and the Battery device exposes POWER_SUPPLY_PROP_STATUS (charging/not-charging), POWER_SUPPLY_PROP_TECHNOLOGY, POWER_SUPPLY_PROP_CAPACITY_LEVEL and POWER_SUPPLY_CHARGE_BEHAVIOUR. Greetings, -- Sebastian
Attachment:
signature.asc
Description: PGP signature
