From: Liu Ying <victor.liu@nxp.com>
To: Marek Vasut <marex@denx.de>,
linux-clk@vger.kernel.org, shengjiu.wang@nxp.com
Cc: Abel Vesa <abelvesa@kernel.org>,
Fabio Estevam <festevam@gmail.com>,
Michael Turquette <mturquette@baylibre.com>,
Peng Fan <peng.fan@nxp.com>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Sascha Hauer <s.hauer@pengutronix.de>,
Shawn Guo <shawnguo@kernel.org>, Stephen Boyd <sboyd@kernel.org>,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] clk: imx: pll14xx: Extend dynamic rates support to PLL1416x
Date: Wed, 13 Nov 2024 12:00:32 +0800 [thread overview]
Message-ID: <83a67ab8-8f3e-4ab0-b68b-4da156817649@nxp.com> (raw)
In-Reply-To: <0a62d3b7-b435-40cf-9795-2fb4ea80a693@denx.de>
On 11/13/2024, Marek Vasut wrote:
> On 11/12/24 4:26 AM, Liu Ying wrote:
>> On 11/12/2024, Marek Vasut wrote:
>>> The pll1416x PLL so far only supports rates from a rate table passed
>>> during initialization. Calculating PLL settings dynamically helps in
>>> case e.g. multiple video outputs are used and they each need their own
>>> separate source of accurate pixel clock on i.MX8MP. In that case, e.g.
>>> PLL1416x PLL3 can be used as another Video PLL for another output.
>>
>> Just want to point out that i.MX8MP audio AXI clock is supposed to be
>> derived from PLL3 to run at 600MHz in nominal mode(i.MX8MP data sheet
>> specifies that rate). So, if a particular i.MX8MP system doesn't use
>> audio, PLL3 can be a free clock source to be used by an i.MX8MP display
>> pipeline, otherwise, video_pll1_out is supposed to be shared by i.MX8MP
>> MIPI DSI and LVDS display pipelines.
>
> In the end, I started using Audio PLL and Video PLL PLL1443x for accurate pixel clock generation and PLL3 to feed CLKOUTn where the less accurate PLL3 PLL1416x is just fine.
If audio PLLs or PLL3 are free, I think you may use them for video output.
>
> With the disparate display requirements, sharing one Video PLL for multiple outputs like DSI and LVDS is unrealistic. (maybe the next SoC should have some nice PLL per display output)
I think there are 2 cases where we may or have to share one video PLL
for DSI and LVDS.
1)It happens that the clock rate requirements of the 2 display pipelines
can be met by one video PLL, e.g., an i.MX8MP platform uses both
DSI to HDMI and LVDS to HDMI bridges - it's probably good enough to
have users use typical display mode combinations, like 1920x1080p@60
(DSI) + 1280x720p@60(LVDS).
In this case, we share one video PLL deliberately.
2) If audio PLLs and PLL3 are used already(very likely by audio subsystem),
then the 2 display pipelines have to share one video PLL.
It's possible that the video PLL cannot meet the clock rate requirements
for one or both of them unfortunately, but maybe that's something we
have to accept.
>
>> Currently, IMX8MP_CLK_AUDIO_AXI_SRC's parent is assigned to
>> IMX8MP_SYS_PLL1_800M in imx8mp.dtsi. Although it's rate is assigned
>> to 600MHz, the actual rate is 400MHz according to clk_summary because
>> the divider cannot find a ratio to reach 600MHz from the clock source
>> running at 800MHz. Looking at imx8mp_audio_axi_sels[], sys_pll3_out
>> is the only free/appropriate clock source that can derive 600MHz audio
>> AXI clock from. Maybe, someone will change IMX8MP_CLK_AUDIO_AXI_SRC's
>> parent to IMX8MP_SYS_PLL3_OUT ?
> Is the 400 MHz sufficient for audio-axi or does it have some negative performance impact ? If the later, better send a patch to use PLL3 for audio-axi .
I'm adding Shengjiu to comment the audio part.
>
> Thanks !
--
Regards,
Liu Ying
next prev parent reply other threads:[~2024-11-13 4:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-11 21:44 [PATCH] clk: imx: pll14xx: Extend dynamic rates support to PLL1416x Marek Vasut
2024-11-12 3:26 ` Liu Ying
2024-11-12 21:27 ` Marek Vasut
2024-11-13 4:00 ` Liu Ying [this message]
2024-11-13 9:43 ` S.J. Wang
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=83a67ab8-8f3e-4ab0-b68b-4da156817649@nxp.com \
--to=victor.liu@nxp.com \
--cc=abelvesa@kernel.org \
--cc=festevam@gmail.com \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=marex@denx.de \
--cc=mturquette@baylibre.com \
--cc=peng.fan@nxp.com \
--cc=s.hauer@pengutronix.de \
--cc=sboyd@kernel.org \
--cc=shawnguo@kernel.org \
--cc=shengjiu.wang@nxp.com \
/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