- 30 Aug, 2019 13 commits
-
-
Chris Wilson authored
With the upcoming change in timing (dramatically reducing the latency between manipulating the ppGTT and execution), no amount of tweaking could save Baytrail, it would always fail to invalidate its TLB. Ville was right, Baytrail is beyond hope. v2: Rollback on all gen7; same timing instability on TLB invalidation. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190830180000.24608-1-chris@chris-wilson.co.uk
-
Lucas De Marchi authored
Use a single function to setup the SDE irq and make MCC, ICP and TGP use it, just like was done for the irq handler. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190829211526.30525-4-jose.souza@intel.comSigned-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
Lucas De Marchi authored
Ice Lake, Tiger Lake and Elkhart Lake all have different port configurations and all of them can be parameterized the same way to form the SDE hotplug bitmask. Avoid making them a special case an just use the parameterized macros. Signed-off-by:
-
Lucas De Marchi authored
The differences are only on the pins, trigger and long_detect function. The MCC handling is already partially merged, so merge TGP as well. Remove the pins argument from icp_irq_handler() so we have all the differences between the 3 set in a common if ladder. Signed-off-by:
-
Lucas De Marchi authored
South, follow the north. Instead of defining separate macros for each port, make them take port as parameter as done for TC ports and for north engine. This will allow us to easily extend this as needed. tgp_ddi_port_hotplug_long_detect() is also removed as after the EHL introduction the tgp variant is an exact copy of icp. Signed-off-by:
-
Joonas Lahtinen authored
Indent GuC/WOPCM documentation correctly to reside under "Memory Management and Command Submission" section to avoid it escaping to the upper level navigation. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
-
Joonas Lahtinen authored
The referenced documentation section has been removed. Remove the link to avoid warning when building the documentation. Signed-off-by:
-
Ramalingam C authored
>From Gen12 onwards, HDCP HW block is implemented within transcoders. Till Gen11 HDCP HW block was part of DDI. Hence required changes in HW programming is handled here. As ME FW needs the transcoder detail on which HDCP is enabled on Gen12+ platform, we are populating the detail in hdcp_port_data. v2: _MMIO_TRANS is used [Lucas and Daniel] platform check is moved into the caller [Lucas] v3: platform check is moved into a macro [Shashank] v4: Few optimizations in the coding [Shashank] v5: Fixed alignment in macro definition in i915_reg.h [Shashank] unused variables "reg" is removed. v6: Configuring the transcoder at compute_config. transcoder is used instead of pipe in macros. Rebased. v7: transcoder is cached at intel_hdcp hdcp_port_data is configured with transcoder index asper ME FW. v8: s/trans/cpu_transcoder s/tc/cpu_transcoder v9: rep_ctl is prepared for TCD too. return moved into deault of rep_ctl prepare function [Shashank] Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Shashank Sharma <shashank.sharma@intel.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190828164216.405-7-ramalingam.c@intel.com
-
Ramalingam C authored
On gen12+ platforms, HDCP HW is associated to the transcoder. Hence on every modeset update associated transcoder into the intel_hdcp of the port. v2: s/trans/cpu_transcoder [Jani] v3: comment is added for fw_ddi init for gen12+ [Shashank] only hdcp capable transcoder is translated into fw_tc [Shashank] v4: fw_tc initialization is kept for modeset. [Tomas] few extra doc is added at port_data init [Tomas] v5: Few comments are improvised [Tomas] Signed-off-by:
-
Ramalingam C authored
For gen12+ platform we need to pass the transcoder info as part of the port info into ME FW. This change fills the payload for ME FW from hdcp_port_data. v2: Doc is enhanced for physical_port and attached_transcoder [Tomas] Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Ramalingam C authored
I915 needs to send the index of the transcoder as per ME FW. To support this, define enum mei_fw_tc and add as a member into the struct hdcp_port_data. v2: Typo in commit msg is fixed [Shashank] v3: kdoc is added for mei_fw_tc [Tomas] s/MEI_TC_x/MEI_TRANSCODER_x Signed-off-by:
-
Ramalingam C authored
We dont need the definition of the enum port outside I915, anymore. Hence move enum port definition into I915 driver itself. v2: intel_display.h is included in intel_hdcp.h v3: enum port is declared in headers. v4: commit msg is rephrased. v5: copyright year is updated [Tomas] Signed-off-by:
-
Ramalingam C authored
I915 converts it's port value into ddi index defiend by ME FW and pass it as a member of hdcp_port_data structure. Hence expose the enum mei_fw_ddi to I915 through i915_mei_interface.h. v2: Copyright years are bumped [Tomas] Signed-off-by:
-
- 29 Aug, 2019 8 commits
-
-
Chris Wilson authored
The addition of the DC_FLUSH failed to ensure sanctity of the post-sync write as CI immediately got a completion CS-event before the breadcrumb was coherent. So let's try the other idea of moving the post-sync write into the CS_STALL. References: https://bugs.freedesktop.org/show_bug.cgi?id=111514 References: e8f6b495 ("drm/i915/execlists: Flush the post-sync breadcrumb write harder") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190829081150.10271-2-chris@chris-wilson.co.uk
-
Manasi Navare authored
Create a new function intel_commit_modeset_disables() consistent with the naming in drm atomic helpers and similar to the enable function. This helps better organize the disable sequence in atomic_commit_tail() No functional change v4: * Do not create a function pointer, just a function (Maarten) v3: * Rebase (Manasi) v2: * Create a helper for old_crtc_state disables (Lucas) Suggested-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> 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/20190828224701.422-1-manasi.d.navare@intel.com
-
Manasi Navare authored
This patch has no functional changes. This just renames the update_crtcs() hooks to commit_modeset_enables() to match the drm_atomic helper naming conventions. v2: * Rebase on drm-tip Suggested-by:
-
Matthew Auld authored
The sg_table for our backing store might contain addresses from stolen-memory or in the future local-memory, at which point this is no longer a dma-iterator. As a consequence we should now break on NULL iter.sgp, instead of dmap == 0 which is considered an invalid dma address. As a bonus, gcc much prefers this construct, Function old new delta gen8_ggtt_insert_entries 211 192 -19 gen6_ggtt_insert_entries 292 262 -30 i915_error_object_create 996 954 -42 Signed-off-by:
-
Fernando Pacheco authored
During normal driver unload we attempt to disable GuC communication while it is currently stopped. This results in a nop'd call to intel_guc_ct_disable within guc_disable_communication because stop/disable rely on the same flag to prevent further comms with CT. We can avoid the call to disable and still leave communication in a satisfactory state by extracting a set of shared steps from stop/disable. This set can include guc_disable_interrupts as we do not require the single caller of guc_stop_communication to be atomic: "drm/i915/selftests: Fixup atomic reset checking". This situation (stop -> disable) only occurs during intel_uc_fini_hw, so during fini, call guc_disable_communication only if currently enabled. The symmetric calls to enable/disable remain unmodified for all other scenarios. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110943Signed-off-by:
Fernando Pacheco <fernando.pacheco@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Chris Wilson authored
Let the scheduler have a breather in between passes of the longer buddy tests. Important if we are running under kasan etc and this takes far longer than usual! Signed-off-by:
-
José Roberto de Souza authored
According to BSpc if link standby is set on TGL+, PSR will not be enabled. Vendors should not use panels that requires link standby and even if they do, panel should assert a PSR error that will cause PSR to be disabled. BSpec: 50434 Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823082055.5992-8-lucas.demarchi@intel.com
-
Dhinakaran Pandiyan authored
Yf tiling was removed in gen-12, so do not expose Yf modifiers to user space. Gen-12 display also is incompatible with pre-gen12 Y-tiled CCS, so do not expose I915_FORMAT_MOD_Y_TILED_CCS. v2: Rebase to carry forward recently added gen11 formats. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 28 Aug, 2019 8 commits
-
-
Madhumitha Tolakanahalli Pradeep authored
DSC was not supported on Pipe A for previous platforms. Tigerlake onwards, all the pipes support DSC. Hence, the DSC and FEC restriction on Pipe A needs to be removed. v2: Changes in the logic around removing the restriction around Pipe A (Manasi, Lucas) Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Reviewed-by:
-
Chris Wilson authored
Trust our own workers to not cause unnecessary delays and disable the automatic timeout on their asynchronous fence waits. (Along the same lines that we trust our own requests to complete eventually, if necessary by force.) Signed-off-by:
-
Imre Deak authored
There is a difference in BSpec's and the driver's designation of DDI ports. BSpec uses the following names: - before GEN11: BSpec/driver: port A/B/C/D etc - GEN11: BSpec/driver: port A-F - GEN12: BSpec: port A/B/C for combo PHY ports port TC1-6 for Type C PHY ports driver: port A-I. The driver's port D name matches BSpec's TC1 port name. So far power domains were named according to the BSpec designation, to make it easier to match the code against the specification. That however can be confusing when a power domain needs to be matched to a port on GEN12+. To resolve that use the driver's port A-I designation for power domain names too and rename the corresponding power wells so that they reflect the mapping from the driver's to BSpec's port name. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823100711.27833-1-imre.deak@intel.com
-
Chris Wilson authored
We've been ignoring similar coherency issues in IGT for Broadwater, and specifically Broadwater (original gen4) and not, for example, Crestline (same generation as Broadwater, but the mobile variant). Without any means to reproduce locally (I have a 965GM but alas no 965G), fixing will be slow, so tell CI to ignore any failure until we are ready with a fix. Signed-off-by:
-
Mika Kuoppala authored
Our current avoidance of non readable mcr range was not inclusive enough. Extend the start and end. References: HSDES#1405586840 Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Chris Wilson authored
Quite rarely we see that the CS completion event fires before the breadcrumb is coherent, which presumably is a result of the CS_STALL not waiting for the post-sync operation. Try throwing in a DC_FLUSH into the following pipecontrol to see if that makes any difference. Signed-off-by:
-
Chris Wilson authored
igt_ctx_exec allocates a new context for each iteration, keeping them all allocated until the end. Instead, release the local ctx reference at the end of each iteration, allowing ourselves to reap those if under mempressure. Signed-off-by:
-
Chris Wilson authored
Upon object creation for live_gem_contexts, we fill the object with known scratch and flush it out of the CPU cache. Before performing the GPU fill, we don't need to flush it again and so avoid serialising with previous fills. However, we do need some throttling on the internal interfaces if we do not want to run out of memory! Signed-off-by:
-
- 27 Aug, 2019 11 commits
-
-
Daniele Ceraolo Spurio authored
The CS pre-parser can pre-fetch commands across memory sync points and starting from gen12 it is able to pre-fetch across BB_START and BB_END boundaries as well, so when we emit gpu relocs the pre-parser might fetch the target location of the reloc before the memory write lands. The parser can't pre-fetch across the ctx switch, so we use a separate context to guarantee that the memory is synchronized before the parser can get to it. Note that there is no risk of the CS doing a lite restore from the reloc context to the user context, even if the two have the same hw_id, because since gen11 the CS also checks the LRCA when deciding if it can lite-restore. v2: limit new context to gen12+, release in eb_destroy, add a comment in emit_fini_breadcrumb (Chris). Suggested-by: -
Michel Thierry authored
Compared to Icelake, Tigerlake's MAX_CONTEXT_HW_ID is smaller by one, but since we just use the upper 32 bits of the lrc_desc, it's guaranteed OA will use the correct one. Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823082055.5992-19-lucas.demarchi@intel.com
-
Michel Thierry authored
Workaround no longer needed (plus L3_LRA_1_GPGPU doesn't exist). Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823082055.5992-17-lucas.demarchi@intel.com
-
José Roberto de Souza authored
On TGL some registers moved from DDI to transcoder and the DisplayPort training sequence has a separate BSpec page. I started adding 'ifs' to the original intel_ddi_pre_enable_dp() but it was becoming really hard to follow, so a new and cleaner function for TGL was added with comments of all steps. It's similar to ICL, but different enough to deserve a new function. The rest of DisplayPort enable and the whole disable sequences remained the same. v2: FEC and DSC should be enabled on sink side before start link training(Maarten reported and Manasi confirmed the DSC part) v3: Add call to enable FEC on step 7.l(Manasi) BSpec: 49190 Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
José Roberto de Souza authored
Disable CRTC/pipes in reverse order because some features (MST in TGL+) requires master and slave relationship between pipes, so it should always pick the lowest pipe as master as it will be enabled first and disable in the reverse order so the master will be the last one to be disabled. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823082055.5992-13-lucas.demarchi@intel.com
-
José Roberto de Souza authored
Same as for_each_oldnew_intel_crtc_in_state() but iterates in reverse order. v2: Fix additional blank line v3: Rebase Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
José Roberto de Souza authored
TGL PSR2 HW supports a bigger resolution, so lets add it BSpec: 50422, 49199 Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
José Roberto de Souza authored
This fix unclaimed access warnings: [ 245.525788] ------------[ cut here ]------------ [ 245.525884] Unclaimed read from register 0x62900 [ 245.526154] WARNING: CPU: 0 PID: 1234 at drivers/gpu/drm/i915/intel_uncore.c:1100 __unclaimed_reg_debug+0x40/0x50 [i915] [ 245.526160] Modules linked in: i915 x86_pkg_temp_thermal ax88179_178a coretemp usbnet crct10dif_pclmul mii crc32_pclmul ghash_clmulni_intel e1000e [last unloaded: i915] [ 245.526191] CPU: 0 PID: 1234 Comm: kms_fullmodeset Not tainted 5.1.0-rc6+ #915 [ 245.526197] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWR1.D00.2081.A10.1904182155 04/18/2019 [ 245.526273] RIP: 0010:__unclaimed_reg_debug+0x40/0x50 [i915] [ 245.526281] Code: 74 05 5b 5d 41 5c c3 45 84 e4 48 c7 c0 76 97 21 a0 48 c7 c6 6c 97 21 a0 89 ea 48 0f 44 f0 48 c7 c7 7f 97 21 a0 e8 4f 1e fe e0 <0f> 0b 83 2d 6f d9 1c 00 01 5b 5d 41 5c c3 66 90 41 57 41 56 41 55 [ 245.526288] RSP: 0018:ffffc900006bf7d8 EFLAGS: 00010086 [ 245.526297] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 245.526304] RDX: 0000000000000007 RSI: 0000000000000000 RDI: 00000000ffffffff [ 245.526310] RBP: 0000000000061900 R08: 0000000000000000 R09: 0000000000000001 [ 245.526317] R10: 0000000000000006 R11: 0000000000000000 R12: 0000000000000001 [ 245.526324] R13: 0000000000000000 R14: ffff8882914f0d58 R15: 0000000000000206 [ 245.526332] FS: 00007fed2a3c39c0(0000) GS:ffff8882a8600000(0000) knlGS:0000000000000000 [ 245.526340] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 245.526347] CR2: 00007fed28dff000 CR3: 00000002a086c006 CR4: 0000000000760ef0 [ 245.526354] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 245.526361] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 245.526367] PKRU: 55555554 [ 245.526373] Call Trace: [ 245.526454] gen11_fwtable_read32+0x219/0x250 [i915] [ 245.526576] intel_psr_activate+0x57/0x400 [i915] [ 245.526697] intel_psr_enable_locked+0x367/0x4b0 [i915] [ 245.526828] intel_psr_enable+0xa4/0xd0 [i915] [ 245.526946] intel_enable_ddi+0x127/0x2f0 [i915] [ 245.527075] intel_encoders_enable.isra.79+0x62/0x90 [i915] [ 245.527202] haswell_crtc_enable+0x2a2/0x850 [i915] [ 245.527337] intel_update_crtc+0x51/0x360 [i915] [ 245.527466] skl_update_crtcs+0x26c/0x300 [i915] [ 245.527603] intel_atomic_commit_tail+0x3e5/0x13c0 [i915] [ 245.527757] intel_atomic_commit+0x24d/0x2d0 [i915] [ 245.527782] drm_atomic_helper_set_config+0x7b/0x90 [ 245.527799] drm_mode_setcrtc+0x1b4/0x6f0 [ 245.527856] ? drm_mode_getcrtc+0x180/0x180 [ 245.527867] drm_ioctl_kernel+0xad/0xf0 [ 245.527886] drm_ioctl+0x2f4/0x3b0 [ 245.527902] ? drm_mode_getcrtc+0x180/0x180 [ 245.527935] ? rcu_read_lock_sched_held+0x6f/0x80 [ 245.527956] do_vfs_ioctl+0xa0/0x6d0 [ 245.527970] ? __task_pid_nr_ns+0xb6/0x200 [ 245.527991] ksys_ioctl+0x35/0x70 [ 245.528009] __x64_sys_ioctl+0x11/0x20 [ 245.528020] do_syscall_64+0x55/0x180 [ 245.528034] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 245.528042] RIP: 0033:0x7fed2cc7c3c7 [ 245.528050] Code: 00 00 90 48 8b 05 c9 3a 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 99 3a 0d 00 f7 d8 64 89 01 48 [ 245.528057] RSP: 002b:00007ffe36944378 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 245.528067] RAX: ffffffffffffffda RBX: 00007ffe369443b0 RCX: 00007fed2cc7c3c7 [ 245.528074] RDX: 00007ffe369443b0 RSI: 00000000c06864a2 RDI: 0000000000000003 [ 245.528081] RBP: 00007ffe369443b0 R08: 0000000000000000 R09: 0000564c0173ae98 [ 245.528088] R10: 0000564c0173aeb8 R11: 0000000000000246 R12: 00000000c06864a2 [ 245.528095] R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 [ 245.528128] irq event stamp: 140866 [ 245.528138] hardirqs last enabled at (140865): [<ffffffff819a63dc>] _raw_spin_unlock_irqrestore+0x4c/0x60 [ 245.528148] hardirqs last disabled at (140866): [<ffffffff819a624d>] _raw_spin_lock_irqsave+0xd/0x50 [ 245.528158] softirqs last enabled at (140860): [<ffffffff81c0038c>] __do_softirq+0x38c/0x499 [ 245.528170] softirqs last disabled at (140853): [<ffffffff810b4a09>] irq_exit+0xa9/0xc0 [ 245.528247] WARNING: CPU: 0 PID: 1234 at drivers/gpu/drm/i915/intel_uncore.c:1100 __unclaimed_reg_debug+0x40/0x50 [i915] [ 245.528254] ---[ end trace 366069676e98a410 ]--- Signed-off-by:
-
José Roberto de Souza authored
On TGL+ it's possible to have PSR1 enabled in other ports besides DDIA. PSR2 is still limited to DDIA. However currently we handle only one instance of PSR struct. Lets guard intel_psr_init_dpcd() against multiple eDP panels and warn about it. v2: Reword commit message to be TGL+ only and with the info where PSR1/PSR2 are supported (Lucas) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Chris Wilson authored
A virtual engine itself does not have a batch pool, but we can gleefully use any of its siblings instead. Signed-off-by:
-
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:
-
