1. 19 3月, 2014 2 次提交
  2. 18 3月, 2014 1 次提交
  3. 13 3月, 2014 6 次提交
    • T
      drm/vmwgfx: Fix a surface reference corner-case in legacy emulation mode · 4b0c8252
      Thomas Hellstrom 提交于
      If running on a gb-object capable device with a non-gb capable surface
      exporter (X server) and a gb capable surface referencing client (GL driver),
      the referencing client expects to find a shareable backing buffer attached to
      the surface at reference time. This may not be the case if the surface has
      not yet been validated. This would cause the surface reference IOCTL to
      return an error.
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
      4b0c8252
    • A
      drm/radeon/cik: properly set compute ring status on disable · b2b3d8d9
      Alex Deucher 提交于
      When we disable the rings, set the status properly.  If
      not other code pathes may try and use the rings which are
      not functional at this point.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      b2b3d8d9
    • A
      drm/radeon/cik: stop the sdma engines in the enable() function · 07ae78c9
      Alex Deucher 提交于
      We always stop the rings when disabling the engines so just
      call the stop functions directly from the sdma enable function.
      This way the rings' status is set correctly on suspend so
      there are no problems on resume.  Fixes resume failures that
      result in acceleration getting disabled.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      07ae78c9
    • A
      drm/radeon/cik: properly set sdma ring status on disable · 7b1bbe88
      Alex Deucher 提交于
      When we disable the rings, set the status properly.  If
      not other code pathes may try and use the rings which are
      not functional at this point.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      7b1bbe88
    • A
      drm/radeon: fix runpm disabling on non-PX harder · 78488659
      Alex Deucher 提交于
      Make sure runtime pm is disabled on non-PX hardware.
      Should fix powerdown problems without displays attached.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      78488659
    • R
      drm/ttm: don't oops if no invalidate_caches() · 9ef7506f
      Rob Clark 提交于
      A few of the simpler TTM drivers (cirrus, ast, mgag200) do not implement
      this function.  Yet can end up somehow with an evicted bo:
      
        BUG: unable to handle kernel NULL pointer dereference at           (null)
        IP: [<          (null)>]           (null)
        PGD 16e761067 PUD 16e6cf067 PMD 0
        Oops: 0010 [#1] SMP
        Modules linked in: bnep bluetooth rfkill fuse ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter ip_tables sg btrfs zlib_deflate raid6_pq xor dm_queue_length iTCO_wdt iTCO_vendor_support coretemp kvm dcdbas dm_service_time microcode serio_raw pcspkr lpc_ich mfd_core i7core_edac edac_core ses enclosure ipmi_si ipmi_msghandler shpchp acpi_power_meter mperf nfsd auth_rpcgss nfs_acl lockd uinput sunrpc dm_multipath xfs libcrc32c ata_generic pata_acpi sr_mod cdrom
         sd_mod usb_storage mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit lpfc drm_kms_helper ttm crc32c_intel ata_piix bfa drm ixgbe libata i2c_core mdio crc_t10dif ptp crct10dif_common pps_core scsi_transport_fc dca scsi_tgt megaraid_sas bnx2 dm_mirror dm_region_hash dm_log dm_mod
        CPU: 16 PID: 2572 Comm: X Not tainted 3.10.0-86.el7.x86_64 #1
        Hardware name: Dell Inc. PowerEdge R810/0H235N, BIOS 0.3.0 11/14/2009
        task: ffff8801799dabc0 ti: ffff88016c884000 task.ti: ffff88016c884000
        RIP: 0010:[<0000000000000000>]  [<          (null)>]           (null)
        RSP: 0018:ffff88016c885ad8  EFLAGS: 00010202
        RAX: ffffffffa04e94c0 RBX: ffff880178937a20 RCX: 0000000000000000
        RDX: 0000000000000000 RSI: 0000000000240004 RDI: ffff880178937a00
        RBP: ffff88016c885b60 R08: 00000000000171a0 R09: ffff88007cf171a0
        R10: ffffea0005842540 R11: ffffffff810487b9 R12: ffff880178937b30
        R13: ffff880178937a00 R14: ffff88016c885b78 R15: ffff880179929400
        FS:  00007f81ba2ef980(0000) GS:ffff88007cf00000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000000000000 CR3: 000000016e763000 CR4: 00000000000007e0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
        Stack:
         ffffffffa0306fae ffff8801799295c0 0000000000260004 0000000000000001
         ffff88016c885b60 ffffffffa0307669 00ff88007cf17738 ffff88017cf17700
         ffff880178937a00 ffff880100000000 ffff880100000000 0000000079929400
        Call Trace:
         [<ffffffffa0306fae>] ? ttm_bo_handle_move_mem+0x54e/0x5b0 [ttm]
         [<ffffffffa0307669>] ? ttm_bo_mem_space+0x169/0x340 [ttm]
         [<ffffffffa0307bd7>] ttm_bo_move_buffer+0x117/0x130 [ttm]
         [<ffffffff81130001>] ? perf_event_init_context+0x141/0x220
         [<ffffffffa0307cb1>] ttm_bo_validate+0xc1/0x130 [ttm]
         [<ffffffffa04e7377>] mgag200_bo_pin+0x87/0xc0 [mgag200]
         [<ffffffffa04e56c4>] mga_crtc_cursor_set+0x474/0xbb0 [mgag200]
         [<ffffffff811971d2>] ? __mem_cgroup_commit_charge+0x152/0x3b0
         [<ffffffff815c4182>] ? mutex_lock+0x12/0x2f
         [<ffffffffa0201433>] drm_mode_cursor_common+0x123/0x170 [drm]
         [<ffffffffa0205231>] drm_mode_cursor_ioctl+0x41/0x50 [drm]
         [<ffffffffa01f5ca2>] drm_ioctl+0x502/0x630 [drm]
         [<ffffffff815cbab4>] ? __do_page_fault+0x1f4/0x510
         [<ffffffff8101cb68>] ? __restore_xstate_sig+0x218/0x4f0
         [<ffffffff811b4445>] do_vfs_ioctl+0x2e5/0x4d0
         [<ffffffff8124488e>] ? file_has_perm+0x8e/0xa0
         [<ffffffff811b46b1>] SyS_ioctl+0x81/0xa0
         [<ffffffff815d05d9>] system_call_fastpath+0x16/0x1b
        Code:  Bad RIP value.
        RIP  [<          (null)>]           (null)
         RSP <ffff88016c885ad8>
        CR2: 0000000000000000
      Signed-off-by: NRob Clark <rclark@redhat.com>
      Reviewed-by: NJérôme Glisse <jglisse@redhat.com>
      Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
      Cc: stable@vger.kernel.org
      9ef7506f
  4. 12 3月, 2014 4 次提交
    • D
      drm/i915: Don't enable display error interrupts from the start · 5c673b60
      Daniel Vetter 提交于
      We need to enable interrupt processing before all the modeset
      state is set up. But that means we can fall over when we get a pipe
      underrun. This shouldn't happen as long as the bios works correctly
      but as usual this turns out to be wishful thinking.
      
      So disable error interrupts at irq install time and rely on the
      re-enabling code in the modeset functions to take care of this.
      
      Note that due to the SDE interrupt handling race we must
      uncondtionally enable all interrupt sources in SDEIER, hence no need
      to enable the SERR bit specifically.
      
      On gmch platforms we don't have an explicit enable/mask bit for fifo
      underruns. Fixing this up would require a bit of software tracking,
      hence is material for a separate patch. To make this possible we need
      to switch all gmch platforms to the new pipestat interrupt handling
      scheme Imre implemented for vlv, and then also add a safe form of sw
      state checking to __cpu_fifo_underrun_reporting_enabled a bit.
      
      v2: Also handle the ilk/snb cpu fifo underrun bits accordingly.
      Spotted by Ville.
      
      v3: Also handle the south interrupt underrun bits on ibx. Again
      spotted by Ville.
      Reported-by: NRob Clark <robdclark@gmail.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: stable@vger.kernel.org
      Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      5c673b60
    • V
      drm/i915: Fix scanline counter fixup on BDW · 24302624
      Ville Syrjälä 提交于
      The display interrupts changed on BDW, so the current ILK-HSW specific
      code in ilk_pipe_in_vblank_locked() doesn't work there. Add the required
      bits for BDW, and while at it, change the existing code to use nicer
      looking vblank status bit macros.
      
      Also remove the now stale __raw_i915_read16() definition which was
      left over from the failed gen2 ISR experiment.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73962Tested-by: NLu Hua <huax.lu@intel.com>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      24302624
    • V
      drm/i915: Add a workaround for HSW scanline counter weirdness · fcb81823
      Ville Syrjälä 提交于
      On HSW the scanline counter seems to behave differently depending on
      the output type. eDP on port A does what you would expect an the normal
      +1 fixup is sufficient to cover it. But on HDMI outputs we seem to need
      a +2 fixup. Just assume we always need the +2 fixup and accept the
      slight inaccuracy on eDP.
      
      This fixes a regression introduced in:
       commit 8072bfa6
       Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
       Date:   Mon Oct 28 21:22:52 2013 +0200
      
          drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos()
      
      That commit removed the heuristic that tried to fix up the timestamps
      for vblank interrupts that fire a bit too early. Since then the vblank
      timestamp code would treat some vblank interrupts as spurious since the
      scanline counter would indicate that vblank_start wasn't reached yet.
      That in turn lead to incorrect vblank event sequence numbers being
      reported to userspace, which lead to unsteady framerate in applications
      such as XBMC which uses them for timing purposes.
      
      v2: Remember to call ilk_pipe_in_vblank_locked() on HSW too (Mika)
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75725
      Tested-by: bugzilla1@gmx.com
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      fcb81823
    • T
      drm/ttm: Work around performance regression with VM_PFNMAP · 0e6d6ec0
      Thomas Hellstrom 提交于
      A performance regression was introduced in TTM in linux 3.13 when we started using
      VM_PFNMAP for shared mappings. In theory this should've been faster due to
      less page book-keeping but it appears like VM_PFNMAP + x86 PAT + write-combine
      is a particularly cpu-hungry combination, as seen by largely increased
      cpu-usage on r200 GL video playback.
      
      Until we've sorted out why, revert to always use VM_MIXEDMAP.
      Reference: freedesktop.org bugzilla bug #75719
      
      Reported-and-tested-by: <smoki00790@gmail.com>
      Acked-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Cc: stable@vger.kernel.org
      0e6d6ec0
  5. 07 3月, 2014 7 次提交
  6. 06 3月, 2014 1 次提交
    • B
      drm/i915: Fix PSR programming · 24bd9bf5
      Ben Widawsky 提交于
      | has a higher precedence than ?. Therefore, the calculation doesn't do
      at all what you would expect. Thanks to Ken for convincing me that this
      was indeed the issue. Send me back to C programmer school, please.
      
      I'm sort of surprised PSR was continuing to work for people. It should
      be broken IMO (and it was broken for me, but I had assumed it never
      worked).
      
      Regression from:
      commit ed8546ac
      Author: Ben Widawsky <benjamin.widawsky@intel.com>
      Date:   Mon Nov 4 22:45:05 2013 -0800
      
          drm/i915/bdw: Support eDP PSR
      
      Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
      Cc: Kenneth Graunke <kenneth.w.graunke@intel.com>
      Cc: Art Runyan <arthur.j.runyan@intel.com>
      Reported-by: N"Kumar, Kiran S" <kiran.s.kumar@intel.com>
      Cc: stable@vger.kernel.org [v3.13+]
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      24bd9bf5
  7. 04 3月, 2014 4 次提交
  8. 03 3月, 2014 3 次提交
    • I
      drm/i915: fix pch pci device enumeration · bcdb72ac
      Imre Deak 提交于
      pci_get_class(class, from) drops the refcount for 'from', so the
      extra pci_dev_put we do on it will result in a use after free bug
      starting with the WARN below.
      
      Regression introduced in
      
      commit 6a9c4b35
      Author: Rui Guo <firemeteor@users.sourceforge.net>
      Date:   Wed Jun 19 21:10:23 2013 +0800
      
          drm/i915: Fix PCH detect with multiple ISA bridges in VM
      
      [  164.338460] WARNING: CPU: 1 PID: 2094 at include/linux/kref.h:47 klist_next+0xae/0x110()
      [  164.347731] CPU: 1 PID: 2094 Comm: modprobe Tainted: G           O 3.13.0-imre+ #354
      [  164.356468] Hardware name: Intel Corp. VALLEYVIEW B0 PLATFORM/NOTEBOOK, BIOS BYTICRB1.X64.0062.R70.1310112051 10/11/2013
      [  164.368796] Call Trace:
      [  164.371609]  [<ffffffff816a32a6>] dump_stack+0x4e/0x7a
      [  164.377447]  [<ffffffff8104f75d>] warn_slowpath_common+0x7d/0xa0
      [  164.384238]  [<ffffffff8104f83a>] warn_slowpath_null+0x1a/0x20
      [  164.390851]  [<ffffffff8169aeae>] klist_next+0xae/0x110
      [  164.396777]  [<ffffffff8130a110>] ? pci_do_find_bus+0x70/0x70
      [  164.403286]  [<ffffffff813cb4a9>] bus_find_device+0x89/0xc0
      [  164.409719]  [<ffffffff8130a373>] pci_get_dev_by_id+0x63/0xa0
      [  164.416238]  [<ffffffff8130a4e4>] pci_get_class+0x44/0x50
      [  164.422433]  [<ffffffffa034821f>] intel_dsm_detect+0x16f/0x1f0 [i915]
      [  164.429801]  [<ffffffffa03482ae>] intel_register_dsm_handler+0xe/0x10 [i915]
      [  164.437831]  [<ffffffffa02d30fe>] i915_driver_load+0xafe/0xf30 [i915]
      [  164.445126]  [<ffffffff8158a150>] ? intel_alloc_coherent+0x110/0x110
      [  164.452340]  [<ffffffffa0148c07>] drm_dev_register+0xc7/0x150 [drm]
      [  164.459462]  [<ffffffffa014b23f>] drm_get_pci_dev+0x11f/0x1f0 [drm]
      [  164.466554]  [<ffffffff816abb81>] ? _raw_spin_unlock_irqrestore+0x51/0x70
      [  164.474287]  [<ffffffffa02cf7a6>] i915_pci_probe+0x56/0x60 [i915]
      [  164.481185]  [<ffffffff8130a028>] pci_device_probe+0x78/0xf0
      [  164.487603]  [<ffffffff813cd495>] driver_probe_device+0x155/0x350
      [  164.494505]  [<ffffffff813cd74e>] __driver_attach+0x6e/0xa0
      [  164.500826]  [<ffffffff813cd6e0>] ? __device_attach+0x50/0x50
      [  164.507333]  [<ffffffff813cb2be>] bus_for_each_dev+0x6e/0xc0
      [  164.513752]  [<ffffffff813ccefe>] driver_attach+0x1e/0x20
      [  164.519870]  [<ffffffff813cc958>] bus_add_driver+0x138/0x260
      [  164.526289]  [<ffffffffa0188000>] ? 0xffffffffa0187fff
      [  164.532116]  [<ffffffff813cde78>] driver_register+0x98/0xe0
      [  164.538558]  [<ffffffffa0188000>] ? 0xffffffffa0187fff
      [  164.544389]  [<ffffffff813087b0>] __pci_register_driver+0x60/0x70
      [  164.551336]  [<ffffffffa014b37d>] drm_pci_init+0x6d/0x120 [drm]
      [  164.558040]  [<ffffffffa0188000>] ? 0xffffffffa0187fff
      [  164.563928]  [<ffffffffa018806a>] i915_init+0x6a/0x6c [i915]
      [  164.570363]  [<ffffffff810002da>] do_one_initcall+0xaa/0x160
      [  164.576783]  [<ffffffff8103b140>] ? set_memory_nx+0x40/0x50
      [  164.583100]  [<ffffffff810ce7f5>] load_module+0x1fb5/0x2550
      [  164.589410]  [<ffffffff810caab0>] ? store_uevent+0x40/0x40
      [  164.595628]  [<ffffffff810cee7d>] SyS_init_module+0xed/0x100
      [  164.602048]  [<ffffffff816b3c52>] system_call_fastpath+0x16/0x1b
      
      v2: simplify the loop further (Chris)
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Reported-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65652
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74161Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      bcdb72ac
    • A
      drm/i915: Resolving the memory region conflict for Stolen area · 3617dc96
      Akash Goel 提交于
      There is a conflict seen when requesting the kernel to reserve
      the physical space used for the stolen area. This is because
      some BIOS are wrapping the stolen area in the root PCI bus, but have
      an off-by-one error. As a workaround we retry the reservation with an
      offset of 1 instead of 0.
      
      v2: updated commit message & the comment in source file (Daniel)
      Signed-off-by: NAkash Goel <akash.goel@intel.com>
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Tested-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      3617dc96
    • J
      drm/i915: use backlight legacy combination mode also for i915gm/i945gm · b6ab66aa
      Jani Nikula 提交于
      i915gm and i945gm also seem to use and need the legacy combination mode
      bit in BLC_PWM_CTL.
      
      v2: Also do this for i915gm (Ville).
      Reported-and-tested-by: NLuis Ortega <luiorpe1@gmail.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75001Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      b6ab66aa
  9. 02 3月, 2014 3 次提交
  10. 28 2月, 2014 7 次提交
  11. 21 2月, 2014 1 次提交
  12. 19 2月, 2014 1 次提交