1. 24 Mar, 2011 2 commits
    • Dave Airlie's avatar
      Merge remote branch 'intel/drm-intel-fixes' of ../drm-next into drm-core-next · 2d370f50
      Dave Airlie authored
      * 'intel/drm-intel-fixes' of ../drm-next:
        Revert "drm/i915: Don't save/restore hardware status page address register"
        drm/i915: Avoid unmapping pages from a NULL address space
        drm/i915: Fix use after free within tracepoint
        drm/i915: Restore missing command flush before interrupt on BLT ring
        drm/i915: Disable pagefaults along execbuffer relocation fast path
        drm/i915: Fix computation of pitch for dumb bo creator
        drm/i915: report correct render clock frequencies on SNB
        drm/i915/dp: Correct the order of deletion for ghost eDP devices
        drm/i915: Fix tiling corruption from pipelined fencing
        drm/i915: Re-enable self-refresh
        drm/i915: Prevent racy removal of request from client list
        drm/i915: skip redundant operations whilst enabling pipes and planes
        drm/i915: Remove surplus POSTING_READs before wait_for_vblank
      2d370f50
    • Chris Wilson's avatar
      Revert "drm/i915: Don't save/restore hardware status page address register" · f0c86024
      Chris Wilson authored
      This reverts commit a7a75c8f.
      
      There are two different variations on how Intel hardware addresses the
      "Hardware Status Page". One as a location in physical memory and the
      other as an offset into the virtual memory of the GPU, used in more
      recent chipsets. (The HWS itself is a cacheable region of memory which
      the GPU can write to without requiring CPU synchronisation, used for
      updating various details of hardware state, such as the position of
      the GPU head in the ringbuffer, the last breadcrumb seqno, etc).
      
      These two types of addresses were updated in different locations of code
      - one inline with the ringbuffer initialisation, and the other during
      device initialisation. (The HWS page is logically associated with
      the rings, and there is one HWS page per ring.) During resume, only the
      ringbuffers were being re-initialised along with the virtual HWS page,
      leaving the older physical address HWS untouched. This then caused a
      hang on the older gen3/4 (915GM, 945GM, 965GM) the first time we tried
      to synchronise the GPU as the breadcrumbs were never being updated.
      Reported-and-tested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Reported-by: default avatarJan Niehusmann <jan@gondor.com>
      Reported-and-tested-by: default avatarJustin P. Mattock <justinmattock@gmail.com>
      Reported-and-tested-by: default avatarMichael "brot" Groh <brot@minad.de>
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Acked-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      f0c86024
  2. 23 Mar, 2011 13 commits
    • Chris Wilson's avatar
      drm/i915: Avoid unmapping pages from a NULL address space · f6e47884
      Chris Wilson authored
      Found by gem_stress.
      
      As we perform retirement from a workqueue, it is possible for us to free
      and unbind objects after the last close on the device, and so after the
      address space has been torn down and reset to NULL:
      
      BUG: unable to handle kernel NULL pointer dereference at 00000054
      IP: [<c1295a20>] mutex_lock+0xf/0x27
      *pde = 00000000
      Oops: 0002 [#1] SMP
      last sysfs file: /sys/module/vt/parameters/default_utf8
      
      Pid: 5, comm: kworker/u:0 Not tainted 2.6.38+ #214
      EIP: 0060:[<c1295a20>] EFLAGS: 00010206 CPU: 1
      EIP is at mutex_lock+0xf/0x27
      EAX: 00000054 EBX: 00000054 ECX: 00000000 EDX: 00012fff
      ESI: 00000028 EDI: 00000000 EBP: f706fe20 ESP: f706fe18
       DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      Process kworker/u:0 (pid: 5, ti=f706e000 task=f7060d00 task.ti=f706e000)
      Stack:
       f5aa3c60 00000000 f706fe74 c107e7df 00000246 dea55380 00000054 f5aa3c60
       f706fe44 00000061 f70b4000 c13fff84 00000008 f706fe54 00000000 00000000
       00012f00 00012fff 00000028 c109e575 f6b36700 00100000 00000000 f706fe90
      Call Trace:
       [<c107e7df>] unmap_mapping_range+0x7d/0x1e6
       [<c109e575>] ? mntput_no_expire+0x52/0xb6
       [<c11c12f6>] i915_gem_release_mmap+0x49/0x58
       [<c11c3449>] i915_gem_object_unbind+0x4c/0x125
       [<c11c353f>] i915_gem_free_object_tail+0x1d/0xdb
       [<c11c55a2>] i915_gem_free_object+0x3d/0x41
       [<c11a6be2>] ? drm_gem_object_free+0x0/0x27
       [<c11a6c07>] drm_gem_object_free+0x25/0x27
       [<c113c3ca>] kref_put+0x39/0x42
       [<c11c0a59>] drm_gem_object_unreference+0x16/0x18
       [<c11c0b15>] i915_gem_object_move_to_inactive+0xba/0xbe
       [<c11c0c87>] i915_gem_retire_requests_ring+0x16e/0x1a5
       [<c11c3645>] i915_gem_retire_requests+0x48/0x63
       [<c11c36ac>] i915_gem_retire_work_handler+0x4c/0x117
       [<c10385d1>] process_one_work+0x140/0x21b
       [<c103734c>] ? __need_more_worker+0x13/0x2a
       [<c10373b1>] ? need_to_create_worker+0x1c/0x35
       [<c11c3660>] ? i915_gem_retire_work_handler+0x0/0x117
       [<c1038faf>] worker_thread+0xd4/0x14b
       [<c1038edb>] ? worker_thread+0x0/0x14b
       [<c103be1b>] kthread+0x68/0x6d
       [<c103bdb3>] ? kthread+0x0/0x6d
       [<c12970f6>] kernel_thread_helper+0x6/0x10
      Code: 00 e8 98 fe ff ff 5d c3 55 89 e5 3e 8d 74 26 00 ba 01 00 00 00 e8
      84 fe ff ff 5d c3 55 89 e5 53 8d 64 24 fc 3e 8d 74 26 00 89 c3 <f0> ff
      08 79 05 e8 ab ff ff ff 89 e0 25 00 e0 ff ff 89 43 10 58
      EIP: [<c1295a20>] mutex_lock+0xf/0x27 SS:ESP 0068:f706fe18
      CR2: 0000000000000054
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarKeith Packard <keithp@keithp.com>
      f6e47884
    • Chris Wilson's avatar
      drm/i915: Fix use after free within tracepoint · 26e12f89
      Chris Wilson authored
      Detected by scripts/coccinelle/free/kfree.cocci.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarKeith Packard <keithp@keithp.com>
      26e12f89
    • Chris Wilson's avatar
      drm/i915: Restore missing command flush before interrupt on BLT ring · 36d527de
      Chris Wilson authored
      We always skipped flushing the BLT ring if the request flush did not
      include the RENDER domain. However, this neglects that we try to flush
      the COMMAND domain after every batch and before the breadcrumb interrupt
      (to make sure the batch is indeed completed prior to the interrupt
      firing and so insuring CPU coherency). As a result of the missing flush,
      incoherency did indeed creep in, most notable when using lots of command
      buffers and so potentially rewritting an active command buffer (i.e.
      the GPU was still executing from it even though the following interrupt
      had already fired and the request/buffer retired).
      
      As all ring->flush routines now have the same preconditions, de-duplicate
      and move those checks up into i915_gem_flush_ring().
      
      Fixes gem_linear_blit.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35284Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: mengmeng.meng@intel.com
      36d527de
    • Chris Wilson's avatar
      drm/i915: Disable pagefaults along execbuffer relocation fast path · d4aeee77
      Chris Wilson authored
      Along the fast path for relocation handling, we attempt to copy directly
      from the user data structures whilst holding our mutex. This causes
      lockdep to warn about circular lock dependencies if we need to pagefault
      the user pages. [Since when handling a page fault on a mmapped bo, we
      need to acquire the struct mutex whilst already holding the mm
      semaphore, it is then verboten to acquire the mm semaphore when already
      holding the struct mutex. The likelihood of the user passing in the
      relocations contained in a GTT mmaped bo is low, but conceivable for
      extreme pathology.] In order to force the mm to return EFAULT rather
      than handle the pagefault, we therefore need to disable pagefaults
      across the relocation fast path.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@kernel.org
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d4aeee77
    • Chris Wilson's avatar
      drm/i915: Fix computation of pitch for dumb bo creator · ed0291fd
      Chris Wilson authored
      Cc: Dave Airlie <airlied@linux.ie>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      ed0291fd
    • Jesse Barnes's avatar
      drm/i915: report correct render clock frequencies on SNB · e281fcaa
      Jesse Barnes authored
      Fix up the debug file to report the right frequencies.  On SNB, we program
      the PCU with a frequency ratio, which is multiplied by 100MHz on the CPU
      side.  But GFX only runs at half that, so report it as such to avoid
      confusion.
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarKeith Packard <keithp@keithp.com>
      e281fcaa
    • Takashi Iwai's avatar
      drm/i915/dp: Correct the order of deletion for ghost eDP devices · 48898b03
      Takashi Iwai authored
      The order of the calls does matter indeed.  Swapping the call order of
      intel_dp_destroy() and intel_dp_encoder_destroy() fixes the problem.
      This is because i2c_del_adapter unregisters the device which parent is
      intel_connector, and connectors are removed in intel_dp_destroy().  Thus
      intel_dp_encoder_destroy() must be called before intel_dp_destroy().
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24822Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarKeith Packard <keithp@keithp.com>
      48898b03
    • Chris Wilson's avatar
      drm/i915: Fix tiling corruption from pipelined fencing · 29c5a587
      Chris Wilson authored
      ... even though it was disabled. A mistake in the handling of fence reuse
      caused us to skip the vital delay of waiting for the object to finish
      rendering before changing the register. This resulted in us changing the
      fence register whilst the bo was active and so causing the blits to
      complete using the wrong stride or even the wrong tiling. (Visually the
      effect is that small blocks of the screen look like they have been
      interlaced). The fix is to wait for the GPU to finish using the memory
      region pointed to by the fence before changing it.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34584
      Cc: Andy Whitcroft <apw@canonical.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      [Note for 2.6.38-stable, we need to reintroduce the interruptible passing]
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: default avatarDave Airlie <airlied@linux.ie>
      29c5a587
    • Yuanhan Liu's avatar
      drm/i915: Re-enable self-refresh · 7ccb4a53
      Yuanhan Liu authored
      A broken implementation of is_pot() prevented the detection of when a
      singular pipe was enabled. Eric Anholt pointed out the existence of
      is_power_of_2() so use that instead of our broken code!
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35402Signed-off-by: default avatarYuanhan Liu <yuanhan.liu@intel.com>
      Tested-by: xunx.fang@intel.com
      Reviewed-by: default avatarKeith Packard <keithp@keithp.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      7ccb4a53
    • Herton Ronaldo Krzesinski's avatar
      drm/i915: Prevent racy removal of request from client list · 09bfa517
      Herton Ronaldo Krzesinski authored
      When i915_gem_retire_requests_ring calls i915_gem_request_remove_from_client,
      the client_list for that request may already be removed in i915_gem_release.
      So we may call twice list_del(&request->client_list), resulting in an
      oops like this report:
      
      [126167.230394] BUG: unable to handle kernel paging request at 00100104
      [126167.230699] IP: [<f8c2ce44>] i915_gem_retire_requests_ring+0xd4/0x240 [i915]
      [126167.231042] *pdpt = 00000000314c1001 *pde = 0000000000000000
      [126167.231314] Oops: 0002 [#1] SMP
      [126167.231471] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/current_now
      [126167.231901] Modules linked in: snd_seq_dummy nls_utf8 isofs btrfs zlib_deflate libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs cryptd aes_i586 aes_generic binfmt_misc vboxnetadp vboxnetflt vboxdrv parport_pc ppdev snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq uvcvideo videodev snd_timer snd_seq_device joydev iwlagn iwlcore mac80211 snd cfg80211 soundcore i915 drm_kms_helper snd_page_alloc psmouse drm serio_raw i2c_algo_bit video lp parport usbhid hid sky2 sdhci_pci ahci sdhci libahci
      [126167.232018]
      [126167.232018] Pid: 1101, comm: Xorg Not tainted 2.6.38-6-generic-pae #34-Ubuntu Gateway                          MC7833U /
      [126167.232018] EIP: 0060:[<f8c2ce44>] EFLAGS: 00213246 CPU: 0
      [126167.232018] EIP is at i915_gem_retire_requests_ring+0xd4/0x240 [i915]
      [126167.232018] EAX: 00200200 EBX: f1ac25b0 ECX: 00000040 EDX: 00100100
      [126167.232018] ESI: f1a2801c EDI: e87fc060 EBP: ef4d7dd8 ESP: ef4d7db0
      [126167.232018]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      [126167.232018] Process Xorg (pid: 1101, ti=ef4d6000 task=f1ba6500 task.ti=ef4d6000)
      [126167.232018] Stack:
      [126167.232018]  f1a28000 f1a2809c f1a28094 0058bd97 f1aa2400 f1a2801c 0058bd7b 0058bd85
      [126167.232018]  f1a2801c f1a28000 ef4d7e38 f8c2e995 ef4d7e30 ef4d7e60 c14d1ebc f6b3a040
      [126167.232018]  f1522cc0 000000db 00000000 f1ba6500 ffffffa1 00000000 00000001 f1a29214
      [126167.232018] Call Trace:
      
      Unfortunately the call trace reported was cut, but looking at debug
      symbols the crash is at __list_del, when probably list_del is called
      twice on the same request->client_list, as the dereferenced value is
      LIST_POISON1 + 4, and by looking more at the debug symbols before
      list_del call it should have being called by
      i915_gem_request_remove_from_client
      
      And as I can see in the code, it seems we indeed have the possibility
      to remove a request->client_list twice, which would cause the above,
      because we do list_del(&request->client_list) on both
      i915_gem_request_remove_from_client and i915_gem_release
      
      As Chris Wilson pointed out, it's indeed the case:
      "(...) I had thought that the actual insertion/deletion was serialised
      under the struct mutex and the intention of the spinlock was to protect
      the unlocked list traversal during throttling. However, I missed that
      i915_gem_release() is also called without struct mutex and so we do need
      the double check for i915_gem_request_remove_from_client()."
      
      This change does the required check to avoid the duplicate remove of
      request->client_list.
      
      Bugzilla: http://bugs.launchpad.net/bugs/733780
      Cc: stable@kernel.org # 2.6.38
      Signed-off-by: default avatarHerton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      09bfa517
    • Chris Wilson's avatar
      drm/i915: skip redundant operations whilst enabling pipes and planes · 00d70b15
      Chris Wilson authored
      If the pipe or plane is already enabled, then we do not need to enable
      it again and can skip the delay. Similarly if it is already disabled
      when we want to disable it, we can also skip it.
      
      This fixes a regression from b24e7179, which caused the LVDS
      output on one PineView machine to become corrupt after changing
      orientation several times.
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarKeith Packard <keithp@keithp.com>
      Tested-by: mengmeng.meng@intel.com
      00d70b15
    • Chris Wilson's avatar
      drm/i915: Remove surplus POSTING_READs before wait_for_vblank · 762237bb
      Chris Wilson authored
      ... as wait_for_vblank (and friends) will do a flush of the MMIO writes
      anyway.
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      762237bb
    • Alex Deucher's avatar
      drm/radeon/kms: prefer legacy pll algo for tv-out · 64146f8b
      Alex Deucher authored
      ntsc seems to work fine with either algo, some
      pal TVs seem pickier.
      
      Fixes:
      https://bugzilla.kernel.org/show_bug.cgi?id=30832Signed-off-by: default avatarAlex Deucher <alexdeucher@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      64146f8b
  3. 21 Mar, 2011 1 commit
  4. 20 Mar, 2011 2 commits
    • Ilija Hadzic's avatar
      drm/kernel: vblank wait on crtc > 1 · 19b01b5f
      Ilija Hadzic authored
      Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds
      the capability to wait on vblank events for CRTCs that are greater than 1
      and thus cannot be represented with primary/secondary flags in the legacy
      interface. It was discussed on the dri-devel list in these two threads:
      
      http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html
      http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html
      
      This patch extends the interface to drm_wait_vblank ioctl so that crtc>1
      can be represented. It also adds a new capability to drm_getcap ioctl so
      that the user space can check whether the new interface to drm_wait_vblank
      is supported (and fall back to the legacy interface if not)
      Signed-off-by: default avatarIlija Hadzic <ihadzic@research.bell-labs.com>
      Reviewed-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de>
      Acked-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de>
      Reviewed-by: default avatarAlex Deucher <alexdeucher@gmail.com>
      Tested-by: default avatarAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      19b01b5f
    • Chris Wilson's avatar
      drm: Fix use-after-free in drm_gem_vm_close() · b74ad5ae
      Chris Wilson authored
      As we may release the last reference, we need to store the device in a
      local variable in order to unlock afterwards.
      
      [   60.140768] BUG: unable to handle kernel paging request at 6b6b6b9f
      [   60.140973] IP: [<c1536d11>] __mutex_unlock_slowpath+0x5a/0x111
      [   60.141014] *pdpt = 0000000024a54001 *pde = 0000000000000000
      [   60.141014] Oops: 0002 [#1] PREEMPT SMP
      [   60.141014] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0A:00/power_supply/BAT0/voltage_now
      [   60.141014] Modules linked in: uvcvideo ath9k pegasus ath9k_common ath9k_hw hid_egalax ath3k joydev asus_laptop sparse_keymap battery input_polldev
      [   60.141014]
      [   60.141014] Pid: 771, comm: meego-ux-daemon Not tainted 2.6.37.2-7.1 #1 EXOPC EXOPG06411/EXOPG06411
      [   60.141014] EIP: 0060:[<c1536d11>] EFLAGS: 00010046 CPU: 0
      [   60.141014] EIP is at __mutex_unlock_slowpath+0x5a/0x111
      [   60.141014] EAX: 00000100 EBX: 6b6b6b9b ECX: e9b4a1b0 EDX: e4a4e580
      [   60.141014] ESI: db162558 EDI: 00000246 EBP: e480be50 ESP: e480be44
      [   60.141014]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      [   60.141014] Process meego-ux-daemon (pid: 771, ti=e480a000 task=e9b4a1b0 task.ti=e480a000)
      [   60.141014] Stack:
      [   60.141014]  e4a4e580 db162558 f5a2f838 e480be58 c1536dd0 e480be68 c125ab1b db162558
      [   60.141014]  db1624e0 e480be78 c10ba071 db162558 f760241c e480be94 c10bb0bc 000155fe
      [   60.141014]  f760241c f5a2f838 f5a2f8c8 00000000 e480bea4 c1037c24 00000000 f5a2f838
      [   60.141014] Call Trace:
      [   60.141014]  [<c1536dd0>] ? mutex_unlock+0x8/0xa
      [   60.141014]  [<c125ab1b>] ? drm_gem_vm_close+0x39/0x3d
      [   60.141014]  [<c10ba071>] ? remove_vma+0x2d/0x58
      [   60.141014]  [<c10bb0bc>] ? exit_mmap+0x126/0x13f
      [   60.141014]  [<c1037c24>] ? mmput+0x37/0x9a
      [   60.141014]  [<c10d450d>] ? exec_mmap+0x178/0x19c
      [   60.141014]  [<c1537f85>] ? _raw_spin_unlock+0x1d/0x36
      [   60.141014]  [<c10d4eb0>] ? flush_old_exec+0x42/0x75
      [   60.141014]  [<c1104442>] ? load_elf_binary+0x32a/0x922
      [   60.141014]  [<c10d3f76>] ? search_binary_handler+0x200/0x2ea
      [   60.141014]  [<c10d3ecf>] ? search_binary_handler+0x159/0x2ea
      [   60.141014]  [<c1104118>] ? load_elf_binary+0x0/0x922
      [   60.141014]  [<c10d56b2>] ? do_execve+0x1ff/0x2e6
      [   60.141014]  [<c100970e>] ? sys_execve+0x2d/0x55
      [   60.141014]  [<c1002a5a>] ? ptregs_execve+0x12/0x18
      [   60.141014]  [<c10029dc>] ? sysenter_do_call+0x12/0x3c
      [   60.141014]  [<c1530000>] ? init_centaur+0x9c/0x1ba
      [   60.141014] Code: c1 00 75 0f ba 38 01 00 00 b8 8c 3a 6c c1 e8 cc 2e b0 ff 9c 58 8d 74 26 00 89 c7 fa 90 8d 74 26 00 e8 d2 b4 b2 ff b8 00 01 00 00 <f0> 66 0f c1 43 04 38 e0 74 07 f3 90 8a 43 04 eb f5 83 3d 64 ef
      [   60.141014] EIP: [<c1536d11>] __mutex_unlock_slowpath+0x5a/0x111 SS:ESP 0068:e480be44
      [   60.141014] CR2: 000000006b6b6b9f
      Reported-by: default avatarRusty Lynch <rusty.lynch@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      b74ad5ae
  5. 17 Mar, 2011 3 commits
  6. 16 Mar, 2011 4 commits
    • Dave Airlie's avatar
      Merge commit '53595338' into drm-core-next · 38f1cff0
      Dave Airlie authored
      This commit changed an internal radeon structure, that meant a new driver
      in -next had to be fixed up, merge in the commit and fix up the driver.
      
      Also fixes a trivial nouveau merge.
      
      Conflicts:
      	drivers/gpu/drm/nouveau/nouveau_mem.c
      38f1cff0
    • Chris Wilson's avatar
      drm: Retry i2c transfer of EDID block after failure · 4819d2e4
      Chris Wilson authored
      Usually EDID retrieval is fine. However, sometimes, especially when the
      machine is loaded, it fails, but succeeds after a few retries.
      
      Based on a patch by Michael Buesch.
      Reported-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      4819d2e4
    • Alex Deucher's avatar
      drm/radeon/kms: fix typo in atom overscan setup · 942b0e95
      Alex Deucher authored
      Typo in the aspect scale setup.
      Signed-off-by: default avatarAlex Deucher <alexdeucher@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      942b0e95
    • Chris Wilson's avatar
      drm: Hold the mode mutex whilst probing for sysfs status · 007c80a5
      Chris Wilson authored
      As detect will use hw registers and may modify structures, it needs to be
      serialised by use of the dev->mode_config.mutex. Make it so.
      
      Otherwise, we may cause random crashes as the sysfs file is queried
      whilst a concurrent hotplug poll is being run. For example:
      
      [ 1189.189626] BUG: unable to handle kernel NULL pointer dereference at 00000100
      [ 1189.189821] IP: [<e0c22019>] intel_tv_detect_type+0xa2/0x203 [i915]
      [ 1189.190020] *pde = 00000000
      [ 1189.190104] Oops: 0000 [#1] SMP
      [ 1189.190209] last sysfs file: /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-SVIDEO-1/status
      [ 1189.190412] Modules linked in: mperf cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_stats decnet uinput fuse loop joydev snd_hd a_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm i915 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq drm_kms_helper snd_timer uvcvideo d rm snd_seq_device eeepc_laptop tpm_tis usbhid videodev i2c_algo_bit v4l1_compat snd sparse_keymap i2c_core hid serio_raw tpm psmouse evdev tpm_bios rfkill shpchp ac processor rng_c ore battery video power_supply soundcore pci_hotplug button output snd_page_alloc usb_storage uas ext3 jbd mbcache sd_mod crc_t10dif ata_generic ahci libahci ata_piix libata uhci_h cd ehci_hcd scsi_mod usbcore thermal atl2 thermal_sys nls_base [last unloaded: scsi_wait_scan]
      [ 1189.192007]
      [ 1189.192007] Pid: 1464, comm: upowerd Not tainted 2.6.37-2-686 #1 ASUSTeK Computer INC. 701/701
      [ 1189.192007] EIP: 0060:[<e0c22019>] EFLAGS: 00010246 CPU: 0
      [ 1189.192007] EIP is at intel_tv_detect_type+0xa2/0x203 [i915]
      [ 1189.192007] EAX: 00000000 EBX: dca74000 ECX: e0f68004 EDX: 00068004
      [ 1189.192007] ESI: dd110c00 EDI: 400c0c37 EBP: dca7429c ESP: de365e2c
      [ 1189.192007]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      [ 1189.192007] Process upowerd (pid: 1464, ti=de364000 task=dcc8acb0 task.ti=de364000)
      [ 1189.192007] Stack: Mar 15 03:43:23 hostname kernel: [ 1189.192007]  e0c2cda4 70000000 400c0c30 00000000 dd111000 de365e54 de365f24 dd110c00
      [ 1189.192007]  e0c22203 01000000 00000003 00000000 00000000 00000000 00000000 4353544e
      [ 1189.192007]  30383420 00000069 00000000 00000000 00000000 00000000 00000000 00000000
      [ 1189.192007] Call Trace: Mar 15 03:43:23 hostname kernel: [ 1189.192007]  [<e0c22203>] ?  intel_tv_detect+0x89/0x12d [i915]
      [ 1189.192007]  [<e0a9dcef>] ?  status_show+0x0/0x2f [drm]
      [ 1189.192007]  [<e0a9dd03>] ?  status_show+0x14/0x2f [drm]
      
      [Digression: what is upowerd doing reading those power hungry files?]
      Reported-by: default avatarPaul Menzel <paulepanter@users.sourceforge.net>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      007c80a5
  7. 14 Mar, 2011 11 commits
    • Dave Airlie's avatar
      Merge remote branch 'nouveau/drm-nouveau-next' of ../drm-nouveau-next into drm-core-next · 235b87af
      Dave Airlie authored
      * 'nouveau/drm-nouveau-next' of ../drm-nouveau-next:
        drm/nouveau: fix __nouveau_fence_wait performance
        drm/nv40: attempt to reserve just enough vram for all 32 channels
        drm/nv50: check for vm traps on every gr irq
        drm/nv50: decode vm faults some more
        drm/nouveau: add nouveau_enum_find() util function
        drm/nouveau: properly handle pushbuffer check failures
        drm/nvc0: remove vm hack forcing large/small pages to not share a PDE
      235b87af
    • Marcin Slusarz's avatar
      drm/nouveau: fix __nouveau_fence_wait performance · bd35fe5a
      Marcin Slusarz authored
      Commit 21e86c1c ("drm/nouveau: remove
      cpu_writers lock") turned on lazy waits. Unfortunately
      __nouveau_fence_wait was not optimized for this case and on HZ=100
      kernel wasted up to 10 ms per call.
      
      Depending on application, it led to 10-30% FPS regression.
      
      Fix it.
      Signed-off-by: default avatarMarcin Slusarz <marcin.slusarz@gmail.com>
      Signed-off-by: default avatarFrancisco Jerez <currojerez@riseup.net>
      bd35fe5a
    • Ben Skeggs's avatar
      drm/nv40: attempt to reserve just enough vram for all 32 channels · 459ca7e5
      Ben Skeggs authored
      This also makes the fact we're giving 512MiB of GART space to all PCIE
      boards explicit, although the vast majority (if not all) of them will
      now have a ramin_rsvd_vram larger than 2MiB anyway.
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      459ca7e5
    • Ben Skeggs's avatar
      drm/nv50: check for vm traps on every gr irq · 6fdb383e
      Ben Skeggs authored
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      6fdb383e
    • Ben Skeggs's avatar
      drm/nv50: decode vm faults some more · 312d1d5f
      Ben Skeggs authored
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      312d1d5f
    • Ben Skeggs's avatar
      bb9b18a3
    • Marcin Slusarz's avatar
      drm/nouveau: properly handle pushbuffer check failures · 7fa0cba2
      Marcin Slusarz authored
      When "buffer in list" check does not pass, don't free validation lists - they were
      not initialized yet.
      
      Fixes this oops:
      
      [drm] nouveau 0000:02:00.0: push 105 buffer not in list
      BUG: unable to handle kernel NULL pointer dereference at 000000000000057c
      IP: [<ffffffff81236aa4>] do_raw_spin_lock+0x14/0x13c
      PGD 1ac6cb067 PUD 1aaa52067 PMD 0
      CPU 0
      Modules linked in: nouveau ttm drm_kms_helper snd_hda_codec_realtek snd_hda_intel snd_hda_codec
      
      Pid: 6265, comm: OilRush_x86 Not tainted 2.6.38-rc6-nv+ #632 System manufacturer System Product Name/P6T SE
      RIP: 0010:[<ffffffff81236aa4>]  [<ffffffff81236aa4>] do_raw_spin_lock+0x14/0x13c
      (...)
      Process OilRush_x86 (pid: 6265, threadinfo ffff8801a6aee000, task ffff8801a26c0000)
       0000000000000000 ffff8801ac74c618 0000000000000000 0000000000000578
       0000000000000000 ffff8801ac74c618 0000000000000000 ffff8801bd9d0000
       [<ffffffff81417f78>] _raw_spin_lock+0x1e/0x22
       [<ffffffffa00a2746>] nouveau_bo_fence+0x2e/0x60 [nouveau]
       [<ffffffffa00a540b>] validate_fini_list+0x35/0xeb [nouveau]
       [<ffffffffa00a54d3>] validate_fini+0x12/0x31 [nouveau]
       [<ffffffffa00a6386>] nouveau_gem_ioctl_pushbuf+0xe94/0xf6b [nouveau]
       [<ffffffff8141ac56>] ? sub_preempt_count+0x9e/0xb2
       [<ffffffff81417e94>] ? _raw_spin_unlock_irqrestore+0x30/0x4d
       [<ffffffff8105dea2>] ? __wake_up+0x3f/0x48
       [<ffffffff812aebb4>] drm_ioctl+0x289/0x361
       [<ffffffff8141ac56>] ? sub_preempt_count+0x9e/0xb2
       [<ffffffffa00a54f2>] ? nouveau_gem_ioctl_pushbuf+0x0/0xf6b [nouveau]
       [<ffffffff8141ac56>] ? sub_preempt_count+0x9e/0xb2
       [<ffffffffa010caa2>] nouveau_compat_ioctl+0x16/0x1c [nouveau]
       [<ffffffff81142c0d>] compat_sys_ioctl+0x1c8/0x12d7
       [<ffffffff814179ca>] ? trace_hardirqs_off_thunk+0x3a/0x6c
       [<ffffffff81058099>] sysenter_dispatch+0x7/0x30
       [<ffffffff8141798e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
      RIP  [<ffffffff81236aa4>] do_raw_spin_lock+0x14/0x13c
       RSP <ffff8801a6aefb88>
      ---[ end trace 0014d5d93e6147e1 ]---
      
      Additionally, don't call validate_fini twice in case of validation failure.
      Signed-off-by: default avatarMarcin Slusarz <marcin.slusarz@gmail.com>
      Signed-off-by: default avatarMaarten Maathuis <madman2003@gmail.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      7fa0cba2
    • Ben Skeggs's avatar
      drm/nvc0: remove vm hack forcing large/small pages to not share a PDE · b84f30e6
      Ben Skeggs authored
      Appears to be fixed with commit:
      
      "drm/nv50-nvc0: make sure vma is definitely unmapped when destroying bo"
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      b84f30e6
    • Dave Airlie's avatar
      drm/i915: disable opregion lid detection for now. · bcd5023c
      Dave Airlie authored
      At least on my HP 2540p this is wrong at bootup, fine
      at any other time once a lid event has occured. This is due to
      _REG vs _INI ordering in the ACPI tables.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      bcd5023c
    • Dave Airlie's avatar
      Merge remote branch 'intel/drm-intel-next' of ../drm-next into drm-core-next · 34db18ab
      Dave Airlie authored
      * 'intel/drm-intel-next' of ../drm-next: (755 commits)
        drm/i915: Only wait on a pending flip if we intend to write to the buffer
        drm/i915/dp: Sanity check eDP existence
        drm/i915: Rebind the buffer if its alignment constraints changes with tiling
        drm/i915: Disable GPU semaphores by default
        drm/i915: Do not overflow the MMADDR write FIFO
        Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing"
        drm/i915: Don't save/restore hardware status page address register
        drm/i915: don't store the reg value for HWS_PGA
        drm/i915: fix memory corruption with GM965 and >4GB RAM
        Linux 2.6.38-rc7
        Revert "TPM: Long default timeout fix"
        drm/i915: Re-enable GPU semaphores for SandyBridge mobile
        drm/i915: Replace vblank PM QoS with "Interrupt-Based AGPBUSY#"
        Revert "drm/i915: Use PM QoS to prevent C-State starvation of gen3 GPU"
        drm/i915: Allow relocation deltas outside of target bo
        drm/i915: Silence an innocuous compiler warning for an unused variable
        fs/block_dev.c: fix new kernel-doc warning
        ACPI: Fix build for CONFIG_NET unset
        mm: <asm-generic/pgtable.h> must include <linux/mm_types.h>
        x86: Use u32 instead of long to set reset vector back to 0
        ...
      
      Conflicts:
      	drivers/gpu/drm/i915/i915_gem.c
      34db18ab
    • Dave Airlie's avatar
      drm/radeon: fix problem with changing active VRAM size. (v2) · 53595338
      Dave Airlie authored
      So we used to use lpfn directly to restrict VRAM when we couldn't
      access the unmappable area, however this was removed in
      93225b0d as it also restricted
      the gtt placements. However it was only later noticed that this
      broke on some hw.
      
      This removes the active_vram_size, and just explicitly sets it
      when it changes, TTM/drm_mm will always use the real_vram_size,
      and the active vram size will change the TTM size used for lpfn
      setting.
      
      We should re-work the fpfn/lpfn to per-placement at some point
      I suspect, but that is too late for this kernel.
      
      Hopefully this addresses:
      https://bugs.freedesktop.org/show_bug.cgi?id=35254
      
      v2: fix reported useful VRAM size to userspace to be correct.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      53595338
  8. 13 Mar, 2011 1 commit
  9. 11 Mar, 2011 1 commit
  10. 10 Mar, 2011 2 commits