All of the davinci SoCs need to call davinci_clk_init() so
put the call in the common init routine.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

The Davinci cpu_is_davinci_*() macros use the SoC part number
and variant retrieved from the JTAG ID register to determine the
type of cpu that the kernel is running on.  Currently, the code to
read the JTAG ID register assumes that the register is always at
the same base address.  This isn't true on some newer SoCs.

To solve this, have the SoC-specific code set the JTAG ID register
base address in soc_info structure and add a 'cpu_id' member to it.
'cpu_id' will be used by the cpu_is_davinci_*() macros to match
the cpu id.  Also move the info used to identify the cpu type into
the SoC-specific code to keep all SoC-specific code together.

The common code will read the JTAG ID register, search through
an array of davinci_id structures to identify the cpu type.
Once identified, it will set the 'cpu_id' member of the soc_info
structure to the proper value and the cpu_is_davinci_*() macros
will now work.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Create a structure to encapsulate SoC-specific information.
This will assist in generalizing code so it can be used by
different SoCs that have similar hardware but with minor
differences such as having a different base address.

The idea is that the code for each SoC fills out a structure
with the correct information.  The board-specific code then
calls the SoC init routine which in turn will call a common
init routine that makes a copy of the structure, maps in I/O
regions, etc.

After initialization, code can get a pointer to the structure
by calling davinci_get_soc_info().  Eventually, the common
init routine will make a copy of all of the data pointed to
by the structure so the original data can be made __init_data.
That way the data for SoC's that aren't being used won't consume
memory for the entire life of the kernel.

The structure will be extended in subsequent patches but
initially, it holds the map_desc structure for any I/O
regions the SoC/board wants statically mapped.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Add SoC and platform-specific data and init for DaVinci EMAC network
driver.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Add SoC and platform-specific data and init for MMC driver.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Add support for DM646x SoC (a.k.a DaVinci HD) and its Evalution
Module (EVM.)

Original support done by Sudhakar Rajashekhara.
Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

In addition, add board support for the DM355 Evaluation Module (EVM)
and the DM355 Leopard board.

Original DM355 EVM support done by Sandeep Paulraj, with significant
updates and improvements by David Brownell.  DM355 Leopord support
done by Koen Kooi.
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: NKoen Kooi <koen@beagleboard.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Signed-off-by: NHugo Villeneuve <hugo.villeneuve@lyrtech.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Add support for Texas Instuments Common Platform Interrupt Controller
(cp_intc) used on DA830/OMAP-L137.
Signed-off-by: NSteve Chen <schen@mvista.com>
Signed-off-by: NMark Greer <mgreer@mvista.com>
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

The davinci pre-kernel boot code assumes that all platforms use the
same UART base address for the console.  That assumption is not longer
valid with some newer SoCs so determine the console UART base address
from the machine number passed in from bootloader.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Signed-off-by: NTroy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch defines debug macros for low-level debugging for Davinci
based platforms

Tested on :
        - DM644x DaVinci EVM
        - DM646X DaVinciHD EVM
	- DM355 EVM

This patch attempts to solve the low-level debug issue in DM646x. The
UART on DM646x SoC allows only 32-bit access. The existing
debug-macro.S uses the macros from debug-8250.S file. This led to
garbage serial out in the case of DM646x.

The inclusion of debug-8250.S does not allow for run time fix for this
issue.  There are compile time errors due to multiple definitions of
the macros.  Also when building a single image for multiple DaVinci
Platforms, the ifdefs cannot be relied upon.

The solution below does not include the debug-8250.S file and defines
the necessary macros. This solution was arrived at after observing
that word access does not affect the low-level debug messages on
DM644x/DM355.

The other approach to this issue is to use the UART module information
available in the peripheral registers to decide the access
mechanism. But this will have to be done for every access of UART
specifically for DM646x. Also this calls for a modification of the
debug-8250.S file.
Signed-off-by: NChaithrika U S <chaithrika@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch seems to get me much more reliable performance using the
GPIO banked interrupts on dm355 for the dm9000 driver.

Changes include:

- init GPIO handling along with normal GPIO init
- mask the level-sensitive bank IRQ during handling
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Fix two IRQ triggering bugs affecting GPIO IRQs:

 - Make sure enabling with IRQ_TYPE_NONE ("default, unspecified")
   isn't a NOP ... default to both edges, at least one must work.

 - As noted by Kevin Hilman, setting the irq trigger type for a
   banked gpio interrupt shouldn't enable irqs that are disabled.

Since GPIO IRQs haven't been used much yet, it's not clear these
bugs could have affected anything.  The few current users don't
seem to have been obviously suffering from these issues.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

They are unneeded and as the issue fixed in lmo commit
63f7ec59053e3f850ab67a9938e631bcba64c6ce shows even harmful.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

  CC      arch/mips/sgi-ip32/ip32-reset.o
cc1: warnings being treated as errors
arch/mips/sgi-ip32/ip32-reset.c: In function 'debounce':
arch/mips/sgi-ip32/ip32-reset.c:97: error: 'reg_a' is used uninitialized in this function

The issues is old but due to the volatile keyword gcc older than 4.4 did
not warn about this obvious bug.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The type of the second argument of access_ok should be (void __user *).
The unnecessary conversion of the clear_user address argument was causing
sparse to emit warnings on the __chk_user_ptr check.
Signed-off-by: NWu Zhangjin <wuzhangjin@gmail.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Something in the HW or FW setup is busted and MSIs aren't working with
IPR on Bimini, so until we figure out exaxtly what's up, we quirk them
out
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This patch fixes the ap325rxa ncm03j camera code to handle
the case where no i2c driver is present. Without this fix
i2c_transfer() may be passed NULL as adapter which results
in a crash.

Triggered when i2c-sh_mobile.c failed to probe() due to
missing MSTP clocks.
Signed-off-by: NMagnus Damm <damm@igel.co.jp>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

The address range size calculation inside local_flush_tlb_kernel_range()
is being truncated by a too small size variable holder on 64-bit systems.
The truncated size can result in an erroneous tlbsize check that means we
sit spinning inside a loop trying to flush a hige number of TLB entries.
This is for all intents and purposes a system hang. Fix by using an
appropriately sized valiable to hold the size.

[Ralf: Greg's original patch submission identified the issue and fixed one
instance in tlb-r4k.c but there there were several more.  For consistency
I also modified tlb-r3k.c even though that file is only used on 32-bit.]
Signed-off-by: NGreg Ungerer <gerg@snapgear.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Richard Sandiford's new code for inserting the cache-barriers, for GCC
4.3 and above and already incorporated in the current GCC-release, uses
a slightly different option-syntax.
Signed-off-by: Npeter fuerst <post@pfrst.de>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The hang was caused by the use of disable_irq() from the interrupt handler
itself.  Fixed by the use of disable_irq_nosync().  The issue was
triggered by:

    commit 3aa551c9
    Author: Thomas Gleixner <tglx@linutronix.de>
    Date:   Mon Mar 23 18:28:15 2009 +0100

        genirq: add threaded interrupt handler support
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The hang was caused by the use of disable_irq() from the interrupt handler
itself.  Fixed by the use of disable_irq_nosync().  The issue was
triggered by:

    commit 3aa551c9
    Author: Thomas Gleixner <tglx@linutronix.de>
    Date:   Mon Mar 23 18:28:15 2009 +0100

        genirq: add threaded interrupt handler support
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Remove the __initdata annotation for the clock lookups, since they
will be needed when loading modules which use clk_get().
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Remove the __initdata annotation for the clock lookups, since they
will be needed when loading modules which use clk_get().
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

+ Fix typographic fault.
Signed-off-by: NMichal Simek <monstr@monstr.eu>

Signed-off-by: NMichal Simek <monstr@monstr.eu>

Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

pfn_valid() is meant to be able to tell if a given PFN has valid memmap
associated with it or not. In FLATMEM, it is expected that holes always
have valid memmap as long as there is valid PFNs either side of the hole.
In SPARSEMEM, it is assumed that a valid section has a memmap for the
entire section.

However, ARM and maybe other embedded architectures in the future free
memmap backing holes to save memory on the assumption the memmap is never
used. The page_zone linkages are then broken even though pfn_valid()
returns true. A walker of the full memmap must then do this additional
check to ensure the memmap they are looking at is sane by making sure the
zone and PFN linkages are still valid. This is expensive, but walkers of
the full memmap are extremely rare.

This was caught before for FLATMEM and hacked around but it hits again for
SPARSEMEM because the page_zone linkages can look ok where the PFN linkages
are totally screwed. This looks like a hatchet job but the reality is that
any clean solution would end up consumning all the memory saved by punching
these unexpected holes in the memmap. For example, we tried marking the
memmap within the section invalid but the section size exceeds the size of
the hole in most cases so pfn_valid() starts returning false where valid
memmap exists. Shrinking the size of the section would increase memory
consumption offsetting the gains.

This patch identifies when an architecture is punching unexpected holes
in the memmap that the memory model cannot automatically detect and sets
ARCH_HAS_HOLES_MEMORYMODEL. At the moment, this is restricted to EP93xx
which is the model sub-architecture this has been reported on but may expand
later. When set, walkers of the full memmap must call memmap_valid_within()
for each PFN and passing in what it expects the page and zone to be for
that PFN. If it finds the linkages to be broken, it assumes the memmap is
invalid for that PFN.
Signed-off-by: NMel Gorman <mel@csn.ul.ie>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

I don't think anything guarantees that the objects in data.page_aligned
are a multiple of PAGE_SIZE, thus the section may end on any boundary.

So the following section, .data.cacheline_aligned needs an explicit
alignment.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Refresh and set these options:

 CONFIG_SYSFS_DEPRECATED_V2: y -> n
 CONFIG_INPUT_JOYSTICK:      y -> n
 CONFIG_HID_SONY:            n -> m
 CONFIG_RTC_DRV_PS3:         - -> m
Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

After upgrading my distcc boxes from gcc 4.2.2 to 4.4.0, the function
graph tracer broke. This was discovered on my x86 boxes.

