1. 06 6月, 2014 7 次提交
  2. 05 6月, 2014 2 次提交
  3. 24 4月, 2014 1 次提交
    • D
      drm/tegra: restrict plane loops to legacy planes · 2b4c3661
      Daniel Vetter 提交于
      In Matt Ropers primary plane series a set of prep patches like
      
      commit af2b653b
      Author: Matt Roper <matthew.d.roper@intel.com>
      Date:   Tue Apr 1 15:22:32 2014 -0700
      
          drm/i915: Restrict plane loops to only operate on overlay planes (v2)
      
      ensured that all exisiting users of the mode_config->plane_list
      wouldn't change behaviour. Unfortunately tegra seems to have fallen
      through the cracks. Fix it.
      
      This regression was introduced in
      
      commit e13161af
      Author: Matt Roper <matthew.d.roper@intel.com>
      Date:   Tue Apr 1 15:22:38 2014 -0700
      
          drm: Add drm_crtc_init_with_planes() (v2)
      
      The result was that we've unref'ed the fb for the primary plane twice,
      leading to a use-after free bug. This is because the drm core will
      already set crtc->primary->fb to NULL and do the unref for us, and the
      crtc disable hook is called by the drm crtc helpers for exactly this
      case.
      
      Aside: Now that the fbdev helpers clean up planes there's no longer a
      need to do this in drivers. So this could probably be nuked entirely
      in linux-next.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
      Tested-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      2b4c3661
  4. 23 4月, 2014 1 次提交
  5. 22 4月, 2014 1 次提交
  6. 08 4月, 2014 1 次提交
  7. 04 4月, 2014 4 次提交
  8. 02 4月, 2014 1 次提交
    • M
      drm: Replace crtc fb with primary plane fb (v3) · f4510a27
      Matt Roper 提交于
      Now that CRTC's have a primary plane, there's no need to track the
      framebuffer in the CRTC.  Replace all references to the CRTC fb with the
      primary plane's fb.
      
      This patch was generated by the Coccinelle semantic patching tool using
      the following rules:
      
              @@ struct drm_crtc C; @@
              -   (C).fb
              +   C.primary->fb
      
              @@ struct drm_crtc *C; @@
              -   (C)->fb
              +   C->primary->fb
      
      v3: Generate patch via coccinelle.  Actual removal of crtc->fb has been
          moved to a subsequent patch.
      
      v2: Fixup several lingering crtc->fb instances that were missed in the
          first patch iteration.  [Rob Clark]
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      f4510a27
  9. 16 3月, 2014 1 次提交
    • D
      drm: provide device-refcount · 099d1c29
      David Herrmann 提交于
      Lets not trick ourselves into thinking "drm_device" objects are not
      ref-counted. That's just utterly stupid. We manage "drm_minor" objects on
      each drm-device and each minor can have an unlimited number of open
      handles. Each of these handles has the drm_minor (and thus the drm_device)
      as private-data in the file-handle. Therefore, we may not destroy
      "drm_device" until all these handles are closed.
      
      It is *not* possible to reset all these pointers atomically and restrict
      access to them, and this is *not* how this is done! Instead, we use
      ref-counts to make sure the object is valid and not freed.
      
      Note that we currently use "dev->open_count" for that, which is *exactly*
      the same as a reference-count, just open coded. So this patch doesn't
      change any semantics on DRM devices (well, this patch just introduces the
      ref-count, anyway. Follow-up patches will replace open_count by it).
      
      Also note that generic VFS revoke support could allow us to drop this
      ref-count again. We could then just synchronously disable any fops->xy()
      calls. However, this is not the case, yet, and no such patches are
      in sight (and I seriously question the idea of dropping the ref-cnt
      again).
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      099d1c29
  10. 12 2月, 2014 2 次提交
  11. 23 1月, 2014 1 次提交
    • T
      drm/tegra: Obtain head number from DT · 13411ddd
      Thierry Reding 提交于
      The head number of a given display controller is fixed in hardware and
      required to program outputs appropriately. Relying on the driver probe
      order to determine this number will not work, since that could yield a
      situation where the second head was probed first and would be assigned
      head number 0 instead of 1.
      
      By explicitly specifying the head number in the device tree, it is no
      longer necessary to rely on these assumptions. As a fallback, if the
      property isn't available, derive the head number from the display
      controller node's position in the device tree. That's somewhat more
      reliable than the previous default but not a proper solution.
      Tested-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      13411ddd
  12. 14 1月, 2014 4 次提交
  13. 20 12月, 2013 9 次提交
  14. 19 12月, 2013 5 次提交