summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2024-10-16drm/i915/vrr: Split vrr-compute-config in two phasesAnimesh Manna3-4/+12
As vrr guardband calculation is dependent on modified vblank start so better to compute late after all vblank adjustement. v1: Initial version. v2: Split in a separate patch from panel-replay workaround. [Ankit] v3: Add a function for late vrr related computation. [Ville] v4: Use flipline instead of vrr.enable and some cosmetic changes. [Ville] v5: Use intel_vrr_possible helper. Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> [vsyrjala: Make adjusted_mode const] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241010040503.1795399-3-mitulkumar.ajitkumar.golani@intel.com
2024-10-16drm/i915/vrr: Add helper to check if vrr possibleMitul Golani2-1/+7
Add helper to check if vrr is possible based on flipline is computed. --v1: return just flipline instead using ternary operator [Jonathan, Ville]. Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241010040503.1795399-2-mitulkumar.ajitkumar.golani@intel.com
2024-10-15drm/i915/irq: s/gen3/gen2/Ville Syrjälä4-58/+58
Now that we use the gen3 codepaths also for gen2 rename everything to gen2_ to match. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241008214349.23331-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-10-15drm/i915/display: Fix Panel Replay vblank enable workaroundJouni Högander1-2/+2
Currently workaround is not applied when vblank is enabled on crtc that needs the workaround if vblank is already enabled for another crtc that doesn't need the workaround. Fix this by increasing counter only if crtc needs the workaround. Fixes: aa451abcffb5 ("drm/i915/display: Prevent DC6 while vblank is enabled for Panel Replay") Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009134225.1322820-2-jouni.hogander@intel.com
2024-10-15drm/i915/display: Add own counter for Panel Replay vblank workaroundJouni Högander2-4/+6
We are about to change meaning of vblank_enabled to fix Panel Replay vblank workaround. For sake of clarity we need to rename it. Vblank_enabled is used for i915gm/i945gm vblank irq workaround as well -> instead of rename add new counter named as vblank_wa_pipes. v2: - s/vblank_wa_pipes/vblank_wa_num_pipes/ - use int as a type for the counter Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009134225.1322820-1-jouni.hogander@intel.com
2024-10-14drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible modeImre Deak1-0/+3
If an MST branch device doesn't support DSC for a given mode, but the MST link has enough BW for the mode, assume that the branch device does support the mode using an uncompressed stream. Fixes: 55eaef164174 ("drm/i915/dp_mst: Handle the Synaptics HBlank expansion quirk") Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009110135.1216498-2-imre.deak@intel.com
2024-10-14drm/i915/dp_mst: Handle error during DSC BW overhead/slice calculationImre Deak1-12/+27
The MST branch device may not support the number of DSC slices a mode requires, handle the error in this case. Fixes: 4e0837a8d00a ("drm/i915/dp_mst: Account for FEC and DSC overhead during BW allocation") Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009110135.1216498-1-imre.deak@intel.com
2024-10-12drm/i915/xe3lpd: Add new display power wellsMatt Roper1-1/+133
Xe3's power well handling is similar to previous platforms, but there are a few changes that need to be handled to ensure optimal power management: - PGB now only depends on PG1, not PG2 - Transcoder B is now in PG1 (was previously in PGB) - Transcoders C & D are now in PG2 (were previously in PGC/PGD) - DC states now require PG2 to be off (whereas on Xe2 it could remain on as a dependency of PGB, although the features inside of it could not be used). Bspec: 72519, 68851 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241010224311.50133-4-matthew.s.atwood@intel.com
2024-10-12drm/i915/xe3lpd: Adjust watermark calculationsMatt Roper1-6/+12
Xe3 makes a couple minor tweaks to the watermark algorithm's block count calculations. Bspec: 68985 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241010224311.50133-3-matthew.s.atwood@intel.com
2024-10-12drm/i915/xe3lpd: reuse xe2lpd definitionClint Taylor2-0/+8
xe3_lpd display is functionally identical to xe2_lpd for now so reuse the device description. A separate xe3 definition will be added in the future if/when new feature flags are required. Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241010224311.50133-2-matthew.s.atwood@intel.com
2024-10-11drm/i915/dp: Disable unnecessary HPD polling for eDPImre Deak1-1/+2
A registered eDP connector is considered to be always connected, so it's unnecessary to poll it for a connect/disconnect event. Polling it involves AUX accesses toggling the panel power, which in turn can generate a spurious short HPD pulse and possibly a new poll cycle via the short HPD handler runtime resuming the device. Avoid this by disabling the polling for eDP connectors. This avoids IGT tests timing out while waiting for the device to runtime suspend, the timeout caused by the above runtime resume->poll->suspend-> resume cycle keeping the device in the resumed state. Testcase: igt/kms_pm_rpm/unverisal-planes Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009194358.1321200-3-imre.deak@intel.com
2024-10-11drm/i915/dp: Assume panel power is off if runtime suspendedImre Deak2-2/+11
If the device is runtime suspended the eDP panel power is also off. Ignore a short HPD on eDP if the device is suspended accordingly, instead of checking the panel power state via the PPS registers for the same purpose. The latter involves runtime resuming the device unnecessarily, in a frequent scenario where the panel generates a spurious short HPD after disabling the panel power and the device is runtime suspended. Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009194358.1321200-2-imre.deak@intel.com
2024-10-09drm/i915/mtl: Update PLL c20 phy value for DP uhbr20Dnyaneshwar Bhadane1-4/+4
Update mtl c20 phy DP table for uhbr20 values according to the revised specifications. Bspec: 74165 Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240827141356.3024760-1-dnyaneshwar.bhadane@intel.com
2024-10-09drm/i915: s/gen12/tgl/ in the universal plane codeVille Syrjälä1-8/+8
Using "gen12" in display code is not desirable. Replace it with "tgl" to match how we talk about other platforms in the same code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918144445.5716-8-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2024-10-09drm/i915: Drop GEN12_MC_CCS check from skl_plane_max_width()Ville Syrjälä1-1/+0
I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS is tgl+ only, so checking for it in skl_plane_max_width() (which only applies to pre-glk hardware) is pointless. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918144445.5716-7-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2024-10-09drm/i915: Enable fp16 + CCS on TGL+Ville Syrjälä2-4/+40
TGL+ support compressed fp16 scanout. Enable it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918144445.5716-6-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2024-10-09drm/i915: Enable 10bpc + CCS on ICLVille Syrjälä2-0/+73
ICL also supports compressed 10bpc scanout. Enable it. v2: Set .depth=30 for all variants to match drm_fourcc.c Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918144445.5716-5-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2024-10-09drm/i915: Enable 10bpc + CCS on TGL+Ville Syrjälä2-4/+40
TGL+ support 10bpc compressed scanout. Enable it. v2: Set .depth=30 for all variants to match drm_fourcc.c Set clear color block size to 0x0 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918144445.5716-4-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2024-10-09drm/i915: Disable compression tricks on JSLVille Syrjälä2-0/+10
Bspec asks us to disable some compression trick on JSL. While the bspec description is pretty vague it looks like this is some extra trick for 10bpc+ CCS which presumably the ICL derived display engine doesn't support. Note that we aren't currently exposing 10bpc CCS scanout support, but once that gets added this presumably becomes an issue. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918144445.5716-3-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2024-10-08drm/i915/psr: Implement Wa 14019834836Jouni Högander1-0/+36
This patch implements HW workaround 14019834836 for display version 30. v2: - move Wa 14019834836 to it's own function - apply only for display version 30 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240926064759.1313335-3-jouni.hogander@intel.com
2024-10-08drm/i915/psr: Add new SU area calculation helper to apply workaroundsJouni Högander1-7/+15
intel_psr2_sel_fetch_update is already quite long function. Now we are about to add one more HW workaround. Let's split applying workarounds to selective update area into a separate function. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240926064759.1313335-2-jouni.hogander@intel.com
2024-10-07drm/i915/display: Fix spelling mistake "Uncomressed" -> "Uncompressed"Colin Ian King1-1/+1
There is a spelling mistake in a drm_WARN message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241002074903.833232-1-colin.i.king@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-10-04drm/i915: use NULL for zero wakeref_t instead of plain integer 0Jani Nikula14-29/+29
As of commit 2edc6a75f26c ("drm/i915: switch intel_wakeref_t underlying type to struct ref_tracker *") we gained quite a few sparse warnings about "Using plain integer as NULL pointer" for using 0 to initialize wakeref_t. Switch to NULL everywhere. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241002181655.582597-1-jani.nikula@intel.com
2024-10-04drm/i915/dsb: Use DSB for plane/color management updatesVille Syrjälä5-40/+128
Push regular plane/color management updates to the DSB, if other constraints allow it. The first part of the sequence will go as follows: - CPU will kick off DSB0 immediately - DSB0 writes double bufferd non-arming registers - DSB0 evades the vblank - DSB0 writes double buffered arming registers If no color management updates is needed we follow that up with: - DSB0 waits for the undelayed vblank - DSB0 waits for the delayed vblank (usec wait) - DSB0 emits an interrupt which will cause the CPU to complete the commit If color management update is needed: - DSB0 will start DSB1 with wait for undelayed vblank - DSB0 will in parallel perform the force DEwake tricks - DSB1 writes single buffered LUT registers - DSB1 waits for the delayed vblank (usec wait) - DSB1 emits an interrupt which will cause the CPU to complete the commit With this sequence we don't need to increase the vblank delay to make room for register programming during vblank, which is a good thing for high refresh rate display. But I'll need to still think of some way to eliminate VRR commit completion related races under this scheme. Stuff that isn't ready for DSB yet: - modesets (potentially we could do at least the plane enabling via DSB) - fastsets - VRR - PSR - scalers - async flips Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930170415.23841-14-ville.syrjala@linux.intel.com
2024-10-04drm/i915: Plumb 'dsb' all way to the color commit hooksVille Syrjälä4-88/+115
Pass the 'dsb' all the way down to the color commit hooks so that we'll be able to update the double buffered color management registers (eg. CSC) via the DSB. Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930170415.23841-13-ville.syrjala@linux.intel.com
2024-10-04drm/i915: Plumb 'dsb' all way to the plane hooksVille Syrjälä10-246/+333
We need to be able to do both MMIO and DSB based pipe/plane programming. To that end plumb the 'dsb' all way from the top into the plane commit hooks. The compiler appears smart enough to combine the branches from all the back-to-back register writes into a single branch. So the generated asm ends up looking more or less like this: plane_hook() { if (dsb) { intel_dsb_reg_write(); intel_dsb_reg_write(); ... } else { intel_de_write_fw(); intel_de_write_fw(); ... } } which seems like a reasonably efficient way to do this. An alternative I was also considering is some kind of closure (register write function + display vs. dsb pointer passed to it). That does result is smaller code as there are no branches anymore, but having each register access go via function pointer sounds less efficient. Not that I actually measured the overhead of either approach yet. Also the reg_rw tracepoint seems to be making a huge mess of the generated code for the mmio path. And additionally there's some kind of IS_GSI_REG() hack in __raw_uncore_read() which ends up generating a pointless branch for every mmio register access. So looks like there might be quite a bit of room for improvement in the mmio path still. Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930170415.23841-12-ville.syrjala@linux.intel.com
2024-10-04drm/i915: Extract intel_crtc_prepare_vblank_event()Ville Syrjälä2-6/+18
Extract the code for staging the vblank event for the flip done interrupt handler. We'll reuse this for DSB stuff later. Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930170415.23841-11-ville.syrjala@linux.intel.com
2024-10-04drm/i915/dsb: Introduce intel_dsb_wait_vblank_delay()Ville Syrjälä2-0/+13
Add intel_dsb_wait_vblank_delay() which instructs the DSB to wait for duration between the undelayed and delayed vblanks. We'll need this as the DSB can only directly wait for the undelayed vblank, but we'll need to wait until the delayed vblank has elapsed as well. Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930170415.23841-10-ville.syrjala@linux.intel.com
2024-10-04drm/i915: Introduce intel_scanlines_to_usecs()Ville Syrjälä2-0/+13
Introduce intel_scanlines_to_usecs() as a counterpart to intel_usecs_to_scanlines(). We'll have some use for this in DSB code as we want to do relative scanline waits to evade the delayed vblank, but unfortunately DSB can't do relative scanline waits (only absolute). So we'll instead convert the relative scanline count to usec and do a relative usec wait instead (which the DSB knows how to do). Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930170415.23841-9-ville.syrjala@linux.intel.com
2024-10-04drm/i915/dsb: Introduce intel_dsb_wait_vblanks()Ville Syrjälä2-0/+7
Add a function to emit a DSB wait for vblank instruction. This just waits until the specified number of vblanks. Note that this triggers on the transcoder's undelayed vblank, as opposed to the pipe's delayed vblank. Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930170415.23841-8-ville.syrjala@linux.intel.com
2024-10-04drm/i915/dsb: Introduce intel_dsb_wait_usec()Ville Syrjälä2-0/+7
Add a function to emit the DSB "wait usecs" instruction. This is just a usleep() for the DSB. As a lower bound it seems pretty accurate, but the upper bound seemed oddly relaxed (ie. sometimes I've seen waits that are quite a bit longer than specified, not sure why). Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930170415.23841-7-ville.syrjala@linux.intel.com
2024-10-04drm/i915/dsb: Introduce intel_dsb_vblank_evade()Ville Syrjälä2-0/+33
Add a helper for performing vblank evasion on the DSB. DSB based plane updates will need this to guarantee all the double buffered arming registers will get programmed atomically within the same frame. With VRR we more or less have two vblanks to worry about: - vmax vblank start in case no push was sent - vmin vblank start in case a push was already sent during the vertical active. Only a concern for mailbox updates, which I suppose could happen if the legacy cursor updates take the non-fastpath without setting state->legacy_cursor_update to false. Since we don't know which case is relevant we'll just evade both. We must also make sure to evade both the delayed vblank (for pipe/plane registers) and the undelayed vblank (for transcoder registers and chained DSBs w/ DSB_WAIT_FOR_VBLANK). TODO: come up with a sensible usec number for the evasion... Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930170415.23841-6-ville.syrjala@linux.intel.com
2024-10-04drm/i915/dsb: Enable programmable DSB interruptVille Syrjälä3-2/+30
The DSB can signal a programmable interrupt in response to a specific DSB command getting executed. Hook that up. For now we'll just use this to signal the completion of the commit via a vblank event. If, in the future, we'll need to do other things in response to DSB interrupts we may need to come up with some kind of fancier DSB interrupt framework where the caller can specify a custom handler... Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930170415.23841-5-ville.syrjala@linux.intel.com
2024-10-04drm/i915/dsb: Generate the DSB buffer in commit_tail()Ville Syrjälä1-13/+10
Once we start using DSB for plane updates we'll need to defer generating the DSB buffer until the clear color has been read out. So we need to move at some of the DSB stuff into commit_tail(). That is perhaps a better place for it anyway as the ioctl thread can move on immediately without spending time building the DSB commands. We always have the MMIO fallback (in case the DSB buffer allocation fails), so there's no real reason to keep any of this in the synchronous part of the ioctl. Because the DSB LUT programming doesn't depend on the plane clear color we can still do that part before waiting for fences/etc. which should help paralleize things a bit more. The DSB plane programming will need to happen after those however as that depends on the clear color. Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930170415.23841-4-ville.syrjala@linux.intel.com
2024-10-04drm/i915: Prepare clear color before wait_for_dependencies()Ville Syrjälä1-2/+2
Read out the clear color as soon as fences and the transient data flush have finished. There is no need to wait for all the display specific operations that might still be going on. This could parallelize things a bit more effectively. Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930170415.23841-3-ville.syrjala@linux.intel.com
2024-10-04drm/i915/dsb: Avoid reads of the DSB buffer for indexed register writesVille Syrjälä1-22/+32
Reading from the DSB command buffer might be somewhat expensive on discrete GPUs because the buffer resides in GPU local memory. Avoid such reads in the indexed register write handling by tracking the previous instruction in intel_dsb. TODO: actually measure this Reviewed-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930170415.23841-2-ville.syrjala@linux.intel.com
2024-10-03drm/i915/irq: remove GEN8_IRQ_RESET_NDX() and GEN8_IRQ_INIT_NDX() macrosJani Nikula4-34/+25
Define register offset triplets for all registers used with GEN8_IRQ_RESET_NDX() and GEN8_IRQ_INIT_NDX() macros, and call the underlying gen3_irq_reset() and gen3_irq_init() functions directly. Remove the macros, along with the macro name concatenation hackery. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241002102645.136155-3-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-03drm/i915/irq: remove GEN3_IRQ_RESET() and GEN3_IRQ_INIT() macrosJani Nikula6-42/+84
Define register offset triplets for all registers used with GEN3_IRQ_RESET() and GEN3_IRQ_INIT() macros, and call the underlying gen3_irq_reset() and gen3_irq_init() functions directly. Remove the macros, along with the macro name concatenation hackery. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241002102645.136155-2-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-03drm/i915/irq: add struct i915_irq_regs tripletJani Nikula3-34/+37
Add struct i915_irq_regs to hold IMR/IER/IIR register offsets to pass to gen3_irq_reset() and gen3_irq_init(). This helps in grouping the registers and further cleanup. Note: gen3_irq_reset() and gen3_irq_init() really did have the IMR/IER/IIR parameters in different order. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241002102645.136155-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-03drm/i915/dp: Extract intel_edp_set_sink_rates()Ville Syrjälä1-36/+40
Declutter intel_edp_init_dpcd() a bit by extracting the sink rates probing into its own function. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918190441.29071-3-ville.syrjala@linux.intel.com Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
2024-10-03drm/i915/dp: Make intel_dp_get_colorimetry_status() staticVille Syrjälä2-2/+1
intel_dp_get_colorimetry_status() is not used outside of intel_dp.c. Make it static. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918190441.29071-2-ville.syrjala@linux.intel.com Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
2024-10-03drm/i915: Apply the i915gm/i945gm irq C-state w/a to CRC interruptsVille Syrjälä3-2/+20
Turns out CRC interrupts also fail to wake up i915gm/i945gm from C2+. I suppose this is a generic problem, but for most other interrupts the system will be busy enough already prior to the irq being issued. But CRC interrupts are like vblank interrupts and only fire once per frame, so plenty of time to fall asleep in between them. Apply the same core clock gating trick to CRC interrupts that we use for vblank interrupts. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241001195803.3371-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-10-03drm/i915: Extract i915gm_irq_cstate_wa_{disable,enable}()Ville Syrjälä1-10/+24
Extract the i915gm/i945gm vblank irq C-state workaround to separate functions. We'll need to reuse these in order to guarantee timely CRC interrupt delivery as well. The irq.vblank_enabled count is currently protected by the drm vblank locks, so let's assert that the innermost of those is held, in anticipation of other callers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241001195803.3371-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-10-03drm/i915/irq: Pair up the vblank enable/disable functionsVille Syrjälä1-46/+46
The current way of organizing all .vblank_enable() functions before all .vblabk_disable() functions is infuriating. It's really hard to compare the enable() vs. disable() for the same platform to make sure they properly mirror each other. Reorganize the functions so that the enable+disable for the same platoform are next to each. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241001195803.3371-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-10-03drm/i915/irq: Nuke stale commentsVille Syrjälä1-6/+0
Remove the tall tales about getting passed pipe indices into the .vblank_{enable,disable}() hooks. This hasn't been true since commit 08fa8fd0faa5 ("drm/i915: Switch to per-crtc vblank vfuncs"). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241001195803.3371-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-10-02drm/i915/hdcp: fix connector refcountingJani Nikula1-3/+7
We acquire a connector reference before scheduling an HDCP prop work, and expect the work function to release the reference. However, if the work was already queued, it won't be queued multiple times, and the reference is not dropped. Release the reference immediately if the work was already queued. Fixes: a6597faa2d59 ("drm/i915: Protect workers against disappearing connectors") Cc: Sean Paul <seanpaul@chromium.org> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org # v5.10+ Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240924153022.2255299-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-02drm/i915:Remove unused parameter in marcoHe Lugang3-5/+5
The parameter dev_priv is actually not used in macro PORT_ALPM_CTL and PORT_ALPM_LFPS_CTL,so remove it to simplify the code. Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: He Lugang <helugang@uniontech.com> Link: https://patchwork.freedesktop.org/patch/msgid/6C2E07E089F0CB73+20240925064016.733173-1-helugang@uniontech.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-02drm/i915/soc: stop using IS_GEN9_LP() and IS_GEN9_BC()Jani Nikula2-3/+6
Replace IS_GEN9_LP() and IS_GEN9_BC() with direct platform checks. This lets us remove their compat counterparts, as neither soc/ nor /display now no longer needs them. v2: Use !A && !B instead of !(A || B) (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> # v1 Link: https://patchwork.freedesktop.org/patch/msgid/20240930124056.3541988-2-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-02drm/i915: remove IS_LP()Jani Nikula6-11/+9
The .is_lp member of struct intel_device_info and its wrapper IS_LP() are used to identify just four platforms, VLV/CHV/BXT/GLK. It didn't become as important as it was perhaps originally planned. Just remove it, and replace with exact platform identification. In a few places this becomes slightly verbose, but in many places it improves clarity to immediately see the exact platforms. Additionally, this lets us remove the xe compat macro. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930124056.3541988-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-01drm/i915: Switch over to gen3 irq code on gen2Ville Syrjälä3-197/+9
The only real reason why we have the gen2 vs. gen3+ split in irq handling is that bspec claims that IIR/IMR/IER/ISR and EMR are only 16 bits on gen2, as opposed to being 32 bits on gen3+. That doesn't seem to be a meaningful distinction as 32bit access to these registers works perfectly fine on gen2 Interestingly the 16 msbs of IMR are in fact hardcoded to 1 on gen2, which to me indicates that 32bit access was the plan all along, and perhaps someone just forgot to update the spec. Nuke the special 16bit gen2 irq code and switch over to the gen3 code. Gen2 doesn't have the ASLE interrupt, which just needs a small tweak in i915_irq_postinstall(). And so far we've not had a codepath that could enable the legacy BLC interrupt on gen2. Now we do, but we'll never actually do it since gen2 machines don't have OpRegion. (and neither do i915/i945 machines btw). On these older platforms the legacy BLC interrupt is meant to be used in conjunction with the LBPC backlight stuff, but we never actually switch off the legacy/combination mode and thus don't use the interrupt either. This was quickly smoke tested on all gen2 variants. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240927143545.8665-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-01-10 11:24:45 +0300