On Wed, 25 Apr 2007, H. Peter Anvin wrote:
>
> That was the 1990s. On a brand new server system:
>
> 00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA
> Engine (rev b1)
>
> For better or worse, slave DMA seems to be making a comeback of sorts.
> Not to mention all kinds of embedded crap^Whardware with optimized DMA
> engines which look nothing like PCI at all.
Well, the solution to that tends to be to just leave them be, and hold
them on until the very end - and just ignore them (and just make-believe
that it's actually the device itself that does the DMA transfer).
The PCI spec for controlling DMA is really pretty nasty. You can disable
it in the PCI config word, of course, but that usually just messes up the
device entirely.
So in practice, the way to shut up DMA (regardless of whether it's an
internal DMA engine or an external one) is that you just tell the device
not to listen any more (for example, for a network controller, the way to
make sure it doesn't do DMA is just to make sure that you're not sending
any frames, but also that it's not listening to any either)!
So whether it's internal to the device, or some "system DMA controller",
the sequence for shutting down DMA always ends up being the same:
- make sure the host itself doesn't generate any new traffic (eg shut
down the send-queue). This is generally a higher-level thing anyway, ie
not really a driver decision.
- the driver needs to tell the hardware to stop listening (ie "stop
scanning the command mailboxes" or "stop walking USB command
structures" or "stop receiving data")
- the driver then needs to wait for the controller to say "ok, I'm idle".
because regardless of whether it's the system DMA controller or some
on-chip DMA controller, you generally can *not* just say "stop
transferring DMA data", because that will generally just lock the chip up
or cause other major unhappiness.
So I don't think an external DMA controller (like the i8237, ugh!) really
_changes_ anything. Except for just the horrible pain of serializing
access to them for programming etc horrible resource handling issues, of
course (but that's not specific to suspend/resume).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
