Hi Kirill, > >Assuming a 'signal processing controller' means that there is > >a DSP or processor on the board, then these two regions probably > >correspond to regions of the DSP/CPU memory map on the > >board. > > > > > There is FPGA Xilinx on this card. Now i can read/write data to/from > this card. There are ZBT memeory and flash. I have access to all > register on this card. Now i need to use DMA channel. > > >Do you have information on the memory map of these two regions? > > > The first region is PLX register, second and third one are FPGA > register and FPGA memory. > Now to access to all os these register i use firsta of all > ioremap_nocache and after readb/writeb. Ah, ok, so you have a driver working to some degree under Linux then? What host CPU are you using? I thought ioremap_nacache was for PowerPC processors - but maybe I am wrong. > >I can send you a driver that finds the PLX-9054 device and allows > >you to memory map these regions. I can also show how to mmap > >the two other regions - this allows programmed I/O from > >user space - good for checking things out. > > > > > If it is not difficult for You, it was nice. I can modify my driver to work with this card for you. But first, lets decide how you want to use DMA. The best way to work out how the driver should act is to determine how you want to use it from user-land. For example, if you only ever want to use it in a blocking read() then you can do the following: - user-land read() call with a user-land buffer - buffer is mapped in the kernel using kiobuf facility - DMA controller is setup to write to the now kernel mapped buffer. Driver call waits on a wait-queue - DMA completed interrupt unblocks the wait-queue. - read() call completes and data is there for the taking. However, if you want to use a non-blocking read, since you may want to use more than one card, and use a select() call to determine which one is ready, then you need to have the driver allocate some buffers internally. (Since the DMA transfer happens first, then the select() call becomes read-able). Then you either setup the DMA controller to use a circular list of buffers, or use ioctl calls to setup the controller. read() is then used to transfer data from the kernel buffer to the user-land buffer. This requires that the CPU is involved in moving the data between the kernel and the user-land. I'm still looking for a way to avoid this copy. But perhaps it is not important as this copy is much faster than a transaction over PCI. An ioctl call that sends a user-space buffer to the kernel for kiobuf remapping before the select call may also be possible. I haven't played with the kiobuf facility yet. I haven't really found a driver that gives me a good example to work from either. If you have found one, let me know :) I won't have time to get you the driver source today, I'm tracking down a problem with some hardware I am working on. Keep up this discussion, and maybe send me a data sheet / engineering spec on your board (just send it to me directly at dwh@ovro.caltech.edu) and I'll put something together for you. For example, my driver looks for the PLX-9054 ID, so I'll need to add a load-time option of looking for your signal processing controller IDs. Dave -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
