Hi Tobias, On 2015년 04월 22일 21:23, Tobias Jakobi wrote: > 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 Right. However, there is a case that we should consider for Exynos SoC. Exynos SoC has a Hardware video codec which is called MFC. This hardware can use a special function for improving decoding and encoding performance, which makes it possible for Y and CbCr data are placed in separated memory banks. So for this, a V4L2 guy of Samsung added a new format - NV12M - to v4l2 fourcc header. AFAIK, the pixels of NV12 format would consist into, yyyyyyyyyy yyyyyyyyyy uvuvuvuvu The memory region of each data - y or uv - is continuous each other. In this case, the base address of each gem buffer is same. On the other hand, the pixels of NV12M consist into, yyyyyyyyyy yyyyyyyyyy ................. uvuvuvuvu The memory region of each data - y or uv - isn't continuous each other. So Exynos driver identifies image format according to two cases above. In this case, the base address of each gem buffer is different. For more information, refer to exynos_drm_format_num_buffers function. > > >>> 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 First, above my comment was wrong. For this, I sent email again. Anyway, only NV12/NV21 + NV12/21 tiled are supported - this format contains macro blocks, which is specific to MFC (Hardware Video codec for Exynos SoC). However, we should consider NV12M format as I mentioned above. > 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). Already commented above. Thanks, Inki Dae > > 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
 |