1. 13 7月, 2016 1 次提交
  2. 12 7月, 2016 1 次提交
  3. 24 6月, 2016 2 次提交
  4. 22 6月, 2016 4 次提交
  5. 17 6月, 2016 4 次提交
  6. 10 6月, 2016 1 次提交
  7. 09 6月, 2016 1 次提交
  8. 07 6月, 2016 3 次提交
  9. 03 6月, 2016 1 次提交
  10. 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
  11. 01 6月, 2016 2 次提交
    • T
      drm: fix fb refcount issue with atomic modesetting · 1e8985a8
      Tomi Valkeinen 提交于
      After commit 027b3f8b ("drm/modes: stop
      handling framebuffer special") extra fb refs are left around when doing
      atomic modesetting.
      
      The problem is that the new drm_property_change_valid_get() does not
      return anything in the '**ref' parameter, which causes
      drm_property_change_valid_put() to do nothing.
      
      For some reason this doesn't cause problems with legacy API.
      
      Also, previously the code only set the 'ref' variable for fbs, with this
      patch the 'ref' is set for all objects.
      
      Fixes: 027b3f8b ("drm/modes: stop handling framebuffer special")
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      1e8985a8
    • T
      drm: add missing drm_mode_set_crtcinfo call · b201e743
      Tomi Valkeinen 提交于
      When setting mode via MODE_ID property,
      drm_atomic_set_mode_prop_for_crtc() does not call
      drm_mode_set_crtcinfo() which possibly causes:
      
      "[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 32: Can't
      calculate constants, dotclock = 0!"
      
      Whether the error is seen depends on the previous data in state->mode,
      as state->mode is not cleared when setting new mode.
      
      This patch adds drm_mode_set_crtcinfo() call to
      drm_mode_convert_umode(), which is called in both legacy and atomic
      paths. This should be fine as there's no reason to call
      drm_mode_convert_umode() without also setting the crtc related fields.
      
      drm_mode_set_crtcinfo() is removed from the legacy drm_mode_setcrtc() as
      that is no longer needed.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      b201e743
  12. 31 5月, 2016 1 次提交
  13. 18 5月, 2016 1 次提交
  14. 05 5月, 2016 2 次提交
  15. 28 4月, 2016 2 次提交
  16. 27 4月, 2016 3 次提交
    • D
      drm: Switch blobs to the new generic modeset obj refcounting · 152ef5fa
      Daniel Vetter 提交于
      Need to move the free function around a bit, but otherwise mostly
      just removing code.
      
      Specifically we can nuke all the _locked variants since the weak idr
      reference is now protected by the idr_mutex, which we never hold
      anywhere expect in the lookup/reg/unreg functions. And those never
      call anything else.
      
      Another benefit of this is that this patch switches the weak reference
      logic from kref_put_mutex to kref_get_unless_zero. And the later is in
      general more flexible wrt accomodating multiple weak references
      protected by different locks, which might or might not come handy
      eventually.
      
      But one consequence of that switch is that we need to acquire the
      blob_lock from the free function for the list_del calls. That's a bit
      tricky to pull off, but works well if we pick the exact same scheme as
      is already used for framebuffers. Most important changes:
      
      - filp list is maintainer by create/destroy_blob ioctls directly
        (already the case, so we can just remove the redundant list_del from
        the free function).
      
      - filp close handler walks the filp-private list lockless - works
        because we know no one else can access it. I copied the same comment
        from the fb code over to explain this.
      
      - Otherwise we need to sufficiently restrict blob_lock critical
        sections to avoid all the unreference calls. Easy to do once the
        blob_lock only protects the list, and no longer the weak reference.
      
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Daniel Stone <daniels@collabora.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      152ef5fa
    • D
      drm: Fix fb leaks and WARN spew in get/set_prop ioctls · 1649c33b
      Daniel Vetter 提交于
      Dave Airlie had at least the refcount leak fixed in a later patch (but
      that patch does other things which need a bit more work). But we still
      have the trouble that silly userspace could hit the WARN_ON in
      drm_mode_object_find.
      
      Fix this all up to make sure we don't leak objects, and don't spew
      into demsg.
      
      Fixes: d0f37cf6 ("drm/mode: move framebuffer reference into object.")
      Testcase: igt/kms_addfb_basic/invalid-*-prop*
      Cc: Dave Airlie <airlied@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      1649c33b
    • D
      drm: Improve kerneldoc for new mode object refcounting · 05981422
      Daniel Vetter 提交于
      Slipped through the cracks in my review. The one issue I spotted
      is that drm_mode_object_find now acquires references and can be
      used on FB objects, which caused follow-on bugs in get/set_prop ioctls.
      Follow-up patches will fix that.
      
      [airlied: fixup some incr fb/decr object mixups]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      05981422
  17. 22 4月, 2016 10 次提交