lkml.org 
[lkml]   [1998]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.1.111: IDE DMA disabled?
Richard B. Johnson wrote:

> > As per Linus' comment in another email, it does make a difference, it not in
> > the cable timings, then in other timings relating to the transfer. Probably
> > not the least of which is memory congestion. In any case, it does make a
> > difference.
> >
> > --
> >
>
> PIO and DMA, at the bus level, use the exact same mechanisms. The
> advantage of DMA is that, if a driver is coded to handle this, the
> CPU can do other things while the DMA transfer is occurring.

Dude, that's what memory congestion is all about. What exactly did you
think I was talking about? When a device is using Bas-Mastering DMA, it
access memory all by itself while the CPU is free to do other things. If
the CPU is also accessing memory, then you have more memory read/writes
occuring in a fixed period of time up to the maximum memory bandwidth.
Using PIO instead, the CPU is busy hand holding the transfer and as a
result, you can not have combined memory access, but instead access is
serialized.

Now, having said that, yes the signals across the PCI bus would be the same
for PIO or DMA (in terms of timing from leading edge of blah signal to
blah). However, that's only one part (and a minor one at that) of the
entire scenario. This view neglects the memory congestion already
mentioned, as well as possible flow control issues on the bus that can arise
due to delayed write and bursting issues, multiple devices wanting to talk
DMA at the same time, etc.

> PIO uses the CPU for the transfer, so the CPU is busy. The Port/RAM
> and RAM/Port speeds are identical if the CPU has a reasonable internal
> clock (like 33MHz and greater).

As mentioned, the whole issue of keeping the CPU busy with the transfer
instead of having it calculate RC5 keys at the same time raises a whole slew
of other timing issues not related to strict signal timing on the bus.

> For instance
> the BusLogic SCSI controller is very fast. The driver doesn't use DMA.
>
> Script started on Tue Jul 28 22:42:37 1998
>
> # cat /proc/dma
> 4: cascade
> # cat /proc/scsi/*
> cat: /proc/scsi/BusLogic: Bad file number
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
> Vendor: SEAGATE Model: ST32550W Rev: 0021
> [SNIPPED]

Dude, you're right the BusLogic *driver* doesn't use DMA (of course not, the
driver is already running on the CPU and accessing memory directly as
standard pratice :). But, the BusLogic cards *all* use bus mastering DMA.
Do you really think that Leonard's driver sits there in a busy loop
transfering data from some register to some data buffer? Hell no, you set
up the Scatter Gather addresses, send them to the card, then let the card
fill the memory itself. That is the essential element of DMA, the card is
directly accessing host memory to fill those buffers instead of just
presenting the bytes on some register for the host CPU to copy into RAM.
The fact that it doesn't show up in the /proc/dma file is simply because it
uses the DMA capabilities of the PCI bus which don't require any DMA
allocations in the DMA controllers.

--

Doug Ledford <dledford@dialnet.net>
Opinions expressed are my own, but
they should be everybody's.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.076 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site