The issue is that gcc used the same register for an output as it did for
an input in an asm statement. I first thought this was a bug in gcc and
reported it. I was notified that gcc was correct and that the output had
to be flagged as an "early clobber".

I noticed that powerpc had the same issue and this patch fixes it.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

pr_debug() can now result in code being generated even when #DEBUG
is not defined. That's not really desirable in the ftrace code
which we want to be snappy.

With CONFIG_DYNAMIC_DEBUG=y:

size before:
   text	   data	    bss	    dec	    hex	filename
   3334	    672	      4	   4010	    faa	arch/powerpc/kernel/ftrace.o

size after:
   text	   data	    bss	    dec	    hex	filename
   2616	    360	      4	   2980	    ba4	arch/powerpc/kernel/ftrace.o
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

With CONFIG_DEBUG_VM, an assertion is made when changing the protection
flags of a PTE that the PTE is locked. Huge pages use a different pagetable
format and the assertion is bogus and will always trigger with a bug looking
something like

 Unable to handle kernel paging request for data at address 0xf1a00235800006f8
 Faulting instruction address: 0xc000000000034a80
 Oops: Kernel access of bad area, sig: 11 [#1]
 SMP NR_CPUS=32 NUMA Maple
 Modules linked in: dm_snapshot dm_mirror dm_region_hash
  dm_log dm_mod loop evdev ext3 jbd mbcache sg sd_mod ide_pci_generic
  pata_amd ata_generic ipr libata tg3 libphy scsi_mod windfarm_pid
  windfarm_smu_sat windfarm_max6690_sensor windfarm_lm75_sensor
  windfarm_cpufreq_clamp windfarm_core i2c_powermac
 NIP: c000000000034a80 LR: c000000000034b18 CTR: 0000000000000003
 REGS: c000000003037600 TRAP: 0300   Not tainted (2.6.30-rc3-autokern1)
 MSR: 9000000000009032 <EE,ME,IR,DR>  CR: 28002484  XER: 200fffff
 DAR: f1a00235800006f8, DSISR: 0000000040010000
 TASK = c0000002e54cc740[2960] 'map_high_trunca' THREAD: c000000003034000 CPU: 2
 GPR00: 4000000000000000 c000000003037880 c000000000895d30 c0000002e5a2e500
 GPR04: 00000000a0000000 c0000002edc40880 0000005700000393 0000000000000001
 GPR08: f000000011ac0000 01a00235800006e8 00000000000000f5 f1a00235800006e8
 GPR12: 0000000028000484 c0000000008dd780 0000000000001000 0000000000000000
 GPR16: fffffffffffff000 0000000000000000 00000000a0000000 c000000003037a20
 GPR20: c0000002e5f4ece8 0000000000001000 c0000002edc40880 0000000000000000
 GPR24: c0000002e5f4ece8 0000000000000000 00000000a0000000 c0000002e5f4ece8
 GPR28: 0000005700000393 c0000002e5a2e500 00000000a0000000 c000000003037880
 NIP [c000000000034a80] .assert_pte_locked+0xa4/0xd0
 LR [c000000000034b18] .ptep_set_access_flags+0x6c/0xb4
 Call Trace:
 [c000000003037880] [c000000003037990] 0xc000000003037990 (unreliable)
 [c000000003037910] [c000000000034b18] .ptep_set_access_flags+0x6c/0xb4
 [c0000000030379b0] [c00000000014bef8] .hugetlb_cow+0x124/0x674
 [c000000003037b00] [c00000000014c930] .hugetlb_fault+0x4e8/0x6f8
 [c000000003037c00] [c00000000013443c] .handle_mm_fault+0xac/0x828
 [c000000003037cf0] [c0000000000340a8] .do_page_fault+0x39c/0x584
 [c000000003037e30] [c0000000000057b0] handle_page_fault+0x20/0x5c
 Instruction dump:
 7d29582a 7d200074 7800d182 0b000000 3c004000 3960ffff 780007c6 796b00c4
 7d290214 7929a302 1d290068 7d6b4a14 <800b0010> 7c000074 7800d182 0b000000

This patch fixes the problem by not asseting the PTE is locked for VMAs
backed by huge pages.
Signed-off-by: NMel Gorman <mel@csn.ul.ie>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Having discussed broadcast tick support with Thomas Glexiner, the
broadcast tick devices should be registered with a higher rating
than the global tick device, and it should have the ONESHOT and
PERIODIC feature flags set.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NThomas Glexiner <tglx@linutronix.de>

smp_cross_call_done() is a no-op for MPCore, and since it's only
used by platform code, there's no point in having it unless it's
doing something.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The ARM SMP code wasn't properly updated for the cpumask changes, which
results in smp_timer_broadcast() broadcasting ticks to non-online CPUs.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Compilation for this board yields the following errors:

arch/arm/mach-pxa/viper.c:511: error: 'FFUART' undeclared here (not in a function)
arch/arm/mach-pxa/viper.c:520: error: 'BTUART' undeclared here (not in a function)
arch/arm/mach-pxa/viper.c:529: error: 'STUART' undeclared here (not in a function)

Fix them by including the necessary header.
Signed-off-by: NRicardo Martins <rasm@fe.up.pt>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>