linux-toradex.git/include/drm/drm_plane_helper.h, branch v4.9.8

drm/kms-helpers: Extract drm_modeset_helper.[hc]

2016-08-16T14:10:19+00:00

While reviewing docs I spotted that we have a few functions that
really just don't fit into their containing helper library section.
Extract them and shovel them all into a new library for random one-off
aux stuff.

v2: Remove wrongly added files for real.

Cc: Sean Paul 
Reviewed-by: Sean Paul 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-3-git-send-email-daniel.vetter@ffwll.ch

drm/plane-helper: Add drm_plane_helper_check_state()

2016-08-08T18:19:45+00:00

Add a version of drm_plane_helper_check_update() which takes a plane
state instead of having the caller pass in everything.

And to reduce code duplication, let's reimplement
drm_plane_helper_check_update() in terms of the new function, by
having a tempororary plane state on the stack.

v2: Add a note that the functions modifies the state (Chris)
v3: Fix drm_plane_helper_check_update() y coordinates (Daniel Kurtz)

Cc: Daniel Kurtz 
Cc: Chris Wilson 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Sean Paul  (v2)
Signed-off-by: Ville Syrjälä 
Signed-off-by: Sean Paul 
Link: http://patchwork.freedesktop.org/patch/msgid/1470642910-14073-1-git-send-email-ville.syrjala@linux.intel.com

drm: Deal with rotation in drm_plane_helper_check_update()

2016-06-17T14:41:25+00:00

drm_plane_helper_check_update() needs to account for the plane rotation
for correct clipping/scaling calculations. Do so.

There was an earlier attempt [1] to add this into
intel_check_primary_plane() but I requested that it'd be put into the
helper instead. An updated patch never materialized AFAICS, so I went
ahead and cooked one up myself.

v2: Deal with new drm_plane_helper_check_update() callers

[1] https://patchwork.freedesktop.org/patch/65177/
Cc: Nabendu Maiti 
Cc: Noralf Trønnes 
Cc: CK Hu 
Cc: Mark Yao 
Cc: Russell King 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Patrik Jakobsson 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1466172790-10025-1-git-send-email-ville.syrjala@linux.intel.com

drm: Reorganize helper vtables and their docs

2015-12-08T15:07:52+00:00

Currently we have 4 helper libraries (probe, crtc, plane & atomic)
that all use the same helper vtables. And that's by necessity since we
don't want to litter the core structs with one ops pointer per helper
library. Also often the reuse the same hooks (like atomic does, to
facilite conversion from existing drivers using crtc and plane
helpers).

Given all that it doesn't make sense to put the docs for these next to
specific helpers. Instead extract them into a new header file and
section in the docbook, and add references to them everywhere.

Unfortunately kernel-doc complains when an include directive doesn't
find anything (and it does by dumping crap into the output file). We
have to remove the now empty includes to avoid that, instead of leaving
them in for future proofing.

v2: More OCD in ordering functions.

v3: Spelling plus collate copyright headers properly.

Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-4-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Thierry Reding

drm/atomic: Make prepare_fb/cleanup_fb only take state, v3.

2015-09-08T11:45:54+00:00

This removes the need to separately track fb changes i915.
That will be done as a separate commit, however.

Changes since v1:
- Add dri-devel to cc.
- Fix a check in intel's prepare and cleanup fb to take rotation
  into account.
Changes since v2:
- Split out i915 changes to a separate commit.

Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst 
Reviewed-by: Daniel Stone 
[danvet: Squash in msm fixup from Maarten.]
Signed-off-by: Daniel Vetter

drm/plane: Remove redundant extern

2015-08-12T15:15:12+00:00

Use of the extern keyword for function prototypes is unnecessary, so it
can be removed.

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

drm: make crtc/encoder/connector/plane helper_private a const pointer

2015-04-13T13:00:13+00:00

They're only used to store const pointers anyway. This helps to keep
Ville and the compiler happy.

Signed-off-by: Jani Nikula 
Reviewed-by: Christian König 
Signed-off-by: Daniel Vetter

drm/plane-helper: unexport drm_primary_helper_create_plane

