ACPI and the PNP Layer
Quoted 7 lines
From: Matthew Wilcox <[email protected]>
To: Dino Klein <[email protected]>
CC: [email protected]
Subject: Re: [ACPI] ACPI and the PNP Layer
Date: Sun, 1 Feb 2004 01:43:17 +0000On Sun, Feb 01, 2004 at 12:28:27AM +0000, Dino Klein wrote:
Quoted 8 lines
Quoted 1 line
I am curious to know whether there is supposed to be a relationship
between
Quoted 1 line
ACPI and the PNP layer in Linux, i.e. should the devices found through
ACPI
Quoted 2 lines
be registered with the PNP layer, or will the PNP layer itself be supplanted on ACPI based machines?
PNP is unnecessary on machines with ACPI.
When you say PNP, are you refering to PNPBIOS/ISAPNP, or the Linux PNP Layer iself, which uses the previous two as PNP protocols?
Quoted 10 lines
Quoted 5 lines
The reason I'm asking is because I'm toying with the idea of writing a protocol driver that will "export" devices from ACPI to the PNP layer. Would this be a more "proper" scheme of dealing with devices, instead of having each driver modified to register with the ACPI bus (serial driver style)? Wouldn't placing devices in the PNP layer make it more
transparent
Quoted 1 line
for drivers to bind to devices, whether the machine supports ACPI, or
only
Quoted 1 line
PNPBIOS?
Quoted 8 lines
I think there's a fundamental mistake here, which is that drivers need to be modified to deal with ACPI. The serial driver (I'm the original author of the 8250_acpi code) needed to be modified to discover serial devices in the ACPI namespace. This is because HP's ia64 machines are legacy-free, so do not have serial ports at
0x3f8and0x2f8(or wherever ...) like PCs. Some of HP's machines have PCI serial ports which need no additional code, but others have what are called 'PDH UARTs' which can only be discovered by looking in the ACPI namespace.
You're saying this under the assumption that everything will go USB/PCI/etc in the future, right?
Quoted 4 lines
Obviously no ia64 machine will support ISAPNP or PNPBIOS, so your proposal wouldn't work very well. It's also not a lot of code -- 4934 bytes for
8250_acpi.cversus 12488 bytes for8250_pnp.c. I can't think of any other "legacy devices in non-legacy positions" situations like this. Can you?
I took a quick look at the two files, and they are quite comparable code-wise; the additional size in 8250_pnp.c is due to the extra comments and EISA IDs defined.
Now about the legacy devices - wouldn't you say that the keyboard/PS2 driver should be modified to register with the ACPI bus, just in order to have everything nice & neat? or how about the parallel port, or motherboard based IRDA (PNP0510)? Perhaps I'm just exaggerating with this, but I like to have things nice and neat :)
_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
A message that is not in the archive (sent off-list or not yet received): Law11-F969ScIXWOReP0000022f-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org
Quoted 4 lines · Dino Klein
Quoted 1 line
PNP is unnecessary on machines with ACPI.
When you say PNP, are you refering to PNPBIOS/ISAPNP, or the Linux PNP Layer iself, which uses the previous two as PNP protocols?
The former.
Quoted 11 lines
Quoted 8 lines
I think there's a fundamental mistake here, which is that drivers need to be modified to deal with ACPI. The serial driver (I'm the original author of the 8250_acpi code) needed to be modified to discover serial devices in the ACPI namespace. This is because HP's ia64 machines are legacy-free, so do not have serial ports at
0x3f8and0x2f8(or wherever ...) like PCs. Some of HP's machines have PCI serial ports which need no additional code, but others have what are called 'PDH UARTs' which can only be discovered by looking in the ACPI namespace.You're saying this under the assumption that everything will go USB/PCI/etc in the future, right?
Correct. They're cheaper and simpler than the alternatives, so once support is sufficiently widespread, I would indeed expect the legacy support to go away.
Quoted 5 lines
Quoted 4 lines
Obviously no ia64 machine will support ISAPNP or PNPBIOS, so your proposal wouldn't work very well. It's also not a lot of code -- 4934 bytes for
8250_acpi.cversus 12488 bytes for8250_pnp.c. I can't think of any other "legacy devices in non-legacy positions" situations like this. Can you?
Quoted 9 lines
I took a quick look at the two files, and they are quite comparable code-wise; the additional size in
8250_pnp.cis due to the extra comments and EISA IDs defined.
Now about the legacy devices - wouldn't you say that the keyboard/PS2 driver should be modified to register with the ACPI bus, just in order to have everything nice & neat? or how about the parallel port, or motherboard based IRDA (PNP0510)?
Perhaps I'm just exaggerating with this, but I like to have things nice and neat :)
PS/2 is obsoleted by USB, as is parallel. I don't know abut IRDA but I would expect it to show up as a PCI device normally. Are manufacturers still making machines which have this as a non-PCI device? Remember just because it's on the motherboard doesn't mean it's a non-PCI device.
Using the PNP layer on non-x86 would certainly lead to problems today. For example:
/* check if the resource is valid */
if (*irq < 0 || *irq > 15)
return 0;I can't see this proposal being a good idea today. Perhaps if the PNP layer were cleaned up it would be. That'd be a good place to direct your efforts. For example, could drivers/pnp/resource.c use more of the facilities in kernel/resource.c? Should some of the features from pnp/resource.c be moved to kernel/resource.c? Are there other places in the tree that could make use of the features in pnp/resource.c if they were generally available? I've had good luck in the past answering questions ike this.
Signature · 13 lines
"Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn
A message that is not in the archive (sent off-list or not yet received): 20040201172447.GV18725-+pPCBgu9SkPzIGdyhVEDUDl5KyyQGfY2kSSpQ9I8OhVaa/[email protected]
Quoted 11 lines · Matthew Wilcox
Quoted 9 lines · Dino Klein
I took a quick look at the two files, and they are quite comparable code-wise; the additional size in
8250_pnp.cis due to the extra comments and EISA IDs defined.
Now about the legacy devices - wouldn't you say that the keyboard/PS2 driver should be modified to register with the ACPI bus, just in order to have everything nice & neat? or how about the parallel port, or motherboard based IRDA (PNP0510)?
Perhaps I'm just exaggerating with this, but I like to have things nice and neat :)
Quoted 4 lines
PS/2 is obsoleted by USB, as is parallel. I don't know abut IRDA but I would expect it to show up as a PCI device normally. Are manufacturers still making machines which have this as a non-PCI device? Remember just because it's on the motherboard doesn't mean it's a non-PCI device.
Compare the output of acpidump and the datasheet for a Super I/O chip some time. Everything on the LPCB is legacy and is thus probed through ACPI, not PCI. IRDA is almost always on the Super I/O.
http://www.via.com.tw/en/Products/superIO.jsp
-Nate
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn