All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Inki Dae <inki.dae@samsung.com>
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 10:42:18 +0200	[thread overview]
Message-ID: <20160825084218.GP10980@phenom.ffwll.local> (raw)
In-Reply-To: <57BEA71F.502@samsung.com>

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?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2016-08-25  8:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-22  9:44 [RFC 0/2] New feature: Framebuffer processors Marek Szyprowski
2016-08-22  9:44 ` [RFC 1/2] drm: add support for framebuffer processors Marek Szyprowski
2016-08-22  9:44 ` [RFC 2/2] drm/exynos: register rotator as fbproc instead of custom ipp framework Marek Szyprowski
2016-08-22  9:44 ` [RFC libdrm] add support for framebuffer processor (fbproc) objects Marek Szyprowski
2016-08-22  9:44 ` [RFC code example] example code for testing fbproc drivers Marek Szyprowski
2016-08-22  9:59 ` [RFC 0/2] New feature: Framebuffer processors Christian König
2016-08-22 14:59   ` Daniel Vetter
2016-08-22 15:23   ` Rob Clark
2016-08-22 15:30     ` Benjamin Gaignard
2016-08-23  9:41     ` Daniel Stone
2016-08-24 11:44       ` Inki Dae
2016-08-24 11:57         ` Daniel Vetter
2016-08-25  8:06           ` Inki Dae
2016-08-25  8:42             ` Daniel Vetter [this message]
2016-08-25 11:45               ` Inki Dae
2016-08-25 12:14                 ` Daniel Vetter
2016-08-30  5:52                   ` Inki Dae
2016-08-22 10:07 ` Tobias Jakobi
2016-08-22 10:50   ` Marek Szyprowski
2016-08-22 11:38     ` Tobias Jakobi
2016-08-22 20:05 ` Dave Airlie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160825084218.GP10980@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=b.zolnierkie@samsung.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=enrico.weigelt@gr13.net \
    --cc=inki.dae@samsung.com \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=sw0312.kim@samsung.com \
    --cc=tjakobi@math.uni-bielefeld.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.