Subject: Re: CVS commit: syssrc
To: Ben Harris <firstname.lastname@example.org>
From: Chris G. Demetriou <email@example.com>
Date: 10/17/2000 09:34:43
Ben Harris <firstname.lastname@example.org> writes:
> Right, so is your problem with there being a separate batch of bus
> attachments for each type of multi-I/O chip?
yes. There may be more, but to be honest I've not been following
closely enough... 8-)
> If so, would an MI version
> of the amiga supio stuff be acceptable?
I think you're probably best off having a bus, call it 'dcisa' or who
knows what, to which attach devices. As with ISA, that bus gets a
bunch of function pointers, etc., that indirect to code provided by
the chip driver. The chip driver also provides a table of devices.
(probably shouldn't use driver names for the purpose, but rather
I'd prefer that, rather than a generic super-io chip device (with all
the chip-specific guts in the match/attach routines) for a couple of
(1) it makes it easier to support multiple types of super-io chips on
a single platform/bus. (i.e. if the guts are in the match/attach, of
which you can have only one per bus, then if you need to support
multiple chips you start getting hairy).
(2) it better accomodates the specification and selection of built-in
Really, in a perfect world, 'isa' would be augmented to take a table
from the MD implementation, and pass an extra argument along in the
isa_attach_args indicating direct configuration, and config_found()
all of the direct-config devices specified in the table, and then
optionally also do indirect configuration for the rest.
To my mind, _this_ is the correct model for operation, because, in a
nutshell, on some systems you have built-in devices at known locations
on isa, and then you have add-in devices as well.
The former should be expressible via direct configuration.