From: Mark Brown <broonie@kernel.org>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: lgirdwood@gmail.com,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
linux-pwm@vger.kernel.org, linux-amlogic@lists.infradead.org,
linux-kernel@vger.kernel.org,
"Thierry Reding" <thierry.reding@gmail.com>,
"Heiner Kallweit" <hkallweit1@gmail.com>,
"Dmitry Rokosov" <ddrokosov@sberdevices.ru>
Subject: Re: [RFC PATCH v1] regulator: pwm-regulator: Fix continuous get_voltage for disabled PWM
Date: Thu, 21 Dec 2023 21:45:49 +0000 [thread overview]
Message-ID: <0c99b575-5cf2-4bd6-8cfd-af19f5fd58da@sirena.org.uk> (raw)
In-Reply-To: <20231221211222.1380658-1-martin.blumenstingl@googlemail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2631 bytes --]
On Thu, Dec 21, 2023 at 10:12:22PM +0100, Martin Blumenstingl wrote:
> It turns out that at least some bootloader versions are keeping the PWM
> output disabled. This is not a problem due to the specific design of the
> regulator: when the PWM output is disabled the output pin is pulled LOW,
> effectively achieving a 0% duty cycle (which in return means that VDDEE
> voltage is at 1140mV).
Hrm. Perhaps the regulator should figure out that it's on with a
minimum voltage of 1.14V in this case - AIUI that broadly corresponds to
your change except for the fact that it doesn't recognise that there's
actually an output in this case since it assumes that disabling the PWM
disables the output which isn't the case with this hardware. We'd need
to know more about the PWM in that case though I think.
> The problem comes when the pwm-regulator driver tries to initialize the
> PWM output. To do so it reads the current state from the hardware, which
> is:
> period: 3666ns
> duty cycle: 3333ns (= ~91%)
> enabled: false
> Then those values are translated using the continuous voltage range to
> 860mV.
> Later, when the regulator is being enabled (either by the regulator core
> due to the always-on flag or first consumer - in this case the lima
> driver for the Mali-450 GPU) the pwm-regulator driver tries to keep the
> voltage (at 860mV) and just enable the PWM output. This is when things
> start to go wrong as the typical voltage used for VDDEE is 1100mV.
So, the constraints say that the 860mV voltage is within range. Where
does the requirement for 1.1V come from in this situation? Is it just
that lima hasn't started yet and requires the 1.1V for hardware init
(and presumably power on) even if it can use a lower voltage at runtime?
> @@ -157,7 +157,12 @@ static int pwm_regulator_get_voltage(struct regulator_dev *rdev)
> - voltage = pwm_get_relative_duty_cycle(&pstate, duty_unit);
> + if (pstate.enabled)
> + voltage = pwm_get_relative_duty_cycle(&pstate, duty_unit);
> + else if (max_uV_duty < min_uV_duty)
> + voltage = max_uV_duty;
> + else
> + voltage = min_uV_duty;
AFAICT this means that enabling the PWM changes the voltage read back
which isn't what we expect (other than a change from 0 to target) and is
likely to cause issues. get_voltage() should not change after an
enable(), and indeed I'm unclear how this change works? I'd expect a
change in the init_state() function, possibly one that programs the PWM
to reflect the actual hardware state but I'm not 100% confident on that
without digging into the PWM API more.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2023-12-21 21:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-21 21:12 Martin Blumenstingl
2023-12-21 21:45 ` Mark Brown [this message]
2023-12-21 22:07 ` Uwe Kleine-König
2023-12-22 11:53 ` Mark Brown
2023-12-21 22:42 ` Martin Blumenstingl
2023-12-22 11:54 ` Mark Brown
2023-12-22 12:24 ` Mark Brown
2023-12-21 22:03 ` Uwe Kleine-König
2023-12-22 0:17 ` Martin Blumenstingl
2023-12-22 7:10 ` Uwe Kleine-König
2023-12-22 10:12 ` Martin Blumenstingl
2023-12-22 10:27 ` Uwe Kleine-König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0c99b575-5cf2-4bd6-8cfd-af19f5fd58da@sirena.org.uk \
--to=broonie@kernel.org \
--cc=ddrokosov@sberdevices.ru \
--cc=hkallweit1@gmail.com \
--cc=lgirdwood@gmail.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®