Re: [RFC 0/2] New feature: Framebuffer processors

From: Inki Dae <inki.dae@samsung.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "moderated list:ARM/S5P EXYNOS AR..."
	<linux-samsung-soc@vger.kernel.org>,
	"Enrico Weigelt" <enrico.weigelt@gr13.net>,
	"Bartlomiej Zolnierkiewicz" <b.zolnierkie@samsung.com>,
	"Seung-Woo Kim" <sw0312.kim@samsung.com>,
	"Tobias Jakobi" <tjakobi@math.uni-bielefeld.de>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>
Subject: Re: [RFC 0/2] New feature: Framebuffer processors
Date: Thu, 25 Aug 2016 20:45:25 +0900	[thread overview]
Message-ID: <57BEDA55.9020605@samsung.com> (raw)
In-Reply-To: <20160825084218.GP10980@phenom.ffwll.local>

2016년 08월 25일 17:42에 Daniel Vetter 이(가) 쓴 글:
> On Thu, Aug 25, 2016 at 05:06:55PM +0900, Inki Dae wrote:
>>
>>
>> 2016년 08월 24일 20:57에 Daniel Vetter 이(가) 쓴 글:
>>> On Wed, Aug 24, 2016 at 08:44:24PM +0900, Inki Dae wrote:
>>>> Hi,
>>>>
>>>> 2016년 08월 23일 18:41에 Daniel Stone 이(가) 쓴 글:
>>>>> Hi,
>>>>>
>>>>> On 22 August 2016 at 16:23, Rob Clark <robdclark@gmail.com> wrote:
>>>>>> I guess a lot comes down to 'how long before hw designers bolt a CP to
>>>>>> the thing'..  at that point, I think you especially don't want a
>>>>>> per-blit kernel interface.
>>>>>
>>>>> Regardless of whether or not we want it, we already _have_ it, in the
>>>>> form of V4L2 M2M. There are already a few IP blocks working on that, I
>>>>> believe. If V4L2 <-> KMS interop is painful, well, we need to fix that
>>>>> anyway ...
>>>>
>>>> So we are trying this. We had expereneced using V4L2 and DRM together on
>>>> Linux Platform makes it too complicated, and also integrated DRM with
>>>> M2M such as 2D and Post processor makes it simplified.  So We have been
>>>> trying to move existing V4L2 based drivers into DRM excepting HW Video
>>>> Codec - called it MFC - and Camera sensor and relevant things.
>>>> I think now V4L2 and DRM frameworks may make many engineers confusing
>>>> because there are the same devices which can be controlled by V4L2 and
>>>> DRM frameworks - maybe we would need more efforts like Laurent did with
>>>> Live source[1] in the future.
>>>
>>> Can you pls explain in more detail where working with both v4l and drm
>>> drivers and making them cooperate using dma-bufs poses problems? We should
>>> definitely fix that.
>>
>> I think it would be most Linux Platforms - Android, Chrome and Tizen -
>> which would use OpenMAX/GStreammer for Multimedia and X or
>> Wayland/SurfaceFlinger for Display.
> 
> Yes, that's the use case. Where is the problem in making this happen? v4l
> can import dma-bufs, drm can export them, and there's plenty devices
> shipping (afaik) that make use of exact this pipeline. Can you pls explain
> what problem you've hit trying to make this work on exynos?

No problem but just make it complicated as I mentioned above - the stream operations - S_FMT, REQBUF, QUARYBUF, QBUF, STREAM ON and DQBUF of V4L2 would never be simple as DRM.
Do you think M2M device should be controlled by V4L2 interfaces? and even 2D accelerator? As long as I know, The Graphics card on Desktop has all devices such as 2D/3D GPU, HW Video codec and Display controller, and these devices are controlled by DRM interfaces. So we - ARM Exynos - are trying to move these things to DRM world and also trying to implement more convenient interfaces like Marek did.

Thanks,
Inki Dae

> -Daniel
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel