From: Daniel Vetter <daniel@ffwll.ch>
To: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: linux-samsung-soc@vger.kernel.org,
Gustavo Padovan <gustavo.padovan@collabora.co.uk>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 04/14] drm/exynos: remove struct *_win_data abstraction on planes
Date: Thu, 5 Feb 2015 10:15:14 +0100 [thread overview]
Message-ID: <20150205091514.GO14009@phenom.ffwll.local> (raw)
In-Reply-To: <54D2D759.3000709@samsung.com>
On Thu, Feb 05, 2015 at 11:37:13AM +0900, Joonyoung Shim wrote:
> Hi Daniel,
>
> On 02/04/2015 11:28 PM, Daniel Vetter wrote:
> > On Wed, Feb 04, 2015 at 04:44:12PM +0900, Joonyoung Shim wrote:
> >> Hi,
> >>
> >> On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
> >>> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> >>>
> >>> struct {fimd,mixer,vidi}_win_data was just keeping the same data
> >>> as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
> >>> directly.
> >>>
> >>> It changes how planes are created and remove .win_mode_set() callback
> >>> that was only filling all *_win_data structs.
> >>>
> >>
> >> I commented already on prior patch.
> >
> > I think you don't quite understand how this primary/overlay plane stuff
> > works in drm core. The entire point of the drm core primary plane is to
> > work _exactly_ like an overlay plane and allow userspace to mangle the
> > primary plane configuration through the overlay plane. The only reason we
> > have primary planes is so that old userspace keeps working.
> >
>
> Right, i misunderstood a bit because exynos hw drivers have dependency
> of zpos(hw overlay position).
>
> Current exynos drm driver has each primary plane of hw drivers and five
> overlay planes. The primary plane is fixed on default hw overlay and all
> overlay plane can map to all hw overlays using specific zpos property of
> exynos drm plane.
>
> Gustavo approach will include specific hw overlay data in overlay plane
> and hw driver keeps overlay planes to array by zpos order. But current
> zpos of overlay plane is 0 always if user doesn't modify it, so hw
> driver will use only hw overlay data of primary plane always even if
> user want to use overlay plane.
>
> If user is modified zpos of overlay plane, hw driver can get wrong hw
> overlay data from different overlay plane because hw driver keeps
> overlay planes by zpos order.
Yeah I noticed the zpos fun when hacking around too. Exynos should
probably switch defaults so that overlays are visible by default. And we
need to standardize the zpos property so that other drivers can use it
too.
But that doesn't change anything with the primary plane just being a
special plane from the sw side (backwards compat), for exynos hw they all
look the same.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-02-05 9:15 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-03 19:14 [PATCH 00/14] drm/exynos: cleanups + atomic phases 1 and 2 Gustavo Padovan
2015-02-03 19:14 ` [PATCH 01/14] drm/exynos: track vblank events on a per crtc basis Gustavo Padovan
2015-02-03 19:14 ` [PATCH 02/14] drm/exynos: Remove exynos_plane_dpms() call with no effect Gustavo Padovan
2015-02-04 7:42 ` Joonyoung Shim
2015-02-04 14:16 ` Daniel Vetter
2015-02-05 1:05 ` Joonyoung Shim
2015-02-05 9:03 ` Daniel Vetter
2015-02-03 19:14 ` [PATCH 03/14] drm/exynos: remove leftover functions declarations Gustavo Padovan
2015-02-03 19:14 ` [PATCH 04/14] drm/exynos: remove struct *_win_data abstraction on planes Gustavo Padovan
2015-02-04 7:44 ` Joonyoung Shim
2015-02-04 14:28 ` Daniel Vetter
2015-02-05 2:37 ` Joonyoung Shim
2015-02-05 9:15 ` Daniel Vetter [this message]
2015-02-05 12:26 ` Rob Clark
2015-02-05 12:48 ` Daniel Stone
2015-02-05 13:06 ` Daniel Vetter
2015-02-06 3:39 ` Joonyoung Shim
2015-02-03 19:14 ` [PATCH 05/14] drm/exynos: do not copy adjusted mode into mode during crtc mode_set Gustavo Padovan
2015-02-03 19:14 ` [PATCH 06/14] drm/exynos: atomic phase 1: use drm_plane_helper_update() Gustavo Padovan
2015-02-03 19:14 ` [PATCH 07/14] drm/exynos: atomic phase 1: use drm_plane_helper_disable() Gustavo Padovan
2015-02-04 7:47 ` Joonyoung Shim
2015-02-03 19:14 ` [PATCH 08/14] drm/exynos: atomic phase 1: add atomic_begin()/atomic_flush() Gustavo Padovan
2015-02-04 7:49 ` Joonyoung Shim
2015-02-04 14:30 ` Daniel Vetter
2015-02-05 2:48 ` Joonyoung Shim
2015-02-05 9:18 ` Daniel Vetter
2015-02-03 19:14 ` [PATCH 09/14] drm/exynos: atomic phase 1: add .mode_set_nofb() callback Gustavo Padovan
2015-02-04 7:51 ` Joonyoung Shim
2015-02-03 19:14 ` [PATCH 10/14] drm/exynos: atomic phase 2: wire up state reset(), duplicate() and destroy() Gustavo Padovan
2015-02-03 19:14 ` [PATCH 11/14] drm/exynos: atomic phase 2: keep track of framebuffer pointer Gustavo Padovan
2015-02-04 7:53 ` Joonyoung Shim
2015-02-04 14:33 ` Daniel Vetter
2015-02-03 19:14 ` [PATCH 12/14] drm/exynos: make exynos_plane_mode_set() static Gustavo Padovan
2015-02-03 19:14 ` [PATCH 13/14] drm/exynos: use correct pipe number on vblank event Gustavo Padovan
2015-02-03 19:14 ` [PATCH 14/14] drm/exynos: remove exynos_disable_plane() Gustavo Padovan
2015-02-04 7:37 ` [PATCH 00/14] drm/exynos: cleanups + atomic phases 1 and 2 Joonyoung Shim
2015-02-04 14:35 ` Daniel Vetter
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=20150205091514.GO14009@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavo.padovan@collabora.co.uk \
--cc=jy0922.shim@samsung.com \
--cc=linux-samsung-soc@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox