- 24 May, 2016 8 commits
-
-
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 <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-7-git-send-email-chris@chris-wilson.co.uk
-
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 31 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ä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463407180-28993-1-git-send-email-ville.syrjala@linux.intel.comReviewed-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:
Jani Nikula <jani.nikula@linux.intel.com>
-
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: -
Dave Gordon authored
Split the function of "enable_guc_submission" into two separate options. The new one ("enable_guc_loading") controls only the *fetching and loading* of the GuC firmware image. The existing one is redefined to control only the *use* of the GuC for batch submission once the firmware is loaded. In addition, the degree of control has been refined from a simple bool to an integer key, allowing several options: -1 (default) whatever the platform default is 0 DISABLE don't load/use the GuC 1 BEST EFFORT try to load/use the GuC, fallback if not available 2 REQUIRE must load/use the GuC, else leave the GPU wedged The new platform default (as coded here) will be to attempt to load the GuC iff the device has a GuC that requires firmware, but not yet to use it for submission. A later patch will change to enable it if appropriate. v4: Changed some error-message levels, mostly ERROR->INFO, per review comments by Tvrtko Ursulin. v5: Dropped one more error message, disabled GuC submission on hypothetical firmware-free devices [Tvrtko Ursulin]. v6: Logging tidy by Tvrtko Ursulin: * Do not log falling back to execlists when wedging the GPU. * Do not log fw load errors when load was disabled by user. * Pass down some error code from fw load for log message to make more sense. Signed-off-by:Fiedorowicz, Lukasz <lukasz.fiedorowicz@intel.com> Signed-off-by:
-
Dave Gordon authored
For now, anything with a GuC requires uCode loading, and then supports command submission once loaded. But these are logically distinct from simply "having a GuC", so we need a separate macro for the latter. Then, various tests should use this new macro rather than HAS_GUC_UCODE() or testing enable_guc_submission. v4: Added a couple more uses of the new macro. Signed-off-by: -
Dave Gordon authored
The GuC initialisation code could do other things apart from loading firmware, so here we rename the three primary entry points to remove any specific reference to "ucode" (no functional changes, just renaming). Signed-off-by:
-
- 22 May, 2016 1 commit
-
-
Daniel Vetter authored
Signed-off-by:
-
