1. 07 Mar, 2013 1 commit
  2. 22 Feb, 2013 2 commits
  3. 13 Feb, 2013 1 commit
    • Daniel Vetter's avatar
      drm: review locking for drm_fb_helper_restore_fbdev_mode · 6aed8ec3
      Daniel Vetter authored
      ... it's required. Fix up exynos and the cma helper, and add a
      corresponding WARN_ON to drm_fb_helper_restore_fbdev_mode.
      Note that tegra calls the fbdev cma helper restore function also from
      it's driver-load callback. Which is a bit against current practice,
      since usually the call is only from ->lastclose, and initial setup is
      done by drm_fb_helper_initial_config.
      Also add the relevant drm DocBook entry.
      v2: Add promised WARN to restore_fbdev_mode.
      Reviewed-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  4. 20 Jan, 2013 7 commits
    • Daniel Vetter's avatar
      drm: revamp framebuffer cleanup interfaces · 36206361
      Daniel Vetter authored
      We have two classes of framebuffer
      - Created by the driver (atm only for fbdev), and the driver holds
        onto the last reference count until destruction.
      - Created by userspace and associated with a given fd. These
        framebuffers will be reaped when their assoiciated fb is closed.
      Now these two cases are set up differently, the framebuffers are on
      different lists and hence destruction needs to clean up different
      things. Also, for userspace framebuffers we remove them from any
      current usage, whereas for internal framebuffers it is assumed that
      the driver has done this already.
      Long story short, we need two different ways to cleanup such drivers.
      Three functions are involved in total:
      - drm_framebuffer_remove: Convenience function which removes the fb
        from all active usage and then drops the passed-in reference.
      - drm_framebuffer_unregister_private: Will remove driver-private
        framebuffers from relevant lists and drop the corresponding
        references. Should be called for driver-private framebuffers before
        dropping the last reference (or like for a lot of the drivers where
        the fbdev is embedded someplace else, before doing the cleanup
      - drm_framebuffer_cleanup: Final cleanup for both classes of fbs,
        should be called by the driver's ->destroy callback once the last
        reference is gone.
      This patch just rolls out the new interfaces and updates all drivers
      (by adding calls to drm_framebuffer_unregister_private at all the
      right places)- no functional changes yet. Follow-on patches will move
      drm core code around and update the lifetime management for
      framebuffers, so that we are no longer required to keep framebuffers
      alive by locking mode_config.mutex.
      I've also updated the kerneldoc already.
      vmwgfx seems to again be a bit special, at least I haven't figured out
      how the fbdev support in that driver works. It smells like it's
      external though.
      v2: The i915 driver creates another private framebuffer in the
      load-detect code. Adjust its cleanup code, too.
      Reviewed-by: default avatarRob Clark <rob@ti.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Daniel Vetter's avatar
      drm: create drm_framebuffer_lookup · 786b99ed
      Daniel Vetter authored
      And replace all fb lookups with it. Also add a WARN to
      drm_mode_object_find since that is now no longer the blessed interface
      to look up an fb. And add kerneldoc to both functions.
      This only updates all callsites, but immediately drops the acquired
      refence again. Hence all callers still rely on the fact that a mode fb
      can't disappear while they're holding the struct mutex. Subsequent
      patches will instate proper use of refcounts, and then rework the rmfb
      and unref code to no longer serialize fb destruction with the
      mode_config lock. We don't want that since otherwise a compositor
      might end up stalling for a few frames in rmfb.
      v2: Don't use kref_get_unless_zero - Greg KH doesn't like that kind of
      Reviewed-by: default avatarRob Clark <rob@ti.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Daniel Vetter's avatar
      drm: revamp locking around fb creation/destruction · 4b096ac1
      Daniel Vetter authored
      Well, at least step 1. The goal here is that framebuffer objects can
      survive outside of the mode_config lock, with just a reference held
      as protection. The first step to get there is to introduce a special
      fb_lock which protects fb lookup, creation and destruction, to make
      them appear atomic.
      This new fb_lock can nest within the mode_config lock. But the idea is
      (once the reference counting part is completed) that we only quickly
      take that fb_lock to lookup a framebuffer and grab a reference,
      without any other locks involved.
      vmwgfx is the only driver which does framebuffer lookups itself, also
      wrap those calls to drm_mode_object_find with the new lock.
      Also protect the fb_list walking in i915 and omapdrm with the new lock.
      As a slight complication there's also the list of user-created fbs
      attached to the file private. The problem now is that at fclose() time
      we need to walk that list, eventually do a modeset call to remove the
      fb from active usage (and are required to be able to take the
      mode_config lock), but in the end we need to grab the new fb_lock to
      remove the fb from the list. The easiest solution is to add another
      mutex to protect this per-file list.
      Currently that new fbs_lock nests within the modeset locks and so
      appears redudant. But later patches will switch around this sequence
      so that taking the modeset locks in the fb destruction path is
      optional in the fastpath. Ultimately the goal is that addfb and rmfb
      do not require the mode_config lock, since otherwise they have the
      potential to introduce stalls in the pageflip sequence of a compositor
      (if the compositor e.g. switches to a fullscreen client or if it
      enables a plane). But that requires a few more steps and hoops to jump
      Note that framebuffer creation/destruction is now double-protected -
      once by the fb_lock and in parts by the idr_lock. The later would be
      unnecessariy if framebuffers would have their own idr allocator. But
      that's material for another patch (series).
      v2: Properly initialize the fb->filp_head list in _init, otherwise the
      newly added WARN to check whether the fb isn't on a fpriv list any
      more will fail for driver-private objects.
      v3: Fixup two error-case unlock bugs spotted by Richard Wilbur.
      Reviewed-by: default avatarRob Clark <rob@ti.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Daniel Vetter's avatar
      drm: add per-crtc locks · 29494c17
      Daniel Vetter authored
      The basic idea is to protect per-crtc state which can change without
      touching the output configuration with separate mutexes, i.e.  all the
      input side state to a crtc like framebuffers, cursor settings or plane
      configuration. Holding such a crtc lock gives a read-lock on all the
      other crtc state which can be changed by e.g. a modeset.
      All non-crtc state is still protected by the mode_config mutex.
      Callers that need to change modeset state of a crtc (e.g. dpms or
      set_mode) need to grab both the mode_config lock and nested within any
      crtc locks.
      Note that since there can only ever be one holder of the mode_config
      lock we can grab the subordinate crtc locks in any order (if we need
      to grab more than one of them). Lockdep can handle such nesting with
      the mutex_lock_nest_lock call correctly.
      With this functions that only touch connectors/encoders but not crtcs
      only need to take the mode_config lock. The biggest such case is the
      output probing, which means that we can now pageflip and move cursors
      while the output probe code is reading an edid.
      Most cases neatly fall into the three buckets:
      - Only touches connectors and similar output state and so only needs
        the mode_config lock.
      - Touches the global configuration and so needs all locks.
      - Only touches the crtc input side and so only needs the crtc lock.
      But a few cases that need special consideration:
      - Load detection which requires a crtc. The mode_config lock already
        prevents a modeset change, so we can use any unused crtc as we like
        to do load detection. The only thing to consider is that such
        temporary state changes don't leak out to userspace through ioctls
        that only take the crtc look (like a pageflip). Hence the load
        detect code needs to grab the crtc of any output pipes it touches
        (but only if it touches state used by the pageflip or cursor
      - Atomic pageflip when moving planes. The first case is sane hw, where
        planes have a fixed association with crtcs - nothing needs to be
        done there. More insane^Wflexible hw needs to have plane->crtc
        mapping which is separately protect with a lock that nests within
        the crtc lock. If the plane is unused we can just assign it to the
        current crtc and continue. But if a plane is already in use by
        another crtc we can't just reassign it.
        Two solution present themselves: Either go back to a slow-path which
        takes all modeset locks, potentially incure quite a hefty delay. Or
        simply disallowing such changes in one atomic pageflip - in general
        the vblanks of two crtcs are not synced, so there's no sane way to
        atomically flip such plane changes accross more than one crtc. I'd
        heavily favour the later approach, going as far as mandating it as
        part of the ABI of such a new a nuclear pageflip.
        And if we _really_ want such semantics, we can always get them by
        introducing another pageflip mutex between the mode_config.mutex and
        the individual crtc locks. Pageflips crossing more than one crtc
        would then need to take that lock first, to lock out concurrent
        multi-crtc pageflips.
      - Optimized global modeset operations: We could just take the
        mode_config lock and then lazily lock all crtc which are affected by
        a modeset operation. This has the advantage that pageflip could
        continue unhampered on unaffected crtc. But if e.g. global resources
        like plls need to be reassigned and so affect unrelated crtcs we can
        still do that - nested locking works in any order.
      This patch just adds the locks and takes them in drm_modeset_lock_all,
      no real locking changes yet.
      v2: Need to initialize the new lock in crtc_init and lock it righ
      away, for otherwise the modeset_unlock_all below will try to unlock a
      not-locked mutex.
      Reviewed-by: default avatarRob Clark <rob@ti.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Daniel Vetter's avatar
      drm: add drm_modeset_lock|unlock_all · 84849903
      Daniel Vetter authored
      This is the first step towards introducing the new modeset locking
      scheme. The plan is to put helper functions into place at all the
      right places step-by-step, so that the final patch to switch on the
      new locking scheme doesn't need to touch every single driver.
      This helper here will serve as the shotgun solutions for all places
      where a more fine-grained locking isn't (yet) implemented.
      v2: Fixup kerneldoc for unlock_all.
      Reviewed-by: default avatarRob Clark <rob@ti.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Daniel Vetter's avatar
      drm: encapsulate crtc->set_config calls · 2d13b679
      Daniel Vetter authored
      With refcounting we need to adjust framebuffer refcounts at each
      callsite - much easier to do if they all call the same little helper
      Reviewed-by: default avatarRob Clark <rob@ti.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Ville Syrjälä's avatar
      drm/edid: Add drm_rgb_quant_range_selectable() · b1edd6a6
      Ville Syrjälä authored
      drm_rgb_quant_range_selectable() will report whether the monitor
      claims to support for RGB quantization range selection.
      The information can be found in the CEA Video capability block.
      v2: s/quantzation/quantization/ in the comment
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Acked-by: default avatarDavid Airlie <airlied@linux.ie>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  5. 30 Nov, 2012 1 commit
    • Rob Clark's avatar
      drm: remove legacy drm_connector_property fxns · 58495563
      Rob Clark authored
      Replace references to and remove the connector property fxns, which
      have been superseded with the more general object property fxns:
        + drm_connector_attach_property -> drm_object_attach_property
        + drm_connector_property_set_value -> drm_object_property_set_value
        + drm_connector_property_get_value -> drm_object_property_get_value
      Signed-off-by: default avatarRob Clark <rob@ti.com>
  6. 29 Nov, 2012 1 commit
  7. 19 Nov, 2012 4 commits
    • Daniel Vetter's avatar
      drm: don't start the poll engine in probe_single_connector · 905bc9ff
      Daniel Vetter authored
      Actually there's a reason this stuff is there, and it's called
      commit e58f637b
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Fri Aug 20 09:13:36 2010 +0100
          drm/kms: Add a module parameter to disable polling
      The idea has been that users can enable/disable polling at runtime. So
      the quick hack has been to just re-enable the output polling if xrandr
      asks for the latest state of the connectors.
      The problem with that hack is that when we force connectors to another
      state than what would be detected, we nicely ping-pong:
      - Userspace calls probe, gets the forced state, but polling starts
      - Polling notices that the state is actually different, wakes up
      - Repeat.
      As that commit already explains, the right fix would be to make the
      locking more fine-grained, so that hotplug detection on one output
      does not interfere with cursor updates on another crtc.
      But that is way too much work. So let's just safe this gross hack by
      caching the last-seen state of drm_kms_helper_poll for that driver,
      and only fire up the poll engine again if it changed from off to on.
      v2: Fixup the edge detection of drm_kms_helper_poll.
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49907
      Tested-by: default avatarTvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
    • Daniel Vetter's avatar
      drm: run the hpd irq event code directly · 69787f7d
      Daniel Vetter authored
      All drivers already have a work item to run the hpd code, so we don't
      need to launch a new one in the helper code. Dave Airlie mentioned
      that the cancel+re-queue might paper over DP related hpd ping-pongs,
      hence why this is split out.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
    • Daniel Vetter's avatar
      drm: handle HPD and polled connectors separately · 816da85a
      Daniel Vetter authored
      Instead of reusing the polling code for hpd handling, split them up.
      This has a few consequences:
      - Don't touch HPD capable connectors in the poll loop.
      - Only touch HPD capable connectors in drm_helper_hpd_irq_event.
      - We could run the HPD handling directly (because all callers already
        use their own work item), but for easier bisect that happens in it's
        own patch.
      The ultimate goal is that drivers grow some smarts about which
      connectors have received a hotplug event and only call the detect code
      of that connector. But that's a second step.
      v2: s/hdp/hpd/, noticed by Adam Jackson. I can't type.
      v3: Split out the work item removal as requested by Dave Airlie. This
      results in a temporary mode_config.hpd_irq_work item to keep things
      the same.
      v4: In the hpd_irq_event handler don't bail out if other bits than HPD
      are set. This is useful where e.g. hpd is unreliably, but mostly
      works. Drivers can then set both HPD and POLL flags, and users get the
      best of both worlds: Quick hotplug feedback if the hpd works, but
      still reliable detection with the polling. The poll loop already works
      the same, and doesn't bail if HPD is set.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
    • Stephane Marchesin's avatar
      drm: get cea video id code for a given display mode · a4799037
      Stephane Marchesin authored
      This patch adds support for getting CEA Video ID Code for a given
      display mode after matching with edid_cea_modes list. Its index in
      the list added with one, gives the desired code.
      This exported function will be used by hdmi drivers for composing
      AVI info frame data.
      Signed-off-by: default avatarStephane Marchesin <marcheu@chromium.org>
      Signed-off-by: default avatarRahul Sharma <rahul.sharma@samsung.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
  8. 06 Nov, 2012 1 commit
  9. 02 Oct, 2012 4 commits
  10. 26 Sep, 2012 1 commit
  11. 16 Sep, 2012 1 commit
  12. 23 Aug, 2012 2 commits
  13. 21 Aug, 2012 1 commit
  14. 19 Jul, 2012 1 commit
  15. 12 Jun, 2012 1 commit
    • Paulo Zanoni's avatar
      drm: increase DRM_OBJECT_MAX_PROPERTY to 24 · fe456168
      Paulo Zanoni authored
      Before Kernel 3.5, no one was checking for the return value of
      drm_connector_attach_property, so we never noticed that we were unable
      to create some properties. Commit "drm: WARN() when
      drm_connector_attach_property fails" added a WARN when we fail to
      create a property, and the transition from "connector properties" to
      "object properties" changed the warning message a little bit.
      On i915 machines with many TV connectors we hit the maximum number of
      properties (since each TV connector uses a lot of properties), so we
      get a few backtraces in our logs. This commit increases the maximum
      number of properties to 24 hoping we'll have enough room for
      Chris suggested that we convert this code to "lists", but I believe
      this conversion can come after we make sure people's dmesgs are not
      spammed by our driver.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reported-by: default avatarDave Jones <davej@redhat.com>
      Tested-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
  16. 22 May, 2012 4 commits
  17. 17 May, 2012 5 commits
  18. 27 Apr, 2012 1 commit
  19. 20 Apr, 2012 1 commit