- 26 Oct, 2010 5 commits
-
-
Lee, Chun-Yi authored
Currently, there have no GMA500(Poulsbo) native video driver to support intel opregion. So, use this stub driver to enable the acpi backlight control sysfs entry files by requrest acpi_video_register. [airlied: fix warnings] Signed-off-by: Lee, Chun-Yi <jlee@novell.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Alex Deucher authored
The vram map in the radeon memory controller needs to be >= the pci aperture size. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=28402 The problematic cards in the above bug have 64 MB of vram, but the pci aperture is 128 MB and the MC vram map was only 64 MB. This can lead to hangs. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Alex Deucher authored
Improper display watermarks can result in underflow to the display controllers which can cause flickering or other artifacts. This patch implements display watermark support and line buffer allocation for evergreen asics. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Alex Deucher authored
These are needed for enabling dynamic GPR allocation in the shaders in the userspace acceleration drivers. v2: fix typo in reg name Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
The CS checker had some incorrect alignment requirements for 2D surfaces, this made rendering to mipmap levels that were 2D broken. Also the CB height was being worked out from the BO size, this doesn't work at all when rendering mipmap levels, instead we work out what height userspace wanted from slice max and use that to check it fits inside the BO, however the DDX send the wrong slice max for an unaligned buffer so we have to workaround for that even though its a userspace bug. Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
- 25 Oct, 2010 1 commit
-
-
Dave Airlie authored
* 'intel/drm-intel-next' of ../drm-next: (63 commits) drm/i915: Move gpu_write_list to per-ring drm/i915: Invalidate the to-ring, flush the old-ring when updating domains drm/i915/ringbuffer: Write the value passed in to the tail register agp/intel: Restore valid PTE bit for Sandybridge after bdd30729 drm/i915: Fix flushing regression from 9af90d19 drm/i915/sdvo: Remove unused encoding member i915: enable AVI infoframe for intel_hdmi.c [v4] drm/i915: Fix current fb blocking for page flip drm/i915: IS_IRONLAKE is synonymous with gen == 5 drm/i915: Enable SandyBridge blitter ring drm/i915/ringbuffer: Remove broken intel_fill_struct() drm/i915/ringbuffer: Fix emit batch buffer regression from 8187a2b7 drm/i915: Copy the updated reloc->presumed_offset back to the user drm/i915: Track objects in global active list (as well as per-ring) drm/i915: Simplify most HAS_BSD() checks drm/i915: cache the last object lookup during pin_and_relocate() drm/i915: Do interrupible mutex lock first to avoid locking for unreference drivers: gpu: drm: i915: Fix a typo. agp/intel: Also add B43.1 to list of supported devices drm/i915: rearrange mutex acquisition for pread ...
-
- 24 Oct, 2010 1 commit
-
-
Chris Wilson authored
... to prevent flush processing of an idle (or even absent) ring. This fixes a regression during suspend from 87acb0a5. Reported-and-tested-by: Alexey Fisher <bug-track@fisher-privat.net> Tested-by: Peter Clifton <pcjc2@cam.ac.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- 23 Oct, 2010 1 commit
-
-
Chris Wilson authored
When the object has been written to by the gpu it remains on the ring until its flush has been retired. However, when the object is moving to the ring and the associated cache needs to be invalidated, we need to perform the flush on the target ring, not the one it came from (which is NULL in the reported case and so the flush was entirely absent). Reported-by: Peter Clifton <pcjc2@cam.ac.uk> Reported-and-tested-by: Alexey Fisher <bug-track@fisher-privat.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- 22 Oct, 2010 5 commits
-
-
Chris Wilson authored
This should fix the error along the reset path were we tried to clear the tail register by setting it to 0, but were in fact setting it to the current value and complaining when it did not reset to 0. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
In cleaning up the mask functions in bdd30729, the setting of the PTE valid bit was dropped for Sandybridge. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Whilst moving the code around in 9af90d19, I dropped the or'ing in of new write domains which would zero out the write domain for a render target if later reused as a source later in the batch. This meant that we might drop a required flush before reading from the render target. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31043 Reported-by: xunx.fang@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
This block is only used when detecting whether the connector is HDMI and never again, so scope the variable to the detection routine. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
David Härdeman authored
This patch enables the sending of AVI infoframes in drivers/gpu/drm/i915/intel_hdmi.c. My receiver currently loses sync when the HDMI output on my computer (DG45FC motherboard) is switched from 800x600 (the BIOS resolution) to 1920x1080 as part of the boot. Fixable by switching inputs on the receiver a couple of times. With this patch, my receiver has not lost sync yet (> 40 tries). Fourth version, now based on drm-intel-next from: git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git Two questions still remain: I'm assuming that the sdvo hardware also stores a header ECC byte in the MSB of the first dword - is this correct? Does the SDVOB and SDVOC handling in intel_hdmi_set_avi_infoframe() look correct? Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- 21 Oct, 2010 7 commits
-
-
Chia-I Wu authored
Block execbuffer for the fb to be flipped away, not the one that is to be flipped in. [ickle: rewritten for -next] Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Kristian Høgsberg <krh@bitplanet.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
So remove the redundant bit in the capabilities block and s/IS_IRONLAKE/IS_GEN5/. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Based on an original patch by Zhenyu Wang, this initializes the BLT ring for SandyBridge and enables support for user execbuffers. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
... before someone tries to use it. The code both calls intel_ring_begin/advance() and open-codes the bookkeeping performed by those two functions. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
In commit 8187a2b7, the number of dwords used in the ringbuffer for executing the batch buffer was erroneously changed from 2 to 4. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Thomas Hellstrom authored
This commit replaces the ttm_bo_cleanup_ref function with two new functions. One for the case where the bo is not yet on the delayed destroy list, and one for the case where the bo was on the delayed destroy list, at least at the time of call. This makes it possible to optimize the two cases somewhat. It also enables the possibility to directly destroy buffers on the delayed delete list when they are about to be evicted or swapped out. Currently they were only evicted / swapped and destruction was left for the delayed buffer destruction thread. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Thomas Hellstrom authored
Release the lru spinlock early. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
- 20 Oct, 2010 4 commits
-
-
Chris Wilson authored
If the userspace driver is using a constant relocation array with a static buffer, they will pass the same relocation array back to the kernel. So we *do* need to update the presumed offset value in those relocations to reflect the current object so that they remain correct with future batchbuffers and we avoid the necessity of having to suspend execution and perform redundant relocations. Fixes the regression introduced by 12f889c for applications using absolute addressing on trees of buffer (i.e. the current consumers of libdrm_intel.so). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30996Reported-by: Wang, Jinjin <jinjin.wang@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
To handle retirements, we need per-ring tracking of active objects. To handle evictions, we need global tracking of active objects. As we enable more rings, rebuilding the global list from the individual per-ring lists quickly grows tiresome and overly complicated. Tracking the active objects in two lists is the lesser of two evils. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
... by always initialising the empty ringbuffer it is always then safe to check whether it is active. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
The most frequent relocation within a batchbuffer is a contiguous sequence of vertex buffer relocations, for which we can virtually eliminate the drm_gem_object_lookup() overhead by caching the last handle to object translation. In doing so we refactor the pin and relocate retry loop out of do_execbuffer into its own helper function and so improve the error paths. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
- 19 Oct, 2010 16 commits
-
-
Chris Wilson authored
One of the primarily consumers of the i915 driver is X, a large signal driven application. Frequently when writing into the buffers, there is a pending signal which causes us not to take the interruptible lock but then we need to take that same lock around the object unreference. By rearranging the code to do the interruptible lock as the first check, we can avoid the frequent additional locking around the unreference. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Andrea Gelmini authored
"userpace" -> "userspace" Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
This was a missing piece from 41a51428 that dropped recognition of the AGP module for the second B43 variant. Reported-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org
-
Chris Wilson authored
... to avoid the double acquisition along fast[er] paths. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
... to avoid reacquiring it to drop the object reference count on exit. Note we have to make sure we now drop (and reacquire) the lock around acquiring the mm semaphore on the slow paths. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
... in the hope that it makes the atomic fast paths more likely. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
After allocation a handle for the fresh object, we know that we can safely drop the refcnt without triggering a free so we do not need the mutex. Strangely, this mutex acquisition is the one that appears on driver profiles. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Avoid an early eviction of the batch buffer into the uncached GTT domain, and so do the relocation fixup in cacheable memory. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
... perform an access validation check up front instead and copy them in on-demand, during i915_gem_object_pin_and_relocate(). As around 20% of the CPU overhead may be spent inside vmalloc for the relocation entries when submitting an execbuffer [for x11perf -aa10text], the savings are considerable and result in around a 10% throughput increase [for glyphs]. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Allow the user to override the detection of the sink's audio capabilities from EDID. Not all sinks support the required EDID level to specify whether they handle audio over the display connection, so allow the user to enable it manually. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Allow the user to override the detection of the sink's audio capabilities from EDID. Not all sinks support the required EDID level to specify whether they handle audio over the display connection, so allow the user to enable it manually. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
Allow the user to override the detection of the sink's audio capabilities from EDID. Not all sinks support the required EDID level to specify whether they handle audio over the display connection, so allow the user to enable it manually. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Zhenyu Wang authored
Rely on monitor's audio capability to turn on audio output for HDMI. Tested-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Zhenyu Wang authored
This will turn on DP audio output by checking monitor's audio capability. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> [ickle: rebase onto recent changes and rearranged for clarity] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Zhenyu Wang authored
To help to determine if digital display port needs to enable audio output or not. This one adds a helper to get monitor's audio capability via EDID CEA extension block. Tested-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Bryan Freed authored
The time between start of the pixel clock and backlight enable is a basic panel timing constraint. If the Panel Power On/Off registers are found to be 0, assume we are booting without VBIOS initialization and set these registers to something reasonable. Change-Id: Ibed6cc10d46bf52fd92e0beb25ae3525b5eef99d Signed-off-by: Bryan Freed <bfreed@chromium.org> [ickle: rearranged into a separate function to distinguish its role from simply parsing the VBIOS tables.] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
-