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
WARNING: multiple messages have this Message-ID (diff)
From: Frank Oltmanns <frank@oltmanns.dev>
To: Roman Beranek <me@crly.cz>
Cc: Samuel Holland <samuel@sholland.org>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Chen-Yu Tsai <wens@csie.org>, Ondrej Jirman <megi@xff.cz>,
linux-sunxi@lists.linux.dev,
linux-arm-kernel@lists.infradead.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
next prev parent reply other threads:[~2023-05-08 7:04 UTC|newest]
Thread overview: 45+ 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 ` Roman Beranek
2023-04-18 7:40 ` 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-18 7:40 ` Roman Beranek
2023-04-18 7:40 ` Roman Beranek
2023-04-25 16:09 ` Maxime Ripard
2023-04-25 16:09 ` Maxime Ripard
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 ` Roman Beranek
2023-04-18 7:40 ` 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 ` Roman Beranek
2023-04-18 7:40 ` 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-18 7:40 ` Roman Beranek
2023-04-18 7:40 ` Roman Beranek
2023-04-25 16:10 ` Maxime Ripard
2023-04-25 16:10 ` Maxime Ripard
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 ` Roman Beranek
2023-04-18 7:40 ` 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 ` Roman Beranek
2023-04-18 7:40 ` Roman Beranek
2023-04-18 7:40 ` [PATCH v2 7/7] drm: sun4i: calculate proper DCLK rate for DSI Roman Beranek
2023-04-18 7:40 ` Roman Beranek
2023-04-18 7:40 ` Roman Beranek
2023-04-23 13:24 ` [PATCH v2 0/7] drm: sun4i: set proper TCON0 DCLK rate in DSI mode Frank Oltmanns
2023-04-23 13:24 ` Frank Oltmanns
2023-04-23 13:24 ` Frank Oltmanns
2023-05-01 13:40 ` Frank Oltmanns
2023-05-01 13:40 ` Frank Oltmanns
2023-05-01 13:40 ` Frank Oltmanns
2023-05-03 14:22 ` Roman Beranek
2023-05-03 14:22 ` Roman Beranek
2023-05-03 14:22 ` Roman Beranek
2023-05-08 6:54 ` Frank Oltmanns [this message]
2023-05-08 6:54 ` Frank Oltmanns
2023-05-08 14:08 ` Frank Oltmanns
2023-05-08 14:08 ` Frank Oltmanns
2023-05-10 18:41 ` Jernej Škrabec
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.