Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Jeremy Fitzhardinge suggested the use of -freg-struct-return, which does
structure-returns (such as when using pte_t) in registers instead of on
the stack.

that is indeed so, and this option reduced the kernel size a bit:

    text    data     bss     dec     hex filename
 4799506  543456 3760128 9103090  8ae6f2 vmlinux.before
 4798117  543456 3760128 9101701  8ae185 vmlinux.after

the resulting kernel booted fine on my testbox. Lets go for it.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Need to use get_irq_msi() not get_irq_data().
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Noticed by Meelis Roos.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The problem:  After moving an interrupt when is it safe to teardown
the data structures for receiving the interrupt at the old location?

With a normal pci device it is possible to issue a read to a device
to flush all posted writes.  This does not work for the oldest ioapics
because they are on a 3-wire apic bus which is a completely different
data path.  For some more modern ioapics when everything is using
front side bus delivery you can flush interrupts by simply issuing a
read to the ioapic.  For other modern ioapics emperical testing has
shown that this does not work.

So it appears the only reliable way to know the last of the irqs from an
ioapic have been received from before the ioapic was reprogrammed is to
received the first irq from the ioapic from after it was reprogrammed.

Once we know the last irq message has been received from an ioapic
into a local apic we then need to know that irq message has been
processed through the local apics.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

For the ISA irqs we reserve 16 vectors.  This patch adds constants for
those vectors and modifies the code to use them.  Making the code a
little clearer and making it possible to move these vectors in the future.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The code in io_apic.c and in i8259.c currently hardcode the same
vector for the timer interrupt so there is no reason for a special
assignment for the timer as the setup for the i8259 already takes care
of this.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Currently assign_irq_vector works mostly by side effect and returns
the results of it's changes to the caller.  Which makes for a lot of
arguments to pass/return and confusion as to what to do if you need
the status but you aren't calling assign_irq_vector.

This patch stops returning values from assign_irq_vector that can be
retrieved just as easily by examining irq_cfg, and modifies the
callers to retrive those values from irq_cfg when they need them.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Currently the io_apic.c has several parallel arrays for different
kinds of data that can be know about an irq.  The parallel arrays
make the code harder to maintain and make it difficult to remove
the static limits on the number of the number of irqs.

This patch pushes irq_data and irq_vector into a irq_cfg array and
updates the code to use it.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

NR_IRQ_VECTORS is currently a compatiblity define set to NR_IRQs.
This patch updates the users of NR_IRQ_VECTORS to use NR_IRQs instead
so that NR_IRQ_VECTORS can be removed.

There is still shared code with arch/i386 that uses NR_IRQ_VECTORS
so we can't remove the #define just yet :(
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If we have an irq that comes from multiple io_apic pins the FINAL action
(which is io_apic_sync or nothing) needs to be called for every entry or
else if the two pins come from different io_apics we may not wait until
after the action happens on the io_apic.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

For some reason the code has been picking TARGET_CPUS when asked to
set the affinity to an empty set of cpus.  That is just silly it's
extra work.  Instead if there are no cpus to set the affinity to we
should just give up immediately.  That is simpler and a little more
intuitive.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Currently we have two routines that do practically the same thing
setup_IO_APIC_irq and io_apic_set_pci_routing.  This patch makes
setup_IO_APIC_irq the common factor of these two previous routines.
For setup_IO_APIC_irq all that was needed was to pass the trigger
and polarity to make the code a proper subset of io_apic_set_pci_routing.

Hopefully consolidating these two routines will improve maintenance
there were several differences that simply appear to be one routine
or the other getting it wrong.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It's dead Jim.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch replaces all instances of "set_native_irq_info(irq, mask)"
with "irq_desc[irq].affinity = mask".  The latter form is clearer
uses fewer abstractions, and makes access to this field uniform
accross different architectures.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

By precomputing old_mask I remove an extra if statement, remove an
indentation level and make the code slightly easier to read.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit 2ff2d3d7.

Uwe Bugla reports that he cannot mount a floppy drive any more, and Jiri
Slaby bisected it down to this commit.

