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 -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
