[Intel-gfx] [PATCH 00/11] Skylake display NV12 feature addition

[Konduru, Chandra]

> -----Original Message-----
> From: Tvrtko Ursulin [mailto:tvrtko.ursulin at linux.intel.com]
> Sent: Monday, May 18, 2015 3:43 AM
> To: Konduru, Chandra; Vetter, Daniel; Lespiau, Damien; Syrjala, Ville
> Cc: intel-gfx at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 00/11] Skylake display NV12 feature addition
> 
> 
> Hi,
> 
> On 05/18/2015 06:24 AM, Konduru, Chandra wrote:
> >> -----Original Message-----
> >> From: Tvrtko Ursulin [mailto:tvrtko.ursulin at linux.intel.com]
> >> Sent: Thursday, May 14, 2015 5:47 AM
> >> To: Konduru, Chandra; Vetter, Daniel; Lespiau, Damien; Syrjala, Ville
> >> Cc: intel-gfx at lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH 00/11] Skylake display NV12 feature
> >> addition
> >>
> >>
> >> On 05/14/2015 06:13 AM, Konduru, Chandra wrote:
> >>> Hi,
> >>> I have seen review comments from you and addressed/responded to them.
> >>> Can you please give R-b tag?
> >>
> >> What about that WARN_ON(fb->pixel_format == DRM_FORMAT_NV12) I am
> >> hitting (and subsequent hard hang)? Were you able to repro that?
> >>
> >> I did rebase your series on latest nightly but it was very trivial if
> >> anything so I don't think I did something wrong there.
> >
> > I was able to reproduce the issue and found the root-cause.
> > The required steps to reproduce this issue requires NV12 as primary
> > plane format via drmModeCrtcSetConfig() and the way you modified
> > kms_rotation_crc is just doing that. In crtc set config flow the way
> > atomic commit planes called without atomic commit call. So, it is missing
> setupscalers required for NV12.
> > And the WARN_ON I added is catching this scenario.
> >
> > Though this may be not common, it requires proper handling in i915.
> > I just send combined NV12 patch series for 0/180 and 90/270 including
> > addressing this issue.
> > Can you please check at your end with updated series?
> >
> > By the way, you need latest drm-intel-nightly, then apply your GEM
> > remapping for NV12 patches (2 to 7 of 8, 8th not required. And 1st one
> > is already merged), then apply my series (12 of 12).
> 
> Warn is gone but my box still locks up hard.
Good.
> 
> I can even reproduce the lockup by running nv12-plane-linear subtest from
> kms_nv12, where it happens perhaps on the second run. May be more easily
> triggerable with drm.debug=0 - but I am not so confident about that.

I have been testing on two boards, and on one board (A step), issue never happens
i.e., no lockups. On the other board (C step), issue happens. I tried chicken bit 
workarounds for C, but still seeing issue. Debugging what is causing lockup.

On another note, when I tested earlier with 400rc3 kernel, I didn't see these lockups
but after moving to 410rc2 started seeing them. So combination of NV12 and
whatever happened in kernel upgrade is causing lockup (at least that' how it appears
now). And this only happens on board (C) not on (A).

> 
> And also with nv12-plane-linear I see FIFO underruns so perhaps wm
> programming is not fully OK for NV12?
Looking at wm programming to rule out that is the case.
> 
> Regards,
> 
> Tvrtko