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: Wed, 27 Nov 2019 12:29:11 +0200 [thread overview]
Message-ID: <87pnhdobns.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)) {
> + 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, 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.
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
next prev parent reply other threads:[~2019-11-27 10:29 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 [this message]
[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=87pnhdobns.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