- 18 Oct, 2019 13 commits
-
-
Ville Syrjälä authored
Despite the its name dirty_pipes refers to crtc indexes. Let's change its behaviout to match the name. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191011200949.7839-4-ville.syrjala@linux.intel.comReviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
The 'realloc_pipes' bitmask is pointless. It is either: a) the set of pipes which are already part of the state, in which case adding them again is entirely redundant b) the set of all pipes which we then add to the state Also the fact that 'realloc_pipes' uses the crtc indexes is going to bite is at some point so best get rid of it quick. Signed-off-by:
-
Ville Syrjälä authored
changed==true just means we have some crtcs in the state. All the stuff following this only operates on crtcs in the state anyway so there is no point in having this bool. Signed-off-by:
-
Ville Syrjälä authored
The DP port/pipe goes wonky if we try to use timings with hdisplay==4096 on pre-HSW platforms. The link fails to train and the pipe may not signal vblank interrupts. On HDMI such at mode works just fine (tested on ELK/SNB/CHV). So let's refuse such modes on DP on older platforms. Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com>
-
Ville Syrjälä authored
Replace the hand rolled stuff with drm_encoder_mask() when populating possible_clones, and rename the function to intel_encoder_possible_clones() to make it clear what it's used for. Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
Ville Syrjälä authored
Unlike other planes the cursor currently handles 180 degree rotation adjustment during the hardware programming phase. Let's move that stuff into intel_cursor_check_surface() to match how we do things with other plane types. And while at we'll plop in the final src x/y coordinates (which will actually always be zero) into the src rect and color_plane[0].x/y, just for some extra consistency. Signed-off-by:
-
Chris Wilson authored
Use the local gt for iterating over the available set of engines. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191018115331.8980-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Remember to include the newly created mock engine in the list of available engines inside the gt. Fixes: a50134b1 ("drm/i915: Make for_each_engine_masked work on intel_gt") Signed-off-by:
-
Matthew Auld authored
Convert stolen memory over to a region object. Still leaves open the question with what to do with pre-allocated objects... Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Reviewed-by:
-
Matthew Auld authored
Convert shmem to an intel_memory_region. Signed-off-by:
-
Abdiel Janulgue authored
Nothing to enumerate yet... Signed-off-by:
Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
Normally, we try and skip submission if ELSP[1] is filled. However, we may desire to enable timeslicing due to the queue priority, even if ELSP[1] itself does not require timeslicing. That is the queue is equal priority to ELSP[0] and higher priority then ELSP[1]. Previously, we would wait until the context switch to preempt the current ELSP[1], but with timeslicing, we want to preempt ELSP[0] and replace it with the queue. In writing the test case, it become quickly apparent that we were also suppressing the tasklet during promotion and so failing to notice when the queue started requiring timeslicing. Fixes: 2229adc8 ("drm/i915/execlist: Trim immediate timeslice expiry") Signed-off-by:
-
Tvrtko Ursulin authored
If name allocation failed the log message will contain an uninitialized error code which can be confusing. Fixes: 05488673 ("drm/i915/pmu: Support multiple GPUs") Signed-off-by:
-
- 17 Oct, 2019 9 commits
-
-
Tvrtko Ursulin authored
Where the function, or code segment, operates on intel_gt, we need to start passing it instead of i915 to for_each_engine(_masked). This is another partial step in migration of i915->engines[] to gt->engines[]. Signed-off-by:
-
Tvrtko Ursulin authored
Medium term goal is to eliminate the i915->engine[] array and to get there we have recently introduced equivalent array in intel_gt. Now we need to migrate the code further towards this state. This next step is to eliminate usage of i915->engines[] from the for_each_engine_masked iterator. For this to work we also need to use engine->id as index when populating the gt->engine[] array and adjust the default engine set indexing to use engine->legacy_idx instead of assuming gt->engines[] indexing. v2: * Populate gt->engine[] earlier. * Check that we don't duplicate engine->legacy_idx v3: * Work around the initialization order issue between default_engines() and intel_engines_driver_register() which sets engine->legacy_idx for now. It will be fixed properly later. v4: * Merge with forgotten v2.5. Signed-off-by: -
Sebastian Andrzej Siewior authored
The locks (active.lock and rq->lock) need to be taken with disabled interrupts. This is done in i915_request_retire() by disabling the interrupts independently of the locks itself. While local_irq_disable()+spin_lock() equals spin_lock_irq() on vanilla it does not on PREEMPT_RT. Chris Wilson confirmed that local_irq_disable() was just introduced as an optimisation to avoid enabling/disabling interrupts during lock/unlock combo. Enable/disable interrupts as part of the locking instruction. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Chris Wilson authored
The request selftests straddle the boundary between checking the driver and the hardware. They are subject to the quirks of the underlying HW, but operate on top of the backend abstractions. The tests focus on the scheduler elements and so should check for interactions of the scheduler across all exposed engines. Signed-off-by:
-
Daniele Ceraolo Spurio authored
Better explain the usage of the microcontroller and what i915 is responsible of. While at it, fix the documentation for the auth function, which doesn't do any pinning anymore. v2: add a comment on HuC being optional and descrive how HuC accesses memory (Martin) v3: add extra newline for better text organization (Martin) Signed-off-by:Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Martin Peres <martin.peres@linux.intel.com> Acked-by:
Anna Karas <anna.karas@intel.com> Reviewed-by:
Martin Peres <martin.peres@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191014183602.3643-3-daniele.ceraolospurio@intel.com
-
Daniele Ceraolo Spurio authored
Add a short description of what we expect from GuC and some minor improvements to existing documentation. Also remove a comment about a difference between GuC and HuC that is not true anymore. v2: add that the GuC is not mandatory (Martin) v3: add extra newline for better text organization (Martin) Signed-off-by:
-
Daniele Ceraolo Spurio authored
To better organize the information, add a microcontrollers section and move/link the GuC, HuC and DMC documentation under it. Also add a small intro. Signed-off-by:
-
Ville Syrjälä authored
The MSA MISC computation now depends on the connector state, and we do it from the DDI .pre_enable() hook. All that is fine for DP SST but with MST we don't actually pass the connector state to the dig port's .pre_enable() hook which leads to an oops. Need to think more how to solve this in a cleaner fashion, but for now let's just add a NULL check to stop the oopsing. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Fixes: 0c06fa15 ("drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA") Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Reviewed-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
-
Tvrtko Ursulin authored
With discrete graphics system can have both integrated and discrete GPU handled by i915. Currently we use a fixed name ("i915") when registering as the uncore PMU provider which stops working in this case. To fix this we add the PCI device name string to non-integrated devices handled by us. Integrated devices keep the legacy name preserving backward compatibility. v2: * Detect IGP and keep legacy name. (Michal) * Use PCI device name as suffix. (Michal, Chris) v3: * Constify the name. (Chris) * Use pci_domain_nr. (Chris) v4: * Fix kfree_const usage. (Chris) v5: * kfree_const does not work for modules. (Chris) * Changed is_igp helper to take i915. Signed-off-by:
-
- 16 Oct, 2019 16 commits
-
-
Khaled Almahallawy authored
In TGL there we are missing the initialization of port G. Do the same as for other ports. Signed-off-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Chris Wilson authored
The HW performs swizzling as part of its fence tiling inside the Global GTT. We already do the probing of the HW settings from the GGTT setup, complete the picture by storing the information as part of the GGTT. The primary benefit is the consistency of our probe routines do not break the i915_ggtt encapsulation. Signed-off-by:
-
Chris Wilson authored
Now that i915_ggtt knows everything about its own paths to perform mmio, we can use that as our primary backpointer for individual fence registers. This reduces the amount of pointer dancing we have to perform on the common paths, but more importantly finishes our fence register encapsulation. Signed-off-by:
-
Chris Wilson authored
Now that we record the default "goldenstate" context, we do not need to emit the mocs registers at the start of each context and can simply do mmio before the first context and capture the registers as part of its default image. As a consequence, this means that we repeat the mmio after each engine reset, fixing up any platform and registers that were zapped by the reset (for those platforms with global not context-saved settings). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111723 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111645Signed-off-by:
Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191016090749.7092-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
The timelines selftests are [mostly] hardware centric and so want to use the gt as its target. Signed-off-by:
-
Chris Wilson authored
The workarounds selftests are hardware centric and so want to use the gt as its target. Signed-off-by:
-
Chris Wilson authored
The guc selftests are hardware^W firmare centric and so want to use the gt as its target. Signed-off-by:
-
Chris Wilson authored
The execlists selftests are hardware centric and so want to use the gt as its target. Signed-off-by:
-
Matt Roper authored
The Jasper Lake PCH follows ICP/TGP's south display behavior and is identical to MCC graphics-wise except that it does not use the unusual (port C -> TC1) pin mapping that MCC does. Also, it turns out the extra PCH ID that we had previously thought was a form of MCC is actually a second ID for JSP (i.e., port C uses the port C pins instead of the TC1 pins). v2: - Also update the port masks (not just the pin table) in mcc_hpd_irq_setup. (Vivek) v3: - Break jsp_hpd_irq_setup out into its own function for clarity. (Vivek) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: James Ausmus <james.ausmus@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191015162854.30546-1-matthew.d.roper@intel.com
-
Matt Roper authored
Since EHL's MCC PCH reuses one of the TC pins we need to supply a TC long detect function when handling the interrupts. Fixes: 53448aed ("drm/i915/ehl: Port C's hotplug interrupt is associated with TC1 bits") Reported-by:
kbuild test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Prepare the mode readout for the uapi vs. hw state split. We'll want to do all readout into the hw state. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190927131432.15978-4-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Prepare the connector/encoder mask readout for the uapi vs. hw state split. We'll want to do all readout into the hw state. Signed-off-by:
-
Ville Syrjälä authored
Prefer the intel_ types in intel_legacy_cursor_update() over the drm_ types. Should make it easier to adapt this to the uapi vs. hw state split. Signed-off-by:
-
Ville Syrjälä authored
Once we do the hw vs. uapi split we can no longer use drm_atomic_helper_calc_timestamping_constants() as it'll consult the uapi state instead of the hw state. So let's just update the vblank timestamping constants whenever we update the scanline offset. We use both to convert the hw scanline count to something which matches the software timing values. First I thought to put these into intel_crtc_vblank_on() but we may want to get the scanline counter value before that (eg. from some early tracepoints), so let's stick to updating them a bit earlier than intel_crtc_vblank_on(). Signed-off-by:
-
Chris Wilson authored
We perform timeslicing immediately upon receipt of a request that may be put into the second ELSP slot. The idea behind this was that since we didn't install the timer if the second ELSP slot was empty, we would not have any idea of how long ELSP[0] had been running and so giving the newcomer a chance on the GPU was fair. However, this causes us extra busy work that we may be able to avoid if we wait a jiffie for the first timeslice as normal. Signed-off-by:
-
Chris Wilson authored
A lately added test was missed when applying the struct_mutex removal patches. Do so now. Signed-off-by:
-
- 15 Oct, 2019 2 commits
-
-
Mika Kuoppala authored
Avoid possible cs hang with semaphores by disabling lite restore. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
-
Mika Kuoppala authored
Disable semaphore idle messages and wait for event power downs. Signed-off-by:
-
