lkml.org 
[lkml]   [2011]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PWM v7 3/3] PWM: Atmel PWMC driver
From
Alexander:

On Thu, Mar 10, 2011 at 1:36 AM, Alexander Stein
<alexander.stein@systec-electronic.com> wrote:
> As far as I can see, the previosly support for pwm_channel_handler has been
> dropped. The new API doesn't support such things.
> What do you think about adding this? It might be important to change the PWM
> setup after a specific amount of time.

Reviewers of the implementation noted some race conditions, and had
additional objections to the implementation. They suggested that I
reimplement channel handlers using genirq.

Since the pwm_channel_handler implementation was broken, I removed it
from the implementation. I haven't yet started on the genirq-based
approach, for two reasons: I'm trying to get everything else into
mainline; and, I'm not quite sure yet how to stitch genirq together
with "genpwm".

There is a larger question, however, that I would like to hear your
answer on since you seem interested in the subject: are end-of-period
callbacks really necessary? If you are trying to "ramp" a PWM signal
from a low duty cycle to a high one, would an hrtimer suffice?
Assuming that a PWM device driver can implement duty cycle and/or
period changes without glitches, is it really necessary to stay so
tightly synchronized to the PWM signal the way that an end-of-period
callback would allow?

In my work, I haven't encountered a need for end-of-period callbacks
when doing mere PWM signal generation (though the topic is very
important when counting pulses, which I'm considering a different
implementation/API for). I don't know if my experience is
comprehensive, however. Would love to hear your opinion.


b.g.
--
Bill Gatliff
bgat@billgatliff.com


\
 
 \ /
  Last update: 2011-03-10 22:37    [W:0.048 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site