comedi todo list
Tabish Mustufa
tabishm at gmail.com
Wed Oct 31 06:40:17 UTC 2007
Hello again folks:
So it seems that there is some traction for bringing the comedi
drivers into the mainline kernel. I thought I'd start to put together
a list of items we may want to tackle. Let us know if you think these
are good or bad ideas...
* Cleanup and documentation for or removal of items listed under "4.7.
Experimental functionality" in the comedilib documentation. In
particular, analog triggering seems like a feature we should support.
* Support for having a subdevice that can do both input and output commands
* Documentation of the interface for "pulse-based signals". Do we
have a well-baked API for counters, timers, encoders, PWM signals,
etc? For what it's worth, I found it confusing last time I looked at
it.
* Removal of "slowly-varying input" filtering
* A better mechanism for adding extensions than INSN_CONFIG
* Use of plug-n-play/hotplug capabilities to remove need for
comedi_config when possible
* Improved driver portability: consistent use of u32, etc
>From Frank Mori Hess:
> First, the protocol for doing output commands needs to be changed (again).
> The current scheme of doing: "command, load buffer, internal trigger"
> doesn't translate to support external triggers. We need "command, load
> buffer, arm". Then for start_src=TRIG_NOW the command would start
> immeditately upon arming, analogously to how start_src=TRIG_INT works now.
> For start_src=TRIG_EXT, the arm step would allow the analog output fifo to
> be loaded or dma transfer initiated, and the board configured to start on
> the external trigger input.
Some cosmetic things:
* Removal of typedefs; e.g. use of "struct comedi_subdevice" instead
of "typedef struct comedi_subdevice_struct comedi_subdevice".
* Removal of lsampl_t and sampl_t in favor of u32 and u16? This would
only affect the kernel to comedilib interface -- comedilib should
continue to use lsampl_t.
* Removal of any legacy kernel function/struct/define names. (At
first glance, the older-kernel support is done quite cleanly, so
hopefully this is a no op).
* Whitespace cleanup
On 10/19/07, Bernd Porr <BerndPorr at f2s.com> wrote:
> A while ago I had integrated comedi into the early 2.6.x kernels.
> I might find the sed script somewhere which converted the
> comedi drivers on the fly to fit into the kernel.
Bernd, if you could find this script, it might be useful.
-Tabish
More information about the devel
mailing list