<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CA+gsUGRXX6haWOh8XNef7_WV9z-miT3A7bJMoh50rgTyjnzF5g@mail.gmail.com"
type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="przanoni@gmail.com" photoname="Paulo Zanoni"
src="cid:part1.01030900.07030907@gmail.com" name="postbox-contact.jpg"
height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:przanoni@gmail.com"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Paulo Zanoni</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">Tuesday, July 29,
2014 3:37 PM</span></font></div></div></div>
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><pre wrap="">2014-07-14 16:10 GMT-03:00 Todd Previte <a class="moz-txt-link-rfc2396E" href="mailto:tprevite@gmail.com"><tprevite@gmail.com></a>:
</pre><blockquote type="cite"><pre wrap="">Implements an updated version of the automated testing function that handles
Displayport compliance for EDID operations.
</pre></blockquote><pre wrap=""><!---->
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 :)</pre></div>
</blockquote>
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.<br>
<blockquote style="border: 0px none;"
cite="mid:CA+gsUGRXX6haWOh8XNef7_WV9z-miT3A7bJMoh50rgTyjnzF5g@mail.gmail.com"
type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">
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?</pre>
</div>
</blockquote>
<br>
Makes sense. I'll add the additional info in the commit messages.<br>
<blockquote style="border: 0px none;"
cite="mid:CA+gsUGRXX6haWOh8XNef7_WV9z-miT3A7bJMoh50rgTyjnzF5g@mail.gmail.com"
type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">
</pre>
<blockquote type="cite"><pre wrap="">Signed-off-by: Todd Previte <a class="moz-txt-link-rfc2396E" href="mailto:tprevite@gmail.com"><tprevite@gmail.com></a>
---
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;
</pre></blockquote><pre wrap=""><!---->
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.</pre></div>
</blockquote>
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.<br>
<br>
However, since there are unused variables, I'll remove those in the next
iteration of this patch. :)<br>
<blockquote style="border: 0px none;"
cite="mid:CA+gsUGRXX6haWOh8XNef7_WV9z-miT3A7bJMoh50rgTyjnzF5g@mail.gmail.com"
type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">
</pre>
<blockquote type="cite"><pre wrap="">+
+ DRM_DEBUG_KMS("Displayport: EDID automated test\n");
+
+ /* Reset the NACK/DEFER counters */
</pre></blockquote><pre wrap=""><!---->
As I said before, this is a great example of the "comment says what
the code already says" problem.</pre></div>
</blockquote>
Fair enough. It will be removed.<br>
<blockquote style="border: 0px none;"
cite="mid:CA+gsUGRXX6haWOh8XNef7_WV9z-miT3A7bJMoh50rgTyjnzF5g@mail.gmail.com"
type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">
</pre>
<blockquote type="cite"><pre wrap="">+ 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) */
</pre></blockquote><pre wrap=""><!---->
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.</pre></div>
</blockquote>
I'll adjust the code to conform to the coding standard, whatever it
happens to be.<br>
<blockquote style="border: 0px none;"
cite="mid:CA+gsUGRXX6haWOh8XNef7_WV9z-miT3A7bJMoh50rgTyjnzF5g@mail.gmail.com"
type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><br>
<blockquote type="cite"><pre wrap="">+ if (intel_dp->aux.i2c_nack_count > 0 ||
+ intel_dp->aux.i2c_defer_count > 0)
</pre></blockquote><pre wrap=""><!---->
We tend to align the contents of the extra line with the '(' char on
the line above.</pre></div>
</blockquote>
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.<br>
<blockquote style="border: 0px none;"
cite="mid:CA+gsUGRXX6haWOh8XNef7_WV9z-miT3A7bJMoh50rgTyjnzF5g@mail.gmail.com"
type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">
</pre>
<blockquote type="cite"><pre wrap="">+ 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);
</pre></blockquote><pre wrap=""><!---->
There are way too many tabs on the 2 lines above.</pre></div>
</blockquote>
See above. This is the tab size problem.<br>
<blockquote style="border: 0px none;"
cite="mid:CA+gsUGRXX6haWOh8XNef7_WV9z-miT3A7bJMoh50rgTyjnzF5g@mail.gmail.com"
type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">
</pre>
<blockquote type="cite"><pre wrap="">+ goto failsafe;
+ }
+
+ /* FIXME: Need to determine how to detect E-DDC here (4.2.2.9) */
</pre></blockquote><pre wrap=""><!---->
But what is the problem with the current code? What are the
consequences of not implementing the FIXME?</pre></div>
</blockquote>
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.<br>
<blockquote style="border: 0px none;"
cite="mid:CA+gsUGRXX6haWOh8XNef7_WV9z-miT3A7bJMoh50rgTyjnzF5g@mail.gmail.com"
type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">
</pre>
<blockquote type="cite"><pre wrap="">+ 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);
</pre></blockquote><pre wrap=""><!---->
Way too many tabs above too.</pre></div>
</blockquote>
Same tab problem.<br>
<blockquote style="border: 0px none;"
cite="mid:CA+gsUGRXX6haWOh8XNef7_WV9z-miT3A7bJMoh50rgTyjnzF5g@mail.gmail.com"
type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">
</pre>
<blockquote type="cite"><pre wrap="">+ /* 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 */
</pre></blockquote><pre wrap=""><!---->
What does <TAP> mean? What are the consequences of not setting DP to
6bpc here as well?</pre></div>
</blockquote>
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. <br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CA+gsUGRXX6haWOh8XNef7_WV9z-miT3A7bJMoh50rgTyjnzF5g@mail.gmail.com"
type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><blockquote
type="cite"><pre wrap="">+ 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;
</pre></blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite"><pre wrap="">+ modeset.fb = modeset.crtc->primary->fb;
</pre></blockquote><pre wrap=""><!---->
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.
</pre><blockquote type="cite"><pre wrap="">+ modeset.x = 0;
+ modeset.y = 0;
+ modeset.mode = use_mode;
+ /* Set the config */
+ intel_dp_set_config(&modeset);
+
</pre></blockquote><pre wrap=""><!---->
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?).</pre></div>
</blockquote>
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. <br>
<blockquote style="border: 0px none;"
cite="mid:CA+gsUGRXX6haWOh8XNef7_WV9z-miT3A7bJMoh50rgTyjnzF5g@mail.gmail.com"
type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">
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.</pre>
</div>
</blockquote>
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:<br>
<br>
"If the test mode requested is supported, the Source DUT shall start
transmitting the<br>
TEST_VIDEO_PATTERN in the test mode requested, and set the TEST_ACK
bit in the TEST_RESPONSE<br>
register."<br>
<br>
"If the test mode requested is not supported, the Source DUT shall
signal a negative acknowledgement by<br>
setting the TEST_NAK bit in the TEST_RESPONSE register."<br>
<br>
"The Source DUT must acknowledge the interrupt by writing to the
TEST_RESPONSE register within 5<br>
seconds of IRQ HPD pulse detect.<span style="font-family:
monospace;">"<br>
<br>
</span>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. <br>
<span style="font-family: monospace;"><br>
</span>
<blockquote style="border: 0px none;"
cite="mid:CA+gsUGRXX6haWOh8XNef7_WV9z-miT3A7bJMoh50rgTyjnzF5g@mail.gmail.com"
type="cite">
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody"><blockquote type="cite"><pre wrap=""> return test_result;
}
--
1.9.1
_______________________________________________
Intel-gfx mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Intel-gfx@lists.freedesktop.org">Intel-gfx@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/intel-gfx">http://lists.freedesktop.org/mailman/listinfo/intel-gfx</a>
</pre></blockquote><pre wrap=""><!---->
</pre></div>
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="tprevite@gmail.com" photoname="Todd Previte"
src="cid:part2.08000601.09020704@gmail.com"
name="compose-unknown-contact.jpg" height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:tprevite@gmail.com"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Todd Previte</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">Monday, July 14,
2014 12:10 PM</span></font></div></div></div>
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody"><div>Implements an updated
version of the automated testing function that handles<br>Displayport
compliance for EDID operations.<br><br>Signed-off-by: Todd Previte
<a class="moz-txt-link-rfc2396E" href="mailto:tprevite@gmail.com"><tprevite@gmail.com></a><br>---<br> drivers/gpu/drm/i915/intel_dp.c |
77 ++++++++++++++++++++++++++++++++++++++++-<br> 1 file changed, 76
insertions(+), 1 deletion(-)<br><br>diff --git
a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c<br>index
33b6dc9..88f1bbe 100644<br>--- a/drivers/gpu/drm/i915/intel_dp.c<br>+++
b/drivers/gpu/drm/i915/intel_dp.c<br>@@ -3408,7 +3408,82 @@
intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)<br> static
uint8_t<br> intel_dp_autotest_edid(struct intel_dp *intel_dp)<br> {<br>-
uint8_t test_result = DP_TEST_NAK;<br>+ struct drm_connector *connector
= &intel_dp->attached_connector->base;<br>+ struct
i2c_adapter *adapter = &intel_dp->aux.ddc;<br>+ struct edid
*edid_read = NULL;<br>+ uint8_t *edid_data = NULL;<br>+ uint8_t
test_result = DP_TEST_NAK, checksum = 0;<br>+ uint32_t i = 0, ret = 0;<br>+
struct drm_display_mode *use_mode = NULL;<br>+ int mode_count = 0;<br>+
struct drm_mode_set modeset;<br>+<br>+ DRM_DEBUG_KMS("Displayport: EDID
automated test\n");<br>+<br>+ /* Reset the NACK/DEFER counters */<br>+
intel_dp->aux.i2c_nack_count = 0;<br>+
intel_dp->aux.i2c_defer_count = 0;<br>+ /* Now read out the EDID */<br>+
edid_read = drm_get_edid(connector, adapter);<br>+<br>+ if (edid_read
== NULL) {<br>+ /* Check for NACKs/DEFERs, goto failsafe if detected<br>+
(DP CTS 1.2 Core Rev 1.1, 4.2.2.4, 4.2.2.5) */<br>+ if
(intel_dp->aux.i2c_nack_count > 0 ||<br>+
intel_dp->aux.i2c_defer_count > 0)<br>+
DRM_DEBUG_KMS("Displayport: EDID read generated %d I2C NACKs, %d
DEFERs\n",<br>+ intel_dp->aux.i2c_nack_count,<br>+
intel_dp->aux.i2c_defer_count);<br>+ goto failsafe;<br>+ }<br>+<br>+
/* FIXME: Need to determine how to detect E-DDC here (4.2.2.9) */<br>+
edid_data = (uint8_t *) edid_read;<br>+<br>+ if
(intel_dp_compute_edid_checksum(edid_data, &checksum)) {<br>+ /*
Write the checksum to EDID checksum register */<br>+ ret =
drm_dp_dpcd_write(&intel_dp->aux,<br>+
DP_TEST_EDID_CHECKSUM,<br>+ &edid_read->checksum, 1);<br>+
/* Reponse is ACK and and checksum written */<br>+ test_result =
DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE;<br>+ } else {<br>+ /*
Invalid checksum - EDID corruption detection test */<br>+ goto
failsafe;<br>+ }<br>+<br>+ /* Update EDID modes */<br>+ mode_count =
intel_connector_update_modes(connector, edid_read);<br>+ if
(!mode_count) {<br>+ DRM_DEBUG_KMS("Displayport: Mode update
failed\n");<br>+ goto failsafe;<br>+ }<br>+<br>+ /* Get the EDID
preferred mode if available */<br>+ use_mode =
intel_dp_get_edid_preferred_mode(intel_dp);<br>+ if (use_mode == NULL)<br>+
goto failsafe;<br>+ else<br>+ goto set_mode;<br>+<br>+failsafe:<br>+
DRM_DEBUG_KMS("Displayport: Setting failsafe display mode\n");<br>+
use_mode = intel_dp_get_failsafe_mode();<br>+ /* FIXME: <TAP> Need
to set DP to 6bpc here as well */<br>+
intel_dp->attached_connector->encoder->new_crtc->config.pipe_bpp
= 18;<br>+<br>+set_mode:<br>+ /* Configure the display mode necessary
*/<br>+ modeset.connectors = &connector;<br>+ modeset.num_connectors
= 1;<br>+ modeset.crtc = connector->encoder->crtc;<br>+
modeset.fb = modeset.crtc->primary->fb;<br>+ modeset.x = 0;<br>+
modeset.y = 0;<br>+ modeset.mode = use_mode;<br>+ /* Set the config */<br>+
intel_dp_set_config(&modeset);<br>+<br> return test_result;<br> }<br>
<br></div></div>
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="tprevite@gmail.com" photoname="Todd Previte"
src="cid:part2.08000601.09020704@gmail.com"
name="compose-unknown-contact.jpg" height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:tprevite@gmail.com"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Todd Previte</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">Monday, July 14,
2014 12:10 PM</span></font></div></div></div>
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody"><div><!----><br>V2:<br>-
Addressed review feedback from the mailing list<br>- Broke up patches
into smaller, easily managed chunks<br>- Reordered the patches such that
they can be applied in order<br>- Fixed checkpatch.pl errors across the
patchset <br>- Updated and enhanced functionality for the EDID test
function<br>- Completely revamped the mode set operations for compliance
testing<br><br></div></div>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<div>Sent with <a href="http://www.getpostbox.com"><span style="color:
rgb(51, 102, 153);">Postbox</span></a></div></div>
</body></html>