1. 13 2月, 2014 3 次提交
    • D
      drm/i915: Fix error path leak in fbdev fb allocation · a8bb6818
      Daniel Vetter 提交于
      In Jesse's patch to switch the fbdev framebuffer from an embedded
      struct to a pointer the kfree in case of an error was missed. Fix this
      up by using our own internal fb allocation helper directly instead of
      reinventing that wheel.
      
      We need a to_intel_framebuffer cast unfortunately since all the other
      callers of _create still look better whith using a drm_framebuffer as
      return pointer.
      
      v2: Add an unlocked __intel_framebuffer_create function since our
      dev->struct_mutex locking is too much a mess. With ppgtt we even need
      it to take a look at the global gtt offset of pinned objects, since
      the vma list might chance from underneath us. At least with the
      current global gtt lookup functions. Reported by Mika.
      
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a8bb6818
    • D
      drm/i915: Use normal fb deref for the fbcon framebuffer · ef2d633e
      Daniel Vetter 提交于
      Now that it's a normally kmalloce buffer we can use the usual cleanup
      paths. The upside here is that if we get the refcounting wrong will be
      able to catch it, since the drm core will complain about leftover
      framebuffers and kref about underflows.
      
      v2: Kill intel_framebuffer_fini - no longer needed now that we
      refcount all fbs properly and only confusing.
      
      v3: We actually still need to call unregister_private to remove the fb
      from the idr and drop the idr reference - the final unref doesn't do
      that. So much for remembering my own fb liftime rules. Reported by
      Imre Deak.
      
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ef2d633e
    • J
      drm/i915: alloc intel_fb in the intel_fbdev struct · 8bcd4553
      Jesse Barnes 提交于
      Allocate this struct instead, so we can re-use another allocated
      elsewhere if needed.
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      [danvet: WARN_ON if there's no backing storage attached to an fb,
      that's a bug.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      8bcd4553
  2. 07 1月, 2014 1 次提交
  3. 18 12月, 2013 1 次提交
  4. 28 11月, 2013 1 次提交
  5. 27 11月, 2013 1 次提交
  6. 21 10月, 2013 1 次提交
  7. 12 10月, 2013 1 次提交
  8. 01 10月, 2013 3 次提交
  9. 07 8月, 2013 1 次提交
  10. 09 7月, 2013 1 次提交
    • B
      drm/i915: Getter/setter for object attributes · f343c5f6
      Ben Widawsky 提交于
      Soon we want to gut a lot of our existing assumptions how many address
      spaces an object can live in, and in doing so, embed the drm_mm_node in
      the object (and later the VMA).
      
      It's possible in the future we'll want to add more getter/setter
      methods, but for now this is enough to enable the VMAs.
      
      v2: Reworked commit message (Ben)
      Added comments to the main functions (Ben)
      sed -i "s/i915_gem_obj_set_color/i915_gem_obj_ggtt_set_color/" drivers/gpu/drm/i915/*.[ch]
      sed -i "s/i915_gem_obj_bound/i915_gem_obj_ggtt_bound/" drivers/gpu/drm/i915/*.[ch]
      sed -i "s/i915_gem_obj_size/i915_gem_obj_ggtt_size/" drivers/gpu/drm/i915/*.[ch]
      sed -i "s/i915_gem_obj_offset/i915_gem_obj_ggtt_offset/" drivers/gpu/drm/i915/*.[ch]
      (Daniel)
      
      v3: Rebased on new reserve_node patch
      Changed DRM_DEBUG_KMS to actually work (will need fixing later)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f343c5f6
  11. 17 6月, 2013 1 次提交
  12. 10 6月, 2013 1 次提交
  13. 03 6月, 2013 2 次提交
  14. 08 5月, 2013 1 次提交
  15. 07 4月, 2013 1 次提交
  16. 27 3月, 2013 1 次提交
  17. 23 3月, 2013 1 次提交
  18. 05 3月, 2013 1 次提交
  19. 14 2月, 2013 3 次提交
  20. 27 1月, 2013 1 次提交
  21. 21 1月, 2013 2 次提交
    • D
      drm: revamp framebuffer cleanup interfaces · 36206361
      Daniel Vetter 提交于
      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
        manually).
      - 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: NRob Clark <rob@ti.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      36206361
    • D
      drm/i915: use drm_modeset_lock_all · a0e99e68
      Daniel Vetter 提交于
      Two exceptions:
      - debugfs files only read information which is not related to crtc, so
        can stay on the modeset_config lock.
      - Same holds for the edp vdd work in intel_dp.c. Add a corresponding
        WARN_ON and a comment next to the intel_dp struct fields for
        documentation.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a0e99e68
  22. 20 1月, 2013 1 次提交
    • B
      drm/i915: Remove use of gtt_mappable_entries · 93d18799
      Ben Widawsky 提交于
      Mappable_end, ie. size is almost always what you want as opposed to the
      number of entries. Since we already have that information, we can scrap
      the number of entries and only calculate it when needed.
      
      If gtt_start is !0, this will have slightly different behavior. This
      difference can only occur in DRI1, and exists when we try to kick out
      the firmware fb. The new code seems like a bugfix to me.
      
      The other case where we've changed the behavior is during init we check
      the mappable region against our current known upper and lower limits
      (64MB, and 512MB). This now matches the comment, and makes things more
      convenient after removing gtt_mappable_entries.
      
      Also worth noting is the setting of mappable_end is taken out of setup
      because we do it earlier now in the DRI2 case and therefore need to add
      that tiny hunk to support the DRI1 IOCTL.
      
      v2: Move up mappable end to before legacy AGP init
      
      v3: Add the dev_priv inclusion here from previous rebase error in patch
      5
      
      Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      [danvet: squash in fix for a printk format flag mismatch warning.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      93d18799
  23. 18 1月, 2013 1 次提交
    • B
      drm/i915: Create a gtt structure · 5d4545ae
      Ben Widawsky 提交于
      The purpose of the gtt structure is to help isolate our gtt specific
      properties from the rest of the code (in doing so it help us finish the
      isolation from the AGP connection).
      
      The following members are pulled out (and renamed):
      gtt_start
      gtt_total
      gtt_mappable_end
      gtt_mappable
      gtt_base_addr
      gsm
      
      The gtt structure will serve as a nice place to put gen specific gtt
      routines in upcoming patches. As far as what else I feel belongs in this
      structure: it is meant to encapsulate the GTT's physical properties.
      This is why I've not added fields which track various drm_mm properties,
      or things like gtt_mtrr (which is itself a pretty transient field).
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
      [Ben modified commit messages]
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5d4545ae
  24. 17 12月, 2012 1 次提交
  25. 12 12月, 2012 1 次提交
    • D
      drm/i915: Fixup hpd irq register setup ordering · 20afbda2
      Daniel Vetter 提交于
      For GMCH platforms we set up the hpd irq registers in the irq
      postinstall hook. But since we only enable the irq sources we actually
      need in PORT_HOTPLUG_EN/STATUS, taking dev_priv->hotplug_supported_mask
      into account, no hpd interrupt sources is enabled since
      
      commit 52d7eced
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sat Dec 1 21:03:22 2012 +0100
      
          drm/i915: reorder setup sequence to have irqs for output setup
      
      Wrongly set-up interrupts also lead to broken hw-based load-detection
      on at least GM45, resulting in ghost VGA/TV-out outputs.
      
      To fix this, delay the hotplug register setup until after all outputs
      are set up, by moving it into a new dev_priv->display.hpd_irq_callback.
      We might also move the PCH_SPLIT platforms to such a setup eventually.
      
      Another funny part is that we need to delay the fbdev initial config
      probing until after the hpd regs are setup, for otherwise it'll detect
      ghost outputs. But we can only enable the hpd interrupt handling
      itself (and the output polling) _after_ that initial scan, due to
      massive locking brain-damage in the fbdev setup code. Add a big
      comment to explain this cute little dragon lair.
      
      v2: Encapsulate all the fbdev handling by wrapping the move call into
      intel_fbdev_initial_config in intel_fb.c. Requested by Chris Wilson.
      
      v3: Applied bikeshed from Jesse Barnes.
      
      v4: Imre Deak noticed that we also need to call intel_hpd_init after
      the drm_irqinstall calls in the gpu reset and resume paths - otherwise
      hotplug will be broken. Also improve the comment a bit about why
      hpd_init needs to be called before we set up the initial fbdev config.
      
      Bugzilla: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54943Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3)
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      20afbda2
  26. 01 12月, 2012 1 次提交
  27. 03 10月, 2012 2 次提交
  28. 05 7月, 2012 1 次提交
  29. 13 6月, 2012 1 次提交
  30. 18 4月, 2012 1 次提交
  31. 17 4月, 2012 1 次提交
新手
引导
客服 返回
顶部