pci_set_master() and PCI_LATENCY_TIMER

Eric Seppanen (eds@reric.net)
Thu, 12 Aug 1999 10:41:59 -0500 (CDT)


I hate to re-open a can of worms but I'm a little confused regarding
kernel policy on PCI_LATENCY_TIMER and use of pci_set_master.

historical: most of the linux-kernel discussion I saw took place 26 Sept
1998 under the subject "PCI_LATENCY_TIMER brain damage in net drivers"

here's the way things look to me- let me know if I'm wrong here.
* There are some systems that set the pci latency value to ridiculously
low numbers (like 0) and this makes things break.
* The 2.0 kernels (afaik) do not attempt to correct this, which led to
drivers (tulip net driver is an example) which detect and correct it
themselves.
* There was code added during 2.1 development to always correct low pci
latency, but it broke some things so it got removed.
* 2.1 added a new pci_set_master() function which sets the master bit, and
corrects low pci latency.

So now, I'm fooling with a system that likes to set pci latency to 0, and
working on a driver that uses pci busmastering. I'm trying to make this
driver work the same under 2.0 and 2.2 kernels using #ifdef
LINUX_VERSION_CODE... directives.

Under 2.0 it seems clear that I should fix pci latency myself.

I'm not clear on what I'm supposed to do for 2.2, however. Am I supposed
to _always_ call pci_set_master()? Can I trust that from now on
pci_set_master() will always fix low pci latency?

And if pci_set_master() is always supposed to be called before
busmastering and it always fixes low pci latency, what are the drivers for
those devices that get broken by the fix supposed to do? Go back to the
2.0 behavior (change it yourself)?

Thanks,

Eric Seppanen
eds@reric.net

-
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.tux.org/lkml/