From: Daniel Vetter <daniel@ffwll.ch>
To: Jyri Sarha <jsarha@ti.com>
Cc: dri-devel@lists.freedesktop.org,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
laurent.pinchart@ideasonboard.com
Subject: Re: [PATCH RFC 00/11] drm/tilcdc: Atomic modeset support
Date: Tue, 10 May 2016 08:34:56 +0200 [thread overview]
Message-ID: <20160510063456.GD27098@phenom.ffwll.local> (raw)
In-Reply-To: <57310133.2000906@ti.com>
On Tue, May 10, 2016 at 12:29:23AM +0300, Jyri Sarha wrote:
> On 05/09/16 17:42, Daniel Vetter wrote:
> >> > It's not clear to me if a (primary) plane is required with atomic
> >> > universal planes and modesetting or not... I guess it is, when thinking
> >> > of how e.g. a framebuffer is configured to be shown on a screen when
> >> > using the atomic modesetting uapi.
> > You need a primary plane, but atomic doesn't require that it's enabled.
> > Which this simple display controller probably wont like, so seems like
> > this implementation of a primary plane is a bit too simple. You also need
>
> So I do what I can, by checking in crtc check that the plane is part of
> the new state. What more should I do?g
>
> > a real plane for the cursor, if you want to support that with atomic.
> >
>
> Well, there is no such thing in LCDC.
>
> >> > But if it is required, it makes me wonder, are there other HWs out there
> >> > without any planes? The dummy plane implementation you added is not
> >> > complex, but is it something that should be implemented with DRM helper
> >> > funcs?
> > There's a drm_simple_display_pipe floating around which seems perfectly
> > suited to tilcdc. It's meant for the case where you have 1 plane, 1 crtc
> > and 1 encoder maybe linking to different connectors. And it takes care of
> > all the small bits for you, with a grand total of 5 callbacks, all of them
> > optional.
> >
> > Might indeed be useful to rebase tilcdc on top of that, should be possible
> > to nuke piles of code.
>
>
> Looks interesting. Does it look like it is getting ready to be merged soon?
Should be landind soon, yes. Probably not for 4.7, that's closed now, but
I can still pick it up into drm-misc right away when it's ready. Open
review comments are all just small things, you could pick the latest
version to start prototyping a conversion and there shouldn't be any
surprises when you rebase onto the merged version.
-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
next prev parent reply other threads:[~2016-05-10 6:34 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-11 16:46 [PATCH RFC 00/11] drm/tilcdc: Atomic modeset support Jyri Sarha
2016-04-11 16:46 ` [PATCH RFC 01/11] drm/tilcdc: Make tilcdc_crtc_page_flip() public Jyri Sarha
2016-04-11 16:46 ` [PATCH RFC 02/11] drm/tilcdc: Add dummy primary plane implementation Jyri Sarha
2016-04-11 16:46 ` [PATCH RFC 03/11] drm/tilcdc: Initialize dummy primary plane from crtc init Jyri Sarha
2016-04-11 16:46 ` [PATCH RFC 04/11] drm/tilcdc: Add tilcdc_crtc_mode_set_nofb() Jyri Sarha
2016-04-12 16:13 ` Daniel Vetter
2016-04-11 16:46 ` [PATCH RFC 05/11] drm/tilcdc: Add tilcdc_crtc_atomic_check() Jyri Sarha
2016-04-11 16:46 ` [PATCH RFC 06/11] drm/tilcdc: Add atomic mode config funcs Jyri Sarha
2016-04-11 16:46 ` [PATCH RFC 07/11] drm/tilcdc: Add drm_mode_config_reset() call to tilcdc_load() Jyri Sarha
2016-04-11 16:46 ` [PATCH RFC 08/11] drm/tilcdc: Call drm_crtc_vblank_off() in tilcdc_crtc_destroy() Jyri Sarha
2016-04-11 16:46 ` [PATCH RFC 09/11] drm/tilcdc: Set DRIVER_ATOMIC and use atomic crtc helpers Jyri Sarha
2016-04-12 7:41 ` Jyri Sarha
2016-04-11 16:46 ` [PATCH RFC 10/11] drm/tilcdc: Remove obsolete crtc helper functions Jyri Sarha
2016-04-11 16:46 ` [PATCH RFC 11/11] drm/tilcdc: Remove tilcdc_verify_fb() Jyri Sarha
2016-05-09 14:10 ` [PATCH RFC 00/11] drm/tilcdc: Atomic modeset support Tomi Valkeinen
2016-05-09 14:42 ` Daniel Vetter
2016-05-09 21:29 ` Jyri Sarha
2016-05-10 6:34 ` Daniel Vetter [this message]
2016-05-10 9:14 ` Jyri Sarha
2016-05-10 14:04 ` Noralf Trønnes
2016-05-10 14:18 ` Daniel Vetter
2016-05-10 15:11 ` Laurent Pinchart
2016-05-10 16:08 ` Daniel Vetter
2016-05-10 17:30 ` Noralf Trønnes
2016-05-10 22:31 ` Daniel Vetter
2016-05-10 6:36 ` Daniel Vetter
2016-05-09 21:16 ` Jyri Sarha
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=20160510063456.GD27098@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jsarha@ti.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=tomi.valkeinen@ti.com \
/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