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@xxxxxxxxx>
>>> ---
>>> 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
