From nobody Tue Dec 2 00:25:40 2025 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (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 3FF4031577D for ; Tue, 25 Nov 2025 11:27:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764070033; cv=none; b=aEHWjjwsK2NBLjpRgba+eLwW296K1uPqVbveLTMKlUQ1ynqT6U7mcSHh7pj9aBtRGmne1sB1hm0eDXrqtB65eRmZ1/IxlK+oK3vtA/F0jKNVhhrbxUw8mZBKtznVsa7PoOls2sOU1xVTmDZmvl42kamhJSfJb0PgLezRNaArPeo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764070033; c=relaxed/simple; bh=GrznQtm2Xbu5M36KVvznD5+BJEJ9tpaSNo1aXMTzPYc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=d2aIasYywxIDl7VNe/ee1jcZtizeCoNPaZufN1TjCUZ00SmeNzpHBAB2MRb2z856irPOZom7jpKW2cGhwEQkO3AtlaFtoPlFCiIqnz3qNaEevmwypfiaeh2dh3IouX5w16WAl3Y42074jg1k8iAP6J0oSErb0Kxx5c5EFmofCrs= 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=RFZiCovK; arc=none smtp.client-ip=209.85.167.43 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="RFZiCovK" Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-5957f617ff0so5731966e87.2 for ; Tue, 25 Nov 2025 03:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1764070028; x=1764674828; 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=7Pe+KUJG6BVKcUJHZJ0mcY6KZ0UWQ2fQ+ADIwlAh+rE=; b=RFZiCovK5pZCDLgtV5QtOrfFpjLVd8m/yQdP5hqZEDtjQDIT8VOPvcJgyjPheLdQdP NtfAgQ8uKqnAcTExhIkNI7A8A4tqY6aeJ3sEFmFqy0MQa45qsTZ8J9fL8k40Als4IKw0 SavHk7L6wCpeODkKCF9mr/jypqesz7Owb/bxip+dUIEisi1Lvgd7/xz+ZOopz1859LWJ vbQhLAw3oxFvn88FIqgyI587buaicfWhLFAq8O4Te57HGtVxnoxvnGkS3rUGwwmLkKy6 2/7WdmtlzvClsCJWL68WO7j4p8mmXZgtQ6dESnPju8+XN/CoaWYrYaGfcVX/ie77BJsW 5tMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764070028; x=1764674828; 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=7Pe+KUJG6BVKcUJHZJ0mcY6KZ0UWQ2fQ+ADIwlAh+rE=; b=OS1hxyrF3QUsgtp5y1xZxeP3Ftx6DA3y66hT2HQQAjSPtjIc/JF24InnXDntRLTg60 ZLnj3qfSXJ6PlBWcO/gn7NpKIZMrfI2ym86ieNlRH9nV+Cs3Chfj8Wf1Zvkn8IhgM1C+ a0ci3qrYgun8nsTXBw9GBU+8jo97sF1DSAjpjnm99FE3JOuzw6Igasl5uKQdhMxLzk7H 9MDMwMuFUp61X/e+7BlcQuFuxh5ooAhxMqKpE7JH5HxrbAbhmQfjfrtUm9Cb6uoktjWc wE82CtIVSg837itZHsB/CjmS/2X66DmJMuEtuc4EkkIVNu3kefZRFAKGPqdmwHZxGkrD pMxQ== X-Forwarded-Encrypted: i=1; AJvYcCUjb7YFBhPy2tzquQ+bCl88R8+ysokKoLDdUL7XV+kszeBHsG8vzmVtJUHdqm8EffAfHC2YkbE7qvlQAjE=@vger.kernel.org X-Gm-Message-State: AOJu0YxmYFjXMHBSJXHlefPZ0cMa9tNUd/5DLm4Tbu21T6Tc6Icxeq61 Y3VWJMgMDkOrXFtMeVP0/TH4g0ut3keAr6YP/0+UTkzmsI/dDK+pC9o8vuKrapVxCdE= X-Gm-Gg: ASbGnctNmoFWzvBFXLUXEGvKP5sY8E74pq29WhX2ogoWbjRFdWFUIp2XLca/qG6dTR6 KZPE7jxARP4R6O2+kLAm0FSrFDQblWBp1Oh9U1HhYGFYNXA9f+bEZU/gaqK1dmQ/SwzYTAgYApO nvg0yJ7atQm9dnpIp1k6s2CdFKJTI6Y01t45C2VjMxWqNj5Fs84s0L38EzwZM3qwsVdfjz3pAQX yRf7UXeePUF+NI4V4Zhlk+2rpu6uvbN4pKfCou57FPT7ZIjF2PwpnvrCfVIbBYSSPCepVD9nQvH utEvTKGgbqSrk/XcfJuXqoEk61ERRUPgsrCYibuXYPYbfVwq+LIoBm34Li4A92OkaSajeWqgnJK ChXsdm5dDjbsex7N3SJGce1soOWnojCCH4PSLE1xA+owWQhgzF3EzoWusUvwFaDS/ky7i0yN2C2 JMeZLM8BnonPo46CGB9vB5W93LZvm9O/0PYTlv3jJ/Qjs8KrLhM8ycur4kf74B X-Google-Smtp-Source: AGHT+IGRDjKSLOucrdLNEeV+cZDbVrqAyKHDt7qFDXqWVrlCSGciMoBT3mitw8rmyaHgPr8TokqaVA== X-Received: by 2002:a05:6512:2313:b0:595:9d7d:6ebb with SMTP id 2adb3069b0e04-596a3ebe00fmr4819702e87.15.1764070028280; Tue, 25 Nov 2025 03:27:08 -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 2adb3069b0e04-5969db7563fsm4993526e87.2.2025.11.25.03.27.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Nov 2025 03:27:06 -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 v4 6/6] Documentation: power/cpuidle: Document the CPU system wakeup latency QoS Date: Tue, 25 Nov 2025 12:26:47 +0100 Message-ID: <20251125112650.329269-7-ulf.hansson@linaro.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20251125112650.329269-1-ulf.hansson@linaro.org> References: <20251125112650.329269-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 Reviewed-by: Dhruva Gole Reviewed-by: Kevin Hilman (TI) Tested-by: Kevin Hilman (TI) Signed-off-by: Ulf Hansson --- Changes in v4: - Fixed grammar (Dhruva). - Added tags. 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..be4c1120e3f0 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 apply to CPU idle time management, user +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