From: Thierry Reding <thierry.reding@gmail.com>
To: Tom Hebb <tommyhebb@gmail.com>
Cc: linux-arm-kernel@vger.kernel.org,
Antoine Tenart <antoine.tenart@free-electrons.com>,
sebastian.hesselbarth@gmail.com, jszhang@marvell.com,
"open list:PWM SUBSYSTEM" <linux-pwm@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND] pwm: berlin: Don't use broken prescaler values
Date: Wed, 6 Jun 2018 11:44:26 +0200 [thread overview]
Message-ID: <20180606094426.GI11810@ulmo> (raw)
In-Reply-To: <75f1a632-80c3-1d99-8405-01fa9a4c2616@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2840 bytes --]
On Tue, Jun 05, 2018 at 12:48:51PM -0400, Tom Hebb wrote:
> On 06/05/2018 05:10 AM, Thierry Reding wrote:
> > On Mon, Jun 04, 2018 at 02:32:41PM -0400, Thomas Hebb wrote:
> >> Six of the eight prescaler values available for Berlin PWM are not true
> >> prescalers but rather internal shifts that throw away the high bits of
> >> TCNT. Currently, we attempt to use those high bits, leading to erratic
> >> behavior. Restrict the prescaler configurations we select to only the
> >> two that respect the full range of TCNT.
> >>
> >> Tested on BG2CD.
> >>
> >> Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
> >> ---
> >> drivers/pwm/pwm-berlin.c | 45 ++++++++++++++++++++++------------------
> >> 1 file changed, 25 insertions(+), 20 deletions(-)
> >
> > Antoine, Jisheng,
> >
> > can you guys review this patch? I'm personally on the fence about this,
> > even if we can technically do the shift in software, I don't necessarily
> > see a reason why we can't "offload" to the hardware.
> >
> > Thierry
>
> Sorry if my commit message was unclear: this patch doesn't just
> arbitrarily change the hw/sw division of responsibility. The driver in
> its current state is broken (at least on BG2CD), and this patch
> implements a fix.
>
> The reason the middle six prescaler values are useless is because they
> do not actually slow down the clock. Instead, they emulate slowing down
> the clock by internally multiplying TCNT.
>
> This would be a fine trick, if not for the fact that the internal TCNT
> value has no extra bits beyond the 16 already exposed to software by the
> register. What this means is that, for a prescaler of 4, the software
> must ensure that the top two bits of TCNT are not set, because hardware
> will chop them off; for a prescaler of 8, the top three bits must not be
> set, and so forth. Software does not currently ensure this, resulting in
> a TCNT several orders of magnitude lower than intended any time one of
> those six prescalers are selected.
>
> Because hardware chops off the high bits in its internal shift, the
> middle six prescalers don't actually allow *anything* that the first
> doesn't. In fact, they are strictly worse than the first, since the
> internal shift of TCNT prevents software from setting the low bits,
> decreasing the resolution, without providing any extra high bits.
>
> By skipping the useless prescalers entirely, this patch actually
> increases the driver's performance, since, when the 4096 prescaler is
> selected, it now does only a single shift rather than the seven
> successive divisions it did before.
>
> Let me know if any of this is still unclear, or if you'd like me to
> revise the commit message.
Perfect, the above, with slight adaptations, would make a great commit
message. =)
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2018-06-06 9:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-04 18:32 [PATCH RESEND] pwm: berlin: Don't use broken prescaler values Thomas Hebb
2018-06-04 18:32 ` Thomas Hebb
2018-06-05 9:10 ` Thierry Reding
2018-06-05 16:48 ` Tom Hebb
2018-06-06 9:44 ` Thierry Reding [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=20180606094426.GI11810@ulmo \
--to=thierry.reding@gmail.com \
--cc=antoine.tenart@free-electrons.com \
--cc=jszhang@marvell.com \
--cc=linux-arm-kernel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=sebastian.hesselbarth@gmail.com \
--cc=tommyhebb@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.