[PATCH 0/2] driver core: platform: / drm/msm: dp: Delay applying clock defaults
Michael Walle
mwalle at kernel.org
Mon Aug 18 12:47:55 UTC 2025
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 297 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/freedreno/attachments/20250818/ae825a30/attachment.sig>
More information about the Freedreno
mailing list