summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2021-05-05drm/i915: Don't include intel_de.h from intel_display_types.hVille Syrjälä48-1/+47
Hoist the intel_de.h include from intel_display_types.h one level up. I need this in order to untangle the include order so that I can add tracepoints into intel_de.h. This little cocci script did most of the work for me: @find@ @@ ( intel_de_read(...) | intel_de_read_fw(...) | intel_de_write(...) | intel_de_write_fw(...) ) @has_include@ @@ ( #include "intel_de.h" | #include "display/intel_de.h" ) @depends on find && !has_include@ @@ + #include "intel_de.h" #include "intel_display_types.h" @depends on find && !has_include@ @@ + #include "display/intel_de.h" #include "display/intel_display_types.h" Cc: Cooper Chiou <cooper.chiou@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> 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/20210430143945.6776-1-ville.syrjala@linux.intel.com
2021-05-05drm/i915/tgl+: Add the missing MC CCS/XYUV8888 format supportImre Deak1-0/+3
Make sure that the XYUV8888 format is handled correctly when it's used with a MC_CCS modifier framebuffer. Besides this format not working, the driver will also return an incorrect error value when trying to use it, indicating that the second color plane in the framebuffer is set unexpectedly. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210501002853.4132009-1-imre.deak@intel.com
2021-05-04drm/i915: Pass intel_framebuffer instad of drm_framebuffer to ↵Imre Deak3-34/+33
intel_fill_fb_info() Make one step to pass intel_framebuffer to all intel_fb functions. 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/20210414155208.3161335-2-imre.deak@intel.com
2021-05-04drm/i915/audio: fix indentation, remove extra bracesJani Nikula1-2/+2
Cleanup the code. No functional changes. Reviewed-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/6c2f6afa4c8866f8c1714b4f8dba9ea2d1509e4a.1620115983.git.jani.nikula@intel.com
2021-05-04drm/i915/audio: simplify, don't mask out in all branchesJani Nikula1-15/+8
Lift the masking outside of the if branches. No functional changes. Reviewed-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/a87fd5e66b52c4d52a568888e1b8037841786fd2.1620115982.git.jani.nikula@intel.com
2021-05-03drm/i915/backlight: use unique backlight device namesJani Nikula1-4/+19
Registering multiple backlight devices with intel_backlight name will obviously fail, regardless of whether they're two connectors in the same drm device or two different drm devices. It would be preferrable to switch to completely unique names, and sunset the generic intel_backlight name. However, there are apparently users out there that hardcode the name, so the change would break backward compatibility. As a compromise, register the first device with intel_backlight name. In the common case, this is the only backlight device anyway. From the second device on, use card%d-%s-backlight format, for example card0-eDP-2-backlight, to make the name unique. This approach does not preclude us from registering the first device using the same naming scheme in the future. v2: Keep using intel_backlight name for first backlight device Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2794 Reviewed-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/7dc3f6974711ce44522189dc9db05d1e6e24e6d8.1619604743.git.jani.nikula@intel.com
2021-05-03drm/i915/backlight: clean up backlight device registerJani Nikula1-14/+23
Add connector and backlight device name to logging, and propagate error code from backlight_device_register() instead of flattening to -ENODEV. Storing the name in an allocated buffer is unnecessary here, but makes follow-up work on names much cleaner. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-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/271206461d9c0f42755792236330b588df3b532e.1619604743.git.jani.nikula@intel.com
2021-04-29drm/i915/adl_s: ADL-S platform Update PCI ids for Mobile BGAAnand Moon1-0/+2
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
2021-04-28drm/i915: Add frontbuffer tracking tracepointsVille Syrjälä2-0/+43
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.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2021-04-28drm/i915: Stop using crtc->index as the pipeVille Syrjälä1-25/+26
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210426185612.13223-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-04-28drm/i915: Remove stray newlinesVille Syrjälä5-5/+0
A bunch of files have a stray newline at the end. Remove it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210318181039.17260-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2021-04-28drm/i915: Fix pre-skl DP AUX precharge lengthVille Syrjälä1-7/+2
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 e3421a189447 ("drm/i915: enable DP/eDP for Sandybridge/Cougarpoint") added the precharge==3 for snb commit 092945e11c5b ("drm/i915/dp: Use auxch precharge value of 5 everywhere") tried to change it to be 5 for snb commit 6b4e0a93ff6e ("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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210318181039.17260-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2021-04-28drm/i915/display: move crtc and dpll declarations where they belongJani Nikula11-6/+16
The definitions are in the crtc and dpll files; move the declarations to the corresponding headers. Reviewed-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/20210427120315.12342-1-jani.nikula@intel.com
2021-04-28drm/i915/hdcp: add intel_dp_hdcp.h and rename init accordinglyJani Nikula5-9/+24
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: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210427114520.4740-1-jani.nikula@intel.com
2021-04-26drm/i915/display: Disable PSR2 if TGL Display stepping is B1 from A0Gwan-gyeong Mun1-0/+7
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: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210422160544.2427123-1-gwan-gyeong.mun@intel.com
2021-04-26drm: Rename DP_PSR_SELECTIVE_UPDATE to better mach eDP specJosé Roberto de Souza1-8/+8
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: José Roberto de Souza <jose.souza@intel.com> Acked-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210421220224.200729-1-jose.souza@intel.com
2021-04-26drm/i915: Simplify CCS and UV plane alignment handlingImre Deak3-18/+18
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: Imre Deak <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210421173220.3587009-1-imre.deak@intel.com
2021-04-26drm/i915/dsi: Fix comment typozuoqilin1-2/+4
Change 'befor' to 'before'. Signed-off-by: zuoqilin <zuoqilin@yulong.com> [Jani: Fix comment marker placement while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210317074228.1147-1-zuoqilin1@163.com
2021-04-23drm/i915/display/xelpd: Do not program EDP_Y_COORDINATE_ENABLEJosé Roberto de Souza2-3/+2
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: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210421220224.200729-2-jose.souza@intel.com
2021-04-21drm/i915/dmc: Let's abstract the dmc path.Rodrigo Vivi1-10/+16
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> #v1 Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210421094406.2017733-1-rodrigo.vivi@intel.com
2021-04-21drm/i915/dp: Use slow and wide link training for everythingKai-Heng Feng1-54/+5
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/272 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210421052054.1434718-1-kai.heng.feng@canonical.com
2021-04-21drm/i915: Say "enable foo" instead of "set foo to enabled"Ville Syrjälä2-8/+8
Use simpler sentences. Just say "enable foo" instead of "set foo to enabled" etc. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-04-21drm/i915: Add enabledisable()Ville Syrjälä5-5/+10
'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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-04-21drm/i915: Polish for_each_dbuf_slice()Ville Syrjälä5-39/+29
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-04-21drm/i915: Use intel_de_rmw() for DBUF_POWER_REQUESTVille Syrjälä1-7/+2
Use intel_de_rmw() instead of hand rolling it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-04-21drm/i915: Use intel_dbuf_slice_size()Ville Syrjälä1-6/+3
Use intel_dbuf_slice_size() instead of hand rolling it. Also clean up some of the types. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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-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-14drm/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
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-27 11:35:57 +0000