From: Fabien DESSENNE <fabien.dessenne@foss.st.com>
To: Marek Vasut <marex@denx.de>,
Linus Walleij <linus.walleij@linaro.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
<linux-gpio@vger.kernel.org>,
<linux-stm32@st-md-mailman.stormreply.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] pinctrl: stm32: improve bank clocks management
Date: Mon, 25 Apr 2022 11:27:45 +0200 [thread overview]
Message-ID: <442677d2-7e9f-14f0-4b5a-1f98a8f40c8a@foss.st.com> (raw)
In-Reply-To: <c48500cd-50be-1d70-2f2c-02c2dcede1eb@denx.de>
Hi Marek
On 22/04/2022 18:26, Marek Vasut wrote:
> On 4/22/22 16:36, Fabien Dessenne wrote:
>> Instead of enabling/disabling the clock at each IO configuration update,
>> just keep the clock enabled from the probe.
>> This makes things simpler and more efficient (e.g. the time required to
>> toggle an output IO is drastically decreased) without significantly
>> increasing the power consumption.
>
> [...]
>
>> static struct irq_domain *stm32_pctrl_get_irq_domain(struct
>> device_node *np)
>> @@ -1575,6 +1537,10 @@ int stm32_pctl_probe(struct platform_device *pdev)
>> ret = stm32_gpiolib_register_bank(pctl, child);
>> if (ret) {
>> of_node_put(child);
>> +
>> + for (i = 0; i < pctl->nbanks; i++)
>> + clk_disable_unprepare(pctl->banks[i].clk);
>> +
>
> There are clk_bulk_*() functions, maybe you can use those to get rid of
> these loops ?
This sounds goods, but checking more in details I see that moving to the
'bulk' implementation would require to move the clk information from the
"struct stm32_gpio_bank *banks" member to its parent "struct stm32_pinctrl".
This would make the clk device information stored in a different
structure from the other device-related information (base address, reset
control, ...). It's better to keep all those information together in the
same struct.
As another drawback we would loose access to 'clk' from any function
that have 'bank' (or 'struct gpio_chip *chip') as input parameter (e.g.
stm32_gpio_get() called from gpiolib).
So I really prefer to keep the current implementation.
BR
Fabien
>
> The rest looks good to me.
next prev parent reply other threads:[~2022-04-25 9:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-22 14:36 [PATCH] pinctrl: stm32: improve bank clocks management Fabien Dessenne
2022-04-22 16:26 ` Marek Vasut
2022-04-25 9:27 ` Fabien DESSENNE [this message]
2022-04-25 22:07 ` Marek Vasut
2022-05-01 21:26 ` Linus Walleij
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=442677d2-7e9f-14f0-4b5a-1f98a8f40c8a@foss.st.com \
--to=fabien.dessenne@foss.st.com \
--cc=alexandre.torgue@foss.st.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=marex@denx.de \
--cc=mcoquelin.stm32@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).