From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (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 A4FFB2D7DF3 for ; Wed, 28 Jan 2026 23:51:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769644310; cv=none; b=ZdYibOCMVnzYxYl/UtGodi11Z+ktedtXbHSpDV9npiLy4wyFA/6RzC6zIhvIVazCoNoQPSdeEcB4BC2id5skfAdDoR4RU1xiyhBMPEi9CplU3U8tjbPzkTTKjbJXk9olmgatSbArbcbVh1kqtHbTWjv7371s5HtzZ9mHIKVQC4U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769644310; c=relaxed/simple; bh=SNnWGRxtwRaXMgkJWx8mnXztZQGfXNSAxvSbqw6z/YM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=lRgwyaIhy9+dq47tLUXimNQ9Mm0+5+q6iOIDmj2o463CN3uVDINUkQ9WEjRvYIQHSeKjIlWi7MW92nykVX8Ld4ra3PjBWKBuyh3/6Fkz/6otBG8CJ/LlU2sgF/Dnu6jQap7IOKVCSmc58fHI1EaeIpSF0rpKOu5a9hvupepjvdw= 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=RSpVi+PC; arc=none smtp.client-ip=209.85.214.173 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="RSpVi+PC" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2a0c20ee83dso2749725ad.2 for ; Wed, 28 Jan 2026 15:51:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1769644308; x=1770249108; 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=8EznR4U20DzXv1n4K0tPEIv8qaghM500zv7iNQ5zGtc=; b=RSpVi+PCyR7ESwvM7F4RcgiouTN0K9odi4ttFJ8Jk8XxgXd/mEI7QxrQ94ElxRLY76 GhT/xWuJtuNl22y4bFbUF+T7oW+aqwCdTp+tGSPICJXePYJNnziCaXWRFEdlq04tooIh Wp46OvE/M2JmF7TydkcUhS6O8JVmITfGKWNGQiZD1/O/CJz44Eqhf7TEdkD7ZZOmYjox dMPTpuUi8ShzzO6zChgAmiXubESRoGDLwlHr/zq6M2wUJntFYl5HekgCf95bP2mn8y1Z xKCuLOXcY5fXxwZ7GfFEBTh6MdNrdhljgiiDjc0B6g5nBTfVoIZ/4RN2YLNrHDszn2t7 5Pog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769644308; x=1770249108; 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=8EznR4U20DzXv1n4K0tPEIv8qaghM500zv7iNQ5zGtc=; b=LwAZToya6uvz/3eSjumnzocVxTyY1MgzDcDbDpJvnNN5rREKoD8Sz31bI1dMEgT1Ol xVqLIaLLOGfNTHah/aG/iUAeLHt7Is74cBE/MdbWZctDkbd6Q1vUPLHdZYV93JmvrKDY 0O5SA+A4wiiagLrBSb3X1zhzn0pZmRilcmRFAFvxitWvwFOsNGbUJSYX4Bx2ylfezWiQ T49sxsPb4fOvhZl5k3vbByjCL1BbONzh753eWR4Xlszeywbi+urJFZeAsy69xOKJMzA2 7Ntbfi2sHRRtl4+EtE+ATvop8ghPfKnsTNQ8Gbhod9o99dPSZg1QNrTjOq6gbdIrSx4k e8MQ== X-Forwarded-Encrypted: i=1; AJvYcCXLzbHsGHgaYGUdHS0ntMwCLXUbCofhlhyYkRwVjydp3bFreV2yPp+TKjTYDuE80y3TTaJ9rRxZmoqjsI8=@vger.kernel.org X-Gm-Message-State: AOJu0YxjhiYRkg44c+LrnLyTSwiG8SDgj5NFhEBuR0jIF/AmrlRsmvKp EaEixF+xvx3981Ub9G0rJS/7jzfRk0AgxtErvnqAeis1IKAiPP/XrIvWqH5T9Znd/Ws= X-Gm-Gg: AZuq6aJXSJbGciCyz5FSENzF6yvdRrDrHepekc+afC7nLXgUGFLoVXdtCZaEYOU8txW KjLDCMnw99P4iRFhCqrYEHq5k/e5LzBgVsNVLvXo1xXSaTXYns/VylkWqrm2L5f744RcNX5B4Wf 5bTjg3w9AiwHEh7KhuXgNeBOuOQIST914vrNl0rHt2NAbwtpDvDaxBEHxRpR92TrdzuXLUpYfxo q57BoJScRlz3Nv2D4da+y+GOmu4HTUnlLUFjeRf7G4vf/KUyk0Y4dnwEWuv9EmEk4Z7ZAocUGaR S0HflY8T2gY+ScUb72NqhDMrtaNA+MyPmG9QABPqitsYhuwPSEBbLUEHgzhZOwyNQW1lGT19vDm wAdpuyPM54W+yZzRtkdKP86SHd0207MZZXRoVWq0tZlc8S+ZGhRu0PkajhrLUjUtL4axoGxt5xv PGXF9YwZcr X-Received: by 2002:a17:903:2f87:b0:2a2:bff6:42f5 with SMTP id d9443c01a7336-2a870d334bfmr52735505ad.8.1769644307921; Wed, 28 Jan 2026 15:51:47 -0800 (PST) Received: from localhost ([71.212.200.220]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a88b4c4665sm33664905ad.64.2026.01.28.15.51.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jan 2026 15:51:47 -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> Date: Wed, 28 Jan 2026 15:51:46 -0800 Message-ID: <7hh5s547ot.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 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. 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. Kevin