- 27 Aug, 2019 4 commits
-
-
Chris Wilson authored
The point of debug_object_activate is to mark the first, and only the first, acquisition. The object then remains active until the last release. However, we marked up all successful first acquires even though we allowed concurrent parties to try and acquire the i915_active simultaneously (serialised by the i915_active.mutex). Testcase: igt/gem_mmap_gtt/fault-concurrent Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190827132631.18627-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we create a new live_context() we should have a mapping for each engine. Document that assumption with an assertion. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Chris Wilson authored
The intention is that we first try to pin the current vma into the mappable aperture only if it is already in use or it fits in the free space and will not cause contention. The first attempt was meant to be using PIN_NOEVICT to reuse the current vma if possible, following up with different eviction strategies. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111485 Fixes: 6846895f ("drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT") Signed-off-by:
-
Chris Wilson authored
To properly handle asynchronous migration of batch objects, we need to couple the fences on the incoming batch into the request and should not assume that they always start idle. Signed-off-by:
-
- 26 Aug, 2019 1 commit
-
-
Lyude Paul authored
Currently, we don't call dma_set_max_seg_size() for i915 because we intentionally do not limit the segment length that the device supports. However, this results in a warning being emitted if we try to map anything larger than SZ_64K on a kernel with CONFIG_DMA_API_DEBUG_SG enabled: [ 7.751926] DMA-API: i915 0000:00:02.0: mapping sg segment longer than device claims to support [len=98304] [max=65536] [ 7.751934] WARNING: CPU: 5 PID: 474 at kernel/dma/debug.c:1220 debug_dma_map_sg+0x20f/0x340 This was originally brought up on https://bugs.freedesktop.org/show_bug.cgi?id=108517 , and the consensus there was it wasn't really useful to set a limit (and that dma-debug isn't really all that useful for i915 in the first place). Unfortunately though, CONFIG_DMA_API_DEBUG_SG is enabled in the debug configs for various distro kernels. Since a WARN_ON() will disable automatic problem reporting (and cause any CI with said option enabled to start complaining), we really should just fix the problem. Note that as me and Chris Wilson discussed, the other solution for this would be to make DMA-API not make such assumptions when a driver hasn't explicitly set a maximum segment size. But, taking a look at the commit which originally introduced this behavior, commit 78c47830 ("dma-debug: check scatterlist segments"), there is an explicit mention of this assumption and how it applies to devices with no segment size: Conversely, devices which are less limited than the rather conservative defaults, or indeed have no limitations at all (e.g. GPUs with their own internal MMU), should be encouraged to set appropriate dma_parms, as they may get more efficient DMA mapping performance out of it. So unless there's any concerns (I'm open to discussion!), let's just follow suite and call dma_set_max_seg_size() with UINT_MAX as our limit to silence any warnings. Changes since v3: * Drop patch for enabling CONFIG_DMA_API_DEBUG_SG in CI. It looks like just turning it on causes the kernel to spit out bogus WARN_ONs() during some igt tests which would otherwise require teaching igt to disable the various DMA-API debugging options causing this. This is too much work to be worth it, since DMA-API debugging is useless for us. So, we'll just settle with this single patch to squelch WARN_ONs() during driver load for users that have CONFIG_DMA_API_DEBUG_SG turned on for some reason. * Move dma_set_max_seg_size() call into i915_driver_hw_probe() - Chris Wilson Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
-
- 24 Aug, 2019 2 commits
-
-
Xiaolin Zhang authored
vgpu ppgtt notification was split into 2 steps, the first step is to update PVINFO's pdp register and then write PVINFO's g2v_notify register with action code to tirgger ppgtt notification to GVT side. currently these steps were not atomic operations due to no any protection, so it is easy to enter race condition state during the MTBF, stress and IGT test to cause GPU hang. the solution is to add a lock to make vgpu ppgtt notication as atomic operation. Cc: stable@vger.kernel.org Signed-off-by:
Xiaolin Zhang <xiaolin.zhang@intel.com> Acked-by:
-
Chris Wilson authored
Avoid having to pass around (ctx, engine) everywhere by passing the actual intel_context we intend to use. Today we preach this lesson to igt_gpu_fill_dw and its callers' callers. The immediate benefit for the GEM selftests is that we aim to use the GEM context as the control, the source of the engines on which to test the GEM context. Signed-off-by:
-
- 23 Aug, 2019 23 commits
-
-
Chris Wilson authored
Ensure that the drm_i915_file_private continues to exist as we attempt to remove a request from its list, which may race with the destruction of the file. <6> [38.380714] [IGT] gem_ctx_create: starting subtest basic-files <0> [42.201329] BUG: spinlock bad magic on CPU#0, kworker/u16:0/7 <4> [42.201356] general protection fault: 0000 [#1] PREEMPT SMP PTI <4> [42.201371] CPU: 0 PID: 7 Comm: kworker/u16:0 Tainted: G U 5.3.0-rc5-CI-Patchwork_14169+ #1 <4> [42.201391] Hardware name: Dell Inc. OptiPlex 745 /0GW726, BIOS 2.3.1 05/21/2007 <4> [42.201594] Workqueue: i915 retire_work_handler [i915] <4> [42.201614] RIP: 0010:spin_dump+0x5a/0x90 <4> [42.201625] Code: 00 48 8d 88 c0 06 00 00 48 c7 c7 00 71 09 82 e8 35 ef 00 00 48 85 db 44 8b 4d 08 41 b8 ff ff ff ff 48 c7 c1 0b cd 0f 82 74 0e <44> 8b 83 e0 04 00 00 48 8d 8b c0 06 00 00 8b 55 04 48 89 ee 48 c7 <4> [42.201660] RSP: 0018:ffffc9000004bd80 EFLAGS: 00010202 <4> [42.201673] RAX: 0000000000000031 RBX: 6b6b6b6b6b6b6b6b RCX: ffffffff820fcd0b <4> [42.201688] RDX: 0000000000000000 RSI: ffff88803de266f8 RDI: 00000000ffffffff <4> [42.201703] RBP: ffff888038381ff8 R08: 00000000ffffffff R09: 000000006b6b6b6b <4> [42.201718] R10: 0000000041cb0b89 R11: 646162206b636f6c R12: ffff88802a618500 <4> [42.201733] R13: ffff88802b32c288 R14: ffff888038381ff8 R15: ffff88802b32c250 <4> [42.201748] FS: 0000000000000000(0000) GS:ffff88803de00000(0000) knlGS:0000000000000000 <4> [42.201765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [42.201778] CR2: 00007f2cefc6d180 CR3: 00000000381ee000 CR4: 00000000000006f0 <4> [42.201793] Call Trace: <4> [42.201805] do_raw_spin_lock+0x66/0xb0 <4> [42.201898] i915_request_retire+0x548/0x7c0 [i915] <4> [42.201989] retire_requests+0x4d/0x60 [i915] <4> [42.202078] i915_retire_requests+0x144/0x2e0 [i915] <4> [42.202169] retire_work_handler+0x10/0x40 [i915] Recently, in commit 44c22f3f ("drm/i915: Serialize insertion into the file->mm.request_list"), we fixed a race on insertion. Now, it appears we also have a race with destruction! Signed-off-by:
-
Daniele Ceraolo Spurio authored
First uc firmware release for EHL. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
Stuart Summers <stuart.summers@intel.com> Tested-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Chris Wilson authored
Our fence management is lazy, very lazy. If the user marks an object as untiled, we do not immediately flush the fence but merely mark it as dirty. On the next use we have to remember to check and remove the fence, by which time we hope it is idle and we do not have to wait. v2: Throw away the old fence on the next ggtt_pin. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111468 Fixes: 1f7fd484 ("drm/i915: Replace i915_vma_put_fence()") Signed-off-by:
-
Chris Wilson authored
In order for the Braswell top-level PD to remain the same from the time of request construction to its submission onto HW, as we may be asynchronously rewriting the page tables (thus changing the expected register state after having already stored the old addresses in the request), the top level PD must be preallocated. So wave goodbye to our lazy allocation of those 4x2 pages. v2: A little bit of write-flushing required (presumably it always has been required, but now we are more susceptible and it is showing up!) v3: Put back the forced-PD-reload on every batch, we can't survive without it and explicitly marking the context for PD reload makes Braswell turn nasty. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823141421.2398-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Sadly lockdep records when the irqs are re-enabled and then marks up the fake lock as being irq-unsafe. Our hand is forced and so we must mark up the entire fake lock critical section as irq-off. Hopefully this is the last tweak required! v2: Not quite, we need to mark the timeline spinlock as irqsafe. That was a genuine bug being hidden by the earlier lockdep splat. Fixes: d6773926 ("drm/i915/gt: Mark up the nested engine-pm timeline lock as irqsafe") Signed-off-by:
-
Ville Syrjälä authored
Use hweight8() instead of hweight32() for 8bit masks. Doesn't actually matter for us since the arch code will go for hweight32() anyway, but maybe we stil want to do this for documentation purposes? Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190821173033.24123-5-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Set a good example and talk about pipes rather than crtcs. Signed-off-by:
-
Ville Syrjälä authored
Replace all "int pipe"s with "enum pipe pipe"s to make it clear what we're dealing with. Signed-off-by:
-
Ville Syrjälä authored
The "pipe" argument passed in by the vblank code is in fact the crtc index. Don't assume that is the same as the pipe. Signed-off-by:
-
Ville Syrjälä authored
We may need to eliminate the crtc->index == pipe assumptions from the code to support arbitrary pipes being fused off. Start that by switching some bitmasks over to using pipe instead of the crtc index. Signed-off-by:
-
Stuart Summers authored
Currently, the subslice_mask runtime parameter is stored as an array of subslices per slice. Expand the subslice mask array to better match what is presented to userspace through the I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is then calculated: slice * subslice stride + subslice index / 8 v2: Fix 32-bit build v3: Use new helper function in SSEU workaround warning message v4: Use GEM_BUG_ON to force developers to use valid SSEU configurations per platform (Chris) Signed-off-by: -
Stuart Summers authored
Add a new function to copy subslices for a specified slice between intel_sseu structures for the purpose of determining power-gate status. Note that currently ss_stride has a max of 1. Signed-off-by:
-
Stuart Summers authored
Refactor instdone loops to use the new intel_sseu_has_subslice function. Signed-off-by:
-
Stuart Summers authored
Add a new function to determine whether a particular slice has a given subslice. Signed-off-by:
-
Stuart Summers authored
Add a subslice stride calculation when setting subslices. This aligns more closely with the userspace expectation of the subslice mask structure. v2: Use local variable for subslice_mask on HSW and clean up a few other subslice_mask local variable changes v3: Add GEM_BUG_ON for ss_stride to prevent array overflow (Chris) Split main set function and refactors in intel_device_info.c into separate patches (Chris) v4: Reduce ss_stride size check when setting subslices per slice based on actual expected max stride (Chris) Move that GEM_BUG_ON check for the ss_stride out to the patch which adds the ss_stride v5: Use memcpy instead of looping through each stride index Signed-off-by: -
Stuart Summers authored
Add a new function to set a set of subslices for a given slice. v2: Fix typo in subslice_mask assignment Signed-off-by:
-
Stuart Summers authored
When setting up subslice_mask, instead of operating on the slice array directly, use a local variable to start bits per slice, then use this to set the per slice array in one step. Signed-off-by:
-
Stuart Summers authored
Add a new SSEU runtime parameter, eu_stride, which is used to mirror the userspace concept of a range of EUs per subslice. This patch simply adds the parameter and updates usage in the QUERY_TOPOLOGY_INFO handler. v2: Add GEM_BUG_ON to make sure eu_stride is valid Signed-off-by:
-
Stuart Summers authored
Add a new parameter, ss_stride, to the runtime info structure. This is used to mirror the userspace concept of subslice stride, which is a range of subslices per slice. This patch simply adds the definition and updates usage in the QUERY_TOPOLOGY_INFO handler. v2: Add GEM_BUG_ON to make sure ss_stride is valid Signed-off-by:
-
Stuart Summers authored
Add a new function to allow each platform to set maximum slice, subslice, and EU information to reduce code duplication. Signed-off-by:
-
Stuart Summers authored
Use a local variable to find SSEU runtime information in various debugfs functions. v2: Remove extra line breaks per feedback from Chris Signed-off-by:
-
Michel Thierry authored
HCP/MFX power gating is disabled by default, turn it on for the vd units available. User space will also issue a MI_FORCE_WAKEUP properly to wake up proper subwell. During driver load, init_clock_gating happens after device_info_init_mmio read the vdbox disable fuse register, so only present vd units will have these enabled. BSpec: 14214 HSDES: 1209977827 Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Tony Ye <tony.ye@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823082055.5992-3-lucas.demarchi@intel.com
-
Michel Thierry authored
GAM registers located in the 0x4xxx range have been relocated to 0xCxxx; this is to make space for global MOCS registers. v2: Rename register and bitfield to its new name (suggested by Mika) HSD: 399379 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
- 22 Aug, 2019 10 commits
-
-
Manasi Navare authored
This patch fixes the intel_configure_pps_for_dsc_encoder() function to use cpu_transcoder instead of encoder->type to select the correct DSC registers that was wrongly used in the original patch for one DSC register isntance. Fixes: 7182414e ("drm/i915/dp: Configure i915 Picture parameter Set registers during DSC enabling") Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190821215950.24223-1-manasi.d.navare@intel.com
-
Anusha Srivatsa authored
DSC engine on ICL supports only 8 and 10 BPC as the input BPC. But DSC engine in TGL supports 8, 10 and 12 BPC. Add 12 BPC support for DSC while calculating compression configuration. v2: Remove the separate define TGL_DP_DSC_MAX_SUPPORTED_BPC and use the value directly.(More such defines can be removed as part of future patches). (Ville) v3: Use values directly instead of accessing the defines everytime for min and max DSC BPC. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
-
José Roberto de Souza authored
No need to unmask PSR interrutpion if PSR is not enabled, better move the call to intel_psr_enable_source(). v2: Renamed intel_psr_irq_control() to psr_irq_control() (Lucas) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
José Roberto de Souza authored
According to PSR2_CTL definition in BSpec there is only one instance of PSR2_CTL. Platforms gen < 12 with EDP transcoder only support PSR2 on TRANSCODER_EDP while on TGL PSR2 is only supported by TRANSCODER_A. Since BDW PSR is allowed on any port, but we need to restrict by transcoder. v8: Renamed _psr2_supported_in_trans() to psr2_supported() (Lucas) v9: Renamed psr2_supported() to transcoder_has_psr2() (Ville) BSpec: 7713 BSpec: 20584 Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190820223325.27490-2-jose.souza@intel.com
-
José Roberto de Souza authored
PSR registers are a mess, some have the full address while others just have the additional offset from psr_mmio_base. For BDW+ psr_mmio_base is nothing more than TRANSCODER_EDP_OFFSET + 0x800 and using it makes more difficult for people with an PSR register address or PSR register name from from BSpec as i915 also don't match the BSpec names. For HSW psr_mmio_base is _DDI_BUF_CTL_A + 0x800 and PSR registers are only available in DDIA. Other reason to make relative to transcoder is that since BDW every transcoder have PSR registers, so in theory it should be possible to have PSR enabled in a non-eDP transcoder. So for BDW+ we can use _TRANS2() to get the register offset of any PSR register in any transcoder while for HSW we have _HSW_PSR_ADJ that will calculate the register offset for the single PSR instance, noting that we are already guarded about trying to enable PSR in other port than DDIA on HSW by the 'if (dig_port->base.port != PORT_A)' in intel_psr_compute_config(), this check should only be valid for HSW and will be changed in future. PSR2 registers and PSR_EVENT was added after Haswell so that is why _PSR_ADJ() is not used in some macros. The only registers that can not be relative to transcoder are PSR_IMR and PSR_IIR that are not relative to anything, so keeping it hardcoded. That changed for TGL but it will be handled in another patch. Also removing BDW_EDP_PSR_BASE from GVT because it is not used as it is the only PSR register that GVT have. v5: - Macros changed to be more explicit about HSW (Dhinakaran) - Squashed with the patch that added the tran parameter to the macros (Dhinakaran) v6: - Checking for interruption errors after module reload in the transcoder that will be used (Dhinakaran) - Using lowercase to the registers offsets v7: - Removing IS_HASWELL() from registers macros(Jani) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Chris Wilson authored
You have to cut it off at the neck, otherwise it just reappears in the next merge, like it did in commit 3f866026f0ce ("Merge drm/drm-next into drm-intel-next-queued") References: 3f866026f0ce ("Merge drm/drm-next into drm-intel-next-queued") Signed-off-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190822065917.18988-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Avoid calling i915_vma_put_fence() by using our alternate paths that bind a secondary vma avoiding the original fenced vma. For the few instances where we need to release the fence (i.e. on binding when the GGTT range becomes invalid), replace the put_fence with a revoke_fence. Signed-off-by:
-
Chris Wilson authored
Since we want to revoke the ggtt vma from only under the ggtt->mutex, we need to move protection of the userfault tracking from the struct_mutex to the ggtt->mutex. Signed-off-by:
-
Chris Wilson authored
We can reduce the locking for fence registers from the dev->struct_mutex to a local mutex. We could introduce a mutex for the sole purpose of tracking the fence acquisition, except there is a little bit of overlap with the fault tracking, so use the i915_ggtt.mutex as it covers both. Signed-off-by:
-
