1. 10 8月, 2010 1 次提交
  2. 02 7月, 2010 1 次提交
    • A
      drm/i915: Fix CRT hotplug regression in 2.6.35-rc1 · 2d1c9752
      Andy Lutomirski 提交于
      Commit 7a772c49 has two bugs which
      made the hotplug problems on my laptop worse instead of better.
      
      First, it did not, in fact, disable the CRT plug interrupt -- it
      disabled all the other hotplug interrupts.  It seems rather doubtful
      that that bit of the patch fixed anything, so let's just remove it.
      (If you want to add it back, you probably meant ~CRT_HOTPLUG_INT_EN.)
      
      Second, on at least my GM45, setting CRT_HOTPLUG_ACTIVATION_PERIOD_64
      and CRT_HOTPLUG_VOLTAGE_COMPARE_50 (when they were previously unset)
      causes a hotplug interrupt about three seconds later.  The old code
      never restored PORT_HOTPLUG_EN so this could only happen once, but
      they new code restores those registers.  So just set those bits when
      we set up the interrupt in the first place.
      Signed-off-by: NAndy Lutomirski <luto@mit.edu>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      2d1c9752
  3. 27 5月, 2010 2 次提交
  4. 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
  5. 13 4月, 2010 3 次提交
  6. 10 4月, 2010 2 次提交
  7. 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
  8. 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
  9. 27 2月, 2010 1 次提交
  10. 26 1月, 2010 1 次提交
  11. 17 12月, 2009 1 次提交
  12. 08 12月, 2009 1 次提交
  13. 01 12月, 2009 2 次提交
  14. 26 11月, 2009 1 次提交
  15. 06 11月, 2009 1 次提交
  16. 18 9月, 2009 1 次提交
  17. 05 9月, 2009 1 次提交
    • S
      drm/i915: Support IGD EOS · 04302965
      Shaohua Li 提交于
      In the event that any one of the DAC analog outputs (R,G,B) were driven
      at full-scale (white video) or some analog level close to full-scale
      voltage, and if the video cable were then disconnected, the analog video
      voltage level would exceed the maximum electrical overstress limit of the
      native (thin-oxide) transistors thus causing a long-term reliability concern.
      The electrical overstress condition occurs in this particular case.
      
      This patch address the IGD EOS (electrical overstress condition) issue.
      When the EOS interrupt occurs, OS should disable DAC and then disable EOS,
      then the normal hotplug operation follows.
      
      TODO: it appears the normal unplug interrupt is missed as reported by Li Peng,
      need more checks here.
      Signed-off-by: NShaohua Li <shaohua.li@intel.com>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      04302965
  18. 30 8月, 2009 1 次提交
  19. 25 8月, 2009 1 次提交
  20. 30 7月, 2009 1 次提交
  21. 11 7月, 2009 1 次提交
  22. 08 7月, 2009 2 次提交
  23. 05 6月, 2009 1 次提交
  24. 04 6月, 2009 1 次提交
    • K
      drm: Hook up DPMS property handling in drm_crtc.c. Add drm_helper_connector_dpms. · c9fb15f6
      Keith Packard 提交于
      Making the drm_crtc.c code recognize the DPMS property and invoke the
      connector->dpms function doesn't remove any capability from the driver while
      reducing code duplication.
      
      That just highlighted the problem with the existing DPMS functions which
      could turn off the connector, but failed to turn off any relevant crtcs. The
      new drm_helper_connector_dpms function manages all of that, using the
      drm_helper-specific crtc and encoder dpms functions, automatically computing
      the appropriate DPMS level for each object in the system.
      
      This fixes the current troubles in the i915 driver which left PLLs, pipes
      and planes running while in DPMS_OFF mode or even while they were unused.
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      c9fb15f6
  25. 27 5月, 2009 1 次提交
  26. 15 5月, 2009 1 次提交
  27. 02 4月, 2009 1 次提交
  28. 28 3月, 2009 2 次提交
  29. 29 12月, 2008 2 次提交
    • H
      drm/i915: fix sparse warnings: make symbols static · b358d0a6
      Hannes Eder 提交于
      Signed-off-by: NHannes Eder <hannes@hanneseder.net>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      Signed-off-by: NDave Airlie <airlied@linux.ie>
      b358d0a6
    • J
      DRM: i915: add mode setting support · 79e53945
      Jesse Barnes 提交于
      This commit adds i915 driver support for the DRM mode setting APIs.
      Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
      supported.  HDMI, DisplayPort and additional SDVO output support will
      follow.
      
      Support for the mode setting code is controlled by the new 'modeset'
      module option.  A new config option, CONFIG_DRM_I915_KMS controls the
      default behavior, and whether a PCI ID list is built into the module for
      use by user level module utilities.
      
      Note that if mode setting is enabled, user level drivers that access
      display registers directly or that don't use the kernel graphics memory
      manager will likely corrupt kernel graphics memory, disrupt output
      configuration (possibly leading to hangs and/or blank displays), and
      prevent panic/oops messages from appearing.  So use caution when
      enabling this code; be sure your user level code supports the new
      interfaces.
      
      A new SysRq key, 'g', provides emergency support for switching back to
      the kernel's framebuffer console; which is useful for testing.
      
      Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      79e53945