Messages in this thread |  | | | Date | Tue, 3 Jun 1997 16:07:49 +0200 (METDST) | | From | Gabriel Paubert <> | | Subject | Re: Question about outb |
| |
On Fri, 30 May 1997, Davide Rossetti wrote:
> > > 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.
|  |