Mike Frysinger wrote: > > the Blackfin timers/pwm's can flip between input and ouput based on > the configuration register. everything else (pin/etc...) is > unchanged. Interesting! >> 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. ;) > 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. 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! 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
