RE: ACPI C4 support

RE: ACPI C4 support

[Grover, Andrew]

> From: Pavel Machek [mailto:pavel-AlSwsSmVLrQ@public.gmane.org] 
> If there is old BIOS guide telling them to use length of 7, could we
> make Linux accept that? Its likely a lot of developers have read
> that...
> 
> Allowing length of 7 is one line change; if we do it, such notebooks
> will be able to use C1..C3, but not C4. That does not seem too bad...

I would favor being a little more demanding before adding a hack. This
could be EASILY fixed by a BIOS update, now that the BIOS developer
knows it is wrong. If this is a common BIOS error then maybe that
changes things.

BTW, hey wasn't someone going to implement _CST support? FreeBSD already
has this, we're behind*! ;-)

Regards -- Andy

* not that any systems use it yet, but it's coming


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click

Re: ACPI C4 support

[Bruno Ducrot]

On Mon, Mar 01, 2004 at 01:26:09PM -0800, Grover, Andrew wrote:
> > From: Pavel Machek [mailto:pavel-AlSwsSmVLrQ@public.gmane.org] 
> > If there is old BIOS guide telling them to use length of 7, could we
> > make Linux accept that? Its likely a lot of developers have read
> > that...
> > 
> > Allowing length of 7 is one line change; if we do it, such notebooks
> > will be able to use C1..C3, but not C4. That does not seem too bad...
> 
> I would favor being a little more demanding before adding a hack. This
> could be EASILY fixed by a BIOS update, now that the BIOS developer
> knows it is wrong. If this is a common BIOS error then maybe that
> changes things.
> 
> BTW, hey wasn't someone going to implement _CST support? FreeBSD already
> has this, we're behind*! ;-)
> 
> Regards -- Andy
> 
> * not that any systems use it yet, but it's coming

http://bugzilla.kernel.org/show_bug.cgi?id=1958

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

RE: ACPI C4 support

[Grover, Andrew]

> [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
> Stefan Behlert
> > No.  pblk_length is 0 or 6.  Not 5 nor 7 ;)
> 
> Sorry, I don't understand: We've a Laptop with a DSDT with
>   Processor (\_PR.CPU0, 0x01, 0x00001010, 0x07)
> in it.
> Comment from the responsible BIOS-team:
> "Our processor block object is 7 bytes in length because we 
> also support
>  C4 (P_LVL4) which is at <P_BLK>+6.  Therefore, the 
> size/length must be
>  reported as 7 and not 6."
> 
> Is the '7' the BIOS-developer mentioned the same '7' as 
> mentioned by you?

This is wrong.

There is confusion here because what older systems do on C3 is different
from what more recent systems do on C3, at the electrical level. I know
at least internally the improved C3-like state was called "C4" but to
the OS it just looks just like C3, and the value for C4 should go in
P_LVL3. P_BLK length should remain 6.

The only way to get more than C1, C2, and C3 is via the _CST object.

Please tell the BIOS developer this. I have an old BIOS developers guide
version that agrees with them but I just asked the experts internally
and they said no.

Thanks -- Regards -- Andy


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click

Re: ACPI C4 support

[Pavel Machek]

Hi!

> > [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
> > Stefan Behlert
> > > No.  pblk_length is 0 or 6.  Not 5 nor 7 ;)
> > 
> > Sorry, I don't understand: We've a Laptop with a DSDT with
> >   Processor (\_PR.CPU0, 0x01, 0x00001010, 0x07)
> > in it.
> > Comment from the responsible BIOS-team:
> > "Our processor block object is 7 bytes in length because we 
> > also support
> >  C4 (P_LVL4) which is at <P_BLK>+6.  Therefore, the 
> > size/length must be
> >  reported as 7 and not 6."
> > 
> > Is the '7' the BIOS-developer mentioned the same '7' as 
> > mentioned by you?
> 
> This is wrong.
> 
> There is confusion here because what older systems do on C3 is different
> from what more recent systems do on C3, at the electrical level. I know
> at least internally the improved C3-like state was called "C4" but to
> the OS it just looks just like C3, and the value for C4 should go in
> P_LVL3. P_BLK length should remain 6.
> 
> The only way to get more than C1, C2, and C3 is via the _CST object.
> 
> Please tell the BIOS developer this. I have an old BIOS developers guide
> version that agrees with them but I just asked the experts internally
> and they said no.

Is updated verision of BIOS developers guide available somewhere?

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: ACPI C4 support

[Pavel Machek]

Hi!

