[Intel-gfx] [PATCH 07/12] drm/i915: Update EDID automated test function for Displayport compliance
Todd Previte
tprevite at gmail.com
Thu Jul 31 20:27:47 CEST 2014
> Paulo Zanoni <mailto:przanoni at gmail.com>
> Tuesday, July 29, 2014 3:37 PM
> 2014-07-14 16:10 GMT-03:00 Todd Previte<tprevite at 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 at 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 at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> Todd Previte <mailto:tprevite at 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 at 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 at 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
>
--
Sent with Postbox <http://www.getpostbox.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20140731/531d7cce/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1254 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20140731/531d7cce/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20140731/531d7cce/attachment-0001.jpg>
More information about the Intel-gfx
mailing list