[PATCH v2 2/2] power: pmic: fix regulators behaviour

[Jaehoon Chung]

Hi,

If will resend this patch according Simon's comment, I will check again.

Best Regards,
Jaehoon Chung

> -----Original Message-----
> From: Simon Glass <sjg at chromium.org>
> Sent: Wednesday, July 19, 2023 10:08 AM
> To: Svyatoslav Ryhel <clamor95 at gmail.com>
> Cc: Jaehoon Chung <jh80.chung at samsung.com>; Patrick Delaunay <patrick.delaunay at foss.st.com>; u-
> boot at lists.denx.de
> Subject: Re: [PATCH v2 2/2] power: pmic: fix regulators behaviour
> 
> Hi Svyatoslav,
> 
> On Sun, 16 Jul 2023 at 07:20, Svyatoslav Ryhel <clamor95 at gmail.com> wrote:
> >
> >
> >
> > 16 липня 2023 р. 16:08:10 GMT+03:00, Simon Glass <sjg at chromium.org> написав(-ла):
> > >Hi Svyatoslav,
> > >
> > >On Sat, 15 Jul 2023 at 22:08, Svyatoslav Ryhel <clamor95 at gmail.com> wrote:
> > >>
> > >>
> > >>
> > >> 16 липня 2023 р. 02:40:37 GMT+03:00, Simon Glass <sjg at chromium.org> написав(-ла):
> > >> >Hi Svyatoslav,
> > >> >
> > >> >On Sat, 15 Jul 2023 at 12:34, Svyatoslav Ryhel <clamor95 at gmail.com> wrote:
> > >> >>
> > >> >> Currently device tree entries of regulators are completely
> > >> >> ignored and regulators are probed only if they are called
> > >> >> by the device which uses it. This results into two issues:
> > >> >> regulators which must run under boot-on or always-on mode
> > >> >> are ignored and not enabled; dts props like voltage are
> > >> >> not applied to the regulator so the regulator may be enabled
> > >> >> with random actual voltage, which may have unexpected
> > >> >> consequences.
> > >> >>
> > >> >> This patch changes this behavior. Post-probe function is
> > >> >> introduced which performs probing of each pmics child and if
> > >> >> it is a regulator, regulator_autoset function is called, which
> > >> >> handles always-on and boot-on regulators, but if none of those
> > >> >> props are set, the regulator is disabled.
> > >> >>
> > >> >> Later disabled regulators can be re-enabled by devices which
> > >> >> use them without issues.
> > >> >>
> > >> >> Signed-off-by: Svyatoslav Ryhel <clamor95 at gmail.com>
> > >> >> ---
> > >> >>  drivers/power/pmic/pmic-uclass.c | 18 ++++++++++++++++++
> > >> >>  1 file changed, 18 insertions(+)
> > >> >
> > >> >Can you add a test for this to test/dm/pmic.c ?
> > >> >
> > >>
> > >> Sure, may you specify what I should add to tests/dm/pmic.c? Which behavior is needed?
> > >
> > >Just for the change you are making...you should be able to check that
> > >it sets the regulators if you make sure there are some autoset ones in
> > >sandbox.
> >
> > Easier to tell then to do. I am basically interfering into device establishment process. If smth
> goes wrong, any regulator related test should fail. At least my devices refused to boot/gave
> unexpected behavior while developing. I will look if I can find anything meaningful.
> 
> Something like this in test/dm/regulator.c:
> 
> struct udevice *pmic, *reg;
> 
> // This should automatically probe the
> ut_asserok(pmic_get("pmic at 41"), &pmic);
> 
> // Check that the regulators are probed and on
> ut_assertok(regulator_get_by_devname("ldo2", &reg));
> ut_assert(regulator_get_enable(reg));
> 
> See test.dtsi and sandbox_pmic.dtsi for the DT nodes. You'll need to
> update ldo2 t too add the properties to cause an autoset.
> 
> Regards,
> Simon