- 20 Apr, 2021 4 commits
-
-
Ville Syrjälä authored
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.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Collect the related dbuf information into a struct. Signed-off-by:
-
Dan Carpenter authored
This code should propagate the error from intel_overlay_pin_fb() but currently it returns success. Fixes: 1b321026 ("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:
-
Jason Ekstrand authored
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:
-
- 19 Apr, 2021 3 commits
-
-
Rodrigo Vivi authored
Merge tag 'topic/intel-gen-to-ver-2021-04-19' of 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] 70bfb307 ("drm/i915/display: Eliminate IS_GEN9_{BC,LP}") Signed-off-by:
-
Ville Syrjälä authored
Replace the hand rolled pfit downscale calculations with intel_adjusted_rate(). Signed-off-by:
-
Ville Syrjälä authored
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:
-
- 15 Apr, 2021 1 commit
-
-
José Roberto de Souza authored
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: b64d6c51 ("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
-
- 14 Apr, 2021 20 commits
-
-
Imre Deak authored
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:
-
Imre Deak authored
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: 264613b4 ("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:
-
Lucas De Marchi authored
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:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Lucas De Marchi authored
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:
-
Lucas De Marchi authored
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:
-
Lucas De Marchi authored
Replace gen with the new graphics_ver value and use GRAPHICS_VER() in those places. Reviewed-by:
-
Lucas De Marchi authored
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:
-
Lucas De Marchi authored
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:
-
Lucas De Marchi authored
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:
-
Lucas De Marchi authored
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:
-
Lucas De Marchi authored
Like it was done in commit 01eb15c9 ("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 authored
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:
-
Lucas De Marchi authored
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 authored
Commit 989634fb ("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:
-
Ville Syrjälä authored
Now that glk display version is 10 we can drop a few more glk checks. Reviewed-by:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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: 2b5a4562 ("drm/i915/display: Simplify GLK display version tests") Reviewed-by:
-
Ville Syrjälä authored
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: 2b5a4562 ("drm/i915/display: Simplify GLK display version tests") Reviewed-by:
-
Ville Syrjälä authored
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: 2b5a4562 ("drm/i915/display: Simplify GLK display version tests") Reviewed-by:
-
Matt Roper authored
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 70bfb307) [Jani: cherry picked to topic branch to reduce conflicts] Signed-off-by:
-
- 12 Apr, 2021 4 commits
-
-
José Roberto de Souza authored
This reverts commit 71c1a499. 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:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Tested-by:
-
José Roberto de Souza authored
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:
-
Hans de Goede authored
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:
-
Hans de Goede authored
After the recently added commit fe0f1e3b ("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: fe0f1e3b ("drm/i915: Shut down displays gracefully on reboot") Signed-off-by:
-
- 09 Apr, 2021 5 commits
-
-
José Roberto de Souza authored
PSR2 is defeatured for RKL and ADL-S, no important power impact as those are desktop CPUs and PSR2 was not even enabled by default yet in platforms without PSR2 HW tracking. HSDES: 14011750631 HSDES: 14011741325 BSpec: 53273 Cc: Caz Yokoyama <Caz.Yokoyama@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
José Roberto de Souza authored
Display features should not be initialized or de-initialized when there is no display. Skip modeset initialization, output setup, plane, crtc, encoder, connector registration, display cdclk and rawclk initialization, display core initialization, etc. Skip the functionality at as high level as possible, and remove any redundant checks. If the functionality is conditional to *other* display checks, do not add more. If the un-initialization has checks for initialization, do not add more. We explicitly do not care about any GMCH/VLV/CHV code paths, as they've always had and will have display. Reviewed-by:
-
José Roberto de Souza authored
Power wells are only part of display block and not necessary when running a headless driver. Reviewed-by:
-
José Roberto de Souza authored
Return ealier in the functions doing interruption setup for GEN8+ also adding a warning in gen8_de_irq_handler() to let us know that something else is still missing. Reviewed-by:
-
Anshuman Gupta authored
Fix static analysis tool uninitialized symbol error. v2: - use ktime_set(0, 0) instead to initialize to zero. [Ankit] Reported-by:
Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210408082642.27066-1-anshuman.gupta@intel.com
-
- 08 Apr, 2021 3 commits
-
-
Ville Syrjälä authored
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: dbf71381 ("drm/i915: Nuke intel_atomic_crtc_state_for_each_plane_state() from skl+ wm code") Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Lyude Paul authored
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: 2227816e ("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/3169Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
-
Jani Nikula authored
Sync up with topic/i915-gem-next and drm-intel-gt-next. Signed-off-by:
-
