Bug 110327

Summary: [exynos-drm] failed to presentate a dumb buffer format NV12 with modifier DRM_FORMAT_MOD_SAMSUNG_64_32_TILE
Product: DRI Reporter: Jens Ziller <zillevdr>
Component: DRM/otherAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: blocker    
Priority: medium    
Version: unspecified   
Hardware: ARM   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
picture from screen
none
complete dmesg out none

Description Jens Ziller 2019-04-04 16:32:07 UTC 
Created attachment 143863 [details]
picture from screen

I want to decode a H264 1280x720 video with v4l2 decoder and present this on DRM with a dumb buffer.

On screen the Y plane is correct but UV plane have the doubled height. Pitch is correct. But looks like a line from uv plane is used for 4 lines on y plane instead of 2. Attached are a picture from the screen. I use the format describtion from: https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-nv12mt.html. 

For dumb buffer configuration the height must aligned to 64 instead of to 32. If align height to 32 EINVAL is returned from AddFB2. OK, the UV plane have the half height from Y plane and must aligned to 32.

The size from DRM_IOCTL_CREATE_DUMB_BUFFER is to big. IOCTL returned a dumb buffer size from 1966080.
width = 1280 => aligned to 128 width = 1280
height = 720 => aligned to 64 height = 768
Y plane 1280 * 768 = 983040
UV plane 1280 * 768 / 2 = 491520
Dumb buffer size should be 1474560. Looks like the UV plane have doubled size as it should be.

The device is a Odroid-U3 with Exynos4412.
Kernel version is 5.0.5.
Comment 1 andrzej.hajda 2019-04-05 06:54:57 UTC 
Could you post exact steps to reproduce it? Code/command line, plus kernel logs with drm.debug=31.
Comment 2 Jens Ziller 2019-04-05 10:55:48 UTC 
Created attachment 143878 [details]
complete dmesg out

The added dmesg out is complete from boot. The warning during boot is new. I never see it before. v4l2-drm-test runs like before.
My code is on github. It's ugly code. Much things are hardcoded. It's only for testing.
https://github.com/zillevdr/v4l2-drm-test
Comment 3 andrzej.hajda 2019-04-16 13:43:04 UTC 
Looking at the code apparently you are setting V4L2_PIX_FMT_NV12MT_16X16 in MFC, but MIXER requires V4L2_PIX_FMT_NV12MT.
Comment 4 Jens Ziller 2019-04-17 07:12:25 UTC 
No, the ioctl there 
https://github.com/zillevdr/v4l2-drm-test/blob/master/v4l2.c#L150
looks what format MFC can use. This I set in line 155. The output from fprintf line 174:
FMT CAPTURE: width 1280 height 736 4cc TM12 num_planes 2

https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/yuv-formats.html say that TM12 is V4L2_PIX_FMT_NV12MT not V4L2_PIX_FMT_NV12MT_16X16. I think the right format is set.
Comment 5 andrzej.hajda 2019-04-18 08:31:15 UTC 
OK, it seems that the format is correct. HW registers also seems to be programmed correctly. Documentation is not helpful at all, at least for me [1]. The only guess I have is that tile format produced by MFC is different than format accepted by MIXER in regard of chroma. Unfortunately I am too busy now to investigate it deeper. Maybe next week I will be able to consult it with sbd more competent in the subject.

[1]: https://usermanual.wiki/Document/SECExynos4412Users20ManualVer10000.544818918.pdf
Comment 6 Martin Peres 2019-11-19 08:53:57 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/misc/issues/4.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.