> > [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
> > Stefan Behlert
> > > No.  pblk_length is 0 or 6.  Not 5 nor 7 ;)
> > 
> > Sorry, I don't understand: We've a Laptop with a DSDT with
> >   Processor (\_PR.CPU0, 0x01, 0x00001010, 0x07)
> > in it.
> > Comment from the responsible BIOS-team:
> > "Our processor block object is 7 bytes in length because we 
> > also support
> >  C4 (P_LVL4) which is at <P_BLK>+6.  Therefore, the 
> > size/length must be
> >  reported as 7 and not 6."
> > 
> > Is the '7' the BIOS-developer mentioned the same '7' as 
> > mentioned by you?
> 
> This is wrong.
> 
> There is confusion here because what older systems do on C3 is different
> from what more recent systems do on C3, at the electrical level. I know
> at least internally the improved C3-like state was called "C4" but to
> the OS it just looks just like C3, and the value for C4 should go in
> P_LVL3. P_BLK length should remain 6.
> 
> The only way to get more than C1, C2, and C3 is via the _CST object.
> 
> Please tell the BIOS developer this. I have an old BIOS developers guide
> version that agrees with them but I just asked the experts internally
> and they said no.

If there is old BIOS guide telling them to use length of 7, could we
make Linux accept that? Its likely a lot of developers have read
that...

Allowing length of 7 is one line change; if we do it, such notebooks
will be able to use C1..C3, but not C4. That does not seem too bad...

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: ACPI C4 support

[Bruno Ducrot]

On Mon, Mar 01, 2004 at 08:27:38PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
> > > Stefan Behlert
> > > > No.  pblk_length is 0 or 6.  Not 5 nor 7 ;)
> > > 
> > > Sorry, I don't understand: We've a Laptop with a DSDT with
> > >   Processor (\_PR.CPU0, 0x01, 0x00001010, 0x07)
> > > in it.
> > > Comment from the responsible BIOS-team:
> > > "Our processor block object is 7 bytes in length because we 
> > > also support
> > >  C4 (P_LVL4) which is at <P_BLK>+6.  Therefore, the 
> > > size/length must be
> > >  reported as 7 and not 6."
> > > 
> > > Is the '7' the BIOS-developer mentioned the same '7' as 
> > > mentioned by you?
> > 
> > This is wrong.
> > 
> > There is confusion here because what older systems do on C3 is different
> > from what more recent systems do on C3, at the electrical level. I know
> > at least internally the improved C3-like state was called "C4" but to
> > the OS it just looks just like C3, and the value for C4 should go in
> > P_LVL3. P_BLK length should remain 6.
> > 
> > The only way to get more than C1, C2, and C3 is via the _CST object.
> > 
> > Please tell the BIOS developer this. I have an old BIOS developers guide
> > version that agrees with them but I just asked the experts internally
> > and they said no.
> 
> If there is old BIOS guide telling them to use length of 7, could we
> make Linux accept that? Its likely a lot of developers have read
> that...
> 
> Allowing length of 7 is one line change; if we do it, such notebooks
> will be able to use C1..C3, but not C4. That does not seem too bad...
> 

The problem is that, from strict acpi point of view, it will be too easy
to allow '7', and _CST support is much better.  Don't ask me why, I'm not
an expert.  So perhaps it may be possible to add the (bahh, beurk)
length of 7 if there exist a bad written bios developper guide released
apparently by Intel, at least as a non pedantic acpi option?

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: ACPI C4 support

[Stefan Seyfried]

On Mon, Mar 01, 2004 at 08:39:17PM +0100, Bruno Ducrot wrote:
 
> > If there is old BIOS guide telling them to use length of 7, could we
> > make Linux accept that? Its likely a lot of developers have read
> > that...

Even non-intel developers. I have a ASUS L2400d, apparently intel-free
(maybe this is why all the ACPI suspend stuff works reasonably well ;-))
which has also the infamous "7" and so only supports C1.

> > Allowing length of 7 is one line change; if we do it, such notebooks
> > will be able to use C1..C3, but not C4. That does not seem too bad...
 
> The problem is that, from strict acpi point of view, it will be too easy
> to allow '7', and _CST support is much better.  Don't ask me why, I'm not
> an expert.  So perhaps it may be possible to add the (bahh, beurk)
> length of 7 if there exist a bad written bios developper guide released
> apparently by Intel, at least as a non pedantic acpi option?

Yes, please!
-- 
Stefan Seyfried



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

ACPI C4 support

[Pavel Machek]

Hi!

Thomas told me:

>what about C4 - Cn states in the kernel implementation?
>A short look into the /proc/acpi/processor/.../power file let me think
>that only C0-C3 is supported by the kernel, even specification talks
>about Cn states?

As a first step, it would be nice if kernel at least used C0..C3 if
the machine supports them... This should do the trick. Does it look
okay?

								Pavel

--- tmp/linux/drivers/acpi/processor.c	2004-02-20 12:29:21.000000000 +0100
+++ linux/drivers/acpi/processor.c	2004-02-28 15:30:52.000000000 +0100
@@ -2205,7 +2202,8 @@
 
 	if (!object.processor.pblk_address)
 		ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL address)\n"));
-	else if (object.processor.pblk_length != 6)
+	else if (object.processor.pblk_length < 6)
+		/* pblk_length of 7 is okay if cpu supports C4 */
 		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid PBLK length [%d]\n",
 			object.processor.pblk_length));
 	else {




-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: ACPI C4 support

[Bruno Ducrot]

On Sat, Feb 28, 2004 at 05:10:11PM +0100, Pavel Machek wrote:
> Hi!
> 
> Thomas told me:
> 
> >what about C4 - Cn states in the kernel implementation?
> >A short look into the /proc/acpi/processor/.../power file let me think
> >that only C0-C3 is supported by the kernel, even specification talks
> >about Cn states?
> 
> As a first step, it would be nice if kernel at least used C0..C3 if
> the machine supports them... This should do the trick. Does it look
> okay?

No.  pblk_length is 0 or 6.  Not 5 nor 7 ;)

