Message ID | 20230702-pll-mipi_set_rate_parent-v3-6-46dcb8aa9cbc@oltmanns.dev |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f45:0:b0:3ea:f831:8777 with SMTP id v5csp97037vqx; Sun, 2 Jul 2023 11:49:44 -0700 (PDT) X-Google-Smtp-Source: APBJJlGDV1+LIBX/hOGyqAnWDXYLK5V/QbJJ5uDuSjWAvgBnrNKdcm3TkmYZ36eINty8wrPul+in X-Received: by 2002:a17:902:fb8e:b0:1b8:70d2:eb3a with SMTP id lg14-20020a170902fb8e00b001b870d2eb3amr8027210plb.0.1688323783618; Sun, 02 Jul 2023 11:49:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688323783; cv=none; d=google.com; s=arc-20160816; b=dBZUP+cmVR+VXCWHHaGrGYZ0Jl6INwJMjNszfODVtOJH1tvEgeTOlLBKeOt5ueGb2q 2hM6FkzxdZ/LKFQZQvvIcUhcSGFTPoX1/JXNWId6/u5+ewJfHDCJSEcVmQCUnUibOAN8 FJjBxJH2aEFLWB3zhwXDhbjUqnXBlzGTjK4yLyg1a2Qt2HHFEArQ0eqMAKP2ShM1UOki 6t1F4WyLozj+quVRcRTRd0REMR8KVHlz+nwWo+1RE3SiVNfYR4G8ncWxcKM5g6qp0eE9 wdt/MDp+8c8+FRsA425GEDAE0UpdmsLQiavE96u9xZtsD/ZfeZVZp7KQOT6G+XCzBtRO od4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=IZMNOAHPDl9b4RN7sUq38ZIUetqHmkZGYvLFzUrfFmY=; fh=qochKExQAM0bhcnc+r+ZD43ZS//6TaZetJnkaAgsyOw=; b=zhW0rEVDhf80A/GDdxEx2+Z+KfZ8Nu46ku1GYjz54yngxrRawkbDtEo1tyiyZCR2Wc DLQTMP6PIAvljUbEJJPkEys7vU3kC+gabwWlF8OtZYKUcL87MlSEhAW0S3Att29BN2ah 7CdDT8zbXT6ixOQrV+ANl9fzZarvBMnYvpUW8iKycJKh4Xkmo0Fzp2ety+dj5nuJKlST 4mWKnM57cmauh7mp5OsnBTXtBRBlT3HJ1CntKLq5L+hMEGm8uysfJKR1+zyoIc+M8xiN LIQSoRom42Ouer6Z7YwU2nJZVTgIu2OBsaREd7TWyPgA9R2jtyo74AP42s53W7jQxesC 8ixQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oltmanns.dev header.s=MBO0001 header.b=ZP3C25mm; 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=pass (p=NONE sp=NONE dis=NONE) header.from=oltmanns.dev Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u2-20020a170902714200b001b89b35deeesi5033plm.390.2023.07.02.11.49.30; Sun, 02 Jul 2023 11:49:43 -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=@oltmanns.dev header.s=MBO0001 header.b=ZP3C25mm; 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=pass (p=NONE sp=NONE dis=NONE) header.from=oltmanns.dev Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229901AbjGBR4P (ORCPT <rfc822;ivan.orlov0322@gmail.com> + 99 others); Sun, 2 Jul 2023 13:56:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229899AbjGBRz7 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 2 Jul 2023 13:55:59 -0400 Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [IPv6:2001:67c:2050:0:465::101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1878DE67; Sun, 2 Jul 2023 10:55:57 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4QvGtz5c4Qz9sZZ; Sun, 2 Jul 2023 19:55:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oltmanns.dev; s=MBO0001; t=1688320555; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IZMNOAHPDl9b4RN7sUq38ZIUetqHmkZGYvLFzUrfFmY=; b=ZP3C25mm/2Mr1zTr4yzpNcFJDvHsxZPCxmErBcBbREuaK+PhUOEcJ0k6gxarSx+cc8iG6g qRxxK8qFy2mIHUkvhUVm3a4N7d4NJEho08eWIVK2srGxF9XKADVUhu9LrMBAxNBbBhvVoW qwYjPsLX43vZMc2HLnybyy/WZ+nBIjDmqot+Oz3vLDSFEiEQS7m7r4a3GtP86o7ArUb7YT +jS4thVX/N9A02xbhYw6gvwlht2Ah3KPL+6sipVfChTHok/BvXB8iQLrtfIHWerNKdY6aX DAo7jPBJhUdaH+5bAwomVTgzglUIg1haCabBfJE7qGy5K7vLtqfuCJ2NCs9AaA== From: Frank Oltmanns <frank@oltmanns.dev> Date: Sun, 02 Jul 2023 19:55:25 +0200 Subject: [PATCH v3 6/8] clk: sunxi-ng: mux: Support finding closest rate MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230702-pll-mipi_set_rate_parent-v3-6-46dcb8aa9cbc@oltmanns.dev> References: <20230702-pll-mipi_set_rate_parent-v3-0-46dcb8aa9cbc@oltmanns.dev> In-Reply-To: <20230702-pll-mipi_set_rate_parent-v3-0-46dcb8aa9cbc@oltmanns.dev> To: Maxime Ripard <maxime@cerno.tech>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Chen-Yu Tsai <wens@csie.org>, Jernej Skrabec <jernej.skrabec@gmail.com>, Samuel Holland <samuel@sholland.org>, Andre Przywara <andre.przywara@arm.com>, Roman Beranek <me@crly.cz> Cc: linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, Frank Oltmanns <frank@oltmanns.dev> X-Developer-Signature: v=1; a=openpgp-sha256; l=2527; i=frank@oltmanns.dev; h=from:subject:message-id; bh=HsHfxFRs7DqOrFQiRdG6ZrjV1WoqnP7I3+QzdUYxcq4=; b=owEB7QES/pANAwAIAZppogiUStPHAcsmYgBkobocaAucRSds8Zel2B2AZiCmG1Rk5mjq8PIH7 ek5IE04aoWJAbMEAAEIAB0WIQQC/SV7f5DmuaVET5aaaaIIlErTxwUCZKG6HAAKCRCaaaIIlErT x4U6C/0XkZefhQVUaII1v3aP3hDxww/N4F+dog+qiEvBVe/dTsFsOc9yPS85sDiiWVJHJ+Yvppy ZwCrAv5ZYb1QX0oyb/CZ0qAb5EtDU2Uix0urFYZPj2XWGZgXxZtYu6zO2p9fDmF00u9daMtcfI1 oH8/qofO//Uzu0dGAbom6cIcJDAnkN884yKtknWrNlH0GQXzCgUiKVlNWre3AZkhaHVgIWmYSxF dDwOe5jOO0dyIA4oXRAIIyl25ZOctIPyln4yX8EtEXuXkwQh07x6d5T8J3eCUSwCEoN3xEVzvIs iH86hDfMS+2A06TZa2x08l+N8zaqS+M3IQDheh7pdPueA07sobAPhP13dMbfNrEVYSqLzohmI4c fPgbTUanW2ky8qUnuGpkYmnRFnV1IiCOkwy7rhbXZ2KXpwbFnozFWKBp3qf/jr9UnuRpQk8580F p6x+H8VwStv2Juvpv7crMUF44JdDWKgUOK42lwZg9BcY+1Cns6/llnbaEwblDaSqObhvU= X-Developer-Key: i=frank@oltmanns.dev; a=openpgp; fpr=02FD257B7F90E6B9A5444F969A69A208944AD3C7 X-Rspamd-Queue-Id: 4QvGtz5c4Qz9sZZ X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE 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: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1770335799532153482?= X-GMAIL-MSGID: =?utf-8?q?1770335799532153482?= |
Series |
clk: sunxi-ng: Consider alternative parent rates when determining NKM clock rate
|
|
Commit Message
Frank Oltmanns
July 2, 2023, 5:55 p.m. UTC
When finding the best rate for a mux clock, consider rates that are
higher than the requested rate by introducing a new clk_ops structure
that uses the existing __clk_mux_determine_rate_closest function.
Furthermore introduce an initialization macro that uses this new
structure.
Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
---
drivers/clk/sunxi-ng/ccu_mux.c | 13 +++++++++++++
drivers/clk/sunxi-ng/ccu_mux.h | 17 +++++++++++++++++
2 files changed, 30 insertions(+)
Comments
On Sun, Jul 02, 2023 at 07:55:25PM +0200, Frank Oltmanns wrote: > When finding the best rate for a mux clock, consider rates that are > higher than the requested rate by introducing a new clk_ops structure > that uses the existing __clk_mux_determine_rate_closest function. > Furthermore introduce an initialization macro that uses this new > structure. > > Signed-off-by: Frank Oltmanns <frank@oltmanns.dev> > --- > drivers/clk/sunxi-ng/ccu_mux.c | 13 +++++++++++++ > drivers/clk/sunxi-ng/ccu_mux.h | 17 +++++++++++++++++ > 2 files changed, 30 insertions(+) > > diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c > index 8594d6a4addd..49a592bdeacf 100644 > --- a/drivers/clk/sunxi-ng/ccu_mux.c > +++ b/drivers/clk/sunxi-ng/ccu_mux.c > @@ -264,6 +264,19 @@ static unsigned long ccu_mux_recalc_rate(struct clk_hw *hw, > parent_rate); > } > > +const struct clk_ops ccu_mux_closest_ops = { > + .disable = ccu_mux_disable, > + .enable = ccu_mux_enable, > + .is_enabled = ccu_mux_is_enabled, > + > + .get_parent = ccu_mux_get_parent, > + .set_parent = ccu_mux_set_parent, > + > + .determine_rate = __clk_mux_determine_rate_closest, > + .recalc_rate = ccu_mux_recalc_rate, > +}; > +EXPORT_SYMBOL_NS_GPL(ccu_mux_closest_ops, SUNXI_CCU); > + This is also a bit inconsistent with the other clocks: most (all?) of them will simply handle this through a flag, but this one requires a new set of clk_ops as well? I think we should create our own wrapper here around __clk_mux_determine_rate and either call __clk_mux_determine_rate_closest or __clk_mux_determine_rate depending on the state of the flags, or call __clk_mux_determine_rate_flags with the proper flags set for our clock. The former is probably slightly simpler. > const struct clk_ops ccu_mux_ops = { > .disable = ccu_mux_disable, > .enable = ccu_mux_enable, > diff --git a/drivers/clk/sunxi-ng/ccu_mux.h b/drivers/clk/sunxi-ng/ccu_mux.h > index 2c1811a445b0..c4ee14e43719 100644 > --- a/drivers/clk/sunxi-ng/ccu_mux.h > +++ b/drivers/clk/sunxi-ng/ccu_mux.h > @@ -46,6 +46,22 @@ struct ccu_mux { > struct ccu_common common; > }; > > +#define SUNXI_CCU_MUX_TABLE_WITH_GATE_CLOSEST(_struct, _name, _parents, _table, \ > + _reg, _shift, _width, _gate, \ > + _flags) \ > + struct ccu_mux _struct = { \ > + .enable = _gate, \ > + .mux = _SUNXI_CCU_MUX_TABLE(_shift, _width, _table), \ > + .common = { \ > + .reg = _reg, \ > + .hw.init = CLK_HW_INIT_PARENTS(_name, \ > + _parents, \ > + &ccu_mux_closest_ops, \ > + _flags), \ > + .features = CCU_FEATURE_CLOSEST_RATE, \ > + } \ > + } > + I'm fine with that one, but like we discussed on the NM (I think?) patch already, this creates some clocks and macros that will use the feature as a flag, and some will encode it into their name. Given that we need it here too, I'm really inclined to prefer what you did there, and thus create a new macro for pll-video0 instead of modifying the existing one. Maxime
On 2023-07-03 at 09:38:48 +0200, Maxime Ripard <maxime@cerno.tech> wrote: > [[PGP Signed Part:Undecided]] > On Sun, Jul 02, 2023 at 07:55:25PM +0200, Frank Oltmanns wrote: >> When finding the best rate for a mux clock, consider rates that are >> higher than the requested rate by introducing a new clk_ops structure >> that uses the existing __clk_mux_determine_rate_closest function. >> Furthermore introduce an initialization macro that uses this new >> structure. >> >> Signed-off-by: Frank Oltmanns <frank@oltmanns.dev> >> --- >> drivers/clk/sunxi-ng/ccu_mux.c | 13 +++++++++++++ >> drivers/clk/sunxi-ng/ccu_mux.h | 17 +++++++++++++++++ >> 2 files changed, 30 insertions(+) >> >> diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c >> index 8594d6a4addd..49a592bdeacf 100644 >> --- a/drivers/clk/sunxi-ng/ccu_mux.c >> +++ b/drivers/clk/sunxi-ng/ccu_mux.c >> @@ -264,6 +264,19 @@ static unsigned long ccu_mux_recalc_rate(struct clk_hw *hw, >> parent_rate); >> } >> >> +const struct clk_ops ccu_mux_closest_ops = { >> + .disable = ccu_mux_disable, >> + .enable = ccu_mux_enable, >> + .is_enabled = ccu_mux_is_enabled, >> + >> + .get_parent = ccu_mux_get_parent, >> + .set_parent = ccu_mux_set_parent, >> + >> + .determine_rate = __clk_mux_determine_rate_closest, >> + .recalc_rate = ccu_mux_recalc_rate, >> +}; >> +EXPORT_SYMBOL_NS_GPL(ccu_mux_closest_ops, SUNXI_CCU); >> + > > This is also a bit inconsistent with the other clocks: most (all?) of > them will simply handle this through a flag, but this one requires a new > set of clk_ops as well? > > I think we should create our own wrapper here around > __clk_mux_determine_rate and either call > __clk_mux_determine_rate_closest or __clk_mux_determine_rate depending > on the state of the flags, or call __clk_mux_determine_rate_flags with > the proper flags set for our clock. > > The former is probably slightly simpler. Ok, I will address that in v4. > >> const struct clk_ops ccu_mux_ops = { >> .disable = ccu_mux_disable, >> .enable = ccu_mux_enable, >> diff --git a/drivers/clk/sunxi-ng/ccu_mux.h b/drivers/clk/sunxi-ng/ccu_mux.h >> index 2c1811a445b0..c4ee14e43719 100644 >> --- a/drivers/clk/sunxi-ng/ccu_mux.h >> +++ b/drivers/clk/sunxi-ng/ccu_mux.h >> @@ -46,6 +46,22 @@ struct ccu_mux { >> struct ccu_common common; >> }; >> >> +#define SUNXI_CCU_MUX_TABLE_WITH_GATE_CLOSEST(_struct, _name, _parents, _table, \ >> + _reg, _shift, _width, _gate, \ >> + _flags) \ >> + struct ccu_mux _struct = { \ >> + .enable = _gate, \ >> + .mux = _SUNXI_CCU_MUX_TABLE(_shift, _width, _table), \ >> + .common = { \ >> + .reg = _reg, \ >> + .hw.init = CLK_HW_INIT_PARENTS(_name, \ >> + _parents, \ >> + &ccu_mux_closest_ops, \ >> + _flags), \ >> + .features = CCU_FEATURE_CLOSEST_RATE, \ >> + } \ >> + } >> + > > I'm fine with that one, but like we discussed on the NM (I think?) patch > already, this creates some clocks and macros that will use the feature > as a flag, and some will encode it into their name. > > Given that we need it here too, I'm really inclined to prefer what you > did there, and thus create a new macro for pll-video0 instead of > modifying the existing one. Ok. Just to be clear: What I did in this patch is fine and I should use the same approach for NM. Did I get that right? Thanks, Frank > > Maxime > > [[End of PGP Signed Part]]
On Mon, Jul 03, 2023 at 11:17:24AM +0200, Frank Oltmanns wrote: > > On 2023-07-03 at 09:38:48 +0200, Maxime Ripard <maxime@cerno.tech> wrote: > > [[PGP Signed Part:Undecided]] > > On Sun, Jul 02, 2023 at 07:55:25PM +0200, Frank Oltmanns wrote: > >> When finding the best rate for a mux clock, consider rates that are > >> higher than the requested rate by introducing a new clk_ops structure > >> that uses the existing __clk_mux_determine_rate_closest function. > >> Furthermore introduce an initialization macro that uses this new > >> structure. > >> > >> Signed-off-by: Frank Oltmanns <frank@oltmanns.dev> > >> --- > >> drivers/clk/sunxi-ng/ccu_mux.c | 13 +++++++++++++ > >> drivers/clk/sunxi-ng/ccu_mux.h | 17 +++++++++++++++++ > >> 2 files changed, 30 insertions(+) > >> > >> diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c > >> index 8594d6a4addd..49a592bdeacf 100644 > >> --- a/drivers/clk/sunxi-ng/ccu_mux.c > >> +++ b/drivers/clk/sunxi-ng/ccu_mux.c > >> @@ -264,6 +264,19 @@ static unsigned long ccu_mux_recalc_rate(struct clk_hw *hw, > >> parent_rate); > >> } > >> > >> +const struct clk_ops ccu_mux_closest_ops = { > >> + .disable = ccu_mux_disable, > >> + .enable = ccu_mux_enable, > >> + .is_enabled = ccu_mux_is_enabled, > >> + > >> + .get_parent = ccu_mux_get_parent, > >> + .set_parent = ccu_mux_set_parent, > >> + > >> + .determine_rate = __clk_mux_determine_rate_closest, > >> + .recalc_rate = ccu_mux_recalc_rate, > >> +}; > >> +EXPORT_SYMBOL_NS_GPL(ccu_mux_closest_ops, SUNXI_CCU); > >> + > > > > This is also a bit inconsistent with the other clocks: most (all?) of > > them will simply handle this through a flag, but this one requires a new > > set of clk_ops as well? > > > > I think we should create our own wrapper here around > > __clk_mux_determine_rate and either call > > __clk_mux_determine_rate_closest or __clk_mux_determine_rate depending > > on the state of the flags, or call __clk_mux_determine_rate_flags with > > the proper flags set for our clock. > > > > The former is probably slightly simpler. > > Ok, I will address that in v4. > > > > >> const struct clk_ops ccu_mux_ops = { > >> .disable = ccu_mux_disable, > >> .enable = ccu_mux_enable, > >> diff --git a/drivers/clk/sunxi-ng/ccu_mux.h b/drivers/clk/sunxi-ng/ccu_mux.h > >> index 2c1811a445b0..c4ee14e43719 100644 > >> --- a/drivers/clk/sunxi-ng/ccu_mux.h > >> +++ b/drivers/clk/sunxi-ng/ccu_mux.h > >> @@ -46,6 +46,22 @@ struct ccu_mux { > >> struct ccu_common common; > >> }; > >> > >> +#define SUNXI_CCU_MUX_TABLE_WITH_GATE_CLOSEST(_struct, _name, _parents, _table, \ > >> + _reg, _shift, _width, _gate, \ > >> + _flags) \ > >> + struct ccu_mux _struct = { \ > >> + .enable = _gate, \ > >> + .mux = _SUNXI_CCU_MUX_TABLE(_shift, _width, _table), \ > >> + .common = { \ > >> + .reg = _reg, \ > >> + .hw.init = CLK_HW_INIT_PARENTS(_name, \ > >> + _parents, \ > >> + &ccu_mux_closest_ops, \ > >> + _flags), \ > >> + .features = CCU_FEATURE_CLOSEST_RATE, \ > >> + } \ > >> + } > >> + > > > > I'm fine with that one, but like we discussed on the NM (I think?) patch > > already, this creates some clocks and macros that will use the feature > > as a flag, and some will encode it into their name. > > > > Given that we need it here too, I'm really inclined to prefer what you > > did there, and thus create a new macro for pll-video0 instead of > > modifying the existing one. > > Ok. Just to be clear: What I did in this patch is fine and I should use > the same approach for NM. Did I get that right? Yes. Leave the NM macro as it is, and add a new _CLOSEST variant that sets the flag like you did there. Maxime
diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c index 8594d6a4addd..49a592bdeacf 100644 --- a/drivers/clk/sunxi-ng/ccu_mux.c +++ b/drivers/clk/sunxi-ng/ccu_mux.c @@ -264,6 +264,19 @@ static unsigned long ccu_mux_recalc_rate(struct clk_hw *hw, parent_rate); } +const struct clk_ops ccu_mux_closest_ops = { + .disable = ccu_mux_disable, + .enable = ccu_mux_enable, + .is_enabled = ccu_mux_is_enabled, + + .get_parent = ccu_mux_get_parent, + .set_parent = ccu_mux_set_parent, + + .determine_rate = __clk_mux_determine_rate_closest, + .recalc_rate = ccu_mux_recalc_rate, +}; +EXPORT_SYMBOL_NS_GPL(ccu_mux_closest_ops, SUNXI_CCU); + const struct clk_ops ccu_mux_ops = { .disable = ccu_mux_disable, .enable = ccu_mux_enable, diff --git a/drivers/clk/sunxi-ng/ccu_mux.h b/drivers/clk/sunxi-ng/ccu_mux.h index 2c1811a445b0..c4ee14e43719 100644 --- a/drivers/clk/sunxi-ng/ccu_mux.h +++ b/drivers/clk/sunxi-ng/ccu_mux.h @@ -46,6 +46,22 @@ struct ccu_mux { struct ccu_common common; }; +#define SUNXI_CCU_MUX_TABLE_WITH_GATE_CLOSEST(_struct, _name, _parents, _table, \ + _reg, _shift, _width, _gate, \ + _flags) \ + struct ccu_mux _struct = { \ + .enable = _gate, \ + .mux = _SUNXI_CCU_MUX_TABLE(_shift, _width, _table), \ + .common = { \ + .reg = _reg, \ + .hw.init = CLK_HW_INIT_PARENTS(_name, \ + _parents, \ + &ccu_mux_closest_ops, \ + _flags), \ + .features = CCU_FEATURE_CLOSEST_RATE, \ + } \ + } + #define SUNXI_CCU_MUX_TABLE_WITH_GATE(_struct, _name, _parents, _table, \ _reg, _shift, _width, _gate, \ _flags) \ @@ -113,6 +129,7 @@ static inline struct ccu_mux *hw_to_ccu_mux(struct clk_hw *hw) } extern const struct clk_ops ccu_mux_ops; +extern const struct clk_ops ccu_mux_closest_ops; unsigned long ccu_mux_helper_apply_prediv(struct ccu_common *common, struct ccu_mux_internal *cm,