public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 11/17] drm/i915: Update the EDID automated compliance test function
Date: Wed, 17 Dec 2014 21:20:57 +0100	[thread overview]
Message-ID: <20141217202057.GC2711@phenom.ffwll.local> (raw)
In-Reply-To: <CA+gsUGQP3ZOxug6hYs+K5pHPSBETfjx0NWEjwitnniqd5=E9Fg@mail.gmail.com>

On Wed, Dec 17, 2014 at 02:25:42PM -0200, Paulo Zanoni wrote:
> 2014-12-10 21:53 GMT-02:00 Todd Previte <tprevite@gmail.com>:
> > Updates the EDID compliance test function to perform the EDID read as
> > required by the tests. This read needs to take place in the kernel for
> > reasons of speed and efficiency. The results of the EDID read are handed
> > off to userspace so that the remainder of the test can be conducted there.
> >
> > V2:
> > - Addressed mailing list feedback
> > - Removed excess debug messages
> > - Removed extraneous comments
> > - Fixed formatting issues (line length > 80)
> > - Updated the debug message in compute_edid_checksum to output hex values
> >   instead of decimal
> >
> > Signed-off-by: Todd Previte <tprevite@gmail.com>
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 72 ++++++++++++++++++++++++++++++++++++++++-
> >  1 file changed, 71 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index b6f5a72..2a13124 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -40,6 +40,13 @@
> >
> >  #define DP_LINK_CHECK_TIMEOUT  (10 * 1000)
> >
> > +/* Compliance test status bits  */
> > +#define  INTEL_DP_EDID_OK              (0<<0)
> > +#define  INTEL_DP_EDID_CORRUPT         (1<<0)
> > +#define  INTEL_DP_RESOLUTION_PREFERRED (1<<2)
> > +#define  INTEL_DP_RESOLUTION_STANDARD  (1<<3)
> > +#define  INTEL_DP_RESOLUTION_FAILSAFE  (1<<4)
> > +
> >  struct dp_link_dpll {
> >         int link_bw;
> >         struct dpll dpll;
> > @@ -3761,9 +3768,72 @@ static uint8_t intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)
> >         return test_result;
> >  }
> >
> > +static bool intel_dp_compute_edid_checksum(uint8_t *edid_data,
> > +                                          uint8_t *edid_checksum)
> > +{
> > +       uint32_t byte_total = 0;
> > +       uint8_t i = 0;
> > +       bool edid_ok = true;
> > +
> > +       /* Don't include last byte (the checksum) in the computation */
> > +       for (i = 0; i < EDID_LENGTH - 2; i++)
> 
> Shouldn't this be "i < EDID_LENGHT - 1"?
> 
> 
> > +               byte_total += edid_data[i];
> > +
> > +       *edid_checksum = 256 - (byte_total % 256);
> > +
> > +       if (*edid_checksum != edid_data[EDID_LENGTH - 1]) {
> > +               DRM_DEBUG_KMS("Invalid EDID checksum %02x, should be %02x\n",
> > +                             edid_data[EDID_LENGTH - 40 - 1], *edid_checksum);
> > +               edid_ok = false;
> > +       }
> > +
> > +       return edid_ok;
> > +}
> > +
> >  static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp)
> >  {
> > -       uint8_t test_result = DP_TEST_NAK;
> > +       struct drm_connector *connector = &intel_dp->attached_connector->base;
> > +       struct i2c_adapter *adapter = &intel_dp->aux.ddc;
> > +       struct edid *edid_read = NULL;
> > +       uint8_t *edid_data = NULL;
> > +       uint8_t test_result = DP_TEST_NAK, checksum = 0;
> > +       uint32_t ret = 0;
> > +
> > +       intel_dp->aux.i2c_nack_count = 0;
> > +       intel_dp->aux.i2c_defer_count = 0;
> > +
> > +       edid_read = drm_get_edid(connector, adapter);
> > +
> > +       if (edid_read == NULL) {
> > +               /* Check for NACKs/DEFERs, use failsafe if detected
> > +                  (DP CTS 1.2 Core Rev 1.1, 4.2.2.4, 4.2.2.5) */
> > +               if (intel_dp->aux.i2c_nack_count > 0 ||
> > +                       intel_dp->aux.i2c_defer_count > 0)
> > +                       DRM_DEBUG_KMS("EDID read had %d NACKs, %d DEFERs\n",
> > +                                     intel_dp->aux.i2c_nack_count,
> > +                                     intel_dp->aux.i2c_defer_count);
> 
> Don't we need to use these _count values somehow, instead of just
> printing them in the logs?
> 
> Everything else looks fine.
> 
> > +               intel_dp->compliance_test_data = INTEL_DP_EDID_CORRUPT |
> > +                                                INTEL_DP_RESOLUTION_FAILSAFE;
> > +       } else {
> > +               edid_data = (uint8_t *) edid_read;
> > +
> > +               if (intel_dp_compute_edid_checksum(edid_data, &checksum)) {
> > +                       ret = drm_dp_dpcd_write(&intel_dp->aux,
> > +                                               DP_TEST_EDID_CHECKSUM,
> > +                                               &edid_read->checksum, 1);
> > +                       test_result = DP_TEST_ACK |
> > +                                     DP_TEST_EDID_CHECKSUM_WRITE;
> > +                       intel_dp->compliance_test_data =
> > +                               INTEL_DP_EDID_OK |
> > +                               INTEL_DP_RESOLUTION_PREFERRED;
> > +               } else {
> > +                       /* Invalid checksum - EDID corruption detection */
> > +                       intel_dp->compliance_test_data =
> > +                               INTEL_DP_EDID_CORRUPT |
> > +                               INTEL_DP_RESOLUTION_FAILSAFE;

Just something random I've spotted while driving by: drm_get_edid does all
the checksum stuff for you already (it retries up to 4 times if the
checkusm is off and also checks a few other things). We should never reach
this case and the checksum function is essentially dead code.

Or do I miss something?
-Daniel

> > +               }
> > +       }
> > +
> >         return test_result;
> >  }
> >
> > --
> > 1.9.1
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
> 
> -- 
> Paulo Zanoni
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2014-12-17 20:20 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-10 23:53 [intel-gfx] Displayport Compliance Testing V2 Todd Previte
2014-12-10 23:53 ` [PATCH 01/17] drm/i915: Add automated testing support for Displayport compliance testing Todd Previte
2014-12-12 20:25   ` Paulo Zanoni
2015-02-18 16:36     ` Todd Previte
2014-12-10 23:53 ` [PATCH 02/17] drm/i915: Update intel_dp_check_link_status() " Todd Previte
2014-12-15 16:36   ` Paulo Zanoni
2015-02-18 16:36     ` Todd Previte
2015-04-06 23:52       ` Paulo Zanoni
2014-12-10 23:53 ` [PATCH 03/17] drm/i915: Add a delay in Displayport AUX transactions for " Todd Previte
2014-12-15 17:35   ` Paulo Zanoni
2015-02-18 16:37     ` Todd Previte
2014-12-10 23:53 ` [PATCH 04/17] drm/i915: Add debugfs information for Displayport " Todd Previte
2014-12-15 13:11   ` Jani Nikula
2015-02-18 16:37     ` Todd Previte
2014-12-10 23:53 ` [PATCH 05/17] drm/i915: Add file ops for Displayport configuration in debugfs Todd Previte
2014-12-10 23:53 ` [PATCH 06/17] drm/i915: Add support functions in debugfs for handling Displayport compliance configuration Todd Previte
2014-12-15 19:25   ` Paulo Zanoni
2014-12-10 23:53 ` [PATCH 07/17] drm/i915: Add and implement the debugfs 'show' functions for Displayport compliance Todd Previte
2014-12-16 19:00   ` Paulo Zanoni
2014-12-17 20:12     ` Daniel Vetter
2015-02-18 16:45       ` Todd Previte
2015-02-18 16:41     ` Todd Previte
2014-12-10 23:53 ` [PATCH 08/17] drm/i915: Add Displayport link configuration structure Todd Previte
2014-12-10 23:53 ` [PATCH 09/17] drm/i915: Add config parsing utilities in debugfs for Displayport compliance Todd Previte
2014-12-10 23:53 ` [PATCH 10/17] drm/i915: Implement the 'open' and 'write' debugfs functions " Todd Previte
2014-12-10 23:53 ` [PATCH 11/17] drm/i915: Update the EDID automated compliance test function Todd Previte
2014-12-17 16:25   ` Paulo Zanoni
2014-12-17 20:20     ` Daniel Vetter [this message]
     [not found]       ` <54E4C490.7080001@gmail.com>
