On 05.07.2017 23:30, Didier Kryn wrote:

> And there are a whole menagerie of addressing and transfer protocols, > including chained dma transfers

Especially things like DMA are naturally kernel domain. I wouldn't ever
allow any direct access to dma controllers from userland.

> In our case it is waveform digitizers and the interaction is so > complex that it cannot be done in a kernel module

What exactly is so complex about that ? Smells like a typical task
for IIO to me.

Some others consider there should be one driver per VME device you
> want to talk to, on top of the raw VME driver.

Exactly.

These people only ever had to deal with simplistic devices. Gabriel Paubert has never seen an application transfering more than a few bytes, while we are transferring data at 320MB/s.

Those kind of things usually involve proper timing, caring about
caching, etc, etc. Natural kernel domain.

Which absurdities, exactly ?
Bus errors were not reported to the application but instead caused a message to syslog! This makes it hard to use; or your application should monitor the log files!

Yes, that's hackish, of course.

This isn't the case here. AFAIU, their BSP contains a VME driver and a device tree. I think it's all GPL. Their buzyness is to send hardware and they make sure their clients can use it.

Looks like your vendor is an exception.

These are SBCs with everything soldered: VME, flash memory, UARTs, USB hub, Sata controllers, Ethernet ports etc... And you just plug it into a VME crate. It makes no sense to develop a board like this to use a dozen of them. We made the digitizers and it was already a big deal for our small team.

Could you develop what is IIO for DAQ devices?

What's the difference between you digitizes and usual DAQ devices ?
What do you actually do with them ?

Some clear requirements on the table, please ;-)

Is it something allowing to write drivers in user space?

What kind of drivers do you wanna have in userland ? And why ?


--mtx
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to