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

[Joonyoung Shim <jy0922.shim@samsung.com>]

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.

Thanks.

> 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
> 
>