1. 21 Sep, 2010 1 commit
    • Wu Fengguang's avatar
      ALSA: hdmi - support infoframe for DisplayPort · 53d7d69d
      Wu Fengguang authored
      DisplayPort works mostly in the same way as HDMI, except that it expects
      a slightly different audio infoframe format.
      
      Citations from "HDA036-A: Display Port Support and HDMI Miscellaneous
      Corrections":
      
      The HDMI specification defines a data island packet with a header of 4
      bytes (3 bytes content + 1 byte ECC) and packet body of 32 bytes (28
      bytes content and 4 bytes ECC). Display Port specification on the other
      hand defines a data island packet (secondary data packet) with header of
      4 bytes protected by 4 bytes of parity, and data of theoretically up to
      1024 bytes with each 16 bytes chunk of data protected by 4 bytes of
      parity. Note that the ECC or parity bytes are not present in the DIP
      content populated by software and are hardware generated.
      
      It tests DP connection based on the ELD conn_type field, which will be
      set by the graphics driver and can be overriden manually by users
      through the /proc/asound/card0/eld* interface.
      
      The DP infoframe is tested OK on Intel SandyBridge/CougarPoint platform.
      Signed-off-by: default avatarWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      53d7d69d
  2. 20 Sep, 2010 6 commits
  3. 17 Sep, 2010 6 commits
  4. 16 Sep, 2010 7 commits
  5. 14 Sep, 2010 2 commits
  6. 13 Sep, 2010 2 commits
  7. 12 Sep, 2010 1 commit
  8. 11 Sep, 2010 13 commits
  9. 10 Sep, 2010 2 commits
    • mark gross's avatar
      PM QoS: Correct pr_debug() misuse and improve parameter checks · 0109c2c4
      mark gross authored
      Correct some pr_debug() misuse and add a stronger parameter check to
      pm_qos_write() for the ASCII hex value case.  Thanks to Dan Carpenter
      for pointing out the problem!
      Signed-off-by: default avatarmark gross <markgross@thegnar.org>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      0109c2c4
    • Dave Chinner's avatar
      xfs: log IO completion workqueue is a high priority queue · 51749e47
      Dave Chinner authored
      The workqueue implementation in 2.6.36-rcX has changed, resulting
      in the workqueues no longer having dedicated threads for work
      processing. This has caused severe livelocks under heavy parallel
      create workloads because the log IO completions have been getting
      held up behind metadata IO completions.  Hence log commits would
      stall, memory allocation would stall because pages could not be
      cleaned, and lock contention on the AIL during inode IO completion
      processing was being seen to slow everything down even further.
      
      By making the log Io completion workqueue a high priority workqueue,
      they are queued ahead of all data/metadata IO completions and
      processed before the data/metadata completions. Hence the log never
      gets stalled, and operations needed to clean memory can continue as
      quickly as possible. This avoids the livelock conditions and allos
      the system to keep running under heavy load as per normal.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAlex Elder <aelder@sgi.com>
      51749e47