Inclusion of UML in 2.6.8

Inclusion of UML in 2.6.8

[BlaisorBlade]

Andrew, what are the requisite for stable inclusion of the UML update inside 
2.6-mm (or directly 2.6.8)? Currently (splitting out a little piece, which 
should not be included) we have almost all the stuff inside arch/um and 
include/asm-um, the addition of <linux/ghash.h> and of two filesystems for 
UML use only, and this little hunk (plus 2 uses of it inside 
mm/page_alloc.c).

+#ifndef HAVE_ARCH_FREE_PAGE
+static inline void arch_free_page(struct page *page, int order) { }
+#endif

Could it go in as-is? I'm especially worried about having it included soon in 
2.6.8, since last time it entered -mm and stayed there just for one release.

The patch correctly applies to 2.6.7 and works; the current code, instead, 
does not even compile at all, so there is no reason for not applying it 
(unless you want to remove UML support / but since you never said this, we 
need this patch applied). However, if you don't want some parts of the code, 
just tell me; I'm waiting for this before preparing the UML patch to send you

Also, I have some patches managed with your patch-scripts, which I'll send you 
after you include the UML patch.

About the STATE of the code:

Of the two filesystems, one (hostfs) now should work perfectly with 2.6 (I've 
just fixed one porting bug to 2.6, related to the force_delete() -> 
.drop_inode change documented in Documentation/filesystems/vfs.txt); the 
other maybe has some problems, but I can remove it from the patch (it also 
will probably be replaced soon by a more generic one, i.e. externfs).

Bye!
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

Re: Inclusion of UML in 2.6.8

[Christoph Hellwig]

On Sat, Jun 26, 2004 at 07:05:22PM +0200, BlaisorBlade wrote:
> Andrew, what are the requisite for stable inclusion of the UML update inside 
> 2.6-mm (or directly 2.6.8)? Currently (splitting out a little piece, which 
> should not be included) we have almost all the stuff inside arch/um and 
> include/asm-um, the addition of <linux/ghash.h> and of two filesystems for 
> UML use only, and this little hunk (plus 2 uses of it inside 
> mm/page_alloc.c).
> 
> +#ifndef HAVE_ARCH_FREE_PAGE
> +static inline void arch_free_page(struct page *page, int order) { }
> +#endif
> 
> Could it go in as-is? I'm especially worried about having it included soon in 
> 2.6.8, since last time it entered -mm and stayed there just for one release.

Please send split patches.  E.g. linux/ghash.h should not ne reintroduced,
it's completely fuly.  Also your above arch_free_page needs some more
discussion.

Re: Inclusion of UML in 2.6.8

[Jeff Dike]

On Sat, Jun 26, 2004 at 07:10:48PM +0100, Christoph Hellwig wrote:
> Please send split patches.  E.g. linux/ghash.h should not ne reintroduced,
> it's completely fuly.  

That requires a little interface work inside UML, and that was the main reason
Andrew hasn't seen UML recently.

> Also your above arch_free_page needs some more
> discussion.

I think that can disappear.  In some cases, it might be handy for the arch
to see pages being freed, but right now, I believe that UML has no need for
it.

				Jeff

Re: Inclusion of UML in 2.6.8

[Rik van Riel]

On Sat, 26 Jun 2004, Jeff Dike wrote:
> On Sat, Jun 26, 2004 at 07:10:48PM +0100, Christoph Hellwig wrote:

> > Also your above arch_free_page needs some more discussion.
> 
> I think that can disappear.  In some cases, it might be handy for the
> arch to see pages being freed, but right now, I believe that UML has no
> need for it.

Should be useful for Linux/Xen, Linux/s390 and Linux/iSeries,
too...

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: Inclusion of UML in 2.6.8

[Arnd Bergmann]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

On Sonntag, 27. Juni 2004 15:57, Rik van Riel wrote:
> On Sat, 26 Jun 2004, Jeff Dike wrote:
> > On Sat, Jun 26, 2004 at 07:10:48PM +0100, Christoph Hellwig wrote:
> 
> > > Also your above arch_free_page needs some more discussion.
> > 
> > I think that can disappear.  In some cases, it might be handy for the
> > arch to see pages being freed, but right now, I believe that UML has no
> > need for it.
> 
> Should be useful for Linux/Xen, Linux/s390 and Linux/iSeries,
> too...

At least for Linux/s390, the underlying architecture interface (DIAG 0x10)
that would let us exploit this is too expensive, so we chose not to do it.
Future machine might give us more flexibility, but using those requires
more than just hooking into free_page.

	Arnd <><

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Uploaded Uml patchset for 2.6.7(was: Re: Inclusion of UML in 2.6.8)

[BlaisorBlade]

Alle 05:53, domenica 27 giugno 2004, Jeff Dike ha scritto:
> On Sat, Jun 26, 2004 at 07:10:48PM +0100, Christoph Hellwig wrote:
> > Please send split patches.  E.g. linux/ghash.h should not ne
> > reintroduced, it's completely fuly.

Anyway, I'm going to upload the whole patchset (as it is now); I just tarred 
my ./patch-scripts folder, containing descriptions, .pc files and actual 
patches. The updates from Jeff Dike are not very split, but everything I've 
added is in his own separate patch. Little changes anyway.

I've problems with patch-bomb, so for now here is it:

http://www.user-mode-linux.org/~blaisorblade/patches/bb/uml-patch-2.6.7-01-bb2.tar.bz2

The description of things is below (and in the patches headings, mostly).

Also, my main fear is about 2.7: if it is split before UML is merged, it means 
it won't be updated for all the API changes in 2.7.x.
For who want to flame with "better leave it broken than just doing compile 
fixes": who introduced set_page_count, for instance, grepped and changed it 
everywhere, even in the UML tree. And there was no reason to do so; so it 
would help us having UML in mainline, to react well to such updates.

> That requires a little interface work inside UML, and that was the main
> reason Andrew hasn't seen UML recently.
>
> > Also your above arch_free_page needs some more
> > discussion.
>
> I think that can disappear.  In some cases, it might be handy for the arch
> to see pages being freed, but right now, I believe that UML has no need for
> it.

