Re: [PATCH 07/12] drm/i915: Update EDID automated test function for Displayport compliance

[Todd Previte <tprevite@xxxxxxxxx>]

Paulo Zanoni

Tuesday, July 29, 2014 3:37 PM

2014-07-14 16:10 GMT-03:00 Todd Previte <tprevite@xxxxxxxxx>:

Implements an updated version of the automated testing function that handles
Displayport compliance for EDID operations.

Both the commit message and the code should mention the name of the
specification that defines these tests, and also mention which
specific tests are implemented by this patch/function. I see that
there are multiple tests being implemented here, but reading the 232
pages of the spec will require too much time, so knowing which ones
are implemented really helps the reviewers :)

Heh fair enough. I can put all the test information in the commit message. I think it's already in the code, but I'll double-check that as well.

Also, you should tell us what happens before and after this patch when
you run your own tests. How many tests were we previously passing? How
many tests are we passing now? I see there are some FIXME lines below,
which leads to the question: is the code you provided enough and
complete, or do we still need more adjustments to pass everything we
can with what you built? In other words: is this patch, alone, already
an improvement to the situation?

Makes sense. I'll add the additional info in the commit messages.

Signed-off-by: Todd Previte <tprevite@xxxxxxxxx>
---
 drivers/gpu/drm/i915/intel_dp.c | 77 ++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 76 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 33b6dc9..88f1bbe 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3408,7 +3408,82 @@ intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)
 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 i = 0, ret = 0;
+       struct drm_display_mode *use_mode = NULL;
+       int mode_count = 0;
+       struct drm_mode_set modeset;

You have initialized every single variable you defined. This creates
the problem that unused variables are not pointed by the compiler
unless you enable the flags to warn set-but-not-used variables. For
example, "i" is unused, and "ret" is set but never used. I also don't
really see the point in, for example, NULL-initializing stuff like
edid_data and edid_read.

I always initialize all the variables I declare as a matter of course. I've always been of the opinion that I'd rather use up a little extra stack space than to have to track down the weird problems that can result from using uninitialized variables. Compilers complain about using uninitialized variables as well, so this is more of a difference of opinion than anything else.

However, since there are unused variables, I'll remove those in the next iteration of this patch. :)

+
+       DRM_DEBUG_KMS("Displayport: EDID automated test\n");
+
+       /* Reset the NACK/DEFER counters */

As I said before, this is a great example of the "comment says what
the code already says" problem.

Fair enough. It will be removed.

+       intel_dp->aux.i2c_nack_count = 0;
+       intel_dp->aux.i2c_defer_count = 0;
+       /* Now read out the EDID */
+       edid_read = drm_get_edid(connector, adapter);
+
+       if (edid_read == NULL) {
+               /* Check for NACKs/DEFERs, goto failsafe if detected
+                  (DP CTS 1.2 Core Rev 1.1, 4.2.2.4, 4.2.2.5) */

Our coding standard is to put aligned '*'s on each line of a
multi-line comment. So this should be "\t\t * (DP CTS 1.2 etc..."
instead of what is above. In theory, the "/*" and "*/" strings should
be on their own lines, alone, but we are inconsistent regarding this
(even though Daniel randomly complained about this to me a few times
in the past). As usual, check Documentation/CodingStyle for better
explanations.

I'll adjust the code to conform to the coding standard, whatever it happens to be.

+               if (intel_dp->aux.i2c_nack_count > 0 ||
+                       intel_dp->aux.i2c_defer_count > 0)

We tend to align the contents of the extra line with the '(' char on
the line above.

I think this is a problem with tab sizes (as evidenced below). My editor is set for 4-space tabs whereas the kernel standard is 8-space tabs. I've resisted changing it because it spaces the code out way too much for my liking while I'm editing. But apparently this is going to be an issue moving forward, so I'm going to have to change it.

+                       DRM_DEBUG_KMS("Displayport: EDID read generated %d I2C NACKs, %d DEFERs\n",
+                                                 intel_dp->aux.i2c_nack_count,
+                                                 intel_dp->aux.i2c_defer_count);

There are way too many tabs on the 2 lines above.

See above. This is the tab size problem.

+               goto failsafe;
+       }
+
+       /* FIXME: Need to determine how to detect E-DDC here (4.2.2.9) */

