mirror of https://github.com/tLDP/LDP
updated
This commit is contained in:
parent
d946fdc913
commit
6ffd63d796
File diff suppressed because it is too large
Load Diff
|
@ -1,13 +1,14 @@
|
|||
|
||||
<!doctype linuxdoc system>
|
||||
<article>
|
||||
<title> Plug-and-Play-HOWTO </title>
|
||||
<title> Plug-and-Play-HOWTO
|
||||
<author>David S.Lawyer
|
||||
<tt><url url="mailto:dave@lafn.org"></tt>
|
||||
<date> v1.10, August 2004
|
||||
<date> v1.11, November 2004
|
||||
|
||||
<!--
|
||||
Revision history:
|
||||
v1.11 Nov. 2004: LPC bus. Format error (text in contents)
|
||||
v1.10 August 2004: sysfs not yet as useful as claimed, obsolete card info
|
||||
moved to "Historical" section.
|
||||
v1.09 August 2004: Edited per long email from Ross Boylan
|
||||
|
@ -137,13 +138,14 @@ url="http://tldp.org/mirrors.html">. Various formats are
|
|||
available. If you only want to quickly check the date of the latest
|
||||
version look at: <url
|
||||
url="http://tldp.org/HOWTO/Plug-and-Play-HOWTO.html">. The
|
||||
version you are now reading is: v1.10, August 2004 .
|
||||
version you are now reading is: v1.11, November 2004 .
|
||||
|
||||
<sect1> New in Recent Versions
|
||||
<p> For a full revision history going back to the first version see
|
||||
the source file (in linuxdoc format) at <url
|
||||
url="http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/sgml/Plug-and-Play-HOWTO.sgml.gz">
|
||||
|
||||
v1.11 November 2004: LPC bus. Format error (text in contents)
|
||||
v1.10 August 2004: sysfs not yet as useful as claimed, obsolete card info
|
||||
moved to "Historical" section.
|
||||
v1.09 August 2004: Edited per email from Ross Boylan
|
||||
|
@ -155,12 +157,6 @@ abilities of Linux. Added brief info on "hot plug" and USB.<newline>
|
|||
v1.07 August 2003: New M$ url, reserve resources for isa-pnp, lspci+,
|
||||
scanport may not find hdw, finding dev. and config. ISA
|
||||
|
||||
The version 1.0 (Nov. 2000) was long overdue and recognized that the
|
||||
kernel is doing more in helping device drivers set up PnP. Kernel 2.4
|
||||
is significantly improved in this respect. There's still a lot of
|
||||
improvement needed in both this HOWTO and the way that Linux does
|
||||
PnP.
|
||||
|
||||
<sect1> General Introduction. Do you need this HOWTO?
|
||||
<p> Plug-and-play (PnP) is a system which automatically detects
|
||||
devices such as disks, sound cards, ethernet cards, modems, etc. It
|
||||
|
@ -173,17 +169,21 @@ which have not been correctly PnP-configured), can often be detected
|
|||
by non-PnP methods. The modern PCI bus is inherently PnP while the
|
||||
old ISA bus originally wasn't PnP but had PnP support added to it
|
||||
later. So sometimes PnP is used to only mean PnP for the old ISA bus.
|
||||
In this HOWTO, PnP means PnP for both the ISA and the PCI bus.
|
||||
For example, when you see a boot-time message from "isapnp" and it
|
||||
reads: "Plug & Play device" it only means a ISA Plug & Play
|
||||
device. In this HOWTO, PnP means PnP for both the ISA and the PCI
|
||||
bus.
|
||||
|
||||
As time goes by the Linux kernel is became better at supporting PnP.
|
||||
In the 20th century, one could say that Linux was not really a PnP OS.
|
||||
But the claim is made that with version 2.6 of the kernel, Linux is
|
||||
now fully PnP (provided the kernel is built with appropriate PnP
|
||||
support). While the PnP system is not centralized like it is in MS
|
||||
Windows (with its registry) the decentralized Linux PnP seems to work.
|
||||
In the late 20th century, one could say that Linux was not really a
|
||||
PnP OS. But the claim is made that with version 2.6 of the kernel,
|
||||
Linux is now fully PnP (provided the kernel is built with appropriate
|
||||
PnP support). While the PnP system is not centralized like it is in
|
||||
MS Windows (with its registry) the decentralized Linux PnP seems to
|
||||
work.
|
||||
|
||||
Linux does keep track of resource assignments requested by device
|
||||
drivers and refuses any request if it thinks it would cause a
|
||||
drivers and refuses any request if it thinks it would cause a
|
||||
conflict. The kernel also provides programs that device drivers can
|
||||
call on to do their own plug-and-play. The kernel also reads all
|
||||
configuration registers of all PnP devices and maintains tables of
|
||||
|
@ -446,41 +446,41 @@ knows which IRQ line to listen on.
|
|||
Once the device driver gets the interrupt from the device it must find
|
||||
out why the interrupt was issued and take appropriate action to
|
||||
service the interrupt. On the ISA bus, each device usually needs its
|
||||
own unique IRQ number. For the PCI bus and other special case, the
|
||||
sharing of IRQs is allowed and the IRQ assignment is determined by a
|
||||
programmable routing chip. See <ref id="interrupt_detail" name=
|
||||
"Interrupts --Details"> for how this works.
|
||||
own unique IRQ number. For the PCI bus and other special cases, the
|
||||
sharing of IRQs is allowed. Also for PCI the assignment of IRQs to
|
||||
devices is set by a programmable routing chip. See <ref
|
||||
id="interrupt_detail" name= "Interrupts --Details"> for how this
|
||||
works.
|
||||
|
||||
<sect1> DMA Channels (not for PCI bus) <label id="dma_">
|
||||
<p> DMA channels don't exist on the PCI bus but are only for the old
|
||||
ISA bus. DMA stands for "Direct Memory Access". This is where a
|
||||
device is allowed to take over the main computer bus from the CPU and
|
||||
transfer bytes directly to main memory. Normally the CPU would make
|
||||
such a transfer in a two step process:
|
||||
<sect1> DMA (Direct Memory Access) or Bus Mastering <label id="dma_">
|
||||
<p> Direct Memory Access (DMA) is where a device is allowed to take
|
||||
over the main computer bus from the CPU and transfer bytes directly to
|
||||
main memory. Normally the CPU would make such a transfer in a two
|
||||
step process:
|
||||
<enum>
|
||||
<item>reading from the I/O memory space of the device and putting these
|
||||
bytes into the CPU itself
|
||||
<item> writing these bytes from the CPU to main memory
|
||||
</enum>
|
||||
<enum>
|
||||
<item> With DMA it's usually a one step process of sending the bytes
|
||||
directly from the device to memory
|
||||
</enum>
|
||||
The device must have such capabilities built into its hardware and
|
||||
thus not all devices can do DMA. While DMA is going on, the CPU can't
|
||||
do too much since the main bus is being used by the DMA transfer.
|
||||
|
||||
The PCI bus doesn't really have true DMA but instead it has something
|
||||
even better: bus mastering. It works something like DMA and is
|
||||
often called DMA (for example, hard disk drives that call
|
||||
themselves "UltraDMA"). It allows devices to temporarily become bus
|
||||
masters and to transfer bytes almost like the bus master was the CPU.
|
||||
It doesn't use any channel numbers since the organization of the PCI
|
||||
bus is such that the PCI hardware knows which device is currently the
|
||||
bus master and which device is requesting to become a bus master.
|
||||
Thus there is no resource allocation of DMA channels for the PCI bus.
|
||||
With DMA it's a one step process of sending the bytes directly from
|
||||
the device to memory. The device must have DMA capabilities built
|
||||
into its hardware and thus not all devices can do DMA. While DMA is
|
||||
going on, the CPU can't do too much since the main bus is being used
|
||||
by the DMA transfer.
|
||||
|
||||
When a device on the ISA bus wants to do DMA it issues a DMA-request
|
||||
Both the PCI bus and the old ISA bus can do DMA, but for the PCI bus,
|
||||
no DMA resources (channels) are needed. DMA on the PCI bus is
|
||||
actually "bus mastering" but the term "DMA" is widely used for it. It
|
||||
allows devices to temporarily become bus masters and to transfer bytes
|
||||
almost like the bus master was the CPU. It doesn't use any channel
|
||||
numbers since the organization of the PCI bus is such that the PCI
|
||||
hardware knows which device is currently the bus master and which
|
||||
device is requesting to become a bus master. Thus there is no
|
||||
resource allocation of DMA channels for the PCI bus.
|
||||
|
||||
<sect1> DMA Channels (not for PCI bus) <label id="dma_isa">
|
||||
<p>When a device on the ISA bus wants to do DMA it issues a DMA-request
|
||||
using dedicated DMA request wires much like an interrupt request. DMA
|
||||
actually could have been handled by using interrupts but this would
|
||||
introduce some delays so it's faster to do it by having a special type
|
||||
|
@ -488,28 +488,28 @@ of interrupt known as a DMA-request. Like interrupts, DMA-requests
|
|||
are numbered so as to identify which device is making the request.
|
||||
This number is called a DMA-channel. Since DMA transfers all use the
|
||||
main bus (and only one can run at a time) they all actually use the
|
||||
same channel but the "DMA channel" number serves to identify who is
|
||||
using the "channel". Hardware registers exist on the motherboard
|
||||
which store the current status of each "channel". Thus in order to
|
||||
issue a DMA-request, the device must know its DMA-channel number which
|
||||
must be stored in a special register on the physical device.
|
||||
same channel for data flow but the "DMA channel" number serves to
|
||||
identify who is using the "channel". Hardware registers exist on the
|
||||
motherboard which store the current status of each "channel". Thus in
|
||||
order to issue a DMA-request, the device must know its DMA-channel
|
||||
number which must be stored in a special register on the physical
|
||||
device.
|
||||
|
||||
<sect1> "Resources" for both Device and Driver
|
||||
<p> Thus device drivers must be "attached" in some way to the hardware
|
||||
they control. This is done by allocating bus-resources (I/O, Memory,
|
||||
IRQ's, DMA's) to both the physical device and the device driver
|
||||
software. For example, a serial port uses only 2 (out of 4 possible)
|
||||
resources: an IRQ and an I/O address. Both of these values must be
|
||||
supplied to the device driver and the physical device. The driver
|
||||
(and its device) is also given a name in the /dev directory (such as
|
||||
ttyS1). The address and IRQ number is stored by the physical device
|
||||
in configuration registers on its card (or in a chip on the
|
||||
motherboard). For the case of jumpers, it's the location of the
|
||||
jumpers themselves that store the bus-resource configuration in the
|
||||
device hardware (on the card, etc.). For the case of PnP, the
|
||||
configuration register data is usually lost when the PC is powered
|
||||
down (turned off) so that the bus-resource data must be supplied to
|
||||
each device anew each time the PC is powered on.
|
||||
<sect1> "Resources" for both Device and Driver <p> Thus device drivers
|
||||
must be "attached" in some way to the hardware they control. This is
|
||||
done by allocating bus-resources (I/O, Memory, IRQ's, DMA's) to both
|
||||
the physical device and the device driver software. For example, a
|
||||
serial port uses only 2 (out of 4 possible) resources: an IRQ and an
|
||||
I/O address. Both of these values must be supplied to the device
|
||||
driver and the physical device. The driver (and its device) is also
|
||||
given a name in the /dev directory (such as ttyS1). The address and
|
||||
IRQ number is stored by the physical device in configuration registers
|
||||
on its card (or in a chip on the motherboard). For the case of
|
||||
jumpers, it's the location of the jumpers themselves that store the
|
||||
bus-resource configuration in the device hardware (on the card, etc.).
|
||||
For the case of PnP, the configuration register data is usually lost
|
||||
when the PC is powered down (turned off) so that the bus-resource data
|
||||
must be supplied to each device anew each time the PC is powered on.
|
||||
|
||||
<sect1> Resources are Limited
|
||||
<p> The architecture of the PC provides only a limited number of
|
||||
|
@ -837,29 +837,32 @@ in your BIOS's CMOS menu:
|
|||
|
||||
<sect1> Do you have a PnP operating system? <label id="bios_pnp_os">
|
||||
<p> Regardless of how you answer this to the BIOS, the PnP BIOS will
|
||||
PnP-configure the hard-drive, video card, and keyboard to make the
|
||||
system bootable. If you said you had a PnP OS it will leave it up to
|
||||
the operating system (or device drivers) to finish the configuration
|
||||
job. If you said no PnP OS then the BIOS should configure everything.
|
||||
PnP-configure the hard-drive, floppy, video card, and keyboard to make
|
||||
the system bootable. If you said you had a PnP OS it will leave it up
|
||||
to the operating system (or device drivers) to finish the
|
||||
configuration job. If you said no PnP OS then the BIOS should
|
||||
configure everything.
|
||||
|
||||
How should you answer this question to your BIOS? If you have at
|
||||
at least the 2.4 kernel you could answer it either way and Linux
|
||||
should work fine. Even if you have have Windows 2000 or XP on the
|
||||
same PC, it should also work OK either way. This is because both
|
||||
Windows and Linux are now PnP OS's and if the OS is PnP it should be
|
||||
able to also handle the case where the BIOS has configured everything
|
||||
(if you falsely said it wasn't PnP). I suggest saying that it's not
|
||||
a PnP OS unless there is a known reason to say otherwise.
|
||||
will usually work fine. But if Linux can't handle something that the
|
||||
BIOS can (for example, the LPC bus ??), then you should say it's not a
|
||||
PnP OS. Even if you have have Windows 2000 or XP on the same PC, it
|
||||
will usually work OK either way. This is because both Windows and
|
||||
Linux are supposedly PnP OS's and if the OS is PnP it should be able
|
||||
to also handle the case where the BIOS has configured everything (if
|
||||
you said it wasn't PnP). But I still suggest saying that it's not a
|
||||
PnP OS unless there is a known reason to say otherwise.
|
||||
|
||||
<sect2>Linux prior to the 2.4 kernel <label id="prior_2.4">
|
||||
<p>It's not clear whether to say yes or no. If isapnp was used by
|
||||
Linux, then Linux does the configuring and it was claimed that it's best
|
||||
to say it's a PnP OS. Why isapnp would have trouble when presented
|
||||
with devices already configured by the BIOS isn't clear, but such
|
||||
trouble sometimes happened and was fixed by stopping the BIOS from
|
||||
configuring (saying yes, it's a PnP OS). There were a few cases where
|
||||
saying no fixed a problem. So if isapnp is doing it's job OK, you
|
||||
should probably say it's PnP. If isapnp isn't used, no is usually
|
||||
<p>It's not often clear whether to say yes or no. If isapnp was used
|
||||
by Linux, then Linux does the configuring and it was claimed that it's
|
||||
best to say it's a PnP OS. Why isapnp would have trouble when
|
||||
presented with devices already configured by the BIOS isn't clear, but
|
||||
such trouble sometimes happened and was fixed by stopping the BIOS
|
||||
from configuring (saying yes, it's a PnP OS). There were a few cases
|
||||
where saying no fixed a problem. So if isapnp is doing it's job OK,
|
||||
you should probably say it's PnP. If isapnp isn't used, no is usually
|
||||
best. The Linux device drivers for PCI devices should configure PCI
|
||||
devices OK. But for the case of PCI devices driven by non-PCI
|
||||
drivers, then you may say it's not PnP to get the BIOS to configure
|
||||
|
@ -883,7 +886,7 @@ it's registry, Windows will tell you that it's finding new hardware.
|
|||
What it's really doing is finding old hardware that has been
|
||||
configured differently so it thinks it's new hardware. At any rate,
|
||||
it records the configuration that the BIOS has used in its registry
|
||||
and the device should work OK now.
|
||||
and the device should work OK from now on.
|
||||
|
||||
<sect2> MS Windows 95, 98 (and Me ?)
|
||||
<p>For Windows9x, MS suggest that you tell the BIOS that you have a
|
||||
|
@ -1130,8 +1133,8 @@ will not save this configuration in the ESCD. A good PnP OS might
|
|||
update the ESCD so you can use it later on for a non-PnP OS (like
|
||||
standard Linux). MS Windows9x does this only in special cases. See
|
||||
<ref id="W9x_ESCD" name="Using Windows to set ESCD">. Starting with
|
||||
kernel 2.6, Linux is capable of modifying the ESCD but it's not clear
|
||||
how this is being used.
|
||||
kernel 2.6, Linux is capable of modifying the ESCD but it's not used
|
||||
yet (as of Aug. 2004).
|
||||
|
||||
To use what's set in ESCD be sure you've set "Not a PnP OS" or the
|
||||
like in the BIOS's CMOS. Then each time the BIOS starts up (before
|
||||
|
@ -1156,10 +1159,9 @@ which bus-resources have been reserved for use by non-PnP cards. Many
|
|||
BIOSs have both.
|
||||
|
||||
<sect2> Using Windows to set the ESCD <label id="W9x_ESCD">
|
||||
<p>Starting with kernel 2.6, Linux can now set the ESCD. At least a
|
||||
function in the new code can do it provided the kernel has been
|
||||
compiled with PNPBIOS. But I don't know under what (if any)
|
||||
circumstances the kernel actually modifies the ESCD.
|
||||
<p>Eventually the Linux kernel may set the ESCD. Starting with kernel
|
||||
2.6, a function in the new code could do it provided the kernel has
|
||||
been compiled with PNPBIOS. But it currently sits in the code unused.
|
||||
|
||||
If the BIOS doesn't set up the ESCD the way you want it (or the way it
|
||||
should be) then it would be nice to have a Linux utility to set the
|
||||
|
@ -1484,10 +1486,11 @@ probe for the existence of a port. See Serial-HOWTO for more details.
|
|||
<sect1> Some Sound Card Driver Examples (from year 2000)
|
||||
|
||||
|
||||
<sect2> OSS (Open Sound System) and ALSA
|
||||
<p> These will detect the card by PnP methods and then select the
|
||||
<sect2> ALSA (Advanced Linux Sound Architecture)
|
||||
<p> This will detect the card by PnP methods and then select the
|
||||
appropriate driver and load it. It will also set the bus-resources on
|
||||
an ISA-PnP card or PCI card.
|
||||
an ISA-PnP cards or PCI cards. OSS (Open Sound System) was formerly
|
||||
popular.
|
||||
|
||||
<sect>How Do I Find Devices and How Are They Configured? <label
|
||||
id="current_config">
|
||||
|
@ -1545,7 +1548,7 @@ until you either reconfigure the BIOS or change a jumper/switch.
|
|||
Since the PCI bus is inherently PnP, there are no hidden devices.
|
||||
Even though PnP devices are easy to find by PnP methods, if the driver
|
||||
doesn't use PnP methods but uses the old method of probing for them at
|
||||
likely address, they may not be found. This is because that until the
|
||||
likely address, they may not be found. This is because that, until the
|
||||
resources are set in a PnP device (by the BIOS or Linux), the device
|
||||
may have no address at all, so probing at likely address yields
|
||||
nothing. For the old ISA bus, some of the devices may be non-PnP and
|
||||
|
@ -1664,7 +1667,7 @@ The slot may actually be labeled PCI2 inside your PC (2 instead of
|
|||
devices on the motherboard that don't use any physical slots. In this
|
||||
example, "slots" 1-10 would be built-in and actual slots 11-14 are
|
||||
labeled 1-4. By typing "lspci" you'll be able to match the numbers
|
||||
(like 0000:00:12.0) to names (like IDE interface).
|
||||
(like 0000:00:12.0) to names (like IDE interface). Use "lspci -vv
|
||||
|
||||
Well then, what is 00:06 ? It's an ISA card (or built-in device) but
|
||||
it's not ISA slot 6 (like the PCI numbering). When a search was made
|
||||
|
@ -1724,6 +1727,38 @@ can be deciphered. Don't confuse the read-port address which
|
|||
<tt/pnpdump/ uses for communication with PnP cards with the I/O
|
||||
address of the found device. They are not the same.
|
||||
|
||||
<sect1>LPC Bus
|
||||
<p>LPC is a bus-like interface often used on laptops (and on some
|
||||
desktops too). To find out if you have LPC type "lspci" and look
|
||||
for something like: "ISA Bridge ... LPC Interface Controller". You
|
||||
see "ISA Bridge" since the LPC bus might be considered to be in the ISA
|
||||
category of buses but LPC is not ISA.
|
||||
|
||||
The ISA bus was slow and has generally been replaced by the fast PCI
|
||||
bus. But for slow devices, there's no need for a large and fast PCI
|
||||
bus. Thus a small LPC interface was created to be used for slow
|
||||
devices such as serial ports, parallel ports, and floppy drives. It
|
||||
is only 4 bits (half-byte) wide as compared to 32 or 64 bits for the
|
||||
PCI bus. This 4-bit path is shared, and used for data, addresses, and
|
||||
control (it's multiplexed). So it's clear why LPC stands for "Low Pin
|
||||
Count" and why it saves space on motherboards (especially important in
|
||||
laptops). Since LPC operates at about 4 times the clock speed of the
|
||||
old ISA bus its bandwidth is no worse than ISA.
|
||||
|
||||
So a computer using LPC will have all fast devices on the PCI bus,
|
||||
etc. and slow (legacy) devices on the LPC bus interface. All LPC
|
||||
devices will be on-board; there are no LPC slots. Unfortunately, LPC
|
||||
has no standards for Plug-and-Play like PCI and ISA do. So each brand
|
||||
of motherboard may do it somewhat differently. The specs suggests
|
||||
that it be done via ACPI but devices on this bus sometimes use isapnp.
|
||||
So if Linux can't configure resources on it, you hope that the BIOS
|
||||
can (tell the BIOS it's a non-PnP OS). Linux support for LPC as of
|
||||
late 2004 was very much incomplete.
|
||||
|
||||
A major chip on the LPC bus is the superio chip which contains legacy
|
||||
devices: serial and parallel ports, floppy controller, keyboard
|
||||
controller, etc. BIOS data may also be on the LPC bus.
|
||||
|
||||
<sect1>Non-PnP Cards <label id="non_pnp">
|
||||
<p>In contrast to PnP cards, non-PnP cards always have their resources
|
||||
set in the hardware. That is they always have an address and IRQ
|
||||
|
@ -2009,7 +2044,8 @@ determine this read-port address.
|
|||
devices to initiate communication besides sending out an interrupt.
|
||||
This method is a DMA (Direct Memory Access) request to take control of
|
||||
the computer from the CPU for a limited amount of time. On the PCI
|
||||
bus, it uses no "resources". See <ref id="dma_" name="DMA Channels">.
|
||||
bus, it uses no "resources". Not all devices are capable of doing
|
||||
DMA. See <ref id="dma_" name="DMA Channels">.
|
||||
|
||||
<sect2>Soft interrupts
|
||||
<p>There's also another type of interrupt known as a "soft interrupt"
|
||||
|
@ -2025,8 +2061,7 @@ kind of interrupt for dealing with device drivers. The device driver
|
|||
starts running due to a hardware interrupt but later on, software
|
||||
interrupts are used for the "bottom half" of the driver's interrupt
|
||||
service routine. Thus, the ksoftirq process is also known as
|
||||
"bottom-half". For more details see kernel documentation.
|
||||
|
||||
"bottom-half". For more details see the kernel documentation.
|
||||
|
||||
<sect2>Hardware interrupts
|
||||
<p>Interrupts convey a lot of information but only indirectly. The
|
||||
|
@ -2093,7 +2128,7 @@ Normally, for example, IRQ5 may be shared between two PCI devices.
|
|||
This sharing ability is built into the hardware and all device drivers
|
||||
are supposed to support it. Note that you can't share the same
|
||||
interrupt between the PCI and ISA bus. However, illegal sharing will
|
||||
work provided only one of the devices which are in conflict, is in use
|
||||
work provided only one of the two conflicting devices is in use
|
||||
at any given time. "In use" here means that a program has "opened"
|
||||
the device (and hasn't "closed" it) in its C programming code, even
|
||||
though such a program could be temporarily sleeping, etc.
|
||||
|
@ -2122,8 +2157,8 @@ it needs two interrupts, it must use both A and B, etc. Thus INTA# is
|
|||
used much more often than INTD#. So one winds up with an excessive
|
||||
number of interrupts sharing the first line (W connected to all the
|
||||
INTA#). To overcome this problem one may connect them in a more
|
||||
complicated way so that each of the 4 interrupt lines (W, X, Y, Z)
|
||||
will share about the same number of actual PCI interrupts.
|
||||
random way so that each of the 4 interrupt lines (W, X, Y, Z) will
|
||||
share about the same number of actual PCI interrupts.
|
||||
|
||||
One method of doing this would be to have wire W share interrupts 1A,
|
||||
2B, 3C, 4D, 5A, 6B, 7C. This is done by physically connecting wire W
|
||||
|
@ -2135,6 +2170,12 @@ program interrogating this register can find out what IRQ the device
|
|||
uses. Note that just writing the IRQ in a register on a PCI card
|
||||
doesn't in any way set the IRQ for that device.
|
||||
|
||||
A practical use for the above is that, as a last resort, one may change
|
||||
the IRQs of a PCI card by inserting it in a different slot. In the
|
||||
above example, INTA# of a PCI card will be connected to wire W if the
|
||||
card is inserted into slot 1 (1A maps to W) but INTA# will be
|
||||
connected to wire X if it's inserted into slot 4 (4A maps to X).
|
||||
|
||||
A card in a slot may have up to 8 devices on it but there are only 4
|
||||
PCI interrupts for it (A, B, C, D). This is OK since interrupts may
|
||||
be shared so that each of the 8 devices (if they exist) can have an
|
||||
|
@ -2161,11 +2202,11 @@ Windows 2000 and XP doesn't change what the BIOS has set, but it may
|
|||
add a new device (with a new IRQ).
|
||||
|
||||
You might think that since the PCI is using IRQs (designed for the ISA
|
||||
bus) it might be slow since the ISA bus is slow. Not really. The ISA
|
||||
bus) it might be slow since the ISA bus was slow. Not really. The ISA
|
||||
Interrupt Controller Chip(s) has a direct interrupt wire going to the
|
||||
CPU so it can get immediate attention. While signals on the ISA
|
||||
address and data buses may be slow to get to the CPU, the IRQ
|
||||
interrupt signals get there very fast.
|
||||
CPU so it can get immediate attention. While signals on the old ISA
|
||||
address and data buses are slow to get to the CPU, the IRQ interrupt
|
||||
signals get there very fast.
|
||||
|
||||
<sect1> ISA Isolation <label id="isolation_">
|
||||
<p> This is only for the old ISA bus. Isolation is a complex method
|
||||
|
@ -2255,6 +2296,13 @@ automatically detected. RedHat supplies a program "sndconfig" which
|
|||
detects ISA PnP sound cards and automatically sets up the modules for
|
||||
loading with the detected bus-resources.
|
||||
|
||||
<sect2>MS Windows Notes
|
||||
<p>Windows NT4 didn't support ISAPNP but had a PNPISA program which one
|
||||
could "use at your own risk". For NT4 users were advised to set "not
|
||||
a PnP OS" in the BIOS so that the BIOS would do the resource
|
||||
configuring. Thus both MS Windows and Linux were in olden days
|
||||
dependent on the BIOS doing the configuring.
|
||||
|
||||
END OF Plug-and-Play-HOWTO
|
||||
</article>
|
||||
|
||||
|
|
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue