Grant Likely wrote: > > Common code is a big gain in and of itself. I completely agree! Which is why I used the GPIO API in my PWM pseudo-device, along with an hrtimer. > What I would like to see is the PWM functions added to the GPIO API. > GPIO drivers can then either implement them or not. If a GPIO driver > supports the PWM function, great. If not, then it returns -EINVAL. > Heck, I'll even got a driver right now that I'd use it with. I'm more > than happy to help code it up even. > I think the appropriate thing to do in such cases is to reimplement the GPIO driver at its lowest level to provide both GPIO API and PWM API interfaces. In my way of thinking, such hardware is a kind of multi-function device and it should be treated that way. No need to expose that multi-functionality to the user unless necessary. The odd case to me is the concept of "timed GPIO", as in the Android kernels. I see the timing capability as a convenience feature that could be realized by adding timers to the GPIO interface (as they did), or by having a one-shot PWM channel. I'm not really comfortable with either as an interface concept, however, because it just doesn't... feel right. :) 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
