summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2022-04-12drm/i915/dg2: Add support for DG2 clear color compressionJuha-Pekka Heikkilä
Add support for the DG2 specific render compression with clear color framebuffer format. DG2 onwards discrete gfx has support for new flat CCS mapping, which brings in display feature in to avoid Aux walk for compressed surface. This support build on top of Flat CCS support added in XEHPSDV. FLAT CCS surface base address should be 64k aligned, Compressed displayable surfaces must use tile4 format. HAS: 1407880786 B.Spec : 7655 B.Spec : 53902 v2: Merge all bits required for the support of functionality into this patch from the patch adding the corresponding modifier. Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220411143405.1073845-5-imre.deak@intel.com
2022-04-12drm/i915/dg2: Add support for DG2 render and media compressionMatt Roper
Add support for DG2 render and media compression, for the description of buffer layouts see the previous patch adding the corresponding frame buffer modifiers. v2: Display version fix [Imre] v3: Split out modifier addition to separate patch. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220411143405.1073845-3-imre.deak@intel.com
2022-04-12drm/i915/bios: Validate the panel_name tableVille Syrjälä
In addition to the fp_timing,dvo_timing,panel_pnp_id tables there also exists a panel_name table. Unlike the others this is just one offset+table_size even though there are still 16 actual panel_names in the data block. The panel_name table made its first appearance somewhere around VBT version 156-163. The exact version is not known. But we don't need to know that since we can just check whether the pointers block has enough room for it or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220405173410.11436-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-12drm/i915/bios: Trust the LFP data pointersVille Syrjälä
Now that we've sufficiently validated the LFP data pointers we can trust them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220405173410.11436-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-12drm/i915/bios: Validate LFP data table pointersVille Syrjälä
Make sure the LFP data table pointers sane. Sensible looking table entries, everything points correctly into the data block, etc. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220405173410.11436-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-12drm/i915/bios: Use the copy of the LFP data table alwaysVille Syrjälä
Currently get_lvds_fp_timing() still returns a pointer to the original data block rather than our copy. Let's convert the data pointer offsets to be relative to the data block rather than the whole BDB. With that we can make get_lvds_fp_timing() return a pointer to the copy. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220405173410.11436-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-12drm/i915/bios: Make copies of VBT data blocksVille Syrjälä
Make a copy of each VBT data block with a guaranteed minimum size. The extra (if any) will just be left zeroed. This means we don't have to worry about going out of bounds when accessing any of the structure members. Otherwise that could easliy happen if we simply get the version check wrong, or if the VBT is broken/malicious. v2: Don't do arithmetic between bdb header and copy of the LFP data block (Jani) v3: Make all the copies up front v4: Only WARN about min_size==0 if we found the block Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220406133817.30652-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-12drm/i915/bios: Use the cached BDB versionVille Syrjälä
We have the BDB version cached, use it. We're going to have to start doing some of the BDB block parsing later, at which point we may no longer have the VBT around anymore (we free it at the end of intel_bios_init() when it didn't come via OpRegion). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220405173410.11436-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-11drm/i915/dg2: Do not explode on phy calibration errorLucas De Marchi
When the PHY fails on calibration we were previously skipping the ddi initialization. However the driver is not really prepared for that, ultimately leading to a NULL pointer dereference: [ 75.748348] i915 0000:03:00.0: [drm:intel_modeset_init_nogem [i915]] SNPS PHY A failed to calibrate; output will not be used. ... [ 75.750336] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [CRTC:80:pipe A] hw state readout: enabled ... ( no DDI A/PHY A ) [ 75.753080] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [ENCODER:235:DDI B/PHY B] hw state readout: disabled, pipe A [ 75.753164] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [ENCODER:245:DDI C/PHY C] hw state readout: disabled, pipe A ... [ 75.754425] i915 0000:03:00.0: [drm] *ERROR* crtc 80: Can't calculate constants, dotclock = 0! [ 75.765558] i915 0000:03:00.0: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev)) [ 75.765569] WARNING: CPU: 5 PID: 1759 at drivers/gpu/drm/drm_vblank.c:728 drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x347/0x360 ... [ 75.781230] BUG: kernel NULL pointer dereference, address: 000000000000007c [ 75.788198] #PF: supervisor read access in kernel mode [ 75.793347] #PF: error_code(0x0000) - not-present page [ 75.798480] PGD 0 P4D 0 [ 75.801019] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 75.805377] CPU: 5 PID: 1759 Comm: modprobe Tainted: G W 5.18.0-rc1-demarchi+ #199 [ 75.827613] RIP: 0010:icl_aux_power_well_disable+0x3b/0x200 [i915] [ 75.833890] Code: 83 ec 30 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 48 8b 06 0f b6 70 1c f6 40 20 04 8d 56 fa 0f 45 f2 e8 88 bd ff ff 48 89 ef <8b> 70 7c e8 ed 67 ff ff 48 89 ef 89 c6 e8 73 67 ff ff 84 c0 75 0a [ 75.852629] RSP: 0018:ffffc90003a7fb30 EFLAGS: 00010246 [ 75.857852] RAX: 0000000000000000 RBX: ffff8881145e8f10 RCX: 0000000000000000 [ 75.864978] RDX: ffff888115220840 RSI: 0000000000000000 RDI: ffff888115220000 [ 75.872106] RBP: ffff888115220000 R08: ffff88888effffe8 R09: 00000000fffdffff [ 75.879234] R10: ffff88888e200000 R11: ffff88888ed00000 R12: ffff8881145e8f10 [ 75.886363] R13: 0000000000000001 R14: ffff888115223240 R15: 0000000000000000 [ 75.893490] FS: 00007ff6e753a740(0000) GS:ffff88888f680000(0000) knlGS:0000000000000000 [ 75.901573] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 75.907313] CR2: 000000000000007c CR3: 00000001216a6001 CR4: 0000000000770ee0 [ 75.914446] PKRU: 55555554 [ 75.917153] Call Trace: [ 75.919603] <TASK> [ 75.921709] intel_power_domains_sanitize_state+0x88/0xb0 [i915] [ 75.927814] intel_modeset_init_nogem+0x317/0xef0 [i915] [ 75.933205] i915_driver_probe+0x5f6/0xdf0 [i915] [ 75.937976] i915_pci_probe+0x51/0x1d0 [i915] We skip the initialization of PHY A, but later we try to find out what is the phy for that power well and dereference dig_port, which is NULL. Failing the PHY calibration could be left as a warning or error, like it was before commit b4eb76d82a0e ("drm/i915/dg2: Skip output init on PHY calibration failure"). However that often fails for outputs not being used, which would make the warning/error appear on systems that have no visible issues. Anyway, there is still a need to fix those failures, but that is left for later. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220410061537.4187383-1-lucas.demarchi@intel.com
2022-04-11drm/i915: Swap ret and status returned from skl_pcode_requestStanislav Lisovskiy
If ret isn't zero, it is almost for sure ETIMEDOUT, because we use it in wait_for macro which does continuous retries until timeout is reached. If we still ran out of time and retries, we most likely would be interested in getting status, to understand what was the actual error propagated from PCode, rather than to find out that we had a time out, which is anyway quite obvious, if the function fails. v2: Make it status ? status : ret(thanks Vinod for the hint) Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220411081343.18099-1-stanislav.lisovskiy@intel.com
2022-04-11drm/i915: Fix skl_pcode_try_request functionStanislav Lisovskiy
Currently skl_pcode_try_request function doesn't properly handle return value it gets from snb_pcode_rw, but treats status != 0 as success, returning true, which basically doesn't allow to use retry/timeout mechanisms if PCode happens to be busy and returns EGAIN or some other status code not equal to 0. We saw this on real hw and also tried simulating this by always returning -EAGAIN from snb_pcode_rw for 6 times, which currently will just result in false success, while it should have tried until timeout is reached: [ 22.357729] i915 0000:00:02.0: [drm:intel_cdclk_dump_config [i915]] Changing CDCLK to 307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0 [ 22.357831] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 1 [ 22.357892] i915 0000:00:02.0: [drm:skl_pcode_request [i915]] Success, exiting [ 22.357936] i915 0000:00:02.0: [drm] ERROR Failed to inform PCU about cdclk change (err -11, freq 307200) We see en error because higher level api, still notices that status was wrong, however we still did try only once. We fix it by requiring _both_ the status to be 0 and request/reply match for success(true) and function should return failure(false) if either status turns out to be EAGAIN, EBUSY or whatever or reply/request masks do not match. So now we see this in the logs: [ 22.318667] i915 0000:00:02.0: [drm:intel_cdclk_dump_config [i915]] Changing CDCLK to 307200 kHz, VCO 614400 kHz, ref 38400 kHz, bypass 19200 kHz, voltage level 0 [ 22.318782] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 1 [ 22.318849] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 2 [ 22.319006] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 3 [ 22.319091] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 4 [ 22.319158] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 5 [ 22.319224] i915 0000:00:02.0: [drm:__snb_pcode_rw [i915]] Returning EAGAIN retry 6 Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220408125200.9069-2-stanislav.lisovskiy@intel.com
2022-04-11Merge drm/drm-next into drm-intel-nextJani Nikula
Sync up with v5.18-rc1, in particular to get 5e3094cfd9fb ("drm/i915/xehpsdv: Add has_flat_ccs to device info"). Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2022-04-09drm/i915/uncore: Warn only if unclaimed access remains flaggedLucas De Marchi
Commit 4b276ed3c7ac ("drm/i915/uncore: Warn on previous unclaimed accesses") tried to improve our report of unclaimed register access, however it unveiled cases that were not previously causing any harm. Downgrade the first message to debug so we can still see them and eventually fix, but don't warn. Fixes: 4b276ed3c7ac ("drm/i915/uncore: Warn on previous unclaimed accesses") Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220408164837.3845786-1-lucas.demarchi@intel.com
2022-04-08drm/i915/display: Fix warnings about PSR lock not heldJosé Roberto de Souza
Commit 3b6f409547fb ("drm/i915/display/psr: Lock and unlock PSR around pipe updates") did not took into account async flips with PSR1 and PSR2 HW tracking, causing PSR lock not be held and causing warnings when intel_psr2_program_trans_man_trk_ctl() is executed. So here taking the PSR lock before the earlier return in intel_pipe_update_start/end(). Cc: Jouni Högander <jouni.hogander@intel.com> Reported-by: Imre Deak <imre.deak@intel.com> Fixes: 3b6f409547fb ("drm/i915/display/psr: Lock and unlock PSR around pipe updates") Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220406210540.493610-1-jose.souza@intel.com
2022-04-06drm/i915/uncore: Warn on previous unclaimed accessesLucas De Marchi
Since gen6 we use FPGA_DBG register to detect unclaimed MMIO registers. This register is in the display engine IP and can only ever detect unclaimed accesses to registers in this area. However sometimes there are reports of this triggering for registers in other areas, which should not be possible. Right now we always warn after the read/write of registers going through unclaimed_reg_debug(). However places using __raw_uncore_* may be triggering the unclaimed access and those being later accounted to a different register. Let's warn both before and after the read/write with a slightly different message, so it's clear if the register reported in the warning is actually the culprit. Commit dda960335e02 ("drm/i915: Just clear the mmiodebug before a register access") attempted to solve the same issue by removing the warning when if FPGA_DBG flags before the mmio read/write. However, it doesn't solve it completely as FPGA_DBG may remain set when reading registers outside display. So in the end the check after the mmio read/write triggers the warning pointing to the wrong register. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220405001149.2675226-1-lucas.demarchi@intel.com
2022-04-06drm/i915/adlp: Fix register corruption after DDI clock enablingImre Deak
Accessing the DDI_BUF_CTL register without the port's DDI clock being enabled (to set/clear the TypeC PHY ownership for the port) can lead to a corrupted value read during any i915 register access right after the DDI clock is enabled. The root cause is the way clock synchronization works for this register, controlled by the CHICKEN_DCPR_1 DDI_CLOCK_REG_ACCESS flag. Correctly this flag should be cleared on ADLP (see the Bspec link below), however after bootup the flag is set. One easily reproducible issue is an unclaimed register access of the PWR_WELL_CTL_DDI2 register, programmed right after DDI clock enabling to enable the port's DDI_IO power well (see the HSDES, VLK links below). With the correct setting above this problem can't be reproduced. Bspec: 49189 HSDES: 18019028154 VLK: 28328, 28655 Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Arthur J Runyan <arthur.j.runyan@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Arthur J Runyan <arthur.j.runyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323201749.288566-1-imre.deak@intel.com
2022-04-06drm/i915: Split i915_run_as_guest into x86 and non-x86Casey Bowman
Split i915_run_as_guest() into a more arch-friendly function as non-x86 builds do not support this functionality. Signed-off-by: Casey Bowman <casey.g.bowman@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331204343.1256150-2-casey.g.bowman@intel.com
2022-04-06drm/i915/display/psr: Use continuos full frame to handle frontbuffer ↵José Roberto de Souza
invalidations Instead of exit PSR when a frontbuffer invalidation happens, we can enable the PSR2 selective fetch continuous full frame, that will keep the panel updated like PSR was disabled but without keeping PSR active. So as soon as the frontbuffer flush happens we can disable the continuous full frame and start to do selective fetches much quicker than the path that would enable PSR, that will wait a few frames to actually activate PSR. Also this approach has proven to fix some glitches found in Alderlake-P when there are a lot of invalidations happening together with page flips. Some may ask why it is writing to CURSURFLIVE(), it is because that is the way that hardware team provided us to poke display to handle PSR updates, and it is being used since display 9. v2: - handling possible race conditions between frontbuffer rendering and page flips Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Cc: Khaled Almahallawy <khaled.almahallawy@intel.com> Cc: Shawn C Lee <shawn.c.lee@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220405155344.47219-3-jose.souza@intel.com
2022-04-06drm/i915/display/psr: Lock and unlock PSR around pipe updatesJosé Roberto de Souza
Frontbuffer rendering and page flips can race with each other and this can potentialy cause issues with PSR2 selective fetch. And because pipe/crtc updates are time sentive we can't grab the PSR lock after intel_pipe_update_start() and before intel_pipe_update_end(). So here adding the lock and unlock functions and calls, the proper PSR2 selective fetch handling will come in a separated patch. v2: - fixed new functions documentation Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220405155344.47219-2-jose.souza@intel.com
2022-04-06drm/i915/display/psr: Set partial frame enable when forcing full frame fetchJosé Roberto de Souza
Following up what was done in commit 804f46885317 ("drm/i915/psr: Set "SF Partial Frame Enable" also on full update") and also setting partial frame enable when psr_force_hw_tracking_exit() is called. Also as PSR2_MAN_TRK_CTL is a double buffered registers do a RMW is not a good idea so here also setting the man_trk_ctl_enable_bit() that is required in TGL and only doing a register write. v2: - not doing a rmw v3: - removing the inline from functions that return PSR2_MAN_TRK_CTL bits Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220405155344.47219-1-jose.souza@intel.com
2022-04-06drm/i915/pmu: Drop redundant IS_VALLEYVIEW check in __get_rc6()Ashutosh Dixit
Because VLV_GT_RENDER_RC6 == GEN6_GT_GFX_RC6, the IS_VALLEYVIEW() check is not needed. Neither is the check present in other code paths which call intel_rc6_residency_ns() (in functions gen6_drpc(), rc6_residency() and rc6_residency_ms_show()). v2: Elimintate VLV_GT_RENDER_RC6 #define (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220314161310.6468-1-ashutosh.dixit@intel.com
2022-04-05drm/i915/dsb: modified to drm_info in dsb_prepare()Animesh Manna
The request to aqquire gem resources is failing for DSB in rare scenario where it is busy and the register programming will be done through mmio fallback path. DSB has extra advantage of faster register programming which may go away through mmio path. Adding wait for gem resource also may not be right as anyways losing time. To make the CI execution happy replaced drm_err() to drm_info() for printing debug info during dsb buffer preparation. v1: Initial version. v2: Added print for mmio fallback at out label. [Nirmoy] v3: Improved debug message. [Nirmoy] Cc: Nirmoy Das <nirmoy.das@linux.intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220325161140.11906-1-animesh.manna@intel.com Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
2022-04-05drm/i915/dp: Fix DFP rgb->ycbcr conversion matrixVille Syrjälä
Our YCbCr output is always supposed to be limited range BT.709. That's what we send with native HDMI. The conn_state->colorspace stuff is entirely independent of that and is not supposed to alter the generated output in any way. If we want a way to do that then we need a new proprty for it. Make it so that the RGB->YCbCr conversion when performed by the DPF will match the BT.709 we would transmit with native HDMI. Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-12-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: Duplicate native HDMI TMDS clock limit handling for DP HDMI DFPsVille Syrjälä
With native HDMI we allow the user to override the mode with something that may not respect the downstream (sink,dual-mode adapter) TMDS clock limits. Let's reuse the same logic for DP HDMI DFPs so that behaviour is more or less uniform. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-11-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: Add support for "4:2:0 also" modes for DPVille Syrjälä
Currently we only support "4:2:0 also" modes on native HDMI. Extend that support for DP as well. With all the HDMI DFP TMDS clock handling sorted out this is now going to work for both native DP and DP->HDMI converters. As with native HDMI we first check if RGB output is possible, and if not we try YCbCr 4:2:0 instead. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-10-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: Rework HDMI DFP TMDS clock handlingVille Syrjälä
Rework the HDMI DFP TMDS clock checks to also check at 8bpc. Previously we only checked the deep color cases. But I suppose a sink could potentially declare "4:2:0 also" modes that only actually fit within its own limits when using 4:2:0. Even if that is too nuts to be real there is no real harm in running through the full checks for everything. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-9-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: Make intel_dp_output_format() usable for "4:2:0 also" modesVille Syrjälä
Hoist the drm_mode_is_420_only() from intel_dp_output_format() into the caller. This will allow intel_dp_output_format() to be reused for "4:2:0 also" modes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-8-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: Pass around intel_connector rather than drm_connectorVille Syrjälä
Prefer to use intel_connector over drm_connector. Also clean up the related variable names a bit. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-7-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: Reorder intel_dp_compute_config() a bitVille Syrjälä
Consolidate the double pfit call, and reorder things so that intel_dp_output_format() and intel_dp_compute_link_config() are back-to-back. They are intimately related, and will need to be called twice to properly handle the "4:2:0 also" modes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-6-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: s/intel_dp_hdmi_ycbcr420/intel_dp_is_ycbcr420/Ville Syrjälä
intel_dp_hdmi_ycbcr420() does account for native DP 4:2:0 output as well, so lets rename it a bit. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-5-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: Extract intel_dp_has_audio()Ville Syrjälä
Declutter intel_dp_compute_config() a bit by moving the has_audio computation into a helper. HDMI already does the same thing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-4-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: Respect the sink's max TMDS clock when dealing with DP->HDMI DFPsVille Syrjälä
Currently we only look at the DFPs max TMDS clock limit when considering whether the mode is valid, or whether we can do deep color. The sink's max TMDS clock limit may be lower than the DFPs, so we need to account for it as well. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4095 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2844 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-3-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-05drm/i915/dp: Extract intel_dp_tmds_clock_valid()Ville Syrjälä
We're currently duplicating the DFP min/max TMDS clock checks in .mode_valid() and .compute_config(). Extract a helper suitable for both use cases. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2022-04-04drm/i915/bios: Extract struct lvds_lfp_data_ptr_tableVille Syrjälä
All the LFP data table pointers have uniform layout. Turn that into a struct. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220317171948.10400-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-04drm/i915: Remove dead members from dev_privVille Syrjälä
Remove some zombies from our device structure. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220321195006.775-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-04drm/i915: Use drm_connector_attach_hdr_output_metadata_property()Ville Syrjälä
Stop hand rolling drm_connector_attach_hdr_output_metadata_property(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220321195006.775-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Allow static DRRS on LVDSVille Syrjälä
Nothing special about static DRRS on LVDS, it's just your bog standard modeset. Let's allow it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-12-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Allow static DRRS on all eDP portsVille Syrjälä
Only seamless DRRS has specific hardware requirements so we can allow static DRRS on any eDP port. And we can replace these port checks and whatnot with a simple check to make sure the transcoder(s) we're about to use are capable of seamless DRRS. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-11-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Move intel_drrs_compute_config() into intel_dp.cVille Syrjälä
intel_drrs_compute_config() is 100% DP specific. DRRS on other types of encoders wouldn't do any of these M2/N2 calculations etc. So let's move this into intel_dp.c so all the DP state calculation is more concentrated into one place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Allow higher refresh rate alternate fixed modesVille Syrjälä
We shouldn't restrict ourselves to just downclock modes with lower refresh rate than the preferred mode. Laptops these days can offer higher refresh rate modes as well. Remove the arbitrary limit and allow all modes that, apart from the clock, match the preferred mode. v2: s/add_edid_downclock_modes/add_edid_alt_fixed_modes/ (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Allow an arbitrary number of downclock modesVille Syrjälä
Remove the "two fixed modes only" limit and grab as many downclock modes from the EDID as we can find. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Stop duplicating the EDID fixed/downclock modesVille Syrjälä
Instead of duplicating the fixed/downclock modes we can just grab the originals straight from the probed_modes list and keep them. The next .get_modes() is going to repopulate the probed_modes list anyway so whatever we leave there is just going to sit around until that time wasting memory. In fact let's clear out the probed modes list entirely to make sure we get 100% consistent behaviour starting already from the very first real .get_modes(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Combine the EDID fixed_mode+downclock_mode lookup into oneVille Syrjälä
The intel_panel_add_edid_fixed_mode() vs. intel_panel_add_edid_downclock_mode() split is not really helpful. Let's just roll those into a single function so that the connector init code doesn't have to care too much about this. All we need to know is whether DRRS should be allowed or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Nuke intel_drrs_init()Ville Syrjälä
intel_drrs_init() is a mostly pointless wrapper around intel_panel_add_edid_downclock_mode(), get rid of it. The only really useful thing left in there is the debug print regarding the DRRS type supported by the connector. Let's just move that into intel_panel_init(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Refactor non-EDID fixed mode duplicationVille Syrjälä
All the non-EDID fixed mode functions basically do the exact same thing. Let's refactor the common bits into a shared function. There are minor differences on how the mode types are populated, whether the display info physical size is updated, and the debug print. The differences are purely accidental, so unifying them is actually a good thing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Put fixed modes directly onto the panel's fixed_modes listVille Syrjälä
Rather than having the connector init get the fixed mode back from intel_panel and then feed it straight back into intel_panel_init() let's just make the fixed mode lookup put the mode directly onto the panel's fixed_modes list. Avoids the pointless round trip and opens the door for further enhancements to the fixed mode handling. v2: Make the debug message correct by using intel_panel_drrs_type() (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-03-31drm/i915: Extract intel_edp_has_drrs()Ville Syrjälä
Pull all the eDP specific platform/port checks out from intel_drrs_init() into intel_edp_has_drrs(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-01drm/i915/display: Add HAS_MBUS_JOININGJosé Roberto de Souza
This will make easy to extend MBUS joining support to future platforms that also supports this feature. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331184152.1086943-1-jose.souza@intel.com
2022-04-01drm/i915/dmc: split out dmc registers to a separate fileJani Nikula
Clean up the massive i915_reg.h a bit with this isolated set of registers. v2: Remove stale comment (Lucas) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220330113417.220964-3-jani.nikula@intel.com
2022-04-01drm/i915/dmc: hide DMC version macrosJani Nikula
The macros are now only needed within intel_dmc.c, so move them there. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220330113417.220964-2-jani.nikula@intel.com
generated by cgit (git 2.34.1) at 2025-05-10 17:34:31 +0000