- 14 Sep, 2017 16 commits
-
-
Ville Syrjälä authored
Eliminate the loops from the gen2-3 irq handlers. Since we don't use MSI anymore on these platforms, and thus the CPU interrupt will be level triggered, we shouldn't need to play any tricks with IER to induce edges from IIR. IIR itself still detects only edges from PIPESTAT & co. on gen4 but since IIR is double buffered and we only clear one bit per irq handler invocation we can use the normal "clear PIPESTAT & co. -> clear IIR" approach to ack the interrupts. On gen2 everything is level triggered, and gen3 presumably follows either the gen2 or gen4 approach since nothing else would really make sense. v2: Drop the IER tricks since we no longer use MSI Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-12-ville.syrjala@linux.intel.comReviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
Extract the gen2-4 PIPESTAT irq handling into separate functions just like we already do on VLV/CHV. We can share valleyview_pipestat_irq_ack() on all gmch platforms to actually read and clear the PIPESTAT status bits, so let's rename it to i9xx_pipestat_irq_ack(). Reviewed-by:
-
Ville Syrjälä authored
There should be no way to land in irq_uninstall without a valid dev_priv. Let's kill off the remaining checks, which are probably some kind of UMS leftovers. Not all the irq_uninstall hooks even had them anymore. Reviewed-by:
-
Ville Syrjälä authored
Do the irq_mask/enable_mask setup in the same way on gen3/4, and also reorder the steps to make the code more uniform. Reviewed-by:
-
Ville Syrjälä authored
We've already cleared PORT_HOTPLUG_EN in the .irq_preinstall hook so doing it again in the .irq_postinstall is pointless. Reviewed-by:
-
Ville Syrjälä authored
Unify the appaerance of the gen2-4 irq postinstall hooks a little bit by doing the EMR setup first on all the platforms. Reviewed-by:
-
Ville Syrjälä authored
Unify the appearance of the gen2 irq code with the gen3+ code by introducing the GEN2_IRQ_RESET/INIT macros. Reviewed-by:
-
Ville Syrjälä authored
Replace the manual IMR+IER+IIR write sequences with the appropriate GEN3_IRQ_RESET/INIT macro invocations in gen3/4. Signed-off-by:
-
Ville Syrjälä authored
The GEN5_IRQ_RESET/INIT macros are perfectly suitable even for gen3/4 hardware as those have 32 bit interrupt registers. Let's rename the macros to reflect that fact. Gen2 on the other hand has 16 bit interrupt registers so these macros aren't really appropriate there. v2: Fix patch subject (Maarten) Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
We have a lot of different ways of clearing the PIPESTAT registers. Let's unify it all into one function. There's no magic in PIPESTAT that would require any of the double clearing and whatnot that some of the code tries to do. All we can really do is clear the status bits and disable the enable bits. There is no way to mask anything so as soon as another event happens the status bit will become set again, and trying to clear them twice or something can't protect against that. Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
commit fd3a4024 ("drm/i915: Rip out legacy page_flip completion/irq handling") removed the code to hande the flip done/pending interrupts, but it failed to actually disable/mask those interrupts. Let's do that now. Also remove a stale comment that was left behind. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Zhi Wang authored
Remove the "INDEX" suffix from PPAT marcos as they are bits actually, not indexes. Suggested-by:
Zhi Wang <zhi.a.wang@intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1505392783-4084-2-git-send-email-zhi.a.wang@intel.com
-
Zhi Wang authored
The private PAT management is to support PPAT entry manipulation. Two APIs are introduced for dynamically managing PPAT entries: intel_ppat_get and intel_ppat_put. intel_ppat_get will search for an existing PPAT entry which perfectly matches the required PPAT value. If not, it will try to allocate a new entry if there is any available PPAT indexs, or return a partially matched PPAT entry if there is no available PPAT indexes. intel_ppat_put will put back the PPAT entry which comes from intel_ppat_get. If it's dynamically allocated, the reference count will be decreased. If the reference count turns into zero, the PPAT index is freed again. Besides, another two callbacks are introduced to support the private PAT management framework. One is ppat->update_hw(), which writes the PPAT configurations in ppat->entries into HW. Another one is ppat->match, which will return a score to show how two PPAT values match with each other. v17: - Refine the comparision of score of BDW. (Joonas) v16: - Fix a bug in PPAT match function of BDW. (Joonas) v15: - Refine some code flow. (Joonas) v12: - Fix a problem "not returning the entry of best score". (Zhenyu) v7: - Keep all the register writes unchanged in this patch. (Joonas) v6: - Address all comments from Chris: http://www.spinics.net/lists/intel-gfx/msg136850.html - Address all comments from Joonas: http://www.spinics.net/lists/intel-gfx/msg136845.html v5: - Add check and warnnings for those platforms which don't have PPAT. v3: - Introduce dirty bitmap for PPAT registers. (Chris) - Change the name of the pointer "dev_priv" to "i915". (Chris) - intel_ppat_{get, put} returns/takes a const intel_ppat_entry *. (Chris) v2: - API re-design. (Chris) Signed-off-by:
-
Ville Syrjälä authored
Use the LLC/eLLC hotspot avoidance mode for CCS on LLC machines. This is reported to give better performance. Testing has indicated that we don't need to enforce any massive 2 or 4 MiB alignment for all compressed resources even though there are still plenty of stale comments in the spec suggesting that we do. We do need to make sure every hardware unit that deals with the compressed data uses the same hash mode. Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Daniel Stone <daniels@collabora.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net>
-
Joonas Lahtinen authored
Convert to use the freshly available made INTEL_GEN_MASK for easier grepping and improve function readability and clarify the UABI documentation. No functional changes. v2: - Lift GEM_BUG_ONs and use is_power_of_2 (Chris) - Retain -EINVAL on bad flags behavior (Chris) v3: - Extract flags with 'entry->size - 1' (Chris) v4: - Add GEM_BUG_ON on for flags vs entry offset (Chris) v5: - Use 'u16' to match 'dev_priv' (Ville) v6: - Fix checkpatch.pl errors Signed-off-by:
-
Joonas Lahtinen authored
Split INTEL_GEN_MASK out of IS_GEN macro, and make it usable within static declarations (unlike compound statements). v2: - s/combound/compound/ (Tvrtko) - Fix whitespace (yes, we need automatic checkpatch.pl) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
- 13 Sep, 2017 17 commits
-
-
Rodrigo Vivi authored
DK had pointed out a comment there was hard to understand, so I tried to read back again and I couldn't understand that as well. So let me re-phrase that in a way that anyone can understand later, even myself. Also fixed the comment block style. v2: Accept DK's suggestion on PSR_state 2 and PSR_state 3 named as spec. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170912183059.5086-1-rodrigo.vivi@intel.com
-
Chris Wilson authored
The engine also provides a mirror of the CSB write pointer in the HWSP, but not of our read pointer. To take advantage of this we need to remember where we read up to on the last interrupt and continue off from there. This poses a problem following a reset, as we don't know where the hw will start writing from, and due to the use of power contexts we cannot perform that query during the reset itself. So we continue the current modus operandi of delaying the first read of the context-status read/write pointers until after the first interrupt. With this we should now have eliminated all uncached mmio reads in handling the context-status interrupt, though we still have the uncached mmio writes for submitting new work, and many uncached mmio reads in the global interrupt handler itself. Still a step in the right direction towards reducing our resubmit latency, although it appears lost in the noise! v2: Cannonlake moved the CSB write index v3: Include the sw/hwsp state in debugfs/i915_engine_info v4: Also revert to using CSB mmio for GVT-g v5: Prevent the compiler reloading tail (Mika) Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170913085605.18299-6-chris@chris-wilson.co.ukReviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com>
-
Chris Wilson authored
The engine provides a mirror of the CSB in the HWSP. If we use the cacheable reads from the HWSP, we can shave off a few mmio reads per context-switch interrupt (which are quite frequent!). Just removing a couple of mmio is not enough to actually reduce any latency, but a small reduction in overall cpu usage. Much appreciation for Ben dropping the bombshell that the CSB was in the HWSP and for Michel in digging out the details. v2: Don't be lazy, add the defines for the indices. v3: Include the HWSP in debugfs/i915_engine_info v4: Check for GVT-g, it currently depends on intercepting CSB mmio v5: Fixup GVT-g mmio path v6: Disable HWSP if VT-d is active as the iommu adds unpredictable memory latency. (Mika) v7: Also markup the CSB read with READ_ONCE() as it may still be an mmio read and we want to stop the compiler from issuing a later (v.slow) reload. Suggested-by:
Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by:
-
Chris Wilson authored
At the time of commit 1f767e02 ("drm/i915: HWS must be in the mappable region for g33"), drm_mm insertion would often default to placing a new object high in the zone forcing us to specify that certain HWSP must be bound within the low mappable region. Since then, drm_mm has gained more finesse over its placement and exposes that to the caller, commit 4e64e553 ("drm: Improve drm_mm search (and fix topdown allocation) with rbtrees"). As such where possible we want the HWSP to be outside of the mappable aperture and so need to specify that can be pinned high. Signed-off-by:
-
Daniele Ceraolo Spurio authored
On gen8+ we're currently using the PPHWSP of the kernel ctx as the global HWSP. However, when the kernel ctx gets submitted (e.g. from __intel_autoenable_gt_powersave) the HW will use that page as both HWSP and PPHWSP. This causes a conflict in the register arena of the HWSP, i.e. dword indices below 0x30. We don't current utilize this arena, but in the following patches we will take advantage of the cached register state for handling execlist's context status interrupt. To avoid the conflict, instead of re-using the PPHWSP of the kernel ctx we can allocate a separate page for the HWSP like what happens for pre-execlists platform. v2: Add a use-case for the register arena of the HWSP. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499357440-34688-1-git-send-email-daniele.ceraolospurio@intel.comSigned-off-by:
-
Michel Thierry authored
Using the HWSP ggtt_offset to get the lrca offset is only correct if the HWSP happens to be before it (when we reuse the PPHWSP of the kernel context as the engine HWSP). Instead of making this assumption, get the lrca offset from the kernel_context engine state. And while looking at this part of the GuC interaction, it was also noticed that the firmware expects the size of only the engine context (context minus the execlist part, i.e. don't include the first 80 dwords), so pass the right size. v2: Use the new macros to prevent abusive overuse of the old ones (Chris). Reported-by:
-
Michel Thierry authored
Not only the context image consist of two parts (the PPHWSP, and the logical context state), but we also allocate a header at the start of for sharing data with GuC. Thus every lrc looks like this: | [guc] | [hwsp] [logical state] | |<- our header ->|<- context image ->| So far, we have oversimplified whenever we use each of these parts of the context, just because the GuC header happens to be in page 0, and the (PP)HWSP is in page 1. But this had led to using the same define for more than one meaning (as a page index in the lrc and as 1 page). This patch adds defines for the GuC shared page, the PPHWSP page and the start of the logical state. It also updated the places where the old define was being used. Since we are not changing the size (or format) of the context, there are no functional changes. v2: Use PPHWSP index for hws again. Suggested-by:
-
Chris Wilson authored
As realised by commit 9e3d6223 ("math64, timers: Fix 32bit mul_u64_u32_shr() and friends"), GCC does not always generate ideal code for performing a 32b x 32b multiply returning a 64b result (i.e. where we idiomatically use u64 result = (u64)x * (u32)x). Signed-off-by:
-
Chris Wilson authored
As realised by commit 9e3d6223 ("math64, timers: Fix 32bit mul_u64_u32_shr() and friends"), GCC does not always generate ideal code for performing a 32b x 32b multiply returning a 64b result (i.e. where we idiomatically use u64 result = (u64)x * (u32)x). This catches a couple of instances in the display code using (u64)x * (u32)y. Signed-off-by:
-
Chris Wilson authored
The sgt iterators cause an drivers/gpu/drm/i915/i915_gpu_error.c:846 i915_error_object_create() warn: statement has no effect 7 everywhere they are used. If we change the code slightly, we can achieve the same increment without altering the output or raising a warning. text data bss dec hex filename 1267906 20587 3168 1291661 13b58d before 1267906 20587 3168 1291661 13b58d after Signed-off-by:
-
Oscar Mateo authored
Spare some comments and other small style changes. Suggested-by:
Oscar Mateo <oscar.mateo@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1505252197-27696-3-git-send-email-oscar.mateo@intel.comReviewed-by:
-
Oscar Mateo authored
We never used it in i915 and it's going to be removed in newer GuC firmwares anyway. Signed-off-by:
-
Oscar Mateo authored
The default values for the default scheduling policy come from the GuC firmware itself. Transform the magic numbers into defines. Suggested-by:
-
Chris Wilson authored
The context descriptor is stored inside the per-engine context state, as we only need to compute it once and access it frequently. However, currently only intel_lrc.c has easy access, but i915_guc_submission.c would like to frequently read it as well, and more so only ever needs the lower 32bits. Make it an inline as the compiler should be able to retrieve the value in less instructions than it takes to do the function call: add/remove: 0/1 grow/shrink: 1/0 up/down: 8/-45 (-37) function old new delta i915_guc_submit 621 629 +8 intel_lr_context_descriptor 45 - -45 Signed-off-by:
-
Mika Kahola authored
Error message indicating that the same MIPI command is sent consecutively is perhaps too strongly said. Let's replace that as a debug message instead. Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
Lee, Shawn C authored
Min brightness value from vbt was missing for CNP platform. This setting have to refer backlight ic spec to restrict min backlight output. Without this restriction, driver would allow to configure lower brightness value and violate backlight ic requirement. Fixes: 4c9f7086 ("drm/i915/cnp: Backlight support for CNP.") Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Shawn Lee <shawn.c.lee@intel.com> Signed-off-by:
-
Uma Shankar authored
This reverts commit bbdf0b2f ("drm/i915/bxt: Disable device ready before shutdown command"). Disable device ready before shutdown command was added previously to avoid a split screen issue seen on dual link DSI panels. As of now, dual link is not supported and will need some rework in the upstream code. For single link DSI panels, the change is not required. This will cause failure in sending SHUTDOWN packet during disable. Hence reverting the change. Will handle the change as part of dual link enabling in upstream. Fixes: bbdf0b2f ("drm/i915/bxt: Disable device ready before shutdown command") Cc: <stable@vger.kernel.org> # v4.12+ Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by:
-
- 12 Sep, 2017 7 commits
-
-
Chris Wilson authored
Following the simplification to a single lookup loop in commit 170fa29b ("drm/i915: Simplify eb_lookup_vmas()") and commit d1b48c1e ("drm/i915: Replace execbuf vma ht with an idr"), we can go one step further and reorder the error paths so that the state of the local variable obj is always known to the compiler and doesn't need the uninitialized_var markup to squelch a compiler warning. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Dhinakaran Pandiyan authored
The SDE interrupt bits 25, 26 and 27 are either reserved or meant for DDI E hotplug in SPT+. These bits are meant for AUX channels only in LPT and CPT, so add the appropriate checks. Signed-off-by:
-
Ville Syrjälä authored
Give a name to the bit which tells pcode to control IPS. v2: Note that IPS_CTL bits apply to DISPLAY_IPS_CONTROL as well (Chris) Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Zhi Wang authored
Factor out setup_private_pat() for introducing the following patches. Signed-off-by:
-
Lee, Shawn C authored
Min brightness value from vbt was missing for BXT platform. This setting have to refer backlight ic spec to restrict min backlight output. Without this restriction, driver would allow to configure lower brightness value and violate backlight ic requirement. Fixes: 0fb890c0 ("drm/i915/bxt: BLC implementation") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Gary C Wang <gary.c.wang@intel.com> Signed-off-by:
-
Marta Lofstedt authored
During IGT testing it has been shown that the specification defined polling time of 1 us for FCLK_DONE, is sometimes not enough. The issue is still reproducible while disabling C-states through the PM QoS framework and also while disabling preemtion. From this the most plausible explanation is that the issue is due to a firmware flaw. As a workaround, it is better to wait a little bit longer for the FCLK_DONE to come around, than to leave with an DRM_ERROR and having FCLK_DONE at a randome time after. While spinning a list of igt tests prone to reproduce the issue the FCLK_DONE poll failed at approximately 2% of the invocations of the bdw_set_cdclk function. The longest poll time during this testing was measured to ~7us. So, the suggested new poll time of 100us is on the safe side. v2: Added more documentation about investigations done. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102243Signed-off-by:
Marta Lofstedt <marta.lofstedt@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
