Skip to content

L
linux
Switch branch/tag
  1. 09 May, 2012 5 commits
    • Christian König's avatar
      drm/radeon: rework locking ring emission mutex in fence deadlock detection v2 · 8a47cc9e
      Christian König authored 
      Some callers illegal called fence_wait_next/empty
while holding the ring emission mutex. So don't
relock the mutex in that cases, and move the actual
locking into the fence code.

v2: Don't try to unlock the mutex if it isn't locked.
Signed-off-by: default avatarChristian König <deathsimple@vodafone.de>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      8a47cc9e
    • Jerome Glisse's avatar
      drm/radeon: rework fence handling, drop fence list v7 · 3b7a2b24
      Jerome Glisse authored 
      Using 64bits fence sequence we can directly compare sequence
number to know if a fence is signaled or not. Thus the fence
list became useless, so does the fence lock that mainly
protected the fence list.

Things like ring.ready are no longer behind a lock, this should
be ok as ring.ready is initialized once and will only change
when facing lockup. Worst case is that we return an -EBUSY just
after a successfull GPU reset, or we go into wait state instead
of returning -EBUSY (thus delaying reporting -EBUSY to fence
wait caller).

v2: Remove left over comment, force using writeback on cayman and
    newer, thus not having to suffer from possibly scratch reg
    exhaustion
v3: Rebase on top of change to uint64 fence patch
v4: Change DCE5 test to force write back on cayman and newer but
    also any APU such as PALM or SUMO family
v5: Rebase on top of new uint64 fence patch
v6: Just break if seq doesn't change any more. Use radeon_fence
    prefix for all function names. Even if it's now highly optimized,
    try avoiding polling to often.
v7: We should never poll the last_seq from the hardware without
    waking the sleeping threads, otherwise we might lose events.
Signed-off-by: default avatarJerome Glisse <jglisse@redhat.com>
Signed-off-by: default avatarChristian König <deathsimple@vodafone.de>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      3b7a2b24
    • Jerome Glisse's avatar
      drm/radeon: convert fence to uint64_t v4 · bb635567
      Jerome Glisse authored 
      This convert fence to use uint64_t sequence number intention is
to use the fact that uin64_t is big enough that we don't need to
care about wrap around.

Tested with and without writeback using 0xFFFFF000 as initial
fence sequence and thus allowing to test the wrap around from
32bits to 64bits.

v2: Add comment about possible race btw CPU & GPU, add comment
    stressing that we need 2 dword aligned for R600_WB_EVENT_OFFSET
    Read fence sequenc in reverse order of GPU write them so we
    mitigate the race btw CPU and GPU.

v3: Drop the need for ring to emit the 64bits fence, and just have
    each ring emit the lower 32bits of the fence sequence. We
    handle the wrap over 32bits in fence_process.

v4: Just a small optimization: Don't reread the last_seq value
    if loop restarts, since we already know its value anyway.
    Also start at zero not one for seq value and use pre instead
    of post increment in emmit, otherwise wait_empty will deadlock.
Signed-off-by: default avatarJerome Glisse <jglisse@redhat.com>
Signed-off-by: default avatarChristian König <deathsimple@vodafone.de>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      bb635567
    • Christian König's avatar
      drm/radeon: replace the per ring mutex with a global one · d6999bc7
      Christian König authored 
      A single global mutex for ring submissions seems sufficient.
Signed-off-by: default avatarChristian König <deathsimple@vodafone.de>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      d6999bc7
    • Jerome Glisse's avatar
      drm/radeon: fix possible lack of synchronization btw ttm and other ring · 133f4cb3
      Jerome Glisse authored 
      We need to sync with the GFX ring as ttm might have schedule bo move
on it and new command scheduled for other ring need to wait for bo
data to be in place.
Signed-off-by: default avatarJerome Glisse <jglisse@redhat.com>
Reviewed by: Christian König <christian.koenig@amd.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      133f4cb3
  3. 07 May, 2012 15 commits
  5. 06 May, 2012 5 commits
  7. 05 May, 2012 10 commits
  9. 04 May, 2012 5 commits
    • Linus Torvalds's avatar
      Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · f756beba
      Linus Torvalds authored 
      Pull timer fix from Thomas Gleixner.

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  rtc: Fix possible null pointer dereference in rtc-mpc5121.c
      f756beba
    • Linus Torvalds's avatar
      Merge git://git.samba.org/sfrench/cifs-2.6 · c6de1687
      Linus Torvalds authored 
      Pull CIFS fixes from Steve French.

* git://git.samba.org/sfrench/cifs-2.6:
  fs/cifs: fix parsing of dfs referrals
  cifs: make sure we ignore the credentials= and cred= options
  [CIFS] Update cifs version to 1.78
  cifs - check S_AUTOMOUNT in revalidate
  cifs: add missing initialization of server->req_lock
  cifs: don't cap ra_pages at the same level as default_backing_dev_info
  CIFS: Fix indentation in cifs_show_options
      c6de1687
    • Dave Jones's avatar
      CPU frequency drivers MAINTAINERS update · a03a09b2
      Dave Jones authored 
      Remove myself as cpufreq maintainer.
x86 driver changes can go through the regular x86/ACPI trees.
ARM driver changes through the ARM trees.
cpufreq core changes are rare these days, and can just go to lkml/direct.
Signed-off-by: default avatarDave Jones <davej@redhat.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a03a09b2
    • Linus Torvalds's avatar
      seqlock: add 'raw_seqcount_begin()' function · 4f988f15
      Linus Torvalds authored 
      The normal read_seqcount_begin() function will wait for any current
writers to exit their critical region by looping until the sequence
count is even.

That "wait for sequence count to stabilize" is the right thing to do if
the read-locker will just retry the whole operation on contention: no
point in doing a potentially expensive reader sequence if we know at the
beginning that we'll just end up re-doing it all.

HOWEVER.  Some users don't actually retry the operation, but instead
will abort and do the operation with proper locking.  So the sequence
count case may be the optimistic quick case, but in the presense of
writers you may want to do full locking in order to guarantee forward
progress.  The prime example of this would be the RCU name lookup.

And in that case, you may well be better off without the "retry early",
and are in a rush to instead get to the failure handling.  Thus this
"raw" interface that just returns the sequence number without testing it
- it just forces the low bit to zero so that read_seqcount_retry() will
always fail such a "active concurrent writer" scenario.
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4f988f15
    • Linus Torvalds's avatar
      Fix __read_seqcount_begin() to use ACCESS_ONCE for sequence value read · 2f624278
      Linus Torvalds authored 
      We really need to use a ACCESS_ONCE() on the sequence value read in
__read_seqcount_begin(), because otherwise the compiler might end up
reloading the value in between the test and the return of it.  As a
result, it might end up returning an odd value (which means that a write
is in progress).

If the reader is then fast enough that that odd value is still the
current one when the read_seqcount_retry() is done, we might end up with
a "successful" read sequence, even despite the concurrent write being
active.

In practice this probably never really happens - there just isn't
anything else going on around the read of the sequence count, and the
common case is that we end up having a read barrier immediately
afterwards.

So the code sequence in which gcc might decide to reaload from memory is
small, and there's no reason to believe it would ever actually do the
reload.  But if the compiler ever were to decide to do so, it would be
incredibly annoying to debug.  Let's just make sure.

Cc: stable@kernel.org
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2f624278
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7