- 29 Apr, 2021 1 commit
-
-
Anand Moon authored
As per Bspec: 53655 Update PCI ids for Mobile BGA. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Anand Moon <anandx.ram.moon@intel.com> Reviewed-by:
Aditya Swarup <aditya.swarup@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210203091029.2089-1-anandx.ram.moon@intel.com
-
- 28 Apr, 2021 6 commits
-
-
Ville Syrjälä authored
Add some tracpoints for frontbuffer tracking so we can try to figure out what's going on. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210414022309.30898-2-ville.syrjala@linux.intel.comAcked-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
The pipe crc code slipped theough the net when we tried to eliminate all crtc->index==pipe abuses. Remedy that. And while at it get rid of those nasty intel_crtc+drm_crtc pointer aliases. Signed-off-by:
-
Ville Syrjälä authored
A bunch of files have a stray newline at the end. Remove it. Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
DP v1.1+ says: "The DisplayPort transmitter, which is the driving end for a request transaction, pre-charges the AUX-CH+ and AUX-CH- to a common mode voltage by transmitting 10 to 16 consecutive 0’s in Manchester II code. After the active pre-charge, the transmitter sends an AUX Sync pattern. The AUX Sync pattern must be as follows: Start with 16 consecutive 0s in Manchester-II code, which results in a transition from low to high in the middle of each bit period. Including active pre-charge pulses, there shall be 26 to 32 consecutive 0s before the end of the AUX_SYNC pattern." BDW bspec says: "Used to determine the precharge time for the Aux Channel. During this time the Aux Channel will drive the SYNC pattern. Every microsecond gives one additional SYNC pulse beyond the hard coded 26 SYNC pulses. The value is the number of microseconds times 2. Default is 3 decimal which gives 6us of precharge which is 6 extra SYN pulses for a total of 32." CPT bspec says the same thing apart from: "... Default is 5 decimal which gives 10us of precharge which is 10 extra SYNC pulses for a total of 36." So it looks like to match the max of 32 of the DP spec we should just always program this extra precharge time to 3. Unfortunately g4x/ibx bspec doesn't have this clarification, but since the cpt default was still the same 5 as for g4x/ibx let's assume the behaviour was always the same. I also did a bit more archaeology and found the following: commit e3421a18 ("drm/i915: enable DP/eDP for Sandybridge/Cougarpoint") added the precharge==3 for snb commit 092945e1 ("drm/i915/dp: Use auxch precharge value of 5 everywhere") tried to change it to be 5 for snb commit 6b4e0a93 ("Revert "drm/i915/dp: Use auxch precharge value of 5 everywhere"") went back to 3 for snb due to a regression So I think the value of 5 was just always wrong, but I guess very few display actually get upset if we do too many SYNCs. Also DP 1.0 did not specify any max value for this, whereas DP 1.1+ added the max==32 wording. Additionally I hooked up a scope to a few machines with the following findings: - ibx and cpt both give us the expected 32 total sync pulses with precharge==3 - ctg is a bit different, it has the 10 hardcoded precharge sync pulses same as later platforms (so we get at least 26 sync pulses in total). However the additional precharge length (which is what we're changing here) is not done with sync pulses. Instead ctg does this part of the precharge with a steady DC voltage. If we wanted to 100% match DP 1.1+ here we should perhaps set prechange length to 0, but less precharge might make AUX less reliable, and so far we're not aware of any problems due to the DC precharge. Hence I think precharge==3 is probably the best choice here too to make the total length of precharge consistent with the later platforms. Signed-off-by:
-
Jani Nikula authored
The definitions are in the crtc and dpll files; move the declarations to the corresponding headers. Reviewed-by:
-
Jani Nikula authored
Add separate intel_dp_hdcp.h to go with intel_dp_hdcp.c, and rename the init function intel_dp_hdcp_init() to follow naming where function prefix matches the file name. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
- 27 Apr, 2021 1 commit
-
-
Gwan-gyeong Mun authored
TGL PSR2 hardware tracking shows momentary flicker and screen shift if TGL Display stepping is B1 from A0. It has been fixed from TGL Display stepping C0. HSDES: 18015970021 HSDES: 2209313811 BSpec: 55378 v2: Add checking of PSR2 manual tracking (Jose) Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
-
- 26 Apr, 2021 3 commits
-
-
José Roberto de Souza authored
DP_PSR_EN_CFG bit 5 aka "Selective Update Region Scan Line Capture Indication" in eDP spec has a ambiguous name, so renaming to better match specification. While at it, replacing bit shit by BIT() macro and adding the version some registers were added to eDP specification. Cc: <dri-devel@lists.freedesktop.org> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
-
Imre Deak authored
We can handle the surface alignment of CCS and UV color planes for all modifiers at one place, so do this. An AUX color plane can be a CCS or a UV plane, use only the more specific query functions and remove is_aux_plane() becoming redundant. While at it add a TODO for linear UV color plane alignments. The spec requires this to be stride-in-bytes * 64 on all platforms, whereas the driver uses an alignment of 4k for gen<12 and 256k for gen>=12 for linear UV planes. v2: - Restore previous alignment for linear UV surfaces. Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by:
-
zuoqilin authored
Change 'befor' to 'before'. Signed-off-by:
zuoqilin <zuoqilin@yulong.com> [Jani: Fix comment marker placement while applying.] Signed-off-by:
-
- 23 Apr, 2021 1 commit
-
-
José Roberto de Souza authored
EDP_Y_COORDINATE_ENABLE became a reserved register in display 13. EDP_Y_COORDINATE_VALID have the same fate as EDP_Y_COORDINATE_ENABLE but as we don't need it, removing the macro definition of it. BSpec: 50422 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
- 21 Apr, 2021 2 commits
-
-
Rodrigo Vivi authored
Although this abstraction removes the convenience of grepping for the file name, it: - makes addition easier. - makes it easier to tweak global path when experiments are needed. - get in sync with guc/huc, without getting overly abstracted. - allows future junction with CSR_VERSION for simplicity. - Enforces dmc file will never change this standard. v2: define DMC_PATH inside .c (Lucas) Cc: Fei Yang <fei.yang@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Kai-Heng Feng authored
Screen flickers on Innolux eDP 1.3 panel when clock rate 540000 is in use. According to the panel vendor, though clock rate 540000 is advertised, but the max clock rate it really supports is 270000. Ville Syrjälä mentioned that fast and narrow also breaks some eDP 1.4 panel, so use slow and wide training for all panels to resolve the issue. User also confirmed that the new strategy doesn't introduce any regression on XPS 9380. v2: - Use slow and wide for everything. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3384 References: https://gitlab.freedesktop.org/drm/intel/-/issues/272Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
- 20 Apr, 2021 10 commits
-
-
Ville Syrjälä authored
Use simpler sentences. Just say "enable foo" instead of "set foo to enabled" etc. Signed-off-by:
-
Ville Syrjälä authored
'enable ? "enable" : "disable"' is a fairly common pattern in our debug prints. Let's introduce a helper for it. Signed-off-by:
-
Ville Syrjälä authored
Now that we have the dbuf slice mask stored in the device info let's use it for for_each_dbuf_slice_in_mask*(). With this we cal also rip out intel_dbuf_size() and intel_dbuf_num_slices(). Signed-off-by:
-
Ville Syrjälä authored
Use intel_de_rmw() instead of hand rolling it. Signed-off-by:
-
Ville Syrjälä authored
Use intel_dbuf_slice_size() instead of hand rolling it. Also clean up some of the types. Signed-off-by:
-
Ville Syrjälä authored
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ä 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ä 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:
-
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:
Harish Chegondi <harish.chegondi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210409231738.238682-1-jose.souza@intel.com
-
- 14 Apr, 2021 12 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 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:
-
