Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932366AbbBPLTW (ORCPT ); Mon, 16 Feb 2015 06:19:22 -0500 Received: from bear.ext.ti.com ([192.94.94.41]:33669 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932259AbbBPLTV (ORCPT ); Mon, 16 Feb 2015 06:19:21 -0500 Message-ID: <54E1D1F5.2050603@ti.com> Date: Mon, 16 Feb 2015 13:18:13 +0200 From: Tomi Valkeinen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sascha Hauer CC: Russell King - ARM Linux , Liu Ying , , , , , , , , , , Subject: Re: [PATCH RFC v9 01/20] clk: divider: Correct parent clk round rate if no bestdiv is normally found References: <1423720903-24806-1-git-send-email-Ying.Liu@freescale.com> <1423720903-24806-2-git-send-email-Ying.Liu@freescale.com> <20150212093356.GR12209@pengutronix.de> <20150212103944.GA1290@victor> <20150212122405.GW12209@pengutronix.de> <20150212125646.GT8656@n2100.arm.linux.org.uk> <20150212134131.GX12209@pengutronix.de> <54DE0BB8.7070004@ti.com> <20150213185713.GA12209@pengutronix.de> In-Reply-To: <20150213185713.GA12209@pengutronix.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3KoQEK9a3HUH6aNkKimN5SAagQexSt6lr" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2754 Lines: 73 --3KoQEK9a3HUH6aNkKimN5SAagQexSt6lr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 13/02/15 20:57, Sascha Hauer wrote: > On Fri, Feb 13, 2015 at 04:35:36PM +0200, Tomi Valkeinen wrote: >> On 12/02/15 15:41, Sascha Hauer wrote: >> >>> Tomis patch is based on the assumption that clk_set_rate(clk_round_ra= te(rate)) >>> is equal to clk_round_rate(rate). So when this assumption is wrong th= en >>> it should simply be reverted. >> >> When is it not equal? >> >> I agree that doing clk_set_rate(clk, clk_round_rate(clk, rate)) is >> pointless, but shouldn't it still work? >> >> And we can forget about clk_round_rate. Without my patch, this would >> behave oddly also: >> >> rate =3D clk_get_rate(clk); >> clk_set_rate(clk, rate); >> >> The end result could be something else than 'rate'. >=20 > I agree that it's a bit odd, but I think it has to be like this. > Consider that you request a rate of 100Hz, but the clock can only > produce 99.5Hz, so due to rounding clk_round_rate() returns 99Hz. > Now when you request 99Hz from clk_set_rate() the 99.5Hz value > can't be used because it's too high. Would that problem better be fixed by changing the clock driver so that when asked for 99Hz, it would look for rates less than 100Hz? I think the old behavior was so odd that I would call it broken, so I hope the current problems can be fixed via some other ways than breaking it again. Tomi --3KoQEK9a3HUH6aNkKimN5SAagQexSt6lr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU4dH5AAoJEPo9qoy8lh71fEsP/3cvSwjn50zaGlKoQK//7/Yv RGzA+FGDC0Bj7tseL9tiEn5O/ACQC1Mg0HLiRBmFt65VORdfY+Xbgn9Cb1/pAHk4 lw5gyCwWUPQZix09WN2XXe2mmHXXSl4Tc6WTD3iNa3kAqF+kBk+zP27Ii5avF9wZ s6Yrx90DktOMhdY18hAuIHg14L2Z8S7wD/YVOuPNCb4vkVX3xgEmkwqADO2lidal TLz/IDmJfZorBztN5ufmllvQWmee4qQAJuBttf8VQNx+eq4efJH20hFLH/XZgRAJ TllGfhtKJHZ6thwgDPlng5IUix448mZTN7BGzHSQp7KFfBkh8KJiddFm6FCB8EUC nIWIfn4DBcFp1Od5naC8g4+wRdg+MUA/BPxokRSGg28DkH0vnzE5EshW08oJol63 gJhBlK4mdy0sr9vHkNHdSbBUbXhqu7i8S+yp3RynRYKquHHTUyGIGoJ9xqatlQ3a 8Jr37uHCOQbdBwHxmxkPIPSTIWvAbfozBVZYXyVQcrYI294/ex/ZHV4rJmxOa/r3 eXH65UNjJqt0dlss4GHFtnw0h5f5L84u7RxPZy+kG9k4xOVxhVdOurlfaTUbfPdW zO1/Hx62rkUpj7n9Xh9O01o5kkJEvi4wAYaaX3HW9Az5OoDQKJoZvXR4dFgVRJ52 b28RuW+JE7mnV05Pd6o6 =HUt4 -----END PGP SIGNATURE----- --3KoQEK9a3HUH6aNkKimN5SAagQexSt6lr-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/