1. 05 Nov, 2015 4 commits
    • Dave Airlie's avatar
      Merge tag 'drm/panel/for-4.4-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next · b26eae93
      Dave Airlie authored
      drm/panel: Changes for v4.4-rc1
      
      Just two small cleanup patches to fix coccinelle warnings.
      
      * tag 'drm/panel/for-4.4-rc1' of git://anongit.freedesktop.org/tegra/linux:
        drm/bridge: ptn3460: Fix coccinelle warnings
        drm/bridge: ps8622: Fix coccinelle warnings
      b26eae93
    • Dave Airlie's avatar
      Merge tag 'drm/tegra/for-4.4-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next · 596a1d32
      Dave Airlie authored
      drm/tegra: Changes for v4.4-rc1
      
      Just a couple of minor fixes and cleanups for this cycle.
      
      * tag 'drm/tegra/for-4.4-rc1' of git://anongit.freedesktop.org/tegra/linux:
        drm/tegra: dc: Request/free syncpoint at init/exit
        drm/tegra: fb: Remove gratuituous blank line
        gpu: host1x: Fix MLOCK's debug info
      596a1d32
    • Dave Airlie's avatar
      Merge tag 'imx-drm-next-2015-10-30' of git://git.pengutronix.de/git/pza/linux into drm-next · cb0fb271
      Dave Airlie authored
      imx-drm fixes and color format updates
      
      - Some correctness fixes found by coccinelle
      - Add drivers/gpu/ipu-v3 directory to MAINTAINERS
      - Add support for more color formats
      - Fix a regression, making displays larger than FullHD work again
      
      * tag 'imx-drm-next-2015-10-30' of git://git.pengutronix.de/git/pza/linux:
        drm/imx: hdmi: fix HDMI setup to allow modes larger than FullHD
        gpu: ipu-v3: fix div_ratio type
        gpu: ipu-v3: csi: add support for 8 bpp grayscale sensors.
        drm/imx: enable ARGB4444 16-bit color format
        gpu: ipu-v3: add support for ARGB4444 16-bit color format
        drm/imx: ipuv3-plane: enable support for RGBX8888 and RGBA8888 pixel formats
        gpu: ipu-v3: add support for RGBX8888 and RGBA8888 pixel formats
        drm/imx: enable 15-bit RGB with 1-bit alpha formats
        gpu: ipu-v3: add support for 15-bit RGB with 1-bit alpha formats
        MAINTAINERS: Add IPUv3 core driver to the i.MX DRM driver section
        gpu: ipu-v3: ipu-csi: bool test doesn't need a comparison to false
      cb0fb271
    • Dave Airlie's avatar
      Merge branch 'drm-next-4.4' of git://people.freedesktop.org/~agd5f/linux into drm-next · 793423ff
      Dave Airlie authored
      - Updated register headers for GFX 8.1 for Stoney
      - Add some new CZ revisions
      - minor pageflip optimizations
      - Fencing clean up
      - Warning fix
      - More fence cleanup
      - oops fix
      - Fiji fixes
      
      * 'drm-next-4.4' of git://people.freedesktop.org/~agd5f/linux: (29 commits)
        drm/amdgpu: group together common fence implementation
        drm/amdgpu: remove AMDGPU_FENCE_OWNER_MOVE
        drm/amdgpu: remove now unused fence functions
        drm/amdgpu: fix fence fallback check
        drm/amdgpu: fix stoping the scheduler timeout
        drm/amdgpu: cleanup on error in amdgpu_cs_ioctl()
        drm/amdgpu: update Fiji's Golden setting
        drm/amdgpu: update Fiji's rev id
        drm/amdgpu: extract common code in vi_common_early_init
        drm/amd/scheduler: don't oops on failure to load
        drm/amdgpu: don't oops on failure to load (v2)
        drm/amdgpu: don't VT switch on suspend
        drm/amdgpu: Make amdgpu_mn functions inline
        drm/amdgpu: remove amdgpu_fence_ref/unref
        drm/amdgpu: use common fence for sync
        drm/amdgpu: use the new fence_is_later
        drm/amdgpu: use common fences for VMID management v2
        drm/amdgpu: move ring_from_fence to common code
        drm/amdgpu: switch to common fence_wait_any_timeout v2
        drm/amdgpu: remove unneeded fence functions
        ...
      793423ff
  2. 04 Nov, 2015 7 commits
    • Christian König's avatar
      drm/amdgpu: group together common fence implementation · a95e2642
      Christian König authored
      And also add some missing function documentation. No functional change.
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarChunming Zhou <david1.zhou@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      a95e2642
    • Christian König's avatar
      drm/amdgpu: remove AMDGPU_FENCE_OWNER_MOVE · 7a91d6cb
      Christian König authored
      Moves are exclusive operations anyway, just use the undefined owner for those.
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarChunming Zhou <david1.zhou@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      7a91d6cb
    • Christian König's avatar
    • Christian König's avatar
      drm/amdgpu: fix fence fallback check · 24372447
      Christian König authored
      Interrupts are notorious unreliable, enable the fallback at
      a couple of more places.
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarChunming Zhou <david1.zhou@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      24372447
    • Christian König's avatar
      drm/amdgpu: fix stoping the scheduler timeout · 424839a6
      Christian König authored
      cancel_delayed_work_sync is forbidden in interrupt context.
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarChunming Zhou <david1.zhou@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      424839a6
    • Dan Carpenter's avatar
      drm/amdgpu: cleanup on error in amdgpu_cs_ioctl() · 4cfdcd9c
      Dan Carpenter authored
      We recently changed the locking in this function and now there is a
      missing unlock on error.  Also there are some other resources that we
      should probably release as well...
      
      Fixes: f48b2659 ('drm/amdgpu: fix the broken vm->mutex V2')
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      4cfdcd9c
    • Daniel Stone's avatar
      drm/i915: Fix locking around GuC firmware load · bf248ca1
      Daniel Stone authored
      The GuC firmware load requires struct_mutex to create a GEM object,
      but this collides badly with request_firmware. Move struct_mutex
      locking down into the loader itself, so we don't hold it across the
      entire load process, including request_firmware.
      
      [   20.451400] ======================================================
      [   20.451420] [ INFO: possible circular locking dependency detected ]
      [   20.451441] 4.3.0-rc5+ #1 Tainted: G        W
      [   20.451457] -------------------------------------------------------
      [   20.451477] plymouthd/371 is trying to acquire lock:
      [   20.451494]  (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0093c62>]
      drm_gem_mmap+0x112/0x290 [drm]
      [   20.451538]
                     but task is already holding lock:
      [   20.451557]  (&mm->mmap_sem){++++++}, at: [<ffffffff811fd9ac>]
      vm_mmap_pgoff+0x8c/0xf0
      [   20.451591]
                     which lock already depends on the new lock.
      
      [   20.451617]
                     the existing dependency chain (in reverse order) is:
      [   20.451640]
                     -> #3 (&mm->mmap_sem){++++++}:
      [   20.451661]        [<ffffffff8110644e>] lock_acquire+0xce/0x1c0
      [   20.451683]        [<ffffffff8120ec9a>] __might_fault+0x7a/0xa0
      [   20.451705]        [<ffffffff8127e34e>] filldir+0x9e/0x130
      [   20.451726]        [<ffffffff81295b86>] dcache_readdir+0x186/0x230
      [   20.451748]        [<ffffffff8127e117>] iterate_dir+0x97/0x130
      [   20.451769]        [<ffffffff8127e66a>] SyS_getdents+0x9a/0x130
      [   20.451790]        [<ffffffff8184f2f2>] entry_SYSCALL_64_fastpath+0x12/0x76
      [   20.451829]
                     -> #2 (&sb->s_type->i_mutex_key#2){+.+.+.}:
      [   20.451852]        [<ffffffff8110644e>] lock_acquire+0xce/0x1c0
      [   20.451872]        [<ffffffff8184b516>] mutex_lock_nested+0x86/0x400
      [   20.451893]        [<ffffffff81277790>] walk_component+0x1d0/0x2a0
      [   20.451914]        [<ffffffff812779f0>] link_path_walk+0x190/0x5a0
      [   20.451935]        [<ffffffff8127803b>] path_openat+0xab/0x1260
      [   20.451955]        [<ffffffff8127a651>] do_filp_open+0x91/0x100
      [   20.451975]        [<ffffffff81267e67>] file_open_name+0xf7/0x150
      [   20.451995]        [<ffffffff81267ef3>] filp_open+0x33/0x60
      [   20.452014]        [<ffffffff8157e1e7>] _request_firmware+0x277/0x880
      [   20.452038]        [<ffffffff8157e9e4>] request_firmware_work_func+0x34/0x80
      [   20.452060]        [<ffffffff810c7020>] process_one_work+0x230/0x680
      [   20.452082]        [<ffffffff810c74be>] worker_thread+0x4e/0x450
      [   20.452102]        [<ffffffff810ce511>] kthread+0x101/0x120
      [   20.452121]        [<ffffffff8184f66f>] ret_from_fork+0x3f/0x70
      [   20.452140]
                     -> #1 (umhelper_sem){++++.+}:
      [   20.452159]        [<ffffffff8110644e>] lock_acquire+0xce/0x1c0
      [   20.452178]        [<ffffffff8184c5c1>] down_read+0x51/0xa0
      [   20.452197]        [<ffffffff810c203b>]
      usermodehelper_read_trylock+0x5b/0x130
      [   20.452221]        [<ffffffff8157e147>] _request_firmware+0x1d7/0x880
      [   20.452242]        [<ffffffff8157e821>] request_firmware+0x31/0x50
      [   20.452262]        [<ffffffffa01b54a4>]
      intel_guc_ucode_init+0xf4/0x400 [i915]
      [   20.452305]        [<ffffffffa0213913>] i915_driver_load+0xd63/0x16e0 [i915]
      [   20.452343]        [<ffffffffa00987d9>] drm_dev_register+0xa9/0xc0 [drm]
      [   20.452369]        [<ffffffffa009ae3d>] drm_get_pci_dev+0x8d/0x1e0 [drm]
      [   20.452396]        [<ffffffffa01521e4>] i915_pci_probe+0x34/0x50 [i915]
      [   20.452421]        [<ffffffff81464675>] local_pci_probe+0x45/0xa0
      [   20.452443]        [<ffffffff81465a6d>] pci_device_probe+0xfd/0x140
      [   20.452464]        [<ffffffff8156a2e4>] driver_probe_device+0x224/0x480
      [   20.452486]        [<ffffffff8156a5c8>] __driver_attach+0x88/0x90
      [   20.452505]        [<ffffffff81567cf3>] bus_for_each_dev+0x73/0xc0
      [   20.452526]        [<ffffffff81569a7e>] driver_attach+0x1e/0x20
      [   20.452546]        [<ffffffff815695ae>] bus_add_driver+0x1ee/0x280
      [   20.452566]        [<ffffffff8156b100>] driver_register+0x60/0xe0
      [   20.453197]        [<ffffffff81464050>] __pci_register_driver+0x60/0x70
      [   20.453845]        [<ffffffffa009b070>] drm_pci_init+0xe0/0x110 [drm]
      [   20.454497]        [<ffffffffa027f092>] 0xffffffffa027f092
      [   20.455156]        [<ffffffff81002123>] do_one_initcall+0xb3/0x200
      [   20.455796]        [<ffffffff811d8c01>] do_init_module+0x5f/0x1e7
      [   20.456434]        [<ffffffff8114c4e6>] load_module+0x2126/0x27d0
      [   20.457071]        [<ffffffff8114cdf9>] SyS_finit_module+0xb9/0xf0
      [   20.457738]        [<ffffffff8184f2f2>] entry_SYSCALL_64_fastpath+0x12/0x76
      [   20.458370]
                     -> #0 (&dev->struct_mutex){+.+.+.}:
      [   20.459773]        [<ffffffff8110584f>] __lock_acquire+0x191f/0x1ba0
      [   20.460451]        [<ffffffff8110644e>] lock_acquire+0xce/0x1c0
      [   20.461074]        [<ffffffffa0093c88>] drm_gem_mmap+0x138/0x290 [drm]
      [   20.461693]        [<ffffffff8121a5ec>] mmap_region+0x3ec/0x670
      [   20.462298]        [<ffffffff8121abb2>] do_mmap+0x342/0x420
      [   20.462901]        [<ffffffff811fd9d2>] vm_mmap_pgoff+0xb2/0xf0
      [   20.463532]        [<ffffffff81218f62>] SyS_mmap_pgoff+0x1f2/0x290
      [   20.464118]        [<ffffffff8102187b>] SyS_mmap+0x1b/0x30
      [   20.464702]        [<ffffffff8184f2f2>] entry_SYSCALL_64_fastpath+0x12/0x76
      [   20.465289]
                     other info that might help us debug this:
      
      [   20.467179] Chain exists of:
                       &dev->struct_mutex --> &sb->s_type->i_mutex_key#2 -->
      &mm->mmap_sem
      
      [   20.468928]  Possible unsafe locking scenario:
      
      [   20.470161]        CPU0                    CPU1
      [   20.470745]        ----                    ----
      [   20.471325]   lock(&mm->mmap_sem);
      [   20.471902]                                lock(&sb->s_type->i_mutex_key#2);
      [   20.472538]                                lock(&mm->mmap_sem);
      [   20.473118]   lock(&dev->struct_mutex);
      [   20.473704]
                      *** DEADLOCK ***
      Signed-off-by: default avatarDaniel Stone <daniels@collabora.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      bf248ca1
  3. 03 Nov, 2015 29 commits