Message ID | 20231001-scmi-clock-v2-v3-2-898bd92d8939@nxp.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2a8e:b0:403:3b70:6f57 with SMTP id in14csp1447005vqb; Mon, 2 Oct 2023 07:02:11 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGGIOnuRGClPO9s89snJiLc4YQTSDMPvRiFVR76ZCO0TVdwGz/X++wYVer/68fJkiTMd1l3 X-Received: by 2002:a17:902:da8d:b0:1bd:e258:a256 with SMTP id j13-20020a170902da8d00b001bde258a256mr18645227plx.32.1696255330508; Mon, 02 Oct 2023 07:02:10 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1696255330; cv=pass; d=google.com; s=arc-20160816; b=ElEcQdrbJORd9R7yvomMDx48us/F9qjOchvfUF5mbmJPGqUNe0Pk3J+/YoAIIZmLcs V52zOzJDWihipEUMsJVqqwoqaHk0HgFNMZgGXIQSaJq31+G99xdBSiOeZPuM9SluEX9P XsPR3svNnh7eT1DP7z8qA4vXgoLBRG0OzNuonxwb2PG+1rJwhbzfRT/NBLSgXKNfHbF1 ZYpofPUpJrVAkQdgE76VKYBOi1x1cDo1arZrm5cmB92a90oj6lVxXD9xBMeaP6bzXOrO xaiUlabaU5sVfsxMbrqILtHyc027b2QmezlonqNZzavtDSl0456MBe8RrzarDNj5Sd+B v8SQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:cc:to:in-reply-to:references :message-id:content-transfer-encoding:subject:date:from :dkim-signature; bh=Ix9KVBYwnHweBcpYqs+IfJUUWkaBBJmN8RTU5DV6tWM=; fh=KvNuq8oD2I3oqUAvZUc/79SLm/dJkxTp/JxS7UR63XY=; b=Q4/lYybV42Hcn+O5yR7H5TM/OYuBAOnAgFUSJEsjf7RetIVW1qFrB7CjVLgN006qrR AVbGm9sesul5FIOCpreVI6LZyWUBGOLpv7h8xIJ7Hu5fK/t6Hr3Y6FYwsQrMLmqFRQys nESQkGUDI5ir+mvG3Dz55GwCHCgcb7elzC2xr4rHAxfrivR4eb2re3bJKEAbqz1AqYHP OYR/lmfU8y8YiE6wgwyVh2FX2hx0DF7Ai3QKrhMkcdmXWBDqTl3mXJpc8pw5wLuaqr65 EPC5pri/R/mP2AcZ7ZKaQhE3NpfvjM6QxuujhciDCHDQDOYAw9CFyLZG8T9BNSEdoXuc VjYA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@NXP1.onmicrosoft.com header.s=selector2-NXP1-onmicrosoft-com header.b=bBfM6wTq; 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 23.128.96.33 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 lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id x18-20020a170902ea9200b001c0ab540e62si10359187plb.277.2023.10.02.07.02.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Oct 2023 07:02:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@NXP1.onmicrosoft.com header.s=selector2-NXP1-onmicrosoft-com header.b=bBfM6wTq; 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 23.128.96.33 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 (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id D445780FD8B6; Sat, 30 Sep 2023 21:34:45 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234087AbjJAEeW (ORCPT <rfc822;pwkd43@gmail.com> + 19 others); Sun, 1 Oct 2023 00:34:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52806 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231660AbjJAEeR (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 1 Oct 2023 00:34:17 -0400 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on2068.outbound.protection.outlook.com [40.107.6.68]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 756C6D3; Sat, 30 Sep 2023 21:34:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=If52zqE08ntfTPzD2AhZDPdbl2l40W4v0OlG0sLjWqPYif8hlJykRVY7L/h6wrn7uYRlXIIyFtMP8jn6fn7DVnDJ36gpQ0zco7BZ0HA4L9XFiEAw6E5zLzvmXj0RQJj2afUvs2lADglliiXE4x8p4kHyRpmlU+xr5r4gO60clf9lh+HUCYi7pa/TglLSsF0r+Pl8/p4XTPZexMQ+9TM71lIhGL3iZgBYAer4+TFL2UCKSV4NbJbDB6Cm0VPmzkv1RqlohfvHTRnr5eAtEtpOVzqmmhJobn2vZiUklA5HVJPRtHA7wgsFNxak7Nd+0JOmPHtYmVze1uYbC92XBon1IQ== 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=Ix9KVBYwnHweBcpYqs+IfJUUWkaBBJmN8RTU5DV6tWM=; b=MldFxaelk99wVIII0BTGpTJMlUfEvx6O7wcrkyHSAFxY/KzCY5vDiIS+g647FSpKZzdpwSvvVi90+VnhFAf/l3nwEPXHTXVKJ9U3eMxB7immfeWARyWp0deD2uHoO4h1gaZlBNFjnu+pXOwl0jUTuSMsFiB8zgg6Ji675DUrxF4rVKPBHs8JOmJXZ4qHvdbG9IhROoUCvAAI8ywCobXWLRtcaIF1SlffQkfm/PziX8wv3pZ/wadnEBOZtl0SAf56VPjfZrA0pOf1O4K1aKbTHANBU8izT6TTF1DwqW4qCRAF/pRFwC+wFTOuZYV0j4oTLLdKY57KUb7uzST0ochMZQ== 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=Ix9KVBYwnHweBcpYqs+IfJUUWkaBBJmN8RTU5DV6tWM=; b=bBfM6wTqiUt6LeYbKT85rvYNeERn8LM7p4v8vwOVWBBhdGxB4hKBGJaDbJNHK7B1iPsG9HGnVmEIR34fk6INoaNzkGR6jg389b99+Q2pr2BDgFDWCQE+4ZEL7vyjFPzTHbUXuaU6+8bj6Q6Ir4zZlZ9yQjXIg/dQLsdKauO1aKA= 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 PAXPR04MB8335.eurprd04.prod.outlook.com (2603:10a6:102:1c2::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.29; Sun, 1 Oct 2023 04:34:11 +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.6838.024; Sun, 1 Oct 2023 04:34:11 +0000 From: "Peng Fan (OSS)" <peng.fan@oss.nxp.com> Date: Sun, 01 Oct 2023 12:38:44 +0800 Subject: [PATCH v3 2/2] clk: scmi: add set/get_parent support Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20231001-scmi-clock-v2-v3-2-898bd92d8939@nxp.com> References: <20231001-scmi-clock-v2-v3-0-898bd92d8939@nxp.com> In-Reply-To: <20231001-scmi-clock-v2-v3-0-898bd92d8939@nxp.com> To: Sudeep Holla <sudeep.holla@arm.com>, Cristian Marussi <cristian.marussi@arm.com>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org> Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, Peng Fan <peng.fan@nxp.com> X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1696135135; l=3380; i=peng.fan@nxp.com; s=20230812; h=from:subject:message-id; bh=GEoaMPEKFPMe5D3pfktJgZun60qYQRSSGhLzuwR/Q7I=; b=hXGJDAHx2IW00hotreyGGPQS2C2hOWCV+M/HezUHfTrbBij/tPhOjKhYm0jfWz0D4OMOTwe2Y h29ULmzQ0E9Byp5888THqNAq0PbbIrZ/xYLRinCSDkpZLl4HVe6umwC X-Developer-Key: i=peng.fan@nxp.com; a=ed25519; pk=I4sJg7atIT1g63H7bb5lDRGR2gJW14RKDD0wFL8TT1g= X-ClientProxiedBy: SG2PR04CA0212.apcprd04.prod.outlook.com (2603:1096:4:187::8) 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_|PAXPR04MB8335:EE_ X-MS-Office365-Filtering-Correlation-Id: df3154fc-44ec-4322-3735-08dbc237a90e 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: Dgi7+pJcMI61ISw94UKUA6PP7egK2QBjpUqY5YaMtC87Tl3YRZdxhMCjzxSykT0wB5msBr2G0VvZx+RqmQYohKYy6JQ+5NNljYQaTTXOh9qKrmp8+cbsJKowz+7cVfUn6O6HLVWsIbYWzOixT1p0x7V6wooPoLc9Yl1uzp1gJaRZft1nZuDqzMZ5R7CKHaf7qFuah8RZlfGx/CU+gQpRGMLJoxwvFQU/OoJu+WJs5PCcd92wjb7L2kfjqoDpAe62shgqHykvZKDMyQ5ZKDsOFLmDYtTaCZfvMqjGqmh0nMVmaQCAoovodKwt/VwHb68cFrORzGAz4pWt8IH7tHR7EZVaGPJ0I1Ss6MTzockj5j2JVjzBCxubVDhyPUnBvoHDTGjymyPwwWzVpiaKdSydc9dwmF1zivpdxssvwgySDxk5Qqxn/0HUx1z4BSJL4tYirAA5T4bSl4dBT7XzzvqgUUcRfr5tthM1fY3XVLgEsRVXEk9mb/+mPwp+4T2hzLPQqeJj2FHVDKF7sTRCqYXcz9hbSlCmTfc0s5XMzE06RYahkXHneBMM4q3cEIeHdbdyZi3Uc/rM8s/iGE54ldIOU1+WlWZ4LGMiRXWGw5U/PxEmhmA26TyeYN7p+4un87wk 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:(13230031)(39860400002)(346002)(136003)(396003)(366004)(376002)(230922051799003)(64100799003)(451199024)(1800799009)(186009)(26005)(38100700002)(86362001)(38350700002)(36756003)(83380400001)(316002)(4326008)(8936002)(8676002)(5660300002)(41300700001)(66476007)(66556008)(66946007)(110136005)(2906002)(6506007)(6666004)(52116002)(9686003)(6512007)(6486002)(478600001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?q?VJteWqMw7c3LJ2cwqZwvgqB/l3SH?= =?utf-8?q?AZhPoChy7XPClrIF1S7JnrZBuly+GesuC4ePoT8OfYVUa3os1VNIJl4I4afnw3JFM?= =?utf-8?q?n5BgD/uu8+KjY1tqu0tlgXec4IOPnf0EwAGxXH9H8fr5wpZ2Mi6lXefoFmfsPaBH4?= =?utf-8?q?GWjj5ZMFfJTjm/30VkkfEi2/Ac8+ec1YPj8B7QsLBJxbaiAj2ep8jfgE8VG1FN4a/?= =?utf-8?q?y6/FZD5h2W8NX4e0VXLt3hQmDHp4fKQGAwIlNFIOdWQPiRSrl6/zm+jdguE1i9rz+?= =?utf-8?q?djqHL8MVmohlP0KvAsGxg+40iD1zKFqTumNQBveXlevlifUhSgZNMNoAh0Y28srnK?= =?utf-8?q?Gx1oq95yBSJlXWB5ISCFUakZw8FeEKBHIRMKFkreWqNplafnYT4oLDnbYldqk1fgY?= =?utf-8?q?/k4TVTqDNu76pEJH+yjaS5nfyIcqhat1nuDw92FqYA0RZIRkG+BS+mfT0C6AqCHGt?= =?utf-8?q?n6RvrUM8qv0rXMATq1pX/MabUffxvO/5MeZgMvo0KPSoxxdW0wdajEuSUXaR2ZqVQ?= =?utf-8?q?iBq2lGunroQXw8/TJabrrLTMOskeVlO76zzQI6aiBCh4uFaHsCcaref35nr/PRy2Z?= =?utf-8?q?YOIje4DNbUPmF2Q+sROKSsaJaGajuWKnwW/khSmsFJtxRix3q5vVfyFgEQqbc1Oxo?= =?utf-8?q?wKh8IwXq9judtSFotCfWpBzxO7xUKu+j102RxKK5tWCp5MNlcJIoWbox6Pdo6wM94?= =?utf-8?q?5cF/osLP4hCobKpuJ0Mh2P60XVNnbswoZNd4Ht/p/ry5BN34BWv3Fd/XC52c3OC2w?= =?utf-8?q?hCsOJUYlgsI4+T2NfYIqg4HAfooa328Nr64OPCR5RvUJIhezcS7ttXqmrsxGU3gGf?= =?utf-8?q?J4Ys/z7k9xZNi5GhCA1GkvPAU4CFFfeVDFgo5P8wE6OKIbk5k7yP5QNdDWwDWcc3e?= =?utf-8?q?XenE+0NJ++kZiTSoERvKF2Ee72TW3Guw+9/70wvQBayCxRA2OF/eNJQr2GPRSK7Tk?= =?utf-8?q?iykpgUbG/U6EpII7aUOtbEppSiSqIgk3E8op1fEtr5FwoFhKmDCwSwIeEE8fnQjrl?= =?utf-8?q?8GZlX+s7/Qj9QCRxChOPEXLApC3cFONakZurTLT6UEq2ELK7i+FL4sysJlYPj24DN?= =?utf-8?q?4bxTBH+BsD1NO0NHJUFBynzhqIUXyVQzk1ILTtWA8gph1d32Eyb+xjn89gIUBjHyO?= =?utf-8?q?5TYwv/37mMUNtJxaknv8OjyXCxeW0I0OFCEkls7sHW+LHtxk9i2jaRV2VASZlyMRZ?= =?utf-8?q?9H0Q37P1EP6KeLkFGD3rALmtGOqm6eZ5Wcagd5S7ipCa72gU527l+Q37PETtgJQrN?= =?utf-8?q?hYyuXyL2OZ737OjccuynqGANEeR11jqU51rqP8QUH1Z9bwVaG1vOWGbzQzoOrmq2o?= =?utf-8?q?VShBVrcMg8ZuYCGRQU9U2xSEKTt6yXgKjbua4KRSRhBlxcOKZUIQjpaHRfr+kxKUT?= =?utf-8?q?dySV8gLu+9Fq3NP9Pjc7QCnX9zgms1DxhKLfXt4f+3WglcamfFaMbpz7ESRhQrDIZ?= =?utf-8?q?VDJVR9Y4c7zv2XsvScbj3pJ28W3aFqdMTfmvBtBTU/IlGuLV/2n3iv60Fa7KtSOb8?= =?utf-8?q?pDKHViUZZkG0?= X-OriginatorOrg: oss.nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: df3154fc-44ec-4322-3735-08dbc237a90e X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9417.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2023 04:34:11.9150 (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: BJjwHRv0MnDbDl9mrGspn7uWJuPIvI/E+Zp5n38jxD1w5G+OeU8cXju282yu42qbmEK5zGaMP2xZlARPXR2lIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR04MB8335 X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Sat, 30 Sep 2023 21:34:45 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778652629446246991 X-GMAIL-MSGID: 1778652629446246991 |
Series |
firmware: arm_scmi: clock: support parents commands
|
|
Commit Message
Peng Fan (OSS)
Oct. 1, 2023, 4:38 a.m. UTC
From: Peng Fan <peng.fan@nxp.com> SCMI v3.2 adds set/get parent clock commands, so update the clk driver to support them. Signed-off-by: Peng Fan <peng.fan@nxp.com> --- drivers/clk/clk-scmi.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 49 insertions(+), 1 deletion(-)
Comments
Hi Stephen, On Sun, Oct 01, 2023 at 12:38:44PM +0800, Peng Fan (OSS) wrote: > From: Peng Fan <peng.fan@nxp.com> > > SCMI v3.2 adds set/get parent clock commands, so update the clk driver > to support them. > The SCMI changes look good. If you are happy with this driver change, please Ack so that I can take it along with the SCMI changes. There are other patches clk driver patches that you have already acked in my branch, hence the need to route it via SCMI tree.
On Sun, Oct 01, 2023 at 12:38:44PM +0800, Peng Fan (OSS) wrote: > From: Peng Fan <peng.fan@nxp.com> > > SCMI v3.2 adds set/get parent clock commands, so update the clk driver > to support them. > Hi, a few notes down below. > Signed-off-by: Peng Fan <peng.fan@nxp.com> > --- > drivers/clk/clk-scmi.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 49 insertions(+), 1 deletion(-) > > diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c > index 2e1337b511eb..5aaca674830f 100644 > --- a/drivers/clk/clk-scmi.c > +++ b/drivers/clk/clk-scmi.c > @@ -24,6 +24,7 @@ struct scmi_clk { > struct clk_hw hw; > const struct scmi_clock_info *info; > const struct scmi_protocol_handle *ph; > + struct clk_parent_data *parent_data; > }; > > #define to_scmi_clk(clk) container_of(clk, struct scmi_clk, hw) > @@ -78,6 +79,35 @@ static int scmi_clk_set_rate(struct clk_hw *hw, unsigned long rate, > return scmi_proto_clk_ops->rate_set(clk->ph, clk->id, rate); > } > > +static int scmi_clk_set_parent(struct clk_hw *hw, u8 parent_index) > +{ > + struct scmi_clk *clk = to_scmi_clk(hw); > + > + return scmi_proto_clk_ops->parent_set(clk->ph, clk->id, parent_index); > +} > + > +static u8 scmi_clk_get_parent(struct clk_hw *hw) > +{ > + struct scmi_clk *clk = to_scmi_clk(hw); > + u32 parent_id; > + int ret; > + > + ret = scmi_proto_clk_ops->parent_get(clk->ph, clk->id, &parent_id); > + if (ret) > + return 0; > + > + return parent_id; > +} > + While testing using CLK Debugfs with CLOCK_ALLOW_WRITE_DEBUGFS 1 I noticed that I can correctly change the clk_parent and then read back the clk_possible_parents, BUT if I read clk_parent right after boot (OR after loading the clk-scmi module) I cannot get back any value from debugfs even though I can see the correct SCMI messages being exchanged from the traces. My guess was that, while scmi_clk_set_parent is invoked by the CLK core with a parent_index that has been remapped by the core to the SCMI clock domain ID, this is not done by scmi_clk_get_parent() so you are returning to the clock framework as parent_id the raw SCMI clock domain id as returned by the platform instead of the clk parent id used by the core. This does not happen after you issue at first a reparent because in that case on the following read of clk_parent the CLK framework returns the last value you have set that it had cached previously. This fixes for me the issue: ---8<---- diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c index 5aaca674830f..fd47232d4021 100644 --- a/drivers/clk/clk-scmi.c +++ b/drivers/clk/clk-scmi.c @@ -89,14 +89,21 @@ static int scmi_clk_set_parent(struct clk_hw *hw, u8 parent_index) static u8 scmi_clk_get_parent(struct clk_hw *hw) { struct scmi_clk *clk = to_scmi_clk(hw); - u32 parent_id; + u32 parent_id, p_idx; int ret; ret = scmi_proto_clk_ops->parent_get(clk->ph, clk->id, &parent_id); if (ret) return 0; - return parent_id; + for (p_idx = 0; p_idx < clk->info->num_parents; p_idx++) + if (clk->parent_data[p_idx].index == parent_id) + break; + + if (p_idx == clk->info->num_parents) + return 0; + + return p_idx; } ----8<----- Not sure if there is a clever way to do it. Aside from this, another inherent issue is that you cannot really return an error from .get_parent() so if the SCMI get_parent ops should fail (ex. timeout) you return 0... (and me too in the above fix) but this is due to the CLK framework callback definition itself. Thanks, Cristian
Hi Cristian, > Subject: Re: [PATCH v3 2/2] clk: scmi: add set/get_parent support > > On Sun, Oct 01, 2023 at 12:38:44PM +0800, Peng Fan (OSS) wrote: > > From: Peng Fan <peng.fan@nxp.com> > > > > SCMI v3.2 adds set/get parent clock commands, so update the clk driver > > to support them. > > > > Hi, > > a few notes down below. > > > Signed-off-by: Peng Fan <peng.fan@nxp.com> > > --- > > drivers/clk/clk-scmi.c | 50 > > +++++++++++++++++++++++++++++++++++++++++++++++++- > > 1 file changed, 49 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c index > > 2e1337b511eb..5aaca674830f 100644 > > --- a/drivers/clk/clk-scmi.c > > +++ b/drivers/clk/clk-scmi.c > > @@ -24,6 +24,7 @@ struct scmi_clk { > > struct clk_hw hw; > > const struct scmi_clock_info *info; > > const struct scmi_protocol_handle *ph; > > + struct clk_parent_data *parent_data; > > }; > > > > #define to_scmi_clk(clk) container_of(clk, struct scmi_clk, hw) @@ > > -78,6 +79,35 @@ static int scmi_clk_set_rate(struct clk_hw *hw, unsigned > long rate, > > return scmi_proto_clk_ops->rate_set(clk->ph, clk->id, rate); } > > > > +static int scmi_clk_set_parent(struct clk_hw *hw, u8 parent_index) { > > + struct scmi_clk *clk = to_scmi_clk(hw); > > + > > + return scmi_proto_clk_ops->parent_set(clk->ph, clk->id, > > +parent_index); } > > + > > +static u8 scmi_clk_get_parent(struct clk_hw *hw) { > > + struct scmi_clk *clk = to_scmi_clk(hw); > > + u32 parent_id; > > + int ret; > > + > > + ret = scmi_proto_clk_ops->parent_get(clk->ph, clk->id, &parent_id); > > + if (ret) > > + return 0; > > + > > + return parent_id; > > +} > > + > > While testing using CLK Debugfs with CLOCK_ALLOW_WRITE_DEBUGFS 1 I > noticed that I can correctly change the clk_parent and then read back the > clk_possible_parents, BUT if I read clk_parent right after boot (OR after > loading the clk-scmi module) I cannot get back any value from debugfs even > though I can see the correct SCMI messages being exchanged from the traces. > > My guess was that, while scmi_clk_set_parent is invoked by the CLK core with > a parent_index that has been remapped by the core to the SCMI clock > domain ID, this is not done by scmi_clk_get_parent() so you are returning to > the clock framework as parent_id the raw SCMI clock domain id as returned > by the platform instead of the clk parent id used by the core. > > This does not happen after you issue at first a reparent because in that case > on the following read of clk_parent the CLK framework returns the last value > you have set that it had cached previously. > > This fixes for me the issue: > > ---8<---- > > diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c index > 5aaca674830f..fd47232d4021 100644 > --- a/drivers/clk/clk-scmi.c > +++ b/drivers/clk/clk-scmi.c > @@ -89,14 +89,21 @@ static int scmi_clk_set_parent(struct clk_hw *hw, u8 > parent_index) static u8 scmi_clk_get_parent(struct clk_hw *hw) { > struct scmi_clk *clk = to_scmi_clk(hw); > - u32 parent_id; > + u32 parent_id, p_idx; > int ret; > > ret = scmi_proto_clk_ops->parent_get(clk->ph, clk->id, &parent_id); > if (ret) > return 0; > > - return parent_id; > + for (p_idx = 0; p_idx < clk->info->num_parents; p_idx++) > + if (clk->parent_data[p_idx].index == parent_id) > + break; > + > + if (p_idx == clk->info->num_parents) > + return 0; > + > + return p_idx; > } > You are right. Thanks for doing the fix. > ----8<----- > > Not sure if there is a clever way to do it. > > Aside from this, another inherent issue is that you cannot really return an > error from .get_parent() so if the SCMI get_parent ops should fail (ex. timeout) > you return 0... (and me too in the above fix) but this is due to the CLK > framework callback definition itself. Yes. Right. I will include your fix and do a test, then out v4, should be soon. Thanks, Peng. > > Thanks, > Cristian
diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c index 2e1337b511eb..5aaca674830f 100644 --- a/drivers/clk/clk-scmi.c +++ b/drivers/clk/clk-scmi.c @@ -24,6 +24,7 @@ struct scmi_clk { struct clk_hw hw; const struct scmi_clock_info *info; const struct scmi_protocol_handle *ph; + struct clk_parent_data *parent_data; }; #define to_scmi_clk(clk) container_of(clk, struct scmi_clk, hw) @@ -78,6 +79,35 @@ static int scmi_clk_set_rate(struct clk_hw *hw, unsigned long rate, return scmi_proto_clk_ops->rate_set(clk->ph, clk->id, rate); } +static int scmi_clk_set_parent(struct clk_hw *hw, u8 parent_index) +{ + struct scmi_clk *clk = to_scmi_clk(hw); + + return scmi_proto_clk_ops->parent_set(clk->ph, clk->id, parent_index); +} + +static u8 scmi_clk_get_parent(struct clk_hw *hw) +{ + struct scmi_clk *clk = to_scmi_clk(hw); + u32 parent_id; + int ret; + + ret = scmi_proto_clk_ops->parent_get(clk->ph, clk->id, &parent_id); + if (ret) + return 0; + + return parent_id; +} + +static int scmi_clk_determine_rate(struct clk_hw *hw, struct clk_rate_request *req) +{ + /* + * Suppose all the requested rates are supported, and let firmware + * to handle the left work. + */ + return 0; +} + static int scmi_clk_enable(struct clk_hw *hw) { struct scmi_clk *clk = to_scmi_clk(hw); @@ -139,6 +169,9 @@ static const struct clk_ops scmi_clk_ops = { .set_rate = scmi_clk_set_rate, .prepare = scmi_clk_enable, .unprepare = scmi_clk_disable, + .set_parent = scmi_clk_set_parent, + .get_parent = scmi_clk_get_parent, + .determine_rate = scmi_clk_determine_rate, }; static const struct clk_ops scmi_atomic_clk_ops = { @@ -148,6 +181,9 @@ static const struct clk_ops scmi_atomic_clk_ops = { .enable = scmi_clk_atomic_enable, .disable = scmi_clk_atomic_disable, .is_enabled = scmi_clk_atomic_is_enabled, + .set_parent = scmi_clk_set_parent, + .get_parent = scmi_clk_get_parent, + .determine_rate = scmi_clk_determine_rate, }; static int scmi_clk_ops_init(struct device *dev, struct scmi_clk *sclk, @@ -158,9 +194,10 @@ static int scmi_clk_ops_init(struct device *dev, struct scmi_clk *sclk, struct clk_init_data init = { .flags = CLK_GET_RATE_NOCACHE, - .num_parents = 0, + .num_parents = sclk->info->num_parents, .ops = scmi_ops, .name = sclk->info->name, + .parent_data = sclk->parent_data, }; sclk->hw.init = &init; @@ -250,6 +287,17 @@ static int scmi_clocks_probe(struct scmi_device *sdev) else scmi_ops = &scmi_clk_ops; + /* Initialize clock parent data. */ + if (sclk->info->num_parents > 0) { + sclk->parent_data = devm_kcalloc(dev, sclk->info->num_parents, + sizeof(*sclk->parent_data), GFP_KERNEL); + + for (int i = 0; i < sclk->info->num_parents; i++) { + sclk->parent_data[i].index = sclk->info->parents[i]; + sclk->parent_data[i].hw = hws[sclk->info->parents[i]]; + } + } + err = scmi_clk_ops_init(dev, sclk, scmi_ops); if (err) { dev_err(dev, "failed to register clock %d\n", idx);