Evgeniy Polyakov [Fri, 20 May 2005 18:33:25 +0000 (22:33 +0400)]
[PATCH] w1: cleanups.
- white space changes.
- list_for_each_entry/list_for_each_entry_safe and reverse changes.
- small coding style changes.
- removed redundant NULL checks.
- use attribute group and macros instead of direct device attributes.
Patch is havily based on work from Adrian Bunk and Dmitry Torokhov,
thanks guys.
[PATCH] w1_smem: support for new simple rom family [0x81 id].
Support for new simple rom family [0x81 id].
It is the same as existing 0x01 family,
which is used in ds9490* w1 adapters.
Patch is on top of new-thermal-sensor-families patch.
[PATCH] w1_therm: support for ds18b20, ds1822 thermal sensors.
Support for ds18b20, ds1822 thermal sensors.
Based on code from Tiziano M_ller <tm@dev-zero.ch>.
Patch is against 2.6.12-rc2 and should be applied
without problems on top of any later kernels since
w1_therm driver was not changed.
Jesper Juhl [Wed, 22 Jun 2005 00:17:30 +0000 (17:17 -0700)]
[PATCH] md: remove unneeded NULL checks before kfree
This patch removes some unneeded checks of pointers being NULL before
calling kfree() on them. kfree() handles NULL pointers just fine, checking
first is pointless.
NeilBrown [Wed, 22 Jun 2005 00:17:28 +0000 (17:17 -0700)]
[PATCH] md: allow md to update multiple superblocks in parallel.
currently, md updates all superblocks (one on each device) in series. It
waits for one write to complete before starting the next. This isn't a big
problem as superblock updates don't happen that often.
However it is neater to do it in parallel, and if the drives in the array have
gone to "sleep" after a period of idleness, then waking them is parallel is
faster (and someone else should be worrying about power drain).
Futher, we will need parallel superblock updates for a future patch which
keeps the intent-logging bitmap near the superblock.
Also remove the silly code that retired superblock updates 100 times. This
simply never made sense.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NeilBrown [Wed, 22 Jun 2005 00:17:27 +0000 (17:17 -0700)]
[PATCH] md: allow md intent bitmap to be stored near the superblock.
This provides an alternate to storing the bitmap in a separate file. The
bitmap can be stored at a given offset from the superblock. Obviously the
creator of the array must make sure this doesn't intersect with data....
After is good for version-0.90 superblocks.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NeilBrown [Wed, 22 Jun 2005 00:17:25 +0000 (17:17 -0700)]
[PATCH] md: optimise reconstruction when re-adding a recently failed drive.
When an array is degraded, bit in the intent-bitmap are never cleared. So if
a recently failed drive is re-added, we only need to reconstruct the block
that are still reflected in the bitmap.
This patch adds support for this re-adding.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NeilBrown [Wed, 22 Jun 2005 00:17:24 +0000 (17:17 -0700)]
[PATCH] md: initialise sync_blocks in raid1 resync
Otherwise it could have a random value and might BUG. This fixes a BUG
during resync problem in raid1 introduced by the bitmap-based-intent-loggin
patches.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NeilBrown [Wed, 22 Jun 2005 00:17:22 +0000 (17:17 -0700)]
[PATCH] md: don't skip bitmap pages due to lack of bit that we just cleared.
When looking for pages that need cleaning we skip pages that don't have
BITMAP_PAGE_CLEAN set. But if it is the 'current' page we will have cleared
that bit ourselves, so skipping it is wrong. So: move the 'skip this page'
inside 'if page != lastpage'.
Also fold call of file_page_offset into the one place where the value (bit) is
used.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NeilBrown [Wed, 22 Jun 2005 00:17:18 +0000 (17:17 -0700)]
[PATCH] md: make sure md bitmap is cleared on a clean start.
As the array-wide clean bit (in the superblock) is set more agressively than
the bits in the bitmap are cleared, it is possible to have an array which is
clean despite there being bits set in the bitmap.
These bits will currently never get cleared, as they can only be cleared by a
resync pass, which never happens.
No, when reading bits from disk, be aware of whether the whole array is known
to be in sync, and act accordingly.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NeilBrown [Wed, 22 Jun 2005 00:17:16 +0000 (17:17 -0700)]
[PATCH] md: call bitmap_daemon_work regularly
bitmap_daemon_work clears bits in the bitmap for blocks that haven't been
written to for a while. It needs to be called regularly to make sure the
bitmap doesn't endup full of ones .... but it wasn't.
So call it from the increasingly-inaptly-named md_check_recovery
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NeilBrown [Wed, 22 Jun 2005 00:17:14 +0000 (17:17 -0700)]
[PATCH] md: optimised resync using Bitmap based intent logging
With this patch, the intent to write to some block in the array can be logged
to a bitmap file. Each bit represents some number of sectors and is set
before any update happens, and only cleared when all writes relating to all
sectors are complete.
After an unclean shutdown, information in this bitmap can be used to optimise
resync - only sectors which could be out-of-sync need to be updated.
Also if a drive is removed and then added back into an array, the recovery can
make use of the bitmap to optimise reconstruction. This is not implemented in
this patch.
Currently the bitmap is stored in a file which must (obviously) be stored on a
separate device.
The patch only provided infrastructure. It does not update any personalities
to bitmap intent logging.
Md arrays can still be used with no bitmap file. This patch has minimal
impact on such arrays.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NeilBrown [Wed, 22 Jun 2005 00:17:13 +0000 (17:17 -0700)]
[PATCH] md: improve the interface to sync_request
1/ change the return value (which is number-of-sectors synced)
from 'int' to 'sector_t'.
The number of sectors is usually easily small enough to fit
in an int, but if resync needs to abort, it may want to return
the total number of remaining sectors, which could be large.
Also errors cannot be returned as negative numbers now, so use
0 instead
2/ Add a 'skipped' return parameter to allow the array to report
that it skipped the sectors. This allows md to take this into account
in the speed calculations.
Currently there is no important skipping, but the bitmap-based-resync
that is coming will use this.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NeilBrown [Wed, 22 Jun 2005 00:17:12 +0000 (17:17 -0700)]
[PATCH] md: improve locking on 'safemode' and move superblock writes
When md marks the superblock dirty before a write, it calls
generic_make_request (to write the superblock) from within
generic_make_request (to write the first dirty block), which could cause
problems later.
With this patch, the superblock write is always done by the helper thread, and
write request are delayed until that write completes.
Also, the locking around marking the array dirty and writing the superblock is
improved to avoid possible races.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NeilBrown [Wed, 22 Jun 2005 00:17:11 +0000 (17:17 -0700)]
[PATCH] md: merge md_enter_safemode into md_check_recovery
md_enter_safemode checks if it is time to mark the md superblock as 'clean'.
i.e. if all writes have completed and a suitable delay has passed.
This is currently called from md_handle_safemode which in-turn is called
(almost) every time md_check_recovery is called, and from the end of
md_do_sync which causes the mddev->thread to run, which will always call
md_check_recovery as well.
So it doesn't need to be a separate function and fits quite well into
md_check_recovery.
The "almost" is because multipathd calls md_check_recovery but not
md_handle_safemode. This is OK because the code from md_enter_safemode is a
no-op if mddev->safemode == 0, which it always is for a multipathd (providing
we don't allow it to be set to 2 on a signal...)
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NeilBrown [Wed, 22 Jun 2005 00:17:09 +0000 (17:17 -0700)]
[PATCH] md: cause md/raid1 to "repack" working devices when number of drives is changed
i.e. missing or failed drives are moved to the end of the list. The means
a 3 drive md array with the first drive missing can be shrunk to a two
drive array. Currently that isn't possible.
Also, the "last_used" device number might be out-of-range after the number
of devices is reduced, so we set it to 0.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Jurriaan [Wed, 22 Jun 2005 00:17:06 +0000 (17:17 -0700)]
[PATCH] New framebuffer fonts + updated 12x22 font available
Improve the fonts for use with the framebuffer.
I've added all the characters marked 'FIXME' in the sun12x22 font and
created a 10x18 font (based on the sun12x22 font) and a 7x14 font (based
on the vga8x16 font).
This patch is non-intrusive, no options are enabled by default so most
users won't notice a thing.
I am placing my changes under the GPL, however, I've not seen any copyright
notices on the sun12x22 font and the vga8x16 font which I derived my new
fonts from so I don't know what the copyright status is.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Jaya Kumar [Wed, 22 Jun 2005 00:17:04 +0000 (17:17 -0700)]
[PATCH] Framebuffer driver for Arc LCD board
Add support for the Arc monochrome LCD board.
The board uses KS108 controllers to drive individual 64x64 LCD matrices.
The board can be paneled in a variety of setups such as 2x1=128x64,
4x4=256x256 and so on. The board/host interface is through GPIO.
Signed-off-by: Jaya Kumar <jayalk@intworks.biz> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: <linux-fbdev-devel@lists.sourceforge.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Sylvain Meyer [Wed, 22 Jun 2005 00:17:02 +0000 (17:17 -0700)]
[PATCH] intelfb: fix accel detection when changing video modes
Changed the tests in intelfb_set_par to check also the parameter
var.accel_flags. If null, do nothing about ring buffers.
Now, the DirectFB i830 driver could nicely work even if intelfb is hw
accelerated. Just change the /etc/fb.modes file to disable console hw
acceleration when starting a DirectFB app.
James Simmons [Wed, 22 Jun 2005 00:17:00 +0000 (17:17 -0700)]
[PATCH] VGA to fbcon fix.
Currently when going from vgacon to fbcon the VT screenbuffer are often
different sizes. In the case when they are different sizes a new VT
screenbuffer is allocated and the contents are copied into the new buffer.
Currently the amount copied from VGA text memory to the new screenbuf is
the size of the framebuffer console. If the framebuffer console new VT
screen buffer is greater than the VGA text memory size then we get some of
the VGA BIOS contents as well.
This patch will only allow you to copy up to the size of VGA text memory
now. The rest is filled with erase characters.
Initial patch by Jordan Crouse <jordan.crouse@amd.com>
Signed-off-by: James Simmons <jsimmons@www.infradead.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
James Simmons [Wed, 22 Jun 2005 00:16:58 +0000 (17:16 -0700)]
[PATCH] fbdev: iomove removal
Since no one is using the inbuf, outbuf of struct fb_pixmap I removed their
use in the framebuffer console. The idea is instead move the pixmap
functionality below the accelerated functions intead of on top as the way
it is now. If there is no objection please apply. This is against Linus
latestr GIT tree. Thank you.
Signed-off-by: James Simmons <jsimmons@www.infradead.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Gerd Knorr [Wed, 22 Jun 2005 00:16:56 +0000 (17:16 -0700)]
[PATCH] some vesafb fixes
Fix the size passed to release_mem_region in an error path.
Also adjust the message printed when vesafb cannot load; the comment there
already says this must not be fatal, so the message should also not mention
the word 'abort' otherwise indicating a problem to worry about in the log.
Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Gerd Knorr <kraxel@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Andrew Morton [Wed, 22 Jun 2005 00:16:55 +0000 (17:16 -0700)]
[PATCH] s1d13xxxfb linkage fix
s1d13xxxfb_remove() is referenced from s1d13xxxfb_probe(), which is marked
__devinit(). So s1d13xxxfb_remove() cannot be marked __devexit.
Does this all make sense? Clearly the __devexit section will still be in
core when the __devinit code is run, if the driver was loaded as a module.
But I suppose that if the driver is statically linked, the __devexit section
might be dropped early in boot. Still, we wouldn't drop __devexit prior to
initcall completion, at which point the __devinit code has all been run
anyway.
verdict: this code was legal and made sense. Is this a generic problem, or an
arm-specific problem?
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
`.exit.text' referenced in section `.init.text' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
Cc: Russell King <rmk@arm.linux.org.uk> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Jeremy White [Wed, 22 Jun 2005 00:16:53 +0000 (17:16 -0700)]
[PATCH] isofs: show hidden files, add granularity for assoc/hidden files flags
The current isofs treatment of hidden files is flawed in two ways. First,
it does not provide sufficient granularity; it hides both 'hidden' files
and 'associated' files (resource fork for Mac files). Second, the default
behavior to completely strip hidden files, while an admirable
implementation of the spec, is a poor choice given the real world use of
hidden files as a poor mans copy protection scheme for MSDOS and Windows
based systems. A longer description of this is available here:
This patch was originally built after a few private conversations with Alan
Cox; I shamefully failed to persist in seeing it go forward, I hope to make
amends now.
This patch introduces granularity by allowing explicit control for both
hidden and associated files. It also reverses the default so that by
default, hidden files are treated as regular files on the iso9660 file
system.
This allow Wine to process Windows CDs, including those that are hybrid
Mac/Windows CDs properly and completely, without our having to go muck up
peoples fstabs as we do now. (I have tested this with such a hybrid +
hidden CD and have verified that this patch works as claimed).
Signed-off-by: Jeremy White <jwhite@codeweavers.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Andrew Morton [Wed, 22 Jun 2005 00:16:50 +0000 (17:16 -0700)]
[PATCH] rock.c: handle corrupted directories
The bug in rock.c is that it's totally trusting of the contents of the
directories. If the directory says there's a continuation 10000 bytes into
this 4k block then we cheerily poke around in memory we don't own and oops.
So change rock_continue() to apply various sanity checks, at least ensuring
that the offset+length remain within the bounds for the header part of a
struct rock_ridge directory entry.
Note that the kernel can still overindex the buffer due to the variable size
of the rock-ridge directory entries. We cannot check that in rock_continue()
unless we go parse the directory entry's signature and work out its size.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Ian Kent [Wed, 22 Jun 2005 00:16:41 +0000 (17:16 -0700)]
[PATCH] autofs4: bad lookup fix
For browsable autofs maps, a mount request that arrives at the same time an
expire is happening can fail to perform the needed mount.
This happens becuase the directory exists and so the revalidate succeeds when
we need it to fail so that lookup is called on the same dentry to do the
mount. Instead lookup is called on the next path component which should be
whithin the mount, but the parent isn't mounted.
The solution is to allow the revalidate to continue and perform the mount as
no directory creation (at mount time) is needed for browsable mount entries.
Signed-off-by: Ian Kent <raven@themaw.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Ian Kent [Wed, 22 Jun 2005 00:16:39 +0000 (17:16 -0700)]
[PATCH] autofs4: post expire race fix
At the tail end of an expire it's possible for a process to enter
autofs4_wait, with a waitq type of NFY_NONE but find that the expire is
finished. In this cause autofs4_wait will try to create a new wait but not
notify the daemon leading to a hang. As the wait type is meant to delay mount
requests from revalidate or lookup during an expire and the expire is done all
we need to do is check if the dentry is a mountpoint. If it's not then we're
done.
Signed-off-by: Ian Kent <raven@themaw.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Max Asbock [Wed, 22 Jun 2005 00:16:34 +0000 (17:16 -0700)]
[PATCH] ibmasm driver: redesign handling of remote control events
This patch rewrites the handling of remote control events. Rather than making
them available from a special file in the ibmasmfs, now the events from the
RSA card get translated into kernel input events and injected into the input
subsystem. The driver now will generate two /dev/input/eventX nodes -- one
for the keyboard and one for the mouse. The mouse node generates absolute
events more like a touch pad than a mouse.
Signed-off-by: Vernon Mauery <vernux@us.ibm.com> Signed-off-by: Max Asbock <masbock@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Max Asbock [Wed, 22 Jun 2005 00:16:33 +0000 (17:16 -0700)]
[PATCH] ibmasm driver: correctly wake up sleeping threads
Due to my incomplete understanding of the wait_event_interruptible() function
threads waiting for service processor events were not woken up. This patch
fixes that problem.
Signed-off-by: Max Asbock <masbock@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Heiko Carstens [Wed, 22 Jun 2005 00:16:30 +0000 (17:16 -0700)]
[PATCH] s390: memory detection > 32GB
The kernel takes a very long time to boot if the memory size is bigger then
32767 MB. The memory size is contained in a structure created by an sclp
call. The kernel accesses the field with a LH instrution which performs a
sign extension of a 16 bit word. In the case of a memory size with bit 2^15
set this results in a very large value and the memory detection just loops for
a long time. In addition if more then 64 GB are used on a 64 bit system the
memory size is read from an incorrect storage location.
Use zero-extention to read the 16 bit memory size and the correct offset to
read the 4 byte memory size on 64 bit.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
With Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
To make sure switcheroo() can execute when we remap all the executable
image, we used a trick to make it use a local copy of errno... this trick
does not work with NPTL glibc, only with LinuxThreads, so use another
(simpler) one to make it work anyway.
Hopefully, a lot improved thanks to merging with the version of Al Viro
(which had his part of problems, though, i.e. removing a fix to another
bug and not fixing the problem on i386).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] uml: make hw_controller_type->release exist only for archs needing it
With Chris Wedgwood <cw@f00f.org>
As suggested by Chris, we can make the "just added" method ->release
conditional to UML only (better: to archs requesting it, i.e. only UML
currently), so that other archs don't get this unneeded crud, and if UML
won't need it any more we can kill this.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> CC: Ingo Molnar <mingo@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] uml: add and use generic hw_controller_type->release
With Chris Wedgwood <cw@f00f.org>
Currently UML must explicitly call the UML-specific
free_irq_by_irq_and_dev() for each free_irq call it's done.
This is needed because ->shutdown and/or ->disable are only called when the
last "action" for that irq is removed.
Instead, for UML shared IRQs (UML IRQs are very often, if not always,
shared), for each dev_id some setup is done, which must be cleared on the
release of that fd. For instance, for each open console a new instance
(i.e. new dev_id) of the same IRQ is requested().
Exactly, a fd is stored in an array (pollfds), which is after read by a
host thread and passed to poll(). Each event registered by poll() triggers
an interrupt. So, for each free_irq() we must remove the corresponding
host fd from the table, which we do via this -release() method.
In this patch we add an appropriate hook for this, and remove all uses of
it by pointing the hook to the said procedure; this is safe to do since the
said procedure.
Also some cosmetic improvements are included.
This is heavily based on some work by Chris Wedgwood, which however didn't
get the patch merged for something I'd call a "misunderstanding" (the need
for this patch wasn't cleanly explained, thus adding the generic hook was
felt as undesirable).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> CC: Ingo Molnar <mingo@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Hirokazu Takata [Wed, 22 Jun 2005 00:16:17 +0000 (17:16 -0700)]
[PATCH] m32r: Use asm-generic/div64.h
The current include/asm-m32r/div64.h of 2.6.12-rc5 looks buggy. Here is a
patch for updating it to use asm-generic/div64.h for m32r like other
architectures.
This patch removes an obsolete header file include/asm-m32r/m32102peri.h.
In this header, there are some undesirable single character types, like V.
And the header is almost no longer used.
Hirokazu Takata [Wed, 22 Jun 2005 00:16:10 +0000 (17:16 -0700)]
[PATCH] m32r: Support M3A-2170(Mappi-III) platform
This patchset is for supporting a new m32r platform, M3A-2170(Mappi-III)
evaluation board. An M32R chip multiprocessor is equipped on the board.
http://http://www.linux-m32r.org/eng/platform/platform.html
* include/asm-m32r/ide.h: CF support for Mappi-III.
* arch/m32r/kernel/setup_mappi3.c: ditto.
* arch/m32r/mappi3/defconfig.smp: A default config file for Mappi-III.
* arch/m32r/mappi3/dot.gdbinit: A default .gdbinit file for Mappi-III.
* arch/m32r/boot/compressed/m32r_sio.c: Modified for Mappi-III
- At boot time, m32r-g00ff bootloader makes MMU off for Mappi-III,
on the contrary it makes MMU on for Mappi-II.
Brent Casavant [Wed, 22 Jun 2005 00:16:01 +0000 (17:16 -0700)]
[PATCH] ioc4: PCI bus speed detection
Several hardware features of SGI's IOC4 I/O controller chip require
timing-related driver calculations dependent upon the PCI bus speed. This
patch enables the core IOC4 driver code to detect the actual bus speed and
store a value that can later be used by the IOC4 subdrivers as needed.
Signed-off-by: Brent Casavant <bcasavan@sgi.com> Acked-by: Pat Gefre <pfg@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Brent Casavant [Wed, 22 Jun 2005 00:16:01 +0000 (17:16 -0700)]
[PATCH] ioc4: CONFIG split
The SGI IOC4 I/O controller chip drivers are currently all configured by
CONFIG_BLK_DEV_SGIIOC4. This is undesirable as not all IOC4 hardware features
are needed by all systems.
This patch adds two configuration variables, CONFIG_SGI_IOC4 for core IOC4
driver support (see patch 1/3 in this series for further explanation) and
CONFIG_SERIAL_SGI_IOC4 to independently enable serial port support.
Signed-off-by: Brent Casavant <bcasavan@sgi.com> Acked-by: Pat Gefre <pfg@sgi.com> Acked-by: Jeremy Higdon <jeremy@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Brent Casavant [Wed, 22 Jun 2005 00:15:59 +0000 (17:15 -0700)]
[PATCH] ioc4: Core driver rewrite
This series of patches reworks the configuration and internal structure
of the SGI IOC4 I/O controller device drivers.
These changes are motivated by several factors:
- The IOC4 chip PCI resources are of mixed use between functions (i.e.
multiple functions are handled in the same address range, sometimes
within the same register), muddling resource ownership and initialization
issues. Centralizing this ownership in a core driver is desirable.
- The IOC4 chip implements multiple functions (serial, IDE, others not
yet implemented in the mainline kernel) but is not a multifunction
PCI device. In order to properly handle device addition and removal
as well as module insertion and deletion, an intermediary IOC4-specific
driver layer is needed to handle these operations cleanly.
- All IOC4 drivers are currently enabled by a single CONFIG value. As
not all systems need all IOC4 functions, it is desireable to enable
these drivers independently.
- The current IOC4 core driver will trigger loading of all function-level
drivers, as it makes direct calls to them. This situation should be
reversed (i.e. function-level drivers cause loading of core driver)
in order to maintain a clear and least-surprise driver loading model.
- IOC4 hardware design necessitates some driver-level dependency on
the PCI bus clock speed. Current code assumes a 66MHz bus, but the
speed should be autodetected and appropriate compensation taken.
This patch series effects the above changes by a newly and better designed
IOC4 core driver with which the function-level drivers can register and
deregister themselves upon module insertion/removal. By tracking these
modules, device addition/removal is also handled properly. PCI resource
management and ownership issues are centralized in this core driver, and
IOC4-wide configuration actions such as bus speed detection are also
handled in this core driver.
This patch:
The SGI IOC4 I/O controller chip implements multiple functions, though it is
not a multi-function PCI device. Additionally, various PCI resources of the
IOC4 are shared by multiple hardware functions, and thus resource ownership by
driver is not clearly delineated. Due to the current driver design, all core
and subordinate drivers must be loaded, or none, which is undesirable if not
all IOC4 hardware features are being used.
This patch reorganizes the IOC4 drivers so that the core driver provides a
subdriver registration service. Through appropriate callbacks the subdrivers
can now handle device addition and removal, as well as module insertion and
deletion (though the IOC4 IDE driver requires further work before module
deletion will work). The core driver now takes care of allocating PCI
resources and data which must be shared between subdrivers, to clearly
delineate module ownership of these items.
Signed-off-by: Brent Casavant <bcasavan@sgi.com> Acked-by: Pat Gefre <pfg@sgi.com Acked-by: Jeremy Higdon <jeremy@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Anton Blanchard [Wed, 22 Jun 2005 00:15:55 +0000 (17:15 -0700)]
[PATCH] ppc64: Mark kernel hptes dirty
We dont use the hardware referenced and changed bits and setting them early
avoids a store to memory. We already do this for userspace hptes but not
kernel ones. Do it.
Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Stephen Rothwell [Wed, 22 Jun 2005 00:15:54 +0000 (17:15 -0700)]
[PATCH] ppc64: tidy up vio devices fake parent
Currently we dynamically allocate the fake parent device for all devices on
the vio bus. This patch statically allocates it. This also allows us to
reuse it for the iSeries "generic" vio device (that is used for passing to
dma routines when communicating with the hypervisor without a device
involved). Also unexport vio_bus_type as it is never used in modules.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Stephen Rothwell [Wed, 22 Jun 2005 00:15:51 +0000 (17:15 -0700)]
[PATCH] ppc64 iSeries: tidy up irq code after merge
This patch just removes some dead code, fixes messages that referred to the
file this code used to be in and inserts XmPciLpEvent_init into its caller.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Stephen Rothwell [Wed, 22 Jun 2005 00:15:50 +0000 (17:15 -0700)]
[PATCH] ppc64 iSeries: remove XmPciLpEvent.c
This patch just merges XmPciLpEvent.c into iSeries_irq.c (the only caller of
its only external function). XmPciLpEvent.c just contained the lowlevel
iSeries irq code.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>