diff options
author | David S. Miller <davem@davemloft.net> | 2005-06-02 12:55:50 -0700 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2005-06-27 21:52:45 -0700 |
commit | e24c2d963a604d9eaa560c90371fa387d3eec8f1 (patch) | |
tree | 66be193d59dd22fac0b62980769c4f19e045b5a2 /include/asm-h8300/local.h | |
parent | 2311b1f2bbd36fa5f366a7448c718b2556e0f02c (diff) | |
download | op-kernel-dev-e24c2d963a604d9eaa560c90371fa387d3eec8f1.zip op-kernel-dev-e24c2d963a604d9eaa560c90371fa387d3eec8f1.tar.gz |
[PATCH] PCI: DMA bursting advice
After seeing, at best, "guesses" as to the following kind
of information in several drivers, I decided that we really
need a way for platforms to specifically give advice in this
area for what works best with their PCI controller implementation.
Basically, this new interface gives DMA bursting advice on
PCI. There are three forms of the advice:
1) Burst as much as possible, it is not necessary to end bursts
on some particular boundary for best performance.
2) Burst on some byte count multiple. A DMA burst to some multiple of
number of bytes may be done, but it is important to end the burst
on an exact multiple for best performance.
The best example of this I am aware of are the PPC64 PCI
controllers, where if you end a burst mid-cacheline then
chip has to refetch the data and the IOMMU translations
which hurts performance a lot.
3) Burst on a single byte count multiple. Bursts shall end
exactly on the next multiple boundary for best performance.
Sparc64 and Alpha's PCI controllers operate this way. They
disconnect any device which tries to burst across a cacheline
boundary.
Actually, newer sparc64 PCI controllers do not have this behavior.
That is why the "pdev" is passed into the interface, so I can
add code later to check which PCI controller the system is using
and give advice accordingly.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'include/asm-h8300/local.h')
0 files changed, 0 insertions, 0 deletions