- 23 11月, 2010 8 次提交
-
-
由 Alex Deucher 提交于
System specific spread spectrum overrides can be specified in the integrated system info table for Fusion APUs. This adds support for using those overrides. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Should improve performance slightly and possibly fix some issues. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 22 11月, 2010 1 次提交
-
-
由 Mario Kleiner 提交于
The DRI2 swap & sync implementation needs precise vblank counts and precise timestamps corresponding to those vblank counts. For conformance to the OpenML OML_sync_control extension specification the DRM timestamp associated with a vblank count should correspond to the start of video scanout of the first scanline of the video frame following the vblank interval for that vblank count. Therefore we need to carry around precise timestamps for vblanks. Currently the DRM and KMS drivers generate timestamps ad-hoc via do_gettimeofday() in some places. The resulting timestamps are sometimes not very precise due to interrupt handling delays, they don't conform to OML_sync_control and some are wrong, as they aren't taken synchronized to the vblank. This patch implements support inside the drm core for precise and robust timestamping. It consists of the following interrelated pieces. 1. Vblank timestamp caching: A per-crtc ringbuffer stores the most recent vblank timestamps corresponding to vblank counts. The ringbuffer can be read out lock-free via the accessor function: struct timeval timestamp; vblankcount = drm_vblank_count_and_time(dev, crtcid, ×tamp). The function returns the current vblank count and the corresponding timestamp for start of video scanout following the vblank interval. It can be used anywhere between enclosing drm_vblank_get(dev, crtcid) and drm_vblank_put(dev,crtcid) statements. It is used inside the drmWaitVblank ioctl and in the vblank event queueing and handling. It should be used by kms drivers for timestamping of bufferswap completion. The timestamp ringbuffer is reinitialized each time vblank irq's get reenabled in drm_vblank_get()/ drm_update_vblank_count(). It is invalidated when vblank irq's get disabled. The ringbuffer is updated inside drm_handle_vblank() at each vblank irq. 2. Calculation of precise vblank timestamps: drm_get_last_vbltimestamp() is used to compute the timestamp for the end of the most recent vblank (if inside active scanout), or the expected end of the current vblank interval (if called inside a vblank interval). The function calls into a new optional kms driver entry point dev->driver->get_vblank_timestamp() which is supposed to provide the precise timestamp. If a kms driver doesn't implement the entry point or if the call fails, a simple do_gettimeofday() timestamp is returned as crude approximation of the true vblank time. A new drm module parameter drm.timestamp_precision_usec allows to disable high precision timestamps (if set to zero) or to specify the maximum acceptable error in the timestamps in microseconds. Kms drivers could implement their get_vblank_timestamp() function in a gpu specific way, as long as returned timestamps conform to OML_sync_control, e.g., by use of gpu specific hardware timestamps. Optionally, kms drivers can simply wrap and use the new utility function drm_calc_vbltimestamp_from_scanoutpos(). This function calls a new optional kms driver function dev->driver->get_scanout_position() which returns the current horizontal and vertical video scanout position of the crtc. The scanout position together with the drm_display_timing of the current video mode is used to calculate elapsed time relative to start of active scanout for the current video frame. This elapsed time is subtracted from the current do_gettimeofday() time to get the timestamp corresponding to start of video scanout. Currently non-interlaced, non-doublescan video modes, with or without panel scaling are handled correctly. Interlaced/ doublescan modes are tbd in a future patch. 3. Filtering of redundant vblank irq's and removal of some race-conditions in the vblank irq enable/disable path: Some gpu's (e.g., Radeon R500/R600) send spurious vblank irq's outside the vblank if vblank irq's get reenabled. These get detected by use of the vblank timestamps and filtered out to avoid miscounting of vblanks. Some race-conditions between the vblank irq enable/disable functions, the vblank irq handler and the gpu itself (updating its hardware vblank counter in the "wrong" moment) are fixed inside vblank_disable_and_save() and drm_update_vblank_count() by use of the vblank timestamps and a new spinlock dev->vblank_time_lock. The time until vblank irq disable is now configurable via a new drm module parameter drm.vblankoffdelay to allow experimentation with timeouts that are much shorter than the current 5 seconds and should allow longer vblank off periods for better power savings. Followup patches will use these new functions to implement precise timestamping for the intel and radeon kms drivers. Signed-off-by: NMario Kleiner <mario.kleiner@tuebingen.mpg.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 19 11月, 2010 6 次提交
-
-
由 Alex Shi 提交于
Frame buffer compression is broken on Ironlake due to buggy hardware. Currently it is disabled through chicken bits, but it still consumes over 1W more than if we simply never attempt to enable the FBC code paths. Signed-off-by: NAlex Shi <alex.shi@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org
-
由 Keith Packard 提交于
Both IBX and CPT have an automatic hotplug detection mode which appears to work reliably enough that we can dispense with the manual force hotplug trigger stuff. This means that hotplug detection is as simple as reading the current hotplug register values. The first time the hotplug detection is activated, the code synchronously waits for a hotplug sequence in case the hardware hasn't bothered to do a detection cycle since being initialized. Signed-off-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Chris Wilson 提交于
We will use this structure in future patches to store CRT specific information on the encoder. Split out and tweaked from a patch by Keith Packard. Signed-off-by: NKeith Packard <keithp@kithp.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Chris Wilson 提交于
Linus Torvalds found that it was rather trivial to trigger a system freeze: In fact, with lockdep, I don't even need to do the sysrq-d thing: it shows the bug as it happens. It's the X server taking the same lock recursively. Here's the problem: ============================================= [ INFO: possible recursive locking detected ] 2.6.37-rc2-00012-gbdbd01ac #7 --------------------------------------------- Xorg/2816 is trying to acquire lock: (&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c626c>] i915_gem_fault+0x50/0x17e but task is already holding lock: (&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c403b>] i915_mutex_lock_interruptible+0x28/0x4a other info that might help us debug this: 2 locks held by Xorg/2816: #0: (&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c403b>] i915_mutex_lock_interruptible+0x28/0x4a #1: (&mm->mmap_sem){++++++}, at: [<ffffffff81022d4f>] page_fault+0x156/0x37b This recursion was introduced by rearranging the locking to avoid the double locking on the fast path (4f27b5d and fbd5a26d) and the introduction of the prefault to encourage the fast paths (b5e4f2b). In order to undo the problem, we rearrange the code to perform the access validation upfront, attempt to prefault and then fight for control of the mutex. the best case scenario where the mutex is uncontended the prefaulting is not wasted. Reported-and-tested-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Alex Deucher 提交于
As per advice from Jean Delvare. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Acked-by: NJean Delvare <khali@linux-fr.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
These got lost in the last i2c cleanup. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=23222Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Cc: stable@kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 18 11月, 2010 25 次提交
-
-
由 Thomas Hellstrom 提交于
A process suspended waiting for a higher sequence or no sequence to unreserve, a bo may be beaten to the reservation by a process with a lower sequence. In that case the first process should give up trying to reserve and return -EAGAIN. In order for that to happen, we must wake waiting processes when we change sequence, so that they have a chance to detect the new sequence. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
We aren't currently using tiling in userspace on evergreen, but the info we currently return for the tiling info query (gb_addr_config) is no adequate for userspace tiling alignment calculations. It does not contain the bank info. Create a custom tiling info dword with all the necessary info (num channels, num banks, group size, row size). Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
We were previously dropping alignment requests on the floor when allocating buffers so we always ended up page aligned. Certain tiling modes on 6xx+ require larger alignment which wasn't happening before. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Cc: Jerome Glisse <j.glisse@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Thomas Hellstrom 提交于
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
This causes the connector to not be added since i2c init fails for the adapter. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=31688 Noticed by Ari Savolainen. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Cc: Ari Savolainen <ari.m.savolainen@gmail.com> Cc: Jean Delvare <khali@linux-fr.org> Cc: stable@kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
These are external encoder chips connected via DVO or DP. The actual external encoder programming is handled by the kms encoder functions for primary encoder. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Handle all the various asic family specific things for DVO. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
The eDP panel must be powered up for aux transactions, so power it up for detect and mode probe functions, otherwise power it up or down based on dpms. v2: - only mess with eDP panel on DCE4+ - only mess with eDP panel on eDP connectors, not all DP connectors v3: - be extra careful to only mess with eDP panels on eDP connectors v4: - avoid possible null derefernce if a connector has not been assigned to the encoder Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
If there was no connector mapped to the encoder, atombios_get_encoder_mode() returned 0 which is the id for DP. Return something sane instead based on the encoder id. This avoids hitting the DP paths on non-DP encoders. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Cc: stable@kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Seems some newer systems require this explicitly. Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Looks like a typo in: drm/radeon/r600: fix tiling issues in CS checker. (f30df2fa) Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Vasiliy Kulikov 提交于
enable_vblank implementations should use negative result to indicate error. radeon_enable_vblank() returns EINVAL in this case. Change this to -EINVAL. Signed-off-by: NVasiliy Kulikov <segoon@openwall.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
Tiled buffers have the same alignment requirements regardless of whether the surface is for db, cb, or textures. Previously, the calculations where inconsistent for each buffer type. - Unify the alignment calculations in a common function - Standardize the alignment units (pixels for pitch/height/depth, bytes for base) - properly check the buffer base alignments Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Andy Lutomirski 提交于
The old code generated an interrupt storm bad enough to completely take down my system. Signed-off-by: NAndy Lutomirski <luto@mit.edu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Avoid confusing userspace by not publishing backlight controls if ACPI equivalents are available. Reported-by: NAaron Sowry <aaron@aeneby.se> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Roy Spliet 提交于
Improvements: - Fix bug in switch statement - Add parts of 0x10022c, 0x10023c - Clean up 0x100234 - Comment out assumption in 0x100228 until verified Signed-off-by: NRoy Spliet <r.spliet@student.tudelft.nl> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
Reported-by: NTomas Miljenovic <tomasmiljenovic@gmail.com> Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
Reported-by: NTomas Miljenovic <tomasmiljenovic@gmail.com> Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Martin Peres 提交于
Signed-off-by: NMartin Peres <martin.peres@ensi-bourges.fr> Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
Analog output polling makes GL programs jerky when pageflip is being used because it's carried out with the mode_config mutex held. Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
Reported-by: NXavier Chantry <chantry.xavier@gmail.com> Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Francisco Jerez 提交于
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-