I don't really understand why gcc gives the error it does, but without
this patch, when building with CONFIG_HOTPLUG=n, I get errors like:
CC arch/x86_64/pci/../../i386/pci/fixup.o
arch/x86_64/pci/../../i386/pci/fixup.c: In function `pci_fixup_i450nx':
arch/x86_64/pci/../../i386/pci/fixup.c:13: error: pci_fixup_i450nx causes a section type conflict
The change is obviously correct: an array should be declared
__devinitdata rather that __devinit.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Acked-by: Martin J. Bligh <mbligh@mbligh.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Patch from Deepak Saxena
CONFIG_MACH_GTWX5715 hardcodes the machine type in head-xscale.S so we
can no longer boot on any other machine types. The proper fix would be
to remove the hardcoding, but that machine is an off-the-shelf system
and most users won't have access to the bootloader. :(
Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Dan Williams
* If request_irq fails then a call to release_mem_region will be made with an invalid pointer.
* Two formatting fixes
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Lennert Buytenhek
This patch adds a microcode loader for the ixp2000 architecture.
The ixp2000 is an xscale-based CPU with a number of additional small
CPUs ('microengines') on die that can be programmed to do various
things. Depending on the ixp2000 model, there are between 2 and 16
microengines.
This code provides an API that allows configuring the microengines,
loading code into them, and starting and stopping them and reading
out a number of status registers, and is used by the microengine
network driver that was recently announced to netdev.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Nicolas Pitre
This patch provides a preemption safe implementation of copy_to_user
and copy_from_user based on the copy template also used for memcpy.
It is enabled unconditionally when CONFIG_PREEMPT=y. Otherwise if the
configured architecture is not ARMv3 then it is enabled as well as it
gives better performances at least on StrongARM and XScale cores. If
ARMv3 is not too affected or if it doesn't matter too much then
uaccess.S could be removed altogether.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Nicolas Pitre
This patch provides a new implementation for optimized memory copy
functions on ARM. It is made of two levels: a template that consists of
the core copy code and separate files that define macros to be used with
the core code depending on the type of copy needed. This allows for best
performances while sharing the same core for implementing memcpy(),
copy_from_user() and copy_to_user() for instance.
Two reasons for this work:
1) the current copy_to_user/copy_from_user implementation assumes no
task switch will ever occur in the middle of each copied page making
it completely unsafe with CONFIG_PREEMPT=y.
2) current copy implementations are measurably suboptimal and optimizing
different implementations separately is a pain and more opportunities
for bugs.
The reason for (1) is the fact that copy inside user pages are performed
with the ldm instruction which has no mean for testing user protections
and could possibly race with process preemption bypassing the COW mechanism
for example. This is a longstanding issue that we said ought to be fixed
for about two years now. The solution is to substitute those ldm insns
with a series of ldrt or strt insns to enforce user memory protection.
At least on StrongARM and XScale cores the ldm is not faster than the
equivalent ldr/str insns with a warm i-cache so there is no measurable
performance degradation with that change. The fact that the copy code is
a template makes it pretty easy to reuse the same core code as for memcpy
and benefit from the same performance optimizations.
Now (2) is best demonstrated with actual throughput measurements.
First, here is a summary of memcopy tests performed on a StrongARM core:
PTR alignment buffer size kernel version this version
------------------------------------------------------------
aligned 32 59.73 107.43
unaligned 32 61.31 74.72
aligned 100 132.47 136.15
unaligned 100 103.84 123.76
aligned 4096 130.67 130.80
unaligned 4096 130.68 130.64
aligned 1048576 68.03 68.18
unaligned 1048576 68.03 68.18
The buffer size is in bytes and the measured speed in MB/s. The copy
was performed repeatedly with given buffer and throughput averaged over
3 seconds.
Here we can see that the current kernel version has a higher entry cost
that shows up with small buffers. As buffer size grows both implementation
converge to the same throughput.
Now here's the exact same test performed on an XScale core (PXA255):
PTR alignment buffer size kernel version this version
------------------------------------------------------------
aligned 32 46.99 77.58
unaligned 32 53.61 59.59
aligned 100 107.19 136.59
unaligned 100 83.61 97.58
aligned 4096 129.13 129.98
unaligned 4096 128.36 128.53
aligned 1048576 53.76 59.41
unaligned 1048576 33.67 56.96
Again we can see the entry setup cost being higher for the current kernel
before getting to the main copy loop. Then throughput results converge
as long as the buffer remains in the cache. Then the 1MB case shows more
differences probably due to better pld placement and/or less instruction
interlocks in this proposed implementation.
Disclaimer: The PXA system was running with slower clocks than the
StrongARM system so trying to infer any conclusion by comparing those
separate sets of results side by side would be completely inappropriate.
So... What this patch does is to replace both memcpy and memmove with
an implementation based on the provided copy code template. The memmove
code is kept separate since it is used only if the memory areas involved
do overlap in which case the code is a transposition of the template but
with the copy occurring in the opposite direction (trying to fit that
mode into the template turned it into a mess not worth it for memmove
alone). And obviously both memcpy and memmove were tested with all kinds
of pointer alignments and buffer sizes to exercise all code paths for
correctness.
The next patch will provide the now trivial replacement implementation
copy_to_user and copy_from_user.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Nicolas Pitre
Required for future enhancement patches.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from David Brownell
Lubbock updates:
* Provide an address for the SMC91x chip that doesn't generate
a boot-time warning (matching the EEPROM).
* Update MMC support to (a) detect card insert/remove, and
(b) report the readonly switch setting for SD cards.
Previously, MMC/SD cards had to be present at boot time else they
couldn't be detected.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Ben Dooks
Add definition for S3C2410_IISMOD_FS_MASK
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Ben Dooks
Update the Documentation/arm/Samsung-S3C24XX to add
example platform data initialisation, and add the
linux-arm mailing list URL.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Ben Dooks
Platform data for the LCD/framebuffer driver for
the RX3715 LCD panel.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Lennert Buytenhek
Switch the users of ixp2000_reg_write that depend on writes being
flushed out of the write buffer by the time that function returns
over to ixp2000_reg_wrb.
When using XCB=101, writes to the same functional unit are still
guaranteed to complete in order, so we only need to protect against:
- reordering of writes to different functional units
- masking an interrupt and then reenabling the IRQ bit in CPSR
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Lennert Buytenhek
On the ixdp2x00, the slave CPU is currently not allowed to reset itself
for fear that it will do something 'funky' on the PCI bus. This fear is
ungrounded -- the slave CPU is wired up such that a CPU reset will not
cause a PCI bus reset to be done. This patch changes arch_reset() so
that the slave CPU also executes the reset sequence, allowing it to
reboot itself using /sbin/reboot.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Lennert Buytenhek
The enp2611 version of the ixp2000 netdev driver needs to be able to
access a number of on-board peripherals. ioremap() is not suitable
for this, as that will cause XCB=000 mappings to be done, which will
make the cpu susceptible to crashing on ixp2400 erratum #66. Properly
aligned iotable mappings with MT_IXP2000_DEVICE will cause section
mappings with XCB=101 to be done, which is safe.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Initialise the .owner field of the device driver
with the module that owns it, for easier tracking
of device driver ownership. (probably also better
for sysfs...)
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
The most trivial typo fix in the world.
Signed-off-by: Pozsar Balazs <pozsy@uhulinux.hu>
Signed-off-by: Pdraig Brady <P@draigBrady.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Initialise the .owner field of the device driver
with the module that owns it, for easier tracking
of device driver ownership.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
The USB "handoff" code is an early PCI quirk to make sure we own the USB
controller (as opposed to the BIOS/SMM). But if the controller isn't
even enabled yet, don't try to access it.
Acked-by: Paul Mackerras <paulus@samba.org> (who had an alternate patch)
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Commit f2b36db692 causes a bootup hang on
at least one machine. Revert for now until we understand why. The old
code may be ugly, but it works.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This adds the magic IO wakeup code for the CardBus version of the
Creative Labs Audigy 2 to the snd-emu10k1 driver.
Without the magic IO enable sequence, reading from the IO region of the
card will fail spectacularly, and the machine will hang.
My next task will be getting the driver to actually play sound without
distortion.
Signed-off-by: James Courtier-Dutton <James@superbug.co.uk>
[ This is a work-in-progress, but since it avoids a total lockup
if the emu10k module is loaded on a machine with the cardbus
card inserted, we're better off with it than without it, even
if sound quality is bad right now ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When the inode count is zero in inode writeback, the
WARN_ON(!(inode->i_state & I_WILL_FREE));
is broken, and needs to test for either I_WILL_FREE|I_FREEING.
When the inode is in I_FREEING state, it's already out of the visibility
of the vm so it can't be freed so it doesn't require the __iget and the
generic_delete_inode path can call the sync internally to the lowlevel
fs callback during the last iput. So the inode being in I_FREEING is
also a valid condition for calling the sync with i_count == 0.
The specific stack trace is this:
0xc00000007b8fb6e0 0xc00000000010118c .__writeback_single_inode +0x5c
0xc00000007b8fb6e0 0xc0000000001014dc (lr) .sync_inode +0x3c
0xc00000007b8fb790 0xc0000000001014dc .sync_inode +0x3c
0xc00000007b8fb820 0xc0000000001a5020 .ext2_sync_inode +0x64
0xc00000007b8fb8f0 0xc0000000001a65b4 .ext2_truncate +0x3f8
0xc00000007b8fba40 0xc0000000001a6940 .ext2_delete_inode +0xdc
0xc00000007b8fbac0 0xc0000000000f7a5c .generic_delete_inode +0x124
0xc00000007b8fbb50 0xc0000000000f5fe0 .iput +0xb8
0xc00000007b8fbbe0 0xc0000000000e9fd4 .sys_unlink +0x2a8
0xc00000007b8fbd10 0xc00000000001048c .ret_from_syscall_1 +0x0
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Jeff Garzik <jgarzik@pobox.com> points out that this was wrong: we need to
disable local interrupts while holding KM_IRQ0 due to IRQ sharing.
And holding interrupts off during a big PIO opration is expensive, so we only
want to do that if we know the page was highmem.
So revert commit 17fd47ab4d
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
CONFIG_PC is left-over cruft after the introduction of CONFIG_X86_PC with
the subarch split. Remove it, and fixup the remaining users to depend on
CONFIG_X86_PC instead.
Signed-off-by: Arthur Othieno <a.othieno@bluewin.ch>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Tejun Heo notes:
"I'm currently debugging this. The problem is that we are using the
generic dispatch queue directly in the noop sched and merging is NOT
allowed on dispatch queues but generic handling of last_merge tries
to merge requests. I'm still trying to verify this, so I'll be back
with results soon."
In the meantime, disable merging for noop by setting REQ_NOMERGE in
elevator_noop_add_request().
Eventually, we should add a noop_list and do the dispatching like in the
other io schedulers. Merging is still beneficial for noop (and it has
always done it).
Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Don't clear ->elevator_data on exit, if we are switching queues we are
overwriting the data of the new io scheduler.
Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Folk seem to get confused when they see two or more ttyS0 ports
appearing at boot time. One comes from the legacy table, and
one from PNP.
Hence, display the bus ID of the device which supplied the port.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The problem is that adbhid[]->input is NULL, so the kernel oopses with
a null pointer dereference as soon as a key is pressed.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
