1. 08 9月, 2010 1 次提交
    • D
      drm/i915: unload: fix error_work races · bc0c7f14
      Daniel Vetter 提交于
      This is the first patch to clean up module unload races due to
      outstanding timers/work. Preparatory step: Thou shalt not destroy
      the workqueue when new work might still get enqued.
      
      Now error_work gets queued by the hangcheck timer and only (atomically)
      reads the chip wedged status. So cancel it right after the hangcheck
      timer is killed. But the hangcheck is armed by interrupts, so move
      everything after irqs are disabled.
      
      Also change a del_timer to a del_timer_sync in the ums gem code, the
      hangcheck timer is self-rearming.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      bc0c7f14
  2. 07 9月, 2010 3 次提交
  3. 17 8月, 2010 1 次提交
    • D
      drm: block userspace under allocating buffer and having drivers overwrite it (v2) · 1b2f1489
      Dave Airlie 提交于
      With the current screwed but its ABI, ioctls for the drm, Linus pointed out that we could allow userspace to specify the allocation size, but we pass it to the driver which then uses it blindly to store a struct. Now if userspace specifies the allocation size as smaller than the driver needs, the driver can possibly overwrite memory.
      
      This patch restructures the driver ioctls so we store the structure size we are expecting, and make sure we allocate at least that size. The copy from/to userspace are still restricted to the size the user specifies, this allows ioctl structs to grow on both sides of the equation.
      
      Up until now we didn't really use the DRM_IOCTL defines in the kernel, so this cleans them up and adds them for nouveau.
      
      v2:
      fix nouveau pushbuf arg (thanks to Ben for pointing it out)
      Reported-by: NLinus Torvalds <torvalds@linuxfoundation.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      1b2f1489
  4. 10 8月, 2010 1 次提交
  5. 02 8月, 2010 2 次提交
  6. 27 7月, 2010 1 次提交
  7. 02 7月, 2010 2 次提交
  8. 19 6月, 2010 1 次提交
  9. 08 6月, 2010 1 次提交
  10. 02 6月, 2010 1 次提交
  11. 01 6月, 2010 3 次提交
  12. 27 5月, 2010 9 次提交
    • E
      drm/i915: Clean up leftover bits from hws move to ring structure. · e20f9c64
      Eric Anholt 提交于
      Fixes /debug/dri/0/i915_gem_interrupt output for status page.
      Signed-off-by: NEric Anholt <eric@anholt.net>
      e20f9c64
    • L
      drm/i915: Add CxSR support on Pineview DDR3 · 95534263
      Li Peng 提交于
      Pineview with DDR3 memory has different latencies to enable CxSR.
      This patch updates CxSR latency table to add Pineview DDR3 latency
      configuration. It also adds one flag "is_ddr3" for checking DDR3
      setting in MCHBAR.
      
      Cc: Shaohua Li <shaohua.li@intel.com>
      Cc: Zhao Yakui <yakui.zhao@intel.com>
      Signed-off-by: NLi Peng <peng.li@intel.com>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      95534263
    • J
      drm/i915: add power monitoring support · 7648fa99
      Jesse Barnes 提交于
      Add power monitoring support to the i915 driver for use by the IPS
      driver.  Export the available power info to the IPS driver through a few
      new inter-driver hooks.  When used together, the IPS driver and this
      patch can significantly increase graphics performance on Ironlake class
      chips.
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      [anholt: Fixed 32-bit compile.  stupid obfuscating div_u64()]
      Signed-off-by: NEric Anholt <eric@anholt.net>
      7648fa99
    • Z
      drm/i915: implement BSD ring buffer V2 · d1b851fc
      Zou Nan hai 提交于
      The BSD (bit stream decoder) ring is used for accessing the BSD engine
      which decodes video bitstream for H.264 and VC1 on G45+.  It is
      asynchronous with the render ring and has access to separate parts of
      the GPU from it, though the render cache is coherent between the two.
      Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
      Signed-off-by: NXiang Hai hao <haihao.xiang@intel.com>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      d1b851fc
    • Z
      drm/i915: convert some gem structures to per-ring V2 · 852835f3
      Zou Nan hai 提交于
      The active list and request list move into the ringbuffer structure,
      so each can track its active objects in the order they are in that
      ring.  The flushing list does not, as it doesn't matter which ring
      caused data to end up in the render cache.  Objects gain a pointer to
      the ring they are active on (if any).
      Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
      Signed-off-by: NXiang Hai hao <haihao.xiang@intel.com>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      852835f3
    • Z
      drm/i915: introduce intel_ring_buffer structure (V2) · 8187a2b7
      Zou Nan hai 提交于
      Introduces a more complete intel_ring_buffer structure with callbacks
      for setup and management of a particular ringbuffer, and converts the
      render ring buffer consumers to use it.
      Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
      Signed-off-by: NXiang Hai hao <haihao.xiang@intel.com>
      [anholt: Fixed up whitespace fail and rebased against prep patches]
      Signed-off-by: NEric Anholt <eric@anholt.net>
      8187a2b7
    • E
      drm/i915: Rename dev_priv->ring to dev_priv->render_ring. · d3301d86
      Eric Anholt 提交于
      With the advent of the BSD ring, be clear about which ring this is.
      The docs are pretty consistent with calling this the Render engine at
      this point.
      d3301d86
    • E
      drm/i915: Move ringbuffer-related code to intel_ringbuffer.c. · 62fdfeaf
      Eric Anholt 提交于
      This is preparation for supporting multiple ringbuffers on Ironlake.
      The non-copy-and-paste changes are:
      - de-staticing functions
      - I915_GEM_GPU_DOMAINS moving to i915_drv.h to be used by both files.
      - i915_gem_add_request had only half its implementation
        copy-and-pasted out of the middle of it.
      62fdfeaf
    • C
      drm/i915: Fail to load driver if KMS request without GEM · 79a78dd6
      Chris Wilson 提交于
      The i915's implementation of KMS requires GEM in order to manage the
      memory and execution domains of the framebuffer and associated
      resources. By the point at which we detect broken a BIOS and need to
      disable GEM, we have already registered ourselves as a KMS driver with
      several subsystems. Rather than introducing a fragile unwind and attempt
      to continue with UMS, spit out an error and unload the driver.
      
      References:
      
        [Bug 15754] IP: [<ffffffffa0207589>] drm_mm_search_free+0x49/0x90 [drm]
                    BUG: unable to handle kernel NULL pointer dereference at (null)
        https://bugzilla.kernel.org/show_bug.cgi?id=15754
      
      [drm:i915_driver_load] *ERROR* Detected broken video BIOS with
      262140/262144kB of video memory stolen.
      [drm:i915_driver_load] *ERROR* Disabling GEM. (try reducing stolen
      memory or updating the BIOS to fix).
      i915 0000:00:02.0: irq 30 for MSI/MSI-X
      [drm] set up 255M of stolen space
      BUG: unable to handle kernel NULL pointer dereference at (null)
      IP: [<ffffffffa0207589>] drm_mm_search_free+0x49/0x90 [drm]
      PGD 69719067 PUD 69dda067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP
      last sysfs file: /sys/module/snd_seq_oss/initstate
      CPU 1
      Pid: 867, comm: modprobe Not tainted 2.6.33-ARCH #1 G43Twins-FullHD/To
      Be Filled By O.E.M.
      RIP: 0010:[<ffffffffa0207589>]  [<ffffffffa0207589>] drm_mm_search_free+0x49/0x90 [drm]
      RSP: 0018:ffff8800699f3af8  EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffffffffffffffff RCX: 0000000000000000
      RDX: 0000000000001000 RSI: 0000000000001000 RDI: ffff8800693d0f78
      RBP: ffff8800699f3b18 R08: 0000000000001000 R09: 0000000000000000
      R10: 2222222222222222 R11: 0000000000000000 R12: ffff880068de70c0
      R13: 0000000000001000 R14: 0000000000000000 R15: ffff8800689cb000
      FS:  00007fa93f4e5700(0000) GS:ffff880001880000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 00000000695a0000 CR4: 00000000000406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process modprobe (pid: 867, threadinfo ffff8800699f2000, task ffff8800694f4740)
      Stack:
       ffff880068de73c0 ffff880068de70c0 ffff8800689cb000 0000000000001000
      <0> ffff8800699f3b68 ffffffffa0299f63 ffff8800693d0f78 0000120068de70c0
      <0> ffff8800689cb000 ffff880068de73c0 ffff880068de70c0 ffff8800689cb000
      Call Trace:
       [<ffffffffa0299f63>] i915_gem_object_bind_to_gtt+0x83/0x360 [i915]
       [<ffffffffa029a2e5>] i915_gem_object_pin+0xa5/0xb0 [i915]
       [<ffffffffa029a3c5>] i915_gem_init_ringbuffer+0xd5/0x510 [i915]
       [<ffffffffa028dbee>] i915_driver_load+0x4ce/0xd00 [i915]
       [<ffffffffa0205d37>] ? drm_sysfs_device_add+0x87/0xb0 [drm]
       [<ffffffffa0203363>] ? drm_get_minor+0x1d3/0x330 [drm]
       [<ffffffffa02037e6>] drm_get_dev+0x326/0x580 [drm]
       [<ffffffffa02bc0a5>] i915_pci_probe+0x10/0xd0 [i915]
       [<ffffffff811e98a2>] local_pci_probe+0x12/0x20
       [<ffffffff811ea8e0>] pci_device_probe+0x80/0xb0
       [<ffffffff8127b12a>] ? driver_sysfs_add+0x5a/0x90
       [<ffffffff8127b273>] driver_probe_device+0x93/0x1a0
       [<ffffffff8127b413>] __driver_attach+0x93/0xa0
       [<ffffffff8127b380>] ? __driver_attach+0x0/0xa0
       [<ffffffff8127a8f8>] bus_for_each_dev+0x68/0x90
       [<ffffffff8127b0c9>] driver_attach+0x19/0x20
       [<ffffffff8127a0ad>] bus_add_driver+0xcd/0x2d0
       [<ffffffff8127b718>] driver_register+0x78/0x140
       [<ffffffff811eab91>] __pci_register_driver+0x51/0xd0
       [<ffffffffa02d6000>] ? i915_init+0x0/0x52 [i915]
       [<ffffffffa01fdc31>] drm_init+0x111/0x120 [drm]
       [<ffffffff810eb0cd>] ? register_shrinker+0x4d/0x60
       [<ffffffffa02d6000>] ? i915_init+0x0/0x52 [i915]
       [<ffffffffa02d6050>] i915_init+0x50/0x52 [i915]
       [<ffffffff81002047>] do_one_initcall+0x37/0x1a0
       [<ffffffff8108ed17>] sys_init_module+0xd7/0x250
       [<ffffffff81009fc2>] system_call_fastpath+0x16/0x1b
      Code: eb 29 49 8b 41 28 31 d2 49 f7 f5 85 d2 74 39 44 89 c0 29 d0 48 89 c2 48 01 f2 49 39 d2 73 29 0f 1f 00 49 89 da 4c 89 d3 4d 89 d9 <4d> 8b 19 49 39 f9 41 0f 18 0b 74 2b 4d 8b 51 30 4d 89 cc 49 39
      RIP  [<ffffffffa0207589>] drm_mm_search_free+0x49/0x90 [drm]
       RSP <ffff8800699f3af8>
      CR2: 0000000000000000
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      79a78dd6
  13. 18 5月, 2010 1 次提交
    • D
      drm/fbdev: rework output polling to be back in the core. (v4) · eb1f8e4f
      Dave Airlie 提交于
      After thinking it over a lot it made more sense for the core to deal with
      the output polling especially so it can notify X.
      
      v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings.
      
      v3: add config lock take inside polling, add intel/nouveau poll init/fini calls
      
      v4: config lock was a bit agressive, only needed around connector list reading.
      otherwise it could re-enter.
      
      glisse: discard drm_helper_hpd_irq_event
      
      v3: Reviewed-by: Michel Dänzer <michel@daenzer.net>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      eb1f8e4f
  14. 08 5月, 2010 2 次提交
  15. 23 4月, 2010 1 次提交
  16. 13 4月, 2010 2 次提交
  17. 07 4月, 2010 1 次提交
    • D
      drm/fb: fix fbdev object model + cleanup properly. · 38651674
      Dave Airlie 提交于
      The fbdev layer in the kms code should act like a consumer of the kms services and avoid having relying on information being store in the kms core structures in order for it to work.
      
      This patch
      
      a) removes the info pointer/psuedo palette from the core drm_framebuffer structure and moves it to the fbdev helper layer, it also removes the core drm keeping a list of kernel kms fbdevs.
      b) migrated all the fb helper functions out of the crtc helper file into the fb helper file.
      c) pushed the fb probing/hotplug control into the driver
      d) makes the surface sizes into a structure for ease of passing
      This changes the intel/radeon/nouveau drivers to use the new helper.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      38651674
  18. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  19. 18 3月, 2010 1 次提交
  20. 01 3月, 2010 1 次提交
    • D
      vga_switcheroo: initial implementation (v15) · 6a9ee8af
      Dave Airlie 提交于
      Many new laptops now come with 2 gpus, one to be used for low power
      modes and one for gaming/on-ac applications. These GPUs are typically
      wired to the laptop panel and VGA ports via a multiplexer unit which
      is controlled via ACPI methods.
      
      4 combinations of systems typically exist - with 2 ACPI methods.
      Intel/ATI - Lenovo W500/T500 - use ATPX ACPI method
      ATI/ATI - some ASUS - use ATPX ACPI Method
      Intel/Nvidia - - use _DSM ACPI method
      Nvidia/Nvidia -  - use _DSM ACPI method.
      
      TODO:
      This patch adds support for the ATPX method and initial bits
      for the _DSM methods that need to written by someone with
      access to the hardware.
      Add a proper non-debugfs interface - need to get some proper
      testing first.
      
      v2: add power up/down support for both devices
      on W500 puts i915/radeon into D3 and cuts power to radeon.
      
      v3: redo probing methods, no DMI list, drm devices call to
      register with switcheroo, it tries to find an ATPX method on
      any device and once there is two devices + ATPX it inits the
      switcher.
      
      v4: ATPX msg handling using buffers - should work on more machines
      
      v5: rearchitect after more mjg59 discussion - move ATPX handling to
          radeon driver.
      
      v6: add file headers + initial nouveau bits (to be filled out).
      
      v7: merge delayed switcher code.
      
      v8: avoid suspend/resume of gpu that is off
      
      v9: rearchitect - mjg59 is always right. - move all ATPX code to
      radeon, should allow simpler DSM also proper ATRM handling
      
      v10: add ATRM support for radeon BIOS, add mutex to lock vgasr_priv
      
      v11: fix bug in resuming Intel for 2nd time.
      
      v12: start fixing up nvidia code blindly.
      
      v13: blindly guess at finishing nvidia code
      
      v14: remove radeon audio hacks - fix up intel resume more like upstream
      
      v15: clean up printks + remove unnecessary igd/dis pointers
      
      mount debugfs
      
      /sys/kernel/debug/vgaswitcheroo/switch - should exist if ATPX detected
       + 2 cards.
      
      DIS - immediate change to discrete
      IGD - immediate change to IGD
      DDIS - delayed change to discrete
      DIGD - delayed change to IGD
      ON - turn on not in use
      OFF - turn off not in use
      
      Tested on W500 (Intel/ATI) and T500 (Intel/ATI)
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      6a9ee8af
  21. 27 2月, 2010 3 次提交
  22. 23 2月, 2010 1 次提交
    • C
      drm/i915: Record batch buffer following GPU error · 9df30794
      Chris Wilson 提交于
      In order to improve our diagnostic capabilities following a GPU hang
      and subsequent reset, we need to record the batch buffer that triggered
      the error. We assume that the current batch buffer, plus a few details
      about what else is on the active list, will be sufficient -- at the very
      least an improvement over nothing.
      
      The extra information is stored in /debug/dri/.../i915_error_state
      following an error, and may be decoded using
      intel_gpu_tools/tools/intel_error_decode.
      
      v2: Avoid excessive work under spinlocks.
      v3: Include ringbuffer for later analysis.
      v4: Use kunmap correctly and record more buffer state.
      v5: Search ringbuffer for current batch buffer
      v6: Use a work fn for the impossible IRQ error case.
      v7: Avoid non-atomic paths whilst in IRQ context.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      9df30794