From: David Collins <collinsd@codeaurora.org>
To: Mark Brown <broonie@kernel.org>
Cc: Stephen Boyd <swboyd@chromium.org>,
lgirdwood@gmail.com, mark.rutland@arm.com, robh+dt@kernel.org,
linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, rnayak@codeaurora.org,
ilina@codeaurora.org
Subject: Re: [PATCH 1/2] regulator: add QCOM RPMh regulator driver
Date: Thu, 17 May 2018 13:48:41 -0700 [thread overview]
Message-ID: <6cb2ac52-258c-332b-e912-809d16e14114@codeaurora.org> (raw)
In-Reply-To: <20180517060948.GI20254@sirena.org.uk>
On 05/16/2018 11:09 PM, Mark Brown wrote:
> On Tue, Apr 24, 2018 at 01:46:21PM -0700, David Collins wrote:
>> The RPMh hardware is aware of the parent-child connections between
>> regulators as well as minimum headroom to ensure stable LDO voltage output
>> for subregulated LDOs. The intention of having the headroom be a
>> configurable property for processors is to support usecases in which
>> subregulated LDO loads are particularly sensitive to noise and require
>> additional headroom. Such usecases are board dependent and beyond the
>> baseline configurations set in RPMh hardware.
>
> So the hardware implementation is some hard coding stuff that doesn't
> really adequately reflect reality? This seems unfortunate. However do
> we really need to tell the hardware about the fact that we're adding
> extra headroom - are there actual interactions with non-Linux things
> here?
The RPMh hardware is configured by the boot loader. The configuration
does reflect reality; however, it cannot handle all configurations at
initialization time. Specific headroom management typically comes up in
modem usecases for RF supplies that are sensitive to noise. This feature
allows RPMh masters (application processor, modem processor, etc) to make
requests only for the regulators that they directly care about without
having to worry about power grid parent-child details and setting the
voltage of parent regulators in order to ensure sufficient headroom.
If you really don't like having this feature present in the Linux RPMh
regulator driver, then I'd be ok removing it. It is not required for
SDM845 which the driver is initially targeting.
>>>> XOB managed regulators physically cannot change voltage. Therefore, do
>>>> you agree that it is reasonable to use fixed_uV for them? Note that I
>>>> removed init_data->constraints.apply_uV manipulation in version 2 of this
>>>> patch.
>
>>> If these regulators can't change voltage then surely we know what
>>> voltage they have without needing it to be specified in DT?
>
>> In the case of XOB managed LDO regulators, the LDOs physically can be
>> configured to different voltages by the bootloader. However, the RPMh
>> interface provides no mechanism for the application processor to read or
>> change that voltage. Therefore, we need a way to specify such voltages in
>> a board specific (as opposed to driver specific) manner (i.e. device tree).
>
> Is the kernel somehow prevented from varying these voltages?
Yes. Physically, there exists no RPMh register to read or write the
voltage of LDOs managed via XOB. Additionally, the kernel running on the
application processor is blocked from configuring the voltage via a direct
SPMI writes by access permissions that crash the system when violated.
Take care,
David
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2018-05-17 20:48 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-17 1:09 [PATCH 0/2] regulator: add QCOM RPMh regulator driver David Collins
2018-03-17 1:09 ` [PATCH 1/2] " David Collins
2018-03-18 20:38 ` [PATCH] regulator: fix platform_no_drv_owner.cocci warnings kbuild test robot
2018-03-19 21:47 ` David Collins
2018-03-18 20:38 ` [PATCH 1/2] regulator: add QCOM RPMh regulator driver kbuild test robot
2018-03-21 2:16 ` Doug Anderson
2018-03-22 22:31 ` David Collins
2018-03-23 20:00 ` Doug Anderson
2018-03-27 11:56 ` Mark Brown
2018-03-27 20:51 ` Doug Anderson
2018-03-28 2:28 ` Mark Brown
2018-03-27 23:38 ` David Collins
2018-03-28 2:08 ` Mark Brown
2018-03-27 23:22 ` David Collins
2018-03-21 19:07 ` Stephen Boyd
2018-03-23 1:30 ` David Collins
2018-03-26 15:35 ` Lina Iyer
2018-04-19 5:55 ` Stephen Boyd
2018-04-19 12:08 ` Mark Brown
2018-04-20 19:28 ` David Collins
2018-04-24 17:41 ` Mark Brown
2018-04-24 20:46 ` David Collins
2018-05-17 6:09 ` Mark Brown
2018-05-17 20:48 ` David Collins [this message]
2018-05-22 16:36 ` Mark Brown
2018-04-20 19:07 ` David Collins
2018-04-20 22:44 ` Lina Iyer
2018-04-24 20:33 ` David Collins
2018-03-29 22:36 ` Doug Anderson
2018-03-17 1:09 ` [PATCH 2/2] dt-bindings: regulator: add QCOM RPMh regulator bindings David Collins
2018-03-21 2:16 ` Doug Anderson
2018-03-21 23:54 ` David Collins
2018-03-21 2:43 ` Mark Brown
2018-03-27 23:48 ` David Collins
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=6cb2ac52-258c-332b-e912-809d16e14114@codeaurora.org \
--to=collinsd@codeaurora.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=ilina@codeaurora.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=rnayak@codeaurora.org \
--cc=robh+dt@kernel.org \
--cc=swboyd@chromium.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;
as well as URLs for NNTP newsgroup(s).