On Wed, 23 Nov 2016, Ville Syrjälä <ville.syrj...@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.nav...@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.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to