Not only does this file duplicate <linux/bitops.h> and implement a
well-known antipattern, it is also not used by anything.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Removing __init from check_platform_magic since it is called by
xen_unplug_emulated_devices in non-init contexts (It probably gets inlined
because of -finline-functions-called-once, removing __init is more to avoid
mismatch being reported).
Signed-off-by: Raghavendra D Prabhu <rprabhu@wnohang.net>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In the past we would only use the function's value if the
returned value was not equal to 'acpi_sci_override_gsi'. Meaning
that the INT_SRV_OVR values for global and source irq were different.
But it is OK to use the function's value even when the global
and source irq are the same.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In the past (2.6.38) the 'xen_allocate_pirq_gsi' would allocate
an entry in a Linux IRQ -> {XEN_IRQ, type, event, ..} array. All
of that has been removed in 2.6.39 and the Xen IRQ subsystem uses
an linked list that is populated when the call to
'xen_allocate_irq_gsi' (universally done from any of the xen_bind_*
calls) is done. The 'xen_allocate_pirq_gsi' is a NOP and there is
no need for it anymore so lets remove it.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
As the code paths that are guarded by CONFIG_XEN_DOM0 already depend
on CONFIG_ACPI so the extra #ifdef is not required. The earlier
patch that added them in had done its job.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
.. which means we can preset of NR_IRQS_LEGACY interrupts using
the 'acpi_get_override_irq' API before this loop.
This means that we can get the IRQ's polarity (and trigger) from either
the ACPI (or MP); or use the default values. This fixes a bug if we did
not have an IOAPIC we would not been able to preset the IRQ's polarity
if the MP table existed.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Since they are only called once and the rest of the pci_xen_*
functions follow the same pattern of setup.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In the past we would guard those code segments to be dependent
on CONFIG_XEN_DOM0 (which depends on CONFIG_ACPI) so this patch is
not stricly necessary. But the next patch will merge common
HVM and initial domain code and we want to make sure the CONFIG_ACPI
dependency is preserved - as HVM code does not depend on CONFIG_XEN_DOM0.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Update the out-dated comment at the beginning of the file.
Also provide the copyrights of folks who have been contributing
to this code lately.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
The file is hard to read. Move the code around so that
the contents of it follows a uniform format:
- setup GSIs - PV, HVM, and initial domain case
- then MSI/MSI-x setup - PV, HVM and then initial domain case.
- then MSI/MSI-x teardown - same order.
- lastly, the __init functions in PV, HVM, and initial domain order.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
The code in setup_ioapic_irq() determines the Destination Field,
so why not also include it in the debug printk output that gets
displayed when the boot parameter "apic=debug" is used.
Before the change, "dmesg" will show:
IOAPIC[0]: Set routing entry (8-1 -> 0x31 -> IRQ 1 Mode:0 Active:0)
IOAPIC[0]: Set routing entry (8-2 -> 0x30 -> IRQ 0 Mode:0 Active:0)
IOAPIC[0]: Set routing entry (8-3 -> 0x33 -> IRQ 3 Mode:0 Active:0) ...
After the change, you will see:
IOAPIC[0]: Set routing entry (8-1 -> 0x31 -> IRQ 1 Mode:0 Active:0 Dest:0)
IOAPIC[0]: Set routing entry (8-2 -> 0x30 -> IRQ 0 Mode:0 Active:0 Dest:0)
IOAPIC[0]: Set routing entry (8-3 -> 0x33 -> IRQ 3 Mode:0 Active:0 Dest:0) ...
Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com>
Link: http://lkml.kernel.org/r/20110708184603.2734.91071.sendpatchset@nchumbalkar.americas.cpqcorp.net
Signed-off-by: Ingo Molnar <mingo@elte.hu>
When IOAPIC data is displayed in "dmesg" with the help of the
boot parameter "apic=debug" certain values are not formatted
correctly wrt their size.
In the "dmesg" snippet below, note that the output for "max
redirection entries", and "IO APIC version" which are each
defined to be just 8-bits long are displayed as 2 bytes in
length. Similarly, "Dst" under the "IRQ redirection table"
should only be 8-bits long.
IO APIC #0......
...
...
.... register #01: 00170020
....... : max redirection entries: 0017
....... : PRQ implemented: 0
....... : IO APIC version: 0020
...
...
.... IRQ redirection table:
NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
00 000 1 0 0 0 0 0 0 00
01 000 0 0 0 0 0 0 0 31
02 000 0 0 0 0 0 0 0 30
03 000 1 0 0 0 0 0 0 33
...
...
Do some formatting clean up, so you will see output like below:
IO APIC #0......
...
...
.... register #01: 00170020
....... : max redirection entries: 17
....... : PRQ implemented: 0
....... : IO APIC version: 20
...
...
.... IRQ redirection table:
NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
00 00 1 0 0 0 0 0 0 00
01 00 0 0 0 0 0 0 0 31
02 00 0 0 0 0 0 0 0 30
03 00 1 0 0 0 0 0 0 33
...
...
Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com>
Link: http://lkml.kernel.org/r/20110708184557.2734.61830.sendpatchset@nchumbalkar.americas.cpqcorp.net
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Commit 2706a0bf7b ("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=1162583
Reported-by: Hans Rosenfeld <hans.rosenfeld@amd.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Conny Seidel <conny.seidel@amd.com>
Link: http://lkml.kernel.org/r/20110711083432.GC943@htj.dyndns.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Make sure that the 'static' keywork is at the beginning of declaration
for arch/xtensa/variants/s6000/include/variant/dmac.h
This gets rid of warnings like
warning: ‘static’ is not at beginning of declaration
when building with -Wold-style-declaration (and/or -Wextra which also
enables it).
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Make sure that the 'static' keywork is at the beginning of declaration
for arch/sh/*
This gets rid of warnings like
warning: ‘static’ is not at beginning of declaration
when building with -Wold-style-declaration (and/or -Wextra which also
enables it).
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Make sure that the 'static' keywork is at the beginning of declaration
for arch/mips/include/asm/mach-jz4740/gpio.h
This gets rid of warnings like
warning: ‘static’ is not at beginning of declaration
when building with -Wold-style-declaration (and/or -Wextra which also
enables it).
Also a few tiny whitespace changes.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Make sure that the 'static' keywork is at the beginning of declaration
for arch/arm/mach-shmobile/board-ap4evb.c
This gets rid of warnings like
warning: ‘static’ is not at beginning of declaration
when building with -Wold-style-declaration (and/or -Wextra which also
enables it).
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
After commits d13586574d ("OMAP: McBSP:
implement functional clock switching via clock framework") and
cf4c87abe2 ("OMAP: McBSP: implement
McBSP CLKR and FSR signal muxing via mach-omap2/mcbsp.c"), any OMAP1
board (such as the AMS Delta) that uses the ASoC McBSP driver will no
longer build:
sound/built-in.o: In function `omap_mcbsp_dai_set_dai_sysclk':
last.c:(.text+0x24ff8): undefined reference to `omap2_mcbsp1_mux_clkr_src'
last.c:(.text+0x2500c): undefined reference to `omap2_mcbsp1_mux_fsr_src'
make: *** [vmlinux] Error 1
Fix by defining three OMAP1-only dummy functions for
omap2_mcbsp1_mux_clkr_src(), omap2_mcbsp1_mux_fsr_src(), and
omap2_mcbsp_set_clks_src().
Normally, code that is OMAP SoC-revision-specific like this should go
under the arch/arm/*omap* directories, and get abstracted away from
drivers via struct platform_data function pointers. This doesn't work
in this case since there doesn't appear to be any convenient way to access
struct platform_data (or something like it) in the current design of
the sound/soc/omap/omap-mcbsp.c driver.
Reported by Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> and Tony Lindgren
<tony@atomide.com>. Janusz also posted a patch to fix this at:
http://www.spinics.net/lists/linux-omap/msg39560.html
(among other places), but the following approach seems less dependent
on compiler behavior.
This patch passes build tests for ams_delta_defconfig and omap2plus_defconfig,
but since I don't have an AMS Delta here, I can't boot test it on that
platform.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
A pcmcia_init callback isn't used on any of the platforms. Drop it.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
gpio_request_array() / gpio_free_array() are functional replacements for
mio_gpio_request() / mio_gpio_free(), which are now obsolete.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
gpio_request_array() is a functional replacement for hx4700_gpio_request(),
which is now obsolete.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Use gpio_request_array() / gpio_free_array() in backlight init and exit
functions and global gpio initialization.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Commit "ARM: pxa: align NR_BUILTIN_GPIO with GPIO interrupt number"
increased NR_BUILTIN_GPIO from 128 to PXA_GPIO_IRQ_NUM (192).
Adjust the previously hardcoded MAGICIAN_EGPIO_BASE accordingly.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
introduce pr_fmt, so the pr_* calls will be cleaner
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
use gpio_request_<one|array>() instead of multiple gpiolib calls
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
While in sleep mode the CS# and other V3020 RTC GPIOs must be driven
high, otherwise V3020 RTC fails to keep the right time in sleep mode.
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Cc: stable@kernel.org
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
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: Daniel Mack <zonque@gmail.com>
Signed-off-by: Eric 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: Sven Neumann <s.neumann@raumfeld.com>
Acked-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Eric 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: Sven Neumann <s.neumann@raumfeld.com>
Acked-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Make sure that the 'static' keywork is at the beginning of declaration
for arch/arm/mach-shmobile/board-ap4evb.c
This gets rid of warnings like
warning: ‘static’ is not at beginning of declaration
when building with -Wold-style-declaration (and/or -Wextra which also
enables it).
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Switch the sh7372 CPU support to use CMT2 instead
of CMT1 for system timer.
CMT1 is located in the A3SP power domain while CMT2
is located in the always-on power domain C5.
This improves our PM situation - with CMT2 as timer
we can power down A3SP and still access the timer.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
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: H Hartley Sweeten <hartleys@visionengravers.com>
Cc: Eric Miao <eric.miao@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Make sure that the 'static' keywork is at the beginning of declaration
for arch/sh/*
This gets rid of warnings like
warning: ‘static’ is not at beginning of declaration
when building with -Wold-style-declaration (and/or -Wextra which also
enables it).
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
clocksource support. This achieves several things:
1. It means we get rid of all these helper functions which frankly should
never have been necessary.
2. It means omap_readl() inside these helper functions does not appear in
ftrace output.
Another plus is that we avoid the overhead of calculating the address to
read each time, but a minus is that we use readl() which has a barrier.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[tony@atomide.com: updated to use ioremap]
Signed-off-by: Tony Lindgren <tony@atomide.com>
