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

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

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