Re: disabled CST_CNT write

2012-07-22 Thread Andriy Gapon
on 08/07/2012 13:19 Taku YAMAMOTO said the following:
> In addition, that does not interfere with jkim's acpi_cx_native2.diff;
> I've been enjoying MWAIT C3 with varying sleep depth based upon AC 
> availability.

Are you saying that you have thoroughly tested that patch? :-)
I don't see any reason not to commit it then.
Jung-uk?

-- 
Andriy Gapon


___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"


Re: disabled CST_CNT write

2012-07-10 Thread Andriy Gapon
on 08/07/2012 19:49 Nate Lawson said the following:
> On Jul 8, 2012, at 2:11 AM, Andriy Gapon wrote:
> 
>> acpi_cpu.c has a block of code to write CST_CNT to SMI_CMD, but the block is
>> under #ifdef notyet.  It seems that the code was added that many years ago 
>> and
>> never enabled.
>> Now, judging from the reports I've seen on this mailing list, it appears that
>> _CST changes do happen and the driver seem to handle them sufficiently well.
>> I think that a lot of modern platforms do not even provide CST_CNT and assume
>> that an OS is able to handle C-state change notifications.
>> So, I guess that it should be safe to enable the code in question now.
>>
>> Could anyone with a FreeBSD laptop and non-zero CST_CNT in FADT please test 
>> this?
> 
> It was only under an #ifdef because at the time our CST implementation 
> couldn't handle CST changes cleanly. I had added some support for it, but 
> since it couldn't be tested, I wasn't sure how actual hardware would behave.
> 
> I think it's fine to enable now. I think 2007-era Thinkpads were some of the 
> first to add this feature.

Nate,

thank you for the information/explanation.

-- 
Andriy Gapon


___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"


RE: disabled CST_CNT write

2012-07-09 Thread Moore, Robert
> This Thinkpad T23 with latest (Oct2006) BIOS & EC shows no FADT .. but
> FACP has CST_CNT=0xf4.  Is that relevant at all?

An oddity of ACPI -- the FADT has the signature "FACP".



> -Original Message-
> From: owner-freebsd-a...@freebsd.org [mailto:owner-freebsd-
> a...@freebsd.org] On Behalf Of Ian Smith
> Sent: Monday, July 09, 2012 9:06 AM
> To: Nate Lawson
> Cc: freebsd-acpi@freebsd.org; Andriy Gapon
> Subject: Re: disabled CST_CNT write
> 
> On Sun, 8 Jul 2012 09:49:57 -0700, Nate Lawson wrote:
>  > On Jul 8, 2012, at 2:11 AM, Andriy Gapon wrote:
>  >
>  > > acpi_cpu.c has a block of code to write CST_CNT to SMI_CMD, but
> the block is  > > under #ifdef notyet.  It seems that the code was
> added that many years ago and  > > never enabled.
>  > > Now, judging from the reports I've seen on this mailing list, it
> appears that  > > _CST changes do happen and the driver seem to handle
> them sufficiently well.
>  > > I think that a lot of modern platforms do not even provide CST_CNT
> and assume  > > that an OS is able to handle C-state change
> notifications.
>  > > So, I guess that it should be safe to enable the code in question
> now.
>  > >
>  > > Could anyone with a FreeBSD laptop and non-zero CST_CNT in FADT  >
> > please test this?
> 
> This Thinkpad T23 with latest (Oct2006) BIOS & EC shows no FADT .. but
> FACP has CST_CNT=0xf4.  Is that relevant at all?
> 
>  > It was only under an #ifdef because at the time our CST  >
> implementation couldn't handle CST changes cleanly. I had added some  >
> support for it, but since it couldn't be tested, I wasn't sure how  >
> actual hardware would behave.
>  >
>  > I think it's fine to enable now. I think 2007-era Thinkpads were
> some  > of the first to add this feature.
> 
> T43?  Maybe it's time I upgraded :)
> 
> cheers, Ian
> ___
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"


Re: disabled CST_CNT write

2012-07-09 Thread Ian Smith
On Sun, 8 Jul 2012 09:49:57 -0700, Nate Lawson wrote:
 > On Jul 8, 2012, at 2:11 AM, Andriy Gapon wrote:
 > 
 > > acpi_cpu.c has a block of code to write CST_CNT to SMI_CMD, but the block 
 > > is
 > > under #ifdef notyet.  It seems that the code was added that many years ago 
 > > and
 > > never enabled.
 > > Now, judging from the reports I've seen on this mailing list, it appears 
 > > that
 > > _CST changes do happen and the driver seem to handle them sufficiently 
 > > well.
 > > I think that a lot of modern platforms do not even provide CST_CNT and 
 > > assume
 > > that an OS is able to handle C-state change notifications.
 > > So, I guess that it should be safe to enable the code in question now.
 > > 
 > > Could anyone with a FreeBSD laptop and non-zero CST_CNT in FADT 
 > > please test this?

