This patch moves clock.h to clock24xx.h to make room for
adding common clock code for 24xx and 34xx.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch removes old 24xx PM code that does not really work for sleep
states, and uses old power management register access. Working PM code
will be added later.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch changes 24xx to use new register access, except for clock
framework. Clock framework register access will get updates in the
next patch.

Note that board-*.c files change GPMC (General Purpose Memory Controller)
access to use gpmc_cs_write_reg() instead of accessing the registers
directly. The code also uses gpmc_fck instead of it's parent clock
core_l3_ck for GPMC clock.

The H4 board file also adds h4_init_flash() function, which specify the
flash start and end addresses.

Also note that sleep.S removes some unused registers addresses.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch adds register access for 34xx power and clock management.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch adds common register access for 24xx and 34xx power
and clock management in order to share code between 24xx and 34xx.

Only change USB platform init code to use new register access, other
access will be changed in later patches.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Misc clean-up for the mux code and remove some unnecessary
ifdefs. Patch changes debug function so it can be used on
both 24xx and 34xx.

Changes are mostly for omap2, but patch also cleans up some
omap1 and common mux code.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add new pin multiplexing configurations
Signed-off-by: NTony Lindgren <tony@atomide.com>

Remove MPU-timer based sched_clock() in favor of the common one based
on 32k sync timer which works across all OMAP1/2/3 platforms.

Using 32k based one also gives a valid sched_clock() very early in the
boot process.
Signed-off-by: NKevin Hilman <khilman@mvista.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

These are no longer used and similar conversions are provided
by the clocksource/clockevent code.
Signed-off-by: NKevin Hilman <khilman@mvista.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch fixes timer32k for clockevents and syncs it with
linux-omap tree.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Move now OMAP1-specific timer32k code to mach-omap1 since OMAP2/3 32k
timers are done in gptimer code.
Signed-off-by: NKevin Hilman <khilman@mvista.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Since 32k timer code is moving to OMAP1 specific dir, move the
32k-based sched_clock() into common code where it is based on the 32k
sync counter and can be used even when using MPU timer.

While moving, change the ticks-to-nsecs conversion to use the helper
functions provided by clocksource.h.

Also removed the unused ticks_to_usec, leaving only ticks_to_nsec.
Signed-off-by: NKevin Hilman <khilman@mvista.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

On OMAP2/3, the gp-timer code can be used for a 32kHz timer simply by
setting the source to be the 32k clock instead of sys_clk.

This patch uses the mach-omap2/timer-gp.c code for 32kHz timer on
OMAP2, moving the logic into mach-omap2/timer-gp.c, and not using
plat-omap/timer32k.c which, for OMAP2, is redundant with the timer-gp
code.

Also, if CONFIG_OMAP_32K_TIMER is enabled, the gptimer-based
clocksource is not used.  Instead the default 32k sync counter is used
as the clocksource (see the clocksource in plat-omap/common.c.)  This
is important for sleep/suspend so there is a valid counter during
sleep.  Note that the suspend/sleep code needs fixing to check for
overflows of this counter.

In addition, the OMAP2/3 details are removed from timer32k.c leaving
that with only OMAP1 specifics.  A follow-up patch will move it from
plat-omap common code to mach-omap1.
Signed-off-by: NKevin Hilman <khilman@mvista.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Use omap processor specific function depending on system type.
Based on an earlier patch by Klaus Pedersen <klaus.k.pedersen@nokia.com>.
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch changes pin multiplexing init to allow registering
custom function. The omap_cfg_reg() func will be split into
omap processor specific functions in later patch.

This is done to make adding omap3 pin multiplexing easier.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Currently, the GPIO interrupt handling is duplicating some of the work
done by the generic IRQ handlers (handle_edge_irq, handle_level_irq)
such as detecting nesting, handling re-triggers etc.  Remove this
duplication and use generic hooks based on IRQ type.

Using generic IRQ handlers ensures correct behavior when using
threaded interrupts introduced by the -rt patch.
Signed-off-by: NKevin Hilman <khilman@mvista.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The clearing was moved to the unmask hook because it is known to run
after the interrupt handler has actually run.  Before this patch, if
interrupts are threaded, the clearing/unmasking of level triggered
interrupts would be done before the threaded handler actually ran.
Signed-off-by: NKevin Hilman <khilman@mvista.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Convert OSK board to use new tps65010 gpiolib support.  This
includes moving its LED support from leds-osk to gpio-leds,
giving more trigger options and a net platform code shrink.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Start cleaning up GPIO handling for OMAP5912 OSK board:

 - Initialize GPIOs using the cross-platform calls, not the old
   OMAP-private ones.

 - Move touchscreen setup out of ads7846 code into board-specfic
   setup code, where it belongs.

