- From: Michal Dobes <dobes_at_tesnet.cz>
- Date: Wed, 29 Jan 2003 21:56:21 +0100
Frank Mori Hess wrote: > I replaced comedi_buf_put() (which should really be given a quick death at > this point) with calls to cfc_write_to_buffer() and > cfc_write_long_to_buffer() as appropriate, in cvs. > Would you try that? At first - the driver now works correctly. At second - cfc_write_long_to_buffer() is twice slowest that incorrect comedi_buf_put() from 0.7.66 version and about few microseconds fastest that my solution with disabling 32 bit transfers. :-) > It still may be too slow though, in which case you would need to either use > cfc_write_array_to_buffer() which I would describe as "more than fast > enough", if you arrange your driver to copy the data in chunks. I'll look on the array functions and try some tests with them. My problem is, that I need by FTL - fastest that light. :-( > Or you could > do a bit of work to make the driver do a zero copy dma directly into comedi's > buffer (like ni_pcimio.c does). The zero copy is problematic with these cards, I need sidetrack some hardware errors in these cards and I must for this in some cases transfer a bit more samples that is stored in comedi buffer as result. In this case there can be funny problems with data overlaping and complex logic for selecting destination of the next DMA transfer. :-(( > I also noticed that your driver seems to do a bit of byte swapping on the > data, making assumptions about the cpu's byte ordering? If this is the case, > you should really use the cpu-independent byte swaping functions provided by > the kernel, such as le16_to_cpu(), etc. Yes, I know about this. This can be done in AMCC S5933 chipset for some cases directly during DMA transfer (if driver will knows on which architecture runs). Majkl
Received on 2003-01-29Z20:56:21