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 6236E1C5488 for ; Fri, 20 Dec 2024 14:20:44 +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=1734704446; cv=none; b=VdaDx2BMG55W/79zuondqVkM4tSXUasIVACBvQgoqj4OGKXbObiBkcCVLnrulJ1jYNAYyajnWpRehwx0ChflmnBLo97obLV2tmLhpBekafjpRFISaFa4dNJA1bL5Zx+d1HlTi76rnLuTfNXs9Ke/p7yzzcmBNLU3Gm9Pmv5cEKU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734704446; c=relaxed/simple; bh=qFIYTw50g8omFtQvU7ugZUUVqMyxaMbXhyvAVRJJbKY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=USpLLofLSXYvfBL9p+c/tiUiRqPqWBd4kXpo7ecMqA8XTf9Mk06QQ5nL+eXa4CjgQJhGv/LTrPRuombXSqQ41CCg+8hOeUZPqVFBoM4SFsojwAhY/OsGN9S/GB44CGiPpkxGk64E5tdSH6vVzcRXTJovDrWipYYpGyXVy78OFTw= 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=ZgX4FUs9; 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="ZgX4FUs9" Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BKA4XiR016204 for ; Fri, 20 Dec 2024 14:20:43 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= oF9Gt4jUsSVFBsboD3SxXYWnqJhf/Ez7AfP4JxIL9eQ=; b=ZgX4FUs9pJIBi5/4 N5RTz48QS+/ZDy1iR/Sohak4vi9HVcCFpWqzjHtXA6rkcb+v3EZw7ONVh0DAB/ik ToCXxPOWACFb2PqSqeKNTPZTR8aEOE2IK75U60Duj+FjgfGpVua4G6EsmbRqvpcg 4d1tr1OZyMDAohbGnQiPUThqzLnya+rcYA6lVcZ9TMrCkNDLGgBqpgMUGUW6i23A dTr4kAJWpgDcTqlUkCrJ1Ddf232qxOZjC4+LHCMUdgwBuco2RodhwVmn3Kequn0s VDTALlvA383TtGnChnbyRgulk43KhwslaHNAdiiGANEQOO2UjqWQG9hTc+SzvelX yrzEVg== Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 43n6gugkm8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 20 Dec 2024 14:20:43 +0000 (GMT) Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-6d88fe63f21so4670726d6.3 for ; Fri, 20 Dec 2024 06:20:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734704442; x=1735309242; 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=oF9Gt4jUsSVFBsboD3SxXYWnqJhf/Ez7AfP4JxIL9eQ=; b=aBQ5QRkQsL5TY0vofKV9qWVzFlGzn2VLLHHDN403ECPtJ1/WIRwrO+5dnUt1zptJ0F Nn50jzMvlXmrV/m0zmxj+B0w1pO0LDR4FWhMacIi2YScNW2yFEQsR+avjU+u9ROcE4qo CIq3qfvD6rtDCnbij0MfO69X9VPdcmMakwJ/mJxc6BUS2yBbl5WSNhLHz9KDlX0oVDIQ 3SxXpiOQS4NC57GmCnT/Z/KrXzzSUferuTMSJB5ll7CqGdKXeeMOr1MVdnMARr/y81FE V/mxJPA7/Fjo6e0UOGP3hazqLdsAu1pwX2MaM38wO9n1zC/otWQmNancJlzfAqKn+jHK Zu9Q== X-Forwarded-Encrypted: i=1; AJvYcCX4fFobPBbrFC9jpW8jd/pjMxShobGrDUkxaJ68PwTY0T04UXCotA+Ok78Qjf4u7JYRw4VskvBseme6gZc=@vger.kernel.org X-Gm-Message-State: AOJu0Ywyn5GK8N0yiCYVw7DXwuvk68bFJZ1BXxDDCQlnshqpft5+oAJM CU9NTotoAZhSMS+BZrBhDTgCLzmIf2h1xXXirhyHrx8IwE1IeLVVzom/Mq61sqEUakp5ZkK2j+H 8QPtpQmdRYclV2TcZ3KTqy0MWkt3bM0rbGBLD8nhwIHUpehMy8igbSfEnDkYAmAs= X-Gm-Gg: ASbGnctSGgJBpnnaiz0F+/TH5IUMJ/1uu+sL5ZJ4KgsQGl8pO77KVHWYHUmuU6qvf1i mjOV2+XRzjGXb++nnhz7ShzT5CKAn2jhKEzOSz+7SPEImJJR2EJAmtzJsE4uqs7E02PrE3RI9zP xJzWVOgotbxcWHd/7FRjHoU11aMTveSBJ8zaZV0n0i1URnfMJ13v5Oy6P5Iq0OW7N6QEwnukDmY EiaaBU0NxNNo76pJGZO8reMNIQHCwzI3bB6JlVXxgyf/zRZhu0ZVMQ6EeAc78727GHnOAdrv1Kv v8ACRCSTPEwNEBUqWIWHJ0Q9c0C2yGa8RQw= X-Received: by 2002:a05:6214:3c9e:b0:6d8:b66e:d26a with SMTP id 6a1803df08f44-6dd233b1640mr17010626d6.7.1734704442226; Fri, 20 Dec 2024 06:20:42 -0800 (PST) X-Google-Smtp-Source: AGHT+IGx88afG3o45UtefzCawfy2RE//adxw/WGB3ljEGjNT53HTDF4pUUmWxMynUrzD3E+f8jCNOA== X-Received: by 2002:a05:6214:3c9e:b0:6d8:b66e:d26a with SMTP id 6a1803df08f44-6dd233b1640mr17010446d6.7.1734704441799; Fri, 20 Dec 2024 06:20:41 -0800 (PST) Received: from [192.168.65.90] (078088045245.garwolin.vectranet.pl. [78.88.45.245]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d806fed752sm1845135a12.54.2024.12.20.06.20.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Dec 2024 06:20:40 -0800 (PST) Message-ID: <875342b7-3825-47bf-810a-effdbeacab46@oss.qualcomm.com> Date: Fri, 20 Dec 2024 15:20:37 +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 0/3] Allow specifying an S2RAM sleep on pre-SYSTEM_SUSPEND PSCI impls To: Sudeep Holla , Konrad Dybcio Cc: Elliot Berman , 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> <20241113165329590-0800.eberman@hu-eberman-lv.qualcomm.com> <765bb1c8-31de-4aec-b8ef-f141a3e25c56@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: YUyT9D4l3VJuvbAEBTFPfr57tcSP0z53 X-Proofpoint-GUID: YUyT9D4l3VJuvbAEBTFPfr57tcSP0z53 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 phishscore=0 spamscore=0 impostorscore=0 lowpriorityscore=0 priorityscore=1501 bulkscore=0 clxscore=1015 adultscore=0 mlxlogscore=999 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2412200118 On 20.12.2024 2:58 PM, Sudeep Holla wrote: > On Fri, Dec 20, 2024 at 01:42:04PM +0100, Konrad Dybcio wrote: >> On 20.12.2024 12:39 PM, Sudeep Holla wrote: >>> On Thu, Dec 19, 2024 at 08:26:51PM +0100, Konrad Dybcio wrote: >>>> On 14.11.2024 2:10 AM, Elliot Berman wrote: >>>> >>>>> I'm not sure why you'd like to support s2ram. Is it *only* that you'd >>>>> like to be able to set pm_set_supend/resume_via_firmware()? I hope this >>>>> doesn't sound silly: what if you register a platform_s2idle_ops for the >>>>> relevant SoCs which calls pm_set_suspend/resume_via_firwmare()? >>>> >>>> S2RAM is what you get after entering a certain state, but currently >>>> it's presented as just another (s2idle) idle state. >>>> >>> >>> Just to be clear, I assume you mean CPU_SUSPEND idle state. There is >>> no special or different s2idle idle states IIUC. >> >> Yeah, right. >> >>>> That means some hardware that may need to be reinitialized, isn't as >>>> Linux has no clue it might have lost power. >>>> >>> >>> Interesting, so this means firmware doesn't automatically save and restore >>> states yet exposes it as CPU_SUSPEND idle state. >> >> Reading the spec, I'm pretty sure PSCI calls should only mess with the >> power state of the cores, core-adjacent peripherals and GIC. >> >> Reading section 5.20.1 (SYSTEM_SUSPEND / Intended use) I think it says >> mostly what I'm trying to convey: >> >> >> "In a typical implementation, the semantics are equivalent to a >> CPU_SUSPEND to the deepest low-power state. However, it is possible that >> an implementation might reserve a deeper state for SYSTEM_SUSPEND than >> those used with CPU_SUSPEND." >> > > Yes these text help to understand the interface easily. If they were same, > do you think we would have defined 2 different interfaces. I would happen to think that, yes. Especially since the reference firmware implementation does *exactly this*: https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/psci_main.c#L179-L221 PSCI_SYSTEM_SUSPEND seems to be simply meant as a wrapper around a specific CPU_SUSPEND state (which may or may not be only callable from inside the firmware when SYSTEM_SUSPEND specifically is requested, for reasons), in a platform-agnostic way, so that the OS can enter suspend without providing that magic StateID on all supported platforms. But since it already requires more elbow grease on the peripheral IP side, I'm not really convinced it's that much useful. Plus, the optional bit of doing more work behind the scenes doesn't seem to be very wildly used across TF-A supported platforms. So please, stop making the argument that it's any different. The firmware I'm dealing with simply didn't expose the same thing twice, in perfect accordance with the spec. Konrad