From: Jani Nikula <jani.nikula@linux.intel.com>
To: allen <allen.chen@ite.com.tw>
Cc: Jau-Chih Tseng <Jau-Chih.Tseng@ite.com.tw>,
Maxime Ripard <maxime.ripard@bootlin.com>,
Allen Chen <allen.chen@ite.com.tw>,
open list <linux-kernel@vger.kernel.org>,
"open list\:DRM DRIVERS" <dri-devel@lists.freedesktop.org>,
David Airlie <airlied@linux.ie>,
Pi-Hsun Shih <pihsun@chromium.org>, Sean Paul <sean@poorly.run>
Subject: Re: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking timings logic
Date: Tue, 10 Dec 2019 13:10:18 +0200 [thread overview]
Message-ID: <87r21ce8rp.fsf@intel.com> (raw)
In-Reply-To: <1574761572-26585-1-git-send-email-allen.chen@ite.com.tw>
On Tue, 26 Nov 2019, allen <allen.chen@ite.com.tw> wrote:
> According to VESA ENHANCED EXTENDED DISPLAY IDENTIFICATION DATA STANDARD
> (Defines EDID Structure Version 1, Revision 4) page: 39
> How to determine whether the monitor support RB timing or not?
> EDID 1.4
> First: read detailed timing descriptor and make sure byte 0 = 0x00,
> byte 1 = 0x00, byte 2 = 0x00 and byte 3 = 0xFD
> Second: read EDID bit 0 in feature support byte at address 18h = 1
> and detailed timing descriptor byte 10 = 0x04
> Third: if EDID bit 0 in feature support byte = 1 &&
> detailed timing descriptor byte 10 = 0x04
> then we can check byte 15, if bit 4 in byte 15 = 1 is support RB
> if EDID bit 0 in feature support byte != 1 ||
> detailed timing descriptor byte 10 != 0x04,
> then byte 15 can not be used
>
> The linux code is_rb function not follow the VESA's rule
>
> Signed-off-by: Allen Chen <allen.chen@ite.com.tw>
> Reported-by: kbuild test robot <lkp@intel.com>
> ---
> drivers/gpu/drm/drm_edid.c | 36 ++++++++++++++++++++++++++++++------
> 1 file changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index f5926bf..e11e585 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -93,6 +93,12 @@ struct detailed_mode_closure {
> int modes;
> };
>
> +struct edid_support_rb_closure {
> + struct edid *edid;
> + bool valid_support_rb;
> + bool support_rb;
> +};
> +
> #define LEVEL_DMT 0
> #define LEVEL_GTF 1
> #define LEVEL_GTF2 2
> @@ -2017,23 +2023,41 @@ struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
> }
> }
>
> +static bool
> +is_display_descriptor(const u8 *r, u8 tag)
> +{
> + return (!r[0] && !r[1] && !r[2] && r[3] == tag) ? true : false;
> +}
> +
> static void
> is_rb(struct detailed_timing *t, void *data)
> {
> u8 *r = (u8 *)t;
> - if (r[3] == EDID_DETAIL_MONITOR_RANGE)
> - if (r[15] & 0x10)
> - *(bool *)data = true;
> + struct edid_support_rb_closure *closure = data;
> + struct edid *edid = closure->edid;
> +
> + if (is_display_descriptor(r, EDID_DETAIL_MONITOR_RANGE)) {
> + if (edid->features & BIT(0) && r[10] == BIT(2)) {
I'll try to explain my original comment again.
Consider edid->features & BIT(0). It remains unchanged across the
iteration. The code will only change anything if edid->features &
BIT(0).
> + closure->valid_support_rb = true;
> + closure->support_rb = (r[15] & 0x10) ? true : false;
You could combine these to e.g. a single int.
if (r[10] == BIT(2)) {
int *ret = data;
*ret = !!(r[15] & 0x10);
}
> + }
> + }
> }
>
> /* EDID 1.4 defines this explicitly. For EDID 1.3, we guess, badly. */
> static bool
> drm_monitor_supports_rb(struct edid *edid)
> {
> + struct edid_support_rb_closure closure = {
> + .edid = edid,
> + .valid_support_rb = false,
> + .support_rb = false,
> + };
> +
> if (edid->revision >= 4) {
> - bool ret = false;
> - drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);
> - return ret;
> + drm_for_each_detailed_block((u8 *)edid, is_rb, &closure);
> + if (closure.valid_support_rb)
> + return closure.support_rb;
Here, you'd do:
if (edid->features & BIT(0)) {
int ret = -1;
drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);
if (ret != -1)
return ret;
}
> }
>
> return ((edid->input & DRM_EDID_INPUT_DIGITAL) != 0);
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2019-12-10 11:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-26 9:46 [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking timings logic allen
2019-11-27 10:29 ` Jani Nikula
[not found] ` <e2486891920843798e9af97209464833@ite.com.tw>
2019-12-03 8:02 ` Jani Nikula
2019-12-10 11:10 ` Jani Nikula [this message]
2019-12-11 3:47 ` allen.chen
-- strict thread matches above, loose matches on Subject: below --
2019-11-04 8:42 allen
2019-11-07 15:42 ` Ville Syrjälä
2019-11-11 1:43 ` allen.chen
2019-11-11 13:54 ` Ville Syrjälä
2019-11-01 8:04 allen
2019-11-03 7:51 ` kbuild test robot
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=87r21ce8rp.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=Jau-Chih.Tseng@ite.com.tw \
--cc=airlied@linux.ie \
--cc=allen.chen@ite.com.tw \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.ripard@bootlin.com \
--cc=pihsun@chromium.org \
--cc=sean@poorly.run \
/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