> > > The card I'm writing the driver for puts its real
> > > registers out of the range accessable by a short. Here's relavent part
> > > of the <cat /proc/ioports>:
> > >
> > > efbdc000-efbddffe: ihcp
> > >
> > > That REALLY is the IO space for the card's registers. Am I missing
> > > something?
> >
> > This looks to me like a memory-mapped I/O region. The ISDN driver
> > does this too, but they _know_ this is "wrong" and comment it.
> > The problem being no support for requesting regions of the address
> > space. This isn't a huge problem in this case, since the address
> > is above the legal ix86 I/O region.
>
> I don't know if it is a PCI board. Assuming so.
> Perhaps onboard formaware does not properly initialize bit x (1 ?, I
> don't remember) of the configuration space register, which asks I/O space
> under 1MB to power-on bios. so it is configured somewhere in full 32bit
> address space. you can always over-write it.
>
>Davide,
> Here's what the techsheet on the card says about what they call the PCI
>base address register:
> The bit that controls where the register maps into is set to 0 (memory
>space) and is NOT writable.
> The bits that control the location fo the register are set to 00 (locate
>anywhere in 32 bit address space) and also are NOT writable.
>
>This seems to tell me that I'm pretty well screwed on this... I'm in just
>a little over my head anyways...
>Pat
Let us try to clarify this, the board is not in the PCI I/O space but in
the memory space (since bit 0 is 0). What appears when cat'ing
/proc/ioports means that the driver calls request_region with invalid
parameters (for x86). This function should not be called in your case.
Memory space is accessed with normal instructions (not in/out) and can be
accessed under Linux with readb/writeb and friends. I remember vaguely
that the new configuration manager has something also to request/release
memory mapped I/O regions (well I'm sure I've seen something posted about
this which gives symmetry between I/O spaces and memory mapped I/O but I
don't remember when).
In any case the correct way to access this space is to vremap (2.0.xx) or
ioremap (2.1.xx) 8 kB (two pages since it seems to be what your card
requires):
device_ptr=vremap(0xefbdc000,8192); /* 2.0.xx */
or
device_pre=ioremap(0xefbdc000,8192); /* 2.1.xx */
your device_ptr can then be used with readb/writeb. You can also declare
it as a pointer to a volatile structure describing your device.
CAUTION: This will work on an x86 but not on an Alpha or PPC, for which
you would have to add to the first parameter the offset from which the PCI
bus is seen from the processor (if I have understood the code).
Neither vremap nor ioremap do not explicitly disable the cache (set the
PCD bit in the PTE), although caching is disabled when you use mmap on
/dev/kmem (used by XFree86). I don't think it's a major problem since
most boards will not assert the cache enable pins of the processor when
accessing the PCI bridge, or the MTRRs will be hopefully correctly set on
PPro.
You might also want to use ioremap_nocache instead of ioremap but this
function is defined only for x86. And no driver actually uses it (as of
2.1.39).
Gabriel.