On Thu, Feb 15, 2007 at 12:31:41PM +1100, Finn Thain wrote:
On Tue, 13 Feb 2007, Brad Boyer wrote:
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.
I was also hoping to cleanup the DMA code and push it into the macio
layer instead of having each driver poke at the DBDMA implementation
directly. It would make the nbpmac port easier as well, since they
have a totally different DMA implementation as well. That's definitely
a project for later, which makes sharing mace and mac53c94 a project
for later as well.
Certainly CUDA.
I suppose it was stupid of me to miss the only one we're actually
already sharing. It would be nice to get rid of some of the #ifdefs.
Did that ever go upstream? If we are going to fake openfirmware, isn't the
logical conclusion a rewrite of the bootloaders?
I don't think nbpmac ever got accepted. A few people were working on
it in 2.6, but I haven't heard anything in a long time. If we were
going to fake openfirmware the way embedded powerpc targets are
doing, the bootloader would be a better place for it. I'm just not
sure that's practical for m68k. It's certainly more than I want to do.
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).
True. Perhaps it's a bad idea. I'll take another look at other approaches.
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?
It does seem like matching on the gestalt id directly or having entries
in the config table is the simplest.
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 lack of documentation isn't really the issue. It's all the stuff
that can't effectively be probed at runtime because you'll break
another model if you poke bits at the wrong address.
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?
It's hard to say how it should work, particularly since some of them
use an IRQ that's not even a real slot. I suppose it depends on how
much they implemented. For example, the builtin video on the SE/30
even has a fake NuBus ROM. Apple officially recommended that PDS cards
look as much like NuBus cards as possible. I think the Farallon
ethernet cards for PDS/030 (SE/30 and IIsi) have a ROM as well.
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.)
That's true. We can know exactly what is on each model because they
have already all been designed and there aren't likely to be new ones.
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.
That's true. We really can't probe chips in the normal I/O range. It's
just a matter of knowing what is where. I'll take a look at doing it
a different way.
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
