* 'sh/ehci' of master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6:
sh: Convert to USB_ARCH_HAS_OHCI/EHCI selects.
usb: ehci-sh: Add missing ehci helpers.
usb: ehci-sh: Fix up fault in shutdown path.
sh: Add EHCI support for SH7786.
usb: ehci-hcd: Add support for SuperH EHCI.
usb: ohci-sh: Set IRQ as shared.
* '2.6.37-rc4-pvhvm-fixes' of git://xenbits.xen.org/people/sstabellini/linux-pvhvm:
xen: unplug the emulated devices at resume time
xen: fix save/restore for PV on HVM guests with pirq remapping
xen: resume the pv console for hvm guests too
xen: fix MSI setup and teardown for PV on HVM guests
xen: use PHYSDEVOP_get_free_pirq to implement find_unbound_pirq
The MACH_MINI2440 entry requires the backlight LED driver, but this
subsystem has not been enabled and the select of LEDS_TRIGGER_BACKLIGHT
alone is insufficient to enable the necessary bits of the LED driver.
Add NEW_LEDS, LEDS_CLASS and LEDS_TRIGGER to the select to allow the
kernel to link.
This fixes the following error:
drivers/built-in.o: In function `led_trigger_set':
/home/ben/linux.git/drivers/leds/led-triggers.c:116: undefined reference to `led_brightness_set'
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
* 'upstream/core' of git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen:
xen: allocate irq descs on any NUMA node
xen: prevent crashes with non-HIGHMEM 32-bit kernels with largeish memory
xen: use default_idle
xen: clean up "extra" memory handling some more
* 'upstream/bugfix' of git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen:
xen: x86/32: perform initial startup on initial_page_table
xen: don't bother to stop other cpus on shutdown/reboot
* 'sh-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6:
sh: se/7724: Remove FSI/B of GPIO init code
sh: se/7724: Update clock framework of FSI clock to non-legacy
sh: Assume new page cache pages have dirty dcache lines.
sh: boards: mach-se: use IS_ERR() instead of NULL check
sh: Add div6_reparent_clks to clock framework for FSI
dma: shdma: add a MODULE_ALIAS() to allow module autoloading
Implement asm/syscall.h for the MN10300 arch.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Currently, to define a GPIO number, we're using something like :
#define EFIKAMX_PCBID0 (2*32 + 16)
to define GPIO 3 16.
This is not really readable and it's error prone imho (note the 3 vs 2).
So, I'm introducing a new macro to define this in a better way. Now, the
code sample become :
#define EFIKAMX_PCBID0 IMX_GPIO_NR(3, 16)
v2:
- move to gpio.h
- add parens & spaces
- switch to IMX_GPIO_NR instead of MX51_GPIO_NR
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Cc: Amit Kucheria <amit.kucheria@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Eric Bénard <eric@eukrea.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Commit 124bf94a "ARM: imx: fix name for functions adding sdhci-esdhc-imx devices"
changed some devices and Kconfig entry and didn't change every places
it should have. It's breaking efikamx build. I've fixed 3ds Kconfig
entry as I believe it's broken there too.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
In commit 2c20b9f (ARM: mx25: dynamically allocate mxc-ehci devices) I
changed the offset to the value specified in the reference manual
intending to test this change on hardware. This slipped through and now
prooved to be wrong. So fix it and add a comment about the
documentation being wrong.
Reported-by: Jaume Ribot <jaume@fqingenieria.es>
Cc: Michael Trimarchi <trimarchi@gandalf.sssup.it>
Cc: Shawn Guo <shawn.gsc@gmail.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
commits 2eb42d5c28 and
9e1dde3387 renamed some defines
but didn't fix all the places where these defines are used
leading to a compile failure for USB on i.MX31, 35 and 27.
Signed-off-by: Eric Bénard <eric@eukrea.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The SDMA firmware consists of a ROM part and a RAM part.
The ROM part is always present in the SDMA engine and
is sufficient for many cases.
This patch allows to pass in platform data containing
the script addresses in ROM, so loading a firmware is
optional now.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Dan Williams <dan.j.williams@intel.com>
As we've now removed the spinlock and bitmask, we have nothing left
which requires interrupts to be disabled when sending an IPI. All
current IPI-sending implementations use the GIC, which also does not
require interrupts disabled when calling gic_raise_softirq().
Remove the now unnecessary IRQ disable.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Avoid using bitmasks and locks in the percpu area for IPIs, and instead
use individual software generated interrupts to identify the reason for
the IPI. This avoids the problems of having spinlocks in the percpu
area.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This allows us to use smp_cross_call() to trigger a number of different
software generated interrupts, rather than combining them all on one
SGI. Recover the SGI number via do_IPI.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
smp_cross_call_done() was removed long ago (see 78d236c - remove useless
smp_cross_call_done()). Remove those which have been subsequently
merged.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch improves the state of the AG5 clock
framework support. The main clock parent is
automatically detected, but most of the clocks
are not used by any driver or subsystem at this
point. More work is needed for support of multi
media hardware such as FSI and/or LCDC/MIPI-DSI.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Wakeup-on-timer code does not have/need debugfs dependency. Move
the function out of debugfs ifdef.
Fixes compile error when CONFIG_DEBUG_FS is disabled but PM debug is
enabled.
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
When OneNAND support is disabled, the platform code defines NULL
board_onenand_data and empty init function for us. By utilizing this we
can avoid cluttering board files with dummy definitions/wrappers.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
When OneNAND support is disabled, the platform code defines NULL
board_onenand_data and empty init function for us. By utilizing this we
can avoid cluttering board files with dummy definitions/wrappers.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
If CONFIG_OMAP_MUX is not enabled, we can define board_mux in the header
file instead of forcing every single board to define it.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
[tony@atomide.com: updated for combined board-zoom files]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Boot to boot the TSC calibration may vary by quite a large amount.
While normal variance of 50-100ppm can easily be seen, the quick
calibration code only requires 500ppm accuracy, which is the limit
of what NTP can correct for.
This can cause problems for systems being used as NTP servers, as
every time they reboot it can take hours for them to calculate the
new drift error caused by the calibration.
The classic trade-off here is calibration accuracy vs slow boot times,
as during the calibration nothing else can run.
This patch uses a delayed workqueue to calibrate the TSC over the
period of a second. This allows very accurate calibration (in my
tests only varying by 1khz or 0.4ppm boot to boot). Additionally this
refined calibration step does not block the boot process, and only
delays the TSC clocksoure registration by a few seconds in early boot.
If the refined calibration strays 1% from the early boot calibration
value, the system will fall back to already calculated early boot
calibration.
Credit to Andi Kleen who suggested using a timer quite awhile back,
but I dismissed it thinking the timer calibration would be done after
the clocksource was registered (which would break things). Forgive
me for my short-sightedness.
This patch has worked very well in my testing, but TSC hardware is
quite varied so it would probably be good to get some extended
testing, possibly pushing inclusion out to 2.6.39.
Signed-off-by: John Stultz <johnstul@us.ibm.com>
LKML-Reference: <1289003985-29060-1-git-send-email-johnstul@us.ibm.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Ingo Molnar <mingo@elte.hu>
CC: Martin Schwidefsky <schwidefsky@de.ibm.com>
CC: Clark Williams <williams@redhat.com>
CC: Andi Kleen <andi@firstfloor.org>
On stock 2.6.37-rc4, running:
# mount lilith:/export /mnt/lilith
# find /mnt/lilith/ -type f -print0 | xargs -0 file
crashes the machine fairly quickly under Xen. Often it results in oops
messages, but the couple of times I tried just now, it just hung quietly
and made Xen print some rude messages:
(XEN) mm.c:2389:d80 Bad type (saw 7400000000000001 != exp
3000000000000000) for mfn 1d7058 (pfn 18fa7)
(XEN) mm.c:964:d80 Attempt to create linear p.t. with write perms
(XEN) mm.c:2389:d80 Bad type (saw 7400000000000010 != exp
1000000000000000) for mfn 1d2e04 (pfn 1d1fb)
(XEN) mm.c:2965:d80 Error while pinning mfn 1d2e04
Which means the domain tried to map a pagetable page RW, which would
allow it to map arbitrary memory, so Xen stopped it. This is because
vm_unmap_ram() left some pages mapped in the vmalloc area after NFS had
finished with them, and those pages got recycled as pagetable pages
while still having these RW aliases.
Removing those mappings immediately removes the Xen-visible aliases, and
so it has no problem with those pages being reused as pagetable pages.
Deferring the TLB flush doesn't upset Xen because it can flush the TLB
itself as needed to maintain its invariants.
When unmapping a region in the vmalloc space, clear the ptes
immediately. There's no point in deferring this because there's no
amortization benefit.
The TLBs are left dirty, and they are flushed lazily to amortize the
cost of the IPIs.
This specific motivation for this patch is an oops-causing regression
since 2.6.36 when using NFS under Xen, triggered by the NFS client's use
of vm_map_ram() introduced in 56e4ebf877 ("NFS: readdir with vmapped
pages") . XFS also uses vm_map_ram() and could cause similar problems.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Bryan Schumaker <bjschuma@netapp.com>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Alex Elder <aelder@sgi.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When remapping MSIs into pirqs for PV on HVM guests, qemu is responsible
for doing the actual mapping and unmapping.
We only give qemu the desired pirq number when we ask to do the mapping
the first time, after that we should be reading back the pirq number
from qemu every time we want to re-enable the MSI.
This fixes a bug in xen_hvm_setup_msi_irqs that manifests itself when
trying to enable the same MSI for the second time: the old MSI to pirq
mapping is still valid at this point but xen_hvm_setup_msi_irqs would
try to assign a new pirq anyway.
A simple way to reproduce this bug is to assign an MSI capable network
card to a PV on HVM guest, if the user brings down the corresponding
ethernet interface and up again, Linux would fail to enable MSIs on the
device.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Fix the mailbox detection for OMAP3630 and 2430, also minor
cleanup on conditional ifdef's that could affect it.
Given that 2430 has an iva too, include it, as the same steps
for omap3 apply.
Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
Acked-by: Hiroshi Doyu <hiroshi.doyu@nokia.com>
In the current mailbox driver, the mailbox internal pointer for
callback can be directly manipulated by the Users, so a second
User can easily corrupt the first user's callback pointer.
The initial effort to correct this issue can be referred here:
https://patchwork.kernel.org/patch/107520/
Along with fixing the above stated issue, this patch adds the
flexibility option to register notifications from
multiple readers to the events received on a mailbox instance.
The discussion regarding this can be referred here.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30671.html
Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
Signed-off-by: Fernando Guzman Lugo <x0095840@ti.com>
Acked-by: Hiroshi Doyu <hiroshi.doyu@nokia.com>
Schedule the Tasklet to send only when mailbox fifo is full and there are
pending messages in kfifo, else send the message directly in the Process
context. This would avoid needless scheduling of Tasklet for every message
transfer
Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
Acked-by: Hiroshi Doyu <hiroshi.doyu@nokia.com>
Fix the following checkpatch warnings observed in mailbox module.
WARNING: please, no space for starting a line,
excluding comments
+ fail_alloc_rxq:$
WARNING: please, no space for starting a line,
excluding comments
+ fail_alloc_txq:$
WARNING: please, no space for starting a line,
excluding comments
+ fail_request_irq:$
WARNING: line over 80 characters
+ mbox_kfifo_size = max_t(unsigned int, mbox_kfifo_size, sizeof(mbox_msg_t));
Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
Acked-by: Hiroshi Doyu <hiroshi.doyu@nokia.com>
The variable rq_full flag is a global variable, so if there are multiple
mailbox users there will be conflicts. Now there is a full flag per
mailbox queue.
Reported-by: Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: Fernando Guzman Lugo <x0095840@ti.com>
Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
Acked-by: Hiroshi Doyu <hiroshi.doyu@nokia.com>
The PXA-SPI driver relies on some files / defines which are arm specific
and are within the ARM tree. The CE4100 SoC which is x86 has also the
SPI core.
This patch moves the ssp and spi files from arm/mach-pxa and plat-pxa to
include/linux where the CE4100 can access them.
This move got verified by building the following defconfigs:
cm_x2xx_defconfig corgi_defconfig em_x270_defconfig ezx_defconfig
imote2_defconfig pxa3xx_defconfig spitz_defconfig zeus_defconfig
raumfeld_defconfig magician_defconfig
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
If a section is not marked with SHF_ALLOC, it will be discarded
by the module code. Therefore, it is not correct to register
the unwind tables.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
There's no need to keep pointers to the ELF sections available while
the module is loaded - we only need the section pointers while we're
finding and registering the unwind tables, which can all be done during
the finalize stage of loading.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This fixes the same problem as described in the patch "nohz: fix
printk_needs_cpu() return value on offline cpus" for the arch_needs_cpu()
primitive:
arch_needs_cpu() may return 1 if called on offline cpus. When a cpu gets
offlined it schedules the idle process which, before killing its own cpu,
will call tick_nohz_stop_sched_tick().
That function in turn will call arch_needs_cpu() in order to check if the
local tick can be disabled. On offline cpus this function should naturally
return 0 since regardless if the tick gets disabled or not the cpu will be
dead short after. That is besides the fact that __cpu_disable() should already
have made sure that no interrupts on the offlined cpu will be delivered anyway.
In this case it prevents tick_nohz_stop_sched_tick() to call
select_nohz_load_balancer(). No idea if that really is a problem. However what
made me debug this is that on 2.6.32 the function get_nohz_load_balancer() is
used within __mod_timer() to select a cpu on which a timer gets enqueued.
If arch_needs_cpu() returns 1 then the nohz_load_balancer cpu doesn't get
updated when a cpu gets offlined. It may contain the cpu number of an offline
cpu. In turn timers get enqueued on an offline cpu and not very surprisingly
they never expire and cause system hangs.
This has been observed 2.6.32 kernels. On current kernels __mod_timer() uses
get_nohz_timer_target() which doesn't have that problem. However there might
be other problems because of the too early exit tick_nohz_stop_sched_tick()
in case a cpu goes offline.
This specific bug was indrocuded with 3c5d92a0 "nohz: Introduce
arch_needs_cpu".
In this case a cpu hotplug notifier is used to fix the issue in order to keep
the normal/fast path small. All we need to do is to clear the condition that
makes arch_needs_cpu() return 1 since it is just a performance improvement
which is supposed to keep the local tick running for a short period if a cpu
goes idle. Nothing special needs to be done except for clearing the condition.
Cc: stable@kernel.org
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Soon resource data will get automatically
populated from a set of autogenerated data
from TI's hardware database for the OMAP
platform.
Such database, might not have resources at
the expected order by the current drivers.
While we could hack in some exceptions to
that tool to generate resources in a specific
order, it seems less fragile to use the
resource name instead. That way, no matter
what order the resources are generated, the
driver still work.
Modified the OMAP, Blackfin and Davinci
architecture files to add the name of the IRQs
in the resource structures and musb driver to
use the platform_get_irq_byname() api to get
the device and dma irq numbers instead of using
the index.
Cc: Tony Lindgren <tony@atomide.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Hema HK <hemahk@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This switches over to selects for the subtypes to enable OHCI/EHCI
support explicitly rather than littering the usb Kconfig with subtype
dependencies.
Suggested-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
you can control it by
echo 0 > /sys/class/leds/led0/brightness
echo 1 > /sys/class/leds/led0/brightness
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This follows the ARM change c01778001a
("ARM: 6379/1: Assume new page cache pages have dirty D-cache") for the
same rationale:
There are places in Linux where writes to newly allocated page
cache pages happen without a subsequent call to flush_dcache_page()
(several PIO drivers including USB HCD). This patch changes the
meaning of PG_arch_1 to be PG_dcache_clean and always flush the
D-cache for a newly mapped page in update_mmu_cache().
This addresses issues seen with executing binaries from MMC, in
addition to some of the other HCDs that don't explicitly do cache
management for their pipe-in buffers.
Requested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
sparc64 systems have a restriction in that passing in buffer
addressses above 4GB to prom calls is not reliable.
We end up violating this when we do prom console writes, because we
use an on-stack buffer to translate '\n' into '\r\n'.
So instead, do this translation into an intermediate buffer, which is
in the kernel image and thus below 4GB, then pass that to the PROM
console write calls.
On the 32-bit side we don't have to deal with any of these issues, so
the new prom_console_write_buf() uses the existing prom_nbputchar()
implementation. However we can now mark those routines static.
Since the 64-bit side completely uses new code we can delete the
putchar bits as they are now completely unused.
Signed-off-by: David S. Miller <davem@davemloft.net>
