Mike Frysinger wrote: > if you'd seriously play with a Blackfin board, i think we can arrange that
I'd seriously *love* to play with one, but I'm pretty strapped for time for another couple of months. The only purpose it would serve near-term would be to prove out the input capabilities of a device that I probably wouldn't have time to write a driver for. :( > 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. Good point. I think I'm sold on the idea now. We'd need a PWM_CONFIG_<something> to tell the hardware to switch to "measurement mode" if such a mode is supported (suggestions for <something> welcomed). The config function would return an error if the measurement mode wasn't supported by the device. PWM_CONFIG_INPUT and PWM_CONFIG_OUTPUT, perhaps? In output mode, the pwm_get_*() methods would return the driven values if the device didn't support a (simultaneous) measurement mode, or cached values if the device's configuration registers were write-only. In measurement mode, they'd return the measured values. I think this'll work. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
