Re: [PATCH 1/6] [PWM] Generic PWM API implementation

[David Brownell <david-b@pacbell.net>]

On Tuesday 04 November 2008, Bill Gatliff wrote:
> This is literally the only feedback I have received. 

I was waiting for followup too.  I finally get onto this
list (for some reason the list management software dropped
several previous "please add me" requests) and ... nothing!!


Patches #1 and #2 seem to be in the wrong order ... and
#2 shouldn't give the header's full pathname.  I'd have
merged the two, myself.

Patch #6 seems to remove LEDS_ATMEL_PWM from Kconfig but
leave the driver around ... and restore the now-deleted
LEDS_CORGI support (leds-gpio suffices).  If you're going
to remove LEDS_ATMEL_PWM you should update the code in
mach-at91/leds.c which sets up for that driver...


> So, what's the next step?  How do I advocate for getting
> this API into mainline? 

The number of backing implementations seemed a bit low ...
just one.  And that's switching Atmel's dedicated PWM, but
not the other PWM driver in the tree (for PXA); so it's
not terrifically accessible.	

And even for Atmel's SOC's it seemed a bit light:  the TC
blocks will do PWM quite happily, and are found on many
more chips than the dedicated PWM hardware.

My rule of thumb is that it's not worth considering a
framework as being general enough until it's got three
fairly different backing implementations.  Two is enough
to consider merging, especially with complicated drivers.

Plus the number of framework users is an issue.  The
PWM led driver is a good demo for two basic features,
and it's useful:  brightness (duty cycle beyond visual
perception) and blink rate (duty cycle easily seen with
the eye).  But it's still only really one API customer,
even given that new LED trigger...

So I'd suggest fleshing it out a bit more, so it works
on some non-Atmel hardware as well as more Atmel SOCs.
And fix the goofs I noted above.  :)

- Dave