But what is the problem with the current code? What are the
consequences of not implementing the FIXME?

4.2.2.9 is a separate test. Until we address it in the code, the test will fail. If additional explanation is necessary, that can be added.

+       edid_data = (uint8_t *) edid_read;
+
+       if (intel_dp_compute_edid_checksum(edid_data, &checksum)) {
+               /* Write the checksum to EDID checksum register */
+               ret = drm_dp_dpcd_write(&intel_dp->aux,
+                                                               DP_TEST_EDID_CHECKSUM,
+                                                               &edid_read->checksum, 1);

Way too many tabs above too.

Same tab problem.

+               /* Reponse is ACK and and checksum written */
+               test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE;
+       } else {
+               /* Invalid checksum - EDID corruption detection test */
+               goto failsafe;
+       }
+
+       /* Update EDID modes */
+       mode_count = intel_connector_update_modes(connector, edid_read);
+       if (!mode_count) {
+               DRM_DEBUG_KMS("Displayport: Mode update failed\n");
+               goto failsafe;
+       }
+
+       /* Get the EDID preferred mode if available */
+       use_mode = intel_dp_get_edid_preferred_mode(intel_dp);
+       if (use_mode == NULL)
+               goto failsafe;
+       else
+               goto set_mode;
+
+failsafe:
+       DRM_DEBUG_KMS("Displayport: Setting failsafe display mode\n");
+       use_mode = intel_dp_get_failsafe_mode();
+       /* FIXME: <TAP> Need to set DP to 6bpc here as well */

What does <TAP> mean? What are the consequences of not setting DP to
6bpc here as well?

My initials? :) That's an oversight on my part. Those are just notes that I'm writing to myself while working in the code. It's a tag I can easily search to make sure I haven't missed anything. That shouldn't have been in there and instead should have been a simple "FIXME" with the added explanation. To answer your question though, without 18bpp the test fails stating that the video format is not correct.

+       intel_dp->attached_connector->encoder->new_crtc->config.pipe_bpp = 18;
+
+set_mode:
+       /* Configure the display mode necessary */
+       modeset.connectors = &connector;
+       modeset.num_connectors = 1;
+       modeset.crtc = connector->encoder->crtc;

I guess this could result in NULL pointer dereferences. I don't see a
guarantee that the connector will have a CRTC at this point.

+       modeset.fb = modeset.crtc->primary->fb;

And I also don't see a guarantee that we'll have an FB, and that the
FB will be big enough for the current mode we're setting.

+       modeset.x = 0;
+       modeset.y = 0;
+       modeset.mode = use_mode;
+       /* Set the config */
+       intel_dp_set_config(&modeset);
+

I guess Daniel said this won't really work, right? This is why it will
probably be simpler to involve user space on the compliance testing
(in addition to the fact that we will test real-world production-used
code). At this point we could just write to the debugfs file something
like "set preferred mode" or "set failsafe mode", then wait for the
modeset to happen. We could either try to detect the modeset (by
setting some variable to zero before we send the message to
user-space, and then verifying that intel_set_mode changed it to true)
or we could make the user-space write a string to the debugfs file,
like "done" and assume user-space is correct and finish the function
(it's debugfs anyway, and root, and DRM master, right?).

Right. I think this whole block is what Daniel was referring to. The two reasons to move it to userspace are that a) it's a more reliable solution to do this in userspace and b) it allows for testing the real code paths that are actively in use rather than just testing dedicated paths for a compliance badge.

Also, if we use the failsafe mode we'll return DP_TEST_NAK. Is that
intentional? Also, it is a little strange that the ACK is the last
thing we should do here, and the spec doesn't seem to be clear
reagarding when we should send it (or I just didn't find the piece of
text that says it...). I guess that by running the compliance tests we
will discover that by looking at the test result.

