Re: drm/exynos: getting the video processor to work

[Tobias Jakobi <tjakobi@math.uni-bielefeld.de>]

Hello Inki and Joonyoung,

On 2015-04-22 08:02, Inki Dae wrote:
> On 2015년 04월 22일 10:55, Joonyoung Shim wrote:
>> Hi Tobias,
>> 
>> On 04/21/2015 06:30 AM, Tobias Jakobi wrote:
>>> Hello,
>>> 
>>> I've spend some time on figuring out how to use the VP on my 
>>> Exynos4412.
>>> I noticed that currently it seems to be pretty broken (I've put a 
>>> full
>>> crashlog with drm.debug=0xff at the end).
>>> 
>>> As far as I can see, the problem stems from conflicting buffer counts 
>>> in
>>> the driver.
>>> 
>>> Let's start with vp_video_buffer(), there buf_num gets set to '2' 
>>> when
>>> DRM_FORMAT_NV12 is encountered as pixelformat. Which results in the 
>>> VP
>>> reading luma data from the plane's dma_addr[0] and chroma from 
>>> dma_addr[1].
>>> 
>>> But dma_addr[1] is never correctly set. It should be set by
>>> exynos_check_plane(), but the loop only does one iteration since
>>> exynos_drm_fb_get_buf_cnt() returns 1.
>>> 
>>> Which is due to special case handling in
>>> exynos_drm_format_num_buffers(). At least for the buffers that 
>>> libdrm's
>>> modetest creates this case handling triggers and reduces buffer count 
>>> to
>>> '1'.
>>> 
>> 
>> This is just pixel format issue and mixer driver is not completed 
>> about
>> that. The exynos mixer can support two NV12 formats.
> 
> To clarify it, NV12 and other NVXX formats have only two planes.
That was also my impression. NV12 and NV21 are always bi-planar, with 
the only difference that NV21 has U/V order reversed (when comparing it 
to NV12). There is no uni-planar NV12/NV21. See also:
https://wiki.videolan.org/YUV#NV12.2FNV21


>> First, NV12 format having just one buffer(Y plane and CbCr plane use a
>> same buffer but differ their start index.)
> 
> So it is called packed YUV format and drm_fourcc header defines these
> formats as follows,
> 
> DRM_FORMAT_YUYV
> DRM_FORMAT_YVYU
> DRM_FORMAT_UYVY
> DRM_FORMAT_VYUY
> DRM_FORMAT_AYUV
I'd like to know if any other formats except for NV12/NV21 are really 
supported by the video processor? Because I don't see any indication for 
that. It's just NV12/NV21 and the tiled variants, which are there to 
make it easier to handle data from the MFC block.


>> Second, NV12 format having split two buffers(one is for Y plane, other
>> is for CbCr plane)
> 
> All NVXX formats should be considered only for separated two buffers.
Does is even make any difference for the VP if luma and chroma are in 
different buffers or in a single one, just with an offset between 
luma/chroma? I think not, because the VP just gets a dma_addr for both 
and then fetches data from that position.


>> Current mixer driver considers only second NV12 format, we can know it
>> from following comment in mixer driver.
>> 
>> /* TODO: single buffer format NV12, NV21 */
> 
> So, it seems like wrong comment. Until now, it seems that we have been
> calling the packed YUV format as NVXX format and calling the NVXX 
> format
> as NVXXM. And Exynos SoC have even NVXXMT whose format consists into
> many macro blocks and which has separated two buffers.
I think getting just regular (un-tiled) NV12/NV21 working should come 
first, then we can think about how to handle the tiled formats (probably 
with the newly introduced fb modifiers).

I've patched the mixer so that it passes valid pointers for luma/chroma 
but I still get a crash (sysmmu) sooner or later. So there seems to be 
more issues than just this pixelformat/buffercount one.



> We would need to make Exynos drivers suitable to fourcc.
> 
> Thanks,
> Inki Dae


With best wishes,
Tobias