- 13 Feb, 2015 5 commits
-
-
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:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:Chris Wilson <chris@chris-wilson.co.uk> Signed-off-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:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> 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 <matthew.d.roper@intel.com> 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:
Rodrigo Vivi <rodrigo.vivi@intel.com> [danvet: Drop the hunks to short-circuit sw tracking: We'd need to push this down one level, and I don't fully trust the test coverage yet to do so. So much prefer we pick a whitelist approach for the cases we know work correctly.] Signed-off-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 13 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:
-
Matt Roper authored
Even though we only support atomic plane updates at the moment, we still need to add an .atomic_get_property() entrypoint for connectors before we allow the driver to flip on the DRIVER_ATOMIC bit. As soon as that bit gets set, the DRM core will start adding atomic connector properties (in addition to the plane properties we care about at the moment), so we need to be able to handle the new way the DRM core will interact with us. For simplicity, we just lookup driver-specific connector properties in the usual shadow array maintained by the core. Once we get real atomic modeset support for crtc's and planes, this code should be re-written to pull the data out of crtc/connector state structures. v2: Fix intel_dvo and intel_dsi that I missed on the first pass (Ander) Signed-off-by:
-
Matt Roper authored
We want to enable/test plane updates via the atomic interface, but as soon as we flip DRIVER_ATOMIC on, the DRM core will take some atomic codepaths to lookup properties during drmModeGetConnector() and some of those codepaths unconditionally dereference connector->state (specifically when looking up the CRTC ID property in drm_atomic_connector_get_property()). Create a dummy connector state for each connector at init time to ensure the DRM core doesn't try to dereference a NULL connector->state. The actual connector properties will never be updated or contain useful information, but since we're doing this specifically for testing/debug of the plane operations (and only when a specific kernel module option is given), that shouldn't really matter. Once we start creating connector states, the DRM core will want to be able to clean them up for us. We also need to hook up the destruction entrypoint to the core's helper. v2: Squash in the patch to set the state destruction hook (Ander & Bob) v3: Only create dummy connector states when we're actually faking atomic support. (Ander) Signed-off-by: -
Matt Roper authored
Add the top-level atomic entrypoints for check/commit. These won't get called yet; we still need to either enable the atomic ioctl or switch to using the non-transitional atomic helpers for legacy operations. v2: - Use plane->pipe rather than plane->possible_crtcs while ensuring that only a single CRTC is in use. Either way will work fine since i915 drm_plane's are always tied to a single CRTC, but plane->pipe is slightly more intuitive. (Ander) - Simplify crtc/connector checking logic. (Ander) Signed-off-by:
-
Matt Roper authored
When we flip on the DRIVER_ATOMIC bit, the DRM core will start calling this entrypoint to set and lookup driver-specific plane property values, rather than maintaining a shadow copy in object->properties. Note that although we add these functions to the plane vtable, they will not yet be called. Future patches that switch our .set_property() handler and/or enable full atomic functionality are required before these code paths will be executed. Signed-off-by:
-
Matt Roper authored
All of the previous refactoring/consolidation of plane code has resulted in intel_primary_plane_funcs, intel_cursor_plane_funcs, and intel_sprite_plane_funcs being identical. Replace all of these with a single 'intel_plane_funcs' vtable for simplicity. Signed-off-by:
-
Matt Roper authored
Runtime state that can be manipulated via properties should now go in intel_plane_state/drm_plane_state so that it can be tracked as part of an atomic transaction. We add a new 'intel_create_plane_state' function so that the proper initial value for this property (and future properties) doesn't have to be repeated at each plane initialization site. v2: - Stick rotation in common drm_plane_state rather than intel_plane_state. (Daniel) - Add intel_create_plane_state() to consolidate the places where we have to set initial state values. (Ander) Signed-off-by:
-
Ville Syrjälä authored
Replace all the vlv_gpu_freq(), vlv_freq_opcode(), *GT_FREQUENCY_MULTIPLIER, and /GT_FREQUENCY_MULTIPLIER instances with intel_gpu_freq() and intel_freq_opcode() calls. Most of the change was performed with the following semantic patch: @@ expression E; @@ ( - E * GT_FREQUENCY_MULTIPLIER + intel_gpu_freq(dev_priv, E) | - E *= GT_FREQUENCY_MULTIPLIER + E = intel_gpu_freq(dev_priv, E) | - E /= GT_FREQUENCY_MULTIPLIER + E = intel_freq_opcode(dev_priv, E) | - do_div(E, GT_FREQUENCY_MULTIPLIER) + E = intel_freq_opcode(dev_priv, E) ) @@ expression E1, E2; @@ ( - vlv_gpu_freq(E1, E2) + intel_gpu_freq(E1, E2) | - vlv_freq_opcode(E1, E2) + intel_freq_opcode(E1, E2) ) @@ expression E1, E2, E3, E4; @@ ( - if (IS_VALLEYVIEW(E1)) { - E2 = intel_gpu_freq(E3, E4); - } else { - E2 = intel_gpu_freq(E3, E4); - } + E2 = intel_gpu_freq(E3, E4); | - if (IS_VALLEYVIEW(E1)) { - E2 = intel_freq_opcode(E3, E4); - } else { - E2 = intel_freq_opcode(E3, E4); - } + E2 = intel_freq_opcode(E3, E4); ) One hunk was manually undone as intel_gpu_freq() ended up calling itself. Supposedly it would be possible to exclude certain functions via !=~, but I couldn't get that to work. Also the removal of vlv_gpu_freq() and vlv_opcode_freq() compat wrappers was done manually. Signed-off-by: -
Ville Syrjälä authored
Rename the vlv_gpu_freq() and vlv_freq_opecode() functions to have an intel_ prefix, and handle non-VLV/CHV platforms in them as well. Leave the vlv_ names around for now since they're currently used. Signed-off-by:
-
Ville Syrjälä authored
Currently the 'gt_cur_freq_mhz' file shows the actual GPU frequency on VLV/CHV, and the last requested frequency on other platforms. Change the meaning of the file on VLV/CHV to follow the the other platforms, and introduce a new file 'gt_act_freq_mhz' which shows the actual frequency on all platforms. Signed-off-by:
-
