Trying to DMA data from PCI bus to IDE

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I'm trying to use a PC104 IO board that utilizes the PLX PCI9080 chip
to handle DMA transfers across the PCI bus to the rest of the PC104
stack.  I've been able to take the data from the IO board, DMA it to
memory, and then use the regular Linux functions to write it to the
hard drive.  Even though my drive is using the highest UDMA settings
(ATA66 for a solid state drive) and have tweaked the hdparm, it seems
as if there's too much Linux file overhead involved to get it any
faster -- especially because I'm trying to "stream" lots of data
really fast for an extended time period to anywhere on the drive
(I'll deal with the partitions and FAT later).  It seems as if Linux
"waits" for about 5sec before it starts to write ANYTHING to the
drive.  Even if I turn off all of the caching settings in hdparm.
This tells me that it's a caching technique specific to the kernel
that *hopefully* I can turn off.

So, Does anyone know of/have ideas about a way to configure the
PCI9080 chip or similar chip to DMA that data to a single address in
memory?  I've set up the drive to receive data via DMA data and write
it to specific sectors so then the PCI9080 would need to be "pointed
to" a single location in memory (0x1f0 to be exact for the primary
IDE).  I've been trying everything, but I think there might be
something having to do with how Linux maps the addresses in virtual
memory vs. physical for the PCI9080.

Effectively, it should be set up to pull the data from the PCI source
(a FIFO address on the IO board) and perform a DMA transfer to memory
while NOT incrementing the destination address.

Any help is GREATLY appreciated.  Thanks.

Re: Trying to DMA data from PCI bus to IDE
Quoted text here. Click to load it

After I tweaked the values in /proc/sys/vm (bdflush in particular)it
looks like I can't achieve the transfers to occur as I need them.
There's still too much file overhead.  I can watch as the program
sends multiple buffers to the disk to be written and then it pauses
for a moment.  I'm essentially looking to have the buffer in memory be
set up for the UDMA transfer and then I leave to grab the next chunk
of data while the drive in busy.

Even when I set up a raw device write (seperate partition, no
formatting, on hda2) it still has trouble bypassing the caching system
-- bdflush's parameteres still govern the transfers.  Do you know of a
way to make a system/kernel call that can just perform the direct
transfer?  I haven't searched the many levels of writing to a file,
but I'm sure that somewhere far down the abstraction there's a place
where a buffer in memory is called to be written to disk.

Quoted text here. Click to load it

Yeah, I considered that as the most viable FAT update method (just
using FAT32 so that it's easy to serve up in SAMBA and not complicated
to control).  I'd still have to go back to the file entry and adjust
the size accordingly, though.

If all this doesn't work, I'll have to try to control the UDMA
transfer myself.  Can this be accomplished using the IDE Bus Mastering
standard?  I
think this feature is part of PCI 2.2 and intrinsic to the SiS630ST
chipset that I'm using.  If so, is this the way to go about performing
a UDMA
transfer?

Thanks again,
Greg

Site Timeline