- 13 Feb, 2015 14 commits
-
-
Damien Lespiau authored
Tvrtko noticed a new warning on boot: WARNING: CPU: 1 PID: 353 at include/linux/kref.h:47 drm_framebuffer_reference+0x6c/0x80 [drm]() Call Trace: [<ffffffff8161f10c>] dump_stack+0x4f/0x7b [<ffffffff81052caa>] warn_slowpath_common+0xaa/0xd0 [<ffffffff81052d8a>] warn_slowpath_null+0x1a/0x20 [<ffffffffa00d035c>] drm_framebuffer_reference+0x6c/0x80 [drm] [<ffffffffa01c0df7>] update_state_fb.isra.54+0x47/0x50 [i915] [<ffffffffa01ccd5c>] skylake_get_initial_plane_config+0x93c/0x950 [i915] [<ffffffffa01e8721>] intel_modeset_init+0x1551/0x17c0 [i915] [<ffffffffa02476e0>] i915_driver_load+0xed0/0x11e0 [i915] [<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70 [<ffffffffa00ca8b7>] drm_dev_register+0x77/0x110 [drm] [<ffffffffa00cda3b>] drm_get_pci_dev+0x11b/0x1f0 [drm] [<ffffffff81098e3d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70 [<ffffffffa0145276>] i915_pci_probe+0x56/0x60 [i915] [<ffffffff813ad59c>] pci_device_probe+0x7c/0x100 [<ffffffff81466aad>] driver_probe_device+0x16d/0x380 We cannot take a reference at this point, not before intel_framebuffer_init() and the underlying drm_framebuffer_init(). Introduced in: commit 706dc7b549175e47f23e913b7f1e52874a7d0f56 Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Feb 3 13:10:04 2015 -0800 drm/i915: Ensure plane->state->fb stays in sync with plane->fb v2: Don't move update_state_fb(). It was moved around because I originally put update_state_fb() in intel_alloc_plane_obj() before finding a better place. (Matt) Reviewed-by:Matt Roper <matthew.d.roper@intel.com> Reported-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
The code look slightly better this way and will ease the next commit, changing where we take the fb pointer from. Signed-off-by:
-
Damien Lespiau authored
update_state_fb() at the end of intel_find_plane_obj() is misleading as it leads us to believe the update is done for all code path. A successful call to intel_alloc_plane_obj() will return and update_state_fb() is then only needed when we share a fb from another CRTC. Put the update() function there then. Signed-off-by:
-
Jani Nikula authored
The check for previously reserved stolen space size for FBC in i915_gem_stolen_setup_compression() did not take the compression threshold into account. Fix this by storing and comparing to uncompressed size instead. The bug has been introduced in commit 5e59f717 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Mon Jun 30 10:41:24 2014 -0700 drm/i915: Try harder to get FBC Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88975Suggested-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Damien Lespiau authored
v2: leave intel_skylake_info alone (Rodrigo, Daniel) Signed-off-by:
-
Damien Lespiau authored
We need to have a separate GT3 struct intel_device_info to declare they have a second VCS. Let's start by splitting the PCI ids per-GT. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Satheeshakrishna M authored
This patch implements core logic of SKL display power well. v2: Addressed Imre's comments - Added respective DDIs under power well #1 and #2 - Simplified repetitive code in power well programming v3: Implemented Imre's comments - Further simplified power well programming - Made sure that PW 1 is enabled prior to PW 2 v4: Fix minor conflict with the the cherryview support (Damien) v5: Add the PLL power domain to the always on power well (Damien) v6: Disable BIOS power well (Imre) Use power well data for comparison (Imre) Put the PLL power domain into PW1 as its needed for CDCLK (Satheesh, Damien) v7: Addressed Imre's comments - Lowered the time out to 1ms - Added parantheses in macro - Moved debug message and fixed wait_for interval v8: - Add a WARN() when swiching on an unknown power well (Imre, done by Damien) - Whitespace fixes (spaces instead of tabs) (Damien) v9: (Imre, done by Damien) - Merge the register definitions with this patch - Merge the MISC IO power well in this patch v10: (Imre, done by Damien) - Define the Misc I/O power domains to be the power well 1 ones as Misc I/O needs to be enabled with PW1 - Added Transcoder A and VGA domains to PW 2 - Remove the MISC_IO power domains as well in the the always on domains definition - Move Misc I/O power well at the top of the power well list so it's turned on right after PW1. Reviewed-by:Imre Deak <imre.deak@intel.com> Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v3,v6,v7) Signed-off-by:
-
Matt Roper authored
plane->state->fb and plane->fb should always reference the same FB so that atomic and legacy codepaths have the same view of display state. In commit commit db068420560511de80ac59222644f2bdf278c3d5 Author: Matt Roper <matthew.d.roper@intel.com> Date: Fri Jan 30 16:22:36 2015 -0800 drm/i915: Keep plane->state updated on pageflip we already fixed one case where these two pointers could get out of sync. However it turns out there are a few other places (mainly dealing with initial FB setup at boot) that directly set plane->fb and neglect to update plane->state->fb. If we never do a successful update through the atomic pipeline, the RmFB cleanup code will look at the plane->state->fb pointer, which has never actually been set to a legitimate value, and try to clean it up, leading to BUG's. Add a quick helper function to synchronize plane->state->fb with plane->fb (and update reference counts accordingly) and call it everywhere the driver tries to manually set plane->fb outside of the atomic pipeline. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88909Signed-off-by: -
Damien Lespiau authored
We already track this in the intel_info struct. Signed-off-by:
-
Shobhit Kumar authored
This isuue got introduced in - commit 24ee0e64 Author: Gaurav K Singh <gaurav.k.singh@intel.com> Date: Fri Dec 5 14:24:21 2014 +0530 drm/i915: Update the DSI enable path to support dual Signed-off-by:
Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Replace the valleyview_set_rps() and gen6_set_rps() calls with intel_set_rps() which itself does the IS_VALLEYVIEW() check. The code becomes simpler since the callers don't have to do this check themselves. Most of the change was performe with the following semantic patch: @@ expression E1, E2, E3; @@ - if (IS_VALLEYVIEW(E1)) { - valleyview_set_rps(E2, E3); - } else { - gen6_set_rps(E2, E3); - } + intel_set_rps(E2, E3); Adding intel_set_rps() and making valleyview_set_rps() and gen6_set_rps() static was done manually. Also valleyview_set_rps() had to be moved a bit avoid a forward declaration. v2: Use a less greedy semantic patch Cc: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Tvrtko Ursulin authored
Daniel Vetter spotted a bug while reviewing some of my refactoring in this are of the code. I'll quote: """ > @@ -9764,6 +9768,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, > work->event = event; > work->crtc = crtc; > work->old_fb_obj = intel_fb_obj(old_fb); > + work->old_tiling_mode = to_intel_framebuffer(old_fb)->tiling_mode; Hm, that's actually an interesting bugfix - currently userspace could be sneaky and destroy the old fb immediately after the flip completes and the change the tiling of the underlying object before the unpin work had a chance to run (needs some fudgin with rt prios to starve workers to make this work though). Imo the right fix is to hold a reference onto the fb and not the underlying gem object. With that tiling is guaranteed not to change. """ This patch tries to implement the above proposed change. Signed-off-by:
-
Matt Roper authored
There are two sets of helper functions provided by the DRM core that can implement the .update_plane() and .disable_plane() hooks in terms of a driver's atomic entrypoints. The transitional helpers (which we have been using so far) create a plane state and then use the plane's atomic entrypoints to perform the atomic begin/check/prepare/commit/finish sequence on that single plane only. The full atomic helpers create a top-level atomic state (which is capable of holding multiple object states for planes, crtc's, and/or connectors) and then passes the top-level atomic state through the full "atomic modeset" pipeline. Switching from the transitional to full helpers here shouldn't result in any functional change, but will enable us to exercise/test more of the internal atomic pipeline with the legacy API's used by existing applications. Signed-off-by:
-
Matt Roper authored
Until all drivers have transitioned to atomic, the framebuffer associated with a plane is tracked in both plane->fb (for legacy) and plane->state->fb (for all the new atomic codeflow). All of our modeset and plane updates use drm_plane->update_plane(), so in theory plane->fb and plane->state->fb should always stay in sync and point at the same thing for i915. However we forgot about the pageflip ioctl case, which currently only updates plane->fb and leaves plane->state->fb at a stale value. Surprisingly, this doesn't cause any real problems at the moment since internally we use the plane->fb pointer in most of the places that matter, and on the next .update_plane() call, we use plane->fb to figure out which framebuffer to cleanup. However when we switch to the full atomic helpers for update_plane()/disable_plane(), those helpers use plane->state->fb to figure out which framebuffer to cleanup, so not having updated the plane->state->fb pointer causes things to blow up following a pageflip ioctl. The fix here is to just make sure we update plane->state->fb at the same time we update plane->fb in the pageflip ioctl. Signed-off-by:
-
- 03 Feb, 2015 1 commit
-
-
Daniel Vetter authored
You can _never_ assert that a lock is not held, except in some very restricted corner cases where it's guranteed that your code is running single-threade (e.g. driver load before you've published any pointers leading to that lock). In addition the early return breaks a bunch of testcases since with highly concurrent hangcheck stress tests the reset fails to work and the test doesn't recover and time out. This regression has been introduced in commit b8d24a06 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Wed Jan 28 17:03:14 2015 +0200 drm/i915: Remove nested work in gpu error handling Aside: It is possible to check whether a given task doesn't hold a lock, but only when lockdep is enabled, using the lockdep_assert_held stuff. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88908Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
- 30 Jan, 2015 7 commits
-
-
Daniel Vetter authored
Signed-off-by: -
Ander Conselvan de Oliveira authored
The get_config() functions for ddi and dp_mst, used to read the value of cpu_transcoder from the crtc->config instead of the state passed as an argument. On the hardware state readout path, that happens to work since the proper value is written to it before encoder->get_config() is called. However, in the check_crtc() path, the state will be read from the cpu_transcoder in the software tracking, instead of the one just read out from hw. Using the field in the supplied intel_crtc_state should do the right thing in both cases. v2: Fix intel_ddi_get_config() too. (Ander) Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by:
-
Nick Hoath authored
Remove request from list before unreferencing it, in case it's actually the only reference. (Found by Tvrtko Ursulin) This issue has been most likely introduced in commit 6d3d8274 Author: Nick Hoath <nicholas.hoath@intel.com> Date: Thu Jan 15 13:10:39 2015 +0000 drm/i915: Subsume intel_ctx_submit_request in to drm_i915_gem_request Signed-off-by:
Nick Hoath <nicholas.hoath@intel.com> Reviewed-by:
-
Ander Conselvan de Oliveira authored
This simplifies __intel_set_mode() a little. Signed-off-by:
-
Mika Kuoppala authored
The checking for ack and also any subsequent mmio access will serialize with setting the forcewake bit. Drop the posting read as superfluous. Note that in the put side we still want to keep the posting read as it will ensure that the hw sees our forcewake release in a timely manner and doesn't keep the hw powered up. Comment from Chris: On Wed, Jan 28, 2015 at 05:54:14PM +0200, Mika Kuoppala wrote: > Ville Syrjälä <ville.syrjala@linux.intel.com> writes: > > IIRC the posting read from same cache line actually fixed real bugs. So > > I'm a bit worried about dropping them. But I suppose it's possible only > > the _put side was important for those bugs. > > I found these: > > commit 6af2d180 > Author: Daniel Vetter <daniel.vetter@ffwll.ch> > Date: Thu Jul 26 16:24:50 2012 +0200 > > drm/i915: fix forcewake related hangs on snb > > commit 8dee3eea > Author: Ben Widawsky <ben@bwidawsk.net> > Date: Sat Sep 1 22:59:50 2012 -0700 > > drm/i915: Never read FORCEWAKE > > https://bugs.freedesktop.org/show_bug.cgi?id=51738 > https://bugs.freedesktop.org/show_bug.cgi?id=52424 > > The snb here seems to survive gem_dummy_reloc_loop and > gem_ring_sync_loop in here with the get side posting removed. Note that we kept the once associated with #52424, but judging by my comments in #51738 the posting read is just a band aid anyway as a full mb() itself was not adequate. Suggested-by:
-
Mika Kuoppala authored
intel_uncore_early_sanitize() will reset the forcewake registers. When forcewake domains were introduced, the domain init was done after the sanitization of the forcewake registers. And as the resetting of registers use the domain accessors, we tried to reset the forcewake registers with unitialized forcewake domains and failed. Fix this by sanitizing after all the domains have been initialized. Do per domain clearing of forcewake register on domain init so that IVB can do early access to ECOBUS do determine the final configuration. This regression was introduced in commit 05a2fb15 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Mon Jan 19 16:20:43 2015 +0200 drm/i915: Consolidate forcewake code v2: Carve out ellc detect, fw_domain_reset for ivb/ecobus (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88805 Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by:
Olof Johansson <olof@lixom.net> Tested-by: Darren Hart <dvhart@linux.intel.com> (v1) Signed-off-by:
-
Ville Syrjälä authored
Move the CHV check into vlv_set_rps_idle() to simplify the caller a bit. Signed-off-by:
-
- 29 Jan, 2015 8 commits
-
-
Mika Kuoppala authored
Now when we declare gpu errors only through our own dedicated hangcheck workqueue there is no need to have a separate workqueue for handling the resetting and waking up the clients as the deadlock concerns are no more. The only exception is i915_debugfs::i915_set_wedged, which triggers error handling through process context. However as this is only used through test harness it is responsibility for test harness not to introduce hangs through both debug interface and through hangcheck mechanism at the same time. Remove gpu_error.work and let the hangcheck work do the tasks it used to. v2: Add a big warning sign into i915_debugfs::i915_set_wedged (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Mika Kuoppala authored
Include intel_uncore.c in template for it to include d documentation for intel_uncore_forcewake_get and *_put. Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
The removed functions can be resurrected in intel_dsi.c as need arises. Signed-off-by:
-
Jani Nikula authored
No functional changes. Signed-off-by:
-
Jani Nikula authored
All of these are replaced by the drm core mipi dsi functions. Signed-off-by:
-
Jani Nikula authored
Use the drm core interfaces in preparation of removing our homebrew. Signed-off-by:
-
Jani Nikula authored
Add basic support for using the drm mipi dsi framework for DSI. We don't use device tree which is pretty much required by mipi_dsi_host_register and friends, and we don't have the kind of device model the functions expect either. So we cheat and use it as a library to abstract what we need: a nice, clean interface for DSI transfers. This means we will have to be careful with what functions we call, as the driver model devices in mipi_dsi_host and mipi_dsi_device will *not* be initialized. Signed-off-by:
-
Jani Nikula authored
Replace intel_dsi_device and intel_dsi_dev_ops with drm_panel and drm_panel_funcs. They are adequate for what we have now, and if we end up needing more than this we should improve drm_panel. This will keep us better aligned with the drm core infrastructure. The panel driver initialization changes a bit. It still remains hideous, but fixing that is beyond the scope here. v2: extend mode config mutex to cover drm_panel_get_modes (Shobhit) vbt_panel->intel_dsi = intel_dsi in vbt panel init (Shobhit) Signed-off-by:
-
- 28 Jan, 2015 6 commits
-
-
Sonika Jindal authored
Mainly taking care of some register offsets, otherwise things are similar to hsw. Also, programming ddi aux to use hardcoded values for psr data select. v2: introduce EDP_PSR_AUX_BASE macro (Chris) v3: Moving to HW tracking for SKL+ platforms, so activating source psr during psr_enabling and then avoiding psr entries and exits for each frontbuffer updates. v4: Using SKL DDI AUX regs instead of changing PSR_AUX regs definition (Rodrigo) Signed-off-by:
Sonika Jindal <sonika.jindal@intel.com> Reviewed-by:
-
Chris Wilson authored
The core fix was applied in commit a63b03e2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jan 6 10:29:35 2015 +0000 mutex: Always clear owner field upon mutex_unlock() (note the absence of stable@ tag) so we can now revert our band-aid commit 226e5ae9 for -next. Signed-off-by:
-
Mika Kuoppala authored
We have had %x and %u intermixed. Bring everything in line and use %x Signed-off-by:
-
Chris Wilson authored
For example, /sys/kernel/debug/dri/0/i915_hangcheck_info: Hangcheck active, fires in 15887800ms render ring: seqno = -4059 [current -583] action = 2 score = 0 ACTHD = 1ee8 [current 21f980] max ACTHD = 0 v2: Include expiration ETA. Can anyone spot a problem? v3: Convert for workqueued hangcheck (Mika) v4: Print seqnos as unsigned ints (Ville) v5: Print seqnos as hex (Chris) Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) (v2) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Signed-off-by: -
Chris Wilson authored
When run as a timer, i915_hangcheck_elapsed() must adhere to all the rules of running in a softirq context. This is advantageous to us as we want to minimise the risk that a driver bug will prevent us from detecting a hung GPU. However, that is irrelevant if the driver bug prevents us from resetting and recovering. Still it is prudent not to rely on mutexes inside the checker, but given the coarseness of dev->struct_mutex doing so is extremely hard. Give in and run from a work queue, i.e. outside of softirq. v2: Use own workqueue to avoid deadlocks (Daniel) Cleanup commit msg and add comment to i915_queue_hangcheck() (Chris) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <dnaiel.vetter@ffwll.chm> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: -
Chris Wilson authored
An interesting bug occurs on Pineview through which the root cause is that the writes of the PTE values into the GTT is not serialised with subsequent memory access through the GTT (when using WC updates of the PTE values). This is despite there being a posting read after the GTT update. However, by changing the address of the posting read, the memory access is indeed serialised correctly. Whilst we are manipulating the memory barriers, we can remove the compiler :memory restraint on the intermediate PTE writes knowing that we explicitly perform a posting read afterwards. v2: Replace posting reads with explicit write memory barriers - in particular this is advantages in case of single page objects. Update comments to mention this issue is only with WC writes. Testcase: igt/gem_exec_big #pnv Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88191 Tested-by: huax.lu@intel.com (v1) Signed-off-by:
-
- 27 Jan, 2015 4 commits
-
-
Kumar Amit Mehta authored
The comment for intel_cpu_fifo_underrun_irq_handler() is not consistent with the code and the rest of the comment for this routine. This patch fixes this typo in comment. Signed-off-by:
Kumar Amit Mehta <gmate.amit@gmail.com> Reviewed-by:
-
Matt Roper authored
We don't have full atomic modeset support yet, but the "nuclear pageflip" subset of functionality (i.e., plane operations only) should be ready. Allow the user to force atomic on for debug purposes, or for fixed-purpose embedded devices that will only use atomic for plane updates. The term 'nuclear' is used here instead of 'atomic' to make it clear that this doesn't allow full atomic modeset support, just a (very useful) subset of the atomic functionality. We'll drop the kernel parameter and unconditionally enable atomic in a future patch once all of the necessary pieces are in. v2: - Use module_param_named_unsafe() (Daniel) - Simplify comment on DRIVER_ATOMIC guard (Daniel) v3: - Make the parameter "nuclear_pageflip" rather than just "nuclear" for clarity. (Ander) v4: - Make the internal variable "nuclear_pageflip" as well as the command-line option. (Ander) Signed-off-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
-
Matt Roper authored
This will exercise our atomic pipeline for legacy property updates. Signed-off-by:
-
Matt Roper authored
The atomic helpers need these to prepare a new state object when starting a new atomic operation. Signed-off-by:
-
