linux.git/include/asm-powerpc/dcr-native.h, branch master

powerpc: Move include files to arch/powerpc/include/asm

2008-08-04T02:02:00+00:00

from include/asm-powerpc.  This is the result of a

mkdir arch/powerpc/include/asm
git mv include/asm-powerpc/* arch/powerpc/include/asm

Followed by a few documentation/comment fixups and a couple of places
where  was being used explicitly.  Of the latter only
one was outside the arch code and it is a driver only built for powerpc.

Signed-off-by: Stephen Rothwell 
Signed-off-by: Paul Mackerras

[POWERPC] Refactor DCR code

2008-05-29T12:06:56+00:00

Previously, DCR support was configured at compile time to either use
MMIO or native dcr instructions.  Although this works for most
platforms, it fails on FPGA platforms:

1) Systems may include more than one DCR bus.
2) Systems may be native DCR capable and still use memory mapped DCR interface.

This patch provides runtime support based on the device trees for the
case where CONFIG_PPC_DCR_MMIO and CONFIG_PPC_DCR_NATIVE are both
selected.  Previously, this was a poorly defined configuration, which
happened to provide NATIVE support.  The runtime selection is made
based on the dcr-controller having a 'dcr-access-method' attribute
in the device tree.  If only one of the above options is selected,
then the code uses #defines to select only the used code in order to
avoid introducing overhead in existing usage.

Signed-off-by: Stephen Neuendorffer 
Signed-off-by: Josh Boyer

[POWERPC] 4xx: Add dcri_clrset() for locked read/modify/write functionality

2008-03-26T12:20:38+00:00

This adds dcri_clrset() macro which does read/modify/write
on indirect dcr registers while holding indirect dcr lock.

Signed-off-by: Valentine Barshak 
Acked-by: Benjamin Herrenschmidt 
Signed-off-by: Josh Boyer

[POWERPC] 4xx: PCIe indirect DCR spinlock fix.

2008-02-07T03:02:57+00:00

Since we have mfdcri() and mtdcri() as macros, we can't use constructions,
such as "mtdcri(base, reg, mfdcri(base, reg) | val)".  In this case the
mfdcri() stuff is not evaluated first.  It's evaluated inside the mtdcri()
macro and we have the dcr_ind_lock spinlock acquired twice.

To avoid this error, I've added __mfdcri()/__mtdcri() inline functions that
take the lock after register name fix-up.

Signed-off-by: Valentine Barshak 
Acked-by: Benjamin Herrenschmidt 
Signed-off-by: Josh Boyer

[POWERPC] 4xx: Improve support for 4xx indirect DCRs

2007-12-23T19:12:11+00:00

Accessing indirect DCRs is done via a pair of address/data DCRs.

Such accesses are thus inherently racy, vs. interrupts, preemption
and possibly SMP if 4xx SMP cores are ever used.

This updates the mfdcri/mtdcri macros in dcr-native.h (which were
so far unused) to use a spinlock.

In addition, add some common definitions to a new dcr-regs.h file.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Josh Boyer

Use dcr_host_t.base in dcr_unmap()

2007-10-15T18:29:49+00:00

With the base stored in dcr_host_t, there's no need for callers to pass
the dcr_n into dcr_unmap(). In fact this removes the possibility of them
passing the incorrect value, which would then be iounmap()'ed.

Signed-off-by: Michael Ellerman 
Signed-off-by: Jeff Garzik

Add dcr_host_t.base in dcr_read()/dcr_write()

2007-10-15T18:29:49+00:00

Now that all users of dcr_read()/dcr_write() add the dcr_host_t.base, we
can save them the trouble and do it in dcr_read()/dcr_write().

As some background to why we just went through all this jiggery-pokery,
benh sayeth:

 Initially the goal of the dcr_read/dcr_write routines was to operate like
 mfdcr/mtdcr which take absolute DCR numbers. The reason is that on 4xx
 hardware, indirect DCR access is a pain (goes through a table of
 instructions) and it's useful to have the compiler resolve an absolute DCR
 inline.

 We decided that wasn't worth the API bastardisation since most places
 where absolute DCR values are used are low level 4xx-only code which may
 as well continue using mfdcr/mtdcr, while the new API is designed for
 device "instances" that can exist on 4xx and Axon type platforms and may
 be located at variable DCR offsets.

Signed-off-by: Michael Ellerman 
Signed-off-by: Jeff Garzik

[POWERPC] Store the base address in dcr_host_t

2007-10-03T03:25:27+00:00

In its current form, dcr_map() doesn't remember the base address you passed
it, which means you need to store it somewhere else.  Rather than adding the
base to another struct it seems simpler to store it in the dcr_host_t.

Signed-off-by: Michael Ellerman 
Acked-by: Benjamin Herrenschmidt 
Signed-off-by: Paul Mackerras

[POWERPC] More DCR native fixups

2007-02-16T03:00:19+00:00

Getting BenH's new EMAC driver working on 440GP, I found some more
problems in the native mode paths of the new DCR code:
	- dcr_map() is supposed to return a dcr_host_t, but the native
version is a macro that doesn't expand to an expression.  With native
DCRs, dcr_host_t is an empty structure, so we just use a constructor
expression instead.
	- dcr_unmap() uses {} instead of the safer do {} while (0)
idiom to implement a no-op

Here's a fix.

Signed-off-by: David Gibson 
Acked-by: Benjamin Herrenschmidt 
Signed-off-by: Paul Mackerras

[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