Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 16 8月, 2016 1 次提交
  3. 09 8月, 2016 2 次提交
  5. 17 6月, 2016 1 次提交
  7. 02 6月, 2016 1 次提交
    • D
      drm/doc: Appease sphinx · 2e7a5701
      由 Daniel Vetter 提交于 
      Mostly this is unexpected indents. But really it's just a
demonstration for my patch, all these issues have been found&fixed
using the correct source file and line number support I just added.
All line numbers have been perfectly accurate.

One issue looked a bit fishy in intel_lrc.c, where I don't quite grok
what sphinx is unhappy about. But since that file looks like it has
never seen a proper kernel-doc parser I figured better to fix in a
separate path.

v2: Use fancy new &drm_device->struct_mutex linking (Jani).

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      2e7a5701
  9. 11 12月, 2015 2 次提交
    • V
      drm: Pass 'name' to drm_universal_plane_init() · b0b3b795
      由 Ville Syrjälä 提交于 
      Done with coccinelle for the most part. It choked on
msm/mdp/mdp5/mdp5_plane.c like so:
"BAD:!!!!!  enum drm_plane_type type;"
No idea how to deal with that, so I just fixed that up
by hand.

Also it thinks '...' is part of the semantic patch, so I put an
'int DOTDOTDOT' placeholder in its place and got rid of it with
sed afterwards.

I didn't convert drm_plane_init() since passing the varargs through
would mean either cpp macros or va_list, and I figured we don't
care about these legacy functions enough to warrant the extra pain.

@@
typedef uint32_t;
identifier dev, plane, possible_crtcs, funcs, formats, format_count, type;
@@
 int drm_universal_plane_init(struct drm_device *dev,
                              struct drm_plane *plane,
                              unsigned long possible_crtcs,
                              const struct drm_plane_funcs *funcs,
                              const uint32_t *formats,
                              unsigned int format_count,
                              enum drm_plane_type type
+                             ,const char *name, int DOTDOTDOT
                              )
{ ... }

@@
identifier dev, plane, possible_crtcs, funcs, formats, format_count, type;
@@
 int drm_universal_plane_init(struct drm_device *dev,
                              struct drm_plane *plane,
                              unsigned long possible_crtcs,
                              const struct drm_plane_funcs *funcs,
                              const uint32_t *formats,
                              unsigned int format_count,
                              enum drm_plane_type type
+                             ,const char *name, int DOTDOTDOT
                              );

@@
expression E1, E2, E3, E4, E5, E6, E7;
@@
 drm_universal_plane_init(E1, E2, E3, E4, E5, E6, E7
+                         ,NULL
                          )

v2: Split crtc and plane changes apart
    Pass NUL for no-name instead of ""
    Leave drm_plane_init() alone
v3: Add ', or NULL...' to @name kernel doc (Jani)
    Annotate the function with __printf() attribute (Jani)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449670795-2853-1-git-send-email-ville.syrjala@linux.intel.com
      b0b3b795
    • V
      drm: Pass 'name' to drm_crtc_init_with_planes() · f9882876
      由 Ville Syrjälä 提交于 
      Done with coccinelle for the most part. However, it thinks '...' is
part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder
in its place and got rid of it with sed afterwards.

I didn't convert drm_crtc_init() since passing the varargs through
would mean either cpp macros or va_list, and I figured we don't
care about these legacy functions enough to warrant the extra pain.

@@
identifier dev, crtc, primary, cursor, funcs;
@@
 int drm_crtc_init_with_planes(struct drm_device *dev,
                               struct drm_crtc *crtc,
                               struct drm_plane *primary, struct drm_plane *cursor,
                               const struct drm_crtc_funcs *funcs
+                              ,const char *name, int DOTDOTDOT
                               )
{ ... }

@@
identifier dev, crtc, primary, cursor, funcs;
@@
 int drm_crtc_init_with_planes(struct drm_device *dev,
                               struct drm_crtc *crtc,
                               struct drm_plane *primary, struct drm_plane *cursor,
                               const struct drm_crtc_funcs *funcs
+                              ,const char *name, int DOTDOTDOT
                               );

