- 07 May, 2012 11 commits
-
-
Kirill A. Shutemov authored
Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
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:
-
- 03 May, 2012 27 commits
-
-
Alan Cox authored
Basically a straight cut/paste from the reference driver code then cleaned up a spot. Signed-off-by:
-
Alan Cox authored
If we set a small text framebuffer and have a bigger scanout then we want to send black not random bits for the overscan. Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
We are not yet ready for this and it makes a mess on some devices. Signed-off-by:
-
Kirill A. Shutemov authored
The proper stride value set in mdfld__intel_pipe_set_base(). TODO: move tc35876x support to separate driver and get rid of all if (mdfld_get_panel_type(dev, pipe) == TC35876X) { ... } Signed-off-by: -
Matthew Garrett authored
Add some stub functions for the case where CONFIG_VGA_ARB is disabled. Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
-
Alex Deucher authored
RV250 found on ppc embedded boards. Cc: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Jerome Glisse authored
Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Reviewed-by:
-
Michel Dänzer authored
Just a cosmetic fix to make dmesg a little less confusing. Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
-
Christian König authored
Since it is now identical to evergreen_gpu_is_lockup. Signed-off-by:
Christian König <deathsimple@vodafone.de> Reviewed-by:
-
Christian König authored
Since it is now identical to r100_gpu_is_lockup. Signed-off-by:
-
Christian König authored
Nothing chipset or ring specific with it, so also move it to radon_ring. Signed-off-by:
-
Christian König authored
Fixing just another deadlock problem with gpu reset tests. Signed-off-by:
-
Christian König authored
Don't hard code the 10 seconds timeout. Compute jobs can run much longer. Signed-off-by:
-
Christian König authored
It isn't chipset specific, so it makes no sense to have that inside r100.c. Signed-off-by:
-
Christian König authored
Instead of all this humpy pumpy with recursive mutex (which also fixes only halve of the problem) move the actual gpu reset out of the fence code, return -EDEADLK and then reset the gpu in the calling ioctl function. v2: Split removal of radeon_mutex into separate patch. Return -EAGAIN if reset is successful. Signed-off-by: -
Christian König authored
Rings need to lock in order, otherwise the ring subsystem can deadlock. v2: fix error handling and number of locked doublewords. v3: stop creating unneeded semaphores. Signed-off-by:
-
Christian König authored
It's never used and so practically superfluous. Signed-off-by:
-
Christian König authored
As discussed with Michel that name better describes the behavior of this function. Signed-off-by:
-
Christian König authored
We should signal the caller that we haven't waited at all. v2: only change fence_wait_next not fence_wait_last. Signed-off-by:
-
Christian König authored
Aligning offset can make it bigger than tmp->offset leading to an overrun bug in the following subtraction. v2: Against initial suspicions this can't happen in mainline, so no need to push it into stable. Signed-off-by: -
Christian König authored
Previusly multiple rings could trigger multiple GPU resets at the same time. Signed-off-by:
-
Christian König authored
Removing all the different error messages and having just one standard behaviour over all chipset generations. Signed-off-by:
-
Christian König authored
Just register the debugfs files on init instead of checking the chipset type multiple times. Signed-off-by:
-
Christian König authored
It makes no sense at all to have more than one flag. Signed-off-by:
-
Christian König authored
Different rings have different criteria to test if they are stuck. v2: rebased on current drm-next Signed-off-by:
-
Patrik Jakobsson authored
Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by:
-
- 02 May, 2012 2 commits
-
-
Dave Airlie authored
These can all be trigged from userspace if you pass the right values. v2: rebase on later kernel. Reviewed-by:
-
Dave Airlie authored
Merge tag 'drm-intel-next-2012-04-23' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next Daniel Vetter writes: A new drm-intel-next pull. Highlights: - More gmbus patches from Daniel Kurtz, I think gmbus is now ready, all known issues fixed. - Fencing cleanup and pipelined fencing removal from Chris. - rc6 residency interface from Ben, useful for powertop. - Cleanups and code reorg around the ringbuffer code (Ben&me). - Use hw semaphores in the pageflip code from Ben. - More vlv stuff from Jesse, unfortunately his vlv cpu is doa, so less merged than I've hoped for - we still have the unused function warning :( - More hsw patches from Eugeni, again, not yet enabled fully. - intel_pm.c refactoring from Eugeni. - Ironlake sprite support from Chris. - And various smaller improvements/fixes all over the place. Note that this pull request also contains a backmerge of -rc3 to sort out a few things in -next. I've also had to frob the shortlog a bit to exclude anything that -rc3 brings in with this pull. Regression wise we have a few strange bugs going on, but for all of them closer inspection revealed that they've been pre-existing, just now slightly more likely to be hit. And for most of them we have a patch already. Otherwise QA has not reported any regressions, and I'm also not aware of anything bad happening in 3.4. * tag 'drm-intel-next-2012-04-23' of git://people.freedesktop.org/~danvet/drm-intel: (420 commits) drm/i915: rc6 residency (fix the fix) drm/i915/tv: fix open-coded ARRAY_SIZE. drm/i915: invalidate render cache on gen2 drm/i915: Silence the change of LVDS sync polarity drm/i915: add generic power management initialization drm/i915: move clock gating functionality into intel_pm module drm/i915: move emon functionality into intel_pm module drm/i915: move drps, rps and rc6-related functions to intel_pm drm/i915: fix line breaks in intel_pm drm/i915: move watermarks settings into intel_pm module drm/i915: move fbc-related functionality into intel_pm module drm/i915: Refactor get_fence() to use the common fence writing routine drm/i915: Refactor fence clearing to use the common fence writing routine drm/i915: Refactor put_fence() to use the common fence writing routine drm/i915: Prepare to consolidate fence writing drm/i915: Remove the unsightly "optimisation" from flush_fence() drm/i915: Simplify fence finding drm/i915: Discard the unused obj->last_fenced_ring drm/i915: Remove unused ring->setup_seqno drm/i915: Remove fence pipelining ...
-
