David Forbes <david@flossy.u-net.com> writes:
> > ISA I/O accesses (and maybe memory accesses) _do_ fall into that
> > category, i.e. a read of a non-existant device is supposed to return
> > all-bits-set.
> 
> This is what I was looking for  ;-)  and having read isareg.h, it appears
> that the addresses I'm attempting to read are beyond IO_ISAEND (0x3ff),
> which would explain the result.

Not really.  that's the original ISA I/O space end, probably.  Modern
systems all have ISA I/O ranges of at least, oh, 64k.


> It's the Acer Labs M1543 chip that does all the i/o stuff in my CATS
> machine, and I'm working from the Acer docs.  Also, the register locations
> that the docs state, appear to be standard across IEEE1284 devices, as
> they're wired in to the FreeBSD ppbus stuff, which is what I'm working
> with.

Yeah, yeah, sure, standard parallel port.

though it pretty much always shows up at that address, i'd be very
surprised if the I/O chip actually forced it to be wired to that
address, or forced it to show up at all.  that's usually a
configuration thang set up by BIOS/firmware, rather than anything
else.


> I suppose the question now is: Given that the registers that I want
> are (according to dev/isa/isareg.h) beyond the end of the standard
> ISA address space, how do I access them?

The code you provided should work fine, i'd bet.  (though, obviously,
it's not optimal for the reason described previously.)

This isn't the thing to be worried about, I don't think.


> > > The code that give this is:
> > > 
> > > 	ppc->ppc_sc = malloc(sizeof(struct ppc_softc),M_DEVBUF,M_NOWAIT);
> > 
> > I'm not sure i want to understand what you're doing here....  (it
> > seems ... unlikely to be the right thing.)
> 
> I knew somebody would say that  ;-)  The code needs some temporary space
> to store stuff like iot & ioh whilst it does the rest of the probe and the
> ppc_softc has roughly the right elements...it's free()'d after the
> bus_space_unmap() a little later on.

Not particularly good style, but i doubt it's your problem, so *punt*.


> > FWIW, you probably want two separate mappings for the two
> > non-contiguous register sets.  on ports which do (proper, hell, ANY!)
> > bus space accounting, this code will fall over fairly well.
> 
> I was wondering about this - It didn't seem "right" to have a gap, but I
> couldn't find an obvious example in the tree which had more than one
> region mapped.

There are plenty.  vga driver.  lots of sound card drivers.  i dunno
what else off-hand.


> By fall over, I presume you mean there'll be a panic at some point?
> Rather than returning a duff value?

"fall over" == "the bus_space_map() call will fail," in this case.

What happens then is up to the code calling bus_space_map().


> > Are you sure that the extended registers are:
> > 	* enabled by the hardware (i.e. the port's not running in
> > 	  'stupid' mode or something), and
> 
> AFAICT from the acer docs, the ECR register is always there, and is what
> is needed to engaged ECP mode.  Unless anyone knows otherwise?  (I have to
> confess to not having read every page of the document - it's a big
> chip...)

I suggest reading more of the documentation.  I'd look at it myself if
i had a copy -- doesn't look like Acer Labs' web site gives away their
documentation without authorization.

My guess is that the additional register region has to be enabled with
some BIOS/firmware code, and are _not_ enabled by default.  Most
"super i/o"-ish chips that i'm aware of do this, typically allowing
_all_ of the random I/O devices to be turned on and off via a
non-standard (i.e. chip- or manufacturer-dependent) software method.
Even things like the keyboard or mouse ports/interrupts can often be
turned off and/or reconfigured.

Obviously, i'm not familiar with the chip in question, but many of the
super i/o chips have the same types of capabilities.  reading what
documentation i was able to find on the ALI web site, it looks like
the chip you've got is a reasonably standard bus interface + super I/O
chip.


> > 	* the system places them in the place you're expecting?
> 
> This is something that the Acer docs (obviously) don't comment on and I
> can't find anything in the tree or elsewhere to explain where they would
> turn up.  It might make sense that they don't appear where I'm expecting,
> given what I read in isareg.h.  Does anyone know where they would appear?

Well, in the absence of any other information, they're probably at the
standard locations.

however, reading the product brief on the ALI web site, i notice about
the parallel port:

     Various Mode Parallel Port
     * Supports ECP/ EPP / PS/2 / SPP and 1284 Compliance
     * Standard Mode
     * Programmable 8-bit I/O Base Address
     * Multiplexing of FDC Signals through Parallel Port Pins
     * 12 IRQ Channel Options
     * 4 8-bit DMA Channel Options

note that it's got a programmable base address, etc.  I would expect
that the section of the document that talks about that also explains
which registers actually respond, how you enable any special modes,
etc.


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.