From patchwork Wed Sep 20 13:09:55 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Alvin_=C5=A0ipraga?= X-Patchwork-Id: 142574 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp4391530vqi; Wed, 20 Sep 2023 13:01:49 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHWt94mDvHVv30+lopamjL4BuuWW/p50C9iVApTLHDhkLWVMcDyVxHTrNi26zi5lGbRB4ze X-Received: by 2002:a17:903:24c:b0:1bb:b86e:8d60 with SMTP id j12-20020a170903024c00b001bbb86e8d60mr4174910plh.46.1695240109522; Wed, 20 Sep 2023 13:01:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695240109; cv=none; d=google.com; s=arc-20160816; b=l2O868dhtgDvMYXv5bIue780sobLe0PppwBQHd2p43dRo4sYmMtyZeW8QFW5BKbW8K Vx8sLXEwlknHXLUCGeIbl8R38D2E2osiOPZqGo1/iPFeNjr4lS254tVpdsGsO9kRZsiw BKDYuab5U9PlkfVptwhmESAQ4F50Zl7CZSkPHlKZbR1+J7VncT2JnSHT27p1FWitqJ7N QAZjPz2AxRhLD6rwrip09Sp9u48Ra9aRvLmf8OZaaClV+zM+t6QcJhBuy/xvk/Va+I0j 9dg6NgEMAyH2zqiqQ0zcDsmV9x7gRd1P7rYdGba46W7mm7BBz/jKystjcMJzDTQyntRi 9NlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=DWkKzE4Z8RDrXV6wrMgsXOyr17/u+hWk6l6i8+o41y0=; fh=KyFBUXcuM6fUgur5yAGjxy8UwwGrnAi0qyRlE0N5PJo=; b=my7u27ybhq/b90lol0ScCa3Qoap/QPejXhs0eQz7LVH4GWVLgqcoQXqvvpdavbKsn9 zvQR+ib6FR4nhdqdy63/Wd4OKRP0Lx8mc5zXMgvMCFCYo58b0+2+xtAQy+oOB/m8lQdy bXpQLcD8wmLZPi4ggx/561yFRBBIdAfVjQzI2NDGZdTNryac9v6i9pJwX8vByak918s9 vc1v2xAJi0FDg43Uu3AisYkA/8wKc6Nh6mCu4M9DZnlmS8BuhjfChinHYB0VaWAbI843 agdOMU54+6HeVN/N6j7YTwotV5oWfWAcHwYkw3p0uHEemnOQii4CRJYQf4g+cED6YZmb irOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@pqrs.dk header.s=google header.b=em1W+8KZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id z10-20020a170903018a00b001c20e55153esi2919816plg.496.2023.09.20.13.01.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Sep 2023 13:01:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@pqrs.dk header.s=google header.b=em1W+8KZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 1977C81F1E87; Wed, 20 Sep 2023 07:05:27 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235121AbjITOFK (ORCPT + 26 others); Wed, 20 Sep 2023 10:05:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52694 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236429AbjITOEc (ORCPT ); Wed, 20 Sep 2023 10:04:32 -0400 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE55BD6 for ; Wed, 20 Sep 2023 07:04:23 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-532784c8770so3146282a12.1 for ; Wed, 20 Sep 2023 07:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqrs.dk; s=google; t=1695218662; x=1695823462; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=DWkKzE4Z8RDrXV6wrMgsXOyr17/u+hWk6l6i8+o41y0=; b=em1W+8KZ7dIQwzWp4QilMrTesB48Ctsb8uT+hL5orBSxzDl3RB5HJufz5LZakFrgy9 8T/Wh/LmWd6u5dvakkoRPSGxjb0purb5EpKQVpuRpFi5BLm8Vtw96MAWbTXTnHqr0Ryh bwjyQpxGbPZXmCRD2lseQfoHWNwTUf3iCZ2JPbWdOXulESyftR4gyCXSyjZu2Sw56VuP N0cQHUAbOW9l6kDCJkGQktxD9FPrSKwu+i905nEZrs1mmp6bprgAJCcH6lY3XZLSWqNE tFYkORTzglmOoPlNUa78gV2b6DttAL2j5vMe6wMrF7U8gbKJUGkLT2wAVqQ4HT0POpNN M26g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695218662; x=1695823462; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DWkKzE4Z8RDrXV6wrMgsXOyr17/u+hWk6l6i8+o41y0=; b=qW3tQ3G8HoLVwJ8q/ny3YbT9MozRbhWT/zbwBocfWFKv8iArGYY0KrqwBhg+vi54xq CCLoK8TaG8R1bYshy3h/CtyjG55oaqup2Qcu3Zj6GmQ0HQ5WGJPSC0mKh6ZIjz7Uucx0 gmLx76URP4W86YuRA4mEROGXrQ/FYiNemiCfFk4c1Q2bknTSgAHc8sB/4gltEksSe4dr 8OZfnB9kpEj0XVnoNUUJQYmVuxlJu+lxrtmXNMbImOZ/wSqb3PNgTg53OTQ0QiNEsZDD ySFhoB61SbpKS2YW+jkRrBxOjoceZ7gkZ7CnvS6AJenTg4ml292yT/x1vSUdE8AVE6Je L40A== X-Gm-Message-State: AOJu0Yw0632KFVJYroRoQLiSggqlWbTyUvsgObJxiVxqEz99i1O54dDK t8d56IkMdyR5xkZT25nT1TPaXQ== X-Received: by 2002:a17:906:5386:b0:9a1:be50:ae61 with SMTP id g6-20020a170906538600b009a1be50ae61mr2179267ejo.69.1695218661856; Wed, 20 Sep 2023 07:04:21 -0700 (PDT) Received: from capella.localdomain ([193.89.194.60]) by smtp.gmail.com with ESMTPSA id c26-20020a170906341a00b00993470682e5sm9397761ejb.32.2023.09.20.07.04.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Sep 2023 07:04:21 -0700 (PDT) From: =?utf-8?q?Alvin_=C5=A0ipraga?= To: =?unknown-8bit?q?Michael_Turquette_=3Cmturquette=40baylibre=2Ecom=3E=2C_?= =?unknown-8bit?q?Stephen_Boyd_=3Csboyd=40kernel=2Eorg=3E=2C_Rob_Herring_=3C?= =?unknown-8bit?q?robh+dt=40kernel=2Eorg=3E=2C_Krzysztof_Kozlowski_=3Ckrzysz?= =?unknown-8bit?q?tof=2Ekozlowski+dt=40linaro=2Eorg=3E=2C_Conor_Dooley_=3Cco?= =?unknown-8bit?q?nor+dt=40kernel=2Eorg=3E=2C_=A0ipraga__=3Calsi=40bang-oluf?= =?unknown-8bit?q?sen=2Edk=3E?= Cc: Sebastian Hesselbarth , Rabeeh Khoury , Jacob Siverskog , Sergej Sawazki , linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 3/3] clk: si5351: allow PLLs to be adjusted without reset Date: Wed, 20 Sep 2023 15:09:55 +0200 Message-ID: <20230920140343.2329225-4-alvin@pqrs.dk> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230920140343.2329225-1-alvin@pqrs.dk> References: <20230920140343.2329225-1-alvin@pqrs.dk> MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Wed, 20 Sep 2023 07:05:27 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777588093100889102 X-GMAIL-MSGID: 1777588093100889102 From: Alvin Šipraga Introduce a new PLL reset mode flag which controls whether or not to reset a PLL after adjusting its rate. The mode can be configured through platform data or device tree. Since commit 6dc669a22c77 ("clk: si5351: Add PLL soft reset"), the driver unconditionally resets a PLL whenever its rate is adjusted. The rationale was that a PLL reset was required to get three outputs working at the same time. Before this change, the driver never reset the PLLs. Commit b26ff127c52c ("clk: si5351: Apply PLL soft reset before enabling the outputs") subsequently introduced an option to reset the PLL when enabling a clock output that sourced it. Here, the rationale was that this is required to get a deterministic phase relationship between multiple output clocks. This clearly shows that it is useful to reset the PLLs in applications where multiple clock outputs are used. However, the Si5351 also allows for glitch-free rate adjustment of its PLLs if one avoids resetting the PLL. In our audio application where a single Si5351 clock output is used to supply a runtime adjustable bit clock, this unconditional PLL reset behaviour introduces unwanted glitches in the clock output. It would appear that the problem being solved in the former commit may be solved by using the optional device tree property introduced in the latter commit, obviating the need for an unconditional PLL reset after rate adjustment. But it's not OK to break the default behaviour of the driver, and it cannot be assumed that all device trees are using the property introduced in the latter commit. Hence, the new behaviour is made opt-in. Cc: Sebastian Hesselbarth Cc: Rabeeh Khoury Cc: Jacob Siverskog Cc: Sergej Sawazki Signed-off-by: Alvin Šipraga --- drivers/clk/clk-si5351.c | 47 ++++++++++++++++++++++++++-- include/linux/platform_data/si5351.h | 2 ++ 2 files changed, 46 insertions(+), 3 deletions(-) diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c index 00fb9b09e030..95d7afb8cfc6 100644 --- a/drivers/clk/clk-si5351.c +++ b/drivers/clk/clk-si5351.c @@ -506,6 +506,8 @@ static int si5351_pll_set_rate(struct clk_hw *hw, unsigned long rate, { struct si5351_hw_data *hwdata = container_of(hw, struct si5351_hw_data, hw); + struct si5351_platform_data *pdata = + hwdata->drvdata->client->dev.platform_data; u8 reg = (hwdata->num == 0) ? SI5351_PLLA_PARAMETERS : SI5351_PLLB_PARAMETERS; @@ -518,9 +520,10 @@ static int si5351_pll_set_rate(struct clk_hw *hw, unsigned long rate, (hwdata->params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0); /* Do a pll soft reset on the affected pll */ - si5351_reg_write(hwdata->drvdata, SI5351_PLL_RESET, - hwdata->num == 0 ? SI5351_PLL_RESET_A : - SI5351_PLL_RESET_B); + if (pdata->pll_reset[hwdata->num]) + si5351_reg_write(hwdata->drvdata, SI5351_PLL_RESET, + hwdata->num == 0 ? SI5351_PLL_RESET_A : + SI5351_PLL_RESET_B); dev_dbg(&hwdata->drvdata->client->dev, "%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate = %lu\n", @@ -1222,6 +1225,44 @@ static int si5351_dt_parse(struct i2c_client *client, } } + /* + * Parse PLL reset mode. For compatibility with older device trees, the + * default is to always reset a PLL after setting its rate. + */ + pdata->pll_reset[0] = true; + pdata->pll_reset[1] = true; + + of_property_for_each_u32(np, "silabs,pll-reset-mode", prop, p, num) { + if (num >= 2) { + dev_err(&client->dev, + "invalid pll %d on pll-reset-mode prop\n", num); + return -EINVAL; + } + + p = of_prop_next_u32(prop, p, &val); + if (!p) { + dev_err(&client->dev, + "missing pll-reset-mode for pll %d\n", num); + return -EINVAL; + } + + switch (val) { + case 0: + /* Reset PLL whenever its rate is adjusted */ + pdata->pll_reset[num] = true; + break; + case 1: + /* Don't reset PLL whenever its rate is adjusted */ + pdata->pll_reset[num] = false; + break; + default: + dev_err(&client->dev, + "invalid pll-reset-mode %d for pll %d\n", val, + num); + return -EINVAL; + } + } + /* per clkout properties */ for_each_child_of_node(np, child) { if (of_property_read_u32(child, "reg", &num)) { diff --git a/include/linux/platform_data/si5351.h b/include/linux/platform_data/si5351.h index c71a2dd66143..5f412a615532 100644 --- a/include/linux/platform_data/si5351.h +++ b/include/linux/platform_data/si5351.h @@ -105,10 +105,12 @@ struct si5351_clkout_config { * @clk_xtal: xtal input clock * @clk_clkin: clkin input clock * @pll_src: array of pll source clock setting + * @pll_reset: array indicating if plls should be reset after setting the rate * @clkout: array of clkout configuration */ struct si5351_platform_data { enum si5351_pll_src pll_src[2]; + bool pll_reset[2]; struct si5351_clkout_config clkout[8]; };