1. 10 8月, 2010 3 次提交
  2. 02 8月, 2010 3 次提交
  3. 27 7月, 2010 1 次提交
  4. 19 6月, 2010 1 次提交
  5. 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
  6. 19 4月, 2010 1 次提交
  7. 13 4月, 2010 1 次提交
  8. 10 4月, 2010 4 次提交
  9. 07 4月, 2010 2 次提交
    • D
      drm/kms/fb: use slow work mechanism for normal hotplug also. · 4abe3520
      Dave Airlie 提交于
      a) slow work is always used now for any fbcon hotplug, as its not
         a fast task and is more suited to being ran under slow work.
      
      b) attempt to not do any fbdev changes when X is running as we'll
         just mess it up. This hooks set_par to hopefully do the changes
         once X hands control to fbdev.
      
      This also adds the nouveau/intel hotplug support.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      4abe3520
    • 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
  10. 26 3月, 2010 1 次提交
    • E
      drm/i915: Rename intel_output to intel_encoder. · 21d40d37
      Eric Anholt 提交于
      The intel_output naming is inherited from the UMS code, which had a
      structure of screen -> CRTC -> output.  The DRM code has an additional
      notion of encoder/connector, so the structure is screen -> CRTC ->
      encoder -> connector.  This is a useful structure for SDVO encoders
      which can support multiple connectors (each of which requires
      different programming in the one encoder and could be connected to
      different CRTCs), or for DVI-I, where multiple encoders feed into the
      connector for whether it's used for digital or analog.  Most of our
      code is encoder-related, so transition it to talking about encoders
      before we start trying to distinguish connectors.
      
      This patch is produced by sed s/intel_output/intel_encoder/ over the
      driver.
      Signed-off-by: NEric Anholt <eric@anholt.net>
      21d40d37
  11. 23 2月, 2010 1 次提交
  12. 08 12月, 2009 1 次提交
  13. 02 12月, 2009 2 次提交
  14. 06 11月, 2009 3 次提交
    • D
      drm/i915: implement interruptible sleeps in the overlay code · 03f77ea5
      Daniel Vetter 提交于
      At least for the common case of userspace ioctls. When doing a
      modeset operation, the wait is still uninterruptible. But considering
      that failing to turn off the overlay when switching off the crtc it's
      running on hangs the chip, it doesn't complicate matters _very_
      much. There's just an unkillable X in addition to a black screen.
      BUG() about it and explain in the code.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      03f77ea5
    • D
      drm/i915: implement fastpath for overlay flip waiting · 5a5a0c64
      Daniel Vetter 提交于
      As long as the gpu can keep up, neither the cpu (waiting for gpu)
      nore the gpu (waiting for vblank to do an overlay flip) stalls.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      5a5a0c64
    • D
      drm/i915: implement drmmode overlay support v4 · 02e792fb
      Daniel Vetter 提交于
      This implements intel overlay support for kms via a device-specific
      ioctl. Thomas Hellstrom brought up the idea of a general ioctl (on
      dri-devel). We've reached the conclusion that such an infrastructure
      only makes sense when multiple kms overlay implementations exists,
      which atm don't (and it doesn't look like this is gonna change).
      
      Open issues:
      - Runs in sync with the gpu, i.e. unnecessary waiting. I've decided
        to wait on this because the hw tends to hang when changing something
        in this area. I left some dummy functions as infrastructure.
      - polyphase filtering uses a static table.
      - uses uninterruptible sleeps. Unfortunately the alternatives may
        unnecessarily wedged the hw if/when we timeout too early (and
        userspace only overloaded the batch buffers with stuff worth a few
        secs of gpu time).
      
      Changes since v1:
      - fix off-by-one misconception on my side. This fixes fullscreen
        playback.
      Changes since v2:
      - add underrun detection as spec'ed for i965.
      - flush caches properly, fixing visual corruptions.
      Changes since v4:
      - fix up cache flushing of overlay memory regs.
      - killed require_pipe_a logic - it hangs the chip.
      
      Tested-By: diego.abelenda@gmail.com (on a 865G)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      [anholt: Resolved against the MADVISE ioctl going in before this one]
      Signed-off-by: NEric Anholt <eric@anholt.net>
      02e792fb
  15. 06 10月, 2009 1 次提交
    • D
      drm/fb: add more correct 8/16/24/32 bpp fb support. · b8c00ac5
      Dave Airlie 提交于
      The previous patches had some unwanted side effects, I've fixed
      the lack of 32bpp working, and fixed up 16bpp so it should also work.
      
      this also adds the interface to allow the driver to set a preferred
      console depth so for example low memory rn50 can set it to 8bpp.
      It also catches 24bpp on cards that can't do it and forces 32bpp.
      
      Tested on r100/r600/i945.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      b8c00ac5
  16. 21 9月, 2009 1 次提交
    • D
      drm/vgaarb: add VGA arbitration support to the drm and kms. · 28d52043
      Dave Airlie 提交于
      VGA arb requires DRM support for non-kms drivers, to turn on/off
      irqs when disabling the mem/io regions.
      
      VGA arb requires KMS support for GPUs where we can turn off VGA
      decoding. Currently we know how to do this for intel and radeon
      kms drivers, which allows them to be removed from the arbiter.
      
      This patch comes from Fedora rawhide kernel.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      28d52043
  17. 11 9月, 2009 1 次提交
    • J
      drm/i915: framebuffer compression for pre-GM45 · 80824003
      Jesse Barnes 提交于
      This patch adds framebuffer compression (good for about ~0.5W power
      savings in the best case) support for pre-GM45 chips.  GM45+ have a new,
      more flexible FBC scheme that will be added in a separate patch.
      
      FBC can't always be enabled: the compressed buffer must be physically
      contiguous and reside in stolen space.  So if you have a large display
      and a small amount of stolen memory, you may not be able to take
      advantage of FBC.  In some cases, a BIOS setting controls how much
      stolen space is available.  Increasing this to 8 or 16M can help.
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      80824003
  18. 09 9月, 2009 1 次提交
  19. 05 9月, 2009 1 次提交
    • J
      drm/i915: add dynamic clock frequency control · 652c393a
      Jesse Barnes 提交于
      There are several sources of unnecessary power consumption on Intel
      graphics systems. The first is the LVDS clock. TFTs don't suffer from
      persistence issues like CRTs, and so we can reduce the LVDS refresh rate
      when the screen is idle. It will be automatically upclocked when
      userspace triggers graphical activity. Beyond that, we can enable memory
      self refresh. This allows the memory to go into a lower power state when
      the graphics are idle. Finally, we can drop some clocks on the gpu
      itself. All of these things can be reenabled between frames when GPU
      activity is triggered, and so there should be no user visible graphical
      changes.
      Signed-off-by: NJesse Barnes <jesse.barnes@intel.com>
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      652c393a
  20. 31 8月, 2009 1 次提交
    • D
      drm/kms: move driver specific fb common code to helper functions (v2) · 785b93ef
      Dave Airlie 提交于
      Initially I always meant this code to be shared, but things
      ran away from me before I got to it.
      
      This refactors the i915 and radeon kms fbdev interaction layers
      out into generic helpers + driver specific pieces.
      
      It moves all the panic/sysrq enhancements to the core file,
      and stores a linked list of kernel fbs. This could possibly be
      improved to only store the fb which has fbcon on it for panics
      etc.
      
      radeon retains some specific codes used for a big endian
      workaround.
      
      changes:
      fix oops in v1
      fix freeing path for crtc_info
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      785b93ef
  21. 25 8月, 2009 1 次提交
  22. 30 7月, 2009 1 次提交
  23. 19 6月, 2009 3 次提交
  24. 15 5月, 2009 2 次提交
  25. 08 2月, 2009 1 次提交
  26. 07 1月, 2009 1 次提交