Hmm, well, indeed that part was added just to support ubd-mmap, which you seem 
to have decided to drop*, but removing it would be hard for me, since it 
would mean doing a lot of checks to physmem handling; and I still don't want 
to fight against all the bugs I'd create. I'm seeing a lot more ones simply 
after switching to Mandrake 10 (don't flame me for this!) for my host.

The same thing holds for COW support: I cannot drop it so simply, since there 
are some references to it in working UBD code. That code should just drop 
them, since IIRC Jeff wants to make COW act on any two block devices; but 
I've not time to do it.

I could, instead, safely remove the /proc/mm support (for running nested UMLs 
in SKAS mode); the patch for this was well tested, so it's included; I'm 
providing a "combinediffed" version of them, since without removing SKAS the 
patch will probably not apply. I've also split ghash.h out.

* But when you say "It's vulnerable to the filesystem making changes to data 
that it intends never to reach the disk" in your diary, you speak about a 
performance problem, right? Or it is even broken?

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

Re: [uml-devel] Uploaded Uml patchset for 2.6.7(was: Re: Inclusion of UML in 2.6.8)

[BlaisorBlade]

Alle 21:29, martedì 29 giugno 2004, BlaisorBlade ha scritto:
> Alle 05:53, domenica 27 giugno 2004, Jeff Dike ha scritto:
> > On Sat, Jun 26, 2004 at 07:10:48PM +0100, Christoph Hellwig wrote:
> > > Please send split patches.  E.g. linux/ghash.h should not ne
> > > reintroduced, it's completely fuly.
>
> Anyway, I'm going to upload the whole patchset (as it is now); I just
> tarred my ./patch-scripts folder, containing descriptions, .pc files and
> actual patches. The updates from Jeff Dike are not very split, but
> everything I've added is in his own separate patch. Little changes anyway.
>
> I've problems with patch-bomb, so for now here is it:
>
> http://www.user-mode-linux.org/~blaisorblade/patches/bb/uml-patch-2.6.7-01-
>bb2.tar.bz2

I forgot 2 things: first - it's against 2.6.7 vanillla. Second - there are 
some not-working patches, but the "series" file does not refer to them.

So, 

tar xjf linux-2.6.7.tar.bz2
cd linux-2.6.7
tar xjf uml-patch-2.6.7-01-bb2.tar.bz2
pushpatch 30 (having patch-scripts installed)

is the simplest way to apply it. Without patch-scripts, for each line in 
patch-scripts/series (do grep -v '^#' first to remove comments) apply the 
patch from patch-scripts/patches.

Also, Andrew, why has it not been included in 2.6.7-mm5?
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

Re: Inclusion of UML in 2.6.8

[Andrew Morton]

BlaisorBlade <blaisorblade_spam@yahoo.it> wrote:
>
> Andrew, what are the requisite for stable inclusion of the UML update inside 
>  2.6-mm

I have no problem plopping it into -mm, as long as it doesn't cause me too
much pain.  It did cause patch management pain last time, but probably
whatever is was interacting with has now been merged up so it'll be OK.

But for a merge into mainline we do need to get down and do some work on it
- reintroducing ghash.h would not be welcome (I though Jeff was going to
eliminate that?) and last time we looked the patch had some blockdev
drivers in it which were doing antiquated 2.4 things.

Generally, UML in 2.6 seems to have fallen behind fairly seriously and at
some stage we need to go through the exercise of splitting the patch up,
reviewing and fixing all the bits and feeding it in.

Re: Inclusion of UML in 2.6.8

[Jeff Dike]

On Sat, Jun 26, 2004 at 01:09:45PM -0700, Andrew Morton wrote:
> I have no problem plopping it into -mm, as long as it doesn't cause me too
> much pain.  It did cause patch management pain last time, but probably
> whatever is was interacting with has now been merged up so it'll be OK.

The tty_init patch is gone, so ghash is the only nasty bit outside the arch
tree.

> But for a merge into mainline we do need to get down and do some work on it
> - reintroducing ghash.h would not be welcome (I though Jeff was going to
> eliminate that?) 

Yeah, it will be, but requires a bit of surgery.

> and last time we looked the patch had some blockdev
> drivers in it which were doing antiquated 2.4 things.

Not sure about that.  hch complained about the cow driver last time, which
can disappear until there is something that vaguely works.

> 
> Generally, UML in 2.6 seems to have fallen behind fairly seriously and at
> some stage we need to go through the exercise of splitting the patch up,
> reviewing and fixing all the bits and feeding it in.

Yup.  I've come to the conclusion that I've painted myself into a corner a
bit with BK and my currently style of working.  I'm looking at quilt, and
I'm pondering taking all the changes since the last time Linus merged UML
(2.5.69 or something), and breaking them up into sensible patches.

That'll be a lot of work, but I think it's something that needs doing.

				Jeff

Re: Inclusion of UML in 2.6.8

[Paul Jackson]

> I'm looking at quilt

Good tool.

It's a bit like a loaded gun with no safety. You will learn a few new
ways to shoot your foot off, and become good at first aid.  You will
want someway to keep personal revision history of your patches, to aid
in such repair work.  CVS or RCS or local bitkeeper or (for ancient
hackers like me) raw SCCS or some such.  Quilt handles the patches, but
in and of itself has nothing to do with preserving history.

All software is divided into two parts - the concrete and the fluid.

Once something is accepted into the main kernel, it's concrete.  You can
never go back - you can only layer fixes on top.  Bitkeeper rules for
this stuff.

But work in progress, for which oneself is still the primary source, is
fluid.  You can slice and dice and redo it, and indeed you want to, to
get the best patch set.  Quilt and friends rule for this stuff.

Conclusion - use Quilt (with your favorite personal version control) on
top of Bitkeeper.

Question - what tools are available for convenient patch set submission?
Composing multiple, related email sets in a GUI emailer is a bit tedious
and error prone.  It's an obvious candidate for scripting.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

Re: Inclusion of UML in 2.6.8

[Andrew Morton]

Paul Jackson <pj@sgi.com> wrote:
>
> > I'm looking at quilt
> 
> Good tool.
> 
> It's a bit like a loaded gun with no safety. You will learn a few new
> ways to shoot your foot off, and become good at first aid.  You will
> want someway to keep personal revision history of your patches, to aid
> in such repair work.  CVS or RCS or local bitkeeper or (for ancient
> hackers like me) raw SCCS or some such.  Quilt handles the patches, but
> in and of itself has nothing to do with preserving history.
> 
> All software is divided into two parts - the concrete and the fluid.
> 
> Once something is accepted into the main kernel, it's concrete.  You can
> never go back - you can only layer fixes on top.  Bitkeeper rules for
> this stuff.
> 
> But work in progress, for which oneself is still the primary source, is
> fluid.  You can slice and dice and redo it, and indeed you want to, to
> get the best patch set.  Quilt and friends rule for this stuff.

Good description, that.  quilt is a grown-up version of patch-scripts, and
is tailored to what I do, and to what distributors do: maintain a series of
diffs against a monolithic tree which someone else maintains.

> Conclusion - use Quilt (with your favorite personal version control) on
> top of Bitkeeper.

yup.  I use patch-scripts+CVS in the way which you describe.

> Question - what tools are available for convenient patch set submission?
> Composing multiple, related email sets in a GUI emailer is a bit tedious
> and error prone.  It's an obvious candidate for scripting.

patch-scripts has the "patch-bomb" script, which would presumably work OK
for quilt - it would need a little tweaking.

	http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.18/

Re: Inclusion of UML in 2.6.8

[Paul Jackson]

> patch-scripts has the "patch-bomb" script,

Aha - interesting.

Actually, I was asking a loaded question.  I just finished writing my
own patch bomber.  I see a few details in your patch-bomb worth stealing
- thanks.  Mine is more driven off of a single text file, that specifies
what files, with what subjects, to send to whom.  And its in Python.

The big feature (?) mine has is to set the Message-Id, In-Reply-To and
References fields so that all but the first one in the set appear to be
followups to the first one, for those using threaded email readers.
Hard to do that with smtpsend in the shell ;).

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

Re: Inclusion of UML in 2.6.8

[Andreas Gruenbacher]

On Sun, 2004-06-27 at 08:40, Andrew Morton wrote:
> Paul Jackson <pj@sgi.com> wrote:
> >
> > > I'm looking at quilt
> > 
> > Good tool.
> > 
> > It's a bit like a loaded gun with no safety. You will learn a few new
> > ways to shoot your foot off, and become good at first aid.

Ideas for improvement are always welcome -- they would best be discussed
on http://lists.nongnu.org/mailman/listinfo/quilt-dev.

