From mboxrd@z Thu Jan 1 00:00:00 1970 From: Todd Previte Subject: Re: [PATCH v2] Displayport compliance testing Date: Thu, 31 Jul 2014 11:27:20 -0700 Message-ID: <53DA8A88.6080701@gmail.com> References: <1405365047-6866-1-git-send-email-tprevite@gmail.com> <20140722064111.GE15237@phenom.ffwll.local> <20140722134845.08b9ebf5@jbarnes-desktop> <20140722141145.4cddf4e5@jbarnes-desktop> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0473756500==" Return-path: Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by gabe.freedesktop.org (Postfix) with ESMTP id 7ABDA6E22B for ; Thu, 31 Jul 2014 11:27:15 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lf10so4095949pab.15 for ; Thu, 31 Jul 2014 11:27:15 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Paulo Zanoni Cc: intel-gfx List-Id: intel-gfx@lists.freedesktop.org This is a multi-part message in MIME format. --===============0473756500== Content-Type: multipart/alternative; boundary="------------030608050408040102060301" This is a multi-part message in MIME format. --------------030608050408040102060301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > Paulo Zanoni > Tuesday, July 29, 2014 2:53 PM > 2014-07-22 18:11 GMT-03:00 Jesse Barnes: >> On Tue, 22 Jul 2014 22:53:44 +0200 >> Daniel Vetter wrote: >> >>> On Tue, Jul 22, 2014 at 10:48 PM, Jesse Barnes wrote: >>>> Are you saying >>>> you'll reject this approach entirely? >>> I'm saying that I don't see terrible lot of value in adding a bunch of >>> code for a sticker, and that we should look into making it actually >>> useful by testing the paths that end-users end up using. And we have >>> to keep this working once it's merged. >>> >>> But if it doesn't make sense to make this sticker useful while still >>> being able to get it then I'll reconsider. >> Yeah I think it depends on the test. We're supposed to go through >> existing paths for testing e.g. link training with different params >> (though with a fixed fb and mode), so getting coverage there is >> something we want regardless. But getting something like probing >> covered as part of the compliance testing may be something else >> entirely... > > I was finally able to take some time to read the spec, and I agree > that the hybrid approach looks like the way to go. Some tests require > specifically-crafted FBs, while some other tests cause real hotplug > events to be sent from the sink. If there's an unknown/unspecified > user-space running when the tests are happening, who knows how it is > going to react? Of course, for tests that can be implemented directly > inside the Kernel still using the "standard" code paths, we should do > it in the Kernel. There's no question that this is going to require considerable support within the kernel. The tests that can be placed inside the kernel are mostly going to be ones that simply can't be accomplished from userspace (the 400us AUX transaction retry, for instance) or are elements that are necessary to enable the userspace tests to execute properly. The tests themselves though should definitely be handled out in userspace where possible. > One possible approach that I thought would be the following: > - Each DP encoder provides its own debugfs file for DP test compiance > (e.g., /sys/kernel/debug/dri/0/i915_ddi_b_dp_test_compliance). > - If the file is not open, any requests for tests that require special > actions from our driver - outside of the normal behavior - will be > NACKed. There's a couple options here that I've considered. This is a perfectly valid option but it's also possible to just use one debugfs file for the compliance work. It's unlikely that multiple Displayport connectors will ever be testing simultaneously, so the need to adjust the parameters on a per-connector basis is arguable. Only the connector for the sink that issued the test request would be required to read the debugfs file and adhere to its parameters. For general debugging of Displayport though, this is a better option as it allows for considerably more flexibility and utility. Personally I prefer the individual file approach, even though it might end up being somewhat more complicated to implement. The single-file approach does have merit though, so if anyone has a solid argument in favor of that, it's worth the discussion. > - If the file is open, we ACK test requests and print special strings > to the debugfs file telling the user-space app what it's supposed to > do. We could use simple strings like "set the preferred mode", "set > failsafe mode", "set mode using FB test pattern Y", etc. A stringly > typed protocol :) Probably better to use clearly-defined constants instead of strings, but yes, that's the idea. :) > - The user-space app needs to be the DRM master, open the debugfs > file, parse the operations it prints and act accordingly, and listen > to the hotplug events sent by the Kernel. Agreed. > - If some special corner quirky case needs to be done (e.g., train > link with a specific number of lanes), the Kernel should store this > information at struct intel_dp, and then when a modeset is done on > this encoder, we check if the debugfs file is open (i.e., we're doing > compliance testing) and then we use the specified configuration. With > this, we can probably avoid special uevents or debug-only > connector/encoder properties. I would argue here that it's better to leave as much of the active configuration undisturbed as possible and only update the fields necessary to complete the test(s). Additionally, any fields that are changed should be saved and subsequently restored upon completion of the test(s) > - The user-space app could be part of intel-gpu-tools. Cool, this is what I was planning on doing. One thing I was looking into was potentially launching the test app from a uevent in the kernel. But none of the solutions I could find were all that good and some were downright scary. So having the app as a separate entity that needs to be launched by the tester isn't such a bad idea. Anyway, this is just an alternate idea to Daniel's suggestion, and many other possible implementation ideas would work for me. Todd, what is your opinion? I will continue the review of the patches we currently have, since it seems we didn't decide what we're gonna merge. > >> -- >> Jesse Barnes, Intel Open Source Technology Center >> _______________________________________________ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > Jesse Barnes > Tuesday, July 22, 2014 2:11 PM > On Tue, 22 Jul 2014 22:53:44 +0200 > > Yeah I think it depends on the test. We're supposed to go through > existing paths for testing e.g. link training with different params > (though with a fixed fb and mode), so getting coverage there is > something we want regardless. But getting something like probing > covered as part of the compliance testing may be something else > entirely... > > Daniel Vetter > Tuesday, July 22, 2014 1:53 PM > > I'm saying that I don't see terrible lot of value in adding a bunch of > code for a sticker, and that we should look into making it actually > useful by testing the paths that end-users end up using. And we have > to keep this working once it's merged. > > But if it doesn't make sense to make this sticker useful while still > being able to get it then I'll reconsider. > -Daniel > Jesse Barnes > Tuesday, July 22, 2014 1:48 PM > On Tue, 22 Jul 2014 08:41:11 +0200 > > This amounts to a complete rewrite with a different goal. In this > series, I only see two big new test functions added: one for EDID > testing and one for link training. The EDID one could probably share > some more code with the core, but for link training it seems pretty > simple, unless we need a full mode & fb for some reason (I'm presuming > Todd has tested this with the equipment). Paulo had some good > feedback, but overall this is a small addition to get the compliance > tests working and get some coverage on the link training paths which we > desperately need. > > Having some additional user level tests would be great, but that's a > much bigger and different task than simply implementing what's required > for the DP compliance test. Asking Todd to take on a huge new task > just because he posted this series is a big request. Are you saying > you'll reject this approach entirely? > > Daniel Vetter > Monday, July 21, 2014 11:41 PM > > Ok, high level review of the overall approach. > > So your design is to implement special functions for each test procedure. > This has two issues: > - We have duplicated code we test, which has a really high chance to be > different from what users actually run on their systems. And so dp > validation won't actually validate the real code. Example would be the > fallback edid reading tests using defer/nacks. The drm i2c helpers > already have logic for this (including fallback modes), but very likely > it doesn't quite match the dp requirements. So we need to adjust that > (presuming the dp standard is sane). > - Even if we can fix this there's still lots of important code in the > probe paths we can't test with this. Userspace updates edids through the > get_connector ioctl, and there's lots of additional logic in-between > until we reach the dp connector implementation in intel_dp.c. > > So what I'd like to see is that the test procedures are implemented in > userspace, using nothing more than the standard kms interfaces. > > Afaics we need three steps overall: > - Get a shot hpd pulse and notice that we should do a validation test > sequence. We need to get this information to userspace, and the best > approach would be a uevent on the connector in sysfs. We can supply any > additional metadata (like the test mode) userspace needs with uevent > attributes. > > - Do the test from userspace. Depending upon what exactly needs to be done > we might need to extend the properties exposed to userspace, e.g. dp > link parameters. > > - Give the result (edid checksum, ...) back to the dp sink/validator. A > generic dp aux transaction interface for userspace in the dp helpers, > maybe even as a real /dev node should fit the bill. > > dp validation has the potential to automatically test a pile of code for > which we currently have 0 automated test coverage at all. I want to fully > seize this opportunity instead of doing the bare minimum to get a (rather > useless) certification. > -Daniel -- Sent with Postbox --------------030608050408040102060301 Content-Type: multipart/related; boundary="------------060207080404000809010505" --------------060207080404000809010505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Tuesday, July 29, 2014 2:53 PM
2014-07-22 18:11 GMT-03:00 Jesse Barnes <jbarnes@virtuousgeek.org>:

