Hello Inki,
On 2015-04-22 16:26, Inki Dae wrote:
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.
I don't see how this is relevant here. The VP doesn't gain anything from
the fact that it can pull data from different memory banks. It's just
the MFC that benefits from that.
Why does the VP need to know whether the data is NV12 or NV12M? When we
get this data from userspace, then in the case of NV12 we always get two
planes (yielding two handles, two pitches, two offsets). The VP then
gets configured with two dma_addr, one for luma plane, one for chroma.
If luma and chroma are contiguous in memory doesn't make any difference
here.
Correct me if I'm wrong, but I think this whole NV12/NV12M business is
strictly related to the video decoding / v4l2 side.
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.
Thanks for the confirmation, but as I said above, I don't see why we
should consider NV12M for the DRM / presentation side.
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