> >  You will
> > want someway to keep personal revision history of your patches, to aid
> > in such repair work.  CVS or RCS or local bitkeeper or (for ancient
> > hackers like me) raw SCCS or some such.  Quilt handles the patches, but
> > in and of itself has nothing to do with preserving history.
> > 
> > All software is divided into two parts - the concrete and the fluid.
> > 
> > Once something is accepted into the main kernel, it's concrete.  You can
> > never go back - you can only layer fixes on top.  Bitkeeper rules for
> > this stuff.
> > 
> > But work in progress, for which oneself is still the primary source, is
> > fluid.  You can slice and dice and redo it, and indeed you want to, to
> > get the best patch set.  Quilt and friends rule for this stuff.
> 
> Good description, that.  quilt is a grown-up version of patch-scripts, and
> is tailored to what I do, and to what distributors do: maintain a series of
> diffs against a monolithic tree which someone else maintains.

The concepts behind quilt are all stolen from patch-scripts, so it has
the same usability problem that patch-scripts has: forgetting to add a
file to a patch before modifying it is painful. the ``quilt edit''
command helps somewhat. I do not have a good idea how to fix this in a
more satisfactory way.

Quilt is missing some of the features of patch-scripts: there are no
equivalents to export_patch, which renames exported patches so that the
filename sort order equals the order of the patches in the series file.
Neither is there a way to strip such sequencing prefixes when importing
patches. (I consider this obsolete.) There is nothing kernel specific,
and nothing specific to version control systems. Also there are no
equiovalents to patch-scripts's new-kernel, mv-patch, patch-bomb,
pstatus, rename-patch, tag-series, unitdiff.py commands.

On the other hand there are lots of small improvements, no more patch
control files (that list the files a patch touches in patch-scripts),
improved diffing and status inquiry functionality, patch dependency
analysis, support for RPM packages. And there is more documentation.

Things I'm currently considering include:

 - handling of meta-information such as one-line summary, author,
   description,

 - support for diffstat (re-add; we had this in older versions),

 - a patch-bomb equivalent.

All of the above things will potentially conflict with the goal of
keeping the whole thing as policy-free and generally useful as possible.
> > Conclusion - use Quilt (with your favorite personal version control) on
> > top of Bitkeeper.
> 
> yup.  I use patch-scripts+CVS in the way which you describe.

Same here.

Cheers,
-- 
Andreas Gruenbacher <agruen@suse.de>
SUSE Labs, SUSE LINUX AG

Re: Inclusion of UML in 2.6.8

[Paul Jackson]

> forgetting to add a file to a patch before modifying it is painful.

Yup.

One can dig ones way out by (1) copying the new code aside, (2)
unwinding until you can forcibly pop (or bk co) the pristine source
back, (3) push'ing back to the desired patch, (4) 'q edit' and copy over
the new code.  But this is a "learned" response.

> I do not have a good idea how to fix this in a more satisfactory way.

Me neither.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

Re: Inclusion of UML in 2.6.8

[David Eger]

On Sat, Jun 26, 2004 at 11:40:25PM -0700, Andrew Morton wrote:
>
> > But work in progress, for which oneself is still the primary source, is
> > fluid.  You can slice and dice and redo it, and indeed you want to, to
> > get the best patch set.  Quilt and friends rule for this stuff.
> 
> Good description, that.  quilt is a grown-up version of patch-scripts, and
> is tailored to what I do, and to what distributors do: maintain a series of
> diffs against a monolithic tree which someone else maintains.
> 
> > Conclusion - use Quilt (with your favorite personal version control) on
> > top of Bitkeeper.
> 
> yup.  I use patch-scripts+CVS in the way which you describe.

I had been wondering how you deal with so many patches...
So do people actually use bitKeeper for more than the following:

(1) glorified 'cp -r'
(2) memory of the history of the tree from which we did a 'cp -r'

-dte

Re: Inclusion of UML in 2.6.8

[Geert Uytterhoeven]

On Sat, 26 Jun 2004, Paul Jackson wrote:
> Question - what tools are available for convenient patch set submission?
> Composing multiple, related email sets in a GUI emailer is a bit tedious
> and error prone.  It's an obvious candidate for scripting.

The scripts I use to keep m68k up-to-date are available at:

    http://linux-m68k-cvs.apia.dhs.org/~geert/

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[PATCH] cirrusfb: update for amiga (zorro)

[David Eger]

Hey Geert, 

Thanks for bringing the ZORRO paths up to date for the cirrusfb driver.
The code looks good, and I trust your knowledge of Amiga much more than
my own. It would be nice if someone actually has this hardware and can
test the patch... Anyone? Anyone? Lars? Beuler?

There was a trivial problem applying the patch - one of the whitespace
fixes choked, so I took it out of the patch (below).

-dte

---

Cirrusfb updates:
  - Cirrusfb depends on Zorro or PCI
  - Revive Zorro support, using new Zorro driver framework
  - Merge PCI and Zorro code where possible
  - Use C99 initializers
  - Kill superfluous whitespace
  - #undef I/O ops before redefining them on Amiga

From: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David Eger <eger@havoc.gtf.org>

--- linux-2.6.8-rc2/drivers/video/Kconfig	2004-07-15 23:14:59.000000000 +0200
+++ linux-m68k-2.6.8-rc2/drivers/video/Kconfig	2004-07-19 21:06:17.000000000 +0200
@@ -40,7 +40,7 @@

 config FB_CIRRUS
 	tristate "Cirrus Logic support"
-	depends on FB && (AMIGA || PCI)
+	depends on FB && (ZORRO || PCI)
 	---help---
 	  This enables support for Cirrus Logic GD542x/543x based boards on
 	  Amiga: SD64, Piccolo, Picasso II/II+, Picasso IV, or EGS Spectrum.
--- linux-2.6.8-rc2/drivers/video/cirrusfb.c	2004-07-18 15:55:33.000000000 +0200
+++ linux-m68k-2.6.8-rc2/drivers/video/cirrusfb.c	2004-07-19 21:14:50.000000000 +0200
@@ -5,8 +5,8 @@
  *
  * Contributors (thanks, all!)
  *
- * 	David Eger:
- * 	Overhaul for Linux 2.6
+ *	David Eger:
+ *	Overhaul for Linux 2.6
  *
  *      Jeff Rugen:
  *      Major contributions;  Motorola PowerStack (PPC and PCI) support,
@@ -145,9 +145,6 @@
  * a run-time table?
  */
 static const struct cirrusfb_board_info_rec {
-	cirrusfb_board_t btype;	/* chipset enum, not strictly necessary, as
-				 * cirrusfb_board_info[] is directly indexed
-				 * by this value */
 	char *name;		/* ASCII name of chipset */
 	long maxclock[5];		/* maximum video clock */
 	/* for  1/4bpp, 8bpp 15/16bpp, 24bpp, 32bpp - numbers from xorg code */
@@ -164,104 +161,115 @@

 	unsigned char sr1f;	/* SR1F VGA initial register value */
 } cirrusfb_board_info[] = {
-	{ BT_NONE, }, /* dummy record */
-	{ BT_SD64,
-		"CL SD64",
-		{ 140000, 140000, 140000, 140000, 140000, },	/* guess */
-		/* the SD64/P4 have a higher max. videoclock */
-		TRUE,
-		TRUE,
-		TRUE,
-		0xF0,
-		0xF0,
-		0,		/* unused, does not multiplex */
-		0xF1,
-		0,		/* unused, does not multiplex */
-		0x20 },
-	{ BT_PICCOLO,
-		"CL Piccolo",
-		{ 90000, 90000, 90000, 90000, 90000 },	/* guess */
-		TRUE,
-		TRUE,
-		FALSE,
-		0x80,
-		0x80,
-		0,		/* unused, does not multiplex */
-		0x81,
-		0,		/* unused, does not multiplex */
-		0x22 },
-	{ BT_PICASSO,
-		"CL Picasso",
-		{ 90000, 90000, 90000, 90000, 90000, },	/* guess */
-		TRUE,
-		TRUE,
-		FALSE,
-		0x20,
-		0x20,
-		0,		/* unused, does not multiplex */
-		0x21,
-		0,		/* unused, does not multiplex */
-		0x22 },
-	{ BT_SPECTRUM,
-		"CL Spectrum",
-		{ 90000, 90000, 90000, 90000, 90000, },	/* guess */
-		TRUE,
-		TRUE,
-		FALSE,
-		0x80,
-		0x80,
-		0,		/* unused, does not multiplex */
-		0x81,
-		0,		/* unused, does not multiplex */
-		0x22 },
-	{ BT_PICASSO4,
-		"CL Picasso4",
-		{ 135100, 135100, 85500, 85500, 0 },
-		TRUE,
-		FALSE,
-		TRUE,
-		0x20,
-		0x20,
-		0,		/* unused, does not multiplex */
-		0x21,
-		0,		/* unused, does not multiplex */
-		0 },
-	{ BT_ALPINE,
-		"CL Alpine",
-		{ 85500, 85500, 50000, 28500, 0}, /* for the GD5430.  GD5446 can do more... */
-		TRUE,
-		TRUE,
-		TRUE,
-		0xA0,
-		0xA1,
-		0xA7,
-		0xA1,
-		0xA7,
-		0x1C },
-	{ BT_GD5480,
-		"CL GD5480",
-		{ 135100, 200000, 200000, 135100, 135100 },
-		TRUE,
-		TRUE,
-		TRUE,
-		0x10,
-		0x11,
-		0,		/* unused, does not multiplex */
-		0x11,
-		0,		/* unused, does not multiplex */
-		0x1C },
-	{ BT_LAGUNA,
-		"CL Laguna",
-		{ 135100, 135100, 135100, 135100, 135100, }, /* guess */
-		FALSE,
-		FALSE,
-		TRUE,
-		0,		/* unused */
-		0,		/* unused */
-		0,		/* unused */
-		0,		/* unused */
-		0,		/* unused */
-		0 },		/* unused */
+	[BT_SD64] = {
+		.name			= "CL SD64",
+		.maxclock		= {
+			/* guess */
+			/* the SD64/P4 have a higher max. videoclock */
+			140000, 140000, 140000, 140000, 140000,
+		},
+		.init_sr07		= TRUE,
+		.init_sr1f		= TRUE,
+		.scrn_start_bit19	= TRUE,
+		.sr07			= 0xF0,
+		.sr07_1bpp		= 0xF0,
+		.sr07_8bpp		= 0xF1,
+		.sr1f			= 0x20
+	},
+	[BT_PICCOLO] = {
+		.name			= "CL Piccolo",
+		.maxclock		= {
+			/* guess */
+			90000, 90000, 90000, 90000, 90000
+		},
+		.init_sr07		= TRUE,
+		.init_sr1f		= TRUE,
+		.scrn_start_bit19	= FALSE,
+		.sr07			= 0x80,
+		.sr07_1bpp		= 0x80,
+		.sr07_8bpp		= 0x81,
+		.sr1f			= 0x22
+	},
+	[BT_PICASSO] = {
+		.name			= "CL Picasso",
+		.maxclock		= {
+			/* guess */
+			90000, 90000, 90000, 90000, 90000
+		},
+		.init_sr07		= TRUE,
+		.init_sr1f		= TRUE,
+		.scrn_start_bit19	= FALSE,
+		.sr07			= 0x20,
+		.sr07_1bpp		= 0x20,
+		.sr07_8bpp		= 0x21,
+		.sr1f			= 0x22
+	},
+	[BT_SPECTRUM] = {
+		.name			= "CL Spectrum",
+		.maxclock		= {
+			/* guess */
+			90000, 90000, 90000, 90000, 90000
+		},
+		.init_sr07		= TRUE,
+		.init_sr1f		= TRUE,
+		.scrn_start_bit19	= FALSE,
+		.sr07			= 0x80,
+		.sr07_1bpp		= 0x80,
+		.sr07_8bpp		= 0x81,
+		.sr1f			= 0x22
+	},
+	[BT_PICASSO4] = {
+		.name			= "CL Picasso4",
+		.maxclock		= {
+			135100, 135100, 85500, 85500, 0
+		},
+		.init_sr07		= TRUE,
+		.init_sr1f		= FALSE,
+		.scrn_start_bit19	= TRUE,
+		.sr07			= 0x20,
+		.sr07_1bpp		= 0x20,
+		.sr07_8bpp		= 0x21,
+		.sr1f			= 0
+	},
+	[BT_ALPINE] = {
+		.name			= "CL Alpine",
+		.maxclock		= {
+			/* for the GD5430.  GD5446 can do more... */
+			85500, 85500, 50000, 28500, 0
+		},
+		.init_sr07		= TRUE,
+		.init_sr1f		= TRUE,
+		.scrn_start_bit19	= TRUE,
+		.sr07			= 0xA0,
+		.sr07_1bpp		= 0xA1,
+		.sr07_1bpp_mux		= 0xA7,
+		.sr07_8bpp		= 0xA1,
+		.sr07_8bpp_mux		= 0xA7,
+		.sr1f			= 0x1C
+	},
+	[BT_GD5480] = {
+		.name			= "CL GD5480",
+		.maxclock		= {
+			135100, 200000, 200000, 135100, 135100
+		},
+		.init_sr07		= TRUE,
+		.init_sr1f		= TRUE,
+		.scrn_start_bit19	= TRUE,
+		.sr07			= 0x10,
+		.sr07_1bpp		= 0x11,
+		.sr07_8bpp		= 0x11,
+		.sr1f			= 0x1C
+	},
+	[BT_LAGUNA] = {
+		.name			= "CL Laguna",
+		.maxclock		= {
+			/* guess */
+			135100, 135100, 135100, 135100, 135100,
+		},
+		.init_sr07		= FALSE,
+		.init_sr1f		= FALSE,
+		.scrn_start_bit19	= TRUE,
+	}
 };


@@ -270,12 +278,12 @@
 	{ PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_##id, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (btype) }

 static struct pci_device_id cirrusfb_pci_table[] = {
-	CHIP( CIRRUS_5436, 	BT_ALPINE ),
-	CHIP( CIRRUS_5434_8, 	BT_ALPINE ),
-	CHIP( CIRRUS_5434_4, 	BT_ALPINE ),
-	CHIP( CIRRUS_5430, 	BT_ALPINE ), /* GD-5440 has identical id */
-	CHIP( CIRRUS_7543, 	BT_ALPINE ),
-	CHIP( CIRRUS_7548, 	BT_ALPINE ),
+	CHIP( CIRRUS_5436,	BT_ALPINE ),
+	CHIP( CIRRUS_5434_8,	BT_ALPINE ),
+	CHIP( CIRRUS_5434_4,	BT_ALPINE ),
+	CHIP( CIRRUS_5430,	BT_ALPINE ), /* GD-5440 has identical id */
+	CHIP( CIRRUS_7543,	BT_ALPINE ),
+	CHIP( CIRRUS_7548,	BT_ALPINE ),
 	CHIP( CIRRUS_5480,	BT_GD5480 ), /* MacPicasso probably */
 	CHIP( CIRRUS_5446,	BT_PICASSO4 ), /* Picasso 4 is a GD5446 */
 	CHIP( CIRRUS_5462,	BT_LAGUNA ), /* CL Laguna */
@@ -289,31 +297,50 @@


 #ifdef CONFIG_ZORRO
+static const struct zorro_device_id cirrusfb_zorro_table[] = {
+	{
+		.id		= ZORRO_PROD_HELFRICH_SD64_RAM,
+		.driver_data	= BT_SD64,
+	}, {
+		.id		= ZORRO_PROD_HELFRICH_PICCOLO_RAM,
+		.driver_data	= BT_PICCOLO,
+	}, {
+		.id		= ZORRO_PROD_VILLAGE_TRONIC_PICASSO_II_II_PLUS_RAM,
+		.driver_data	= BT_PICASSO,
+	}, {
+		.id		= ZORRO_PROD_GVP_EGS_28_24_SPECTRUM_RAM,
+		.driver_data	= BT_SPECTRUM,
+	}, {
+		.id		= ZORRO_PROD_VILLAGE_TRONIC_PICASSO_IV_Z3,
+		.driver_data	= BT_PICASSO4,
+	},
+	{ 0 }
+};
+
 static const struct {
-	cirrusfb_board_t btype;
-	zorro_id id, id2;
+	zorro_id id2;
 	unsigned long size;
-} cirrusfb_zorro_probe_list[] __initdata = {
-	{ BT_SD64,
-		ZORRO_PROD_HELFRICH_SD64_RAM,
-		ZORRO_PROD_HELFRICH_SD64_REG,
-		0x400000 },
-	{ BT_PICCOLO,
-		ZORRO_PROD_HELFRICH_PICCOLO_RAM,
-		ZORRO_PROD_HELFRICH_PICCOLO_REG,
-		0x200000 },
-	{ BT_PICASSO,
-		ZORRO_PROD_VILLAGE_TRONIC_PICASSO_II_II_PLUS_RAM,
-		ZORRO_PROD_VILLAGE_TRONIC_PICASSO_II_II_PLUS_REG,
-		0x200000 },
-	{ BT_SPECTRUM,
-		ZORRO_PROD_GVP_EGS_28_24_SPECTRUM_RAM,
-		ZORRO_PROD_GVP_EGS_28_24_SPECTRUM_REG,
-		0x200000 },
-	{ BT_PICASSO4,
-		ZORRO_PROD_VILLAGE_TRONIC_PICASSO_IV_Z3,
-		0,
-		0x400000 },
+} cirrusfb_zorro_table2[] = {
+	[BT_SD64] = {
+		.id2	= ZORRO_PROD_HELFRICH_SD64_REG,
+		.size	= 0x400000
+	},
+	[BT_PICCOLO] = {
+		.id2	= ZORRO_PROD_HELFRICH_PICCOLO_REG,
+		.size	= 0x200000
+	},
+	[BT_PICASSO] = {
+		.id2	= ZORRO_PROD_VILLAGE_TRONIC_PICASSO_II_II_PLUS_REG,
+		.size	= 0x200000
+	},
+	[BT_SPECTRUM] = {
+		.id2	= ZORRO_PROD_GVP_EGS_28_24_SPECTRUM_REG,
+		.size	= 0x200000
+	},
+	[BT_PICASSO4] = {
+		.id2	= 0,
+		.size	= 0x400000
+	}
 };
 #endif /* CONFIG_ZORRO */

@@ -381,13 +408,12 @@
 	struct { u8 red, green, blue, pad; } palette[256];

 #ifdef CONFIG_ZORRO
-	unsigned long board_addr,
-		      board_size;
+	struct zorro_dev *zdev;
 #endif
-
 #ifdef CONFIG_PCI
 	struct pci_dev *pdev;
 #endif
+	void (*unmap)(struct cirrusfb_info *cinfo);
 };


@@ -401,50 +427,83 @@
 static const struct {
 	const char *name;
 	struct fb_var_screeninfo var;
-} cirrusfb_predefined[] =
-
-{
-	{"Autodetect",		/* autodetect mode */
-	 {0}
-	},
-
-	{"640x480",		/* 640x480, 31.25 kHz, 60 Hz, 25 MHz PixClock */
-	 {
-		 640, 480, 640, 480, 0, 0, 8, 0,
-		 {0, 8, 0},
-		 {0, 8, 0},
-		 {0, 8, 0},
-		 {0, 0, 0},
-	       0, 0, -1, -1, FB_ACCEL_NONE, 40000, 48, 16, 32, 8, 96, 4,
-     FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED
-	 }
-	},
-
-	{"800x600",		/* 800x600, 48 kHz, 76 Hz, 50 MHz PixClock */
-	 {
-		 800, 600, 800, 600, 0, 0, 8, 0,
-		 {0, 8, 0},
-		 {0, 8, 0},
-		 {0, 8, 0},
-		 {0, 0, 0},
-	       0, 0, -1, -1, FB_ACCEL_NONE, 20000, 128, 16, 24, 2, 96, 6,
-     0, FB_VMODE_NONINTERLACED
-	 }
-	},
-
-	/*
-	   Modeline from XF86Config:
-	   Mode "1024x768" 80  1024 1136 1340 1432  768 770 774 805
-	 */
-	{"1024x768",		/* 1024x768, 55.8 kHz, 70 Hz, 80 MHz PixClock */
-		{
-			1024, 768, 1024, 768, 0, 0, 8, 0,
-			{0, 8, 0},
-			{0, 8, 0},
-			{0, 8, 0},
-			{0, 0, 0},
-	      0, 0, -1, -1, FB_ACCEL_NONE, 12500, 144, 32, 30, 2, 192, 6,
-     0, FB_VMODE_NONINTERLACED
+} cirrusfb_predefined[] = {
+	{
+		/* autodetect mode */
+		.name	= "Autodetect",
+	}, {
+		/* 640x480, 31.25 kHz, 60 Hz, 25 MHz PixClock */
+		.name	= "640x480",
+		.var	= {
+			.xres		= 640,
+			.yres		= 480,
+			.xres_virtual	= 640,
+			.yres_virtual	= 480,
+			.bits_per_pixel	= 8,
+			.red		= { .length = 8 },
+			.green		= { .length = 8 },
+			.blue		= { .length = 8 },
+			.width		= -1,
+			.height		= -1,
+			.pixclock	= 40000,
+			.left_margin	= 48,
+			.right_margin	= 16,
+			.upper_margin	= 32,
+			.lower_margin	= 8,
+			.hsync_len	= 96,
+			.vsync_len	= 4,
+			.sync		= FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+			.vmode		= FB_VMODE_NONINTERLACED
+		 }
+	}, {
+		/* 800x600, 48 kHz, 76 Hz, 50 MHz PixClock */
+		.name	= "800x600",
+		.var	= {
+			.xres		= 800,
+			.yres		= 600,
+			.xres_virtual	= 800,
+			.yres_virtual	= 600,
+			.bits_per_pixel	= 8,
+			.red		= { .length = 8 },
+			.green		= { .length = 8 },
+			.blue		= { .length = 8 },
+			.width		= -1,
+			.height		= -1,
+			.pixclock	= 20000,
+			.left_margin	= 128,
+			.right_margin	= 16,
+			.upper_margin	= 24,
+			.lower_margin	= 2,
+			.hsync_len	= 96,
+			.vsync_len	= 6,
+			.vmode		= FB_VMODE_NONINTERLACED
+		 }
+	}, {
+		/*
+		 * Modeline from XF86Config:
+		 * Mode "1024x768" 80  1024 1136 1340 1432  768 770 774 805
+		 */
+		/* 1024x768, 55.8 kHz, 70 Hz, 80 MHz PixClock */
+		.name	= "1024x768",
+		.var	= {
+			.xres		= 1024,
+			.yres		= 768,
+			.xres_virtual	= 1024,
+			.yres_virtual	= 768,
+			.bits_per_pixel	= 8,
+			.red		= { .length = 8 },
+			.green		= { .length = 8 },
+			.blue		= { .length = 8 },
+			.width		= -1,
+			.height		= -1,
+			.pixclock	= 12500,
+			.left_margin	= 144,
+			.right_margin	= 32,
+			.upper_margin	= 30,
+			.lower_margin	= 2,
+			.hsync_len	= 192,
+			.vsync_len	= 6,
+			.vmode		= FB_VMODE_NONINTERLACED
 		}
 	}
 };
@@ -478,7 +537,7 @@
 static struct fb_ops cirrusfb_ops = {
 	.owner		= THIS_MODULE,
 	.fb_open	= cirrusfb_open,
-	.fb_release 	= cirrusfb_release,
+	.fb_release	= cirrusfb_release,
 	.fb_setcolreg	= cirrusfb_setcolreg,
 	.fb_check_var	= cirrusfb_check_var,
 	.fb_set_par	= cirrusfb_set_par,
@@ -1132,7 +1191,7 @@
 			DPRINTK (" (for GD54xx)\n");
 			vga_wseq (regbase, CL_SEQR7,
 				  regs.multiplexing ?
-				  	bi->sr07_1bpp_mux : bi->sr07_1bpp);
+					bi->sr07_1bpp_mux : bi->sr07_1bpp);
 			break;

 		case BT_LAGUNA:
@@ -1216,7 +1275,7 @@
 			DPRINTK (" (for GD54xx)\n");
 			vga_wseq (regbase, CL_SEQR7,
 				  regs.multiplexing ?
-				  	bi->sr07_8bpp_mux : bi->sr07_8bpp);
+					bi->sr07_8bpp_mux : bi->sr07_8bpp);
 			break;

 		case BT_LAGUNA:
@@ -2156,10 +2215,144 @@
 	framebuffer_release(cinfo->info);
 	pci_disable_device(pdev);
 }
+#endif /* CONFIG_PCI */
+
+
+#ifdef CONFIG_ZORRO
+static void __devexit cirrusfb_zorro_unmap (struct cirrusfb_info *cinfo)
+{
+	zorro_release_device(cinfo->zdev);
+
+	if (cinfo->btype == BT_PICASSO4) {
+		cinfo->regbase -= 0x600000;
+		iounmap ((void *)cinfo->regbase);
+		iounmap ((void *)cinfo->fbmem);
+	} else {
+		if (zorro_resource_start(cinfo->zdev) > 0x01000000)
+			iounmap ((void *)cinfo->fbmem);
+	}
+	framebuffer_release(cinfo->info);
+}
+#endif /* CONFIG_ZORRO */
+
+static int cirrusfb_set_fbinfo(struct cirrusfb_info *cinfo)
+{
+	struct fb_info *info = cinfo->info;
+	struct fb_var_screeninfo *var = &info->var;
+
+	info->currcon = -1;
+	info->par = cinfo;
+	info->pseudo_palette = cinfo->pseudo_palette;
+	info->flags = FBINFO_DEFAULT
+		    | FBINFO_HWACCEL_XPAN
+		    | FBINFO_HWACCEL_YPAN
+		    | FBINFO_HWACCEL_FILLRECT
+		    | FBINFO_HWACCEL_COPYAREA;
+	if (noaccel)
+		info->flags |= FBINFO_HWACCEL_DISABLED;
+	info->fbops = &cirrusfb_ops;
+	info->screen_base = cinfo->fbmem;
+	if (cinfo->btype == BT_GD5480) {
+		if (var->bits_per_pixel == 16)
+			info->screen_base += 1 * MB_;
+		if (var->bits_per_pixel == 24 || var->bits_per_pixel == 32)
+			info->screen_base += 2 * MB_;
+	}
+
+	/* Fill fix common fields */
+	strlcpy(info->fix.id, cirrusfb_board_info[cinfo->btype].name,
+		sizeof(info->fix.id));
+
+	/* monochrome: only 1 memory plane */
+	/* 8 bit and above: Use whole memory area */
+	info->fix.smem_start = cinfo->fbmem_phys;
+	info->fix.smem_len   = (var->bits_per_pixel == 1) ? cinfo->size / 4 : cinfo->size;
+	info->fix.type       = cinfo->currentmode.type;
+	info->fix.type_aux   = 0;
+	info->fix.visual     = cinfo->currentmode.visual;
+	info->fix.xpanstep   = 1;
+	info->fix.ypanstep   = 1;
+	info->fix.ywrapstep  = 0;
+	info->fix.line_length = cinfo->currentmode.line_length;
+
+	/* FIXME: map region at 0xB8000 if available, fill in here */
+	info->fix.mmio_start = cinfo->fbregs_phys;
+	info->fix.mmio_len   = 0;
+	info->fix.accel = FB_ACCEL_NONE;
+
+	fb_alloc_cmap(&info->cmap, 256, 0);
+
+	return 0;
+}

+static int cirrusfb_register(struct cirrusfb_info *cinfo)
+{
+	struct fb_info *info;
+	int err;
+	cirrusfb_board_t btype;
+
+	DPRINTK ("ENTER\n");

-static struct cirrusfb_info *cirrusfb_pci_setup (struct pci_dev *pdev,
-				   		 const struct pci_device_id *ent)
+	printk (KERN_INFO "cirrusfb: Driver for Cirrus Logic based graphic boards, v" CIRRUSFB_VERSION "\n");
+
+	info = cinfo->info;
+	btype = cinfo->btype;
+
+	/* sanity checks */
+	assert (btype != BT_NONE);
+
+	DPRINTK ("cirrusfb: (RAM start set to: 0x%p)\n", cinfo->fbmem);
+
+	/* Make pretend we've set the var so our structures are in a "good" */
+	/* state, even though we haven't written the mode to the hw yet...  */
+	info->var = cirrusfb_predefined[cirrusfb_def_mode].var;
+	info->var.activate = FB_ACTIVATE_NOW;
+
+	err = cirrusfb_decode_var(&info->var, &cinfo->currentmode, info);
+	if (err < 0) {
+		/* should never happen */
+		DPRINTK("choking on default var... umm, no good.\n");
+		goto err_unmap_cirrusfb;
+	}
+
+	/* set all the vital stuff */
+	cirrusfb_set_fbinfo(cinfo);
+
+	err = register_framebuffer(info);
+	if (err < 0) {
+		printk (KERN_ERR "cirrusfb: could not register fb device; err = %d!\n", err);
+		goto err_dealloc_cmap;
+	}
+
+	DPRINTK ("EXIT, returning 0\n");
+	return 0;
+
+err_dealloc_cmap:
+	fb_dealloc_cmap(&info->cmap);
+err_unmap_cirrusfb:
+	cinfo->unmap(cinfo);
+	return err;
+}
+
+static void __devexit cirrusfb_cleanup (struct fb_info *info)
+{
+	struct cirrusfb_info *cinfo = info->par;
+	DPRINTK ("ENTER\n");
+
+	switch_monitor (cinfo, 0);
+
+	unregister_framebuffer (info);
+	fb_dealloc_cmap (&info->cmap);
+	printk ("Framebuffer unregistered\n");
+	cinfo->unmap(cinfo);
+
+	DPRINTK ("EXIT\n");
+}
+
+
+#ifdef CONFIG_PCI
+static int cirrusfb_pci_register (struct pci_dev *pdev,
+				  const struct pci_device_id *ent)
 {
 	struct cirrusfb_info *cinfo;
 	struct fb_info *info;
@@ -2233,11 +2426,13 @@

 	cinfo->fbmem_phys = board_addr;
 	cinfo->size = board_size;
+	cinfo->unmap = cirrusfb_pci_unmap;

 	printk (" RAM (%lu kB) at 0xx%lx, ", cinfo->size / KB_, board_addr);
 	printk ("Cirrus Logic chipset on PCI bus\n");
+	pci_set_drvdata(pdev, info);

-	return cinfo;
+	return cirrusfb_register(cinfo);

 err_release_legacy:
 	if (release_io_ports)
@@ -2252,77 +2447,51 @@
 err_disable:
 	pci_disable_device(pdev);
 err_out:
-	return ERR_PTR(ret);
+	return ret;
 }
-#endif				/* CONFIG_PCI */
-
-

-
-#ifdef CONFIG_ZORRO
-static int cirrusfb_zorro_find (struct zorro_dev **z_o,
-				    struct zorro_dev **z2_o,
-				    cirrusfb_board_t *btype, unsigned long *size)
+void __devexit cirrusfb_pci_unregister (struct pci_dev *pdev)
 {
-	struct zorro_dev *z = NULL;
-	int i;
-
-	assert (z_o != NULL);
-	assert (btype != NULL);
-
-	for (i = 0; i < ARRAY_SIZE(cirrusfb_zorro_probe_list); i++)
-		if ((z = zorro_find_device(cirrusfb_zorro_probe_list[i].id, NULL)))
-			break;
-
-	if (z) {
-		*z_o = z;
-		if (cirrusfb_zorro_probe_list[i].id2)
-			*z2_o = zorro_find_device(cirrusfb_zorro_probe_list[i].id2, NULL);
-		else
-			*z2_o = NULL;
-
-		*btype = cirrusfb_zorro_probe_list[i].btype;
-		*size = cirrusfb_zorro_probe_list[i].size;
-
-		printk (KERN_INFO "cirrusfb: %s board detected; ",
-			cirrusfb_board_info[*btype].name);
+	struct fb_info *info = pci_get_drvdata(pdev);
+	DPRINTK ("ENTER\n");

-		return 0;
-	}
+	cirrusfb_cleanup (info);

-	printk (KERN_NOTICE "cirrusfb: no supported board found.\n");
-	return -ENODEV;
+	DPRINTK ("EXIT\n");
 }

-
-static void __devexit cirrusfb_zorro_unmap (struct cirrusfb_info *cinfo)
-{
-	release_mem_region(cinfo->board_addr, cinfo->board_size);
-
-	if (cinfo->btype == BT_PICASSO4) {
-		cinfo->regbase -= 0x600000;
-		iounmap ((void *)cinfo->regbase);
-		iounmap ((void *)cinfo->fbmem);
-	} else {
-		if (cinfo->board_addr > 0x01000000)
-			iounmap ((void *)cinfo->fbmem);
-	}
-	framebuffer_release(cinfo->info);
-}
+static struct pci_driver cirrusfb_pci_driver = {
+	.name		= "cirrusfb",
+	.id_table	= cirrusfb_pci_table,
+	.probe		= cirrusfb_pci_register,
+	.remove		= __devexit_p(cirrusfb_pci_unregister),
+#ifdef CONFIG_PM
+#if 0
+	.suspend	= cirrusfb_pci_suspend,
+	.resume		= cirrusfb_pci_resume,
+#endif
+#endif
+};
+#endif /* CONFIG_PCI */


-static struct cirrusfb_info *cirrusfb_zorro_setup(void)
+#ifdef CONFIG_ZORRO
+static int cirrusfb_zorro_register(struct zorro_dev *z,
+				   const struct zorro_device_id *ent)
 {
 	struct cirrusfb_info *cinfo;
 	struct fb_info *info;
 	cirrusfb_board_t btype;
-	struct zorro_dev *z = NULL, *z2 = NULL;
+	struct zorro_dev *z2 = NULL;
 	unsigned long board_addr, board_size, size;
 	int ret;

-	ret = cirrusfb_zorro_find (&z, &z2, &btype, &size);
-	if (ret < 0)
-		goto err_out;
+	btype = ent->driver_data;
+	if (cirrusfb_zorro_table2[btype].id2)
+		z2 = zorro_find_device(cirrusfb_zorro_table2[btype].id2, NULL);
+	size = cirrusfb_zorro_table2[btype].size;
+	printk(KERN_INFO "cirrusfb: %s board detected; ",
+	       cirrusfb_board_info[btype].name);

 	info = framebuffer_alloc(sizeof(struct cirrusfb_info), &z->dev);
 	if (!info) {
@@ -2339,11 +2508,12 @@
 	assert (z2 >= 0);
 	assert (btype != BT_NONE);

-	cinfo->board_addr = board_addr = z->resource.start;
-	cinfo->board_size = board_size = z->resource.end-z->resource.start+1;
+	cinfo->zdev = z;
+	board_addr = zorro_resource_start(z);
+	board_size = zorro_resource_len(z);
 	cinfo->size = size;

-	if (!request_mem_region(board_addr, board_size, "cirrusfb")) {
+	if (!zorro_request_device(z, "cirrusfb")) {
 		printk(KERN_ERR "cirrusfb: cannot reserve region 0x%lx, abort\n",
 		       board_addr);
 		ret = -EBUSY;
@@ -2370,7 +2540,7 @@
 		cinfo->fbregs_phys = board_addr + 0x600000;

 		cinfo->fbmem_phys = board_addr + 16777216;
-		cinfo->fbmem = ioremap (info->fbmem_phys, 16777216);
+		cinfo->fbmem = ioremap (cinfo->fbmem_phys, 16777216);
 		if (!cinfo->fbmem)
 			goto err_unmap_regbase;
 	} else {
@@ -2390,10 +2560,12 @@

 		DPRINTK ("cirrusfb: Virtual address for board set to: $%p\n", cinfo->regbase);
 	}
+	cinfo->unmap = cirrusfb_zorro_unmap;

 	printk (KERN_INFO "Cirrus Logic chipset on Zorro bus\n");
+	zorro_set_drvdata(z, info);

-	return 0;
+	return cirrusfb_register(cinfo);

 err_unmap_regbase:
 	/* Parental advisory: explicit hack */
@@ -2403,153 +2575,12 @@
 err_release_fb:
 	framebuffer_release(info);
 err_out:
-	return ERR_PTR(ret);
+	return ret;
 }
-#endif /* CONFIG_ZORRO */

-static int cirrusfb_set_fbinfo(struct cirrusfb_info *cinfo)
+void __devexit cirrusfb_zorro_unregister(struct zorro_dev *z)
 {
-	struct fb_info *info = cinfo->info;
-	struct fb_var_screeninfo *var = &info->var;
-
-	info->currcon = -1;
-	info->par = cinfo;
-	info->pseudo_palette = cinfo->pseudo_palette;
-	info->flags = FBINFO_DEFAULT
-		    | FBINFO_HWACCEL_XPAN
-		    | FBINFO_HWACCEL_YPAN
-		    | FBINFO_HWACCEL_FILLRECT
-		    | FBINFO_HWACCEL_COPYAREA;
-	if (noaccel)
-		info->flags |= FBINFO_HWACCEL_DISABLED;
-	info->fbops = &cirrusfb_ops;
-	info->screen_base = cinfo->fbmem;
-	if (cinfo->btype == BT_GD5480) {
-		if (var->bits_per_pixel == 16)
-			info->screen_base += 1 * MB_;
-		if (var->bits_per_pixel == 24 || var->bits_per_pixel == 32)
-			info->screen_base += 2 * MB_;
-	}
-
-	/* Fill fix common fields */
-	strlcpy(info->fix.id, cirrusfb_board_info[cinfo->btype].name,
-		sizeof(info->fix.id));
-
-	/* monochrome: only 1 memory plane */
-	/* 8 bit and above: Use whole memory area */
-	info->fix.smem_start = cinfo->fbmem_phys;
-	info->fix.smem_len   = (var->bits_per_pixel == 1) ? cinfo->size / 4 : cinfo->size;
-	info->fix.type       = cinfo->currentmode.type;
-	info->fix.type_aux   = 0;
-	info->fix.visual     = cinfo->currentmode.visual;
-	info->fix.xpanstep   = 1;
-	info->fix.ypanstep   = 1;
-	info->fix.ywrapstep  = 0;
-	info->fix.line_length = cinfo->currentmode.line_length;
-
-	/* FIXME: map region at 0xB8000 if available, fill in here */
-	info->fix.mmio_start = cinfo->fbregs_phys;
-	info->fix.mmio_len   = 0;
-	info->fix.accel = FB_ACCEL_NONE;
-
-	fb_alloc_cmap(&info->cmap, 256, 0);
-
-	return 0;
-}
-
-#if defined(CONFIG_PCI)
-#define cirrusfb_unmap cirrusfb_pci_unmap
-#define cirrusfb_bus_setup cirrusfb_pci_setup
-#elif defined(CONFIG_ZORRO)
-#define cirrusfb_unmap cirrusfb_zorro_unmap
-#define cirrusfb_bus_setup cirrusfb_zorro_setup
-#endif
-
-
-static int cirrusfb_pci_register (struct pci_dev *pdev,
-				  const struct pci_device_id *ent)
-{
-	struct fb_info *info;
-	struct cirrusfb_info *cinfo = NULL;
-	int err;
-	cirrusfb_board_t btype;
-
-	DPRINTK ("ENTER\n");
-
-	printk (KERN_INFO "cirrusfb: Driver for Cirrus Logic based graphic boards, v" CIRRUSFB_VERSION "\n");
-
-	cinfo = cirrusfb_bus_setup(pdev, ent);
-
-	if (IS_ERR(cinfo)) {
-		err = PTR_ERR(cinfo);
-		goto err_out;
-	}
-
-	info = cinfo->info;
-	btype = cinfo->btype;
-
-	/* sanity checks */
-	assert (btype != BT_NONE);
-	assert (btype == cirrusfb_board_info[btype].btype);
-
-	DPRINTK ("cirrusfb: (RAM start set to: 0x%p)\n", cinfo->fbmem);
-
-	/* Make pretend we've set the var so our structures are in a "good" */
-	/* state, even though we haven't written the mode to the hw yet...  */
-	info->var = cirrusfb_predefined[cirrusfb_def_mode].var;
-	info->var.activate = FB_ACTIVATE_NOW;
-
-	err = cirrusfb_decode_var(&info->var, &cinfo->currentmode, info);
-	if (err < 0) {
-		/* should never happen */
-		DPRINTK("choking on default var... umm, no good.\n");
-		goto err_unmap_cirrusfb;
-	}
-
-	/* set all the vital stuff */
-	cirrusfb_set_fbinfo(cinfo);
-
-	pci_set_drvdata(pdev, info);
-
-	err = register_framebuffer(info);
-	if (err < 0) {
-		printk (KERN_ERR "cirrusfb: could not register fb device; err = %d!\n", err);
-		goto err_dealloc_cmap;
-	}
-
-	DPRINTK ("EXIT, returning 0\n");
-	return 0;
-
-err_dealloc_cmap:
-	fb_dealloc_cmap(&info->cmap);
-err_unmap_cirrusfb:
-	cirrusfb_unmap(cinfo);
-err_out:
-	return err;
-}
-
-
-static void __devexit cirrusfb_cleanup (struct fb_info *info)
-{
-	struct cirrusfb_info *cinfo = info->par;
-	DPRINTK ("ENTER\n");
-
-#ifdef CONFIG_ZORRO
-	switch_monitor (cinfo, 0);
-#endif
-
-	unregister_framebuffer (info);
-	fb_dealloc_cmap (&info->cmap);
-	printk ("Framebuffer unregistered\n");
-	cirrusfb_unmap (cinfo);
-
-	DPRINTK ("EXIT\n");
-}
-
-
-void __devexit cirrusfb_pci_unregister (struct pci_dev *pdev)
-{
-	struct fb_info *info = pci_get_drvdata(pdev);
+	struct fb_info *info = zorro_get_drvdata(z);
 	DPRINTK ("ENTER\n");

 	cirrusfb_cleanup (info);
@@ -2557,26 +2588,25 @@
 	DPRINTK ("EXIT\n");
 }

-static struct pci_driver cirrusfb_driver = {
-	.name	= "cirrusfb",
-	.id_table	= cirrusfb_pci_table,
-	.probe		= cirrusfb_pci_register,
-	.remove		= __devexit_p(cirrusfb_pci_unregister),
-#ifdef CONFIG_PM
-#if 0
-	.suspend	= cirrusfb_pci_suspend,
-	.resume		= cirrusfb_pci_resume,
-#endif
-#endif
+static struct zorro_driver cirrusfb_zorro_driver = {
+	.name		= "cirrusfb",
+	.id_table	= cirrusfb_zorro_table,
+	.probe		= cirrusfb_zorro_register,
+	.remove		= __devexit_p(cirrusfb_zorro_unregister),
 };
+#endif /* CONFIG_ZORRO */

 int __init cirrusfb_init(void)
 {
+	int error = 0;
+
 #ifdef CONFIG_ZORRO
-	return cirrusfb_pci_register(NULL, NULL);
-#else
-	return pci_module_init(&cirrusfb_driver);
+	error |= zorro_module_init(&cirrusfb_zorro_driver);
 #endif
+#ifdef CONFIG_PCI
+	error |= pci_module_init(&cirrusfb_pci_driver);
+#endif
+	return error;
 }


@@ -2619,7 +2649,12 @@

 void __exit cirrusfb_exit (void)
 {
-	pci_unregister_driver (&cirrusfb_driver);
+#ifdef CONFIG_PCI
+	pci_unregister_driver(&cirrusfb_pci_driver);
+#endif
+#ifdef CONFIG_ZORRO
+	zorro_unregister_driver(&cirrusfb_zorro_driver);
+#endif
 }

 #ifdef MODULE
@@ -2830,7 +2865,7 @@

 static void cirrusfb_BitBLT (caddr_t regbase, int bits_per_pixel,
 			     u_short curx, u_short cury, u_short destx, u_short desty,
-		  	     u_short width, u_short height, u_short line_length)
+			     u_short width, u_short height, u_short line_length)
 {
 	u_short nwidth, nheight;
 	u_long nsrc, ndest;
--- linux-2.6.8-rc2/include/video/vga.h	2003-03-25 10:07:30.000000000 +0100
+++ linux-m68k-2.6.8-rc2/include/video/vga.h	2004-07-19 19:38:47.000000000 +0200
@@ -26,8 +26,15 @@
 /*
  * FIXME
  * Ugh, we don't have PCI space, so map readb() and friends to use Zorro space
- * for MMIO accesses. This should make clgenfb work again on Amiga
+ * for MMIO accesses. This should make cirrusfb work again on Amiga
  */
+#undef inb_p
+#undef inw_p
+#undef outb_p
+#undef outw
+#undef readb
+#undef writeb
+#undef writew
 #define inb_p(port)	0
 #define inw_p(port)	0
 #define outb_p(port, val)	do { } while (0)