@@
expression E1, E2, E3, E4, E5;
@@
 drm_crtc_init_with_planes(E1, E2, E3, E4, E5
+                          ,NULL
                           )

v2: Split crtc and plane changes apart
    Pass NULL for no-name instead of ""
    Leave drm_crtc_init() alone
v3: Add ', or NULL...' to @name kernel doc (Jani)
    Annotate the function with __printf() attribute (Jani)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449670771-2751-1-git-send-email-ville.syrjala@linux.intel.com
      f9882876
  11. 08 12月, 2015 1 次提交
    • D
      drm: Reorganize helper vtables and their docs · 092d01da
      由 Daniel Vetter 提交于 
      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: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-4-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>
      092d01da
  13. 24 11月, 2015 1 次提交
  15. 08 9月, 2015 1 次提交
  17. 27 7月, 2015 1 次提交
  19. 22 7月, 2015 1 次提交
    • D
      drm: Roll out drm_for_each_connector more · 9a9f5ce8
      由 Daniel Vetter 提交于 
      Now that we also grab the connection_mutex and so fixed the race with
atomic modeset we can use the iterator there too.

The other special case is drm_connector_unplug_all which would have a
locking inversion with the sysfs store/show functions if we'd grab the
mode_config.mutex around the unplug. We could just grab
connection_mutex instead, but that's a bit too much a dirty trick for
my taste. Also it's only used by udl, which doesn't do any other kind
of connector hotplugging, so should be race-free. Hence just stick
with a comment for now.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      9a9f5ce8
  21. 03 7月, 2015 1 次提交
  23. 22 5月, 2015 1 次提交
  25. 08 4月, 2015 1 次提交
  27. 11 3月, 2015 1 次提交
    • D
      drm/plane-helper: Fixup mismerge · 967667fd
      由 Daniel Vetter 提交于 
      I somehow manage to screw up applying Laurent's patch in eca93e28c256:
"drm: Check in setcrtc if the primary plane supports the fb pixel
format". It was a conflict with

commit 3461b30b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Mar 5 10:32:44 2015 +0100

    drm/plane-helper: unexport drm_primary_helper_create_plane

and I just didn't check that the solution from wiggle made sense.

Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: laurent.pinchart@ideasonboard.com
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: laurent.pinchart@ideasonboard.com
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      967667fd
  29. 10 3月, 2015 2 次提交
  31. 05 3月, 2015 1 次提交
  33. 27 1月, 2015 1 次提交
    • T
      drm/plane: Add optional ->atomic_disable() callback · 407b8bd9
      由 Thierry Reding 提交于 
      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.htmlReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NThierry Reding <treding@nvidia.com>
      407b8bd9
  35. 26 1月, 2015 2 次提交
  37. 18 12月, 2014 1 次提交
    • D
      drm/atomic: Introduce state->obj backpointers · 07cc0ef6
      由 Daniel Vetter 提交于 
      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 <robdclark@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com> (v2)
Tested-by: Rob Clark <robdclark@gmail.com> (v2)
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      07cc0ef6
  39. 11 12月, 2014 1 次提交
  41. 25 11月, 2014 1 次提交
  43. 07 11月, 2014 2 次提交
    • D
      drm/atomic: Refcounting for plane_state->fb · 321ebf04
      由 Daniel Vetter 提交于 
      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: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      321ebf04
    • D
      drm: Docbook integration and over sections for all the new helpers · 3150c7d0
      由 Daniel Vetter 提交于 
      In all cases the text requires that new drivers are converted to the
atomic interfaces.

v2: Add overview for state handling.

v3: Review from Sean: Some spelling fixes and drop the misguided
hunk to remove rgba8888 from the plane helpers compat list.

Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3150c7d0
  45. 06 11月, 2014 2 次提交
    • D
      drm/crtc-helper: Transitional functions using atomic plane helpers · 2f324b42
      由 Daniel Vetter 提交于 
      These two functions allow drivers to reuse their atomic plane helpers
functions for the primary plane to implement the interfaces required
by the crtc helpers for the legacy ->set_config callback.

This is purely transitional and won't be used once the driver is fully
converted. But it allows partial conversions to the atomic plane
helpers which are functional.

