On Wed, Oct 8, 2008 at 23:46, Bill Gatliff wrote: > Mike Frysinger wrote: >>> Are you proposing that the API accommodate both input and output devices? >> >> i dont think we should preclude it from the outset. > > I don't think have a problem with that. At some point, I would need someone > with input/output hardware to test the input-specific parts, however. Hint, > hint. ;) if you'd seriously play with a Blackfin board, i think we can arrange that >> not really, but i see the existing code you've posted could already >> utilize some of the "get" functions ... > > Which parts? I don't really like keeping the period_ticks and duty_ticks values > around, but in my case I have no choice--- unless I were to read the CPRE, CPRD > and CDTY values from the hardware directly. Which could be what your proposed > "get" methods would do. sorry, i misread the led driver. too many structures! :) > But that still isn't PWM "input" the way you are describing, because my hardware > wouldn't be _reading_ an incoming PWM: it would be just reporting back the > values that it was using to produce its output signal. Huge difference. > > I dunno, I'm still not sure that measuring the characteristics of an incoming > PWM signal isn't a different kind of device from one that produces PWM signals, > at least conceptually. Which, in a way, makes it out of scope for the proposed > API. Not saying I can't go along with the idea, I'm just not sure what a user > would expect to happen if they called pwm_get_period_ns() on the SAM9263 PWMC > device. They certainly aren't going to get a measured value in return! while true, hardware that can support PWM as both input/output would suffer from two frameworks. if there's ambiguity in behavior (using "get" in an output mode), then we can just stick it in the documentation and move on. the GPIO framework already has this behavior (set a pin to output and then try and read the data) and i dont recall it ever being an issue there. -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
