Patch "regulator: core: Shorten off-on-delay-us for always-on/boot-on by time since booted" has been added to the 6.3-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    regulator: core: Shorten off-on-delay-us for always-on/boot-on by time since booted

to the 6.3-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     regulator-core-shorten-off-on-delay-us-for-always-on.patch
and it can be found in the queue-6.3 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 0d5d373c3d1b57da7704c8d8956ed16a6f661459
Author: Douglas Anderson <dianders@xxxxxxxxxxxx>
Date:   Mon Mar 13 11:18:19 2023 -0700

    regulator: core: Shorten off-on-delay-us for always-on/boot-on by time since booted
    
    [ Upstream commit 691c1fcda5351ed98a44610b7dccc0e3ee920020 ]
    
    This is very close to a straight revert of commit 218320fec294
    ("regulator: core: Fix off-on-delay-us for always-on/boot-on
    regulators"). We've identified that patch as causing a boot speed
    regression on sc7180-trogdor boards. While boot speed certainly isn't
    more important than making sure that power sequencing is correct,
    looking closely at the original change it doesn't seem to have been
    fully justified. It mentions "cycling issues" without describing
    exactly what the issues were. That means it's possible that the
    cycling issues were really a problem that should be fixed in a
    different way.
    
    Let's take a careful look at how we should handle regulators that have
    an off-on-delay and that are boot-on or always-on. Linux currently
    doesn't have any way to identify whether a GPIO regulator was already
    on when the kernel booted. That means that when the kernel boots we
    probe a regulator, see that it wants boot-on / always-on we, and then
    turn the regulator on. We could be in one of two cases when we do
    this:
    
    a) The regulator might have been left on by the bootloader and we're
       ensuring that it stays on.
    b) The regulator might have been left off by the bootloader and we're
       just now turning it on.
    
    For case a) we definitely don't need any sort of delay. For case b) we
    _might_ need some delay in case the bootloader turned the regulator
    off _right_ before booting the kernel. To get the proper delay for
    case b) then we can just assume a `last_off` of 0, which is what it
    gets initialized to by default.
    
    As per above, we can't tell whether we're in case a) or case b) so
    we'll assume the longer delay (case b). This basically puts the code
    to how it was before commit 218320fec294 ("regulator: core: Fix
    off-on-delay-us for always-on/boot-on regulators"). However, we add
    one important change: we make sure that the delay is actually honored
    if `last_off` is 0. Though the original "cycling issues" cited were
    vague, I'm hopeful that this important extra change will be enough to
    fix the issues that the initial commit mentioned.
    
    With this fix, I've confined that on a sc7180-trogdor board the delay
    at boot goes down from 500 ms to ~250 ms. That's not as good as the 0
    ms that we had prior to commit 218320fec294 ("regulator: core: Fix
    off-on-delay-us for always-on/boot-on regulators"), but it's probably
    safer because we don't know if the bootloader turned the regulator off
    right before booting.
    
    One note is that it's possible that we could be in a state that's not
    a) or b) if there are other issues in the kernel. The only one I can
    think of is related to pinctrl. If the pinctrl driver being used on a
    board isn't careful about avoiding glitches when setting up a pin then
    it's possible that setting up a pin could cause the regulator to "turn
    off" briefly immediately before the regulator probes. If this is
    indeed causing problems then the pinctrl driver should be fixed,
    perhaps in a similar way to what was done in commit d21f4b7ffc22
    ("pinctrl: qcom: Avoid glitching lines when we first mux to output")
    
    Fixes: 218320fec294 ("regulator: core: Fix off-on-delay-us for always-on/boot-on regulators")
    Cc: Christian Kohlschütter <christian@xxxxxxxxxxxxxxxx>
    Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
    Link: https://lore.kernel.org/r/20230313111806.1.I2eaad872be0932a805c239a7c7a102233fb0b03b@changeid
    Signed-off-by: Mark Brown <broonie@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 4fcd36055b025..1490eb40c973a 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1583,9 +1583,6 @@ static int set_machine_constraints(struct regulator_dev *rdev)
 			rdev->constraints->always_on = true;
 	}
 
-	if (rdev->desc->off_on_delay)
-		rdev->last_off = ktime_get_boottime();
-
 	/* If the constraints say the regulator should be on at this point
 	 * and we have control then make sure it is enabled.
 	 */
@@ -1619,6 +1616,8 @@ static int set_machine_constraints(struct regulator_dev *rdev)
 
 		if (rdev->constraints->always_on)
 			rdev->use_count++;
+	} else if (rdev->desc->off_on_delay) {
+		rdev->last_off = ktime_get();
 	}
 
 	print_constraints(rdev);
@@ -2668,7 +2667,7 @@ static int _regulator_do_enable(struct regulator_dev *rdev)
 
 	trace_regulator_enable(rdev_get_name(rdev));
 
-	if (rdev->desc->off_on_delay && rdev->last_off) {
+	if (rdev->desc->off_on_delay) {
 		/* if needed, keep a distance of off_on_delay from last time
 		 * this regulator was disabled.
 		 */



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux