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

[Svyatoslav Ryhel]

31 жовтня 2023 р. 07:11:02 GMT+02:00, Jaehoon Chung <jh80.chung at samsung.com> написав(-ла):
>Hi,
>
>If will resend this patch according Simon's comment, I will check again.
>
>Best Regards,
>Jaehoon Chung
>
It will not be updated since it was split into 2 different bigger patchsets one of which was dropped as well. You have missed a 3 or 4 month of discussion.

>> -----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
>
>