- 06 Jul, 2017 11 commits
-
-
Imre Deak authored
The comments match an earlier version of the patch, fix them to match the current state. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498750622-14023-6-git-send-email-imre.deak@intel.com
-
Imre Deak authored
So far in an attempt to make sure all power wells get disabled during display uninitialization the driver removed any secondary request bits (BIOS, KVMR, DEBUG) that were set for a given power well. The known source for these requests was DMC's request on power well 1 and the misc IO power well. Since DMC is inactive (DC states are disabled) at the point we disable these power wells, there shouldn't be any reason to leave them on. However there are two problems with the above assumption: Bspec requires that the misc IO power well stays enabled (without providing a reason) and there can be KVMR requests that we can't remove anyway (the KVMR request register is R/O). Atm, a KVMR request can trigger a timeout WARN when trying to disable power wells. To make the code aligned to Bspec and to get rid of the KVMR WARN, don't try to remove the secondary requests, only detect them and stop polling for the power well disabled state when any one is set. Also add a comment about the timeout values required by Bspec when enabling power wells and the fact that waiting for them to get disabled is not required by Bspec. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98564Signed-off-by:
-
Imre Deak authored
What we want to assert based on the conditions required by Bspec is that power well 2 is disabled, so no need to check for other power wells. In addition we can only check if the driver's request is removed, the actual state depends on whether the other request bits are set or not (BIOS, KVMR, DEBUG). So check only the driver's request bit. Signed-off-by:
-
Imre Deak authored
Bspec requires leaving the misc IO power well enabled during display uninit, so align the code accordingly. Signed-off-by:
-
Imre Deak authored
Bspec requires a 10 us delay after disabling power well 1 and - if not toggled on-demand - the AUX IO power wells during display uninit. Signed-off-by:
-
Chris Wilson authored
Currently, we move all unreferenced contexts to an RCU free list and then onto a worker for eventual reaping. To compensate against this growing into a long list with frequent allocations starving the system of available memory, before we allocate a new context we reap all the stale contexts. This puts all the cost of destroying the context into the next allocator, which is presumably more sensitive to syscall latency and unfair. We can limit the number of contexts being freed by the new allocator to both keep the list trimmed and to allow the allocator to be reasonably fast. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705142634.18554-4-chris@chris-wilson.co.ukReviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Chris Wilson authored
Before we create a new context, we try and reap all the stale contexts (i.e. those that are freed but waiting for a worker to come and return their allocations to the system). Before we do this, we retire all requests so that we clear any inflight no longer used contexts (who are only being kept alived by those inflght requests). However, any context that is finally unreferenced by this retirement is put onto an RCU list and not available for immediately reaping, we stall for no immediate benefit. Signed-off-by:
-
Chris Wilson authored
We need to reap the stale contexts for all new contexts, be they created by user in i915_gem_context_ioctl or from opening a new file in i915_gem_context_open. Both paths may be called very frequently accumulating many stale contexts before any worker has a chance to run and free their memory. Fixes: 1acfc104 ("drm/i915: Enable rcu-only context lookups") Signed-off-by:
-
Chris Wilson authored
Avoid any pointer dereference in inspecting a potential PTR_ERR by checking for the error pointer before checking for an invalid context. Signed-off-by:
-
Xiong Zhang authored
In a IGD passthrough environment, the real ISA bridge may doesn't exist. then pch_id couldn't be correctly gotten from ISA bridge, but pch_id is used to identify LPT_H and LPT_LP. Currently i915 treat all LPT pch as LPT_H,then errors occur when i915 runs on LPT_LP machines with igd passthrough. This patch set pch_id for HSW/BDW according to IGD type and isn't fully correct. But it solves such issue on HSW/BDW ult/ulx machines. QA CI system is blocked by this issue for a long time, it's better that we could merge it to unblock QA CI system. We know the root cause is in device model of virtual passthrough, and will resolve it in the future with several parts cooperation in kernel, qemu and xen. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99938Signed-off-by:
Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1497496305-5364-1-git-send-email-xiong.y.zhang@intel.com
-
Arvind Yadav authored
attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by <linux/sysfs.h> work with const attribute_group. So mark the non-const structs as const. File size before: text data bss dec hex filename 4028 1088 0 5116 13fc drivers/gpu/drm/i915/i915_sysfs.o File size After adding 'const': text data bss dec hex filename 4196 928 0 5124 1404 drivers/gpu/drm/i915/i915_sysfs.o Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
-
- 04 Jul, 2017 5 commits
-
-
Manasi Navare authored
This patch fixes the DP AUX CH timeouts observed during CI IGT tests thus fixing the CI failures. This is done by adding a quirk for a particular PCI device that requires the panel power cycle delay (T12) to be set to 800ms which is 300msecs more than the minimum value specified in the eDP spec. So a quirk is implemented for that specific PCI device. v4: * Add Bugzilla links for FDO bugs in the commit message (Ville, Jani) v3: * Change some comments, specify the delay as 800 * 10 (Ville) v2: * Change the function and variable names to from PPS_T12_ to _T12 since it is a T12 delay (Clint) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101154 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101167 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101515 Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Clinton Taylor <clinton.a.taylor@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Clinton Taylor <clinton.a.taylor@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1498840428-23176-1-git-send-email-manasi.d.navare@intel.comSigned-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Mahesh Kumar authored
GEN9+ Interlace fetch mode doesn't support pipe/plane scaling, This patch adds check to fail the flip if pipe/plane scaling is requested in Interlace fetch mode. Changes since V1: - move check to skl_update_scaler (ville) - mode to adjusted_mode (ville) - combine pipe/plane scaling check Changes since V2: - Indentation fix - Added TODO to handle/reject NV12 with interlace mode Signed-off-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170630121100.20159-3-mahesh1.kumar@intel.comReviewed-by:
-
Mahesh Kumar authored
In Gen9 platform Interlaced fetch mode doesn't support following plane configuration: - Y/Yf tiling - 90/270 rotation - YUV420 hybrid planar source pixel formats. This patch adds check to fail the flip if any of the above configuration is requested. Changes since V1: - handle checks in intel_plane_atomic_check_with_state (ville) - takeout plane scaler checks combile with pipe scaler in next patch Changes since V2: - No need to check for NV12 as it need scaling, so it will be rejected by scaling check (ville) Signed-off-by:
-
Chris Wilson authored
Commit fabef825 ("drm/i915: Drop struct_mutex around frontbuffer flushes") adds a dependency to ifbdev->vma when flushing the framebufer, but the checks are only against the existence of the ifbdev->fb and not against ifbdev->vma. This leaves a window of opportunity where we may try to operate on the fbdev prior to it being probed (thanks to asynchronous booting). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101534 Fixes: fabef825 ("drm/i915: Drop struct_mutex around frontbuffer flushes") Signed-off-by:
-
Chris Wilson authored
When iterating the list of contexts to free, we need to use a safe iterator as we are freeing the link as we go. Pass an extra thick brown paper bag. Fixes: 5f09a9c8 ("drm/i915: Allow contexts to be unreferenced locklessly") Signed-off-by:
Matthew Auld <matthew.auld@intel.com>
-
- 03 Jul, 2017 3 commits
-
-
Maarten Lankhorst authored
When reading all debugfs files on a system with DP-MST the kernel panics on a null pointer dereference because intel_dp is null for a DP-MST connector. Detect this case and skip those connectors. Also fix the write for the DP compliance file in the same way. Changes since v1: - Fix i915_displayport_test_active_write too. (DK) Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170626081835.24251-1-maarten.lankhorst@linux.intel.com
-
sagar.a.kamble@intel.com authored
OA buffer initialization involves access to HW registers to set the OA base, head and tail. Ensure device is awake while setting these. With this, all oa.ops are covered under RPM and forcewake wakelock. Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
-
Daniel Vetter authored
Signed-off-by:
-
- 30 Jun, 2017 1 commit
-
-
Navare, Manasi D authored
The Cursor Coeff is lower 6 bits in the PORT_TX_DW4 register and hence the CURSOR_COEFF_MASK should be (0x3F << 0) Fixes: 04416108 ("drm/i915/cnl: Add registers related to voltage swing sequences.") Signed-off-by:
-
- 29 Jun, 2017 3 commits
-
-
Rodrigo Vivi authored
During the review of Coffee Lake workarounds Mika pointed out that WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC should be removed from CFL and with that I should carry the rv-b. However when doing the v2 I removed another Workaround that should remain because although not mentioned by spec the history of hangs around it advocates on its favor. On some follow-up patches I continued operating on the wrong workardound, but Ville noticed that, so here is the fix for the current CFL code that is upstream already. Fixes: 46c26662 ("drm/i915/cfl: Introduce Coffee Lake workarounds.") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Chris Wilson authored
When computing a hash for looking up relocation target handles in an execbuf, we start with a large size for the hashtable and proceed to halve it until the allocation succeeds. The final attempt is with an order of 0 (i.e. a single element). This means that we then pass bits=0 to hash_32() which then computes "hash >> (32 - 0)" to lookup the single element. Right shifting a value by the width of the operand is undefined, so limit the smallest hash table we use to order 1. v2: Keep the retry allocation flag for the final pass Fixes: 4ff4b44c ("drm/i915: Store a direct lookup from object handle to vma") Signed-off-by:
-
Gabriel Krisman Bertazi authored
There are still cases on these platforms where an attempt is made to configure the CDCLK while the power domain is off, like when coming back from a suspend. So the workaround below is still needed. This effectively reverts commit 63ff3044 ("drm/i915: Nuke the VLV/CHV PFI programming power domain workaround"). Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101517Suggested-by:
Gabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170628210605.4994-1-krisman@collabora.co.ukReviewed-by:
-
- 28 Jun, 2017 3 commits
-
-
Chris Wilson authored
Once a client has requested a waitboost, we keep that waitboost active until all clients are no longer waiting. This is because we don't distinguish which waiter deserves the boost. However, with the advent of fence signaling, the signaler threads appear as waiters to the RPS interrupt handler. So instead of using a single boolean to track when to keep the waitboost active, use a counter of all outstanding waitboosted requests. At this point, I have removed all vestiges of the rate limiting on clients. Whilst this means that compositors should remain more fluid, it also means that boosts are more prevalent. See commit b29c19b6 ("drm/i915: Boost RPS frequency for CPU stalls") for a longer discussion on the pros and cons of both approaches. A drawback of this implementation is that it requires constant request submission to keep the waitboost trimmed (as it is now cancelled when the request is completed). This will be fine for a busy system, but near idle the boosts may be kept for longer than desired (effectively tens of vblanks worstcase) and there is a reliance on rc6 instead. v2: Remove defunct rps.client_lock Reported-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
-
Chris Wilson authored
i915_gem_suspend() is called from all of our finalization paths (suspend, hibernate, unload). i915_gem_drain_freed_objects() adds an arbitrary delay as it uses an rcu_barrier() to ensure that there are no more freed objects in flight, and this delay causes a large amount of variability in suspend timings. For S3 suspend, we do not need to free pages as doing so does not impact at all upon the system in its suspended state, unlike S4 hibernation where we do want the hibernation image to be as small as possible. Therefore we can forgo waiting inside i915_gem_suspend(), so long as we ensure that we do cleanup before unload (see i915_gem_load_cleanup()) and prefer to reap our objects prior to hibernation (see i915_gem_freeze()). Removing the rcu_barrier() from i915_gem_suspend() improves S3 latency by about 30ms on Skylake (ymmv). Reported-by:
David Weinehall <david.weinehall@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
Due to the slight asynchronicity in handling the execlists interrupts (i.e. we defer the work to a handler that may consume more than one interrupt event), when the engine is idle we may still have an irq tasklet queued (especially when it has been deferred to a ksoftirqd). At the beginning of the tasklet, we assert that we do hold a device wakeref for the access we are about to perform. This assumes that when we idle and release the GT wakeref, all execlists work has been completed (since the elsp tracking says the hw is idle). However, there may still be a tasklet queued, so as we mark the engine idle, also cancel any pending tasklet. Signed-off-by:
-
- 27 Jun, 2017 5 commits
-
-
Christophe JAILLET authored
'dma_buf_vmap' returns NULL on error, not an error pointer. Fixes: 6cca22ed ("drm/i915: Add some mock tests for dmabuf interop") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: http://patchwork.freedesktop.org/patch/msgid/20170627053854.21152-1-christophe.jaillet@wanadoo.frReviewed-by:
-
Chris Wilson authored
Smatch spots: drivers/gpu/drm/i915/selftests/intel_hangcheck.c:669 igt_render_engine_reset_fallback() error: double unlock 'mutex:&i915->drm.struct_mutex' Signed-off-by:
Michel Thierry <michel.thierry@intel.com>
-
Ville Syrjälä authored
We have pretty clear evidence that MSIs are getting lost on g4x and somehow the interrupt logic doesn't seem to recover from that state even if we try hard to clear the IIR. Disabling IER around the normal IIR clearing in the irq handler isn't sufficient to avoid this, so the problem really seems to be further up the interrupt chain. This should guarantee that there's always an edge if any IIR bits are set after the interrupt handler is done, which should normally guarantee that the CPU interrupt is generated. That approach seems to work perfectly on VLV/CHV, but apparently not on g4x. MSI is documented to be broken on 965gm at least. The chipset spec says MSI is defeatured because interrupts can be delayed or lost, which fits well with what we're seeing on g4x. Previously we've already disabled GMBUS interrupts on g4x because somehow GMBUS manages to raise legacy interrupts even when MSI is enabled. Since there's such widespread MSI breakahge all over in the pre-gen5 land let's just give up on MSI on these platforms. Seqno reporting might be negatively affected by this since the legcy interrupts aren't guaranteed to be ordered with the seqno writes, whereas MSI interrupts may be? But an occasioanlly missed seqno seems like a small price to pay for generally working interrupts. Cc: stable@vger.kernel.org Cc: Diego Viola <diego.viola@gmail.com> Tested-by:
Diego Viola <diego.viola@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261Signed-off-by:
-
Manasi Navare authored
Now the VBT.seq->t11_t12 value adds 100ms to both Gen9_LP as well as non Gen9_LP cases so no need to special case and do -1 during HW readout and +1 during pp_div write for Gen9_LP/CNP case. Reviewed-by:
-
Manasi Navare authored
When we read the VBT t11_t12 value for panel power cycle delay, it is a zero based value so we need to 100ms to that. And then it needs to be multiplied by 10 to store it in 100usecs unit same as SW VBT. v3: * Add it as part of series v2: * Change the VBT value instead of HW readout and pp div (Ville Syrjala) Reviewed-by:
-
- 23 Jun, 2017 4 commits
-
-
Chris Wilson authored
Trying to do a modeset from within a reset is fraught with danger. We can fall into a cyclic deadlock where the modeset is waiting on a previous modeset that is waiting on a request, and since the GPU hung that request completion is waiting on the reset. As modesetting doesn't allow its locks to be broken and restarted, or for its *own* reset mechanism to take over the display, we have to do something very evil instead. If we detect that we are stuck waiting to prepare the display reset (by using a very simple timeout), resort to cancelling all in-flight requests and throwing the user data into /dev/null, which is marginally better than the driver locking up and keeping that data to itself. This is not a fix; this is just a workaround that unbreaks machines until we can resolve the deadlock in a way that doesn't lose data! v2: Move the retirement from set-wegded to the i915_reset() error path, after which we no longer any delayed worker cleanup for i915_handle_error() v3: C abuse for syntactic sugar v4: Cover all waits with the timeout to catch more driver breakage References: https://bugs.freedesktop.org/show_bug.cgi?id=99093Signed-off-by:
-
Puthikorn Voravootivat authored
This patch adds option to enable dynamic backlight for eDP panel that supports this feature via DPCD register and set minimum / maximum brightness to 0% and 100% of the normal brightness. Signed-off-by:
Puthikorn Voravootivat <puthik@chromium.org> Reviewed-by:
-
Puthikorn Voravootivat authored
Add heuristic to decide that AUX or PWM pin should use for backlight brightness adjustment and modify i915 param description to have auto, force disable, and force enable. The heuristic to determine that using AUX pin is better than using PWM pin is that the panel support any of the feature list here. - Regional backlight brightness adjustment - Backlight PWM frequency set - More than 8 bits resolution of brightness level - Backlight enablement via AUX and not by BL_ENABLE pin Signed-off-by:
-
Puthikorn Voravootivat authored
Read desired PWM frequency from panel vbt and calculate the value for divider in DPCD address 0x724 and 0x728 to have as many bits as possible for PWM duty cyle for granularity of brightness adjustment while the frequency divisor is still within 25% of the desired value. Signed-off-by:
-
- 22 Jun, 2017 5 commits
-
-
Ville Syrjälä authored
Make the code less confusiong by always using the top 9 bits of the LPC bridge device ID to detect the PCH type. We need to add a bit of new code for WPT, and we need to adjust the KBP ID as well. All the other pre-CNP IDs are fine as is. The virtualization cases I think are fine. These P2X and P3X IDs actually just look like the old PIIX4 and PIIX3 IDs to me. Not sure why they're not called PIIX3/4 though. The qemu one has a comment saying the full ID is 0x2918 which is fine with 9 bits. v2: Keep the CNP ID as 0xa300 (DK) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Write the '!(SNB||IVB)' checks in the CPT/PPT detections as '!SNB && !IVB' to make it less messy looking, and clear out some useless parens the from the virtualization PCH detection case. Signed-off-by:
-
Ville Syrjälä authored
For our purposes PPT is equivalent to CPT, and WPT is equivalent to LPT. Document that fact. Signed-off-by:
-
Ville Syrjälä authored
Fix a typo in the PCH type debug message. Signed-off-by:
-
Ville Syrjälä authored
We have a few cases comparing pch_type directly. Let's just replace them with HAS_PCH_CPT() since CPT/PPT is what they're looking for. Signed-off-by:
-
