On Tue, Nov 17, 2009 at 8:39 AM, Bill Gatliff <bgat@xxxxxxxxxxxxxxx> wrote: > Grant Likely wrote: >> Hi Bill >> >> On Wed, Oct 15, 2008 at 11:14 AM, Bill Gatliff <bgat@xxxxxxxxxxxxxxx> 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. >>> >> >> Hey Bill, >> >> 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. > > It's true that PWM signals can be emitted via GPIO pins, and in fact the > API code I submitted uses the GPIO API combined with an hrtimer to > generate a low-speed PWM output. > > It's also true that things like LEDs might want to be driven by PWM > signals, and indeed LEDs can also be driven by GPIO pins. > > Finally, it's accurate to say that a lot of microcontrollers multiplex > GPIO functions onto pins that also provide PWM functionality. > > But in my opinion, none of the above means that the PWM API and GPIO API > should be coupled at the interface abstraction. All it means is that in > some cases, one implementation might be able to "stand in" as an > embodiment of the other's interface. And we all agree on that for PWM > and GPIO. I have no problem with the PWM API. I think it describes most of the PWM *usage* requirements well, and I agree that GPIO devices can never implement the PWM API. > Given a PWM-capable chip that you control over an I2C or SPI interface, > I don't think anyone would argue that such chips should be viewed as an > extension of the SPI or I2C APIs just because the chips use those > communications protocols. Nor would I. > I think it's a similar argument for PWM and GPIO. I don't think that's true, but I'm approaching it from the viewpoint of managing pins; not the usage API. ie. the difference between gpiolib (management) and the gpio api (usage). g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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
