linux-stable.git/include/drm/drm_atomic.h, branch linux-4.1.y

drm/atomic: fix out of bounds read in for_each_*_in_state helpers

2015-08-03T16:29:08+00:00

commit 60f207a5b6d8f23c2e8388b415e8d5c7311cc79d upstream.

for_each_*_in_state validate array index after
access to array elements, thus perform out of bounds read.

Fix this by validating index in the first place and read
array element iff validation was successful.

Fixes: df63b9994eaf ("drm/atomic: Add for_each_{connector,crtc,plane}_in_state helper macros")
Signed-off-by: Andrey Ryabinin 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/atomic: Add for_each_{connector,crtc,plane}_in_state helper macros

2015-04-11T16:50:22+00:00

This saves some typing whenever a iteration over all the connector,
crtc or plane states in the atomic state is written, which happens
quite often.

Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Ander Conselvan de Oliveira 
Signed-off-by: Daniel Vetter

drm/atomic: Hide drm.ko internal interfaces

2015-01-05T12:55:30+00:00

This is just a bit fallout from patch polishing and moving the
get_prop logic fully into the core:
- Drop EXPORT_SYMBOL and make the helpers static.
- Drop kerneldoc since not used by drivers.
- Move the cross-file function declarations only used by drm.ko
  internally to an internal header.

v2: keep the gist of the comments, requested by Rob.

Cc: Rob Clark 
Reviewed-by: Rob Clark 
Signed-off-by: Daniel Vetter

drm: add atomic properties

2015-01-05T12:54:38+00:00

Once a driver is using atomic helpers for modeset, the next step is to
switch over to atomic properties.  To do this, make sure that any
modeset objects have their ->atomic_{get,set}_property() vfuncs suitably
populated if they have custom properties (you did already remember to
plug in atomic-helper func for the legacy ->set_property() vfuncs,
right?), and then set DRIVER_ATOMIC bit in driver_features flag.

A new cap is introduced, DRM_CLIENT_CAP_ATOMIC, for the purposes of
shielding legacy userspace from atomic properties.  Mostly for the
benefit of legacy DDX drivers that do silly things like getting/setting
each property at startup (since some of the new atomic properties will
be able to trigger modeset).

Signed-off-by: Rob Clark 
[danvet: Squash in fixup patch to check for DRM_MODE_PROP_ATOMIC
instaed of the CAP define when filtering properties. Reported by
Tvrtko Uruslin, acked by Rob.]
Signed-off-by: Daniel Vetter

drm: add atomic_get_property

2014-12-18T21:22:46+00:00

Since we won't be using the obj->properties->values[] array to shadow
property values for atomic drivers, we are going to need a vfunc for
getting prop values.  Add that along w/ mandatory wrapper fxns.

v2: more comments and copypasta comment typo fix

Signed-off-by: Rob Clark 
Reviewed-by: Sean Paul 
Reviewed-by: Daniel Vetter 
Signed-off-by: Daniel Vetter

drm: add atomic_set_property wrappers

2014-12-18T21:22:39+00:00

As we add properties for all the standard plane/crtc/connector
attributes (in preperation for the atomic ioctl), we are going to want
to handle core state in core (rather than per driver).  Intercepting the
core properties will be easier if the atomic_set_property vfuncs are not
called directly, but instead have a mandatory wrapper function (which
will later serve as the point to intercept core properties).

v2: more verbose comments and copypasta comment fix

Signed-off-by: Rob Clark 
Reviewed-by: Sean Paul 
Reviewed-by: Daniel Vetter 
Signed-off-by: Daniel Vetter

drm/atomic: Introduce state->obj backpointers

2014-12-17T19:23:23+00:00

Useful since this way we can pass around just the state objects and
will get ther real object, too.

Specifically this allows us to again simplify the parameters for
set_crtc_for_plane.

v2: msm already has it's own specific plane_reset hook, don't forget
that one!

v3: Fixup kerneldoc, reported by 0-day builder.

Cc: Rob Clark 
Reviewed-by: Rob Clark  (v2)
Tested-by: Rob Clark  (v2)
Signed-off-by: Daniel Vetter

drm/atomic: track bitmask of planes attached to crtc

2014-11-27T14:38:15+00:00

Chasing plane->state->crtc of planes that are *not* part of the same
atomic update is racy, making it incredibly awkward (or impossible) to
do something simple like iterate over all planes and figure out which
ones are attached to a crtc.

Solve this by adding a bitmask of currently attached planes in the
crtc-state.

Note that the transitional helpers do not maintain the plane_mask.  But
they only support the legacy ioctls, which have sufficient brute-force
locking around plane updates that they can continue to loop over all
planes to see what is attached to a crtc the old way.

Signed-off-by: Rob Clark 
[danvet:
- Drop comments about locking in set_crtc_for_plane since they're a
  bit misleading - we already should hold lock for the current crtc.
- Also WARN_ON if get_state on the old crtc fails since that should
  have been done already.
- Squash in fixup to check get_plane_state return value, reported by
  Dan Carpenter and acked by Rob Clark.]
Signed-off-by: Daniel Vetter

drm: Make drm_atomic.h standalone includible

2014-11-25T12:28:25+00:00

This header file makes use of a bunch of structures declared in the
drm_crtc.h header file. Include that to make sure the drm_atomic.h
header can be included standalone.

Signed-off-by: Thierry Reding 
Signed-off-by: Daniel Vetter

drm/atomic: Refcounting for plane_state->fb

2014-11-06T20:08:37+00:00

So my original plan was that the drm core refcounts framebuffers like
with the legacy ioctls. But that doesn't work for a bunch of reasons:

- State objects might live longer than until the next fb change
  happens for a plane. For example delayed cleanup work only happens
  _after_ the pageflip ioctl has completed. So this definitely doesn't
  work without the plane state holding its own references.

- The other issue is transition from legacy to atomic implementations,
  where the driver works under a mix of both worlds. Which means
  legacy paths might not properly update the ->fb pointer under
  plane->state->fb. Which is a bit a problem when then someone comes
  around and _does_ try to clean it up when it's long gone.

The second issue is just a bit a transition bug, since drivers should
update plane->state->fb in all the paths that aren't converted yet.
But a bit more robustness for the transition can't hurt - we pull
similar tricks with cleaning up the old fb in the transitional helpers
already.

The pattern for drivers that transition is

	if (plane->state)
		drm_atomic_set_fb_for_plane(plane->state, plane->fb);

inserted after the fb update has logically completed at the end of
->set_config (or ->set_base/mode_set if using the crtc helpers),
->page_flip, ->update_plane or any other entry point which updates
plane->fb.

v2: Update kerneldoc - copypasta fail.

v3: Fix spelling in the commit message (Sean).

Reviewed-by: Sean Paul 
Signed-off-by: Daniel Vetter