1. 11 Nov, 2015 2 commits
  2. 09 Nov, 2015 1 commit
    • Guenter Roeck's avatar
      drm/vc4: Add dependency on HAVE_DMA_ATTRS, and select DRM_GEM_CMA_HELPER · 2565df91
      Guenter Roeck authored
      Avoid the following build errors, seen with m68k:allmodconfig and other
      architectures which do not support HAVE_DMA_ATTRS.
      
      ERROR: "drm_gem_cma_create" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_prime_mmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_prime_get_sg_table" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_vm_ops" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_mmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_prime_vunmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_prime_import_sg_table" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_free_object" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_prime_vmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_dumb_map_offset" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_create" [drivers/gpu/drm/drm_kms_helper.ko] undefined!
      ERROR: "drm_gem_cma_describe" [drivers/gpu/drm/drm_kms_helper.ko] undefined!
      ERROR: "drm_gem_cma_free_object" [drivers/gpu/drm/drm_kms_helper.ko] undefined!
      Acked-by: default avatarEric Anholt <eric@anholt.net>
      Fixes: c8b75bca ("drm/vc4: Add KMS support for Raspberry Pi.")
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      2565df91
  3. 07 Nov, 2015 2 commits
    • Dave Airlie's avatar
      Merge tag 'drm-intel-next-fixes-2015-11-06' of... · 816d2206
      Dave Airlie authored
      Merge tag 'drm-intel-next-fixes-2015-11-06' of git://anongit.freedesktop.org/drm-intel into drm-next
      
      Here's a handful of i915 fixes for drm-next/v4.4. Imre's commit alone
      should address the remaining warnings galore you experienced on
      Skylake. Almost all of the rest are also fixes against user or QA
      reported bugs, with references.
      
      * tag 'drm-intel-next-fixes-2015-11-06' of git://anongit.freedesktop.org/drm-intel:
        drm/i915/skl: disable display side power well support for now
        drm/i915: Extend DSL readout fix to BDW and SKL.
        drm/i915: Do graphics device reset under forcewake
        drm/i915: Skip fence installation for objects with rotated views (v4)
        drm/i915: add quirk to enable backlight on Dell Chromebook 11 (2015)
        drm/i915/skl: Prevent unclaimed register writes on skylake.
        drm/i915: disable CPU PWM also on LPT/SPT backlight disable
        drm/i915: Fix maxfifo watermark calc on vlv cursor planes
        drm/i915: add hotplug activation period to hotplug update mask
      816d2206
    • Dave Airlie's avatar
      Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux into drm-next · d0baf921
      Dave Airlie authored
      One is fix for a regression in 4.3, One irq locking rework.
      
      * 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux:
        drm/vmwgfx: Relax irq locking somewhat
        drm/vmwgfx: Properly flush cursor updates and page-flips
      d0baf921
  4. 06 Nov, 2015 4 commits
  5. 05 Nov, 2015 7 commits
    • Mika Kuoppala's avatar
      drm/i915: Do graphics device reset under forcewake · 99106bc1
      Mika Kuoppala authored
      We have a timed release of a forcewake when using
      I915_READ/WRITE macros. wait_for() macro will go to quite
      long sleep if the first read doesn't satisfy the condition for
      successful exit. With these two interacting, it is possible that
      we lose the forcewake during the wait_for() and the subsequent read
      will reaquire forcewake.
      
      Further experiments with skl shows that when we lose forcewake,
      we lose the reset request we submitted. So reset request register
      is not power context saved.
      
      Grab forcewakes for all engines before starting the reset/request
      dance so that all requests stay valid for the duration of reset
      requisition across all the engines.
      
      v2: Add comment on power well sleeps. Wrap the reset handling
          under forcewake instead of just reset requests (Chris)
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92774
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: Tomi Sarvela <tomix.p.sarvela@intel.com> (v1, v2)
      Signed-off-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1446721898-1450-1-git-send-email-mika.kuoppala@intel.comSigned-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      99106bc1
    • Vivek Kasireddy's avatar
      drm/i915: Skip fence installation for objects with rotated views (v4) · 9807216f
      Vivek Kasireddy authored
      While pinning a fb object to the display plane, only install a fence
      if the object is using a normal view. This corresponds with the
      behavior found in i915_gem_object_do_pin() where the fencability
      criteria is determined only for objects with normal views.
      
      v2:
      Look at the object's map_and_fenceable flag to determine whether to
      install a fence or not (Chris).
      
      v3:
      Pin and unpin a fence only if the current view type is normal.
      
      v4:
      Extend the "view type is normal" check for pin_fence as well.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarVille Syrjala <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarVivek Kasireddy <vivek.kasireddy@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1446170078-20792-1-git-send-email-vivek.kasireddy@intel.comSigned-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      9807216f
    • Lukas Wunner's avatar
      vga_switcheroo: Drop client power state VGA_SWITCHEROO_INIT · e02328f4
      Lukas Wunner authored
      hda_intel.c:azx_probe() defers initialization of an audio controller
      on the discrete GPU if the GPU is powered off. The power state of the
      GPU is determined by calling vga_switcheroo_get_client_state().
      
      vga_switcheroo_get_client_state() returns VGA_SWITCHEROO_INIT if
      vga_switcheroo is not enabled, i.e. if no second GPU or no handler
      has registered.
      
      This can go wrong in the following scenario:
      - Driver for the integrated GPU is not loaded.
      - Driver for the discrete GPU registers with vga_switcheroo, uses driver
        power control to power down the GPU, handler cuts power to the GPU.
      - Driver for the audio controller gets loaded after the GPU was powered
        down, calls vga_switcheroo_get_client_state() which returns
        VGA_SWITCHEROO_INIT instead of VGA_SWITCHEROO_OFF.
      - Consequence: azx_probe() tries to initialize the audio controller even
        though the GPU is powered down.
      
      The power state VGA_SWITCHEROO_INIT was introduced by c8e9cf7b
      ("vga_switcheroo: Add a helper function to get the client state").
      It is not apparent what its benefit might be. The idea seems to
      be to initialize the audio controller even if the power state is
      VGA_SWITCHEROO_OFF (were vga_switcheroo enabled), but as shown
      above this can fail.
      
      Drop VGA_SWITCHEROO_INIT to solve this.
      Acked-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      e02328f4
    • 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
  6. 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
  7. 03 Nov, 2015 17 commits