- 05 Jun, 2018 5 commits
-
-
Michal Wajdeczko authored
In function gem_init_hw() we are calling uc_init_hw() but in case of error later in function, we missed to call matching uc_fini_hw() v2: pulled out from the series Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180605122443.23776-1-michal.wajdeczko@intel.com
-
Chris Wilson authored
To spare ourselves a long line later, refactor the repeated check of bind_count vs pin_count to a helper. v2: Fix up the commentary! Suggested-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180605094107.31367-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
In preparation, for having non-vma objects stored inside the ggtt, to handle restoration of the GGTT following resume, we need to walk over the ggtt address space rebinding vma, as opposed to walking over bound objects looking for ggtt entries. v2: Skip objects only bound for the aliasing_ppgtt Signed-off-by:
-
Chris Wilson authored
Currently, we have a special routine for pinning the context state at the start of activity tracking, but lack the complementary unpin routine. Create it to to ease later patches that want to do partial teardown on error, and, not least, to improve the readability of the code. Suggested-by:
-
Changbin Du authored
This adds a new vGPU cap info bit VGT_CAPS_HUGE_GTT, which is to detect whether the host supports shadowing of huge gtt pages. If host does support it, remove the page sizes restriction for vGPU. Signed-off-by:
Changbin Du <changbin.du@intel.com> Reviewed-by:
-
- 04 Jun, 2018 5 commits
-
-
Mahesh Kumar authored
Do not update number of enabled dbuf slices in dev_priv struct until we actually enable/disable dbuf slice in hw. This is leading to never updating dbuf slices and resulting in DBuf slice mismatch warning. Fixes: aa9664ff ("drm/i915/icl: Enable 2nd DBuf slice only when needed") Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by:
-
Lionel Landwerlin authored
One thing we didn't really understand about the OA report is that the ContextID field (dword 2) is copy of the context descriptor (dword 1). On Gen8->10 and without using GuC we didn't notice the issue because we only checked the 21bits of the ContextID field in the OA reports which matches exactly the hw_id stored into the context descriptor. When using GuC submission we have an issue of a non matching hw_id because GuC uses bit 20 of the hw_id to signal proxy submission. This change introduces a mask to compare only the relevant bits. On ICL the context descriptor format has changed and we failed to address this. On top of using a mask we also need to shift the bits properly. v2: Reuse lrc_desc rather than recomputing part of it (Chris/Michel) v3: Always pin the context we're filtering with (Chris) Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 1de401c0 ("drm/i915/perf: enable perf support on ICL") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104252 BSpec: 1237 Testcase: igt/perf/gen8-unprivileged-single-ctx-counters Acked-by:
Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180602112946.30803-3-lionel.g.landwerlin@intel.com Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org
-
Lionel Landwerlin authored
We currently using GuC as a proxy to the hardware. When Guc is used in such mode, it consumes the bit 20 of the hw_id to indicate that the workload was submitted by proxy. So far we probably haven't seen the issue because we need to allocate 1048576+ contexts to hit this issue. Still, we should avoid allocating the hw_id on that bit and restriction to bits [0:19] (i.e 20bits instead of 21). v2: Leave the max hw_id computation in i915_gem_context.c (Michel) v3: Be consistent on if/else usage (Chris) Signed-off-by:
-
Chris Wilson authored
As the ppgtt for execlists is tightly coupled to the executing context, and not switch separately, we no longer use the ppgtt->switch_mm hooks on gen8+. Remove them. References: 79e6770c ("drm/i915: Remove obsolete ringbuffer emission for gen8+") Signed-off-by:
-
Michal Wajdeczko authored
We should keep i915_gem_init/fini functions together for easier tracking of their symmetry. v2: rebased, pulled out from the series Signed-off-by:
-
- 01 Jun, 2018 21 commits
-
-
Arkadiusz Hiler authored
Start using the new registers for ICL and on. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com> Signed-off-by:
-
Manasi Navare authored
PLLs are the source clocks for the DDIs so in order to determine the ddi clock we need to check the PLL configuration. This gets a little tricky for ICL since there is no register bit that maps directly to the link clock. So this patch creates a separate function in intel_dpll_mgr.c to obtain the write array PLL Params and compares the set pll_params with the table to get the corresponding link clock. v2: - Fix the encoder type check (DK). - Improve our error checking, return a sane value (Mika, Paulo). - Fix table entries (Paulo). Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> [Paulo: implement v2] Signed-off-by:
-
Anusha Srivatsa authored
This patch adds the support to detect PCH_ICP. Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Radhakrishna Sripada authored
On ICL we need to map VBT DDC Pin to BSpec DDC Pin. Adding ICL Pin Values. According to VBT Block 2 (General Bytes Definition) DDC Bus +----------+-----------+--------------------+ | DDI Type | VBT Value | BSpec Mapped Value | +----------+-----------+--------------------+ | DDI-A | 0x1 | 0x1 | | DDI-B | 0x2 | 0x2 | | PORT-1 | 0x4 | 0x9 | | PORT-2 | 0x5 | 0xA | | PORT-3 | 0x6 | 0xB | | PORT-4 | 0x7 | 0xC | +----------+-----------+--------------------+ Cc: James Ausmus <james.ausmus@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
James Ausmus <james.ausmus@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> [Paulo: checkpatch fixes.] Signed-off-by:
-
Manasi Navare authored
DFLEXDPMLE register is required to tell the FIA hardware which main links of DP are enabled on TCC Connectors. FIA uses this information to program PHY to Controller signal mapping. This register is applicable in both TC connector's Alternate mode as well as DP connector mode. v2: * Remove _ICL prefix since the reg is first introduced in ICL (Paulo) * s/ICL/icl in commit message (Lucas) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Paulo Zanoni authored
Add and enum for TC ports and auxiliary functions to handle them. Icelake brings a lot of registers and other things that only apply to the TC ports and are indexed starting from 0, so having an enum for tc_ports that starts at 0 really helps the indexing. This patch is based on previous patches written by Dhinakaran Pandiyan and Mahesh Kumar. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by:
-
Dhinakaran Pandiyan authored
ICL has AUX F. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
Mahesh Kumar authored
All connectors may not have best_encoder attached, so don't dereference encoder pointer for each connector. Fixes: c27e917e ("drm/i915/icl: add basic support for the ICL clocks") Reviewed-by:
-
Chris Wilson authored
Let's not take any chances by using a shortcut to mark the objects as in the CPU domain upon freezing (all pages will be written to disk and so on restore all objects will start from the CPU domain). Currently, we simply mark the objects as being in the CPU domain, bypassing the flushes. Let's call the full domain transfer function so that we have less special case code (and symmetry with the suspend path) even though it will be mostly redundant. Signed-off-by:
-
Chris Wilson authored
As we have already suspended the device, this should be a no-op except for marking that all writes are indeed complete. The downside is that we then have to walk all the lists of objects for what should be a no-op (in some cases they will be mmio read to ensure the GGTT writes are indeed flushed, and clflushes to ensure that cpu writes are in memory). It seems prudent and the safer course for us to ensure all writes are flushed to memory before suspend. Signed-off-by:
-
Ville Syrjälä authored
Set up the SKL+ scaler initial phase registers correctly. Otherwise we start fetching the data from the center of the first pixel instead of the top-left corner, which obviously then leads to right/bottom edges replicating data excessively as the data runs out half a pixel too soon. Cc: Vidya Srinivas <vidya.srinivas@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180521185613.5097-2-ville.syrjala@linux.intel.comReviewed-By:
Vidya Srinivas <vidya.srinivas@intel.com>
-
Ville Syrjälä authored
We already handle the color encoding mode properly. Remove the broken NV12 special case. Cc: Vidya Srinivas <vidya.srinivas@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 8ed30ab6 ("drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg") Signed-off-by:
-
Ville Syrjälä authored
The sprite code has a bunch of spaces where tabs should be used. Fix it up. v2: Make the patch subject more specific (Jani) Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Call the enum i9xx_plane_id variable i9xx_plane like we do elsewhere. Cc: Hans de Goede <j.w.r.degoede@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
We disable trickle feed whenever possible, except for the cursors on SNB/IVB. Let's try disabling it there too if for no other reason than consistency. Signed-off-by:
-
Ville Syrjälä authored
Use MCURSOR_ instead of CURSOR_ as the prefix for the non-845/865 cursor defines consistently, and move the pipe CSC enable bit next to the other non-845/865 cursor defines. v2: Take care of gvt uses as well v3: Another gvt use popped up Signed-off-by:
-
Ville Syrjälä authored
Like we do for encoder let's make the plane->get_hw_state() return the pipe to which the plane is currently attached. We don't currently allow planes to move between the pipes, but perhaps one day we will. In either case this makes the code more uniform and perhaps makes intel_plane_mapping_ok() slightly more clear. Note that for i965 and g4x planes A and B still have pipe select bits but they're hardwired to pipe A and B respectively. This means we can safely interpret those bits just like on gen2/3. This allows the same readout code work for plane C (which can still be assigned to eiter pipe on i965) should we ever expose it. g4x no longer allows moving the cursor planes between the pipes, but the pipe select bits can still be set in the register. Thus we have to ignore those bits. OTOH i965 still allows the cursors to move between pipes thus we have to trust the bits there. Signed-off-by:
-
Chris Wilson authored
On resume, we have to rewrite all the PDE entries for gen7 ppgtts. If we switch on full-ppgtt, there is then one address space with no PDE, the GGTT. Currently under aliasing-ppgtt, the GGTT address space does have an associated ppgtt and so the restore works just fine. We would have a similar problem if we tried disabling aliasing-ppgtt (i915.enable_ppgtt=0). So skip the empty ppgtt, as being non-existent it doesn't need restoring. Signed-off-by:
-
Chris Wilson authored
On hsw and older, we do not need to allocate the ppgtt on the fly and so ppgtt->allocate_va_range() is NULL. Fixup ppgtt_bind_vma not to call it, in that case! v2: PIN_UPDATE still exists. Signed-off-by:
-
Chris Wilson authored
As we store the intel_context on the request (rq->hw_context), we can simply compare that against the local intel_context for the i915->kernel_context rather than using the rq->gem_context. Signed-off-by:
-
Chris Wilson authored
Now that we always switch to the kernel context upon idling, we can make that assertion. References: 4dfacb0b ("drm/i915: Switch to kernel context before idling at runtime") Signed-off-by:
-
- 31 May, 2018 6 commits
-
-
Chris Wilson authored
During testing we encounter a conflict between SUSPEND_TEST_DEVICES and disabling reset (gem_eio/suspend). This results in the device continuing on without being reset, but since it has gone through HW sanitization to account for the suspend/resume cycle, we have to assume the device has been reset to its defaults. A simple way around this is to skip the sanitize phase for SUSPEND_TEST_DEVICES by moving it to suspend-late. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180531082246.9763-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
As we reset the GPU on suspend/resume, we also do need to reset the engine state tracking so call into the engine backends. This is especially important so that we can also sanitize the state tracking across resume. References: https://bugs.freedesktop.org/show_bug.cgi?id=106702Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180531082246.9763-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
During suspend we want to flush out all active contexts and their rendering. To do so we queue a request from the kernel's context, once we know that request is done, we know the GPU is completely idle. To speed up that switch bump the GPU clocks. Switching to the kernel context prior to idling is also used to enforce a barrier before changing OA properties, and when evicting active rendering from the global GTT. All cases where we do want to race-to-idle. v2: Limit the boosting to only the switch before suspend. v3: Limit it to the wait-for-idle on suspend. Signed-off-by:
-
Chris Wilson authored
We can reduce our exposure to random neutrinos by resting on the kernel context having flushed out the user contexts to system memory and beyond. The corollary is that we then we require two passes through the idle handler to go to sleep, which on a truly idle system involves an extra pass through the slow and irregular retire work handler. Signed-off-by:
-
Michal Wajdeczko authored
SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and those events are now handled by intel_guc_to_host_event_handler_mmio(). We should not try to read it on MMIO action error as 1) we may be using different set of registers for GuC MMIO communication, and 2) GuC may use CTB mechanism for sending events to host. While here, upgrade error message to DRM_ERROR. Signed-off-by:
-
Maarten Lankhorst authored
Normally this is called on a modeset, but the call is missing when we inherit the mode from the BIOS, so make sure it's called somewhere in hardware readout. Changes since v1: - Unconditionally call intel_opregion_notify_encoder. (Ville) Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180516085038.36785-1-maarten.lankhorst@linux.intel.comReviewed-by:
-
- 30 May, 2018 2 commits
-
-
Rodrigo Vivi authored
Signed-off-by: -
Chris Wilson authored
Since we use i915_gem_find_active_request() from inside intel_engine_dump() and may call that at any time, we do not guarantee that the engine is paused nor that the signal kthreads and irq handler are suspended, so we cannot assert that the breadcrumb doesn't advance and that the irq hasn't happened on another CPU signaling the request we believe to be idle. The second assert removed (that request->engine == engine) remains valid, but is now more rigorously checked during retirement. Fixes: f636edb2 ("drm/i915: Make i915_engine_info pretty printer to standalone") Signed-off-by:
-
- 29 May, 2018 1 commit
-
-
Dhinakaran Pandiyan authored
DPCD 2009h "Synchronization latency in sink" has bits that tell us the maximum number of frames sink can take to resynchronize to source timing when exiting PSR. More importantly, as per eDP 1.4b, this is the "Minimum number of frames following PSR exit that the Source device needs to wait for PSR entry." We currently use this value only to setup the number frames to wait before PSR2 selective update. But, based on the above description it makes more sense to use this to configure idle frames for both PSR1 and and PSR2. This will ensure we wait the required number of frames before activation whether it is PSR1 or PSR2. The minimum number of idle frames remains 6, while allowing sink synchronization latency and VBT to increase this value. This also solves the flip-flop between sink and source frames that I noticed on my Thinkpad X260 during PSR exit. This specific panel has a value of 8h, which according to the spec means the "Source device must wait for more than eight active frames after PSR exit before initiating PSR entry. (In this case, should be provided by the panel supplier.)" VBT however has a value of 0. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jose Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
