Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp68367ybm; Thu, 28 May 2020 16:17:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzpMPtxFZAVNWEnI7hfMpsBDeIICNxvCDY2YmFG/vZsHbe2WTpSFdp4cDnqMHoTHlLiai7a X-Received: by 2002:a50:8d07:: with SMTP id s7mr5728543eds.371.1590707842107; Thu, 28 May 2020 16:17:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590707842; cv=none; d=google.com; s=arc-20160816; b=vARM3FWUSA9Fyk1vxyJmkXlRC3TeeS4Y00mVD15dYL4m091nyhaIpssR2drgys4EAR Ncztt5ErQyeuG2KLTXflqCWwndP8NnQ4z/40GtayoiVoLDU15SJ7zClt6PHD5iCXIT/D k2LZEXJxY39vo0r520mjYvcFnUyI6bSnVA+2VSM8LHgMOtUBVhPHY1kpNqL+vPYaFTcV K0WmUci9s+iKiukJRwqPbOqPmZUxTyMpJduXo9db2NY0McVfFjOCeB+9tFBR6cB0fVE6 jS1BjY/LWa0hVmKPZiZKPPklrKt28iaElYj4u8lCKj1ZzmcuokXAJbTLNKdBWuruOsvc lHeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:date:to:cc:from :subject:references:in-reply-to:content-transfer-encoding :mime-version:dkim-signature; bh=Hpkd/bnzAwMa2wYaLNzcSxcPwpiTe5W01TOCSeHtFtk=; b=NpUeuuh5p3gh4wP/0CkXChpsInAfY1fRokLYOo1d3uFUXlO9lS2fMGhuJYFP1UHip7 0jfS2J78wJieXKey0u5WNL0y2Ye3TYIKf5Qx4XqD6cfYXgp5WqlkbDGA/7np1Pmu4dCJ 7G/6ndoztQSRSSlDEqgs3F33Hp0zH2l7cGTDVhYO30wXFCwC8612ecrzrsaMGiUHZKgs FE4weBbQ9479VvRRJvrdUyo9S7gmWInWUuVlA0Hl2dZguzv7g5GVU0TSk8mr9tc+NgwH qUPRt7aVRGzZNhobzIGJMF/QfH2DUrm4+0tN0otTh0gwvqMnr1pgLvIgK7G9u8SK6QYS evSg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=SObhxzW0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p19si4613694ejj.538.2020.05.28.16.16.57; Thu, 28 May 2020 16:17:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=SObhxzW0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391551AbgE1XMl (ORCPT + 99 others); Thu, 28 May 2020 19:12:41 -0400 Received: from mail.kernel.org ([198.145.29.99]:51156 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389436AbgE1XMj (ORCPT ); Thu, 28 May 2020 19:12:39 -0400 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5B6E520776; Thu, 28 May 2020 23:12:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590707558; bh=VGj2i8flL9JlQmAgKNzGrKzB+vOOk0rvJ232QmrQW+U=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=SObhxzW0L9TD8+lQKsRJoVJbBChIFc11d9J4X/Xct+03ugNYxr56U2xTRNwgn7dHB aExWegMQLCmeVfn7ykME1aGYMtvOKHaaYYjziXI/cHRzY7cDqQV20dImop//7idsQ9 id34cjmGl/0MApGajyGtOqF4UTajggOQNMSVEIZ0= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <2c8cd31a-46ba-ec6a-67a7-f3d9abe561ff@xilinx.com> References: <1584048699-24186-1-git-send-email-jolly.shah@xilinx.com> <1584048699-24186-3-git-send-email-jolly.shah@xilinx.com> <159054169658.88029.371843532116000844@swboyd.mtv.corp.google.com> <2c8cd31a-46ba-ec6a-67a7-f3d9abe561ff@xilinx.com> Subject: Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction clock check from custom type flags From: Stephen Boyd Cc: rajanv@xilinx.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Tejas Patel , Rajan Vaja To: Jolly Shah , arm@kernel.org, linux-clk@vger.kernel.org, michal.simek@xilinx.com, mturquette@baylibre.com, olof@lixom.net Date: Thu, 28 May 2020 16:12:37 -0700 Message-ID: <159070755756.69627.18401650656284023600@swboyd.mtv.corp.google.com> User-Agent: alot/0.9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Jolly Shah (2020-05-28 10:44:01) > Hi Stephan, >=20 > Thanks for the review. >=20 > > ------Original Message------ > > From: Stephen Boyd > > Sent: Tuesday, May 26, 2020 6:08PM > > To: Jolly Shah , Arm ,=20 > Linux-clk , Michal Simek=20 > , Mturquette , Olof=20 > > > Cc: Rajan Vaja ,=20 > Linux-arm-kernel@lists.infradead.org=20 > , Linux-kernel@vger.kernel.org=20 > , Tejas Patel ,=20 > Rajan Vaja , Jolly Shah > > Subject: Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction=20 > clock check from custom type flags > > > > Quoting Jolly Shah (2020-03-12 14:31:39) > >> From: Tejas Patel > >> > >> Older firmware version sets BIT(13) in clkflag to mark a > >> divider as fractional divider. Updated firmware version sets BIT(4) > >> in type flags to mark a divider as fractional divider since > >> BIT(13) is defined as CLK_DUTY_CYCLE_PARENT in the common clk > >> framework flags. > >> > >> To support both old and new firmware version, consider BIT(13) from > >> clkflag and BIT(4) from type_flag to check if divider is fractional > >> or not. > >> > >> To maintain compatibility BIT(13) of clkflag in firmware will not be > >> used in future for any purpose and will be marked as unused. > >=20 > > Why are we mixing the firmware flags with the ccf flags? They shouldn't > > be the same. The firmware should have its own 'flag numberspace' that is > > distinct from the common clk framework's 'flag numberspace'. Please fix > > the code. > >=20 >=20 > Yes firmware flags are using separate numberspace now. Firmware=20 > maintains CCF and firmware specific flags separately but earlier=20 > CLK_FRAC was mistakenly defined in ccf flagspace and hence handled here=20 > for backward compatibility. Driver takes care of not registering same=20 > with CCF. Let me know if I misunderstood. Why is the firmware maintaining CCF specific flags? The firmware shouldn't know about the CCF flag numbering at all. We can change the numbers that the CCF flags are assigned to randomly and that shouldn't mean that the firmware needs to change. Maybe I should apply this patch? ---8<---- diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index bd1ee9039558..c1f36bca85b0 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -16,22 +16,22 @@ * * Please update clk_flags[] in drivers/clk/clk.c when making changes here! */ -#define CLK_SET_RATE_GATE BIT(0) /* must be gated across rate change */ -#define CLK_SET_PARENT_GATE BIT(1) /* must be gated across re-parent */ -#define CLK_SET_RATE_PARENT BIT(2) /* propagate rate change up one level */ -#define CLK_IGNORE_UNUSED BIT(3) /* do not gate even if unused */ +#define CLK_SET_RATE_GATE BIT(13) /* must be gated across rate change */ +#define CLK_SET_PARENT_GATE BIT(2) /* must be gated across re-parent */ +#define CLK_SET_RATE_PARENT BIT(3) /* propagate rate change up one level */ +#define CLK_IGNORE_UNUSED BIT(4) /* do not gate even if unused */ /* unused */ /* unused */ -#define CLK_GET_RATE_NOCACHE BIT(6) /* do not use the cached clk rate */ -#define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate change = */ -#define CLK_GET_ACCURACY_NOCACHE BIT(8) /* do not use the cached clk accur= acy */ -#define CLK_RECALC_NEW_RATES BIT(9) /* recalc rates after notifications */ -#define CLK_SET_RATE_UNGATE BIT(10) /* clock needs to run to set rate */ -#define CLK_IS_CRITICAL BIT(11) /* do not gate, ever */ +#define CLK_GET_RATE_NOCACHE BIT(5) /* do not use the cached clk rate */ +#define CLK_SET_RATE_NO_REPARENT BIT(6) /* don't re-parent on rate change = */ +#define CLK_GET_ACCURACY_NOCACHE BIT(7) /* do not use the cached clk accur= acy */ +#define CLK_RECALC_NEW_RATES BIT(8) /* recalc rates after notifications */ +#define CLK_SET_RATE_UNGATE BIT(9) /* clock needs to run to set rate */ +#define CLK_IS_CRITICAL BIT(10) /* do not gate, ever */ /* parents need enable during gate/ungate, set rate and re-parent */ -#define CLK_OPS_PARENT_ENABLE BIT(12) +#define CLK_OPS_PARENT_ENABLE BIT(11) /* duty cycle call may be forwarded to the parent clock */ -#define CLK_DUTY_CYCLE_PARENT BIT(13) +#define CLK_DUTY_CYCLE_PARENT BIT(12) =20 struct clk; struct clk_hw;