From mboxrd@z Thu Jan 1 00:00:00 1970 From: sboyd@codeaurora.org (Stephen Boyd) Date: Tue, 20 May 2014 10:48:43 -0700 Subject: [RFC PATCH 2/5] clk: Introduce 'clk_round_rate_nearest()' In-Reply-To: <4bb5f44a-60bb-4e34-8f88-f91b8419be8d@BL2FFO11FD050.protection.gbl> References: <1400106655-22465-1-git-send-email-soren.brinkmann@xilinx.com> <1400106655-22465-3-git-send-email-soren.brinkmann@xilinx.com> <20140515073816.GI16662@pengutronix.de> <91822600-39d0-4e71-b0f5-9eda35b76ec0@BN1AFFO11FD016.protection.gbl> <20140519161949.GG16662@pengutronix.de> <20140520073358.GJ16662@pengutronix.de> <4bb5f44a-60bb-4e34-8f88-f91b8419be8d@BL2FFO11FD050.protection.gbl> Message-ID: <537B957B.5010001@codeaurora.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 05/20/14 09:01, S?ren Brinkmann wrote: > >>>>> +{ >>>>> + unsigned long lower, upper, cur, lower_last, upper_last; >>>>> + >>>>> + lower = clk_round_rate(clk, rate); >>>>> + if (lower >= rate) >>>>> + return lower; >>>> Is the >-case worth a warning? >>> No, it's correct behavior. If you request a rate that is way lower than what the >>> clock can generate, returning something larger is perfectly valid, IMHO. >>> Which reveals one problem in this whole discussion. The API does not >>> require clk_round_rate() to round down. It is actually an implementation >>> choice that had been made for clk-divider. >> I'm sure it's more than an implementation choice for clk-divider. But I >> don't find any respective documentation (but I didn't try hard). > A similar discussion - without final conclusion: > https://lkml.org/lkml/2010/7/14/260 > > Please call this new API something like clk_find_nearest_rate() or something. clk_round_rate() is supposed to return the rate that will be set if you call clk_set_rate() with the same arguments. It's up to the implementation to decide if that means rounding the rate up or down or to the nearest value. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation