From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8940A19E985 for ; Thu, 19 Dec 2024 19:23:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734636233; cv=none; b=i/bZzkaScH60kqPdvqSUKfEeSrBR7/paoqtSjLome0+IVS77Itt9RMIN1Zx2QD2ZfSjFnAv1PdFr9hCu/eNKCs8EuEjw+skpcgF2JYaxul6ZPldeh6CNdF4akaZm2i2Xa2aYr6QJxf2sUcQAOXK8GnGajfTHrZOaiWDEW90kJvY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734636233; c=relaxed/simple; bh=nNXw7c6zswaVsQyCI0bJK+h1nBx5470yLS/fQZ1qXEo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hHVFIz2MhreIS/GJUPn5o+5E6MptEJjKPvUmq6gKVukyNzMZTSgl6Q+s5JH5b9vyRd/lJcKxscY5IjjyoAqlGAGJWcK5UpUp5+FaYE8HeUmNtQLIfim5a931LE1hG8oOS1W1p2HnoyYTfYcdVPJ1xxr7B/sejUMLXgR4xaXU740= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=FWgzBYxR; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="FWgzBYxR" Received: from pps.filterd (m0279871.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJGHCv6011898 for ; Thu, 19 Dec 2024 19:23:50 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= 6gocZlng0p/reM2Z0HZmLyZtSompFACzks2JqqAmCik=; b=FWgzBYxRtam4oByW bKWLBbGsOHieOnUPWxryGwXo1P9eOM/nUNg+f38E62VtVvOiNaL5+R4Q/0l/SJLS Vt5uCH5oSKAJy/+MDBflWEuB7wIrcvQMY7Ukj1jWcSciGfSi7/2ZyCpUi3MhM/mj 3lTtbE36Zy2XsdvhAlJsvuhAL6URK3EjstGcLlsmm+2fHfpcZFjbvujZ9AX0QBzz TmC1JDWPEpNgsuhmYXbcy5FLzvjKLRTikHC8FKK6AKR43PxyJsaOHoQF8UA1ghOM S7GuCf1HYz38M98GxQV9DB7SZ0wnhyEGfQOft+YFVWaG7jqpiKhEyXXMwcqXmEYK SaL3Xw== Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 43mpvageqk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 19 Dec 2024 19:23:50 +0000 (GMT) Received: by mail-qk1-f200.google.com with SMTP id af79cd13be357-7b6ea8fc9acso12066085a.2 for ; Thu, 19 Dec 2024 11:23:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734636229; x=1735241029; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6gocZlng0p/reM2Z0HZmLyZtSompFACzks2JqqAmCik=; b=hzSdWGds88f4t7fZ+Hz1Khzzcx3cG7vBWvw4kL92VfFKgHgs11l9LymEKMkNhn30sf FUYBIe/v38MeG375XnMSfuYTvBRc9FAo5DJAGnK3foJch1q3V4dflIqtOUyts2ZKhyfn 5OHVFmskyezPEnpI2R2662AIpA0v09qMx+IIkSl40csIpBbzeAfLlkZfwS69vbP+9lx3 b5l0M2ZhZOSM+ybYntM9czBsqVeseOjQAwVK8bffr344DmUxZOofzsG+LtMVM2L7rybq eZwRpIBgOLi89xUce7HzzWYsB7azAIwvERSZfa2s6cdMsQF8BklEEqnhYwYDvfL3KHEa ieUA== X-Forwarded-Encrypted: i=1; AJvYcCWacZMs2+7Q6ObpEo9cRyr4oh4t/cxzH32Fp4dNIdKkxwSOfQyQ5moTvJtu6BjqIxZERCnjUWhHosPJ75g=@vger.kernel.org X-Gm-Message-State: AOJu0YyYuHysffqRONRPrz5vbrEwCZlv/ooIExS7ExLulQn2hkwJp9LY 3QY+cSbhhnZOiOMPxaqPqo/5MMgVvVcz7d0Jk5j2czbqHxQgPJ5slS5CvS2s4ZuSYfWwLwAv02d LUXYYuOOY0ff1WD5oM46KExvtzJfQYsfxyJSYRYeSmH7LQIwGlPm1FY0XPIfi3FQ= X-Gm-Gg: ASbGncubu3DGS3NOAsZZSdlByLyQ8hWA9Oi9kWZECS1CBrc50Jbit3Nj7vqkU/i25n1 gttL/d8Fy/0WEYHXZAlHNC0ZtZxVJ8mFb4p7ZkA7dolWUkEZP6HjQVY9eVRDaEKOKDwGThsPH3q 2NbdBKGEH5I1iBBL0nTrRDuJh5KxmoCx4bRQkaLbZbFwC1yFQ8fKS7CpZF17a6UuRmCO8RzPfyY eJCJjTaTbw+OzX1B2dtOOVGGKFn5h2s8GBIj5xT+iOB6tZIOFm/foya4zOei2RwUWWcivEvKrlV LK5IC/PSIDI+6xv6IiLenuyixvCqj2yrNhQ= X-Received: by 2002:a05:620a:4511:b0:7ac:b95b:7079 with SMTP id af79cd13be357-7b9ba7aae17mr4554485a.10.1734636229536; Thu, 19 Dec 2024 11:23:49 -0800 (PST) X-Google-Smtp-Source: AGHT+IFM1BPlEJFAs9IGgICkS3iH2K9v9JTl8Ae4oc+exXVBSbnnU5Tx2jQefnOYgBTNxPPEtT3yjA== X-Received: by 2002:a05:620a:4511:b0:7ac:b95b:7079 with SMTP id af79cd13be357-7b9ba7aae17mr4552285a.10.1734636229107; Thu, 19 Dec 2024 11:23:49 -0800 (PST) Received: from [192.168.65.90] (078088045245.garwolin.vectranet.pl. [78.88.45.245]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0e82f828sm95661466b.19.2024.12.19.11.23.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Dec 2024 11:23:48 -0800 (PST) Message-ID: <761f93a0-5894-402c-b39a-ce9a65707a55@oss.qualcomm.com> Date: Thu, 19 Dec 2024 20:23:46 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] firmware/psci: Allow specifying an S2RAM state through CPU_SUSPEND To: Lorenzo Pieralisi , Konrad Dybcio Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Mark Rutland , Marijn Suijten , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Bjorn Andersson , Konrad Dybcio References: <20241028-topic-cpu_suspend_s2ram-v1-0-9fdd9a04b75c@oss.qualcomm.com> <20241028-topic-cpu_suspend_s2ram-v1-3-9fdd9a04b75c@oss.qualcomm.com> Content-Language: en-US From: Konrad Dybcio In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-ORIG-GUID: k3BN-1b8TVgLW8AQxoSP2i83vK-SZV8u X-Proofpoint-GUID: k3BN-1b8TVgLW8AQxoSP2i83vK-SZV8u X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.60.29 definitions=2024-09-06_09,2024-09-06_01,2024-09-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 malwarescore=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 clxscore=1015 spamscore=0 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2412190154 On 13.11.2024 1:57 PM, Lorenzo Pieralisi wrote: > On Mon, Oct 28, 2024 at 03:22:59PM +0100, Konrad Dybcio wrote: >> From: Konrad Dybcio >> >> Certain firmware implementations (such as the ones found on Qualcomm >> SoCs between roughly 2015 and 2023) expose an S3-like S2RAM state >> through the CPU_SUSPEND call. >> >> This works exactly like SYSTEM_SUSPEND. The PSCI spec describes that >> call as optional (and only introduced in PSCIv1.0), so not all >> platforms expose it. >> >> Marking a DT-described "domain-idle-state" as such isn't currently >> well accounted for in the PSCI idle topology infrastructure: the >> cpuidle and genpd framework are deeply intertwined, and trying to >> separate them would cause more havoc than good. > > I don't understand what you mean here please elaborate. > > The part of the story I understand is that you have a system (well, > firmware for an extended set of systems) that does not implement > SYSTEM_SUSPEND but can reach a S2R like system state through the > CPU_SUSPEND call. Firmware works in OS-initiated mode, idle-states > should allow you to define idle states that allow the system to > enter the S2R state through CPUidle. > > Please explain to me what's missing. > >> Instead, allow the specifying of a single CPU_SUSPEND sleep param >> under the /psci node that shall be treated exactly like SYSTEM_SUSPEND >> from Linux's POV. As a bonus, this way we also don't have to fight >> with the genpd idle governor to avoid taking the S3-like state into >> consideration. > > That's not acceptable. I want to understand what's preventing this > system to enter that state through suspend2idle and the mainline code. The answer to both is: Linux doesn't get to know we're entering a S2RAM state and can't make different decisions based on that, if said low power state is exposed though cpuidle. We e.g. can't expect all hardware to come back up functional after entering such state. Konrad