From: Stefan Wahren <wahrenst@gmx.net>
To: "Alexander Stein" <alexander.stein@ew.tq-group.com>,
"Sean Young" <sean@mess.org>,
linux-media@vger.kernel.org,
"Ivaylo Dimitrov" <ivo.g.dimitrov.75@gmail.com>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Florian Fainelli" <florian.fainelli@broadcom.com>,
"Ray Jui" <rjui@broadcom.com>,
"Scott Branden" <sbranden@broadcom.com>,
"Broadcom internal kernel review list"
<bcm-kernel-feedback-list@broadcom.com>
Cc: linux-pwm@vger.kernel.org, linux-rpi-kernel@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] pwm: bcm2835: allow pwm driver to be used in atomic context
Date: Fri, 13 Oct 2023 13:44:03 +0200 [thread overview]
Message-ID: <cc563313-32d7-4098-b93a-1fa06b8afb02@gmx.net> (raw)
In-Reply-To: <5203415.ElGaqSPkdT@steina-w>
Hi Alexander,
Am 13.10.23 um 13:13 schrieb Alexander Stein:
> Hi,
>
> Am Freitag, 13. Oktober 2023, 13:04:48 CEST schrieb Stefan Wahren:
>> Hi Sean,
>>
>> Am 13.10.23 um 12:46 schrieb Sean Young:
>>> clk_get_rate() may do a mutex lock. Since the clock rate cannot change on
>>> an rpi, simply fetch it once.
>> does it mean you checked all possible SoCs (BCM2835, BCM2836, BCM2837,
>> BCM2711, BCM2712) for this change?
>>
>> Is it impossible that the real clock can never be influenced by turbo
>> mode like SPI?
> Assuming the clock can change, which I would, then a clock notifier seems
> appropriate. See [1] for an example.
i remember a similiar approach for the CPU frequency for the RPi. At end
the we decided to let the firmware handle it and don't use clock
notifier, see [2] and the related links for more background. The fact
that the VideoCore has the real control makes it hard.
I don't want to say that's impossible.
[2] -
https://patchwork.kernel.org/project/linux-arm-kernel/cover/20190520104708.11980-1-nsaenzjulienne@suse.de/
>
> Best regards,
> Alexander
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
> commit/?id=90ad2cbe88c22d0215225ab9594eeead0eb24fde
>
>> Best regards
>>
>>> Signed-off-by: Sean Young <sean@mess.org>
>>> ---
>>>
>>> drivers/pwm/pwm-bcm2835.c | 21 ++++++++++++---------
>>> 1 file changed, 12 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
>>> index bdfc2a5ec0d6..59ea154dd657 100644
>>> --- a/drivers/pwm/pwm-bcm2835.c
>>> +++ b/drivers/pwm/pwm-bcm2835.c
>>> @@ -28,6 +28,7 @@ struct bcm2835_pwm {
>>>
>>> struct device *dev;
>>> void __iomem *base;
>>> struct clk *clk;
>>>
>>> + unsigned long rate;
>>>
>>> };
>>>
>>> static inline struct bcm2835_pwm *to_bcm2835_pwm(struct pwm_chip *chip)
>>>
>>> @@ -63,17 +64,11 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip,
>>> struct pwm_device *pwm,>
>>> {
>>>
>>> struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
>>>
>>> - unsigned long rate = clk_get_rate(pc->clk);
>>>
>>> unsigned long long period_cycles;
>>> u64 max_period;
>>>
>>> u32 val;
>>>
>>> - if (!rate) {
>>> - dev_err(pc->dev, "failed to get clock rate\n");
>>> - return -EINVAL;
>>> - }
>>> -
>>>
>>> /*
>>>
>>> * period_cycles must be a 32 bit value, so period * rate /
>>> NSEC_PER_SEC
>>> * must be <= U32_MAX. As U32_MAX * NSEC_PER_SEC < U64_MAX the
>>>
>>> @@ -88,13 +83,13 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip,
>>> struct pwm_device *pwm,>
>>> * <=> period < ((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) / rate
>>> * <=> period <= ceil((U32_MAX * NSEC_PER_SEC + NSEC_PER_SEC/2) /
> rate)
>>> - 1
>>> */
>>>
>>> - max_period = DIV_ROUND_UP_ULL((u64)U32_MAX * NSEC_PER_SEC +
> NSEC_PER_SEC
>>> / 2, rate) - 1; + max_period = DIV_ROUND_UP_ULL((u64)U32_MAX *
>>> NSEC_PER_SEC + NSEC_PER_SEC / 2, pc->rate) - 1;>
>>> if (state->period > max_period)
>>>
>>> return -EINVAL;
>>>
>>> /* set period */
>>>
>>> - period_cycles = DIV_ROUND_CLOSEST_ULL(state->period * rate,
>>> NSEC_PER_SEC); + period_cycles = DIV_ROUND_CLOSEST_ULL(state->period *
>>> pc->rate, NSEC_PER_SEC);>
>>> /* don't accept a period that is too small */
>>> if (period_cycles < PERIOD_MIN)
>>>
>>> @@ -103,7 +98,7 @@ static int bcm2835_pwm_apply(struct pwm_chip *chip,
>>> struct pwm_device *pwm,>
>>> writel(period_cycles, pc->base + PERIOD(pwm->hwpwm));
>>>
>>> /* set duty cycle */
>>>
>>> - val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * rate, NSEC_PER_SEC);
>>> + val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * pc->rate,
> NSEC_PER_SEC);
>>> writel(val, pc->base + DUTY(pwm->hwpwm));
>>>
>>> /* set polarity */
>>>
>>> @@ -129,6 +124,7 @@ static const struct pwm_ops bcm2835_pwm_ops = {
>>>
>>> .request = bcm2835_pwm_request,
>>> .free = bcm2835_pwm_free,
>>> .apply = bcm2835_pwm_apply,
>>>
>>> + .atomic = true,
>>>
>>> .owner = THIS_MODULE,
>>>
>>> };
>>>
>>> @@ -156,6 +152,13 @@ static int bcm2835_pwm_probe(struct platform_device
>>> *pdev)>
>>> if (ret)
>>>
>>> return ret;
>>>
>>> + pc->rate = clk_get_rate(pc->clk);
>>> + if (!pc->rate) {
>>> + dev_err(pc->dev, "failed to get clock rate\n");
>>> + ret = -EINVAL;
>>> + goto add_fail;
>>> + }
>>> +
>>>
>>> pc->chip.dev = &pdev->dev;
>>> pc->chip.ops = &bcm2835_pwm_ops;
>>> pc->chip.npwm = 2;
>
next prev parent reply other threads:[~2023-10-13 11:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1697193646.git.sean@mess.org>
2023-10-13 10:46 ` [PATCH v2 1/3] pwm: make it possible to apply pwm changes in atomic context Sean Young
2023-10-13 11:51 ` Thierry Reding
2023-10-13 14:58 ` Sean Young
2023-10-13 15:34 ` Thierry Reding
2023-10-13 18:04 ` Uwe Kleine-König
2023-10-14 8:31 ` Sean Young
2023-10-13 10:46 ` [PATCH v2 2/3] pwm: bcm2835: allow pwm driver to be used " Sean Young
2023-10-13 11:04 ` Stefan Wahren
2023-10-13 11:13 ` Alexander Stein
2023-10-13 11:44 ` Stefan Wahren [this message]
2023-10-13 17:51 ` Uwe Kleine-König
2023-10-14 6:51 ` Ivaylo Dimitrov
2023-10-14 8:47 ` Uwe Kleine-König
2023-10-13 10:46 ` [PATCH v2 3/3] media: pwm-ir-tx: trigger edges from hrtimer interrupt context Sean Young
2023-10-15 6:31 ` Ivaylo Dimitrov
2023-10-15 21:25 ` Sean Young
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=cc563313-32d7-4098-b93a-1fa06b8afb02@gmx.net \
--to=wahrenst@gmx.net \
--cc=alexander.stein@ew.tq-group.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=florian.fainelli@broadcom.com \
--cc=ivo.g.dimitrov.75@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=rjui@broadcom.com \
--cc=sbranden@broadcom.com \
--cc=sean@mess.org \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/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