On Tue, 22 Jul 2014 22:53:44 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:


On Tue, Jul 22, 2014 at 10:48 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

Are you saying
you'll reject this approach entirely?

I'm saying that I don't see terrible lot of value in adding a bunch of
code for a sticker, and that we should look into making it actually
useful by testing the paths that end-users end up using. And we have
to keep this working once it's merged.

But if it doesn't make sense to make this sticker useful while still
being able to get it then I'll reconsider.

Yeah I think it depends on the test.  We're supposed to go through
existing paths for testing e.g. link training with different params
(though with a fixed fb and mode), so getting coverage there is
something we want regardless.  But getting something like probing
covered as part of the compliance testing may be something else
entirely...


I was finally able to take some time to read the spec, and I agree
that the hybrid approach looks like the way to go. Some tests require
specifically-crafted FBs, while some other tests cause real hotplug
events to be sent from the sink. If there's an unknown/unspecified
user-space running when the tests are happening, who knows how it is
going to react? Of course, for tests that can be implemented directly
inside the Kernel still using the "standard" code paths, we should do
it in the Kernel.
There's no question that this is going to require considerable support within the kernel. The tests that can be placed inside the kernel are mostly going to be ones that simply can't be accomplished from userspace (the 400us AUX transaction retry, for instance) or are elements that are necessary to enable the userspace tests to execute properly. The tests themselves though should definitely be handled out in userspace where possible. 
One possible approach that I thought would be the following:
- Each DP encoder provides its own debugfs file for DP test compiance
(e.g., /sys/kernel/debug/dri/0/i915_ddi_b_dp_test_compliance).
- If the file is not open, any requests for tests that require special
actions from our driver - outside of the normal behavior - will be
NACKed.
There's a couple options here that I've considered. This is a perfectly valid option but it's also possible to just use one debugfs file for the compliance work. It's unlikely that multiple Displayport connectors will ever be testing simultaneously, so the need to adjust the parameters on a per-connector basis is arguable. Only the connector for the sink that issued the test request would be required to read the debugfs file and adhere to its parameters.

For general debugging of Displayport though, this is a better option as it allows for considerably more flexibility and utility. Personally I prefer the individual file approach, even though it might end up being somewhat more complicated to implement. The single-file approach does have merit though, so if anyone has a solid argument in favor of that, it's worth the discussion.
- If the file is open, we ACK test requests and print special strings
to the debugfs file telling the user-space app what it's supposed to
do. We could use simple strings like "set the preferred mode", "set
failsafe mode", "set mode using FB test pattern Y", etc. A stringly
typed protocol :)
Probably better to use clearly-defined constants instead of strings, but yes, that's the idea. :)
- The user-space app needs to be the DRM master, open the debugfs
file, parse the operations it prints and act accordingly, and listen
to the hotplug events sent by the Kernel.
Agreed.
- If some special corner quirky case needs to be done (e.g., train
link with a specific number of lanes), the Kernel should store this
information at struct intel_dp, and then when a modeset is done on
this encoder, we check if the debugfs file is open (i.e., we're doing
compliance testing) and then we use the specified configuration. With
this, we can probably avoid special uevents or debug-only
connector/encoder properties.
I would argue here that it's better to leave as much of the active configuration undisturbed as possible and only update the fields necessary to complete the test(s). Additionally, any fields that are changed should be saved and subsequently restored upon completion of the test(s)
- The user-space app could be part of intel-gpu-tools.
Cool, this is what I was planning on doing. One thing I was looking into was potentially launching the test app from a uevent in the kernel. But none of the solutions I could find were all that good and some were downright scary. So having the app as a separate entity that needs to be launched by the tester isn't such a bad idea.

