1. 18 11月, 2010 2 次提交
  2. 24 9月, 2010 4 次提交
  3. 06 8月, 2010 2 次提交
  4. 09 4月, 2010 1 次提交
  5. 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
  6. 10 3月, 2010 1 次提交
  7. 25 2月, 2010 1 次提交
  8. 10 2月, 2010 1 次提交
  9. 09 2月, 2010 1 次提交
  10. 18 1月, 2010 1 次提交
    • L
      drm/nouveau: Acknowledge DMA_VTX_PROTECTION PGRAPH interrupts · d051bbb2
      Luca Barbieri 提交于
      Currently Nouveau is unable to dismiss DMA_VTX_PROTECTION errors,
      which results in an infinite loop in the interrupt handler.
      
      These errors are caused both by bugs in the Gallium driver and by
      user-specified index buffers with out of bounds indices.
      
      By mmio-tracing the nVidia drivers, I found out how this is done.
      On DMA_VTX_PROTECTION, The nVidia driver reads the register 0x402000,
      always getting the value 4, and then writes 4 back to 0x402000.
      
      This patch adds that logic by reading 0x402000 and writing the same
      value back.
      It's unclear what should happen if the value read is not 4, and
      the current approach might not be the correct one.
      
      To test this, modify mesa/progs/trivial/vbo-drawrange.c, defining
      ELTOBJ to 1 and replacing indices with huge out of bounds integers.
      
      Without this patch, the GPU and/or kernel should lock up.
      With this patch, it should misrender as expected but not lock up.
      
      The errors are still logged since they are useful for development.
      
      This has been tested on NV49 and may not work on other cards.
      
      To find out how things work on other cards, run the aforementioned
      test using the blob with mmiotrace and grep for a read of the PGRAPH
      source register.
      Signed-off-by: NLuca Barbieri <luca@luca-barbieri.com>
      Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      d051bbb2
  11. 11 1月, 2010 2 次提交
    • B
      drm/nv50: prevent a possible ctxprog hang · dc8d76ca
      Ben Skeggs 提交于
      The below is mainly an educated guess at what's going on, docs would
      sure be handy...  NVIDIA? :P
      
      It appears it's possible for a ctxprog to run even while a GPU exception
      is pending.  The GF8 and up ctxprogs appear to have a small snippet of
      code which detects this, and stalls the ctxprog until it's been handled,
      which essentially looks like:
      
      	if (r2 & 0x00008000) {
      		r0 |= 0x80000000;
      		while (r0 & 0x80000000) {}
      	}
      
      I don't know of any way that flag would get cleared unless the driver
      intervenes (and indeed, in the cases I've seen the hang, nothing steps
      in to automagically clear it for us).  This patch causes the driver to
      clear the flag during the PGRAPH IRQ handler.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      dc8d76ca
    • B
      drm/nv50: prevent a possible ctxprog hang · 7978b9cf
      Ben Skeggs 提交于
      The below is mainly an educated guess at what's going on, docs would
      sure be handy...  NVIDIA? :P
      
      It appears it's possible for a ctxprog to run even while a GPU exception
      is pending.  The GF8 and up ctxprogs appear to have a small snippet of
      code which detects this, and stalls the ctxprog until it's been handled,
      which essentially looks like:
      
      	if (r2 & 0x00008000) {
      		r0 |= 0x80000000;
      		while (r0 & 0x80000000) {}
      	}
      
      I don't know of any way that flag would get cleared unless the driver
      intervenes (and indeed, in the cases I've seen the hang, nothing steps
      in to automagically clear it for us).  This patch causes the driver to
      clear the flag during the PGRAPH IRQ handler.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      7978b9cf
  12. 11 12月, 2009 1 次提交
    • B
      drm/nouveau: Add DRM driver for NVIDIA GPUs · 6ee73861
      Ben Skeggs 提交于
      This adds a drm/kms staging non-API stable driver for GPUs from NVIDIA.
      
      This driver is a KMS-based driver and requires a compatible nouveau
      userspace libdrm and nouveau X.org driver.
      
      This driver requires firmware files not available in this kernel tree,
      interested parties can find them via the nouveau project git archive.
      
      This driver is reverse engineered, and is in no way supported by nVidia.
      
      Support for nearly the complete range of nvidia hw from nv04->g80 (nv50)
      is available, and the kms driver should support driving nearly all
      output types (displayport is under development still) along with supporting
      suspend/resume.
      
      This work is all from the upstream nouveau project found at
      nouveau.freedesktop.org.
      
      The original authors list from nouveau git tree is:
      Anssi Hannula <anssi.hannula@iki.fi>
      Ben Skeggs <bskeggs@redhat.com>
      Francisco Jerez <currojerez@riseup.net>
      Maarten Maathuis <madman2003@gmail.com>
      Marcin Kościelnicki <koriakin@0x04.net>
      Matthew Garrett <mjg@redhat.com>
      Matt Parnell <mparnell@gmail.com>
      Patrice Mandin <patmandin@gmail.com>
      Pekka Paalanen <pq@iki.fi>
      Xavier Chantry <shiningxc@gmail.com>
      along with project founder Stephane Marchesin <marchesin@icps.u-strasbg.fr>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      6ee73861