| Message ID | 1405365047-6866-8-git-send-email-tprevite@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
2014-07-14 16:10 GMT-03:00 Todd Previte <tprevite@gmail.com>: > 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 :) 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? > > Signed-off-by: Todd Previte <tprevite@gmail.com> > --- > 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. > + > + 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. > + 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. > + 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. > + 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. > + 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? > + 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. > + /* 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? > + 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?). 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. > 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 <mailto:przanoni@gmail.com> > Tuesday, July 29, 2014 3:37 PM > 2014-07-14 16:10 GMT-03:00 Todd Previte<tprevite@gmail.com>: >> 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@gmail.com> >> --- >> 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@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > Todd Previte <mailto:tprevite@gmail.com> > 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@gmail.com> > --- > 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 <mailto:tprevite@gmail.com> > 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 >
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; }
Implements an updated version of the automated testing function that handles Displayport compliance for EDID operations. Signed-off-by: Todd Previte <tprevite@gmail.com> --- drivers/gpu/drm/i915/intel_dp.c | 77 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 76 insertions(+), 1 deletion(-)