mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: allen <allen.chen@ite.com.tw>
To: unlisted-recipients:; (no To-header on input)
Cc: Allen Chen <allen.chen@ite.com.tw>,
	Pi-Hsun Shih <pihsun@chromium.org>,
	Jau-Chih Tseng <Jau-Chih.Tseng@ite.com.tw>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Sean Paul <sean@poorly.run>, David Airlie <airlied@linux.ie>,
	"open list:DRM DRIVERS" <dri-devel@lists.freedesktop.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking timings logic
Date: Tue, 26 Nov 2019 17:46:12 +0800	[thread overview]
Message-ID: <1574761572-26585-1-git-send-email-allen.chen@ite.com.tw> (raw)

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)) {
+			closure->valid_support_rb = true;
+			closure->support_rb = (r[15] & 0x10) ? true : false;
+		}
+	}
 }
 
 /* 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;
 	}
 
 	return ((edid->input & DRM_EDID_INPUT_DIGITAL) != 0);
-- 
1.9.1


             reply	other threads:[~2019-11-26  9:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-26  9:46 allen [this message]
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
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=1574761572-26585-1-git-send-email-allen.chen@ite.com.tw \
    --to=allen.chen@ite.com.tw \
    --cc=Jau-Chih.Tseng@ite.com.tw \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --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

all inboxes | Powered by JetHome®