03 Nov, 2005
6 commits
-
This fixes the x86-64 find_[first|next]_zero_bit() function for the
end-of-range case. It didn't test for a zero size, and the "rep scas"
would do entirely the wrong thing.Signed-off-by: Alexandre Oliva
Signed-off-by: Linus Torvalds -
This patch adds the infrastructure to support hotplug CPU on ARM
platforms.Signed-off-by: Russell King
-
Use *cpus_addr() to display the mask of pending/to be called CPUs.
Signed-off-by: Russell King
-
Track the idle thread task_struct for each CPU.
Signed-off-by: Russell King
02 Nov, 2005
17 commits
-
3016/1 changed the map_desc structure to take a PFN instead of a
physical address. Fixup Realview machine support for this change.Signed-off-by: Russell King
-
It seems that without the extra tlb flush, we may end up faulting
during the early kernel initialisation because the TLB can't see
the updated page tables.Signed-off-by: Russell King
-
Signed-off-by: Al Viro
Signed-off-by: Linus Torvalds -
This section of code calls .audit_syscal_exit, but is inside CONFIG_AUDIT,
so it will fail to build if CONFIG_AUDITSYSCALL is not defined.After discussion with David Woodhouse, change the ifdef to
CONFIG_AUDITSYSCALLSigned-off-by: Horms
Acked-by: David Woodhouse
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Updated m68knommu defconfig. Part of changing the "Motorola" names
to their new name "Freescale".Signed-off-by: Greg Ungerer
Signed-off-by: Linus Torvalds -
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 conflictThe change is obviously correct: an array should be declared
__devinitdata rather that __devinit.Signed-off-by: Roland Dreier
Acked-by: Martin J. Bligh
Signed-off-by: Linus Torvalds -
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
Signed-off-by: Russell King -
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
Signed-off-by: Deepak Saxena
Signed-off-by: Russell King -
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
Signed-off-by: Russell King -
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.18The 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.96Again 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
Signed-off-by: Russell King -
Patch from Nicolas Pitre
Required for future enhancement patches.
Signed-off-by: Nicolas Pitre
Signed-off-by: Russell King -
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
Signed-off-by: Russell King -
Patch from Ben Dooks
Platform data for the LCD/framebuffer driver for
the RX3715 LCD panel.Signed-off-by: Ben Dooks
Signed-off-by: Russell King -
Patch from Lennert Buytenhek
Misc ixp2000 typo and whitespace fixes.
Signed-off-by: Lennert Buytenhek
Signed-off-by: Deepak Saxena
Signed-off-by: Russell King -
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 CPSRSigned-off-by: Lennert Buytenhek
Signed-off-by: Deepak Saxena
Signed-off-by: Russell King -
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
Signed-off-by: Deepak Saxena
Signed-off-by: Russell King
01 Nov, 2005
5 commits
-
Commit f2b36db692b7ff6972320ad9839ae656a3b0ee3e 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
-
Applied Al's change 06a544971fad0992fe8b92c5647538d573089dd4
to new location of swiotlb.cSigned-off-by: Tony Luck
-
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
Signed-off-by: Linus Torvalds -
Signed-off-by: Russell King
-
Signed-off-by: Russell King
31 Oct, 2005
12 commits
-
Manual #include fixups for clashes - there may be some unnecessary
-
Support for RealView EB.
Signed-off-by: Catalin Marinas
Signed-off-by: Russell King -
... namely, the change to the 2-argument pte_alloc_kernel.
Signed-off-by: Paul Mackerras
-
Signed-off-by: Paul Mackerras
-
Signed-off-by: Paul Mackerras
-
We had a static memory_limit in prom.c, and then another one defined
in setup_64.c and used in numa.c, which resulted in the kernel crashing
when mem=xxx was given on the command line. This puts the declaration
in system.h and the definition in mem.c. This also moves the
definition of tce_alloc_start/end out of setup_64.c.Signed-off-by: Paul Mackerras
-
I recently picked up my older work to remove unnecessary #includes of
sched.h, starting from a patch by Dave Jones to not include sched.h
from module.h. This reduces the number of indirect includes of sched.h
by ~300. Another ~400 pointless direct includes can be removed after
this disentangling (patch to follow later).
However, quite a few indirect includes need to be fixed up for this.In order to feed the patches through -mm with as little disturbance as
possible, I've split out the fixes I accumulated up to now (complete for
i386 and x86_64, more archs to follow later) and post them before the real
patch. This way this large part of the patch is kept simple with only
adding #includes, and all hunks are independent of each other. So if any
hunk rejects or gets in the way of other patches, just drop it. My scripts
will pick it up again in the next round.Signed-off-by: Tim Schmielau
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Reads from an HPET register require a round trip to the south bridge and are
almost as slow as PCI reads. By caching the last value we've written to the
comparator register, we can eliminate all HPET reads from the fast path in the
emulated RTC interrupt handler.Signed-off-by: Clemens Ladisch
Acked-by: Venkatesh Pallipadi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Make sure that the RTC timer is in non-periodic mode; some stupid BIOS might
have initialized it to periodic mode.Furthermore, don't set the SETVAL bit in the config register. This wouldn't
have any effect unless the timer was in period mode (which it isn't), and then
the actual timer frequency would be half that of the desired one because
incrementing the comparator in the interrupt handler would be done after the
hardware has already incremented it itself.Signed-off-by: Clemens Ladisch
Acked-by: Venkatesh Pallipadi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
When the emulated RTC interrupt is no longer needed, we better disable it;
otherwise, we get a spurious interrupt whenever the timer has rolled over and
reaches the same comparator value.Having a superfluous interrupt every five minutes doesn't hurt much, but it's
bad style anyway. ;-)Signed-off-by: Clemens Ladisch
Acked-by: "Pallipadi, Venkatesh"
Cc: Andi Kleen
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
