1. 14 May, 2014 13 commits
  2. 09 May, 2014 6 commits
  3. 08 May, 2014 9 commits
  4. 07 May, 2014 6 commits
  5. 06 May, 2014 6 commits
    • Dave Airlie's avatar
      Merge branch 'mullins' of git://people.freedesktop.org/~deathsimple/linux into drm-fixes · 995c376e
      Dave Airlie authored
      Add Mullins chips support.
      
      * 'mullins' of git://people.freedesktop.org/~deathsimple/linux:
        drm/radeon: add pci ids for Mullins
        drm/radeon: add Mullins VCE support
        drm/radeon: modesetting updates for Mullins.
        drm/radeon: dpm updates for KV/KB
        drm/radeon: add Mullins dpm support.
        drm/radeon: add Mullins UVD support.
        drm/radeon: update cik init for Mullins.
        drm/radeon: add Mullins chip family
      995c376e
    • Dave Airlie's avatar
      Merge branch 'drm-nouveau-next' of... · 2a1235e5
      Dave Airlie authored
      Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
      
      nouveau fixes.
      
      * 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
        drm/gm107/gr: bump attrib cb size quite a bit
        drm/nouveau: fix another lock unbalance in nouveau_crtc_page_flip
        drm/nouveau/bios: fix shadowing from PROM on big-endian systems
        drm/nouveau/acpi: allow non-optimus setups to load vbios from acpi
      2a1235e5
    • Dave Airlie's avatar
      Merge tag 'topc/core-stuff-2014-05-05' of git://anongit.freedesktop.org/drm-intel into drm-fixes · 508200c5
      Dave Airlie authored
      Some more i915 fixes. There's still some DP issues we are looking into,
      but wanted to get these moving.
      
      * tag 'topc/core-stuff-2014-05-05' of git://anongit.freedesktop.org/drm-intel:
        drm/i915: don't try DP_LINK_BW_5_4 on HSW ULX
        drm/i915: Sanitize the enable_ppgtt module option once
        drm/i915: Break encoder->crtc link separately in intel_sanitize_crtc()
      508200c5
    • Dave Airlie's avatar
      Merge branch 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux into drm-fixes · 9eabb911
      Dave Airlie authored
      this is the next pull quested for stashed up radeon fixes for 3.15. As discussed support for Mullins was separated out and will get it's own pull request. Remaining highlights are:
      1. Some more patches to better handle PLL limits.
      2. Making use of the PFLIP additional to the VBLANK interrupt, otherwise we sometimes miss page flip events.
      3. Fix for the UVD command stream parser.
      4. Fix for bootup UVD clocks on RV7xx systems.
      5. Adding missing error check on dpcd reads.
      6. Fixes number of banks calculation on SI.
      
      * 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux:
        drm/radeon: lower the ref * post PLL maximum
        drm/radeon: check that we have a clock before PLL setup
        drm/radeon: drm/radeon: add missing radeon_semaphore_free to error path
        drm/radeon: Fix num_banks calculation for SI
        drm/radeon/dp: check for errors in dpcd reads
        drm/radeon: avoid high jitter with small frac divs
        drm/radeon: check buffer relocation offset
        drm/radeon: use pflip irq on R600+ v2
        drm/radeon/uvd: use lower clocks on old UVD to boot v2
      9eabb911
    • Dave Chinner's avatar
      xfs: fix directory readahead offset off-by-one · 8cfcc3e5
      Dave Chinner authored
      Directory readahead can throw loud scary but harmless warnings
      when multiblock directories are in use a specific pattern of
      discontiguous blocks are found in the directory. That is, if a hole
      follows a discontiguous block, it will throw a warning like:
      
      XFS (dm-1): xfs_da_do_buf: bno 637 dir: inode 34363923462
      XFS (dm-1): [00] br_startoff 637 br_startblock 1917954575 br_blockcount 1 br_state 0
      XFS (dm-1): [01] br_startoff 638 br_startblock -2 br_blockcount 1 br_state 0
      
      And dump a stack trace.
      
      This is because the readahead offset increment loop does a double
      increment of the block index - it does an increment for the loop
      iteration as well as increase the loop counter by the number of
      blocks in the extent. As a result, the readahead offset does not get
      incremented correctly for discontiguous blocks and hence can ask for
      readahead of a directory block from an offset part way through a
      directory block.  If that directory block is followed by a hole, it
      will trigger a mapping warning like the above.
      
      The bad readahead will be ignored, though, because the main
      directory block read loop uses the correct mapping offsets rather
      than the readahead offset and so will ignore the bad readahead
      altogether.
      
      Fix the warning by ensuring that the readahead offset is correctly
      incremented.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      8cfcc3e5
    • Dave Chinner's avatar
      xfs: don't sleep in xlog_cil_force_lsn on shutdown · ac983517
      Dave Chinner authored
      Reports of a shutdown hang when fsyncing a directory have surfaced,
      such as this:
      
      [ 3663.394472] Call Trace:
      [ 3663.397199]  [<ffffffff815f1889>] schedule+0x29/0x70
      [ 3663.402743]  [<ffffffffa01feda5>] xlog_cil_force_lsn+0x185/0x1a0 [xfs]
      [ 3663.416249]  [<ffffffffa01fd3af>] _xfs_log_force_lsn+0x6f/0x2f0 [xfs]
      [ 3663.429271]  [<ffffffffa01a339d>] xfs_dir_fsync+0x7d/0xe0 [xfs]
      [ 3663.435873]  [<ffffffff811df8c5>] do_fsync+0x65/0xa0
      [ 3663.441408]  [<ffffffff811dfbc0>] SyS_fsync+0x10/0x20
      [ 3663.447043]  [<ffffffff815fc7d9>] system_call_fastpath+0x16/0x1b
      
      If we trigger a shutdown in xlog_cil_push() from xlog_write(), we
      will never wake waiters on the current push sequence number, so
      anything waiting in xlog_cil_force_lsn() for that push sequence
      number to come up will not get woken and hence stall the shutdown.
      
      Fix this by ensuring we call wake_up_all(&cil->xc_commit_wait) in
      the push abort handling, in the log shutdown code when waking all
      waiters, and adding a shutdown check in the sequence completion wait
      loops to ensure they abort when a wakeup due to a shutdown occurs.
      Reported-by: default avatarBoris Ranto <branto@redhat.com>
      Reported-by: default avatarEric Sandeen <esandeen@redhat.com>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      ac983517