Repository navigation
Conversation
mainline inclusion from mainline-v6.14-rc1 category: bugfix In order to add more MBUS sanitation into the code we'll want to reuse a bunch of the code that performs the MBUS/related hardware programming. Currently that code comes after the main skl_wm_get_hw_state_and_sanitize() entrypoint. In order to avoid annoying forward declarations relocate the skl_wm_get_hw_state_and_sanitize() and related stuff nearer to the end of the file. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241031155646.15165-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit e31e868) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.14-rc1 category: bugfix We'll be wanting to reprogram the PIPE_MBUS_DBOX_CTL registers during an upcoming MBUS sanitation stage. To make that easier extract a helper that computes the full register value for us. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241031155646.15165-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 45bc523) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.14-rc1 category: bugfix We'll be wanting to reprogram the PIPE_MBUS_DBOX_CTL registers during an upcoming MBUS sanitation stage. Extract the reprogramming loop into a helper that doesn't depend on the full atomic state so that it can be reused. We'll stick to sturct drm_i915_private for now (instead of struct intel_display) since the rest of the skl wm code does the same, and we might need to bakport this. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241031155646.15165-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 7b3cb58) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.14-rc1 category: bugfix We'll be wanting to reprogram the MBUS_CTL register during an upcoming MBUS sanitation stage. Extract the reprogramming into a helper that doesn't depend on the full atomic state so that it can be reused. We'll stick to sturct drm_i915_private for now (instead of struct intel_display) since the rest of the skl wm code does the same, and we might need to bakport this. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241031155646.15165-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 0656f1f) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.14-rc1 category: bugfix If the system boots with MBUS joining enabled but we disable the relevant pipe during sanitation we later get into trouble as the rest of the code doesn't expect MBUS joining to be enabled unless the set of active pipes is in agreement. We could relax some of the MBUS joining related checks during normal atomic commits to let this slide, but that might also let some real bugs through. So let's sanitize the MBUS joining instead. And in order to keep things more or less in sync we'll do the related credit, cdclk/mdclk ratio, etc. updates as well. We'll stick to sturct drm_i915_private for now (instead of struct intel_display) since the rest of the skl wm code does the same, and we might need to bakport this. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241031155646.15165-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 4985a9b) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.14-rc1 category: bugfix Implement xelpdp_is_only_pipe_per_dbuf_bank() in a slightly more straightforward way. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241031155646.15165-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 5819326) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.8-rc1 category: bugfix Rename hdcp 1.4 enablement function from _intel_hdcp_enable to intel_hdcp1_enable to better represent what version of hdcp is being enabled Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231026121139.987437-2-suraj.kandpal@intel.com (cherry picked from commit da36ce0) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.8-rc1 category: bugfix Let's convert intel_hdcp_enable to a blanket function which just has some conditions which needs to be checked before connectors enable hdcp. This cleans up code and avoids code duplication. --v3 -Keep function name as intel_hdcp_enable() [Jani] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231026121139.987437-3-suraj.kandpal@intel.com (cherry picked from commit 4f60f06) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.8-rc1 category: bugfix When we dock a monitor we end up with a enable and disable connector cycle but if hdcp content is running we get the userspace in enabled state and driver maintaining a undesired state which causes the content to stop playing and we only enable hdcp if the userspace state in desired. This patch fixes that. --v2 -Move code to intel_hdcp [Jani] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231026121139.987437-4-suraj.kandpal@intel.com (cherry picked from commit 3b9bbd7) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion
from mainline-v6.7-rc1
category: bugfix
After recent discussions with Mesa folks, it was requested
that we optimize i915's GET_PARAM for the PXP_STATUS without
changing the UAPI spec.
Add these additional optimizations:
- If any PXP initializatoin flow failed, then ensure that
we catch it so that we can change the returned PXP_STATUS
from "2" (i.e. 'PXP is supported but not yet ready')
to "-ENODEV". This typically should not happen and if it
does, we have a platform configuration issue.
- If a PXP arbitration session creation event failed
due to incorrect firmware version or blocking SOC fusing
or blocking BIOS configuration (platform reasons that won't
change if we retry), then reflect that blockage by also
returning -ENODEV in the GET_PARAM:PXP_STATUS.
- GET_PARAM:PXP_STATUS should not wait at all if PXP is
supported but non-i915 dependencies (component-driver /
firmware) we are still pending to complete the init flows.
In this case, just return "2" immediately (i.e. 'PXP is
supported but not yet ready').
Difference from prio revs:
v3: - Rebase with latest tip that has pulled in setting the
gsc fw load to fail if proxy init fails.
v2: - Use a #define for the default readiness timeout (Vivaik).
- Improve comments around the failing of proxy-init.
v1: - Change the commit msg style to be imperative. (Jani)
- Rename timeout to timeout_ms. (Jani)
- Fix is_fw_err_platform_config to use higher order
param (pxp) first. (Jani)
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Balasubrawmanian, Vivaik <vivaik.balasubrawmanian@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230802182550.1592926-1-alan.previn.teres.alexis@intel.com
(cherry picked from commit 3b918f4)
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.9-rc1 category: bugfix When suspending, flush the context-guc-id deregistration worker at the final stages of intel_gt_suspend_late when we finally call gt_sanitize that eventually leads down to __uc_sanitize so that the deregistration worker doesn't fire off later as we reset the GuC microcontroller. Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Mousumi Jana <mousumi.jana@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231228045558.536585-2-alan.previn.teres.alexis@intel.com (cherry picked from commit 5e83c06) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.8-rc1 category: bugfix In order to show per client memory usage lets add some infrastructure which enables tracking buffer objects owned by clients. We add a per client list protected by a new per client lock and to support delayed destruction (post client exit) we make tracked objects hold references to the owning client. Also, object memory region teardown is moved to the existing RCU free callback to allow safe dereference from the fdinfo RCU read section. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231107101806.608990-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit e4ae85e) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.8-rc1 category: bugfix Account ring buffers and logical context space against the owning client memory usage stats. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231107101806.608990-4-tvrtko.ursulin@linux.intel.com (cherry picked from commit dc1a277) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.8-rc1 category: bugfix Use the newly added drm_print_memory_stats helper to show memory utilisation of our objects in drm/driver specific fdinfo output. To collect the stats we walk the per memory regions object lists and accumulate object size into the respective drm_memory_stats categories. v2: * Only account against the active region. * Use DMA_RESV_USAGE_BOOKKEEP when testing for active. (Tejas) v3: * Update commit text. (Aravind) * Update to use memory regions uabi names. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231107101806.608990-6-tvrtko.ursulin@linux.intel.com (cherry picked from commit 9688530) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.8-rc1 category: bugfix At the moment memory region names are a bit too varied and too inconsistent to be used for ABI purposes, like for upcoming fdinfo memory stats. System memory can be either system or system-ttm. Local memory has the instance number appended, others do not. Not only incosistent but thi kind of implementation detail is uninteresting for intended users of fdinfo memory stats. Add a stable name always formed as $type$instance. Could have chosen a different stable scheme, but I think any consistent and stable scheme should do just fine. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231107101806.608990-5-tvrtko.ursulin@linux.intel.com (cherry picked from commit 3b38d35) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.8-rc1 category: bugfix There is no need to return anything in the version which was merged and also the implementation of the !CONFIG_PROC_FS wasn't returning anything, causing a build failure there. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: e4ae85e ("drm/i915: Add ability for tracking buffer objects per client") Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311110104.8TlHVxUI-lkp@intel.com/ Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231113085457.199053-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit 44eea8d) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.8-rc1 category: bugfix __rcu annotation is needed to avoid the sparse warnings such as: .../i915_drm_client.c:92:9: sparse: sparse: incompatible types in comparison expression (different address spaces): .../i915_drm_client.c:92:9: sparse: struct list_head [noderef] __rcu * .../i915_drm_client.c:92:9: sparse: struct list_head * Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 9688530 ("drm/i915: Implement fdinfo memory stats printing") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311110610.h0m6ydI5-lkp@intel.com/ Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231113085457.199053-2-tvrtko.ursulin@linux.intel.com (cherry picked from commit e31b380) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.9-rc1 category: bugfix Switch to using the new gem shared memory stats helper rather than hand rolling it. Link: https://lore.kernel.org/all/20231207180225.439482-1-alexander.deucher@amd.com/ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> (cherry picked from commit 905a176) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.10-rc1 category: bugfix For Earlier platforms, the Pipe source size is 12-bits so max pipe source width and height is 4096. For newer platforms it is 13-bits so theoretically max width/height is 8192. For few of the earlier platforms the scaler did not use all bits of the PIPESRC, so max scaler source size was used to make that the pipe source size is programmed within limits, before using scaler. This creates a problem, for MTL where scaler source size is 4096, but max pipe source width can theroretically be 8192. Switch the check to use the max scaler destination size, which closely match the limits. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240313143825.3461208-1-ankit.k.nautiyal@intel.com (cherry picked from commit 183e256) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.7-rc1 category: bugfix The first production SoC steppings for DG2 were C0 (for G10), B1 (for G11), and A1 (for G12). This corresponds to PCI revision IDs 0x8, 0x5, and 0x1 respectively. Add this information to the driver's pre-production detection. Bspec: 44477 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230816214201.534095-8-matthew.d.roper@intel.com (cherry picked from commit 3d3e027) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.7-rc1 category: bugfix Currently for testing an output format with DSC, we just force the output format, without checking if it can be supported. This also creates an issue where there is a PCON which might need to convert from forced output format to the format to sink format. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230817142459.89764-19-ankit.k.nautiyal@intel.com (cherry picked from commit 7adfec8) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.7-rc1 category: bugfix Combine all DP audio configs into a single function Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230818111950.128992-3-vinod.govindapillai@intel.com (cherry picked from commit 1bd1817) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.7-rc1 category: bugfix Put parens around macro argument evaluation for safety. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230705202122.17915-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit a5d1d0a) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.7-rc1 category: bugfix The SDVO inputs are reported a simple number, not a bitmask. Adjust the code to match reality. Note that we don't actually support dual input SDVO devices, and we just always use the first input. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230705202122.17915-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 469c096) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.7-rc1 category: bugfix Allow *_calc_dpll_params() to be called even if the N/P dividers are zero without warning. We'll want to call these to make sure the derived values are fully computed, but not all users (VLV DSI in particular) even enable the DPLL and thus the dividers will be left at zero. It could also be possible that the BIOS has misprogrammed the DPLL (IIRC happened with some SNB machines with 4k+ displays) and thus we'll currently generate a lot of dmesg spew. Better be silent and just let the normal state checker/etc. deal with any driver bugs. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230705202122.17915-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 7176dca) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.7-rc1 category: bugfix Call *_calc_dpll_params() even in cases where the encoder has computed the DPLL params for us. The SDVO TV output code doesn't populate crtc_state->dpll.dot leading to the dotclock getting calculated as zero, and that leads to all kinds of real problems. The g4x DP code also doesn't populate the derived dividers nor .vco, which could also create some confusion. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230705202122.17915-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit c99c0e2) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.7-rc1 category: bugfix port_clock is what the encoder/dpll code is supposed to calculate, it is not the input clock. Use the dotclock as the target we're trying to achieve instead. TODO: the SDVO TV clocking is a mess atm and needs further work Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230705202122.17915-7-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit d320aaa) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.7-rc1 category: bugfix We were propagating dig_port info to dp hdcp2 specific functions. Let us clean that up and send intel_connector in the following functions: intel_dp_hdcp2_wait_for_msg, get_receiver_id_list_rx_info, intel_dp_hdcp2_read_rx_status. This optimises mst scenarios where aux ends up being remote and not stored in dig_port and dig_port can always be derived from intel_connector if needed. --v2 -Fix Typo [Arun] -Dont pass drm_dp core structures [Arun] -Fix commit message styling [Arun] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230828063850.604048-1-suraj.kandpal@intel.com (cherry picked from commit 524240b) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.7-rc1 category: bugfix Instead of operating on the output the user specified (via the connector) the current code tends to operate on whichever outputs it has detected as attached. That is not how the kms uapi is supposed to work. So simply get rid of attached_outputs and instead directly operate on the output the user has specified. Acked-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/20230825134431.24391-2-ville.syrjala@linux.intel.com (cherry picked from commit 31ea785) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.7-rc1 category: bugfix We should switch over to the standard "ddc" per-connector symlink instead of rolling our own thing. The i2c specific symlink is also in the way of reworking the SDVO DDC handling (which is a mess atm) so get rid of it. 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/20230825134431.24391-5-ville.syrjala@linux.intel.com (cherry picked from commit 5bb306b) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.8-rc1 category: bugfix The workaround database was just updated to extend this workaround to DG2-G11 (whereas previously it applied only to G10 and G12). Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231115182117.2551522-2-matthew.d.roper@intel.com (cherry picked from commit 89a410b) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.8-rc1 category: bugfix Commit 78cc55e ("drm/i915/mcr: Hold GT forcewake during steering operations") introduced the workaround which was in early stages. With a valid lineage number update Workaround for future tracking. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231116212511.1760446-1-radhakrishna.sripada@intel.com (cherry picked from commit 3c7a5eb) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.8-rc1 category: bugfix Use min() instead of clamp() since the color values involved are unsigned. No functional changes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231013131402.24072-4-ville.syrjala@linux.intel.com Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 5d76c81) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.8-rc1 category: bugfix drm_color_lut_extract() rounding was changed to follow the OpenGL int<->float conversion rules. Adjust intel_color_lut_pack() to match. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231013131402.24072-3-ville.syrjala@linux.intel.com Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit edc2b74) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.9-rc1 category: bugfix Commit 8015bee ("drm/i915/display: Add framework to add parameters specific to display") added the file intel_display_debugfs_params.c, which calls the functions "debugfs_create_{bool, ulong, str}" -- all of which are defined in <linux/debugfs.h>. The missing inclusion of this header file is breaking the ChromeOS build -- add an explicit include to fix that. Signed-off-by: Paz Zcharya <pazz@chromium.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240131204658.795278-1-pazz@chromium.org (cherry picked from commit 7fd4548) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.9-rc1 category: bugfix mem->region is a struct resource, but mem->io_start and mem->io_size are not for whatever reason. Let's unify this and convert the io stuff into a struct resource as well. Should make life a little less annoying when you don't have juggle between two different approaches all the time. Mostly done using cocci (with manual tweaks at all the places where we mutate io_size by hand): @@ struct intel_memory_region *M; expression START, SIZE; @@ - M->io_start = START; - M->io_size = SIZE; + M->io = DEFINE_RES_MEM(START, SIZE); @@ struct intel_memory_region *M; @@ - M->io_start + M->io.start @@ struct intel_memory_region M; @@ - M.io_start + M.io.start @@ expression M; @@ - M->io_size + resource_size(&M->io) @@ expression M; @@ - M.io_size + resource_size(&M.io) Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-2-ville.syrjala@linux.intel.com (cherry picked from commit 3c0fa9f) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.9-rc1 category: bugfix Dump the details about every memory region into dmesg at probe time. Avoids having to dig those out from random places when debugging stuff. Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-3-ville.syrjala@linux.intel.com (cherry picked from commit 2ab1fe5) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion
from mainline-v6.9-rc1
category: bugfix
On MTL accessing stolen memory via the BARs is somehow borked,
and it can hang the machine. As a workaround let's bypass the
BARs and just go straight to DSMBASE/GSMBASE instead.
Note that on every other platform this itself would hang the
machine, but on MTL the system firmware is expected to relax
the access permission guarding stolen memory to enable this
workaround, and thus direct CPU accesses should be fine.
The raw stolen memory areas won't be passed to VMs so we'll
need to risk using the BAR there for the initial setup. Once
command submission is up we should switch to MI_UPDATE_GTT
which at least shouldn't hang the whole machine.
v2: Don't use direct GSM/DSM access on guests
Add w/a number
v3: Check register 0x138914 to see if pcode did its job
Add some debug prints
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Tested-by: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-5-ville.syrjala@linux.intel.com
(cherry picked from commit c08c364)
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.9-rc1 category: bugfix Now that the GGTT PTE updates go straight to GSMBASE (bypassing GTTMMADR) there should be no more risk of system hangs? So the "binder" (ie. update the PTEs via MI_UPDATE_GTT) is no longer necessary, disable it. My main worry with the MI_UPDATE_GTT are: - only used on this one platform so very limited testing coverage - async so more opprtunities to screw things up - what happens if the engine hangs while we're waiting for MI_UPDATE_GTT to finish? - requires working command submission, so even getting a working display now depends on a lot more extra components working correctly TODO: MI_UPDATE_GTT might be interesting as an optimization though, so perhaps someone should look into always using it (assuming the GPU is alive and well)? v2: Keep using MI_UPDATE_GTT on VM guests v3: use i915_direct_stolen_access() Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-6-ville.syrjala@linux.intel.com (cherry picked from commit be5e8dc) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.9-rc1 category: bugfix 0x108100 and 0x1080c0 have been around since snb. Rename the defines appropriately. v2: Rebase Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-7-ville.syrjala@linux.intel.com (cherry picked from commit f8ae1d5) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.9-rc1 category: bugfix Move checks on the source side for HDCP2.2 into its own function so that they can be used in the HDCP remote capability check function. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240223081453.1576918-4-suraj.kandpal@intel.com (cherry picked from commit 26f7d01) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.9-rc1 category: bugfix Whenever LIC fails instead of moving from ENABLED to DESIRED CP property we directly enable HDCP1.4 without informing the userspace of this failure in link integrity check. Now we will just update the value to DESIRED send the event to userspace and then continue with the normal flow of HDCP enablement. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240226063051.1685326-5-suraj.kandpal@intel.com (cherry picked from commit 483f7d9) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.9-rc1 category: bugfix Factor out a function to read the sink's DPRX capabilities used by a follow-up patch enabling the DP tunnel BW allocation mode. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220211841.448846-10-imre.deak@intel.com (cherry picked from commit 363c317) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.9-rc1 category: bugfix A follow-up change will need to resume DP tunnels during system resume, so call intel_dp_sync_state() always for DDI encoders, so this function can resume the tunnels for all DP connectors. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220211841.448846-19-imre.deak@intel.com (cherry picked from commit 7605d0e) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.9-rc1 category: bugfix The TBT DP tunnel BW request logic in the Thunderbolt Connection Manager depends on the GFX driver reading out the sink's DPRX capabilities in response to a long HPD pulse. Since in i915 this read-out can be blocked by another connector's/encoder's hotplug event handling (which is serialized by drm_mode_config::connection_mutex), do a dummy DPRX read-out in the encoder's HPD pulse handler (which is not blocked by other encoders). Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220211841.448846-21-imre.deak@intel.com (cherry picked from commit a32f3a9) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.10-rc1 category: bugfix Allow user to provide a low latency context hint. When set, KMD sends a hint to GuC which results in special handling for this context. SLPC will ramp the GT frequency aggressively every time it switches to this context. The down freq threshold will also be lower so GuC will ramp down the GT freq for this context more slowly. We also disable waitboost for this context as that will interfere with the strategy. We need to enable the use of SLPC Compute strategy during init, but it will apply only to contexts that set this bit during context creation. Userland can check whether this feature is supported using a new param- I915_PARAM_HAS_CONTEXT_FREQ_HINT. This flag is true for all guc submission enabled platforms as they use SLPC for frequency management. The Mesa usage model for this flag is here - https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint v2: Rename flags as per review suggestions (Rodrigo, Tvrtko). Also, use flag bits in intel_context as it allows finer control for toggling per engine if needed (Tvrtko). v3: Minor review comments (Tvrtko) v4: Update comment (Sushma) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Ivan Briano <ivan.briano@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240306012759.204938-1-vinay.belgaumkar@intel.com (cherry picked from commit cec8281) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.10-rc1 category: bugfix Historically the expectation was to set brightness to max on enable, if it was zero. However, the policy should be to preserve brightness across disable/enable, for example the userspace might want to dim the brightness before disable (e.g. on suspend) and gradually bring it back up after enable (e.g. on resume). If the brightness gets bumped to max at enable, this causes flicker as the userspace expects the brightness to have been preserved across disable/enable. For example: (suspend) [53949.248875] i915 0000:00:02.0: [drm:intel_edp_backlight_off] [53949.452046] i915 0000:00:02.0: [drm:intel_backlight_set_pwm_level] set backlight PWM = 0 (wakeup) [53986.067356] i915 0000:00:02.0: [drm:intel_edp_backlight_on] [53986.067367] i915 0000:00:02.0: [drm:intel_backlight_enable] pipe A [53986.067476] i915 0000:00:02.0: [drm:intel_backlight_set_pwm_level] set backlight PWM = 96000 [53986.119766] backlight intel_backlight: PM: calling backlight_resume+0x0/0x7a @ 4916, parent: card0-eDP-1 [53986.119781] backlight intel_backlight: PM: backlight_resume+0x0/0x7a returned 0 after 0 usecs [53986.220068] [drm:intel_backlight_device_update_status] updating intel_backlight, brightness=26321/96000 [53986.220086] i915 0000:00:02.0: [drm:intel_panel_actually_set_backlight] set backlight level = 27961 Reduce the check to respecting the minimum brightness, and avoid bumping min brightness to max on enable. Note: It's possible there's still userspace out there that relies on the old behaviour. It would be unfortunate, but there's really only one way to find out. Cc: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gareth Yu <gareth.yu@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [Jani: Rewrote the commit message.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240321045311.2124111-1-gareth.yu@intel.com (cherry picked from commit 9271400) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…eed it mainline inclusion from mainline-v6.10-rc1 category: bugfix Commit 9bb66c1 ("drm/i915: Reserve some kernel space per vm") reduces the available VM space of one page in order to apply Wa_16018031267 and Wa_16018063123. This page was reserved indiscrimitely in all platforms even when not needed. Limit it to DG2 onwards. Fixes: 9bb66c1 ("drm/i915: Reserve some kernel space per vm") Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Acked-by: Michal Mrozek <michal.mrozek@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240327200546.640108-1-andi.shyti@linux.intel.com (cherry picked from commit 9721634) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.11-rc1 category: bugfix Plane .max_stride() is already a vfunc so having one made up of two branches based on the display version is silly. Split i9xx_plane_max_stride() into gen2 vs. gen3 variants so that we get rid of said check. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506125718.26001-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 7050ef3) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.11-rc1 category: bugfix To enable adding override of the default engine context image let us start shadowing the per engine state in the context. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Carlos Santa <carlos.santa@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Tvrtko Ursulin <tursulin@igalia.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://patchwork.freedesktop.org/patch/msgid/20240514145939.87427-1-tursulin@igalia.com (cherry picked from commit e1eb97c) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…nly for DP mainline inclusion from mainline-v6.12-rc1 category: bugfix If the DDI encoder output is enabled in HDMI mode there is no point in calling intel_dp_sync_state(), as in that case the DPCD initialization will fail - as expected - with AUX timeouts. Prevent calling the hook in this case. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-5-imre.deak@intel.com (cherry picked from commit a64d5fe) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.9-rc1 category: bugfix Whenever LIC fails instead of moving from ENABLED to DESIRED CP property we directly enable HDCP2.2 without informing the userspace of this failure in link integrity check. Now we will just update the value to DESIRED send the event to userspace and then continue with the normal flow of HDCP enablement. --v2 -Don't change the function prototype in this function [Ankit] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240226063051.1685326-4-suraj.kandpal@intel.com (cherry picked from commit 47ef55a) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
|
Sorry @opsiff, your pull request is larger than the review limit of 150,000 diff characters |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
There was a problem hiding this comment.
🟡 Changes recommended
A critical GuC reset race can cause use-after-free in the destruction worker, alongside unresolved functional regressions and resource leaks.
9 open issues
What changed in this PR
Backports i915 fixes and supporting infrastructure into Deepin’s Linux 6.6.y kernel, covering GPU scheduling, memory management, protected execution, and display behavior.
Changes:
- Add low-latency context frequency hints and improve GuC suspend/context cleanup and PXP readiness reporting.
- Consolidate memory I/O resources, add fdinfo memory accounting, and update stolen-memory access and GT workarounds.
- Apply display fixes and introduce shared-driver stubs and display-parameter infrastructure.
Paths below are relative to drivers/gpu/drm/i915/, except the UAPI header.
| File | Description |
|---|---|
| include/uapi/drm/i915_drm.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/selftests/intel_memory_region.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/pxp/intel_pxp.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/pxp/intel_pxp.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/pxp/intel_pxp_types.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/Makefile | Updated as part of this pull request. |
| drivers/gpu/drm/i915/intel_region_ttm.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/intel_memory_region.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/intel_memory_region.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/i915_utils.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/i915_utils.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/i915_reg.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/i915_query.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/i915_gpu_error.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/i915_getparam.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/i915_drm_client.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/i915_drm_client.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/i915_driver.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/uc/intel_uc.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/selftest_tlb.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/selftest_lrc.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/intel_workarounds.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/intel_rps.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/intel_ring_submission.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/intel_region_lmem.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/intel_lrc.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/intel_gtt.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/intel_gtt.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/intel_gt.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/intel_gt.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/intel_gt_mcr.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/intel_ggtt.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/intel_engine_regs.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/intel_context.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/intel_context_types.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gt/gen8_ppgtt.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gem/i915_gem_ttm.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gem/i915_gem_stolen.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gem/i915_gem_region.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gem/i915_gem_pm.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gem/i915_gem_object.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gem/i915_gem_object_types.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gem/i915_gem_context.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/gem/i915_gem_context_types.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/skl_watermark.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/skl_scaler.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_sdvo.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_sdvo_regs.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_pch_display.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_hdcp.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_hdcp.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_fdi.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_fdi.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_fbdev_fb.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_dpll.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_dpio_phy.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_dp.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_dp_mst.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_dp_link_training.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_dp_link_training.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_dp_hdcp.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_display.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_display_params.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_display_params.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_display_device.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_display_device.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_display_debugfs.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_display_debugfs_params.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_display_debugfs_params.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_display_core.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_ddi.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_cx0_phy.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_color.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/intel_backlight.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/i9xx_plane.h | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/i9xx_plane.c | Updated as part of this pull request. |
| drivers/gpu/drm/i915/display/hsw_ips.h | Updated as part of this pull request. |
Review effort: Max
Comment on lines
+3408
to
+3409
| spin_lock_irqsave(&ce->guc_state.lock, flags); | ||
| pending_destroyed = context_destroyed(ce); |
Comment on lines
+157
to
+176
| struct dentry *dir; | ||
| char dirname[16]; | ||
|
|
||
| snprintf(dirname, sizeof(dirname), "%s_params", i915->drm.driver->name); | ||
| dir = debugfs_lookup(dirname, minor->debugfs_root); | ||
| if (!dir) | ||
| dir = debugfs_create_dir(dirname, minor->debugfs_root); | ||
| if (IS_ERR(dir)) | ||
| return; | ||
|
|
||
| /* | ||
| * Note: We could create files for params needing special handling | ||
| * here. Set mode in params to 0 to skip the generic create file, or | ||
| * just let the generic create file fail silently with -EEXIST. | ||
| */ | ||
|
|
||
| #define REGISTER(T, x, unused, mode, ...) _intel_display_param_create_file( \ | ||
| dir, #x, mode, &i915->display.params.x); | ||
| INTEL_DISPLAY_PARAMS_FOR_EACH(REGISTER); | ||
| #undef REGISTER |
| if (force_dsc_output_format) { | ||
| if (source_can_output(intel_dp, force_dsc_output_format) && | ||
| (!drm_dp_is_branch(intel_dp->dpcd) || | ||
| sink_format != force_dsc_output_format || |
Comment on lines
+1090
to
+1092
| intel_hdcp_update_value(connector, | ||
| DRM_MODE_CONTENT_PROTECTION_DESIRED, | ||
| true); |
Comment on lines
+2492
to
+2493
| .late_register = intel_connector_register, | ||
| .early_unregister = intel_connector_unregister, |
Comment on lines
+78
to
+80
| if (ctx->client) | ||
| i915_drm_client_add_context_objects(ctx->client, | ||
| ce); |
Comment on lines
+1017
to
+1018
| if (test_bit(CONTEXT_LOW_LATENCY, &rq->context->flags)) | ||
| return; |
| if (intel_uc_uses_guc_submission(&to_gt(i915)->uc)) | ||
| value = 1; | ||
| else | ||
| value = -EINVAL; |
| * @platform_cfg_is_bad: used to track if any prior arb session creation resulted | ||
| * in a failure that was caused by a platform configuration issue, meaning that | ||
| * failure will not get resolved without a change to the platform (not kernel) | ||
| * such as BIOS configuration, firwmware update, etc. This bool gets reflected when |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.