2014-07-22 18:11 GMT-03:00 Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>: > On Tue, 22 Jul 2014 22:53:44 +0200 > Daniel Vetter <daniel@xxxxxxxx> wrote: > >> On Tue, Jul 22, 2014 at 10:48 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> 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. 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. - 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 :) - 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. - 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. - The user-space app could be part of intel-gpu-tools. 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
