summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display
AgeCommit message (Collapse)Author
2021-03-08drm/i915: Call primary encoder's .get_config() from MST .get_config()Ville Syrjälä
Stop assuming intel_ddi_get_config() is all we need from the primary encoder, and instead call it via the .get_config() vfunc. This will allow customized .get_config() for the primary, which I plan to use to handle the differences in the clock readout between various platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-2-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-03-05drm/i915: Fix DSI TE max_vblank_count handlingVille Syrjälä
commit 33267703df15 ("drm/i915/dsi: Enable software vblank counter") claims to get the mode_flags from the crtc_state, but in fact does not. Fix it to do it right. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210304170421.10901-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-03-05drm/i915: Don't try to query the frame counter for disabled pipesVille Syrjälä
For platforms/outputs without hardware frame counters we can't call drm_crtc_accurate_vblank_count() when the vblank support is disabled or we just get a WARN due to the crtc timings (vblank->hwmode) being considered invalid. Note that until the pipe in question has been enabled and drm_crtc_set_max_vblank_count() has been called on it we would also take this path on platforms which have a working frame counter. So getting the WARN is rather likely on any platform unless you always boot with lots of displays plugged in. Also even on hardware with a working frame counter we may not be able to read the actual frame counter register on disabled pipes due the relevant power well being disabled. Ie. would just result in the unclaimed reg spew. So let's just avoid all this an directly report zero in case the pipe is disabled. Reported-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210304170421.10901-3-ville.syrjala@linux.intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2021-03-05drm/i915: Move pipe enable/disable tracepoints to intel_crtc_vblank_{on,off}()Ville Syrjälä
On platforms/outputs without a working frame counter we rely on the vblank code to cook up the frame counter from the timestamps. That requires that vblank support is enabled. Thus we need to move the pipe enable/disable tracepoints to the other side of the drm_vblank_{on,off}() calls. There shouldn't really be much happening between these old and new call sites so the tracepoints should still provide reasonable data. The alternative would be to give up on having the frame counter values in the trace which would render the tracepoints more or less pointless. v2: Missed one case in intel_ddi_post_disable() Drop the now useless i915_trace.h includes Reported-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210304170421.10901-2-ville.syrjala@linux.intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2021-03-04drm/i915/edp: enable eDP MSO during link trainingJani Nikula
If the source and sink support MSO, enable it during link training. v4: Divide DRRS pixel clock by link count before M/N calculation v3: Adjust timings, refer to splitter v2: Limit MSO to pipe A using ->pipe_mask Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2711 Cc: Nischal Varide <nischal.varide@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/66da48b4b3c5ccffaac7989097cd96d6c6af8243.1614682842.git.jani.nikula@intel.com
2021-03-04drm/i915/edp: modify fixed and downclock modes for MSOJani Nikula
In the case of MSO (Multi-SST Operation), the EDID contains the timings for a single panel segment. We'll want to hide the fact from userspace, and expose modes that span the entire display. Don't modify the EDID, as the userspace should not use that for modesetting, only modify the actual modes. v3: Use pixel overlap if available. v2: Rename intel_dp_mso_mode_fixup -> intel_edp_mso_mode_fixup Cc: Nischal Varide <nischal.varide@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2862284eb033bb0ffc96134b7d5b11bf29e4587f.1614682842.git.jani.nikula@intel.com
2021-03-04drm/i915/mso: add splitter state checkJani Nikula
For starters, we expect the state to be zero, as we don't enable MSO anywhere. v2: Refer to splitter. Cc: Nischal Varide <nischal.varide@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/459a332f3cdce941c57312150872559db68f88c1.1614682842.git.jani.nikula@intel.com
2021-03-04drm/i915/mso: add splitter state readout for platforms that support itJani Nikula
Add splitter configuration to crtc state, and read it where supported. Also add splitter state dumping. The stream splitter will be required for eDP MSO. v4: - Catch invalid splitter configuration (Uma) v3: - Convert segment timings to full panel timings. - Refer to splitter instead of mso in crtc state. - Dump splitter state. v2: Add warning for mso being enabled on pipes other than A. Cc: Nischal Varide <nischal.varide@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/95cbe1c9d45edf3e3ec252e49fb49055def98155.1614682842.git.jani.nikula@intel.com
2021-03-03drm/i915: Clean up verify_wm_state()Ville Syrjälä
Get rid of the nonsense cursor special case in verify_wm_state() by just iterating through all the planes. And let's use the canonical [PLANE:..] style in the debug prints while at it. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210226153204.1270-8-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-03-03drm/i915: Check tgl+ SAGV watermarks properlyVille Syrjälä
We know which WM0 (normal vs. SAGV) we supposedly programmed into the hardware, so just check against that instead of accepting either watermark as valid. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210226153204.1270-7-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-03-03drm/i915: Introduce SAGV transtion watermarkVille Syrjälä
Seems to me that if we calculate WM0 using the bumped up SAGV latency we need to calculate the transition watermark accordingly. Track it alongside the other watermarks. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210226153204.1270-6-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-03-03drm/i915: Stuff SAGV watermark into a sub-structureVille Syrjälä
We'll want a SAGV transition watermark as well. Prepare for that by collecting SAGV wm0 into a sub-strcture. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210226153204.1270-5-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2021-03-03drm/i915: Readout conn_state->max_bpcVille Syrjälä
Populate conn_state->max_bpc with something sensible from the start. Otherwise it's possible that we get to compute_sink_pipe_bpp() with max_bpc==0. The specific scenario goes as follows: 1. Initial connector state allocated with max_bpc==0 2. Trigger a modeset on the crtc feeding the connector, without actually adding the connector to the commit 3. drm_atomic_connector_check() is skipped because the connector has not yet been added, hence conn_state->max_bpc retains its current value 4. drm_atomic_helper_check_modeset() -> drm_atomic_add_affected_connectors() -> the connector is now part of the commit 5. compute_baseline_pipe_bpp() -> MISSING_CASE(max_bpc==0) Note that pipe_bpp itself may not be populated on pre-g4x machines, in which case we just fall back to max_bpc==8 and let .compute_config() limit the resulting pipe_bpp further if necessary. Cc: Daniel Vetter <daniel@ffwll.ch> Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210216160035.4780-1-ville.syrjala@linux.intel.com Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-02-25Merge tag 'drm-next-2021-02-26' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull more drm updates from Dave Airlie: "This is mostly fixes but I missed msm-next pull last week. It's been in drm-next. Otherwise it's a selection of i915, amdgpu and misc fixes, one TTM memory leak, nothing really major stands out otherwise. core: - vblank fence timing improvements dma-buf: - improve error handling ttm: - memory leak fix msm: - a6xx speedbin support - a508, a509, a512 support - various a5xx fixes - various dpu fixes - qseed3lite support for sm8250 - dsi fix for msm8994 - mdp5 fix for framerate bug with cmd mode panels - a6xx GMU OOB race fixes that were showing up in CI - various addition and removal of semicolons - gem submit fix for legacy userspace relocs path amdgpu: - clang warning fix - S0ix platform shutdown/poweroff fix - misc display fixes i915: - color format fix - -Wuninitialised reenabled - GVT ww locking, cmd parser fixes atyfb: - fix build rockchip: - AFBC modifier fix" * tag 'drm-next-2021-02-26' of git://anongit.freedesktop.org/drm/drm: (60 commits) drm/panel: kd35t133: allow using non-continuous dsi clock drm/rockchip: Require the YTR modifier for AFBC drm/ttm: Fix a memory leak drm/drm_vblank: set the dma-fence timestamp during send_vblank_event dma-fence: allow signaling drivers to set fence timestamp dma-buf: heaps: Rework heap allocation hooks to return struct dma_buf instead of fd dma-buf: system_heap: Make sure to return an error if we abort drm/amd/display: Fix system hang after multiple hotplugs (v3) drm/amdgpu: fix shutdown and poweroff process failed with s0ix drm/i915: Nuke INTEL_OUTPUT_FORMAT_INVALID drm/i915: Enable -Wuninitialized drm/amd/display: Remove Assert from dcn10_get_dig_frontend drm/amd/display: Add vupdate_no_lock interrupts for DCN2.1 Revert "drm/amd/display: reuse current context instead of recreating one" drm/amd/pm/swsmu: Avoid using structure_size uninitialized in smu_cmn_init_soft_gpu_metrics fbdev: atyfb: add stubs for aty_{ld,st}_lcd() drm/i915/gvt: Introduce per object locking in GVT scheduler. drm/i915/gvt: Purge dev_priv->gt drm/i915/gvt: Parse default state to update reg whitelist dt-bindings: dp-connector: Drop maxItems from -supply ...
2021-02-24drm/i915/tgl+: Sanitize the DDI LANES/IO and AUX power domain namesImre Deak
In Bspec the TGL TypeC ports are TC1-6, the AUX power well request flags are USBC1-6/TBT1-6, so for clarity use these names in the port power domain names instead of the D-I terminology (which Bspec uses only for the ICL TypeC ports). A domain name should follow the <domain>_<pipe/transcoder/port/aux_ch> format. Add the new aliases based on this, leaving a change to rename all the rest accordingly for a follow-up. No functional change. v2: Add comment to commit log about unifying domain names. (Jose) Cc: Souza Jose <jose.souza@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210222210400.940158-1-imre.deak@intel.com
2021-02-23drm/i915/display: Do not allow DC3CO if PSR SF is enabledGwan-gyeong Mun
Even though GEN12+ HW supports PSR + DC3CO, DMC's HW DC3CO exit mechanism has an issue with using of Selective Fecth and PSR2 manual tracking. And as some GEN12+ platforms (RKL, ADL-S) don't support PSR2 HW tracking, Selective Fetch will be enabled by default on that platforms. Therefore if the system enables PSR Selective Fetch / PSR manual tracking, it does not allow DC3CO dc state, in that case. When this DC3CO exit issue is addressed while PSR Selective Fetch is enabled, this restriction should be removed. v2: Address Jose's review comment. - Fix typo - Move check routine of DC3CO ability to tgl_dc3co_exitline_compute_config() v3: Change the check routine of enablement of psr2 sel fetch. (Jose) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210222213006.1609085-1-gwan-gyeong.mun@intel.com
2021-02-23drm/i915: Nuke INTEL_OUTPUT_FORMAT_INVALIDVille Syrjälä
We tend to use output_format!=RGB as a shorthand for YCbCr, but this fails if we have a disabled crtc where output_format==INVALID. We're now getting some fail from intel_color_check() when we have: hw.enable==false hw.ctm!=NULL output_format==INVALID Let's avoid that by throwing INTEL_OUTPUT_FORMAT_INVALID to the dumpster, and thus everything defaults to RGB when the crtc is disabled. This does beg the deeper question of how much of the state should we in fact be validating when hw/uapi.enable==false. And should we even be doing the uapi->hw copy when uapi.enable==false? So far I've not been able to come up with satisfactory answers for myself, so I'm putting it off for the moment. Cc: Lee Shawn C <shawn.c.lee@intel.com> Fixes: 0aa5c3835c8a ("drm/i915: support two CSC module on gen11 and later") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2964 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205202322.27608-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (cherry picked from commit 7e07c68f06a248441b485249de4c4115cba262cc) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-02-22drm/i915/edp: read sink MSO configuration for eDP 1.4+Jani Nikula
Read and debug log the eDP sink MSO configuration. Do not actually do anything with the information yet besides logging. FIXME: The pixel overlap is present in DisplayID 2.0, but we don't have parsing for that. Assume zero for now. We could also add quirks for non-zero pixel overlap before DisplayID 2.0 parsing. v3: Add placeholder for pixel overlap. v2: Rename intel_dp_mso_init -> intel_edp_mso_init Cc: Nischal Varide <nischal.varide@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/24ef61574e5af12cd86d5b85afbfbd4ac2f9de25.1613054234.git.jani.nikula@intel.com
2021-02-22drm/i915/edp: always add fixed mode to probed modes in ->get_modes()Jani Nikula
Unconditionally add fixed mode to probed modes even if EDID is present and has modes. Prepare for cases where the fixed mode is not present in EDID (such as eDP MSO). Cc: Nischal Varide <nischal.varide@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6979f123f3e4ed948333f1b181202bbced3c3e85.1613054234.git.jani.nikula@intel.com
2021-02-22drm/i915/edp: reject modes with dimensions other than fixed modeJani Nikula
Be more strict about filtering modes for eDP. Cc: Nischal Varide <nischal.varide@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/feb4c3b2b9c4da56a840bdb3c0e7fd0e58ee50de.1613054234.git.jani.nikula@intel.com
2021-02-22drm/i915/display: Set source_support even if panel do not support PSRJosé Roberto de Souza
This will set the right value of source_support when the port encoder/port supports PSR but sink don't. This change will also be needed in future for panel replay as psr struct needs to be initialized even if disconnected or current sink don't support PSR. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209181439.215104-4-jose.souza@intel.com
2021-02-22drm/i915/display: Remove some redundancy around CAN_PSR()José Roberto de Souza
If source_support is set the platform supports PSR so no need to check it again at every CAN_PSR(). Also removing the intel_dp_is_edp() calls, if sink_support is set the sink connected is for sure a eDP panel. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209181439.215104-3-jose.souza@intel.com
2021-02-22drm/i915/display: Only write to register in ↵José Roberto de Souza
intel_psr2_program_trans_man_trk_ctl() There is no support for two pipes one transcoder for PSR and if we had that the current code should not use cpu_transcoder. Also I can't see a scenario where crtc_state->enable_psr2_sel_fetch is set and PSR is not enabled and if by a bug it happens PSR HW will just ignore any value in set in PSR2_MAN_TRK_CTL. So dropping all the rest and keeping the same behavior that we have with intel_psr2_program_plane_sel_fetch(). Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209181439.215104-2-jose.souza@intel.com
2021-02-22drm/i915/display: Rename for_each_intel_encoder.*_can_psr to ↵José Roberto de Souza
for_each_intel_encoder.*_with_psr for_each_intel_encoder.*_"can_psr" sounds strange, in my opinion "with_psr" is better. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209181439.215104-1-jose.souza@intel.com
2021-02-22drm/i915/display: Allow PSR2 selective fetch to be enabled at run-timeJosé Roberto de Souza
Right now CI is blacklisting module reload, so we need to be able to enable PSR2 selective fetch in run time to test this feature before enable it by default. Changes in IGT will also be needed. v2: - Fixed handling of I915_PSR_DEBUG_ENABLE_SEL_FETCH in intel_psr_debug_set() Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209205036.351076-1-jose.souza@intel.com
2021-02-21Merge tag 'drm-next-2021-02-19' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull drm updates from Dave Airlie: "A pretty normal tree, lots of refactoring across the board, ttm, i915, nouveau, and bunch of features in various drivers. docs: - lots of updated docs core: - require crtc to have unique primary plane - fourcc macro fix - PCI bar quirk for bar resizing - don't sent hotplug on error - move vm code to legacy - nuke hose only used on old oboslete alpha dma-buf: - kernel doc updates - improved lock tracking dp/hdmi: - DP-HDMI2.1 protocol converter support ttm: - bo size handling cleanup - release a pinned bo warning - cleanup lru handler - avoid using pages with drm_prime_sg_to_page_addr_arrays cma-helper: - prime/mmap fixes bridge: - add DP support gma500: - remove gma3600 support i915: - try eDP fast/narrow link again with fallback - Intel eDP backlight control - replace display register read/write macros - refactor intel_display.c - display power improvements - HPD code cleanup - Rocketlake display fixes - Power/backlight/RPM fixes - DG1 display fix - IVB/BYT clear residuals security fix again - make i915 mitigations options via parameter - HSW GT1 GPU hangs fixes - DG1 workaround hang fixes - TGL DMAR hang avoidance - Lots of GT fixes - follow on fixes for residuals clear - gen7 per-engine-reset support - HDCP2.2 + HDCP1.4 GEN12 DP MST support - TGL clear color support - backlight refactoring - VRR/Adaptive sync enabling on DP/EDP for TGL+ - async flips for all ilk+ amdgpu: - rework IH ring handling (Vega/Navi) - rework HDP handling (Vega/Navi) - swSMU updates for renoir/vangogh - Sienna Cichild overdrive support - FP16 on DCE8-11 support - GPU reset on navy flounder/vangogh - SMU profile fixes for APU - SR-IOV fixes - Vangogh SMU fixes - fan speed control fixes amdkfd: - config handling fix - buffer free fix - recursive lock warnings fix nouveau: - Turing MMU fault recovery fixes - mDP connectors reporting fix - audio locking fixes - rework engines/instances code to support new scheme tegra: - VIC newer firmware support - display/gr2d fixes for older tegra - pm reference leak fix mediatek: - SOC MT8183 support - decouple sub driver + share mtk mutex driver radeon: - PCI resource fix for some platforms ingenic: - pm support - 8-bit delta RGB panels vmwgfx: - managed driver helpers vc4: - BCM2711 DSI1 support - converted to atomic helpers - enable 10/12 bpc outputs - gem prime mmap helpers - CEC fix omap: - use degamma table - CTM support - rework DSI support imx: - stack usage fixes - drm managed support - imx-tve clock provider leak fix - rcar-du: - default mode fixes - conversion to managed API hisilicon: - use simple encoder vkms: - writeback connector support d3: - BT2020 support" * tag 'drm-next-2021-02-19' of git://anongit.freedesktop.org/drm/drm: (1459 commits) drm/amdgpu: Set reference clock to 100Mhz on Renoir (v2) drm/radeon: OLAND boards don't have VCE drm/amdkfd: Fix recursive lock warnings drm/amd/display: Add FPU wrappers to dcn21_validate_bandwidth() drm/amd/display: Fix potential integer overflow drm/amdgpu/display: remove hdcp_srm sysfs on device removal drm/amdgpu: fix CGTS_TCC_DISABLE register offset on gfx10.3 drm/i915/gt: Correct surface base address for renderclear drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling drm/nouveau/top/ga100: initial support drm/nouveau/top: add ioctrl/nvjpg drm/nouveau/privring: rename from ibus drm/nouveau/nvkm: remove nvkm_subdev.index drm/nouveau/nvkm: determine subdev id/order from layout drm/nouveau/vic: switch to instanced constructor drm/nouveau/sw: switch to instanced constructor drm/nouveau/sec2: switch to instanced constructor drm/nouveau/sec: switch to instanced constructor drm/nouveau/pm: switch to instanced constructor drm/nouveau/nvenc: switch to instanced constructor ...
2021-02-20drm/i915/vbt: update DP max link rate tableLee Shawn C
According to Bspec #20124, max link rate table for DP was updated at BDB version 230. Max link rate can support upto UHBR. After migrate to BDB v230, the definition for LBR, HBR2 and HBR3 were changed. For backward compatibility. If BDB version was from 216 to 229. Driver have to follow original rule to configure DP max link rate value from VBT. v2: split the mapping table to two for old and new BDB definition. v3: return link rate instead of assigning it. v4: remove the useless variable. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> [vsyrjala: Try to retain the comment that VBT version 216 added some of this] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210218052333.16109-1-shawn.c.lee@intel.com
2021-02-18drm/i915: Wait for scanout to stop when sanitizing planesVille Syrjälä
When we sanitize planes let's wait for the scanout to stop before we let the subsequent code tear down the ggtt mappings and whatnot. Cures an underrun on my ivb when I boot with VT-d enabled and the BIOS fb gets thrown out due to stolen being considered unusable with VT-d active. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210217162050.13803-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2021-02-18drm/i915: Nuke INTEL_OUTPUT_FORMAT_INVALIDVille Syrjälä
We tend to use output_format!=RGB as a shorthand for YCbCr, but this fails if we have a disabled crtc where output_format==INVALID. We're now getting some fail from intel_color_check() when we have: hw.enable==false hw.ctm!=NULL output_format==INVALID Let's avoid that by throwing INTEL_OUTPUT_FORMAT_INVALID to the dumpster, and thus everything defaults to RGB when the crtc is disabled. This does beg the deeper question of how much of the state should we in fact be validating when hw/uapi.enable==false. And should we even be doing the uapi->hw copy when uapi.enable==false? So far I've not been able to come up with satisfactory answers for myself, so I'm putting it off for the moment. Cc: Lee Shawn C <shawn.c.lee@intel.com> Fixes: 0aa5c3835c8a ("drm/i915: support two CSC module on gen11 and later") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2964 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205202322.27608-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-02-17drm: Switch to %p4cc format modifierSakari Ailus
Switch DRM drivers from drm_get_format_name() to %p4cc. This gets rid of a large number of temporary variables at the same time. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210216155723.17109-4-sakari.ailus@linux.intel.com
2021-02-17drm/i915: Disallow plane x+w>stride on ilk+ with X-tilingVille Syrjälä
ilk+ planes get notably unhappy when the plane x+w exceeds the stride. This wasn't a problem previously because we always aligned SURF to the closest tile boundary so the x offset never got particularly large. But now with async flips we have to align to 256KiB instead and thus this becomes a real issue. On ilk/snb/ivb it looks like the accesses just wrap early to the next tile row when scanout goes past the SURF+n*stride boundary, hsw/bdw suffer more heavily and start to underrun constantly. i965/g4x appear to be immune. vlv/chv I've not yet checked. Let's borrow another trick from the skl+ code and search backwards for a better SURF offset in the hopes of getting the x offset below the limit. IIRC when I ran into a similar issue on skl years ago it was causing the hardware to fall over pretty hard as well. And let's be consistent and include i965/g4x in the check as well, just in case I just got super lucky somehow when I wasn't able to reproduce the issue. Not that it really matters since we still use 4k SURF alignment for i965/g4x anyway. Fixes: 6ede6b0616b2 ("drm/i915: Implement async flips for vlv/chv") Fixes: 4bb18054adc4 ("drm/i915: Implement async flip for ilk/snb") Fixes: 2a636e240c77 ("drm/i915: Implement async flip for ivb/hsw") Fixes: cda195f13abd ("drm/i915: Implement async flips for bdw") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209021918.16234-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 59fb8218c8e5001f854e7d5fdb5fb135cba58102) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo also exported some functions from intel_display.c during backport]
2021-02-16drm/i915: s/dev_priv/i915/ for the remainder of DDI clock routingVille Syrjälä
Convert the remaining 'dev_priv's to 'i915's in the DDI clock routing functions. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-16-ville.syrjala@linux.intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
2021-02-16drm/i915: Relocate icl_sanitize_encoder_pll_mapping()Ville Syrjälä
Move icl_sanitize_encoder_pll_mapping() out from the middle of the .{enable,disable}_clock() functions. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-15-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Use .disable_clock() for pll sanitationVille Syrjälä
Instead of every new platform having yet another masive copy of the whole PLL sanitation code, let's just reuse the .disable_clock() hook for this purpose. We do need to plug this into the ICL+ DSI code for that, but fortunately it already has a suitable function we can use. We do lose the debug message though on account of not bothering to check if the clock is actually enabled or not before turning it off. We could introduce yet another vfunc to query the current state, but not sure it's worth the hassle? Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-14-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Split adl-s/rkl from icl_ddi_combo_{enable,disable}_clock()Ville Syrjälä
Since .{enable,disable}_clock() are already vfuncs it's a bit silly to have if-ladders inside them. Just provide specialized version for adl-s and rkl so we don't need any of that. v2: s/dev_priv/i915/ (Lucas) Fix typos in platform names (Lucas) Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-13-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Extract _cnl_ddi_{enable,disable}_clock()Ville Syrjälä
All the DPCLKA_CFGCR handling follows a common pattern. Let's extract that to a small helper that just takes a few parameters each caller can customize. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-12-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Sprinkle WARN(!pll) into icl/dg1 .clock_enable()Ville Syrjälä
The other DDI .enable_clock() functions are trying to protect us against pll==NULL. A bit tempted to throw out all the WARNs as just unnecessary noise, but I guess they might have some use when poking around the shared_dpll code (not sure it wouldn't oops elsewhere though). So let's unify it all and sprinkle in the missing WARNs for icl/dg1. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-11-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Sprinkle a few missing locks around shared DDI clock registersVille Syrjälä
The current code attempts to protect the RMWs into global clock routing registers with a mutex, but forgets to do so in a few places. Let's remedy that. Note that at the moment we serialize all modesets onto single wq, so this shouldn't actually matter. But maybe one day we wish to attempt parallel modesets again... Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-10-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Use intel_de_rmw() for DDI clock routingVille Syrjälä
The DDI clock routing programming is riddled with shared registers, forcing us to do a lot of RMW. Switch over to intel_de_rmw() to make that a bit less obnoxious. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-9-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Extract icl+ .{enable,disable}_clock() vfuncsVille Syrjälä
For ICL+ we have several styles of clock routing for DDIs: 1) TC DDI + TC PHY -> needs DDI_CLK_SEL==MG/TBT part form intel_ddi_clk_{select,disable}() and ICL_DPCLKA_CFGCR0_TC_CLK_OFF part form icl_{map,unmap}_plls_to_ports() 2) ICL/TGL combo DDI + combo PHY -> just need the stuff from icl_{map,unmap}_plls_to_ports() 3) JSL/EHL TC DDI + combo PHY -> needs DDI_CLK_SEL==MG part from intel_ddi_clk_{select,disable}() and the full combo style clock selection from icl_{map,unmap}_plls_to_ports() 4) ADLS/RKL -> these use both TC and combo DDIs with combo PHYs, however they always use the full combo style clock selection as per icl_{map,unmap}_plls_to_ports() and do not use DDI_CLK_SEL at all, thus get treated the same as 2) We extract all that from the current mess in the following way: 1) icl_ddi_tc_{enable,disable}_clock() 2) icl_ddi_combo_{enable,disable}_clock() 3) jsl_ddi_tc_{enable,disable}_clock() 4) for now we reuse icl_ddi_combo_{enable,disable}_clock() here v2: s/dev_priv/i915/ (Lucas) Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-8-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Convert DG1 over to .{enable,disable}_clock()Ville Syrjälä
Replace dg1_{map,unmap}_plls_to_ports() with the appropriate encoder vfuncs. And let's relocate the disable function next to the enable function while at it. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-7-ville.syrjala@linux.intel.com
2021-02-16drm/i195: Extract cnl_ddi_{enable,disable}_clock()Ville Syrjälä
Extract the DDI clock routing for CNL into the new vfuncs. v2: s/dev_priv/i915/ (Lucas) Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-6-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Extract skl_ddi_{enable,disable}_clock()Ville Syrjälä
Extract the DDI clock routing clode for skl/derivatives into the new encoder vfuncs. v2: s/dev_priv/i915/ (Lucas) Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-5-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Extract hsw_ddi_{enable,disable}_clock()Ville Syrjälä
Yank out the HSW/BDW code from intel_ddi_clk_{select,disable}() and put it into the new encoder .{enable,disable}_clock() vfuncs. v2: s/dev_priv/i915/ (Lucas) v3: Deal with FDI Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> #v2 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-4-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Introduce .{enable,disable}_clock() encoder vfuncsVille Syrjälä
The current code dealing with the clock routing for DDI encoders is a maintenance nightmare. Let's start cleaning it up by allowing the encoder to provide vfuncs for enablign/disabling the clock. We leave them initially unimplemented, falling back to the old if-else approach. v2: Convert the FDI enable sequence Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> #v2 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-3-ville.syrjala@linux.intel.com
2021-02-16drm/i915: Use intel_ddi_clk_select() for FDIVille Syrjälä
We want to put all DDI clock routing code into one place. Unify the FDI enable sequence to use the standard function instead of hand rolling its own. The disable sequence already uses the normal thing. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-2-ville.syrjala@linux.intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
2021-02-13drm/i915: move intel_init_audio_hooks inside displayLucas De Marchi
intel_init_audio_hooks() sets up hooks in the display struct and only makes sense when we have display. Move it inside intel_init_display_hooks() so it isn't called when we don't have display. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20210213042756.953007-4-lucas.demarchi@intel.com
2021-02-13drm/i915/display: move register functions to display/Lucas De Marchi
Now that all display-related functions are grouped in i915_driver_register(), move them to display/ so we reduce the amount of display calls from the rest of the driver. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20210213042756.953007-3-lucas.demarchi@intel.com
2021-02-12drm/i915/gen9_bc: Add W/A for missing STRAP config on TGP PCH + CML combosLyude Paul
Apparently the new gen9_bc platforms that Intel has introduced don't provide us with a STRAP config register to read from for initializing DDI B, C, and D detection. So, workaround this by hard-coding our strap config in intel_setup_outputs(). Changes since v4: * Split this into it's own commit Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> [originally from Tejas's work] Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209212832.1401815-5-lyude@redhat.com
2021-02-12drm/i915/gen9_bc: Introduce HPD pin mappings for TGP PCH + CML combosLyude Paul
Next, let's start introducing the HPD pin mappings for Intel's new gen9_bc platform in order to make hotplugging display connectors work. Since gen9_bc is just a TGP PCH along with a CML CPU, except with the same HPD mappings as ICL, we simply add a skl_hpd_pin function that is shared between gen9 and gen9_bc which handles both the traditional gen9 HPD pin mappings and the Icelake HPD pin mappings that gen9_bc uses. Changes since v4: * Split this into its own commit * Introduce skl_hpd_pin() like vsyrjala suggested and use that instead of sticking our HPD pin mappings in TGP code Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> [originally from Tejas's work] Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209212832.1401815-4-lyude@redhat.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-03 23:08:31 +0000