All of lore.kernel.org
 help / color / mirror / Atom feed
From: ChiYuan Huang <u0084500@gmail.com>
To: Axel Lin <axel.lin@ingics.com>
Cc: Mark Brown <broonie@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	ChiYuan Huang <cy_huang@richtek.com>
Subject: Re: [PATCH] regulator: rt5033: Use linear ranges to map all voltage selection
Date: Thu, 1 Jul 2021 13:53:03 +0800	[thread overview]
Message-ID: <CADiBU3_dCNvZRwewiztB0UGFvDz3g5sw-q+95sg9akqte1YJsA@mail.gmail.com> (raw)
In-Reply-To: <CAFRkauCNf6fP8zAz+0gY_Vzb_wCtVyYqLjw8s1T+t2s=bR0RQw@mail.gmail.com>

Axel Lin <axel.lin@ingics.com> 於 2021年7月1日 週四 下午12:41寫道:
>
>
>
> cy_huang <u0084500@gmail.com> 於 2021年7月1日 週四 上午11:54寫道:
>>
>> From: ChiYuan Huang <cy_huang@richtek.com>
>>
>> Instead of linear mapping, Use linear range to map all voltage selection.
>>
>> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
>> ---
>> Even though commit 6549c46af855 ("regulator: rt5033: Fix n_voltages settings for BUCK and LDO")
>> can fix the linear mapping to the correct min/max voltage
>> But there're still non-step ranges for the reserved value.
>>
>> To use the linear range can fix it for mapping all voltage selection.
>> ---
>>  drivers/regulator/rt5033-regulator.c | 23 +++++++++++++++--------
>>  1 file changed, 15 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/regulator/rt5033-regulator.c b/drivers/regulator/rt5033-regulator.c
>> index 0e73116..2ff607c 100644
>> --- a/drivers/regulator/rt5033-regulator.c
>> +++ b/drivers/regulator/rt5033-regulator.c
>> @@ -13,6 +13,16 @@
>>  #include <linux/mfd/rt5033-private.h>
>>  #include <linux/regulator/of_regulator.h>
>>
>> +static const struct linear_range rt5033_buck_ranges[] = {
>> +       REGULATOR_LINEAR_RANGE(1000000, 0, 20, 100000),
>> +       REGULATOR_LINEAR_RANGE(3000000, 21, 31, 0),
>> +};
>> +
>> +static const struct linear_range rt5033_ldo_ranges[] = {
>> +       REGULATOR_LINEAR_RANGE(1200000, 0, 18, 100000),
>> +       REGULATOR_LINEAR_RANGE(3000000, 19, 31, 0),
>> +};
>> +
>>  static const struct regulator_ops rt5033_safe_ldo_ops = {
>>         .is_enabled             = regulator_is_enabled_regmap,
>>         .enable                 = regulator_enable_regmap,
>> @@ -24,8 +34,7 @@ static const struct regulator_ops rt5033_buck_ops = {
>>         .is_enabled             = regulator_is_enabled_regmap,
>>         .enable                 = regulator_enable_regmap,
>>         .disable                = regulator_disable_regmap,
>> -       .list_voltage           = regulator_list_voltage_linear,
>> -       .map_voltage            = regulator_map_voltage_linear,
>> +       .list_voltage           = regulator_list_voltage_linear_range,
>>         .get_voltage_sel        = regulator_get_voltage_sel_regmap,
>>         .set_voltage_sel        = regulator_set_voltage_sel_regmap,
>>  };
>> @@ -39,9 +48,8 @@ static const struct regulator_desc rt5033_supported_regulators[] = {
>>                 .ops            = &rt5033_buck_ops,
>>                 .type           = REGULATOR_VOLTAGE,
>>                 .owner          = THIS_MODULE,
>> -               .n_voltages     = RT5033_REGULATOR_BUCK_VOLTAGE_STEP_NUM,
>> -               .min_uV         = RT5033_REGULATOR_BUCK_VOLTAGE_MIN,
>> -               .uV_step        = RT5033_REGULATOR_BUCK_VOLTAGE_STEP,
>> +               .linear_ranges  = rt5033_buck_ranges,
>> +               .n_linear_ranges = ARRAY_SIZE(rt5033_buck_ranges),
>>
>
> If you want to use linear range here, you need to change RT5033_REGULATOR_BUCK_VOLTAGE_STEP_NUM back to 32
> rather than delete the .n_voltages setting.

Sorry, I really forget the N_VOLTAGES.
>
> I'm fifty-fifty about the change because I don't see any benefit with converting to linear range (even though in theory it's correct).
> The voltage of all entries in the second linear range is the *same* as the latest selector of the first linear range.
> When the regulator core to choose the best selector, it will always select the latest selector of the first linear range if it meets the requested range anyway.
> (Because the entries in the second linear range are not *better*, it's just the same.)
>
> If the initial version is this driver is using linear range then it's fine.
> But given the initial version is using linear so when I fix the n_voltages setting I decide to not change it to linear range.
> This makes it easier to fix older versions if necessary.
> (I'm not sure if linear range is available in some old kernel versions, the initial version of this driver was committed in 2014).
>
>
From the regulator register in probe, it will get the current voltage
from the IC.
If the vout sel is not is over N_VOLTAGES, it will return the error number.

But as I think it's the side effect to change the vout step num.
To use the linear range is just to guarantee all vout sel range are included.

That's my initial thoughts.
> Regards,
> Axel
>

  parent reply	other threads:[~2021-07-01  5:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-01  3:54 [PATCH] regulator: rt5033: Use linear ranges to map all voltage selection cy_huang
     [not found] ` <CAFRkauCNf6fP8zAz+0gY_Vzb_wCtVyYqLjw8s1T+t2s=bR0RQw@mail.gmail.com>
2021-07-01  5:53   ` ChiYuan Huang [this message]
2021-07-02 15:47     ` ChiYuan Huang
2021-07-05 16:52       ` Mark Brown
2021-07-06  6:32         ` ChiYuan Huang

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=CADiBU3_dCNvZRwewiztB0UGFvDz3g5sw-q+95sg9akqte1YJsA@mail.gmail.com \
    --to=u0084500@gmail.com \
    --cc=axel.lin@ingics.com \
    --cc=broonie@kernel.org \
    --cc=cy_huang@richtek.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.