Messages in this thread | | | From | "Eric Seppanen" <> | Subject | pci_set_master() and PCI_LATENCY_TIMER | Date | 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/
| |