After merging the moduleh tree, today's linux-next build (x86_64
allmodconfig) failed like this:

  arch/x86/kernel/sys_x86_64.c:28:10: warning: 'enum align_flags' declared inside parameter list
  arch/x86/kernel/sys_x86_64.c:28:10: warning: its scope is only this definition or declaration, which is probably not what you
  want arch/x86/kernel/sys_x86_64.c:28:22: error: parameter 3 ('flags') has incomplete type
  [...]

Presumably caused by the module.h split interacting with a
new commit dfb09f9b ("x86, amd: Avoid cache aliasing penalties
on AMD family 15h") from the x8 tree.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NBorislav Petkov <borislav.petkov@amd.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Link: http://lkml.kernel.org/r/20110928174214.17a58be15d84d67c185930e1@canb.auug.org.auSigned-off-by: NIngo Molnar <mingo@elte.hu>

L3 subcaches 0 and 1 of AMD Family 15h CPUs can have a size of 2MB.
Update the calculation routine for the number of L3 indices to
reflect that.
Signed-off-by: NFrank Arnold <frank.arnold@amd.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Rosenfeld Hans <Hans.Rosenfeld@amd.com>
Cc: Herrmann3 Andreas <Andreas.Herrmann3@amd.com>
Cc: Mike Travis <travis@sgi.com>
Cc: Frank Arnold <Frank.Arnold@amd.com>
Link: http://lkml.kernel.org/r/20110726170449.GB32536@aftabSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

It's not a good reason to allocate memory in the smp function call
just because someone thought it's the most conveniant place.

The AMD L3 data is coupled to the northbridge info by a pointer to the
corresponding north bridge data. So allocating it with the northbridge
data and referencing the northbridge in the cache_info code instead
uses less memory and gets rid of that atomic allocation hack in the
smp function call.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NBorislav Petkov <borislav.petkov@amd.com>
Cc: Hans Rosenfeld <hans.rosenfeld@amd.com>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: Mike Travis <travis@sgi.com>
Link: http://lkml.kernel.org/r/20110723212626.688229918@linutronix.deSigned-off-by: NIngo Molnar <mingo@elte.hu>

Commit f9b90566 ("x86: reduce stack usage in init_intel_cacheinfo")
introduced a shadow structure to reduce the stack usage on large
machines instead of making the smaller structure embedded into the
large one. That's definitely a candidate for the bad taste award.

Move the small struct into the large one and get rid of the ugly type
casts.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Hans Rosenfeld <hans.rosenfeld@amd.com>
Cc: Borislav Petkov <borislav.petkov@amd.com>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: Mike Travis <travis@sgi.com>
Link: http://lkml.kernel.org/r/20110723212626.625651773@linutronix.deSigned-off-by: NIngo Molnar <mingo@elte.hu>

free_cache_attributes() kfree's:

   per_cpu(ici_cpuid4_info, cpu)->l3

which is a pointer to memory which was allocated as a block in
amd_init_l3_cache(). l3 of a particular cpu points to a part of this
memory blob. The part and the rest of the blob are still referenced by
other cpus.

As far as I can tell from the git history this is a leftover from the
conversion from per cpu to node data with commit ba06edb6(x86,
cacheinfo: Make L3 cache info per node) and the following commit
f658bcfb(x86, cacheinfo: Cleanup L3 cache index disable support)
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Hans Rosenfeld <hans.rosenfeld@amd.com>
Cc: Borislav Petkov <borislav.petkov@amd.com>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: Mike Travis <travis@sgi.com>
Link: http://lkml.kernel.org/r/20110723212626.550539989@linutronix.deSigned-off-by: NIngo Molnar <mingo@elte.hu>

When the moduleu.h splitting tree is merged to the latest
tip:x86/cpu tree, the x86_64 allmodconfig build fails like this:

 arch/x86/kernel/cpu/amd.c: In function 'bsp_init_amd':
 arch/x86/kernel/cpu/amd.c:437:3: error: 'va_align' undeclared (first use in this function)
 arch/x86/kernel/cpu/amd.c:438:23: error: 'ALIGN_VA_32' undeclared (first use in this function)
 arch/x86/kernel/cpu/amd.c:438:37: error: 'ALIGN_VA_64' undeclared (first use in this function)

This is caused by the module.h split up intreacting with commit
dfb09f9b ("x86, amd: Avoid cache aliasing penalties on AMD
family 15h") from the tip:x86/cpu tree.

I have added the following patch for today (this, or something
similar, could be applied to the tip tree directly - the
export.h include below was added by the module.h splitup).

So include elf.h to use va_align and remove this implicit
dependency on module.h doing it for us.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Cc: Borislav Petkov <borislav.petkov@amd.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Link: http://lkml.kernel.org/r/20110810114956.238d66772883636e3040d29f@canb.auug.org.auSigned-off-by: NIngo Molnar <mingo@elte.hu>

hpa reported that dfb09f9b breaks 32-bit
builds with the following error message:

/home/hpa/kernel/linux-tip.cpu/arch/x86/kernel/cpu/amd.c:437: undefined
reference to `va_align'
/home/hpa/kernel/linux-tip.cpu/arch/x86/kernel/cpu/amd.c:436: undefined
reference to `va_align'

This is due to the fact that va_align is a global in a 64-bit only
compilation unit. Move it to mmap.c where it is visible to both
subarches.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
Link: http://lkml.kernel.org/r/1312633899-1131-1-git-send-email-bp@amd64.orgSigned-off-by: NH. Peter Anvin <hpa@zytor.com>

Move code which is run once on the BSP during boot into the cpu_dev
helper.

[ hpa: removed bogus cpu_has -> static_cpu_has conversion ]
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
Link: http://lkml.kernel.org/r/20110805180409.GC26217@aftabSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Add a function ptr to struct cpu_dev which is destined to be run only
once on the BSP during boot.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
Link: http://lkml.kernel.org/r/20110805180116.GB26217@aftabSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

This patch provides performance tuning for the "Bulldozer" CPU. With its
shared instruction cache there is a chance of generating an excessive
number of cache cross-invalidates when running specific workloads on the
cores of a compute module.

This excessive amount of cross-invalidations can be observed if cache
lines backed by shared physical memory alias in bits [14:12] of their
virtual addresses, as those bits are used for the index generation.

This patch addresses the issue by clearing all the bits in the [14:12]
slice of the file mapping's virtual address at generation time, thus
forcing those bits the same for all mappings of a single shared library
across processes and, in doing so, avoids instruction cache aliases.

It also adds the command line option "align_va_addr=(32|64|on|off)" with
which virtual address alignment can be enabled for 32-bit or 64-bit x86
individually, or both, or be completely disabled.

This change leaves virtual region address allocation on other families
and/or vendors unaffected.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
Link: http://lkml.kernel.org/r/1312550110-24160-2-git-send-email-bp@amd64.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Commit 63ab25eb (kgdbts: unify/generalize gdb breakpoint adjustment)
introduced a compile regression on sparc.

kgdbts.c: In function 'check_and_rewind_pc':
kgdbts.c:307: error: implicit declaration of function 'instruction_pointer_set'

Simply add the correct macro definition for instruction pointer on the
Sparc architecture.
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
Acked-by: NMike Frysinger <vapier@gentoo.org>
Acked-by: NDavid S. Miller <davem@davemloft.net>

Yet another variant of the Dell Latitude series which requires
reboot=pci.

From the E5420 bug report by Daniel J Blueman:

> The E6420 is affected also (same platform, different casing and
> features), which provides an external confirmation of the issue; I can
> submit a patch for that later or include it if you prefer:
> http://linux.koolsolutions.com/2009/08/04/howto-fix-linux-hangfreeze-during-reboots-and-restarts/Reported-by: NDaniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
Cc: <stable@kernel.org>

Rebooting on the Dell E5420 often hangs with the keyboard or ACPI
methods, but is reliable via the PCI method.

[ hpa: this was deferred because we believed for a long time that the
  recent reshuffling of the boot priorities in commit
  660e34ce fixed this platform.
  Unfortunately that turned out to be incorrect. ]
Signed-off-by: NDaniel J Blueman <daniel.blueman@gmail.com>
Link: http://lkml.kernel.org/r/1305248699-2347-1-git-send-email-daniel.blueman@gmail.comSigned-off-by: NH. Peter Anvin <hpa@zytor.com>
Cc: <stable@kernel.org>

Video input mux settings for tvp7002 and imager inputs were swapped.
Comment was correct.

Tested on EVM with tvp7002 input.
Signed-off-by: NJon Povey <jon.povey@racelogic.co.uk>
Acked-by: NManjunath Hadli <manjunath.hadli@ti.com>
Cc: stable@kernel.org
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

Avoid NULL dereference of irq_alloc_generic_chip return in low
memory conditions.
Signed-off-by: NTodd Poynor <toddpoynor@google.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

This shift instruction appears to be shifting in the wrong direction.
Without this change, my SparcStation-20MP hangs just after bringing up
the second CPU:

Entering SMP Mode...
Starting CPU 2 at f02b4e90
Brought up 2 CPUs
Total of 2 processors activated (99.52 BogoMIPS).
   *** stuck ***
Signed-off-by: NWill Simoneau <simoneau@ele.uri.edu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Function declaration differs between file: dma.c and file:dma.h
and SPARSE (Documentation/sparse.txt) gives error messages

All dma channels are members of 'enum dma_ch' and not 'unsigned int'
Please have a look at channel definitions in:
arch/arm/mach-s3c64xx/include/mach/dma.h
arch/arm/plat-samsung/include/plat/s3c-dma-pl330.h
arch/arm/mach-s3c2410/include/mach/dma.h
So all arguments should be of type 'enum dma_ch'
Signed-off-by: NSangwook Lee <sangwook.lee@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Signed-off-by: NTodd Poynor <toddpoynor@google.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Commit 234b6ced

   clocksource: convert ARM 32-bit up counting clocksources

broke the build for ixp4xx and made big endian operation impossible.
This commit restores the original behaviour.
Signed-off-by: NRichard Cochran <richard.cochran@omicron.at>
Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>
[ Thomas says that we might want to have generic BE accessor functions
  to the MMIO clock source, but that hasn't happened yet, so in the
  meantime this seems to be the short-term fix for the particular
  problem - Linus ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The code in arch/mips/kernel/i8259.c still hasn't been converted to
using struct syscore_ops instead of a sysdev for resume and shutdown.
As a result, this code doesn't build any more after suspend, resume
and shutdown callbacks have been removed from struct sysdev_class.
Fix this problem by converting i8259.c to using syscore_ops.
Reported-and-tested-by: NRoland Vossen <rvossen@broadcom.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NRalf Baechle <ralf@linux-mips.org>

Fix the printk_once() so that it actually prints (didn't print before
due to a stray comma.)

[ hpa: changed to an incremental patch and adjusted the description
  accordingly. ]
Signed-off-by: NLen Brown <len.brown@intel.com>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107151732480.18606@x980
Cc: <table@kernel.org>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Fix a trivial typo in the name of the constant
ENERGY_PERF_BIAS_POWERSAVE.  This didn't cause trouble because this
constant is not currently used for anything.
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: Len Brown <len.brown@intel.com>
Link: http://lkml.kernel.org/r/tip-abe48b108247e9b90b4c6739662a2e5c765ed114@git.kernel.org

Since 2.6.36 (23016bf0), Linux prints the existence of "epb" in /proc/cpuinfo,
Since 2.6.38 (d5532ee7), the x86_energy_perf_policy(8) utility has
been available in-tree to update MSR_IA32_ENERGY_PERF_BIAS.

However, the typical BIOS fails to initialize the MSR, presumably
because this is handled by high-volume shrink-wrap operating systems...

Linux distros, on the other hand, do not yet invoke x86_energy_perf_policy(8).
As a result, WSM-EP, SNB, and later hardware from Intel will run in its
default hardware power-on state (performance), which assumes that users
care for performance at all costs and not for energy efficiency.
While that is fine for performance benchmarks, the hardware's intended default
operating point is "normal" mode...

Initialize the MSR to the "normal" by default during kernel boot.

x86_energy_perf_policy(8) is available to change the default after boot,
should the user have a different preference.
Signed-off-by: NLen Brown <len.brown@intel.com>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107140051020.18606@x980Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@kernel.org>

The Dell Latitude E6320 doesn't reboot unless reboot=pci is set.
Force it thanks to DMI.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: http://lkml.kernel.org/r/1309269451-4966-1-git-send-email-maxime.ripard@free-electrons.com
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

Commit 74164016 ("arm: davinci: Fix fallout from generic irq chip
conversion") introduced a bug, causing low level interrupt handlers to
get a bogus irq number as an argument. The gpio irq handler falsely
assumes that the handler data is the irq base number and that is no
longer true.

Set the irq handler data to be a pointer to the corresponding gpio
controller. The chained irq handler can then use it to extract both the
irq base number and the gpio registers structure.
Signed-off-by: NIdo Yariv <ido@wizery.com>
CC: Thomas Gleixner <tglx@linutronix.de>
[nsekhar@ti.com: renamed "ctl" to "d", simplified indexing logic for chips and
took care of odd bank handling in irq handler]
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

Just compiling pseries in the kernel causes it to override
memory_block_size_bytes() regardless of what is the runtime
platform.

This cleans up the implementation of that function, fixing
a bug or two while at it, so that it's harmless (and potentially
useful) for other platforms. Without this, bugs in that code
would trigger a WARN_ON() in drivers/base/memory.c when
booting some different platforms.

If/when we have another platform supporting memory hotplug we
might want to either move that out to a generic place or
make it a ppc_md. callback.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The macro MIN_MEMORY_BLOCK_SIZE is currently defined twice in two .c
files, and I need it in a third one to fix a powerpc bug, so let's
first move it into a header
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NIngo Molnar <mingo@elte.hu>

Commit 2706a0bf ("x86, NUMA: Enable CONFIG_AMD_NUMA on 32bit
too") enabled AMD NUMA for 32bit too.  Unfortunately, SPARSEMEM
on 32bit had rather coarse (512MiB) addr->node mapping
granularity due to lack of space in page->flags.  This led to
boot failure on certain AMD NUMA machines which had 128MiB
alignment on nodes.

Patches to properly detect this condition and reject NUMA
configuration are posted[1] but deemed too pervasive for merge
at this point (-rc6).  Disable AMD NUMA for 32bit for now and
re-enable once the detection logic is merged.

[1] http://thread.gmane.org/gmane.linux.kernel/1161279/focus=1162583Reported-by: NHans Rosenfeld <hans.rosenfeld@amd.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Conny Seidel <conny.seidel@amd.com>
Link: http://lkml.kernel.org/r/20110711083432.GC943@htj.dyndns.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>

In commit f0fba2ad (ASoC: multi-component - ASoC Multi-Component
Support), the name of the ak4104 codec driver was changed without
amending the platform code which uses it as well.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

The display requires some milliseconds between GPIO_TFT_VA_EN
and GPIO_DISPLAY_ENABLE. Reorder initialisation to comply with
the display spec.

Also tune timings for better compliance with the spec.
Signed-off-by: NSven Neumann <s.neumann@raumfeld.com>
Acked-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

The backlight control is going to change back to PWM in the
upcoming Raumfeld Controller hardware revision.
Signed-off-by: NSven Neumann <s.neumann@raumfeld.com>
Acked-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

The PXA platform code has a static inline helper called
gpio_to_chip which clashes with the gpiolib namespace if we
try to expose the function with the same name from gpiolib,
and it's still confusing even if we don't do that. So rename
it to gpio_to_pxachip().
Reported-by: NH Hartley Sweeten <hartleys@visionengravers.com>
Cc: Eric Miao <eric.miao@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

If mini2440_init() is in __init, mini2440_parse_features() should also
be in __init. Fixes:

(.text+0x9adc): Section mismatch in reference from the function mini2440_parse_features.clone.0() to the
(unknown reference) .init.data:(unknown)
The function mini2440_parse_features.clone.0() references the (unknown reference) __initdata (unknown).
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Cc: Michel Pollet <buserror@gmail.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Commit bb072c3c (ARM / Samsung: Use struct syscore_ops for "core" power
management) turned s3c2410_dma_resume_chan() from int to void. So, drop
the actual return values, too. Fixes:

arch/arm/plat-s3c24xx/dma.c: In function 's3c2410_dma_resume_chan':
arch/arm/plat-s3c24xx/dma.c:1238:3: warning: 'return' with a value, in function returning void
arch/arm/plat-s3c24xx/dma.c:1250:2: warning: 'return' with a value, in function returning void
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Commit 8970ef47 (S3C24XX: Remove hardware specific registers from DMA
calls) removed the parameter dcon in s3c2410_dma_config() and calculates
it on its own. So the debug-output for the old parameter can go, too.
Fixes:

arch/arm/plat-s3c24xx/dma.c: In function 's3c2410_dma_config':
arch/arm/plat-s3c24xx/dma.c:1030:2: warning: 'dcon' is used uninitialized in this function
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Previously we would check for acpi_sci_override_gsi == gsi every time
a PCI device was enabled. That works during early bootup, but later
on it could lead to triggering unnecessarily the acpi_gsi_to_irq(..) lookup.
The reason is that acpi_sci_override_gsi was declared in __initdata and
after early bootup could contain bogus values.

This patch moves the check for acpi_sci_override_gsi to the
site where the ACPI SCI is preset.

CC: stable@kernel.org
Reported-by: NRaghavendra D Prabhu <rprabhu@wnohang.net>
Tested-by: NRaghavendra D Prabhu <rprabhu@wnohang.net>
[http://lists.xensource.com/archives/html/xen-devel/2011-07/msg00154.html]
Suggested-by: NIan Campbell <ijc@hellion.org.uk>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This fixes a regression introduced by e59347a1 "arm: orion:
Use generic irq chip".

Depending on the device, interrupts acknowledgement is done by setting
or by clearing a dedicated register. Replace irq_gc_ack() with some
{set,clr}_bit variants allows to handle both cases.

Note that this patch affects the following SoCs: Davinci, Samsung and
Orion. Except for this last, the change is minor: irq_gc_ack() is just
renamed into irq_gc_ack_set_bit().

For the Orion SoCs, the edge GPIO interrupts support is currently
broken. irq_gc_ack() try to acknowledge a such interrupt by setting
the corresponding cause register bit. The Orion GPIO device expect the
opposite. To fix this issue, the irq_gc_ack_clr_bit() variant is used.

Tested on Network Space v2.
Reported-by: NJoey Oravec <joravec@drewtech.com>
Signed-off-by: NSimon Guinot <sguinot@lacie.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

This platform has not been converted to 'struct irq_data' when the big
pile was done. It fails to compile nowadays, because the compatibility
code has gone.

  CC      arch/arm/mach-vt8500/irq.o
arch/arm/mach-vt8500/irq.c:118:2: error: unknown field 'ack' specified in initializer
arch/arm/mach-vt8500/irq.c:118:2: warning: initialization from incompatible pointer type
arch/arm/mach-vt8500/irq.c:119:2: error: unknown field 'mask' specified in initializer
arch/arm/mach-vt8500/irq.c:119:2: warning: initialization from incompatible pointer type
arch/arm/mach-vt8500/irq.c:120:2: error: unknown field 'unmask' specified in initializer
arch/arm/mach-vt8500/irq.c:120:2: warning: initialization from incompatible pointer type
arch/arm/mach-vt8500/irq.c:121:2: error: unknown field 'set_type' specified in initializer
arch/arm/mach-vt8500/irq.c:121:2: warning: initialization from incompatible pointer type
make[1]: *** [arch/arm/mach-vt8500/irq.o] Error 1

Add the missing conversion. Tested on a JayPC-Tablet.
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Acked-by: NAlexey Charkov <alchark@gmail.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

To get hundredths of MHz the rate needs to be divided by 10'000.
Here is an example:
 twd_timer_rate = 123456789
 Before the patch:
    twd_timer_rate / 1000000 = 123
    (twd_timer_rate / 1000000) % 100 = 23
    Result: 123.23MHz.
 After being fixed:
    twd_timer_rate / 1000000 = 123
    (twd_timer_rate / 10000) % 100 = 45
    Result: 123.45MHz.
Signed-off-by: NVitaly Kuzmichev <vkuzmichev@mvista.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Testing suggests that at least some Lenovos and some Intels will
fail to reboot via EFI, attempting to jump to an unmapped
physical address. In the long run we could handle this by
providing a page table with a 1:1 mapping of physical addresses,
but for now it's probably just easier to assume that ACPI or
legacy methods will be present and reboot via those.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Alan Cox <alan@linux.intel.com>
Link: http://lkml.kernel.org/r/1309985557-15350-1-git-send-email-mjg@redhat.comSigned-off-by: NIngo Molnar <mingo@elte.hu>