Messages in this thread | ![/](/images/icornerl.gif) | | From | Frank Oltmanns <> | Subject | Re: [RFC PATCH 0/3] clk: sunxi-ng: Optimize rate selection for NKM clocks | Date | Mon, 05 Jun 2023 13:41:17 +0200 |
| |
Hi Jernej, hi Maxime,
On 2023-06-02 at 09:34:03 +0200, Maxime Ripard <mripard@kernel.org> wrote: > [[PGP Signed Part:Undecided]] > On Thu, Jun 01, 2023 at 09:41:30PM +0200, Jernej Škrabec wrote: >> Dne četrtek, 01. junij 2023 ob 07:16:45 CEST je Frank Oltmanns napisal(a): >> > Re: Why speed up factor calculation? >> > ==================================== >> > I'm not aware that the current implementation of calculating n, k, and m >> > poses a bottleneck in any situation. Again, while going through the >> > code, I wondered why not save a few CPU cycles by precalculating the >> > meaningful combinations. In my opinion, it does not have any side >> > effects, so we might as well do it. (There is of course the side effect >> > of using a higher rate, but this is unrelated to precalculation as I >> > could as well employ a rate comparison that only allows lower rates, or >> > only optionally higher rates.) >> > >> > > Clocks in general are very regression-prone, so I'd rather be a bit >> > > conservative there, and "if it ain't broke, don't fix it". >> > >> > Sure, I get that. >> > >> > As I stated in my cover letter: >> > "The motivation for these proposed changes lies in the current behavior >> > of rate selection for NKM clocks, which doesn't observe the >> > CLK_SET_RATE_PARENT flag. I.e. it does not select a different rate for >> > the parent clock to find the optimal rate." >> > >> > I thought that this required this optimization to be implemented, but by >> > now, I'm no longer sure. I'll probably continue investigating different >> > paths for CLK_SET_RATE_PARENT for NKM clocks and follow up with new >> > findings. >> >> Let's leave out any optimizations that are not apparently needed. Most clock >> rates are set only once at boot and others, like video clocks, not that often, >> so a suboptimal code speed doesn't hurt currently. > > I'm not even sure we can make that assumption for video clocks. We might > for a panel, but for a more "dynamic" output like HDMI all bets are off > and depending on the monitor, the user settings and the userspace stack > we can definitely expect the video clock to change quite frequently.
Thank you both for your valuable feedback!
The goal I head in mind was adjusting pll-video0's clock when setting DCLK on Allwinner A64. And you're both right, I got sidetracked by premature optimizations.
As I wrote elsewhere in this thread, I will submit a patchset for the original goal and we can discuss potential needs for optimization there.
Thanks, Frank
> > Maxime > > [[End of PGP Signed Part]]
| ![\](/images/icornerr.gif) |