From: jerome Neanne <jneanne@baylibre.com>
To: Mark Brown <broonie@kernel.org>, Esteban Blanc <eblanc@baylibre.com>
Cc: linus.walleij@linaro.org, lgirdwood@gmail.com,
a.zummo@towertech.it, alexandre.belloni@bootlin.com,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-rtc@vger.kernel.org, jpanis@baylibre.com
Subject: Re: [PATCH INTERNAL v1 3/3] regulator: tps6594-regulator: Add driver for TI TPS6594 regulators
Date: Thu, 23 Mar 2023 10:12:21 +0100 [thread overview]
Message-ID: <bd4aa2ad-4535-94ca-7630-846546ae3d82@baylibre.com> (raw)
In-Reply-To: <Y/i+wVSy+eQxDFJ3@sirena.org.uk>
>> +static int tps6594_get_rdev_by_name(const char *regulator_name,
>> + struct regulator_dev *rdevbucktbl[BUCK_NB],
>> + struct regulator_dev *rdevldotbl[LDO_NB],
>> + struct regulator_dev *dev)
>> +{
>> + int i;
>> +
>> + for (i = 0; i <= BUCK_NB; i++) {
>> + if (strcmp(regulator_name, buck_regs[i].name) == 0) {
>> + dev = rdevbucktbl[i];
>> + return 0;
>> + }
>> + }
>> +
>> + for (i = 0; i < ARRAY_SIZE(ldo_regs); i++) {
>> + if (strcmp(regulator_name, ldo_regs[i].name) == 0) {
>> + dev = rdevldotbl[i];
>> + return 0;
>> + }
>> + }
>> + return -EINVAL;
>> +}
>
>> + for (i = 0; i < ARRAY_SIZE(tps6594_regulator_irq_types); ++i) {
>> + irq_type = &tps6594_regulator_irq_types[i];
>> +
>> + irq = platform_get_irq_byname(pdev, irq_type->irq_name);
>> + if (irq < 0)
>> + return -EINVAL;
>> +
>> + irq_data[i].dev = tps->dev;
>> + irq_data[i].type = irq_type;
>> +
>> + tps6594_get_rdev_by_name(irq_type->regulator_name, rdevbucktbl,
>> + rdevldotbl, rdev);
>
> This would be simpler and you wouldn't need this lookup function if the
> regulator descriptions included their IRQ names, then you could just
> request the interrupts while registering the regulators.
I changed the code to follow your recommendations then now in case of a
multiphase buck, only one set of interrupt is requested.
ex: multiphase buck1234 single buck5
cat /proc/interrupts:
563: 0 0 tps6594-0-0x4c 0 Edge buck1_ov
564: 0 0 tps6594-0-0x4c 1 Edge buck1_uv
565: 0 0 tps6594-0-0x4c 2 Edge buck1_sc
566: 0 0 tps6594-0-0x4c 3 Edge buck1_ilim
579: 0 0 tps6594-0-0x4c 16 Edge buck5_ov
580: 0 0 tps6594-0-0x4c 17 Edge buck5_uv
581: 0 0 tps6594-0-0x4c 18 Edge buck5_sc
582: 0 0 tps6594-0-0x4c 19 Edge buck5_ilim
buck2, buck3, buck4 are not associated to a regulator device because
buck1 registers control all the multiphase bucks (only one logic
regulator). Consequently the mapping for the associated interrupts does
not occur.
I'm not sure it's the right option.
Do you suggest to keep it like that for multiphase?
Is it better to request all the interrupts anyway and map it to the same
rdev?
>
>> + error = devm_request_threaded_irq(tps->dev, irq, NULL,
>> + tps6594_regulator_irq_handler,
>> + IRQF_ONESHOT,
>> + irq_type->irq_name,
>> + &irq_data[i]);
>> + if (error) {
>> + dev_err(tps->dev, "failed to request %s IRQ %d: %d\n",
>> + irq_type->irq_name, irq, error);
>> + return error;
>> + }
>
> This leaks all previously requested interrupts.
I'm not sure to understand this sentence correctly. You mean all the
interrupts already requested are still allocated after the error occurs?
next prev parent reply other threads:[~2023-03-23 9:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-24 13:31 [PATCH v1 0/3] TI TPS6594 PMIC support (RTC, pinctrl, regulators, device trees) Esteban Blanc
2023-02-24 13:31 ` [PATCH INTERNAL v1 1/3] rtc: tps6594: add driver for TPS6594 PMIC RTC Esteban Blanc
2023-03-07 11:08 ` Alexandre Belloni
2023-03-13 9:18 ` Esteban Blanc
2023-03-13 11:01 ` Alexandre Belloni
2023-03-13 12:10 ` Esteban Blanc
2023-03-13 13:38 ` Alexandre Belloni
2023-02-24 13:31 ` [PATCH INTERNAL v1 2/3] pinctrl: tps6594: add for TPS6594 PMIC Esteban Blanc
2023-02-24 18:49 ` kernel test robot
2023-02-25 20:36 ` kernel test robot
2023-03-06 14:10 ` Linus Walleij
2023-03-14 17:30 ` Esteban Blanc
2023-02-24 13:31 ` [PATCH INTERNAL v1 3/3] regulator: tps6594-regulator: Add driver for TI TPS6594 regulators Esteban Blanc
2023-02-24 13:42 ` Mark Brown
2023-03-03 15:02 ` jerome Neanne
2023-03-23 9:12 ` jerome Neanne [this message]
2023-03-23 11:38 ` Mark Brown
2023-03-24 8:00 ` jerome Neanne
2023-02-24 14:05 ` Matti Vaittinen
2023-03-03 14:49 ` jerome Neanne
2023-02-24 22:06 ` kernel test robot
2023-03-22 9:10 ` Julien Panis
2023-03-22 13:13 ` Mark Brown
2023-03-22 13:40 ` Julien Panis
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=bd4aa2ad-4535-94ca-7630-846546ae3d82@baylibre.com \
--to=jneanne@baylibre.com \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=broonie@kernel.org \
--cc=eblanc@baylibre.com \
--cc=jpanis@baylibre.com \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@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®