v2:
- Use ->atomic_duplicate_state if available.
- Don't forget to run crtc_funcs->atomic_check.

v3: Shift source coordinates correctly for 16.16 fixed point.

v4: Don't forget to call ->atomic_destroy_state if available.

v5: Fixup kerneldoc.

v6: Reuse the plane_commit function from the transitional plane
helpers to avoid too much duplication.

v7:
- Remove some stale comment.
- Correctly handle the lack of plane->state object, necessary for
  transitional use.

v8: Fixup an embarrassing h/vdisplay mixup.
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2f324b42
    • D
      drm/plane-helper: transitional atomic plane helpers · acf24a39
      由 Daniel Vetter 提交于 
      Converting a driver to the atomic interface can be a daunting
undertaking. One of the prerequisites is to have full universal planes
support.

To make that transition a bit easier this patch provides plane helpers
which use the new atomic helper callbacks just only for the plane
changes. This way the plane update functionality can be tested without
being forced to convert everything at once.

Of course a real atomic update capable driver will implement the
all plane properties through the atomic interface, so these helpers
are mostly transitional. But they can be used to enable proper
universal plane support, especially once the crtc helpers have also
been adapted.

v2: Use ->atomic_duplicate_state if available.

v3: Don't forget to call ->atomic_destroy_state if available.

v4: Fixup kerneldoc, reported by Paulo.

v5: Extract a common plane_commit helper and fix some bugs in the
plane_state setup of the plane_disable implementation.

v6: Fix issues with the cleanup of the old fb. Since transitional
helpers can be mixed we need to assume that the old fb has been set up
by a legacy path (e.g. set_config or page_flip when the primary plane
is converted to use these functions already). Hence pass an additional
old_fb parameter to plane_commit to do that cleanup work correctly.

v7:
- Fix spurious WARNING (crtc helpers really love to disable stuff
  harder) and fix array index bonghits.
- Correctly handle the lack of plane->state object, necessary for
  transitional use.
- Don't indicate failure if drm_vblank_get doesn't work - that's
  expected when the pipe is in dpms off mode.

v8: Review from Sean:
- s/fail/out/ to make the meaning of a label more clear.
- spelling fix in the commit message.

Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      acf24a39
  47. 05 11月, 2014 1 次提交
  49. 18 7月, 2014 1 次提交
    • M
      drm/plane-helper: Use proper plane init function · 3281cc7e
      由 Matt Roper 提交于 
      drm_plane_init() (the legacy plane initialization function) takes a bool
as its final parameter; originally this indicated whether a plane was
'private' to the driver (before the DRM core understood non-overlay
planes), now it indicates whether the plane is a primary plane (private
planes were used by some drivers to represent primary planes
internally).  The newer drm_universal_plane_init() take an 'enum
drm_plane_type' as its final parameter to allow the caller to specify
the specific plane type desired (primary, cursor, or overlay).

Due to a rebasing mistake, the primary plane helper is currently passing
DRM_PLANE_TYPE_PRIMARY (enum value = 1) for drm_plane_init()'s boolean
'is_primary' parameter.  This winds up giving the correct behavior since
DRM_PLANE_TYPE_PRIMARY evaluates as true, but is confusing to anyone
reading the code since we're passing an enum value (one of three
possible values) for a boolean parameter.

Replace the primary plane helper's call to drm_plane_init() with
drm_universal_plane_init() so that the parameter and value types match
up as expected.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3281cc7e
  51. 05 6月, 2014 3 次提交
  53. 04 6月, 2014 1 次提交
    • D
      drm: Split connection_mutex out of mode_config.mutex (v3) · 6e9f798d
      由 Daniel Vetter 提交于 
      After the split-out of crtc locks from the big mode_config.mutex
there's still two major areas it protects:
- Various connector probe states, like connector->status, EDID
  properties, probed mode lists and similar information.
- The links from connector->encoder and encoder->crtc and other
  modeset-relevant connector state (e.g. properties which control the
  panel fitter).

The later is used by modeset operations. But they don't really care
about the former since it's allowed to e.g. enable a disconnected VGA
output or with a mode not in the probed list.

