Message ID | 20230814104127.1929-8-peng.fan@oss.nxp.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b824:0:b0:3f2:4152:657d with SMTP id z4csp2702415vqi; Mon, 14 Aug 2023 05:15:07 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHKbNIY7wGxkuy2twpTYGHzXy2HowLfVORCDtz9PvOd748ZfOFKON2zsNnelegWJVqEXse3 X-Received: by 2002:a05:6a21:998e:b0:13b:b4bb:8b18 with SMTP id ve14-20020a056a21998e00b0013bb4bb8b18mr10633895pzb.1.1692015307503; Mon, 14 Aug 2023 05:15:07 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1692015307; cv=pass; d=google.com; s=arc-20160816; b=1LpYRbpwNsfg4iLanMmK4EQyEpWuqjkTCCK7XkVujJMbjN0wNLyHCEfyNOhEMucy5F QcJ/1FM3g9Qt2QzAyqk/yvfA6/tLzTNvlSdEzrcnZaj/WcY3iqtRqbUP93AWm4shd5eF av7PlRcboEpbQV5FC8xa3fUb/HQl0/UfNIriAfOOHdC1jWIbax43sfF3hCcINYBeccK7 Yd28LWuT7HfVVHEpbJ5txODaO8De2xbOK83SfuiN5qvnLrFq6LU/GqCbJCxhvbwakfQh bHElOKeH80F66hsLpuxTGQtkHLLKXfNQbxVNzl0iARuGGAX5G3UQ6PZwaybMiW3u+Bno 9sdA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=bTqXGAi4gv6df3uCGkaSZVTjEApwuAc+7+xXRdnwpqU=; fh=TlZEgCjOXNq8CKSnQ5emAFoUhkQr53TmuXUrJtBtV5c=; b=zuHlRAQdFJfXfCuWa38V9Kk5NOJpBlHL/bflwW15vuEAcN7fQzaoyDzk7Xm7Qry6JG rYUicC85TmT8bia2vM3+fV97bdJhhjRCJv/WwaIu4CFqSwUl2ioX8AxCHT0y6xSCT2qK 289ZXo2ZRWI0yfIfhpzXpF4tcDxezJCauW29TW9aY/Lr7yvXN14RgkaAjZEYMFwzv6ps FOmHqwD9SpRpA4krY8etNiESibBsuyWmXDitS1Cb8Xy3cesWadk5afBP5fDIX27xNCnn EB1g4oJJYh5BjPuY8y9I7HfVZ2EA5HQbOC1uBCmPfA6/08gHDByQw5arXL1MeflydZf8 9YQw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@NXP1.onmicrosoft.com header.s=selector2-NXP1-onmicrosoft-com header.b=SbjOrr2y; arc=pass (i=1 spf=pass spfdomain=oss.nxp.com dkim=pass dkdomain=oss.nxp.com dmarc=pass fromdomain=oss.nxp.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e20-20020a056a001a9400b0067fea30cd05si8063636pfv.79.2023.08.14.05.14.49; Mon, 14 Aug 2023 05:15:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@NXP1.onmicrosoft.com header.s=selector2-NXP1-onmicrosoft-com header.b=SbjOrr2y; arc=pass (i=1 spf=pass spfdomain=oss.nxp.com dkim=pass dkdomain=oss.nxp.com dmarc=pass fromdomain=oss.nxp.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234966AbjHNKht (ORCPT <rfc822;274620705z@gmail.com> + 99 others); Mon, 14 Aug 2023 06:37:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234921AbjHNKhS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 14 Aug 2023 06:37:18 -0400 Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2065.outbound.protection.outlook.com [40.107.21.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BEB510F; Mon, 14 Aug 2023 03:37:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fOI062OrkbK4gP4hav6CgFAie1HNj4jOZ6WFT4PEqOYHF3wA5KlZ1/TGxLNkjxUqyojw2ZwDtRkYaxTmyFFWZOOcv/ejqD/zlAn7TAKUaozm0SXvYY8URnn5eRvlmRMlnuKtpEXZ5WcYpcfZxym6vlg1VSePvEEbxVKMEOE/kak641KT7GIT4nJVv9VC2S27p0OL8BdrkL3NcBFFmKg38P4vbvm0W5Ct7Rm6NVCUJcqEQI3oBUUxagS/0cYreyGQKsCX9diG609iR7MNXBXh2hF7ZzD3EapeE0ubD42MCggUBKfJWevW0EmjJaNsE6z6cZntr7cAr47lFVoZ2lLyKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bTqXGAi4gv6df3uCGkaSZVTjEApwuAc+7+xXRdnwpqU=; b=HPfZ2CuRWnJEJ4G3o/YV4yNcwzePY5JF2dWUdpKCp0f8Q/8ZaXPxIPm/+w1qTxr76EKWJfolrJOmjYSBRZcmmw2mHoaduHXkXuFlbmbKT45+1nRG5UA/dMjyrbM2Hf98TMoa3AJ++DqVeHZmI0eQ6hZZswSWsh37m3f/HbabS131q7pa5hIth5X5QOqYK2aFlRFNGtzI1Le5ikC4OSZLzaVfDN2wRT/RC4xwYDwGX98K3+ZMIDqq8nlC8/BQA6O+mW+bGLClAnLvNYeHv1OuV1Cz3ekqskzv6Pvp11gxOUTd2X50bhQUpqz/DiGCLp9F33coT1HOpbq+kt+eHxyfSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com; dkim=pass header.d=oss.nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com; s=selector2-NXP1-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bTqXGAi4gv6df3uCGkaSZVTjEApwuAc+7+xXRdnwpqU=; b=SbjOrr2yhabk5xCMA2cNqVd+EjJlMpvaTggDGM7tRlSUBgyEEQ9nIgJ4qnwS1BHAnxnONBnBLuOfomD010+G1qYSrCNi+9LxSpN9mMz0BxlntnH8jw/A1kJf8OSakFu8Bi4MveW93qm6zayBrzFkSakK5R8oI7Qcp8JA4l78sGE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=oss.nxp.com; Received: from DU0PR04MB9417.eurprd04.prod.outlook.com (2603:10a6:10:358::11) by VE1PR04MB7216.eurprd04.prod.outlook.com (2603:10a6:800:1b0::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6678.24; Mon, 14 Aug 2023 10:37:15 +0000 Received: from DU0PR04MB9417.eurprd04.prod.outlook.com ([fe80::2b3:d8de:95c8:b28b]) by DU0PR04MB9417.eurprd04.prod.outlook.com ([fe80::2b3:d8de:95c8:b28b%3]) with mapi id 15.20.6678.022; Mon, 14 Aug 2023 10:37:14 +0000 From: "Peng Fan (OSS)" <peng.fan@oss.nxp.com> To: ulf.hansson@linaro.org, shawnguo@kernel.org, s.hauer@pengutronix.de Cc: kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Peng Fan <peng.fan@nxp.com> Subject: [PATCH V4 7/8] genpd: imx: scu-pd: add multi states support Date: Mon, 14 Aug 2023 18:41:26 +0800 Message-Id: <20230814104127.1929-8-peng.fan@oss.nxp.com> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20230814104127.1929-1-peng.fan@oss.nxp.com> References: <20230814104127.1929-1-peng.fan@oss.nxp.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SG2PR02CA0011.apcprd02.prod.outlook.com (2603:1096:3:17::23) To DU0PR04MB9417.eurprd04.prod.outlook.com (2603:10a6:10:358::11) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU0PR04MB9417:EE_|VE1PR04MB7216:EE_ X-MS-Office365-Filtering-Correlation-Id: 00f6d7d0-b45c-43b9-65ad-08db9cb26cd4 X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: itTx81Fu9muAEzoC0x3T9krMJehDavYLSs2oaCDewnmJFBnL225kMTAsjKbdIyGmbO4Cmb4ElwkYdqIEaFnDNCCOGAOe97/8bOW3zU1G984cpNRJJZPtkNX1nlt0L53aqOF8c+1HPGkfZaEf/4R99sv4ziOU1aj3c82jwdKuGemu3HuPIyBiBEAoMuBf1gim75Eu/EtnzrBPPxU1XTyFvQDQQJZOxfa2Zkup1GLHmdCu9BD3SayEvvGLi9XdBR9S3igqVr49VXBJxR6K6FgbN4Gi1RYlDPVRgGxg76KaOEfs0KEmqI9JmYBObX5GLitr2NBTCtHmBmbGmxhZIOBS7dNSKjhGuS90khezqEpIedyvOxAwkns/IgOayv46TqoI+xFNg7smozZbnFszwkFx4JAXQoZLYAE1OPpVnkrw/r/W0m3sMyObaXrg+XsR43/U7I9G44f4m9pf3lKf4Lyxo1s85TqsYCj+pL4KtuD3Mjkn9z926ajBwi9TnthnhJyxHkyImLzLLoOU9yBY3pUnepDJYt1b6sS2+szkiw1uBHcoBM5f6AtGLdwzaT7IBu8X3qQbxrajdJ/D8q+KlC1dsq+NnGUOFbWFrzIx8S0CO/R41bhw7V88OAJy8qYoEPWi X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0PR04MB9417.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(376002)(396003)(346002)(136003)(39860400002)(366004)(1800799006)(186006)(451199021)(478600001)(6486002)(6666004)(6506007)(26005)(1076003)(52116002)(6512007)(2616005)(66946007)(66556008)(66476007)(8676002)(316002)(4326008)(8936002)(41300700001)(5660300002)(38100700002)(38350700002)(86362001)(83380400001)(2906002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: a4IrxbJYx8LSwCpVPW5xmErbzsLXXG0lZXGjm1YRbUjTccIW/tNAU0v9W/C0x9ozLQAoOJmdX8qolkqk+HxLgKyZQT6vB3OzvjnSOMxSRVgbW5W/cumUZuarp5iqIiGZI4iRnOn/UOEiFbHxCjuaTJYFwr+zBGbI8/Q+GFmrFdxVZ+e9d6YJe8DJ0eItYmxuy9v7+5hnjaQ7TBoZd/0AcmxlTPaMM6DE8QxXF5qbDX0QcjtvzR5Wg2xKJ6J2wXtlOY7pHwqHD4aQhvQL2C/XhKKRsyBffCNLFa7LquhzngXgCapkmP9T3/OjzaEQ71Vuwwx1oGlCZLTtkQ6pHx1hYaC6l+vrfcK/RQ3H//guKAfWoTBTyREz7S8wXiw8SUl+Db3XkLxlETAfwZl6tB3sgzWcBGjO4q1sOvWcg4NmHQU66ph8ckWVdONF8rhOQMD9FF7XOCFMijhX6yqmyuPMYBJqbzuAgXT7phj9pOJYCOiOhzfuuvLQL4oNfw8lYh/ygRipt10Ciix1/eWJT7+mj0h2ZvdeO2LMDx7qINR1/pKc459s2awKP9gcjv8b+qX6K5K7J0xbT2VEg53IEovhgU5sLMDBq7SnEgbR4L415vgdz5/KB6QRdP3Sw3K3rh+o1eJHbcowTwZIbKm2VQ4uWubbuKCZF5TMEODoC76hhGpOiSF6gKePDSGKkcnHkiTT5+xdTuCAfMec7V8bSQ144hI4k0ADDUp/Hvj9OPwozgCgmpxi4fA0rK1N6eiw3tcz3YuAq1qIK92FEhU0to9o12Z5Gv6ByAlXN/03E3/teX80fcVrQhPWdpxzJhfOOwJMJVmro2SDOxcyHeXD7Up2/0j0HHJFGKOJbfGwpYqFYaLNp+9SY8zw87f3dLC/sgi0AYoDsogQh42PsMXcVw7DVhqXD4LyNG0qVO0nElLjhgTKPacRBYuaCsqRKVNAyTR29aXk86RTq3cqPU5gYDSED7qfSpeGt1k4gK3f9w41gT4dyvdOnHn6ATCX3XfZRs/UXHdRAXg/xJ0LmAd72L5ExbHHZGof/DrC8hHf310YzuO9R2snFufsSerO4uHP5EsKTx/Jn22MehtNcM//msyWZfWvW+6/baRM8kuehpLz08VHVzcwbqbKdtEd/oKDU9q+Kn8wwfTs29D5e5Dlz12wsKxnYL1QiMMzftlyBgL+66wLytS87mbMDr9jgmQFlaKn7971tcaqArcsZJE31Sjpiwt8/ubvgzxmf7J5tM2aytIKNAZl39dLV/foQi715ORtnSsmAuuo2QOAHnVvr+q8HnDPrqEQINqvKZTuWhQ2SreL2SHiLUEsg6vP7RXQUr1/eMnU71yVCqcPePJ+EjsmRAF9UdH6nhSMqbEK3WgUIubZpvQn+28OzWFSrsIs+6xPvT+o0WFOdZvopokeNjAa0bzJbGv8m0ZspN4BrKvoB1GwGi5xdorvDk713h1Zgc+YvazPJtZwnHhopzp0BoWm3zNSQlgFrI1O8LcRHVlACLTjEYfXgqHzcMPs0nwh0R0PwyaXuKxlDsilyaw27xN7x2Kxpiqik5FEVwilIgeUhYzr8vygRxgSN312yt/A5TpF X-OriginatorOrg: oss.nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 00f6d7d0-b45c-43b9-65ad-08db9cb26cd4 X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9417.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Aug 2023 10:37:14.8722 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 1hwYOa/B4Ev8raqPCMwnipfJs5Q6VpqN7HGR+fl22jg7hAQjAqgMISuI/sVhtuizubwkGnLbX/M3+krjzrfNHw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB7216 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1774206642914032565 X-GMAIL-MSGID: 1774206642914032565 |
Series |
genpd: imx: relocate scu-pd and misc update
|
|
Commit Message
Peng Fan (OSS)
Aug. 14, 2023, 10:41 a.m. UTC
From: Peng Fan <peng.fan@nxp.com> Add multi states support, this is to support devices could run in LP mode when runtime suspend, and OFF mode when system suspend. Signed-off-by: Peng Fan <peng.fan@nxp.com> --- drivers/genpd/imx/scu-pd.c | 48 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 46 insertions(+), 2 deletions(-)
Comments
On Mon, 14 Aug 2023 at 12:37, Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote: > > From: Peng Fan <peng.fan@nxp.com> > > Add multi states support, this is to support devices could run in LP mode > when runtime suspend, and OFF mode when system suspend. For my understanding, is there a functional problem to support OFF at runtime suspend too? > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > --- > drivers/genpd/imx/scu-pd.c | 48 ++++++++++++++++++++++++++++++++++++-- > 1 file changed, 46 insertions(+), 2 deletions(-) > > diff --git a/drivers/genpd/imx/scu-pd.c b/drivers/genpd/imx/scu-pd.c > index 2f693b67ddb4..30da101119eb 100644 > --- a/drivers/genpd/imx/scu-pd.c > +++ b/drivers/genpd/imx/scu-pd.c > @@ -65,6 +65,12 @@ > #include <linux/pm_domain.h> > #include <linux/slab.h> > > +enum { > + PD_STATE_LP, > + PD_STATE_OFF, > + PD_STATE_MAX > +}; > + > /* SCU Power Mode Protocol definition */ > struct imx_sc_msg_req_set_resource_power_mode { > struct imx_sc_rpc_msg hdr; > @@ -368,7 +374,8 @@ static int imx_sc_pd_power(struct generic_pm_domain *domain, bool power_on) > hdr->size = 2; > > msg.resource = pd->rsrc; > - msg.mode = power_on ? IMX_SC_PM_PW_MODE_ON : IMX_SC_PM_PW_MODE_LP; > + msg.mode = power_on ? IMX_SC_PM_PW_MODE_ON : pd->pd.state_idx ? > + IMX_SC_PM_PW_MODE_OFF : IMX_SC_PM_PW_MODE_LP; > > /* keep uart console power on for no_console_suspend */ > if (imx_con_rsrc == pd->rsrc && !console_suspend_enabled && !power_on) > @@ -412,11 +419,33 @@ static struct generic_pm_domain *imx_scu_pd_xlate(struct of_phandle_args *spec, > return domain; > } > > +static bool imx_sc_pd_suspend_ok(struct device *dev) > +{ > + /* Always true */ > + return true; > +} > + > +static bool imx_sc_pd_power_down_ok(struct dev_pm_domain *pd) > +{ > + struct generic_pm_domain *genpd = pd_to_genpd(pd); > + > + /* For runtime suspend, choose LP mode */ > + genpd->state_idx = 0; > + > + return true; > +} I am wondering if we couldn't use the simple_qos_governor here instead. In principle it looks like we want a QoS latency constraint to be set during runtime, to prevent the OFF state. During system wide suspend, the deepest state is always selected by genpd. > + > +struct dev_power_governor imx_sc_pd_qos_governor = { > + .suspend_ok = imx_sc_pd_suspend_ok, > + .power_down_ok = imx_sc_pd_power_down_ok, > +}; > + > static struct imx_sc_pm_domain * > imx_scu_add_pm_domain(struct device *dev, int idx, > const struct imx_sc_pd_range *pd_ranges) > { > struct imx_sc_pm_domain *sc_pd; > + struct genpd_power_state *states; > bool is_off; > int mode, ret; > > @@ -427,9 +456,22 @@ imx_scu_add_pm_domain(struct device *dev, int idx, > if (!sc_pd) > return ERR_PTR(-ENOMEM); > > + states = devm_kcalloc(dev, PD_STATE_MAX, sizeof(*states), GFP_KERNEL); > + if (!states) { > + devm_kfree(dev, sc_pd); > + return ERR_PTR(-ENOMEM); > + } > + > sc_pd->rsrc = pd_ranges->rsrc + idx; > sc_pd->pd.power_off = imx_sc_pd_power_off; > sc_pd->pd.power_on = imx_sc_pd_power_on; > + states[PD_STATE_LP].power_off_latency_ns = 25000; > + states[PD_STATE_LP].power_on_latency_ns = 25000; > + states[PD_STATE_OFF].power_off_latency_ns = 2500000; > + states[PD_STATE_OFF].power_on_latency_ns = 2500000; We should probably describe these in DT instead? The domain-idle-states bindings allows us to do this. See Documentation/devicetree/bindings/power/domain-idle-state.yaml. Then we have of_genpd_parse_idle_states(), a helper that parses the values. > + > + sc_pd->pd.states = states; > + sc_pd->pd.state_count = PD_STATE_MAX; > > if (pd_ranges->postfix) > snprintf(sc_pd->name, sizeof(sc_pd->name), > @@ -455,14 +497,16 @@ imx_scu_add_pm_domain(struct device *dev, int idx, > sc_pd->name, sc_pd->rsrc); > > devm_kfree(dev, sc_pd); > + devm_kfree(dev, states); > return NULL; > } > > - ret = pm_genpd_init(&sc_pd->pd, NULL, is_off); > + ret = pm_genpd_init(&sc_pd->pd, &imx_sc_pd_qos_governor, is_off); > if (ret) { > dev_warn(dev, "failed to init pd %s rsrc id %d", > sc_pd->name, sc_pd->rsrc); > devm_kfree(dev, sc_pd); > + devm_kfree(dev, states); > return NULL; > } > > -- > 2.37.1 > Kind regards Uffe
> Subject: Re: [PATCH V4 7/8] genpd: imx: scu-pd: add multi states support > > On Mon, 14 Aug 2023 at 12:37, Peng Fan (OSS) <peng.fan@oss.nxp.com> > wrote: > > > > From: Peng Fan <peng.fan@nxp.com> > > > > Add multi states support, this is to support devices could run in LP > > mode when runtime suspend, and OFF mode when system suspend. > > For my understanding, is there a functional problem to support OFF at > runtime suspend too? In OFF mode, the HW state is lost, so the clks that exported by this(Subsystem) genpd is lost. While in LF mode, no need handle clks recover. Such as subsystem LSIO has clks output, has GPIO, has LPUART. The clks are in drivers/clk/imx/clk-imx8qxp*, which relies on the scu pd. If scu-pd is off, the clks will lose state. > > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > > --- > > drivers/genpd/imx/scu-pd.c | 48 > > ++++++++++++++++++++++++++++++++++++-- > > 1 file changed, 46 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/genpd/imx/scu-pd.c b/drivers/genpd/imx/scu-pd.c > > index 2f693b67ddb4..30da101119eb 100644 > > --- a/drivers/genpd/imx/scu-pd.c > > +++ b/drivers/genpd/imx/scu-pd.c > > @@ -65,6 +65,12 @@ > > #include <linux/pm_domain.h> > > #include <linux/slab.h> > > > > +enum { > > + PD_STATE_LP, > > + PD_STATE_OFF, > > + PD_STATE_MAX > > +}; > > + > > /* SCU Power Mode Protocol definition */ struct > > imx_sc_msg_req_set_resource_power_mode { > > struct imx_sc_rpc_msg hdr; > > @@ -368,7 +374,8 @@ static int imx_sc_pd_power(struct > generic_pm_domain *domain, bool power_on) > > hdr->size = 2; > > > > msg.resource = pd->rsrc; > > - msg.mode = power_on ? IMX_SC_PM_PW_MODE_ON : > IMX_SC_PM_PW_MODE_LP; > > + msg.mode = power_on ? IMX_SC_PM_PW_MODE_ON : pd- > >pd.state_idx ? > > + IMX_SC_PM_PW_MODE_OFF : IMX_SC_PM_PW_MODE_LP; > > > > /* keep uart console power on for no_console_suspend */ > > if (imx_con_rsrc == pd->rsrc && !console_suspend_enabled && > > !power_on) @@ -412,11 +419,33 @@ static struct generic_pm_domain > *imx_scu_pd_xlate(struct of_phandle_args *spec, > > return domain; > > } > > > > +static bool imx_sc_pd_suspend_ok(struct device *dev) { > > + /* Always true */ > > + return true; > > +} > > + > > +static bool imx_sc_pd_power_down_ok(struct dev_pm_domain *pd) { > > + struct generic_pm_domain *genpd = pd_to_genpd(pd); > > + > > + /* For runtime suspend, choose LP mode */ > > + genpd->state_idx = 0; > > + > > + return true; > > +} > > I am wondering if we couldn't use the simple_qos_governor here instead. In > principle it looks like we want a QoS latency constraint to be set during > runtime, to prevent the OFF state. LP mode indeed could save resume time, but the major problem is to avoid save/restore clks. > > During system wide suspend, the deepest state is always selected by genpd. > > > + > > +struct dev_power_governor imx_sc_pd_qos_governor = { > > + .suspend_ok = imx_sc_pd_suspend_ok, > > + .power_down_ok = imx_sc_pd_power_down_ok, }; > > + > > static struct imx_sc_pm_domain * > > imx_scu_add_pm_domain(struct device *dev, int idx, > > const struct imx_sc_pd_range *pd_ranges) { > > struct imx_sc_pm_domain *sc_pd; > > + struct genpd_power_state *states; > > bool is_off; > > int mode, ret; > > > > @@ -427,9 +456,22 @@ imx_scu_add_pm_domain(struct device *dev, int > idx, > > if (!sc_pd) > > return ERR_PTR(-ENOMEM); > > > > + states = devm_kcalloc(dev, PD_STATE_MAX, sizeof(*states), > GFP_KERNEL); > > + if (!states) { > > + devm_kfree(dev, sc_pd); > > + return ERR_PTR(-ENOMEM); > > + } > > + > > sc_pd->rsrc = pd_ranges->rsrc + idx; > > sc_pd->pd.power_off = imx_sc_pd_power_off; > > sc_pd->pd.power_on = imx_sc_pd_power_on; > > + states[PD_STATE_LP].power_off_latency_ns = 25000; > > + states[PD_STATE_LP].power_on_latency_ns = 25000; > > + states[PD_STATE_OFF].power_off_latency_ns = 2500000; > > + states[PD_STATE_OFF].power_on_latency_ns = 2500000; > > We should probably describe these in DT instead? The domain-idle-states > bindings allows us to do this. See > Documentation/devicetree/bindings/power/domain-idle-state.yaml. The scu-pd is a firmware function node, there is no sub-genpd node inside it. Just like scmi pd, there is no sub-genpd in it. Thanks, Peng. > > Then we have of_genpd_parse_idle_states(), a helper that parses the values. > > > + > > + sc_pd->pd.states = states; > > + sc_pd->pd.state_count = PD_STATE_MAX; > > > > if (pd_ranges->postfix) > > snprintf(sc_pd->name, sizeof(sc_pd->name), @@ -455,14 > > +497,16 @@ imx_scu_add_pm_domain(struct device *dev, int idx, > > sc_pd->name, sc_pd->rsrc); > > > > devm_kfree(dev, sc_pd); > > + devm_kfree(dev, states); > > return NULL; > > } > > > > - ret = pm_genpd_init(&sc_pd->pd, NULL, is_off); > > + ret = pm_genpd_init(&sc_pd->pd, &imx_sc_pd_qos_governor, > > + is_off); > > if (ret) { > > dev_warn(dev, "failed to init pd %s rsrc id %d", > > sc_pd->name, sc_pd->rsrc); > > devm_kfree(dev, sc_pd); > > + devm_kfree(dev, states); > > return NULL; > > } > > > > -- > > 2.37.1 > > > > Kind regards > Uffe
On Mon, 14 Aug 2023 at 13:52, Peng Fan <peng.fan@nxp.com> wrote: > > > Subject: Re: [PATCH V4 7/8] genpd: imx: scu-pd: add multi states support > > > > On Mon, 14 Aug 2023 at 12:37, Peng Fan (OSS) <peng.fan@oss.nxp.com> > > wrote: > > > > > > From: Peng Fan <peng.fan@nxp.com> > > > > > > Add multi states support, this is to support devices could run in LP > > > mode when runtime suspend, and OFF mode when system suspend. > > > > For my understanding, is there a functional problem to support OFF at > > runtime suspend too? > > In OFF mode, the HW state is lost, so the clks that exported by this(Subsystem) > genpd is lost. While in LF mode, no need handle clks recover. > > > Such as subsystem LSIO has clks output, has GPIO, has LPUART. > > The clks are in drivers/clk/imx/clk-imx8qxp*, which relies on the scu pd. > > If scu-pd is off, the clks will lose state. Thanks for clarifying, much appreciated! So it sounds like it's the clock provider(s) that has these requirements then. Can we let the clock provider set a QoS latency constraint for its device that is attached to the genpd then? To prevent the deeper OFF state? Another option would be to enable runtime PM support for the clock provider (to manage the save/restore from runtime PM callbacks), but whether that's feasible sounds like a separate discussion. > > > > > > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > > > --- > > > drivers/genpd/imx/scu-pd.c | 48 > > > ++++++++++++++++++++++++++++++++++++-- > > > 1 file changed, 46 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/genpd/imx/scu-pd.c b/drivers/genpd/imx/scu-pd.c > > > index 2f693b67ddb4..30da101119eb 100644 > > > --- a/drivers/genpd/imx/scu-pd.c > > > +++ b/drivers/genpd/imx/scu-pd.c > > > @@ -65,6 +65,12 @@ > > > #include <linux/pm_domain.h> > > > #include <linux/slab.h> > > > > > > +enum { > > > + PD_STATE_LP, > > > + PD_STATE_OFF, > > > + PD_STATE_MAX > > > +}; > > > + > > > /* SCU Power Mode Protocol definition */ struct > > > imx_sc_msg_req_set_resource_power_mode { > > > struct imx_sc_rpc_msg hdr; > > > @@ -368,7 +374,8 @@ static int imx_sc_pd_power(struct > > generic_pm_domain *domain, bool power_on) > > > hdr->size = 2; > > > > > > msg.resource = pd->rsrc; > > > - msg.mode = power_on ? IMX_SC_PM_PW_MODE_ON : > > IMX_SC_PM_PW_MODE_LP; > > > + msg.mode = power_on ? IMX_SC_PM_PW_MODE_ON : pd- > > >pd.state_idx ? > > > + IMX_SC_PM_PW_MODE_OFF : IMX_SC_PM_PW_MODE_LP; > > > > > > /* keep uart console power on for no_console_suspend */ > > > if (imx_con_rsrc == pd->rsrc && !console_suspend_enabled && > > > !power_on) @@ -412,11 +419,33 @@ static struct generic_pm_domain > > *imx_scu_pd_xlate(struct of_phandle_args *spec, > > > return domain; > > > } > > > > > > +static bool imx_sc_pd_suspend_ok(struct device *dev) { > > > + /* Always true */ > > > + return true; > > > +} > > > + > > > +static bool imx_sc_pd_power_down_ok(struct dev_pm_domain *pd) { > > > + struct generic_pm_domain *genpd = pd_to_genpd(pd); > > > + > > > + /* For runtime suspend, choose LP mode */ > > > + genpd->state_idx = 0; > > > + > > > + return true; > > > +} > > > > I am wondering if we couldn't use the simple_qos_governor here instead. In > > principle it looks like we want a QoS latency constraint to be set during > > runtime, to prevent the OFF state. > > LP mode indeed could save resume time, but the major problem is to avoid > save/restore clks. Okay. So it still sounds like a QoS latency constraint (for the clock provider) sounds like the correct thing to do. If/when the clock provider gets runtime PM support, we can remove the QoS latency constraints. That should work, right? > > > > During system wide suspend, the deepest state is always selected by genpd. > > > > > + > > > +struct dev_power_governor imx_sc_pd_qos_governor = { > > > + .suspend_ok = imx_sc_pd_suspend_ok, > > > + .power_down_ok = imx_sc_pd_power_down_ok, }; > > > + > > > static struct imx_sc_pm_domain * > > > imx_scu_add_pm_domain(struct device *dev, int idx, > > > const struct imx_sc_pd_range *pd_ranges) { > > > struct imx_sc_pm_domain *sc_pd; > > > + struct genpd_power_state *states; > > > bool is_off; > > > int mode, ret; > > > > > > @@ -427,9 +456,22 @@ imx_scu_add_pm_domain(struct device *dev, int > > idx, > > > if (!sc_pd) > > > return ERR_PTR(-ENOMEM); > > > > > > + states = devm_kcalloc(dev, PD_STATE_MAX, sizeof(*states), > > GFP_KERNEL); > > > + if (!states) { > > > + devm_kfree(dev, sc_pd); > > > + return ERR_PTR(-ENOMEM); > > > + } > > > + > > > sc_pd->rsrc = pd_ranges->rsrc + idx; > > > sc_pd->pd.power_off = imx_sc_pd_power_off; > > > sc_pd->pd.power_on = imx_sc_pd_power_on; > > > + states[PD_STATE_LP].power_off_latency_ns = 25000; > > > + states[PD_STATE_LP].power_on_latency_ns = 25000; > > > + states[PD_STATE_OFF].power_off_latency_ns = 2500000; > > > + states[PD_STATE_OFF].power_on_latency_ns = 2500000; > > > > We should probably describe these in DT instead? The domain-idle-states > > bindings allows us to do this. See > > Documentation/devicetree/bindings/power/domain-idle-state.yaml. > > The scu-pd is a firmware function node, there is no sub-genpd node inside it. > > Just like scmi pd, there is no sub-genpd in it. Not sure I got your point. We don't need a sub-genpd node to describe this. This is how it could look like: domain-idle-states { domain_retention: domain-retention { compatible = "domain-idle-state"; entry-latency-us = <25>; exit-latency-us = <25>; }; domain_off: domain-off { compatible = "domain-idle-state"; entry-latency-us = <2500>; exit-latency-us = <2500>; }; }; power-controller { compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd"; #power-domain-cells = <1>; domain-idle-states = <&domain_retention>, <&domain_off>; }; [...] Kind regards Uffe
On Mon, 14 Aug 2023 at 14:23, Ulf Hansson <ulf.hansson@linaro.org> wrote: > > On Mon, 14 Aug 2023 at 13:52, Peng Fan <peng.fan@nxp.com> wrote: > > > > > Subject: Re: [PATCH V4 7/8] genpd: imx: scu-pd: add multi states support > > > > > > On Mon, 14 Aug 2023 at 12:37, Peng Fan (OSS) <peng.fan@oss.nxp.com> > > > wrote: > > > > > > > > From: Peng Fan <peng.fan@nxp.com> > > > > > > > > Add multi states support, this is to support devices could run in LP > > > > mode when runtime suspend, and OFF mode when system suspend. > > > > > > For my understanding, is there a functional problem to support OFF at > > > runtime suspend too? > > > > In OFF mode, the HW state is lost, so the clks that exported by this(Subsystem) > > genpd is lost. While in LF mode, no need handle clks recover. > > > > > > Such as subsystem LSIO has clks output, has GPIO, has LPUART. > > > > The clks are in drivers/clk/imx/clk-imx8qxp*, which relies on the scu pd. > > > > If scu-pd is off, the clks will lose state. > > Thanks for clarifying, much appreciated! So it sounds like it's the > clock provider(s) that has these requirements then. Can we let the > clock provider set a QoS latency constraint for its device that is > attached to the genpd then? To prevent the deeper OFF state? > > Another option would be to enable runtime PM support for the clock > provider (to manage the save/restore from runtime PM callbacks), but > whether that's feasible sounds like a separate discussion. > > > > > > > > > > > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > > > > --- > > > > drivers/genpd/imx/scu-pd.c | 48 > > > > ++++++++++++++++++++++++++++++++++++-- > > > > 1 file changed, 46 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/genpd/imx/scu-pd.c b/drivers/genpd/imx/scu-pd.c > > > > index 2f693b67ddb4..30da101119eb 100644 > > > > --- a/drivers/genpd/imx/scu-pd.c > > > > +++ b/drivers/genpd/imx/scu-pd.c > > > > @@ -65,6 +65,12 @@ > > > > #include <linux/pm_domain.h> > > > > #include <linux/slab.h> > > > > > > > > +enum { > > > > + PD_STATE_LP, > > > > + PD_STATE_OFF, > > > > + PD_STATE_MAX > > > > +}; > > > > + > > > > /* SCU Power Mode Protocol definition */ struct > > > > imx_sc_msg_req_set_resource_power_mode { > > > > struct imx_sc_rpc_msg hdr; > > > > @@ -368,7 +374,8 @@ static int imx_sc_pd_power(struct > > > generic_pm_domain *domain, bool power_on) > > > > hdr->size = 2; > > > > > > > > msg.resource = pd->rsrc; > > > > - msg.mode = power_on ? IMX_SC_PM_PW_MODE_ON : > > > IMX_SC_PM_PW_MODE_LP; > > > > + msg.mode = power_on ? IMX_SC_PM_PW_MODE_ON : pd- > > > >pd.state_idx ? > > > > + IMX_SC_PM_PW_MODE_OFF : IMX_SC_PM_PW_MODE_LP; > > > > > > > > /* keep uart console power on for no_console_suspend */ > > > > if (imx_con_rsrc == pd->rsrc && !console_suspend_enabled && > > > > !power_on) @@ -412,11 +419,33 @@ static struct generic_pm_domain > > > *imx_scu_pd_xlate(struct of_phandle_args *spec, > > > > return domain; > > > > } > > > > > > > > +static bool imx_sc_pd_suspend_ok(struct device *dev) { > > > > + /* Always true */ > > > > + return true; > > > > +} > > > > + > > > > +static bool imx_sc_pd_power_down_ok(struct dev_pm_domain *pd) { > > > > + struct generic_pm_domain *genpd = pd_to_genpd(pd); > > > > + > > > > + /* For runtime suspend, choose LP mode */ > > > > + genpd->state_idx = 0; > > > > + > > > > + return true; > > > > +} > > > > > > I am wondering if we couldn't use the simple_qos_governor here instead. In > > > principle it looks like we want a QoS latency constraint to be set during > > > runtime, to prevent the OFF state. > > > > LP mode indeed could save resume time, but the major problem is to avoid > > save/restore clks. > > Okay. So it still sounds like a QoS latency constraint (for the clock > provider) sounds like the correct thing to do. > > If/when the clock provider gets runtime PM support, we can remove the > QoS latency constraints. That should work, right? > > > > > > > During system wide suspend, the deepest state is always selected by genpd. > > > > > > > + > > > > +struct dev_power_governor imx_sc_pd_qos_governor = { > > > > + .suspend_ok = imx_sc_pd_suspend_ok, > > > > + .power_down_ok = imx_sc_pd_power_down_ok, }; > > > > + > > > > static struct imx_sc_pm_domain * > > > > imx_scu_add_pm_domain(struct device *dev, int idx, > > > > const struct imx_sc_pd_range *pd_ranges) { > > > > struct imx_sc_pm_domain *sc_pd; > > > > + struct genpd_power_state *states; > > > > bool is_off; > > > > int mode, ret; > > > > > > > > @@ -427,9 +456,22 @@ imx_scu_add_pm_domain(struct device *dev, int > > > idx, > > > > if (!sc_pd) > > > > return ERR_PTR(-ENOMEM); > > > > > > > > + states = devm_kcalloc(dev, PD_STATE_MAX, sizeof(*states), > > > GFP_KERNEL); > > > > + if (!states) { > > > > + devm_kfree(dev, sc_pd); > > > > + return ERR_PTR(-ENOMEM); > > > > + } > > > > + > > > > sc_pd->rsrc = pd_ranges->rsrc + idx; > > > > sc_pd->pd.power_off = imx_sc_pd_power_off; > > > > sc_pd->pd.power_on = imx_sc_pd_power_on; > > > > + states[PD_STATE_LP].power_off_latency_ns = 25000; > > > > + states[PD_STATE_LP].power_on_latency_ns = 25000; > > > > + states[PD_STATE_OFF].power_off_latency_ns = 2500000; > > > > + states[PD_STATE_OFF].power_on_latency_ns = 2500000; > > > > > > We should probably describe these in DT instead? The domain-idle-states > > > bindings allows us to do this. See > > > Documentation/devicetree/bindings/power/domain-idle-state.yaml. > > > > The scu-pd is a firmware function node, there is no sub-genpd node inside it. > > > > Just like scmi pd, there is no sub-genpd in it. > > Not sure I got your point. We don't need a sub-genpd node to describe > this. This is how it could look like: > > domain-idle-states { > domain_retention: domain-retention { > compatible = "domain-idle-state"; > entry-latency-us = <25>; > exit-latency-us = <25>; > }; > domain_off: domain-off { > compatible = "domain-idle-state"; > entry-latency-us = <2500>; > exit-latency-us = <2500>; > }; > }; > > power-controller { > compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd"; > #power-domain-cells = <1>; > domain-idle-states = <&domain_retention>, <&domain_off>; > }; Ahh, now I think I got your point. The domain-idle-states need a corresponding power-domain specifier too, right? Can we do something along the lines of the below: domain-idle-states = <&domain_retention domain-id>, <&domain_off domain-id>; Anyway, I don't have a strong opinion about moving this to the DT, if you want to keep the values in the code, that works too. Kind regards Uffe
diff --git a/drivers/genpd/imx/scu-pd.c b/drivers/genpd/imx/scu-pd.c index 2f693b67ddb4..30da101119eb 100644 --- a/drivers/genpd/imx/scu-pd.c +++ b/drivers/genpd/imx/scu-pd.c @@ -65,6 +65,12 @@ #include <linux/pm_domain.h> #include <linux/slab.h> +enum { + PD_STATE_LP, + PD_STATE_OFF, + PD_STATE_MAX +}; + /* SCU Power Mode Protocol definition */ struct imx_sc_msg_req_set_resource_power_mode { struct imx_sc_rpc_msg hdr; @@ -368,7 +374,8 @@ static int imx_sc_pd_power(struct generic_pm_domain *domain, bool power_on) hdr->size = 2; msg.resource = pd->rsrc; - msg.mode = power_on ? IMX_SC_PM_PW_MODE_ON : IMX_SC_PM_PW_MODE_LP; + msg.mode = power_on ? IMX_SC_PM_PW_MODE_ON : pd->pd.state_idx ? + IMX_SC_PM_PW_MODE_OFF : IMX_SC_PM_PW_MODE_LP; /* keep uart console power on for no_console_suspend */ if (imx_con_rsrc == pd->rsrc && !console_suspend_enabled && !power_on) @@ -412,11 +419,33 @@ static struct generic_pm_domain *imx_scu_pd_xlate(struct of_phandle_args *spec, return domain; } +static bool imx_sc_pd_suspend_ok(struct device *dev) +{ + /* Always true */ + return true; +} + +static bool imx_sc_pd_power_down_ok(struct dev_pm_domain *pd) +{ + struct generic_pm_domain *genpd = pd_to_genpd(pd); + + /* For runtime suspend, choose LP mode */ + genpd->state_idx = 0; + + return true; +} + +struct dev_power_governor imx_sc_pd_qos_governor = { + .suspend_ok = imx_sc_pd_suspend_ok, + .power_down_ok = imx_sc_pd_power_down_ok, +}; + static struct imx_sc_pm_domain * imx_scu_add_pm_domain(struct device *dev, int idx, const struct imx_sc_pd_range *pd_ranges) { struct imx_sc_pm_domain *sc_pd; + struct genpd_power_state *states; bool is_off; int mode, ret; @@ -427,9 +456,22 @@ imx_scu_add_pm_domain(struct device *dev, int idx, if (!sc_pd) return ERR_PTR(-ENOMEM); + states = devm_kcalloc(dev, PD_STATE_MAX, sizeof(*states), GFP_KERNEL); + if (!states) { + devm_kfree(dev, sc_pd); + return ERR_PTR(-ENOMEM); + } + sc_pd->rsrc = pd_ranges->rsrc + idx; sc_pd->pd.power_off = imx_sc_pd_power_off; sc_pd->pd.power_on = imx_sc_pd_power_on; + states[PD_STATE_LP].power_off_latency_ns = 25000; + states[PD_STATE_LP].power_on_latency_ns = 25000; + states[PD_STATE_OFF].power_off_latency_ns = 2500000; + states[PD_STATE_OFF].power_on_latency_ns = 2500000; + + sc_pd->pd.states = states; + sc_pd->pd.state_count = PD_STATE_MAX; if (pd_ranges->postfix) snprintf(sc_pd->name, sizeof(sc_pd->name), @@ -455,14 +497,16 @@ imx_scu_add_pm_domain(struct device *dev, int idx, sc_pd->name, sc_pd->rsrc); devm_kfree(dev, sc_pd); + devm_kfree(dev, states); return NULL; } - ret = pm_genpd_init(&sc_pd->pd, NULL, is_off); + ret = pm_genpd_init(&sc_pd->pd, &imx_sc_pd_qos_governor, is_off); if (ret) { dev_warn(dev, "failed to init pd %s rsrc id %d", sc_pd->name, sc_pd->rsrc); devm_kfree(dev, sc_pd); + devm_kfree(dev, states); return NULL; }