This doesn't depend on the patches to update OMAP to use the
gpiolib implementation framework.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Update OMAP to use the new GPIO implementation framework.  This is just a
quick'n'dirty update ... more code could now be removed, ideally as part
of cleaning up the entire OMAP GPIO infrastructure ...
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The prevent_tail_call() macro works around the problem of the compiler
clobbering argument words on the stack, which for asmlinkage functions
is the caller's (user's) struct pt_regs.  The tail/sibling-call
optimization is not the only way that the compiler can decide to use
stack argument words as scratch space, which we have to prevent.
Other optimizations can do it too.

Until we have new compiler support to make "asmlinkage" binding on the
compiler's own use of the stack argument frame, we have work around all
the manifestations of this issue that crop up.

More cases seem to be prevented by also keeping the incoming argument
variables live at the end of the function.  This makes their original
stack slots attractive places to leave those variables, so the compiler
tends not clobber them for something else.  It's still no guarantee, but
it handles some observed cases that prevent_tail_call() did not.
Signed-off-by: NRoland McGrath <roland@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch also resolves hangs on boot:
	http://lkml.org/lkml/2008/2/23/263
	http://bugzilla.kernel.org/show_bug.cgi?id=10093

The bug was causing once-in-few-reboots 10-15 sec wait during boot on
certain laptops.

Earlier commit 40d6a146 added
smp_call_function in cpu_idle_wait() to kick cpus that are in tickless
idle.  Looking at cpu_idle_wait code at that time, code seemed to be
over-engineered for a case which is rarely used (while changing idle
handler).

Below is a simplified version of cpu_idle_wait, which just makes a dummy
smp_call_function to all cpus, to make them come out of old idle handler
and start using the new idle handler.  It eliminates code in the idle
loop to handle cpu_idle_wait.
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Make NOMMU-mode work with base addresses other than 0xC0000000 by:

 (1) Giving the code that sets up the protection registers the right address
     in __sdram_base.  Rather than being hard coded to 0xC0000000, the value
     of __page_offset is obtained from the linker script.

 (2) Eliminate the check in __switch_to() that verifies the current thread
     info is in the 0xCxxxxxxx region.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use traps 120-126 to emulate atomic cmpxchg32, xchg32, and XOR-, OR-, AND-, SUB-
and ADD-to-memory operations for userspace.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

1) ptrace should pass 'current' to task_user_regset_view()

2) When fetching general registers using a 64-bit view, and
   the target is 32-bit, we have to convert.

3) Skip the whole register window get/set code block if
   the user isn't asking to access anything in there.

   Otherwise we have problems if the user doesn't have
   an address space setup.  Fetching ptrace register is
   still valid at such a time, and ptrace does not try
   to access the register window area of the regset.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

gcc expects all toplevel assembly to return to the original section type.
The code in alteranative.c does not do this. This caused some strange bugs
in sched-devel where code would end up in the .rodata section and when
the kernel sets the NX bit on all .rodata, the kernel would crash when
executing this code.

This patch adds a .previous marker to return the code back to the
original section.

Credit goes to Andrew Pinski for telling me it wasn't a gcc bug but a
bug in the toplevel asm code in the kernel.  ;-)
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

flush_cache_vmap / flush_cache_vunmap were calling flush_cache_all which -
having been deprecated - turned into a nop ...
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

In time_cpufreq_notifier() the cpu id to act upon is held in freq->cpu. Use it
instead of smp_processor_id() in the call to set_cyc2ns_scale().
This makes the preempt_*able() unnecessary and lets set_cyc2ns_scale() update
the intended cpu's cyc2ns.

Related mail/thread: http://lkml.org/lkml/2007/12/7/130Signed-off-by: NKarsten Wiese <fzu@wemgehoertderstaat.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

revert:

| commit 47001d60
| Author: Thomas Gleixner <tglx@linutronix.de>
| Date:   Tue Apr 1 19:45:18 2008 +0200
|
|     x86: tsc prevent time going backwards

it has been identified to cause suspend regression - and the
commit fixes a longstanding bug that existed before 2.6.25 was
opened - so it can wait some more until the effects are better
understood.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

We handle a broken tsc these days, so no need to panic.  We clear the
TSC bit when tsc_init decides it's unreliable (eg.  under lguest w/ bad
host TSC), leading to bogus panic.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Building UP kernel with KGDB enabled produces the following errors and warning
(fatal due to -Werror in arch/mips/kernel/Makefile):

In file included from arch/mips/kernel/gdb-stub.c:142:
include/asm/smp.h:25:1: "raw_smp_processor_id" redefined
In file included from include/linux/sched.h:69,
                 from arch/mips/kernel/gdb-stub.c:126:
include/linux/smp.h:88:1: this is the location of the previous definition
In file included from arch/mips/kernel/gdb-stub.c:142:
include/asm/smp.h:62: error: redefinition of 'smp_send_reschedule'
include/linux/smp.h:102: error: previous definition of 'smp_send_reschedule' was here
include/asm/smp.h: In function `smp_send_reschedule':
include/asm/smp.h:65: error: dereferencing pointer to incomplete type
arch/mips/kernel/gdb-stub.c: At top level:
arch/mips/kernel/gdb-stub.c:660: warning: 'kgdb_wait' defined but not used

Fix the errors by not directly including <asm/smp.h> (which is already included
by <linux/smp.h>) and the warning by enclosing kgdb_wait() in #ifdef CONFIG_SMP.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Long overdue update of the m68k defconfigs
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The default defconfig should be one from arch/m68k/configs/

arch/m68k/defconfig was not exactly identical to amiga_defconfig but
also considering how long they have been without any update that doesn't
seem to have been on purpose.
Signed-off-by: NAdrian Bunk <adrian.bunk@movial.fi>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The commits:

commit 37a47db8
Author: Balaji Rao <balajirrao@gmail.com>
Date:   Wed Jan 30 13:30:03 2008 +0100

    x86: assign IRQs to HPET timers, fix

and

commit e3f37a54
Author: Balaji Rao <balajirrao@gmail.com>
Date:   Wed Jan 30 13:30:03 2008 +0100

    x86: assign IRQs to HPET timers

have been identified to cause a regression on some platforms due to
the assignement of legacy IRQs which makes the legacy devices
connected to those IRQs disfunctional.

Revert them.

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=10382Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

We already catch most of the TSC problems by sanity checks, but there
is a subtle bug which has been in the code for ever. This can cause
time jumps in the range of hours.

This was reported in:
     http://lkml.org/lkml/2007/8/23/96
and
     http://lkml.org/lkml/2008/3/31/23

I was able to reproduce the problem with a gettimeofday loop test on a
dual core and a quad core machine which both have sychronized
TSCs. The TSCs seems not to be perfectly in sync though, but the
kernel is not able to detect the slight delta in the sync check. Still
there exists an extremly small window where this delta can be observed
with a real big time jump. So far I was only able to reproduce this
with the vsyscall gettimeofday implementation, but in theory this
might be observable with the syscall based version as well.

CPU 0 updates the clock source variables under xtime/vyscall lock and
CPU1, where the TSC is slighty behind CPU0, is reading the time right
after the seqlock was unlocked.

The clocksource reference data was updated with the TSC from CPU0 and
the value which is read from TSC on CPU1 is less than the reference
data. This results in a huge delta value due to the unsigned
subtraction of the TSC value and the reference value. This algorithm
can not be changed due to the support of wrapping clock sources like
pm timer.

The huge delta is converted to nanoseconds and added to xtime, which
is then observable by the caller. The next gettimeofday call on CPU1
will show the correct time again as now the TSC has advanced above the
reference value.

To prevent this TSC specific wreckage we need to compare the TSC value
against the reference value and return the latter when it is larger
than the actual TSC value.

I pondered to mark the TSC unstable when the readout is smaller than
the reference value, but this would render an otherwise good and fast
clocksource unusable without a real good reason.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Cc: xen-devel@lists.xensource.com
Cc: Mark McLoughlin <markmc@redhat.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

i.e. with this simple test case:

    int fd = open("/dev/zero", O_RDONLY);
    munmap(mmap((void *)0x40000000, 0x1000_LEN, PROT_READ, MAP_PRIVATE, fd, 0), 0x1000);
    close(fd);

we currently get:

   kernel BUG at arch/x86/xen/enlighten.c:678!
   ...
   EIP is at xen_release_pt+0x79/0xa9
   ...
   Call Trace:
    [<c041da25>] ? __pmd_free_tlb+0x1a/0x75
    [<c047a192>] ? free_pgd_range+0x1d2/0x2b5
    [<c047a2f3>] ? free_pgtables+0x7e/0x93
    [<c047b272>] ? unmap_region+0xb9/0xf5
    [<c047c1bd>] ? do_munmap+0x193/0x1f5
    [<c047c24f>] ? sys_munmap+0x30/0x3f
    [<c0408cce>] ? syscall_call+0x7/0xb
    =======================

and xen complains:

  (XEN) mm.c:2241:d4 Mfn 1cc37 not pinned

Further details at:

  https://bugzilla.redhat.com/436453Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Cc: xen-devel@lists.xensource.com
Cc: Mark McLoughlin <markmc@redhat.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Cc: xen-devel@lists.xensource.com
Cc: Mark McLoughlin <markmc@redhat.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Fix obsolete printks in aperture-64. We used not to handle missing
agpgart, but we handle it okay now.
Signed-off-by: NPavel Machek <pavel@suse.cz>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

right now if there's no CPU support for nmi_watchdog=2 we'll just
refuse it silently.

print a useful warning.
Signed-off-by: NIngo Molnar <mingo@elte.hu>