From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A510AC3DA7F for ; Mon, 12 Aug 2024 10:16:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:CC:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=jetBjWlaxcB1THwlxqi2YhaDriyDPW2lWzkPmfG3rNo=; b=c6aj3pxaFFoKEjFMkH79KfmxaY K0vv6tboJjmJ7SVnTbaY0sWxw7/11mbdI5oEjlZmEqRi2LtZIZ1JYGAa5Il9gzrvFwQpjoOVtkqHO FbC0yMmE66t9n015pNy0zEOxxDDdgeRP/Qrd1UTD8uByy2N/XweSJSnJo2LKZucpYxxsFuPVUM/qM ecZV+QfE+i4xeaTeswlne03heeT8T8JSVQGm1JNUIKVyF7yAfu1FkIgqB9keCxeZQMOVB8V+6O/Nn NJcn5wzaLZrIbr3aly9lcHifu2FZVc0wDjH2/bfFFnCb/i57+4nezzlvyEpbp8dh3ajqr/SuhW5Xa xmuEs9Yw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sdS6R-0000000HZoF-3Y7a; Mon, 12 Aug 2024 10:16:40 +0000 Received: from fllv0015.ext.ti.com ([198.47.19.141]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sdS1r-0000000HZFl-0fK8 for linux-arm-kernel@lists.infradead.org; Mon, 12 Aug 2024 10:13:55 +0000 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 47CABoIJ058174; Mon, 12 Aug 2024 05:11:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1723457510; bh=jetBjWlaxcB1THwlxqi2YhaDriyDPW2lWzkPmfG3rNo=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=GxosKveut4rFochjGgKtdHu8RfoG8lwgdu01ZprsjXwBU7dUP9q5GAn9UyZ1Xb1ZD qt6OU8hfXIIcRUo+m2+jho8z236iHACZ31AutpzW492Cor4v/RIN0kdf6iLbbZb0O4 EfHiiTLUxbFcFRagtUpVI6SIFjizruk+ORhEBLWg= Received: from DFLE104.ent.ti.com (dfle104.ent.ti.com [10.64.6.25]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 47CABoaO030952 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 12 Aug 2024 05:11:50 -0500 Received: from DFLE100.ent.ti.com (10.64.6.21) by DFLE104.ent.ti.com (10.64.6.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Mon, 12 Aug 2024 05:11:49 -0500 Received: from lelvsmtp6.itg.ti.com (10.180.75.249) by DFLE100.ent.ti.com (10.64.6.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Mon, 12 Aug 2024 05:11:49 -0500 Received: from localhost (lcpd911.dhcp.ti.com [172.24.227.68]) by lelvsmtp6.itg.ti.com (8.15.2/8.15.2) with ESMTP id 47CABnaQ117106; Mon, 12 Aug 2024 05:11:49 -0500 Date: Mon, 12 Aug 2024 15:41:48 +0530 From: Dhruva Gole To: Markus Schneider-Pargmann CC: Nishanth Menon , Tero Kristo , Santosh Shilimkar , Vibhore Vardhan , Kevin Hilman , , Subject: Re: [PATCH v9 4/4] firmware: ti_sci: add CPU latency constraint management Message-ID: <20240812101148.wpybfhqkd2kponp7@lcpd911> References: <20240809135347.2112634-1-msp@baylibre.com> <20240809135347.2112634-5-msp@baylibre.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20240809135347.2112634-5-msp@baylibre.com> X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240812_031155_353300_741E84DC X-CRM114-Status: GOOD ( 22.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello, On Aug 09, 2024 at 15:53:47 +0200, Markus Schneider-Pargmann wrote: > From: Kevin Hilman > > During system-wide suspend, check if any of the CPUs have PM QoS > resume latency constraints set. If so, set TI SCI constraint. > > TI SCI has a single system-wide latency constraint, so use the max of > any of the CPU latencies as the system-wide value. > > Note: DM firmware clears all constraints at resume time, so > constraints need to be checked/updated/sent at each system suspend. > > Co-developed-by: Vibhore Vardhan > Signed-off-by: Vibhore Vardhan > Signed-off-by: Kevin Hilman > Reviewed-by: Dhruva Gole > Signed-off-by: Dhruva Gole > Signed-off-by: Markus Schneider-Pargmann > --- > drivers/firmware/ti_sci.c | 22 +++++++++++++++++++++- > 1 file changed, 21 insertions(+), 1 deletion(-) > > diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c > index 5cbeca5df313..481b7649fde1 100644 > --- a/drivers/firmware/ti_sci.c > +++ b/drivers/firmware/ti_sci.c > @@ -9,6 +9,7 @@ > #define pr_fmt(fmt) "%s: " fmt, __func__ > > #include > +#include > #include > #include > #include > @@ -19,6 +20,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -3639,7 +3641,25 @@ static int ti_sci_prepare_system_suspend(struct ti_sci_info *info) > static int ti_sci_suspend(struct device *dev) > { > struct ti_sci_info *info = dev_get_drvdata(dev); > - int ret; > + struct device *cpu_dev; > + s32 val, cpu_lat = 0; > + int i, ret; > + > + if (info->fw_caps & MSG_FLAG_CAPS_LPM_DM_MANAGED) { > + for_each_possible_cpu(i) { > + cpu_dev = get_cpu_device(i); > + val = dev_pm_qos_read_value(cpu_dev, DEV_PM_QOS_RESUME_LATENCY); > + if (val != PM_QOS_RESUME_LATENCY_NO_CONSTRAINT) > + cpu_lat = max(cpu_lat, val); > + } > + if (cpu_lat && cpu_lat != PM_QOS_RESUME_LATENCY_NO_CONSTRAINT) { > + dev_dbg(cpu_dev, "%s: sending max CPU latency=%u\n", __func__, cpu_lat); An interesting observation was made which caused us to suspect this code, the CPU on which the latency was actually being set was not being printed here. It was always the cpu3 cpu cpu3: ti_sci_suspend: sending max CPU latency=100 If you look at how this print comes, it's always after all the cpu indices have run, so by then the cpu_dev value will have always become = nproc in the system. This makes debugging it confusing. -- Best regards, Dhruva Gole