- 11 May, 2012 5 commits
-
-
Alan Cox authored
Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Alan Cox authored
All the conditional ugly register selection really wants to be cleaned up. Use a struct describing each pipe and its registers. This will also let us hide some of the oddments between platforms for any future merging of bits together. In particular the way the DPLL and FP registers randomly wander around. Signed-off-by:
-
Alan Cox authored
We have lots of local assignments that can now be eliminated Signed-off-by:
-
Alan Cox authored
This starts the move away from lots of confused unions of per driver stuff inherited when we merged the drivers together. Signed-off-by:
-
Alan Cox authored
Reported-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
- 09 May, 2012 20 commits
-
-
Dave Airlie authored
/ssd/git/drm-core-next/drivers/gpu/drm/radeon/radeon_fence.c: In function ‘radeon_debugfs_fence_info’: /ssd/git/drm-core-next/drivers/gpu/drm/radeon/radeon_fence.c:606:7: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘long long int’ [-Wformat] Signed-off-by: -
Jerome Glisse authored
No need to malloc it any more. Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Signed-off-by:
Christian König <deathsimple@vodafone.de> Signed-off-by:
-
Christian König authored
If we don't store local data into global variables it isn't necessary to lock anything. v2: rebased on new SA interface Signed-off-by:
-
Jerome Glisse authored
It never really belonged there in the first place. Signed-off-by:
-
Christian König authored
We can now protected the semaphore ram by a fence, so free it immediately. Signed-off-by:
-
Jerome Glisse authored
It isn't necessary any more and the suballocator seems to perform even better. Signed-off-by:
-
Jerome Glisse authored
Directly use the suballocator to get small chunks of memory. It's equally fast and doesn't crash when we encounter a GPU reset. v2: rebased on new SA interface. Signed-off-by:
-
Christian König authored
A startover with a new idea for a multiple ring allocator. Should perform as well as a normal ring allocator as long as only one ring does somthing, but falls back to a more complex algorithm if more complex things start to happen. We store the last allocated bo in last, we always try to allocate after the last allocated bo. Principle is that in a linear GPU ring progression was is after last is the oldest bo we allocated and thus the first one that should no longer be in use by the GPU. If it's not the case we skip over the bo after last to the closest done bo if such one exist. If none exist and we are not asked to block we report failure to allocate. If we are asked to block we wait on all the oldest fence of all rings. We just wait for any of those fence to complete. v2: We need to be able to let hole point to the list_head, otherwise try free will never free the first allocation of the list. Also stop calling radeon_fence_signalled more than necessary. v3: Don't free allocations without considering them as a hole, otherwise we might lose holes. Also return ENOMEM instead of ENOENT when running out of fences to wait for. Limit the number of holes we try for each ring to 3. Signed-off-by: -
Jerome Glisse authored
Use one wait queue for all rings. When one ring progress, other likely does to and we are not expecting to have a lot of waiter anyway. Also add a fence_wait_any that will wait until the first fence in the fence array (one fence per ring) is signaled. This allow to wait on all rings. v2: some minor cleanups and improvements. Signed-off-by:
-
Christian König authored
Define the interface without modifying the allocation algorithm in any way. v2: rebase on top of fence new uint64 patch v3: add ring to debugfs output Signed-off-by:
-
Christian König authored
Allocating and freeing it seperately. Signed-off-by:
-
Christian König authored
Instead of offset + size keep start and end offset directly. Signed-off-by:
-
Christian König authored
Dumping the current allocations. Signed-off-by:
-
Christian König authored
Make the suballocator self containing to locking. v2: split the bugfix into a seperate patch. v3: remove some unreleated changes. Sig-off-by:
-
Christian König authored
Instead of hacking the calculation multiple times. Signed-off-by:
-
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:
-
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: -
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: -
Christian König authored
A single global mutex for ring submissions seems sufficient. Signed-off-by:
-
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:
-
- 07 May, 2012 15 commits
-
-
git://people.freedesktop.org/~danvet/drm-intelDave Airlie authored
Daniel prepared this branch with a back-merge as git was getting very confused about changes in intel_display.c
-
Daniel Vetter authored
Conflicts: drivers/gpu/drm/i915/intel_display.c Ok, this is a fun story of git totally messing things up. There /shouldn't/ be any conflict in here, because the fixes in -rc6 do only touch functions that have not been changed in -next. The offending commits in drm-next are 14415745..1fa61106 which simply move a few functions from intel_display.c to intel_pm.c. The problem seems to be that git diff gets completely confused: $ git diff 14415745..1fa61106 is a nice mess in intel_display.c, and the diff leaks into totally unrelated functions, whereas $git diff --minimal 14415745..1fa61106 is exactly what we want. Unfortunately there seems to be no way to teach similar smarts to the merge diff and conflict generation code, because with the minimal diff there really shouldn't be any conflicts. For added hilarity, every time something in that area changes the + and - lines in the diff move around like crazy, again resulting in new conflicts. So I fear this mess will stay with us for a little longer (and might result in another backmerge down the road). Signed-Off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Kirill A. Shutemov authored
Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
-
Kirill A. Shutemov authored
cc1: warning: include/drm: No such file or directory [enabled by default] It's reproducible if you build with O=/some/obj/dir and W=1. Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Kirill A. Shutemov authored
This was mostly already fixed but this one change is needed to match Kirill's original submission Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Alan Cox authored
We need this for Poulsbo Signed-off-by:
-
Alan Cox authored
Add the opregion support and bring us in line with the opregion functionality in the reference driver code. We can't share this with i915 currently because there are hardcoded assumptions about dev_priv etc in both versions. [airlied: include opregion.h fix] Signed-off-by:
-