No it shouldn't NAK the test since it's been implemented. That's an error in the code that needs to be corrected. Page 24 of the Link CTS spec has some info on the ACK/NAK. Here's what it says:

    "If the test mode requested is supported, the Source DUT shall start transmitting the
    TEST_VIDEO_PATTERN in the test mode requested, and set the TEST_ACK bit in the TEST_RESPONSE
    register."

    "If the test mode requested is not supported, the Source DUT shall signal a negative acknowledgement by
    setting the TEST_NAK bit in the TEST_RESPONSE register."

    "The Source DUT must acknowledge the interrupt by writing to the TEST_RESPONSE register within 5
    seconds of IRQ HPD pulse detect."

In some cases, the ACK can only be set after the operation is complete (i.e. active video being transmitted or correct test pattern being transmitted). So for uniformity, the ACK with the appropriate other test bits set is done at the end. Also, with the 5 second timeout, there's no need to respond with an ACK immediately in some cases and wait til the end in others.

        return test_result;
 }

--
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Todd Previte

Monday, July 14, 2014 12:10 PM

Implements an updated version of the automated testing function that handles
Displayport compliance for EDID operations.

Signed-off-by: Todd Previte <tprevite@xxxxxxxxx>
---
drivers/gpu/drm/i915/intel_dp.c | 77 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 76 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 33b6dc9..88f1bbe 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3408,7 +3408,82 @@ intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)
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 i = 0, ret = 0;
+ struct drm_display_mode *use_mode = NULL;
+ int mode_count = 0;
+ struct drm_mode_set modeset;
+
+ DRM_DEBUG_KMS("Displayport: EDID automated test\n");
+
+ /* Reset the NACK/DEFER counters */
+ intel_dp->aux.i2c_nack_count = 0;
+ intel_dp->aux.i2c_defer_count = 0;
+ /* Now read out the EDID */
+ edid_read = drm_get_edid(connector, adapter);
+
+ if (edid_read == NULL) {
+ /* Check for NACKs/DEFERs, goto 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("Displayport: EDID read generated %d I2C NACKs, %d DEFERs\n",
+ intel_dp->aux.i2c_nack_count,
+ intel_dp->aux.i2c_defer_count);
+ goto failsafe;
+ }
+
+ /* FIXME: Need to determine how to detect E-DDC here (4.2.2.9) */
+ edid_data = (uint8_t *) edid_read;
+
+ if (intel_dp_compute_edid_checksum(edid_data, &checksum)) {
+ /* Write the checksum to EDID checksum register */
+ ret = drm_dp_dpcd_write(&intel_dp->aux,
+ DP_TEST_EDID_CHECKSUM,
+ &edid_read->checksum, 1);
+ /* Reponse is ACK and and checksum written */
+ test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE;
+ } else {
+ /* Invalid checksum - EDID corruption detection test */
+ goto failsafe;
+ }
+
+ /* Update EDID modes */
+ mode_count = intel_connector_update_modes(connector, edid_read);
+ if (!mode_count) {
+ DRM_DEBUG_KMS("Displayport: Mode update failed\n");
+ goto failsafe;
+ }
+
+ /* Get the EDID preferred mode if available */
+ use_mode = intel_dp_get_edid_preferred_mode(intel_dp);
+ if (use_mode == NULL)
+ goto failsafe;
+ else
+ goto set_mode;
+
+failsafe:
+ DRM_DEBUG_KMS("Displayport: Setting failsafe display mode\n");
+ use_mode = intel_dp_get_failsafe_mode();
+ /* FIXME: <TAP> Need to set DP to 6bpc here as well */
+ intel_dp->attached_connector->encoder->new_crtc->config.pipe_bpp = 18;
+
+set_mode:
+ /* Configure the display mode necessary */
+ modeset.connectors = &connector;
+ modeset.num_connectors = 1;
+ modeset.crtc = connector->encoder->crtc;
+ modeset.fb = modeset.crtc->primary->fb;
+ modeset.x = 0;
+ modeset.y = 0;
+ modeset.mode = use_mode;
+ /* Set the config */
+ intel_dp_set_config(&modeset);
+
return test_result;
}

Todd Previte

Monday, July 14, 2014 12:10 PM

V2:
- Addressed review feedback from the mailing list
- Broke up patches into smaller, easily managed chunks
- Reordered the patches such that they can be applied in order
- Fixed checkpatch.pl errors across the patchset
- Updated and enhanced functionality for the EDID test function
- Completely revamped the mode set operations for compliance testing

--

Sent with Postbox

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx