[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200414092412.scsl6sekikc2tsv5@pengutronix.de>
Date: Tue, 14 Apr 2020 11:24:12 +0200
From: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
To: Stephen Boyd <sboyd@...nel.org>,
Michael Turquette <mturquette@...libre.com>
Cc: linux-pwm@...r.kernel.org, od@...c.me,
Artur Rojek <contact@...ur-rojek.eu>,
Mathieu Malaterre <malat@...ian.org>,
linux-kernel@...r.kernel.org, Paul Cercueil <paul@...pouillou.net>,
Thierry Reding <thierry.reding@...il.com>,
kernel@...gutronix.de, linux-clk@...r.kernel.org
Subject: Re: About rounding in the clk framework [Was: Re: [PATCH 4/7] pwm:
jz4740: Improve algorithm of clock calculation]
Hello Stephen, hello Michael,
On Wed, Feb 12, 2020 at 08:29:11AM +0100, Uwe Kleine-König wrote:
> Can you please explain what is the reason why clk_round_rate_up/down()
> is a bad idea? Would it help to create a patch that introduces these
> functions to get the discussion going?
I didn't get any feedback on my mail. Are you to busy working on more
important stuff? Is the answer so obvious that you don't consider it
worth your time to answer?
Looking a bit through the code I see there are two callbacks hwclks can
provide to implement rounding (determine_rate and round_rate). The docs
for both use the term "return the closes rate actually supported". Does
that mean "round-closest" is already the official policy and other
strategies in lowlevel drivers are a bug?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Powered by blists - more mailing lists