1. 12 6月, 2015 32 次提交
  2. 21 5月, 2015 1 次提交
  3. 15 5月, 2015 3 次提交
    • 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
    • H
      drm/msm/dsi: Simplify the code to get the number of read byte · ec1936eb
      Hai Li 提交于
      During cmd rx, only new versions of H/W provide register to read back
      the real number of byte returned by panel. For the old versions, reading
      this register will not get the right number. In fact, we only need to
      assume the returned data is the same size as we expected, because later
      we will check the data type to detect error.
      Signed-off-by: NHai Li <hali@codeaurora.org>
      ec1936eb
    • H
      drm/msm: Attach assigned encoder to eDP and DSI connectors · 6f6b2879
      Hai Li 提交于
      drm_mode_connector_attach_encoder() function call is missing
      during eDP and DSI connector initialization. As a result,
      no encoder is returned by DRM_IOCTL_MODE_GETCONNECTOR system
      call. This change is to fix this issue.
      Signed-off-by: NHai Li <hali@codeaurora.org>
      6f6b2879
  4. 14 5月, 2015 4 次提交
    • R
      drm/msm: setup vram after component_bind_all() · 13f15565
      Rob Clark 提交于
      First of all, we don't want -EPROBE_DEFER when trying to bind children
      to cause us to forget to free our vram.  And second we don't want vram
      allocation fail to trigger _unbind_all() before _bind_all().
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      13f15565
    • R
      drm/msm/dsi: use pr_err_ratelimited · ff431fa4
      Rob Clark 提交于
      When things go badly we can get a lot of these error irqs.  Let's not
      DoS the user.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      ff431fa4
    • S
      drm/msm: fix unbalanced DRM framebuffer init/destroy · 7194b62c
      Stephane Viau 提交于
      When msm_framebuffer_init() fails before calling drm_framebuffer_init(),
      drm_framebuffer_cleanup() [called in msm_framebuffer_destroy()]
      is still being called even though drm_framebuffer_init() was not
      called for that buffer. Thus a NULL pointer derefencing:
      
      [  247.529691] Unable to handle kernel NULL pointer dereference at virtual address 0000027c
      ...
      [  247.563996] PC is at __mutex_lock_slowpath+0x94/0x3a8
      ...
      [  247.823025] [<c07c3c78>] (__mutex_lock_slowpath) from [<c07c3fac>] (mutex_lock+0x20/0x3c)
      [  247.831186] [<c07c3fac>] (mutex_lock) from [<c0347cf0>] (drm_framebuffer_cleanup+0x18/0x38)
      [  247.839520] [<c0347cf0>] (drm_framebuffer_cleanup) from [<c036d138>] (msm_framebuffer_destroy+0x48/0x100)
      [  247.849066] [<c036d138>] (msm_framebuffer_destroy) from [<c036d580>] (msm_framebuffer_init+0x1e8/0x228)
      [  247.858439] [<c036d580>] (msm_framebuffer_init) from [<c036d630>] (msm_framebuffer_create+0x70/0x134)
      [  247.867642] [<c036d630>] (msm_framebuffer_create) from [<c03493ec>] (internal_framebuffer_create+0x67c/0x7b4)
      [  247.877537] [<c03493ec>] (internal_framebuffer_create) from [<c034ce34>] (drm_mode_addfb2+0x20/0x98)
      [  247.886650] [<c034ce34>] (drm_mode_addfb2) from [<c034071c>] (drm_ioctl+0x240/0x420)
      [  247.894378] [<c034071c>] (drm_ioctl) from [<c011df7c>] (do_vfs_ioctl+0x4e4/0x5a4)
      ...
      Signed-off-by: NStephane Viau <sviau@codeaurora.org>
      [plus initialize msm_fb to NULL to -Rob]
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      7194b62c
    • S
      drm/msm/mdp5: Fix iteration on INTF config array · fe34464d
      Stephane Viau 提交于
      The current iteration in get_dsi_id_from_intf() is wrong:
      instead of iterating until hw_cfg->intf.count, we need to iterate
      until MDP5_INTF_NUM_MAX here.
      
      Let's take the example of msm8x16:
      
       hw_cfg->intf.count = 1
       intfs[0] = INTF_Disabled
       intfs[1] = INTF_DSI
      
      If we stop iterating once i reaches hw_cfg->intf.count (== 1),
      we will miss the test for intfs[1].
      
      Actually, this hw_cfg->intf.count entry is quite confusing and is not
      (or *should not be*) used anywhere else; let's remove it.
      Signed-off-by: NStephane Viau <sviau@codeaurora.org>
      fe34464d