Re: proper ioport space allocation

Kurt Garloff (garloff@kg1.ping.de)
Fri, 18 Dec 1998 08:51:11 +0100


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/