- 17 Sep, 2019 1 commit
-
-
Chris Wilson authored
If we try to clear, or even set, a bit in the register that doesn't change the register state; skip the write. There's a slight danger in that the register acts as a latch-on-write, but I do not think we use a rmw cycle with any such latch registers. Suggested-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190917080029.27632-1-chris@chris-wilson.co.uk
-
- 16 Sep, 2019 7 commits
-
-
Chris Wilson authored
Include the active context register state when dumping the engine. Suggested-by:
Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190915203701.29163-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
Stop setting ->pipe_mask to zero when display is disabled, allowing us to have different code paths for not actually having display hardware, and having display hardware disabled. This lets us develop those two avenues independently. There are no functional changes for when there is no display. However, all uses of for_each_pipe() and for_each_pipe_masked() will start running for the disabled display case. Put one of the more significant ones behind checks for INTEL_DISPLAY_ENABLED(), otherwise the cases should not be hit with disabled display, or they seem benign. Fingers crossed. All in all, this might not be the ideal solution. In fact we may have had something along the lines of this in the past, but we ended up conflating the two cases. Possibly even by recommendation by yours truly; I did not dare dig up that part of the history. But the perfect is the enemy of the good, this is a straightforward change, and lets us get actual work done in both fronts without interfering with each other. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190916092901.31440-1-jani.nikula@intel.com
-
Ville Syrjälä authored
Clean up the mess with the drm vs. intel types in intel_crtc_atomic_check() and rename varibles accordingly. Reviewed-by:
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/20190913193157.9556-5-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Exfiltrate the cdclk code from intel_modeset_checks() into intel_modeset_calc_cdclk(). Reviewed-by:
-
Ville Syrjälä authored
Bspec says that glk+ max downscale factor is <3.0 for all pixel formats. Older platforms had a max of <2.0 for NV12. Update the code to deal with this. Reviewed-by:
-
Ville Syrjälä authored
There's a helper in drm_fourcc.h these days to check of we're dealing with a two plane YUV format. Make use if it. Also s/plane/color_plane/ in skl_plane_relative_data_rate() to reduce the confusion. Reviewed-by:
-
Jani Nikula authored
Prepare for making a distinction between not having display and having disabled display. Add INTEL_DISPLAY_ENABLED() and use it where HAS_DISPLAY() is used after intel_device_info_runtime_init(). This is initially duplication, as disabling display still leads to ->pipe_mask = 0 and HAS_DISPLAY() being false. Note that ever since i915.display_disable was introduced, it has not affected PCH detection even if it uses HAS_DISPLAY(), as display disable happens after that. Since INTEL_DISPLAY_ENABLED() will not make sense unless HAS_DISPLAY() is true, include a warning for catching misuses making decisions on INTEL_DISPLAY_ENABLED() when HAS_DISPLAY() is false. v2: Remove INTEL_DISPLAY_ENABLED() check from intel_detect_pch() (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Acked-by:
-
- 13 Sep, 2019 8 commits
-
-
Mika Kuoppala authored
We think that we got rc6 problems sorted out. Flip the switch and let CI expose our tendency to naive optimism. Signed-off-by:
-
Michel Thierry authored
The media ranges extend beyond what gen11 gives so we can't piggypack on gen11 ranges, even on read side. Introduce a table for gen12 and accessors for it. v2: correctly implement gen12_fwtable_write/read (Daniele) v3: update with ranges from bspec. v4: avoid GEN11_NEEDS_FORCEWAKE (Mika) v5: bspec ref (Daniele) BSpec: 52078 Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
-
Mika Kuoppala authored
Daniele noticed new render ranges in Gen11 fw table. Bspec: 18331 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Chris Wilson authored
More pruning away of features until we have a stable system and a basis for debugging what's missing. v2: Fixup vdbox/vebox fusing Signed-off-by:
-
Chris Wilson authored
While srcu may use an integer tag, it does not exclude potential error codes and so may overlap with our own use of -EINTR. Use a separate outparam to store the tag, and report the error code separately. Fixes: 2caffbf1 ("drm/i915: Revoke mmaps and prevent access to fence registers across reset") Signed-off-by:
-
Manasi Navare authored
On ICL+, the max supported plane height is 4320, so bump it up To support 4320, we need to increase the number of bits used to read plane_height to 13 as opposed to older 12 bits. v4: * Adjust the width mask also since extra bits are mbz (Ville) v3: * Use 0xffff for mask as extra bits are mbz (Ville) v2: * ICL plane height supported is 4320 (Ville) * Add a new line between max width and max height (Jose) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
-
Manasi Navare authored
On ICL+, the vertical limits for the transcoders are increased to 8192 and horizontal limits are bumped to 16K so bump up limits in intel_mode_valid() v4: * Increase the hdisplay to 16K (Ville) v3: * Supported starting ICL (Ville) * Use the higher limits from TRANS_VTOTAL register (Ville) v2: * Checkpatch warning (Manasi) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
As we remove the struct_mutex protection from around the vma pinning, counters need to be atomic and aware that there may be multiple threads simultaneously active. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190913064200.24297-1-chris@chris-wilson.co.uk
-
- 12 Sep, 2019 13 commits
-
-
Chris Wilson authored
Keep the engine awake to ensure that we don't inject any pm-idle requests. References: https://bugs.freedesktop.org/show_bug.cgi?id=111108Signed-off-by:
-
Arkadiusz Hiler authored
Without it we get: Unclaimed read from register 0x1e1110 WARNING: CPU: 2 PID: 1029 at drivers/gpu/drm/i915/intel_uncore.c:1101 __unclaimed_reg_debug+0x40/0x50 [i915] Call Trace: fwtable_read32+0x233/0x300 [i915] i915_interrupt_info+0xa73/0xd60 [i915] seq_read+0xdb/0x3c0 full_proxy_read+0x51/0x80 vfs_read+0x9e/0x160 ksys_read+0x8f/0xe0 do_syscall_64+0x55/0x1c0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Cc: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109824Signed-off-by:
Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by:
-
Chris Wilson authored
We see failures where the context continues executing past a preemption event, eventually leading to situations where a request has executed before we have event submitted it to HW! It seems like tgl is ignoring our RING_TAIL updates, but more likely is that there is a missing update required for our semaphore waits around preemption. v2: And disable internal semaphore usage Signed-off-by:
-
Chris Wilson authored
As we track when we put the GT device to sleep upon idling, we can use that callback to sample the current rc6 counters and record the timestamp for estimating samples after that point while asleep. v2: Stick to using ktime_t v3: Track user_wakerefs that interfere with the new intel_gt_pm_wait_for_idle v4: No need for parked/unparked estimation if !CONFIG_PM v5: Keep timer park/unpark logic as was v6: Refactor duplicated estimate/update rc6 logic v7: Pull intel_get_pm_get_if_awake() out from the pmu->lock. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105010Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190912124813.19225-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
Replace device info number of pipes with a bit mask of available pipes. This will prove handy in the future. There's still a bunch of future work to do to actually allow a non-consecutive mask of pipes, but it's a start. No functional changes. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Since d0aa694b ("drm/i915/pmu: Always sample an active ringbuffer") the cost of sampling the engine state on execlists platforms became a little bit higher when both engine busyness and one of the wait states are being monitored. (Previously the busyness sampling on legacy platforms was done via seqno comparison so there was no cost of mmio read.) We can avoid that by skipping busyness sampling when engine supports software busy stats and so avoid the cost of potential mmio read and sample accumulation. Signed-off-by:
-
Chris Wilson authored
After we manipulate the context to allow replay after a GPU reset, force that context to be reloaded. This should be a layer of paranoia, for if the GPU was reset, the context will no longer be resident! Signed-off-by:
-
Chris Wilson authored
After a GPU reset, we need to drain all the CS events so that we have an accurate picture of the execlists state at the time of the reset. Be paranoid and force a read of the CSB write pointer from memory. Signed-off-by:
-
Chris Wilson authored
The FBC requires a couple of contiguous buffers, which we allocate from stolen memory. If stolen memory is unavailable, we cannot allocate those buffers and so cannot support FBC. Mark it so. Signed-off-by:
-
Ville Syrjälä authored
Reuse the same .modeset_calc_cdclk() function for all bxt+. The only difference in between the cnl/icl and the bxt variants is the call to cnl_compute_min_voltage_level(). We can do that call just fine on older platforms since they leave min_voltage_level[] zeroed. Let's rename the function to bxt_compute_min_voltage_level() just so it stays consistent with the rest of the naming scheme. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Ville Syrjälä authored
The cnl and icl .modeset_calc_cdclk() functions are identical. Drop one copy. Signed-off-by:
-
Ville Syrjälä authored
We're forgetting to mask off all three pipe select bits from the CDCLK_CTL value on icl+ which may lead to the extra bit being left in. That will cause us to consider the current hardware cdclk state as invalid, and we proceed to sanitize it even though the hardware may have active pipes and whatnot. Fix up the mask so we get rid of all three pipe select bits and thus hopefully no longer sanitize cdclk when it's already correctly programmed. Cc: Matt Roper <matthew.d.roper@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111641 Fixes: 0c1279b5 ("drm/i915: Consolidate {bxt,cnl,icl}_init_cdclk") Signed-off-by:
-
Ville Syrjälä authored
On tgl/bxt/glk the cdclk bypass frequency depends on the PLL reference clock. So let's read out the ref clock before we try to compute the bypass clock. Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: 71dc367e ("drm/i915: Consolidate bxt/cnl/icl cdclk readout") Signed-off-by:
-
- 11 Sep, 2019 11 commits
-
-
Jani Nikula authored
Abstract away direct access to ->num_pipes to allow further refactoring. No functional changes. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
There's no easy way of checking whether iommu is enabled for the GPU (you can grep dmesg if you know the device, or you can grep i915_gpu_info if that's available). We do have a central i915_capabilities with the intent of listing such pertinent information, so add the iommu status. Suggested-by:
Martin Peres <martin.peres@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
The same read-only affliction as befell Icelake is affecting Tigerlake. Disable the read-only support as clearly it was not fixed. Testcase: igt/i915_selftests/live_gem_context References: 3936867d ("drm/i915: Disable read only ppgtt support for gen11") Signed-off-by:
-
Ville Syrjälä authored
i915 doesn't use the crtc_state->plane_changed flag for anything, so setting it is pointless. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
system_unbound_wq can't keep up sometimes and we get dropped frames. Switch to a high priority variant. Reported-by:
Heinrich Fink <heinrich.fink@daqri.com> Tested-by:
-
Chris Wilson authored
Commit 736da811 ("drm/i915: Use literal representation of cdclk tables") pushed the cdclk logic into tables, adding glk_cdclk_table but not using yet: drivers/gpu/drm/i915/display/intel_cdclk.c:1173:38: error: ‘glk_cdclk_table’ defined but not used [-Werror=unused-const-variable=] Fixes: 736da811 ("drm/i915: Use literal representation of cdclk tables") Signed-off-by:
-
Chris Wilson authored
In preparation for reducing struct_mutex stranglehold around the vm, make the vma.flags atomic so that we can acquire a pin on the vma atomically before deciding if we need to take the mutex. Signed-off-by:
-
Kenneth Graunke authored
This allows userspace to use "legacy" mode for push constants, where they are committed at 3DPRIMITIVE or flush time, rather than being committed at 3DSTATE_BINDING_TABLE_POINTERS_XS time. Gen6-8 and Gen11 both use the "legacy" behavior - only Gen9 works in the "new" way. Conflating push constants with binding tables is painful for userspace, we would like to be able to avoid doing so. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Cc: stable@vger.kernel.org Reviewed-by:
-
Chris Wilson authored
Add an atomic counter and always take the spinlock around the pin/unpin events, so that we can perform the list manipulation concurrently. Signed-off-by:
-
Tvrtko Ursulin authored
These notifications operate on intel_gt so make the code take what it needs. Signed-off-by:
-
Tvrtko Ursulin authored
Both in the container_of and getting to gt->awake there is no need to go via i915 since both the wakeref and awake are members of gt. Signed-off-by:
-
