From: Bodo Eggert <hidden> Date: 2007-05-06 12:20:59
Robin Getz [off-list ref] wrote:
On Fri 4 May 2007 16:52, Robert Schwebel pondered:
quoted
On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
quoted
quoted
We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA),
that would be nice to put in the "right" place - I don't think that
drivers/char is the right place, nor drivers/misc - I also don't think
that /adc is a descriptive place for DAC or mixed signal front ends
(MxFE).
What userspace interface do your drivers have?
Right now, it is a little rudimentary char interface, it needs a little care
to be a bit more general purpose, but it suited needs of what the people who
were using it.
[...]
I would be interested in having a detailed discussion/random thoughts on
this - what is the best way to expose these types of devices?
Since you ask for random thoughts:
IO of data streams from or to a DAC/ADC is essentially what soundcards do.
I'm wondering if these cards are similar enough to use alsa, and if using
that interface would ease or hinder programming the driver.
--
Top 100 things you don't want the sysadmin to say:
76. I have never seen it do *that* before...
Friß, Spammer: BZmk0Kx63V@ld7M4m.7eggert.dyndns.org
From: Paul Sokolovsky <hidden> Date: 2007-05-06 13:20:36
Hello Bodo,
Sunday, May 6, 2007, 3:19:59 PM, you wrote:
Robin Getz [off-list ref] wrote:
quoted
On Fri 4 May 2007 16:52, Robert Schwebel pondered:
quoted
On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
quoted
quoted
quoted
We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA),
that would be nice to put in the "right" place - I don't think that
drivers/char is the right place, nor drivers/misc - I also don't think
that /adc is a descriptive place for DAC or mixed signal front ends
(MxFE).
What userspace interface do your drivers have?
Right now, it is a little rudimentary char interface, it needs a little care
to be a bit more general purpose, but it suited needs of what the people who
were using it.
[...]
quoted
I would be interested in having a detailed discussion/random thoughts on
this - what is the best way to expose these types of devices?
Since you ask for random thoughts:
IO of data streams from or to a DAC/ADC is essentially what soundcards do.
I'm wondering if these cards are similar enough to use alsa, and if using
that interface would ease or hinder programming the driver.
FYI, within handhelds.org kernel project, we also saw the need
for consistent ADC infrastructure, and developed such, based on
classdev concept, on todo to be submitted for review. Our
API/userspace interface however optimized for individual (or
fixed-batch) readings over stream operations, our target usage
are touchscreen, battery, hwmon drivers.
--
Best regards,
Paul mailto:pmiscml@gmail.com
From: Robert Schwebel <hidden> Date: 2007-05-06 16:01:22
On Sun, May 06, 2007 at 02:19:59PM +0200, Bodo Eggert wrote:
Since you ask for random thoughts:
IO of data streams from or to a DAC/ADC is essentially what soundcards do.
I'm wondering if these cards are similar enough to use alsa, and if using
that interface would ease or hinder programming the driver.
I had a short look at ALSA and it looks like it is a little bit too
focussed towards "normal" audio. For example, if follows an asynchronous
model in the sense that an application can read/write to a buffer at any
time, taken that the ringbuffer doesn't overflow. That's not enough for
example for control applications; you need the option for real
synchronous operation there.
IMHO we need an API which offers
- kernel ring buffers (to make it sure no data gets lost)
- generic data types (streaming plain ADC values is just the simplest
case; we also have for example streaming FPGA data containing
preprocessed data sets)
- optional timestamping for each sample
- zero-copy from hardware into userspace memory, with DMA support
- application notification every N samples (N >= 1)
v4l2 may also be worth a look; but in the end I suppose they are all
specialized sub-cases of what we'd need for fast DAQ.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
From: Robin Getz <hidden> Date: 2007-05-06 19:31:23
On Sun 6 May 2007 12:01, Robert Schwebel pondered:
On Sun, May 06, 2007 at 02:19:59PM +0200, Bodo Eggert wrote:
quoted
Since you ask for random thoughts:
IO of data streams from or to a DAC/ADC is essentially what soundcards
do. I'm wondering if these cards are similar enough to use alsa, and if
using that interface would ease or hinder programming the driver.
I had a short look at ALSA and it looks like it is a little bit too
focussed towards "normal" audio. For example, if follows an asynchronous
model in the sense that an application can read/write to a buffer at any
time, taken that the ringbuffer doesn't overflow. That's not enough for
example for control applications; you need the option for real
synchronous operation there.
Yes - there are too many applications which require tight/sync connection with
the data - control loops, software radios, machine control, etc - all have
much different needs than audio, hwmon, or touchscreen.
IMHO we need an API which offers
- kernel ring buffers (to make it sure no data gets lost)
- generic data types (streaming plain ADC values is just the simplest
case; we also have for example streaming FPGA data containing
preprocessed data sets)
- optional timestamping for each sample
- zero-copy from hardware into userspace memory, with DMA support
I am assuming that the driver takes care of all DMA/coherency issues that
might pop up? (and handles all interrupts)?
- application notification every N samples (N >= 1)
v4l2 may also be worth a look; but in the end I suppose they are all
specialized sub-cases of what we'd need for fast DAQ.
I would guess that something like v4l might be the best bet - the driver
provides a few mmapped buffers that you can read/write into, and some
mechanism to sync in/out of the buffers.
I was actually looking at UIO, but thought that since we really desire the
kernel ring buffers, that a think model might be better.?
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/uio-documentation.patch
-Robin
On Fri 4 May 2007 16:52, Robert Schwebel pondered:
quoted
On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
quoted
quoted
quoted
We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA),
that would be nice to put in the "right" place - I don't think that
drivers/char is the right place, nor drivers/misc - I also don't think
that /adc is a descriptive place for DAC or mixed signal front ends
(MxFE).
What userspace interface do your drivers have?
Right now, it is a little rudimentary char interface, it needs a little care
to be a bit more general purpose, but it suited needs of what the people who
were using it.
If I were thinking about a DAC / ADC API I would have a look at Comedi -
somehow I think it should be pretty well designed...
Thanks
Guennadi
---
Guennadi Liakhovetski