- 07 Oct, 2015 13 commits
-
-
Jani Nikula authored
Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Appease gcc and remove the unused variable.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Signed-off-by:
-
Akash Goel authored
Note that in Bspec you have to dig around in a section called "Timestamp bases" and Bspec update request is filed. Signed-off-by:
Ankitprasad Sharma <ankitprasad.r.sharma@intel.com> Signed-off-by:
Akash Goel <akash.goel@intel.com> Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> [danvet: Add note about state of Bspec.] Signed-off-by:
-
Chris Wilson authored
Passing cliprects into the kernel for it to re-execute the batch buffer with different CMD_DRAWRECT died out long ago. As DRI1 support has been removed from the kernel, we can now simply reject any execbuf trying to use this "feature". To keep Daniel happy with the prospect of being able to reuse these fields in the next decade, continue to ensure that current userspace is not passing garbage in through the dead fields. v2: Fix the cliprects_ptr check Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
-
Chris Wilson authored
Exclude active GPU pages from the purview of the background shrinker (kswapd), as these cause uncontrollable GPU stalls. Given that the shrinker is rerun until the freelists are satisfied, we should have opportunity in subsequent passes to recover the pages once idle. If the machine does run out of memory entirely, we have the forced idling in the oom-notifier as a means of releasing all the pages we can before an oom is prematurely executed. Note that this relies upon an up-front retire_requests to keep the inactive list in shape, which was added in a previous patch, mostly as execlist ctx pinning band-aids. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> [danvet: Add note about retire_requests.] Signed-off-by:
-
Chris Wilson authored
With UMS gone, we no longer use it during suspend. And with the last user removed from the shrinker, we can remove the dead code. Signed-off-by:
-
Chris Wilson authored
We can forgo an evict-everything here as the shrinker operation itself will unbind any vma as required. If we explicitly idle the GPU through a switch to the default context, we not only create a request in an illegal context (e.g. whilst shrinking during execbuf with a request already allocated), but switching to the default context will not free up the memory backing the active contexts - unless in the unlikely situation that context had already been closed (and just kept arrive by being the current context). The saving is near zero and the danger real. To compensate for the loss of the forced retire, add a couple of retire-requests to i915_gem_shirnk() - this should help free up any transitive cache from the requests. Note that the second retire_requests is for the benefit of the hand-rolled execlist ctx active tracking: We need to manually kick requests to get those unpinned again. Once that's fixed we can try to remove this again. Signed-off-by:
-
Chris Wilson authored
Often it is very useful to know why we suddenly purge vast tracts of memory and surprisingly up until now we didn't even have a tracepoint for when we shrink our memory. Note that there are slab_start/end tracepoints already, but those don't cover the internal recursion when we directly call into our shrinker code. Hence a separate tracepoint seems justified. Also note that we don't really need a separate tracepoint for the actual amount of pages freed since we already have an unbind tracpoint for that. Signed-off-by:
-
Libin Yang authored
Add the item of i915_component.h in DocBook and add the DOC for i915_component.h. Explain the struct i915_audio_component_ops and struct i915_audio_component_audio_ops usage. Signed-off-by:
Libin Yang <libin.yang@intel.com> Signed-off-by:
-
Libin Yang authored
Add the kerneldoc for i915_audio_component in i915_component.h Signed-off-by:
-
Daniel Vetter authored
Pull in the i915/hda changes for N/CTS setting so I can apply the follow-up documentation work for drm/i915. Some conflicts because ofc we had to rework i915 while that N/CTS work was going on. But not more than adjacent changes really. Signed-off-by:Daniel Vetter <daniel.vetter@intel.com>
-
Chris Wilson authored
As the shrinker_control now passes us unsigned long targets, update our shrinker functions to match. Signed-off-by:
-
Daniel Vetter authored
I've botched this, so let's fix it. Botched in commit eb0b44ad Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 18 14:47:59 2015 +0100 drm/i915: kerneldoc for i915_gem_shrinker.c v2: Be a good citizen^Wmaintainer and add the proper commit citation. Noticed by Jani. Reviewed-by:
-
- 06 Oct, 2015 14 commits
-
-
Chris Wilson authored
Whilst discussing possible ways to trigger an invalidate_range on a userptr with an aliased GGTT mmapping (and so cause a struct_mutex deadlock), the conclusion is that we can, and we must, prevent any possible deadlock by avoiding taking the mutex at all during invalidate_range. This has numerous advantages all of which stem from avoid the sleeping function from inside the unknown context. In particular, it simplifies the invalidate_range because we no longer have to juggle the spinlock/mutex and can just hold the spinlock for the entire walk. To compensate, we have to make get_pages a bit more complicated in order to serialise with a pending cancel_userptr worker. As we hold the struct_mutex, we have no choice but to return EAGAIN and hope that the worker is then flushed before we retry after reacquiring the struct_mutex. The important caveat is that the invalidate_range itself is no longer synchronous. There exists a small but definite period in time in which the old PTE's page remain accessible via the GPU. Note however that the physical pages themselves are not invalidated by the mmu_notifier, just the CPU view of the address space. The impact should be limited to a delay in pages being flushed, rather than a possibility of writing to the wrong pages. The only race condition that this worsens is remapping an userptr active on the GPU where fresh work may still reference the old pages due to struct_mutex contention. Given that userspace is racing with the GPU, it is fair to say that the results are undefined. v2: Only queue (and importantly only take one refcnt) the worker once. Signed-off-by:
-
Chris Wilson authored
Michał Winiarski found a really evil way to trigger a struct_mutex deadlock with userptr. He found that if he allocated a userptr bo and then GTT mmaped another bo, or even itself, at the same address as the userptr using MAP_FIXED, he could then cause a deadlock any time we then had to invalidate the GTT mmappings (so at will). Tvrtko then found by repeatedly allocating GTT mmappings he could alias with an old userptr mmap and also trigger the deadlock. To counter act the deadlock, we make the observation that we only need to take the struct_mutex if the object has any pages to revoke, and that before userspace can alias with the userptr address space, it must have invalidated the userptr->pages. Thus if we can check for those pages outside of the struct_mutex, we can avoid the deadlock. To do so we introduce a separate flag for userptr objects that we can inspect from the mmu-notifier underneath its spinlock. The patch makes one eye-catching change. That is the removal serial=0 after detecting a to-be-freed object inside the invalidate walker. I felt setting serial=0 was a questionable pessimisation: it denies us the chance to reuse the current iterator for the next loop (before it is freed) and being explicit makes the reader question the validity of the locking (since the object-free race could occur elsewhere). The serialisation of the iterator is through the spinlock, if the object is freed before the next loop then the notifier.serial will be incremented and we start the walk from the beginning as we detect the invalid cache. To try and tame the error paths and interactions with the userptr->active flag, we have to do a fair amount of rearranging of get_pages_userptr(). v2: Grammar fixes v3: Reorder set-active so that it is only set when obj->pages is set (and so needs cancellation). Only the order of setting obj->pages and the active-flag is crucial. Calling gup after invalidate-range begin means the userptr sees the new set of backing storage (and so will not need to invalidate its new pages), but we have to be careful not to set the active-flag prior to successfully establishing obj->pages. v4: Take the active->flag early so we know in the mmu-notifier when we have to cancel a pending gup-worker. v5: Rearrange the error path so that is not so convoluted v6: Set pinned to 0 when negative before calling release_pages() Reported-by:
Michał Winiarski <michal.winiarski@intel.com> Testcase: igt/gem_userptr_blits/map-fixed* Signed-off-by:
-
Chris Wilson authored
The userptr worker allows for a slight race condition where upon there may two or more threads calling get_user_pages for the same object. When we have the array of pages, then we serialise the update of the object. However, the worker should only overwrite the obj->userptr.work pointer if and only if it is the active one. Currently we clear it for a secondary worker with the effect that we may rarely force a second lookup. v2: Rebase and rename a variable to avoid 80cols v3: Mention v2 Signed-off-by:
-
Michel Thierry authored
We tried to fix this in commit fdc454c1 ("drm/i915: Prevent out of range pt in gen6_for_each_pde"). But the static analyzer still complains that, just before we break due to "iter < I915_PDES", we do "pt = (pd)->page_table[iter]" with an iter value that is bigger than I915_PDES. Of course, this isn't really a problem since no one uses pt outside the macro. Still, every single new usage of the macro will create a new issue for us to mark as a false positive. Also, Paulo re-started the discussion a while ago [1], but didn't end up implemented. In order to "solve" this "problem", this patch takes the ideas from Chris and Dave, but that check would change the desired behavior of the code, because the object (for example pdp->page_directory[iter]) can be null during init/alloc, and C would take this as false, breaking the for loop immediately. This has been already verified with "static analysis tools". [1]http://lists.freedesktop.org/archives/intel-gfx/2015-June/068548.html v2: Make it a single statement, while preventing the common subexpression elimination (Chris) Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Prevent leaking VMAs and PPGTT VMs when objects are imported via flink. Scenario is that any VMAs created by the importer will be left dangling after the importer exits, or destroys the PPGTT context with which they are associated. This is caused by object destruction not running when the importer closes the buffer object handle due the reference held by the exporter. This also leaks the VM since the VMA has a reference on it. In practice these leaks can be observed by stopping and starting the X server on a kernel with fbcon compiled in. Every time X server exits another VMA will be leaked against the fbcon's frame buffer object. Also on systems where flink buffer sharing is used extensively, like Android, this leak has even more serious consequences. This version is takes a general approach from the earlier work by Rafael Barbalho (drm/i915: Clean-up PPGTT on context destruction) and tries to incorporate the subsequent discussion between Chris Wilson and Daniel Vetter. v2: Removed immediate cleanup on object retire - it was causing a recursive VMA unbind via i915_gem_object_wait_rendering. And it is in fact not even needed since by definition context cleanup worker runs only after the last context reference has been dropped, hence all VMAs against the VM belonging to the context are already on the inactive list. v3: Previous version could deadlock since VMA unbind waits on any rendering on an object to complete. Objects can be busy in a different VM which would mean that the cleanup loop would do the wait with the struct mutex held. This is an even simpler approach where we just unbind VMAs without waiting since we know all VMAs belonging to this VM are idle, and there is nothing in flight, at the point context destructor runs. v4: Double underscore prefix for __915_vma_unbind_no_wait and a commit message typo fix. (Michel Thierry) Note that this is just a partial/interim fix since we have a bit a fundamental issue with cleaning up, e.g. https://bugs.freedesktop.org/show_bug.cgi?id=87729Signed-off-by:
-
kbuild test robot authored
Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Reviewed-by:
-
Ander Conselvan de Oliveira authored
The link training functions had confusing names. The start function actually does the clock recovery phase of the link training, and the complete function does the channel equalization. So call them that instead. Also, every call to intel_dp_start_link_train() was followed by a call to intel_dp_complete_link_train(), so add a new start function that calls clock_recory and channel_equalization. Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by:
-
Sonika Jindal authored
This patch adds a separate probe function for HDMI EDID read over DDC channel. This function has been registered as a .hot_plug handler for HDMI encoder. The current implementation of hdmi_detect() function re-sets the cached HDMI edid (in connector->detect_edid) in every detect call.This function gets called many times, sometimes directly from userspace probes, forcing drivers to read EDID every detect function call.This causes several problems like: 1. Race conditions in multiple hot_plug / unplug cases, between interrupts bottom halves and userspace detections. 2. Many Un-necessary EDID reads for single hotplug/unplug 3. HDMI complaince failures which expects only one EDID read per hotplug This function will be serving the purpose of really reading the EDID by really probing the DDC channel, and updating the cached EDID. The plan is to: 1. i915 IRQ handler bottom half function already calls intel_encoder->hotplug() function. Adding This probe function which will read the EDID only in case of a hotplug / unplug. 2. During init_connector this probe will be called to read the edid 3. Reuse the cached EDID in hdmi_detect() function. The "< gen7" check is there because this was tested only for >=gen7 platforms. For older platforms the hotplug/reading edid path remains same. v2: Calling set_edid instead of hdmi_probe during init. Also, for platforms having DDI, intel_encoder for DP and HDMI is same (taken from intel_dig_port), so for DP also, hot_plug function gets called which is not intended here. So, check for HDMI in intel_hdmi_probe Rely on HPD for updating edid only for platforms gen > 8 and also for VLV. v3: Dropping the gen < 8 || !VLV check. Now all platforms should rely on hotplug or init for updating the edid.(Daniel) Also, calling hdmi_probe in init instead of set_edid v4: Renaming intel_hdmi_probe to intel_hdmi_hot_plug. Also calling this hotplug handler from intel_hpd_init to take care of init resume scenarios. v5: Moved the call to encoder hotplug during init to separate patch(Daniel) Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
Sonika Jindal <sonika.jindal@intel.com> [danvet: Mark intel_hdmi_hot_plug as static.] Signed-off-by:
-
Jordan Justen authored
This is required to support glDispatchComputeIndirect for gen7. Signed-off-by:
Jordan Justen <jordan.l.justen@intel.com> Reviewed-by:
Kristian Høgsberg <krh@bitplanet.net> Signed-off-by:
-
Sagar Arun Kamble authored
When using RC6 timeout mode, the timeout value should be written to GEN6_RC6_THRESHOLD. v2: Updated commit message. (Tom) v3: Rebase over whitespace differences. (Daniel) Cc: Tom O'Rourke <Tom.O'Rourke@intel.com> Signed-off-by:
Tom O'Rourke <Tom.O'Rourke@intel.com> Signed-off-by:
-
Alex Dai authored
Add host2guc interface to notify GuC power state changes when enter or resume from power saving state. v3: Move intel_guc_suspend to i915_drm_suspend for consistency. v2: Add GuC suspend/resume to runtime suspend/resume too v1: Change to a more flexible way when fill host to GuC scratch data in order to remove hard coding. Signed-off-by:
Alex Dai <yu.dai@intel.com> Reviewed-by:
-
Ville Syrjälä authored
The BIOS can leave the CHV display PHY in some odd state where some of the LDOs/lanes won't power down fully when unused. This will trigger a host of asserts that were added in: 30142273 drm/i915: Add CHV PHY LDO power sanity checks 6669e39f drm/i915: Add some CHV DPIO lane power state asserts To avoid that, skip the asserts until the PHY power well has been disabled at least once. That will fully reset the PHY, and once brought back up, the dynamic power down features will work correctly. Signed-off-by:
-
Ville Syrjälä authored
The docs are unclear as usual, so it's not clear whether LRC should be bypassed, performed normally or GRC code should be used as the LRC code. Some old docs stated that LRC bypass ought to be used, more recent ones no longer say that. Some docs indicated that we could use GRC as the LRC code on CHV, but the BIOS doesn't do that, so let's not do it either. Besides to enable LRC bypass properly, I believe we should set the bit already before deasserting cmnreset. Signed-off-by:
-
Sonika Jindal authored
For all the encoders, call the hot_plug if it is registered. This is required for connected boot and resume cases to generate fake hpd resulting in reading of edid. Removing the initial sdvo hot_plug call too so that it will be called just once from this loop. Signed-off-by:
-
- 05 Oct, 2015 1 commit
-
-
Dan Carpenter authored
We need to call intel_runtime_pm_put() and mutex_unlock() before returning. Fixes: 7cb5dff8 ('drm/i915: fix task reference leak in i915_debugfs.c') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Geliang Tang <geliangtang@163.com> Signed-off-by:
-
- 02 Oct, 2015 10 commits
-
-
Sunil Kamath authored
Latest VBT mentions which set of registers will be used for BLC, as controller number field. Making use of this field in BXT BLC implementation. Also, the registers are used in case control pin indicates display DDI. Adding a check for this. According to Bspec, BLC_PWM_*_2 uses the display utility pin for output. To use backlight 2, enable the utility pin with mode = PWM v2: Jani's review comments addressed - Add a prefix _ to BXT BLC registers definitions. - Add "bxt only" comment for u8 controller - Remove control_pin check for DDI controller - Check for valid controller values - Set pipe bits in UTIL_PIN_CTL - Enable/Disable UTIL_PIN_CTL in enable/disable_backlight() - If BLC 2 is used, read active_low_pwm from UTIL_PIN polarity Satheesh's review comment addressed - If UTIL PIN is already enabled, BIOS would have programmed it. No need to disable and enable again. v3: Jani's review comments - add UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK - Disable UTIL_PIN if controller 1 is used - Mask out UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK before enabling UTIL_PIN - check valid controller value in intel_bios.c - add backlight.util_pin_active_low - disable util pin before enabling v4: Change for BXT-PO branch: Stubbed unwanted definition which was existing before because of DC6 patch. UTIL_PIN_MODE_PWM (0x1b << 24) v2: Fixed Jani's review comment. v3: Split the backight PWM frequency programming into separate patch, in cases BIOS doesn't initializes it. v4: Starting afresh and not modifying existing state for backlight, as per Jani's recommendation. v5: Fixed Jani's review comment wrt util pin enable Signed-off-by:Vandana Kannan <vandana.kannan@intel.com> Signed-off-by:
Sunil Kamath <sunil.kamath@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Reviewed-by:
-
Shashank Sharma authored
BXT's DSI PLL is different from that of VLV. So this patch adds a new function to get the current DSI pixel clock based on the PLL divider ratio and lane count. This function is required for intel_dsi_get_config() function. v2: Fixed Jani's review comments. Signed-off-by:
-
Shashank Sharma authored
Pick appropriate port control register (BXT or VLV), based on device. Get the current hw state wrt Mipi port. v2: Rebased on latest drm nightly branch. v3: Removed the GET_DSI_PORT_CTRL Macro for consistency with earlier implementations as per Jani's suggestion. Signed-off-by: -
Shashank Sharma authored
This patch contains changes to support DSI disble sequence in BXT. The changes are: 1. BXT specific changes in clear_device_ready function. 2. BXT specific changes in DSI disable and post-disable functions. 3. Add a new function to reset BXT Dphy clock and dividers (bxt_dsi_reset_clocks). 4. Moved some part of the vlv clock reset code, in a new function (vlv_dsi_reset_clocks) maintaining the exact same sequence. 5. Wrapper function to call corresponding reset clock function. v2: Fixed Jani's review comments. v3: Removed the GET_DSI_PORT_CTRL Macro for consistency with earlier implementations as per Jani's suggestion. Signed-off-by: -
Shashank Sharma authored
BXT DSI clocks are different than previous platforms. So adding a new function to program following clocks and dividers: 1. Program variable divider to generate input to Tx clock divider (Output value must be < 39.5Mhz) 2. Select divide by 2 option to get < 20Mhz for Tx clock 3. Program 8by3 divider to generate Rx clock v2: Fixed Jani's review comments. Adjusted the Macro definition as per convention. Simplified the logic for bit definitions for MIPI PORT A and PORT C in same registers. v3: Refactored the macros for TX, RX Escape and DPHY clocks as per Jani's suggestion. v4: Addressed Jani's review comments. Signed-off-by: -
Shashank Sharma authored
This patch contains following changes: 1. MIPI device ready changes to support dsi_pre_enable. Changes are specific to BXT device ready sequence. Added check for ULPS mode(No effects on VLV). 2. Changes in dsi_enable to pick BXT port control register. 3. Changes in dsi_pre_enable to restrict DPIO programming for VLV v2: Fixed Jani's review comments. Removed the changes in VLV/CHV code. Fixed the macros to get proper port offsets. v3: Rebased on latest drm-nightly branch. Fixed Jani's review comments. Signed-off-by: -
Shashank Sharma authored
SKL and BXT qualifies the HAS_DDI() check, and hence haswell modeset functions are re-used for modeset sequence. But DDI interface doesn't include support for DSI. This patch adds: 1. cases for DSI encoder, in those modeset functions and allows a CRTC modeset 2. Adds call to pre_pll enabled from CRTC modeset function. Nothing needs to be done as such in CRTC for DSI encoder, as PLL, clock and and transcoder programming will be taken care in encoder's pre_enable and pre_pll_enable function. v2: Fixed Jani's review comments. Added INVALID_PORT for non DDI encoder like DSI for platforms having HAS_DDI as true. v3: Rebased on latest drm-nightly branch. Added a WARN_ON for invalid encoder. v4: WARN_ON for invalid encoder is refactored as per Jani's suggestion. Fixed the sequence for pre_pll_enable. v5: Protected DDI code paths in case of DSI encoder calls. Signed-off-by: -
Imre Deak authored
This register was added on GEN4, by the name INSTDONE_1 whereas the GEN6 specification calls it INSTDONE_2. Keep the original name with a platform prefix to make it clearer which INSTDONE register instance this is. Also add a comment about the SNB alternative name. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Imre Deak authored
We have a bunch of INSTDONE registers for different platforms and purposes and it's not immediately clear which instance they are just by looking at the register name. This one was added on GEN2, where it was the only INSTDONE register, so mark it as such. Signed-off-by:
-
Imre Deak authored
We use 3 different names to refer to the same render ring INSTDONE register. This can be confusing when comparing two parts of the code accessing the register via different names. Although the GEN4 version's layout is different, we treat it the same way as the GEN7+ version, in that we simply read it out during error capture. So remove the duplicates and leave a comment about the GEN4 difference. Note that there is also a GEN2 version of this register, but that's on a different address so not handled in this patch. Signed-off-by:
-
- 01 Oct, 2015 2 commits
-
-
Michel Thierry authored
There are some allocations that must be only referenced by 32-bit offsets. To limit the chances of having the first 4GB already full, objects not requiring this workaround use DRM_MM_SEARCH_BELOW/ DRM_MM_CREATE_TOP flags In specific, any resource used with flat/heapless (0x00000000-0xfffff000) General State Heap (GSH) or Instruction State Heap (ISH) must be in a 32-bit range, because the General State Offset and Instruction State Offset are limited to 32-bits. Objects must have EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag to indicate if they can be allocated above the 32-bit address range. To limit the chances of having the first 4GB already full, objects will use DRM_MM_SEARCH_BELOW + DRM_MM_CREATE_TOP flags when possible. The libdrm user of the EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag is here: http://lists.freedesktop.org/archives/intel-gfx/2015-September/075836.html v2: Changed flag logic from neeeds_32b, to supports_48b. v3: Moved 48-bit support flag back to exec_object. (Chris, Daniel) v4: Split pin flags into PIN_ZONE_4G and PIN_HIGH; update PIN_OFFSET_MASK to use last PIN_ defined instead of hard-coded value; use correct limit check in eb_vma_misplaced. (Chris) v5: Don't touch PIN_OFFSET_MASK and update workaround comment (Chris) v6: Apply pin-high for ggtt too (Chris) v7: Handle simultaneous pin-high and pin-mappable end correctly (Akash) Fix check for entries currently using +4GB addresses, use min_t and other polish in object_bind_to_vm (Chris) v8: Commit message updated to point to libdrm patch. v9: vmas are allocated in the correct ozone, so only check flag when the vma has not been allocated. (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v4) Signed-off-by:
-
Sagar Arun Kamble authored
Due to flip interrupts GuC stays awake always and GT does not enter RC6. Do not route those interrupts to GuC for now. Driver won't touch DE_GUCRMR register and leave it as what default value. Signed-off-by:
-
