Hello Roman,
On 2023-05-03 at 16:22:32 +0200, "Roman Beranek" <me@xxxxxxx> wrote:
> Hello everyone,
>
> I apologize for my absence from the discussion during past week, I got
> hit with tonsillitis.
I hope you feel better!
> On Mon May 1, 2023 at 3:40 PM CEST, Frank Oltmanns wrote:
>> Looking at ccu_nkm_determine_rate(), we've found our culprit because it
>> does not try parent clock rates other than the current one. The same
>> applies to all other ccu_nkm_* functions.
>
> Yes, that's why I dropped CLK_SET_RATE_PARENT from pll-mipi in v3.
>
>> b. Add functionality to ccu_nkm_* to also update the parent clock rate.
>>
>> I'm actually interested in tackling b, but I can't make any promises as
>> to if and when I'll be able to solve it. I'm not certain about any side
>> effects this might have.
>
> It sounds like an interesting exercise. But what if HDMI is then added
> to the mix?
Thanks for interest in this discussion! I really appreciate it!
First of all, let me admit that I'm no expert on this. But nobody else
has replied so far, and I want to keep this conversation going, so let
me share my view.
My understanding is that pll-mipi being able to set pll-video0's rate
should not have an impact on HDMI, neither positive nor negative. If I'm
not mistaken those two things are orthogonal.
The relevant part of the clk_summary with your v4 [1] patch on top of
drm-next looks like this:
enable protect hardware
clock count count rate enable
----------------------------------------------------------------------
pll-video0 1 1 294000000 Y
hdmi 0 0 294000000 N
tcon1 0 0 294000000 N
pll-mipi 1 1 431200000 Y
tcon0 2 1 431200000 Y
tcon-data-clock 1 1 107800000 Y
pll-video0-2x 0 0 588000000 Y
Note, that pll-video0 is protected.
I don't own any boards that support HDMI in mainline. For the pinephone
this support is added e.g. in megi's kernel, where connecting an HDMI
output results in pll-video0's rate being set to 297MHz, even though it
is 294MHz after boot.
So, for reference, this is the same part of the clk_summary with megi's
6.3.0 kernel, USB-C dock unplugged:
enable protect hardware
clock count count rate enable
----------------------------------------------------------------------
pll-video0 3 0 294000000 Y
hdmi-phy-clk 1 0 73500000 Y
hdmi 1 0 294000000 Y
tcon1 0 0 294000000 N
pll-mipi 1 0 431200000 Y
tcon0 2 0 431200000 Y
tcon-pixel-clock 1 0 107800000 Y
pll-video0-2x 0 0 588000000 Y
pll-video0 is not protected. When plugging in the USB-C dock with an HDMI
monitor connected, the situation looks like this:
enable protect hardware
clock count count rate enable
----------------------------------------------------------------------
pll-video0 4 1 297000000 Y
hdmi-phy-clk 1 0 148500000 Y
hdmi 1 0 148500000 Y
tcon1 1 1 148500000 Y
pll-mipi 1 0 424285714 Y
tcon0 2 0 424285714 Y
tcon-pixel-clock 1 0 106071428 Y
pll-video0-2x 0 0 594000000 Y
As you can see, pll-video0 is updated to 297 MHz. My understanding is
(again: not an expert here) this is only possible due to the missing
protection.
What I'm trying to say is that I don't see a connection between HDMI and
having the functionality in ccu_nkm_* to update the parent clock rate.
But I do think it would be preferable to have pll-video0 at 297 MHz
after boot on the pinephone. We could achieve this with my two previous
proposals:
a) Set pll-video0 to 297 MHz on boot
b) Add functionality to ccu_nkm_* to also update the parent clock rate.
If solution b is viable, the goal for the pinephone (and any other
boards supporting HDMI) would then be to select a pixel-data-clock so
that the rate for pll-video0 is set to 297 MHz (by selecting an
appropriate clock speed for the internal panel).
Maybe I'm misunderstanding something. If so, I'd appreciate any
corrections.
Thanks,
Frank
[1]: https://lore.kernel.org/all/20230505052110.67514-1-me@xxxxxxx/
>
> Best regards
> Roman