Look at http://bugzilla.kernel.org/show_bug.cgi?id=1958

Note that I don't have time to work on it by now.  When the acpi video
extension will be OK, I will rework on that one unless someone else do
the work.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: ACPI C4 support

[Stefan Behlert]

Moin,

On Mar 01, 04 16:28:10 +0100, Bruno Ducrot wrote:
> On Sat, Feb 28, 2004 at 05:10:11PM +0100, Pavel Machek wrote:
> > Hi!
> > Thomas told me:
> > >what about C4 - Cn states in the kernel implementation?
> > >A short look into the /proc/acpi/processor/.../power file let me think
> > >that only C0-C3 is supported by the kernel, even specification talks
> > >about Cn states?
> > As a first step, it would be nice if kernel at least used C0..C3 if
> > the machine supports them... This should do the trick. Does it look
> > okay?
> 
> No.  pblk_length is 0 or 6.  Not 5 nor 7 ;)

Sorry, I don't understand: We've a Laptop with a DSDT with
  Processor (\_PR.CPU0, 0x01, 0x00001010, 0x07)
in it.
Comment from the responsible BIOS-team:
"Our processor block object is 7 bytes in length because we also support
 C4 (P_LVL4) which is at <P_BLK>+6.  Therefore, the size/length must be
 reported as 7 and not 6."

Is the '7' the BIOS-developer mentioned the same '7' as mentioned by you?


> 
> Look at http://bugzilla.kernel.org/show_bug.cgi?id=1958

> 
> Note that I don't have time to work on it by now.  When the acpi video
> extension will be OK, I will rework on that one unless someone else do
> the work.

Thanks.

> 
> -- 
> Bruno Ducrot

        caio,
          Stefan

-- 
Stefan Behlert, SUSE LINUX AG,
Mobile Devices
 
Maxfeldstr. 5, D-90409 Nuernberg, Germany
Phone +49-(0)911-74053-173


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: ACPI C4 support

[Bruno Ducrot]

On Mon, Mar 01, 2004 at 07:09:58PM +0100, Stefan Behlert wrote:
> Moin,
> 
> On Mar 01, 04 16:28:10 +0100, Bruno Ducrot wrote:
> > On Sat, Feb 28, 2004 at 05:10:11PM +0100, Pavel Machek wrote:
> > > Hi!
> > > Thomas told me:
> > > >what about C4 - Cn states in the kernel implementation?
> > > >A short look into the /proc/acpi/processor/.../power file let me think
> > > >that only C0-C3 is supported by the kernel, even specification talks
> > > >about Cn states?
> > > As a first step, it would be nice if kernel at least used C0..C3 if
> > > the machine supports them... This should do the trick. Does it look
> > > okay?
> > 
> > No.  pblk_length is 0 or 6.  Not 5 nor 7 ;)
> 
> Sorry, I don't understand: We've a Laptop with a DSDT with
>   Processor (\_PR.CPU0, 0x01, 0x00001010, 0x07)
> in it.
> Comment from the responsible BIOS-team:
> "Our processor block object is 7 bytes in length because we also support
>  C4 (P_LVL4) which is at <P_BLK>+6.  Therefore, the size/length must be
>  reported as 7 and not 6."
> 
> Is the '7' the BIOS-developer mentioned the same '7' as mentioned by you?
> 

No.  Bad documentation.  Change documentation.  Look at acpi spec at
http://www.acpi.info/

You can define only latencies for C2 and C3 via FADT, so if you allow
C4 via the p_blk, you *don't* have latency for C4.  You *must* define C4
in a _CST object in order to get at least the latency, amongst other
informations.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: ACPI C4 support

[Stefan Behlert]

Moin,

Thanks for the information. With it I can communicate what's wrong and how
to fix it. Helps us a lot.

        ciao,
          Stefan

On Mar 01, 04 20:48:25 +0100, Bruno Ducrot wrote:
> On Mon, Mar 01, 2004 at 07:09:58PM +0100, Stefan Behlert wrote:
> > 
> > Is the '7' the BIOS-developer mentioned the same '7' as mentioned by you?
> > 
> 
> No.  Bad documentation.  Change documentation.  Look at acpi spec at
> http://www.acpi.info/
> 
> You can define only latencies for C2 and C3 via FADT, so if you allow
> C4 via the p_blk, you *don't* have latency for C4.  You *must* define C4
> in a _CST object in order to get at least the latency, amongst other
> informations.
> 
> -- 
> Bruno Ducrot

-- 
Stefan Behlert, SUSE LINUX AG,
Mobile Devices
 
Maxfeldstr. 5, D-90409 Nuernberg, Germany
Phone +49-(0)911-74053-173


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click