2015-02-20 16:55         ` Daniel Vetter
2015-02-18 16:47     ` Todd Previte
2015-02-23 15:55   ` Daniel Vetter
2014-12-10 23:53 ` [PATCH 12/17] drm/i915: Update intel_dp_compute_config() to handle compliance test requests Todd Previte
2014-12-17 17:04   ` Paulo Zanoni
2015-01-07 19:28     ` Clint Taylor
2015-02-18 16:59       ` Todd Previte
2014-12-10 23:53 ` [PATCH 13/17] drm/i915: Update intel_dp_hpd_pulse() to check link status for non-MST operation Todd Previte
2014-12-17 17:57   ` Paulo Zanoni
2014-12-17 20:30     ` Daniel Vetter
2015-02-18 17:06       ` Todd Previte
2015-02-18 17:06     ` Todd Previte
2014-12-10 23:53 ` [PATCH 14/17] drm/i915: Add debugfs function to check connector status for compliance testing Todd Previte
2014-12-17 18:03   ` Paulo Zanoni
2015-02-18 17:08     ` Todd Previte
2015-02-18 23:09       ` Todd Previte
2014-12-10 23:53 ` [PATCH 15/17] drm/i915: Update debugfs functions for Displayport " Todd Previte
2014-12-10 23:53 ` [PATCH 16/17] drm/i915: Add new debugfs file for Displaypor compliance test control Todd Previte
2014-12-10 23:53 ` [PATCH 17/17] drm/i915: Add debugfs write and test param parsing function for DP " Todd Previte
2014-12-16  7:13   ` shuang.he

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=20141217202057.GC2711@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=przanoni@gmail.com \
    /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