On Tue, Feb 13, 2007 at 03:26:09PM +1100, Finn Thain wrote:
On Sun, 11 Feb 2007, Brad Boyer wrote:
I'm working on getting the macio bus finished on m68k, but I haven't had
enough time to work on it recently. It's a bit of a pain, since it means
moving the hardware data out of the individual drivers into something
more generic.
From a cohesion point of view, that isn't ideal. Could that data be placed
in __init structs and remain in the drivers?
I know it isn't ideal, but I wanted to be able to share more drivers with
the pmac versions. Some of the drivers I was hoping to share are mace,
pmac_zilog, and mac53c94. I'm sure there are more. I suppose I could
make some kind of data load call in the init only on m68k. I know the ppc
port already has the hardware tables from firmware on any PCI mac, and
the nbpmac port just builds up a fake firmware table and shoves it into
the generic ppc code. I'll take a look at it.
I currently have something like the nbpmac port in ppc does, with a
bunch of hard-coded tables matched onto the gestalt ID passed in from
Penguin. Suggestions of a better idea would be good.
This is what mac_identify() does too. I don't see a problem with using the
gestalt ID (?) If nothing else, it lets me use "I wish I were" to get my
Daystar Mac II to show up as a Mac IIx (i.e. a supported model). What's
wrong with a probe routine that just tests the macintosh_config global?
Well, the macintosh_config global doesn't have information about all the
onboard hardware. I suppose we could add it for other things like sound.
I had some delusion that we might be able to get rid of macintosh_config.
The code isn't finished yet, so I don't really have anything to share.
I'm starting to get where I have a little more time, so I may have
something in the next few weeks.
Doing a proper driver model framework for nubus would be a little easier
since it is possible to probe for nubus cards, unlike the onboard chips.
It's possible that might work better than what we have. If we could ensure
that the non-nubus devices that use nubus IRQs (SONIC, Baboon, IDE...) had
already been probed, then we might be able to prevent any unregistered
slot IRQs, just by registering the nubus handler after nubus probing is
done.
My idea would be to make everything that uses a nubus IRQ to at least
partially fake being a nubus driver. I haven't looked at enough of the
hacky ones like IDE to be sure of this. I'll take another look after I
get the work on macio done.
Brad Boyer
flar@xxxxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
