linux.git/include/asm-ppc/pci.h, branch master

powerpc: Remove arch/ppc and include/asm-ppc

2008-06-10T11:40:22+00:00

All the maintained platforms are now in arch/powerpc, so the old
arch/ppc stuff can now go away.

Acked-by: Adrian Bunk 
Acked-by: Arnd Bergmann 
Acked-by: Becky Bruce 
Acked-by: Benjamin Herrenschmidt 
Acked-by: Geert Uytterhoeven 
Acked-by: Grant Likely 
Acked-by: Jochen Friedrich 
Acked-by: John Linn 
Acked-by: Jon Loeliger 
Acked-by: Josh Boyer 
Acked-by: Kumar Gala 
Acked-by: Olof Johansson 
Acked-by: Peter Korsgaard 
Acked-by: Scott Wood 
Acked-by: Sean MacLennan 
Acked-by: Segher Boessenkool 
Acked-by: Stefan Roese 
Acked-by: Stephen Neuendorffer 
Acked-by: Wolfgang Denk 
Signed-off-by: Paul Mackerras

PCI: remove pci_dac_dma_... APIs

2007-07-11T23:02:11+00:00

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: Jan Beulich 
Cc: Andi Kleen 
Cc: Jesse Barnes 
Cc: Christoph Hellwig 
Acked-by: David Miller 
Cc: Jeff Garzik 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

PCI: Use a weak symbol for the empty version of pcibios_add_platform_entries()

2007-07-11T23:02:07+00:00

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: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

[POWERPC] Define pci_unmap_addr() et al. when CONFIG_NOT_COHERENT_CACHE=y

2006-12-08T06:10:18+00:00

The current PowerPC code makes pci_unmap_addr(), pci_unmap_addr_set(),
and friends trivial for all 32-bit kernels.  This is reasonable, since
for those kernels it is true that pci_unmap_single() does not need the
DMA address from the original DMA mapping -- in fact, it is a NOP.

However, I recently tried the tg3 driver on a PowerPC 440SPe machine,
which runs a 32-bit kernel and has non-cache-coherent PCI DMA.  I
found that the tg3 driver crashed in pci_dma_sync_single_for_cpu(),
since for non-coherent systems, that function must invalidate the
cache for the DMA address range requested, and therefore it does use
the address passed in.  tg3 uses a DMA address it stashes away with
pci_unmap_addr_set() and retrieves with pci_unmap_addr().  Of course,
since pci_unmap_addr() is defined to (0) right now, this doesn't work.

It seems to me that the tg3 driver is using pci_unmap_addr() in a
legitimate way -- I wouldn't want to have to teach all drivers that
they should use pci_unmap_addr() if they only need the address for
unmapping functions, but if they want the pci_dma_sync functions, then
they have to store the DMA address without the helper macros.
The right fix therefore seems to be in the definition of the macros in
 -- we should use the trivial versions only for 32-bit
kernels for coherent systems, and the real versions for both 64-bit
kernels and non-coherent systems.

Signed-off-by: Roland Dreier 
Signed-off-by: Paul Mackerras

[PATCH] 64bit resource: change pci core and arch code to use resource_size_t

2006-06-27T16:24:00+00:00

Based on a patch series originally from Vivek Goyal 

Cc: Vivek Goyal 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

[PATCH] ppc: make phys_mem_access_prot() work with pfns instead of addresses

2005-10-29T04:25:49+00:00

Change the phys_mem_access_prot() function to take a pfn instead of an
address.  This allows mmap64() to work on /dev/mem for addresses above 4G
on 32-bit architectures.  We start with a pfn in mmap_mem(), so there's no
need to convert to an address; in fact, it's actively bad, since the
conversion can overflow when the address is above 4G.

Similarly fix the ppc32 page_is_ram() function to avoid a conversion to an
address by directly comparing to max_pfn.  Working with max_pfn instead of
high_memory fixes page_is_ram() to give the right answer for highmem pages.

Signed-off-by: Roland Dreier 
Cc: Anton Blanchard 
Cc: Benjamin Herrenschmidt 
Signed-off-by: Andrew Morton 
Signed-off-by: Paul Mackerras

ppc: rename pci_assign_all_busses to pci_assign_all_buses

2005-10-20T10:57:05+00:00

... for consistency with ppc64 and to make merging easier.

Signed-off-by: Paul Mackerras

[PATCH] Make sparc64 use setup-res.c

2005-09-08T21:57:25+00:00

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: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

[PATCH] pci and yenta: pcibios_bus_to_resource

2005-08-05T04:32:46+00:00

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: Dominik Brodowski 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Linus Torvalds

[ACPI] merge acpi-2.6.12 branch into latest Linux 2.6.13-rc...

2005-07-12T21:21:56+00:00

Signed-off-by: Len Brown