- 03 Jan, 2017 2 commits
-
-
Chris Wilson authored
Ville explained that the wakelock was being acquired during set-idle in order to flush the voltage change from the punit. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170102152845.32352-1-chris@chris-wilson.co.ukReviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Michal Wajdeczko authored
This function is only used by intel_guc_send() and it doesn't need to be exposed outside of intel_uc.o file. Also when defined as static, compiler will generate smaller code. Additionally let it take guc param instead dev_priv to match function name. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
- 02 Jan, 2017 2 commits
-
-
Nabendu Maiti authored
In future patches, we require greater flexibility in describing the number of scalers available on each CRTC. To ease that transition we move the current assignment to intel_device_info. Scaler structure initialisation is done if scaler is available on the CRTC. Gen9 check is not required as on depending upon numbers of scalers we initialize scalers or return without doing anything in skl_init_scalers. v3: Changed skl_init_scaler to intel_crtc_init_scalers v2: Added Chris's comments. Signed-off-by:
Nabendu Maiti <nabendu.bikash.maiti@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1480398794-22741-1-git-send-email-nabendu.bikash.maiti@intel.com
-
Ander Conselvan de Oliveira authored
The function intel_atomic_get_shared_dpll_state() is only called from intel_dpll_mgr.c and it concerns the same data structures as the other functions in that file, so move it there and make it static. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
- 31 Dec, 2016 4 commits
-
-
Chris Wilson authored
DRRS is not yet kerneldoc despite the allusion prior to enum drrs_refresh_rate_type. Drop the '**' to avoid the warnings from make htmldocs. Signed-off-by:
-
Chris Wilson authored
The existing kerneldoc was outdated, so time for a refresh. v2: Use single line kdoc, mention functions for manipulation Signed-off-by:
-
Chris Wilson authored
Parameter - no. Parameter: yes. Signed-off-by:
-
Chris Wilson authored
The read of the page pin count and the bind count are unordered, presenting races in the assert and it firing off incorrectly. Prevent this by restricting the assert to the vma bind/unbind routines where we have local cpu ordering between the two. Signed-off-by:
-
- 30 Dec, 2016 6 commits
-
-
Ander Conselvan de Oliveira authored
Remove the IS_PLATFORM() macros from intel_dump_pipe_config() and split that logic in platform specific implementations inside the dpll code, accessed through a platform independent interface. v2: Rebase. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The documentation for most of the non-static members and structs were missing. Fix that. v2: Fix typos (Durga) v3: Rebase. Fix make docs warnings. Document more. v4: capitilize CRTC; say that the prepare hook is a nop if the DPLL is already enabled; link to struct intel_dpll_hw_state from @hw_state field in struct intel_shared_dpll_state; reorganize DPLL flags; link intel_shared_dpll_state to other structs and functions. (Daniel) Signed-off-by: -
Ander Conselvan de Oliveira authored
The hook is called from intel_prepare_shared_dpll(). The name doesn't make sense after all the changes to modeset code. So just call it prepare. Signed-off-by:
Durgadoss R <durgadoss.r@intel.com> Reviewed-by:
-
Ander Conselvan de Oliveira authored
Struct intel_shared_dpll_config is used to hold the state of the DPLL in the "atomic" sense, so call it state like everything else atomic. v2: Rebase Signed-off-by:
-
Ander Conselvan de Oliveira authored
The function intel_shared_dpll_commit() performs the equivalent of drm_atomic_helper_swap_state() for the shared dpll state, which is not handled by the helpers. So make it do a full swap of the state and rename it for consistency. v2: Fix typo in the commit message. (Durga) v3: Rebase. v4: Swap the states instead of just renaming the function. (Daniel) Signed-off-by:
-
Ander Conselvan de Oliveira authored
While the details of getting a shared dpll are wrapped by intel_get_shared_dpll(), the release was still hand rolled into the modeset code. Fix that by creating an entry point for releasing the pll and move that code there. v2: Take old_dpll from crtc->state instead of crtc_state. (CI) Signed-off-by:
-
- 28 Dec, 2016 1 commit
-
-
Chris Wilson authored
Add an assertion to the plain i915_ggtt_offset() to double check that any offset we hand to the GuC is outside of its unmappable ranges. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
-
- 26 Dec, 2016 1 commit
-
-
Daniel Vetter authored
Signed-off-by:
-
- 24 Dec, 2016 2 commits
-
-
Daniele Ceraolo Spurio authored
The context has to obey the same offset requirements as the ring, so we can re-use the same bias value we computed for the ring instead of unconditionally using GUC_WOPCM_TOP. Suggested-by:
-
Daniele Ceraolo Spurio authored
GuC will validate the ring offset and fail if it is in the [0, GUC_WOPCM_TOP) range. The bias is conditionally applied only if GuC loading is enabled (we can't check for guc submission enabled as in other cases because HuC loading requires this fix). Note that the default context is processed before enable_guc_loading is sanitized, so we might still apply the bias to its ring even if it is not needed. v2: compute the value during ctx init and pass it to intel_ring_pin (Chris), updated commit message Signed-off-by:
-
- 23 Dec, 2016 9 commits
-
-
Chris Wilson authored
As the fence may be signaled concurrently from an interrupt on another device, it is possible for the list of requests on the timeline to be modified as we walk it. Take both (the context's timeline and the global timeline) locks to prevent such modifications. Fixes: 80b204bc ("drm/i915: Enable multiple timelines") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161223145804.6605-10-chris@chris-wilson.co.uk
-
Chris Wilson authored
When creating a partial VMA assert that it first fits with the parent object, and that if it covers the whole of the parent a normal view was created instead. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161223145804.6605-5-chris@chris-wilson.co.uk
-
Chris Wilson authored
As trimming the sg table is merely an optimisation that gracefully fails if we cannot allocate a new table, we do not need to report the failure either. Fixes: 0c40ce13 ("drm/i915: Trim the object sg table") Signed-off-by:
-
Chris Wilson authored
When we teardown the backing storage for the phys object, we copy from the coherent contiguous block back to the shmemfs object, clflushing as we go. Trying to clflush the invalid sg beforehand just oops and would be redundant (due to it already being coherent, and clflushed afterwards). Reported-by:
-
Chris Wilson authored
The idle work handler is self-arming - if it detects that it needs to run again it will queue itself from its work handler. Take greater care when trying to drain the idle work, and double check that it is flushed. The free worker has a similar issue where it is armed by an RCU task which may be running concurrently with us. This should hopefully help with the sporadic WARN_ON(dev_priv->gt.awake) from i915_gem_suspend. v2: Reuse drain_freed_objects. v3: Don't try to flush the freed objects from the shrinker, as it may be underneath the struct_mutex already. v4: do while and comment upon the excess rcu_barrier in drain_freed_objects Signed-off-by:
-
Chris Wilson authored
Since commit db6c2b41 ("drm/i915: Store the vma in an rbtree under the object") the vma are once again sorted into GGTT first, then ppGTT so that the typical case of walking the GGTT vma can stop as soon as we find a non-ppGTT. Apply that optimisation. Signed-off-by:
-
Ville Syrjälä authored
Now that we're disabling L2 clock gating MI_OVERLAY_OFF actually works on 830, so let's use it. v2: Nuke the unused dev_priv variable Signed-off-by:
-
Hans de Goede authored
On enable intel_dsi_enable() directly calls intel_enable_dsi_pll(), make intel_dsi_disable() also directly call intel_disable_dsi_pll(), rather then hiding the call in intel_dsi_clear_device_ready(), no functional changes. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Vincente Tsou authored
The upper bits of the vsync width, vsync offset and hsync width were not parsed from the VBT. Parse these fields in this patch. V2: Renamed lvds dvo timing structure members and code identation fix (Jani's review comments) V3: Corrected commit message, used "from the VBT" Signed-off-by:
Vincente Tsou <vincente.tsou@intel.com> Signed-off-by:
Madhav Chauhan <madhav.chauhan@intel.com> Reviewed-by:
-
- 22 Dec, 2016 13 commits
-
-
Ville Syrjälä authored
BSpec says: "Overlay Clock Gating Must be Disabled: Overlay & L2 Cache clock gating must be disabled in order to prevent device hangs when turning off overlay.SW must turn off Ovrunit clock gating (6200h) and L2 Cache clock gating (C8h)." We only turned off the overlay clock gating (due to lack of docs I presume). After a bit of experimentation it looks like the the magic C8h register lives in the PCI config space of device 0, and the magic bit appears to be bit 2. Or at the very least this eliminates the GPU death after MI_OVERLAY_OFF. L2 clock gating seems to save ~80mW, so let's keep it on unless we need to actually use the overlay. Also let's move the OVRUNIT clock gating to the same place since we can, and 845 supposedly doesn't need it. Signed-off-by:
-
Ville Syrjälä authored
Extract the primary plane pixel format via plane state when setting up the overlay colorkey. Signed-off-by:
-
Ville Syrjälä authored
Use two-dimensional arrays and named initializers to make the overlay filter coefficient tables easier to parse for humans. Signed-off-by:
-
Ville Syrjälä authored
The formula in Bspec for computing the overlay SWIDTHSW is overly obfuscated. Simplify the formula to something that's easily parsed by humans. Signed-off-by:
-
Ville Syrjälä authored
Check pipe config gmch_pfit.control instead of using intel_panel_fitter_pipe() to figure out if the pipe for the overlay is using the panel fitter. Signed-off-by:
-
Ville Syrjälä authored
Replace the use of crtc->mode.h/vdisplay with the more appropriate config->pipe_src_w/h. Signed-off-by:
-
Ville Syrjälä authored
Do the overlay frontbuffer tracking properly so that it matches the state of the overlay on/off/continue requests. One slight problem is that intel_frontbuffer_flip_complete() may get delayed by an arbitrarily liong time due to the fact that the overlay code likes to bail out when a signal occurs. So the flip may not get completed until the ioctl is restarted. But fixing that would require bigger surgery, so I decided to ignore it for now. Signed-off-by:
-
Ville Syrjälä authored
The vma will be NULL if the overlay was previously off, so dereferencing it will oops. Check for NULL before doing that. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Fixes: 9b3b7841 ("drm/i915/overlay: Use VMA as the primary tracker for images") Signed-off-by:
-
Ville Syrjälä authored
The i915_gem_active stuff doesn't like a NULL ->retire hook, but the overlay code can set it to NULL. That obviously ends up oopsing. Fix it by introducing a new helper to assign the retirement callback that will switch out the NULL function pointer with i915_gem_retire_noop. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Fixes: 0d9bdd88 ("drm/i915: Convert intel_overlay to request tracking") Signed-off-by:
-
Ville Syrjälä authored
Initialize overlay->last_flip properly instead of leaving it zeroed. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 0d9bdd88 ("drm/i915: Convert intel_overlay to request tracking") Reviewed-by:
-
Ville Syrjälä authored
Trying to determine the pixel rate of the pipe can't be done until we know the clock, which means it can't be done until the encoder .get_config() hooks have been called. So let's move the min_pixclk[] stuff to the end of intel_modeset_readout_hw_state() when we actually have gathered all the required infromation. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Fixes: 565602d7 ("drm/i915: Do not acquire crtc state to check clock during modeset, v4.") Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Ville Syrjälä authored
Apparently some VLV BIOSen like to leave the VDD force bit enabled even for power seqeuncers that aren't properly hooked up to any port. That will result in a imbalance in the AUX power domain refcount when we stat to use said power sequencer as edp_panel_vdd_on() will not grab the power domain reference if it sees that the VDD is already on. To fix this let's make sure we turn off the VDD force bit when we initialize the power sequencer registers. That is, unless it's being done from the init path since there we are actually initializing the registers for the current power sequencer and we don't want to turn VDD off needlessly as that would require waiting for the power cycle delay before we turn it back on. This fixes the following kind of warnings: WARNING: CPU: 0 PID: 123 at ../drivers/gpu/drm/i915/intel_runtime_pm.c:1455 intel_display_power_put+0x13a/0x170 [i915]() WARN_ON(!power_domains->domain_use_count[domain]) ... v2: Fix typos in comment (David) Cc: stable@vger.kernel.org Cc: Matwey V. Kornilov <matwey.kornilov@gmail.com> Tested-by:
Matwey V. Kornilov <matwey.kornilov@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98695Signed-off-by:
David Weinehall <david.weinehall@linux.intel.com>
-
Imre Deak authored
There is at least one APL based system using port A in DP mode (connecting to an on-board DP->VGA adaptor). Atm we'll configure port A unconditionally as eDP which is incorrect in this case. Fix this by relying on the VBT DDI port 'internal port' flag instead on all ports on DDI platforms. For now chicken out from using VBT for port A before GEN9. v2: - Move the DDI port info lookup to intel_bios_is_port_edp() (David, Jani) - Use the DDI port info on all DDI platforms starting from port B. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: David Weinehall <david.weinehall@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1482315444-24750-1-git-send-email-imre.deak@intel.com
-
