From: "Mårten Lindahl" <martenli@axis.com>
To: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
<kernel@axis.com>
Subject: Re: [PATCH v2 2/2] regulator: Add support for TI TPS6287x regulators
Date: Fri, 5 May 2023 10:29:58 +0200 [thread overview]
Message-ID: <cb621245-7133-67ac-2b1f-b829b96b7c07@axis.com> (raw)
In-Reply-To: <ZFOfX+PTsmA35TsC@finisterre.sirena.org.uk>
Hi Mark!
On 5/4/23 14:04, Mark Brown wrote:
> On Thu, May 04, 2023 at 10:30:27AM +0200, Mårten Lindahl wrote:
>
>> +static int tps6287x_get_voltage(struct regulator_dev *rdev)
>> +{
>> + struct device *dev = rdev_get_dev(rdev);
>> + struct tps6287x_chip *chip =
>> + i2c_get_clientdata(to_i2c_client(dev->parent));
>> + unsigned int val;
>> + int ret;
>> +
>> + ret = regmap_read(rdev->regmap, TPS6287X_VSET, &val);
>> + if (ret != 0)
>> + return -ENOTRECOVERABLE;
>> +
>> + return (val * chip->uv_step) + rdev->constraints->min_uV;
>> +}
> Don't open code the voltage conversion, just use selectors - in which
> case you can simply describe the bitfield that the device has and use
> the generic regmap helpers.
>
> The driver should also never be referring to constraints to figure out
> what the register values mean, this is just not going to work - boards
> will typically be able to use far fewer voltages than the regulator
> supports.
>
> Also try to avoid squashing error codes, just pass the result back.
>
>> +static int tps6287x_set_voltage(struct regulator_dev *rdev, int min_uv,
>> + int max_uv, unsigned int *selector)
> Similarly here, describe the bitfield and use the generic helpers.
I understand. I'll change it. Explanation below why I did it like this.
>
>> +static int tps6287x_setup_vrange(struct tps6287x_chip *chip)
>> +{
>> + struct regulator_dev *rdev = chip->rdev;
>> + unsigned int val, r;
>> + bool found = false;
>> + int ret;
>> +
>> + /*
>> + * Match DT voltage range to one of the predefined ranges,
>> + * and configure the regulator with the selected range.
>> + */
>> + for (r = 0; r < ARRAY_SIZE(tps6287x_voltage_table); r++) {
>> + if (tps6287x_voltage_table[r][0] == rdev->constraints->min_uV &&
>> + tps6287x_voltage_table[r][1] == rdev->constraints->max_uV) {
>> + found = true;
>> + break;
>> + }
>> + }
> No, as I said above the driver should just know what the device
> supports based on the device ID. In general if a regulator driver is
> looking at the constraints that indicates that it's doing something
> wrong, the purpose of constraints is to grant permission for the
> features of the regulator to be used on the board.
The reason for doing like this is that all 4 device IDs support all 4
voltage ranges:
0.4-V to 0.71875-V in 1.25-mV steps
0.4-V to 1.0375-V in 2.5-mV steps
0.4-V to 1.675-V in 5-mV steps
0.8-V to 3.35-V in 10-mV steps
Of which the third is default for all devices. The range is solely
selected by a register
field (no hardware pin connection), so I can't associate a specific
device ID with a
specific voltage range, which is why I let the DT properties min/max
decide the range.
But I see now it should be done in another way. I can think of 2 ways to
implement it:
1. Introduce a DT property for this driver, like "ti,vrange-selector"
and select one of
the 4 voltage ranges by desc->of_parse_cb. This way allows a new
voltage only to be set
if it is within the selected range.
2. Dynamically set the range when a new voltage is set. This way any
voltage from
0.4V to 3.35V could be set if the DT node has:
regulator-min-microvolt = <400000>;
regulator-max-microvolt = <3350000>;
I hope I was clear enough with my reasoning. Maybe there are better ways
to do it?
Kind regards
Mårten
>
>> +static const struct of_device_id tps6287x_dt_ids[] = {
>> + { .compatible = "ti,tps62870", },
>> + { .compatible = "ti,tps62871", },
>> + { .compatible = "ti,tps62872", },
>> + { .compatible = "ti,tps62873", },
>> + { }
>> +};
> Use the .data field here...
>
>> +static const struct i2c_device_id tps6287x_i2c_id[] = {
>> + { "tps62870", 0 },
>> + { "tps62871", 0 },
>> + { "tps62872", 0 },
>> + { "tps62873", 0 },
>> + {},
>> +};
> ...and here to enumerate which of the variants is being used and hence
> which voltage range is required.
next prev parent reply other threads:[~2023-05-05 8:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-04 8:30 [PATCH v2 0/2] regulator: Add support for TPS6287x Mårten Lindahl
2023-05-04 8:30 ` [PATCH v2 1/2] regulator: Add bindings " Mårten Lindahl
2023-05-04 9:34 ` Krzysztof Kozlowski
2023-05-04 15:08 ` Mårten Lindahl
2023-05-04 15:11 ` Krzysztof Kozlowski
2023-05-05 11:03 ` Mårten Lindahl
2023-05-04 8:30 ` [PATCH v2 2/2] regulator: Add support for TI TPS6287x regulators Mårten Lindahl
2023-05-04 12:04 ` Mark Brown
2023-05-05 8:29 ` Mårten Lindahl [this message]
[not found] ` <e02589b8-118d-0feb-d32a-bdf39d1b88f6@axis.com>
2023-05-05 11:52 ` Mark Brown
2023-05-08 6:51 ` Mårten Lindahl
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=cb621245-7133-67ac-2b1f-b829b96b7c07@axis.com \
--to=martenli@axis.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel@axis.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@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®