summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2021-02-22drm/i915/display: Rename for_each_intel_encoder.*_can_psr to ↵José Roberto de Souza4-13/+13
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 Souza2-3/+6
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-22drm/i915/gvt: Introduce per object locking in GVT scheduler.Zhi Wang1-9/+40
To support ww locking and per-object implemented in i915, GVT scheduler needs to be refined. Most of the changes are located in shadow batch buffer, shadow wa context in GVT-g, where use quite a lot of i915 gem object APIs. v2: - Adjust the usage of ww lock on context pin/unpin. (maarten) - Rebase the patch on the newest staging branch. Fixes: 6b05030496f7 ("drm/i915: Convert i915_gem_object/client_blt.c to use ww locking as well, v2.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1610314985-26065-1-git-send-email-zhi.wang.linux@gmail.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2021-02-22drm/i915/gvt: Purge dev_priv->gtChris Wilson2-7/+4
Use the right intel_gt stored as a backpointer in intel_vgpu. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210129004933.29755-2-chris@chris-wilson.co.uk Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2021-02-22drm/i915/gvt: Parse default state to update reg whitelistChris Wilson1-73/+20
Rather than break existing context objects by incorrectly forcing them to rogue cache coherency and trying to assert a new mapping, read the reg whitelist from the default context image. And use gvt->gt, never &dev_priv->gt. Fixes: 493f30cd086e ("drm/i915/gvt: parse init context to update cmd accessible reg whitelist") Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Cc: Wang Zhi <zhi.a.wang@intel.com> Cc: Yan Zhao <yan.y.zhao@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210129004933.29755-1-chris@chris-wilson.co.uk
2021-02-22Merge tag 'drm-next-2021-02-19' of git://anongit.freedesktop.org/drm/drmLinus Torvalds239-20862/+25051
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-22Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds1-6/+6
Pull KVM updates from Paolo Bonzini: "x86: - Support for userspace to emulate Xen hypercalls - Raise the maximum number of user memslots - Scalability improvements for the new MMU. Instead of the complex "fast page fault" logic that is used in mmu.c, tdp_mmu.c uses an rwlock so that page faults are concurrent, but the code that can run against page faults is limited. Right now only page faults take the lock for reading; in the future this will be extended to some cases of page table destruction. I hope to switch the default MMU around 5.12-rc3 (some testing was delayed due to Chinese New Year). - Cleanups for MAXPHYADDR checks - Use static calls for vendor-specific callbacks - On AMD, use VMLOAD/VMSAVE to save and restore host state - Stop using deprecated jump label APIs - Workaround for AMD erratum that made nested virtualization unreliable - Support for LBR emulation in the guest - Support for communicating bus lock vmexits to userspace - Add support for SEV attestation command - Miscellaneous cleanups PPC: - Support for second data watchpoint on POWER10 - Remove some complex workarounds for buggy early versions of POWER9 - Guest entry/exit fixes ARM64: - Make the nVHE EL2 object relocatable - Cleanups for concurrent translation faults hitting the same page - Support for the standard TRNG hypervisor call - A bunch of small PMU/Debug fixes - Simplification of the early init hypercall handling Non-KVM changes (with acks): - Detection of contended rwlocks (implemented only for qrwlocks, because KVM only needs it for x86) - Allow __DISABLE_EXPORTS from assembly code - Provide a saner follow_pfn replacements for modules" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (192 commits) KVM: x86/xen: Explicitly pad struct compat_vcpu_info to 64 bytes KVM: selftests: Don't bother mapping GVA for Xen shinfo test KVM: selftests: Fix hex vs. decimal snafu in Xen test KVM: selftests: Fix size of memslots created by Xen tests KVM: selftests: Ignore recently added Xen tests' build output KVM: selftests: Add missing header file needed by xAPIC IPI tests KVM: selftests: Add operand to vmsave/vmload/vmrun in svm.c KVM: SVM: Make symbol 'svm_gp_erratum_intercept' static locking/arch: Move qrwlock.h include after qspinlock.h KVM: PPC: Book3S HV: Fix host radix SLB optimisation with hash guests KVM: PPC: Book3S HV: Ensure radix guest has no SLB entries KVM: PPC: Don't always report hash MMU capability for P9 < DD2.2 KVM: PPC: Book3S HV: Save and restore FSCR in the P9 path KVM: PPC: remove unneeded semicolon KVM: PPC: Book3S HV: Use POWER9 SLBIA IH=6 variant to clear SLB KVM: PPC: Book3S HV: No need to clear radix host SLB before loading HPT guest KVM: PPC: Book3S HV: Fix radix guest SLB side channel KVM: PPC: Book3S HV: Remove support for running HPT guest on RPT host without mixed mode support KVM: PPC: Book3S HV: Introduce new capability for 2nd DAWR KVM: PPC: Book3S HV: Add infrastructure to support 2nd DAWR ...
2021-02-20drm/i915/vbt: update DP max link rate tableLee Shawn C2-21/+60
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ä1-0/+1
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ä3-4/+1
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/i915: Remove dead code from skl_pipe_wm_get_hw_state()José Roberto de Souza1-3/+0
There is nothing else to be executed after this if block. Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210212182201.155043-2-jose.souza@intel.com
2021-02-17drm/i915: Enable -WuninitializedNathan Chancellor1-1/+0
-Wunintialized was disabled in commit c5627461490e ("drm/i915: Disable -Wuninitialized") because there were two warnings that were false positives. The first was due to DECLARE_WAIT_QUEUE_HEAD_ONSTACK, which was fixed in LLVM 9.0.0. The second was in busywait_stop, which was fixed in LLVM 10.0.0 (issue 415). The kernel's minimum version for LLVM is 10.0.1 so this warning can be safely enabled, where it has already caught a couple bugs. Link: https://github.com/ClangBuiltLinux/linux/issues/220 Link: https://github.com/ClangBuiltLinux/linux/issues/415 Link: https://github.com/ClangBuiltLinux/linux/issues/499 Link: https://github.com/llvm/llvm-project/commit/2e040398f8d691cc378c1abb098824ff49f3f28f Link: https://github.com/llvm/llvm-project/commit/c667cdc850c2aa821ffeedbc08c24bc985c59edd Fixes: c5627461490e ("drm/i915: Disable -Wuninitialized") References: 2ea4a7ba9bf6 ("drm/i915/gt: Avoid uninitialized use of rpcurupei in frequency_show") References: 2034c2129bc4 ("drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state") Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20210216212953.24458-1-nathan@kernel.org
2021-02-17drm: Switch to %p4cc format modifierSakari Ailus3-31/+19
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/gt: Correct surface base address for renderclearChris Wilson1-1/+1
The surface_state_base is an offset into the batch, so we need to pass the correct batch address for STATE_BASE_ADDRESS. Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.7+ Link: https://patchwork.freedesktop.org/patch/msgid/20210210122728.20097-1-chris@chris-wilson.co.uk (cherry picked from commit 1914911f4aa08ddc05bae71d3516419463e0c567) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-02-17drm/i915: Disallow plane x+w>stride on ilk+ with X-tilingVille Syrjälä3-6/+39
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ä1-19/+19
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ä1-56/+56
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ä2-90/+3
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ä1-29/+62
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ä1-64/+44
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ä1-0/+6
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ä1-0/+8
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ä1-49/+28
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ä1-58/+99
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ä1-22/+21
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ä1-20/+42
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ä1-15/+38
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ä3-6/+31
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ä4-9/+32
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ä3-8/+8
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-16kbuild: use always-y instead of extra-yMasahiro Yamada1-1/+1
As commit d0e628cd817f ("kbuild: doc: clarify the difference between extra-y and always-y") explained, extra-y should be used for listing the prerequisites of vmlinux. These targets are not related to vmlinux. always-y is a better fix. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org>
2021-02-13drm/i915: move intel_init_audio_hooks inside displayLucas De Marchi2-2/+1
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 Marchi3-43/+58
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-13drm/i915: group display-related register callsLucas De Marchi1-30/+34
intel_gt_driver_register() may be called earlier than intel_opregion_register() and acpi_video_register(), so move it up. intel_display_debugfs_register() may be called later, together with the other display-related initializations. There is a slight change in behavior that sysfs files will show up before the display-related debugfs files, but that shouldn't be a problem - userspace shouldn't be relying in debugfs. This allows us to group all the display-related calls under a single check for "HAS_DISPLAY()" that can be later moved to a better place. 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-2-lucas.demarchi@intel.com
2021-02-13drm/i915: stop registering if drm_dev_register() failsLucas De Marchi1-9/+11
If drm_dev_register() fails there is no reason to continue registering the driver and initializing. 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-1-lucas.demarchi@intel.com
2021-02-13drm/i915: Try to detect sudden loss of MMIO accessMatt Roper1-0/+16
In rare circumstances bugs in PCI programming, broken BIOS, or failing hardware can cause the CPU to lose access to the MMIO BAR on dgfx platforms. This is a pretty catastrophic failure since all register reads come back with values of 0xFFFFFFFF. Let's check for this special case while doing our usual checks for unclaimed registers; the FPGA_DBG register we use for those checks on modern platforms has some unused bits that will always read back as 0 when things are behaving properly; we can use them as canaries to detect when MMIO itself has suddenly broken and try to print a more informative error message in the logs. v2: Let the detection function still return 'true' if we've lost our MMIO access. We'll still get an extra false positive message about an unclaimed register access, but we'll still honor the 'mmio_debug' limit and not spam the log. (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210212211925.3418280-2-matthew.d.roper@intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
2021-02-13drm/i915: FPGA_DBG is display-specificMatt Roper3-4/+4
Although the bspec's description doesn't make it very clear, the hardware architects have confirmed that the FPGA_DBG register that we use to check for unclaimed MMIO accesses is display-specific and will only properly flag unclaimed MMIO transactions for registers in the display range. If a platform doesn't have display, FPGA_DBG itself will not be available and should not be checked. Let's move the feature flag into intel_device_info.display to more accurately reflect this. Given that we now know FPGA_DBG is display-specific, it could be argued that we should only check it on out intel_de_*() functions. However let's not make that change right now; keeping the checks in all of the existing locations still helps us catch cases where regular intel_uncore_*() functions use bad MMIO offset math / base addresses and accidentally wind up landing within an unused area within the display MMIO range. It will also help catch cases where userspace-initiated MMIO (e.g., IGT's intel_reg tool) attempt to read bad offsets within the display range. v2: Add missing hunk with the update to the HAS_FPGA_DBG_UNCLAIMED macro. (CI) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210212222049.3516344-1-matthew.d.roper@intel.com
2021-02-13drm/i915/gen9_bc: Add W/A for missing STRAP config on TGP PCH + CML combosLyude Paul1-1/+8
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-13drm/i915/gen9_bc: Introduce HPD pin mappings for TGP PCH + CML combosLyude Paul1-0/+10
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
2021-02-12Merge tag 'kvmarm-5.12' of ↵Paolo Bonzini11-103/+339
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 updates for Linux 5.12 - Make the nVHE EL2 object relocatable, resulting in much more maintainable code - Handle concurrent translation faults hitting the same page in a more elegant way - Support for the standard TRNG hypervisor call - A bunch of small PMU/Debug fixes - Allow the disabling of symbol export from assembly code - Simplification of the early init hypercall handling
2021-02-12i915/perf: Drop the check for report reason in OAUmesh Nerlige Ramappa1-5/+0
After fixing the OA_TAIL_PTR corruption, there are no more reports with reason field of zero. Drop the check for report reason. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210210190106.8586-1-umesh.nerlige.ramappa@intel.com
2021-02-12drm/i915/debugfs: HDCP capability enc NULL checkAnshuman Gupta1-3/+14
DP-MST connector encoder initializes at modeset Adding a connector->encoder NULL check in order to avoid any NULL pointer dereference. intel_hdcp_enable() already handle this but debugfs can also invoke the intel_{hdcp,hdcp2_capable}. Handling it gracefully. v2: - Use necessary lock and NULL check in i915_hdcp_sink_capability_show. [Imre] Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210211140502.22786-1-anshuman.gupta@intel.com
2021-02-12drm/i915/display: fix comment on skl strapsLucas De Marchi1-2/+3
We are not checking for specific SKUs and feedback from HW team is that it may not work since it was supposed to be fixed by the same time straps stopped to be used. So, just update comment. v2: Instead of removing the check, just update the comment since feedback from HW team was that it actually may not work Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200625001120.22810-3-lucas.demarchi@intel.com
2021-02-12drm/i915/gen9_bc: Introduce TGP PCH DDC pin mappingsLyude Paul2-0/+29
With the introduction of gen9_bc, where Intel combines Cometlake CPUs with a Tigerpoint PCH, we'll need to introduce new DDC pin mappings for this platform in order to make all of the display connectors work. So, let's do that. Changes since v4: * Split this into it's own patch - vsyrjala Changes since v5: * Rename gen9bc_port_to_ddc_pin() to gen9bc_tgp_port_to_ddc_pin() 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-3-lyude@redhat.com
2021-02-12drm/i915/gen9_bc: Recognize TGP PCH + CML combosLyude Paul1-1/+2
Since Intel has introduced the gen9_bc platform, a combination of Tigerpoint PCHs and CML CPUs, let's recognize such platforms as valid and avoid WARNing on them. Changes since v4: * Split this into it's own patch - vsyrjala 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-2-lyude@redhat.com
2021-02-11drm/i915/display: Handle lane polarity for DDI portUma Shankar3-0/+22
Lane Reversal is required for some of the DDI ports. This information is populated in VBT and driver should read the same and set the polarity while enabling the port. This patch handles the same. It helps fix a display blankout issue on DP ports on certain platforms. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210211114209.23866-1-uma.shankar@intel.com
2021-02-10drm/i915/display: Add DDR5 and LPDDR5 BW buddy page entriesJosé Roberto de Souza1-0/+8
Set the right BW buddy page mask for new memory types. BSpec: 49218 Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209174238.153278-1-jose.souza@intel.com
2021-02-10drm/i915: Fix overlay frontbuffer trackingVille Syrjälä1-9/+8
We don't have a persistent fb holding a reference to the frontbuffer object, so every time we do the get+put we throw the frontbuffer object immediately away. And so the next time around we get a pristine frontbuffer object with bits==0 even for the old vma. This confuses the frontbuffer tracking code which understandably expects the old frontbuffer to have the overlay's bit set. Fix this by hanging on to the frontbuffer reference until the next flip. And just to make this a bit more clear let's track the frontbuffer explicitly instead of just grabbing it via the old vma. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1136 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209021918.16234-2-ville.syrjala@linux.intel.com Fixes: 8e7cb1799b4f ("drm/i915: Extract intel_frontbuffer active tracking") Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 553c23bdb4775130f333f07a51b047276bc53f79) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-02-10drm/i915: Warn when releasing a frontbuffer while in useVille Syrjälä1-0/+2
Let's scream if we are about to release a frontbuffer which is still in use. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209021918.16234-3-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2021-02-10drm/i915: Fix overlay frontbuffer trackingVille Syrjälä1-9/+8
We don't have a persistent fb holding a reference to the frontbuffer object, so every time we do the get+put we throw the frontbuffer object immediately away. And so the next time around we get a pristine frontbuffer object with bits==0 even for the old vma. This confuses the frontbuffer tracking code which understandably expects the old frontbuffer to have the overlay's bit set. Fix this by hanging on to the frontbuffer reference until the next flip. And just to make this a bit more clear let's track the frontbuffer explicitly instead of just grabbing it via the old vma. Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1136 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209021918.16234-2-ville.syrjala@linux.intel.com Fixes: 8e7cb1799b4f ("drm/i915: Extract intel_frontbuffer active tracking") Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-17 05:43:05 +0300