Re: [RFC 0/6] Proposal for a Generic PWM Device API

["Mike Frysinger" <vapier.adi@gmail.com>]

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