comedi todo list

Tabish Mustufa tabishm at
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

* 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> 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.


More information about the devel mailing list