This commit is contained in:
gferg 2004-11-16 16:36:13 +00:00
parent d946fdc913
commit 6ffd63d796
3 changed files with 1037 additions and 782 deletions

File diff suppressed because it is too large Load Diff

View File

@ -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 &amp Play device" it only means a ISA Plug &amp 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