Anyway, this is just an alternate idea to Daniel's suggestion, and
many other possible implementation ideas would work for me. Todd, what
is your opinion?

I will continue the review of the patches we currently have, since it
seems we didn't decide what we're gonna merge.


--
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Tuesday, July 22, 2014 2:11 PM
On Tue, 22 Jul 2014 22:53:44 +0200

Yeah I think it depends on the test. We're supposed to go through
existing paths for testing e.g. link training with different params
(though with a fixed fb and mode), so getting coverage there is
something we want regardless. But getting something like probing
covered as part of the compliance testing may be something else
entirely...

Tuesday, July 22, 2014 1:53 PM

I'm saying that I don't see terrible lot of value in adding a bunch of
code for a sticker, and that we should look into making it actually
useful by testing the paths that end-users end up using. And we have
to keep this working once it's merged.

But if it doesn't make sense to make this sticker useful while still
being able to get it then I'll reconsider.
-Daniel
Tuesday, July 22, 2014 1:48 PM
On Tue, 22 Jul 2014 08:41:11 +0200

This amounts to a complete rewrite with a different goal. In this
series, I only see two big new test functions added: one for EDID
testing and one for link training. The EDID one could probably share
some more code with the core, but for link training it seems pretty
simple, unless we need a full mode & fb for some reason (I'm presuming
Todd has tested this with the equipment). Paulo had some good
feedback, but overall this is a small addition to get the compliance
tests working and get some coverage on the link training paths which we
desperately need.

Having some additional user level tests would be great, but that's a
much bigger and different task than simply implementing what's required
for the DP compliance test. Asking Todd to take on a huge new task
just because he posted this series is a big request. Are you saying
you'll reject this approach entirely?

Monday, July 21, 2014 11:41 PM

Ok, high level review of the overall approach.

So your design is to implement special functions for each test procedure.
This has two issues:
- We have duplicated code we test, which has a really high chance to be
different from what users actually run on their systems. And so dp
validation won't actually validate the real code. Example would be the
fallback edid reading tests using defer/nacks. The drm i2c helpers
already have logic for this (including fallback modes), but very likely
it doesn't quite match the dp requirements. So we need to adjust that
(presuming the dp standard is sane).
- Even if we can fix this there's still lots of important code in the
probe paths we can't test with this. Userspace updates edids through the
get_connector ioctl, and there's lots of additional logic in-between
until we reach the dp connector implementation in intel_dp.c.

So what I'd like to see is that the test procedures are implemented in
userspace, using nothing more than the standard kms interfaces.

Afaics we need three steps overall:
- Get a shot hpd pulse and notice that we should do a validation test
sequence. We need to get this information to userspace, and the best
approach would be a uevent on the connector in sysfs. We can supply any
additional metadata (like the test mode) userspace needs with uevent
attributes.

- Do the test from userspace. Depending upon what exactly needs to be done
we might need to extend the properties exposed to userspace, e.g. dp
link parameters.

- Give the result (edid checksum, ...) back to the dp sink/validator. A
generic dp aux transaction interface for userspace in the dp helpers,
maybe even as a real /dev node should fit the bill.

dp validation has the potential to automatically test a pile of code for
which we currently have 0 automated test coverage at all. I want to fully
seize this opportunity instead of doing the bare minimum to get a (rather
useless) certification.
-Daniel

