- 29 Sep, 2010 2 commits
-
-
Chris Wilson authored
Replaced by tracepoints. Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
This has bitrotted through inuse and superseded by tracing and debugfs. Signed-off-by:
-
- 28 Sep, 2010 8 commits
-
-
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
This check only appears to succeed when using GMBUS, so we need to skip it if we have fallen back to using GPIO bit banging. Signed-off-by: -
Chris Wilson authored
-
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
There are several reported instances of GMBUS failing to successfully read the EDID, so revert back to bit banging until the issue is resolved. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30371Signed-off-by:
-
Chris Wilson authored
Besides a couple of bugs when writing more than a single byte along the GMBUS, SDVO was completely failing whilst trying to use GMBUS, so use bit banging instead. Signed-off-by: -
Chris Wilson authored
With multiple rings generating requests independently, the outstanding requests must also be track independently. Reported-by:
Wang Jinjin <jinjin.wang@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30380Signed-off-by:
-
- 27 Sep, 2010 1 commit
-
-
Jesse Barnes authored
The IPS driver needs to know the current power consumption of the GMCH in order to make decisions about when to increase or decrease the CPU and/or GPU power envelope. So fix up the divisions to save the results so the numbers are actually correct (contrary to some earlier comments and code, these functions do not modify the first argument and use it for the result). Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
- 26 Sep, 2010 3 commits
-
-
Chris Wilson authored
Introduced by 48b956c5, I had thought I had already fixed this. Oh well. Reported-by:
Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by:
-
Chris Wilson authored
There is no equivalent to mutex_destroy() for spinlocks so just delete the code. Signed-off-by: -
Chris Wilson authored
Daniel Vetter pointed out that in this case is would be clearer and cleaner to use a spinlock instead of a mutex to protect the per-file request list manipulation. Make it so. Signed-off-by:
-
- 25 Sep, 2010 7 commits
-
-
Daniel Vetter authored
It's the same code, essentially, so kill all copies safe one unified version. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
All functions are extremely similar, so fold them into one generic implementation. This function isn't used anyway, because there's not yet a bsd ring error state dumper. Signed-off-by:
-
Daniel Vetter authored
Two macros that use a base address for HWS_PGA were missing, add them. Also switch the remaining users of *_ACTHD to the ring-base one. Kill the other ring-specific macros because they're now unused. Signed-off-by:
-
Daniel Vetter authored
This was mixed up in the following patch: commit a6c45cf0 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Sep 17 00:32:17 2010 +0100 drm/i915: INTEL_INFO->gen supercedes i8xx, i9xx, i965g Signed-off-by:
-
Daniel Vetter authored
Everything is now handled in intel-gtt.h so these defines are only confusing. Signed-off-by:
-
Chris Wilson authored
... and combine it with the wedged completion handler. Signed-off-by: -
Chris Wilson authored
Owain Ainsworth reported an issue between the interaction of the hangcheck and userspace immediately (and permanently) falling back to s/w rasterisation. In order to break the mutex and begin resetting the GPU, we must abort the current operation (usually within the wait) and climb sufficiently far back up the call chain to drop the mutex. In his implementation, Owain has a loop within the ioctl handler to detect the hang and then sleep until the error handler has run. I've chosen to return to userspace and report an EAGAIN which should trigger the userspace ioctl handler to repeat the call (simply because it felt less invasive...). Before hitting a wedged GPU, we then wait upon completion of the error handler. Reported-by:
Owain G. Ainsworth <zerooa@googlemail.com> Signed-off-by:
-
- 24 Sep, 2010 10 commits
-
-
Chris Wilson authored
Avoid cause latencies in other clients by not taking the global struct mutex and moving the per-client request manipulation a local per-client mutex. For example, this allows a compositor to schedule a page-flip (through X) whilst an OpenGL application is monopolising the GPU. Signed-off-by: -
Hette Visser authored
This patch fixes the black screen bug on Dell e6510, by adding two delays to give the eDP panel time to turn on before we continue with the next write. 300ms is rather arbitray and a rather long sleep, we need to find a way of refining this value. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29278Signed-off-by:
-
Jan Beulich authored
In commit e517a5e9 the call to map_page_into_agp() got removed from intel_i830_setup_flush(), but the counterpart call from intel_i830_fini_flush() to unmap_page_from_agp() was left in place. Additionally, the page allocated here never gets its physical address used for sending to hardware, so there's no need to allocate it with GFP_DMA32. Nor is __GFP_ZERO really necessary, as the page is used only to store data to force flushing of some internal processor state. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Cc: Eric Anholt <eric@anholt.net> Signed-off-by:
-
Chris Wilson authored
First step, lets have a look at the values for troublesome panels and see if they may be used to improve our link training. Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
We need to drain the pending flips prior to disabling the pipe during modeset, and these need to be done in an uninterruptible fashion. Signed-off-by: -
Chris Wilson authored
This is now private to the DVO connector, remove it from the main device private. Signed-off-by: -
Chris Wilson authored
As we presume space is signed when computing and looking for wrap along, make it so. Reported-by:
-
Chris Wilson authored
These have served their purpose and are now just noise in the debug stream. Signed-off-by: -
Chris Wilson authored
Try to validate the panel's connection by writing to address 0xA0. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18072Signed-off-by:
-
- 23 Sep, 2010 5 commits
-
-
Chris Wilson authored
In the event that the external chipset doesn't implement the GET_SUPPORTED_ENHANCEMENTS commands, gracefully treat it as having no enhancments rather than bailing. Reported-and-tested-by:
Woody Suwalski <terraluna977@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18342Signed-off-by:
-
Chris Wilson authored
We weren't unlinking the freed connector from the drm lists, and so hit some use-after-free if we failed to initialise the connector. Reported-and-tested-by:
-
Chris Wilson authored
We need to wait for the PLLs to settle prior to detecting the state changes. The BIOS writers guide suggests waiting for the next vblank. Reported-by:
Carlos R. Mafra <crmafra2@gmail.com> Signed-off-by:
-
Chris Wilson authored
This is already performed with the pipelined flush, so by the time we schedule the flush in the page-flip, the ring is NULL and we OOPs instead. Reported-by:
-
Chris Wilson authored
A minor typo caused a single fence register to be incorrectly programmed, resulting in occassional tiling corruption. Reported-and-tested-by:
Hans de Bruin <bruinjm@xs4all.nl> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18962Signed-off-by:
-
- 22 Sep, 2010 4 commits
-
-
Chris Wilson authored
The BIOS writer's guide suggests that a VGA connection will ACK a write to address 0xA0 and that this should be used before doing legacy load-detection. Considering the extreme cost of load-detection, performing an extra DDC seems a risk worth taking. Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
We are not currently using it as intended, so remove the complication. Signed-off-by: -
Chris Wilson authored
Previously when converting the GMBUS pin to the GPIO reg, we would offset the pin by one and then use the look-up table. Now that we first try to use the GMBUS pin, we no longer need the offset and can use the value from the VBIOS directly. Reported-by:
-
