From ac5ebdad20060a734ba5ae75e20dcfc1b89ef998 Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Wed, 14 Aug 2024 12:27:25 +0200 Subject: dt-bindings: serial: Allow embedded-controller as child node There exist some embedded controllers (like Microsoft SAM found on Surface devices or Apple Oscar found on old iPhones) that connect to the host device via serial. Allow that class of devices to exist under serial interface controller nodes. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240814-topic-sam-v3-1-a84588aad233@quicinc.com Signed-off-by: Hans de Goede --- Documentation/devicetree/bindings/serial/serial.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/serial.yaml b/Documentation/devicetree/bindings/serial/serial.yaml index ffc9198ae214..9b2c94796371 100644 --- a/Documentation/devicetree/bindings/serial/serial.yaml +++ b/Documentation/devicetree/bindings/serial/serial.yaml @@ -88,7 +88,7 @@ properties: TX FIFO threshold configuration (in bytes). patternProperties: - "^(bluetooth|bluetooth-gnss|gnss|gps|mcu|onewire)$": + "^(bluetooth|bluetooth-gnss|embedded-controller|gnss|gps|mcu|onewire)$": if: type: object then: -- cgit v1.2.3 From ceccd196e158805a4e9b69d92318dafe7b9d3ea2 Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Wed, 14 Aug 2024 12:27:26 +0200 Subject: dt-bindings: platform: Add Surface System Aggregator Module Add bindings for the Surface System Aggregator Module (SAM/SSAM), the Microsoft Surface-standard Embedded Controller, used on both x86- and Qualcomm-based devices. It provides a plethora of functions, depending on what's wired up to it. That includes but is not limited to: fan control, keyboard/touchpad support, thermal sensors, power control, special buttons, tablet mode. Signed-off-by: Konrad Dybcio Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240814-topic-sam-v3-2-a84588aad233@quicinc.com Signed-off-by: Hans de Goede --- .../bindings/platform/microsoft,surface-sam.yaml | 47 ++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 Documentation/devicetree/bindings/platform/microsoft,surface-sam.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/platform/microsoft,surface-sam.yaml b/Documentation/devicetree/bindings/platform/microsoft,surface-sam.yaml new file mode 100644 index 000000000000..b33d26f15b2a --- /dev/null +++ b/Documentation/devicetree/bindings/platform/microsoft,surface-sam.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/platform/microsoft,surface-sam.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Surface System Aggregator Module (SAM, SSAM) + +maintainers: + - Konrad Dybcio + +description: | + Surface devices use a standardized embedded controller to let the + operating system interface with various hardware functions. The + specific functionalities are modeled as subdevices and matched on + five levels: domain, category, target, instance and function. + +properties: + compatible: + const: microsoft,surface-sam + + interrupts: + maxItems: 1 + + current-speed: true + +required: + - compatible + - interrupts + +additionalProperties: false + +examples: + - | + #include + uart { + embedded-controller { + compatible = "microsoft,surface-sam"; + + interrupts-extended = <&tlmm 91 IRQ_TYPE_EDGE_RISING>; + + pinctrl-0 = <&ssam_state>; + pinctrl-names = "default"; + + current-speed = <4000000>; + }; + }; -- cgit v1.2.3 From 8022ae2c435f09f029a68235e3bb49e1e0b5b686 Mon Sep 17 00:00:00 2001 From: Tero Kristo Date: Wed, 28 Aug 2024 18:34:53 +0300 Subject: Documentation: admin-guide: pm: Add efficiency vs. latency tradeoff to uncore documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Added documentation about the functionality of efficiency vs. latency tradeoff control in intel Xeon processors, and how this is configured via sysfs. Signed-off-by: Tero Kristo Reviewed-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20240828153657.1296410-2-tero.kristo@linux.intel.com Signed-off-by: Hans de Goede --- .../pm/intel_uncore_frequency_scaling.rst | 59 ++++++++++++++++++++++ 1 file changed, 59 insertions(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst b/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst index 5ab3440e6cee..5151ec312dc0 100644 --- a/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst +++ b/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst @@ -113,3 +113,62 @@ to apply at each uncore* level. Support for "current_freq_khz" is available only at each fabric cluster level (i.e., in uncore* directory). + +Efficiency vs. Latency Tradeoff +------------------------------- + +The Efficiency Latency Control (ELC) feature improves performance +per watt. With this feature hardware power management algorithms +optimize trade-off between latency and power consumption. For some +latency sensitive workloads further tuning can be done by SW to +get desired performance. + +The hardware monitors the average CPU utilization across all cores +in a power domain at regular intervals and decides an uncore frequency. +While this may result in the best performance per watt, workload may be +expecting higher performance at the expense of power. Consider an +application that intermittently wakes up to perform memory reads on an +otherwise idle system. In such cases, if hardware lowers uncore +frequency, then there may be delay in ramp up of frequency to meet +target performance. + +The ELC control defines some parameters which can be changed from SW. +If the average CPU utilization is below a user-defined threshold +(elc_low_threshold_percent attribute below), the user-defined uncore +floor frequency will be used (elc_floor_freq_khz attribute below) +instead of hardware calculated minimum. + +Similarly in high load scenario where the CPU utilization goes above +the high threshold value (elc_high_threshold_percent attribute below) +instead of jumping to maximum uncore frequency, frequency is increased +in 100MHz steps. This avoids consuming unnecessarily high power +immediately with CPU utilization spikes. + +Attributes for efficiency latency control: + +``elc_floor_freq_khz`` + This attribute is used to get/set the efficiency latency floor frequency. + If this variable is lower than the 'min_freq_khz', it is ignored by + the firmware. + +``elc_low_threshold_percent`` + This attribute is used to get/set the efficiency latency control low + threshold. This attribute is in percentages of CPU utilization. + +``elc_high_threshold_percent`` + This attribute is used to get/set the efficiency latency control high + threshold. This attribute is in percentages of CPU utilization. + +``elc_high_threshold_enable`` + This attribute is used to enable/disable the efficiency latency control + high threshold. Write '1' to enable, '0' to disable. + +Example system configuration below, which does following: + * when CPU utilization is less than 10%: sets uncore frequency to 800MHz + * when CPU utilization is higher than 95%: increases uncore frequency in + 100MHz steps, until power limit is reached + + elc_floor_freq_khz:800000 + elc_high_threshold_percent:95 + elc_high_threshold_enable:1 + elc_low_threshold_percent:10 -- cgit v1.2.3