public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Jakob Hauser <jahau@rocketmail.com>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Lee Jones <lee@kernel.org>, Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Beomho Seo <beomho.seo@samsung.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Stephan Gerhold <stephan@gerhold.net>,
	Raymond Hackley <raymondhackley@protonmail.com>,
	Pavel Machek <pavel@ucw.cz>, Axel Lin <axel.lin@ingics.com>,
	ChiYuan Huang <cy_huang@richtek.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Henrik Grimler <henrik@grimler.se>,
	linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, phone-devel@vger.kernel.org,
	~postmarketos/upstreaming@lists.sr.ht
Subject: Re: [PATCH v4 7/8] power: supply: rt5033_battery: Adopt status property from charger
Date: Tue, 9 May 2023 03:01:32 +0200	[thread overview]
Message-ID: <55fd9835-4246-00e8-b641-c8b0ee3f7e22@rocketmail.com> (raw)
In-Reply-To: <20230508220605.kderc3nihhezouit@mercury.elektranox.org>

Hi Sebastian,

On 09.05.23 00:06, Sebastian Reichel wrote:
> Hi,
> 
> On Mon, May 08, 2023 at 11:18:28PM +0200, Jakob Hauser wrote:
>> On 08.05.23 13:35, Sebastian Reichel wrote:
>>> On Sat, May 06, 2023 at 05:54:34PM +0200, Jakob Hauser wrote:
>>>> The rt5033-battery fuelgauge can't get a status by itself. The rt5033-charger
>>>> can, let's get this value.
>>>>
>>>> Tested-by: Raymond Hackley <raymondhackley@protonmail.com>
>>>> Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
>>>> ---
>>>>    drivers/power/supply/rt5033_battery.c | 24 ++++++++++++++++++++++++
>>>>    1 file changed, 24 insertions(+)
>>>>
>>>> diff --git a/drivers/power/supply/rt5033_battery.c b/drivers/power/supply/rt5033_battery.c
>>>> index 5c04cf305219..a6520716d813 100644
>>>> --- a/drivers/power/supply/rt5033_battery.c
>>>> +++ b/drivers/power/supply/rt5033_battery.c
>>>> @@ -12,6 +12,26 @@
>>>>    #include <linux/mfd/rt5033-private.h>
>>>>    #include <linux/mfd/rt5033.h>
>>>> +static int rt5033_battery_get_status(struct i2c_client *client)
>>>> +{
>>>> +	struct power_supply *charger;
>>>> +	union power_supply_propval val;
>>>> +	int ret;
>>>> +
>>>> +	charger = power_supply_get_by_name("rt5033-charger");
>>>> +	if (!charger)
>>>> +		return POWER_SUPPLY_STATUS_UNKNOWN;
>>>> +
>>>> +	ret = power_supply_get_property(charger, POWER_SUPPLY_PROP_STATUS, &val);
>>>> +	if (ret) {
>>>> +		power_supply_put(charger);
>>>> +		return POWER_SUPPLY_STATUS_UNKNOWN;
>>>> +	}
>>>
>>> struct rt5033_battery *battery = i2c_get_clientdata(client);
>>> ret = power_supply_get_property_from_supplier(battery->psy, POWER_SUPPLY_PROP_STATUS, &val);
>>> if (ret)
>>>       val.intval = POWER_SUPPLY_STATUS_UNKNOWN;
>>
>> I don't think this works. There is no direct relationship between
>> rt5033-charger and rt5033-battery. They operate independently from each
>> other.
> 
> That should be fine as long as the supply dependency is properly declared.
> 
>> I had a short try and the status property of rt5033-battery was "unknown".
>>
>> Just for the record, the full function I tried was:
>>
>> static int rt5033_battery_get_status(struct i2c_client *client)
>> {
>>          struct rt5033_battery *battery = i2c_get_clientdata(client);
>>          union power_supply_propval val;
>>          int ret;
>>
>>          ret = power_supply_get_property_from_supplier(battery->psy,
>>                                               POWER_SUPPLY_PROP_STATUS,
>>                                               &val);
>>          if (ret)
>>                  val.intval = POWER_SUPPLY_STATUS_UNKNOWN;
>>
>>          return val.intval;
>> }
>>
>> Later on I added a read-out of the "ret" value. It is "-19". I guess that's
>> the "return -ENODEV;" from function
>> power_supply_get_property_from_supplier(). [2]
>>
>> [2] https://github.com/torvalds/linux/blob/v6.4-rc1/drivers/power/supply/power_supply_core.c#L397-L421
> 
> I suppose your DT is missing the connection between the charger and
> the battery:
> 
> rt5033_charger: charger {
>      compatible = "rt5033-charger";
>      ...
> }
> 
> fuel-gauge {
>      compatible = "rt5033-battery";
>      ...
>      power-supplies = <&rt5033_charger>; // you are probably missing this
> };
> 
> See also Documentation/devicetree/bindings/power/supply/power-supply.yaml

...

Thanks for the hints.

This leads to updating the dt-bindings because adding the 
"power-supplies" property is important to be aware of.

Btw. first it didn't work. It took me quite some time to debug. I needed 
to add "psy_cfg.of_node = client->dev.of_node;" to the rt5033-battery 
probe function.

Now it works. However, there is a new problem. The battery driver gets 
probed first. The charger driver a bit later. In the meantime the 
battery driver spams dmesg with several "Failed to register power 
supply" because the charger driver isn't available yet. Once the charger 
driver is there, it works fine and dmesg becomes silent.

With the current state of the patchset:
dmesg | grep rt5033
[   13.628030] rt5033 6-0034: Device found (rev. 6)
[   13.633552] rt5033-led: Failed to locate of_node [id: -1]
[   13.790478] rt5033-charger rt5033-charger: DMA mask not set

With the changes discussed here:
dmesg | grep rt5033
[   15.741915] rt5033-battery 4-0035: Failed to register power supply
[   15.752894] rt5033-battery 4-0035: Failed to register power supply
[   15.795458] rt5033-battery 4-0035: Failed to register power supply
[   15.910760] rt5033-battery 4-0035: Failed to register power supply
[   15.913187] rt5033 6-0034: Device found (rev. 6)
[   15.914341] rt5033-led: Failed to locate of_node [id: -1]
[   15.920052] rt5033-battery 4-0035: Failed to register power supply
[   15.927262] rt5033-battery 4-0035: Failed to register power supply
[   16.017131] rt5033-battery 4-0035: Failed to register power supply
[   16.017401] rt5033-charger rt5033-charger: DMA mask not set

The message is comming from the rt5033-battery probe function, it's the 
power_supply_register() that fails.

Any ideas what could be done about this?

Kind regards,
Jakob

  reply	other threads:[~2023-05-09  1:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230506155435.3005-1-jahau.ref@rocketmail.com>
2023-05-06 15:54 ` [PATCH v4 0/8] Add RT5033 charger device driver Jakob Hauser
2023-05-06 15:54   ` [PATCH v4 1/8] mfd: rt5033: Drop rt5033-battery sub-device Jakob Hauser
2023-05-06 15:54   ` [PATCH v4 2/8] mfd: rt5033: Fix chip revision readout Jakob Hauser
2023-05-06 15:54   ` [PATCH v4 3/8] mfd: rt5033: Fix STAT_MASK, HZ_MASK and AICR defines Jakob Hauser
2023-05-06 15:54   ` [PATCH v4 4/8] mfd: rt5033: Apply preparatory changes before adding rt5033-charger driver Jakob Hauser
2023-05-06 15:54   ` [PATCH v4 5/8] power: supply: rt5033_charger: Add RT5033 charger device driver Jakob Hauser
2023-05-08  6:50     ` Sebastian Reichel
2023-05-08 20:27       ` Jakob Hauser
2023-05-06 15:54   ` [PATCH v4 6/8] power: supply: rt5033_charger: Add cable detection and USB OTG supply Jakob Hauser
2023-05-08 11:43     ` Sebastian Reichel
2023-05-08 20:36       ` Jakob Hauser
2023-05-06 15:54   ` [PATCH v4 7/8] power: supply: rt5033_battery: Adopt status property from charger Jakob Hauser
2023-05-08 11:35     ` Sebastian Reichel
2023-05-08 21:18       ` Jakob Hauser
2023-05-08 22:06         ` Sebastian Reichel
2023-05-09  1:01           ` Jakob Hauser [this message]
2023-05-09  7:25             ` Sebastian Reichel
2023-05-09 23:00               ` Jakob Hauser
2023-05-06 15:54   ` [PATCH v4 8/8] dt-bindings: Add rt5033 mfd, regulator and charger Jakob Hauser
2023-05-09  9:18     ` Krzysztof Kozlowski
2023-05-09 23:08       ` Jakob Hauser

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=55fd9835-4246-00e8-b641-c8b0ee3f7e22@rocketmail.com \
    --to=jahau@rocketmail.com \
    --cc=axel.lin@ingics.com \
    --cc=beomho.seo@samsung.com \
    --cc=broonie@kernel.org \
    --cc=cw00.choi@samsung.com \
    --cc=cy_huang@richtek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=henrik@grimler.se \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lee@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=phone-devel@vger.kernel.org \
    --cc=raymondhackley@protonmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=stephan@gerhold.net \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    /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