Umm, I think you missed the point.
My point was _exactly_ that the 3.11 drivers do NOT use (U)DMA, yet they
obviously are expected to work anyway.
So whatever the BIOS does to enabled (U)DMA does not _require_ that you
use (U)DMA. A driver that choses to ignore DMA will work correctly, and
the argument that the BIOS has set up some internal registers for DMA
does _not_ mean that you have to use DMA only because the BIOS tells you
it has set it up.
>What you will see are Windows 95 DMA Bus Mastering drivers. Those set
>safe timings which might not be available from the BIOS initialization
>routines.
Again, this is exactly my point. We're being too aggressive by default:
we use DMA (even though we don't have to), and we probably use fairly
aggressive DMA timing settings too, judging by some of the code in the
ide drivers (grep for "bus_speed", for example, and notice how a comment
says that a system_bus_speed setting of 40 is "safe" on PCI. It's
nowhere close to safe - if we assume that the system bus speed is 40 and
it really is 66MHz PCI, we're now completely off).
>Most recent BIOSes report this in their boot message. They may also be
>setting timing parameters for (U)DMA transfers. I can give you at least
>one example: the ASUS SP-97V motherboard.
So? Who tested those timing parameters? Let me suspect that the
parameters were tested on a Win95 system where both the memory bus and
the PCI bus are essentially idle durint all disk transfers.. Especially
as win95 isn't exactly known for having blazingly fast disk IO, so the
timings weren't even verified under very heavy load, were they?
So are you willing to guarantee that the timings are safe if there is
something else going on in the system?
So I suspect we're too aggressive.
Btw, if you assume that BIOS writers know what they are doing, you
should think twice. They make sure it works under DOS and Windows, and
very very little else. The same is true of the people that put the
machines together - at _no_ point in time is there generally anybody who
actually looks at the physical timings.
Linus
-
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