[RFC] power: supply: gpio-charger: extend for supercap charger ltc4041

[RFC] power: supply: gpio-charger: extend for supercap charger ltc4041

[Josua Mayer]

Hi Sebastian,

I came across your generic gpio-charger driver while looking
at a design using lrc4041 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.

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>;

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%

sincerely
Josua Mayer

Re: [RFC] power: supply: gpio-charger: extend for supercap charger ltc4041

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 3284 bytes --]

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@topic.nl

> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]