--
Sent with Postbox
--------------060207080404000809010505 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD8+vGXjPxJ4h8Ty6xrFzZ6jf6jBbXd5eXu nW1xNNLJbxu7M7xk/eY4GcKMAAAACHI6Y07s+l/g3+zwvjTwamt65Ppdmbpd0MUOj2W9kI4c 5iI59MdK8HFZs6Vb2cFex9JhclVWgp1Ha+x5/wDEv4V658LfFWlSRXWlzWL3sPlXEWk2ttcR sJV4DxoGDYJIdSCCuRiu/BYxYjR6M8vMMveF21Ryn/DaH7U3/RZNa/79Qf8AxuvRPK5R3wV8 G+CviH4g1fSPEmqLbX39i2h0lGfb5s6JEWAHRjtUjb6MTjjjyc0xNTC0ueCuup9BkmFoY2o4 VHZ9PvPtyH4e6Po2paRr9lrdtaFGhby2jj/cFRgYcAOowMY3YOcEYr5zC1qipXa1Z9ZiMJTq VdHZJHzL+094m1671/Qv7Um2jUL+G4gjUoIvLXadygKGXBYjlmBGCMdK+iy6EdWlqfJ5w5xt GT9D5Y+zn++3/fBr09TwLn05+yr8E/FOq+KrrxrdaVPa22g20lqjXUTR79QChPKCsAfkGd3H BwOtfOZ7joJRwy+KT27LzPsuHctlGTxU1ZJaPu32PpnVfF3huy8MajdzXkVtqCwNFew3Urhr baOH8sMoP45U1hg6c2rNHoYvEUqd5XPg/wCMvxKm+IPja21m3kf+ztJjjtLEPjcUQ5Zz9T/K vo8LQ9jT16nxuPxLxNXm6dDO/wCFXfGT/ol/iv8A8E0//wARW9kcnLP+rH3Z8f8A/kq/ij/s It/6ClfL1/8AfmfYR/3aPoj5J+On/INH+/8A1r2sL8R4WL+E82+E/wDyVDwb/wBjBp3/AKUx 16b2PFe5++1BR//Z --------------060207080404000809010505 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------060207080404000809010505 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="postbox-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="postbox-contact.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAAR CAAZABkDAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0F/H1kV06/wBcitb671eGCea+lghlLyGK N5N7uM/xH1AHAxivhK0qkpNo+mpxpqKuzDuviVcw/FaXQ4bDT5LAaOo+zDS4Nput4IO/Z3Vh 09e4rT2U/qvP1uZc8frHJfodbP4jnMUmpW/heMw2t5BDLLDaQxszZAbyyq78gtwwI6A7uDWF FVHJXla5tU5ErJXPNf8AhrL4rf8AQ1eIP/ANf/jderzV/wDn5+Rw8tL+Q5zSfE+tXPhrTrC3 8MWcljBZwK6XOGHyxDfkc8HqcjoeM5ArlrQh7RuVTV9jaDfLZQOVj13xBL8To9ZjSCO7Nx9i QRZaMYtlIwFHLAbRgDhq77UvqvLq9L/icn7xYnm0XT8D03Tf+E41C8tL/UNduLdRKipHBbrH 5hxkAO3XrnP+0fQZ8pVKULKML+rPRdOo/ilY+fv7C1n/AKGL/wAip/jXq/WI/wAhw+yf8xsW /wAUbq0sItOXw9Np11YWkMLo+F82RU2sro2GXBD5GM8FcAis3l/vtyd/0NI43RRiv+Ccze/E HWjq8mrbghl1Se4S5jj2/Ps2BcAjkYGVz371208LD2bh5Wt87nJOtLm5vM3774pX5e2vL/xJ GBcFZdqHCE8MVKnOGyeckADtgYONPCQvpA0niJN6yPLv+EN+I3/RP/E3/gquf/iK9H2b/lOX n8zs/wBr7/k57xj/ANfy/wDolKc/tDjujyDV/wDj3m/7CEtOjuFb4fmX/hv/AMjJ4S/7GWy/ 9LIa2/5eGX2D9yasR//Z --------------060207080404000809010505-- --------------030608050408040102060301-- --===============0473756500== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============0473756500==--