gpio7 on the tps65930 is used as an output on the devkit8000 and
gpio1 is not connected. Remove gpio7 and change gpio1 to pulldown
Signed-off-by: NDaniel Morsing <daniel.morsing@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

offsets in the comment were wrong - fix this.
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fix rtc gpios and mux
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Earlier patches select HAVE_SCHED_CLOCK for omaps. To have working sched_clock
also for MPU timer, we need to implement it in a way where the right one gets
selected during the runtime.
Signed-off-by: NTony Lindgren <tony@atomide.com>

For omap15xx and 730 we need to use the MPU timer
as the 32K timer is not available. For omap16xx
we want to use the 32K timer because of PM. Fix this
by allowing to build in both timers.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Otherwise systems using the MPU timer will hang.
Signed-off-by: NTony Lindgren <tony@atomide.com>

A few headers are included twice, remove them.

Found the following errors using make includecheck:
arch/arm/mach-omap2/clock44xx_data.c: prm44xx.h is
included more than once.
arch/arm/mach-omap2/clockdomains44xx_data.c: cm1_44xx.h
is included more than once.
arch/arm/mach-omap2/clockdomains44xx_data.c: cm2_44xx.h
is included more than once.
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c: prm-regbits-34xx.h
is included more than once.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
[paul@pwsan.com: dropped lists from patch cc:s; tweaked subject line]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Commit 56a6a19d ("omap2plus: prm:
Trvial build break fix for undefined reference to
'omap2_prm_read_mod_reg'") generates a lot of warnings on boot since
clockdomain functions that manipulate wake-up dependencies are not
implemented yet on OMAP4 for 2.6.38.  This patch bypasses the OMAP2/3
functions on OMAP4, which in turn avoids the warnings when the
functions would attempt to call the underlying OMAP2/3 PRCM functions.
A one-line warning is still logged from the clockdomain code that the
OMAP4 wake-up dependency code is not yet implemented.

A clockdomain wake-up and sleep dependency implementation for OMAP4
from Rajendra should be possible to merge during the 2.6.39 merge
window:

    http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41748.html

    http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42222.htmlReported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

After commit dc548fbb ("ARM: omap: convert
sched_clock() to use new infrastructure"), OMAPs that use the 32KiHz
"synchronization timer" as their clocksource crash during boot:

[    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
[    0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[    0.000000] pgd = c0004000
[    0.000000] [00000000] *pgd=00000000
[    0.000000] Internal error: Oops: 80000005 [#1] SMP
[    0.000000] last sysfs file:
[    0.000000] Modules linked in:
[    0.000000] CPU: 0    Tainted: G        W    (2.6.37-07734-g2467802 #7)
[    0.000000] PC is at 0x0
[    0.000000] LR is at sched_clock_poll+0x2c/0x3c
[    0.000000] pc : [<00000000>]    lr : [<c0060b74>]    psr: 600001d3
[    0.000000] sp : c058bfd0  ip : c058a000  fp : 00000000
[    0.000000] r10: 00000000  r9 : 411fc092  r8 : 800330c8
[    0.000000] r7 : c05a08e0  r6 : c0034c48  r5 : c05ffc40  r4 : c0034c4c
[    0.000000] r3 : c05ffe6c  r2 : c05a0bc0  r1 : c059f098  r0 : 00000000
[    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
[    0.000000] Control: 10c53c7f  Table: 8000404a  DAC: 00000017

This is due to the recent ARM init_sched_clock() changes and the late
initialization of the counter_32k clock source.  More information here:

   http://marc.info/?l=linux-omap&m=129513468605208&w=2

Fix by initializing the counter_32k clocksource during the machine timer
initialization.
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NThomas Weber <weber@corscience.de>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Interrupts ought to be disabled _before_ irq_enter().
Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NMatt Turner <mattst88@monolith.freenet-rz.de>

Commit df9ee292 made arch_local_irq_save and arch_local_irq_restore
static inline which with -Werror trips up on __set_hae() and _set_hae()
which are extern inline.  The naive solution is to make __set_hae() and
set_hae() static inline but for reasons described in commit d559d4a2
this breaks the generic kernel build.  Instead, since this is architecture
specific code, this patch hard wires in the architecture specific method
f disabling and enabling interrupts.
Tested-by: NMichael Cree <mcree@orcon.net.nz>
Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NMatt Turner <mattst88@gmail.com>

Acked-by: NKyle McMartin <kyle@redhat.com>
Signed-off-by: NMatt Turner <mattst88@gmail.com>

Remove the leftover from the commit 14e2acd8 ("select:
fix alpha OSF wrapper").
Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NMatt Turner <mattst88@gmail.com>

Signed-off-by: Nmatt mooney <mfm@muteddisk.com>
Signed-off-by: NMatt Turner <mattst88@gmail.com>

Good riddance... Nuke a pile of redundant handlers that the
generic code takes care of as well.
Tested-by: NMichael Cree <mcree@orcon.net.nz>
Signed-off-by: NKyle McMartin <kyle@redhat.com>
Signed-off-by: NMatt Turner <mattst88@gmail.com>

Stop touching irq_desc[irq] directly, instead use accessor
functions provided. Use irq_has_action instead of directly
testing the irq_desc.
Tested-by: NMichael Cree <mcree@orcon.net.nz>
Signed-off-by: NKyle McMartin <kyle@redhat.com>
Signed-off-by: NMatt Turner <mattst88@gmail.com>

Also kill superfluous IRQ_DISABLED initialization, since that's the
default state of the irq_desc[i].status field.
Tested-by: NMichael Cree <mcree@orcon.net.nz>
Signed-off-by: NKyle McMartin <kyle@redhat.com>
Signed-off-by: NMatt Turner <mattst88@gmail.com>

On PARISC, we have an include of linux/mm.h inside our asm/pgtable.h, so
this patch

  commit 14fd403f
  Author: Andrea Arcangeli <aarcange@redhat.com>
  Date:   Thu Jan 13 15:46:37 2011 -0800

      thp: export maybe_mkwrite

causes us an unsatisfiable use of pte_mkwrite in linux/mm.h.

The fix is to avoid including linux/mm.h in our pgtable.h, which
unbreaks the build.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The physical address is never used by the device tree code when
allocating memory for unflattening.  Change the architecture's alloc
hook to return the virutal address instead.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

When DEBUG_LL is not set, we don't want __error_a re-entering
__lookup_machine_type - we want it to go to the error function.  This
used to be the case before we reorganized the layout for hotplug cpu,
as we used to fall through to __error.  With the changed layout, we
need an explicit branch here instead.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Drive strength for PXA910 is a 2 bit value but because of the mapping in
plat-pxa/mfp.h needs to be shifted up one bit to handle real
location in mfp registers.  (MMP2 and PXA910 drive strength start
at bit 11 while PXA168 starts at bit 10).

Values 0, 1, 2, and 3 effectively need to be
0, 2, 4, and 6 to fit into register.  8 does not work.
Signed-off-by: NPhilip Rakity <prakity@marvell.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Drive strength for MMP2 is a 2 bit value but because of the mapping in
plat-pxa/mfp.h needs to be shifted up one bit to handle real
location in mfp registers.  (MMP2 and PXA910 drive strength start
at bit 11 while PXA168 starts at bit 10).

Values 0, 1, 2, and 3 effectively need to be
0, 2, 4, and 6 to fit into register.  8 does not work.
Signed-off-by: NPhilip Rakity <prakity@marvell.com>
Tested-by: NJohn Watlington <wad@laptop.org>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
Tested-by: NMarek Vasut <marek.vasut@gmail.com>

Rabin Vincent reports:
| On SMP, this BUG() in save_stack_trace_tsk() can be easily triggered
| from user space by reading /proc/$PID/stack, where $PID is any pid but
| the current process:
|
|	if (tsk != current) {
| #ifdef CONFIG_SMP
|		/*
|		 * What guarantees do we have here that 'tsk'
|		 * is not running on another CPU?
|		 */
|		BUG();
| #else

Fix this by replacing the BUG() with an entry to terminate the stack
trace, returning an empty trace - I'd rather not expose the dwarf
unwinder to a volatile stack of a running thread.
Reported-by: NRabin Vincent <rabin@rab.in>
Tested-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Build errors similar this appeared in todays kautobuild for the above
targets:

In file included from arch/arm/include/asm/pgtable.h:461,
                 from arch/arm/mach-pxa/generic.c:26:
include/asm-generic/pgtable.h: In function 'ptep_test_and_clear_young':
include/asm-generic/pgtable.h:29: error: dereferencing pointer to incomplete type

None of the .c files including asm/pgtable.h with this error is using
this header, so simply remove the include.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fixes this build error:

 ERROR: "arbitrary_virt_to_machine" [drivers/xen/xen-gntdev.ko] undefined!
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Do not use memory bank info to request the "system ram" resources as
they do not track holes created by memblock_remove inside
machine's reserve callback. If the removed memory is passed as
platform_device's ioresource, then drivers that call
request_mem_region would fail due to a conflict with the incorrectly
configured system ram resource.

Instead, iterate through the regions of memblock.memory and add
those as "System RAM" resources.
Signed-off-by: NDima Zavin <dima@android.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

OLPC uses select for OLPC_OPENFIRMWARE, which means OLPC has to
enforce the dependencies for OLPC_OPENFIRMWARE.  Make sure it does so.
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: Daniel Drake <dsd@laptop.org>
Cc: Andres Salomon <dilinger@queued.net>
Cc: Grant Likely <grant.likely@secretlab.ca>
LKML-Reference: <20100923162846.D8D409D401B@zog.reactivated.net>
Cc: <stable@kernel.org> 2.6.37

Offlining the secondary CPU causes the timer irq affinity to be set to
CPU 0. When the secondary CPU is back online again, the wrong irq
affinity will be used.

This patch ensures secondary per CPU timer always has the correct
IRQ affinity when enabled.
Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
LKML-Reference: <1294963604-18111-1-git-send-email-jacob.jun.pan@linux.intel.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@kernel.org> 2.6.37

Implement __pmd macro for ia64 too.
Signed-off-by: NAndrea Arcangeli <aarcange@redhat.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

The GS_IA18_S (GMS) is a carrier board from GeoSIG Ltd used with the
Stamp9G20 SoM from Taskit company.
It operate as an internet accelerometer.
Signed-off-by: NIgor Plyatov <plyatov@gmail.com>
[nicolas.ferre@atmel.com: rm Kconfig, whitespace fixes, change machine name]
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

Signed-off-by: NSergio Tanzilli <tanzilli@acmesystems.it>
[nicolas.ferre@atmel.com: whitespace fixes, change machine name]
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

Konrad Wilk reported that the new delayed calibration crashes with a
divide by zero on Xen. The reason is that Xen sets the pmtimer
address, but reading from it returns 0xffffff. That results in the
ref_start and ref_stop value being the same, so the delta is zero
which causes the divide by zero later in the calculation.

The conditional (!hpet && !ref_start && !ref_stop) which sanity checks
the calibration reference values doesn't really make sense. If the
refs are null, but hpet is on, we still want to break out.

The div by zero would be possible to trigger by chance if both reads
from the hardware provided the exact same value (due to hardware
wrapping).

So checking if both the ref values are the same should handle if we
don't have hardware (both null) or if they are the same value (either by
invalid hardware, or by chance), avoiding the div by zero issue.

[ tglx: Applied the same fix to native_calibrate_tsc() where this
  	check was copied from ]
Reported-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
LKML-Reference: <1295024788-15619-1-git-send-email-johnstul@us.ibm.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

This functionality is known to be incomplete, so discourage its use in
general-purpose kernels.

The only reason to use this driver is to support PCI hotplug on CNB20LE-
based machines that don't have ACPI, and there are very few such
systems.

Reference: https://bugzilla.redhat.com/show_bug.cgi?id=665109Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The broadcom_bus.c quirk was written (without benefit of documentation)
to support PCI hotplug on an old system that doesn't have ACPI.  As
such, we should only use it when the system doesn't have ACPI.

If the system does have ACPI and we need the host bridge description, we
should get it from the ACPI _CRS method.  On machines older than 2008,
we currently ignore _CRS, but that doesn't mean we should use
broadcom_bus.c.  It means we should either (a) do what we've done in the
past and assume everything in the PCI gap is routed to bus 0 (so hotplug
may not work), or (b) arrange to use _CRS.  This patch does (a).

Reference: https://bugzilla.redhat.com/show_bug.cgi?id=665109Acked-by: NIra W. Snyder <iws@ovro.caltech.edu>
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This patch enables pci=bfsort by default on future Dell systems.
It reads SMBIOS type 0xB1 vendor specific record and sets pci=bfsort
accordingly.

Offset  Name    Length  Value   Description

04      Flags0  Word    Varies  Bits 9-10
                                - 10:9 = 00  Unknown
                                - 10:9 = 01  Breadth First
                                - 10:9 = 10  Depth First
                                - 10:9 = 11  Reserved

1. Any time pci=bfsort has to be enabled on a system, we need to add the
   model number of the system to the white list. With this patch, that
   is not required.

2. Typically, model number has to be added to the white list when the
   system is under development. With this change, that is not required.
Signed-off-by: NJordan Hargrave <jordan_hargrave@dell.com>
Signed-off-by: NNarendra K <narendra_k@dell.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Signed-off-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>