bjh21@netbsd.org (Ben Harris) writes:

> On 15 Oct 2000, Chris G. Demetriou wrote:
> 
> > I disagree with the notion of a directory for every single chip of the
> > PC super-io variety, or even this one unless there's some overriding
> > reason -- i'm coming into this thread late, and this was the first
> > message I saw about it.
> > 
> > If it's a PC super-io chip, what's wrong with just attaching an 'ISA'
> > to it?
> 
> Its a possibility, though there are a few things I don't like about the
> prospect:
> 
>  - At the moment, the upc driver reads the chip's configuration registers,
>    and uses the results to locate the child devices.  Is this sensibly
>    possible with an isa attachment?  If not, we have to fall back to
>    probing for each device, which is grotty.

hence my comment about doing a direct-config variant of ISA, which is
what you want if you don't want each device to probe.


>  - The UPC has the ability to power sections of the chip up and down,
>    which should be used to eg turn off the serial ports when they're not
>    in use.  While there's no code to handle this at present, I can imagine
>    that it would get even harder to add with an isa interface in the way.

yeah, so, throw some hooks into the chipset structure and off you go.


>  - Devices attached at isa are expected to call bus_space_map themselves,
>    which means the relevant bus_space_tag_t has to contain enough
>    information to locate the UPC in the system's I/O space.  This is
>    probably only a problem if you use a very simple bus_space
>    implementation, though.

I don't think i understand the issue you're facing.  do you have a
non-flat I/O space, or what?

if it's effectively flat, you could go the route where the I/O
addresses are large numbers, rather than small numbers.  8-)


> > that's what some ports do, unless i'm mistaken.
> 
> Which ones?  I'd like to see how it works in practice.

actually, i may be mistaken in that regard, and don't have time to
look very carefully right now.

the alpha jensen i/o invents its own pseudo-bus and attaches
direct-config stuff on its super-io there.  (not sure that i agree
that that's the Right Way, but whatever; i didn't write that code.)

shark gets its from ofw nodes / ofisa.

i dunno about others off-hand -- and had to check to see how the
jensen did it.


ofisa is kind-of something similar, but the method of configuration
would be different.  (instead of walking tree, chip provides a table
of hardware that's there.)


cgd