Thus far this hasn't been a problem, but for the atomic modeset
conversion Rob Clark needs to convert all modeset relevant locks into
w/w locks. This is required because the order of acquisition is
determined by how userspace supplies the atomic modeset data. This has
run into troubles in the detect path since the i915 load detect code
needs _both_ protections offered by the mode_config.mutex: It updates
probe state and it needs to change the modeset configuration to enable
the temporary load detect pipe.

The big deal here is that for the probe/detect users of this lock a
plain mutex fits best, but for atomic modesets we really want a w/w
mutex. To fix this lets split out a new connection_mutex lock for the
modeset relevant parts.

For simplicity I've decided to only add one additional lock for all
connector/encoder links and modeset configuration states. We have
piles of different modeset objects in addition to those (like bridges
or panels), so adding per-object locks would be much more effort.

Also, we're guaranteed (at least for now) to do a full modeset if we
need to acquire this lock. Which means that fine-grained locking is
fairly irrelevant compared to the amount of time the full modeset will
take.

I've done a full audit, and there's just a few things that justify
special focus:
- Locking in drm_sysfs.c is almost completely absent. We should
  sprinkle mode_config.connection_mutex over this file a bit, but
  since it already lacks mode_config.mutex this patch wont make the
  situation any worse. This is material for a follow-up patch.

- omap has a omap_framebuffer_flush function which walks the
  connector->encoder->crtc links and is called from many contexts.
  Some look like they don't acquire mode_config.mutex, so this is
  already racy. Again fixing this is material for a separate patch.

- The radeon hot_plug function to retrain DP links looks at
  connector->dpms. Currently this happens without any locking, so is
  already racy. I think radeon_hotplug_work_func should gain
  mutex_lock/unlock calls for the mode_config.connection_mutex.

- Same applies to i915's intel_dp_hot_plug. But again, this is already
  racy.

- i915 load_detect code needs to acquire this lock. Which means the
  w/w dance due to Rob's work will be nicely contained to _just_ this
  function.

I've added fixme comments everywhere where it looks suspicious but in
the sysfs code. After a quick irc discussion with Dave Airlie it
sounds like the lack of locking in there is due to sysfs cleanup fun
at module unload.

v1: original (only compile tested)

v2: missing mutex_init(), etc (from Rob Clark)

v3: i915 needs more care in the conversion:
- Protect the edp pp logic with the connection_mutex.
- Use connection_mutex in the backlight code due to
  get_pipe_from_connector.
- Use drm_modeset_lock_all in suspend/resume paths.
- Update lock checks in the overlay code.

Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NRob Clark <robdclark@gmail.com>
      6e9f798d
  55. 02 6月, 2014 2 次提交
    • T
      drm/plane: Fix a couple of checkpatch warnings · 233fd4ec
      由 Thierry Reding 提交于 
      Code should be indented using tabs rather than spaces (see CodingStyle)
