- 29 Sep, 2021 8 commits
-
-
Dave Airlie authored
These are the watermark api between display and pm. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Dave Airlie authored
This function is only used inside intel_pm.c Reviewed-by:
-
Dave Airlie authored
This wraps the fdi link training vfunc to make it clearer. Suggested by Jani. Reviewed-by:
-
Dave Airlie authored
This adds wrappers around all the vtable callers so they are in one place. Suggested by Jani. Reviewed-by:
-
Dave Airlie authored
This moves one wrapper from the pm->display side, and creates wrappers for all the others, this should simplify things later. One thing to note is that the code checks the existence of some of these ptrs, so the wrappers are a bit complicated by that. Suggested by Jani. v2: fixup warnings in wrong place error. v3 by Jani: fix intel_compute_global_watermarks() return value check Reviewed-by:
-
Dave Airlie authored
The crtc was never being used here. Reviewed-by:
-
Dave Airlie authored
The i845_update_wm code was always calling the i845 variant, and the i9xx_update_wm had only a choice between i830 and i9xx paths, hardly worth the vfunc overhead. Reviewed-by:
-
Dave Airlie authored
constify it while here. drop the put function since it was never overloaded and always has done the same thing, no point in indirecting it for show. Reviewed-by:
-
- 28 Sep, 2021 1 commit
-
-
Vandita Kulkarni authored
The right parameter that selects second dsc engine is dsc_split. Hence use dsc_split instead of slice_count while selecting the cdclk in order to accommodate 1ppc limitaion of vdsc. Fixes: fe01883f ("drm/i915: Get proper min cdclk if vDSC enabled") Suggested-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210915054338.29869-1-vandita.kulkarni@intel.com
-
- 27 Sep, 2021 1 commit
-
-
Kai-Heng Feng authored
Commit 989634fb ("drm/i915/audio: set HDA link parameters in driver") makes HDMI audio on Lenovo P350 disappear. So in addition to TGL, extend the logic to RKL to use BIOS provided value to fix the regression. Fixes: 989634fb ("drm/i915/audio: set HDA link parameters in driver") Reviewed-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
- 24 Sep, 2021 4 commits
-
-
Ville Syrjälä authored
On FBC1 we can specify an arbitrary cfb stride. The hw will simply throw away any compressed line that would exceed the specified limit and keep using the uncompressed data instead. Thus we can allow arbitrary compression limits. The one thing we have to keep in mind though is that the cfb stride is specified in units of 32B (gen2) or 64B (gen3+). Fortunately X-tile is already 128B (gen2) or 512B (gen3+) wide so as long as we limit outselves to the same 4x compression limit that FBC2 has we are guaranteed to have a sufficiently aligned cfb stride. Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921152517.803-5-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
There's some kind of weird corner cases in FBC which requires FBC segments to be separated by at least one extra cacheline. Make sure that is present. v2: Respin to fit in with skl_fbc_min_cfb_stride() v3: Make it build Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> #v1 Signed-off-by:
-
Ville Syrjälä authored
Apply the same 512 byte FBC segment alignment to glk+ as we use on skl+. The only real difference is that we now have a dedicated register for the FBC override stride. Not 100% sure which platforms really need the 512B alignment, but it's easiest to just do it on everything. Also the hardware no longer seems to misclaculate the CFB stride for linear, so we can omit the use of the override stride for linear unless the stride is misaligned. Reviewed-by:
-
Ville Syrjälä authored
The code to calculate the cfb stride/size is a bit of mess. The cfb size is getting calculated based purely on the plane stride and plane height. That doesn't account for extra alignment we want for the cfb stride. The gen9 override stride OTOH is just calculated based on the plane width, and it does try to make things more aligned but any extra alignment added there is not considered in the cfb size calculations. So not at all convinced this is working as intended. Additionally the compression limit handling is split between the cfb allocation code and g4x_dpfc_ctl_limit() (for the 16bpp case), which is just confusing. Let's streamline the whole thing: - Start with the plane stride, convert that into cfb stride (cfb is always 4 bytes per pixel). All the calculations will assume 1:1 compression limit since that will give us the max values, and we don't yet know how much stolen memory we will be able to allocate - Align the cfb stride to 512 bytes on modern platforms. This guarantees the 4 line segment will be 512 byte aligned regardles of the final compression limit we choose later. The 512 byte alignment for the segment is required by at least some of the platforms, and just doing it always seems like the easiest option - Figure out if we need to use the override stride or not. For X-tiled it's never needed since the plane stride is already 512 byte aligned, for Y-tiled it will be needed if the plane stride is not a multiple of 512 bytes, and for linear it's apparently always needed because the hardware miscalculates the cfb stride as PLANE_STRIDE*512 instead of the PLANE_STRIDE*64 that it use with linear. - The cfb size will be calculated based on the aligned cfb stride to guarantee we actually reserved enough stolen memory and the FBC hw won't end up scribbling over whatever else is allocated in stolen - The compression limit handling we just do fully in the cfb allocation code to make things less confusing v2: Write the min cfb segment stride calculation in a more explicit way to make it clear what is going on v3: Remeber to update fbc->limit when changing to 16bpp Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v2 Signed-off-by:
-
- 23 Sep, 2021 9 commits
-
-
Ville Syrjälä authored
If HPLL watermarks are already enabled, let's not mark them as disabled by forgetting to bump 'level' before we call g4x_raw_plane_wm_set(). Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
José Roberto de Souza authored
PSR always had a requirement to only be enabled if there is active planes but not following that never caused any issues. But that changes in Alderlake-P, leaving PSR enabled without active planes causes transcoder/port underruns. Similar behavior was fixed during the pipe disable sequence by commit 84030adb ("drm/i915/display: Disable audio, DRRS and PSR before planes"). intel_dp_compute_psr_vsc_sdp() had to move from intel_psr_enable_locked() to intel_psr_compute_config() because we need to be able to disable/enable PSR from atomic states without connector and encoder state. Reviewed-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210922215242.66683-3-jose.souza@intel.com
-
José Roberto de Souza authored
We were not completely following the selective fetch programming sequence, here some things we were doing wrong: - not programming plane selective fetch a PSR2_MAN_TRK_CTL registers when doing a modeset - programming PSR2_MAN_TRK_CTL out of vblank With this changes the last remainig underrun found in Alderlake-P is fixed. Bspec: 55229 Tested-by:
-
José Roberto de Souza authored
Specification asks for DC_STATE_DEBUG_MASK_CORES to be set for all platforms that supports DMC, not only for geminilake and broxton. While at is also taking the oportunity to simply the code. BSpec: 7402 BSpec: 49436 Reviewed-by:
Imre Deak <imre.deak@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
Imre Deak authored
Add support for remapping CCS FBs on ADL-P to remove the restriction of the power-of-two sized stride and the 2MB surface offset alignment for these FBs. We can only remap the tiles on the main surface, not the tiles on the CCS surface, so userspace has to generate the CCS surface aligning to the POT size padded main surface stride (by programming the AUX pagetable accordingly). For the required AUX pagetable setup, this requires that either the main surface stride is 8 tiles or that the stride is 16 tiles aligned (= 64 kbytes, the area mapped by one AUX PTE). v2: - Init intel_remapped_info::plane_alignment only for remapped views and do this from intel_fb_view_init(). Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Imre Deak authored
Follow the usual new->old order in intel_fb_stride_alignment() platform check ladder. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Imre Deak authored
Atm the DPT object can accommodate only one VMA, so the VMA offset will be always 0. Add an assert for this. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Imre Deak authored
At the moment CCS FB strides must be power-of-two sized, but a follow-up change will add support remapping these FBs, allowing the FB passed in by userspace to have a non-POT sized stride. For these remapped FBs we can only remap the main surface, not the CCS surface. This means that userspace has to always generate the CCS surface aligning to the POT stride padded main surface (by setting up the CCS AUX pagetables accordingly). Adjust the CCS surface stride check to enforce this. No functional change. v2: - Fix the gen12_ccs_aux_stride() is not static sparse warning. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Imre Deak authored
The tile size for all surface types is 4 kbyte (or 2 kbyte on old platforms), with the exception of the TGL/ADL CCS surface where the tile size is 64 bytes. To be able to remap CCS FBs the CCS surface tile needs to be defined as 4 kbyte as well (the granularity of GTT pages in a remapped view). The only place using the dimension of the 64 byte CCS area is the initial check for the main vs. CCS plane origin coordinate match. To prepare for adding support for remapping CCS FBs let's call the 64 byte CCS area a 'tile block' and add a helper to retrieve the dimensions for it. No functional change. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
- 22 Sep, 2021 5 commits
-
-
Ville Syrjälä authored
The w/a database lists this for both ctg and elk. So let's apply it to elk as well. And add the w/a name. Signed-off-by:
-
Ville Syrjälä authored
The intention was to check whether the primary plane is enabled without any sprites planes being enabled. Instead we ended up checking whether just any one of the planes is enabled. g4x isn't vlv/chv and cxsr only works with the primary plane. Fix the check to examine the bitmask of active planes rather than the number of bits set in said bitmask. Signed-off-by:
-
Ville Syrjälä authored
Be consistent in that active_planes bitmask fits in a u8. Signed-off-by:
-
Ville Syrjälä authored
intel_plane_atomic_calc_changes() deals with both the old and new crtc/plane states. Make the variable names reflect that more clearly. Signed-off-by:
-
Tejas Upadhyay authored
Add helper function with returns if HDR mode in on Signed-off-by:
Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210907113658.1351456-1-tejaskumarx.surendrakumar.upadhyay@intel.com [vsyrjala: fix up alignment to match codingstyle] Signed-off-by:
-
- 20 Sep, 2021 12 commits
-
-
Jani Nikula authored
There's a new register pair for 128b/132b mode where you need to set the pixel clock in Hz. v2: Fix UHBR rate check, use intel_dp_is_uhbr() helper Bspec: 54128 Reviewed-by:
-
Jani Nikula authored
128b/132b has a separate transcoder DDI mode, which also requires the MST transport select to be set. Note that we'll use DP MST also for single-stream 128b/132b. Having the FDI and 128b/132b modes share the register mode value complicates things a bit. v2: - Use HAS_DP20 abstraction for 128b/132b mode (Ville) - Use intel_dp_is_uhbr() helper Bspec: 50493 Reviewed-by:
-
Jani Nikula authored
Let's abstract the DP 2.0 feature. Initially just DG2. Reviewed-by:
-
Jani Nikula authored
Set the DP 2.0 128b/132b channel encoding for UHBR rates. v2: Fix UHBR port clock check, use intel_dp_is_uhbr() Bspec: 54128 Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Jani Nikula authored
UHBR rates and 128b/132b channel encoding go hand in hand. v2: Fix check for >= UHBR rates using intel_dp_is_uhbr() (Ville) Reviewed-by:
-
Jani Nikula authored
128b/132b channel encoding has separate TPS1 and TPS2, although the DPCD register values coincide with 8b/10b TPS1 and TPS2 values. Use 128b/132b TPS2 for channel equalization. v2: Use intel_dp_is_uhbr Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> # v1 Signed-off-by:
-
Jani Nikula authored
Helpful abstraction to avoid duplication. Reviewed-by:
-
Jani Nikula authored
Unfortunately, the DP 2.0 128b/132b DDI mode selection in the register conflicts with FDI. Since we have to deal with both meanings in the same code, for different platforms, clarify the macro name so we don't forget. Bspec: 50493 Reviewed-by:
-
Jani Nikula authored
The DP 2.0 128b/132b channel coding uses TX FFE presets instead of vswing and pre-emphasis. Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
-
Jani Nikula authored
DP 2.0 brings some new DPCD addresses for PHY repeaters. Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
Jani Nikula authored
Extend the use of extended receiver cap at 0x2200 to cover MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation hides the DP 2.0 128b/132b channel encoding cap. v2: Extend to DP_RECEIVER_CAP_SIZE (Ville) Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Acked-by:
-
Jani Nikula authored
The bw code equals link_rate / 0.27 Gbps only for 8b/10b link rates. Handle DP 2.0 UHBR rates as special cases, though this is not pretty. Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
