pwm: omap-dmtimer: fix period/duty_cycle calculation
Get series with b4
b4 am 20160304211838.GA21731@ulmoVersions newest first
- v1 Latest0 of 4 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 4 patches the cover letter announces are in this archive.
Reviews trailers per patch
| Patch | Adam Ford |
|---|---|
| Series | T-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH 0/4] pwm: omap-dmtimer: fix period/duty_cycle calculation
Quoted 51 lines · David Rivshin (Allworx)
Quoted 39 lines · On Fri, 4 Mar 2016 16:19:48 +0100 Thierry Reding <[email protected]>…
Quoted 38 lines · David Rivshin (Allworx)
Quoted 34 lines · On Fri, 29 Jan 2016 23:26:50 -0500 "David Rivshin (Allworx)"…
From: David Rivshin <[email protected]>
When using a short PWM period (approaching the min of 2/clk_rate), pwm-omap-dmtimer does not produce accurate results. In the worst case a requested period of 2/clk_rate would result in a real period of 4/clk_rate instead. This is a series includes a fix for that problem, as well as other related improvements, and is based on the current linux-pwm/for-next tip.
I have tested on a Sitara AM335x platform, using a scope to verify the output with a variety of periods and duty cycles. This includes a PWM rate up clk_rate/2 with 50% duty cycle (e.g. generating fclk/2) with both 32768Hz and 24MHz fclks. I do not have an OMAP4 board to test with, although appropriate sections in the the reference manuals appear substantially the same, so I believe the changes are equally correct there.
Note that the OMAP4 TRMs do effectively state that the maximum PWM rate is clk_rate/4, so at very fast PWM rates the behavior may not be as reliable as I observed with Sitara. Although I suspect that it's the same module and will also work, at least under some circumstances. If anyone with OMAP4 hardware and a scope is so inclined, I would be curious to know the results.
David Rivshin (4):
pwm: omap-dmtimer: fix inaccurate period/duty_cycle calculation
pwm: omap-dmtimer: add sanity checking for load and match values
pwm: omap-dmtimer: round load and match values rather than truncate
pwm: omap-dmtimer: adddev_dbg()message for effective period and duty
cycledrivers/pwm/pwm-omap-dmtimer.c | 71 ++++++++++++++++++++++++++++++++---------- 1 file changed, 55 insertions(+), 16 deletions(-)Quoted 8 lines
Quoted 5 lines
Hi Thierry,
Gentle ping. It does not look like you've taken this series, and I wanted to make sure you're not waiting on something from me. It would be nice to get at least the first patch into 4.5, if possible.
I've applied patches 1 and 3, and I'm planning on sending out a pull request for inclusion in v4.5-rc7 later on.
Quoted 7 lines
Thanks!
Quoted 2 lines
Patches 2 and 4 didn't seem ready/critical, so let's finish those up for v4.6-rc1.
I know there was a lot of discussion on 4, but I'm not sure what the concern is on patch 2. Is there something specific you're thinking of?
Patch 2 sounded like some optional sanity checking which we didn't hit anyway in the current code. Hence I didn't consider it a fix.
Quoted 5 lines
FYI, I know that Adam Ford is using this driver as the backend for a pwm-backlight control. Without patch 2 this driver will not configure the HW in a legal way at 0 or 100% duty cycle. However, I forget what the practical effect of that is, and Adam seemed to indicate it was OK for his purposes.
Okay, I'll hold back a little longer to give you some time to test.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160304/83c0a526/attachment-0001.sig>