linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).