From: Mark Brown <broonie@kernel.org>
To: Jorge Ramirez <jorge.ramirez-ortiz@linaro.org>
Cc: lgirdwood@gmail.com, robh+dt@kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
bjorn.andersson@linaro.org, vinod.koul@linaro.org,
niklas.cassel@linaro.org, khasim.mohammed@linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 2/3] drivers: regulator: qcom: add PMS405 SPMI regulator
Date: Thu, 2 May 2019 11:33:16 +0900 [thread overview]
Message-ID: <20190502023316.GS14916@sirena.org.uk> (raw)
In-Reply-To: <a3c281d5-d30e-294f-71ab-957decde2ba0@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 2440 bytes --]
On Mon, Apr 29, 2019 at 02:31:55PM +0200, Jorge Ramirez wrote:
> On 4/27/19 20:21, Mark Brown wrote:
> > Since the point of this change is AFAICT that this regulator only has a
> > single linear range it seems like it should just be able to use the
> > existing generic functions shouldn't it?
> yes that would have been ideal but it does not seem to be the case for
> this hardware.
> The register that stores the voltage range for all other SPMI regulators
> (SPMI_COMMON_REG_VOLTAGE_RANGE 0x40) is used by something else in the
> HFS430: SPMI_HFS430_REG_VOLTAGE_LB 0x40 stores the voltage level in two
> bytes 0x40 and 0x41;
> This overlap really what is creating the pain: HFS430 cant use 0x40 to
> store the range (even if it is only one)
> so yeah, most of the changes in the patch are working around this fact.
I'm not sure I follow here, sorry - I can see that the driver needs a
custom get/set selector operation but shouldn't it be able to use the
standard list and map operations for linear ranges?
>
> enum spmi_common_regulator_registers {
> SPMI_COMMON_REG_DIG_MAJOR_REV = 0x01,
> SPMI_COMMON_REG_TYPE = 0x04,
> SPMI_COMMON_REG_SUBTYPE = 0x05,
> SPMI_COMMON_REG_VOLTAGE_RANGE = 0x40, ******
> SPMI_COMMON_REG_VOLTAGE_SET = 0x41,
> SPMI_COMMON_REG_MODE = 0x45,
> SPMI_COMMON_REG_ENABLE = 0x46,
> SPMI_COMMON_REG_PULL_DOWN = 0x48,
> SPMI_COMMON_REG_SOFT_START = 0x4c,
> SPMI_COMMON_REG_STEP_CTRL = 0x61,
> };
>
> enum spmi_hfs430_registers {
> SPMI_HFS430_REG_VOLTAGE_LB = 0x40, *******
> SPMI_HFS430_REG_VOLTAGE_VALID_LB = 0x42,
> SPMI_HFS430_REG_MODE = 0x45,
> };
>
> It just needs it's own
> > set/get_voltage_sel() operations. As far as I can see the main thing
> > the driver is doing with the custom stuff is handling the fact that
> > there's multiple ranges but that's not an issue for this regulator.
> > It's possible I'm missing something there but that was the main thing
> > (and we do have some generic support for multiple linear ranges in the
> > helper code already, can't remember why this driver isn't using that -
> > the ranges overlap IIRC?).
> >
> > TBH looking at the uses of find_range() I'm not sure they're 100%
> > sensible as they are - the existing _time_sel() is assuming we only need
> > to work out the ramp time between voltages in the same range which is
> > going to have trouble.
> >
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-05-02 2:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-28 11:45 [PATCH 0/3] qcom: add PMS405 SPMI regulator Jorge Ramirez-Ortiz
2019-01-28 11:45 ` [PATCH 1/3] dt-bindings: qcom_spmi: Document pms405 support Jorge Ramirez-Ortiz
2019-02-23 0:44 ` Rob Herring
2019-01-28 11:45 ` [PATCH 2/3] drivers: regulator: qcom: add PMS405 SPMI regulator Jorge Ramirez-Ortiz
2019-02-04 9:03 ` Mark Brown
2019-04-19 17:29 ` Jorge Ramirez
2019-04-25 18:37 ` Mark Brown
2019-04-25 19:44 ` Jorge Ramirez
2019-04-27 18:21 ` Mark Brown
2019-04-29 12:31 ` Jorge Ramirez
2019-05-02 2:33 ` Mark Brown [this message]
2019-05-02 11:30 ` Jorge Ramirez
2019-05-03 6:26 ` Mark Brown
2019-05-03 8:29 ` Jorge Ramirez
2019-05-06 4:38 ` Mark Brown
2019-05-23 8:35 ` Jorge Ramirez
2019-05-23 13:16 ` Mark Brown
2019-01-28 11:45 ` [PATCH 3/3] arm64: dts: qcom: pms405: add spmi regulators Jorge Ramirez-Ortiz
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=20190502023316.GS14916@sirena.org.uk \
--to=broonie@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jorge.ramirez-ortiz@linaro.org \
--cc=khasim.mohammed@linaro.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=niklas.cassel@linaro.org \
--cc=robh+dt@kernel.org \
--cc=vinod.koul@linaro.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