- 08 Dec, 2020 1 commit
-
-
Manasi Navare authored
The Bspec does not mention polling the FEC Enable Live status bit. That is only there for debug purposes. So remove the polling from driver. Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201125072634.27664-1-manasi.d.navare@intel.com
-
- 04 Dec, 2020 5 commits
-
-
Chris Wilson authored
Switch off the scanout during driver unregister, so we can shutdown the HW immediately for unbind. v2: Remove the old shutdown from remove, it should now be redundant. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201204161601.20897-1-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
Let's do the kill_bigjoiner_slave() thing from intel_bigjoiner_add_affected_crtcs() since it's related to what we do there. This cleans up the logic in the compute_config() loop a bit. Signed-off-by:
-
Ville Syrjälä authored
If either of the bigjoiner pipes needs a modeset then we need a modeset on both pipes. Make it so. v2: Split out the kill_bigjoiner_slave() change (Manasi) Add affected connectors/planes Signed-off-by: -
Ville Syrjälä authored
drm_atomic_add_affected_planes() only considers planes which are logically enabled in the uapi state. For bigjoiner we need to consider planes logically enabled in the hw state. Add a helper for that. Signed-off-by:
-
Ville Syrjälä authored
Currently crtc_state->uapi.plane_mask only tracks logically enabled planes on the uapi level. For bigjoiner purposes we want to do the same for the hw state. Let's follow the pattern established by active_planes & co. here. Signed-off-by:
-
- 03 Dec, 2020 12 commits
-
-
Manasi Navare authored
VRR_CTL register only had a GENMASK but no field prep define for TRANS_VRR_CTL_LINE_COUNT field so add that Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201202182727.26158-1-manasi.d.navare@intel.com
-
Chris Wilson authored
Throw away all the debugfs entries that are not being actively used for debugging/developing IGT. Note that a couple of these are already and will remain available under the gt/ Files removed: i915_gem_fence_regs i915_gem_interrupt i915_ring_freq_table i915_context_status i915_llc i915_shrinker_info Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201202112140.16759-1-chris@chris-wilson.co.uk
-
Imre Deak authored
All the display power domain references are wakeref tracked now, so we can mark intel_display_power_put_unchecked() as an internal function (for suppressing wakeref tracking in non-debug builds). Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
Add wakeref tracking for the display power domain reference taken to keep the display power well functionality disabled. v2: Add missing wakeref zeroing to intel_power_domains_driver_remove() Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Imre Deak authored
Rename power_domains.wakeref to power_domains.init_wakeref to make the use of this reference clearer. The next patch adds tracking for another power reference user of the power_domains functionality. While at it add a missing zero wakeref assert when setting the wakeref. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Imre Deak authored
Add wakeref tracking for the eDP encoders' AUX display power domain references taken while the panel's VDD is enabled. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Imre Deak authored
Add wakeref tracking for the DDI encoders' main lane AUX display power domain references. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Imre Deak authored
Add wakeref tracking for the DDI encoders' DDI_IO display power domain references. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Imre Deak authored
Add wakeref tracking for display power domain references taken for enabled CRTCs. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Imre Deak authored
Factor out helper functions to get/put a set of power domains that are tracked using their wakeref handles. The same is needed by the next patch adding tracking for enabled CRTC power domains. v2: s/uint64_t/u64/ (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Imre Deak authored
The for_each_oldnew_intel_crtc_in_state() iterator index does match crtc->pipe, but using the same thing as array index when getting and putting CRTC power domains makes things clearer. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Dave Airlie authored
This moves the functions into static const instead of having funcs and data in the same struct. It leaves the power callback alone, as it is used in a different manner. v2: leave power callback alone (Jani) Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
- 02 Dec, 2020 5 commits
-
-
Chris Wilson authored
Since we try and estimate how long we require to update the registers to perform a plane update, it is of vital importance that we measure the distribution of plane updates to better guide our estimate. If we underestimate how long it takes to perform the plane update, we may slip into the next scanout frame causing a tear. If we overestimate, we may unnecessarily delay the update to the next frame, causing visible jitter. Replace the warning that we exceed some arbitrary threshold for the vblank update with a histogram for debugfs. v2: Add a per-crtc debugfs entry so that the information is easier to extract when testing individual CRTC, and so that it can be reset before a test. v3: Flip the graph on its side; creates space to label the time axis. Updates: 4684 | 1us | | 4us |******** |********** 16us |*********** |***** 66us | | 262us | | 1ms | | 4ms | | 17ms | | Min update: 5918ns Max update: 54781ns Average update: 16628ns Overruns > 250us: 0 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1982Signed-off-by: -
Jani Nikula authored
Good riddance! Remove the macros and their remaining references in comments. The following functions should be used instead, depending on the use case: - intel_uncore_read(), intel_uncore_write(), intel_uncore_posting_read() - intel_de_read(), intel_de_write(), intel_de_posting_read() Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Uma Shankar authored
FBC can be re-enabled on TGL with WA of keeping it disabled while PSR2 is enabled. This reverts commit 2982ded2. Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
Uma Shankar authored
There are some corner cases wrt underrun when we enable FBC with PSR2 on TGL. Recommendation from hardware is to keep this combination disabled. Bspec: 50422 HSD: 14010260002 v2: Added psr2 enabled check from crtc_state (Anshuman) Added Bspec link and HSD referneces (Jose) v3: Moved the logic to disable fbc to intel_fbc_update_state_cache and removed the crtc->config usages, as per Ville's recommendation. v4: Introduced a variable in fbc state_cache instead of the earlier plane.visible WA, as suggested by Jose. v5: Dropped an extra check for fbc in intel_fbc_enable and addressed review comments by Jose. v6: Move WA to end of function and added Jose's RB. Signed-off-by:
-
Jani Nikula authored
Let's avoid adding new I915_WRITE uses while we try to get rid of them. Fixes: 5f60b12e ("drm/i915/gvt: Save/restore HW status to support GVT suspend/resume") Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Hang Yuan <hang.yuan@linux.intel.com> Cc: Colin Xu <colin.xu@intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: intel-gvt-dev@lists.freedesktop.org Reviewed-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
- 01 Dec, 2020 17 commits
-
-
Uma Shankar authored
Non-HDMI sinks shouldn't be sent Dynamic Range and Mastering infoframes. Check for that when using LSPCON. v2: Addressed Ville's review comment. Signed-off-by:
-
Uma Shankar authored
Implement Read back of HDR metadata infoframes i.e Dynamic Range and Mastering Infoframe for LSPCON devices. v2: Added proper bitmask of enabled infoframes as per Ville's recommendation. v3: Dropped a redundant wrapper as per Ville's comment. v4: Dropped a redundant print, added Ville's RB. Signed-off-by:
-
Uma Shankar authored
Implemented Infoframes enabled readback for LSPCON devices. This will help align the implementation with state readback infrastructure. v2: Added proper bitmask of enabled infoframes as per Ville's recommendation. v3: Added pcon specific infoframe types instead of using the HSW one's, as recommended by Ville. v4: Addressed Ville's review comment by adding HDMI infoframe versions directly instead of DIP wrappers. v5: Re-ordered the patches to avoid potential break in usage, as suggested by Ville. Signed-off-by:
-
Uma Shankar authored
Lspcon has Infoframes as well as DIP for HDR metadata(DRM Infoframe). Create a separate mechanism for lspcon compared to HDMI in order to address the same and ensure future scalability. v2: Streamlined this as per Ville's suggestions, making sure that HDMI infoframe versions are directly returned instead of a redundant and confusing DIP overhead. Suggested-by:
-
Uma Shankar authored
Enable HDR for LSPCON based on Parade along with MCA. v2: Added a helper for status reg as suggested by Ville. v3: Removed a redundant variable, added Ville's RB. Signed-off-by:
Vipin Anand <vipin.anand@intel.com> Reviewed-by:
-
Uma Shankar authored
Dropped a irrelevant lspcon check from intel_hdmi_add_properties function. Suggested-by:
-
Uma Shankar authored
Enable HDMI Colorspace for LSPCON based devices. Sending Colorimetry data for HDR using AVI infoframe. LSPCON firmware expects this and though SOC drives DP, for HDMI panel AVI infoframe is sent to the LSPCON device which transfers the same to HDMI sink. v2: Dropped state managed in drm core as per Jani Nikula's suggestion. v3: Aligned colorimetry handling for lspcon as per compute_avi_infoframes, as suggested by Ville. v4: Finally fixed this with Ville's help, re-phrased the commit header and description. v5: Register HDMI colorspace for lspcon and move this to intel_dp_add_properties as we can't create property at late_register. Credits-to: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
With LSPCON we use the AVI infoframe to convey the colorimetry information (as opposed to DP MSA/SDP), so the property we expose should match the values we can stuff into the infoframe. Ie. we must use the HDMI variant of the property, even though we drive LSPCON in PCON mode. To that end just split intel_attach_colorspace_property() into HDMI and DP variants and let the caller worry about which one it wants to use. Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Uma Shankar authored
Content type is supported on HDMI sink devices. Attached the property for the same for LSPCON based devices. v2: Added the content type programming when we are attaching the property to connector, as suggested by Ville. v3: Need to attach content type on intel_dp_add_properties as creating of new properties is not possible at late_register. Signed-off-by:
-
Uma Shankar authored
Add a WARN to rule out an invalid output range and format combination. This is to align the lspcon code with compute_avi_infoframes. Signed-off-by:
-
Uma Shankar authored
This patch fixes the quantization range for YCbCr output on Lspcon based devices. v2: Re-phrased the description and added Ville's Rb. Signed-off-by:
-
Uma Shankar authored
Attach HDR property for Gen9 devices with MCA LSPCON chips. v2: Cleaned HDR property attachment logic based on capability as per Jani Nikula's suggestion. v3: Fixed the HDR property attachment logic as per the new changes by Kai-Feng to align with lspcon detection failure on some devices. v4: Add HDR proprty in late_register to handle lspcon detection, as suggested by Ville. v5: Init Lspcon only if advertized from BIOS. v6: Added a Todo to plan a cleanup later, added Ville's RB. Signed-off-by:
-
Uma Shankar authored
Gen9 hardware supports HDMI2.0 through LSPCON chips. Extending HDR support for MCA LSPCON based GEN9 devices. SOC will drive LSPCON as DP and send HDR metadata as standard DP SDP packets. LSPCON will be set to operate in PCON mode, will receive the metadata and create Dynamic Range and Mastering Infoframe (DRM packets) and send it to HDR capable HDMI sink devices. v2: Re-used hsw infoframe write implementation for HDR metadata for LSPCON as per Ville's suggestion. v3: Addressed Jani Nikula's review comments. v4: Addressed Ville's review comments, removed redundant wrapper and checks, passed arguments instead of hardcodings. Signed-off-by:
-
Uma Shankar authored
LSPCON firmware exposes HDR capability through LPCON_CAPABILITIES DPCD register. LSPCON implementations capable of supporting HDR set HDR_CAPABILITY bit in LSPCON_CAPABILITIES to 1. This patch reads the same, detects the HDR capability and adds this to intel_lspcon struct. v2: Addressed Jani Nikula's review comment and fixed the HDR capability detection logic v3: Deferred HDR detection from lspcon_init (Ville) v4: Addressed Ville's minor review comments, added his RB. Signed-off-by: -
José Roberto de Souza authored
Add the calculations to set plane selective fetch registers depending in the value of the area damaged. It is still using the whole plane area as damaged but that will change in next patches. v2: - fixed new_plane_state->uapi.dst.y2 typo in intel_psr2_sel_fetch_update() - do not shifthing new_plane_state->uapi.dst only src is in 16.16 format BSpec: 55229 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Tested-by:
-
Jani Nikula authored
Arguably some of these should use intel_de_read() or intel_de_write(), however not all. Prioritize I915_READ() and I915_WRITE() removal in general over migrating to the pedantically correct replacements right away. Reviewed-by:
-
Jani Nikula authored
Arguably some of these should use intel_de_read() or intel_de_write(), however not all. Prioritize I915_READ() and I915_WRITE() removal in general over migrating to the pedantically correct replacements right away. Reviewed-by:
-
