mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: George Stark <gnstark@salutedevices.com>
To: <broonie@kernel.org>, <lgirdwood@gmail.com>
Cc: <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <kernel@salutedevices.com>,
	George Stark <gnstark@salutedevices.com>
Subject: [PATCH 0/1] pwm-regulator with voltage table problem
Date: Mon, 10 Jun 2024 15:00:24 +0300	[thread overview]
Message-ID: <20240610120025.405062-1-gnstark@salutedevices.com> (raw)

Here is the situation we've met on an ARM SoC:

We have an ARM SoC with dedicated power input for CPU core and supports different
CPU clocks. CPU core power is supplied by external regulator, it's controlled by
PWM channel from the SoC. DTS has node for pwm-regulator with voltage table
(voltage table is used instead of range apparently to use only fine-tuned
duty-cycle values) and with boot-on and always-on properties. This regulator is
bound to cpu node. The pwm-regulator is inited at very early stage before bootloader
in vendor closed-source code.

When a pwm-regulator is probed in the kernel it gets pwm current state and search
voltage table by dutycycle to figure out the current voltage. If that search failed
then the regulator goes to notrecoverbale state and the core sets the minimal power
for the regulator.

The situation: bootloader sets mean cpu power and mean cpu clock.
but that cpu power is not found in the voltage table (value is between table items)
due to different versions of bootloader and kernel and the regulator core sets
the minimal power but cpu clock stays the same. CPU hangs somewhere during boot.

The core problem as I see it is if regulator is bound to CPU (or some other
complex consumer) it can't be changed except by the consumer at any stage. So
the regulator driver (core part) should wait for the own consumer to init
it properly but regulator can't be in unknown state after probing.

What you think? The least should be done is to report about the situation.

George Stark (1):
  regulator: core: add warning for not-recoverable state

 drivers/regulator/core.c | 4 ++++
 1 file changed, 4 insertions(+)

--
2.25.1


             reply	other threads:[~2024-06-10 12:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-10 12:00 George Stark [this message]
2024-06-10 12:00 ` [PATCH 1/1] regulator: core: add warning for not-recoverable state George Stark
2024-06-10 15:47   ` Mark Brown
2024-06-10 14:36 ` [PATCH 0/1] pwm-regulator with voltage table problem Mark Brown
2024-06-10 15:37 ` Mark Brown
2024-06-10 21:33   ` George Stark
2024-06-10 21:55     ` Mark Brown

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=20240610120025.405062-1-gnstark@salutedevices.com \
    --to=gnstark@salutedevices.com \
    --cc=broonie@kernel.org \
    --cc=kernel@salutedevices.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    /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®