Date: Mon, 5 May 2014 09:55:29 -0700 From: Adrian Chadd <adrian@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: Kevin Oberman <rkoberman@gmail.com>, "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax Message-ID: <CAJ-VmomizFLDsMmaLHx3ojEefajMMGJmbC6EANx0gi6T9hJuew@mail.gmail.com> In-Reply-To: <201405051109.39345.jhb@freebsd.org> References: <CAJ-Vmo=mUtpjgVwNHg8af05vCxVchZdsaekR9_Wf-pOfFjnABQ@mail.gmail.com> <201405051109.39345.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 May 2014 08:09, John Baldwin <jhb@freebsd.org> wrote: > On Sunday, May 04, 2014 4:27:38 am Adrian Chadd wrote: >> Hi, >> >> I'd like to propose flipping a few things: >> >> * Flipping the default lid state to S3. I think ACPI suspend/resume >> seems to work well enough these days and I've not met anyone lately >> who expects the default from their laptop to be "stay awake with the >> lid shut." >> * Save chip bugs that we should add workarounds for, we should be OK >> to enter lower sleep states when idling. Flipping this may expose some >> further crazy driver, platform or timer bugs, but they again likely >> should be fixed. >> >> what do people think? > > I think the lid switch thing is premature. Even on my X220 I use a devd > hook to enable it only when i915drm is loaded as resume doesn't work until > that is done. > > I think the Cmax thing OTOH is probably more appropriate. We have several > things place that should "mostly" DTRT for picking the correct timers to > use. The one case I know of recently were some somewhat older systems where > the HPET wasn't reliable, but the system chose to use HPET instead of LAPIC > becuase the LAPIC was known to stop during C1E, etc. In this case the user > just stuck with plain old C1 and forced the LAPIC timer which worked fine. > However, it is hard to identify those cases. On modern systems I would > expect the LAPIC to work just fine, so this problem will become less and > less important as time goes on. right. I'd rather we start finding more of these sooner rather than later. :-) -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomizFLDsMmaLHx3ojEefajMMGJmbC6EANx0gi6T9hJuew>