- Feb 14, 2015
-
-
Hoath, Nicholas authored
v2: Don't add WaHdcDisableFetchWhenMasked. Add stepping check for WaForceEnableNonCoherent Signed-off-by:
Nick Hoath <nicholas.hoath@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Hoath, Nicholas authored
Move Wa4x4STCOptimizationDisable to gen9_init_workarounds v2: rebase Signed-off-by:
-
Nick Hoath authored
Move WaEnableYV12BugFixInHalfSliceChicken7 to gen9_init_workarounds v2: Add stepping check. Signed-off-by:
-
Hoath, Nicholas authored
v2: Add stepping check for WaDisableSDEUnitClockGating. Signed-off-by:
-
Nick Hoath authored
This one doesn't have one of these nice cryptic names unfortunately. v2: Added missing register bitmap Signed-off-by:
-
Nick Hoath authored
Move WaDisableDgMirrorFixInHalfSliceChicken5 to gen9_init_workarounds v2: Added stepping check v3: Removed unused register bitmap Signed-off-by:
-
Hoath, Nicholas authored
v2: Dont add WaDisableThreadStallDopClockGating as not SKL WA. (Found by Damien Lespiau) Signed-off-by:
-
Hoath, Nicholas authored
Add Skylake stepping Revision IDs definitions. v1: Use existing revision id. Signed-off-by:
-
Hoath, Nicholas authored
Add framework for gen 9 HW WAs v1: Changed SOC specific WA function to gen 9 common function (Req: Damien Lespiau) Signed-off-by:
-
Damien Lespiau authored
We don't want to end up in a state where we track that the pipe has its primary plane enabled when primary plane registers are programmed with values that look possible but the plane actually disabled. Refuse to read out the fb state when the primary plane isn't enabled. Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Damien Lespiau authored
Right now, we get a warning when taking over the firmware fb: [drm:drm_atomic_plane_check] FB set but no CRTC with the following backtrace: [<ffffffffa010339d>] drm_atomic_check_only+0x35d/0x510 [drm] [<ffffffffa0103567>] drm_atomic_commit+0x17/0x60 [drm] [<ffffffffa00a6ccd>] drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper] [<ffffffffa00f1fed>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm] [<ffffffffa00a8a1b>] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper] [<ffffffffa00aa969>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper] [<ffffffffa00aa9e2>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper] [<ffffffffa050a71a>] intel_fbdev_set_par+0x1a/0x60 [i915] [<ffffffff813ad444>] fbcon_init+0x4f4/0x580 That's because we update the plane state with the fb from the firmware, but we never associate the plane to that CRTC. We don't quite have the full DRM take over from HW state just yet, so fake enough of the plane atomic state to pass the checks. v2: Fix the state on which we set the CRTC in the case we're sharing the initial fb with another pipe. (Matt) Signed-off-by: -
Damien Lespiau authored
At the moment we use crtc->base.primary->fb to hold the initial framebuffer allocation, disregarding if it's valid or not. This lead to believe we were actually updating the fb at this point, but it's not true and we haven't even called drm_framebuffer_init() on this fb. Instead, let's store the state in struct intel_initial_plane_config until we know we can reuse that framebuffer. Signed-off-by:
-
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: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 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=88975 Suggested-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=88909 Signed-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: -
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:
-
- Feb 04, 2015
-
-
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=88908 Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
- Jan 31, 2015
-
-
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:
-
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:
-
- Jan 30, 2015
-
-
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:
-
- Jan 29, 2015
-
-
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:
-
