- 16 10月, 2007 1 次提交
-
-
由 Mike Rapoport 提交于
This patch provides driver for ITE 8152 PCI bridge. Signed-off-by: NMike Rapoport <mike@compulab.co.il> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 12 7月, 2007 2 次提交
-
-
由 Jan Beulich 提交于
Based on replies to a respective query, remove the pci_dac_dma_...() APIs (except for pci_dac_dma_supported() on Alpha, where this function is used in non-DAC PCI DMA code). Signed-off-by: NJan Beulich <jbeulich@novell.com> Cc: Andi Kleen <ak@suse.de> Cc: Jesse Barnes <jesse.barnes@intel.com> Cc: Christoph Hellwig <hch@infradead.org> Acked-by: NDavid Miller <davem@davemloft.net> Cc: Jeff Garzik <jeff@garzik.org> Cc: <linux-arch@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Michael Ellerman 提交于
I'm not sure if this is going to fly, weak symbols work on the compilers I'm using, but whether they work for all of the affected architectures I can't say. I've cc'ed as many arch maintainers/lists as I could find. But assuming they do, we can use a weak empty definition of pcibios_add_platform_entries() to avoid having an empty definition on every arch. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 26 4月, 2006 1 次提交
-
-
由 David Woodhouse 提交于
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
-
- 09 9月, 2005 1 次提交
-
-
由 David S. Miller 提交于
There were three changes necessary in order to allow sparc64 to use setup-res.c: 1) Sparc64 roots the PCI I/O and MEM address space using parent resources contained in the PCI controller structure. I'm actually surprised no other platforms do this, especially ones like Alpha and PPC{,64}. These resources get linked into the iomem/ioport tree when PCI controllers are probed. So the hierarchy looks like this: iomem --| PCI controller 1 MEM space --| device 1 device 2 etc. PCI controller 2 MEM space --| ... ioport --| PCI controller 1 IO space --| ... PCI controller 2 IO space --| ... You get the idea. The drivers/pci/setup-res.c code allocates using plain iomem_space and ioport_space as the root, so that wouldn't work with the above setup. So I added a pcibios_select_root() that is used to handle this. It uses the PCI controller struct's io_space and mem_space on sparc64, and io{port,mem}_resource on every other platform to keep current behavior. 2) quirk_io_region() is buggy. It takes in raw BUS view addresses and tries to use them as a PCI resource. pci_claim_resource() expects the resource to be fully formed when it gets called. The sparc64 implementation would do the translation but that's absolutely wrong, because if the same resource gets released then re-claimed we'll adjust things twice. So I fixed up quirk_io_region() to do the proper pcibios_bus_to_resource() conversion before passing it on to pci_claim_resource(). 3) I was mistakedly __init'ing the function methods the PCI controller drivers provide on sparc64 to implement some parts of these routines. This was, of course, easy to fix. So we end up with the following, and that nasty SPARC64 makefile ifdef in drivers/pci/Makefile is finally zapped. Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 05 8月, 2005 1 次提交
-
-
由 Dominik Brodowski 提交于
In yenta_socket, we default to using the resource setting of the CardBus bridge. However, this is a PCI-bus-centric view of resources and thus needs to be converted to generic resources first. Therefore, add a call to pcibios_bus_to_resource() call in between. This function is a mere wrapper on x86 and friends, however on some others it already exists, is added in this patch (alpha, arm, ppc, ppc64) or still needs to be provided (parisc -- where is its pcibios_resource_to_bus() ?). Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 12 7月, 2005 1 次提交
-
-
由 David Shaohua Li 提交于
http://bugme.osdl.org/show_bug.cgi?id=4016Written-by: NDavid Shaohua Li <shaohua.li@intel.com> Acked-by: NAdam Belay <abelay@novell.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 28 6月, 2005 2 次提交
-
-
由 Andrew Morton 提交于
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: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 David S. Miller 提交于
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: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
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!
-