This patch removes the simplistic implementation of irq_domains and enables
the powerpc infrastructure for all irq_domain users. The powerpc
infrastructure includes support for complex mappings between Linux and
hardware irq numbers, and can manage allocation of irq_descs.
This patch also converts the few users of irq_domain_add()/irq_domain_del()
to call irq_domain_add_legacy() instead.
v3: Fix bug that set up too many irqs in translation range.
v2: Fix removal of irq_alloc_descs() call in gic driver
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Milton Miller <miltonm@bga.com>
Tested-by: Olof Johansson <olof@lixom.net>
Add support for a legacy mapping where irq = (hwirq - first_hwirq + first_irq)
so that a controller driver can allocate a fixed range of irq_descs and use
a simple calculation to translate back and forth between linux and hw irq
numbers. This is needed to use an irq_domain with many of the ARM interrupt
controller drivers that manage their own irq_desc allocations. Ultimately
the goal is to migrate those drivers to use the linear revmap, but doing it
this way allows each driver to be converted separately which makes the
migration path easier.
This patch generalizes the IRQ_DOMAIN_MAP_LEGACY method to use
(first_irq-first_hwirq) as the offset between hwirq and linux irq number,
and adds checks to make sure that the hwirq number does not exceed range
assigned to the controller.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Milton Miller <miltonm@bga.com>
Tested-by: Olof Johansson <olof@lixom.net>
Each revmap type has different arguments for setting up the revmap.
This patch splits up the generator functions so that each revmap type
can do its own setup and the user doesn't need to keep track of how
each revmap type handles the arguments.
This patch also adds a host_data argument to the generators. There are
cases where the host_data pointer will be needed before the function returns.
ie. the legacy map calls the .map callback for each irq before returning.
v2: - Add void *host_data argument to irq_domain_add_*() functions
- fixed failure to compile
- Moved IRQ_DOMAIN_MAP_* defines into irqdomain.c
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Milton Miller <miltonm@bga.com>
Tested-by: Olof Johansson <olof@lixom.net>
This patch only moves the code. It doesn't make any changes, and the
code is still only compiled for powerpc. Follow-on patches will generalize
the code for other architectures.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Milton Miller <miltonm@bga.com>
Tested-by: Olof Johansson <olof@lixom.net>
There is only one user, and it is trivial to open-code.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Milton Miller <miltonm@bga.com>
Tested-by: Olof Johansson <olof@lixom.net>
This patch drops the powerpc-specific irq_map table and replaces it with
directly using the irq_alloc_desc()/irq_free_desc() interfaces for allocating
and freeing irq_desc structures.
This patch is a preparation step for generalizing the powerpc-specific virq
infrastructure to become irq_domains.
As part of this change, the irq_big_lock is changed to a mutex from a raw
spinlock. There is no longer any need to use a spin lock since the irq_desc
allocation code is now responsible for the critical section of finding
an unused range of irq numbers.
The radix lookup table is also changed to store the irq_data pointer instead
of the irq_map entry since the irq_map is removed. This should end up being
functionally equivalent since only allocated irq_descs are ever added to the
radix tree.
v5: - Really don't ever allocate virq 0. The previous version could still
do it if hint == 0
- Respect irq_virq_count setting for NOMAP. Some NOMAP domains cannot
use virq values above irq_virq_count.
- Use numa_node_id() when allocating irq_descs. Ideally the API should
obtain that value from the caller, but that touches a lot of call sites
so will be deferred to a follow-on patch.
- Fix irq_find_mapping() to include irq numbers lower than
NUM_ISA_INTERRUPTS. With the switch to irq_alloc_desc*(), the lowest
possible allocated irq is now returned by arch_probe_nr_irqs().
v4: - Fix incorrect access to irq_data structure in debugfs code
- Don't ever allocate virq 0
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Milton Miller <miltonm@bga.com>
Tested-by: Olof Johansson <olof@lixom.net>
This patch drops the powerpc-specific irq_host structures and uses the common
irq_domain strucutres defined in linux/irqdomain.h. It also fixes all
the users to use the new structure names.
Renaming irq_host to irq_domain has been discussed for a long time, and this
patch is a step in the process of generalizing the powerpc virq code to be
usable by all architecture.
An astute reader will notice that this patch actually removes the irq_host
structure instead of renaming it. This is because the irq_domain structure
already exists in include/linux/irqdomain.h and has the needed data members.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Milton Miller <miltonm@bga.com>
Tested-by: Olof Johansson <olof@lixom.net>
Trivial change, microblaze doesn't use irq remapping yet.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Part of the series to unify the irq remapping mechanisms in the
kernel. A follow up patch will copy the powerpc implementation into
kernel/irq/irqdomain.c, which will be a lot easier if the structures
are identical.
Where they differ, I've chose to use the powerpc names since there is
a lot more code using those names.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Milton Miller <miltonm@bga.com>
Tested-by: Olof Johansson <olof@lixom.net>
This set of changes are fixing various section mismatch warnings which
look to be completely valid. Primerily, those which are fixed are those
which can cause oopses by manipulation of driver binding via sysfs. For
example: calling code marked __init from driver probe __devinit
functions.
Some of these changes will be reworked at the next merge window when the
underlying reasons are sorted out. In the mean time, I think it's
important to have this fixed for correctness.
Also included in this set are fixes to various error messages in OMAP -
including making them gramatically correct, fixing a few spelling
errors, and more importantly, making them greppable by unwrapping them.
Tony Lindgren has acked all these patches, put them out for testing a
week ago, and I've tested them on the platforms I have.
* 'omap-fixes-warnings' of git://git.linaro.org/people/rmk/linux-arm:
ARM: omap: resolve nebulous 'Error setting wl12xx data'
ARM: omap: fix wrapped error messages in omap_hwmod.c
ARM: omap: fix section mismatch warnings in mux.c caused by hsmmc.c
ARM: omap: fix section mismatch warning for sdp3430_twl_gpio_setup()
ARM: omap: fix section mismatch error for omap_4430sdp_display_init()
ARM: omap: fix section mismatch warning for omap_secondary_startup()
ARM: omap: preemptively fix section mismatch in omap4_sdp4430_wifi_mux_init()
ARM: omap: fix section mismatch warning in mux.c
ARM: omap: fix section mismatch errors in TWL PMIC driver
ARM: omap: fix uninformative vc/i2c configuration error message
ARM: omap: fix vc.c PMIC error message
ARM: omap: fix prm44xx.c OMAP44XX_IRQ_PRCM build error
This pull request covers the major oopsing issues with OMAP, caused by
the lack of the TWL driver. Even when the TWL driver is not built in,
we shouldn't oops.
* 'omap-fixes-urgent' of git://git.linaro.org/people/rmk/linux-arm:
ARM: omap: fix broken twl-core dependencies and ifdefs
ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c
ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found
Some code - especially the crypto layer - wants to use the x86
FP/MMX/AVX register set in what may be interrupt (typically softirq)
context.
That *can* be ok, but the tests for when it was ok were somewhat
suspect. We cannot touch the thread-specific status bits either, so
we'd better check that we're not going to try to save FP state or
anything like that.
Now, it may be that the TS bit is always cleared *before* we set the
USEDFPU bit (and only set when we had already cleared the USEDFP
before), so the TS bit test may actually have been sufficient, but it
certainly was not obviously so.
So this explicitly verifies that we will not touch the TS_USEDFPU bit,
and adds a few related sanity-checks. Because it seems that somehow
AES-NI is corrupting user FP state. The cause is not clear, and this
patch doesn't fix it, but while debugging it I really wanted the code to
be more obviously correct and robust.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It was marked asmlinkage for some really old and stale legacy reasons.
Fix that and the equally stale comment.
Noticed when debugging the irq_fpu_usable() bugs.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It's useful to print the error code when a called function fails so a
diagnosis of why it failed is possible. In this case, it fails because
we try to register some data for the wl12xx driver, but as the driver
is not configured, a stub function is used which simply returns -ENOSYS.
Let's do the simple thing for -rc and print the error code.
Also, the return code from platform_register_device() at each of these
sites was not being checked. Add some checking, and again print the
error code.
This should be fixed properly for the next merge window so we don't
issue error messages merely because a driver is not configured.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
While trying to debug my OMAP platforms, they emitted this message:
omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state
The following backtrace said it was from a function called '_enable',
which didn't provide much clue. Grepping didn't find it either.
The message is wrapped, so unwrap the message so grep can find it. Do
the same for three other messages in this file.
Acked-by: Paul Walmsley <paul@pwsan.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The previous commit causes new section mismatch warnings:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb30): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio()
The function omap_init_hsmmc() references
the function __init omap_mux_init_gpio().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_gpio is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb4c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio()
The function omap_init_hsmmc() references
the function __init omap_mux_init_gpio().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_gpio is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb60): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb6c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb78): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb90): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb9c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdba8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbc0): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbcc): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbd8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbf8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc04): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc10): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc28): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc34): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc40): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc58): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc64): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc70): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc7c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
Again, as for omap2_hsmmc_init(), these functions are callable at
runtime via the gpio-twl4030.c driver, and so these can't be marked
__init.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xd0f0): Section mismatch in reference from the function sdp3430_twl_gpio_setup() to the function .init.text:omap2_hsmmc_init()
The function sdp3430_twl_gpio_setup() references
the function __init omap2_hsmmc_init().
This is often because sdp3430_twl_gpio_setup lacks a __init
annotation or the annotation of omap2_hsmmc_init is wrong.
sdp3430_twl_gpio_setup() is called via platform data from the
gpio-twl4030 module, which can be inserted and removed at runtime.
This makes sdp3430_twl_gpio_setup() callable at runtime, and prevents
it being marked with an __init annotation.
As it calls omap2_hsmmc_init() unconditionally, the only resolution to
this warning is to remove the __init markings from omap2_hsmmc_init()
and its called functions. This addresses the functions in hsmmc.c.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xb798): Section mismatch in reference from the function omap_4430sdp_display_init() to the function .init.text:omap_display_init()
The function omap_4430sdp_display_init() references
the function __init omap_display_init().
This is often because omap_4430sdp_display_init lacks a __init
annotation or the annotation of omap_display_init is wrong.
Fix this by adding __init to omap_4430sdp_display_init().
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
WARNING: vmlinux.o(.text+0x1c664): Section mismatch in reference from the function omap_secondary_startup() to the function .cpuinit.text:secondary_startup()
The function omap_secondary_startup() references
the function __cpuinit secondary_startup().
This is often because omap_secondary_startup lacks a __cpuinit
annotation or the annotation of secondary_startup is wrong.
Unfortunately, fixing this causes a new warning which is harder to
solve:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x5328): Section mismatch in reference from the function omap4_hotplug_cpu() to the function .cpuinit.text:omap_secondary_startup()
The function omap4_hotplug_cpu() references
the function __cpuinit omap_secondary_startup().
This is often because omap4_hotplug_cpu lacks a __cpuinit
annotation or the annotation of omap_secondary_startup is wrong.
because omap4_hotplug_cpu() is used by power management code as well,
which may not end up using omap_secondary_startup().
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Found by review.
omap4_sdp4430_wifi_mux_init() is called by an __init marked function,
and only calls omap_mux_init_gpio() and omap_mux_init_signal() which
are both also an __init marked functions.
The only reason this doesn't issue a warning is because the compiler
inlines omap4_sdp4430_wifi_mux_init() into omap4_sdp4430_wifi_init().
So, lets add the __init annotation to ensure this remains safe should
the compiler choose not to inline.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x15a4): Section mismatch in reference from the function omap_mux_init_signals() to the function .init.text:omap_mux_init_signal()
The function omap_mux_init_signals() references
the function __init omap_mux_init_signal().
This is often because omap_mux_init_signals lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
On my OMAP4 platform, I'm getting this error message repeated several
times at boot:
omap_vc_i2c_init: I2C config for all channels must match.
omap_vc_i2c_init: I2C config for all channels must match.
This doesn't help identify what the problem is. Fix this message to
be more informative:
omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0).
This allows us to identify which voltage domains have a problem, and
what the I2C configuration state (a boolean, i2c_high_speed) setting
being used actually is.
From this we find that omap4_core_pmic has i2c_high_speed false, but
omap4_iva_pmic and omap4_mpu_pmic both have it set true.
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
While testing on my OMAP3430 platform, this error message was emitted:
omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc
Trying to find this message was difficult because it was wrapped across
several lines. It also mis-spells "required", doesn't read very well,
and has spaces lacking. Let's replace it with a more concise:
omap_vc_init_channel: No PMIC info for vdd_core
While we're here, fix a simple spelling error in a comment.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When CONFIG_OF is disabled, the compile fails with:
arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function)
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf: Fix double start/stop in x86_pmu_start()
perf evsel: Fix an issue where perf report fails to show the proper percentage
perf tools: Fix prefix matching for kernel maps
perf tools: Fix perf stack to non executable on x86_64
perf: Remove deprecated WARN_ON_ONCE()
Just a few new device ids, omap serial driver regression fixes, and a
build fix for the 8250 driver movement.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk80KZgACgkQMUfUDdst+yk0HgCeIdU3VTWqdxZDXp3G1sFIXZ1b
47YAnRAMAar+/aLaNhqGrcz7aa5y2cUU
=8sr8
-----END PGP SIGNATURE-----
Merge tag 'tty-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Serial/TTY fixes for the 3.3-rc3 tree
Just a few new device ids, omap serial driver regression fixes, and a
build fix for the 8250 driver movement.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tag 'tty-3.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
tty: serial: omap-serial: wakeup latency constraint is in microseconds, not milliseconds
tty: serial: OMAP: block idle while the UART is transferring data in PIO mode
tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode
m32r: relocate drivers back out of 8250 dir
tty: fix a build failure on sparc
serial: samsung: Add support for EXYNOS5250
serial: samsung: Add support for EXYNOS4212 and EXYNOS4412
drivers/tty/vt/vt_ioctl.c: fix KDFONTOP 32bit compatibility layer
Prevent OMAP UARTs from going idle while they are still transferring
data in PIO mode. This works around an oversight in the OMAP UART
hardware present in OMAP34xx and earlier: an idle UART won't send a
wakeup when the TX FIFO threshold is reached. This causes long delays
during data transmission when the MPU powerdomain enters a low-power
mode. The MPU interrupt controller is not able to respond to
interrupts when it's in a low-power state, so the TX buffer is not
refilled until another wakeup event occurs.
This fix changes the erratum i291 DMA idle workaround. Rather than
toggling between force-idle and no-idle, it will toggle between
smart-idle and no-idle. The important part of the workaround is the
no-idle part, so this shouldn't result in any change in behavior.
This fix should work on all OMAP UARTs. Future patches intended for
the 3.4 merge window will make this workaround conditional on a
"feature" flag, and will use the OMAP36xx+ TX event wakeup support.
Thanks to Kevin Hilman <khilman@ti.com> for mentioning the erratum i291
workaround, which led to the development of this approach.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Govindraj.R <govindraj.raja@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ARM kernel uses undefined instructions to implement
BUG/BUG_ON(). This leads to problems where people don't read one
line above the Oops message and see the "kernel BUG at ..."
message and so they wrongly assume the kernel has hit an
undefined instruction.
Instead of printing:
Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP
print
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
This should prevent people from thinking the BUG_ON was an
undefined instruction when it was actually intentional.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
armv7's flush_cache_all() flushes caches via set/way. To
determine the cache attributes (line size, number of sets,
etc.) the assembly first writes the CSSELR register to select a
cache level and then reads the CCSIDR register. The CSSELR register
is banked per-cpu and is used to determine which cache level CCSIDR
reads. If the task is migrated between when the CSSELR is written and
the CCSIDR is read the CCSIDR value may be for an unexpected cache
level (for example L1 instead of L2) and incorrect cache flushing
could occur.
Disable interrupts across the write and read so that the correct
cache attributes are read and used for the cache flushing
routine. We disable interrupts instead of disabling preemption
because the critical section is only 3 instructions and we want
to call v7_dcache_flush_all from __v7_setup which doesn't have a
full kernel stack with a struct thread_info.
This fixes a problem we see in scm_call() when flush_cache_all()
is called from preemptible context and sometimes the L2 cache is
not properly flushed out.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
With an admittedly exotic choice of configuration options
(CC_OPTIMIZE_FOR_SIZE, THUMB2, some other size-minimizing ones)
and compiler, the proc_info table can end up being misaligned,
and the kernel being unbootable (Error: unrecognized/unsupported
processor variant).
Forcing the alignement to 4 bytes in the linker script fixes the
issue.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
It includes:
- a compile fix for fsl-diu-fb
- a fix for a suspend/resume issue in atmel_lcdfb
- a fix for a suspend/resume issue in OMAP
- a workaround for a hardware bug to avoid physical damage in OMAP
- a really trivial dead code removal in intelfb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
iQIcBAABAgAGBQJPMG54AAoJECSVL5KnPj1PR6QQAKOoD4luFRw2F85jdk4GYBiX
WqUWc1OlKYxCGIhk6LpV6fwBLDZCTjOw9NU/9i3JIOHAscGzqVvUce1zYwolEu0B
tTH15/6Bh6uuRJEKYF8H53t1vsbrutssvUsqVcJsHrfie6bVjqjGV18cLT9siVy5
jEZnU958Nb7t8hk7Af1ppQkbB4cpExHX4k3hXTKM+dOkRWMaH1fHv2dnikKuYXDq
G7PC57VqN89DP14M+isUGt5uUgaMSmI09VdTYZ8xgULaZwOxnfOQNnceb/AaKnTY
I2oHDNlNwmiHVgafN7uS0tAhIqnlYOAVLJNLlDfL7xC71AyH6WtzwJuhXnqun7v6
moSwzzGKHohCXyeTjMAthx6HyLq55fBPAI1CmEEtmFLMv1tADLAp9Rm4dsaAjyF8
7aKJO/9iGEpolLYjAGJGGjgCALa+/NWdXnW/zP/2vmcjAaPOZtd0YlD3OaPYr31p
0cImhG57xIAfh60BRq+/FDthEN478Xj8f2jRe/2nsonw8JuFodZZ6nUaFeQS25X/
X/07Wkvmz2CY8FoPeXDHaKO8B1wJphzvY2iJjDwI1jg8u/PT2agILNM24tH3SVky
s6nyBLOEBHZh7mVwll2YifjZ6zzJm4y09LzgZpqXmUXOYPDn5JP9yZE4+R23RaEY
kVz8fkE/FjmjAlx/WjKa
=2uP4
-----END PGP SIGNATURE-----
Merge tag 'fbdev-fixes-for-3.3-1' of git://github.com/schandinat/linux-2.6
fbdev fixes for 3.3
It includes:
- compile fix for fsl-diu-fb
- fix for a suspend/resume issue in atmel_lcdfb
- fix for a suspend/resume issue in OMAP
- workaround for a hardware bug to avoid physical damage in OMAP
- really trivial dead code removal in intelfb
* tag 'fbdev-fixes-for-3.3-1' of git://github.com/schandinat/linux-2.6:
atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume
intelfb: remove some dead code
drivers/video: compile fixes for fsl-diu-fb.c
OMAPDSS: HDMI: PHY burnout fix
OMAP: 4430SDP/Panda: add HDMI HPD gpio
OMAP: 4430SDP/Panda: setup HDMI GPIO muxes
OMAPDSS: remove wrong HDMI HPD muxing
OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD
OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios
OMAPDSS: use sync versions of pm_runtime_put
Kevin Cernekee reported that recent cleanup
that replaced pci_iomap with a generic function
failed to take into account the differences
in io port handling on mips and sh architectures.
Rather than revert the changes reintroducing the
code duplication, this patchset fixes this
by adding ability for architectures to override
ioport mapping for pci devices.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJPL9X8AAoJECgfDbjSjVRpgzgIAIQGeWIP0JUWDDhLfYscTBZx
96Am+8+maVl12t+evVH8lMnJDSqjKH0kWxk6CTQSUo57gZ4ne1SxbZ0+s5DcsE6m
XAnIvkA+4pw36l4QRkEj8g+yrhpQhqaiKJt/l80jaVFGVAw47WrxGKatUe9L90lI
X7+xa/F5zvZO6oamEI94SAojIvmKkZfHIjGc/NaZLaWHRysdFf8Ek13mj2+9FLq3
dxmg9F14eS2X59tIkN4BLM4Dq8UyZqraT0N/0bO0Tetqx0azzNZbsBsg5RwQ15IF
Ei0dMFARoT9UcIpdSwtpGGCoqYa5yRHFT1g54hv/Pon0mKUjG7Fpz5LRWmZ5Xic=
=b1R2
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
arch: fix ioport mapping on mips,sh
Kevin Cernekee reported that recent cleanup that replaced pci_iomap with
a generic function failed to take into account the differences in io
port handling on mips and sh architectures.
Rather than revert the changes reintroducing the code duplication, this
patchset fixes this by adding ability for architectures to override
ioport mapping for pci devices.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
sh: use the the PCI channels's io_map_base
mips: use the the PCI controller's io_map_base
lib: add NO_GENERIC_PCI_IOPORT_MAP
The following patch fixes a bug introduced by the following
commit:
e050e3f0a7 ("perf: Fix broken interrupt rate throttling")
The patch caused the following warning to pop up depending on
the sampling frequency adjustments:
------------[ cut here ]------------
WARNING: at arch/x86/kernel/cpu/perf_event.c:995 x86_pmu_start+0x79/0xd4()
It was caused by the following call sequence:
perf_adjust_freq_unthr_context.part() {
stop()
if (delta > 0) {
perf_adjust_period() {
if (period > 8*...) {
stop()
...
start()
}
}
}
start()
}
Which caused a double start and a double stop, thus triggering
the assert in x86_pmu_start().
The patch fixes the problem by avoiding the double calls. We
pass a new argument to perf_adjust_period() to indicate whether
or not the event is already stopped. We can't just remove the
start/stop from that function because it's called from
__perf_event_overflow where the event needs to be reloaded via a
stop/start back-toback call.
The patch reintroduces the assertion in x86_pmu_start() which
was removed by commit:
84f2b9b ("perf: Remove deprecated WARN_ON_ONCE()")
In this second version, we've added calls to disable/enable PMU
during unthrottling or frequency adjustment based on bug report
of spurious NMI interrupts from Eric Dumazet.
Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Stephane Eranian <eranian@google.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: markus@trippelsdorf.de
Cc: paulus@samba.org
Link: http://lkml.kernel.org/r/20120207133956.GA4932@quad
[ Minor edits to the changelog and to the code ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Fixing a regression with the PMU MSRs when PMU virtualization is
disabled, a guest-internal DoS with the SYSCALL instruction, and a dirty
memory logging race that may cause live migration to fail.
* 'kvm-updates/3.3' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: do not #GP on perf MSR writes when vPMU is disabled
KVM: x86: fix missing checks in syscall emulation
KVM: x86: extend "struct x86_emulate_ops" with "get_cpuid"
KVM: Fix __set_bit() race in mark_page_dirty() during dirty logging
* A series of OMAP regression fixes for merge window fallout
* Two patches for Davinci, one removes some misdefined clocks, the other
is a regression fix for merge window fallout
* Two patches that makes Broadcom bcmring build again (and removes a
bunch of unused code in the process)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPLYzVAAoJEIwa5zzehBx3QSMP/17+6JYJEnzNgZAnrCNm03EK
4f72pLIh6SSKn85jrq+mYlUorakUhlkF26G7+IyYz96YsvvEjrp8mKqlnate4Svv
veROfNIa12AifX6H/0hr9xiRJLK+RLz933HAywh24x9GeKBAjoS72EcZRmThZWJ9
RssfzAXAUbAfwYJyczcEpLOLkg7HJIAx5w7mQLh/hkhWkDKAugO8z1tSKESN98F3
HJtSKE84Xg17y0c1SRoBTV3npSf3D2RptSX0r7H/nT3dpM1lSjoPvawtqdGf+ibT
plHmRY75ebGEq18CHOl177YXPq0iUyfCDLqsu/nbcTtWoY/Cdfdj5gmMHuCYItcY
8JJ758KUIJeHBpjbfeFbAPXJwa2FTnhgG9IQmCWuO47mquBCAi2TCWMmyNi1+kuZ
PB+RkoU8O99bIwI+9vza1apVjjqx7rW6+9IS56KXkKYq6FkSbkvtpuveYvkvuboT
D9o9GKmLL2Z4qE0XG7jsFi7RU1dymTaWow4chyx/iVvNvZnA/Yb9z1CmbydsyLV3
ND1e7Tt49OIjy764Vw1KNmnIhd2joFoqF4jcw/+ID+Hy7cFSuBjjIR6TkZrqYjNf
FhgqrRTl4iIw9zIroAJFuWOQOe82vxDDRVTe/7S7SrhvF5nTDF0AqHmeenBo6cLM
0CfOwbRxbpgXfDpaHbH9
=tFsG
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
arm-soc fixes for 3.3-rc
* A series of OMAP regression fixes for merge window fallout
* Two patches for Davinci, one removes some misdefined clocks, the other
is a regression fix for merge window fallout
* Two patches that makes Broadcom bcmring build again (and removes a
bunch of unused code in the process)
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: bcmring: fix build failure in mach-bcmring/arch.c
ARM: bcmring: remove unused DMA map code
ARM: davinci: update mdio bus name
ARM: OMAP2+: arch/arm/mach-omap2/smartreflex.c: add missing iounmap
ARM: OMAP2+: arch/arm/mach-omap2/devices.c: introduce missing kfree
ARM: OMAP: fix MMC2 loopback clock handling
ARM: OMAP: fix erroneous mmc2 clock change on mmc3 setup
ARM: OMAP2+: GPMC: fix device size setup
ARM: OMAP2+: timer: Fix crash due to wrong arg to __omap_dm_timer_read_counter
ARM: OMAP3: hwmod data: register dss hwmods after dss_core
ARM: OMAP2/3: PRM: fix missing plat/irqs.h build breakage
ARM: OMAP2+: io: fix compilation breakage on 2420-only configs
ARM: OMAP4: hwmod data: Add names for DMIC memory address space
ARM: OMAP3: hwmod data: add SYSC_HAS_ENAWAKEUP for dispc
ARM: OMAP2+: hwmod data: split omap2/3 dispc hwmod class
ARM: davinci: DA850: remove non-existing pll1_sysclk4-7 clocks
ARM: OMAP2: fix regulator warnings
ARM: OMAP2: fix omap3 touchbook kconfig warning
i2c: OMAP: Fix OMAP1 build error
Upstream commit d1fce9c115
"ARM: restart: bcmring: use new restart hook"
breaks building of this platform, since what used to be the
last field of the MACHINE_START/END block didn't have a
trailing comma. Once another field was added below, we get:
arch/arm/mach-bcmring/arch.c:198: error: request for member 'restart' in something not a structure or union
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Jiandong Zheng <jdzheng@broadcom.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Remove BCMRING DMA map code which is no longer used.
This also fixes a build error with dma.c introduced by
bfcd2ea6a4.
Signed-off-by: Jiandong Zheng <jdzheng@broadcom.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
i.MX SDMA: Fix burstsize settings
ARM: mach-shmobile: both USB DMAC instances on sh7372 are slave-only
dma: sh_dma: not all SH DMAC implementations support MEMCPY
at_hdmac: bugfix for enabling channel irq
dmaengine: fix missing 'cnt' in ?: in dmatest
Enable use of the generic atomic64 implementation on AVR32 platforms.
Without this the kernel fails to build as the architecture does not
provide its version.
Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Defining memscan() as memchr() is wrong, because the return values of
memscan() and memchr() are different when the character is not found. So
use the generic memscan() implementation to fix this.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Chris Zankel <chris@zankel.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
__kuser_cmpxchg64 has a return path using bx lr to get back to the caller.
This is actually ok since the code in question is predicated on
CONFIG_CPU_32v6K, but for the sake of consistency using the usr_ret
macro is probably better.
Acked-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
With the new throttling/unthrottling code introduced with
commit:
e050e3f0a7 ("perf: Fix broken interrupt rate throttling")
we occasionally hit two WARN_ON_ONCE() checks in:
- intel_pmu_pebs_enable()
- intel_pmu_lbr_enable()
- x86_pmu_start()
The assertions are no longer problematic. There is a valid
path where they can trigger but it is harmless.
The assertion can be triggered with:
$ perf record -e instructions:pp ....
Leading to paths:
intel_pmu_pebs_enable
intel_pmu_enable_event
x86_perf_event_set_period
x86_pmu_start
perf_adjust_freq_unthr_context
perf_event_task_tick
scheduler_tick
And:
intel_pmu_lbr_enable
intel_pmu_enable_event
x86_perf_event_set_period
x86_pmu_start
perf_adjust_freq_unthr_context.
perf_event_task_tick
scheduler_tick
cpuc->enabled is always on because when we get to
perf_adjust_freq_unthr_context() the PMU is not totally
disabled. Furthermore when we need to adjust a period,
we only stop the event we need to change and not the
entire PMU. Thus, when we re-enable, cpuc->enabled is
already set. Note that when we stop the event, both
pebs and lbr are stopped if necessary (and possible).
Signed-off-by: Stephane Eranian <eranian@google.com>
Cc: peterz@infradead.org
Link: http://lkml.kernel.org/r/20120202110401.GA30911@quad
Signed-off-by: Ingo Molnar <mingo@elte.hu>
* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
bugs, x86: Fix printk levels for panic, softlockups and stack dumps
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf top: Fix number of samples displayed
perf tools: Fix strlen() bug in perf_event__synthesize_event_type()
perf tools: Fix broken build by defining _GNU_SOURCE in Makefile
x86/dumpstack: Remove unneeded check in dump_trace()
perf: Fix broken interrupt rate throttling
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/rt: Fix task stack corruption under __ARCH_WANT_INTERRUPTS_ON_CTXSW
sched: Fix ancient race in do_exit()
sched/nohz: Fix nohz cpu idle load balancing state with cpu hotplug
sched/s390: Fix compile error in sched/core.c
sched: Fix rq->nr_uninterruptible update race
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/reboot: Remove VersaLogic Menlow reboot quirk
x86/reboot: Skip DMI checks if reboot set by user
x86: Properly parenthesize cmpxchg() macro arguments
Linux uses two PMD entries for a PTE with the classic page table format,
covering 2MB range. However, the __pte_free_tlb() function only adds a
single TLB flush corresponding to 1MB range covering 'addr'. On
Cortex-A15, level 1 entries can be cached by the TLB independently of
the level 2 entries and without additional flushing a PMD entry would be
left pointing at the wrong PTE. The patch limits the TLB flushing range
to two 4KB pages around the 1MB boundary within PMD.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 89d6c0b5 ("perf, arch: Add generic NODE cache events") added
empty NODE event definitions for the ARM PMU implementations. This was
merged along with Cortex-A5 and Cortex-A15 PMU support, so they missed
out on the original patch.
This patch adds the empty definitions to Cortex-A5 and Cortex-A15.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
