From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (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 9CD992F6935 for ; Thu, 29 Jan 2026 18:29:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769711365; cv=none; b=XxJtOSXQt3RGAKvdxjzEpGEN8UzmFqpMxyaBTEzjB4KPDP4uw9MgEKr4tY1UcPHWWIKFTrMvgCsl7wst1YSznWxfadTJSgkZ1zrLUtpuM2oTQluLG7GT/uQRRyX4mRbqgHQ+3awA8nQxGle3guSFq1KfeFaHS+yJ5EzunC/L4IA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769711365; c=relaxed/simple; bh=s9cyBAx523IF+w7+uTG0ioM4KyoCJ4gol0oHmNarFvo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=YhmnQBfXUSGW16+OU1ZlEfHhrmZ/cgzfTodDi2ECzJxBXEMP0v4Op8peeZEE91Req3jBecp+POGrA6fyeAKScKfghvnlOlZWNqqu4rgN+sTtSDjr/QUb0pwL7CaA5N7EXGK+cwuXKOJOFS3bFdPL48CMih84rEEz9+h1n00+yyg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b=OVuhTfGa; arc=none smtp.client-ip=209.85.214.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="OVuhTfGa" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-2a12ed4d205so7531965ad.0 for ; Thu, 29 Jan 2026 10:29:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1769711363; x=1770316163; darn=vger.kernel.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=/bgjJsIT5xznnALKdHvfKbvj/wc+CMZK/BWvtb0BD48=; b=OVuhTfGaEw3Nt7NIo7oUke5CT5noSltbwGmGg/SgEvwrSy3IM2UkYd2kcn/vcGdNsU rk8hGjavybVmIqfLKwgJSVZCKwnnNm0/ck6v0+hyNCAyqIdNyVVp3DMD+Y0idoAGdupz PoZpJC0hMRiSgURLlbod8JjNXlVrfswgl/5vK4eQ0VlYSvOrdvPxYXn6gArKBGZh2bKX G3VXkQ4AumD2jf/1Eqnw1dqIH56HbzQXd4tOINPzg2MXa/pTnOK9d7rEv1PgaTK/H/o0 G5+rB5PzvoKu5b553JUAtpNx1EzSq/5RwoZxIvNLXr0+qjPE4VnZYbmMODRZf3V8DH/l UnDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769711363; x=1770316163; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/bgjJsIT5xznnALKdHvfKbvj/wc+CMZK/BWvtb0BD48=; b=IFves483DliUdoF5sepvJ/tLmf5OkebeavJPaHTA/NdaMa6K1w0iUs7N+U4SorIXAn EVnVzEDyKp49XEnsLtwfx7Z6s5cElrFw09xhRAyo9RIk+kIvtWzPlOAvwxvbOhs+FtU2 jLcPuepSs6RY2bxkh0hGxikbtxo2LxsaSqNYeS6yIn026PVchAzDO1CkwGEVTw1PcWK/ yugK7vmZ/5ZY01BzUhid8LkLIwEA304hjc4lPWSOlGc9NeMubcyWCgiHTXCR372DUYBJ YQNYrN/J0r0N12BBmwTDb04e3Z6Uv5PIG1xBSJpqseaTBOMMKqWO07Jz02o3tyPudT3c +f5Q== X-Forwarded-Encrypted: i=1; AJvYcCWG7z6wInu+cyp0COVuaVF2oOfl2RJXyYpYAOIRQMLiPIHOw5dQch9od5Y8akV4J1+b1qBLovYMVPf6xj0=@vger.kernel.org X-Gm-Message-State: AOJu0YxxrwxwP6R9qGmnUUWPjLs4qty+k2mQIyvsGDg3AfDnFFtvJQSw jeRdzURc+CfqYdpfL+/MIKgMXmL4yOzYPb9qFINVGvjIvfgZfOnFi6wVUx65XDmhu6M= X-Gm-Gg: AZuq6aJqeMCV4RBdNhqDYmB39IzKD0w7rZgMkPBrIa52PuhWdseB7U7VsdUywBUOePK RIU6o1zt0ToGyGWI0m+tudEpfGr8OOEGdrQRa7CpyNGbyC7wRLsI8jCWuoQ3Kr5dQx0smTfriAQ pfxXlJ9UjwKqgdkNpTw1V1NhKKNpS/l8cohwysh0/LndufFmItnSKojSOVlw4MUMaWleQ+sOBJu AEVEjyqNi5MGQExkobSIhsrbxC5PtQIIEtVHMaU7sqc/fmrpPyY34pFdsLtJNzzTUxzmbI3mpBR IgWS1nPl+mqx7gKe809+hZBdVVdSEA0FYE3zpkfljvktBJvHJkyvPLKGai6ZyrArRnmt2JBMaKO oT3POvjxaLWDXydAtBOn4Qqg4WBQqb/NaqplwYFneerz8e7gWf+yBVuGYLlRm1HDOYNHWAV1vtf x65oGcHLdV X-Received: by 2002:a17:902:ced0:b0:2a0:8e35:969d with SMTP id d9443c01a7336-2a8d990beccmr1186465ad.39.1769711362830; Thu, 29 Jan 2026 10:29:22 -0800 (PST) Received: from localhost ([71.212.200.220]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a88b4c3b08sm56001275ad.59.2026.01.29.10.29.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Jan 2026 10:29:21 -0800 (PST) From: Kevin Hilman To: Ulf Hansson Cc: "Rafael J. Wysocki" , linux-pm@vger.kernel.org, Dhruva Gole , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2] PM: QoS/pmdomains: support resume latencies for system-wide PM In-Reply-To: References: <20260120-topic-lpm-pmdomain-device-constraints-v1-0-108fc4cfafce@baylibre.com> <7hh5s547ot.fsf@baylibre.com> Date: Thu, 29 Jan 2026 10:29:20 -0800 Message-ID: <7hbjic46in.fsf@baylibre.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Ulf Hansson writes: > On Thu, 29 Jan 2026 at 00:51, Kevin Hilman wrote: >> >> Hi Ulf, >> >> Ulf Hansson writes: >> >> > On Wed, 21 Jan 2026 at 02:54, Kevin Hilman (TI) wrote: >> >> >> >> Currently QoS resume latencies are only considered for runtime PM >> >> transitions of pmdomains, which remains the default. >> >> >> >> In order to also support QoS resume latencies during system-wide PM, >> >> add a new flag to indicate a resume latency should be used for >> >> system-wide PM *instead of* runtime PM. >> >> >> >> For example, by doing this: >> >> >> >> # echo 500000 > /sys/devices/...//power/pm_qos_resume_latency_us >> >> >> >> dev0 now has a resume latency of 500000 usec for runtime PM >> >> transitions. >> >> >> >> Then, if the new flag is also set: >> >> >> >> # echo 1 > /sys/devices/...//power/pm_qos_latency_sys >> >> >> >> That 500000 usec delay now applies to system-wide PM (and not to >> >> runtime PM). >> >> >> >> If a user requires a different latency value for system-wide PM >> >> compared to runtime PM, then the runtime PM value can be set for >> >> normal operations, and the system-wide value (and flag) can be set by >> >> userspace before suspend, and the runtime PM value can be restored >> >> after resume. >> > >> > That's sounds complicated for user-space to manage - and causes churns >> > during every suspend/resume cycle. Why don't we just add a new latency >> > value instead, that applies both to runtime PM and system-wide PM, >> > similar and consistent to what we did for CPU QoS? >> >> First, I don't think it will be very common to have different *device* >> latency values between runtime PM and system PM, because the reasons for >> device-specific wakeup latency will likely be the same in both cases, at >> least for all the usecases I've thought about. The only real distiction >> being whether the latency should be applied to runtime or system-wide >> PM, which the new flag provides. >> >> Second, this doesn't have to be in userspace at all, that's just the >> example I used to illustrate. In fact, today not many latency >> constraints are exposed to userspace, so this can be acheived by the >> kernel API for setting latency values & flags, which I think is the more >> likely usecase anyways. For example, for a driver that is managing a >> wakeup latency constraint, it could update it's own constraint and set >> the flag in it's ->prepare() and ->complete() hook if it needs separate >> values for system-wide vs. runtime PM. > > Right, as long as the use cases can be managed by the kernel itself, > then this should be fine. So, I guess the question is, if we should > consider use-cases that requires user space involvement at this point? > > Also note, patch1 do exposes a new QoS sysfs file, to allow user space > to manage the new QoS flag - so this becomes ABI. > >> >> Third, adding a new QoS value for this involves a bunch of new code that >> is basically copy/paste of the current latency code. That includes APIs >> for >> >> - sysfs interface >> - notifiers (add, remove) >> - read/add/update value adds a new type >> - expose value to userspace (becomes ABI) >> - tolerance >> >> I actually went down this route first, and realized this would be lots >> of duplicated code for a usecase that we're not even sure exists, so I >> found the flag approach to be much more straight forward for the >> usecases at hand. > > I understand your concern and I agree! > > However, my main issue is the user space ABI part. Is the QoS flag, > that patch1 exposes, future proof enough when considering user cases > that needs to be managed by user space? In my opinion, I don't think > so. Well, I think we have the same problem with the alternative proposal (creating a new QoS value) because we simply don't know the use-cases that need to be managed by userspace. That being said, I'm fine if we drop [PATCH 1/2] for now, and just manage this from the kernel API while we start using this feature and and whether it needs to be used from userspace at all. Kevin