Different thermal policies require different UUIDs to be written to the
INT3400 interface. Avoid hardcoding that and allow engines to override it
as needed.

Systems may provide the DPTF policy information in an ACPI table. Allow
that to be used directly, and disable parsing of XML config to avoid
confusion.

If we're going to read a binary sysfs file, we want to know how big it is
in advance. Add a helper to do that. In addition, add support for reading
files greater than a single page.

We can obtain PPCC parameters from the firmware, so abstract that rather
than calling directly into the XML parser code.

The adaptive target tables may include information targeted at specific
device types. Add core support for passing that through to the cooling
devices.

Firmware may provide multiple PPCC entries, including one for DRAM. Try to
use it if we can, but fix up the XML parser to it makes sure that we don't
break existing setups.

Add support for setting RAPL parameters based on adaptive targets.
Incomplete at present.

In adaptive mode we prefer the use of the MMIO RAPL interface if available.

We want engines to be able to override this.

This is something of a hack right now (it should be event driven rather
than polling), but we need to update the adaptive engine state to check
whether we should transition to a new target.

The firmware doesn't pay attention to the configured UUID in the INT3400
device until _OSC is called, and this only happens when we enable the
associated thermal zone. Make sure we do so, and disable it again on exit.

DPTM provides an adaptive power policy that allows for improved integration
between the platform and the OS. Firmware can provide a set of complex
conditions to the OS, and an OS agent (in this case thermal_daemon) is
responsible for evaluating them, potentially making use of information that
is easily available to the OS and not the firmware. The agent evaluates
each set of conditions in turn, and once the first evaluates completely it
triggers a set of actions.

This implementation only covers a subset of the conditions - notably, it
only currently handles conditions that are associated with OEM-specific
variables exported via ACPI. It is also only currently capable of managing
RAPL targets or loading new passive thermal policies, since that's all that
my test system does.

Add a command line option to enable the use of the adaptive engine.

GDDV payloads can be compressed using LZMA. Add support for handling that.

PTTV entries may have a uint64 rather than a string for the target argument,
so make sure we handle that and also deal with cases where we have multiple
PSVTs in the parent object rather than in the shared space by passing
through a unique name.

Skipping a uint64 requires also skipping the type defintion, so fix up the
offset calculations.

We're not going to do anything with this data right now, so if it's not
something we can parse, bail.

This changes both the fatal into an error, and the loop to report _all_
unsupported conditions at once.

It should make it easier to gauge how much work is neded to support a
certain firmware.

Some systems use APPC to provide additional information associated with
conditions. Parse that and then merge it into our conditions.

Doing it this way was a bad idea, but here we are.

Make sure we don't inappropriately walk off the end of the APAT table.

PSVT tables may contain multiple passive trip points. Add support for that.

Add rough support for temperature comparisons. Right now this ignores
hysteresis.

If the APPC doesn't have anything that looks like a legitimate version
number at the start, ignore it.

This relies on upower, so add a dependency on that as well.

Add support for conditions that depend on whether the system is on AC or not

Add a handler to report that the workload is bursty at all times - we don't
currently have a good way to report something meaningful here.

Requires that the platform provide a SW_TABLET_MODE switch, so this may not
be reliable.

Fix the free()ing of arrays allocated with new, and notice that we've hit
the end of the data vault and are starting a new (currently unused) entry
and avoid misparsing it.

Names are padded out to four characters using trailing _ characters, but
device names aren't padded. Trim the trailing characters so we can match
more easily.

Current Intel platforms don't appear to provide supported UUIDs via ACPI,
only via the data vault. Since we're not parsing that in-kernel, just
assume it matches for now.

I can't find any supporting evidence for special casing the TMEM zone to
use dram RAPL rather than the CPU package, and there are machines with TMEM
zones that don't have dram RAPL, so remove it for now.

This should reduce CPU-based thermal throttling

It seems like the PL1MAX target is intended to raise the maximum RAPL limit
rather than to immediately change the limit - this is supported by various
laptops that set PL1MAX and also set PL1PowerLimit in the same table,
presumably to allow a gradual ramping up to avoid immediately crossing
other trip points.

If the current state is outside the new RAPL limits, clamp it to the limit.

Add support for statically updating the PL2 configuration when requested.

Conditions can specify that a condition must have held for more than or less
than a given period of time. Add support for that.

The PSV action appears to indicate that the passive trip point for the
associated device should be updated, so try doing that.

Clear the temporary string stream before testing each sysfs entry, to
test the correct entry names.

Ensure that pl2_index is set, rather than using uninitialized memory
when the short_term window isn't found.

We were out of sync for higher conditions, which caused misinterpretation
of legitimate values.