Hello Joonyoung!
On 2015-04-23 01:57, Joonyoung Shim wrote:
Hi Tobias,
On 04/22/2015 11:56 PM, Tobias Jakobi wrote:
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.
I feel it is just each other different implementation issue, not right
and wrong. If you are interested, could you please make a patch to
support NV12 format(including NV12M)? Maybe will have to modify or
remove exynos_drm_format_num_buffers function and delivery each buffer
informations to mixer driver via struct exynos_drm_plane. I think it's
not difficult to do.
I'm going to take a look at this in the next days.
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
