public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frank Oltmanns <frank@oltmanns.dev>
To: Roman Beranek <me@crly.cz>
Cc: Maxime Ripard <mripard@kernel.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Chen-Yu Tsai <wens@csie.org>, David Airlie <airlied@gmail.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Samuel Holland <samuel@sholland.org>, Ondrej Jirman <megi@xff.cz>,
	dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/7] drm: sun4i: set proper TCON0 DCLK rate in DSI mode
Date: Mon, 08 May 2023 08:54:28 +0200	[thread overview]
Message-ID: <87o7mvpayj.fsf@oltmanns.dev> (raw)
In-Reply-To: <CSCPKPC8OB80.1TTBCM3YDVJQ5@void.crly.cz>

Hello Roman,

On 2023-05-03 at 16:22:32 +0200, "Roman Beranek" <me@crly.cz> 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@crly.cz/

>
> Best regards
> Roman

  reply	other threads:[~2023-05-08  6:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-18  7:40 [PATCH v2 0/7] drm: sun4i: set proper TCON0 DCLK rate in DSI mode Roman Beranek
2023-04-18  7:40 ` [PATCH v2 1/7] clk: sunxi-ng: a64: propagate rate change from pll-mipi Roman Beranek
2023-04-25 16:09   ` Maxime Ripard
2023-04-18  7:40 ` [PATCH v2 2/7] clk: sunxi-ng: a64: export PLL_MIPI Roman Beranek
2023-04-18  7:40 ` [PATCH v2 3/7] clk: sunxi-ng: a64: prevent CLK_TCON0 being reparented Roman Beranek
2023-04-18  7:40 ` [PATCH v2 4/7] arm64: dts: allwinner: a64: assign PLL_MIPI to CLK_TCON0 Roman Beranek
2023-04-25 16:10   ` Maxime Ripard
2023-04-18  7:40 ` [PATCH v2 5/7] ARM: dts: sunxi: rename tcon's clock output Roman Beranek
2023-04-18  7:40 ` [PATCH v2 6/7] drm: sun4i: rename sun4i_dotclock to sun4i_tcon_dclk Roman Beranek
2023-04-18  7:40 ` [PATCH v2 7/7] drm: sun4i: calculate proper DCLK rate for DSI Roman Beranek
2023-04-23 13:24 ` [PATCH v2 0/7] drm: sun4i: set proper TCON0 DCLK rate in DSI mode Frank Oltmanns
2023-05-01 13:40   ` Frank Oltmanns
2023-05-03 14:22     ` Roman Beranek
2023-05-08  6:54       ` Frank Oltmanns [this message]
2023-05-08 14:08         ` Frank Oltmanns
2023-05-10 18:41           ` Jernej Škrabec

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o7mvpayj.fsf@oltmanns.dev \
    --to=frank@oltmanns.dev \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=me@crly.cz \
    --cc=megi@xff.cz \
    --cc=mripard@kernel.org \
    --cc=samuel@sholland.org \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox