From: Luca Ceresoli <luca@lucaceresoli.net>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: linux-pm@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] power: supply: max77976: add Maxim MAX77976 charger driver
Date: Tue, 26 Oct 2021 13:50:42 +0200 [thread overview]
Message-ID: <d8f6daba-4cb5-002e-9d3f-16825bf8c96b@lucaceresoli.net> (raw)
In-Reply-To: <20211025220256.tlsfosmuclbioj5m@earth.universe>
Hi Sebastian,
On 26/10/21 00:02, Sebastian Reichel wrote:
[...]
>> +config CHARGER_MAX77976
>> + tristate "Maxim MAX77976 battery charger driver"
>> + depends on REGMAP_I2C
>
> needs to be selected as pointed out by Randy.
Yes, fix ready for v2.
>> +static int max77976_get_health(struct max77976 *chg, int *val)
>> +{
>> + unsigned int regval;
>> + int err;
>> +
>> + err = regmap_field_read(chg->rfield[BAT_DTLS], ®val);
>> + if (err < 0)
>> + return err;
>> +
>> + switch (regval) {
>> + case MAX77976_BATTERY_BATTERY_REMOVAL:
>> + *val = POWER_SUPPLY_HEALTH_DEAD;
>> + break;
>
> I suppose the charger is still able to power the system when
> there is no battery, so it's not dead.
Correct.
> I think this should
> either report POWER_SUPPLY_HEALTH_GOOD or introduce a new
> POWER_SUPPLY_HEALTH_NO_BATTERY.
Introducing POWER_SUPPLY_HEALTH_NO_BATTERY seems to be the correct way.
I'll add a patch for that.
>> + case MAX77976_BATTERY_PREQUALIFICATION:
>> + case MAX77976_BATTERY_LOW_VOLTAGE:
>
> Not sure what prequalification is, but at least low voltage seems
> like a candidate to either introduce a new health property, or
> report an unspecified failure instead of HEALTH_GOOD.
Prequalification is defined in the datasheet [0] as: "A valid adapter is
present and the battery voltage is low: V_BATT < V_TRICKLE" (page 57).
The battery is charged at a very low current (300 mA) until voltage goes
above V_trickle (3.1 V).
[0] https://datasheets.maximintegrated.com/en/ds/MAX77975-MAX77976.pdf
This state probably very short-lived as I don't normally observe it even
when connecting a completely discharged battery.
To the best of my understanding, in this state the charger is charging
slowly to ensure the battery is good while staying safe. Perhaps this
should return POWER_SUPPLY_HEALTH_UNKNOWN then.
Low voltage is defined as: "A valid adapter is present and the battery
voltage is lower than the minimum system regulation level but higher
than prequalification voltage: V_TRICKLE < V_BATT < V_SYSMIN. V_SYS is
regulated at least equal to V_SYSMIN".
In this state the battery is not fully charged but it is OK, as
confirmed by the definition of bit BAT_OK in the CHG_INT_OK register
(0x12): "The battery is okay. BAT_DTLS = 0x03,0x04 or 0x07", value 0x04
being MAX77976_BATTERY_LOW_VOLTAGE.
So I think I should change PREQUALIFICATION to report
POWER_SUPPLY_HEALTH_UNKNOWN and leave LOW_VOLTAGE as is. Does it sound
correct?
>> +static const struct power_supply_desc max77976_psy_desc = {
>> + .name = MAX77976_DRIVER_NAME,
>> + .type = POWER_SUPPLY_TYPE_BATTERY,
>
> Incorrect type. TYPE_BATTERY is for fuel gauges. Looks like max77976
> is supposed to be used with USB, so:
>
> .type = POWER_SUPPLY_TYPE_USB,
Even though this charger is definitely a USB-oriented one, it is not
restricted to USB. E.g. I'm using it without any USB. Should I use
POWER_SUPPLY_TYPE_USB anyway?
>> +/* --------------------------------------------------------------------------
>> + * Entry point
>> + */
>> +
>> +static int max77976_detect(struct max77976 *chg)
>> +{
>> + struct device *dev = &chg->client->dev;
>> + unsigned int id, ver, rev;
>> + int err;
>> +
>> + err = regmap_read(chg->regmap, MAX77976_REG_CHIP_ID, &id);
>> + if (err)
>> + return dev_err_probe(dev, err, "cannot read chip ID\n");
>> +
>> + if (id != MAX77976_CHIP_ID)
>> + return dev_err_probe(dev, -ENXIO, "unknown model ID 0x%02x\n", id);
>> +
>> + err = regmap_field_read(chg->rfield[VERSION], &ver);
>> + if (!err)
>> + err = regmap_field_read(chg->rfield[REVISION], &rev);
>> + if (err)
>> + return dev_err_probe(dev, -ENXIO, "cannot read version/revision\n");
>> +
>> + dev_info(dev, "detected model MAX779%02x ver %u rev %u", id, ver, rev);
>> +
>> + return 0;
>> +}
>
> missing newline
Ouch.
--
Luca
next prev parent reply other threads:[~2021-10-26 11:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-04 13:07 [PATCH 1/2] dt-bindings: power: supply: add Maxim MAX77976 battery charger Luca Ceresoli
2021-10-04 13:07 ` [PATCH 2/2] power: supply: max77976: add Maxim MAX77976 charger driver Luca Ceresoli
2021-10-04 15:28 ` Randy Dunlap
2021-10-05 13:15 ` Luca Ceresoli
2021-10-25 22:02 ` Sebastian Reichel
2021-10-26 11:50 ` Luca Ceresoli [this message]
2021-10-06 16:15 ` [PATCH 1/2] dt-bindings: power: supply: add Maxim MAX77976 battery charger Sebastian Reichel
2021-10-26 11:53 ` Luca Ceresoli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d8f6daba-4cb5-002e-9d3f-16825bf8c96b@lucaceresoli.net \
--to=luca@lucaceresoli.net \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=sebastian.reichel@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®