summaryrefslogtreecommitdiff
path: root/include/asm-i386/pci.h
AgeCommit message (Collapse)AuthorFilesLines
2005-08-15Revert PCIBIOS_MIN_IO changes for 2.6.13Linus Torvalds1-1/+3
This reverts commits 71db63acff69618b3d9d3114bd061938150e146b [PATCH] increase PCIBIOS_MIN_IO on x86 and 0b2bfb4e7ff61f286676867c3508569bea6fbf7a ACPI: increase PCIBIOS_MIN_IO on x86 since Lukas Sandströ<lukass@etek.chalmers.se> reports that this breaks his on-board nvidia audio. We should re-visit this later. For now we revert the change Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-03[PATCH] increase PCIBIOS_MIN_IO on x86Ivan Kokshaysky1-3/+1
There is a number of x86 laptops that have some non-PCI IO ports in the 0x1000-0x1fff range, and it's quite hard to control the correct order of resource allocation between PCI and other subsystems controlling these ports. Especially with modular kernel. So just increase PCIBIOS_MIN_IO to 0x4000 to prevent any new PCI resource allocations in the problematic range (this limitation must apply _only_ to the root bus resources - see Linus' change in pci_bus_alloc_resource). As PCIBIOS_MIN_IO and PCIBIOS_MIN_CARDBUS_IO are the same now on i386 and x86-64, we can remove the latter. Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-13[ACPI] merge acpi-2.6.12 branch into latest Linux 2.6.13-rc...Len Brown1-1/+1
Signed-off-by: Len Brown <len.brown@intel.com>
2005-07-12[ACPI] PNPACPI vs sound IRQDavid Shaohua Li1-1/+1
http://bugme.osdl.org/show_bug.cgi?id=4016 Written-by: David Shaohua Li <shaohua.li@intel.com> Acked-by: Adam Belay <abelay@novell.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-28[PATCH] PCI: fix up errors after dma bursting patch and CONFIG_PCI=nAndrew Morton1-0/+2
With CONFIG_PCI=n: In file included from include/linux/pci.h:917, from lib/iomap.c:6: include/asm/pci.h:104: warning: `enum pci_dma_burst_strategy' declared inside parameter list include/asm/pci.h:104: warning: its scope is only this definition or declaration, which is probably not what you want. include/asm/pci.h: In function `pci_dma_burst_advice': include/asm/pci.h:106: dereferencing pointer to incomplete type include/asm/pci.h:106: `PCI_DMA_BURST_INFINITY' undeclared (first use in this function) include/asm/pci.h:106: (Each undeclared identifier is reported only once include/asm/pci.h:106: for each function it appears in.) make[1]: *** [lib/iomap.o] Error 1 Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-28[PATCH] PCI: DMA bursting adviceDavid S. Miller1-0/+8
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>
2005-04-17Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+110
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!