linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: ChiYuan Huang <u0084500@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Lee Jones <lee.jones@linaro.org>,
	dmitry.torokhov@gmail.com, Liam Girdwood <lgirdwood@gmail.com>,
	cy_huang <cy_huang@richtek.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, lkml <linux-kernel@vger.kernel.org>,
	linux-input@vger.kernel.org
Subject: Re: [PATCH 3/4] regulator: rt5120: Add PMIC regulator support
Date: Mon, 13 Jun 2022 12:10:05 +0100	[thread overview]
Message-ID: <YqcbDfceSusNea6v@sirena.org.uk> (raw)
In-Reply-To: <CADiBU383BxOttuoLdF2GjXHasoPMc634wsMr3zLC=v74OBGUmw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]

On Mon, Jun 13, 2022 at 09:49:31AM +0800, ChiYuan Huang wrote:
> Mark Brown <broonie@kernel.org> 於 2022年6月10日 週五 下午7:03寫道:

> > > Not just buck2/3, buck2/3/4/ldo/exten all need the dynamic handling.

> > Why do the others need it?

> Sometimes, for this kind of general purpose PMIC, it need to provide
> the flexibility.
> Cause buck2 and ldo can already be fixed by the external resistor,
> buck3 and buck4 seems to be fixed by IC default.
> So there may be the same part number and use the postfix to be
> different like as 5120'A'/5120'B', etc...
> And use it to define the voltage for the different IC default for
> buck3 and buck4, and exten behavior.
> That's due to the different application use the different power on
> sequence and default voltages.l

Variants should have separate compatibles, and if the code is doing
something fixed then it shouldn't make any difference if that fixed
thing is written in code or as a data table.

> > > If I put 'of_parce_cb' to make core handling it, the input parameter
> > > 'init_data' is declared as const.
> > > I cannot override the 'apply_uV'.

> > > Right?

> > Yes, that's by design.

> I have traced the code for 'of_get_regulator_init_data' and
> 'set_machine_constraints' in regulator register.
> If I cannot overwrite apply_uV variable, it will cause the
> regulator_register return -EINVAL.

We have a very large number of fixed voltage regulators in use on
various systems which manage perfectly fine without this.  If the
constraints are trying to set something invalid then they're what 
should be fixed.

> Is the below flow that you suggested?
> 1. of_parse_cb to check min_uV and max_uV, and fill in the fixed_uV in
> regulator_desc

No, the device should just know what voltage the fixed voltage
regulators in the device have.

> 2. provide the duummy set/get voltage  to make set_machine_constraints
> not return '-EINVAL'.

No, people just shouldn't be trying to set the voltage for fixed voltage
regulators.  If the regulators are configurable in hardware then provide
DT properties for whatever is configured (eg, resistors).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2022-06-13 12:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-07  5:52 [PATCH 0/4] Add Richtek RT5120 PMIC support cy_huang
2022-06-07  5:52 ` [PATCH 1/4] dt-binding: mfd: " cy_huang
2022-06-07 11:52   ` Krzysztof Kozlowski
2022-06-08  2:52     ` ChiYuan Huang
2022-06-08  7:01       ` Krzysztof Kozlowski
2022-06-08  7:25         ` ChiYuan Huang
2022-06-08  7:44           ` Krzysztof Kozlowski
2022-06-07 19:02   ` Mark Brown
2022-06-08  3:04     ` ChiYuan Huang
2022-06-07  5:52 ` [PATCH 2/4] mfd: rt5120: Add Richtek " cy_huang
2022-06-07  5:52 ` [PATCH 3/4] regulator: rt5120: Add PMIC regulator support cy_huang
2022-06-07 19:00   ` Mark Brown
2022-06-08  3:15     ` ChiYuan Huang
2022-06-08 10:12       ` Mark Brown
2022-06-09  6:35         ` ChiYuan Huang
2022-06-10 11:03           ` Mark Brown
2022-06-13  1:49             ` ChiYuan Huang
2022-06-13 11:10               ` Mark Brown [this message]
2022-06-07  5:52 ` [PATCH 4/4] input: misc: rt5120: Add power key support cy_huang
2022-06-08  7:03   ` Krzysztof Kozlowski
2022-06-08  7:05     ` Krzysztof Kozlowski

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=YqcbDfceSusNea6v@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=cy_huang@richtek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=u0084500@gmail.com \
    /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).