1. 02 10月, 2015 11 次提交
    • D
      drm/dp/mst: drop cancel work sync in the mstb destroy path (v2) · 274d8352
      Dave Airlie 提交于
      Since 9eb1e57f
      drm/dp/mst: make sure mst_primary mstb is valid in work function
      
      we validate the mstb structs in the work function, and doing
      that takes a reference. So we should never get here with the
      work function running using the mstb device, only if the work
      function hasn't run yet or is running for another mstb.
      
      So we don't need to sync the work here, this was causing
      lockdep spew as below.
      
      [  +0.000160] =============================================
      [  +0.000001] [ INFO: possible recursive locking detected ]
      [  +0.000002] 3.10.0-320.el7.rhel72.stable.backport.3.x86_64.debug #1 Tainted: G        W      ------------
      [  +0.000001] ---------------------------------------------
      [  +0.000001] kworker/4:2/1262 is trying to acquire lock:
      [  +0.000001]  ((&mgr->work)){+.+.+.}, at: [<ffffffff810b29a5>] flush_work+0x5/0x2e0
      [  +0.000007]
      but task is already holding lock:
      [  +0.000001]  ((&mgr->work)){+.+.+.}, at: [<ffffffff810b57e4>] process_one_work+0x1b4/0x710
      [  +0.000004]
      other info that might help us debug this:
      [  +0.000001]  Possible unsafe locking scenario:
      
      [  +0.000002]        CPU0
      [  +0.000000]        ----
      [  +0.000001]   lock((&mgr->work));
      [  +0.000002]   lock((&mgr->work));
      [  +0.000001]
       *** DEADLOCK ***
      
      [  +0.000001]  May be due to missing lock nesting notation
      
      [  +0.000002] 2 locks held by kworker/4:2/1262:
      [  +0.000001]  #0:  (events_long){.+.+.+}, at: [<ffffffff810b57e4>] process_one_work+0x1b4/0x710
      [  +0.000004]  #1:  ((&mgr->work)){+.+.+.}, at: [<ffffffff810b57e4>] process_one_work+0x1b4/0x710
      [  +0.000003]
      stack backtrace:
      [  +0.000003] CPU: 4 PID: 1262 Comm: kworker/4:2 Tainted: G        W      ------------   3.10.0-320.el7.rhel72.stable.backport.3.x86_64.debug #1
      [  +0.000001] Hardware name: LENOVO 20EGS0R600/20EGS0R600, BIOS GNET71WW (2.19 ) 02/05/2015
      [  +0.000008] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
      [  +0.000001]  ffffffff82c26c90 00000000a527b914 ffff88046399bae8 ffffffff816fe04d
      [  +0.000004]  ffff88046399bb58 ffffffff8110f47f ffff880461438000 0001009b840fc003
      [  +0.000002]  ffff880461438a98 0000000000000000 0000000804dc26e1 ffffffff824a2c00
      [  +0.000003] Call Trace:
      [  +0.000004]  [<ffffffff816fe04d>] dump_stack+0x19/0x1b
      [  +0.000004]  [<ffffffff8110f47f>] __lock_acquire+0x115f/0x1250
      [  +0.000002]  [<ffffffff8110fd49>] lock_acquire+0x99/0x1e0
      [  +0.000002]  [<ffffffff810b29a5>] ? flush_work+0x5/0x2e0
      [  +0.000002]  [<ffffffff810b29ee>] flush_work+0x4e/0x2e0
      [  +0.000002]  [<ffffffff810b29a5>] ? flush_work+0x5/0x2e0
      [  +0.000004]  [<ffffffff81025905>] ? native_sched_clock+0x35/0x80
      [  +0.000002]  [<ffffffff81025959>] ? sched_clock+0x9/0x10
      [  +0.000002]  [<ffffffff810da1f5>] ? local_clock+0x25/0x30
      [  +0.000002]  [<ffffffff8110dca9>] ? mark_held_locks+0xb9/0x140
      [  +0.000003]  [<ffffffff810b4ed5>] ? __cancel_work_timer+0x95/0x160
      [  +0.000002]  [<ffffffff810b4ee8>] __cancel_work_timer+0xa8/0x160
      [  +0.000002]  [<ffffffff810b4fb0>] cancel_work_sync+0x10/0x20
      [  +0.000007]  [<ffffffffa0160d17>] drm_dp_destroy_mst_branch_device+0x27/0x120 [drm_kms_helper]
      [  +0.000006]  [<ffffffffa0163968>] drm_dp_mst_link_probe_work+0x78/0xa0 [drm_kms_helper]
      [  +0.000002]  [<ffffffff810b5850>] process_one_work+0x220/0x710
      [  +0.000002]  [<ffffffff810b57e4>] ? process_one_work+0x1b4/0x710
      [  +0.000005]  [<ffffffff810b5e5b>] worker_thread+0x11b/0x3a0
      [  +0.000003]  [<ffffffff810b5d40>] ? process_one_work+0x710/0x710
      [  +0.000002]  [<ffffffff810beced>] kthread+0xed/0x100
      [  +0.000003]  [<ffffffff810bec00>] ? insert_kthread_work+0x80/0x80
      [  +0.000003]  [<ffffffff817121d8>] ret_from_fork+0x58/0x90
      
      v2: add flush_work.
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      274d8352
    • D
      drm/dp/mst: split connector registration into two parts (v2) · d9515c5e
      Dave Airlie 提交于
      In order to cache the EDID properly for tiled displays, we
      need to retrieve it before we register the connector with
      userspace, otherwise userspace can call get resources
      and try and get the edid before we've even cached it.
      
      This fixes some problems when hotplugging mst monitors,
      with X/mutter running. As mutter seems to get 0 modes
      for one of the monitors in the tile.
      
      v2: fix warning in radeon
      handle tile setting in cached path rather than
      get edid path.
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      d9515c5e
    • D
      drm/dp/mst: update the link_address_sent before sending the link address (v3) · 68d8c9fc
      Dave Airlie 提交于
      Update the state before sending the msg to close it.
      
      v2: reset value if return indicates we haven't send the msg.
      v3: just clean the code up.
      Pointed out by Adam J Richter on
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91481Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      68d8c9fc
    • D
      drm/dp/mst: fixup handling hotplug on port removal. · df4839fd
      Dave Airlie 提交于
      output ports should always have a connector, unless
      in the rare case connector allocation fails in the
      driver.
      
      In this case we only need to teardown the pdt,
      and free the struct, and there is no need to
      send a hotplug msg.
      
      In the case were we add the port to the destroy
      list we need to send a hotplug if we destroy
      any connectors, so userspace knows to reprobe
      stuff.
      
      this patch also handles port->connector allocation
      failing which should be a rare event, but makes
      the code consistent.
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      df4839fd
    • D
      drm/dp/mst: don't pass port into the path builder function · 1c960876
      Dave Airlie 提交于
      This is unnecessary and it makes it easier to see what is needed
      from port.
      
      also add blank line to make things nicer.
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      1c960876
    • A
      drm/radeon: drop radeon_fb_helper_set_par · 0c6dadbe
      Alex Deucher 提交于
      It was just a wrapper around drm_fb_helper_set_par that
      called cursor_set2 in addition.  Now that the core handles
      this, drop this radeon specific version.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      0c6dadbe
    • A
      drm: handle cursor_set2 in restore_fbdev_mode · 03f9abb2
      Alex Deucher 提交于
      If a driver uses the cursor_set2 crtc callback rather than
      cursor_set, use that.  This fixes the fbdev helper for drivers
      that use cursor_set2.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      03f9abb2
    • D
      Merge tag 'drm-intel-fixes-2015-10-01' of git://anongit.freedesktop.org/drm-intel into drm-fixes · ec403b89
      Dave Airlie 提交于
      a few i915 fixes for v4.3.
      
      * tag 'drm-intel-fixes-2015-10-01' of git://anongit.freedesktop.org/drm-intel:
        drm/i915: Call non-locking version of drm_kms_helper_poll_enable(), v2
        drm: Add a non-locking version of drm_kms_helper_poll_enable(), v2
        drm/i915: Consider HW CSB write pointer before resetting the sw read pointer
        drm/i915/skl: Don't call intel_prepare_ddi when encoder list isn't yet initialized.
      ec403b89
    • D
      Merge tag 'vmwgfx-fixes-4.3-151001' of git://people.freedesktop.org/~thomash/linux into drm-fixes · 62886a36
      Dave Airlie 提交于
      A single commit to fix a command submission hang regression.
      
      Pull request of 2015-10-01
      
      * tag 'vmwgfx-fixes-4.3-151001' of git://people.freedesktop.org/~thomash/linux:
        drm/vmwgfx: Fix a command submission hang regression
      62886a36
    • D
      Merge branch 'exynos-drm-fixes' of... · 8e592eab
      Dave Airlie 提交于
      Merge branch 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes
      
         This pull request includes regression fixups, build warnings, and
         trivial cleanups which mostly remove some codes not used anymore.
      
      * 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
        drm/exynos: Staticize local function in exynos_drm_gem.c
        drm/exynos: fimd: actually disable dp clock
        drm/exynos: dp: remove suspend/resume functions
        drm/exynos: remove unused mode_fixup() code
        drm/exynos: remove decon_mode_fixup()
        drm/exynos: remove fimd_mode_fixup()
        drm/exynos: rotator: Clock control is unused if !PM
        drm/exynos: fimc: Clock control is unused if !PM
        drm/exynos: Suspend/resume is unused if !PM
        drm/exynos: create a fake mmap offset with gem creation
        drm/exynos: remove call to drm_gem_free_mmap_offset()
        drm/exynos: Remove useless EXPORT_SYMBOL_GPLs
        drm/exynos: cleanup line feed in exynos_drm_gem_get_ioctl
        drm/exynos: cleanup function calling written twice
        drm/exynos: staticize exynos_drm_gem_init()
        drm/exynos: remove unnecessary NULL assignment
        drm/exynos: fix missed calling of drm_prime_gem_destroy()
        drm/exynos: fix layering violation of address
      8e592eab
    • D
      Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux into drm-fixes · 5b638641
      Dave Airlie 提交于
      radeon and amdgpu fixes for 4.3.
      - backlight s/r fixes
      - typo fix from Dan
      - vm debugging fix
      - remove import_gpu_mem after discussion with Daniel
      
      * 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux:
        drm/amdgpu: only print meaningful VM faults
        drm/amdgpu/cgs: remove import_gpu_mem
        drm/amdgpu:  Restore LCD backlight level on resume
        drm/radeon: Restore LCD backlight level on resume (>= R5xx)
        drm/amdgpu: signedness bug in amdgpu_cs_parser_init()
      5b638641
  2. 01 10月, 2015 6 次提交
  3. 30 9月, 2015 21 次提交
  4. 28 9月, 2015 2 次提交
    • M
      drm/i915: Consider HW CSB write pointer before resetting the sw read pointer · dfc53c5e
      Michel Thierry 提交于
      A previous commit resets the Context Status Buffer (CSB) read pointer in
      ring init
          commit c0a03a2e ("drm/i915: Reset CSB read pointer in ring init")
      
      This is generally correct, but this pointer is not reset after
      suspend/resume in some platforms (cht). In this case, the driver should
      read the register value instead of resetting the sw read counter to 0.
      Otherwise we process old events, leading to unwanted pre-emptions or
      something worse.
      
      But in other platforms (bdw) and also during GPU reset or power up, the
      CSBWP is reset to 0x7 (an invalid number), and in this case the read
      pointer should be set to 5 (the interrupt code will increment this
      counter one more time, and will start reading from CSB[0]).
      
      v2: When the CSB registers are reset, the read pointer needs to be set
      to 5, otherwise the first write (CSB[0]) won't be read (Mika).
      Replace magic numbers with GEN8_CSB_ENTRIES (6) and GEN8_CSB_PTR_MASK
      (0x07).
      
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: stable@vger.kernel.org # v4.0+
      Signed-off-by: NLei Shen <lei.shen@intel.com>
      Signed-off-by: NDeepak S <deepak.s@intel.com>
      Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      dfc53c5e
    • R
      drm/i915/skl: Don't call intel_prepare_ddi when encoder list isn't yet initialized. · bc5f2ab1
      Rodrigo Vivi 提交于
      In case something goes wrong with power well initialization we were calling
      intel_prepare_ddi during boot while encoder list isnt't initilized.
      
      [    9.618747] i915 0000:00:02.0: Invalid ROM contents
      [    9.631446] [drm] failed to find VBIOS tables
      [    9.720036] BUG: unable to handle kernel NULL pointer dereference at 00000000
      00000058
      [    9.721986] IP: [<ffffffffa014eb72>] ddi_get_encoder_port+0x82/0x190 [i915]
      [    9.723736] PGD 0
      [    9.724286] Oops: 0000 [#1] PREEMPT SMP
      [    9.725386] Modules linked in: intel_powerclamp snd_hda_intel(+) coretemp crc
      32c_intel snd_hda_codec snd_hda_core serio_raw snd_pcm snd_timer i915(+) parport
      _pc parport pinctrl_sunrisepoint pinctrl_intel nfsd nfs_acl
      [    9.730635] CPU: 0 PID: 497 Comm: systemd-udevd Not tainted 4.3.0-rc2-eywa-10
      967-g72de2cfd-dirty #2
      [    9.732785] Hardware name: Intel Corporation Cannonlake Client platform/Skyla
      ke DT DDR4 RVP8, BIOS CNLSE2R1.R00.X021.B00.1508040310 08/04/2015
      [    9.735785] task: ffff88008a704700 ti: ffff88016a1ac000 task.ti: ffff88016a1a
      c000
      [    9.737584] RIP: 0010:[<ffffffffa014eb72>]  [<ffffffffa014eb72>] ddi_get_enco
      der_port+0x82/0x190 [i915]
      [    9.739934] RSP: 0000:ffff88016a1af710  EFLAGS: 00010296
      [    9.741184] RAX: 000000000000004e RBX: ffff88008a9edc98 RCX: 0000000000000001
      [    9.742934] RDX: 000000000000004e RSI: ffffffff81fc1e82 RDI: 00000000ffffffff
      [    9.744634] RBP: ffff88016a1af730 R08: 0000000000000000 R09: 0000000000000578
      [    9.746333] R10: 0000000000001065 R11: 0000000000000578 R12: fffffffffffffff8
      [    9.748033] R13: ffff88016a1af7a8 R14: ffff88016a1af794 R15: 0000000000000000
      [    9.749733] FS:  00007eff2e1e07c0(0000) GS:ffff88016fc00000(0000) knlGS:00000
      00000000000
      [    9.751683] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    9.753083] CR2: 0000000000000058 CR3: 000000016922b000 CR4: 00000000003406f0
      [    9.754782] Stack:
      [    9.755332]  ffff88008a9edc98 ffff88008a9ed800 ffffffffa01d07b0 00000000fffb9
      09e
      [    9.757232]  ffff88016a1af7d8 ffffffffa0154ea7 0000000000000246 ffff88016a370
      080
      [    9.759182]  ffff88016a370080 ffff88008a9ed800 0000000000000246 ffff88008a9ed
      c98
      [    9.761132] Call Trace:
      [    9.761782]  [<ffffffffa0154ea7>] intel_prepare_ddi+0x67/0x860 [i915]
      [    9.763332]  [<ffffffff81a56996>] ? _raw_spin_unlock_irqrestore+0x26/0x40
      [    9.765031]  [<ffffffffa00fad01>] ? gen9_read32+0x141/0x360 [i915]
      [    9.766531]  [<ffffffffa00b43e1>] skl_set_power_well+0x431/0xa80 [i915]
      [    9.768181]  [<ffffffffa00b4a63>] skl_power_well_enable+0x13/0x20 [i915]
      [    9.769781]  [<ffffffffa00b2188>] intel_power_well_enable+0x28/0x50 [i915]
      [    9.771481]  [<ffffffffa00b4d52>] intel_display_power_get+0x92/0xc0 [i915]
      [    9.773180]  [<ffffffffa00b4fcb>] intel_display_set_init_power+0x3b/0x40 [i91
      5]
      [    9.774980]  [<ffffffffa00b5170>] intel_power_domains_init_hw+0x120/0x520 [i9
      15]
      [    9.776780]  [<ffffffffa0194c61>] i915_driver_load+0xb21/0xf40 [i915]
      
      So let's protect this case.
      
      My first attempt was to remove the intel_prepare_ddi, but Daniel had pointed out
      this is really needed to restore those registers values. And Imre pointed out
      that this case was without the flag protection and this was actually where things
      were going bad. So I've just checked and this indeed solves my issue.
      
      The regressing intel_prepare_ddi call was added in
      
      commit 1d2b9526
      Author: Damien Lespiau <damien.lespiau@intel.com>
      Date:   Fri Mar 6 18:50:53 2015 +0000
      
          drm/i915/skl: Restore the DDI translation tables when enabling PW1
      
      Cc: Imre Deak <imre.deak@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      [Jani: regression reference]
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      bc5f2ab1