Benjamin LaHaise also points out that this is a big hot-path, and that
interrupt delivery while idle is very common and should not go through
all these expensive gyrations.

Fix up conflicts in arch/i386/kernel/apic.c and arch/i386/kernel/irq.c
due to other unrelated irq changes.

Cc: Stephane Eranian <eranian@hpl.hp.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Uwe Bugla <uwe.bugla@gmx.de>
Cc: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

 aware

Since TEXT_OFFSET is meant to determine RAM location for kernel use,
itshould affect .data and .bss initial mapping in the XIP case.
Otherwise a XIP kernel would crash if TEXT_OFFSET gets somewhat larger
than 2MB.

Corresponding code is also moved up a bit to be near the similar .text
mapping code making the whole a bit more straight forward to understand.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Since commit 2552fc27 XIP kernels failed
to boot because (_end - PAGE_OFFSET - 1) is much smaller than the size
of the kernel text and data in the XIP case, causing the kernel not to
be entirely mapped.

Even in the non-XIP case, the use of (_end - PAGE_OFFSET - 1) is wrong
because it produces a too large value if TEXT_OFFSET is larger than 1MB.

Finally the original code was performing one loop too many.

Let's break the loop when the section pointer has passed the last byte
of the kernel instead.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The new gpio_direction_input() and gpio_direction_output() functions
were both enabling output mode.  When configuring a GPIO for input mode,
you need to program the ODR (Output Disable Register).
Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The duplicate file "include/asm-arm/arch-at91rm9200/entry-macro.S" can
be removed - it was already moved to include/asm-arm/arch-at91/.

Fix 3 small typo's - two in comments, and the incorrect clock was
specified for the LCD device.
Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add the Armzone QT2410 to the list of built
machines in the s3c2410_defconfig
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Udpate s3c2410_defconfig for 2.6.21-rc1
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NDale Farnsworth <dale@farnsworth.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The generic version truncates addresses.

This reverts commit 8e087929.

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This patch adds trivial support for SMARTMIPS extension. This extension
is currently implemented by 4KS[CD] CPUs.

Basically it saves/restores ACX register, which is part of the SMARTMIPS
ASE, when needed. This patch does *not* add any support for Smartmips MMU
features.

Futhermore this patch does not add explicit support for 4KS[CD] CPUs since
they are respectively mips32 and mips32r2 compliant.  So with the current
processor configuration, a platform that has such CPUs needs to select
both configs:

	CPU_HAS_SMARTMIPS
	SYS_HAS_CPU_MIPS32_R[12]

This is due to the processor configuration which is mixing up all the
architecture variants and the processor types.

The drawback of this, is that we currently pass '-march=mips32' option to
gcc when building a kernel instead of '-march=4ksc' for 4KSC case. This
can lead to a kernel image a little bit bigger than required.
Signed-off-by: NFranck Bui-Huu <fbuihuu@gmail.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NGuy Martin <gmsoft@tuxicoman.be>

Since $(ARCH) is always "s390" we can replace it with "s390".
Signed-off-by: NMichael Holzheu <holzheu@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

With CONFIG_SHARED_KERNEL the kernel text segment that might be in a
read only memory sections starts at 1MB. Memory between 0x12000 and
0x100000 is unused then. Free this, so we have appr. an extra MB
of memory available.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Clear only memory from __bss_start to __bss_stop when clearing the bss
section. Not until _end, which currently happens to be the same.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

To avoid ugly warings for older gccs, we replace
BUG() with "return NULL", which is just as well.
Signed-off-by: NMichael Holzheu <holzheu@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Setup.h has been misused for ipl related stuff in the past. We now move
everything, which has to do with ipl and reipl to a new header file named
"ipl.h".
Signed-off-by: NMichael Holzheu <holzheu@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Replace two stidp inline assemblies with one global implementation.
Signed-off-by: NMichael Holzheu <holzheu@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Force reading of *in_sync in while loop. Loops where the content that
is checked for is changed by a different cpu always should have some
sort of barrier() semantics.
Otherwise this might lead to very subtle bugs.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Disable ZONE_DMA on 31-bit. All memory is addressable by all
devices and we do not need any special memory pool.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>