Message-ID: <311c13e0-2f14-4134-afb5-128bc82111e7@kernel.org>
Date: Fri, 31 May 2024 14:18:22 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Artur Weber <aweber.kernel@...il.com>,
 Chanwoo Choi <cw00.choi@...sung.com>
Cc: Sebastian Reichel <sre@...nel.org>, Rob Herring <robh@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Lee Jones <lee@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Alim Akhtar <alim.akhtar@...sung.com>, linux-pm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-samsung-soc@...r.kernel.org,
 ~postmarketos/upstreaming@...ts.sr.ht, Henrik Grimler <henrik@...mler.se>,
 Wolfgang Wiedmeyer <wolfgit@...dmeyer.de>,
 Denis 'GNUtoo' Carikli <GNUtoo@...erdimension.org>
Subject: Re: [PATCH RFC 06/11] power: supply: max77693: Set charge current
 limits during init

On 31/05/2024 13:55, Artur Weber wrote:
> On 31.05.2024 11:47, Krzysztof Kozlowski wrote:
>> On 30/05/2024 10:55, Artur Weber wrote:
>>> There are two charger current limit registers:
>>>
>>> - Fast charge current limit (which controls current going from the
>>>    charger to the battery);
>>> - CHGIN input current limit (which controls current going into the
>>>    charger through the cable, and is managed by the CHARGER regulator).
>>>
>>> Add functions for setting both of the values, and set them to a
>>> safe default value of 500mA at initialization.
>>>
>>> The default value for the fast charge current limit can be modified
>>> by setting the maxim,fast-charge-current-microamp DT property; the
>>> CHGIN input current limit will be set up later in the charger detection
>>> mechanism.
>>>
>>> Signed-off-by: Artur Weber <aweber.kernel@...il.com>
>>> ---
>>>   drivers/power/supply/max77693_charger.c | 45 +++++++++++++++++++++++++++++++++
>>>   1 file changed, 45 insertions(+)
>>>
>>> diff --git a/drivers/power/supply/max77693_charger.c b/drivers/power/supply/max77693_charger.c
>>> index 894c35b750b3..d59b1524b0a4 100644
>>> --- a/drivers/power/supply/max77693_charger.c
>>> +++ b/drivers/power/supply/max77693_charger.c
>>> @@ -28,6 +28,7 @@ struct max77693_charger {
>>>   	u32 min_system_volt;
>>>   	u32 thermal_regulation_temp;
>>>   	u32 batttery_overcurrent;
>>> +	u32 fast_charge_current;
>>>   	u32 charge_input_threshold_volt;
>>>   };
>>>   
>>> @@ -591,6 +592,35 @@ static int max77693_set_batttery_overcurrent(struct max77693_charger *chg,
>>>   			CHG_CNFG_12_B2SOVRC_MASK, data);
>>>   }
>>>   
>>> +static int max77693_set_input_current_limit(struct max77693_charger *chg,
>>> +		unsigned int uamp)
>>> +{
>>> +	dev_dbg(chg->dev, "CHGIN input current limit: %u\n", uamp);
>>
>> That's quite useless debug. It duplicates
>> max77693_set_fast_charge_current(). Just drop entire wrapper.
> 
> It doesn't duplicate max77693_set_fast_charge_current, they modify two
> separate registers. Quote from the commit message: 

But it is the same uamp value. Debug messages should not be per register
write, because we are not debugging here registers...

> 
>> There are two charger current limit registers:
>>
>> - Fast charge current limit (which controls current going from the
>>  charger to the battery);
>> - CHGIN input current limit (which controls current going into the
>>   charger through the cable, and is managed by the CHARGER regulator).
> 
> max77693_set_fast_charge_current sets up the "fast charge current"
> register (in CNFG_02, CHG_CNFG_02_CC). The CHARGER regulators sets the
> CHGIN input current (in CNFG_09, CHG_CNFG_09_CHGIN_ILIM).
> 
> (Apparently the CHARGER regulator is supposed to handle the fast
> charge current, but it does not; I wrote about this in the "CHARGER
> regulator" section of the patchset description.)
> 
>>> +
>>> +	return regulator_set_current_limit(chg->regu, (int)uamp, (int)uamp);
>>> +}
>>> +
>>> +static int max77693_set_fast_charge_current(struct max77693_charger *chg,
>>> +		unsigned int uamp)
>>> +{
>>> +	unsigned int data;
>>> +
>>> +	data = (uamp / 1000) * 10 / 333; /* 0.1A/3 steps */
>>> +
>>> +	if (data > CHG_CNFG_02_CC_MASK) {
>>> +		dev_err(chg->dev, "Wrong value for fast charge current\n");
>>> +		return -EINVAL;
>>> +	}
>>> +
>>> +	data <<= CHG_CNFG_02_CC_SHIFT;
>>> +
>>> +	dev_dbg(chg->dev, "Fast charge current: %u (0x%x)\n", uamp, data);
>>> +
>>> +	return regmap_update_bits(chg->max77693->regmap,
>>> +			MAX77693_CHG_REG_CHG_CNFG_02,
>>> +			CHG_CNFG_02_CC_MASK, data);
>>
>> I am surprised that you set current limit via regulator but actual
>> charging current value here. I think both should go to regulator in such
>> case.
> 
> As in, both fast charge current and input current should be set up by
> the CHARGER regulator? Sure, sounds good to me.
> 
> I've noticed that on the original kernel, both of the values are
> modified together too (only exception is that fast charge current would
> be set to 0 when the cable was unplugged, but the input current stayed
> at 500mA. This doesn't seem to affect anything, though.).
> 
> At one point I actually considered going the other way around - moving
> all charger register handling into the charger driver, instead of having
> it be a regulator. As far as I can tell, only some Samsung-submitted
> charger drivers (max77693, max8997, max8998, max14577) use a regulator
> to manage the charger current (if anything, some power supply drivers
> expose an OTG/VBUS regulator, might be something for us to consider as
> well...).

regulator choice was to match userspace design that time (long time
ago), but I think now preference is to use writeable properties of power
supply class. I'll defer here to Sebastian.

> 
> I see you wrote at least the max14577 and part of the max77693 driver;
> out of curiosity, what's the benefit of doing it through a current
> regulator (as opposed to adding set functions for the relevant
> properties in the charger driver)? I've noticed the downstream driver
> has a very similar pattern[1], I wonder if it's just a port of that or
> if there's a more concrete reason.
> 


Best regards,
Krzysztof

Powered by blists - more mailing lists