aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915/bios: Avoid temporary allocation whilst searching for downclockChris Wilson2011-07-131-59/+83
| | | | | | | | | | | | | | | Alan Cox reported a missing check on the kmalloc return value for the allocation of a temporary mode used for searching for the LVDS downlock frequency. This allocation is roughly 200 bytes, a little too large to friviously place on the stack. However, we can simply use the few bytes we need stored within the original DVO timing data, skip the translation and do the compare directly between the timing data rather than on a mode, thus avoiding the need for any temporary allocations. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Cache GT fifo count for SandyBridgeChris Wilson2011-07-133-5/+12
| | | | | | | | | | | The read back of the available FIFO entries is vital for system stability, but extremely costly. However, we only need a guide so as to avoid eating into the reserved entries and since we are the only consumer we can cache the read of the count from the last write. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
* i915: Fix opregion notificationsMatthew Garrett2011-07-131-4/+11
| | | | | | | | | | | | | opregion-based platforms will send ACPI video event 0x80 for a range of notification types for legacy compatibility. This is interpreted as a display switch event, which may not be appropriate in the circumstances. When we receive such an event we should make sure that the platform is genuinely requesting a display switch before passing that event through to userspace. Signed-off-by: Matthew Garrett <mjg@redhat.com> Tested-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: TVDAC_STATE_CHG does not indicate successful load-detectKeith Packard2011-07-131-20/+20
| | | | | | | | | Do not use this bit to indicate that load detection has completed, instead just wait for vblank, at which point the load registers will have been updated. Signed-off-by: Keith Packard <keithp@keithp.com> Tested-by: Yi Sun <yi.sun@intel.com>
* drm/i915: Select correct pipe during TV detectKeith Packard2011-07-131-0/+6
| | | | | Signed-off-by: Keith Packard <keithp@keithp.com> Tested-by: Yi Sun <yi.sun@intel.com>
* Merge branch 'drm-intel-fixes' into drm-intel-nextKeith Packard2011-07-123-5/+13
|\
| * drm/i915/ringbuffer: Idling requires waiting for the ring to be emptyChris Wilson2011-07-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...which is measured by the size and not the amount of space remaining. Waiting upon size-8, did one of two things. In the common case with more than 8 bytes available to write into the ring, it would return immediately. Otherwise, it would timeout given the impossible condition of waiting for more space than is available in the ring, leading to warnings such as: [drm:intel_cleanup_ring_buffer] *ERROR* failed to quiesce render ring whilst cleaning up: -16 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Keith Packard <keithp@keithp.com>
| * Revert "drm/i915: enable rc6 by default"Keith Packard2011-07-121-1/+1
| | | | | | | | | | | | | | | | | | This reverts commit a51f7a66fb5e4af5ec4286baef940d06594b59d2. We still have a few Ironlake and Sandybridge machines which fail when RC6 is enabled. Better luck next release? Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: Clean up i915_driver_load failure pathKeith Packard2011-07-121-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i915_driver_load adds a write-combining MTRR region for the GTT aperture to improve memory speeds through the aperture. If i915_driver_load fails after this, it would not have cleaned up the MTRR. This shouldn't cause any problems, except for consuming an MTRR register. Still, it's best to clean up completely in the failure path, which is easily done by calling mtrr_del if the mtrr was successfully allocated. i915_driver_load calls i915_gem_load which register i915_gem_inactive_shrink. If i915_driver_load fails after calling i915_gem_load, the shrinker will be left registered. When called, it will access freed memory and crash. The fix is to unregister the shrinker in the failure path using code duplicated from i915_driver_unload. i915_driver_load also has some incorrect gotos in the error cleanup paths: * After failing to initialize the GTT (which cannot happen, btw, intel_gtt_get returns a fixed (non-NULL) value), it tries to free the uninitialized WC IO mapping. Fixed this by changing the target from out_iomapfree to out_rmmap Signed-off-by: Keith Packard <keithp@keithp.com> Tested-by: Lin Ming <ming.m.lin@intel.com>
* | drm/i915: Enable i915 frame buffer compression by defaultKeith Packard2011-07-081-1/+1
| | | | | | | | | | | | | | We'll try again with the new fixes. Prepare to see this reverted when we get regression reports... Signed-off-by: Keith Packard <keithp@keithp.com>
* | drm/i915: Share the common work of disabling active FBC before updatingChris Wilson2011-07-082-60/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Upon review, all path share the same dependencies for updating the registers and so we can benefit from sharing the code and checking early. This removes the unsightly intel_wait_for_vblank() from the lowlevel functions and upon further analysis the only path that will require a wait is if we are performing an instantaneous transition between two valid FBC configurations. The page-flip path itself will have disabled FBC registers and will have waited for at least one vblank before finishing the flip and attempting to re-enable FBC. This wait can be accomplished simply by delaying the enable until after we are sure that a vblank will have passed, which we are already doing to make sure that the display is settled before enabling FBC. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* | drm/i915: Perform intel_enable_fbc() from a delayed taskChris Wilson2011-07-083-2/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | In order to accommodate the requirements of re-enabling FBC after page-flipping, but to avoid doing so and incurring the cost of a wait for vblank in the middle of a page-flip sequence, we defer the actual enablement by 50ms. If any request to disable FBC arrive within that interval, the enablement is cancelled and we are saved from blocking on the wait. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* | drm/i915: Disable FBC across page-flippingChris Wilson2011-07-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Page-flipping updates the scanout address, nukes the FBC compressed image and so forces an FBC update so that the displayed image remains consistent. However, page-flipping does not update the FBC registers themselves, which remain pointing to both the old address and the old CPU fence. Future updates to the new front-buffer (scanout) are then undetected! This first approach to demonstrate the issue and highlight the fix, simply disables FBC upon page-flip (a recompression will be forced on every flip so FBC becomes immaterial) and then re-enables FBC in the page-flip finish work function, so that the FBC registers are now pointing to the new framebuffer and front-buffer rendering works once more. Ideally, we want to only re-enable FBC after page-flipping is complete, as otherwise we are just wasting cycles and power (with needless recompression) whilst the page-flipping application is still running. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33487 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* | drm/i915: Set persistent-mode for ILK/SNB framebuffer compressionChris Wilson2011-07-082-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Persistent mode is intended for use with front-buffer rendering, such as X, where it is necessary to detect writes to the scanout either by the GPU or through the CPU's fence, and recompress the dirty regions on the fly. (By comparison to the back-buffer rendering, the scanout is always recompressed after a page-flip.) References: https://bugs.freedesktop.org/show_bug.cgi?id=33487 References: https://bugs.freedesktop.org/show_bug.cgi?id=31742 Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* | drm/i915: Use of a CPU fence is mandatory to update FBC regions upon CPU writesChris Wilson2011-07-081-19/+14
| | | | | | | | | | | | | | | | | | ...and this requirement is enforced by intel_update_fbc() so we can remove the later check from g4x_enable_fbc() and ironlake_enable_fbc(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* | drm/i915: Remove vestigial pitch from post-gen2 FBC control routinesChris Wilson2011-07-081-6/+2
| | | | | | | | | | | | | | | | | | | | The cfb_pitch was only used for 8xx_enable_fbc(), every later routine was just overwriting the value with itself thanks to a copy'n'paste error. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* | drm/i915: Replace direct calls to vfunc.disable_fbc with intel_disable_fbc()Chris Wilson2011-07-081-8/+5
| | | | | | | | | | | | | | ...to ensure that any pending FBC enable tasklet is cancelled. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* | drm/i915: Only export the generic intel_disable_fbc() interfaceChris Wilson2011-07-084-34/+30
| | | | | | | | | | | | | | | | | | | | | | As the enable/disable routines will be gain additional complexity in future patches, it is necessary that all callers do not bypass the generic interface by calling into the chipset routines directly. to do this we make the chipset routines static, so there is no choice. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* | Merge branch 'drm-intel-fixes' into drm-intel-nextKeith Packard2011-07-071-0/+1
|\ \ | |/
| * drm/i915: Enable GPU reset on Ivybridge.Kenneth Graunke2011-07-071-0/+1
| | | | | | | | | | | | | | | | According to the hardware documentation, GDRST is exactly the same as on Sandybridge. So simply enable the existing code. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* | Merge branch 'drm-intel-fixes' into drm-intel-nextKeith Packard2011-07-076-32/+103
|\ \ | |/
| * drm/i915/dp: manage sink power state if possibleJesse Barnes2011-07-071-0/+35
| | | | | | | | | | | | | | | | | | | | On sinks with a DPCD rev of 1.1 or greater, we can send sink power management commands to address 0x600 per section 5.1.5 of the DisplayPort 1.1a spec. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915/dp: consolidate AUX retry codeJesse Barnes2011-07-071-21/+30
| | | | | | | | | | | | | | | | | | | | | | When checking link status during a hot plug event or detecting sink presence, we need to retry 3 times per the spec (section 9.1 of the 1.1a DisplayPort spec). Consolidate the retry code into a native_aux_read_retry function for use by get_link_status and _detect. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915/dp: remove DPMS mode tracking from DPJesse Barnes2011-07-071-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | We currently use this when a hot plug event is received, only checking the link status and re-training if we had previously configured a link. However if we want to preserve the DP configuration across both hot plug and DPMS events (which we do for userspace apps that don't respond to hot plug uevents), we need to unconditionally check the link and try to bring it up on hot plug. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915/dp: try to read receiver capabilities 3 times when detectingJesse Barnes2011-07-071-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | If ->detect is called too soon after a hot plug event, the sink may not be ready yet. So try up to 3 times with 1ms sleeps in between tries to get the data (spec dictates that receivers must be ready to respond within 1ms and that sources should try 3 times). See section 9.1 of the 1.1a DisplayPort spec. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915/dp: read more receiver capability bits on hotplugJesse Barnes2011-07-071-0/+11
| | | | | | | | | | | | | | | | | | When a hotplug event is received, we need to check the receiver cap bits in case they've changed (as they might with a hub or chain config). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915/dp: use DP DPCD defines when looking at DPCD valuesJesse Barnes2011-07-071-8/+10
| | | | | | | | | | | | | | | | Makes it easier to search for DP related constants. Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915/dp: retry link status read 3 times on failureJesse Barnes2011-07-071-7/+13
| | | | | | | | | | | | | | | | | | | | | | | | Especially after a hotplug or power status change, the sink may not reply immediately to a link status query. So retry 3 times per the spec to really make sure nothing is there. See section 9.1 of the 1.1a DisplayPort spec. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * Merge branch 'drm-fixes' of ↵Linus Torvalds2011-07-023-4/+5
| |\ | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 * 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: Revert "drm/nvc0: recognise 0xdX chipsets as NV_C0" drm/radeon/kms: fix typo in cayman reg offset drm/radeon/kms: use correct reg on fusion when reading back mem config
| | * Revert "drm/nvc0: recognise 0xdX chipsets as NV_C0"Ben Skeggs2011-07-021-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | Oh boy. That was a bad gamble. PDISP has changed. This reverts commit cdf81a235f11c8a55023c6b181d21d519a8a5967. Signed-off-by: Dave Airlie <airlied@redhat.com>
| | * drm/radeon/kms: fix typo in cayman reg offsetAlex Deucher2011-07-021-1/+1
| | | | | | | | | | | | | | | Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| | * drm/radeon/kms: use correct reg on fusion when reading back mem configAlex Deucher2011-07-021-1/+4
| | | | | | | | | | | | | | | Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | Merge branch 'drm-intel-fixes' of ↵Linus Torvalds2011-07-017-109/+94
| |\ \ | | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6 * 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6: drm/i915: apply HWSTAM writes to Ivy Bridge as well drm/i915: move IRQ function table init to i915_irq.c drm/i915/overlay: Fix unpinning along init error paths drm/i915: Don't call describe_obj on NULL pointers drm/i915: Hold struct_mutex during i915_save_state/i915_restore_state
| * | drm/radeon/kms: Fix chremap setup on RV770 CEAlex Deucher2011-07-011-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CE variant requires a different chremap setup. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=35472 Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon/kms: increase rom size for atrm methodAlex Deucher2011-06-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The vbios rom is >64k on a lot of modern asics. Increase the fetch size for atrm to make sure we don't miss part of a larger rom. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/i915: use pipe bpp in DP link bandwidth calculationJesse Barnes2011-07-071-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we track bpp on a per-pipe basis, we can use the actual value rather than assuming 24bpp. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* | | drm/i915: check for supported depth at fb init timeJesse Barnes2011-07-071-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | This will catch bad fb configs earlier. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* | | drm: bpp and depth changes require full mode setsJesse Barnes2011-07-071-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To properly drive a framebuffer with a new depth or bpp, dither settings and link bandwidth calculations may change, so make sure we go through a full mode set in that case. Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* | | drm/i915: use pipe bpp when setting HDMI bpcJesse Barnes2011-07-071-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | The Intel HDMI encoder can support 8bpc or 12bpc. Set the appropriate value based on the pipe bpp when configuring the output. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* | | drm/i915: use pipe bpp in DP link bandwidth calculationsJesse Barnes2011-07-071-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pipe may be driving various bpp values depending on the display configuration, so take that into account when calculating link bandwidth requirements. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* | | drm/i915: split out plane update codeJesse Barnes2011-07-072-9/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Updating the planes is device specific, so create a new display callback and use it in pipe_set_base. (In fact we could go even further, valid display plane bits have changed with each generation, as has tiled buffer handling.) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* | | drm/i915: split out Ironlake pipe bpp picking codeJesse Barnes2011-07-072-42/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Figuring out which pipe bpp to use is a bit painful. It depends on both the encoder and display configuration attached to a pipe. For instance, to drive a 24bpp framebuffer out to an 18bpp panel, we need to use 6bpc on the pipe but also enable dithering. But driving that same framebuffer to a DisplayPort output on another pipe means using 8bpc and no dithering. So split out and enhance the code to handle the various cases, returning an appropriate pipe bpp as well as whether dithering should be enabled. Save the resulting pipe bpp in the intel_crtc struct for use by encoders in calculating bandwidth requirements (defaults to 24bpp on pre-ILK). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* | | drm/i915: set bpc for DP transcoderJesse Barnes2011-07-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This may not be the default value, so pull the bpc out of the pipe reg and write it to the DP transcoder so proper dithering and signaling occurs. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* | | drm/i915: don't set transcoder bpc on CougarPointJesse Barnes2011-07-071-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | This prevents us from setting reserved or incorrect bits on CougarPoint. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* | | drm/i915: don't set SDVO color range on ILK+Jesse Barnes2011-07-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | These bits are reserved on ILK+ (ILK+ provides this feature in the transcoder and pipe configuration instead, which we already set). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* | | Merge branch 'drm-intel-fixes' into drm-intel-nextKeith Packard2011-07-011-1/+1
|\ \ \ | | |/ | |/|
| * | drm/i915: apply HWSTAM writes to Ivy Bridge as wellJesse Barnes2011-07-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | In an attempt to fix 38862 and 38863. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* | | Merge branch 'drm-intel-fixes' into drm-intel-nextKeith Packard2011-06-295-94/+70
|\ \ \ | |/ /
| * | drm/i915: move IRQ function table init to i915_irq.cJesse Barnes2011-06-294-87/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This lets us make the various IRQ functions static and helps avoid problems like the one fixed in "drm/i915: Use chipset-specific irq installers" where one of the exported functions was called rather than the chipset specific version. This also fixes a UMS-mode bug -- the correct irq functions for IRL and later chips were only getting loaded in the KMS path. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
| * | drm/i915/overlay: Fix unpinning along init error pathsChris Wilson2011-06-291-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As pointed out by Dan Carpenter, it was seemingly possible to hit an error whilst mapping the buffer for the regs (except the only likely error returns should not happen during init) and so leak a pin count on the bo. To handle this we would need to reacquire the struct mutex, so for simplicity rearrange for the lock to be held for the entire function. For extra pedagogy, test that we only call init once. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
generated by cgit v1.1 at 2025-02-09 01:36:33 +0000