- 25 Aug, 2021 14 commits
-
-
Matt Roper authored
The memory latency values returned by pcode on DG2 are in units of "2 usec" rather than 1 usec on all other platforms. I.e., we need to double the value returned by pcode to obtain the true latency value. The bspec wording here was a bit ambiguous as to whether it wanted us to multiply or divide the pcode value by two, but we confirmed offline with the hardware team that we need to double the value the pcode gives us; this change is intended to support a larger range of potential latency values. Bspec: 49326 Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Harish Chegondi <harish.chegondi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210820225710.401136-1-matthew.d.roper@intel.com
-
Ville Syrjälä authored
intel_prepare_shared_dpll() is now useless, so get rid of it. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210715093530.31711-14-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Move the FP divider programming into ibx_pch_dpll_enable(). No reason that I can see why these would have to be programmed this early. Signed-off-by:
-
Ville Syrjälä authored
Can't think of a good reason why we'd need to program the FP dividers so early. Let's just do it when programming the rest of the DPLL. Signed-off-by:
-
Ville Syrjälä authored
Use ilk_needs_fb_cb_tune() for reduced_clock instead of hand rolling it. Also ilk_needs_fb_cb_tune() can just use the precomputed M value instead of calculating it again. Signed-off-by:
-
Ville Syrjälä authored
We always call the vlv/chv prepare_pll() just before enable_pll(). Move the calls into the enable_pll() funcs. We can also consolidate the DPLL_VCO_ENABLE checks while at it. Signed-off-by:
-
Ville Syrjälä authored
On g4x and pch the DPLL has two P1 dividers (for refresh rate switching). Program the FPx1 P1 divider consistently to the reduced clock P1 divider if available, otherwise just program it to the same value as the FPx0 P1 divider. Signed-off-by:
-
Ville Syrjälä authored
Get rid of the local 'reg' variable for the DPLL control register in i9xx_enable_pll(). We have other registers in there too so this is just making things more confusing. Signed-off-by:
-
Ville Syrjälä authored
s/pipe_config/crtc_state/ in the DPLL code. Signed-off-by:
-
Ville Syrjälä authored
Stop passing both the crtc and its state to the DPLL functions. The state alone is enough. Signed-off-by:
-
Ville Syrjälä authored
Lots of places don't need to modify the DPLL params, so make them const. Signed-off-by:
-
Ville Syrjälä authored
Make the PCH dpll code match the gmch code by splitting the FP register handling out from ilk_compute_dpll(). Signed-off-by:
-
Ville Syrjälä authored
The current gen2 DPLL readout code: * assumes i845/i865 have LVDS which is not true * assumes only pipe B can drive LVDS (true, but makes the code appear a bit magical) * hard to parse in general Clean it up by checking for i85x (the only gen2 platform with LVDS) and reusing intel_lvds_port_enabled(). Signed-off-by:
-
Ville Syrjälä authored
When we enable the DPLL for the PPS kick, let's tell the DPLL code we're dealing with an eDP output. This shouldn't really matter, but it's more consistent with the way the DPLL is configured when we're actually enabling the eDP port for real. Signed-off-by:
-
- 24 Aug, 2021 15 commits
-
-
Ville Syrjälä authored
We don't care about __iomem mismatch when dealing with error pointers. Silence it with ERR_CAST(). drivers/gpu/drm/i915/display/intel_dpt.c:136:21: warning: incorrect type in assignment (different address spaces) drivers/gpu/drm/i915/display/intel_dpt.c:136:21: expected struct i915_vma *[assigned] vma drivers/gpu/drm/i915/display/intel_dpt.c:136:21: got void [noderef] __iomem *[assigned] iomem v2: The code moved into intel_dpt.c Signed-off-by:
Matthew Auld <matthew.auld@intel.com>
-
Jani Nikula authored
Split out fb related stuff from intel_display.c to intel_fb.c. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Jani Nikula authored
Split out fb related stuff from intel_display.c to intel_fb.c. Reviewed-by:
-
Jani Nikula authored
Split out fb related stuff from intel_display.c to intel_fb.c. Reviewed-by:
-
Jani Nikula authored
Split out fb related stuff from intel_display.c to intel_fb.c. Reviewed-by:
-
Jani Nikula authored
This will be needed in multiple places soon. Reviewed-by:
-
Jani Nikula authored
Let's try to reduce the size of intel_display.c, not increase it. Reviewed-by:
-
Jani Nikula authored
The unsigned doesn't help us here. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by:
-
Swati Sharma authored
drm_dp_dpcd_read/write already has debug error message. Drop redundant error messages which gives false status even if correct value is read in drm_dp_dpcd_read(). v2: -Added fixes tag (Ankit) v3: -Fixed build error (CI) Fixes: 9488a030 ("drm/i915: Add support for enabling link status and recovery") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.12+ Reviewed-by:
Swati Sharma <swati2.sharma@intel.com> Signed-off-by:
-
Jani Nikula authored
DP 2.0 UHBR link rates always use 128b/132b channel encoding, which has a different data bandwidth efficiency from 8b/10b. The computation is slightly convoluted due to the units we use; this is all explained in the added comment. v2: Clarified comment (Manasi) Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Jani Nikula authored
DG2 supports DP 2.0 UHBR and 128b/132b channel encoding. Bspec: 53657, 54034 Acked-by:
-
Jani Nikula authored
Add the registers for specifying the lower and higher 24 bits of the DP 2.0 pixel clock frequency in Hz. Bspec: 53326 Reviewed-by:
-
Jani Nikula authored
This register controls the DP 2.0 datapath. Bspec: 69967 Reviewed-by:
-
Jani Nikula authored
See if sink supports DP 2.0 128b/132b channel encoding, and update sink rates accordingly. FIXME: Also take LTTPR 128b/132b into account. v2: Add build-time check for ->sink_rates size (Ville) Reviewed-by:
-
Jani Nikula authored
The MST code uses actual link rates in the limits struct, while the DP code in general uses indexes to the ->common_rates[] array. Fix the confusion by using actual link rate values everywhere. This is a better abstraction than some obscure index. Rename the struct members while at it to ensure all the places are covered. Reviewed-by:
-
- 23 Aug, 2021 1 commit
-
-
Tejas Upadhyay authored
Sync PCI IDs with Bspec. Bspec:53655 Changes since V2: - Upstream devices which are "POR" yes and "Ok to upstream" yes - James Asmus Changes since V1: - All POR and Non POR Ids needs to be upstreamed - James Asmus Signed-off-by:Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210818050116.1116237-1-tejaskumarx.surendrakumar.upadhyay@intel.com
-
- 20 Aug, 2021 10 commits
-
-
Kai-Heng Feng authored
Users reported that after commit 2bbd6dba ("drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure"), the screen starts to have wobbly effect. Commit a5c936ad ("drm/i915/dp: Use slow and wide link training for everything") doesn't help either, that means the affected eDP 1.2 panels only work with max params. So use max params for panels < eDP 1.4 as Windows does to solve the issue. v3: - Do the eDP rev check in intel_edp_init_dpcd() v2: - Check eDP 1.4 instead of DPCD 1.1 to apply max params Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3714 Fixes: 2bbd6dba ("drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure") Fixes: a5c936ad ("drm/i915/dp: Use slow and wide link training for everything") Suggested-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Ville Syrjälä authored
Polish the FBC stride override stuff: - just call it override_cfb_stride since it'll be used on more gens later - Use REG_BIT() & co. for the registers and give everything CHICKEN_ prefix since glk+ will have a different register for this - Use intel_de_rmw() for the RMW Signed-off-by:
-
Ville Syrjälä authored
On ILK+ we current do a nuke right after activating FBC. If my memory isn't playing tricks on me this is actially required if FBC didn't stay disabled for a full frame. In that case the deactivate+reactivate may not invalidate the cfb. I'd have to double chekc to be sure though. So let's keep the nuke, and just extend it backwards to cover all the platforms by doing it a bit higher up. Reviewed-by:
-
Ville Syrjälä authored
Pull the fbc enable vs. disable stuff into a small helper so we don't have to have it pollute the higher level modeset code. Reviewed-by:
-
Ville Syrjälä authored
Write the tiling check in a nicer form. No functional changes due to Y-tile scanout being a gen9+ feature. Reviewed-by:
-
Jani Nikula authored
There's no performance reason to have it as static inline; move it out of intel_display_types.h to reduce clutter and dependency on i915_drv.h. Reviewed-by:
-
Jani Nikula authored
There's no performance reason to have it as static inline; move it out of intel_display_types.h to reduce clutter and dependency on i915_drv.h. Reviewed-by:
-
Jani Nikula authored
The fewer includes the better. Reviewed-by:
-
Jani Nikula authored
Reduce includes. Reviewed-by:
-
Jani Nikula authored
Presumably if the compiler is smart, it does not generate an extra function call to the update functions that are now static. Reviewed-by:
-
