1. 16 8月, 2015 2 次提交
  2. 15 8月, 2015 1 次提交
  3. 12 6月, 2015 2 次提交
    • R
      drm/msm: fix timeout calculation · 56c2da83
      Rob Clark 提交于
      The 'timeout' value comes from userspace (CLOCK_MONOTONIC), but
      converting this directly to jiffies doesn't take into account the
      initial jiffies count at boot, which may differ from the base time
      of CLOCK_MONOTONIC.
      
      TODO: add ktime_delta_jiffies() when rebasing on 4.1 and use that
      instead of ktime_sub/ktime_to_timespec/timespec_to_jiffies combo (as
      suggested by Arnd)
      
      v2: switch over from 'struct timespec' to ktime_t throughout, since
      'struct timespec' will be deprecated (as suggested by Arnd)
      v3: minor cosmetic tweaks
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      56c2da83
    • R
      drm/msm: add missing DRIVER_ATOMIC flag · a5436e1d
      Rob Clark 提交于
      Somehow this got lost when msm atomic support was first merged.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      a5436e1d
  4. 15 5月, 2015 1 次提交
    • R
      drm/msm: fix locking inconsistencies in gpu->destroy() · 774449eb
      Rob Clark 提交于
      In error paths, this was being called without struct_mutex held.
      Leading to panics like:
      
        msm 1a00000.qcom,mdss_mdp: No memory protection without IOMMU
        Kernel panic - not syncing: BUG!
        CPU: 0 PID: 1409 Comm: cat Not tainted 4.0.0-dirty #4
        Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
        Call trace:
        [<ffffffc000089c78>] dump_backtrace+0x0/0x118
        [<ffffffc000089da0>] show_stack+0x10/0x20
        [<ffffffc0006686d4>] dump_stack+0x84/0xc4
        [<ffffffc0006678b4>] panic+0xd0/0x210
        [<ffffffc0003e1ce4>] drm_gem_object_free+0x5c/0x60
        [<ffffffc000402870>] adreno_gpu_cleanup+0x60/0x80
        [<ffffffc0004035a0>] a3xx_destroy+0x20/0x70
        [<ffffffc0004036f4>] a3xx_gpu_init+0x84/0x108
        [<ffffffc0004018b8>] adreno_load_gpu+0x58/0x190
        [<ffffffc000419dac>] msm_open+0x74/0x88
        [<ffffffc0003e0a48>] drm_open+0x168/0x400
        [<ffffffc0003e7210>] drm_stub_open+0xa8/0x118
        [<ffffffc0001a0e84>] chrdev_open+0x94/0x198
        [<ffffffc000199f88>] do_dentry_open+0x208/0x310
        [<ffffffc00019a4c4>] vfs_open+0x44/0x50
        [<ffffffc0001aa26c>] do_last.isra.14+0x2c4/0xc10
        [<ffffffc0001aac38>] path_openat+0x80/0x5e8
        [<ffffffc0001ac354>] do_filp_open+0x2c/0x98
        [<ffffffc00019b60c>] do_sys_open+0x13c/0x228
        [<ffffffc00019b72c>] SyS_openat+0xc/0x18
        CPU1: stopping
      
      But there isn't any particularly good reason to hold struct_mutex for
      teardown, so just standardize on calling it without the mutex held and
      use the _unlocked() versions for GEM obj unref'ing
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      774449eb
  5. 14 5月, 2015 3 次提交
  6. 02 4月, 2015 3 次提交
  7. 02 2月, 2015 2 次提交
  8. 19 12月, 2014 1 次提交
  9. 18 12月, 2014 1 次提交
    • D
      drm/atomic-helper: Again check modeset *before* plane states · b4274fbe
      Daniel Vetter 提交于
      This essentially reverts
      
      commit 934ce1c2
      Author: Rob Clark <robdclark@gmail.com>
      Date:   Wed Nov 19 16:41:33 2014 -0500
      
          drm/atomic: check mode_changed *after* atomic_check
      
      Depending upon the driver both orders (or maybe even interleaving) is
      required:
      - If ->atomic_check updates ->mode_changed then helper_check_modeset
        must be run afters.
      - If ->atomic_check depends upon accurate adjusted dotclock values for
        e.g. watermarks, then helper_check_modeset must be run first.
      
      The failure mode in the first case is usually a totally angry hw
      because the pixel format switching doesn't happen. The failure mode in
      the later case is usually nothing, since in most cases the old
      adjusted mode from the previous modeset wont be too far off to be a
      problem. So just underruns and perhaps even just suboptimal (from a
      power consumption) watermarks.
      
      Furthermore in the transitional helpers we only call ->atomic_check
      after the new modeset state has been fully set up (and hence
      computed).
      
      Given that asymmetry in expected failure modes I think it's safer to
      go back to the older order. So do that and give msm a special check
      function to compensate.
      
      Also update kerneldoc to explain this a bit.
      
      v2: Actually add the missing hunk Rob spotted.
      
      v3: Move msm_atomic_check into msm_atomic.c, requested by Rob.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      Tested-by: NRob Clark <robdclark@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      b4274fbe
  10. 17 11月, 2014 3 次提交
  11. 20 10月, 2014 1 次提交
  12. 11 9月, 2014 1 次提交
  13. 10 9月, 2014 4 次提交
  14. 26 8月, 2014 1 次提交
  15. 04 8月, 2014 2 次提交
    • R
      drm/msm: fix potential deadlock in gpu init · a1ad3523
      Rob Clark 提交于
      Somewhere along the way, the firmware loader sprouted another lock
      dependency, resulting in possible deadlock scenario:
      
       &dev->struct_mutex --> &sb->s_type->i_mutex_key#2 --> &mm->mmap_sem
      
      which is problematic vs things like gem mmap.
      
      So introduce a separate mutex to synchronize gpu init.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      a1ad3523
    • R
      drm/msm: DT support for 8960/8064 (v3) · 41e69778
      Rob Clark 提交于
      Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
      add necessary DT support so that we can use drm/msm on upstream kernel.
      
      v2: update for review comments
      v3: rebase on component helper changes
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      41e69778
  16. 05 7月, 2014 1 次提交
  17. 22 6月, 2014 1 次提交
  18. 05 6月, 2014 1 次提交
  19. 02 6月, 2014 3 次提交
  20. 23 4月, 2014 1 次提交
  21. 31 3月, 2014 3 次提交
  22. 14 1月, 2014 1 次提交
  23. 10 1月, 2014 1 次提交
    • R
      drm/msm: add mdp5/apq8x74 · 06c0dd96
      Rob Clark 提交于
      Add support for the new MDP5 display controller block.  The mapping
      between parts of the display controller and KMS is:
      
        plane   -> PIPE{RGBn,VIGn}             \
        crtc    -> LM (layer mixer)            |-> MDP "device"
        encoder -> INTF                        /
        connector -> HDMI/DSI/eDP/etc          --> other device(s)
      
      Unlike MDP4, it appears we can get by with a single encoder, rather
      than needing a different implementation for DTV, DSI, etc.  (Ie. the
      register interface is same, just different bases.)
      
      Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
      routed through MDP.
      
      And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
      which blocks need to be allocated to the active pipes based on fetch
      stride.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      06c0dd96