Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210603093809.1108629-1-axel.lin@ingics.com> <1622715641.1034.5.camel@richtek.com>
 <CAFRkauDs6nyuboPBf9Q-=KDFkSjwQ4z9mDjzm3o95uzdu5bKCw@mail.gmail.com>
 <1622716902.1034.15.camel@richtek.com> <1622733524.3635.10.camel@richtek.com>
 <CAFRkauCKoipBe4-QacQbjZgWuFrMPKdAfWB00Q6Lyw7xJ=6sfQ@mail.gmail.com>
 <1622773474.9011.14.camel@richtek.com> <CAFRkauCdRoChK-djEi+TzC4As5JzykPF=fb1YmDukEjWJG0K_g@mail.gmail.com>
 <1622785727.9011.17.camel@richtek.com>
In-Reply-To: <1622785727.9011.17.camel@richtek.com>
From:   Axel Lin <axel.lin@ingics.com>
Date:   Fri, 4 Jun 2021 13:59:07 +0800
Message-ID: <CAFRkauAFVdxHcKkNzAW3uHhADwb2G-sdiLBUoZj+eOAXEV4rfA@mail.gmail.com>
Subject: Re: [PATCH] regulator: rt6160: Convert to use regulator_set_ramp_delay_regmap
To:     =?UTF-8?B?Y3lfaHVhbmco6buD5ZWf5Y6fKQ==?= <cy_huang@richtek.com>
Cc:     "lgirdwood@gmail.com" <lgirdwood@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "u0084500@gmail.com" <u0084500@gmail.com>,
        "broonie@kernel.org" <broonie@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

cy_huang(=E9=BB=83=E5=95=9F=E5=8E=9F) <cy_huang@richtek.com> =E6=96=BC 2021=
=E5=B9=B46=E6=9C=884=E6=97=A5 =E9=80=B1=E4=BA=94 =E4=B8=8B=E5=8D=881:48=E5=
=AF=AB=E9=81=93=EF=BC=9A
>
>
>
> =E6=96=BC =E4=BA=94=EF=BC=8C2021-06-04 =E6=96=BC 11:30 +0800=EF=BC=8CAxel=
 Lin =E6=8F=90=E5=88=B0=EF=BC=9A
>
> cy_huang(=E9=BB=83=E5=95=9F=E5=8E=9F) <cy_huang@richtek.com> =E6=96=BC 20=
21=E5=B9=B46=E6=9C=884=E6=97=A5 =E9=80=B1=E4=BA=94 =E4=B8=8A=E5=8D=8810:26=
=E5=AF=AB=E9=81=93=EF=BC=9A
>
>
>
>
> cy_huang(=E9=BB=83=E5=95=9F=E5=8E=9F) <cy_huang@richtek.com> =E6=96=BC 20=
21=E5=B9=B46=E6=9C=883=E6=97=A5 =E9=80=B1=E5=9B=9B =E4=B8=8B=E5=8D=8811:18=
=E5=AF=AB=E9=81=93=EF=BC=9A
>
>
> Hi,> >
>
>
> cy_huang(=E9=BB=83=E5=95=9F=E5=8E=9F) <cy_huang@richtek.com> =E6=96=BC 20=
21=E5=B9=B46=E6=9C=883=E6=97=A5 =E9=80=B1=E5=9B=9B =E4=B8=8B=E5=8D=886:20=
=E5=AF=AB=E9=81=93=EF=BC=9A
>
>
>
>
> 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 =3D  1000 =3D>sel =3D 0
> target =3D  2500 =3D>sel =3D 1
> target =3D  5000 =3D>sel =3D 2
> target =3D 10000 =3D>sel =3D 3
> target =3D  1700 =3D>sel =3D 1
> target =3D  2750 =3D>sel =3D 2
> target =3D  7500 =3D>sel =3D 3
> target =3D 15000 =3D>failed to find best select, sel =3D 3
> target =3D     0 =3D>sel =3D 0
> descending [10000 5000 2500 1000]
> target =3D  1000 =3D>sel =3D 3
> target =3D  2500 =3D>sel =3D 2
> target =3D  5000 =3D>sel =3D 1
> target =3D 10000 =3D>sel =3D 0
> target =3D  1700 =3D>sel =3D 2
> target =3D  2750 =3D>sel =3D 1
> target =3D  7500 =3D>sel =3D 0
> target =3D 15000 =3D>failed to find best select, sel =3D 0
> target =3D     0 =3D>sel =3D 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 val=
ue as the best selection.
>
>
> If your table is [1000 2500 5000 10000], find_closest_bigger() will
> choose sel=3D0 when ramp_delay=3D0.
> If your table is [10000 5000 2500 1000], find_closest_bigger() will
> choose sel=3D3 when ramp_delay=3D0.
> i.e. In both cases, find_closest_bigger() chooses the fastest ramping val=
ue.
>
> 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=3D1 when ramp_delay=3D0 in this case.
>
> This selection may be wrong.
> ramp_delay=3D0 means ramp disabled,
> If chip not support rampping disable, this selection must be configured a=
s 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=3D1653ccf4c52df6a4abe8ec2f33f2cb2896d129ea
>
> 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=3D0.
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=3D0. in this case, it should
have an exactly match and
write the register to disable ramp_delay.