From: Alex Bee <knaerzche@gmail.com>
To: Maxime Ripard <mripard@kernel.org>
Cc: "Sandy Huang" <hjc@rock-chips.com>,
"Heiko Stübner" <heiko@sntech.de>, "Andy Yan" <andyshrk@163.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 04/11] drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range
Date: Thu, 14 Dec 2023 15:05:59 +0100 [thread overview]
Message-ID: <a8f13e19-7bb3-4a7f-a264-1e1ede1864e0@gmail.com> (raw)
In-Reply-To: <db3kdzy4ogf3o2fd6apr36s44qitcsxksfkfa2oc77s5y6dv2w@kfji4iszthxa>
Am 14.12.23 um 12:33 schrieb Maxime Ripard:
> On Thu, Dec 14, 2023 at 12:12:08PM +0100, Alex Bee wrote:
>> Hi Maxime
>>
>> Am 14.12.23 um 08:56 schrieb Maxime Ripard:
>>> Hi Alex,
>>>
>>> Thanks for working on this!
>>>
>>> On Wed, Dec 13, 2023 at 08:51:18PM +0100, Alex Bee wrote:
>>>> The display controller will always give full range RGB regardless of the
>>>> mode set, but HDMI requires certain modes to be transmitted in limited
>>>> range RGB. This is especially required for HDMI sinks which do not support
>>>> non-standard quantization ranges.
>>>>
>>>> This enables color space conversion for those modes and sets the
>>>> quantization range accordingly in the AVI infoframe.
>>>>
>>>> Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
>>>> Signed-off-by: Alex Bee <knaerzche@gmail.com>
>>>> ---
>>>> drivers/gpu/drm/rockchip/inno_hdmi.c | 40 ++++++++++++++++++++++------
>>>> 1 file changed, 32 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
>>>> index 345253e033c5..32626a75723c 100644
>>>> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
>>>> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
>>>> @@ -33,6 +33,7 @@ struct hdmi_data_info {
>>>> unsigned int enc_in_format;
>>>> unsigned int enc_out_format;
>>>> unsigned int colorimetry;
>>>> + bool rgb_limited_range;
>>>> };
>>>> struct inno_hdmi_i2c {
>>>> @@ -308,6 +309,18 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
>>>> else
>>>> frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>>>> + if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_RGB) {
>>>> + drm_hdmi_avi_infoframe_quant_range(&frame.avi,
>>>> + &hdmi->connector, mode,
>>>> + hdmi->hdmi_data.rgb_limited_range ?
>>>> + HDMI_QUANTIZATION_RANGE_LIMITED :
>>>> + HDMI_QUANTIZATION_RANGE_FULL);
>>>> + } else {
>>>> + frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
>>>> + frame.avi.ycc_quantization_range =
>>>> + HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
>>>> + }
>>>> +
>>>> return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
>>>> }
>>>> @@ -334,14 +347,22 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
>>>> if (data->enc_in_format == data->enc_out_format) {
>>>> if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
>>>> (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
>>>> - value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
>>>> - hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
>>>> -
>>>> - hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
>>>> - m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
>>>> - v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
>>>> - v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
>>>> - return 0;
>>>> + if (data->enc_in_format == HDMI_COLORSPACE_RGB &&
>>>> + data->enc_out_format == HDMI_COLORSPACE_RGB &&
>>>> + hdmi->hdmi_data.rgb_limited_range) {
>>>> + csc_mode = CSC_RGB_0_255_TO_RGB_16_235_8BIT;
>>>> + auto_csc = AUTO_CSC_DISABLE;
>>>> + c0_c2_change = C0_C2_CHANGE_DISABLE;
>>>> + csc_enable = v_CSC_ENABLE;
>>>> + } else {
>>>> + value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
>>>> + hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
>>>> + hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
>>>> + m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
>>>> + v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
>>>> + v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
>>>> + return 0;
>>>> + }
>>>> }
>>>> }
>>>> @@ -458,6 +479,9 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
>>>> else
>>>> hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
>>>> + hdmi->hdmi_data.rgb_limited_range =
>>>> + drm_default_rgb_quant_range(mode) == HDMI_QUANTIZATION_RANGE_LIMITED;
>>>> +
>>> This patch conflicts heavily with my inno_hdmi patches here (patches 22 to 38):
>>> https://lore.kernel.org/dri-devel/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org/
>> I'm aware of that and I mentioned it in the cover letter.
> Sorry, I missed that part.
>
>> Your series is not merged yet and it didn't get much feedback so far.
>> What is the status there?
> It didn't have much reviews, but I'll hope to change that. For the
> patches 22 to 38 though, it doesn't really matter. Those changes are
> self-contained and can be applied as is outside of the series.
>
>> Especially because you are removing things from inno-hdmi driver (which
>> aren't really required to remove there) which will I have to reintroduce.
> I'm not entirely sure which part I remove that are actually going to be
> used here.
I'm refering to [PATCH v5 33/44] which completly removes csc coeffs but
this series needs the CSC_RGB_0_255_TO_RGB_16_235_8BIT coeffs and
[PATCH v5 29/44] which removes writing csc_coeffs to the hardware.
>
>>> I would appreciate if you could test and merge them into your series.
>>>
>>> In particular, there's no need to store the range here: enc_out_format
>> rgb_limited_range is currently not only used for csc, but also for for
>> infoframe creation. So it makes sense to have this stored to avoid calling
>> drm_default_rgb_quant_range twice.
> You're right, I missed one. Still, it shouldn't be stored in the
> hdmi_data_info structure, it's tied to the mode, and the mode is part of
> the state, so it's not a property to a given device, but it's tied to
> the connector state.
>
> So if you want to do so, you should really create a custom state
> structure and store the range there, just like vc4 is doing for example.
OK - I'll check.
Alex
>
> Maxime
next prev parent reply other threads:[~2023-12-14 14:06 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-13 19:51 [PATCH 00/11] Add HDMI support for RK3128 Alex Bee
2023-12-13 19:51 ` [PATCH 01/11] dt-bindings: display: rockchip,inno-hdmi: Document RK3128 compatible Alex Bee
2023-12-14 7:53 ` Krzysztof Kozlowski
2023-12-14 15:22 ` Alex Bee
2023-12-14 16:07 ` Krzysztof Kozlowski
2023-12-14 16:20 ` Heiko Stübner
2023-12-14 16:26 ` Krzysztof Kozlowski
2023-12-13 19:51 ` [PATCH 02/11] drm/rockchip: vop: Add output selection registers for RK312x Alex Bee
2023-12-13 19:51 ` [PATCH 03/11] drm/rockchip: inno_hdmi: Fix video timing Alex Bee
2023-12-13 19:51 ` [PATCH 04/11] drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range Alex Bee
2023-12-14 7:56 ` Maxime Ripard
2023-12-14 11:12 ` Alex Bee
2023-12-14 11:17 ` Heiko Stübner
2023-12-14 11:36 ` Maxime Ripard
2023-12-14 11:50 ` Andy Yan
2023-12-14 16:34 ` Alex Bee
2023-12-15 12:29 ` Maxime Ripard
2023-12-14 11:33 ` Maxime Ripard
2023-12-14 14:05 ` Alex Bee [this message]
2023-12-15 12:27 ` Maxime Ripard
2023-12-13 19:51 ` [PATCH 05/11] drm/rockchip: inno_hdmi: Add variant support Alex Bee
2023-12-13 19:51 ` [PATCH 06/11] drm/rockchip: inno_hdmi: Add RK3128 support Alex Bee
2023-12-13 19:51 ` [PATCH 07/11] drm/rockchip: inno_hdmi: Add basic mode validation Alex Bee
2023-12-14 8:05 ` Maxime Ripard
2023-12-14 11:17 ` Alex Bee
2023-12-14 11:40 ` Maxime Ripard
2023-12-14 13:05 ` Alex Bee
2023-12-13 19:51 ` [PATCH 08/11] drm/rockchip: inno_hdmi: Drop custom fill_modes hook Alex Bee
2023-12-13 19:51 ` [PATCH 09/11] ARM: dts: rockchip: Add display subsystem for RK3128 Alex Bee
2023-12-13 19:51 ` [PATCH 10/11] ARM: dts rockchip: Add HDMI node " Alex Bee
2023-12-13 19:51 ` [PATCH 11/11] ARM: dts: rockchip: Enable HDMI output for XPI-3128 Alex Bee
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=a8f13e19-7bb3-4a7f-a264-1e1ede1864e0@gmail.com \
--to=knaerzche@gmail.com \
--cc=airlied@gmail.com \
--cc=andyshrk@163.com \
--cc=conor+dt@kernel.org \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=robh+dt@kernel.org \
--cc=tzimmermann@suse.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).