Use regulator_set_ramp_delay_regmap instead of open-coded.
Signed-off-by: Axel Lin <[email protected]>
---
drivers/regulator/rt6160-regulator.c | 35 +++++++---------------------
1 file changed, 9 insertions(+), 26 deletions(-)
diff --git a/drivers/regulator/rt6160-regulator.c b/drivers/regulator/rt6160-regulator.c
index 4588ae0748a5..69550284083d 100644
--- a/drivers/regulator/rt6160-regulator.c
+++ b/drivers/regulator/rt6160-regulator.c
@@ -46,6 +46,10 @@ struct rt6160_priv {
bool enable_state;
};
+static const unsigned int rt6160_ramp_tables[] = {
+ 1000, 2500, 5000, 10000
+};
+
static int rt6160_enable(struct regulator_dev *rdev)
{
struct rt6160_priv *priv = rdev_get_drvdata(rdev);
@@ -140,31 +144,6 @@ static int rt6160_set_suspend_voltage(struct regulator_dev *rdev, int uV)
return regmap_update_bits(regmap, reg, RT6160_VSEL_MASK, vsel);
}
-static int rt6160_set_ramp_delay(struct regulator_dev *rdev, int target)
-{
- struct regmap *regmap = rdev_get_regmap(rdev);
- const int ramp_tables[] = { 1000, 2500, 5000, 10000 };
- unsigned int i, sel;
-
- /* Find closest larger or equal */
- for (i = 0; i < ARRAY_SIZE(ramp_tables); i++) {
- sel = i;
-
- /* If ramp delay is equal to 0, directly set ramp speed to fastest */
- if (target == 0) {
- sel = ARRAY_SIZE(ramp_tables) - 1;
- break;
- }
-
- if (target <= ramp_tables[i])
- break;
- }
-
- sel <<= ffs(RT6160_RAMPRATE_MASK) - 1;
-
- return regmap_update_bits(regmap, RT6160_REG_CNTL, RT6160_RAMPRATE_MASK, sel);
-}
-
static int rt6160_get_error_flags(struct regulator_dev *rdev, unsigned int *flags)
{
struct regmap *regmap = rdev_get_regmap(rdev);
@@ -203,7 +182,7 @@ static const struct regulator_ops rt6160_regulator_ops = {
.set_mode = rt6160_set_mode,
.get_mode = rt6160_get_mode,
.set_suspend_voltage = rt6160_set_suspend_voltage,
- .set_ramp_delay = rt6160_set_ramp_delay,
+ .set_ramp_delay = regulator_set_ramp_delay_regmap,
.get_error_flags = rt6160_get_error_flags,
};
@@ -292,6 +271,10 @@ static int rt6160_probe(struct i2c_client *i2c)
priv->desc.vsel_reg = RT6160_REG_VSELH;
priv->desc.vsel_mask = RT6160_VSEL_MASK;
priv->desc.n_voltages = RT6160_N_VOUTS;
+ priv->desc.ramp_reg = RT6160_REG_CNTL;
+ priv->desc.ramp_mask = RT6160_RAMPRATE_MASK;
+ priv->desc.ramp_delay_table = rt6160_ramp_tables;
+ priv->desc.n_ramp_values = ARRAY_SIZE(rt6160_ramp_tables);
priv->desc.of_map_mode = rt6160_of_map_mode;
priv->desc.ops = &rt6160_regulator_ops;
if (priv->vsel_active_low)
--
2.25.1
cy_huang(黃啟原) <[email protected]> 於 2021年6月3日 週四 下午6:20寫道：
>
> Hi, Axel:> Use regulator_set_ramp_delay_regmap instead of open-coded.
> >
> There's some reason.
> You can refer to https://lkml.org/lkml/2021/6/1/1145.
>
> It's because our ramp value order is from small to large, not large to small.
> It conflicts with find_closest_bigger value chosen logic.
I have verified the rt6160_set_ramp_delay() behavior exactly the same as
regulator_set_ramp_delay_regmap. (both functions get the same selector
for a given delay)
Could you check if this patch works?
Thanks,
Axel
Hi, Axel:> Use regulator_set_ramp_delay_regmap instead of open-coded.
>
There's some reason.
You can refer to https://lkml.org/lkml/2021/6/1/1145.
It's because our ramp value order is from small to large, not large to small.
It conflicts with find_closest_bigger value chosen logic.
That's why I need hard-coded for my ramp value selection.
> Signed-off-by: Axel Lin <[email protected]>
> ---
> drivers/regulator/rt6160-regulator.c | 35 +++++++---------------------
> 1 file changed, 9 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/regulator/rt6160-regulator.c b/drivers/regulator/rt6160-
> regulator.c
> index 4588ae0748a5..69550284083d 100644
> --- a/drivers/regulator/rt6160-regulator.c
> +++ b/drivers/regulator/rt6160-regulator.c
> @@ -46,6 +46,10 @@ struct rt6160_priv {
> bool enable_state;
> };
>
> +static const unsigned int rt6160_ramp_tables[] = {
> +1000, 2500, 5000, 10000
> +};
> +
> static int rt6160_enable(struct regulator_dev *rdev)
> {
> struct rt6160_priv *priv = rdev_get_drvdata(rdev);
> @@ -140,31 +144,6 @@ static int rt6160_set_suspend_voltage(struct
> regulator_dev *rdev, int uV)
> return regmap_update_bits(regmap, reg, RT6160_VSEL_MASK, vsel);
> }
>
> -static int rt6160_set_ramp_delay(struct regulator_dev *rdev, int target)
> -{
> -struct regmap *regmap = rdev_get_regmap(rdev);
> -const int ramp_tables[] = { 1000, 2500, 5000, 10000 };
> -unsigned int i, sel;
> -
> -/* Find closest larger or equal */
> -for (i = 0; i < ARRAY_SIZE(ramp_tables); i++) {
> -sel = i;
> -
> -/* If ramp delay is equal to 0, directly set ramp speed to
> fastest */
> -if (target == 0) {
> -sel = ARRAY_SIZE(ramp_tables) - 1;
> -break;
> -}
> -
> -if (target <= ramp_tables[i])
> -break;
> -}
> -
> -sel <<= ffs(RT6160_RAMPRATE_MASK) - 1;
> -
> -return regmap_update_bits(regmap, RT6160_REG_CNTL,
> RT6160_RAMPRATE_MASK, sel);
> -}
> -
> static int rt6160_get_error_flags(struct regulator_dev *rdev, unsigned int
> *flags)
> {
> struct regmap *regmap = rdev_get_regmap(rdev);
> @@ -203,7 +182,7 @@ static const struct regulator_ops rt6160_regulator_ops = {
> .set_mode = rt6160_set_mode,
> .get_mode = rt6160_get_mode,
> .set_suspend_voltage = rt6160_set_suspend_voltage,
> -.set_ramp_delay = rt6160_set_ramp_delay,
> +.set_ramp_delay = regulator_set_ramp_delay_regmap,
> .get_error_flags = rt6160_get_error_flags,
> };
>
> @@ -292,6 +271,10 @@ static int rt6160_probe(struct i2c_client *i2c)
> priv->desc.vsel_reg = RT6160_REG_VSELH;
> priv->desc.vsel_mask = RT6160_VSEL_MASK;
> priv->desc.n_voltages = RT6160_N_VOUTS;
> +priv->desc.ramp_reg = RT6160_REG_CNTL;
> +priv->desc.ramp_mask = RT6160_RAMPRATE_MASK;
> +priv->desc.ramp_delay_table = rt6160_ramp_tables;
> +priv->desc.n_ramp_values = ARRAY_SIZE(rt6160_ramp_tables);
> priv->desc.of_map_mode = rt6160_of_map_mode;
> priv->desc.ops = &rt6160_regulator_ops;
> if (priv->vsel_active_low)
************* Email Confidentiality Notice ********************
The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you!
> cy_huang(黃啟原) <[email protected]> 於 2021年6月3日 週四 下午6:20寫道：
> >
> >
> > Hi, Axel:> Use regulator_set_ramp_delay_regmap instead of open-coded.
> > >
> > >
> > There's some reason.
> > You can refer to https://lkml.org/lkml/2021/6/1/1145.
> >
> > It's because our ramp value order is from small to large, not large to
> > small.
> > It conflicts with find_closest_bigger value chosen logic.
> I have verified the rt6160_set_ramp_delay() behavior exactly the same as
> regulator_set_ramp_delay_regmap. (both functions get the same selector
> for a given delay)
>
> Could you check if this patch works?
Sure.
>
> Thanks,
> Axel
************* Email Confidentiality Notice ********************
The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you!
cy_huang(黃啟原) <[email protected]> 於 2021年6月3日 週四 下午6:41寫道：
>
> > cy_huang(黃啟原) <[email protected]> 於 2021年6月3日 週四 下午6:20寫道：
> > >
> > >
> > > Hi, Axel:> Use regulator_set_ramp_delay_regmap instead of open-coded.
> > > >
> > > >
> > > There's some reason.
> > > You can refer to https://lkml.org/lkml/2021/6/1/1145.
> > >
> > > It's because our ramp value order is from small to large, not large to
> > > small.
> > > It conflicts with find_closest_bigger value chosen logic.
> > I have verified the rt6160_set_ramp_delay() behavior exactly the same as
> > regulator_set_ramp_delay_regmap. (both functions get the same selector
> > for a given delay)
> >
> > Could you check if this patch works?
> Sure.
The find_closest_bigger() does not rely on ascending or descending
table entries.
Regards,
Axel
Hi,> >
> > cy_huang(黃啟原) <[email protected]> 於 2021年6月3日 週四 下午6:20寫道：
> > >
> > >
> > >
> > > Hi, Axel:> Use regulator_set_ramp_delay_regmap instead of open-coded.
> > > >
> > > >
> > > >
> > > There's some reason.
> > > You can refer to https://lkml.org/lkml/2021/6/1/1145.
> > >
> > > It's because our ramp value order is from small to large, not large to
> > > small.
> > > It conflicts with find_closest_bigger value chosen logic.
> > I have verified the rt6160_set_ramp_delay() behavior exactly the same as
> > regulator_set_ramp_delay_regmap. (both functions get the same selector
> > for a given delay)
> >
> > Could you check if this patch works?
> Sure.
After my test sample code, below's the result.
ascending [1000 2500 5000 10000]
target = 1000 =>sel = 0
target = 2500 =>sel = 1
target = 5000 =>sel = 2
target = 10000 =>sel = 3
target = 1700 =>sel = 1
target = 2750 =>sel = 2
target = 7500 =>sel = 3
target = 15000 =>failed to find best select, sel = 3
target = 0 =>sel = 0
descending [10000 5000 2500 1000]
target = 1000 =>sel = 3
target = 2500 =>sel = 2
target = 5000 =>sel = 1
target = 10000 =>sel = 0
target = 1700 =>sel = 2
target = 2750 =>sel = 1
target = 7500 =>sel = 0
target = 15000 =>failed to find best select, sel = 0
target = 0 =>sel = 3
It means when target is in range or even over, the result are all correct.
But like as the ramp target is equal to 0, the selection will only choose the minimum one.
When the ramp target is equal to 0, it means the user want to disable the rammpping function.
As I know, if target is equal to 0, it must find the fastest rampping value as the best selection.
> >
> >
> > Thanks,
> > Axel
************* Email Confidentiality Notice ********************
The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you!
cy_huang(黃啟原) <[email protected]> 於 2021年6月3日 週四 下午11:18寫道：
>
> Hi,> >
> > > cy_huang(黃啟原) <[email protected]> 於 2021年6月3日 週四 下午6:20寫道：
> > > >
> > > >
> > > >
> > > > Hi, Axel:> Use regulator_set_ramp_delay_regmap instead of open-coded.
> > > > >
> > > > >
> > > > >
> > > > There's some reason.
> > > > You can refer to https://lkml.org/lkml/2021/6/1/1145.
> > > >
> > > > It's because our ramp value order is from small to large, not large to
> > > > small.
> > > > It conflicts with find_closest_bigger value chosen logic.
> > > I have verified the rt6160_set_ramp_delay() behavior exactly the same as
> > > regulator_set_ramp_delay_regmap. (both functions get the same selector
> > > for a given delay)
> > >
> > > Could you check if this patch works?
> > Sure.
> After my test sample code, below's the result.
> ascending [1000 2500 5000 10000]
> target = 1000 =>sel = 0
> target = 2500 =>sel = 1
> target = 5000 =>sel = 2
> target = 10000 =>sel = 3
> target = 1700 =>sel = 1
> target = 2750 =>sel = 2
> target = 7500 =>sel = 3
> target = 15000 =>failed to find best select, sel = 3
> target = 0 =>sel = 0
> descending [10000 5000 2500 1000]
> target = 1000 =>sel = 3
> target = 2500 =>sel = 2
> target = 5000 =>sel = 1
> target = 10000 =>sel = 0
> target = 1700 =>sel = 2
> target = 2750 =>sel = 1
> target = 7500 =>sel = 0
> target = 15000 =>failed to find best select, sel = 0
> target = 0 =>sel = 3
>
>
> It means when target is in range or even over, the result are all correct.
> But like as the ramp target is equal to 0, the selection will only choose the minimum one.
> When the ramp target is equal to 0, it means the user want to disable the rammpping function.
>
> As I know, if target is equal to 0, it must find the fastest rampping value as the best selection.
If your table is [1000 2500 5000 10000], find_closest_bigger() will
choose sel=0 when ramp_delay=0.
If your table is [10000 5000 2500 1000], find_closest_bigger() will
choose sel=3 when ramp_delay=0.
i.e. In both cases, find_closest_bigger() chooses the fastest ramping value.
This meets your exception.
Actually, even if your table is [10000, 1000, 5000, 2500],
find_closest_bigger() still can choose the correct selector.
i.e. sel=1 when ramp_delay=0 in this case.
Regards,
Axel
cy_huang(黃啟原) <[email protected]> 於 2021年6月4日 週五 上午10:26寫道：
>
>
>
> cy_huang(黃啟原) <[email protected]> 於 2021年6月3日 週四 下午11:18寫道：
>
>
> Hi,> >
>
>
> cy_huang(黃啟原) <[email protected]> 於 2021年6月3日 週四 下午6:20寫道：
>
>
>
>
> Hi, Axel:> Use regulator_set_ramp_delay_regmap instead of open-coded.
>
>
>
>
>
> There's some reason.
> You can refer to https://lkml.org/lkml/2021/6/1/1145.
>
> It's because our ramp value order is from small to large, not large to
> small.
> It conflicts with find_closest_bigger value chosen logic.
>
> I have verified the rt6160_set_ramp_delay() behavior exactly the same as
> regulator_set_ramp_delay_regmap. (both functions get the same selector
> for a given delay)
>
> Could you check if this patch works?
>
> Sure.
>
> After my test sample code, below's the result.
> ascending [1000 2500 5000 10000]
> target = 1000 =>sel = 0
> target = 2500 =>sel = 1
> target = 5000 =>sel = 2
> target = 10000 =>sel = 3
> target = 1700 =>sel = 1
> target = 2750 =>sel = 2
> target = 7500 =>sel = 3
> target = 15000 =>failed to find best select, sel = 3
> target = 0 =>sel = 0
> descending [10000 5000 2500 1000]
> target = 1000 =>sel = 3
> target = 2500 =>sel = 2
> target = 5000 =>sel = 1
> target = 10000 =>sel = 0
> target = 1700 =>sel = 2
> target = 2750 =>sel = 1
> target = 7500 =>sel = 0
> target = 15000 =>failed to find best select, sel = 0
> target = 0 =>sel = 3
>
>
> It means when target is in range or even over, the result are all correct.
> But like as the ramp target is equal to 0, the selection will only choose the minimum one.
> When the ramp target is equal to 0, it means the user want to disable the rammpping function.
>
> As I know, if target is equal to 0, it must find the fastest rampping value as the best selection.
>
>
> If your table is [1000 2500 5000 10000], find_closest_bigger() will
> choose sel=0 when ramp_delay=0.
> If your table is [10000 5000 2500 1000], find_closest_bigger() will
> choose sel=3 when ramp_delay=0.
> i.e. In both cases, find_closest_bigger() chooses the fastest ramping value.
>
> This meets your exception.
>
> Actually, even if your table is [10000, 1000, 5000, 2500],
> find_closest_bigger() still can choose the correct selector.
> i.e. sel=1 when ramp_delay=0 in this case.
>
> This selection may be wrong.
> ramp_delay=0 means ramp disabled,
> If chip not support rampping disable, this selection must be configured as fastest rampping value, not the minimum one.
0 does not mean ramp disable.
It could be explicitly set to zero or its unintialized (zero by default).
see
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/regulator/core.c?id=1653ccf4c52df6a4abe8ec2f33f2cb2896d129ea
cy_huang(黃啟原) <[email protected]> 於 2021年6月4日 週五 下午1:48寫道：
>
>
>
> 於 五，2021-06-04 於 11:30 +0800，Axel Lin 提到：
>
> cy_huang(黃啟原) <[email protected]> 於 2021年6月4日 週五 上午10:26寫道：
>
>
>
>
> cy_huang(黃啟原) <[email protected]> 於 2021年6月3日 週四 下午11:18寫道：
>
>
> Hi,> >
>
>
> cy_huang(黃啟原) <[email protected]> 於 2021年6月3日 週四 下午6:20寫道：
>
>
>
>
> Hi, Axel:> Use regulator_set_ramp_delay_regmap instead of open-coded.
>
>
>
>
>
> There's some reason.
> You can refer to https://lkml.org/lkml/2021/6/1/1145.
>
> It's because our ramp value order is from small to large, not large to
> small.
> It conflicts with find_closest_bigger value chosen logic.
>
> I have verified the rt6160_set_ramp_delay() behavior exactly the same as
> regulator_set_ramp_delay_regmap. (both functions get the same selector
> for a given delay)
>
> Could you check if this patch works?
>
> Sure.
>
> After my test sample code, below's the result.
> ascending [1000 2500 5000 10000]
> target = 1000 =>sel = 0
> target = 2500 =>sel = 1
> target = 5000 =>sel = 2
> target = 10000 =>sel = 3
> target = 1700 =>sel = 1
> target = 2750 =>sel = 2
> target = 7500 =>sel = 3
> target = 15000 =>failed to find best select, sel = 3
> target = 0 =>sel = 0
> descending [10000 5000 2500 1000]
> target = 1000 =>sel = 3
> target = 2500 =>sel = 2
> target = 5000 =>sel = 1
> target = 10000 =>sel = 0
> target = 1700 =>sel = 2
> target = 2750 =>sel = 1
> target = 7500 =>sel = 0
> target = 15000 =>failed to find best select, sel = 0
> target = 0 =>sel = 3
>
>
> It means when target is in range or even over, the result are all correct.
> But like as the ramp target is equal to 0, the selection will only choose the minimum one.
> When the ramp target is equal to 0, it means the user want to disable the rammpping function.
>
> As I know, if target is equal to 0, it must find the fastest rampping value as the best selection.
>
>
> If your table is [1000 2500 5000 10000], find_closest_bigger() will
> choose sel=0 when ramp_delay=0.
> If your table is [10000 5000 2500 1000], find_closest_bigger() will
> choose sel=3 when ramp_delay=0.
> i.e. In both cases, find_closest_bigger() chooses the fastest ramping value.
>
> This meets your exception.
>
> Actually, even if your table is [10000, 1000, 5000, 2500],
> find_closest_bigger() still can choose the correct selector.
> i.e. sel=1 when ramp_delay=0 in this case.
>
> This selection may be wrong.
> ramp_delay=0 means ramp disabled,
> If chip not support rampping disable, this selection must be configured as fastest rampping value, not the minimum one.
>
>
> 0 does not mean ramp disable.
> It could be explicitly set to zero or its unintialized (zero by default).
> see
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/regulator/core.c?id=1653ccf4c52df6a4abe8ec2f33f2cb2896d129ea
>
> How about 'ramp_disable' falg is true?
My understanding is:
If the h/w does not support disabling ramp_delay, the regulator core
won't call ops->set_ramp_delay when ramp_delay=0.
If the h/w supports disabling ramp, i.e. ramp_disable flag is true,
the regulator core will
call ops->set_ramp_delay with ramp_delay=0. in this case, it should
have an exactly match and
write the register to disable ramp_delay.
於 三，2021-06-09 於 11:32 +0800，Axel Lin 提到：
> cy_huang(黃啟原) <[email protected]> 於 2021年6月4日 週五 下午2:29寫道：
> >
> >
> >
> > 於 五，2021-06-04 於 13:59 +0800，Axel Lin 提到：
> >
> > cy_huang(黃啟原) <[email protected]> 於 2021年6月4日 週五 下午1:48寫道：
> >
> >
> >
> >
> > 於 五，2021-06-04 於 11:30 +0800，Axel Lin 提到：
> >
> > cy_huang(黃啟原) <[email protected]> 於 2021年6月4日 週五 上午10:26寫道：
> >
> >
> >
> >
> > cy_huang(黃啟原) <[email protected]> 於 2021年6月3日 週四 下午11:18寫道：
> >
> >
> > Hi,> >
> >
> >
> > cy_huang(黃啟原) <[email protected]> 於 2021年6月3日 週四 下午6:20寫道：
> >
> >
> >
> >
> > Hi, Axel:> Use regulator_set_ramp_delay_regmap instead of open-coded.
> >
> >
> >
> >
> >
> > There's some reason.
> > You can refer to https://lkml.org/lkml/2021/6/1/1145.
> >
> > It's because our ramp value order is from small to large, not large to
> > small.
> > It conflicts with find_closest_bigger value chosen logic.
> >
> > I have verified the rt6160_set_ramp_delay() behavior exactly the same as
> > regulator_set_ramp_delay_regmap. (both functions get the same selector
> > for a given delay)
> >
> > Could you check if this patch works?
> >
> > Sure.
> >
> > After my test sample code, below's the result.
> > ascending [1000 2500 5000 10000]
> > target = 1000 =>sel = 0
> > target = 2500 =>sel = 1
> > target = 5000 =>sel = 2
> > target = 10000 =>sel = 3
> > target = 1700 =>sel = 1
> > target = 2750 =>sel = 2
> > target = 7500 =>sel = 3
> > target = 15000 =>failed to find best select, sel = 3
> > target = 0 =>sel = 0
> > descending [10000 5000 2500 1000]
> > target = 1000 =>sel = 3
> > target = 2500 =>sel = 2
> > target = 5000 =>sel = 1
> > target = 10000 =>sel = 0
> > target = 1700 =>sel = 2
> > target = 2750 =>sel = 1
> > target = 7500 =>sel = 0
> > target = 15000 =>failed to find best select, sel = 0
> > target = 0 =>sel = 3
> >
> >
> > It means when target is in range or even over, the result are all correct.
> > But like as the ramp target is equal to 0, the selection will only choose the minimum one.
> > When the ramp target is equal to 0, it means the user want to disable the rammpping function.
> >
> > As I know, if target is equal to 0, it must find the fastest rampping value as the best selection.
> >
> >
> > If your table is [1000 2500 5000 10000], find_closest_bigger() will
> > choose sel=0 when ramp_delay=0.
> > If your table is [10000 5000 2500 1000], find_closest_bigger() will
> > choose sel=3 when ramp_delay=0.
> > i.e. In both cases, find_closest_bigger() chooses the fastest ramping value.
> >
> > This meets your exception.
> >
> > Actually, even if your table is [10000, 1000, 5000, 2500],
> > find_closest_bigger() still can choose the correct selector.
> > i.e. sel=1 when ramp_delay=0 in this case.
> >
> > This selection may be wrong.
> > ramp_delay=0 means ramp disabled,
> > If chip not support rampping disable, this selection must be configured as fastest rampping value, not the minimum
> > one.
> >
> >
> > 0 does not mean ramp disable.
> > It could be explicitly set to zero or its unintialized (zero by default).
> > see
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/regulator/core.c?id=1653ccf4c52df6
> > a4abe8ec2f33f2cb2896d129ea
> >
> > How about 'ramp_disable' falg is true?
> >
> >
> > My understanding is:
> > If the h/w does not support disabling ramp_delay, the regulator core
> > won't call ops->set_ramp_delay when ramp_delay=0.
> > If the h/w supports disabling ramp, i.e. ramp_disable flag is true,
> > the regulator core will
> > call ops->set_ramp_delay with ramp_delay=0. in this case, it should
> > have an exactly match and
> > write the register to disable ramp_delay.
> >
> >
> > If this can be guaranteed , to use the set_ramp_delay_regmap helper function would be better.
> Hi ChiYuan,
> Can you add Reviewed-by or Acked-by if this patch works.
Sure, already tested.
Reviewed-by: ChiYuan Huang <[email protected]>
>
> Regards,
> Axel
************* Email Confidentiality Notice ********************
The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you!
cy_huang(黃啟原) <[email protected]> 於 2021年6月4日 週五 下午2:29寫道：
>
>
> 於 五，2021-06-04 於 13:59 +0800，Axel Lin 提到：
>
> cy_huang(黃啟原) <[email protected]> 於 2021年6月4日 週五 下午1:48寫道：
>
>
>
>
> 於 五，2021-06-04 於 11:30 +0800，Axel Lin 提到：
>
> cy_huang(黃啟原) <[email protected]> 於 2021年6月4日 週五 上午10:26寫道：
>
>
>
>
> cy_huang(黃啟原) <[email protected]> 於 2021年6月3日 週四 下午11:18寫道：
>
>
> Hi,> >
>
>
> cy_huang(黃啟原) <[email protected]> 於 2021年6月3日 週四 下午6:20寫道：
>
>
>
>
> Hi, Axel:> Use regulator_set_ramp_delay_regmap instead of open-coded.
>
>
>
>
>
> There's some reason.
> You can refer to https://lkml.org/lkml/2021/6/1/1145.
>
> It's because our ramp value order is from small to large, not large to
> small.
> It conflicts with find_closest_bigger value chosen logic.
>
> I have verified the rt6160_set_ramp_delay() behavior exactly the same as
> regulator_set_ramp_delay_regmap. (both functions get the same selector
> for a given delay)
>
> Could you check if this patch works?
>
> Sure.
>
> After my test sample code, below's the result.
> ascending [1000 2500 5000 10000]
> target = 1000 =>sel = 0
> target = 2500 =>sel = 1
> target = 5000 =>sel = 2
> target = 10000 =>sel = 3
> target = 1700 =>sel = 1
> target = 2750 =>sel = 2
> target = 7500 =>sel = 3
> target = 15000 =>failed to find best select, sel = 3
> target = 0 =>sel = 0
> descending [10000 5000 2500 1000]
> target = 1000 =>sel = 3
> target = 2500 =>sel = 2
> target = 5000 =>sel = 1
> target = 10000 =>sel = 0
> target = 1700 =>sel = 2
> target = 2750 =>sel = 1
> target = 7500 =>sel = 0
> target = 15000 =>failed to find best select, sel = 0
> target = 0 =>sel = 3
>
>
> It means when target is in range or even over, the result are all correct.
> But like as the ramp target is equal to 0, the selection will only choose the minimum one.
> When the ramp target is equal to 0, it means the user want to disable the rammpping function.
>
> As I know, if target is equal to 0, it must find the fastest rampping value as the best selection.
>
>
> If your table is [1000 2500 5000 10000], find_closest_bigger() will
> choose sel=0 when ramp_delay=0.
> If your table is [10000 5000 2500 1000], find_closest_bigger() will
> choose sel=3 when ramp_delay=0.
> i.e. In both cases, find_closest_bigger() chooses the fastest ramping value.
>
> This meets your exception.
>
> Actually, even if your table is [10000, 1000, 5000, 2500],
> find_closest_bigger() still can choose the correct selector.
> i.e. sel=1 when ramp_delay=0 in this case.
>
> This selection may be wrong.
> ramp_delay=0 means ramp disabled,
> If chip not support rampping disable, this selection must be configured as fastest rampping value, not the minimum one.
>
>
> 0 does not mean ramp disable.
> It could be explicitly set to zero or its unintialized (zero by default).
> see
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/regulator/core.c?id=1653ccf4c52df6a4abe8ec2f33f2cb2896d129ea
>
> How about 'ramp_disable' falg is true?
>
>
> My understanding is:
> If the h/w does not support disabling ramp_delay, the regulator core
> won't call ops->set_ramp_delay when ramp_delay=0.
> If the h/w supports disabling ramp, i.e. ramp_disable flag is true,
> the regulator core will
> call ops->set_ramp_delay with ramp_delay=0. in this case, it should
> have an exactly match and
> write the register to disable ramp_delay.
>
>
> If this can be guaranteed , to use the set_ramp_delay_regmap helper function would be better.
Hi ChiYuan,
Can you add Reviewed-by or Acked-by if this patch works.
Regards,
Axel
On Thu, 3 Jun 2021 17:38:09 +0800, Axel Lin wrote:
> Use regulator_set_ramp_delay_regmap instead of open-coded.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[1/1] regulator: rt6160: Convert to use regulator_set_ramp_delay_regmap
commit: b113ec2d8562f5f3e0359c547cba53686ee805e9
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark