Re: rtlinux dma get_buffer_contents number of bytes transferred

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 06 March 2004 10:01 pm, Alex Fielding wrote:
> I am using cmd (comedi 0.7.67) to initiate a continuous A/D acquisition
> in an RTLinux (3.1) kernel module (with the ni_pcimio driver and a
> National Instruments PCI-MIO-16E-1 board).  After some review of the
> list I've managed to successfully read the preallocated buffer (by first
> performing a comedi_map(), cmd.data=NULL, and
> cmd.data_len=map_size*sizeof(sampl_t)), but I am still unclear on the
> best way to periodically read and flush out the buffer contents.
>
> I have seen several posts to this mailing list indicating that
> get_buffer_contents, get_buf_head_pos, and get_buffer_offset do not
> return the number of bytes transferred when called on the kernel side
> (kcomedilib) (in my test program I get values of zero returned all the
> time).  I also have seen references to calling mite driver routines and
> minimum block sizes for the dma transfers but I am not entirely clear on
> what's happening there.  Will someone explain?
>
> I need to know the number of bytes transferred accurately.  When running
> continuous acquisition in user-space we call get_buffer_contents and
> mark_buffer_read.  How can I accomplish the similar task in the
> real-time kernel module?
>

Those functions should work when called from kcomedilib also.  The number 
of bytes transferred will only get updated when the mite generates an 
interrupt though.  To do better would require supporting comedi_poll() for 
dma transfers in the driver (which would actually be pretty trivial to do 
at this point).

- -- 
Frank

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAUQrU5vihyNWuA4URArcXAJ9GzfVDvTufg5/jK2H2RsQR6MoyhACgwLKT
tthfETeSh+msiyygvVnOHSc=
=SpmH
-----END PGP SIGNATURE-----

Received on 2004-03-12Z00:56:49