- 22 May, 2014 24 commits
-
-
Oscar Mateo authored
As advanced by the previous patch, the ringbuffers and the engine command streamers belong in different structs. This is so because, while they used to be tightly coupled together, the new Logical Ring Contexts (LRC for short) have a ringbuffer each. In legacy code, we will use the buffer* pointer inside each ring to get to the pertaining ringbuffer (the actual switch will be done in the next patch). In the new Execlists code, this pointer will be NULL and we will use instead the one inside the context instead. Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Oscar Mateo authored
In the upcoming patches we plan to break the correlation between engine command streamers (a.k.a. rings) and ringbuffers, so it makes sense to refactor the code and make the change obvious. No functional changes. Signed-off-by:
-
Imre Deak authored
Atm, we disable GT power saving during the end of the suspend sequence in i915_save_state(). Doing the disabling at that point seems arbitrary. One reason to disable it early though is to have a quiescent HW state before we do anything else (for example save registers). So move the disabling earlier, which also takes care canceling of the deferred RPS enabling work done by intel_disable_gt_powersave(). Note that after the move we'll call intel_disable_gt_powersave() only in case modeset is enabled, but that's anyway the only case where we have it enabled in the first place. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Robert Beckett <robert.beckett@intel.com> Signed-off-by:
-
Imre Deak authored
In commit c6df39b5 Author: Imre Deak <imre.deak@intel.com> Date: Mon Apr 14 20:24:29 2014 +0300 drm/i915: get a runtime PM ref for the deferred GT powersave enabling I added an RPM get-ref when enabling RPS from a deferred work, but forgot to add the corresponding put-ref when canceling the work. This may leave RPM disabled. Note that the race is real since we run the rps enabling with a delayed work item after resume, so leaves enough time (in contrived examples) to fit a quick autoresum in. Signed-off-by:
-
Imre Deak authored
Currently user space can access GEM buffers mapped to GTT through existing mappings concurrently while the platform specific suspend handlers are running. Since these handlers may change the HW state in a way that would break such accesses, remove the mappings before calling the handlers. Spotted by Ville. Also Chris pointed out that the lists that i915_gem_release_all_mmaps() walks through need dev->struct_mutex, so take this lock. There is a potential deadlock against a concurrent RPM resume, resolve this by aborting and rescheduling the suspend (Daniel). v2: - take struct_mutex around i915_gem_release_all_mmaps() (Chris, Daniel) Signed-off-by:
-
Ville Syrjälä authored
Apparently we need to disable VCP unit clock gating around media reset on g4x. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ville Syrjälä authored
On gen2 the scanline counter behaves a bit differently from the later generations. Instead of adding one to the raw scanline counter value, we must subtract one. On HSW/BDW the scanline counter requires a +2 adjustment on HDMI outputs. DP outputs on the on the other require the typical +1 adjustment. As the fixup we must apply to the hardware scanline counter depends on several factors, compute the desired offset at modeset time and tuck it away for when it's needed. v2: Clarify HSW+ situation Signed-off-by:
-
Ville Syrjälä authored
The docs are a bit lacking when it comes to describing when certain timing related events occur in the hardware. Draw a picture which tries to capture the most important ones. v2: Clarify a few details (Imre) v3: Add HSW+ HDMI scanline counter numbers Acked-by:
Akash Goel <akash.goels@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Currently the logic to fix up the frame counter on gen3/4 assumes that start of vblank occurs at vblank_start*htotal pixels, when in fact it occurs htotal-hsync_start pixels earlier. Apply the appropriate adjustment to make the frame counter more accurate. Also fix the vblank start position for interlaced display modes. Reviewed-by:
-
Ville Syrjälä authored
In interlaced modes, the pixel counter counts all pixels, so one field will have htotal more pixels. In order to avoid the reported position from jumping backwards when the pixel counter is beyond the length of the shorter field, just clamp the position the length of the shorter field. This matches how the scanline counter based position works since the scanline counter doesn't count the two half lines. Signed-off-by:
-
Chris Wilson authored
Daniel keeps on ramping up the warning level of the DRM and our display core to make it complain whenever the locking rules are not followed. This caught commit 24576d23 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Mar 26 09:25:45 2013 -0700 drm/i915: enable VT switchless resume v3 introducing an unlocked access to the CRTC whilst disabling it for suspend. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78114Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
-
Chris Wilson authored
Before purging our pages (as opposed to copying back the contents from the GPU), make sure that there is not an exposed CPU mmapping through which the user can inspect the results. Regression from commit 5537252b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Mar 25 13:23:06 2014 +0000 drm/i915: Invalidate our pages under memory pressure Testcase: igt/gem_mmap/new-object Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79005Signed-off-by:
Guo Jinxian <jinxianx.guo@intel.com> Signed-off-by:
-
Ville Syrjälä authored
We have to write to the primary plane base address registrer when we enable/disable the primary plane in response to sprite coverage. Those writes will cause the flip counter to increment which could interfere with the detection of CS flip completion. We could end up completing CS flips before the CS has even executed the commands from the ring. To avoid such issues, wait for CS flips to finish before we toggle the primary plane on/off. v2: Rebased due to atomic sprite update changes Testcase: igt/kms_mmio_vs_cs_flip/setplane_vs_cs_flip Signed-off-by:
-
Paulo Zanoni authored
With the current code, we unconditionally touch HSW_AUD_PIN_ELD_CP_VLD, which means we can touch it when the power well is off, and that will trigger an "Unclaimed register" message. Just adding the intel_crtc->config.has_audio should already avoid the unclaimed register messsages, but since we actually need the power well to make the Audio code work, it makes sense to also grab the audio power domain reference, and release it when it's not needed anymore. I used IGT's pm_rpm to reproduce this bug, but it can probably be reproduced on other tests that do modesets. I'm using a machine with eDP+HDMI connected. Regression introduced by: commit acfa75b0 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Apr 24 23:54:51 2014 +0200 drm/i915: Simplify audio handling on DDI ports Credits to Daniel for suggesting this implementation. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Paulo Zanoni authored
Because this will trigger "Unclaimed register" messages. All I need to reproduce this problem is to boot my HSW machine with eDP+HDMI connected. Regression introduced by: commit 9ed109a7 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Apr 24 23:54:52 2014 +0200 drm/i915: Track has_audio in the pipe config Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
Adding stuff at the bottom is really no how this should be done, since that's the place for ums/dri dungeons. This was added in commit a8ebba75 Author: Zhao Yakui <yakui.zhao@intel.com> Date: Thu Apr 17 10:37:40 2014 +0800 drm/i915: Use the coarse ping-pong mechanism based on drm fd to dispatch the BSD command on BDW GT3 Also add a note to prevent this from happening again - people really should be less lazy and take more time to look for a good home of their new driver-global state. Cc: Imre Deak <imre.deak@intel.com> Cc: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Gen2 reports FIFO underruns whenever no planes are enabled on the pipe. So in order to avoid false positives we must enable the FIFO underrun reporting only when at least one plane is enabled on the pipe. For now just move the underrun reporting enable/disable points to the other side of the plane enable/disable point. That doesn't cover cases when we turn off all the planes for the pipe but leave the pipe running on purpose, but it's better than the current situation. On gen4+ we can actually move the underrun reporting enable/disable to the opposite ends of the crtc enable/disable hooks. I suppose in theory we could leave the underrun reporting enabled all the time, except on VLV where PIPESTAT stops working when the display power well is down. If we ever get around to unifying the PIPESTAT irq handling for all gmch platforms, we should still follow the VLV route for other platforms. It would also micro-optimize the irq handler a bit since we could then skip the PIPESTAT reads for all disabled pipes. Gen3 is still a mystery, but for now I'm going to assume it behaves like gen4+. Signed-off-by:
Thomas Wood <thomas.wood@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Checking whether the error interrupt was enabled or not isn't really necessary when we check for uncleared FIFO underruns. If it was enabled we'll race with the interrupt handler a bit, but that seems OK as we still claim the interrupt. Signed-off-by:
-
Ville Syrjälä authored
FIFO underruns don't generate interrupts on gmch platforms, so if we want to know whether a modeset triggered FIFO underruns we need to explicitly check for them. As a modeset on one pipe could cause underruns on other pipes, check for underruns on all pipes. Signed-off-by:
-
Ville Syrjälä authored
FIFO underruns don't generate an interrupt on gmch platforms, so we should check whether there were any that we failed to notice when we're disabling FIFO underrun reporting. Signed-off-by:
-
Daniel Vetter authored
Noticed by Thierry Reding in his review, but I've merged the drm vblank rework topic branch a bit too quickly. So separate fixup. Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: -
Ville Syrjälä authored
The ascii art version of the DPIO diagram gets mangled by docbook, so we can't use it there. Insted provide another version built using <table>. Signed-off-by:
Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Document the internal structure of the VLV display PHY a bit to help people understand how the different register blocks relate to each other. v2: Add a bit more text Make it a DOC: comment, but leave the ascii art out since it would get mangled Signed-off-by: -
Mika Kuoppala authored
for proper refcounting to take place as we use i915_add_request() for it. i915_add_request() also takes the context for the request from ring->last_context so move the null state batch submission after the ring context has been set. v2: we need to check for correct ring now (Ville Syrjälä) v3: no need to expose i915_gem_move_object_to_active (Chris Wilson) v4: cargoculted vma/active/inactive error handling removed (Chris Wilson) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
- 21 May, 2014 14 commits
-
-
Ville Syrjälä authored
If a pipe is already active when we init/resume there might not be a full modeset afterwards so drm_vblank_on() may not get called. In such a case if someone is holding a vblank reference across a suspend/resume cycle drm_vblank_get() called after resuming won't re-enable the vblank interrupts. So in order to make sure vblank interrupts get re-enabled post-resume, call drm_vblank_on() in intel_sanitize_crtc() if the crtc is already active. v2: Also drm_vblank_off() if the pipe got disabled magically Signed-off-by:
-
Daniel Vetter authored
Pull in the drm vblank rework from Ville and me. drm core parts acked by Dave Airlie Conflicts: drivers/gpu/drm/i915/intel_display.c Just a bit of fun around the placement of drm_vblank_on. This merge resolution has been tested in drm-intel-nightly for a while already. Acked-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Daniel Vetter authored
We don't have hardware based disable bits on gmch platforms, so need to block spurious underrun reports in software. Which means that we _must_ start out with fifo underrun reporting disabled everywhere. This is in big contrast to ilk/hsw/cpt where there's only _one_ disable bit for all platforms and hence we must allow underrun reporting on disabled pipes. Otherwise nothing really works, especially the CRC support since that's key'ed off the same irq disable bit. This allows us to ditch the fifo underrun reporting hack from the vlv runtime pm code and unexport the internal function from i915_irq.c again. Yay! v2: Keep the display irq disabling, spotted by Imre. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Daniel Vetter authored
Now that we unconditionally dtrt when disabling/enabling crtcs we don't need any hacks any longer to keep the vblank logic sane when all the registers go poof. So let's rip it all out. This essentially undoes commit 9dbd8feb Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Tue Jul 23 10:48:11 2013 -0300 drm/i915: update last_vblank when disabling the power well Apparently igt/kms_flip is already powerful enough to exercise this properly, yay! See the reference regression report for details. v2: Update testcase name References: https://bugs.freedesktop.org/show_bug.cgi?id=66808 Testcase: igt/kms_flip/vblank-vs-*-rpm Reviewed-by:
-
Daniel Vetter authored
Only the low-level irq handling functions still use integer crtc indices with this. But fixing that will require a lot more sugery and some good ideas for backwards compat with old ums userspace. Both in drivers and in the drm core. Reviewed-by:
-
Daniel Vetter authored
We need to start somewhere ... With this the only places left in i915 where we use pipe integers is in the interrupt handling code. And there it actually makes some amount of sense. v2: - Polish kerneldoc a bit (Thierry). - Drop "dev" parameter since it's unecessary. - Split out i915 changes (Thierry). Cc: Thierry Reding <thierry.reding@gmail.com> Reviewed-by:
-
Daniel Vetter authored
- Integrate into the drm DocBook - Disable kerneldoc for functions not exported to drivers. - Properly document the new drm_vblank_on|off and add cautious comments explaining when drm_vblank_pre|post_modesets shouldn't be used. - General polish and OCD. v2: Polish as suggested by Thierry. Cc: Thierry Reding <thierry.reding@gmail.com> Reviewed-by:
-
Daniel Vetter authored
Leftover from the old days of ums and should be used any longer. Since commit 29935554 Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Date: Wed May 30 00:58:09 2012 +0200 drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers it is a complete no-Op for kms drivers. v2: Fix up mangled sentence spotted by Michel. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Michel Dänzer <michel@daenzer.net> Reviewed-by:
-
Daniel Vetter authored
Originally these functions have been for user modesetting drivers to ensure vblank processing doesn't fall over completely around modeset changes. This has been carried over ever since then. Now that Ville cleaned our vblank handling with an explicit drm_vblank_off/on braket when disabling/enabling crtcs. So this seems to be unnecessary now. The most important side effect was that due to the delayed vblank disabling we have been pretty much guaranteed to receive a vblank interrupt soonish after a crtc was enabled. Note that our vblank handling across modeset is still fairly decent fubar - we don't actually handle vblank counter all to well. drm_update_vblank_count will make sure that the frame counter always rolls forward, but userspace isn't really all to ready to cope with the big jumps this causes. This isn't a big mostly because the hardware retains the frame counter. But with runtime pm and also across suspend/resume we fall over. Fixing this is a lot more involved and also needs som i-g-ts. So material for another patch series. Reviewed-by:
-
Ville Syrjälä authored
All of the .queue_flip() callbacks duplicate the same code to pin the buffers and calculate the gtt_offset. Move that code to intel_crtc_page_flip(). In order to do that we must also move the ring selection logic there. Signed-off-by:
-
Ville Syrjälä authored
Now that we've plugged the mmio vs. ring flip race, we shouldn't need these vblank waits in the modeset codepaths anymore. So get rid of them. v2: gen2 needs to wait for planes to turn off before disabling pipe Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Now that the vblank wait is gone from intel_enable_primary_plane(), hsw_enable_ips() needs to do the vblank wait itself. Signed-off-by:
-
Ville Syrjälä authored
Starting from ILK, mmio flips also cause a flip done interrupt to be signalled. This means if we first do a set_base and follow it immediately with the CS flip, we might mistake the flip done interrupt caused by the set_base as the flip done interrupt caused by the CS flip. The hardware has a flip counter which increments every time a mmio or CS flip is issued. It basically counts the number of DSPSURF register writes. This means we can sample the counter before we put the CS flip into the ring, and then when we get a flip done interrupt we can check whether the CS flip has actually performed the surface address update, or if the interrupt was caused by a previous but yet unfinished mmio flip. Even with the flip counter we still have a race condition of the CS flip base address update happens after the mmio flip done interrupt was raised but not yet processed by the driver. When the interrupt is eventually processed, the flip counter will already indicate that the CS flip has been executed, but it would not actually complete until the next start of vblank. We can use the DSPSURFLIVE register to check whether the hardware is actually scanning out of the buffer we expect, or if we managed hit this race window. This covers all the cases where the CS flip actually changes the base address. If the base address remains unchanged, we might still complete the CS flip before it has actually completed. But since the address didn't change anyway, the premature flip completion can't result in userspace overwriting data that's still being scanned out. CTG already has the flip counter and DSPSURFLIVE registers, and although the flip done interrupt is still limited to CS flips alone, the code now also checks the flip counter on CTG as well. v2: s/dspsurf/gtt_offset/ (Chris) Testcase: igt/kms_mmio_vs_cs_flip/setcrtc_vs_cs_flip Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73027Signed-off-by:
-
Jesse Barnes authored
We really just want to go detect displays again and fire off a hotplug event if things have changed, not go through full hotplug processing. Requested-by:
-
- 20 May, 2014 2 commits
-
-
Daniel Vetter authored
Since commit 2e82a720 Author: Imre Deak <imre.deak@intel.com> Date: Fri Jan 17 15:46:43 2014 +0200 drm/i915: don't disable DP port after a failed link training and commit 5d6a1116 Author: Imre Deak <imre.deak@intel.com> Date: Thu Jan 16 18:35:57 2014 +0200 drm/i915: don't disable the DP port if the link is lost we no longer call intel_dp_link_down from generic DP code, but only from the !HAS_DDI dp encoder functions. hsw/bdw have their own encoder disabling callback in intel_ddi.c. Hence the early return is no longer needed and the big comment just confusing, so let's rip it out. To ensure what we don't accidentally use this again on ddi encoders add a WARN_ON instead. Spotted while reading through intel_dp.c Cc: Imre Deak <imre.deak@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
drm_vblank_off() will turn off vblank interrupts, but as long as the refcount is elevated drm_vblank_get() will not re-enable them. This is a problem is someone is holding a vblank reference while a modeset is happening, and the driver requires vblank interrupt to work during that time. Add drm_vblank_on() as a counterpart to drm_vblank_off() which will re-enabled vblank interrupts if the refcount is already elevated. This will allow drivers to choose the specific places in the modeset sequence at which vblank interrupts get disabled and enabled. Testcase: igt/kms_flip/*-vs-suspend Signed-off-by:
-
