- 13 May, 2022 2 commits
-
-
Jani Nikula authored
Need to use pipe_name(pipe) instead of pipe directly. Fixes: 1f31e35f ("drm/i915/audio: unify audio codec enable/disable debug logging") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220512161638.272601-1-jani.nikula@intel.com
-
Anusha Srivatsa authored
Bspec has added some steps that check forDMC MMIO range before programming them v2: Fix for CI v3: move register defines to .h (Anusha) - Check MMIO restrictions per pipe - Add MMIO restricton for v1 dmc header as well (Lucas) v4: s/_PICK/_PICK_EVEN and use it only for Pipe DMC scenario. - clean up sanity check logic.(Lucas) - Add MMIO range for RKL as well.(Anusha) v5: Use DISPLAY_VER instead of per platform check (Lucas) BSpec: 49193 Cc: stable@vger.kernel.org Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
- 12 May, 2022 1 commit
-
-
Imre Deak authored
Fix the following sparse warnings: drivers/gpu/drm/i915/display/intel_display_power.c:2431:34: warning: mixing different enum types: drivers/gpu/drm/i915/display/intel_display_power.c:2431:34: unsigned int enum intel_display_power_domain drivers/gpu/drm/i915/display/intel_display_power.c:2431:34: int enum port drivers/gpu/drm/i915/display/intel_display_power.c:2442:37: warning: mixing different enum types: drivers/gpu/drm/i915/display/intel_display_power.c:2442:37: unsigned int enum intel_display_power_domain drivers/gpu/drm/i915/display/intel_display_power.c:2442:37: int enum port drivers/gpu/drm/i915/display/intel_display_power.c:2468:43: warning: mixing different enum types: drivers/gpu/drm/i915/display/intel_display_power.c:2468:43: unsigned int enum intel_display_power_domain drivers/gpu/drm/i915/display/intel_display_power.c:2468:43: unsigned int enum aux_ch drivers/gpu/drm/i915/display/intel_display_power.c:2479:35: warning: mixing different enum types: drivers/gpu/drm/i915/display/intel_display_power.c:2479:35: unsigned int enum intel_display_power_domain drivers/gpu/drm/i915/display/intel_display_power.c:2479:35: unsigned int enum aux_ch Fixes: 979e1b32 ("drm/i915: Sanitize the port -> DDI/AUX power domain mapping for each platform") Reported-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
- 11 May, 2022 1 commit
-
-
Anusha Srivatsa authored
Add Support for DC states on Dg2. v2: Add dc9 as the max supported DC states and disable DC5. v3: set max_dc to 0. (Imre) Cc: Imre Deak <imre.deak@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
- 09 May, 2022 2 commits
-
-
Jani Nikula authored
Reduce the magic of what's going on in GEM_DEBUG_EXEC() by expanding it inline and being explicit about it. It's as single use case anyway, so the macro feels overkill. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220504183716.987793-2-jani.nikula@intel.com
-
Jani Nikula authored
There are already too many choices here, take away the unused ones. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
-
- 05 May, 2022 10 commits
-
-
Ville Syrjälä authored
Make sure our choice of downclock mode respects the VBT seameless DRRS min refresh rate limit. v2: s/vrefesh/vrefresh/ (Jani) Reviewed-by:
-
Ville Syrjälä authored
Extract the seamless DRRS min refresh rate from the VBT. v2: Do a version check Reviewed-by:
-
Ville Syrjälä authored
Make the panel type code a bit more abstract along the lines of the source of the panel type. For the moment we have three classes: OpRegion, VBT, fallback. Well introduce another one shortly. We can now also print out all the different panel types, and indicate which one we ultimately selected. Could help with debugging. v2: Add .get_panel_type() vfunc (Jani) Reviewed-by:
-
Ville Syrjälä authored
Pull the code to determine the panel type into its own set of sane functions. v2: rebase Reviewed-by:
-
Ville Syrjälä authored
Just assume panel_type==0 always if the VBT gives us bogus data. We actually already do this everywhere else except in parse_panel_options() since we just leave i915->vbt.panel_type zeroed. This also seems to be what Windows does. Reviewed-by:
-
Ville Syrjälä authored
Document the fact that struct lvds_lfp_data_entry can't be used directly and instead must be accessed via the data table pointers. Also remove the bogus comment implying that there might be a variable number of panel entries in the table. There are always exactly 16. Reviewed-by:
-
Ville Syrjälä authored
We need to start parsing stuff from the tail end of the LFP data block. This is made awkward by the fact that the fp_timing table has variable size. So we must use a bit more finesse to get the tail end, and to make sure we allocate enough memory for it to make sure our struct representation fits. v2: Rebase due to the preallocation of BDB blocks v3: Rebase due to min_size WARN relocation v4: Document BDB_LVDS_LFP_DATA vs. BDB_LVDS_LFP_DATA_PTRS order (Jani) Reviewed-by:
-
Ville Syrjälä authored
Modern VBTs no longer contain the LFP data table pointers block (41). We are expecting to have one in order to be able to parse the LFP data block (42), so let's make one up. Since the fp_timing table has variable size we must somehow determine its size. Rather than just hardcode it we look for the terminator bytes (0xffff) to figure out where each table entry starts. dvo_timing, panel_pnp_id, and panel_name are expected to have fixed size. This has been observed on various machines, eg. TGL with BDB version 240, CML with BDB version 231, etc. The most recent VBT I've observed that still had block 41 had BDB version 228. So presumably the cutoff (if an exact cutoff even exists) is somewhere around BDB version 229-231. v2: kfree the thing we allocated, not the thing+3 bytes v3: Do the debugprint only if we found the LFP data block v4: Fix t0 null check (Jani) Reviewed-by:
-
Ville Syrjälä authored
Reorder things so that we can parse the entier LFP data block in one go. For now we just stick to parsing the DTD from it. Also fix the misleading comment about block 42 being deprecated. Only the DTD part is deprecated, the rest is still very much needed. v2: Move the version check+comment into parse_generic_dtd() (Jani) Reviewed-by:
-
Ville Syrjälä authored
Initialize on-stack modes with drm_mode_init() to guarantee no stack garbage in the list head, or that we aren't copying over another mode's list head. Based on the following cocci script, with manual fixups: @decl@ identifier M; expression E; @@ - struct drm_display_mode M = E; + struct drm_display_mode M; @@ identifier decl.M; expression decl.E; statement S, S1; @@ struct drm_display_mode M; ... when != S + drm_mode_init(&M, &E); + S1 @@ expression decl.E; @@ - &*E + E Signed-off-by:
-
- 04 May, 2022 1 commit
-
-
Jani Nikula authored
Make sure each DDI platform has sane ->get_buf_trans initialized. Suggested-by:
Matt Roper <matthew.d.roper@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Arun R Murthy <arun.r.murthy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220503082134.4128355-1-jani.nikula@intel.com
-
- 02 May, 2022 1 commit
-
-
Jani Nikula authored
Using compound literals for initialization can be tricky. Lacking a const qualifier, they won't end up in rodata, which is probably not expected or intended. Add const to move a whopping 136 initializers to rodata. Compare: $ objdump --syms drivers/gpu/drm/i915/display/intel_display_power_map.o | grep "\.rodata.*__compound_literal" $ objdump --syms drivers/gpu/drm/i915/display/intel_display_power_map.o | grep "\.data.*__compound_literal" Before and after the change. Fixes: c32ffce4 ("drm/i915: Convert the power well descriptor domain mask to an array of domains") Fixes: 4a845ff0 ("drm/i915: Simplify power well definitions by adding power well instances") Cc: Imre Deak <imre.deak@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
-
- 29 Apr, 2022 1 commit
-
-
https://github.com/intel/gvt-linuxJani Nikula authored
gvt-next-2022-04-29 Introduce fixes from previous pull. - Fix a compiling warning of non-static funtion only having one caller. - Fix a potential NULL pointer reference in the code re-factor. - Fix a compiling error when CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n Signed-off-by:
-
- 28 Apr, 2022 3 commits
-
-
Wan Jiabing authored
Fix following coccicheck error: ./drivers/gpu/drm/i915/gvt/handlers.c:2925:35-41: ERROR: block is NULL but dereferenced. Use gvt->mmio.mmio_block instead of block to avoid NULL pointer dereference when find_mmio_block returns NULL. Fixes: e0f74ed4 ("i915/gvt: Separate the MMIO tracking table from GVT-g") Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220427115457.836729-1-wanjiabing@vivo.comReviewed-by:
-
Zhi Wang authored
A compiling error was reported when CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n. Fix the problem by using the pre-defined macro. Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@linux.intel.com>
-
Zhi Wang authored
After the refactor of GVT-g, the reference of intel_gvt_match_device() only happens in handlers.c. Make it static to let the compiler be happy. Fixes: e0f74ed4 ("i915/gvt: Separate the MMIO tracking table from GVT-g") Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Robert Beckett <bob.beckett@collabora.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
- 27 Apr, 2022 2 commits
-
-
Matt Roper authored
The IDs added here are the subset reserved for 'motherboard down' designs of DG2. We have all the necessary support upstream to enable these now (although they'll continue to require force_probe until the usual requirements are met). The remaining DG2 IDs for add-in cards will come in a future patch once some additional required functionality has fully landed. Bspec: 44477 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
-
Imre Deak authored
To avoid AUX timeouts and subsequent spurious hotplug interrupts, make sure that the first DPCD access during detection is a read from an LTTPR register. Some ADLP DP link configuration at least with multiple LTTPRs expects the first DPCD access during the LTTPR/DPCD detection after hotplug to be a read from the LTTPR range starting with DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV. The side effect of this read is to put each LTTPR into the LTTPR transparent or LTTPR non-transparent mode. The lack of the above read may leave some of the LTTPRs in non-LTTPR mode, while other LTTPRs in LTTPR transparent or LTTPR non-transparent mode (for instance LTTPRs after system suspend/resume that kept their mode from before suspend). Due to the different AUX timeouts the different modes imply, the DPCD access from a non-LTTPR range will timeout and lead to an LTTPR generated hotplug towards the source (which the LTTPR firmware uses to account for buggy TypeC adapters with a long wake-up delay). SYSCROS: 72939 v2: Keep DPCD read-out working on non-LTTPR platforms. v3: Summarize what and why the patch does at the beginning of the commit log. (Jani) Signed-off-by:
-
- 26 Apr, 2022 3 commits
-
-
Jani Nikula authored
Need to bring commit d8bb92e7 ("drm/dp: Factor out a function to probe a DPCD address") back as a dependency to further work in drm-intel-next. Signed-off-by:
-
https://github.com/intel/gvt-linuxJani Nikula authored
gvt-next-2022-04-26 - Add two missing exports of symbols when i915 debug is enabled Signed-off-by:
-
Zhi Wang authored
When CONFIG_DRM_I915_DEBUG_RUNTIME and CONFIG_DRM_I915_DEBUG_PM are enabled, two more extra symols in i915 are required to be exported. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 25 Apr, 2022 13 commits
-
-
Ville Syrjälä authored
Start splitting the .compute_crtc_clock() into two parts; one part does the computation, the second part does the shared dpll assignment. I want to move the actual computation part much earlier into the compute_config() phase. v2: dg2_crtc_get_shared_dpll() not needed (Jani) Signed-off-by:
-
Ville Syrjälä authored
DG2 doesn't currently used the shared_dpll stuff so let's just split it out from hsw_crtc_compute_clock() entirely. Signed-off-by:
-
Ville Syrjälä authored
Clear the dpll_hw_state when we're about disable the pipe. Previously it looks like we just left the old junk in there. Signed-off-by:
-
Ville Syrjälä authored
All .crtc_compute_clock() implementations do the same memset() to clear the dpll_hw_state (since we preserve it across intel_crtc_prepare_cleared_state()). Move the memset() to the common wrapper. Signed-off-by:
-
Ville Syrjälä authored
Move some checks into intel_dpll_crtc_compute_clock() from the caller. Avoids the caller from having to worry about all this crap. We'll also reorder the hw.enable vs. shared_dpll checks since it makes sense to sanity check that we've cleared out the old shared_dpll even if the pipe is getting disabled. Signed-off-by:
-
Ville Syrjälä authored
Pass the full atomic state+crtc rather than the redundant crtc+crtc_state pair. We already need the full atomic state in the hsw+ codepath anyway. Signed-off-by:
-
Ville Syrjälä authored
All platforms have dpll_funcs. Remove the pointless NULL checks. Signed-off-by:
-
Ville Syrjälä authored
Stop passing around the drm_device and just pass the dev_priv instead. Signed-off-by:
-
Ville Syrjälä authored
Get rid of the confusing back and forth between bools and ints in the .get_dplls() stuff. Just make everything return an int. Initial conversion done with cocci, with some manual fixups on top: @find@ identifier func !~ "get_hw_state|_is_|needed"; typedef bool; parameter list[N] P; @@ - bool + int func(P) { <... ( - return true; + return 0; | - return false; + return -EINVAL; ) ...> } @@ identifier find.func; expression list[find.N] E; expression X; @@ - if (!func(E)) + ret = func(E); + if (ret) { ... - return X; + return ret; } @@ identifier find.func; expression X; expression list[find.N] E; @@ - if (!func(E)) + ret = func(E); + if (ret) - return X; + return ret; @@ identifier find.func; expression list[find.N] E; expression O, X; typedef bool; bool B; @@ - B = func(E); - if (O && !B) + if (O) { + ret = func(E); + if (ret) - return X; + return ret; + } @@ identifier find.func; expression list[find.N] E; expression O, X; @@ - if (O && !func(E)) + if (O) { + ret = func(E); + if (ret) - return X; + return ret; + } @@ identifier find.func; expression list[find.N] E; expression X; typedef bool; bool B; @@ - B = func(E); - if (!B) + ret = func(E); + if (ret) { ... - return X; + return ret; } Signed-off-by: -
Ville Syrjälä authored
intel_fbc_check_plane() is supposed to an int, not a boolean. So replace the bogus 'return false's with the correct 'return 0's. These were accidental copy-paste mistakes when the code got moved into intel_fbc_check_plane() from somewhere else tht did return a boolean. No functional issue here since false==0. Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com>
-
Ville Syrjälä authored
plane_state->uapi.crtc is not what we want to be looking at. If bigjoiner is used hw.crtc is what tells us what crtc the plane is supposedly using. Not an actual problem on current hardware as the only FBC capable pipe (A) can't be a bigjoiner slave and thus uapi.crtc==hw.crtc always here. But when we get more FBC instances this will become actually important. Fixes: 2e6c99f8 ("drm/i915/fbc: Nuke lots of crap from intel_fbc_state_cache") Signed-off-by:
-
Imre Deak authored
Fix typo in the _SEL_FETCH_PLANE_BASE_1_B register base address. Fixes: a5523e2f ("drm/i915: Add PSR2 selective fetch registers") References: https://gitlab.freedesktop.org/drm/intel/-/issues/5400 Cc: José Roberto de Souza <jose.souza@intel.com> Cc: <stable@vger.kernel.org> # v5.9+ Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220421162221.2261895-1-imre.deak@intel.com
-
Jani Nikula authored
Merge tag 'gvt-next-2022-04-21-for-christoph' of https://github.com/intel/gvt-linux into drm-intel-next gvt-next-2022-04-21-for-christoph - Separating the MMIO table from GVT-g. (Zhi) - GVT-g re-factor. (Christoph) - GVT-g mdev API cleanup. (Jason) - GVT-g trace/makefile cleanup. (Jani) [Jani: added #include to adapt to header refactoring in drm-intel-next] Signed-off-by:
-
