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

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Mon May 18 03:42:59 PDT 2015


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.

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.

And also with nv12-plane-linear I see FIFO underruns so perhaps wm 
programming is not fully OK for NV12?

Regards,

Tvrtko


More information about the Intel-gfx mailing list