- 26 Mar, 2008 1 commit
-
-
Valentine Barshak authored
This adds dcri_clrset() macro which does read/modify/write on indirect dcr registers while holding indirect dcr lock. Signed-off-by:
Valentine Barshak <vbarshak@ru.mvista.com> Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Josh Boyer <jwboyer@linux.vnet.ibm.com>
-
- 06 Feb, 2008 1 commit
-
-
Valentine Barshak authored
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 <vbarshak@ru.mvista.com> Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Josh Boyer <jwboyer@linux.vnet.ibm.com>
-
- 23 Dec, 2007 1 commit
-
-
Benjamin Herrenschmidt authored
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 <benh@kernel.crashing.org> Signed-off-by:
Josh Boyer <jwboyer@linux.vnet.ibm.com>
-
- 15 Oct, 2007 2 commits
-
-
Michael Ellerman authored
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>
-
Michael Ellerman authored
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>
-
- 02 Oct, 2007 1 commit
-
-
Michael Ellerman authored
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>
-
- 15 Feb, 2007 1 commit
-
-
David Gibson authored
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>
-
- 11 Dec, 2006 1 commit
-
-
Kumar Gala authored
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>
-
- 04 Dec, 2006 1 commit
-
-
Benjamin Herrenschmidt authored
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>
-
- 02 Oct, 2006 1 commit
-
-
Dave Kleikamp authored
Removed trailing spaces & tabs, and spaces preceding tabs. Also a couple very minor comment cleanups. Signed-off-by:
Dave Kleikamp <shaggy@austin.ibm.com> (cherry picked from f74156539964d7b3d5164fdf8848e6a682f75b97 commit)
-
- 01 Sep, 2005 1 commit
-
-
Dave Kleikamp authored
Signed-off-by:
Dave Kleikamp <shaggy@austin.ibm.com>
-
- 23 Jun, 2005 1 commit
-
-
Christoph Hellwig authored
This file duplicates <linux/posix_acl_xattr.h>, using slightly different names. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 16 Apr, 2005 1 commit
-
-
Linus Torvalds authored
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!
-