This Thinkpad T23 with latest (Oct2006) BIOS & EC shows no FADT .. but 
FACP has CST_CNT=0xf4.  Is that relevant at all?

 > It was only under an #ifdef because at the time our CST 
 > implementation couldn't handle CST changes cleanly. I had added some 
 > support for it, but since it couldn't be tested, I wasn't sure how 
 > actual hardware would behave.
 > 
 > I think it's fine to enable now. I think 2007-era Thinkpads were some 
 > of the first to add this feature.

T43?  Maybe it's time I upgraded :)

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"


Re: disabled CST_CNT write

2012-07-08 Thread Nate Lawson
On Jul 8, 2012, at 2:11 AM, Andriy Gapon wrote:

> acpi_cpu.c has a block of code to write CST_CNT to SMI_CMD, but the block is
> under #ifdef notyet.  It seems that the code was added that many years ago and
> never enabled.
> Now, judging from the reports I've seen on this mailing list, it appears that
> _CST changes do happen and the driver seem to handle them sufficiently well.
> I think that a lot of modern platforms do not even provide CST_CNT and assume
> that an OS is able to handle C-state change notifications.
> So, I guess that it should be safe to enable the code in question now.
> 
> Could anyone with a FreeBSD laptop and non-zero CST_CNT in FADT please test 
> this?

It was only under an #ifdef because at the time our CST implementation couldn't 
handle CST changes cleanly. I had added some support for it, but since it 
couldn't be tested, I wasn't sure how actual hardware would behave.

I think it's fine to enable now. I think 2007-era Thinkpads were some of the 
first to add this feature.

-Nate

___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"


Re: disabled CST_CNT write

2012-07-08 Thread Andriy Gapon
on 08/07/2012 13:19 Taku YAMAMOTO said the following:
> On Sun, 08 Jul 2012 12:11:32 +0300
> Andriy Gapon  wrote:
> 
>>
>> acpi_cpu.c has a block of code to write CST_CNT to SMI_CMD, but the block is
>> under #ifdef notyet.  It seems that the code was added that many years ago 
>> and
>> never enabled.
>> Now, judging from the reports I've seen on this mailing list, it appears that
>> _CST changes do happen and the driver seem to handle them sufficiently well.
>> I think that a lot of modern platforms do not even provide CST_CNT and assume
>> that an OS is able to handle C-state change notifications.
>> So, I guess that it should be safe to enable the code in question now.
>>
>> Could anyone with a FreeBSD laptop and non-zero CST_CNT in FADT please test 
>> this?
> 
> My Thinkpad X60 (Core 2 Duo) is such one of them.
> Enabling that code makes this laptop correctly raise _CST change
> notification on AC status change without a single problem.
> Without enabling that, this laptop never generates such notifications.
> 
> In fact, I have been enabling that code locally for more than a couple of
> years without a problem :)
> 
> In addition, that does not interfere with jkim's acpi_cx_native2.diff;
> I've been enjoying MWAIT C3 with varying sleep depth based upon AC 
> availability.
> 

Thank you very much for the information!
I will commit this change.

-- 
Andriy Gapon


___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"


Re: disabled CST_CNT write

2012-07-08 Thread Taku YAMAMOTO
On Sun, 08 Jul 2012 12:11:32 +0300
Andriy Gapon  wrote:

> 
> acpi_cpu.c has a block of code to write CST_CNT to SMI_CMD, but the block is
> under #ifdef notyet.  It seems that the code was added that many years ago and
> never enabled.
> Now, judging from the reports I've seen on this mailing list, it appears that
> _CST changes do happen and the driver seem to handle them sufficiently well.
> I think that a lot of modern platforms do not even provide CST_CNT and assume
> that an OS is able to handle C-state change notifications.
> So, I guess that it should be safe to enable the code in question now.
> 
> Could anyone with a FreeBSD laptop and non-zero CST_CNT in FADT please test 
> this?

My Thinkpad X60 (Core 2 Duo) is such one of them.
Enabling that code makes this laptop correctly raise _CST change
notification on AC status change without a single problem.
Without enabling that, this laptop never generates such notifications.

In fact, I have been enabling that code locally for more than a couple of
years without a problem :)

In addition, that does not interfere with jkim's acpi_cx_native2.diff;
I've been enjoying MWAIT C3 with varying sleep depth based upon AC availability.

-- 
-|-__   YAMAMOTO, Taku
 | __ < 

  - A chicken is an egg's way of producing more eggs. -
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"