linux-toradex.git/include/asm-powerpc, branch v2.6.20.21

[PATCH] dma-mapping.h stubs fix

2007-01-30T16:39:21+00:00

do { } while(0) is not a good imitation of function returning void;
use ((void)0) instead.

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

Fix Maple PATA IRQ assignment.

2007-01-26T22:27:40+00:00

On the Maple board, the AMD8111 IDE is in legacy mode... except that it
appears on IRQ 20 instead of IRQ 15. For drivers/ide this was handled by
the architecture's "pci_get_legacy_ide_irq()" function, but in libata we
just hard-code the numbers 14 and 15.

This patch provides asm-powerpc/libata-portmap.h which maps the IRQ as
appropriate, having added a pci_dev argument to the
ATA_{PRIM,SECOND}ARY_IRQ macros.

There's probably a better way to do this -- especially if we observe
that the _only_ case in which this seemingly-generic
"pci_get_legacy_ide_irq()" function returns anything other than 14 and
15 for primary and secondary respectively is the case of the AMD8111 on
the Maple board -- couldn't we handle that with a special case in the
pata_amd driver, or perhaps with a PCI quirk for Maple to switch it into
native mode during early boot and assign resources properly?

Signed-off-by: David Woodhouse 
Signed-off-by: Jeff Garzik

[POWERPC] atomic_dec_if_positive sign extension fix

2007-01-22T10:27:36+00:00

On 64-bit machines, if an atomic counter is explicitly set to a
negative value, the atomic_dec_if_positive function will decrement and
store the next smallest value in the atomic counter, contrary to its
intended operation.

The comparison to determine if the decrement will make the result
negative was done by the "addic." instruction, which operates on a
64-bit value, namely the zero-extended word loaded from the atomic
variable.  This patch uses an explicit word compare (cmpwi) and
changes the addic. to an addi (also changing "=&r" to "=&b" so that r0
isn't used, and addi doesn't become li).

This also fixes a bug for both 32-bit and 64-bit in that previously
0x80000000 was considered positive, since the result after
decrementing is positive.  Now it is considered negative.

Also, I clarify the return value in the comments just to make it clear
that the value returned is always the decremented value, even if that
value is not stored back to the atomic counter.

Signed-off-by: Robert Jennings 
Signed-off-by: Paul Mackerras

[PATCH] FD_ZERO build fix

2007-01-12T02:18:22+00:00

unionfs managed to hit this on s390.  Some architectures use __ptr_t in their
FD_ZERO implementation.  We don't have a __ptr_t.  Switch them over to plain
old void*.

Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Al Viro 
Cc: Paul Mackerras 
Cc: Benjamin Herrenschmidt 
Cc: "Luck, Tony" 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Josef 'Jeff' Sipek 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[POWERPC] Fix bugs in the hypervisor call stats code

2007-01-09T06:03:03+00:00

There were a few issues with the HCALL_STATS code:

- PURR cpu feature checks were backwards
- We iterated one entry off the end of the hcall_stats array
- Remove dead update_hcall_stats() function prototype

I noticed one thing while debugging, and that is we call H_ENTER (to set
up the MMU hashtable in early init) before we have done the cpu fixups.
This means we will execute the PURR SPR reads even on a CPU that isnt
capable of it. I wonder if we can move the CPU feature fixups earlier.

Signed-off-by: Anton Blanchard 
Signed-off-by: Paul Mackerras

[POWERPC] 52xx: Don't use device_initcall to probe of_platform_bus

2007-01-09T06:03:02+00:00

Using device_initcall makes it happen for every platform that
compiles this file in. This is really bad, for obvious reasons.

Instead, we use the .init field of the machine description. If
the platform needs the hook to do something specific it can provides
its own function and call mpc52xx_declare_of_platform_devices from
there. If not, the mpc52xx_declare_of_platform_devices function can
directly be used as the init hook.

Signed-off-by: Sylvain Munaut 
Acked-by: Grant Likely 
Signed-off-by: Paul Mackerras

[POWERPC] Fix manual assembly WARN_ON() in enter_rtas().

2007-01-09T06:03:02+00:00

When we switched over to the generic BUG mechanism we forgot to change
the assembly code which open-codes a WARN_ON() in enter_rtas(), so the
bug table got corrupted.

This patch provides an EMIT_BUG_ENTRY macro for use in assembly code,
and uses it in entry_64.S. Tested with CONFIG_DEBUG_BUGVERBOSE on ppc64
but not without -- I tried to turn it off but it wouldn't go away; I
suspect Aunt Tillie probably needed it.

This version gets __FILE__ and __LINE__ right in the assembly version --
rather than saying include/asm-powerpc/bug.h line 21 every time which is
a little suboptimal.

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

[POWERPC] cell: add forward struct declarations to spu.h

2006-12-19T14:35:36+00:00

Needed to be able to include spu.h independant from other
headers.

Signed-off-by: Arnd Bergmann

[PATCH] Optimize D-cache alias handling on fork

2006-12-13T17:27:08+00:00

Virtually index, physically tagged cache architectures can get away
without cache flushing when forking.  This patch adds a new cache
flushing function flush_cache_dup_mm(struct mm_struct *) which for the
moment I've implemented to do the same thing on all architectures
except on MIPS where it's a no-op.

Signed-off-by: Ralf Baechle 
Signed-off-by: Linus Torvalds

[PATCH] PM: Fix SMP races in the freezer

2006-12-13T17:05:49+00:00

Currently, to tell a task that it should go to the refrigerator, we set the
PF_FREEZE flag for it and send a fake signal to it.  Unfortunately there
are two SMP-related problems with this approach.  First, a task running on
another CPU may be updating its flags while the freezer attempts to set
PF_FREEZE for it and this may leave the task's flags in an inconsistent
state.  Second, there is a potential race between freeze_process() and
refrigerator() in which freeze_process() running on one CPU is reading a
task's PF_FREEZE flag while refrigerator() running on another CPU has just
set PF_FROZEN for the same task and attempts to reset PF_FREEZE for it.  If
the refrigerator wins the race, freeze_process() will state that PF_FREEZE
hasn't been set for the task and will set it unnecessarily, so the task
will go to the refrigerator once again after it's been thawed.

To solve first of these problems we need to stop using PF_FREEZE to tell
tasks that they should go to the refrigerator.  Instead, we can introduce a
special TIF_*** flag and use it for this purpose, since it is allowed to
change the other tasks' TIF_*** flags and there are special calls for it.

To avoid the freeze_process()-refrigerator() race we can make
freeze_process() to always check the task's PF_FROZEN flag after it's read
its "freeze" flag.  We should also make sure that refrigerator() will
always reset the task's "freeze" flag after it's set PF_FROZEN for it.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Pavel Machek 
Cc: Russell King 
Cc: David Howells 
Cc: Andi Kleen 
Cc: "Luck, Tony" 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Paul Mundt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds