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. The reason I think that PWM merits its own API is because I want the users of the interface to be able to treat it as a PWM-only metaphor. Behind the scenes, we may in fact have a connection with the GPIO interface--- and in fact we already do with my code. But PWM generation can also come from timer/counter peripherals having a compare/match capability, from true PWM generation hardware (which are in most cases just three tightly-coupled timer/counters with compare/match hardware), as well as from standalone chips that are controlled over an I2C or SPI interface. The latter example is in fact the initial motivation for the code, even though at the moment I don't have any patches available to submit because the devices in question are 8-bit microcontrollers running custom firmware. 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. I think it's a similar argument for PWM and GPIO. Overall, I think your question is a very good one and it's one that I asked myself early on. And it's a question that we should ask for EVERY new interface abstraction that's developed for kernel-facing or application-facing users. > 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". > I hope my reasoning is clear. I might not be right, but at least you know what my thoughts are. Questions, comments and flames welcome! b.g. -- Bill Gatliff bgat@xxxxxxxxxxxxxxx -- 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
