ACPI and the PNP Layer

Hello everyone,
I am curious to know whether there is supposed to be a relationship between 
ACPI and the PNP layer in Linux, i.e. should the devices found through ACPI 
be registered with the PNP layer, or will the PNP layer itself be supplanted 
on ACPI based machines?

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 for 
drivers to bind to devices, whether the machine supports ACPI, or only 
PNPBIOS?

Thanks.

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

-------------------------------------------------------
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

Re: ACPI and the PNP Layer

On Sun, Feb 01, 2004 at 12:28:27AM +0000, Dino Klein wrote:
> I am curious to know whether there is supposed to be a relationship between 
> ACPI and the PNP layer in Linux, i.e. should the devices found through ACPI 
> 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.

> 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 
> for drivers to bind to devices, whether the machine supports ACPI, or only 
> PNPBIOS?

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 0x3f8 and 0x2f8 (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.

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.c versus 12488 bytes for 8250_pnp.c.  I can't think of any other
"legacy devices in non-legacy positions" situations like this.  Can you?

Re: ACPI and the PNP Layer

>From: Matthew Wilcox <willy@...>
>To: Dino Klein <dinoklein@...>
>CC: acpi-devel@...
>Subject: Re: [ACPI] ACPI and the PNP Layer
>Date: Sun, 1 Feb 2004 01:43:17 +0000
>
>On Sun, Feb 01, 2004 at 12:28:27AM +0000, Dino Klein wrote:
> > I am curious to know whether there is supposed to be a relationship 
>between
> > ACPI and the PNP layer in Linux, i.e. should the devices found through 
>ACPI
> > 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?

> > 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
> > for drivers to bind to devices, whether the machine supports ACPI, or 
>only
> > PNPBIOS?
>
>I think there's a fundamental mistake here, which is that drivers need

dsdt patch

Hi,

Just want to ask where can I find a patch that will allow me to use my 
own dsdt for kernel 2.4.24? Is there such a patch flying around or is 
the kernel itself patched to allow implementation of custom dsdt table?
I am sorry if this is the wrong place to ask such a question but I could 
not find a mailing list for dsdt itself. I would very much appreciate if 
someone can point me to the right direction.
Thanks heaps.

Alimin

-------------------------------------------------------
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

system crashes after cat /proc/acpi/battery/BAT0/state

Hi,

after

cat /proc/acpi/battery/BAT0/state

the system print out battery informations but after 5 seconds the system 
crashs
completely.
I can't find any error messages in /var/log/messages which helps me
understanding whats going on.

Anyone any idea, what's going on? Or what can I do, to get any helpfull
hints?

I am using kernel 2.6.0 Debian/sid.

cat /proc/acpi/info
version:                 20031002

cat /proc/acpi/battery/BAT0/info

present:                 yes
design capacity:         3876 mAh
last full capacity:      3876 mAh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 388 mAh
design capacity low:     0 mAh
capacity granularity 1:  100 mAh

Returned mail

--- The message cannot be delivered to the following address. ---

claudia@...    Mailbox unknown or not accepting mail.
550 5.1.1 <claudia@...>... User unknown

From: --- The message cannot be delivered to the following address. --- claudia@... Mailbox unknown or not accepting mail. 550 5.1.1 <claudia@...>... User unknown <acpi-devel@...>
Subject: Hello
Date: 2004-02-01 11:37:18 GMT

�7� �ԡJc���m��q�߂uSb��Y��:Mi��*L#)O������fw��x�d�mɥ�(��z�i{)��`R
�M�yđ�l�hS��4_T�A�"��;V!1��TS�����f�W]-���x[氞hpԡ�3��k�j|؂�C���
�ˋ��J
���$*Y���4��S���3��ͳl�',���
����!�J[��#OV�5��8X^� �hڡ��x�f����B��GC��1�6Y�{P7��� ���G�mjW�v���*s9�.[G�zv��4E�M`2r�]I�A̺��c���a�%�]y�LB
�ZZS��X�f�j_kG������2#c,xBk��;����~�q R���>KC"I������c��0
������3ߘ�$R1�ֶ�q�$7(�Ǧ?��Zh�ǔ�K.̓׷�-����ĝ����s��'8�c�B~Q�Q�9d
���m��K�{8ϲ�<j��Q"l6�����a�erX�� �
,�Q�O�CDT��qCW���c��u1�k��%��{��o]�~&����*�1�B��F�*L�� �-�4�a�&�H���Ւ�x$�ˆ^a�

system crashes after cat /proc/acpi/battery/BAT0/state

Hi,

excuse me, but I forgot to tell, that I'm using the ACPI DSDT initrd 
patch and a special DSDT-file for Compaq Evo N800v (while I have an
Compaq Evo N800c)

Hi,

after

cat /proc/acpi/battery/BAT0/state

the system print out battery informations but after 5 seconds the system
crashs
completely.
I can't find any error messages in /var/log/messages which helps me
understanding whats going on.

Anyone any idea, what's going on? Or what can I do, to get any helpfull
hints?

I am using kernel 2.6.0 Debian/sid.

cat /proc/acpi/info
version:                 20031002

cat /proc/acpi/battery/BAT0/info

present:                 yes
design capacity:         3876 mAh

Re: ACPI and the PNP Layer

On Sun, Feb 01, 2004 at 02:41:02AM +0000, Dino Klein wrote:
> >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.

> >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 0x3f8 and 0x2f8 (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.

> >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.c versus 12488 bytes for 8250_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 

FW: ACPI breakage in 2.6.2-rc3 (and before)

Forwarding potential degradation in 2.6.2-rc3.

Jun
-----Original Message-----
From: linux-kernel-owner@...
[mailto:linux-kernel-owner@...] On Behalf Of Joseph Pingenot
Sent: Sunday, February 01, 2004 12:20 PM
To: Linus Torvalds
Cc: Kernel Mailing List
Subject: ACPI breakage in 2.6.2-rc3 (and before)
Importance: High

From Linus Torvalds on Friday, 30 January, 2004:
>The bulk of this is an ACPI update, but there's USB, ia-64, i2c, XFS
and 
>PCI hotplug updates here too.
>Please don't send in anything but critical fixes until after the final 
>2.6.2 release.

Hmm.  I just tried 2.6.2-rc3 (after having tried 2.6.1 after having
  tried 2.6.2-rc2-mm1), and I note that ACPI can get my battery
  status in 2.6.1, but *not* in 2.6.2-rc2-mm1 or in 2.6.2-rc3.
  It notes that there is a battery in one of the two bays, and
  that it's on battery or AC power, but nothing more; all status
  readouts say that the battery's drained.

System is a Dell Inspiron 8600.

Thanks!

Re: FW: ACPI breakage in 2.6.2-rc3 (and before)

Hello,

on 02/01/04 19:27, Nakajima, Jun wrote:
> Forwarding potential degradation in 2.6.2-rc3.
<cut>
> -----Original Message-----
<cut>
> Hmm.  I just tried 2.6.2-rc3 (after having tried 2.6.1 after having
>   tried 2.6.2-rc2-mm1), and I note that ACPI can get my battery
>   status in 2.6.1, but *not* in 2.6.2-rc2-mm1 or in 2.6.2-rc3.
>   It notes that there is a battery in one of the two bays, and
>   that it's on battery or AC power, but nothing more; all status
>   readouts say that the battery's drained.
just as a report, no problem here on an ASUS M3410C (M3N):

2.6.1 + ACPI 20031203
gismo:~# cat /proc/acpi/battery/BAT0/info
present:                 yes
design capacity:         64500 mWh
last full capacity:      59970 mWh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 6450 mWh
design capacity low:     3225 mWh
capacity granularity 1:  645 mWh
capacity granularity 2:  645 mWh
model number:            M3N
serial number:
battery type:            LIon