- 17 Oct, 2019 2 commits
-
-
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191015190538.27539-1-ville.syrjala@linux.intel.comReviewed-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:Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191016093802.12483-1-tvrtko.ursulin@linux.intel.com
-
- 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 22 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:
-
Mika Kuoppala authored
Avoid possible deadlock on context switch. Signed-off-by:
-
Mika Kuoppala authored
To avoid possible hang, we need to add depth stall if we flush the depth cache. Signed-off-by:
-
Mika Kuoppala authored
Avoid possible hang in tsg,vfe units by keeping l3 clocks runnings. Signed-off-by:
-
Mika Kuoppala authored
Avoid possible hang in CPSS unit. Signed-off-by:
-
Mika Kuoppala authored
To ensure correct state data for compute workloads, we need to keep the ff dop clock enabled. References: HSDES#1606700617 Signed-off-by:
-
Mika Kuoppala authored
In order to ensure constant caches are invalidated properly with a0, we need extra hdc flush after invalidation. v2: use IS_TGL_REVID (Chris) References: HSDES#1604544889 Signed-off-by:
-
Mika Kuoppala authored
Add hdc pipeline flush to ensure memory state is coherent in L3 when we are done. v2: Flush also in breadcrumbs (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Mika Kuoppala authored
Aim for completeness and invalidate also the ro parts in l3 cache. This might allow to get rid of the preparser disable/enable workaround on invalidation path. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Mika Kuoppala authored
We are going to need this macro on limiting the workaround scope. Signed-off-by:
-
Mika Kuoppala authored
Avoid possible hang in tsg,vfe units by keeping l3 clocks runnings. Signed-off-by:
-
Chris Wilson authored
If the system is being slow and userspace is racing ahead of the GPU and finds itself waiting for the GPU to catch up, before the process sleeps give the tasklet a kick, bypassing ksoftirqd. If the system is overloaded, then ksoftirqd may be delayed incurring additional latency to our user. This should not be a frequent problem, but in the past we have observed several hundred millisecond delays before ksoftirqd services an interrupt, so burn a few cycles to lend a helping hand. Signed-off-by:
-
Ville Syrjälä authored
Use the new drm_rect_init() helper where appropriate. Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Use the newly introduced drm_rect_translate_to() instead of hand rolling it. Signed-off-by:
-
Ville Syrjälä authored
While not all platforms allow us to change the cdclk frequency we should still verify that the fixed cdclk frequency isn't too low. To that end let's cook up a .modeset_calc_cdclk() implementation that only does the min_cdclk vs. actual cdclk frequency check for such platforms. Also we mustn't forget about double wide pipe on gen2/3 when doing this. Signed-off-by:
-
Ville Syrjälä authored
We need to insert stuff between the plane and crtc .atomic_check() drm_atomic_helper_check_planes() doesn't allow us to do that so stop using it and hand roll the loops instead. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
Ville Syrjälä authored
Now that we have standard defines for the MSA MISC bits lets use them on HSW+ where we program these directly into the TRANS_MSA_MISC register. Signed-off-by:
-
Gwan-gyeong Mun authored
It attaches HDR metadata property to DP connector on GLK+. It enables HDR metadata infoframe sdp on GLK+ to be used to send HDR metadata to DP sink. v2: Minor style fix Signed-off-by:
-
Gwan-gyeong Mun authored
Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP header and data block setup for HDR Static Metadata. It enables writing of HDR metadata infoframe SDP to panel. Support for HDR video was introduced in DisplayPort 1.4. It implements the CTA-861-G standard for transport of static HDR metadata. The HDR Metadata will be provided by userspace compositors, based on blending policies and passed to the driver through a blob property. Because each of GEN11 and prior GEN11 have different register size for HDR Metadata Infoframe SDP packet, it adds and uses different register size. Setup Infoframe SDP header and data block in function intel_dp_setup_hdr_metadata_infoframe_sdp for HDR Static Metadata as per dp 1.4 spec and CTA-861-F spec. As per DP 1.4 spec, 2.2.2.5 SDP Formats. It enables Dynamic Range and Mastering Infoframe for HDR content, which is defined in CTA-861-F spec. According to DP 1.4 spec and CEA-861-F spec Table 5, in order to transmit static HDR metadata, we have to use Non-audio INFOFRAME SDP v1.3. +--------------------------------+-------------------------------+ | [ Packet Type Value ] | [ Packet Type ] | +--------------------------------+-------------------------------+ | 80h + Non-audio INFOFRAME Type | CEA-861-F Non-audio INFOFRAME | +--------------------------------+-------------------------------+ | [Transmission Timing] | +----------------------------------------------------------------+ | As per CEA-861-F for INFOFRAME, including CEA-861.3 within | | which Dynamic Range and Mastering INFOFRAME are defined | +----------------------------------------------------------------+ v2: Add a missed blank line after function declaration. v3: Remove not handled return values from intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma] v9: Addressed review comments from Ville. - Add BUILD_BUG_ON to check a changing of struct dp_sdp size. - Change a passed size toward write_infoframe() for DP infoframe sdp packet for HDR static metadata. Signed-off-by: -
Gwan-gyeong Mun authored
According to Bspec, GEN11 and prior GEN11 have different register size for HDR Metadata Infoframe SDP packet. It adds new VIDEO_DIP_GMP_DATA_SIZE for GEN11. And it makes handle different register size for HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN platforms. It addresses Uma's review comments. v9: Add WARN_ON() when buffer size if larger than register size. [Ville] Signed-off-by:
-
Gwan-gyeong Mun authored
It attaches the colorspace connector property to a DisplayPort connector. Based on colorspace change, modeset will be triggered to switch to a new colorspace. And in order to distinguish colorspace bwtween DP and HDMI connector, it adds a handling of drm_mode_create_dp_colorspace_property() to intel_attach_colorspace_property(). Based on colorspace property value create a VSC SDP packet with appropriate colorspace. This would help to enable wider color gamut like BT2020 on a sink device. v9: Addressed review comments from Ville - Add a handling of drm_mode_create_dp_colorspace_property() to intel_attach_colorspace_property(). This hunk moved from the previous commit. Signed-off-by:
-
