From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Baruch Siach <baruch@tkos.co.il>,
Thierry Reding <thierry.reding@gmail.com>,
Lee Jones <lee.jones@linaro.org>,
Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Andrew Lunn <andrew@lunn.ch>,
Gregory Clement <gregory.clement@bootlin.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Chris Packham <chris.packham@alliedtelesis.co.nz>,
Sascha Hauer <s.hauer@pengutronix.de>,
Ralph Sennhauser <ralph.sennhauser@gmail.com>,
linux-pwm@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 5/5] gpio: mvebu: document zero pwm duty cycle limitation
Date: Mon, 11 Jan 2021 22:43:00 +0000 [thread overview]
Message-ID: <20210111224300.GA1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <20210111202413.lk3mxthlqagdhy7t@pengutronix.de>
On Mon, Jan 11, 2021 at 09:24:13PM +0100, Uwe Kleine-König wrote:
> On Mon, Jan 11, 2021 at 01:17:06PM +0200, Baruch Siach wrote:
> > Add a comment on why the code never sets the 'on' register to zero.
> >
> > Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> > drivers/gpio/gpio-mvebu.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
> > index eb7456fa6d86..4261e3b22b4e 100644
> > --- a/drivers/gpio/gpio-mvebu.c
> > +++ b/drivers/gpio/gpio-mvebu.c
> > @@ -706,6 +706,7 @@ static int mvebu_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > val = DIV_ROUND_UP_ULL(val, NSEC_PER_SEC);
> > if (val > UINT_MAX)
> > return -EINVAL;
> > + /* zero 'on' value does not work as expected for some reason */
>
> What does the reference manual say about this? If there is no
> information about this, please point this out, too. (Something like: The
> reference manual is silent about this issue though.) Also I'd prefer to
> read about the behaviour, so maybe mention that there is an occational
> peek even when on is configured to 0. Does '$off = 0' has a symmetrical
> issue?
It isn't a proper PWM block - it's documented as being a "blink
function". It contains two counters, one defines the "on" duration,
and the other defines the "off" duration.
The block is not well documented in the reference manual, so we have
to resort to experimentation - and experimentation reveals that if
we program both registers to zero, then we get about 17s on and 17s
off. That is 2^32 / 250MHz seconds. So, a value of 0 in either register
is interpreted by the hardware as a value of 2^32.
So, let's say we want a 25kHz signal. If we program the "on" duration
to 10000 and the "off" duration to 0, what we actually get a 40us
on duration, and a 17.2s off duration - resulting in a frequency of
0.058Hz!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
prev parent reply other threads:[~2021-01-12 0:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 11:17 [PATCH 0/5] gpio: mvebu: pwm fixes and improvements Baruch Siach
2021-01-11 11:17 ` [PATCH 1/5] gpio: mvebu: fix pwm get_state period calculation Baruch Siach
2021-01-11 20:17 ` Uwe Kleine-König
2021-01-13 6:36 ` Baruch Siach
2021-01-13 8:17 ` Uwe Kleine-König
2021-01-11 11:17 ` [PATCH 2/5] gpio: mvebu: improve pwm period calculation accuracy Baruch Siach
2021-01-11 20:18 ` Uwe Kleine-König
2021-01-11 11:17 ` [PATCH 3/5] gpio: mvebu: make pwm apply/get_state closer to idempotent Baruch Siach
2021-01-11 20:20 ` Uwe Kleine-König
2021-01-11 11:17 ` [PATCH 4/5] gpio: mvebu: don't limit pwm period/duty_cycle to UINT_MAX Baruch Siach
2021-01-11 20:21 ` Uwe Kleine-König
2021-01-11 11:17 ` [PATCH 5/5] gpio: mvebu: document zero pwm duty cycle limitation Baruch Siach
2021-01-11 20:24 ` Uwe Kleine-König
2021-01-11 22:43 ` Russell King - ARM Linux admin [this message]
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=20210111224300.GA1551@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=baruch@tkos.co.il \
--cc=bgolaszewski@baylibre.com \
--cc=chris.packham@alliedtelesis.co.nz \
--cc=gregory.clement@bootlin.com \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=ralph.sennhauser@gmail.com \
--cc=s.hauer@pengutronix.de \
--cc=sebastian.hesselbarth@gmail.com \
--cc=thierry.reding@gmail.com \
--cc=thomas.petazzoni@bootlin.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;
as well as URLs for NNTP newsgroup(s).