On Fri, Nov 13, 2009 at 14:08, Grant Likely wrote: > On Wed, Oct 15, 2008 at 11:14 AM, Bill Gatliff wrote: >> This series implements a Generic PWM Device API, including reference >> implementations for the Atmel PWMC device, an LED device, and an LED >> trigger. It is based on linux-2.6.27. > [...] >> The implementation of the Generic PWM Device API is structurally >> similar to the generic GPIO API, except that the PWM code uses >> platform bus_id strings instead of integers to identify target >> deviices. A configuration structure is also provided, both to >> facilitate atomic hardware state changes and so that the API can be >> extended in a source-code-compatible way to accomodate devices with >> features not anticipated by the current code. > > I'm concerned about the approach taken here. As I understand it, the > PWM signals are very similar to GPIOs in that each PWM device controls > an external signal line, just like GPIO lines. The difference being > that PWMs cannot do input, and has additional capabilities (can be > programmed with a signal; not just on/off/tristate). Actually, many > GPIOs have these properties too. I've got a part with output-only > gpios, and gpio devices that also have a PWM. > > What is the reason for bringing in an entirely new framework instead > of extending the GPIO API or gpiolib? I'm not too excited about > having two entirely different frameworks for what basically boils down > to "numbered signal pins". unifying resource management obviously makes sense so as to avoid conflicts, but i dont think the fact that one pin can be multi purpose means it should be entirely forced into the GPIO framework, nor do i see any real gain for doing so. -mike -- 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
