On Tue, 13 Feb 2007, Brad Boyer wrote:
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,
There's not much point trying to reuse mace. The ppc macs have mace behind
the descriptor-based dma engine, which involves the larger part of the
code in the driver. My recent macmace patch brought the two closer, but I
feel that it would become a #ifdef disaster if it were a single driver.
There is some chance for a {macsonic,jazzsonic,sonic}.c style split, but
the common code is small (chip initialisation), unlikely to change, and it
is only replicated once anyway.
pmac_zilog, and mac53c94. I'm sure there are more.
Certainly CUDA.
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.
Did that ever go upstream? If we are going to fake openfirmware, isn't the
logical conclusion a rewrite of the bootloaders?
Doing that probably makes sense for nubus powermacs, since they share more
drivers with pci powermacs. In our case, it is zilog, scsi and cuda (maybe
pmu, but a minority of drivers anyway).
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.
True, and perhaps some of those devices can be probed by looking for their
signatures in memory mapped registers ... maybe you can do that for
macmace, since the chip is documented by AMD, but why would you? We know
that if a machine has mace, it is a 840av or a 660av. And if a machine is
840av or a 660av, then it has mace on the motherboard. So we use the
gestalt ID in macintosh_config to check for 840av or 660av... can this be
improved upon?
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.
Ambitious. The problem is of course, how do you probe for RBV vs VIA? Or
IDE? Or CUDA vs Egret? How do you tell whether a machine supports the A/UX
interrupt scheme?
We will always depend on macintosh_config for hardware that can't be
probed because it isn't documented.
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.
That's a good idea. From the aesthetic point of view, it kind of spoils a
nice clean device tree -- not that I care... Fact is these are both
platform devices and nubus devices, or maybe neither. But it raises a
useful question: how far should one push the wrong abstraction?
There really is no openfirmware on 68k macs, which is why Apple's gestalt
mechanism works the way it does. There is an argument for passing Gestalt
feature tests up from the boot loader instead of the machine ID. But I'm
not sure what that would buy us. (It isn't like we don't know what Apple's
next 68k mac release will look like, which was the situation when Gestalt
feature tests were designed.)
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.
Fair enough. I like the idea of probing for devices if it is easy to do.
But if there is a simple rule to infer device presence from gestalt ID (as
with RBV, PSC, Baboon, IDE etc) that's hard to beat.
-f
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
