[igt-dev] [PATCH i-g-t] lib/igt_debugfs: Add timeouts to opening pipe CRC fd.
Dhinakaran Pandiyan
dhinakaran.pandiyan at intel.com
Fri Apr 6 18:27:30 UTC 2018
On Fri, 2018-04-06 at 09:33 +0200, Maarten Lankhorst wrote:
> Op 06-04-18 om 00:39 schreef Dhinakaran Pandiyan:
> > On Thu, 2018-04-05 at 22:10 +0000, Souza, Jose wrote:
> >> On Thu, 2018-04-05 at 22:15 +0100, Chris Wilson wrote:
> >>> Quoting Souza, Jose (2018-04-05 22:03:46)
> >>>> On Thu, 2018-04-05 at 12:49 +0200, Maarten Lankhorst wrote:
> >>>>> This will fix the PSR tests to fail slightly faster, since they
> >>>>> wait
> >>>>> indefinitely for a CRC that never comes during open.
> > Because the pipe is not active and hence doesn't generate crc's any
> > more? The timeouts are needed but any idea how we should deal with the
> > lack of CRCs?
> >
> >>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.c
> >>>>> om>
> >>>>> ---
> >>>>> lib/igt_debugfs.c | 3 +++
> >>>>> 1 file changed, 3 insertions(+)
> >>>>>
> >>>>> diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
> >>>>> index 8adc02e9cc47..094df564b6f4 100644
> >>>>> --- a/lib/igt_debugfs.c
> >>>>> +++ b/lib/igt_debugfs.c
> >>>>> @@ -757,7 +757,10 @@ void igt_pipe_crc_start(igt_pipe_crc_t
> >>>>> *pipe_crc)
> >>>>>
> >>>>> sprintf(buf, "crtc-%d/crc/data", pipe_crc->pipe);
> >>>>>
> >>>>> + igt_set_timeout(5, "Opening crc fd, which waits for first
> >>>>> CRC.");
> >>>>> pipe_crc->crc_fd = openat(pipe_crc->dir, buf, pipe_crc-
> >>>>>> flags);
> >>>>> + igt_reset_timeout();
> >>>> Hum I was able to reproduce this one too in a KBL, I was thinking
> >>>> in
> >>>> add a timeout in the kernel side, if it don't get the CRC buffer
> >>>> filled
> >>>> it would return a error.
> >>> That would be unexpected behaviour for a read() interface. If you
> >>> want a
> >>> timeout, implement poll().
> >> Not change the read() but return a error in open() when timeout
> >> happens:
> >>
> >> "
> >> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> >> b/drivers/gpu/drm/drm_debugfs_crc.c
> >> index 9f8312137cad..223cd45b3aff 100644
> >> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> >> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> >> @@ -206,9 +206,10 @@ static int crtc_crc_open(struct inode *inode,
> >> struct file *filep)
> >> * guess when this particular piece of HW will be ready to
> >> start
> >> * generating CRCs.
> >> */
> >> - ret = wait_event_interruptible_lock_irq(crc->wq,
> >> - crtc_crc_data_count(cr
> >> c),
> >> - crc->lock);
> >> + ret = wait_event_interruptible_lock_irq_timeout(crc->wq,
> >> + crtc_crc_data_
> >> count(crc),
> >> + crc->lock,
> >> + msecs_to_jiffi
> >> es(2500));
> >> spin_unlock_irq(&crc->lock);
> >>
> >> if (ret)
>
> I think this should be fixed in userspace, and the fix of doing a
> timeout in igt_pipe_crc_start should work. The kernel side is correct
> to block forever,
Even if the kernel knows the hardware will not generate CRCs? That seems
to be the case here, isn't it?
> and this helped us caught bugs when igt/debugfs_test
> was reading /sys/kernel/debug/dri/0/crtc-0/crc/data and being blocked
> until the test hit its internal timeout (10s), we would lose that
> check if kernel times out sooner.
>
> On your patch itself, I think the _timeout function returns a long with
> the remainder of the timeout, and 0 for timed out, the if (ret) below
> wouldn't work any more in that case.
>
>
> ~Maarten
> _______________________________________________
> igt-dev mailing list
> igt-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
More information about the igt-dev
mailing list