Re: [PATCH] regulator: rt6160: Convert to use regulator_set_ramp_delay_regmap

[Axel Lin <axel.lin@ingics.com>]

cy_huang(黃啟原) <cy_huang@richtek.com> 於 2021年6月3日 週四 下午11:18寫道：
>
> Hi,> >
> > > cy_huang(黃啟原) <cy_huang@richtek.com> 於 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