Messages in this thread | | | Date | Fri, 18 Dec 1998 08:51:11 +0100 | From | Kurt Garloff <> | Subject | Re: proper ioport space allocation |
| |
On Thu, Dec 17, 1998 at 06:04:12PM -0600, Bob McElrath wrote: > On Thu, 17 Dec 1998, Kurt Garloff wrote: > I think you're right. Each of the 2-bit ranges seems to have a specific > function. For instance, Mixer functions are at 0x788 (+4), PCM control is > at 0xF88 (+4). It couldn't distinguish 0x788 from 0x388 unless it decoded > all 16 bits. So it actually *uses* all the higher harmonics. I suspect > that harmonics that don't have definitions in my developer's kit might map > to ports on the board's ASIC, and have some (undocumented) function, and > thus it would be bad if another driver/app tried to use them.
OK. I really didn't expect the PAS to use all these aliases.
> > In any case, I would only register one address and not all the aliases. > > Why? It seems to me that the only way to avoid conflict of devices is to > register *all* the harmonics. Perhaps the holder of /proc/ioports > information (whatever it is...) should define a 0x400+ harmonic method of > allocation, so that you don't have to individually register each harmonic, > and so that the output of /proc/ioports is less than 50 pages.
Well, you are right. If the aliasese/harmonics are used, they should be registered. I originally thought they were only registered to prevent conflicts with 10bits ISA cards. This would have been useless.
> Does anyone know if the PCI-ISA bridge blocks addresses with something other > than zero in the high word from reaching the ISA devices? (I assume PCI I/O > ports are 32-bits)
PCI I/O is 32 bits (or even 64 on some architectures) and I think all addresses are forwarded to PCI bus, but the ones with the high word == 0 also to ISA. Maybe there are optimizations to prevent the low addresses to be seen (and block?) the PCI bus ... I don't know.
Regards, -- Kurt Garloff <K.Garloff@ping.de> (Dortmund, FRG) PGP key on http://student.physik.uni-dortmund.de/homepages/garloff
There is something frustrating about the quality and speed of Linux development. I.e. the quality is too high and the speed is too high, in other words, I can implement this XXXX feature, but I bet someone else has already done it and is just about to release his patch to Linus soon... [From a posting of Tigran Aivazian to linux-kernel, XXXX = disk stat]
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |