From: Neil Armstrong <narmstrong@baylibre.com>
To: Maxime Jourdan <mjourdan@baylibre.com>
Cc: heiko@sntech.de, maxime.ripard@bootlin.com,
Sandy Huang <hjc@rock-chips.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
a.hajda@samsung.com, Laurent.pinchart@ideasonboard.com,
p.zabel@pengutronix.de, linux-amlogic@lists.infradead.org
Subject: Re: [PATCH v2 7/8] drm/meson: Add YUV420 output support
Date: Tue, 19 Mar 2019 11:38:01 +0100 [thread overview]
Message-ID: <cd6b8fc6-82a7-faba-54d5-e271242ba024@baylibre.com> (raw)
In-Reply-To: <CAMO6nayWKDfcsQtrPK7-Pki75F5tAYO-0B=D=TAbGvQmt=gwrw@mail.gmail.com>
On 19/03/2019 11:35, Maxime Jourdan wrote:
> Hi Neil,
>
> On Fri, Feb 1, 2019 at 1:08 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>> This patch adds support for the YUV420 output from the Amlogic Meson SoCs
>> Video Processing Unit to the HDMI Controller.
>>
>> The YUV420 is obtained by generating a YUV444 pixel stream like
>> the classic HDMI display modes, but then the Video Encoder output
>> can be configured to down-sample the YUV444 pixel stream to a YUV420
>> stream.
>> In addition if pixel stream down-sampling, the Y Cb Cr components must
>> also be mapped differently to align with the HDMI2.0 specifications.
>>
>> This mode needs a different clock generation scheme since the TMDS PHY
>> clock must match the 10x ration with the YUV420 pixel clock, but
>> the video encoder must run at 2x the pixel clock.
>>
>> This patch adds the TMDS PHY clock value in all the video clock setup
>> in order to better support these specific uses cases and switch
>> to the Common Clock framework for clocks handling in the future.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> drivers/gpu/drm/meson/meson_dw_hdmi.c | 110 ++++++++++++++++++++++++++------
>> drivers/gpu/drm/meson/meson_vclk.c | 93 ++++++++++++++++++++-------
>> drivers/gpu/drm/meson/meson_vclk.h | 7 +-
>> drivers/gpu/drm/meson/meson_venc.c | 6 +-
>> drivers/gpu/drm/meson/meson_venc.h | 11 ++++
>> drivers/gpu/drm/meson/meson_venc_cvbs.c | 3 +-
>> 6 files changed, 184 insertions(+), 46 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c b/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> index e28814f..540971a 100644
>> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
>> @@ -141,6 +141,8 @@ struct meson_dw_hdmi {
>> struct regulator *hdmi_supply;
>> u32 irq_stat;
>> struct dw_hdmi *hdmi;
>> + unsigned long input_bus_format;
>> + unsigned long output_bus_format;
>> };
>> #define encoder_to_meson_dw_hdmi(x) \
>> container_of(x, struct meson_dw_hdmi, encoder)
>> @@ -323,25 +325,36 @@ static void dw_hdmi_set_vclk(struct meson_dw_hdmi *dw_hdmi,
>> {
>> struct meson_drm *priv = dw_hdmi->priv;
>> int vic = drm_match_cea_mode(mode);
>> + unsigned int phy_freq;
>> unsigned int vclk_freq;
>> unsigned int venc_freq;
>> unsigned int hdmi_freq;
>>
>> vclk_freq = mode->clock;
>>
>> + /* For 420, pixel clock is half unlike venc clock */
>> + if (dw_hdmi->input_bus_format == MEDIA_BUS_FMT_UYYVYY8_0_5X24)
>> + vclk_freq /= 2;
>> +
>> + /* TMDS clock is pixel_clock * 10 */
>> + phy_freq = vclk_freq * 10;
>> +
>> if (!vic) {
>> - meson_vclk_setup(priv, MESON_VCLK_TARGET_DMT, vclk_freq,
>> - vclk_freq, vclk_freq, false);
>> + meson_vclk_setup(priv, MESON_VCLK_TARGET_DMT, phy_freq,
>> + vclk_freq, vclk_freq, vclk_freq, false);
>> return;
>> }
>>
>> + /* 480i/576i needs global pixel doubling */
>> if (mode->flags & DRM_MODE_FLAG_DBLCLK)
>> vclk_freq *= 2;
>>
>> venc_freq = vclk_freq;
>> hdmi_freq = vclk_freq;
>>
>> - if (meson_venc_hdmi_venc_repeat(vic))
>> + /* VENC double pixels for 1080i, 720p and YUV420 modes */
>> + if (meson_venc_hdmi_venc_repeat(vic) ||
>> + dw_hdmi->input_bus_format == MEDIA_BUS_FMT_UYYVYY8_0_5X24)
>> venc_freq *= 2;
>>
>> vclk_freq = max(venc_freq, hdmi_freq);
>> @@ -349,11 +362,11 @@ static void dw_hdmi_set_vclk(struct meson_dw_hdmi *dw_hdmi,
>> if (mode->flags & DRM_MODE_FLAG_DBLCLK)
>> venc_freq /= 2;
>>
>> - DRM_DEBUG_DRIVER("vclk:%d venc=%d hdmi=%d enci=%d\n",
>> - vclk_freq, venc_freq, hdmi_freq,
>> + DRM_DEBUG_DRIVER("vclk:%d phy=%d venc=%d hdmi=%d enci=%d\n",
>> + phy_freq, vclk_freq, venc_freq, hdmi_freq,
>> priv->venc.hdmi_use_enci);
>>
>> - meson_vclk_setup(priv, MESON_VCLK_TARGET_HDMI, vclk_freq,
>> + meson_vclk_setup(priv, MESON_VCLK_TARGET_HDMI, phy_freq, vclk_freq,
>> venc_freq, hdmi_freq, priv->venc.hdmi_use_enci);
>> }
>>
>> @@ -386,8 +399,9 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void *data,
>> /* Enable normal output to PHY */
>> dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_BIST_CNTL, BIT(12));
>>
>> - /* TMDS pattern setup (TOFIX Handle the YUV420 case) */
>> - if (mode->clock > 340000) {
>> + /* TMDS pattern setup */
>> + if (mode->clock > 340000 &&
>> + dw_hdmi->input_bus_format == MEDIA_BUS_FMT_YUV8_1X24) {
>> dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01, 0);
>> dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23,
>> 0x03ff03ff);
>> @@ -560,6 +574,8 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
>> const struct drm_display_mode *mode)
>> {
>> struct meson_drm *priv = connector->dev->dev_private;
>> + bool is_hdmi2_sink = connector->display_info.hdmi.scdc.supported;
>> + unsigned int phy_freq;
>> unsigned int vclk_freq;
>> unsigned int venc_freq;
>> unsigned int hdmi_freq;
>> @@ -568,8 +584,10 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
>>
>> DRM_DEBUG_DRIVER("Modeline " DRM_MODE_FMT "\n", DRM_MODE_ARG(mode));
>>
>> - /* If sink max TMDS clock, we reject the mode */
>> - if (mode->clock > connector->display_info.max_tmds_clock)
>> + /* If sink does not support 540MHz, reject the non-420 HDMI2 modes */
>> + if (mode->clock > connector->display_info.max_tmds_clock &&
>> + !drm_mode_is_420_only(&connector->display_info, mode) &&
>> + !drm_mode_is_420_also(&connector->display_info, mode))
>> return MODE_BAD;
>>
Hi Maxime,
>
> This part makes all the modes identified as BAD on my TV, on G12A and
> GXL, which in turn breaks HDMI output (no signal detected).
In fact, the issue comes from patch 2.
+ if (mode->clock > connector->display_info.max_tmds_clock)
+ return MODE_BAD;
is wrong if max_tmds_clock is 0, as reported from a DMT monitor.
The original :
+ /* If sink max TMDS clock < 340MHz, we reject the HDMI2.0 modes */
+ if (mode->clock > 340000 &&
+ connector->display_info.max_tmds_clock < 340000)
+ return MODE_BAD;
was correct, and I was asked to simplify it.
I will submit a fix reverting to the later.
Neil
>
> Here is the dmesg with drm debug: https://pastebin.com/t3XESC2w
>
> Cheers,
> Maxime
>
> |snip]
>
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2019-03-19 10:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-01 12:07 [PATCH v2 0/8] drm/meson: Add support for HDMI2.0 4k60 Neil Armstrong
2019-02-01 12:07 ` [PATCH v2 1/8] drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support Neil Armstrong
2019-03-07 23:13 ` Rob Herring
2019-03-08 8:05 ` Neil Armstrong
2019-03-08 14:54 ` Rob Herring
2019-03-11 8:53 ` Neil Armstrong
2019-03-14 18:55 ` Rob Herring
2019-03-14 20:07 ` Neil Armstrong
2019-03-14 20:14 ` Rob Herring
2019-03-15 7:47 ` Neil Armstrong
2019-02-01 12:07 ` [PATCH v2 2/8] drm/meson: add HDMI div40 TMDS mode Neil Armstrong
2019-02-01 12:07 ` [PATCH v2 3/8] drm/meson: add support for HDMI2.0 2160p modes Neil Armstrong
2019-02-01 12:07 ` [PATCH v2 4/8] drm/bridge: dw-hdmi: add support for YUV420 output Neil Armstrong
2019-02-01 12:48 ` Andrzej Hajda
2019-02-01 12:07 ` [PATCH v2 5/8] drm/bridge: dw-hdmi: support dynamically get input/out color info Neil Armstrong
2019-02-01 12:07 ` [PATCH v2 6/8] drm/bridge: dw-hdmi: allow ycbcr420 modes for >= 0x200a Neil Armstrong
2019-02-01 12:07 ` [PATCH v2 7/8] drm/meson: Add YUV420 output support Neil Armstrong
2019-03-19 10:35 ` Maxime Jourdan
2019-03-19 10:38 ` Neil Armstrong [this message]
2019-02-01 12:07 ` [PATCH v2 8/8] drm/meson: Output in YUV444 if sink supports it Neil Armstrong
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=cd6b8fc6-82a7-faba-54d5-e271242ba024@baylibre.com \
--to=narmstrong@baylibre.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.ripard@bootlin.com \
--cc=mjourdan@baylibre.com \
--cc=p.zabel@pengutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).