[PATCH 00/16] Atomic/nuclear modeset/pageflip
Rob Clark
robdclark at gmail.com
Wed Mar 19 05:23:31 PDT 2014
On Wed, Mar 19, 2014 at 7:07 AM, Daniel Vetter <daniel at 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 at 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
More information about the dri-devel
mailing list