Commit graph

6 commits

Author SHA1 Message Date
Michael Ellerman
cdbd3865ac Use dcr_host_t.base in dcr_unmap()
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 <michael@ellerman.id.au>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-15 14:29:49 -04:00
Michael Ellerman
83f34df4e7 Add dcr_host_t.base in dcr_read()/dcr_write()
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 <michael@ellerman.id.au>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-15 14:29:49 -04:00
Michael Ellerman
0b94a1eeee [POWERPC] Store the base address in dcr_host_t
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 <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-03 13:25:27 +10:00
David Gibson
c91ef59861 [POWERPC] More DCR native fixups
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 <dwg@au1.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-16 14:00:19 +11:00
Kumar Gala
45d8e7aaf4 [POWERPC] Only export __mtdcr/__mfdcr if CONFIG_PPC_DCR is set
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 <galak@kernel.crashing.org>
2006-12-10 23:15:47 -06:00
Benjamin Herrenschmidt
4c75a6f441 [POWERPC] Generic DCR infrastructure
This patch adds new dcr_map/dcr_read/dcr_write accessors for DCRs that
can be used by drivers to transparently address either native DCRs or
memory mapped DCRs. The implementation for memory mapped DCRs is done
after the binding being currently worked on for SLOF and the Axon
chipset. This patch enables it for the cell native platform

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-12-04 16:08:25 +11:00