Hi all,
I'm in the stage of integrating some ADC and DAC drivers for the AMCC 405EZ
PPC and looking for the correct location to place these drivers in the Linux
source tree. The drivers are basically character-drivers, so my first thought
is to put them in "drivers/char/adc/foo.c" or "drivers/char/adc_foo.c". Is
this a good solution?
Any suggestions welcome (could be that I missed an already existing example).
BTW: I am aware of the hwmon subsystem, but I don't think it fits my needs in
this case.
Best regards,
Stefan
On Tue, 1 May 2007, Stefan Roese wrote:
> I'm in the stage of integrating some ADC and DAC drivers for the AMCC 405EZ
> PPC and looking for the correct location to place these drivers in the Linux
> source tree. The drivers are basically character-drivers, so my first thought
> is to put them in "drivers/char/adc/foo.c" or "drivers/char/adc_foo.c". Is
> this a good solution?
drivers/mfd following ucb1x00?
Thanks
Guennadi
---
Guennadi Liakhovetski
On Tuesday 01 May 2007 23:03, Guennadi Liakhovetski wrote:
> On Tue, 1 May 2007, Stefan Roese wrote:
> > I'm in the stage of integrating some ADC and DAC drivers for the AMCC
> > 405EZ PPC and looking for the correct location to place these drivers in
> > the Linux source tree. The drivers are basically character-drivers, so my
> > first thought is to put them in "drivers/char/adc/foo.c" or
> > "drivers/char/adc_foo.c". Is this a good solution?
>
> drivers/mfd following ucb1x00?
Perhaps. Not sure though. I just checked again and I still think the drivers
will better fit for "our" drivers because of the chrdev nature.
Is there a maintainer for this "drivers/mfd" directory?
Thanks.
Best regards,
Stefan
On Wed, May 02, 2007 at 12:25:53PM +0200, Stefan Roese wrote:
> Is there a maintainer for this "drivers/mfd" directory?
rmk
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
On Wed, May 02, 2007 at 03:35:12PM +0200, Robert Schwebel wrote:
> On Wed, May 02, 2007 at 12:25:53PM +0200, Stefan Roese wrote:
> > Is there a maintainer for this "drivers/mfd" directory?
>
> rmk
I wouldn't go that far. There's no real infrastructure there
to maintain, so I'd actually say that the directory was
maintainerless. However, I'll own up to the UCB/MCP drivers
in there.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Wednesday 02 May 2007 21:11, Russell King wrote:
> > > Is there a maintainer for this "drivers/mfd" directory?
> >
> > rmk
>
> I wouldn't go that far. There's no real infrastructure there
> to maintain, so I'd actually say that the directory was
> maintainerless. However, I'll own up to the UCB/MCP drivers
> in there.
So perhaps you could answer is you feel that these ADC & DAC chrdev device
drivers would fit into this drivers/mfd directory, or are better suited for
the drivers/char directory?
Thanks.
Best regards,
Stefan
On Fri, May 04, 2007 at 08:11:42AM +0200, Stefan Roese wrote:
> On Wednesday 02 May 2007 21:11, Russell King wrote:
> > > > Is there a maintainer for this "drivers/mfd" directory?
> > >
> > > rmk
> >
> > I wouldn't go that far. There's no real infrastructure there
> > to maintain, so I'd actually say that the directory was
> > maintainerless. However, I'll own up to the UCB/MCP drivers
> > in there.
>
> So perhaps you could answer is you feel that these ADC & DAC chrdev device
> drivers would fit into this drivers/mfd directory, or are better suited for
> the drivers/char directory?
No idea; firstly I've long since deleted the email, secondly I've not much
interest in the directory itself, and thirdly I've enough patches to review
already. Finally, I'm out all day today, including the evening. I doubt
I'll read any further email until the weekend.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, May 01, 2007 at 02:35:44PM +0200, Stefan Roese wrote:
> I'm in the stage of integrating some ADC and DAC drivers for the AMCC
> 405EZ PPC and looking for the correct location to place these drivers
> in the Linux source tree. The drivers are basically character-drivers,
> so my first thought is to put them in "drivers/char/adc/foo.c" or
> "drivers/char/adc_foo.c". Is this a good solution?
>
> Any suggestions welcome (could be that I missed an already existing
> example).
>
> BTW: I am aware of the hwmon subsystem, but I don't think it fits my
> needs in this case.
Could you elaborate the requirements a bit more? ADC is not ADC, because
slow i2c ADCs which measure a temperature every five minutes have other
requirements than multi-megabyte-per-second-dma-driven ADCs.
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
On Friday 04 May 2007 10:24, Robert Schwebel wrote:
> On Tue, May 01, 2007 at 02:35:44PM +0200, Stefan Roese wrote:
> > I'm in the stage of integrating some ADC and DAC drivers for the AMCC
> > 405EZ PPC and looking for the correct location to place these drivers
> > in the Linux source tree. The drivers are basically character-drivers,
> > so my first thought is to put them in "drivers/char/adc/foo.c" or
> > "drivers/char/adc_foo.c". Is this a good solution?
> >
> > Any suggestions welcome (could be that I missed an already existing
> > example).
> >
> > BTW: I am aware of the hwmon subsystem, but I don't think it fits my
> > needs in this case.
>
> Could you elaborate the requirements a bit more? ADC is not ADC, because
> slow i2c ADCs which measure a temperature every five minutes have other
> requirements than multi-megabyte-per-second-dma-driven ADCs.
The hardware (PPC405EZ) actually implements an high speed, dma capable, ADC
controller with 10-bit resolution and up to 4MHz sample rate. The current
driver doesn't support all these features though (dma is not supported right
now for example). Could be that this will be added in future releases. It
would be good though, to have the driver located at the "correct" place in
the kernel tree right away.
Best regards,
Stefan
On Fri 4 May 2007 04:54, Stefan Roese pondered:
> On Friday 04 May 2007 10:24, Robert Schwebel wrote:
> > On Tue, May 01, 2007 at 02:35:44PM +0200, Stefan Roese wrote:
> > > I'm in the stage of integrating some ADC and DAC drivers for the AMCC
> > > 405EZ PPC and looking for the correct location to place these drivers
> > > in the Linux source tree. The drivers are basically character-drivers,
> > > so my first thought is to put them in "drivers/char/adc/foo.c" or
> > > "drivers/char/adc_foo.c". Is this a good solution?
> > >
> > > Any suggestions welcome (could be that I missed an already existing
> > > example).
> > >
> > > BTW: I am aware of the hwmon subsystem, but I don't think it fits my
> > > needs in this case.
> >
> > Could you elaborate the requirements a bit more? ADC is not ADC, because
> > slow i2c ADCs which measure a temperature every five minutes have other
> > requirements than multi-megabyte-per-second-dma-driven ADCs.
>
> The hardware (PPC405EZ) actually implements an high speed, dma capable, ADC
> controller with 10-bit resolution and up to 4MHz sample rate. The current
> driver doesn't support all these features though (dma is not supported
> right now for example). Could be that this will be added in future
> releases. It would be good though, to have the driver located at the
> "correct" place in the kernel tree right away.
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 about /drivers/char/daq or just drivers/daq - drivers for
non-PCI/USB/ISA/PCMCIA Data Acquisition Hardware, D/A and A/D converters,
Analog Front ends, etc.
I think that is the common TLA - at least according to
http://en.wikipedia.org/wiki/Data_acquisition
?
-Robin
Robin,
On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
> 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? I don't think that there
is anything generic available at the moment, other than COMEDI (which is
rather outdated as far as I know).
> What about /drivers/char/daq or just drivers/daq - drivers for
> non-PCI/USB/ISA/PCMCIA Data Acquisition Hardware, D/A and A/D
> converters, Analog Front ends, etc.
I'd like drivers/daq better, because it doesn't have anything to do with
the bus it is connected to; a chipselect bus connectable ADC may be
connected to a SoC CS-bus or to a PCI bridge and you want to use the
same driver for it.
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
On Fri 4 May 2007 16:52, Robert Schwebel pondered:
> Robin,
>
> On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
> > 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.
http://blackfin.uclinux.org/gf/project/linux-kernel/scmsvn/?view=markup&path=/trunk/drivers/char/ad9960.c
> I don't think that there
> is anything generic available at the moment, other than COMEDI (which is
> rather outdated as far as I know).
I would be interested in having a detailed discussion/random thoughts on
this - what is the best way to expose these types of devices?
I never actually used COMEDI, to understand the pro/cons of what it did.
> > What about /drivers/char/daq or just drivers/daq - drivers for
> > non-PCI/USB/ISA/PCMCIA Data Acquisition Hardware, D/A and A/D
> > converters, Analog Front ends, etc.
>
> I'd like drivers/daq better, because it doesn't have anything to do with
> the bus it is connected to; a chipselect bus connectable ADC may be
> connected to a SoC CS-bus or to a PCI bridge and you want to use the
> same driver for it.
That makes sense - I have seen more and more parts with selectable interfaces
(I2C or SPI), and you should be able to use the same base driver, independent
of the bus - so drivers/daq would suite me fine.
-Robin
Robin Getz <[email protected]> wrote:
> On Fri 4 May 2007 16:52, Robert Schwebel pondered:
>> On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
>> > 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: [email protected]
Hello Bodo,
Sunday, May 6, 2007, 3:19:59 PM, you wrote:
> Robin Getz <[email protected]> wrote:
>> On Fri 4 May 2007 16:52, Robert Schwebel pondered:
>>> On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
>>> > 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.
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:[email protected]
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
On Sun 6 May 2007 12:01, Robert Schwebel pondered:
> 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.
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 Sun, 6 May 2007, Bodo Eggert wrote:
> Robin Getz <[email protected]> wrote:
> > On Fri 4 May 2007 16:52, Robert Schwebel pondered:
> >> On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
>
> >> > 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