From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.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 9ED8A7D07D for ; Fri, 20 Dec 2024 12:54:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734699292; cv=none; b=Y46bAqWN9GoDhNsr/0a9MOHdP3Y1fyFRvz2vk9WEpdM6Vk9g9YUoRAEObK0nYq+iUvNMi7Mt9NOlvhQI/imeNDE4IEM9TdDeoARWS7tFHK0r/nj2Fzgnzyi1GCRKZlBkCMDxgJ4PCHOZypxJrMTbjfrmf3PDKW/NQY+UPcv+/4w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734699292; c=relaxed/simple; bh=Pe8SHXyg6eYI2kthWaJBClGql2i+k6hNjsS3CXqFy5I=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=c4sciWMNj90v4eUwj4YArmLjKFJbYj+tNKYQBJnuFMyNxB65QpkPtM0lRmZHNCxcPzzoI48dxHdPd6CalMjrW5P+nA96XmV/WevgSWflbyJLXh3HOHUIX/8Ytbm7KfbIWxumRsuleiOnep3QKVIsfpwga7BeuCEWSAftvxWi49M= 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=pmX18UQL; arc=none smtp.client-ip=205.220.168.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="pmX18UQL" Received: from pps.filterd (m0279866.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BKAKYhp002763 for ; Fri, 20 Dec 2024 12:54: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= 1glOxkn1IDIgd0UCki0Nf++sUdgcqfIdre3vsIotpyM=; b=pmX18UQLuSX88CLk MhVSc8dtXRsGWf5WGvy24lwct93xuTUWxTcYx7aSEmCufyVckvc9OFXxu4XmUNdN fwxel1A1agJy6GkzT6oSUzLZZxWfPOa/bcv3vi14h0ypmagBA50Rfec1KCnbnGbo vU1z8lvQrIvcsnaGrharGpXuFKE2NLrMB2XD1FrFJbyT3UB0wPyGRVwpMyk+w3w5 1GjAajYsYOqXkcxUmo6KPrc2bljVR09YTXQgVL+s7L1DqUVnFVDdCYDdkBZn7d4P UCBY8+xEI2amEkFSAx7ik3VHyDxbwepGkAjxe/GOhLh4wlTrNbpPIgX8EjoU/KWI uR9fWQ== Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 43n6ra8bft-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 20 Dec 2024 12:54:49 +0000 (GMT) Received: by mail-qt1-f199.google.com with SMTP id d75a77b69052e-469059f07e2so4163451cf.3 for ; Fri, 20 Dec 2024 04:54:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734699288; x=1735304088; 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=1glOxkn1IDIgd0UCki0Nf++sUdgcqfIdre3vsIotpyM=; b=c340/MkTI1p8zpTdPJgIr7P0eEkHLJI49bogQwXjqNXAPTj/Fn/W4ixij4idq5Yej+ qDhcHA1oHBrluNb4FXDy5gQklPYAf8cpAsYJrJsx0fRYMNVox3PVbDZfaaknBiwbundL 3X5aN98h4q4az6kPtlidO6zuhZUwATPqgY8YDE84DlzdztPJlekv0TJ0DQTI7lbCPloD p+TOz62ZGMNkq4PSh5KZs0biwIewM2d+h2lRSHsGG8bRKQ5nKhhjmK+BkTn+fx/YgdDP mn7uoKmqFWYH7tQ50ndkhh59W1XVFpPEwS5sMkgbb82bQfWDkv3tZDqziUrWzdTYpZ/i xabg== X-Forwarded-Encrypted: i=1; AJvYcCVg17COVGHQBN2MUY3FnbcuUJdTfkPfrwWMsuLGfY21mp8d5i8osQ8ptIEgGZAP6KbMkc4/pMRW9HazL9g=@vger.kernel.org X-Gm-Message-State: AOJu0YxwIp4WW6hFHNF37SZPExvI9K+4c5T7ycpImxRBprentF9mgibT qLjSLz2Q28AHJmsv3fxObrY39K08ef3WHaN1NXtu2tmsZ1PpHea0A6U6yUUa7NpMhk76oXLVY/y y3vPPLx2/kjh81EQX0Qz/uY1RIQpJdGjME0coLGyFubxqvZ/6PLR0KIhy6IyIy+s= X-Gm-Gg: ASbGncvrJ9H5Sf25n5xMeBVhSBEo8tMdgjpwuGbHCpgLEjZndjCStQl+PCssHDiB38m d7pnXWJ1ncKpvQ5J9UFRX+PJTegdXE8lnYwVsvBTIwmtBvi/DJOh1IBM0d8wJ9Anx1JxxeuH3vG owRWLR9d4f5zF7FQsW22MxZYRO/WBh7obVnlHfyDNwRWxWqkSFtCt9fmPfQCpON+2DhvZfkc7M5 67c9nOs6qG+IHTVR/ziB3RiGF6F0NwOlpksoSglqjEihH0BCC3JJC0QSt0XgHtZBcpFdGTIxRzZ V3ax+TXDmcc3H7i7xx7A6ZSgdbtPume0ALo= X-Received: by 2002:a05:620a:1999:b0:7b6:d252:b4f1 with SMTP id af79cd13be357-7b9ba7c8376mr131313785a.11.1734699288405; Fri, 20 Dec 2024 04:54:48 -0800 (PST) X-Google-Smtp-Source: AGHT+IFauhfwJ3WJ9nZ/J7KQQZfJVN6/UgwZW5dzxwD9LiwBWG5nYGkVE6qtjqC+2RPuPXzjDKtKTw== X-Received: by 2002:a05:620a:1999:b0:7b6:d252:b4f1 with SMTP id af79cd13be357-7b9ba7c8376mr131312185a.11.1734699288018; Fri, 20 Dec 2024 04:54:48 -0800 (PST) Received: from [192.168.65.90] (078088045245.garwolin.vectranet.pl. [78.88.45.245]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0eae71desm172876166b.89.2024.12.20.04.54.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Dec 2024 04:54:47 -0800 (PST) Message-ID: <349bac70-87e0-4870-a3f0-9f6a3b3e6824@oss.qualcomm.com> Date: Fri, 20 Dec 2024 13:54:45 +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 1/3] dt-bindings: arm,psci: Allow S2RAM power_state parameter description To: Sudeep Holla , Konrad Dybcio Cc: Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Lorenzo Pieralisi , Mark Rutland , Marijn Suijten , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Bjorn Andersson References: <20241028-topic-cpu_suspend_s2ram-v1-0-9fdd9a04b75c@oss.qualcomm.com> <20241028-topic-cpu_suspend_s2ram-v1-1-9fdd9a04b75c@oss.qualcomm.com> <54cc4221-ba5f-4741-9033-20874265ca01@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-GUID: saeLSjwLfDLda_RBYu8l1LUSeMf98ASJ X-Proofpoint-ORIG-GUID: saeLSjwLfDLda_RBYu8l1LUSeMf98ASJ 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 mlxscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 malwarescore=0 lowpriorityscore=0 priorityscore=1501 phishscore=0 impostorscore=0 adultscore=0 clxscore=1015 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2412200105 On 20.12.2024 12:27 PM, Sudeep Holla wrote: > On Thu, Dec 19, 2024 at 08:43:27PM +0100, Konrad Dybcio wrote: >> On 6.12.2024 11:21 AM, Sudeep Holla wrote: >>> On Mon, Oct 28, 2024 at 03:22:57PM +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, as opposed to exposing PSCIv1.0's >>>> optional PSCI_SYSTEM_SUSPEND. >>>> >>> >>> If so, can you elaborate why s2idle doesn't work as an alternative to what >>> you are hacking up here. >> >> Please see other branches of this thread >> >>> >>>> This really doesn't work well with the model where we associate all >>>> calls to CPU_SUSPEND with cpuidle. Allow specifying a single special >>>> CPU_SUSPEND suspend parameter value that is to be treated just like >>>> SYSTEM_SUSPEND from the OS's point of view. >>>> >>>> Signed-off-by: Konrad Dybcio >>>> --- >>>> Documentation/devicetree/bindings/arm/psci.yaml | 6 ++++++ >>>> 1 file changed, 6 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml >>>> index cbb012e217ab80c1ca88e611e7acc06c6d56fad0..a6901878697c8e1ec1cbfed62298ae3bc58f2501 100644 >>>> --- a/Documentation/devicetree/bindings/arm/psci.yaml >>>> +++ b/Documentation/devicetree/bindings/arm/psci.yaml >>>> @@ -98,6 +98,12 @@ properties: >>>> [1] Kernel documentation - ARM idle states bindings >>>> Documentation/devicetree/bindings/cpu/idle-states.yaml >>>> >>>> + arm,psci-s2ram-param: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + description: >>>> + power_state parameter denoting the S2RAM/S3-like system suspend state >>> >>> Yet another NACK as this corresponds to PSCI SYSTEM_SUSPEND and as per >>> specification it takes no such parameter. This is just misleading. >>> >> >> Yeah PSCI_SYSTEM_SUSPEND takes care of this on platforms that expose it. >> > > And those that don't advertise/expose don't get to use, simple. The spec says: "The call is equivalent to using the CPU_SUSPEND call for the deepest possible platform powerdown state." so by that logic, I'd rather call implementing PSCI_SYSTEM_SUSPEND in Linux unnecessary bloat.. >> DEN0022F.b Section 6.5. recommends that CPU_SUSPEND StateID includes >> a field for system-level power down states. This binding change only >> adds a way for DT-based platforms to associate such state with S2RAM >> suspend. >> > > Sure, just use the CPU_SUSPEND bindings that already exist. No need to > define this as some special case if it is exposed as CPU_SUSPEND idle > state. Not sure why you want to do it differently. I understand the > need to handle it different in the kernel, but I don't understand to > define the new bindings for that. Just use the existing bindings for the > idle states. Again I see no exception for this case. The bindings exist for core/cluster idle states. This whole series tries to include a system-wide suspend state that has no business being described as a cpuidle one and depends on more than just the CPUs being powered down. >> That may be a bit Linux-specific whereas bindings are supposed to be >> OS-agnostic, but since we effectively want one PSCI state for deep >> suspend regardless of the OS, I would think this kind of hint is fine. >> > > Exactly, that's the reason for not changing this into special case and > special binding for that special case created. I simply don't think it's fitting to lie about system suspend states being just CPU idle states, see above. Konrad