Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1032374ybl; Tue, 3 Dec 2019 00:04:20 -0800 (PST) X-Google-Smtp-Source: APXvYqyXi1HXq6zi8+d/gStbWOKmVTRbN13W+ch94u8PTvf4gXKgf3wx0kXv499rV+tcHwfxgXvT X-Received: by 2002:a05:6830:2335:: with SMTP id q21mr2195133otg.237.1575360260598; Tue, 03 Dec 2019 00:04:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575360260; cv=none; d=google.com; s=arc-20160816; b=PDPrYRLw0JVUxEs0KlkNcCGQnz7PObP3NwUAEcACmMymWudMxCSxBfQB56PVn7/9x/ kVHLELgbAIWGXAfoLHLLit9RiU27rmTSR2bbCTtn5TQWSE+YIqXN2v/xKb9Uw9ntKhPa pC+25E4FML9jfwPMyccap2sJUN0Oac7qdzHqvzWpbrJ186E0RVAVBaHXzF+BJGZXNShj wMfyfl1vv8Vvw7fHif60BgdnOl6+QCHk1x6jsM0DUASbS05WAlTTbXw1l5TFGrbCAsV0 bBx2cwhfEKCInSWweLST1ECD0m3wkW3gGrhHgVZyMAXsbGr2u+9TmCTt0jglCt5wBAgJ aDSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:references:organization:in-reply-to:subject:cc:to :from; bh=06o9cL0/CTV15llW/gRe7bS/Tal6ili1v/gxqe3/oHM=; b=qTXH+kvQ+Ts+AI8/hI08UzUhMBMz6hVLkscz9HYb1d0CHTkRNGgVcWh9U7zRoiCKUE YolM5VJ/Xf3y04QItcMG1HbqSVfXXk38hQY1VmdjUpXd2OHB5hknxx2oDntfnfb0IN2W BJw3VrzmWVyRvm0XkJdFFqCdAI4t0e+zja8YiJWmSn1T+JpA/nq2uFQ+wBYzUiJWI/oX DNhoPXzhb0RIjFKgbo3jwaF8NVyB2+TGANJRw8ATYfqvqKSESgDTffxpgRBtYIvacS8b zEw9NVSll563w5EbYz+0xp5W8Vp2klcFUHPCLGZvdvwGPRmia6lzBWi733o2xi4V19gm 9AKQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i20si823319otk.270.2019.12.03.00.04.07; Tue, 03 Dec 2019 00:04:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727594AbfLCICb convert rfc822-to-8bit (ORCPT + 99 others); Tue, 3 Dec 2019 03:02:31 -0500 Received: from mga14.intel.com ([192.55.52.115]:23908 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727491AbfLCICa (ORCPT ); Tue, 3 Dec 2019 03:02:30 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Dec 2019 00:02:30 -0800 X-IronPort-AV: E=Sophos;i="5.69,272,1571727600"; d="scan'208";a="200908546" Received: from jnikula-mobl3.fi.intel.com (HELO localhost) ([10.237.66.161]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Dec 2019 00:02:27 -0800 From: Jani Nikula To: allen.chen@ite.com.tw Cc: Jau-Chih.Tseng@ite.com.tw, maxime.ripard@bootlin.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, airlied@linux.ie, pihsun@chromium.org, sean@poorly.run Subject: RE: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking timings logic In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <1574761572-26585-1-git-send-email-allen.chen@ite.com.tw> <87pnhdobns.fsf@intel.com> Date: Tue, 03 Dec 2019 10:02:25 +0200 Message-ID: <87muc9kfam.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 03 Dec 2019, wrote: > Hi Jani Nikula > > > > Thanks for your suggestion and I have replied two comments below. Please read my question again. BR, Jani. > > > > -----Original Message----- > From: Jani Nikula [mailto:jani.nikula@linux.intel.com] > Sent: Wednesday, November 27, 2019 6:29 PM > To: Allen Chen (陳柏宇) > Cc: Jau-Chih Tseng (曾昭智); Maxime Ripard; Allen Chen (陳柏宇); open list; open list:DRM DRIVERS; David Airlie; Pi-Hsun Shih; Sean Paul > Subject: Re: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking timings logic > > > > On Tue, 26 Nov 2019, allen 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 > >> Reported-by: kbuild test robot > >> --- > >> 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; > > > > Are you planning on extending the closure use somehow? > > > > I did not look up the spec, > > > > ==> iTE: as the picture below, from VESA E-EDID standard > > [cid:image003.jpg@01D5A9EA.9B7364D0] > > > > [cid:image005.jpg@01D5A9EA.9B7364D0] > > > > if EDID bit 0 in feature support byte = 1 && detailed timing descriptor byte 10 = 0x04 then the CVT timing supported. > > > > [cid:image009.jpg@01D5A9EA.9B7364D0] > > > > If CVT timing supported then we can check byte 15 bit 4 to determine whether the reduced-blanking timings suported or not. > > If CVT timing not supported then we can not use byte 15 to judge. > > but purely on the code changes alone, you > > could just move the edid->features bit check at this level, and not pass > > it down, and nothing would change. I.e. don't iterate the EDID at all if > > the bit is not set. > > > > ð iTE: We still have to check whether detailed timing descriptor byte 10 = 0x04 or not, so it is hard to check at this level > > You also don't actually use the distinction between valid_support_rb > > vs. support_rb for anything, so the closure just adds code. > > > > BR, > > Jani. > > > > > >> } > >> > >> return ((edid->input & DRM_EDID_INPUT_DIGITAL) != 0); > > > > -- > > Jani Nikula, Intel Open Source Graphics Center -- Jani Nikula, Intel Open Source Graphics Center