linux.git/include/asm-ppc, branch v2.6.21

[POWERPC] ppc: Add support for AMCC Taishan 440GX eval board

2007-02-13T04:35:52+00:00

This patch adds support for the AMCC Taishan PPC440GX evaluation
board.

This is still an arch/ppc port. I'm aware that the move of
4xx to arch/powerpc is making good progress right now. So this
patch is mainly intended to make the Taishan support available
for the community right now.

Signed-off-by: Stefan Roese 
Signed-off-by: Paul Mackerras

[PATCH] kill eth_io_copy_and_sum()

2007-02-09T17:14:07+00:00

On all targets that sucker boils down to memcpy_fromio(sbk->data, from, len).
The function name is highly misguiding (it _never_ does any checksums), the
last argument is just a noise and simply expanding the call to memcpy_fromio()
gives shorter and more readable source.  For a lot of reasons it has almost
no remaining users, so it's better to just outright kill it.

Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds

[POWERPC] Compile fixes for arch/powerpc dcr code

2007-02-07T03:03:23+00:00

The new dcr code does not currently compile when configured for native
DCR access on ARCH=powerpc.  This patch fixes the problems.

Signed-off-by: David Gibson 
Signed-off-by: Paul Mackerras

[POWERPC] 8xx: powerpc port of core CPM PIC

2007-02-07T03:03:17+00:00

This covers common CPM access functions, CPM interrupt controller code,
micropatch and a few compatibility things to kee the same driver base
working with arch/ppc. This version is refined with all the comments
(mostly PIC-related) addressed.

Signed-off-by: Vitaly Bordug 
Signed-off-by: Paul Mackerras

[POWERPC] Remove the broken Gemini support

2007-01-24T10:13:58+00:00

Signed-off-by: Adrian Bunk 
Signed-off-by: Paul Mackerras

Merge branch 'for_paulus' of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc

2006-12-11T05:31:42+00:00

[POWERPC] Only export mtdcr/mfdcr if CONFIG_PPC_DCR is set

2006-12-11T05:15:47+00:00

On 85xx we don't build in dcr support because the core doesn't implement the
instructions.  This caused problems when building an 85xx kernel.  Additionally
made it so we only build __mtdcr/__mfdcr if we are CONFIG_PPC_DCR_NATIVE.

The 85xx build issue wasPointed out by Dai Haruki.

Signed-off-by: Kumar Gala

[POWERPC] Fix mmap of PCI resource with hack for X

2006-12-08T06:21:06+00:00

The powerpc version of pci_resource_to_user() and associated hooks
used by /proc/bus/pci and /sys/bus/pci mmap have been broken for some
time on machines that don't have a 1:1 mapping of devices (basically
on non-PowerMacs) and have PCI devices above 32 bits.

This attempts to fix it as well as possible.

The rule is supposed to be that pci_resource_to_user() always converts
the resources back into a BAR values since that's what the /proc
interface was supposed to deal with. However, for X to work on
platforms where PCI MMIO is not mapped 1:1, it became a habit of
platforms like powerpc to pass "fixed up" values there since X expects
to be able to use values from /proc/bus/pci/devices as offsets to mmap
of /dev/mem...

So we keep that contraption here, causing also /sys/*/resource to
expose fully absolute MMIO addresses instead of BAR values, which is
ugly, but should still work as long as those are only used to calculate
alignment within a page.

X is still broken when built 32 bits on machines where PCI MMIO can be
above 32-bit space unfortunately.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Paul Mackerras

[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] mm: pagefault_{disable,enable}()

2006-12-07T16:39:21+00:00

Introduce pagefault_{disable,enable}() and use these where previously we did
manual preempt increments/decrements to make the pagefault handler do the
atomic thing.

Currently they still rely on the increased preempt count, but do not rely on
the disabled preemption, this might go away in the future.

(NOTE: the extra barrier() in pagefault_disable might fix some holes on
       machines which have too many registers for their own good)

[heiko.carstens@de.ibm.com: s390 fix]
Signed-off-by: Peter Zijlstra 
Acked-by: Nick Piggin 
Cc: Martin Schwidefsky 
Signed-off-by: Heiko Carstens 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds