From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
Bryan Wu <cooloney@gmail.com>, Richard Purdie <rpurdie@rpsys.net>,
linux-leds@vger.kernel.org
Subject: Re: [PATCH 4/5] leds: leds-pwm: implement PWM inversion
Date: Mon, 7 Apr 2014 16:01:53 +0100 [thread overview]
Message-ID: <20140407150153.GF7528@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20140407142024.GX30127@piout.net>
On Mon, Apr 07, 2014 at 04:20:24PM +0200, Alexandre Belloni wrote:
> Point taken. I'm still a bit afraid about people then setting both the
> inverted polarity on the PWM and active-low. Or not knowing when to
> choose which one. I would expect that inverting the PWM is still the
> better choice as it allows to disable the PWM.
That depends. Consider the case that I have - a LED connected between
supply and the PWM output. The PWM controller, when disabled, sets the
output to ground. When when the PWM controller supports output inversion,
when the controller is disabled, it still sets the output to ground.
That's the root of my problem - the iMX6 "inversion" isn't a real
inversion of the output itself, it's a change in the way the logic
inside the PWM works.
The design appears to be:
1. A counter which resets to zero, and then increments to a programmable
maximum value.
2. A comparitor which compares the counter output with the sample value.
3. A set-reset flip flop on the output
4. Muxes on the set and reset input to select which signals are routed
to the flip-flop.
What this means is that when the counter is reset to zero, the output
flip flop can be either set or cleared. When the counter reaches the
sample value, the output can be either cleared or set.
While the PWM is running, this results in apparant polarity changes as
per the description in linux/pwm.h. However, when disabled, the output
is always forced to zero.
What is not clearly specified is what happens at enable time. The
documentations use of "the output pin is set to start a new period"
is rather ambiguous when they've already shown that there's a set-reset
latch - does it mean that a pulse is always sent to the 'set' input
causing the output to go high when the PWM is enabled... which would
mean it would end up remaining high until the end of the first period.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
next prev parent reply other threads:[~2014-04-07 15:02 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-06 22:18 [PATCH 0/5] Fix various issues with leds-pwm Russell King - ARM Linux
2014-04-06 22:20 ` [PATCH 1/5] leds: leds-pwm: properly clean up after probe failure Russell King
2014-04-06 22:20 ` [PATCH 2/5] leds: leds-pwm: provide a common function to setup a single led-pwm device Russell King
2014-04-06 22:20 ` [PATCH 3/5] leds: leds-pwm: convert OF parsing code to use led_pwm_add() Russell King
2014-04-06 22:20 ` [PATCH 4/5] leds: leds-pwm: implement PWM inversion Russell King
2014-04-07 8:46 ` Alexandre Belloni
2014-04-07 8:52 ` Russell King - ARM Linux
2014-04-07 9:28 ` Alexandre Belloni
2014-04-07 9:42 ` Russell King - ARM Linux
2014-04-07 11:10 ` Thierry Reding
2014-04-07 11:35 ` Russell King - ARM Linux
2014-04-07 12:01 ` Thierry Reding
2014-04-07 12:37 ` Russell King - ARM Linux
2014-04-07 13:37 ` Thierry Reding
2014-04-07 14:20 ` Alexandre Belloni
2014-04-07 15:01 ` Russell King - ARM Linux [this message]
2014-04-06 22:20 ` [PATCH 5/5] leds: leds-pwm: add DT support for LEDs wired to supply Russell King
2014-04-07 21:31 ` [PATCH 0/5] Fix various issues with leds-pwm Bryan Wu
2014-04-07 21:33 ` Russell King - ARM Linux
2014-04-07 21:36 ` Bryan Wu
2014-06-12 17:12 ` Russell King - ARM Linux
2014-06-12 17:37 ` Bryan Wu
2014-06-12 17:56 ` Alexandre Belloni
2014-06-12 18:01 ` Bryan Wu
2014-06-12 18:03 ` Russell King - ARM Linux
2014-06-12 18:16 ` Bryan Wu
2014-06-12 18:21 ` Russell King - ARM Linux
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=20140407150153.GF7528@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=alexandre.belloni@free-electrons.com \
--cc=cooloney@gmail.com \
--cc=linux-leds@vger.kernel.org \
--cc=rpurdie@rpsys.net \
--cc=thierry.reding@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).