On Thu, Oct 9, 2008 at 00:18, Bill Gatliff wrote: > 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. :(
i'll probably look at the Blackfin-pwm core soonish ... we already implemented a generic framework for it (look for "gptimers"), so it shouldnt take too much time to transition code for it. >> 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? only part on Kconfig i think we'll need is each implementation selecting "GENERIC_PWM_INPUT" and "GENERIC_PWM_OUTPUT". are we looking towards having multiple master implementations being usable simultaneously ? otherwise, i dont think defining things in terms of "generating" and "measuring" is really needed ... "input" and "output" seems straightforward enough. > 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. the current generic core looks like it could handle this easily enough since we're working with an array of function pointers. -mike -- 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
