- 25 Jul, 2012 29 commits
-
-
Daniel Vetter authored
Now that we unconditionally flush and invalidate between every batch buffer, we no longer need the complex logic to decide which domains require flushing. Remove it and rejoice. v2 (danvet): Keep around the flip waiting logic. It's gross and broken, I know, but we can't just kill that thing ... even if we just keep it around as a reminder that things are broken. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
Rely instead on the insertion of the implicit flush before the seqno breadcrumb. Signed-off-by:
-
Chris Wilson authored
As the flush is either performed explictly immediately after the execbuffer dispatch, or before the serialisation of last_fenced_seqno we can forgo the explict i915_gem_flush_ring(). Signed-off-by:
-
Chris Wilson authored
This is now handled by a global flag to ensure we emit a flush before the next serialisation point (if we failed to queue one previously). Signed-off-by:
-
Chris Wilson authored
As we guarantee to emit a flush before emitting the breadcrumb or the next batchbuffer, there is no further need for the flushing list. Signed-off-by:
-
Chris Wilson authored
As we always flush the GPU cache prior to emitting the breadcrumb, we no longer have to worry about the deferred flush causing the pending_gpu_write to be delayed. So we can instead utilize the known last_write_seqno to hopefully minimise the wait times. Signed-off-by:
-
Chris Wilson authored
As we move to lazily clearing the GPU write domain only when the buffer becomes inactive, this leaves a window of opportunity for i915_gem_object_pin_to_display_plane() to detect a seemingly inconsistent value. This function is special as it tries to pipeline the operation to avoid the stall and so may not retires the buffer and we may not get the opportunity to clear the write domain. However, we know all is good, so drop the assertion. Signed-off-by:
-
Chris Wilson authored
Request preallocation was added to i915_add_request() in order to support the overlay. However, not all users care and can quite happily ignore the failure to allocate the request as they will simply repeat the request in the future. By pushing the allocation down into i915_add_request(), we can then remove some rather ugly error handling in the callers. v2: Nullify request->file_priv otherwise we chase a garbage pointer when retiring requests. Signed-off-by:
-
Daniel Vetter authored
With the base addresses shifting around, this is easier to handle. Also move to the real reg offset on vlv. Acked-by:
-
Daniel Vetter authored
Will be used more in the next patch. Signed-off-by: -
Chris Wilson authored
The intention is to help select which engine to use for copies with interoperating clients - such as a GL client making a request to the X server to perform a SwapBuffers, which may require copying from the active GL back buffer to the X front buffer. We choose to report a mask of the active rings to future proof the interface against any changes which may allow for the object to reside upon multiple rings. Signed-off-by:
-
Ben Widawsky authored
The interface's immediate purpose is to do synchronous timestamp queries as required by GL_TIMESTAMP. The GPU has a register for reading the timestamp but because that would normally require root access through libpciaccess, the IOCTL can provide this service instead. Currently the implementation whitelists only the render ring timestamp register, because that is the only thing we need to expose at this time. v2: make size implicit based on the register offset Add a generation check Reviewed-by:
Eric Anholt <eric@anholt.net> Cc: Jacek Lawrynowicz <jacek.lawrynowicz@intel.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> [danvet: fixup the ioctl numerb:] Signed-off-by:
-
Daniel Vetter authored
I'm planing to merge this next week for 3.7, but I'd like to avoid stupid conflicts with the exsting userspace when merging the new reg_read ioctl (which doesn't have userspace yet, but this caching interface has). Header extracted from Chris Wilson's patch, but fix up the copy&pasted comment in the interface struct. Signed-off-by:
-
Thomas Richter authored
This patch adds support for the ns2501 DVO, found in some older Fujitsu/Siemens Labtops. It is in the state of "works for me". Includes now proper DPMS support. Includes switching between resolutions - from 640x480 to 1024x768. Currently assumes that the native display resolution is 1024x768. The ns2501 seems to be rather critical - if the output PLL is not running, the chip doesn't seem to be clocked and then doesn't react on i2c messages. Thus, a quick'n-dirty trick ensures that the DVO is active before submitting any i2c messages to it. This is probably to be reviewed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17902Signed-off-by:
Thomas Richter <thor@math.tu-berlin.de> [danvet: fixup whitespace fail.] Signed-off-by:
-
Paulo Zanoni authored
This will be needed for Haswell, but already has its uses here. This patch started as a small patch written patch by Shobhit Kumar, but it has changed so much that none of its original lines remain. Credits-to: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Paulo Zanoni authored
We have some common code that we always run before calling intel_dp_set_link_train. This common code sets the correct training patterns to the DP variable. If we add more calls to intel_dp_set_link_train, we'll also have to duplicate this common code. So instead of repeating this code whenever we call intel_dp_set_link_train, we move the code to inside the function: now we check which training pattern we're going to set and then we set the DP register according to it. One of the side-effects of this change is that now we never forget to mask the training pattern bits before changing them. It looks like this was working before because we were first masking the bits, then writing 00, 01 and then 11. This patch also enables us to use the intel_dp_set_link_train function when disabling link training: in this case we need to avoid writing the DP_TRAINING_LANE*_SET AUX commands. As a bonus, the big intel_dp_{start,complete}_link_train functions will get smaller and a little bit easier to read. Version 2 changes: - Rewrite commit message. - Also clear the training pattern bits before changing them. Signed-off-by: -
Daniel Vetter authored
Instead of having a giant if cascade to figure this out according to the passed-in register. We could do quite a bit more cleaning up and all by using the port at more places, but I think this should be part of a bigger rework to introduce a struct intel_digital_port which would keep track of all these things. I guess this will be part of some haswell-DP-induced refactoring. For now this rips out the big cascade, which is what annoyed me so much. v2: Add port variable name back for the func decl (I've tried to trick myself below the 80 char limit). Reviewed-by:
-
Daniel Vetter authored
Intel hw only has one MUX for encoders, so outputs are either not cloneable or all in the same group of cloneable outputs. This neatly simplifies the code and allows us to ditch some ugly if cascades in the dp and hdmi init code (well, we need these if cascades for other stuff still, but that can be taken care of in follow-up patches). Note that this changes two things: - dvo can now be cloned with sdvo, but dvo is gen2 whereas sdvo is gen3+, so no problem. Note that the old code had a bug and didn't allow cloning crt with dvo (but only the other way round). - sdvo-lvds can now be cloned with sdvo-non-tv. Spec says this won't work, but the only reason I've found is that you can't use the panel-fitter (used for lvds upscaling) with anything else. But we don't use the panel fitter for sdvo-lvds. Imo this part of Bspec is a) rather confusing b) mostly as a guideline to implementors (i.e. explicitly stating what is already implicit from the spec, without always going into the details of why). So I think we can ignore this - worst case we'll get a bug report from a user with with sdvo-lvds and sdvo-tmds and have to add that special case back in. Because sdvo lvds is a bit special explain in comments why sdvo LVDS outputs can be cloned, but native LVDS and eDP can't be cloned - we use the panel fitter for the later, but not for sdvo. Note that this also uncoditionally initializes the panel_vdd work used by eDP. Trying to be clever doesn't buy us anything (but strange bugs) and this way we can kill the is_edp check. v2: Incorporate review from Paulo - Add in a missing space. - Pimp comment message to address his concerns. Reviewed-by:
-
Daniel Vetter authored
Splitting them up between pch and gmch variants just makes it harder to find things. Especially since the hotplug bits are actually valid on earlier chips, too. v2: Fixed the comment as pointed out by Paulo Zanoni. Reviewed-by:
-
Chris Wilson authored
When bug hunting, I found the interface to do_switch() overly complicated and I believe festered the earlier bug. This aims to make the code a little clearer. Signed-off-by:
-
Shobhit Kumar authored
Move the DP structure to shared location so that it can be used from within the ddi module. Changes from Paulo: - Move less code to intel_drv.h - Remove #include statement - Replace a tab with a space in train_set Signed-off-by:
Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by:
-
Daniel Vetter authored
We now refuse to load on gen6+ if kms is not enabled: commit 26394d92 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Mar 26 21:33:18 2012 +0200 drm/i915: refuse to load on gen6+ without kms Which results in the drm core calling our lastclose function to clean up the mess, but that one is neatly broken for such failure cases since kms has been introduced in commit 79e53945 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Nov 7 14:24:08 2008 -0800 DRM: i915: add mode setting support Reported-and-tested-by:
Paulo Zanoni <przanoni@gmail.com> Signed-Off-by:
-
Eric Anholt authored
Fixes failures in transform feedback on gen7 because our SOL_RESET flag was setting the transform feedback offsets in the old context (occasionally happened to be ours) instead of the new context. Signed-off-by:
-
Daniel Vetter authored
Laurent Pinchart missed this when sending in is giant constify patch: commit e811f5ae Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Date: Tue Jul 17 17:56:50 2012 +0200 drm: Make the .mode_fixup() operations mode argument a const pointer Acked-by; Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-Off-by:
-
Daniel Vetter authored
LVDS is the first output where dpms on/off and prepare/commit don't perfectly match. Now the idea behind this special case seems to be that for simple resolution changes on the LVDS we don't need to stop the pipe, because (at least on newer chips) we can adjust the panel fitter on the fly. There are a few problems with the current code though: - We still stop and restart the pipe unconditionally, because the crtc helper code isn't flexible enough. - We show some ugly flickering, especially when changing crtcs (this the crtc helper would actually take into account, but we don't implement the encoder->get_crtc callback required to make this work properly). So it doesn't even work as advertised. I agree that it would be nice to do resolution changes on LVDS (and also eDP) whithout blacking the screen where the panel fitter allows to do that. But imo we should implement this as a special case a few layers up in the mode set code, akin to how we already detect simple framebuffer changes (and only update the required registers with ->mode_set_base). Until this is all in place, make our lives easier and just rip it out. Also note that this seems to fix actual bugs with enabling the lvds output, see: http://lists.freedesktop.org/archives/intel-gfx/2012-July/018614.html Cc: Takashi Iwai <tiwai@suse.de> Cc: Giacomo Comes <comes@naic.edu> Acked-by:
Takashi Iwai <tiwai@suse.de> Signed-Off-by:
-
Dan Carpenter authored
We need to check that "ctx" is a valid pointer before dereferencing it. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Chris Wilson authored
Otherwise we end up trying to unpin a freed object and BUG. Signed-off-by:
-
Chris Wilson authored
This prevents a WARN introduced with commit de2b9985 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jul 4 22:52:50 2012 +0200 drm/i915: don't return a spurious -EIO from intel_ring_begin Signed-off-by:
-
Chris Wilson authored
The issue is that we stale data in the CPU caches, when we come to swap-out the object, the CPU may short-circuit the reads from those cacheline and so corrupt the context object. Secondary, leaving the context object as being marked in the CPU write domain whilst on the GPU active list is a bad idea and will throw warnings later. Note: Thanks to calling set_to_gtt_domain with write = false and not setting any gpu write domain when putting a context object onto the active list (when we switch away from it) the set_to_gtt_domain call won't block. Signed-off-by:
-
- 20 Jul, 2012 11 commits
-
-
Chris Wilson authored
As we take the struct_mutex lock to access the command-stream, there is a possibility that we may need to wait for a GPU hang and so should make the lock both interruptible and error-checking. References: https://bugs.freedesktop.org/show_bug.cgi?id=50069Signed-off-by:
-
Paulo Zanoni authored
When we enable/disable the CPU backlight registers we can't forget to enable/disable the PCH backlight registers. Since we're using the CPU registers we should also unset the override bit. Fixes a regression on the following commit: drm/i915: properly enable the blc controller on the right pipe The commit just deleted the code that sets the PCH registers, so it was relying on the values set by the BIOS. I told my BIOS to boot on the DVI monitor instead of the LVDS panel, so I noticed the bug. Signed-off-by:
-
Chris Wilson authored
If we drop the breadcrumb request after a batch due to a signal for example we aim to fix it up at the next opportunity. In this case we emit a second batchbuffer with no waits upon the first and so no opportunity to insert the missing request, so we need to emit the missing flush for coherency. (Note that that invalidating the render cache is the same as flushing it, so there should have been no observable corruption.) Note that beside simply adding the missing flush, avoiding potential render corruption, this will also fix at least parts of the problem introduced by some funny interaction of these two commits: commit de2b9985 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jul 4 22:52:50 2012 +0200 drm/i915: don't return a spurious -EIO from intel_ring_begin which allowed intel_ring_begin to return -ERESTARTSYS and commit cc889e0f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jun 13 20:45:19 2012 +0200 drm/i915: disable flushing_list/gpu_write_list which essentially disabled the flushing list. The issue happens when we submit a batch & emit it, but get interrupted (thanks to the first patch) while trying to emit the flush. On the next batch we still assume that the full gpu domain handling is in effect and hence compute the invalidate&flushing domains. But thanks to the 2nd patch we totally ignore these and only invalidate all gpu domains, presuming that any required flushes have been issued already. Which is wrong and eventually results in us updating the new write_domain values with the computed pending_write_domain values, which leaves an object with write_domain == 0 on the gpu_write_list. As soon as we try to unbind that object, things blow up. Fix this by emitting the missing flush according to the new ring->gpu_caches_dirty flag. Note that this does _not_ fix all the current cases where we end up with an object on the flushing_list that can't be flushed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52040Signed-off-by:
-
Ben Widawsky authored
Signed-off-by:
-
Ander Conselvan de Oliveira authored
Or going from tiled to untiled may break. Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
-
Paulo Zanoni authored
While debugging Haswell link train failures I observed that we never try the maximum voltage configuration more than once consecutively. We start the training, the monitor keeps telling us to increase the voltage, then when we reach the maximum we just go back to the start (because of the "memset" above "voltage_tries = 0"). When we reach this point, we keep alternating between the maximum and the minimum voltages until we give up. The DP spec suggests that we should try the same voltage 5 times before giving up. This patch makes us try the maximum voltage at least 5 times before going back to the minimum voltages. This patch does not fix any particular bug I'm aware of. Signed-off-by:
-
Daniel Vetter authored
We have way too much lying hardware to rely on a simple "does someone answer on the ddc i2c address?" check. And now it's unused, so just kill it. Reviewed-by:
-
Daniel Vetter authored
Somehow detect_ddc manages to fall through all checks when we think that something responds on the ddc i2c address, but the edid read failed. Fix this up by explicitly checking for this case. This fixes a regression on newer chips because since commit aaa37730 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Jun 16 15:30:32 2012 +0200 drm/i915/crt: Do not rely upon the HPD presence pin we use ddc detection also on hotplug capable platforms. And one of these reads all 0s for any i2c transaction if nothing is connected to the vga port. v2: Implement Chris Wilson's review: - simplify logic, default to "nothing detected" - kill stale comment - BUG_ON(!crt->type != ANALOG) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51900Tested-by:
Yang Guang <guang.a.yang@intel.com> Reviewed-by:
-
Daniel Vetter authored
I so totally suck. This can cause a black screen if (for whatever reason) the bios hasn't set this bit itself. This regression has been introduced in commit 7cf41601 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jun 5 10:07:09 2012 +0200 drm/i915: clear up backlight #define confusion on gen4+ Tested-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-Off-by:
-
Chris Wilson authored
Having had to dive into the bspec to understand what each stage of the workaround meant, and how that the ring broadcasting IDLE corresponded with the GT powering down the ring (i.e. rc6) add comments to aide the next reader. And since the register "is used to control all aspects of PSMI and power saving functions" that makes it quite interesting to inspect with regards to RC6 hangs, so add it to the error-state. v2: Rediscover the piece of magic, set the RNCID to 0 before waiting for the ring to wake up. Signed-off-by:
-
Chris Wilson authored
It never quite worked despite the numerous workarounds, yet I still see people trying to use this hardware and filing bug reports. As we no longer even try to implement the workarounds, since 6a233c78 (drm/i915/ringbuffer: kill snb blt workaround), simply disable the ring. v2: Add a message to inform the user about the limited capabilities of their pre-production hardware. Signed-off-by:
-
