summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2021-04-21drm/i915: Store dbuf slice mask in device infoVille Syrjälä5-10/+16
Let's just store the dbuf slice information as a bitmask in the device info. Makes life a little easier later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-04-21drm/i915: Handle dbuf bypass path allocation earlierVille Syrjälä2-12/+5
We always reserve the same 4 dbuf blocks for the bypass path allocation, so might as well do that when declaring the dbuf size. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-04-21drm/i915: Collect dbuf device info into a sub-structVille Syrjälä4-19/+21
Collect the related dbuf information into a struct. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-04-20drm/i915: fix an error code in intel_overlay_do_put_image()Dan Carpenter1-1/+3
This code should propagate the error from intel_overlay_pin_fb() but currently it returns success. Fixes: 1b321026e213 ("drm/i915: Pass ww ctx to intel_pin_to_display_plane") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YHaFcEzcnh/hk1/Q@mwanda
2021-04-20drm/i915/pm: Make the wm parameter of print_wm_latency a pointerJason Ekstrand1-1/+1
This fixes the following build error with GCC 11: In function ‘snb_wm_latency_quirk’, inlined from ‘ilk_setup_wm_latency’ at drivers/gpu/drm/i915/intel_pm.c:3109:3, inlined from ‘intel_init_pm’ at drivers/gpu/drm/i915/intel_pm.c:7695:3: drivers/gpu/drm/i915/intel_pm.c:3058:9: error: ‘intel_print_wm_latency’ reading 16 bytes from a region of size 10 [-Werror=stringop-overread] 3058 | intel_print_wm_latency(dev_priv, "Primary", dev_priv->wm.pri_latency); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/intel_pm.c: In function ‘intel_init_pm’: drivers/gpu/drm/i915/intel_pm.c:3058:9: note: referencing argument 3 of type ‘const u16 *’ {aka ‘const short unsigned int *’} drivers/gpu/drm/i915/intel_pm.c:2995:13: note: in a call to function ‘intel_print_wm_latency’ 2995 | static void intel_print_wm_latency(struct drm_i915_private *dev_priv, | ^~~~~~~~~~~~~~~~~~~~~~ As far as I can tell, we don't actually need 8 elements except on SKL and that uses dev_priv->wm.skl_latency which has enough. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210413173259.472405-1-jason@jlekstrand.net Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-04-20Merge tag 'gvt-fixes-2021-04-20' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi1-6/+13
drm-intel-fixes gvt-fixes-2021-04-20 - Fix cmd parser regression on BDW (Zhenyu) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210420023312.GL1551@zhen-hp.sh.intel.com
2021-04-20drm/i915/selftests: Only query RAPL for integrated power measurementsChris Wilson4-13/+35
RAPL provides an on-package power measurements which does not encompass discrete graphics, so let's avoid using the igfx masurements when testing dgfx. Later we will abstract the simple librapl interface over hwmon so that we can verify basic power consumption scenarios. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412090526.30547-3-matthew.auld@intel.com
2021-04-20drm/i915/selftests: Skip aperture remapping selftest where there is no apertureChris Wilson1-0/+3
If there is no mappable aperture, we cannot remap it for access, and the selftest is void. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412090526.30547-2-matthew.auld@intel.com
2021-04-20Merge tag 'topic/intel-gen-to-ver-2021-04-19' of ↵Joonas Lahtinen51-348/+376
git://anongit.freedesktop.org/drm/drm-intel into drm-intel-gt-next Gen to ver conversions across the driver The main change is Lucas' series [1], with Ville's GLK fixes [2] and a cherry-pick of Matt's commit [3] from drm-intel-next as a base to avoid conflicts. [1] https://patchwork.freedesktop.org/series/88825/ [2] https://patchwork.freedesktop.org/series/88938/ [3] 70bfb30743d5 ("drm/i915/display: Eliminate IS_GEN9_{BC,LP}") Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/878s5ebny0.fsf@intel.com
2021-04-19drm/i915: Fix modesetting in case of unexpected AUX timeoutsImre Deak1-1/+2
In case AUX failures happen unexpectedly during a modeset, the driver should still complete the modeset. In particular the driver should perform the link training sequence steps even in case of an AUX failure, as this sequence also includes port initialization steps. Not doing that can leave the port/pipe in a broken state and lead for instance to a flip done timeout. Fix this by continuing with link training (in a no-LTTPR mode) if the DPRX DPCD readout failed for some reason at the beginning of link training. After a successful connector detection we already have the DPCD read out and cached, so the failed repeated read for it should not cause a problem. Note that a partial AUX read could in theory partly overwrite the cached DPCD (and return error) but this overwrite should not happen if the returned values are corrupted (due to a timeout or some other IO error). Kudos to Ville to root cause the problem. Fixes: 7dffbdedb96a ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4") References: https://gitlab.freedesktop.org/drm/intel/-/issues/3308 Cc: stable@vger.kernel.org # 5.11 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412232413.2755054-1-imre.deak@intel.com (cherry picked from commit e42e7e585984b85b0fb9dd1fefc85ee4800ca629) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [adjusted Fixes: tag]
2021-04-19Merge tag 'topic/intel-gen-to-ver-2021-04-19' of ↵Rodrigo Vivi47-249/+265
git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next Gen to ver conversions across the driver The main change is Lucas' series [1], with Ville's GLK fixes [2] and a cherry-pick of Matt's commit [3] from drm-intel-next as a base to avoid conflicts. [1] https://patchwork.freedesktop.org/series/88825/ [2] https://patchwork.freedesktop.org/series/88938/ [3] 70bfb30743d5 ("drm/i915/display: Eliminate IS_GEN9_{BC,LP}") Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> # Conflicts: # drivers/gpu/drm/i915/display/intel_bios.c # drivers/gpu/drm/i915/display/intel_cdclk.c # drivers/gpu/drm/i915/display/intel_ddi.c # drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c # drivers/gpu/drm/i915/display/intel_display.c # drivers/gpu/drm/i915/display/intel_display_power.c # drivers/gpu/drm/i915/display/intel_dp.c # drivers/gpu/drm/i915/display/intel_dpll_mgr.c # drivers/gpu/drm/i915/display/intel_fbc.c # drivers/gpu/drm/i915/display/intel_gmbus.c # drivers/gpu/drm/i915/display/intel_hdcp.c # drivers/gpu/drm/i915/display/intel_hdmi.c # drivers/gpu/drm/i915/display/intel_pps.c # drivers/gpu/drm/i915/intel_pm.c From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/878s5ebny0.fsf@intel.com
2021-04-19drm/i915: Reuse intel_adjusted_rate() for pfit pixel rate adjustmentVille Syrjälä3-20/+13
Replace the hand rolled pfit downscale calculations with intel_adjusted_rate(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210330184254.6290-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-04-19drm/i915: Extract intel_adjusted_rate()Ville Syrjälä1-8/+28
Extract a small helper to calculate the downscaling adjusted pixel rate/data rate/etc. v2: Drop the plane visibility check and add a comment explaining why 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/20210401154043.19466-1-ville.syrjala@linux.intel.com
2021-04-16drm/i915/gvt: Fix BDW command parser regressionZhenyu Wang1-6/+13
On BDW new Windows driver has brought extra registers to handle for LRM/LRR command in WA ctx. Add allowed registers in cmd parser for BDW. Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Yan Zhao <yan.y.zhao@intel.com> Cc: stable@vger.kernel.org Tested-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Colin Xu <colin.xu@intel.com> Fixes: 73a37a43d1b0 ("drm/i915/gvt: filter cmds "lrr-src" and "lrr-dst" in cmd_handler") Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210414084813.3763353-1-zhenyuw@linux.intel.com
2021-04-15drm/i915/gvt: Fix error code in intel_gvt_init_device()Dan Carpenter1-4/+4
The intel_gvt_init_vgpu_type_groups() function is only called from intel_gvt_init_device(). If it fails then the intel_gvt_init_device() prints the error code and propagates it back again. That's a bug because false is zero/success. The fix is to modify it to return zero or negative error codes and make everything consistent. Fixes: c5d71cb31723 ("drm/i915/gvt: Move vGPU type related code into gvt file") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/YHaFQtk/DIVYK1u5@mwanda Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2021-04-15drm/i915/gvt: remove useless functionJiapeng Chong1-6/+0
Fix the following clang warning: drivers/gpu/drm/i915/gvt/gtt.c:590:20: warning: unused function 'ppgtt_set_guest_root_entry' [-Wunused-function]. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1618294728-78952-1-git-send-email-jiapeng.chong@linux.alibaba.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2021-04-15drm/i915/display/psr: Fix cppcheck warningsJosé Roberto de Souza1-2/+1
Fix redundant condition, caught in cppcheck by kernel test robot. Reported-by: kernel test robot <lkp@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Fixes: b64d6c51380b ("drm/i915/display: Support PSR Multiple Instances") Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210409231738.238682-1-jose.souza@intel.com
2021-04-14drm/i915: Drop redundant address-of op before lttpr_common_caps arrayImre Deak1-1/+1
The address-of op in front of an array is just an alias to using the array on its own, so drop the op. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412232413.2755054-2-imre.deak@intel.com
2021-04-14drm/i915: Fix modesetting in case of unexpected AUX timeoutsImre Deak1-1/+2
In case AUX failures happen unexpectedly during a modeset, the driver should still complete the modeset. In particular the driver should perform the link training sequence steps even in case of an AUX failure, as this sequence also includes port initialization steps. Not doing that can leave the port/pipe in a broken state and lead for instance to a flip done timeout. Fix this by continuing with link training (in a no-LTTPR mode) if the DPRX DPCD readout failed for some reason at the beginning of link training. After a successful connector detection we already have the DPCD read out and cached, so the failed repeated read for it should not cause a problem. Note that a partial AUX read could in theory partly overwrite the cached DPCD (and return error) but this overwrite should not happen if the returned values are corrupted (due to a timeout or some other IO error). Kudos to Ville to root cause the problem. Fixes: 264613b406eb ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4") References: https://gitlab.freedesktop.org/drm/intel/-/issues/3308 Cc: stable@vger.kernel.org # 5.11 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412232413.2755054-1-imre.deak@intel.com
2021-04-14drm/i915: split dgfx features from gen 12Lucas De Marchi1-3/+3
Make them independent so we can use DGFX_FEATURES more generically. For future platforms that do not use the GEN nomenclature we will define graphics, media and display separately, so we avoid setting graphics_ver with the GEN() macro. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-13-lucas.demarchi@intel.com
2021-04-14drm/i915: add media and display versions to device_info printLucas De Marchi1-0/+2
Since we are now converting from a single gen version to graphics_ver, media_ver and display_ver, add the last 2 when printing the device info. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-12-lucas.demarchi@intel.com
2021-04-14drm/i915: finish removal of gen from intel_device_infoLucas De Marchi4-8/+6
Now that it's not being used anymore, finish its removal. Like for gen_mask, we replace INTEL_GEN() and IS_GEN() macros to use the new field. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> [Jani: Minor code comment change while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-11-lucas.demarchi@intel.com
2021-04-14drm/i915: eliminate remaining uses of intel_device_info->genLucas De Marchi3-13/+13
Replace gen with the new graphics_ver value and use GRAPHICS_VER() in those places. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-10-lucas.demarchi@intel.com
2021-04-14drm/i915: finish removal of gen_maskLucas De Marchi4-14/+5
Now that it's not used anywhere, remove it from struct intel_device_info. To allow a period in which code will be converted to the new macro, keep IS_GEN_RANGE() around, just redefining it to use the new fields. The size advantage from IS_GEN_RANGE() using a mask is not that big as it has pretty limited use througout the driver: text data bss dec hex filename 2758497 95965 6496 2860958 2ba79e drivers/gpu/drm/i915/i915.ko.old 2758586 95953 6496 2861035 2ba7eb drivers/gpu/drm/i915/i915.ko.new Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> [Jani: Minor code comment change while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-9-lucas.demarchi@intel.com
2021-04-14drm/i915/selftests: eliminate use of gen_maskLucas De Marchi2-6/+10
Remove the remaining uses of INTEL_GEN_MASK() and the correspondent gen_mask in struct intel_device_info. This will allow the removal of gen_mask later since it's incompatible with the new per-IP versioning scheme. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-8-lucas.demarchi@intel.com
2021-04-14drm/i915/selftests: replace unused mask with simple versionLucas De Marchi1-5/+5
Since its introduction 2 years ago, we never used the mask to span more than one gen. Replace gen_mask a single number and start using the new GRAPHICS_VER(). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-7-lucas.demarchi@intel.com
2021-04-14drm/i915/gt: replace gen use in intel_engine_csLucas De Marchi2-29/+29
Start using the new fields graphics_version for the previous gen checks. Here we rename the "gen" field and replace the comparisons using it to start using the new GRAPHICS_VER(). Other uses of INTEL_GEN() were left as is for automatic conversion later. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-6-lucas.demarchi@intel.com
2021-04-14drm/i915: add macros for graphics and media versionsLucas De Marchi3-2/+23
Like it was done in commit 01eb15c9165e ("drm/i915: Add DISPLAY_VER() and related macros") add the correspondent macros for graphics and media. Going forward we will prefer checking the versions for the specific IPs (graphics, media and display) rather than grouping everything under a "gen" version. For consistency and to make the maintenance easier, it'd be preferred not to mix the *GEN* macros with the new ones. For older platforms we can simply consider that the previous "gen" number will extend to all 3 IPs. Then we can start replacing its use in the driver. Right now this replacement is not done and only the infrastructure is put in place. We also leave gen and gen_mask inside struct intel_device_info while it's still being used throughout the code. v2: Repurpose IS_{GRAPHICS,MEDIA}_VER() macros to work with a range Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [Jani: Minor code comment change while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-5-lucas.demarchi@intel.com
2021-04-14drm/i915/display: rename display version macrosLucas De Marchi35-165/+164
While converting the rest of the driver to use GRAPHICS_VER() and MEDIA_VER(), following what was done for display, some discussions went back on what we did for display: 1) Why is the == comparison special that deserves a separate macro instead of just getting the version and comparing directly like is done for >, >=, <=? 2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for brevity. If we remove the current users of IS_DISPLAY_VER(), we could actually repurpose it for a range check With (1) there could be an advantage if we used gen_mask since multiple conditionals be combined by the compiler in a single and instruction and check the result. However a) INTEL_GEN() doesn't use the mask since it would make the code bigger everywhere else and b) in the cases it made sense, it also made sense to convert to the _RANGE() variant. So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER() users to use == and != operators. Aside from the definition changes, this was done by the following semantic patch: @@ expression dev_priv, E1; @@ - !IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) != E1 @@ expression dev_priv, E1; @@ - IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) == E1 @@ expression dev_priv, from, until; @@ - IS_DISPLAY_RANGE(dev_priv, from, until) + IS_DISPLAY_VER(dev_priv, from, until) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> [Jani: Minor conflict resolve while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
2021-04-14drm/i915: rename display.version to display.verLucas De Marchi3-4/+4
The macro we use to check is called DISPLAY_VER(). While using this macro and the new ones being added in following changes I made the mistake multiple times when mixing both "ver" and "version". Although it's usually better to prefer the complete name, the shorhand DISPLAY_VER() / GRAPHICS_VER / MEDIA_VER are clear and cause less visual polution. Another issue is when copying the variable to other places. "display.version" would be copied to a "display_version" variable which is long and would make people abbreviate as "version", or "display_ver". In the first case it's not always clear what version refers to, and in the second case it just hints it should be the name in the first place. So, in the same way use used "gen" rather than "generation", use "ver" instead of "version". Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-3-lucas.demarchi@intel.com
2021-04-14drm/i915/display: use DISPLAY_VER() on remaining usersLucas De Marchi1-1/+1
Commit 989634fb49ad ("drm/i915/audio: set HDA link parameters in driver") added INTEL_GEN() in the display code, where it should actually be using DISPLAY_VER(). Switch to the new macro. Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-2-lucas.demarchi@intel.com
2021-04-14drm/i915: Remove a few redundant glk checksVille Syrjälä2-2/+2
Now that glk display version is 10 we can drop a few more glk checks. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412054607.18133-6-ville.syrjala@linux.intel.com
2021-04-14drm/i915: Don't use {skl, cnl}_hpd_pin() for bxt/glkVille Syrjälä1-2/+2
Just let bxt/glk fall back to intel_hpd_pin_default() instead of using skl_hpd_pin() or cnl_hpd_pin(). Doesn't really matter since both functions will end up returning the correct hpd pin anyway, but I find it a bit less confusing when bxt/glk are fully separated from the logic for the other platforms. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412054607.18133-5-ville.syrjala@linux.intel.com
2021-04-14drm/i915: Disable LTTPR detection on GLK once againVille Syrjälä1-1/+1
The glk display version change is causing us to again attempt LTTPR detection on glk. We must not do tha since glk doesn't have a long enough AUX timeout. Restore the correct logic to skip the detection. Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: 2b5a4562edd0 ("drm/i915/display: Simplify GLK display version tests") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412054607.18133-4-ville.syrjala@linux.intel.com
2021-04-14drm/i915: Restore lost glk ccs w/aVille Syrjälä1-1/+2
We lost a CCS related w/a on glk when the display version became 10 instead of 9. Restore the correct check. Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: 2b5a4562edd0 ("drm/i915/display: Simplify GLK display version tests") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412054607.18133-3-ville.syrjala@linux.intel.com
2021-04-14drm/i915: Restore lost glk FBC 16bpp w/aVille Syrjälä1-1/+1
We lost the FBC 16bpp 512byte stride requirement on glk when we switched from display version 9 to 10. Restore the w/a to avoid enabling FBC with a bad stride and thus display garbage. Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: 2b5a4562edd0 ("drm/i915/display: Simplify GLK display version tests") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412054607.18133-2-ville.syrjala@linux.intel.com
2021-04-14drm/i915/display: Eliminate IS_GEN9_{BC,LP}Matt Roper21-134/+146
Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the display code, we should also kill off our use of the IS_GEN9_* macros too. We'll do the conversion manually this time instead of using Coccinelle since the most logical substitution can depend heavily on the code context, and sometimes we can keep the code simpler if we make additional adjustments such as swapping the order of if/else arms. v2: - Restore a lost negation in intel_pll_is_valid(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com (cherry picked from commit 70bfb30743d5da73058b0a2271e9c127a84fb494) [Jani: cherry picked to topic branch to reduce conflicts] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-04-14drm/aperture: Convert drivers to aperture interfacesThomas Zimmermann1-1/+2
Mass-convert all drivers from FB helpers to aperture interfaces. No functional changes besides checking for returned errno codes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412131043.5787-3-tzimmermann@suse.de
2021-04-14Merge drm/drm-fixes into drm-nextDaniel Vetter1-2/+20
msm-next pull request has a baseline with stuff from -fixes, roll forward first. Some simple conflicts in amdgpu, ttm and one in i915 where git gets confused and tries to add the same function twice. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2021-04-12Revert "drm/i915/tgl/psr: Fix glitches when doing frontbuffer modifications"José Roberto de Souza1-15/+1
This reverts commit 71c1a4998320962f7b8362b2c5ee36610d49e8fb. The proper fix is Wa_14013723622, so now we can revert this WA and get back some power savings. 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> Tested-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210408204917.254272-2-jose.souza@intel.com
2021-04-12drm/i915/display: Implement Wa_14013723622José Roberto de Souza2-0/+8
This WA fix some display glitches when the system is under high memory pressure. BSpec: 52890 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> Tested-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210408204917.254272-1-jose.souza@intel.com
2021-04-12vfio/mdev: Correct the function signatures for the mdev_type_attributesJason Gunthorpe1-10/+11
The driver core standard is to pass in the properly typed object, the properly typed attribute and the buffer data. It stems from the root kobject method: ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,..) Each subclass of kobject should provide their own function with the same signature but more specific types, eg struct device uses: ssize_t (*show)(struct device *dev, struct device_attribute *attr,..) In this case the existing signature is: ssize_t (*show)(struct kobject *kobj, struct device *dev,..) Where kobj is a 'struct mdev_type *' and dev is 'mdev_type->parent->dev'. Change the mdev_type related sysfs attribute functions to: ssize_t (*show)(struct mdev_type *mtype, struct mdev_type_attribute *attr,..) In order to restore type safety and match the driver core standard There are no current users of 'attr', but if it is ever needed it would be hard to add in retroactively, so do it now. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Message-Id: <18-v2-d36939638fc6+d54-vfio2_jgg@nvidia.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2021-04-12vfio/mdev: Remove kobj from mdev_parent_ops->create()Jason Gunthorpe1-1/+1
The kobj here is a type-erased version of mdev_type, which is already stored in the struct mdev_device being passed in. It was only ever used to compute the type_group_id, which is now extracted directly from the mdev. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Message-Id: <17-v2-d36939638fc6+d54-vfio2_jgg@nvidia.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2021-04-12vfio/gvt: Use mdev_get_type_group_id()Jason Gunthorpe3-22/+11
intel_gvt_init_vgpu_type_groups() makes gvt->types 1:1 with the supported_type_groups array, so the type_group_id is also the index into gvt->types. Use it directly and remove the string matching. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Message-Id: <16-v2-d36939638fc6+d54-vfio2_jgg@nvidia.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2021-04-12vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEVJason Gunthorpe1-0/+1
At some point there may have been some reason for this weird split in this driver, but today only the VFIO side is actually implemented. However, it got messed up at some point and mdev code was put in gvt.c and is pretending to be "generic" by masquerading as some generic attribute list: static MDEV_TYPE_ATTR_RO(description); But MDEV_TYPE attributes are only usable with mdev_device, nothing else. Ideally all of this would be moved to kvmgt.c, but it is entangled with the rest of the "generic" code in an odd way. Thus put in a kconfig dependency so we don't get randconfig failures when the next patch creates a link time dependency related to the use of MDEV_TYPE. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Message-Id: <15-v2-d36939638fc6+d54-vfio2_jgg@nvidia.com> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2021-04-12drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when disabling ↵Hans de Goede1-2/+2
the panel After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot"), the DSI panel on a Cherry Trail based Predia Basic tablet would no longer properly light up after reboot. I've managed to reproduce this without rebooting by doing: chvt 3; echo 1 > /sys/class/graphics/fb0/blank;\ echo 0 > /sys/class/graphics/fb0/blank Which rapidly turns the panel off and back on again. The vlv_dsi.c code uses an intel_dsi_msleep() helper for the various delays used for panel on/off, since starting with MIPI-sequences version >= 3 the delays are already included inside the MIPI-sequences. The problems exposed by the "Shut down displays gracefully on reboot" change, show that using this helper for the panel_pwr_cycle_delay is not the right thing to do. This has not been noticed until now because normally the panel never is cycled off and directly on again in quick succession. Change the msleep for the panel_pwr_cycle_delay to a normal msleep() call to avoid the panel staying black after a quick off + on cycle. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210325114823.44922-1-hdegoede@redhat.com (cherry picked from commit 2878b29fc25a0dac0e1c6c94177f07c7f94240f0) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-04-12drm/i915: Don't zero out the Y plane's watermarksVille Syrjälä1-2/+2
Don't zero out the watermarks for the Y plane since we've already computed them when computing the UV plane's watermarks (since the UV plane always appears before ethe Y plane when iterating through the planes). This leads to allocating no DDB for the Y plane since .min_ddb_alloc also gets zeroed. And that of course leads to underruns when scanning out planar formats. Cc: stable@vger.kernel.org Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: dbf71381d733 ("drm/i915: Nuke intel_atomic_crtc_state_for_each_plane_state() from skl+ wm code") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210327005945.4929-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (cherry picked from commit f99b805fb9413ff007ca0b6add871737664117dd) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-04-12drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBTLyude Paul1-1/+0
Looks like that there actually are another subset of laptops on the market that don't support the Intel HDR backlight interface, but do advertise support for the VESA DPCD backlight interface despite the fact it doesn't seem to work. Note though I'm not entirely clear on this - on one of the machines where this issue was observed, I also noticed that we appeared to be rejecting the VBT defined backlight frequency in intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that: /* Use highest possible value of Pn for more granularity of brightness * adjustment while satifying the conditions below. * ... * - FxP is within 25% of desired value. * Note: 25% is arbitrary value and may need some tweak. */ So it's possible that this value might just need to be tweaked, but for now let's just disable the VESA backlight interface unless it's specified in the VBT just to be safe. We might be able to try enabling this again by default in the future. Fixes: 2227816e647a ("drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169 Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210318170204.513000-1-lyude@redhat.com (cherry picked from commit 9e2eb6d5380e9dadcd2baecb51f238e5eba94bee) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-04-12drm/i915/display/vlv_dsi: Move panel_pwr_cycle_delay to next panel-onHans de Goede2-6/+20
Instead of sleeping panel_pwr_cycle_delay ms when turning the panel off, record the time it is turned off and if necessary wait any (remaining) time when the panel is turned on again. Also sleep the remaining time on shutdown, because on reboot the GOP will immediately turn on the panel again. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210325114823.44922-2-hdegoede@redhat.com
2021-04-12drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when disabling ↵Hans de Goede1-2/+2
the panel After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot"), the DSI panel on a Cherry Trail based Predia Basic tablet would no longer properly light up after reboot. I've managed to reproduce this without rebooting by doing: chvt 3; echo 1 > /sys/class/graphics/fb0/blank;\ echo 0 > /sys/class/graphics/fb0/blank Which rapidly turns the panel off and back on again. The vlv_dsi.c code uses an intel_dsi_msleep() helper for the various delays used for panel on/off, since starting with MIPI-sequences version >= 3 the delays are already included inside the MIPI-sequences. The problems exposed by the "Shut down displays gracefully on reboot" change, show that using this helper for the panel_pwr_cycle_delay is not the right thing to do. This has not been noticed until now because normally the panel never is cycled off and directly on again in quick succession. Change the msleep for the panel_pwr_cycle_delay to a normal msleep() call to avoid the panel staying black after a quick off + on cycle. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210325114823.44922-1-hdegoede@redhat.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-28 06:46:09 +0300