Re: [PATCH][ACPI] AC/DC notifier

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(Resending in text-only  sorry for the noise to the individual recipients)

Comments below.

-------- Original Message  --------
Subject: Re: [PATCH][ACPI] AC/DC notifier
From: Pavel Machek <pavel@xxxxxx>
To: Tippett, Matthew <matthew.tippett@xxxxxxx>
Cc: "Willy Tarreau" <w@xxxxxx>, "Matthew Garrett" <mjg59@xxxxxxxxxxxxx>, "Langsdorf, Mark" <mark.langsdorf@xxxxxxx>, lenb@xxxxxxxxxx, linux-acpi@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, "Li, Samuel" <Samuel.Li@xxxxxxx>
Date: 10/07/2009 03:31 AM

On Tue 2009-10-06 10:53:22, Tippett, Matthew wrote:

Please do. So far you did not show valid use for such notifier.

(Ok, I know of one. Old amd64 notebooks had cpufreq scaling enabled,
with battery unable to supply enough current to feed the CPU at
highest cpufreq setting. At that point, scaling cpufreq down at unplug
is correctness issue, and AC/DC notifier in kernel makes
sense.)

So... what do you want to use it for?

We have a general requirement from OEMs and consequently our shared Windows/Linux components that the AC/DC state is accurately known.

The concrete examples of use include at least the following.

1) Automatic frequency scaling has an AC-mode and a DC-mode in Powerplay tables in the GPU BIOS ensures that the highest permitted clocks fit the system design. This allows at least i) system level thermals and power consumption to be managed (eg: you shouldn't have the clocks up high if the system fan has been asked to slow down). ii) protection of hardware high clocks with a low-current battery is a bad idea. 2) The pixel clock can only drive certain modes with certain engine and memory clocks, in DC-mode you will have lower clocks and consequently you will need to change the pixel clock and hence the mode to something that fits within the budget, otherwise the 3D or display engine may not be able to get the bandwidth required to operate effectively. 3) OEM OS equivalency. Some OEMs care that Linux has the same thermal, power and performance characteristics as other operating systems. This requires that the software act in a similar way and reduces OEM/ODM/IHV/OSV validation and deployment costs.

In particular 1 and 2 are very relevant for KMS based drivers.

1 is most likely relevant for other ACPI/SBIOS related hardware components that rely on co-operating components doing what is expected by the system design. If a device doesn't change it's behaviour in sync with other devices when AC/DC changes, then bad (or at the very least annoying) things may happen. When there is a SBIOS/ACPI/Driver stack in place, the driver should honor the system design as well.

3 is only really relevant for the commercial side of things, but is a real issue that takes up more engineering effort than the first 2 - my cross to bear so to speak.

Regards,

Matthew


--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux