1. 25 2月, 2012 2 次提交
  2. 24 2月, 2012 2 次提交
  3. 16 2月, 2012 1 次提交
    • E
      drm/i915: do not enable RC6p on Sandy Bridge · 1c8ecf80
      Eugeni Dodonov 提交于
      With base on latest findings, RC6p seems to be respondible for RC6-related
      issues on Sandy Bridge platform. To work-around those issues, the previous
      solution was to completely disable RC6 on Sandy Bridge for the past few
      releases, even if plain RC6 was not giving any issues.
      
      What this patch does is preventing RC6p from being enabled on Sandy Bridge
      even if users enable RC6 via a kernel parameter. So it won't change the
      defaults in any way, but will ensure that if users do enable RC6 manually
      it won't break their machines by enabling this extra state.
      
      Proper fix for this (enabling specific RC6 states according to the GPU
      generation) were proposed for the -next kernel, but we are too late in the
      release process now to pick such changes.
      Acked-by: NKeith Packard <keithp@keithp.com>
      Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      1c8ecf80
  4. 11 2月, 2012 4 次提交
  5. 09 2月, 2012 1 次提交
    • K
      drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT (v2) · 617cf884
      Keith Packard 提交于
      An identical patch has been merged for i9xx_crtc_mode_set:
      
      Commit 59df7b17
      Author: Christian Schmidt <schmidt@digadd.de>
      Date:   Mon Dec 19 20:03:33 2011 +0100
      
          drm/intel: Fix initialization if startup happens in interlaced mode [v2]
      
      But that one neglected to fix up the ironlake+ path.
      
      This should fix the issue reported by Alfonso Fiore where booting with
      only a HDMI cable connected to his TV failed to display anything. The
      issue is that the bios set up things for 1080i and used the pannel
      fitter to scale up the lower progressive resolutions. We failed to
      clear the interlace bit in the PIPEACONF register, resulting in havoc.
      
      v2: Be more paranoid and just unconditionally clear the field before
      setting new values.
      
      Cc: Peter Ross <pross@xvid.org>
      Cc: Alfonso Fiore <alfonso.fiore@gmail.com>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      617cf884
  6. 29 1月, 2012 1 次提交
  7. 28 1月, 2012 1 次提交
  8. 14 1月, 2012 1 次提交
  9. 13 1月, 2012 1 次提交
  10. 04 1月, 2012 6 次提交
  11. 27 12月, 2011 1 次提交
  12. 20 12月, 2011 5 次提交
  13. 17 12月, 2011 3 次提交
  14. 01 12月, 2011 1 次提交
    • V
      drm: Redefine pixel formats · 04b3924d
      Ville Syrjälä 提交于
      Name the formats as DRM_FORMAT_X instead of DRM_FOURCC_X. Use consistent
      names, especially for the RGB formats. Component order and byte order are
      now strictly specified for each format.
      
      The RGB format naming follows a convention where the components names
      and sizes are listed from left to right, matching the order within a
      single pixel from most significant bit to least significant bit.
      
      The YUV format names vary more. For the 4:2:2 packed formats and 2
      plane formats use the fourcc. For the three plane formats the
      name includes the plane order and subsampling information using the
      standard subsampling notation. Some of those also happen to match
      the official fourcc definition.
      
      The fourccs for for all the RGB formats and some of the YUV formats
      I invented myself. The idea was that looking at just the fourcc you
      get some idea what the format is about without having to decode it
      using some external reference.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      04b3924d
  15. 24 11月, 2011 1 次提交
  16. 17 11月, 2011 1 次提交
  17. 16 11月, 2011 1 次提交
  18. 08 11月, 2011 2 次提交
  19. 29 10月, 2011 2 次提交
  20. 21 10月, 2011 3 次提交