Re: [PATCH 0/2] driver core: platform: / drm/msm: dp: Delay applying clock defaults

["Michael Walle" <mwalle@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

Hi,

On Thu Aug 14, 2025 at 11:18 AM CEST, Stephan Gerhold wrote:
> Michael had a somewhat related problem in the PVR driver recently [1],
> where of_clk_set_defaults() needs to be called a second time from the PVR
> driver (after the GPU has been powered on) to make the assigned-clock-rates
> work correctly.

I've come back to this and just noticed that the
assigned-clock-rates do actually work. What doesn't work is the
caching of the clock rate. That bug was then masked by calling
of_clk_set_defaults() again in the driver.

Here is what the driver is doing:
 (1) driver gets handle to the clock with clk_get().
 (2) driver enables clock with clk_enable()
 (3) driver does a clk_get_rate() which returns 0, although there is
     already a hardware default in my case. That got me curious
     again..

Now on the k3 platforms the clocking is handled by a firmware and it
appears that the firmware is reporting a clock rate of 0 unless the
clock is actually enabled. After the clock is enabled it will report
the correct rate. (FWIW, I can modify the hardware/firmware default
rate with the assigned-clock-rates DT property).

I've hacked the clock driver to register all clocks with
CLK_GET_RATE_NO_CACHE and then everything is working as expected.

I'm no expert for the clocking framework, but it seems that
clk_get() will ask the HW for the clk rate and caches it early on.

-michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]