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: Fri, 22 Dec 2023 12:24:01 +0000 [thread overview]
Message-ID: <9bea64d5-8689-48f0-a081-5da60434e6c0@sirena.org.uk> (raw)
In-Reply-To: <CAFBinCDJnVzE2sMwu52MQGTKW7dtCuUoj63ZZHhJPJO0+dZDkg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 795 bytes --]
On Thu, Dec 21, 2023 at 11:42:29PM +0100, Martin Blumenstingl wrote:
> The vendor BSP includes a custom u-boot with lots of relevant
> information for which there's seemingly no documentation.
> It seems that 1.1V is what should be used during normal operation.
> 0.86V is what can be used during system suspend (when power to the
> Cortex-A5 cores is turned off and an integrated ARC core is taking
> over for wakeup purposes).
> Hence the supported voltage range of 0.86..1.1V
That sounds like the constraints are wrong actually, if 0.86V can only
be used during system suspend then it shouldn't be in the valid voltage
range - the suspend voltage doesn't need to be in the range used during
normal operation. If we might use it during runtime suspend then it
does need to be there though.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-12-22 12:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-21 21:12 [RFC PATCH v1] regulator: pwm-regulator: Fix continuous get_voltage for disabled PWM Martin Blumenstingl
2023-12-21 21:45 ` Mark Brown
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 [this message]
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=9bea64d5-8689-48f0-a081-5da60434e6c0@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).