aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_pm.c
AgeCommit message (Collapse)AuthorFilesLines
2022-05-31drm/i915/pvc: Add initial PVC workaroundsStuart Summers1-1/+15
Bspec: 64027 Signed-off-by: Stuart Summers <stuart.summers@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220527163348.1936146-3-matthew.d.roper@intel.com
2022-05-25Merge tag 'drm-next-2022-05-25' of git://anongit.freedesktop.org/drm/drmLinus Torvalds1-290/+255
Pull drm updates from Dave Airlie: "Intel have enabled DG2 on certain SKUs for laptops, AMD has started some new GPU support, msm has user allocated VA controls dma-buf: - add dma_resv_replace_fences - add dma_resv_get_singleton - make dma_excl_fence private core: - EDID parser refactorings - switch drivers to drm_mode_copy/duplicate - DRM managed mutex initialization display-helper: - put HDMI, SCDC, HDCP, DSC and DP into new module gem: - rework fence handling ttm: - rework bulk move handling - add common debugfs for resource managers - convert to kvcalloc format helpers: - support monochrome formats - RGB888, RGB565 to XRGB8888 conversions fbdev: - cfb/sys_imageblit fixes - pagelist corruption fix - create offb platform device - deferred io improvements sysfb: - Kconfig rework - support for VESA mode selection bridge: - conversions to devm_drm_of_get_bridge - conversions to panel_bridge - analogix_dp - autosuspend support - it66121 - audio support - tc358767 - DSI to DPI support - icn6211 - PLL/I2C fixes, DT property - adv7611 - enable DRM_BRIDGE_OP_HPD - anx7625 - fill ELD if no monitor - dw_hdmi - add audio support - lontium LT9211 support, i.MXMP LDB - it6505: Kconfig fix, DPCD set power fix - adv7511 - CEC support for ADV7535 panel: - ltk035c5444t, B133UAN01, NV3052C panel support - DataImage FG040346DSSWBG04 support - st7735r - DT bindings fix - ssd130x - fixes i915: - DG2 laptop PCI-IDs ("motherboard down") - Initial RPL-P PCI IDs - compute engine ABI - DG2 Tile4 support - DG2 CCS clear color compression support - DG2 render/media compression formats support - ATS-M platform info - RPL-S PCI IDs added - Bump ADL-P DMC version to v2.16 - Support static DRRS - Support multiple eDP/LVDS native mode refresh rates - DP HDR support for HSW+ - Lots of display refactoring + fixes - GuC hwconfig support and query - sysfs support for multi-tile - fdinfo per-client gpu utilisation - add geometry subslices query - fix prime mmap with LMEM - fix vm open count and remove vma refcounts - contiguous allocation fixes - steered register write support - small PCI BAR enablement - GuC error capture support - sunset igpu legacy mmap support for newer devices - GuC version 70.1.1 support amdgpu: - Initial SoC21 support - SMU 13.x enablement - SMU 13.0.4 support - ttm_eu cleanups - USB-C, GPUVM updates - TMZ fixes for RV - RAS support for VCN - PM sysfs code cleanup - DC FP rework - extend CG/PG flags to 64-bit - SI dpm lockdep fix - runtime PM fixes amdkfd: - RAS/SVM fixes - TLB flush fixes - CRIU GWS support - ignore bogus MEC signals more efficiently msm: - Fourcc modifier for tiled but not compressed layouts - Support for userspace allocated IOVA (GPU virtual address) - DPU: DSC (Display Stream Compression) support - DP: eDP support - DP: conversion to use drm_bridge and drm_bridge_connector - Merge DPU1 and MDP5 MDSS driver - DPU: writeback support nouveau: - make some structures static - make some variables static - switch to drm_gem_plane_helper_prepare_fb radeon: - misc fixes/cleanups mxsfb: - rework crtc mode setting - LCDIF CRC support etnaviv: - fencing improvements - fix address space collisions - cleanup MMU reference handling gma500: - GEM/GTT improvements - connector handling fixes komeda: - switch to plane reset helper mediatek: - MIPI DSI improvements omapdrm: - GEM improvements qxl: - aarch64 support vc4: - add a CL submission tracepoint - HDMI YUV support - HDMI/clock improvements - drop is_hdmi caching virtio: - remove restriction of non-zero blob types vmwgfx: - support for cursormob and cursorbypass 4 - fence improvements tidss: - reset DISPC on startup solomon: - SPI support - DT improvements sun4i: - allwinner D1 support - drop is_hdmi caching imx: - use swap() instead of open-coding - use devm_platform_ioremap_resource - remove redunant initializations ast: - Displayport support rockchip: - Refactor IOMMU initialisation - make some structures static - replace drm_detect_hdmi_monitor with drm_display_info.is_hdmi - support swapped YUV formats, - clock improvements - rk3568 support - VOP2 support mediatek: - MT8186 support tegra: - debugabillity improvements" * tag 'drm-next-2022-05-25' of git://anongit.freedesktop.org/drm/drm: (1740 commits) drm/i915/dsi: fix VBT send packet port selection for ICL+ drm/i915/uc: Fix undefined behavior due to shift overflowing the constant drm/i915/reg: fix undefined behavior due to shift overflowing the constant drm/i915/gt: Fix use of static in macro mismatch drm/i915/audio: fix audio code enable/disable pipe logging drm/i915: Fix CFI violation with show_dynamic_id() drm/i915: Fix 'mixing different enum types' warnings in intel_display_power.c drm/i915/gt: Fix build error without CONFIG_PM drm/msm/dpu: handle pm_runtime_get_sync() errors in bind path drm/msm/dpu: add DRM_MODE_ROTATE_180 back to supported rotations drm/msm: don't free the IRQ if it was not requested drm/msm/dpu: limit writeback modes according to max_linewidth drm/amd: Don't reset dGPUs if the system is going to s2idle drm/amdgpu: Unmap legacy queue when MES is enabled drm: msm: fix possible memory leak in mdp5_crtc_cursor_set() drm/msm: Fix fb plane offset calculation drm/msm/a6xx: Fix refcount leak in a6xx_gpu_init drm/msm/dsi: don't powerup at modeset time for parade-ps8640 drm/rockchip: Change register space names in vop2 dt-bindings: display: rockchip: make reg-names mandatory for VOP2 ...
2022-05-23Merge tag 'drm-intel-next-2022-05-20' of ↵Tvrtko Ursulin1-5/+24
git://anongit.freedesktop.org/drm/drm-intel into drm-intel-gt-next drm/i915 drm-intel-next -> drm-intel-gt-next cross-merge sync Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> # Conflicts: # drivers/gpu/drm/i915/gt/intel_rps.c # drivers/gpu/drm/i915/i915_vma.c From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87y1ywbh5y.fsf@intel.com
2022-05-20drm/i915/pcode: Extend pcode functions for multiple gt'sAshutosh Dixit1-5/+5
Each gt contains an independent instance of pcode. Extend pcode functions to interface with pcode on different gt's. To avoid creating dependency of display functionality on intel_gt, pcode function interfaces are exposed in terms of uncore rather than intel_gt. Callers have been converted to pass in the appropritate (i915 or intel_gt) uncore to the pcode functions. v2: Expose pcode functions in terms of uncore rather than gt (Jani/Rodrigo) v3: Retain previous function names to eliminate needless #defines (Rodrigo) v4: Move out i915_pcode_init() to a separate patch (Tvrtko) Remove duplicated drm_err/drm_dbg from intel_pcode_init() (Tvrtko) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220519085732.1276255-2-tvrtko.ursulin@linux.intel.com [tursulin: fixup merge conflict]
2022-05-19drm/i915/dg2: Extend Wa_22010954014 to DG2-G11 and DG2-G12Swathi Dhanavanthri1-4/+3
Signed-off-by: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220517201338.7291-1-swathi.dhanavanthri@intel.com
2022-05-04drm/i915: Fix -Wstringop-overflow warning in call to intel_read_wm_latency()Gustavo A. R. Silva1-1/+1
Fix the following -Wstringop-overflow warnings when building with GCC-11: drivers/gpu/drm/i915/intel_pm.c:3106:9: warning: ‘intel_read_wm_latency’ accessing 16 bytes in a region of size 10 [-Wstringop-overflow=] 3106 | intel_read_wm_latency(dev_priv, dev_priv->wm.pri_latency); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/intel_pm.c:3106:9: note: referencing argument 2 of type ‘u16 *’ {aka ‘short unsigned int *’} drivers/gpu/drm/i915/intel_pm.c:2861:13: note: in a call to function ‘intel_read_wm_latency’ 2861 | static void intel_read_wm_latency(struct drm_i915_private *dev_priv, | ^~~~~~~~~~~~~~~~~~~~~ by removing the over-specified array size from the argument declarations. It seems that this code is actually safe because the size of the array depends on the hardware generation, and the function checks for that. Notice that wm can be an array of 5 elements: drivers/gpu/drm/i915/intel_pm.c:3109: intel_read_wm_latency(dev_priv, dev_priv->wm.pri_latency); or an array of 8 elements: drivers/gpu/drm/i915/intel_pm.c:3131: intel_read_wm_latency(dev_priv, dev_priv->wm.skl_latency); and the compiler legitimately complains about that. This helps with the ongoing efforts to globally enable -Wstringop-overflow. Link: https://github.com/KSPP/linux/issues/181 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2022-04-20drm/i915: program wm blocks to at least blocks required per lineVinod Govindapillai1-0/+19
In configurations with single DRAM channel, for usecases like 4K 60 Hz, FIFO underruns are observed quite frequently. Looks like the wm0 watermark values need to bumped up because the wm0 memory latency calculations are probably not taking the DRAM channel's impact into account. As per the Bspec 49325, if the ddb allocation can hold at least one plane_blocks_per_line we should have selected method2. Assuming that modern HW versions have enough dbuf to hold at least one line, set the wm blocks to equivalent to blocks per line. v2: styling and comments changes (Ville) v3: Updated the reviewed-by tag v4: max_t to max and patch styling (Ville) References: https://gitlab.freedesktop.org/drm/intel/-/issues/4321 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220417093105.729014-1-vinod.govindapillai@intel.com
2022-04-06drm/i915/adlp: Fix register corruption after DDI clock enablingImre Deak1-0/+3
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-01drm/i915/display: Add HAS_MBUS_JOININGJosé Roberto de Souza1-3/+3
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-03-30drm/i915/display/adlp: Fix programing of PIPE_MBUS_DBOX_CTLJosé Roberto de Souza1-0/+52
PIPE_MBUS_DBOX_CTL was only being programmed when a pipe is being enabled but that could potentially cause issues as it could have mismatching values while pipes are being enabled. So here moving the PIPE_MBUS_DBOX_CTL programming of all pipes to be executed before the function that enables all pipes, leaving all pipes with a matching A_CREDIT value. While at it, also moving it to intel_pm.c as we are trying to reduce the gigantic size of intel_display.c and intel_pm.c have other MBUS programing sequences. v2: - do not program PIPE_MBUS_DBOX_CTL if pipe will not be active or when it do not needs modeset - remove the checks to wait a vblank v3: - checking if dbuf state is present in state before using it v4: - removing redundant checks - calling intel_atomic_get_new_dbuf_state instead of intel_atomic_get_dbuf_state BSpec: 49213 BSpec: 50343 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220330155724.255226-3-jose.souza@intel.com
2022-03-21drm/i915: Remove total[] and uv_total[] from ddb allocationVille Syrjälä1-60/+62
There's really no need to maintain these total[] arrays to track the size of each plane's ddb allocation. We just stick the results straight into the crtc_state ddb tracking structures. The main annoyance with all this is the mismatch between wm_uv vs. ddb_y on pre-icl. If only the hw was consistent in what it considers the primary source of information we could avoid some of the uglyness. But since that is not the case we need a bit of special casing for planar formats. v2: Keep the ddb entry zeroed when the plane is disabled Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-5-ville.syrjala@linux.intel.com
2022-03-21drm/i915: Pre-calculate plane relative data rateVille Syrjälä1-151/+36
Handle the plane relative data rate in exactly the same way as we already handle the real data rate. Ie. pre-calculate it during intel_plane_atomic_check_with_state(), and assign/clear it for the Y plane as needed. This should guarantee that the tracking is 100% consistent, and makes me have to think less when the same apporach is used by both types of data rate. We might even want to consider replacing the relative data rate with the real data rate entirely, but it's not clear if that will produce less optimal plane ddb allocations. So for now lets keep using the current approach. v2: Rebase due to async flip wm optimization Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-4-ville.syrjala@linux.intel.com
2022-03-21drm/i915: Tweak plane ddb allocation trackingVille Syrjälä1-63/+45
Let's store the plane allocation in a manner which more closely matches how the hw operates. That is, we store the packed/CbCr ddb in one struct, and the Y ddb in another. Currently we're storing packed/Y in one struct, CbCr in the other. This also works pretty well for icl+ where the UV plane is the main plane and the Y plane is subservient to it. Although in this case we do not even use ddb_y as we do the ddb allocation in terms of hw planes. v2: Rebase Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-2-ville.syrjala@linux.intel.com
2022-03-21drm/i915: Treat SAGV block time 0 as SAGV disabledVille Syrjälä1-4/+6
For modern platforms the spec explicitly states that a SAGV block time of zero means that SAGV is not supported. Let's extend that to all platforms. Supposedly there should be no systems where this isn't true, and it'll allow us to: - use the same code regardless of older vs. newer platform - wm latencies already treat 0 as disabled, so this fits well with other related code - make it a bit more clear when SAGV is used vs. not - avoid overflows from adding U32_MAX with a u16 wm0 latency value which could cause us to miscalculate the SAGV watermarks on tgl+ Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (cherry picked from commit d8f5855b31c0523ea3b171db8dfb998830e8735d) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2022-03-18drm/i915: Rename pre-icl SAGV enable/disable functionsVille Syrjälä1-18/+14
Give the pre-icl SAGV control functions a skl_ prefix instead of the intel_ prefix to make it a bit more clear that they are not some kind of universal things that can be called on any platform. Also make the functions void since we never use the return value anyway. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-6-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-18drm/i915: Reject excessive SAGV block timeVille Syrjälä1-0/+6
If the mailbox returns an exceesively large SAGV block time let's just reject it. This avoids having to worry about overflows when we add the SAGV block time to the wm0 latency. We shall put the limit arbitrarily at U16_MAX. >65msec latency doesn't really make sense to me in any case. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-5-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-18drm/i915: Probe whether SAGV works on pre-iclVille Syrjälä1-0/+14
Instead of leaving the SAGV enable/disable to the first commit let's try to disable it first thing to see if we can do it or not (disabling SAGV is a safe thing to at any time). This avoids running the code in this funny intermediate state where we don't know if SAGV is available or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-4-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-18drm/i915: Rework SAGV block time probingVille Syrjälä1-15/+21
I'd like to see the SAGV block time we got from the mailbox in the logs regardless of whether other factors prevent the use of SAGV. So let's adjust the code to always query the SAGV block time, log it, and then reset it if SAGV is not actually supported. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-18drm/i915: Treat SAGV block time 0 as SAGV disabledVille Syrjälä1-4/+6
For modern platforms the spec explicitly states that a SAGV block time of zero means that SAGV is not supported. Let's extend that to all platforms. Supposedly there should be no systems where this isn't true, and it'll allow us to: - use the same code regardless of older vs. newer platform - wm latencies already treat 0 as disabled, so this fits well with other related code - make it a bit more clear when SAGV is used vs. not - avoid overflows from adding U32_MAX with a u16 wm0 latency value which could cause us to miscalculate the SAGV watermarks on tgl+ Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-09drm/i915: Remove leftover cnl SAGV block timeVille Syrjälä1-3/+0
GLK doesn't support SAGV, so with CNL gone there is no use for having a DISPLAY_VER==10 SAGV block time in the code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220308173230.4182-2-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
2022-03-08drm/i915: Don't skip ddb allocation if data_rate==0Ville Syrjälä1-18/+12
data_rate==0 no longer means a plane is disabled, it could also mean we want to use the minimum ddb allocation for it. Hence we can't bail out early during ddb allocation or else we'll simply forget to allocate any ddb for such planes. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: 6a4d8cc6bbbf ("drm/i915: Don't allocate extra ddb during async flip for DG2") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220214105532.13049-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (cherry picked from commit 6475e106821babc0dc478a9cb3fc3973739c43fb) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2022-03-03drm/i915: Don't skip ddb allocation if data_rate==0Ville Syrjälä1-18/+12
data_rate==0 no longer means a plane is disabled, it could also mean we want to use the minimum ddb allocation for it. Hence we can't bail out early during ddb allocation or else we'll simply forget to allocate any ddb for such planes. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: 6a4d8cc6bbbf ("drm/i915: Don't allocate extra ddb during async flip for DG2") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220214105532.13049-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-02drm/i915: Use str_enabled_disabled()Lucas De Marchi1-2/+2
Remove the local enableddisabled() implementation and adopt the str_enabled_disabled() from linux/string_helpers.h. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220225234631.3725943-3-lucas.demarchi@intel.com
2022-03-02drm/i915: Use str_yes_no()Lucas De Marchi1-4/+6
Remove the local yesno() implementation and adopt the str_yes_no() from linux/string_helpers.h. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220225234631.3725943-1-lucas.demarchi@intel.com
2022-02-28drm/i915/wm: use REG_FIELD_{PREP,GET} for PLANE_WM_BLOCKS_MASKJani Nikula1-2/+2
Use REG_FIELD_{PREP,GET} for completeness, and to avoid bitwise operations with different sizes. v2: Also use REG_FIELD_GET in skl_wm_level_from_reg_val() (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223103517.634229-1-jani.nikula@intel.com
2022-02-24drm/i915/dg2: Tile 4 plane format supportStanislav Lisovskiy1-0/+1
Tile4 in bspec format is 4K tile organized into 64B subtiles with same basic shape as for legacy TileY which will be supported by Display13. v2: - Moved Tile4 associating struct for modifier/display to the beginning(Imre Deak) - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier checks(Imre Deak) - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12 (Imre Deak) v3: - Rebased patch on top of new changes related to plane_caps. - Added static assert to check that PLANE_CTL_TILING_YF matches PLANE_CTL_TILING_4(Nanley Chery) - Fixed naming and layout description for Tile 4 in drm uapi header(Nanley Chery) v4: - Extracted drm_fourcc changes to separate patch(Nanley Chery) Reviewed-by: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220118115544.15116-3-stanislav.lisovskiy@intel.com
2022-02-18drm/i915: Pimp icl+ sagv pre/post updateVille Syrjälä1-18/+17
Add some debugs on what exactly we're doing to the QGV point mask in the icl+ sagv pre/post plane update hooks. Currently we're just guessing. v2: s/u32/u16/ for consistency with the mask sizes (Stan) Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-5-ville.syrjala@linux.intel.com
2022-02-18drm/i915: Split pre-icl vs. icl+ SAGV hooks apartVille Syrjälä1-40/+74
To further reduce the confusion between the pre-icl vs. icl+ SAGV codepaths let's do a full split. Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-4-ville.syrjala@linux.intel.com
2022-02-18drm/i915: Correctly populate use_sagv_wm for all pipesVille Syrjälä1-11/+11
When changing between SAGV vs. no SAGV on tgl+ we have to update the use_sagv_wm flag for all the crtcs or else an active pipe not already in the state will end up using the wrong watermarks. That is especially bad when we end up with the tighter non-SAGV watermarks with SAGV enabled. Usually ends up in underruns. Cc: stable@vger.kernel.org Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: 7241c57d3140 ("drm/i915: Add TGL+ SAGV support") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-2-ville.syrjala@linux.intel.com
2022-02-18drm/i915: Polish ilk+ wm register bitsVille Syrjälä1-29/+28
Use REG_GENMASK() & co. for ilk+ watermark registers. v2: Stick to the current bitmask sizes (Jani) Fix "watermarm" typo (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220216232806.6194-4-ville.syrjala@linux.intel.com
2022-02-18drm/i915: Clean up SSKPD/MLTR definesVille Syrjälä1-13/+13
Give names to the SSKPD/MLTR fields, and use the REG_GENMASK* and REG_FIELD_GET*. Also drop the bogus non-mirrored SSKP register define. v2: Rebase due to intel_mchbar_regs.h Leave gen6_check_mch_setup() in place for the moment Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220216232806.6194-3-ville.syrjala@linux.intel.com
2022-02-16drm/i915: Move MCHBAR registers to their own headerMatt Roper1-0/+1
Registers that exist within the MCH BAR and are mirrored into the GPU's MMIO space are a good candidate to separate out into their own header. For reference, the mirror of the MCH BAR starts at the following locations in the graphics MMIO space (the end of the MCHBAR range differs slightly on each platform): * Pre-gen6: 0x10000 * Gen6-Gen11 + RKL: 0x140000 v2: - Create separate patch to swtich a few register definitions to be relative to the MCHBAR mirror base. - Drop upper bound of MCHBAR mirror from commit message; there are too many different combinations between various platforms to list out, and the documentation is spotty for the older pre-gen6 platforms anyway. Bspec: 134, 51771 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220215061342.2055952-2-matthew.d.roper@intel.com
2022-02-16drm/i915: Unconfuse pre-icl vs. icl+ intel_sagv_{pre,post}_plane_update()Ville Syrjälä1-4/+6
intel_sagv_{pre,post}_plane_update() can accidentally forget to bail out early on pre-icl and proceed down the icl+ codepath at the end of the function. Fortunately it'll bail out before it gets too far due to old_qgv_mask==new_qgv_mask==0 so no real bug here. But lets make the code less confusing anyway. 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/20220214091811.13725-5-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-16drm/i915: Use {active,scaled}_planes to compute ilk watermarksVille Syrjälä1-6/+2
Use the {active,scaled}_planes bitmasks from the crtc state rather than poking at the plane state directly. One step towards eliminating the last use of the somewhat questionble intel_atomic_crtc_state_for_each_plane_state() macro which peeks into the plane state without actually holding the plane mutex. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220211090629.15555-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-11drm/i915: Extract skl_allocate_plane_ddb()Ville Syrjälä1-17/+24
Replace some copy-pasta with a function. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220118092354.11631-6-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-11drm/i915: Introduce skl_plane_ddb_iterVille Syrjälä1-48/+49
Collect a bit of the stuff used during the plane ddb allocation into a struct we can pass around. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220118092354.11631-5-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-11drm/i915: Fix plane relative_data_rate calculationVille Syrjälä1-61/+2
We are currently computing the relative data rates as src_size * scale_factor where scale_factor is src_size / dst_size. Thus relative data rate is src_size * src_size / dst_size, which is just utter nonsense. What we really seem to want is just a reasonable estimate on how much data will be fetched which is just src_size. So let's do that instead. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220118092354.11631-4-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-11drm/i915: Extract skl_ddb_entry_init()Ville Syrjälä1-19/+25
Extract a small helper to populate a ddb entry. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220118092354.11631-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-11drm/i915: Drop pointless dev_priv argumentVille Syrjälä1-6/+5
skl_ddb_entry_init_from_hw() has no need for dev_priv. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220118092354.11631-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-09drm/i915/pm: hide struct drm_i915_clock_gating_funcsJani Nikula1-0/+4
The struct is only needed in intel_pm.c, move it there. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/63779ac0472895803113180818ecadc22c10369e.1643896905.git.jani.nikula@intel.com
2022-02-08drm/i915: Fix mbus join config lookupVille Syrjälä1-1/+1
The bogus loop from compute_dbuf_slices() was copied into check_mbus_joined() as well. So this lookup is wrong as well. Fix it. Cc: stable@vger.kernel.org Fixes: f4dc00863226 ("drm/i915/adl_p: MBUS programming") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220207132700.481-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-08drm/i915: Fix dbuf slice config lookupVille Syrjälä1-1/+1
Apparently I totally fumbled the loop condition when I removed the ARRAY_SIZE() stuff from the dbuf slice config lookup. Comparing the loop index with the active_pipes bitmask is utter nonsense, what we want to do is check to see if the mask is zero or not. Note that the code actually ended up working correctly despite the fumble, up until commit eef173954432 ("drm/i915: Allow !join_mbus cases for adlp+ dbuf configuration") when things broke for real. Cc: stable@vger.kernel.org Fixes: 05e8155afe35 ("drm/i915: Use a sentinel to terminate the dbuf slice arrays") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220207132700.481-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-07drm/i915: Workaround broken BIOS DBUF configuration on TGL/RKLVille Syrjälä1-0/+68
On TGL/RKL the BIOS likes to use some kind of bogus DBUF layout that doesn't match what the spec recommends. With a single active pipe that is not going to be a problem, but with multiple pipes active skl_commit_modeset_enables() goes into an infinite loop since it can't figure out any order in which it can commit the pipes without causing DBUF overlaps between the planes. We'd need some kind of extra DBUF defrag stage in between to make the transition possible. But that is clearly way too complex a solution, so in the name of simplicity let's just sanitize the DBUF state by simply turning off all planes when we detect a pipe encroaching on its neighbours' DBUF slices. We only have to disable the primary planes as all other planes should have already been disabled (if they somehow were enabled) by earlier sanitization steps. And for good measure let's also sanitize in case the DBUF allocations of the pipes already seem to overlap each other. Cc: <stable@vger.kernel.org> # v5.14+ Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4762 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220204141818.1900-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-07drm/i915: Populate pipe dbuf slices more accurately during readoutVille Syrjälä1-5/+8
During readout we cannot assume the planes are actually using the slices they are supposed to use. The BIOS may have misprogrammed things and put the planes onto the wrong dbuf slices. So let's do the readout more carefully to make sure we really know which dbuf slices are actually in use by the pipe at the time. Cc: <stable@vger.kernel.org> # v5.14+ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220204141818.1900-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-07drm/i915: Allow !join_mbus cases for adlp+ dbuf configurationVille Syrjälä1-20/+46
Reintroduce the !join_mbus single pipe cases for adlp+. Due to the mbus relative dbuf offsets in PLANE_BUF_CFG we need to know the actual slices used by the pipe when doing readout, even when mbus joining isn't enabled. Accurate readout will be needed to properly sanitize invalid BIOS dbuf configurations. This will also make it much easier to play around with the !join_mbus configs for testin/workaround purposes. Cc: <stable@vger.kernel.org> # v5.14+ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220204141818.1900-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-02-02drm/i915: Move GT registers to their own header fileMatt Roper1-0/+1
This is a huge, chaotic mass of registers copied over as-is without any real cleanup. We'll come back and organize these better, align on consistent coding style, remove dead code, etc. in separate patches later that will be easier to review. v2: - Add missing include in intel_pxp_irq.c v3: - Correct a few indentation errors (Lucas) - Minor conflict resolution Cc: Jani Nikula <jani.nikula@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/20220127234334.4016964-6-matthew.d.roper@intel.com
2022-01-31Merge drm/drm-next into drm-intel-nextRodrigo Vivi1-4/+33
Catch-up with 5.17-rc2 and trying to align with drm-intel-gt-next for a possible topic branch for merging the split of i915_regs... Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-01-26drm/i915: Use single_enabled_crtc() in i9xx_update_wm()Ville Syrjälä1-15/+11
Replace the ad-hoc single_enabled_crtc() thing in i9xx_update_wm() with the real thing, just like we do in the other legacy wm functions. We can also nuke the extra 'enabled' variable. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211209144311.3221-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-26drm/i915: Use the correct plane source width in watermark calculationsVille Syrjälä1-11/+10
Currently we sometimes use the plane destination width, or just the pipe src width as the plane source width in the watermark calculatons. Use the correct thing everywhere. v2: convert ilk cur/fbc cases too Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211209144311.3221-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-26drm/i915: Fix up pixel_rate vs. clock confusion in wm calculationsVille Syrjälä1-30/+22
Use pixel_rate rather than crtc_clock in the watermark calculations. These are actually identical on gmch platforms for now since we don't adjust the pixel rate based on pfit downscaling. But pixel_rate is the thing we are actually interested here so use the proper name for it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211209144311.3221-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Powered by cgit, Gruvboxed by Blaster4385.