Date: Mon, 13 Sep 2010 20:07:41 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: Alexander Motin <mav@FreeBSD.org> Cc: freebsd-acpi@FreeBSD.org, Norikatsu Shigemura <nork@FreeBSD.org> Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 Message-ID: <4C8E5A5D.6000303@icyb.net.ua> In-Reply-To: <4C8CF91A.4040804@FreeBSD.org> References: <4C8BCAC5.5050008@root.org> <mailpost.1284277196.1767764.83548.mailing.freebsd.current@FreeBSD.cs.nctu.edu.tw> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9F06.4090505@icyb.net.ua> <20100912190537.621e357e.nork@FreeBSD.org> <20100912190952.8c0d5726.nork@FreeBSD.org> <20100912192518.e791c191.nork@FreeBSD.org> <4C8CAC01.70004@icyb.net.ua> <4C8CAD7D.50602@FreeBSD.org> <4C8CF03F.1050902@icyb.net.ua> <4C8CF412.9080601@icyb.net.ua> <4C8CF91A.4040804@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 12/09/2010 19:00 Alexander Motin said the following: > > I am not sure this patch is complete: Well, I agree, it's far from complete. And situation is somewhat messy. > 1) AFAIR I have seen somewhere example where system had several C-states > with different latency, but the same type - C3. Type only means > enter/exit semantics, and there could be several states with the same > semantics. Not sire how to properly them in this case. ACPI specification suggests how to address this, but I am not sure if we want to follow that suggestion and how we would do that: ACPI> Notice in the example above that OSPM should anticipate the possibility of a _CST object providing more ACPI> than one entry with the same C_State_Type value. In this case OSPM must decide which C_State_Register ACPI> it will use to enter that C state. So it looks like the specification does tie C_State_Type to "C state". But then, in general, the specification looks confusing. It mentions C4, ..., Cn states; but then says that their enter/exit semantics should correspond to C1, C2, C3; but then it uses "1, 2, 3, *etc*" [emphasis mine] when it describes C State type. So, at least I am confused as to what they would designate with C4 - a state described in _CST with type of 4, or a forth state in _CST perhaps with a type of 3. And entry/exit semantics the state would have in the former case. I do not see an explicit answer in their wording. > May be existing > approach was not so bad. It is ACPI C-states, not CPU C-states, they are > not same. > May be we should just mention type somewhere in addition. > 2) This change makes heavily understandable values of cx_lowest. > 3) If touch cx_lowest, I would prefer to see there possibility to set it > to some abstract C6 or whatever, allowing system automatically choose > state it has available at the moment. > Yes, I agree. It's just overall confusing. But you are correct that index of a C-state works better than "C-state-type" or whatever it can be called. And a user probably doesn't care much about the latter. But probably it's a good idea to report the type somewhere. I am also going to take a look how Linux and OpenSolaris name the C-states. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C8E5A5D.6000303>