[Intel-gfx] [PATCH 5/5] drm/i915: Add support for DP Video pattern compliance tests

[Daniel Vetter]

On Wed, Nov 23, 2016 at 03:58:34PM +0200, Jani Nikula wrote:
> On Wed, 23 Nov 2016, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> > On Wed, Nov 23, 2016 at 03:37:24PM +0200, Jani Nikula wrote:
> >> On Tue, 22 Nov 2016, Manasi Navare <manasi.d.navare at intel.com> wrote:
> >> > The intel_dp_autotest_video_pattern() function gets invoked through the
> >> > compliance test handler on a HPD short pulse if the test type is
> >> > set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
> >> > reads to read the requested test pattern, video pattern resolution,
> >> > frame rate and bits per color value. The results of this analysis
> >> > are handed off to userspace so that the userspace app can set the
> >> > video pattern mode appropriately for the test result/response.
> >> >
> >> > The compliance_test_active flag is set at the end of the individual
> >> > test handling functions. This is so that the kernel-side operations
> >> > can be completed without the risk of interruption from the userspace
> >> > app that is polling on that flag.
> >> 
> >> I've brought this up before, but I think for this stuff the way to go is
> >> to have the userspace read the DPCD directly. We have the dev node for
> >> it.
> >> 
> >> With the approach in this patch, we'll just end up reading a bunch of
> >> stuff from DPCD in kernel, doing error handling for that, decoding and
> >> sanity checking the values, putting them in debugfs for the userspace to
> >> read, having userspace code read debugfs, doing error handling for that,
> >> decoding and sanity checking the data, finally doing something based on
> >> the data.
> >> 
> >> You'll also get a *much* faster turnaround for getting your userspace
> >> code done than getting all of this in kernel first, then tweaking your
> >> userspace, having to update both of those in lockstep, etc. When this is
> >> based on reading DPCD directly, you can just add new stuff quickly in
> >> userspace, with no kernel dependency.
> >> 
> >> The easiest way would be to have an indication in debugfs for userspace
> >> that there's something interesting in DPCD. Just a simple thing.
> >
> > Or just have the kernel fire off an uevent...
> 
> I know, I know, I had that written in my mail already, but swallowed it
> not to add another dependency on another new UABI... we can do that
> later.

In principle I'd agree, but the trouble with dp compliance is that the CTS
expects us to do stupid shit sometimes, like that test pattern forced as
6bpc. So if we decode&handle everything in userspace then the question is
how to feed all those special cases back into the kernel, which means more
debugfs interfaces. Just going in the other direction.

Given that it's a bit a toss-up unfortunately, and the current approach
seems reasonable.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch