1. 24 2月, 2015 1 次提交
  2. 23 2月, 2015 6 次提交
  3. 12 2月, 2015 6 次提交
  4. 11 2月, 2015 5 次提交
  5. 10 2月, 2015 3 次提交
  6. 09 2月, 2015 3 次提交
  7. 05 2月, 2015 8 次提交
  8. 04 2月, 2015 3 次提交
    • T
      drm: Use static attribute groups for managing connector sysfs entries · 335f1a62
      Takashi Iwai 提交于
      Instead of manual calls of device_create_file() and
      device_remove_file(), assign the static attribute groups to the device
      with device_create_with_groups().  The conditionally built sysfs
      entries are handled via is_visible callback.
      
      This simplifies the code and also avoids the possible races.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      335f1a62
    • D
      drm: remove DRM_FORMAT_NV12MT · 083500ba
      Daniel Vetter 提交于
      So this has been merged originally in
      
      commit 83052d4d
      Author: Seung-Woo Kim <sw0312.kim@samsung.com>
      Date:   Thu Dec 15 15:40:55 2011 +0900
      
          drm: Add multi buffer plane pixel formats
      
      which hasn't seen a lot of review really. The problem is that it's not
      a real pixel format, but just a different way to lay out NV12 pixels
      in macroblocks, i.e. a tiling format.
      
      The new way of doing this is with the soon-to-be-merged fb modifiers.
      
      This was brough up in some long irc discussion around the entire
      topic, as an example of where things have gone wrong. Luckily we can
      correct the mistake:
      - The kms side support for NV12MT is all dead code because
        format_check in drm_crtc.c never accepted NV12MT.
      - The gem side for the gsc support doesn't look better: The code
        forgets to set the pixel format and makes a big mess with the tiling
        mode bits, inadvertedly setting them all.
      
      Conclusion: This never really worked (at least not in upstream) and
      hence we can safely correct our mistake here.
      
      Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Rob Clark <robclark@freedesktop.org>
      Cc: Daniel Stone <daniel@fooishbar.org>
      Cc: Damien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: NRob Clark <robclark@freedesktop.org>
      Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Acked-by: NJoonyoung Shim <jy0922.shim@samsung.com>
      Acked-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      083500ba
    • D
      drm/i915: Remove bogus locking check in the hangcheck code · b838cbee
      Daniel Vetter 提交于
      You can _never_ assert that a lock is not held, except in some very
      restricted corner cases where it's guranteed that your code is running
      single-threade (e.g. driver load before you've published any pointers
      leading to that lock).
      
      In addition the early return breaks a bunch of testcases since with
      highly concurrent hangcheck stress tests the reset fails to work and
      the test doesn't recover and time out.
      
      This regression has been introduced in
      
      commit b8d24a06
      Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Date:   Wed Jan 28 17:03:14 2015 +0200
      
          drm/i915: Remove nested work in gpu error handling
      
      Aside: It is possible to check whether a given task doesn't hold a
      lock, but only when lockdep is enabled, using the lockdep_assert_held
      stuff.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88908Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      b838cbee
  9. 03 2月, 2015 3 次提交
    • V
      drm/modes: Print the mode status in human readable form · f79d1548
      Ville Syrjälä 提交于
      Currently when a mode is rejected the reason is printed as a raw number.
      Having to manually decode that to a enum drm_mode_status value is
      tiresome. Have the code do the decoding instead and print the result
      in a human readable format.
      
      Just having an array of strings indexed with the mode status doesn't
      work since the enum includes negative values. So we offset the status
      by +3 which makes all the indexes non-negative. Also add a bit of
      paranoia into the code to catch out of bounds accesses in case
      someone adds more enum values but forgets to update the code.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f79d1548
    • V
      drm/modes: Print the mode status in human readable form · e4bf44b3
      Ville Syrjälä 提交于
      Currently when a mode is rejected the reason is printed as a raw number.
      Having to manually decode that to a enum drm_mode_status value is
      tiresome. Have the code do the decoding instead and print the result
      in a human readable format.
      
      Just having an array of strings indexed with the mode status doesn't
      work since the enum includes negative values. So we offset the status
      by +3 which makes all the indexes non-negative. Also add a bit of
      paranoia into the code to catch out of bounds accesses in case
      someone adds more enum values but forgets to update the code.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      e4bf44b3
    • C
      drm: Kconfig: Let all DRM_GEM_CMA_HELPER related macros depend on HAVE_DMA_ATTRS · db88c8f4
      Chen Gang S 提交于
      DRM_GEM_CMA_HELPER is depend on HAVE_DMA_ATTRS, or it will break the
      building. The related error (with allmodconfig under xtensa):
      
          CC [M]  drivers/gpu/drm/drm_gem_cma_helper.o
        drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_create':
        drivers/gpu/drm/drm_gem_cma_helper.c:110:19: error: implicit declaration of function 'dma_alloc_writecombine' [-Werror=implicit-function-declaration]
          cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
                           ^
        drivers/gpu/drm/drm_gem_cma_helper.c:110:17: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
          cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
                         ^
        drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_free_object':
        drivers/gpu/drm/drm_gem_cma_helper.c:193:3: error: implicit declaration of function 'dma_free_writecombine' [-Werror=implicit-function-declaration]
           dma_free_writecombine(gem_obj->dev->dev, cma_obj->base.size,
           ^
        drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_mmap_obj':
        drivers/gpu/drm/drm_gem_cma_helper.c:330:8: error: implicit declaration of function 'dma_mmap_writecombine' [-Werror=implicit-function-declaration]
          ret = dma_mmap_writecombine(cma_obj->base.dev->dev, vma,
                ^
      Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      db88c8f4
  10. 02 2月, 2015 2 次提交
    • D
      Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next · 44df9c41
      Dave Airlie 提交于
      Rebase of main pull for 3.20.  There was a mid-air collision between
      the bridge changes and msm eDP support.  And atomic dpms support broke
      msm somewhat, due to using prepare/commit hooks in a different way.
      Compared to the initial pull req, this fixes up a memory leak caused
      by the bridge changes, rebases the eDP support on the bridge changes,
      and migrates to the atomic dpms hooks to fix the dpms breakage.
      
      Highlights (from original pull req):
      
      1) YUV support for mdp4 and mdp5
      2) eDP support
      3) hw cursor support for mdp5[*]
      4) additional hdmi support for apq8084 (snapdragon 805)
      5) few bug fixes
      
      Note that I may have a later pull to enable hdmi hpd irqs.. but
      (un)fortunately I seem to have a particularly troublesome monitor..  I
      managed to figure out a workaround for spurious hpd disconnect irqs
      that works with some of my boards but not others, so holding off on
      that patch for now.  There are also patches for HDCP support, but
      those are waiting on some scm patches outside of drm so I think
      waiting until 3.21 at this point.
      
      * 'msm-next' of git://people.freedesktop.org/~robclark/linux: (22 commits)
        drm/msm: add moduleparam to disable fbdev
        drm/msm: fix build error with W=1
        drm/msm/mdp5: Fix negative SMP block allocation
        drm/msm/hdmi: disallow interlaced
        drm/msm/atomic: fix issue with gnome-shell wayland
        drm/msm/mdp5: Add hardware cursor support
        drm/msm/hdmi: rework hdmi configurations, using dt_match[]
        drm/msm/hdmi: Add HDMI platform config for apq8084
        drm/msm/hdmi: use dynamic allocation for hdmi resources
        drm/msm/mdp5: fix parameter type for mdp5_ctl_set_intf()
        drm/msm/dp: use link power helpers
        drm/msm: Add the eDP connector in msm drm driver (V2)
        drm/msm: Initial add eDP support in msm drm driver (v5)
        drm/msm/mdp4: add YUV format support
        drm/msm/mdp5: add NV12 support for MDP5
        drm/msm/mdp: add common YUV information for MDP4/MDP5
        drm/msm: update generated headers
        drm/msm: Do not BUG_ON(!spin_is_locked()) on UP
        drm/msm/hdmi: fix memory leak after bridge changes
        drm/msm: fix fallout of atomic dpms changes
        ...
      44df9c41
    • R
      drm/msm: add moduleparam to disable fbdev · e90dfec7
      Rob Clark 提交于
      Useful to avoid recompiling to disable fbdev.  Useful because otherwise
      the first modeset happens under console_lock (ie. debugging sadness).
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      e90dfec7