- 03 May, 2024 23 commits
-
-
Balasubramani Vivekanandan authored
Max supported speed by xe2hpd is UHBR13.5. Limit the max DP source rate to it. Bspec: 67066 Signed-off-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by:
Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430172850.1881525-16-radhakrishna.sripada@intel.com
-
Ankit Nautiyal authored
This reverts commit 562f3383. For BMG it seems that the VBT to DDI mapping does not follow DG1, and DG2, but follows ADLP mapping given in Bspec:20124. Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Matt Roper authored
Battlemage's south display is the same as Meteor Lake's, including the need to invert the HPD pins, which Lunar Lake does not need. Signed-off-by:
Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Signed-off-by:
-
José Roberto de Souza authored
No display IP beyond Xe_LPD+ has "BW credits" bits in MBUS_DBOX_CTL register. Restrict the programming only to Xe_LPD+. BSpec: 49213 CC: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Matt Roper authored
Unlike DG2, Xe2_HPD does support multiple GV points with different maximum memory bandwidths, but uses a much simpler algorithm than igpu platforms use. Bspec: 64631 CC: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Anusha Srivatsa authored
Add step 9 from initialize display sequence. v2: Commit subject improved Bpsec: 49189 Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Add initial display info for xe2hpd. It is similar to xelpdp, but with no PORT_B. v2: Inherit from XE_LPDP_FEATURES instead of XE_LPD_FEATURES Bspec: 67066 CC: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Ravi Kumar Vodapalli authored
DP/eDP and HDMI pll values are updated for Xe2_HPD platform v2: Removed the unsupported mtl_c20_dp_uhbr20 from xehpd_c20_dp_tables Bspec: 74165 Signed-off-by:
Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com> Signed-off-by:
-
Balasubramani Vivekanandan authored
Tables for eDP PHY PLL configuration for different link rates added for Xe2_HPD. Previous platforms were using C10 PHY for eDP port whereas Xe2_HPD has C20 PHY. v2: Updated with a more appropriate Bspec number. Bspec: 74165 CC: Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by:
-
Balasubramani Vivekanandan authored
Xe2_HPD has different offsets for C20 PHY SRAM configuration context location. Use the display version to select the right address. Note that Xe2_LPD uses the same C20 SRAM offsets used by Xe_LPDP (i.e. MTL's display). According to the BSpec, currently, only Xe2_HPD has different offsets, so make sure it is the only display using them in the driver. v2: * Redesigned how the right offsets are selected for different display IP versions. v3: Fix white space error(RK) Bspec: 67610 Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
José Roberto de Souza authored
Xe2_HPD has a different value to power down port A. BSpec: 65450 Signed-off-by:
-
Radhakrishna Sripada authored
Discrete cards use the Port numbers TC1-4 for the offsets. The regular flow for type-c subsystem port initialization can be skipped. This check is present in DG2. Extend this to future discrete products. Signed-off-by:
-
Clint Taylor authored
Add Xe2_HPD specific CDCLK table and use MTL Funcs. Bspec: 65243 CC: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
-
Balasubramani Vivekanandan authored
Display code uses IS_BATTLEMAGE macro but the platform support doesn't exist in i915. So fake IS_BATTLEMAGE macro defined to enable building i915 code. We should make sure the macro parameter is used in the always-false expression so that we don't run into "unused variable" warnings from i915 builds if the IS_BATTLEMAGE() check is the only place the i915 pointer gets used in a function. While we're at it, also update the IS_LUNARLAKE macro to include the parameter in the false expression for consistency. Signed-off-by:
-
Clint Taylor authored
Write both CX0 Lanes for Context Toggle for all except TC pin assignment D. v2: Update title(RK) Bspec: 64539 CC: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Rodrigo Vivi authored
A backmerge to sync xe and i915 and allow us to merge "Enable display support for Battlemage" series through drm-intel Link: https://patchwork.freedesktop.org/series/132429/Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Mika Kahola authored
With HDMI monitors we bumped up a case where the crtc clock rate caused a mismatch on state verification. This was due to assumption that the SW clock rate from PLL structure would match the calculated counterpart from HW. This is not necessarily always the case and therefore we would actually need to recalculate the clock rate from SW PLL parameters. Then these SW and HW crtc clock rates can be compared with each other. The patch recalculates the crtc clock rate for SW state based on SW PLL parameters and compares the crtc clock rate calculated from the parameters found from the HW. Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240502131716.504616-1-mika.kahola@intel.com
-
Ville Syrjälä authored
Rename need_async_flip_disable_wa to need_async_flip_toggle_wa to better reflect the fact that we need to deal with the bad PLANE_CTL_ASYNC_FLIP double buffering behaviour going both ways. Reviewed-by:
Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430095639.26390-6-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
On bdw-glk the sync->async flip change takes an extra frame due to the double buffering behaviour of the async flip plane control bit. Since on skl+ we are now explicitly converting the first async flip to a sync flip (in order to allow changing the modifier and/or ddb/watermarks) we are now taking two extra frames until async flips are actually active. We can drop that back down to one frame by setting the async flip bit already during the sync flip. Note that on bdw we don't currently do the extra sync flip (see intel_plane_do_async_flip()) so technically we wouldn't have to deal with this in i9xx_plane_update_arm(). But I added the relevant snippet of code there as well, just in case we ever decide to go for the extra sync flip on pre-skl platforms as well (we might, for example, want to change the fb stride). Signed-off-by:
-
Ville Syrjälä authored
With Xorg+modesetting on skl+ we see the following behaviour: 1. root pixmap is X-tiled 2. client submitted buffers can be Y-tiled (w/ 'Option "dmabuf_capable"') 3. we try to switch from the X-tiled buffer to the Y-tiled buffer using an async flip (when vsync is disabled). 4. the async flip will be rejected by i915 due to the modifier change Relax the rules a bit by turning the first async flip into a sync flip so that we can change the modifier if necessary. Note that we already convert the first async flip into a sync flip on adl+ in order to reprogram the watermarks. Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
DDB/watermarks are always double buffered on the vblank, so we can't safely change them during async flips. Currently this never happens, but we'll be making changing between sync and async flips a bit more flexible, in which case we can actually end up here. Reviewed-by:
-
Ville Syrjälä authored
On ADL async flips apparently generate DMAR and GGTT faults (with accompanying visual glitches) unless PLANE_SURF is aligned to at least 16k. Bump up the alignment to 16k. TODO: analyze things better to figure out what is really going on here Reviewed-by: -
Dave Airlie authored
Merge tag 'drm-xe-next-fixes-2024-05-02' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: - Fix for a backmerge going slightly wrong. - An UAF fix - Avoid a WA error on LNL. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZjOijQA43zhu3SZ4@fedora
-
- 02 May, 2024 5 commits
-
-
Chaitanya Kumar Borah authored
Intel hardware is capable of programming the Maud/Naud SDPs on its own based on real-time clocks. While doing so, it takes care of any deviations from the theoretical values. Programming the registers explicitly with static values can interfere with this logic. Therefore, let the HW decide the Maud and Naud SDPs on it's own. Cc: stable@vger.kernel.org # v5.17 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8097Co-developed-by:
Kai Vehmanen <kai.vehmanen@intel.com> Signed-off-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430091825.733499-1-chaitanya.kumar.borah@intel.com
-
Lucas De Marchi authored
In order to detect duplicate implementations for the same workaround, early in the implementation of RTP it was decided to error out even if the values set are exactly the same. With the introduction of 18034896535 in commit 74671d23 ("drm/xe/xe2: Add workaround 18034896535"), LNL stepping with graphics stepping A1 now gives the following error on module load: xe 0000:00:02.0: [drm] *ERROR* GT0: [GT OTHER] \ discarding save-restore reg e48c (clear: 00000200, set: 00000200,\ masked: yes, mcr: yes): ret=-22 RTP may be improved in the future, but for now simply join the entries like done with e.g. "1607297627, 1607030317, 1607186500". Fixes: 74671d23 ("drm/xe/xe2: Add workaround 18034896535") Cc: Bommu Krishnaiah <krishnaiah.bommu@intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240427135339.3485559-1-lucas.demarchi@intel.comSigned-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com>
-
Matthew Auld authored
We flush the rebind worker during the vm close phase, however in places like preempt_fence_work_func() we seem to queue the rebind worker without first checking if the vm has already been closed. The concern here is the vm being closed with the worker flushed, but then being rearmed later, which looks like potential uaf, since there is no actual refcounting to track the queued worker. We can't take the vm->lock here in preempt_rebind_work_func() to first check if the vm is closed since that will deadlock, so instead flush the worker again when the vm refcount reaches zero. v2: - Grabbing vm->lock in the preempt worker creates a deadlock, so checking the closed state is tricky. Instead flush the worker when the refcount reaches zero. It should be impossible to queue the preempt worker without already holding vm ref. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1676 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1591 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1364 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1304 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1249Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240423074721.119633-4-matthew.auld@intel.com (cherry picked from commit 3d44d67c) Signed-off-by:
-
Thomas Hellström authored
The recent backmerge from drm-next to drm-xe-next brought with it some silent unexpected results. One code snippet was added twice and a partial revert had merge errors. Fix that up to reinstate the affected code as it was before the backmerge. v2: - Commit log message rewording (Lucas DeMarchi) Fixes: 79790b68 ("Merge drm/drm-next into drm-xe-next") Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-next-2024-04-30' of https://anongit.freedesktop.org/git/drm/drm-intel into drm-next Core DRM: - Export drm_client_dev_unregister (Thomas Zimmermann) Display i915: - More initial work to make display code more independent from i915 (Jani) - Convert i915/xe fbdev to DRM client (Thomas Zimmermann) - VLV/CHV DPIO register cleanup (Ville) Signed-off-by:
-
- 30 Apr, 2024 12 commits
-
-
Ville Syrjälä authored
Pull the VLV/CHV DPIO PHY sideband registers to their own file. v2: drop stray tabs (Jani) Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Use REG_BIT() & co. for the vlv/chv DPIO PHY registers. Note that DPIO_BIAS_CURRENT_CTL_SHIFT was incorrectly defined to be 21 wheres 20 is the correct value. It is not used in the code though so didn't bother splitting to a separate patch. v2: drop stray tabs (Jani) Signed-off-by:
-
Ville Syrjälä authored
The DPIO PHY registers follow clear numbering rules. Express those in a few macros to get rid of the hand calculated final offsets. Signed-off-by:
-
Ville Syrjälä authored
Drop the leading underscore from the CHV PHY common lane register definitions. We use these directly from actual code so the underscore here is misleading as usually it indicates an intermediate define that shouldn't be used directly. Signed-off-by:
-
Ville Syrjälä authored
Include _GRP in VLV DPIO PHY group access register define names. Makes it more obvious where the accesses will land. Also matches the naming used by BXT already. Signed-off-by:
-
Ville Syrjälä authored
In the encoder hooks we are dealing primarily with the encoder, so derive the DPIO PHY from the encoder rather than the pipe. Technically this doesn't matter as we can't cross connect pipes<->port across PHY boundaries, but it does conveny the intention more accurately. Signed-off-by:
-
Ville Syrjälä authored
Stop using 'pipe' directly as the DPIO PHY channel. This does happen to work on VLV since it just has the one PHY with CH0==pipe A and CH1==pipe B. But explicitly converting the thing to the right enum makes the whole thing less confusing. Signed-off-by:
-
Ville Syrjälä authored
Stop calling the DPIO PHY channel "port". Just say "ch", which is already used in a bunch of places. Signed-off-by:
-
Ville Syrjälä authored
Use a consistent 'tmp' as the variable name for the register values during rmw when we don't deal with multiple registers in parallel. Signed-off-by:
-
Ville Syrjälä authored
Drop all the local variables for the DPLL dividers for vlv/chv and just consult the state directly. Signed-off-by:
-
Ville Syrjälä authored
The spreadsheet defines the PLL register block as having the dwords in the following order: block dwords offsets PLL1 0x0-0x7 0x00-0x1f PLL2 0x0-0x7 0x20-0x3f PLL1ext 0x10-0x1f 0x40-0x5f PLL2ext 0x10-0x1f 0x60-0x7f So dword indexes 0x8-0xf don't even exist. Renumber our register defines to match. Note that the spreadsheet used hex numbering whereas our defiens are in decimal. Perhaps we should change that? Signed-off-by:
-
Ville Syrjälä authored
VLV_PLL_DW9_BCAST is actually VLV_PCS_DW17_BCAST. The address does kinda look like it goes to the PLL block on a first glance, but broadcast is special and doesn't even exist for the PLL (only PCS and TX have it). The fact that we use a broadcast write here is a bit sketchy IMO since we're now blasting the register to all PCS splines across the whole PHY. So the PCS registers in the other channel (ie. other pipe/port) will also be written. But I guess the fact that we always write the same value should make this a nop even if the other channel is already enabled (assuming the VBIOS/GOP didn't screw up and use some other value...). Signed-off-by:
-
