- 25 May, 2016 1 commit
-
-
Daniel Vetter authored
This reverts the following patches: d55dbd06 drm/i915: Allow nonblocking update of pageflips. 15c86bdb drm/i915: Check for unpin correctness. 95c2ccdc Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates" a6747b73 drm/i915: Make unpin async. 03f476e1 drm/i915: Prepare connectors for nonblocking checks. 2099deff drm/i915: Pass atomic states to fbc update functions. ee7171af drm/i915: Remove reset_counter from intel_crtc. 2ee004f7 drm/i915: Remove queue_flip pointer. b8d2afae drm/i915: Remove use_mmio_flip kernel parameter. 8dd634d9 drm/i915: Remove cs based page flip support. 143f73b3 drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3. 84fc494b drm/i915: Add the exclusive fence to plane_state. 6885843a drm/i915: Convert flip_work to a list. aa420ddd drm/i915: Allow mmio updates on all platforms, v2. afee4d87 Revert "drm/i915: Avoid stalling on pending flips for legacy cursor updates" "drm/i915: Allow nonblocking update of pageflips" should have been split up, misses a proper commit message and seems to cause issues in the legacy page_flip path as demonstrated by kms_flip. "drm/i915: Make unpin async" doesn't handle the unthrottled cursor updates correctly, leading to an apparent pin count leak. This is caught by the WARN_ON in i915_gem_object_do_pin which screams if we have more than DRM_I915_GEM_OBJECT_MAX_PIN_COUNT pins. Unfortuantely we can't just revert these two because this patch series came with a built-in bisect breakage in the form of temporarily removing the unthrottled cursor update hack for legacy cursor ioctl. Therefore there's no other option than to revert the entire pile :( There's one tiny conflict in intel_drv.h due to other patches, nothing serious. Normally I'd wait a bit longer with doing a maintainer revert, but since the minimal set of patches we need to revert (due to the bisect breakage) is so big, time is running out fast. And very soon (especially after a few attempts at fixing issues) it'll be really hard to revert things cleanly. Lessons learned: - Not a good idea to rush the review (done by someone fairly new to the area) and not make sure domain experts had a chance to read it. - Patches should be properly split up. I only looked at the two patches that should be reverted in detail, but both look like the mix up different things in one patch. - Patches really should have proper commit messages. Especially when doing more than one thing, and especially when touching critical and tricky core code. - Building a patch series and r-b stamping it when it has a built-in bisect breakage is not a good idea. - I also think we need to stop building up technical debt by postponing atomic igt testcases even longer. I think it's clear that there's enough corner cases in this beast that we really need to have the testcases _before_ the next step lands. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Dave Airlie <airlied@redhat.com> Acked-by:
Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
- 24 May, 2016 11 commits
-
-
Chris Wilson authored
One of the uses for i915_gem_objects is pin-pointing leaks. For this, we can compare the number of allocated objects and who owns them, a discrepancy here often indicates a kernel bug. One allocator of unreported objects is for backing context objects, so include those in the listing. v2: Take filelist_mutex which requires a little dance with struct_mutex to avoid nesting filelist_mutex inside struct_mutex. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464098023-3294-10-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
Pack the integers and related types together inside the struct. Signed-off-by:
-
Chris Wilson authored
struct intel_context contains two substructs, one for the legacy RCS and one for every execlists engine. Since legacy RCS is a subset of the execlists engine support, just combine the two substructs. v2: Only pin the default context for legacy mode (the object only exists for legacy, but adding i915.enable_execlists provides symmetry with the cleanup functions). Signed-off-by:
-
Chris Wilson authored
Just move the kernel_context member of drm_i915_private next to the engines it is associated with. Signed-off-by:
-
Chris Wilson authored
Print the context's owner (via the pid under file_priv) under debugfs. In doing so, we must be careful that the filp is not accessed after it is freed (notified via i915_gem_context_close). v2: Mark the file_priv as closed. Signed-off-by:
-
Chris Wilson authored
Rather than have every context ask "am I owned by the kernel? pin!", move that logic into the creator of the kernel context, in order to improve code comprehension. v2: Throw away the user_handle on failure to allocate the ppgtt. Signed-off-by:
-
Chris Wilson authored
We want to give a name to the currently anonymous per-engine struct inside the context, so that we can assign it to a local variable and save clumsy typing. The name we have chosen is intel_context as it reflects the HW facing portion of the context state (the logical context state, the registers, the ringbuffer etc). Signed-off-by:
-
Chris Wilson authored
i915_gem_context_get() is a very simple wrapper around idr_find(), so simple that it would be smaller to do the lookup inline. Also we use the verb 'lookup' to return a pointer from a handle, freeing 'get' to imply obtaining a reference to the context. Signed-off-by:
-
Chris Wilson authored
Markup the functions that require the caller to hold struct_mutex with lockdep_assert_held(). In the hopefully not-too-distant future we will split the struct_mutex up, and in doing so we need to be sure that we know what it protects - here the lockdep annotations are invaluable. Signed-off-by:
-
Chris Wilson authored
Our goal is to rename the anonymous per-engine struct beneath the current intel_context. However, after a lively debate resolving around the confusion between intel_context_engine and intel_engine_context, the realisation is that the two structs target different users. The outer struct is API / user facing, and so carries the higher level GEM information. The inner struct is hw facing. Thus we want to name the inner struct intel_context and the outer one i915_gem_context. As the first step, we need to rename the current struct: s/struct intel_context/struct i915_gem_context/ which fits much better with its constructors already conveying the i915_gem_context prefix! Signed-off-by:
-
Tvrtko Ursulin authored
New GuC code is logging errors at runtime suspend and resume which causes CI testing to log "orange" status. Default to not trying to load the firmware until this is resolved. Example of the log: [drm] RC6 on [drm:intel_runtime_suspend] Suspending device [drm:host2guc_action [i915]] *ERROR* GUC: host2guc action 0x501 failed. ret=-110 status=0x00000501 response=0x40000000 ... [drm:intel_runtime_resume] Resuming device [drm:host2guc_action [i915]] *ERROR* GUC: host2guc action 0x502 failed. ret=-110 status=0x00000502 response=0x40000000 [drm:intel_runtime_resume] Device resumed Signed-off-by:
-
- 23 May, 2016 28 commits
-
-
Ville Syrjälä authored
Like with cdclk, the DMC is supposed to manage dbuf enabling/disabling. Let's make sure it has correctly restored the dbuf state to enabled when we disable the DC states. v2: s/skl/gen9/ in function name (Imre) Cc: Imre Deak <imre.deak@intel.com> Suggested-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
In case the driver is initialized without active displays, we should just drop the cdclk to the minimum frequency right off the bat. There might not be a modeset to drop it to the minimum late rafter all. With DMC supposedly we should always have the cdclk up and running. The DMC will shut the DE PLL down when appropriate, so let's nuke the related FIXMEs as well. Trying to do anything different would go against the expectations of the DMC firmware, and we all know how fragile the DMC firmware is. Signed-off-by:
-
Ville Syrjälä authored
Rather than having a BXT specific function to make sure the DE PLL is enabled after disabling DC6, let's just make sure the current cdclk is the same as what we last programmed. Having another check in bxt_display_core_init() almost immediately after the cdclk init seems redundant, so let's just kill that one. Signed-off-by:
-
Ville Syrjälä authored
Make bxt_set_cdclk() more readable by looking at current vs. target DE PLL vco to determine if the DE PLL needs disabling and/or enabling. We can also calculate the CD2X divider simply as (vco/cdclk) instead of depending on magic numbers. The magic numbers are still needed though, but only to map the supported cdclk frequencies to corresponding DE PLL frequencies. Note that w'll now program CDCLK_CTL correctly even for the bypass case. Actually the CD2X divider should not matter in that case since the hardware will bypass it too, but the "decimal" part should matter (if we want to do gmbus/aux with the bypass enabled). Signed-off-by:
-
Ville Syrjälä authored
Now that we've read out the DE PLL vco and refclk, we can just use them in the cdclk calculation. While at it switch over to DIV_ROUND_CLOSEST(). Signed-off-by:
-
Ville Syrjälä authored
Let's make sure our cached cdclk state is accurate right after broxton_init_cdclk() whether or not we end up changing the cdclk frequency. Signed-off-by:
-
Ville Syrjälä authored
We have need to know the DE PLL refclk and output frequency in various cdclk calculations, so let's store those in dev_priv. Signed-off-by:
-
Ville Syrjälä authored
Enabling and disalbing the DE PLL are two nice self contained operations, so let's move them into a few small helper functions. Makes it easier to see the forest from the trees in broxton_set_cdclk(). Signed-off-by:
-
Ville Syrjälä authored
Future platforms will have multiple options for the cdclk PLL reference clock, so let's start tracking that under dev_priv alreday on SKL, although on SKL it's always 24 MHz. Signed-off-by:
-
Ville Syrjälä authored
We'll want to store the cdclk PLL (whatever PLL that is in reality) vco frequency somewhere on other platforms too, so let's rename the skl_vco_freq to cdclk_pll.vco, and let's store it in kHz instead of MHz to match most of the other clocks. v2: Drop the spurious > vs != change (Imre) Signed-off-by:
-
Ville Syrjälä authored
The SKL 308.57 MHz cdclk is probably 8640/28 = ~308.571 Mhz. Similartly the 617.14 MHz cdclk is probably 8640/14 = ~617.143 MHz. Let's use the slightly more accurate numbers. Potentially we might change to computing all of these based on dividers, but let's stick to the current theme for now.. Signed-off-by:
-
Ville Syrjälä authored
SKL and BXT have the same snippets of code for enabling disabling the DBUF. Extract those into helpers and move the calls from init/unit_cdclk() to the display core init/init since this stuff isn't really about cdclk. Also doing the enable twice shouldn't hurt since you're just setting the request bit again when it was already set. We can also toss in a few WARNs about the register values into skl_get_dpll0_vco() now that we know that things should always be sane there. Flatten skl_init_cdclk() while at it. v2: s/skl/gen9/ in function names (Imre) Signed-off-by:
-
Ville Syrjälä authored
Currently we initialize cdclk on SKL from two different places, depending on whether it's during driver init or resume. Let's unify it to happen from the same place always, and that place will be the display core init function. To do this we first run through the cdclk sanitation code, which will first verify that the PLL is programmed correctly, after which we can read out the current cdclk frequency, and once the cdclk is known we verify that the cdclk "decimal" frequency is programmed correctly. If any of these fail we will force a cdclk change, and to be safe we also force the PLL to be turned off and on again. If the sanitation step didn't notice anything amiss, we'll skip the cdclk programming which will prevent cdclk reprogramming when the displays might be active. We can also toss in a few WARNs about the register values into skl_update_dpll0() since we now know that the PLL state should always be sane when that function is called. Signed-off-by:
-
Ville Syrjälä authored
Also verify the DPLL_CTRL1 register value in skl_sanitize_cdclk(), throw out a few unneeded variables, and write the CDCLK_CTL check a bit more legible way. Signed-off-by:
-
Ville Syrjälä authored
Now that skl_vco_freq tracks the actual DPLL0 vco frequency, we'll need something that keeps track of which vco frequency we want to use in case the current vco is 0. This would be important across supend/resume since we'll disable DPLL0 around those parts. We'll also update our idea of max cdclk/dotclock when the preferred vco changes. That could happen if out initial guess was wrong, and later eDP would force us to change it. One issue here could be that changing the max dotclock could cause our mode list to change during next time the displays get probed. But I don't see a good way to avoid that, except perhaps by allowing either vco frequency to be used as needed. But the docs suggest that such usage wasn't really inteded. Also need to make sure we don't update our max_cdclk value before we have a preferred vco value, which means moving that to happen after the cdclk sanitation. Signed-off-by:
-
Ville Syrjälä authored
In case we originally guessed wrong which lcpll vco frequency to use, we will need to shut down the pll and restart it when reprogamming the cdclk. This also allows us to track the actual vco frequency in dev_priv instead of just a guess. Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Currently we're trying to guess which lcpll vco frequency is used use based on the cdclk. That doesn't work for cdclk==540 since both vco frequencies can generate a 540 Mhz output. Let's stop guessing and just read the actual vco frequency from the hardware. Signed-off-by:
-
Ville Syrjälä authored
We have many places where we want to pick a suitable cdclk frequency for skl based on the dotclock and lcpll vco. Split that code into a small helper and call it from all over. Signed-off-by:
-
Ville Syrjälä authored
Shared plls won't get assigned until the .compute_clocks() hook gets called, which happens from the crtc .atomic_check hook. That's too late as the cdclk computation has already happened. So let's move the DPLL0 VCO computation into intel_dp_compute_config() so that it's done when the cdclk computation happens. Also only do it for eDP since we only pick DPLL0 for eDP. Signed-off-by:
-
Clint Taylor authored
WARNING: Using ChromeOS with an eDP panel and a 4K@60 DP monitor connected to DDI1 the system will hard hang during a cold boot. Occurs when DDI1 is enabled when the cdclk is less then required. DP connected to DDI2 and HPD on either port works correctly. Set cdclk based on the max required pixel clock based on VCO selected. Track boot vco instead of boot cdclk. The vco is now tracked at the atomic level and all CRTCs updated if the required vco is changed. Not tested with eDP v1.4 panels that require 8640 vco due to availability. V1: initial version V2: add vco tracking in intel_dp_compute_config(), rename skl_boot_cdclk. V3: rebase, V2 feedback not possible as encoders are not aware of atomic. V4: track target vco is atomic state. modeset all CRTCs if vco changes V5: rename atomic variable, cleaner if/else logic, use existing vco if encoder does not return a new vco value. check_patch.pl cleanup V6: simplify logic in intel_modeset_checks. V7: reorder an IF for readability and whitespace fix. V8: use dev_cdclk for tracking new cdclk during atomic V9: correctly handle vco 8640 when crtcs==0 V10: Clean up if else in crtcs==0 V11: Rebase for new intel_dpll_mgr.c Reviewed-by:Clint Taylor <clinton.a.taylor@intel.com> [vsyrjala: rebased due to churn] Signed-off-by:
-
Ville Syrjälä authored
commit 4e5ca60f ("drm/i915: Use ilk_max_pixel_rate() for BXT cdclk calculation") tried to change BXT to use ilk_max_pixel_rate() to compute the pipe pixel rate. I failed to notice that there was another place in the state readout code that needs the same treatment. So let's change that one too. Should probably just change things to always compuyte the pipe pixel rates, instead of just doing on platforms that can change cdclk dynamically. But for now let's just move BXT fully over to the side that uses ilk_pipe_pixel_rate(). Cc: Jani Nikula <jani.nikula@intel.com> Fixes: 4e5ca60f ("drm/i915: Use ilk_max_pixel_rate() for BXT cdclk calculation") Signed-off-by:
-
Chris Wilson authored
Current intel_opregion_init is called during the driver registration phase and intel_opregion_fini from the unregistration phase. Rename the functions so that this is clear from their names. The phases tell us what we expect the existing hw state to be, e.g. whether interrupts are still enabled etc. It should be noted that the opregion init/fini routines are asymmetric and this is carried across into their new names. Indeed, their new names make it even clearer that perhaps all is not well in the opregion suspend/resume sequence (as well in the module unload). Signed-off-by:
-
Chris Wilson authored
Prefer passing struct drm_i915_private to internal interfaces as this saves us having to dance between drm_device and our native struct. The savings hare are small (only 70 bytes of unrequired dancing), but progressive! Signed-off-by:
-
Ville Syrjälä authored
We've never actually enabled or unmasked the GSE interrupt on BDW+, even though the interrupt handler was always prepared for it. Let's enable it and see what happens. Credit to Mark Kettenis who fixed this in the OpenBSD fork of the driver. He reports that it fixed the "ACPI _BCM/_BCQ-based brightness mechanism on a MacBookPro12,1 and a 3rd gen Lenovo X1 Carbon" for them. Mark says: "FWIW, this *is* needed if you want ACPI-based backlight control to work. On Linux you probably don't notice, since "hardware" backlight control is preferred over "firmware" or "platform" backlight control. It would help me if this did land in the Linux tree though, as it will make future imports of the i915 driver into OpenBSD easier." So even though we don't really need this, let's put it in to help Mark with future porting efforts. Should be harmless to have it enabled in any case. Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> References: http://lists.freedesktop.org/archives/intel-gfx/2015-December/081799.htmlReported-by:
Mark Kettenis <mark.kettenis@xs4all.nl> Cc: Mark Kettenis <mark.kettenis@xs4all.nl> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Dave Gordon authored
Mostly little optimisations and future-proofing against code breakage. For instance, if the driver is correctly following the submission protocol, the "out of space" condition is impossible, so the previous runtime WARN_ON() is promoted to a GEM_BUG_ON() for a more dramatic effect in development and less impact in end-user systems. Similarly we can make alignment checking more stringent and replace other WARN_ON() conditions that don't relate to the runtime hardware state with either BUILD_BUG_ON() for compile-time-detectable issues, or GEM_BUG_ON() for logical "can't happen" errors. With those changes, we can convert it to void, as suggested by Chris Wilson, and update the calling code appropriately. v2: Note that we're now putting the request seqno in the "fence_id" field of each GuC-work-item, in case it turns up somewhere useful (e.g. in a GuC log) [Tvrtko Ursulin]. Signed-off-by:Dave Gordon <david.s.gordon@intel.com> Reviewed-by:
-
Dave Gordon authored
Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid of an uninterruptable sleep in the polling code :) We'll also add a counter to the GuC client statistics, to see how often we find the WQ full. v2: Flag the likely() code path (Tvtrko Ursulin). v4: Add/update comments about failure counters (Tvtrko Ursulin). Signed-off-by: -
Dave Gordon authored
The knowledge of how to derive the relevant client from the request should be localised within i915_guc_submission.c; the LRC code shouldn't have to know about the internal details of the GuC submission process. And all the information the GuC code needs should be encapsulated in (or reachable from) the request. v2: GEM_BUG_ON() for bad GuC client (Tvrtko Ursulin). Add/update kerneldoc explaining check_space/submit protocol Signed-off-by:
-