2015-03-10T08:59:35+00:00

We shouldn't tempt driver writers into using this since it uses a
default format list which is likely wrong. And when that's done we can
simplify the code a bit, too.

Noticed while reviewing a patch from Laurent.

Cc: Laurent Pinchart 
Cc: Matt Roper 
Reviewed-by: Matt Roper 
Signed-off-by: Daniel Vetter

drm: Pass in new and old plane state to prepare_fb and cleanup_fb

2015-03-04T23:49:02+00:00

Use cases like rotation require these hooks to have some context so they
know how to prepare and cleanup the frame buffer correctly.

For i915 specifically, object backing pages need to be mapped differently
for different rotation modes and the driver needs to know which mapping to
instantiate and which to tear down when transitioning between them.

v2: Made passed in states const. (Daniel Vetter)

[airlied: add mdp5 and atmel fixups]
Signed-off-by: Tvrtko Ursulin 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Rob Clark 
Signed-off-by: Dave Airlie

drm/plane: Add optional ->atomic_disable() callback

2015-01-27T09:14:42+00:00

In order to prevent drivers from having to perform the same checks over
and over again, add an optional ->atomic_disable callback which the core
calls under the right circumstances.

v2: pass old state and detect edges to avoid calling ->atomic_disable on
already disabled planes, remove redundant comment (Daniel Vetter)

v3: rename helper to drm_atomic_plane_disabling() to clarify that it is
checking for transitions, move helper to drm_atomic_helper.h, clarify
check for !old_state and its relation to transitional helpers

Here's an extract from some discussion rationalizing the behaviour (for
a full version, see the reference below):

    > > Hm, thinking about this some more this will result in a slight difference
    > > in behaviour, at least when drivers just use the helper ->reset functions
    > > but don't disable everything:
    > > - With transitional helpers we assume we know nothing and call
    > >   ->atomic_disable.
    > > - With atomic old_state->crtc == NULL in the same situation right after
    > >   boot-up, but we asssume the plane is really off and _dont_ call
    > >   ->atomic_disable.
    > >
    > > Should we instead check for (old_state && old_state->crtc) and state that
    > > drivers need to make sure they don't have stuff hanging around?
    >
    > I don't think we can check for old_state because otherwise this will
    > always return false, whereas we really want it to force-disable planes
    > that could be on (lacking any more accurate information). For
    > transitional helpers anyway.
    >
    > For the atomic helpers, old_state will never be NULL, but I'd assume
    > that the driver would reconstruct the current state in ->reset().

    By the way, the reason for why old_state can be NULL with transitional
    helpers is the ordering of the steps in the atomic transition. Currently
    the Tegra patches do this (based on your blog post and the Exynos proto-
    type):

        1) atomic conversion, phase 1:
           - implement ->atomic_{check,update,disable}()
           - use drm_plane_helper_{update,disable}()

        2) atomic conversion, phase 2:
           - call drm_mode_config_reset() from ->load()
           - implement ->reset()

    That's only a partial list of what's done in these steps, but that's the
    only relevant pieces for why old_state is NULL.

    What happens is that without ->reset() implemented there won't be any
    initial state, hence plane->state (the old_state here) will be NULL the
    first time atomic state is applied.

    We could of course reorder the sequence such that drivers are required
    to hook up ->reset() before they can (or at the same as they) hook up
    the transitional helpers. We could add an appropriate WARN_ON to this
    helper to make that more obvious.

    However, that will not solve the problem because it only gets rid of the
    special case. We still don't know whether old_state->crtc == NULL is the
    current state or just the initial default.

    So no matter which way we do this, I don't see a way to get away without
    requiring specific semantics from drivers. They would be that:

        - drivers recreate the correct state in ->reset() so that
          old_state->crtc != NULL if the plane is really enabled

    or

        - drivers have to ensure that the real state in fact mirrors the
          initial default as encoded in the state (plane disabled)

References: http://lists.freedesktop.org/archives/dri-devel/2015-January/075578.html
Reviewed-by: Daniel Vetter 
Reviewed-by: Gustavo Padovan 
Signed-off-by: Thierry Reding