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
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
