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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
