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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6FECBC433F5 for ; Tue, 26 Apr 2022 03:28:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242952AbiDZDbj (ORCPT ); Mon, 25 Apr 2022 23:31:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48492 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232679AbiDZDbf (ORCPT ); Mon, 25 Apr 2022 23:31:35 -0400 Received: from fllv0015.ext.ti.com (fllv0015.ext.ti.com [198.47.19.141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3EBC3669E; Mon, 25 Apr 2022 20:28:27 -0700 (PDT) Received: from lelv0266.itg.ti.com ([10.180.67.225]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 23Q3SHWa089998; Mon, 25 Apr 2022 22:28:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1650943697; bh=+o6NhAJsTjHg2+8VyeHYHIdbFc/RG121uOxauMu/fng=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=pN/GsGgaKCeExUssIz/hOMcsZzySVM+kiEsCYDU1ThMGxpkFPXfKG3V67NrvPJCWO xuMhKB5B3ucZVcv+S6i61ETnkRGseFlGdH5e1cBtasXJOydkolc/+3w4blR1BE/uir SLpd4WqzRLN18xLzht6fJ2N+iHRgtYnifiKzX3do= Received: from DLEE115.ent.ti.com (dlee115.ent.ti.com [157.170.170.26]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 23Q3SHgJ104849 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 25 Apr 2022 22:28:17 -0500 Received: from DLEE111.ent.ti.com (157.170.170.22) by DLEE115.ent.ti.com (157.170.170.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Mon, 25 Apr 2022 22:28:16 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DLEE111.ent.ti.com (157.170.170.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14 via Frontend Transport; Mon, 25 Apr 2022 22:28:16 -0500 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 23Q3SGGk032680; Mon, 25 Apr 2022 22:28:16 -0500 Date: Mon, 25 Apr 2022 22:28:16 -0500 From: Nishanth Menon To: Dave Gerlach CC: Andrew Davis , Rob Herring , Santosh Shilimkar , Krzysztof Kozlowski , Tero Kristo , , , , Vignesh Raghavendra Subject: Re: [PATCH 1/6] dt-bindings: ti,sci: Add ti,ctx-memory-region property Message-ID: <20220426032816.lov27rwssipapqp4@causing> References: <20220421203659.27853-1-d-gerlach@ti.com> <20220421203659.27853-2-d-gerlach@ti.com> <2528be71-ca3f-566b-4769-36063c98ee0e@ti.com> <20220423133648.jlkeyfq7gjbwij5l@bonelike> <5f9485b0-d48c-6418-dc52-a2cd57e98791@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <5f9485b0-d48c-6418-dc52-a2cd57e98791@ti.com> User-Agent: NeoMutt/20171215 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15:24-20220425, Dave Gerlach wrote: > Hi, > > On 4/23/22 08:36, Nishanth Menon wrote: > > On 14:10-20220422, Dave Gerlach wrote: > >> Hi, > >> > >> On 4/22/22 14:02, Andrew Davis wrote: > >>> On 4/21/22 3:36 PM, Dave Gerlach wrote: > >>>> Add documentation for the ti,ctx-memory-region property which is a > >>>> phandle to a reserved-memory carveout to be used by the ti_sci driver > >>>> storage of low power mode memory context. This is optional for normal > >>>> system operation but required to enabled suspend-to-mem usage of Deep > >>>> Sleep state. > >>>> > >>>> Signed-off-by: Dave Gerlach > >>>> --- > >>>> .../devicetree/bindings/arm/keystone/ti,sci.yaml | 9 +++++++++ > >>>> 1 file changed, 9 insertions(+) > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml > >>>> index 34f5f877d444..ec88aa88a2a0 100644 > >>>> --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml > >>>> +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml > >>>> @@ -61,6 +61,15 @@ properties: > >>>> mboxes: > >>>> minItems: 2 > >>>> > >>>> + ti,ctx-memory-region: Just memory-region? > >>>> + description: > >>>> + Phandle to the reserved memory node to be associated with the > >>>> + ti-sci device, to be used for saving low power context. The > >>>> + reserved memory node should be a carveout node, and should > >>>> + be defined as per the bindings in > >>>> + Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > >>>> + $ref: /schemas/types.yaml#/definitions/string $ref: /schemas/types.yaml#/definitions/phandle ? maxItems: 1 > >>>> + > >>> > >>> > >>> Why does this have to be yet another reserved carveout region, > >>> should be dynamically allocated. > >>> > >> > >> This must be a fixed address in order to support other low power modes > >> which have not yet been introduced. > > > > Please elaborate the need - Many of our devices, esp the AM62 class ones > > are memory constrained devices - LPM states are controlled entry states, why > > should we loose a chunk of DDR in operational state while waiting for > > the suspend or idle state to be invoked? > > OR, is the argument is as follows: > > - need a guarenteed memory for me to enter low power and not be > > dependent on availability on attempt. > > - Latency overhead of allocation during a "hot path" such as cpu idle, > > this is completely unacceptable? > > > > or something of that form.. please elaborate? > > Yes, in the case of some future low power modes, it is possible for the > SoC to completely lose context. For the mode being introduced here, I > agree that we could dynamically allocate this memory and then share that > address around, but keeping it fixed of course works here, and *also* > works for the complete context loss case, as a different mechanism would > be restoring this context and can easily get the fixed address straight > from the DT. Otherwise we would have two completely divergent paths > because there is no way to share some dynamic address across the transition. > > To me it makes sense to keep it the same for all modes when possible. a) Clearly this does'nt apply to all SoCs supporting ti,sci. Can we make it more stringent? b) This is a hardware description of a memory region that is carvedout for context information and maybe used as part of various LPM modes where restoration needs to occur prior to OS startup (and dynamic handshake can occur with the entity that manages power controls). I think this should be clearly articulated in commit message and description to help understand the rationale. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D 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 DECCCC433F5 for ; Tue, 26 Apr 2022 03:30:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:CC:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=IJsmHrWtSFsjqESh01HYtbw7U1aOrJ8qUbgYKmVXGc8=; b=u+YdvvAy7NGlNC dT797JYjlWX2MdHV6cCe2bLFBEECbQ/DkA/NF9ZNdVzrU3chY2glffeXHt5sYZsCWEbnoqX4IgD6X /FHL/zkWp3sERIpAtHlOovJoPC3N/IusyslrH80jq+aPRb8tMW2N57JId7CxQZA979La9aL2Ru4ZC eTrXeQVvD3/lZuPPsPN04tFrfDTbPZRMZn+QObs/U3kEe0mC+5MravoOyY79xuQ+jg6KjqSL1zsbe QNGOhvH1QoKWZZIda4wwavUN/OO5cTnGIsE82uJ3GKr5vTz6rOLKaKo72Ie080x5Qx3pFwcHrlR+p VSPT4aZBXeKfE82s0X0Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1njBsK-00CJA6-S2; Tue, 26 Apr 2022 03:28:28 +0000 Received: from fllv0015.ext.ti.com ([198.47.19.141]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1njBsG-00CJ8F-Ov for linux-arm-kernel@lists.infradead.org; Tue, 26 Apr 2022 03:28:26 +0000 Received: from lelv0266.itg.ti.com ([10.180.67.225]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 23Q3SHWa089998; Mon, 25 Apr 2022 22:28:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1650943697; bh=+o6NhAJsTjHg2+8VyeHYHIdbFc/RG121uOxauMu/fng=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=pN/GsGgaKCeExUssIz/hOMcsZzySVM+kiEsCYDU1ThMGxpkFPXfKG3V67NrvPJCWO xuMhKB5B3ucZVcv+S6i61ETnkRGseFlGdH5e1cBtasXJOydkolc/+3w4blR1BE/uir SLpd4WqzRLN18xLzht6fJ2N+iHRgtYnifiKzX3do= Received: from DLEE115.ent.ti.com (dlee115.ent.ti.com [157.170.170.26]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 23Q3SHgJ104849 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 25 Apr 2022 22:28:17 -0500 Received: from DLEE111.ent.ti.com (157.170.170.22) by DLEE115.ent.ti.com (157.170.170.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Mon, 25 Apr 2022 22:28:16 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DLEE111.ent.ti.com (157.170.170.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14 via Frontend Transport; Mon, 25 Apr 2022 22:28:16 -0500 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 23Q3SGGk032680; Mon, 25 Apr 2022 22:28:16 -0500 Date: Mon, 25 Apr 2022 22:28:16 -0500 From: Nishanth Menon To: Dave Gerlach CC: Andrew Davis , Rob Herring , Santosh Shilimkar , Krzysztof Kozlowski , Tero Kristo , , , , Vignesh Raghavendra Subject: Re: [PATCH 1/6] dt-bindings: ti,sci: Add ti,ctx-memory-region property Message-ID: <20220426032816.lov27rwssipapqp4@causing> References: <20220421203659.27853-1-d-gerlach@ti.com> <20220421203659.27853-2-d-gerlach@ti.com> <2528be71-ca3f-566b-4769-36063c98ee0e@ti.com> <20220423133648.jlkeyfq7gjbwij5l@bonelike> <5f9485b0-d48c-6418-dc52-a2cd57e98791@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5f9485b0-d48c-6418-dc52-a2cd57e98791@ti.com> User-Agent: NeoMutt/20171215 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-20220425_202825_018023_0738DDBE X-CRM114-Status: GOOD ( 37.43 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 15:24-20220425, Dave Gerlach wrote: > Hi, > > On 4/23/22 08:36, Nishanth Menon wrote: > > On 14:10-20220422, Dave Gerlach wrote: > >> Hi, > >> > >> On 4/22/22 14:02, Andrew Davis wrote: > >>> On 4/21/22 3:36 PM, Dave Gerlach wrote: > >>>> Add documentation for the ti,ctx-memory-region property which is a > >>>> phandle to a reserved-memory carveout to be used by the ti_sci driver > >>>> storage of low power mode memory context. This is optional for normal > >>>> system operation but required to enabled suspend-to-mem usage of Deep > >>>> Sleep state. > >>>> > >>>> Signed-off-by: Dave Gerlach > >>>> --- > >>>> .../devicetree/bindings/arm/keystone/ti,sci.yaml | 9 +++++++++ > >>>> 1 file changed, 9 insertions(+) > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml > >>>> index 34f5f877d444..ec88aa88a2a0 100644 > >>>> --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml > >>>> +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml > >>>> @@ -61,6 +61,15 @@ properties: > >>>> mboxes: > >>>> minItems: 2 > >>>> > >>>> + ti,ctx-memory-region: Just memory-region? > >>>> + description: > >>>> + Phandle to the reserved memory node to be associated with the > >>>> + ti-sci device, to be used for saving low power context. The > >>>> + reserved memory node should be a carveout node, and should > >>>> + be defined as per the bindings in > >>>> + Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > >>>> + $ref: /schemas/types.yaml#/definitions/string $ref: /schemas/types.yaml#/definitions/phandle ? maxItems: 1 > >>>> + > >>> > >>> > >>> Why does this have to be yet another reserved carveout region, > >>> should be dynamically allocated. > >>> > >> > >> This must be a fixed address in order to support other low power modes > >> which have not yet been introduced. > > > > Please elaborate the need - Many of our devices, esp the AM62 class ones > > are memory constrained devices - LPM states are controlled entry states, why > > should we loose a chunk of DDR in operational state while waiting for > > the suspend or idle state to be invoked? > > OR, is the argument is as follows: > > - need a guarenteed memory for me to enter low power and not be > > dependent on availability on attempt. > > - Latency overhead of allocation during a "hot path" such as cpu idle, > > this is completely unacceptable? > > > > or something of that form.. please elaborate? > > Yes, in the case of some future low power modes, it is possible for the > SoC to completely lose context. For the mode being introduced here, I > agree that we could dynamically allocate this memory and then share that > address around, but keeping it fixed of course works here, and *also* > works for the complete context loss case, as a different mechanism would > be restoring this context and can easily get the fixed address straight > from the DT. Otherwise we would have two completely divergent paths > because there is no way to share some dynamic address across the transition. > > To me it makes sense to keep it the same for all modes when possible. a) Clearly this does'nt apply to all SoCs supporting ti,sci. Can we make it more stringent? b) This is a hardware description of a memory region that is carvedout for context information and maybe used as part of various LPM modes where restoration needs to occur prior to OS startup (and dynamic handshake can occur with the entity that manages power controls). I think this should be clearly articulated in commit message and description to help understand the rationale. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel