On Wed, Mar 19, 2014 at 7:07 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Tue, Mar 18, 2014 at 05:22:37PM -0400, Rob Clark wrote:
Previous revision of series: http://lists.freedesktop.org/archives/dri-devel/2013-November/049594.html
And if you prefer, in git form: http://cgit.freedesktop.org/~robclark/linux/log/?h=cold-fusion git://people.freedesktop.org/~robclark/linux cold-fusion
Compared to previous revision:
rebased on primary-plane RFC series. As a result, nearly none of the drivers actually compile at the moment :-P
But it is in the end a good thing... it reduces some code paths (now only having to care about fbs on planes, and it avoids exposing an intermediate ABI state to userspace so avoids the need for some compat glue later).
state objects now carry their own ref to fbs. This cleaned up most of the refcnt'ing issues, so I'm pretty happy how that turned out. With that plus all the other major hacks cleaned up, I'm happy enough to drop the "RFC" tag.
There are, I think, two remaining issues to solve:
we either need to add an event ptr param to plane->update_plane() or come up with another way to handle events on planes.
I kinda would still like to add to the atomic ioctl some way to indicate ok/error on a bit finer granularity than per-ioctl. Ie. perhaps an array where userspace can ask for results per KMS object (crtc/plane)? Something along these lines would give the kernel a bit more flexibility to deal with some of the edge cases which come up when you gang crtcs for ultra high resolution displays. In short, it would let the driver "steal" some of the planes if needed from userspace.
This would also, conveniently, be pretty similar to how (AFAIU) hw compositor and ADF work on android. Which seems like it would be useful to eventually enable android devices to use an upstream display driver.
For this we could pretty easily just throw in a placeholder that we could replace later with an optional ptr to __user array. I think that would be fine for an initial version, but I just wanted to throw this idea out there, because I think it will become important.
Hm, do you have some pointers to read up on this? I still think a more elaborate fail scheme is overkill, but maybe reading a bit of android code convinces me differently ;-)
sadly no pointers to anything to read (but ofc would be interested if anyone else does)..
Mostly it comes out of thinking through what I'll need to support ultra-wide displays.. the hw seems to have support for doubling up pipes into blenders (planes into crtcs) as well as blenders into encoders. And afaiu, I get to deal with one hw generation which needs me to use two pipes if an overlay spans the middle of the screen, while a later generation only needs double-wide pipes for overlays beyond a certain width.
The sanest way I can think to deal with this is if the kernel has a way to tell userspace that it can do certain layers in the requested overlay config but needs other layers to fall back to gpu compositing. Without something like this, every frame will just fall back to 100% gpu composition, which really isn't the desired result.
Note that this series is really only the beginning of atomic. Once this is merged, there are some various vague thoughts about next steps:
finish converting remaining callers of drm_mode_set_config_internal() to use atomic
replace driver usage of plane->fb with plane->state->fb.. drop plane->fb, somewhere along the way deprecate/drop ->page_flip() and possibly current incarnation of ->update_plane()..
perhaps some more fine grained event notification or other such extensions.
I know there are a few things I plan on ripping out / simplifying in drm/msm as a result of atomic, but just waiting until this is merge to avoid carrying such
.......
So, that all said, I am a bit curious about how we might eventually land this series some day. Especially once we include changes to update all points in various drivers that access crtc->fb to crtc->primary->fb it will be one big hairy merge-conflict-prone branch. Not the sort of thing that I'd really like to have to rebase for the next five kernel cycles if at all avoidable.
We certainly could merge everything but the new ioctl, or hide the ioctl behind an experimental module param for now. I'm less concerned about that (either option would be pretty easy), and more about merging the infrastructure changes.
On the i915 side I think all the various pieces we need are finally coming together, and I hope a lot of that goes in for 3.16. So I think we can soonish jump on board with providing real proof-of-concepts based on your ioctl.
For merging the core stuff I think we should concentrate first on getting Matt's universal planes stuff in asap. I've scanned through his series with a cursory look and atm it has a few change-the-world flag days. I'll try to do an in-depth review later on looking for ways to make the transition smoother. cursor planes seem to be the main culprit in this ...
it would be nice if there was a way to get things merged sooner than 3.18 or so.. but we do need at least the *initial* primary plane work first.
Some of the stuff like cursor planes should really happen independently from atomic. And maybe at the same time we want to expose cursor properties, or at least somehow property-ify cursors. The part that really needs to be in before atomic is the crtc->primary->fb bit.
Everything else should be doable by shoveling helper code into the existing drm functions to handle primary and cursor planes without any invasive driver changes. With the exception of the crtc->fb to crtc->primary->fb transition maybe. But since that's a pure sed job it should be doable (cocinelle job maybe).
For merging the actual atomic stuff I wonder a bit whether we shouldn't make this fully opt-in. Atomic without driver support is a bit pointless after all ;-) Of course we need to hide the thing behind a module option and maybe do a add_tain(TAINT_CRAP); in the ioctl. Then we can throw the switch once we have a few drivers ported and userspace ready and all tested.
yeah, some combination of module param and possibly a driver cap flag would be reasonable.
fwiw I had even initially thought about entirely keeping the legacy .page_flip()/.update_plane()/etc codepaths in place to even make the new atomic infrastructure opt-in, but it started getting pretty ugly before I killed off that idea.
BR, -R
-Daniel
Rob Clark (13): drm: fix typo drm: add atomic fxns drm: convert crtc to ww_mutex drm: add object property type drm: add signed-range property type drm: helpers to find mode objects drm: split propvals out and blob property support drm: allow FB's in drm_mode_object_find drm: convert plane to properties/state drm: convert crtc to properties/state drm: push locking down into restore_fbdev_mode drm/msm: add atomic support drm: spiff out FB refcnting traces
Ville Syrjälä (3): drm: Allow drm_mode_object_find() to look up an object of any type drm: Refactor object property check code drm: Atomic modeset ioctl
drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/armada/armada_crtc.c | 15 +- drivers/gpu/drm/armada/armada_fbdev.c | 4 +- drivers/gpu/drm/armada/armada_output.c | 3 +- drivers/gpu/drm/armada/armada_overlay.c | 15 +- drivers/gpu/drm/ast/ast_drv.c | 6 + drivers/gpu/drm/ast/ast_drv.h | 1 + drivers/gpu/drm/ast/ast_mode.c | 1 + drivers/gpu/drm/cirrus/cirrus_drv.c | 6 + drivers/gpu/drm/cirrus/cirrus_drv.h | 1 + drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + drivers/gpu/drm/drm_atomic.c | 702 +++++++++++ drivers/gpu/drm/drm_crtc.c | 1667 +++++++++++++++++++-------- drivers/gpu/drm/drm_crtc_helper.c | 2 +- drivers/gpu/drm/drm_drv.c | 1 + drivers/gpu/drm/drm_fb_cma_helper.c | 9 +- drivers/gpu/drm/drm_fb_helper.c | 28 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 11 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 7 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 +- drivers/gpu/drm/gma500/cdv_intel_crt.c | 4 +- drivers/gpu/drm/gma500/cdv_intel_display.c | 1 + drivers/gpu/drm/gma500/cdv_intel_dp.c | 7 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 7 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 10 +- drivers/gpu/drm/gma500/mdfld_dsi_output.c | 12 +- drivers/gpu/drm/gma500/psb_drv.c | 11 +- drivers/gpu/drm/gma500/psb_drv.h | 1 + drivers/gpu/drm/gma500/psb_intel_display.c | 1 + drivers/gpu/drm/gma500/psb_intel_drv.h | 4 +- drivers/gpu/drm/gma500/psb_intel_lvds.c | 10 +- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 23 +- drivers/gpu/drm/i2c/ch7006_drv.c | 4 +- drivers/gpu/drm/i915/i915_drv.c | 8 + drivers/gpu/drm/i915/intel_crt.c | 4 +- drivers/gpu/drm/i915/intel_display.c | 16 +- drivers/gpu/drm/i915/intel_dp.c | 7 +- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_fbdev.c | 6 +- drivers/gpu/drm/i915/intel_hdmi.c | 7 +- drivers/gpu/drm/i915/intel_lvds.c | 4 +- drivers/gpu/drm/i915/intel_sdvo.c | 23 +- drivers/gpu/drm/i915/intel_sprite.c | 1 + drivers/gpu/drm/i915/intel_tv.c | 11 +- drivers/gpu/drm/mgag200/mgag200_drv.c | 7 + drivers/gpu/drm/mgag200/mgag200_drv.h | 1 + drivers/gpu/drm/mgag200/mgag200_mode.c | 1 + drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 69 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 6 + drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 1 + drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 15 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 66 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 6 + drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 2 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 15 +- drivers/gpu/drm/msm/msm_atomic.c | 141 +++ drivers/gpu/drm/msm/msm_drv.c | 33 +- drivers/gpu/drm/msm/msm_drv.h | 8 + drivers/gpu/drm/msm/msm_gem.c | 24 +- drivers/gpu/drm/msm/msm_gem.h | 13 + drivers/gpu/drm/msm/msm_kms.h | 1 + drivers/gpu/drm/nouveau/dispnv04/crtc.c | 1 + drivers/gpu/drm/nouveau/dispnv04/overlay.c | 14 +- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 3 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 7 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 7 + drivers/gpu/drm/nouveau/nouveau_drm.h | 1 + drivers/gpu/drm/nouveau/nv50_display.c | 1 + drivers/gpu/drm/omapdrm/omap_crtc.c | 27 +- drivers/gpu/drm/omapdrm/omap_drv.c | 16 +- drivers/gpu/drm/omapdrm/omap_drv.h | 5 +- drivers/gpu/drm/omapdrm/omap_plane.c | 11 +- drivers/gpu/drm/qxl/qxl_display.c | 6 +- drivers/gpu/drm/qxl/qxl_drv.c | 9 + drivers/gpu/drm/radeon/radeon_connectors.c | 9 +- drivers/gpu/drm/radeon/radeon_display.c | 2 + drivers/gpu/drm/radeon/radeon_drv.c | 9 + drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 + drivers/gpu/drm/rcar-du/rcar_du_drv.c | 7 + drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 3 +- drivers/gpu/drm/rcar-du/rcar_du_plane.c | 12 +- drivers/gpu/drm/rcar-du/rcar_du_vgacon.c | 3 +- drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 6 +- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 7 + drivers/gpu/drm/shmobile/shmob_drm_plane.c | 2 + drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 1 + drivers/gpu/drm/tilcdc/tilcdc_drv.c | 6 + drivers/gpu/drm/tilcdc/tilcdc_drv.h | 1 + drivers/gpu/drm/tilcdc/tilcdc_slave.c | 3 +- drivers/gpu/drm/udl/udl_connector.c | 6 +- drivers/gpu/drm/udl/udl_drv.c | 8 + drivers/gpu/drm/udl/udl_modeset.c | 2 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 7 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 + include/drm/drmP.h | 88 +- include/drm/drm_atomic.h | 172 +++ include/drm/drm_crtc.h | 379 +++++- include/drm/drm_fb_helper.h | 3 +- include/uapi/drm/drm.h | 12 + include/uapi/drm/drm_mode.h | 38 + 106 files changed, 3214 insertions(+), 792 deletions(-) create mode 100644 drivers/gpu/drm/drm_atomic.c create mode 100644 drivers/gpu/drm/msm/msm_atomic.c create mode 100644 include/drm/drm_atomic.h
-- 1.8.5.3
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch