1. 04 1月, 2012 3 次提交
    • J
      drm/i915: add SNB and IVB video sprite support v6 · b840d907
      Jesse Barnes 提交于
      The video sprites support various video surface formats natively and can
      handle scaling as well.  So add support for them using the new DRM core
      sprite support functions.
      
      v2: use drm specific fourcc header and defines
      v3: address Daniel's comments:
        - don't take struct mutex around register access (only needed for
          regs in the GT power well)
        - don't hold struct mutex across vblank waits
        - fix up update_plane API (pass obj instead of GTT offset)
        - add interlaced defines for sprite regs
        - drop unnecessary 'reg' variables
        - comment double buffered reg flushing
        Also fix w/h confusion when writing the scaling reg.
      v4: more fixes, address more comments from Daniel, and include Hai's fix
        - prevent divide by zero in scaling calculation (Hai Lan)
        - update to Ville's new DRM_FORMAT_* types
        - fix sprite watermark handling (calc based on CRTC size, separate
          from normal display wm)
        - remove private refcounts now that the fb cleanups handles things
      v5: add linear surface support
      v6: remove color key clearing & setting from update_plane
      
      For this version, I tested DPMS since it came up in the last review;
      DPMS off/on works ok when a video player is working under X, but for
      power saving we'll probably want to do something smarter.  I'll leave
      that for a separate patch on top.  Likewise with the refcounting/fb
      layer handling, which are really separate cleanups.
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      b840d907
    • K
      drm/i915: Clean up multi-threaded forcewake patch · c7dffff7
      Keith Packard 提交于
      We learned that the ECOBUS register was inside the GT power well, and
      so *did* need force wake to be read, so it gets removed from the list
      of 'doesn't need force wake' registers.
      
      That means the code reading ECOBUS after forcing the mt_force_wake
      function to be called needs to use I915_READ_NOTRACE; it doesn't need
      to do more force wake fun as it's already done it manually.
      
      This also adds a comment explaining why the MT forcewake testing code
      only needs to call mt_forcewake_get/put and not disable RC6 manually
      -- the ECOBUS read will return 0 if the device is in RC6 and isn't
      using MT forcewake, causing the test to work correctly.
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      c7dffff7
    • B
      drm/i915: Update GEN6_RP_CONTROL definitions · 6ed55ee7
      Ben Widawsky 提交于
      This matches the modern specs more accurately.
      
      This will be used by the following patch to fix the way we display RC
      status.
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      6ed55ee7
  2. 20 12月, 2011 5 次提交
  3. 17 12月, 2011 3 次提交
  4. 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
  5. 24 11月, 2011 1 次提交
  6. 17 11月, 2011 1 次提交
  7. 16 11月, 2011 1 次提交
  8. 08 11月, 2011 2 次提交
  9. 29 10月, 2011 2 次提交
  10. 21 10月, 2011 14 次提交
  11. 29 9月, 2011 3 次提交
  12. 28 9月, 2011 2 次提交
  13. 22 9月, 2011 2 次提交
    • K
      drm/i915: FBC off for ironlake and older, otherwise on by default · cd0de039
      Keith Packard 提交于
      Make the default FBC behaviour chipset specific, allowing us to turn
      it on by default for Ironlake and older where it has been seen to
      cause trouble with screen updates.
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      Tested-by: NFrancis Moreau <francis.moro@gmail.com>
      cd0de039
    • W
      drm/i915: pass ELD to HDMI/DP audio driver · e0dac65e
      Wu Fengguang 提交于
      Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
      SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.
      
      ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
      capabilities of the plugged monitor. It's built and passed to audio
      driver in 2 steps:
      
      (1) at get_modes time, parse EDID and save ELD to drm_connector.eld[]
      
      (2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw
          ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver
      
      This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP.
      Test scheme: plug in the HDMI/DP monitor, and run
      
              cat /proc/asound/card0/eld*
      
      to check if the monitor name, HDMI/DP type, etc. show up correctly.
      
      Minor imperfection: the GEN5_AUD_CNTL_ST/DIP_Port_Select field always
      reads 0 (reserved). Without knowing the port number, I worked it around
      by setting the ELD_valid bit for ALL the three ports. It's tested to not
      be a problem, because the audio driver will find invalid ELD data and
      hence rightfully abort, even when it sees the ELD_valid indicator.
      
      Thanks to Zhenyu and Pierre-Louis for a lot of valuable help and testing.
      
      CC: Zhao Yakui <yakui.zhao@intel.com>
      CC: Wang Zhenyu <zhenyu.z.wang@intel.com>
      CC: Jeremy Bush <contractfrombelow@gmail.com>
      CC: Christopher White <c.white@pulseforce.com>
      CC: Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
      CC: Paul Menzel <paulepanter@users.sourceforge.net>
      Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      e0dac65e