All of lore.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.