and the canonical form to declare a constant static variable is using
"static const" rather than "const static". Fixes the following warnings
from checkpatch:

	$ scripts/checkpatch.pl -f drivers/gpu/drm/drm_plane_helper.c
	WARNING: storage class should be at the beginning of the declaration
	#40: FILE: drivers/gpu/drm/drm_plane_helper.c:40:
	+const static uint32_t safe_modeset_formats[] = {

	WARNING: please, no spaces at the start of a line
	#41: FILE: drivers/gpu/drm/drm_plane_helper.c:41:
	+       DRM_FORMAT_XRGB8888,$

	WARNING: please, no spaces at the start of a line
	#42: FILE: drivers/gpu/drm/drm_plane_helper.c:42:
	+       DRM_FORMAT_ARGB8888,$
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      233fd4ec
    • T
      drm/plane: Fix sparse warnings · f220e626
      由 Thierry Reding 提交于 
      Include the drm_plane_helper.h header file to fix the following sparse
warnings:

	  CHECK   drivers/gpu/drm/drm_plane_helper.c
	drivers/gpu/drm/drm_plane_helper.c:102:5: warning: symbol 'drm_primary_helper_update' was not declared. Should it be static?
	drivers/gpu/drm/drm_plane_helper.c:219:5: warning: symbol 'drm_primary_helper_disable' was not declared. Should it be static?
	drivers/gpu/drm/drm_plane_helper.c:233:6: warning: symbol 'drm_primary_helper_destroy' was not declared. Should it be static?
	drivers/gpu/drm/drm_plane_helper.c:241:30: warning: symbol 'drm_primary_helper_funcs' was not declared. Should it be static?
	drivers/gpu/drm/drm_plane_helper.c:259:18: warning: symbol 'drm_primary_helper_create_plane' was not declared. Should it be static?

Doing that makes gcc complain as follows:

	  CC      drivers/gpu/drm/drm_plane_helper.o
	drivers/gpu/drm/drm_plane_helper.c:260:19: error: conflicting types for 'drm_primary_helper_create_plane'
	 struct drm_plane *drm_primary_helper_create_plane(struct drm_device *dev,
	                   ^
	In file included from drivers/gpu/drm/drm_plane_helper.c:29:0:
	include/drm/drm_plane_helper.h:42:19: note: previous declaration of 'drm_primary_helper_create_plane' was here
	 struct drm_plane *drm_primary_helper_create_plane(struct drm_device *dev,
	                   ^
	drivers/gpu/drm/drm_plane_helper.c: In function 'drm_primary_helper_create_plane':
	drivers/gpu/drm/drm_plane_helper.c:274:11: warning: assignment discards 'const' qualifier from pointer target type
	   formats = safe_modeset_formats;
	           ^
	In file included from include/linux/linkage.h:6:0,
	                 from include/linux/kernel.h:6,
	                 from include/drm/drmP.h:45,
	                 from drivers/gpu/drm/drm_plane_helper.c:27:
	drivers/gpu/drm/drm_plane_helper.c: At top level:
	drivers/gpu/drm/drm_plane_helper.c:289:15: error: conflicting types for 'drm_primary_helper_create_plane'
	 EXPORT_SYMBOL(drm_primary_helper_create_plane);
	               ^
	include/linux/export.h:57:21: note: in definition of macro '__EXPORT_SYMBOL'
	  extern typeof(sym) sym;     \
	                     ^
	drivers/gpu/drm/drm_plane_helper.c:289:1: note: in expansion of macro 'EXPORT_SYMBOL'
	 EXPORT_SYMBOL(drm_primary_helper_create_plane);
	 ^
	In file included from drivers/gpu/drm/drm_plane_helper.c:29:0:
	include/drm/drm_plane_helper.h:42:19: note: previous declaration of 'drm_primary_helper_create_plane' was here
	 struct drm_plane *drm_primary_helper_create_plane(struct drm_device *dev,
	                   ^

Which can easily be fixed by making the signatures of the implementation
and the prototype match.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f220e626
  57. 24 4月, 2014 1 次提交
    • D
      drm: Simplify fb refcounting rules around ->update_plane · 0fe27f06
      由 Daniel Vetter 提交于 
      The introduction of primary planes has apparently caused a bit of fb
refcounting fun for people. That makes it a good time to clean up the
arcane rules and slight differences between ->update_plane and
->set_config. The new rules are:

- The core holds a reference for both the new and the old fb (if
  they're non-NULL of course) while calling into the driver through
  either ->update_plane or ->set_config.

- Drivers may not clobber plane->fb if their callback fails. If they
  do that, they need to store a pointer to the old fb in it again.
  When calling into the driver plane->fb still points at the current
  (old) framebuffer.

- The core will update the plane->fb pointer on success. Drivers can
  do that themselves too, but aren't required to any more for the
  primary plane.

- The core will update fb refcounts for the plane->fb pointer,
  presuming the drivers hold up their end of the bargain.

v2: Remove now unused tmpfb (Thierry)

v3: Drop broken changes from drm_mode_setplane (Ville). Also polish
the commit message a bit.

v4: Also fix up the handling of ->disable_plane in
drm_plane_force_disable. The issue was that we didn't save plane->fb
over the ->disable_plane call. Just paranoia, nothing relies on this.

v5: Keep still useful comments about directly calling ->set_config,
which I should have done for v4 already. Requested by Matt.

Cc: Thierry Reding <treding@nvidia.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0fe27f06
  59. 22 4月, 2014 2 次提交