From nobody Tue Dec 2 02:03:29 2025 Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 93CCB126C17 for ; Fri, 21 Nov 2025 10:03:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.179 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763719431; cv=none; b=JktbR2TAYNGXGmSd7hzktFKrSLlKCL/xfMylFfW4zHvaIXCrd0tdZOAY5Hl0SZEb5opVsotvxOKZDerm6WtzGe5vhOgslczW1QlLyMHq5AWn4EfkkanhLwWFZQWvpM0MMCqFKOJsUcxjwg2ZNXnwtYq9Ao8eyV9B6YQF0GmM/Dc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763719431; c=relaxed/simple; bh=x+e7y/pvYnxiFBlQnOJXkaitWecU5Du5bsfUUw5U7PM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DSdzdMvmtwXFM7VO6BeDB1LKJbjv1TD07TdLFYQguf6q8gegm7M07kfAJaY3IGDSp33tgJHS5riHc1pPoSRIIObfr740PoGSxElfEv2XUEGSGLsujsmZ/6vzgCGxDeJn0WNNIGG+KNWr4H2YvkKedukyV1OUEYZwzuya03rBR74= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=hEjr5oQl; arc=none smtp.client-ip=209.85.208.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="hEjr5oQl" Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-37ba5af5951so19944651fa.1 for ; Fri, 21 Nov 2025 02:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1763719425; x=1764324225; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=pC4XiP3l8Ew8D/XkZDyv3rIKzQexxvvUyzQqhlG1XiY=; b=hEjr5oQl8g8sTWpX9WKE6QYoy6k0kzBgMKIZQh6oH9vnzf6vSg8vxLXDYBcjHiWsjc os55PYPbJ8QlAnAfzbQBCovLmhWUKSzkO/Z53cRyRWH2WVMYG9p2rstzq1Qz3aZSCzGz 6cQbqAyP/x8e97FQUDVsccBeZKTbmDzf/V57j7K6/wbQDqAi/tLuCN6fGtwbcCVJrCCy avG7x8GR8/eUV5L5VKZwToG9hBEWCYmh5wQFtGvlxwSHvGkMGcMKWH5Hl1Lt67mP6MZP 6vj1AzfmiHon1qEbzBycuQvx9IqmvBEdzqcQ6IGART+BYYnjj5l3B8qghxLf4O61l6K9 6EUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763719425; x=1764324225; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=pC4XiP3l8Ew8D/XkZDyv3rIKzQexxvvUyzQqhlG1XiY=; b=eTuzgaggrPQqG31Q3J2LkpOfc9Riqu2IitdvlZdsc8FQatEWhFlCAJPIFtysxlPUzv YkzTz63Cr+PZUWWOK7mptOOCMC5ufsOw/t/T38J6KZZ/x0NBPuu/jL07CQIUKS7t4gHq DC/H8me+ka50IOpbN1n6fbHbnxcIpWEWe3ja1sE2hBAStusiECKVH/gZumkLpEtcySNS fjqbL08nQWg9Ya6zUxzRr5sYJMJx9kZtDp2eZzadsvSmuLkl3ciaBRjsl0OXq+otkf5H xeGMM7zMFzH8MW30G/M8JfGq/lVDYnfMPcsaYDNYgSAyiS6U+PwA1E+MBGwm1P11S8PB UW0Q== X-Forwarded-Encrypted: i=1; AJvYcCV6ZoW6G8UdjGSF+LXmagBhbkPuQqXur4rrJ3xf4WhMhxeJ2swwVTP8Ax3ptzyNSU04fJt88Bk/oq9pUsY=@vger.kernel.org X-Gm-Message-State: AOJu0YxXUx4BXEbZfqFGM0jey+yaKGt1yZe0cojCSog7Gpd6kfr5qjrR dkT3W9WG3TB2rAPk9ORVvRLKxQfHAuCwUxamlBik9/uKZ2Qd7pED4NUxA/8XAoG4qlM= X-Gm-Gg: ASbGncva8/J8ca8IPdqiGXGRI7haeeQMMA+Yk+YyiSln8zJaUxEk4Oxdg6TOeVnfMe+ 8b1da/v7GbY0/6lc7BXM4PMC+e60UsMzgmU0WXg6z2KwNfDl9GvZSJZCS8fdPmhUhbxXse1M20O 1Jq8vfEpbSPSRtIlpZgHoX9ffzSaMxBgt/VE0L+AH+8W52BX8GTOBP3WqZ644+mknzjB9PQOwaa T+/NJiMiBXjQr/9nzOvWzAcydBVb6Lyg31VB0R7tj+h31QD7TJAwZPxXsM+Z+mvWTPB5KtJ4m5k newuvxYNSkxw61VG9a63GL6hgxHK8nAMSUWqhWbL1NSsYGgjLUN9UNVYwcgQYlSYCOrbz3hopSV WRpqGyilvdAOLMcV1xx7gf6DCVT/6hekxWNECyZhH5NcD6OnaV35OYYRsOMYdzSRhCP5VRg52KE KtSZufRVhjf+4Qtb8Kwh57qUB6gjy/kDJqrAhjM3eI/U2FFl8dqv2UEzcT22+/ X-Google-Smtp-Source: AGHT+IE1QBDl25thXOykf99W0hmO2fID/AbQq/E1G/iDg+8zCCoVv/kRzbF75XHT2jFRieRUjU039g== X-Received: by 2002:a05:651c:4207:b0:37a:846c:3484 with SMTP id 38308e7fff4ca-37cd9164042mr3913491fa.4.1763719425337; Fri, 21 Nov 2025 02:03:45 -0800 (PST) Received: from uffe-tuxpro14.. (h-178-174-189-39.A498.priv.bahnhof.se. [178.174.189.39]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-37cc6b597b2sm11056181fa.12.2025.11.21.02.03.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Nov 2025 02:03:44 -0800 (PST) From: Ulf Hansson To: "Rafael J . Wysocki" , linux-pm@vger.kernel.org Cc: Vincent Guittot , Peter Zijlstra , Kevin Hilman , Pavel Machek , Len Brown , Daniel Lezcano , Maulik Shah , Prasad Sodagudi , Dhruva Gole , Deepti Jaggi , Ulf Hansson , linux-kernel@vger.kernel.org, Jonathan Corbet Subject: [PATCH v3 6/6] Documentation: power/cpuidle: Document the CPU system wakeup latency QoS Date: Fri, 21 Nov 2025 11:03:12 +0100 Message-ID: <20251121100315.316300-7-ulf.hansson@linaro.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251121100315.316300-1-ulf.hansson@linaro.org> References: <20251121100315.316300-1-ulf.hansson@linaro.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Let's document how the new CPU system wakeup latency QoS limit can be used from user space, along with how the constraint is taken into account for s2idle and cpuidle. Cc: Jonathan Corbet Signed-off-by: Ulf Hansson Reviewed-by: Dhruva Gole --- Changes in v3: - Improved documentation. - Updated commit message. Changes in v2: - New patch. --- Documentation/admin-guide/pm/cpuidle.rst | 9 +++++++++ Documentation/power/pm_qos_interface.rst | 9 +++++---- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/Documentation/admin-guide/pm/cpuidle.rst b/Documentation/admin= -guide/pm/cpuidle.rst index 0c090b076224..c39ad6ab99d9 100644 --- a/Documentation/admin-guide/pm/cpuidle.rst +++ b/Documentation/admin-guide/pm/cpuidle.rst @@ -580,6 +580,15 @@ the given CPU as the upper limit for the exit latency = of the idle states that they are allowed to select for that CPU. They should never select any idle states with exit latency beyond that limit. =20 +While the above CPU QoS constraints applies to CPU idle time management, u= ser +space may also request a CPU system wakeup latency QoS limit, via the +`cpu_wakeup_latency` file. This QoS constraint is respected when selectin= g a +suitable idle state for the CPUs, while entering the system-wide suspend-t= o-idle +sleep state, but also to the regular CPU idle time management. + +Note that, the management of the `cpu_wakeup_latency` file works according= to +the 'cpu_dma_latency' file from user space point of view. Moreover, the u= nit +is also microseconds. =20 Idle States Control Via Kernel Command Line =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/Documentation/power/pm_qos_interface.rst b/Documentation/power= /pm_qos_interface.rst index 5019c79c7710..4c008e2202f0 100644 --- a/Documentation/power/pm_qos_interface.rst +++ b/Documentation/power/pm_qos_interface.rst @@ -55,7 +55,8 @@ int cpu_latency_qos_request_active(handle): =20 From user space: =20 -The infrastructure exposes one device node, /dev/cpu_dma_latency, for the = CPU +The infrastructure exposes two separate device nodes, /dev/cpu_dma_latency= for +the CPU latency QoS and /dev/cpu_wakeup_latency for the CPU system wakeup latency QoS. =20 Only processes can register a PM QoS request. To provide for automatic @@ -63,15 +64,15 @@ cleanup of a process, the interface requires the proces= s to register its parameter requests as follows. =20 To register the default PM QoS target for the CPU latency QoS, the process= must -open /dev/cpu_dma_latency. +open /dev/cpu_dma_latency. To register a CPU system wakeup QoS limit, the +process must open /dev/cpu_wakeup_latency. =20 As long as the device node is held open that process has a registered request on the parameter. =20 To change the requested target value, the process needs to write an s32 va= lue to the open device node. Alternatively, it can write a hex string for the va= lue -using the 10 char long format e.g. "0x12345678". This translates to a -cpu_latency_qos_update_request() call. +using the 10 char long format e.g. "0x12345678". =20 To remove the user mode request for a target value simply close the device node. --=20 2.43.0