From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C4679C433F5 for ; Sat, 1 Oct 2022 10:41:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=jTAxK/zI/4/AqMCeksF9av+CUOrbQ56xwbpEuMmjzyk=; b=hkzh88oNRL6Kr4 w9vf8SlauCM6ZwYajQ1Qp9SqhW3b/0VLrN3VF64P8St8tko+agEJxu1/PqALbQZmtYF0BRzJIOmQa QoByEDPSgjAzIQ1G2T69MloRofkixOfkVyxBML5NuyDkFIhc9bbcDqRjApswg22GS8H0Kx8vLCFTI 8ojQWLRkYKnbcYenzF3N4gE4Y+KPMhzJNRXmKJmXRVLitJbXmuVALe7a3jEmHor2J6AviuuLiCThH KAw6DsxjFYgLQjXsBnL3GxOpT3Xye7/kYy6Mi0Q4PJ/CAVOoWNhR/lxzWxwu4uIlqaxS3zh/F47Gc dYHjkYzWTLJkv+gzJz7w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oeZul-00EAwC-SX; Sat, 01 Oct 2022 10:40:12 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oeZuj-00EAsv-Cc for linux-arm-kernel@lists.infradead.org; Sat, 01 Oct 2022 10:40:11 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A489F5C0189; Sat, 1 Oct 2022 06:40:03 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sat, 01 Oct 2022 06:40:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1664620803; x= 1664707203; bh=b/+Ttgoaang+cJhHV5IX3sd+XwgOFB5wO7nsllJd+kQ=; b=b vfSxuhVzgjkSf4TqamudQc+iFtYwFoyYLs3ZbIGaq4O9PnsbowGKM72cyYGnwqAp NYhxxdGi/XY8XQEXlvT8auTuycJ1E7JbvOzFX+brmSZb5M9Gq7e30QgixWQbOchJ FeEeKjBxit8P5Ul9E0miak/mEBAlMpHP27FMCrsx3H4vLFXU1GDQMtTetcXjGdVN ZrsinqnZtnCnmR6Eqi0+2SZ3vsK33wpXGlXRIdmeX6suBGGq9e8DNsxxBri8UWKG Qh+ou+mNrX0c8YlCTcQWvOJ7DdB7NkRw+PqFsRGe4pYPviYTDKaB0OiI2oMCmPs2 NeDn+PE93zvKd1v6dkuLw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1664620803; x= 1664707203; bh=b/+Ttgoaang+cJhHV5IX3sd+XwgOFB5wO7nsllJd+kQ=; b=G gOmEqYmC2hfiDfCuRCAFyR1ni6Y9BMmlsvvWQ74CJRyOWh4qbeYSGRWAoJOMR2x/ 1R1N/3psvIaOFoXwyKB3bI2lfo6NtL463K4/V0SOalwzelFBRxEMIRry33yhA43c jGtlgGSeVnRMdSqaXZ+ZT4tj1+y7MaKI3T9g2+LyJyctXbypJsei2snr3CB2UHcl VKeeLZy5lxMl449VktUDovRja9+zk5NPbArO/ve3bKjKUz1AgFdY0j/Nh2pc2zQL yUPWnUQYFcQnw2F0cBnyLt5j4cKfd++aKbevheFisbxTzCtvXazA7N2nTcSImuIk iRfYgB2XrAy8Y4L1tx/zQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeehgedgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggugfgjsehtqhertddttddunecuhfhrohhmpeforgig ihhmvgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrf grthhtvghrnhepjeevffdtheevvdefveffffejkedtgfekvdeigfefhfefgfethfejjeei geeiueegnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrgigihhmvgestggvrhhnohdrthgv tghh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 1 Oct 2022 06:40:02 -0400 (EDT) Date: Sat, 1 Oct 2022 12:40:01 +0200 From: Maxime Ripard To: Stephen Boyd Cc: Laurent Pinchart , Quanyang Wang , linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Michal Simek , Rajan Vaja Subject: Re: [PATCH] clk: zynqmp: pll: Fix divider calculation to avoid out-of-range rate Message-ID: <20221001104001.r7r2utwymm32tv53@houat> References: <20220928201656.30318-1-laurent.pinchart@ideasonboard.com> <11481209-7c8f-7543-1e04-5723ffc2ccd4@windriver.com> <20221001000503.23268C433D6@smtp.kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20221001000503.23268C433D6@smtp.kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221001_034009_543417_81E07CBA X-CRM114-Status: GOOD ( 20.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi On Fri, Sep 30, 2022 at 05:05:01PM -0700, Stephen Boyd wrote: > +Maxime > = > Quoting Quanyang Wang (2022-09-28 18:05:10) > > Hi Laurent, > > = > > I have sent a patch as below to fix this issue which set rate failed an= d = > > it's in linux-next repo now. > > = > > https://lore.kernel.org/linux-arm-kernel/20220826142030.213805-1-quanya= ng.wang@windriver.com/T/ > > = It looks to me that the fundamental issue is that, in some situations, the round_rate implementation can return a rate outside of the boundaries enforced on a clock. I think that's the current behaviour (that was there prior to my patches) to reject any rate outside of the boundaries in clk_calc_new_rates() makes it clear that it's not something we should allow. I'm a bit two-minded on this though. All the failures of that test I've seen actually turned out to be bugs, so I guess it's useful, but it's also true that for rounding errors it's a bit overkill. We could also relax that check and warn instead of failing. > > As for the frequency gap between the requested rate and the actual, it'= s = > > because of the commit: > > = > > commit 948fb0969eae8 > > Author: Maxime Ripard > > Date:=A0=A0 Fri Feb 25 15:35:26 2022 +0100 > > = > > =A0=A0=A0 clk: Always clamp the rounded rate > > = > > And I haven't figured out how to fix it. Again, it boils down on whether or not we should allow a rate outside of boundaries. If we don't and if the clock can't do better, then yeah, the rate difference is fairly big but we can't do better. > Maxime has some more patches to fix this and they're in linux-next. > Maybe those fix this problem? I don't think they will fix it. However, depending on the outcome of that discussion I can send more fixes your way :) Maxime _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel