[Intel-gfx] [PATCH 0/3] Implement CMRR Support
CMRR is a display feature that uses adaptive sync framework to vary Vtotal slightly to match the content rate exactly without frame drops. This feature is a variation of VRR where it varies Vtotal slightly (between additional 0 and 1 Vtotal scanlines) to match content rate exactly without frame drops using the adaptive sync framework. enable this feature by programing new registers for CMRR enable, CMRR_M, CMRR_N, vmin=vmax=flipline.The CMRR_M/CMRR_N ratio represents the fractional part in (actual refresh rate/target refresh rate) * origVTotal. --v6: - CMRR handling in co-existatnce of LRR and DRRS - Correct vtotal paramas accuracy and add 2 digit precision. Mitul Golani (3): drm/i915: Define and compute Transcoder CMRR registers drm/i915: Add Enable/Disable for CMRR based on VRR state drm/i915: Compute CMRR and calculate vtotal .../drm/i915/display/intel_crtc_state_dump.c | 4 +- drivers/gpu/drm/i915/display/intel_display.c | 61 +++- .../drm/i915/display/intel_display_device.h | 1 + .../drm/i915/display/intel_display_types.h| 6 + drivers/gpu/drm/i915/display/intel_vrr.c | 136 -- drivers/gpu/drm/i915/i915_reg.h | 10 ++ 6 files changed, 197 insertions(+), 21 deletions(-) -- 2.25.1
Re: [Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: add SKL/KBL connect-all quirks
On Mon, 2023-12-04 at 16:09 +0200, Kai Vehmanen wrote: > Hi, > > I'll send this first to intel-gfx to verify the i915 CI results. If > all ok, I'll send this series to ALSA/sound upstream. > > This seriers is to address kms_hdmi_inject@inject-audio failures > reported in: > https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/3 Thank you Kai for these patches. They are now pushed to topic/core-for- CI branch to help our CI BAT runs. BR, Jouni Högander > > Kai Vehmanen (3): > ALSA: hda/hdmi: add connect-all quirk for NUC5CPYB > ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Prime B560M-A > ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Z170 Pro > > sound/pci/hda/patch_hdmi.c | 3 +++ > 1 file changed, 3 insertions(+) >
Re: [Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: add SKL/KBL connect-all quirks
Hi, > -Original Message- > From: Saarinen, Jani > Sent: Monday, December 4, 2023 4:26 PM > To: Kai Vehmanen ; intel- > g...@lists.freedesktop.org; Nikula, Jani > Subject: RE: [Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: add SKL/KBL connect-all > quirks > > Hi, > > > -Original Message- > > From: Intel-gfx On Behalf Of > > Kai Vehmanen > > Sent: Monday, December 4, 2023 4:10 PM > > To: intel-gfx@lists.freedesktop.org > > Subject: [Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: add SKL/KBL > > connect-all quirks > > > > Hi, > > > > I'll send this first to intel-gfx to verify the i915 CI results. If > > all ok, I'll send this series to ALSA/sound upstream. > > > > This seriers is to address kms_hdmi_inject@inject-audio failures reported > > in: > > https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/3 > > > > Kai Vehmanen (3): > > ALSA: hda/hdmi: add connect-all quirk for NUC5CPYB > > ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Prime B560M-A > > For the series, > > Acked-By: Jani Saarinen BSW already proven to work > with https://patchwork.freedesktop.org/series/127208/ This now provenly fixing all platforms https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/index.html?testfilter=audio > > @Nikula, Jani can we add this to core-for-ci? Same question applies still to core-for-ci ? > > > ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Z170 Pro > > > > sound/pci/hda/patch_hdmi.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > -- > > 2.43.0
Re: [Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: add SKL/KBL connect-all quirks
Hi, > -Original Message- > From: Intel-gfx On Behalf Of Kai > Vehmanen > Sent: Monday, December 4, 2023 4:10 PM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: add SKL/KBL connect-all > quirks > > Hi, > > I'll send this first to intel-gfx to verify the i915 CI results. If all ok, > I'll send this > series to ALSA/sound upstream. > > This seriers is to address kms_hdmi_inject@inject-audio failures reported in: > https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/3 > > Kai Vehmanen (3): > ALSA: hda/hdmi: add connect-all quirk for NUC5CPYB > ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Prime B560M-A For the series, Acked-By: Jani Saarinen BSW already proven to work with https://patchwork.freedesktop.org/series/127208/ @Nikula, Jani can we add this to core-for-ci? > ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Z170 Pro > > sound/pci/hda/patch_hdmi.c | 3 +++ > 1 file changed, 3 insertions(+) > > -- > 2.43.0
[Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: add SKL/KBL connect-all quirks
Hi, I'll send this first to intel-gfx to verify the i915 CI results. If all ok, I'll send this series to ALSA/sound upstream. This seriers is to address kms_hdmi_inject@inject-audio failures reported in: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/3 Kai Vehmanen (3): ALSA: hda/hdmi: add connect-all quirk for NUC5CPYB ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Prime B560M-A ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Z170 Pro sound/pci/hda/patch_hdmi.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.43.0
[Intel-gfx] [PATCH 0/3] drm/i915/display: Convert link bitrate to clock
While reading HW state for C10 and C20 chips, let's update the PLL clock rates. For C20 the clock rate differs from link bit rate on DP2.0 cases and hence a conversion from link bitrate to clock is needed. Signed-off-by: Mika Kahola Mika Kahola (3): drm/i915/display: Move C20 HW readout drm/i915/display: Convert link bitrate to corresponding PLL clock drm/i915/display: Print out debug messages for clock rates drivers/gpu/drm/i915/display/intel_cx0_phy.c | 161 +++ drivers/gpu/drm/i915/display/intel_cx0_phy.h | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- 3 files changed, 100 insertions(+), 64 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH 0/3] QGV/SAGV related fixes
We have couple of customer issues, related to SAGV/QGV point calculation. Those patches contain fixes plus some additional debugs for those issues. Stanislav Lisovskiy (3): drm/i915: Add meaningful traces for QGV point info error handling drm/i915: Extract code required to calculate max qgv/psf gv point drm/i915: Disable SAGV on bw init, to force QGV point recalculation drivers/gpu/drm/i915/display/intel_bw.c | 104 drivers/gpu/drm/i915/display/intel_bw.h | 1 + drivers/gpu/drm/i915/soc/intel_dram.c | 2 + 3 files changed, 89 insertions(+), 18 deletions(-) -- 2.37.3
[Intel-gfx] [PATCH 0/3] Enable Adaptive Sync SDP Support for DP
An Adaptive Sync SDP allows a DP protocol converter to forward Adaptive Sync video with minimal buffering overhead within the converter. An Adaptive-Sync-capable DP protocol converter indicates its support by setting the related bit in the DPCD register. Computes AS SDP values based on the display configuration, ensuring proper handling of Variable Refresh Rate (VRR) in the context of Adaptive Sync. Mitul Golani (3): drm: Add Adaptive Sync SDP logging drm/i915/display/: Add Read/Write support for Adaptive Sync SDP drm/i915/display/:Compute and enable daptive Sync SDP drivers/gpu/drm/display/drm_dp_helper.c | 15 ++ .../drm/i915/display/intel_display_types.h| 1 + drivers/gpu/drm/i915/display/intel_dp.c | 139 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 11 +- drivers/gpu/drm/i915/i915_reg.h | 6 + include/drm/display/drm_dp.h | 1 + include/drm/display/drm_dp_helper.h | 30 7 files changed, 196 insertions(+), 7 deletions(-) -- 2.25.1
Re: [Intel-gfx] [PATCH 0/3] Implement CMRR Support
On Wed, 22 Nov 2023, Jani Nikula wrote: > On Wed, 22 Nov 2023, Mitul Golani > wrote: >> CMRR is a display feature that uses adaptive sync >> framework to vary Vtotal slightly to match the >> content rate exactly without frame drops. This >> feature is a variation of VRR where it varies Vtotal >> slightly (between additional 0 and 1 Vtotal scanlines) >> to match content rate exactly without frame drops >> using the adaptive sync framework. > > Please check and use the -v option of git-send-email. More precisely it's a git format-patch option, but send-email passes it along. > > BR, > Jani. > > >> >> enable this feature by programing new registers for >> CMRR enable, CMRR_M, CMRR_N, vmin=vmax=flipline.The >> CMRR_M/CMRR_N ratio represents the fractional part >> in (actual refresh rate/target refresh rate) * origVTotal. >> >> Mitul Golani (3): >> drm/i915: Define and compute Transcoder CMRR registers >> drm/i915: Add Enable/Disable for CMRR based on VRR state >> drm/i915: Compute CMRR and calculate vtotal >> >> .../drm/i915/display/intel_crtc_state_dump.c | 4 +- >> drivers/gpu/drm/i915/display/intel_display.c | 54 +++- >> .../drm/i915/display/intel_display_device.h | 1 + >> .../drm/i915/display/intel_display_types.h| 6 + >> drivers/gpu/drm/i915/display/intel_vrr.c | 129 -- >> drivers/gpu/drm/i915/i915_reg.h | 10 ++ >> 6 files changed, 184 insertions(+), 20 deletions(-) -- Jani Nikula, Intel
Re: [Intel-gfx] [PATCH 0/3] Implement CMRR Support
On Wed, 22 Nov 2023, Mitul Golani wrote: > CMRR is a display feature that uses adaptive sync > framework to vary Vtotal slightly to match the > content rate exactly without frame drops. This > feature is a variation of VRR where it varies Vtotal > slightly (between additional 0 and 1 Vtotal scanlines) > to match content rate exactly without frame drops > using the adaptive sync framework. Please check and use the -v option of git-send-email. BR, Jani. > > enable this feature by programing new registers for > CMRR enable, CMRR_M, CMRR_N, vmin=vmax=flipline.The > CMRR_M/CMRR_N ratio represents the fractional part > in (actual refresh rate/target refresh rate) * origVTotal. > > Mitul Golani (3): > drm/i915: Define and compute Transcoder CMRR registers > drm/i915: Add Enable/Disable for CMRR based on VRR state > drm/i915: Compute CMRR and calculate vtotal > > .../drm/i915/display/intel_crtc_state_dump.c | 4 +- > drivers/gpu/drm/i915/display/intel_display.c | 54 +++- > .../drm/i915/display/intel_display_device.h | 1 + > .../drm/i915/display/intel_display_types.h| 6 + > drivers/gpu/drm/i915/display/intel_vrr.c | 129 -- > drivers/gpu/drm/i915/i915_reg.h | 10 ++ > 6 files changed, 184 insertions(+), 20 deletions(-) -- Jani Nikula, Intel
[Intel-gfx] [PATCH 0/3] Implement CMRR Support
CMRR is a display feature that uses adaptive sync framework to vary Vtotal slightly to match the content rate exactly without frame drops. This feature is a variation of VRR where it varies Vtotal slightly (between additional 0 and 1 Vtotal scanlines) to match content rate exactly without frame drops using the adaptive sync framework. enable this feature by programing new registers for CMRR enable, CMRR_M, CMRR_N, vmin=vmax=flipline.The CMRR_M/CMRR_N ratio represents the fractional part in (actual refresh rate/target refresh rate) * origVTotal. Mitul Golani (3): drm/i915: Define and compute Transcoder CMRR registers drm/i915: Add Enable/Disable for CMRR based on VRR state drm/i915: Compute CMRR and calculate vtotal .../drm/i915/display/intel_crtc_state_dump.c | 4 +- drivers/gpu/drm/i915/display/intel_display.c | 54 +++- .../drm/i915/display/intel_display_device.h | 1 + .../drm/i915/display/intel_display_types.h| 6 + drivers/gpu/drm/i915/display/intel_vrr.c | 129 -- drivers/gpu/drm/i915/i915_reg.h | 10 ++ 6 files changed, 184 insertions(+), 20 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH 0/3] Implement CMRR Support
CMRR is a display feature that uses adaptive sync framework to vary Vtotal slightly to match the content rate exactly without frame drops. This feature is a variation of VRR where it varies Vtotal slightly (between additional 0 and 1 Vtotal scanlines) to match content rate exactly without frame drops using the adaptive sync framework. enable this feature by programing new registers for CMRR enable, CMRR_M, CMRR_N, vmin=vmax=flipline.The CMRR_M/CMRR_N ratio represents the fractional part in (actual refresh rate/target refresh rate) * origVTotal. Mitul Golani (3): drm/i915: Define and compute Transcoder CMRR registers drm/i915: Add Enable/Disable for CMRR based on VRR state drm/i915: Compute CMRR and calculate vtotal .../drm/i915/display/intel_crtc_state_dump.c | 4 +- drivers/gpu/drm/i915/display/intel_display.c | 54 +++- .../drm/i915/display/intel_display_device.h | 1 + .../drm/i915/display/intel_display_types.h| 6 + drivers/gpu/drm/i915/display/intel_vrr.c | 126 -- drivers/gpu/drm/i915/i915_reg.h | 10 ++ 6 files changed, 181 insertions(+), 20 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH 0/3] Prepare intel_fb for Xe
Intel fb creation is differing between Xe and i915 due to different implementations of backing object. This patch set is splitting i915 specific code into it's own source file. Similar source files will be introduced for Xe as well. Also use intel_bo_to_drm_bo instead of directly referring i915_gem_object->base. One i915_gem_object_put is changed to drm_gem_object_put. Cc: Rodrigo Vivi Cc: Maarten Lankhorst Cc: Jani Nikula Cc: Uma Shankar Jouni Högander (3): drm/i915/display: use intel_bo_to_drm_bo in intel_fb.c drm/i915/display: Convert intel_fb_modifier_to_tiling as non-static drm/i915/display: Split i915 specific code away from intel_fb.c drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_fb.c| 121 ++--- drivers/gpu/drm/i915/display/intel_fb.h| 2 + drivers/gpu/drm/i915/display/intel_fb_bo.c | 93 drivers/gpu/drm/i915/display/intel_fb_bo.h | 24 5 files changed, 153 insertions(+), 88 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_fb_bo.c create mode 100644 drivers/gpu/drm/i915/display/intel_fb_bo.h -- 2.34.1
[Intel-gfx] [PATCH 0/3] Implement CMRR Support
CMRR is a display feature that uses adaptive sync framework to vary Vtotal slightly to match the content rate exactly without frame drops. This feature is a variation of VRR where it varies Vtotal slightly (between additional 0 and 1 Vtotal scanlines) to match content rate exactly without frame drops using the adaptive sync framework. enable this feature by programing new registers for CMRR enable, CMRR_M, CMRR_N, vmin=vmax=flipline.The CMRR_M/CMRR_N ratio represents the fractional part in (actual refresh rate/target refresh rate) * origVTotal. Signed-off-by: Mitul Golani Mitul Golani (3): drm/i915: Define and compute Transcoder CMRR registers drm/i915: Add Enable/Disable for CMRR based on VRR state drm/i915: Compute CMRR and calculate vtotal .../drm/i915/display/intel_crtc_state_dump.c | 4 +- drivers/gpu/drm/i915/display/intel_display.c | 51 ++- .../drm/i915/display/intel_display_device.h | 1 + .../drm/i915/display/intel_display_types.h| 6 + drivers/gpu/drm/i915/display/intel_vrr.c | 126 -- drivers/gpu/drm/i915/i915_reg.h | 10 ++ 6 files changed, 178 insertions(+), 20 deletions(-) -- 2.25.1
Re: [Intel-gfx] [PATCH 0/3] drm/i915/hdcp: Additional conditions to enable hdcp
On 10/26/2023 5:41 PM, Suraj Kandpal wrote: We are seeing a issue when we close the lid of a laptop or dock a monitor hdcp content is not being reenabled automatically this is because 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 enabe hdcp if the userspace state in desired. This first and second patch refactors the code while the third one adds the new conditions to enable hdcp. Signed-off-by: Suraj Kandpal Suraj Kandpal (3): drm/i915/hdcp: Rename HCDP 1.4 enablement function drm/i915/hdcp: Convert intel_hdcp_enable to a blanket function drm/i915/hdcp: Add more conditions to enable hdcp Series pushed to drm-intel-next. Thanks for the patches and reviews. Regards, Ankit drivers/gpu/drm/i915/display/intel_ddi.c| 5 +-- drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +-- drivers/gpu/drm/i915/display/intel_hdcp.c | 37 - drivers/gpu/drm/i915/display/intel_hdcp.h | 8 ++--- 4 files changed, 35 insertions(+), 20 deletions(-)
[Intel-gfx] [PATCH 0/3] drm/i915/hdcp: Additional conditions to enable hdcp
We are seeing a issue when we close the lid of a laptop or dock a monitor hdcp content is not being reenabled automatically this is because 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 enabe hdcp if the userspace state in desired. This first and second patch refactors the code while the third one adds the new conditions to enable hdcp. Signed-off-by: Suraj Kandpal Suraj Kandpal (3): drm/i915/hdcp: Rename HCDP 1.4 enablement function drm/i915/hdcp: Convert intel_hdcp_enable to a blanket function drm/i915/hdcp: Add more conditions to enable hdcp drivers/gpu/drm/i915/display/intel_ddi.c| 5 +-- drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +-- drivers/gpu/drm/i915/display/intel_hdcp.c | 37 - drivers/gpu/drm/i915/display/intel_hdcp.h | 8 ++--- 4 files changed, 35 insertions(+), 20 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH 0/3] drm/i915/hdcp: Additional conditions to enable hdcp
We are seeing a issue when we close the lid of a laptop or dock a monitor hdcp content is not being reenabled automatically this is because 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 enabe hdcp if the userspace state in desired. This first and second patch refactors the code while the third one adds the new conditions to enable hdcp. Signed-off-by: Suraj Kandpal Suraj Kandpal (3): drm/i915/hdcp: Rename HCDP 1.4 enablement function drm/i915/hdcp: Convert intel_hdcp_enable to a blanket function drm/i915/hdcp: Add more conditions to enable hdcp drivers/gpu/drm/i915/display/intel_ddi.c| 5 +-- drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +-- drivers/gpu/drm/i915/display/intel_hdcp.c | 37 - drivers/gpu/drm/i915/display/intel_hdcp.h | 8 ++--- 4 files changed, 35 insertions(+), 20 deletions(-) -- 2.25.1
Re: [Intel-gfx] [PATCH 0/3] Trim some pre-production code
Hi Tvrtko, > A little bit of house keeping, trimming off some pre-production hardware and > incomplete platform support. > > Tvrtko Ursulin (3): > drm/i915: Remove early/pre-production Haswell code > drm/i915: Remove incomplete PVC plumbing > drm/i915: Remove xehpsdv support That's a very nice cleanup! Thanks! I have started this same work long time ago, but ever since it has been sitting there with little progress. Will review it now. Thanks, Andi
[Intel-gfx] [PATCH 0/3] Trim some pre-production code
From: Tvrtko Ursulin A little bit of house keeping, trimming off some pre-production hardware and incomplete platform support. Tvrtko Ursulin (3): drm/i915: Remove early/pre-production Haswell code drm/i915: Remove incomplete PVC plumbing drm/i915: Remove xehpsdv support .../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +- drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 3 - drivers/gpu/drm/i915/gt/intel_gsc.c | 15 -- drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 47 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 - drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 20 +- drivers/gpu/drm/i915/gt/intel_mocs.c | 50 - drivers/gpu/drm/i915/gt/intel_rps.c | 6 +- drivers/gpu/drm/i915/gt/intel_sseu.c | 9 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 176 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 - drivers/gpu/drm/i915/i915_debugfs.c | 12 -- drivers/gpu/drm/i915/i915_driver.c| 1 - drivers/gpu/drm/i915/i915_drv.h | 15 -- drivers/gpu/drm/i915/i915_hwmon.c | 6 - drivers/gpu/drm/i915/i915_pci.c | 52 -- drivers/gpu/drm/i915/i915_perf.c | 4 +- drivers/gpu/drm/i915/i915_reg.h | 2 - drivers/gpu/drm/i915/intel_clock_gating.c | 26 +-- drivers/gpu/drm/i915/intel_device_info.c | 2 - drivers/gpu/drm/i915/intel_device_info.h | 2 - drivers/gpu/drm/i915/intel_step.c | 80 +--- drivers/gpu/drm/i915/intel_uncore.c | 142 -- drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 - 24 files changed, 15 insertions(+), 664 deletions(-) -- 2.39.2
Re: [Intel-gfx] [PATCH 0/3] drm/i915: nuke i915->gt0
On Mon, 02 Oct 2023, Andi Shyti wrote: > Hi Jani, > > adding a few folks in Cc for some extra eyes on this series. Thanks for the reviews and acks, pushed to drm-intel-next. drm-intel-next instead of drm-intel-gt-next because of the changes in i915_drv.h, and it's easier to sync from din to dign than vice versa. BR, Jani. > > On Mon, Oct 02, 2023 at 11:47:01AM +0300, Jani Nikula wrote: >> Chopping up [1] to more digestable pieces. Start off with nuking >> i915->gt0. >> >> [1] https://patchwork.freedesktop.org/series/124418/ >> >> Jani Nikula (3): >> drm/i915/mocs: use to_gt() instead of direct &i915->gt >> drm/i915: allocate i915->gt0 dynamically >> drm/i915/gt: remove i915->gt0 in favour of i915->gt[0] >> >> drivers/gpu/drm/i915/gt/intel_gt.c | 10 +++--- >> drivers/gpu/drm/i915/gt/intel_mocs.c | 4 ++-- >> drivers/gpu/drm/i915/i915_drv.h | 10 ++ >> drivers/gpu/drm/i915/selftests/mock_gem_device.c | 1 - >> 4 files changed, 11 insertions(+), 14 deletions(-) > > Michal, Michal and Tomasz, can you please check here? > > Thanks, > Andi -- Jani Nikula, Intel
Re: [Intel-gfx] [PATCH 0/3] drm/i915: nuke i915->gt0
On Mon, Oct 02, 2023 at 04:04:51PM +0200, Andi Shyti wrote: > Hi Jani, > > adding a few folks in Cc for some extra eyes on this series. > > On Mon, Oct 02, 2023 at 11:47:01AM +0300, Jani Nikula wrote: > > Chopping up [1] to more digestable pieces. Start off with nuking > > i915->gt0. > > > > [1] https://patchwork.freedesktop.org/series/124418/ > > > > Jani Nikula (3): > > drm/i915/mocs: use to_gt() instead of direct &i915->gt > > drm/i915: allocate i915->gt0 dynamically > > drm/i915/gt: remove i915->gt0 in favour of i915->gt[0] > > > > drivers/gpu/drm/i915/gt/intel_gt.c | 10 +++--- > > drivers/gpu/drm/i915/gt/intel_mocs.c | 4 ++-- > > drivers/gpu/drm/i915/i915_drv.h | 10 ++ > > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 1 - > > 4 files changed, 11 insertions(+), 14 deletions(-) > > Michal, Michal and Tomasz, can you please check here? > > Thanks, > Andi Acked-by: Michał Winiarski -Michał
Re: [Intel-gfx] [PATCH 0/3] drm/i915: nuke i915->gt0
Hi Jani, > adding a few folks in Cc for some extra eyes on this series. > > On Mon, Oct 02, 2023 at 11:47:01AM +0300, Jani Nikula wrote: > > Chopping up [1] to more digestable pieces. Start off with nuking > > i915->gt0. > > > > [1] https://patchwork.freedesktop.org/series/124418/ > > > > Jani Nikula (3): > > drm/i915/mocs: use to_gt() instead of direct &i915->gt > > drm/i915: allocate i915->gt0 dynamically > > drm/i915/gt: remove i915->gt0 in favour of i915->gt[0] > > > > drivers/gpu/drm/i915/gt/intel_gt.c | 10 +++--- > > drivers/gpu/drm/i915/gt/intel_mocs.c | 4 ++-- > > drivers/gpu/drm/i915/i915_drv.h | 10 ++ > > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 1 - > > 4 files changed, 11 insertions(+), 14 deletions(-) > > Michal, Michal and Tomasz, can you please check here? please don't merge this patch without first receiving a feedback by the the guys I Cc'ed. Thanks, Andi
Re: [Intel-gfx] [PATCH 0/3] drm/i915: nuke i915->gt0
Hi Jani, adding a few folks in Cc for some extra eyes on this series. On Mon, Oct 02, 2023 at 11:47:01AM +0300, Jani Nikula wrote: > Chopping up [1] to more digestable pieces. Start off with nuking > i915->gt0. > > [1] https://patchwork.freedesktop.org/series/124418/ > > Jani Nikula (3): > drm/i915/mocs: use to_gt() instead of direct &i915->gt > drm/i915: allocate i915->gt0 dynamically > drm/i915/gt: remove i915->gt0 in favour of i915->gt[0] > > drivers/gpu/drm/i915/gt/intel_gt.c | 10 +++--- > drivers/gpu/drm/i915/gt/intel_mocs.c | 4 ++-- > drivers/gpu/drm/i915/i915_drv.h | 10 ++ > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 1 - > 4 files changed, 11 insertions(+), 14 deletions(-) Michal, Michal and Tomasz, can you please check here? Thanks, Andi
[Intel-gfx] [PATCH 0/3] drm/i915: nuke i915->gt0
Chopping up [1] to more digestable pieces. Start off with nuking i915->gt0. [1] https://patchwork.freedesktop.org/series/124418/ Jani Nikula (3): drm/i915/mocs: use to_gt() instead of direct &i915->gt drm/i915: allocate i915->gt0 dynamically drm/i915/gt: remove i915->gt0 in favour of i915->gt[0] drivers/gpu/drm/i915/gt/intel_gt.c | 10 +++--- drivers/gpu/drm/i915/gt/intel_mocs.c | 4 ++-- drivers/gpu/drm/i915/i915_drv.h | 10 ++ drivers/gpu/drm/i915/selftests/mock_gem_device.c | 1 - 4 files changed, 11 insertions(+), 14 deletions(-) -- 2.39.2
[Intel-gfx] [PATCH 0/3] scalable display feature configurations
Get the reported device capabilities and update DSC and scaler feature support Vinod Govindapillai (3): drm/i915/xe2lpd: display capability register definitions drm/i915/xe2lpd: update the dsc feature capability drm/i915/xe2lpd: update the scaler feature capability drivers/gpu/drm/i915/display/intel_display_device.c | 13 + drivers/gpu/drm/i915/i915_reg.h | 5 + 2 files changed, 18 insertions(+) -- 2.34.1
[Intel-gfx] [PATCH 0/3] Engine busyness v2
From: John Harrison The latest GuC implements a new and improved scheme for tracking engine busyness. So make use of it. Note that this change comes along with a new set of PMU counters. The old counters have a fundamental problem that they are defined in terms of wall time but the sampling is now all done by the GPU in terms of clock ticks. This leads to issues with timebase conversion, some of which are non-trivial. For existing platforms, the old counters will still be updated by the new scheme and will still suffer all the same issues. For newer platforms (MTL onwards), the old counters are no longer supported. Instead, there is a new set of tick based counters. These include the actual busyness count per engine plus a total ticks count. The intention is that they should be queried as an atomic pair and used together to determine a busyness percentage. No assumptions may be made about tick frequencies or relations to wall time. Test-with: 20230922215233.2438200-1-umesh.nerlige.rama...@intel.com Signed-off-by: John Harrison John Harrison (1): drm/i915/guc: Support new and improved engine busyness Umesh Nerlige Ramappa (2): drm/i915/mtl: Add a PMU counter for total active ticks drm/i915/mtl: Add counters for engine busyness ticks drivers/gpu/drm/i915/gt/intel_engine.h| 1 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 16 + drivers/gpu/drm/i915/gt/intel_engine_types.h | 16 +- drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 + .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 4 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 82 ++-- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 55 ++- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h| 9 +- drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 23 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 460 ++ .../gpu/drm/i915/gt/uc/intel_guc_submission.h | 1 + drivers/gpu/drm/i915/i915_pmu.c | 31 +- drivers/gpu/drm/i915/i915_pmu.h | 2 +- include/uapi/drm/i915_drm.h | 15 +- 14 files changed, 570 insertions(+), 146 deletions(-) -- 2.41.0
[Intel-gfx] [PATCH 0/3] drm/i915/display: remove last uses of GEM_BUG_ON/GEM_WARN_ON
The display code has almost no uses of GEM_BUG_ON/GEM_WARN_ON. Remove the last ones to be clean of them. Jani Nikula (3): drm/i915/fbc: replace GEM_BUG_ON() to drm_WARN_ON() drm/i915/fb: replace GEM_WARN_ON() with drm_WARN_ON() drm/i915/dpt: replace GEM_BUG_ON() with drm_WARN_ON() drivers/gpu/drm/i915/display/intel_dpt.c| 2 +- drivers/gpu/drm/i915/display/intel_fb_pin.c | 3 ++- drivers/gpu/drm/i915/display/intel_fbc.c| 14 -- 3 files changed, 11 insertions(+), 8 deletions(-) -- 2.39.2
[Intel-gfx] [PATCH 0/3] drm/i915/perf: A few fixes and enhancements
Ashutosh Dixit (2): drm/i915/perf: Subtract gtt_offset from hw_tail drm/i915/perf: Remove gtt_offset from stream->oa_buffer.head/.tail Umesh Nerlige Ramappa (1): drm/i915/perf: Initialize gen12 OA buffer unconditionally drivers/gpu/drm/i915/i915_perf.c | 62 ++-- 1 file changed, 18 insertions(+), 44 deletions(-) -- 2.41.0
[Intel-gfx] [PATCH 0/3] drm/i915: Slightly more atomic multi-pipe commits
From: Ville Syrjälä Attempt at making synced multi-pipe commits a bit more atomic. Ville Syrjälä (3): drm/i915: Drop redundant !modeset check drm/i915: Split intel_update_crtc() into two parts drm/i915: Do plane/etc. updates more atomically across pipes drivers/gpu/drm/i915/display/intel_display.c | 40 ++-- 1 file changed, 37 insertions(+), 3 deletions(-) -- 2.41.0
[Intel-gfx] [PATCH 0/3] Get optimal audio frequency and channels
Currently we do not check if there is enough bandwidth for audio, and what channels and freq it can really support. Also sometimes there can be HW constraints e.g. GLK where audio channels supported are only 2. https://patchwork.freedesktop.org/series/107647/ Obtain the optimal audio rate and channel based on available display timing constraints. This can be achieved by: - Retrieve the supported channel and rate information from SADs - Adding audio-related config parameters in the CRTC state, such as audio support, rate, and channel. - Initializing the audio config parameters with the maximum supported rate and channel by the audio source. - Computing the SADs based on the audio source's capabilities. Signed-off-by: Mitul Golani Mitul Golani (3): drm/i915: Add has_audio to separate audio parameter in crtc_state drm: Add Wrapper Functions for ELD SAD Extraction drm/i915/display: Configure and initialize HDMI audio capabilities drivers/gpu/drm/i915/display/g4x_dp.c | 4 +- drivers/gpu/drm/i915/display/g4x_hdmi.c | 16 +-- drivers/gpu/drm/i915/display/intel_audio.c| 133 +- drivers/gpu/drm/i915/display/intel_cdclk.c| 6 +- .../drm/i915/display/intel_crtc_state_dump.c | 4 +- drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- drivers/gpu/drm/i915/display/intel_display.c | 4 +- .../drm/i915/display/intel_display_types.h| 12 +- drivers/gpu/drm/i915/display/intel_dp.c | 2 +- drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +- drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +- include/drm/drm_edid.h| 15 +- 13 files changed, 175 insertions(+), 37 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH 0/3] Define a final failure state when link training fails
Currently, when link training fails after all fallback values have been exhausted, the i915 driver seizes to send uevents to userspace. This leave userspace thinking that the last passing atomic commit was successful, and that all connectors (displays) are connected and operational, when in fact, the last link failed to train and the displays remain dark. This manifests as "zombie" displays in userspace, in which users observe the displays appear in their display settings page, but they are dark and unresponsive. Since, at the time of writing, MST link training fallback is not implemented, failing MST link training is a significantly more common case then a complete SST link training failure. And with users using MST hubs than ever to connect multiple displays via their USB-C ports we observe this case often. This patchset series suggest a solution, in which a final failure state is defined. In this final state, the connector's bit rate capabilities, namely max_link_rate and max_link_lane_count, are set to 0. This effectively set the connector's bandwidth to 0Gbps, thus causing all its modes to be pruned in the following connector probing. Next, with this state defined, we emit a link-status=Bad uevent. The next time userspace probes the connector, it should recognize that the connector has no modes and ignore it since it is in a bad state. I am aware that always sending a uevent and never stopping may result in some userspaces having their expectations broken and enter an infinite loop of modesets and link-training attempts. However, per DRM link-status spec: ``` * link-status: * Connector link-status property to indicate the status of link. The * default value of link-status is "GOOD". If something fails during or * after modeset, the kernel driver may set this to "BAD" and issue a * hotplug uevent. Drivers should update this value using * drm_connector_set_link_status_property(). * * When user-space receives the hotplug uevent and detects a "BAD" * link-status, the sink doesn't receive pixels anymore (e.g. the screen * becomes completely black). The list of available modes may have * changed. User-space is expected to pick a new mode if the current one * has disappeared and perform a new modeset with link-status set to * "GOOD" to re-enable the connector. ``` (form drivers/gpu/drm/drm_connector.c - DOC: standard connector properties) it seems reasonable to assume that the suggested state is an extension of the spec's guidelines, in which the next new mode userspace picks for a connector with no modes is - none, thus breaking the cycle of failed link-training attempts. I suspect that, maybe, zeroing out the bit rate capabilities is not the right way to go, and perhaps marking the connector as disconnected instead may be a better solution. However, if marking a connector disconnected is the way to go, We will have to iterate over all MST ports in the MST case and mark the spawned connectors as disconnected as well. As a final note I should add that this approach was tested with ChromeOS as userspace, and we observed that the zombie displays stop showing up once the connectors are pruned of all their modes and are ignored by userspace. For your consideration and guidance. Thanks, Gil Dekel (3): drm/i915/dp_link_training: Add a final failing state to link training fallback drm/i915/dp_link_training: Add a final failing state to link training fallback for MST drm/i915/dp_link_training: Emit a link-status=Bad uevent with trigger property Cc: Jani Nikula Cc: Manasi Navare Cc: Sean Paul Signed-off-by: Gil Dekel --- drivers/gpu/drm/i915/display/intel_dp.c | 50 +-- drivers/gpu/drm/i915/display/intel_dp.h | 4 +- .../drm/i915/display/intel_dp_link_training.c | 8 +-- 3 files changed, 41 insertions(+), 21 deletions(-) -- Gil Dekel, Software Engineer, Google / ChromeOS Display and Graphics
Re: [Intel-gfx] [PATCH 0/3] Get optimal audio frequency and channels
Hi, On Thu, 17 Aug 2023, Mitul Golani wrote: > Currently we do not check if there is enough bandwidth for > audio, and what channels and freq it can really support. > Also sometimes there can be HW constraints e.g. GLK where audio > channels supported are only 2. [...] > Mitul Golani (3): > drm/i915: Add has_audio to separate audio parameter in crtc_state > drm/i915/display: Configure and initialize HDMI audio capabilities > drm/i915/display: Add wrapper to Compute SAD thanks, looks good now. The adjusted logic to balance between channels and rates seems to hit a fair balance. For the series: Reviewed-by: Kai Vehmanen Br, Kai
[Intel-gfx] [PATCH 0/3] Get optimal audio frequency and channels
Currently we do not check if there is enough bandwidth for audio, and what channels and freq it can really support. Also sometimes there can be HW constraints e.g. GLK where audio channels supported are only 2. https://patchwork.freedesktop.org/series/107647/ Obtain the optimal audio rate and channel based on available display timing constraints. This can be achieved by: - Retrieve the supported channel and rate information from SADs - Adding audio-related config parameters in the CRTC state, such as audio support, rate, and channel. - Initializing the audio config parameters with the maximum supported rate and channel by the audio source. - Computing the SADs based on the audio source's capabilities. Signed-off-by: Mitul Golani Mitul Golani (3): drm/i915: Add has_audio to separate audio parameter in crtc_state drm/i915/display: Configure and initialize HDMI audio capabilities drm/i915/display: Add wrapper to Compute SAD drivers/gpu/drm/i915/display/g4x_dp.c | 4 +- drivers/gpu/drm/i915/display/g4x_hdmi.c | 16 +- drivers/gpu/drm/i915/display/intel_audio.c| 149 +- drivers/gpu/drm/i915/display/intel_cdclk.c| 6 +- .../drm/i915/display/intel_crtc_state_dump.c | 4 +- drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- drivers/gpu/drm/i915/display/intel_display.c | 4 +- .../drm/i915/display/intel_display_types.h| 12 +- drivers/gpu/drm/i915/display/intel_dp.c | 2 +- drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +- drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +- 12 files changed, 181 insertions(+), 32 deletions(-) -- 2.25.1
Re: [Intel-gfx] [PATCH 0/3] drm/i915: Fix Wa_22016122933 implementation
Hi Jonathan, pushed in drm-intel-gt-next. I added two links to the commit logs: the first one refers to this series, while the second refers to the series sent to CI which includes the rebase conflict fix. Hope this is fine. Thanks, Andi On Tue, Aug 01, 2023 at 08:32:39AM -0700, Jonathan Cavitt wrote: > WA_22016122933 was recently applied to all MeteorLake engines, which is > simultaneously too broad (should only apply to Media engines) and too > specific (should apply to all platforms that use the same media engine > as MeteorLake). Correct this for all current use cases. > > There are two additional changes that deserve special attention: > > > First, the usage of the workaround in i915_coherent_map_type required > a more invasive change to check the gt, which was split into its own > patch. > > Second, the addition of write barriers during ct_read and > gsc_fw_load_prepare were found to be unconditional, so the workaround > tags were removed as the usages were not platform dependent. > > v2: > - Refactor i915_coherent_map_type to intel_gt_coherent_map_type and move > it to the gt folder as it now takes an intel_gt instead of a > drm_i915_private. > > v3: > - Remove additional gt requirement from shmem_create_from_object. > Instead of passing a gt to check if the workaround applies in > intel_gt_coherent_map_type, only check if the object is lmem to > determine the map type to use. > > v4: > - Fix formatting warnings. > - Add this cover letter and all missing revision notes. > - Add missing acks and reviews to commit messages. > - Fix contributor ordering in commit messages. > > Jonathan Cavitt (3): > drm/i915/gt: Simplify shmem_create_from_object map_type selection > drm/i915: Make i915_coherent_map_type GT-centric > drm/i915/gt: Apply workaround 22016122933 correctly > > drivers/gpu/drm/i915/display/intel_hdcp_gsc.c| 3 ++- > drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 > drivers/gpu/drm/i915/gem/i915_gem_pages.c| 15 --- > .../drm/i915/gem/selftests/i915_gem_migrate.c| 12 ++-- > drivers/gpu/drm/i915/gt/intel_engine_pm.c| 2 +- > drivers/gpu/drm/i915/gt/intel_gt.c | 16 > drivers/gpu/drm/i915/gt/intel_gt.h | 9 + > drivers/gpu/drm/i915/gt/intel_gtt.c | 4 ++-- > drivers/gpu/drm/i915/gt/intel_lrc.c | 13 +++-- > drivers/gpu/drm/i915/gt/intel_ring.c | 3 ++- > drivers/gpu/drm/i915/gt/selftest_context.c | 5 +++-- > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 ++-- > drivers/gpu/drm/i915/gt/selftest_lrc.c | 6 +++--- > drivers/gpu/drm/i915/gt/shmem_utils.c| 3 +-- > drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 7 +-- > drivers/gpu/drm/i915/gt/uc/intel_guc.c | 11 ++- > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c| 4 > drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c| 3 +-- > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 3 ++- > drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 3 ++- > drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 5 - > drivers/gpu/drm/i915/selftests/igt_spinner.c | 2 +- > 22 files changed, 71 insertions(+), 66 deletions(-) > > -- > 2.25.1
[Intel-gfx] [PATCH 0/3] drm/i915: Fix Wa_22016122933 implementation
WA_22016122933 was recently applied to all MeteorLake engines, which is simultaneously too broad (should only apply to Media engines) and too specific (should apply to all platforms that use the same media engine as MeteorLake). Correct this for all current use cases. There are two additional changes that deserve special attention: First, the usage of the workaround in i915_coherent_map_type required a more invasive change to check the gt, which was split into its own patch. Second, the addition of write barriers during ct_read and gsc_fw_load_prepare were found to be unconditional, so the workaround tags were removed as the usages were not platform dependent. v2: - Refactor i915_coherent_map_type to intel_gt_coherent_map_type and move it to the gt folder as it now takes an intel_gt instead of a drm_i915_private. v3: - Remove additional gt requirement from shmem_create_from_object. Instead of passing a gt to check if the workaround applies in intel_gt_coherent_map_type, only check if the object is lmem to determine the map type to use. v4: - Fix formatting warnings. - Add this cover letter and all missing revision notes. - Add missing acks and reviews to commit messages. - Fix contributor ordering in commit messages. Jonathan Cavitt (3): drm/i915/gt: Simplify shmem_create_from_object map_type selection drm/i915: Make i915_coherent_map_type GT-centric drm/i915/gt: Apply workaround 22016122933 correctly drivers/gpu/drm/i915/display/intel_hdcp_gsc.c| 3 ++- drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 drivers/gpu/drm/i915/gem/i915_gem_pages.c| 15 --- .../drm/i915/gem/selftests/i915_gem_migrate.c| 12 ++-- drivers/gpu/drm/i915/gt/intel_engine_pm.c| 2 +- drivers/gpu/drm/i915/gt/intel_gt.c | 16 drivers/gpu/drm/i915/gt/intel_gt.h | 9 + drivers/gpu/drm/i915/gt/intel_gtt.c | 4 ++-- drivers/gpu/drm/i915/gt/intel_lrc.c | 13 +++-- drivers/gpu/drm/i915/gt/intel_ring.c | 3 ++- drivers/gpu/drm/i915/gt/selftest_context.c | 5 +++-- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 ++-- drivers/gpu/drm/i915/gt/selftest_lrc.c | 6 +++--- drivers/gpu/drm/i915/gt/shmem_utils.c| 3 +-- drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 7 +-- drivers/gpu/drm/i915/gt/uc/intel_guc.c | 11 ++- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c| 4 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c| 3 +-- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 3 ++- drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 3 ++- drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 5 - drivers/gpu/drm/i915/selftests/igt_spinner.c | 2 +- 22 files changed, 71 insertions(+), 66 deletions(-) -- 2.25.1
Re: [Intel-gfx] [PATCH 0/3] drm/i915/uncore: unclaimed reg debug race fix and optimization
On Tue, 04 Jul 2023, Jani Nikula wrote: > Fix a race in unclaimed reg debug. This does increase the code size for > CONFIG_DRM_I915_DEBUG_MMIO=y. > > However, also add an optimization to reduce code size for > CONFIG_DRM_I915_DEBUG_MMIO=n. > > Do we care about the bloat for the debug config? > > Before/after for both CONFIG_DRM_I915_DEBUG_MMIO=y and =n. > > > $ scripts/bloat-o-meter intel_uncore.before.with-debug.o > intel_uncore.after.with-debug.o > add/remove: 0/2 grow/shrink: 10/0 up/down: 927/-149 (778) > Function old new delta > fwtable_read16 721 821+100 > fwtable_read32 719 817 +98 > fwtable_read8722 818 +96 > fwtable_read64 722 817 +95 > gen6_write16 679 772 +93 > gen6_write8 678 769 +91 > gen6_write32 677 768 +91 > fwtable_write16 742 831 +89 > fwtable_write8 741 828 +87 > fwtable_write32 740 827 +87 > __pfx___unclaimed_reg_debug 16 - -16 > __unclaimed_reg_debug133 --133 Looking at the size decrease for __unclaimed_reg_debug(), it occurs to me the compiler wasn't previously inlining unclaimed_reg_debug() regardless of the inline keyword. It just bundled unclaimed_reg_debug() together with __unclaimed_reg_debug(), and called it. The juggling here actually makes them both inline, which presumably was the original intention. The optimization for CONFIG_DRM_I915_DEBUG_MMIO=n below is the good stuff. BR, Jani. > Total: Before=33797, After=34575, chg +2.30% > > $ scripts/bloat-o-meter intel_uncore.before.without-debug.o > intel_uncore.after.without-debug.o > add/remove: 0/2 grow/shrink: 0/10 up/down: 0/-2557 (-2557) > Function old new delta > __pfx___unclaimed_reg_debug 16 - -16 > __unclaimed_reg_debug133 --133 > gen6_write8 678 446-232 > gen6_write32 677 445-232 > gen6_write16 679 447-232 > fwtable_read64 722 482-240 > fwtable_read32 719 479-240 > fwtable_read16 721 481-240 > fwtable_read8722 480-242 > fwtable_write8 741 491-250 > fwtable_write32 740 490-250 > fwtable_write16 742 492-250 > Total: Before=33797, After=31240, chg -7.57% > > Cc: Lee Shawn C > > Jani Nikula (3): > drm/i915/uncore: split unclaimed_reg_debug() to header and footer > drm/i915/uncore: fix race around i915->params.mmio_debug > drm/i915/uncore: optimize CONFIG_DRM_I915_DEBUG_MMIO=n more > > drivers/gpu/drm/i915/intel_uncore.c | 47 ++--- > 1 file changed, 29 insertions(+), 18 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH 0/3] drm/i915/uncore: unclaimed reg debug race fix and optimization
Fix a race in unclaimed reg debug. This does increase the code size for CONFIG_DRM_I915_DEBUG_MMIO=y. However, also add an optimization to reduce code size for CONFIG_DRM_I915_DEBUG_MMIO=n. Do we care about the bloat for the debug config? Before/after for both CONFIG_DRM_I915_DEBUG_MMIO=y and =n. $ scripts/bloat-o-meter intel_uncore.before.with-debug.o intel_uncore.after.with-debug.o add/remove: 0/2 grow/shrink: 10/0 up/down: 927/-149 (778) Function old new delta fwtable_read16 721 821+100 fwtable_read32 719 817 +98 fwtable_read8722 818 +96 fwtable_read64 722 817 +95 gen6_write16 679 772 +93 gen6_write8 678 769 +91 gen6_write32 677 768 +91 fwtable_write16 742 831 +89 fwtable_write8 741 828 +87 fwtable_write32 740 827 +87 __pfx___unclaimed_reg_debug 16 - -16 __unclaimed_reg_debug133 --133 Total: Before=33797, After=34575, chg +2.30% $ scripts/bloat-o-meter intel_uncore.before.without-debug.o intel_uncore.after.without-debug.o add/remove: 0/2 grow/shrink: 0/10 up/down: 0/-2557 (-2557) Function old new delta __pfx___unclaimed_reg_debug 16 - -16 __unclaimed_reg_debug133 --133 gen6_write8 678 446-232 gen6_write32 677 445-232 gen6_write16 679 447-232 fwtable_read64 722 482-240 fwtable_read32 719 479-240 fwtable_read16 721 481-240 fwtable_read8722 480-242 fwtable_write8 741 491-250 fwtable_write32 740 490-250 fwtable_write16 742 492-250 Total: Before=33797, After=31240, chg -7.57% Cc: Lee Shawn C Jani Nikula (3): drm/i915/uncore: split unclaimed_reg_debug() to header and footer drm/i915/uncore: fix race around i915->params.mmio_debug drm/i915/uncore: optimize CONFIG_DRM_I915_DEBUG_MMIO=n more drivers/gpu/drm/i915/intel_uncore.c | 47 ++--- 1 file changed, 29 insertions(+), 18 deletions(-) -- 2.39.2
[Intel-gfx] [PATCH 0/3] Move stolen memory handling details into i915_gem_stolen
We are preparing for Xe driver. Stolen memory handling will be different in Xe driver. Due to this we want to remove all stolen memory handling details away from FBC code. Cc: Jani Nikula Cc: Rodrigo Vivi Cc: Ville Syrjälä Cc: Maarten Lankhorst Jouni Högander (3): drm/i915: Move stolen memory handling into i915_gem_stolen drm/i915/fbc: Make FBC check stolen at use time drm/i915/fbc: Moved fence related code away from intel_fbc drivers/gpu/drm/i915/display/intel_fbc.c | 64 -- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 37 + drivers/gpu/drm/i915/gem/i915_gem_stolen.h | 13 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 + drivers/gpu/drm/i915/i915_vma.h| 5 ++ 5 files changed, 91 insertions(+), 30 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH 0/3] Avoid reading OA reports before they land
Fix OA issue seen on DG2 where parts of OA reports are zeroed out or have stale values. This was due to the fact that rewind logic was not being run when the tail pointer was aged. The series drops the complex aging/aged logic and just checks the reports for validity. rev1 - https://patchwork.freedesktop.org/series/118054/ Signed-off-by: Umesh Nerlige Ramappa Umesh Nerlige Ramappa (3): i915/perf: Drop the aging_tail logic in perf OA i915/perf: Do not add ggtt offset to hw_tail i915/perf: Drop the aged_tail from rewind logic drivers/gpu/drm/i915/i915_perf.c | 76 ++ drivers/gpu/drm/i915/i915_perf_types.h | 12 2 files changed, 28 insertions(+), 60 deletions(-) -- 2.36.1
[Intel-gfx] [PATCH 0/3] Use FAST_REQUEST mechanism for non-blocking H2G calls
From: John Harrison The GuC interface supports a mechanism for returning errors against non-blocking H2G calls. This is called FAST_REQUEST. Given that the call is asynchronous, matching the returned error up is difficult. However, getting any error at all back is better than no error. If any such errors are reported, then extra tracking support can be compiled in for manual debug. Signed-off-by: John Harrison Michal Wajdeczko (3): drm/i915/guc: Use FAST_REQUEST for non-blocking H2G calls drm/i915/guc: Update log for unsolicited CTB response drm/i915/guc: Track all sent actions to GuC drivers/gpu/drm/i915/Kconfig.debug| 1 + .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 30 +++ drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 79 --- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 11 +++ 4 files changed, 112 insertions(+), 9 deletions(-) -- 2.39.1
[Intel-gfx] [PATCH 0/3] HDCP Cleanup
Some basic cleanup of hdcp code. Consists of -rename dev_priv to i915. -move away from master naming rename it to arbiter. -rename comp_mutex to hdcp_mutex. Signed-off-by: Suraj Kandpal Suraj Kandpal (3): drm/i915/hdcp: Rename dev_priv to i915 drm/i915/hdcp: Move away from master naming to arbiter drm/i915/hdcp: Rename comp_mutex to hdcp_mutex .../gpu/drm/i915/display/intel_display_core.h | 6 +- drivers/gpu/drm/i915/display/intel_hdcp.c | 652 +- drivers/gpu/drm/i915/display/intel_hdcp.h | 6 +- drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 16 +- drivers/gpu/drm/i915/i915_driver.c| 2 +- drivers/misc/mei/hdcp/mei_hdcp.c | 26 +- include/drm/i915_hdcp_interface.h | 4 +- 7 files changed, 356 insertions(+), 356 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH 0/3] drm/i915: implement internal workqueues
Hi, This series implements internal workqueues in the i915 driver in order to avoid using the system queue. We add one generic workqueue in the drm_i915_private structure, one specific for wake references and one in a self-test. This is based on Tetsuo's work[1] and is required to get rid of the flush_scheduled_work() usage. Please review. [1] https://patchwork.freedesktop.org/series/114608/ Cheers, Luca. Luca Coelho (3): drm/i915: add a dedicated workqueue inside drm_i915_private drm/i915/gt: create workqueue dedicated to wake references drm/i915/selftests: add local workqueue for SW fence selftest drivers/gpu/drm/i915/display/intel_display.c | 5 ++-- .../drm/i915/display/intel_display_driver.c | 2 +- drivers/gpu/drm/i915/display/intel_dmc.c | 2 +- drivers/gpu/drm/i915/display/intel_dp.c | 2 +- .../drm/i915/display/intel_dp_link_training.c | 5 ++-- drivers/gpu/drm/i915/display/intel_drrs.c | 4 ++- drivers/gpu/drm/i915/display/intel_fbc.c | 2 +- drivers/gpu/drm/i915/display/intel_fbdev.c| 3 ++- drivers/gpu/drm/i915/display/intel_hdcp.c | 23 ++--- drivers/gpu/drm/i915/display/intel_hotplug.c | 18 - drivers/gpu/drm/i915/display/intel_opregion.c | 3 ++- drivers/gpu/drm/i915/display/intel_pps.c | 4 ++- drivers/gpu/drm/i915/display/intel_psr.c | 8 +++--- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 7 +- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 15 +-- drivers/gpu/drm/i915/gt/intel_engine_pm.h | 3 ++- .../drm/i915/gt/intel_execlists_submission.c | 5 ++-- .../gpu/drm/i915/gt/intel_gt_buffer_pool.c| 10 +--- drivers/gpu/drm/i915/gt/intel_gt_irq.c| 2 +- drivers/gpu/drm/i915/gt/intel_gt_requests.c | 10 drivers/gpu/drm/i915/gt/intel_reset.c | 2 +- drivers/gpu/drm/i915/gt/intel_rps.c | 20 --- drivers/gpu/drm/i915/gt/mock_engine.c | 8 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 2 +- drivers/gpu/drm/i915/i915_driver.c| 7 ++ drivers/gpu/drm/i915/i915_drv.h | 3 ++- drivers/gpu/drm/i915/i915_request.c | 2 +- drivers/gpu/drm/i915/intel_wakeref.c | 21 drivers/gpu/drm/i915/intel_wakeref.h | 25 --- .../gpu/drm/i915/selftests/i915_sw_fence.c| 16 +--- 30 files changed, 162 insertions(+), 77 deletions(-) -- 2.39.2
[Intel-gfx] [PATCH 0/3] Fixed-width mask/bit helpers
Generalize the REG_GENMASK*() and REG_BIT*() macros so they can be used
by other drivers. The intention is to migrate i915 to the generic
helpers and also make use of them on the upcoming xe driver. There are
possibly other users in the kernel that need u32/u16/u8 bit handling.
First patch is one of the possible alternatives in radeon/amdgpu drivers
so they use the U32() that is planned to be used here. Other
alternatives would be to use a amd/radeon prefix or use a _Generic().
Last patch is a temporary one to demonstrate what would be changed on
the i915 side. However instead of replacing the implementation of the
REG_* macros, the goal is to replace the callers as well.
Patches here are currently based on drm-tip branch.
Lucas De Marchi (3):
drm/amd: Remove wrapper macros over get_u{32,16,8}
linux/bits.h: Add fixed-width GENMASK and BIT macros
drm/i915: Temporary conversion to new GENMASK/BIT macros
drivers/gpu/drm/amd/amdgpu/atom.c | 212
drivers/gpu/drm/amd/include/atom-bits.h | 9 +-
drivers/gpu/drm/i915/i915_reg_defs.h| 28 +---
drivers/gpu/drm/radeon/atom-bits.h | 9 +-
drivers/gpu/drm/radeon/atom.c | 209 +++
include/linux/bits.h| 22 +++
include/uapi/linux/const.h | 2 +
include/vdso/const.h| 1 +
8 files changed, 249 insertions(+), 243 deletions(-)
--
2.40.1
[Intel-gfx] [PATCH 0/3] drm/i915: hotplug and display irq refactoring
Move hotplug and display irq handling to their respective files under display/. This is a start, with mostly just code movement. Further work clarifying the borders between these files as well as renames is to be expected. BR, Jani. Jani Nikula (3): drm/i915/irq: relocate gmbus and dp aux irq handlers drm/i915/irq: split out hotplug irq handling drm/i915/irq: split out display irq handling drivers/gpu/drm/i915/Makefile |2 + drivers/gpu/drm/i915/display/i9xx_plane.c |2 +- drivers/gpu/drm/i915/display/intel_crt.c |1 + drivers/gpu/drm/i915/display/intel_crtc.c |2 +- .../gpu/drm/i915/display/intel_display_irq.c | 1677 .../gpu/drm/i915/display/intel_display_irq.h | 79 + .../i915/display/intel_display_power_well.c |1 + drivers/gpu/drm/i915/display/intel_dp.c |1 + drivers/gpu/drm/i915/display/intel_dp_aux.c |5 + drivers/gpu/drm/i915/display/intel_dp_aux.h |3 + .../drm/i915/display/intel_fifo_underrun.c|2 +- drivers/gpu/drm/i915/display/intel_gmbus.c|5 + drivers/gpu/drm/i915/display/intel_gmbus.h|2 + drivers/gpu/drm/i915/display/intel_hotplug.c |1 + .../gpu/drm/i915/display/intel_hotplug_irq.c | 1442 +++ .../gpu/drm/i915/display/intel_hotplug_irq.h | 35 + drivers/gpu/drm/i915/display/intel_tv.c |2 +- .../drm/i915/display/skl_universal_plane.c|2 +- drivers/gpu/drm/i915/gt/intel_rps.c |1 + drivers/gpu/drm/i915/i915_irq.c | 3638 ++--- drivers/gpu/drm/i915/i915_irq.h | 46 +- 21 files changed, 3528 insertions(+), 3421 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_display_irq.c create mode 100644 drivers/gpu/drm/i915/display/intel_display_irq.h create mode 100644 drivers/gpu/drm/i915/display/intel_hotplug_irq.c create mode 100644 drivers/gpu/drm/i915/display/intel_hotplug_irq.h -- 2.39.2
Re: [Intel-gfx] [PATCH 0/3] Consider multi-gt instead of to_gt()
Hi Tejas, On Wed, Apr 19, 2023 at 11:30:33AM +0530, Tejas Upadhyay wrote: > drm/i915/gt: drm/i915/gem: drm/i915/selftests: > Consider multi-gt instead of to_gt() > > In order to enable complete multi-GT, use the GT > reference obtained directly from the engine, rather > than relying on the to_gt(), which only provides a > reference to the primary GT. > > Problem appear when it runs on platform like MTL > where different set of engines are possible on > different GTs. > > Cc: Andi Shyti > Signed-off-by: Tejas Upadhyay pushed to drm-intel-gt-next. Thank you! Andi
[Intel-gfx] [PATCH 0/3] Consider multi-gt instead of to_gt()
drm/i915/gt: drm/i915/gem: drm/i915/selftests: Consider multi-gt instead of to_gt() In order to enable complete multi-GT, use the GT reference obtained directly from the engine, rather than relying on the to_gt(), which only provides a reference to the primary GT. Problem appear when it runs on platform like MTL where different set of engines are possible on different GTs. Cc: Andi Shyti Signed-off-by: Tejas Upadhyay Tejas Upadhyay (3): drm/i915/gt: Consider multi-gt instead of to_gt() drm/i915/gem: Consider multi-gt instead of to_gt() drm/i915/selftests: Consider multi-gt instead of to_gt() .../drm/i915/gem/selftests/i915_gem_context.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +- .../gpu/drm/i915/selftests/igt_live_test.c| 46 +++ 3 files changed, 30 insertions(+), 22 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH 0/3] drm/i915/guc: Disable PL1 power limit when loading GuC firmware
Updates to Patch 2/3 and Patch 3/3 in this version. Ashutosh Dixit (3): drm/i915/hwmon: Get mutex and rpm ref just once in hwm_power_max_write drm/i915/guc: Disable PL1 power limit when loading GuC firmware drm/i915/hwmon: Block waiting for GuC reset to complete drivers/gpu/drm/i915/gt/uc/intel_uc.c | 13 +++- drivers/gpu/drm/i915/i915_hwmon.c | 94 +++ drivers/gpu/drm/i915/i915_hwmon.h | 7 ++ 3 files changed, 100 insertions(+), 14 deletions(-) -- 2.38.0
[Intel-gfx] [PATCH 0/3] drm/i915/active: Fix other potential list corruption root causes
While perfroming root cause analyses of fence callback list corruptions, a couple of other potential though less likely root causes have been identified in addition to barrier tasks list deletion results ignored. This series tries to fix those potential issues, also in longterm stable releases starting from v5.10. The third patch, while not fixing any real bug, is believed to make the code more predictable and easy to understand, then more easy to debug should other barrier related issue still exist. Janusz Krzysztofik (3): drm/i915/active: Serialize preallocation of idle barriers drm/i915/active: Serialize use of barriers as fence trackers drm/i915/active: Simplify llist search-and-delete drivers/gpu/drm/i915/i915_active.c | 124 ++--- 1 file changed, 78 insertions(+), 46 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH 0/3] drm/i915/pmu: Use common freq functions with sysfs
Using common freq functions with sysfs in PMU (but without taking forcewake) solves the following issues (a) missing support for MTL (b) missing support for older generations (prior to Gen6) (c) missing support for slpc when freq sampling has to fall back to requested freq. It also makes the PMU code future proof where sometimes code has been updated for sysfs and PMU has been missed. Ashutosh Dixit (3): drm/i915/rps: Expose read_actual_frequency_fw for PMU drm/i915/rps: Expose get_requested_frequency_fw for PMU drm/i915/pmu: Use common freq functions with sysfs drivers/gpu/drm/i915/gt/intel_rps.c | 68 + drivers/gpu/drm/i915/gt/intel_rps.h | 4 +- drivers/gpu/drm/i915/i915_pmu.c | 10 ++--- 3 files changed, 56 insertions(+), 26 deletions(-) -- 2.38.0
[Intel-gfx] [PATCH 0/3] drm/i915: track gt->wakerefs
This patchset extracts i915 rpm wakeref tracking to separate files (patch 1) and then uses it to track GT wakerefs (patch 2). Next step is to use external library lib/ref_track, but this requires some adjustements to the library and will be performed in separate patchset. The patches are taken from internal branch. To: Jani Nikula To: Joonas Lahtinen To: Rodrigo Vivi To: Tvrtko Ursulin To: David Airlie To: Daniel Vetter Cc: linux-ker...@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: Chris Wilson Signed-off-by: Andrzej Hajda --- Andrzej Hajda (1): drm/i915: Correct type of wakeref variable Chris Wilson (2): drm/i915: Separate wakeref tracking drm/i915: Track leaked gt->wakerefs drivers/gpu/drm/i915/Kconfig.debug | 24 ++ drivers/gpu/drm/i915/Makefile | 4 + drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 7 +- .../drm/i915/gem/selftests/i915_gem_coherency.c| 10 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 14 +- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c| 13 +- drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h | 3 +- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 + .../gpu/drm/i915/gt/intel_execlists_submission.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 10 +- drivers/gpu/drm/i915/gt/intel_gt_pm.h | 38 +++- drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 20 +- drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 5 +- drivers/gpu/drm/i915/gt/selftest_reset.c | 10 +- drivers/gpu/drm/i915/gt/selftest_rps.c | 17 +- drivers/gpu/drm/i915/gt/selftest_slpc.c| 5 +- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +- drivers/gpu/drm/i915/i915_pmu.c| 16 +- drivers/gpu/drm/i915/intel_runtime_pm.c| 244 +++-- drivers/gpu/drm/i915/intel_runtime_pm.h| 10 +- drivers/gpu/drm/i915/intel_wakeref.c | 4 + drivers/gpu/drm/i915/intel_wakeref.h | 48 +++- drivers/gpu/drm/i915/intel_wakeref_tracker.c | 234 drivers/gpu/drm/i915/intel_wakeref_tracker.h | 76 +++ 26 files changed, 536 insertions(+), 299 deletions(-) --- base-commit: 1ddc2e762c6a109af52f3c39534c7115aebe change-id: 20230224-track_gt-1b3da8bdacd7 Best regards, -- Andrzej Hajda
[Intel-gfx] [PATCH 0/3] PL1 power limit fixes for ATSM
Previous PL1 power limit implementation assumed that the PL1 limit is always enabled in HW. However we now find this not to be the case on ATSM where the PL1 limit is disabled at power up. This requires changes in the previous PL1 limit implementation. Submitting 3 patches for easier review but patches can be squashed if needed. Ashutosh Dixit (3): drm/i915/hwmon: Replace hwm_field_scale_and_write with hwm_power_max_write drm/i915/hwmon: Enable PL1 limit when writing limit value to HW drm/i915/hwmon: Expose power1_max_enable .../ABI/testing/sysfs-driver-intel-i915-hwmon | 7 ++ drivers/gpu/drm/i915/i915_hwmon.c | 85 +-- 2 files changed, 68 insertions(+), 24 deletions(-) -- 2.38.0
[Intel-gfx] [PATCH 0/3] drm/i915/hwmon: PL1 power limit fixes for ATSM
Previous PL1 power limit implementation assumed that the PL1 limit is always enabled in HW. However we now find this not to be the case on ATSM where the PL1 limit is disabled at power up. This requires changes in the previous PL1 implementation. Ashutosh Dixit (3): drm/i915/hwmon: Replace hwm_field_scale_and_write with hwm_power_max_write drm/i915/hwmon: Enable PL1 limit when writing limit value to HW drm/i915/hwmon: Use -1 to designate disabled PL1 power limit .../ABI/testing/sysfs-driver-intel-i915-hwmon | 3 +- drivers/gpu/drm/i915/i915_hwmon.c | 61 +-- 2 files changed, 43 insertions(+), 21 deletions(-) -- 2.38.0
[Intel-gfx] [PATCH 0/3] drm/i915: Fix eDP+DSI dual panel systems
From: Ville Syrjälä Several fixes to light up the secondary (DSI) panel on Lenovo ThinkBook Plus Gen 3. References: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Ville Syrjälä (3): drm/i915: Fix VBT DSI DVO port handling drm/i915: Populate encoder->devdata for DSI on icl+ drm/i915: Pick the backlight controller based on VBT on ICP+ drivers/gpu/drm/i915/display/icl_dsi.c| 3 +- .../gpu/drm/i915/display/intel_backlight.c| 34 +++-- drivers/gpu/drm/i915/display/intel_bios.c | 48 ++- 3 files changed, 68 insertions(+), 17 deletions(-) -- 2.39.1
[Intel-gfx] [PATCH 0/3] htmldocs fixes for next-20230203
Here are small htmldocs fixes for htmldocs warnings that are recently reported for next-20230203. Each patch can be applied separately by respective maintainers. Bagas Sanjaya (3): drm/i915/doc: Escape wildcard in method names drm/scheduler: Fix elapsed_ns kernel-doc error media: v4l2-core: Describe privacy_led field of v4l2_subdev drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 +++--- include/drm/gpu_scheduler.h | 2 +- include/media/v4l2-subdev.h | 1 + 3 files changed, 5 insertions(+), 4 deletions(-) base-commit: 4fafd96910add124586b549ad005dcd179de8a18 -- An old man doll... just what I always wanted! - Clara
[Intel-gfx] [PATCH 0/3] More error capture improvements
From: John Harrison Ecodes got lost with the switch to GuC based register lists. Put them back. Seqno values got lost with the switch to per context timelines. Put hose back too. Signed-off-by: John Harrison John Harrison (3): drm/i915/guc: Fix missing ecodes drm/i915/guc: Clean up of register capture search drm/i915: Include timelines in error capture .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 27 --- drivers/gpu/drm/i915/i915_gpu_error.c | 3 +++ 2 files changed, 27 insertions(+), 3 deletions(-) -- 2.39.1
[Intel-gfx] [PATCH 0/3] Drop TGL/DG1 workarounds for pre-prod steppings
As described in the comment on intel_detect_preproduction_hw(), Our policy for removing pre-production workarounds is to keep the current gen workarounds as a guide to the bring-up of the next gen (workarounds have a habit of persisting!). Anything older than that should be removed along with the complications they introduce. TGL and DG1 are well past the point where we should move forward with removing the hardware workarounds specific to internal/pre-production hardware. JSL/EHL appear to have productized A0 hardware, so all workarounds for those platforms will stay in the driver forever. We can probably remove some pre-production workarounds for RKL and ADL at this point as well, but the bspec doesn't have details about which steppings were only used in pre-production, so we'll need to track down that information later. Matt Roper (3): drm/i915/tgl: Drop support for pre-production steppings drm/i915/dg1: Drop support for pre-production steppings drm/i915/dg1: Drop final use of IS_DG1_GRAPHICS_STEP .../drm/i915/display/intel_display_power.c| 6 +- drivers/gpu/drm/i915/display/intel_psr.c | 26 -- .../drm/i915/display/skl_universal_plane.c| 2 +- drivers/gpu/drm/i915/gt/intel_region_lmem.c | 2 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 86 +-- drivers/gpu/drm/i915/i915_driver.c| 2 + drivers/gpu/drm/i915/i915_drv.h | 13 --- drivers/gpu/drm/i915/intel_pm.c | 16 8 files changed, 10 insertions(+), 143 deletions(-) -- 2.39.1
[Intel-gfx] [PATCH 0/3] drm/i915: Use designated initializers for struct pci_device_id init
Use designated initializers for struct pci_device_id init. Jani Nikula (3): drm/i915/pciids: add common INTEL_VGA_DEVICE_INIT macro drm/i915/pciids: use designated initializers for struct pci_device_id drm/i915: define INTEL_VGA_DEVICE_INIT() for subplatform init drivers/gpu/drm/i915/intel_device_info.c | 4 +-- include/drm/i915_pciids.h| 43 +--- 2 files changed, 26 insertions(+), 21 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH 0/3] Fixes for various UC related issues
From: John Harrison Fix a bunch of assorted issues with firmware loading and GuC intialisation. Signed-off-by: John Harrison John Harrison (3): drm/i915/guc: Fix missing return code checks in submission init drm/i915/guc: Fix a static analysis warning drm/i915/uc: Fix two issues with over-size firmware files .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 75 ++- .../gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 7 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 42 +++ 4 files changed, 91 insertions(+), 35 deletions(-) -- 2.39.0
[Intel-gfx] [PATCH 0/3] Fixes for various UC related issues
From: John Harrison Fix a bunch of assorted issues with firmware loading and GuC intialisation. Signed-off-by: John Harrison John Harrison (3): drm/i915/guc: Fix missing return code checks in submission init drm/i915/guc: Fix a static analysis warning drm/i915/uc: Fix two issues with over-size firmware files .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 75 ++- .../gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 7 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 42 +++ 4 files changed, 91 insertions(+), 35 deletions(-) -- 2.39.0
[Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: i915 keepalive fixes
A series with multiple fixes to i915 keepalive (KAE) functionality. First patch fixes issue that is hit on some A750/770 cards: https://gitlab.freedesktop.org/drm/intel/-/issues/7353 The two other improve behaviour especially with certain USB-C docks. Kai Vehmanen (3): ALSA: hda/hdmi: fix i915 silent stream programming flow ALSA: hda/hdmi: set default audio parameters for KAE silent-stream ALSA: hda/hdmi: fix stream-id config keep-alive for rt suspend include/sound/hda_codec.h | 1 + sound/pci/hda/hda_codec.c | 3 +- sound/pci/hda/patch_hdmi.c | 114 - 3 files changed, 114 insertions(+), 4 deletions(-) base-commit: 81a2da5a10a6eaa6ae16108eed4e74651cc296bf -- 2.38.1
[Intel-gfx] [PATCH 0/3] Add KUnit support for i915 mock selftests
That's an updated version of my previous KUnit RFC series: https://patchwork.freedesktop.org/series/110481/ While the RFC series added support for live and perf, let's start with mock, as running tests in bare metal is not the current focus of KUnit. So, basically patch 1 was changed to export just mock functions, and the bare metal patches got removed from this version. As before, running KUnit on i915 driver requires the --arch parameter: ./tools/testing/kunit/kunit.py run --arch=x86_64 --kunitconfig=drivers/gpu/drm/i915/selftests/ --jobs=`nproc --all` [13:18:40] Configuring KUnit Kernel ... [13:18:40] Building KUnit Kernel ... Populating config with: $ make ARCH=x86_64 O=.kunit olddefconfig Building with: $ make ARCH=x86_64 O=.kunit --jobs=8 [13:23:20] Starting KUnit Kernel (1/1)... [13:23:20] Running tests with: $ qemu-system-x86_64 -nodefaults -m 1024 -kernel .kunit/arch/x86/boot/bzImage -append 'kunit.enable=1 console=ttyS0 kunit_shutdown=reboot' -no-reboot -nographic -serial stdio [13:23:21] i915 mock selftests (18 subtests) = [13:23:21] [PASSED] mock_sanitycheck [13:23:21] [PASSED] mock_shmem [13:23:24] [PASSED] mock_fence [13:23:25] [PASSED] mock_scatterlist [13:23:27] [PASSED] mock_syncmap [13:23:27] [PASSED] mock_uncore [13:23:27] [PASSED] mock_ring [13:23:27] [PASSED] mock_engine [13:23:31] [PASSED] mock_timelines [13:23:32] [PASSED] mock_requests [13:23:32] [PASSED] mock_objects [13:23:32] [PASSED] mock_phys [13:23:32] [PASSED] mock_dmabuf [13:23:38] [PASSED] mock_vma [13:23:38] [PASSED] mock_evict [13:23:41] [PASSED] mock_gtt [13:23:42] [PASSED] mock_hugepages [13:23:42] [PASSED] mock_memory_region [13:23:42] === [PASSED] i915 mock selftests === [13:23:42] [13:23:42] Testing complete. Ran 18 tests: passed: 18 [13:23:42] Elapsed time: 302.766s total, 0.003s configuring, 280.393s building, 22.341s running Mauro Carvalho Chehab (3): drm/i915: place selftest preparation on a separate function drm/i915: export all mock selftest functions drm/i915: allow running mock selftests via Kunit drivers/gpu/drm/i915/Kconfig | 15 +++ drivers/gpu/drm/i915/Makefile | 5 + .../gpu/drm/i915/gem/selftests/huge_pages.c | 1 + .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 1 + .../drm/i915/gem/selftests/i915_gem_object.c | 1 + .../drm/i915/gem/selftests/i915_gem_phys.c| 1 + drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 1 + drivers/gpu/drm/i915/gt/selftest_ring.c | 1 + drivers/gpu/drm/i915/gt/selftest_timeline.c | 1 + drivers/gpu/drm/i915/gt/st_shmem_utils.c | 1 + drivers/gpu/drm/i915/i915_selftest.h | 2 + drivers/gpu/drm/i915/selftests/.kunitconfig | 12 +++ .../gpu/drm/i915/selftests/i915_gem_evict.c | 1 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 1 + drivers/gpu/drm/i915/selftests/i915_kunit.c | 95 +++ drivers/gpu/drm/i915/selftests/i915_request.c | 1 + .../gpu/drm/i915/selftests/i915_selftest.c| 23 +++-- .../gpu/drm/i915/selftests/i915_sw_fence.c| 1 + drivers/gpu/drm/i915/selftests/i915_syncmap.c | 1 + drivers/gpu/drm/i915/selftests/i915_vma.c | 1 + .../drm/i915/selftests/intel_memory_region.c | 1 + drivers/gpu/drm/i915/selftests/intel_uncore.c | 1 + drivers/gpu/drm/i915/selftests/scatterlist.c | 1 + 23 files changed, 161 insertions(+), 8 deletions(-) create mode 100644 drivers/gpu/drm/i915/selftests/.kunitconfig create mode 100644 drivers/gpu/drm/i915/selftests/i915_kunit.c -- 2.38.1
[Intel-gfx] [PATCH 0/3] More GuC firmware version improvements
From: John Harrison Start using the 'submission API version' for deciding which GuC API to use in the submission code. Correct version number manipulation code to support full 32bit major/minor/patch components, except for GuC which is guaranteed to be 8bit safe. Other minor code clean ups around version number handling. Signed-off-by: John Harrison John Harrison (3): drm/i915/uc: Rationalise delimiters in filename macros drm/i915/uc: More refactoring of UC version numbers drm/i915/guc: Use GuC submission API version number drivers/gpu/drm/i915/gt/uc/intel_guc.h| 11 ++ .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 173 -- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 15 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 3 +- 6 files changed, 150 insertions(+), 73 deletions(-) -- 2.37.3
[Intel-gfx] [PATCH 0/3] drm/i915: Fix timeout handling when retiring requests
Fixes for issues discovered via code review while working on https://gitlab.freedesktop.org/drm/intel/issues/7349. Reworked version of a series supposed to fix the same issues, sent before under the same subject. Since some solutions are significantly different than before, I'm not marking this series and individual patches as v2. Janusz Krzysztofik (3): drm/i915: Fix negative remaining time after retire requests drm/i915: Never return 0 on timeout when retiring requests drm/i915: Never return 0 if request wait succeeds drivers/gpu/drm/i915/gt/intel_gt_requests.c | 26 ++--- drivers/gpu/drm/i915/i915_request.c | 2 ++ 2 files changed, 25 insertions(+), 3 deletions(-) -- 2.25.1
Re: [Intel-gfx] [PATCH 0/3] Add _PICK_EVEN_RANGES
On Fri, 21 Oct 2022, Lucas De Marchi wrote:
> On Wed, Oct 12, 2022 at 12:05:31PM -0700, Lucas De Marchi wrote:
>>On Wed, Oct 12, 2022 at 11:51:48AM +0300, Jani Nikula wrote:
>>>On Tue, 11 Oct 2022, Lucas De Marchi wrote:
Add a new macro, _PICK_EVEN_RANGES, that supports using 2 address
ranges. This should cover most of our needs for _MMIO_PLL3 and such.
To show what is achieved with the new macro, convert some PLL-related
macros to use it instead of _MMIO_PLL3.
>>>
>>>While there's nothing particularly wrong about the solution when looked
>>>at in isolation, I do have pretty strong reservations on the whole.
>>>
>>>We have:
>>>
>>>1) _PICK_EVEN() used in _PIPE() and friends
>>>
>>>2) _PICK() used in _MMIO_PIPE3() and friends
>>>
>>>3) ->pipe_offsets[] etc. adjustment used in _MMIO_PIPE2() and friends
>>>
>>>4) ->ddi_index[] mapping proposed in [1]
>>>
>>>5) _PICK_EVEN_RANGES() proposed here
>>>
>>>Originally we only had the first one, when the hardware was
>>>simpler. Every single addition since then made sense at the time, but if
>>>we add 4 & 5 to the mix, I think it's just too many options.
>>>
>>>I think it's time to take a step back and figure out if there's a more
>>>generic approach that could be used.
>>
>>true... I actually see this as replacing most of the uses of _PICK()
>>and giving and extra benefit of removing the worry we are doing
>>out-of-bounds array access. It also allows to more easily move ranges
>>for new platforms, which is my intention here.
>
> Jani, any feedback here or in the possible things to do below? I'd like
> to get a sketch of whatever solution we think could be the right
> direction during next week.
Considering that I basically stalled this but couldn't provide a
decision on a concrete better path forward either,
Acked-by: Jani Nikula
on the original approach here. Needs a rebase, but it doesn't block us
from the other ideas later either.
Thanks, and sorry,
Jani.
>
> thanks
> Lucas De Marchi
>
>>
>>So I think that we could have something like this if changing it to
>>something else means a bigger refactor. Talking about a big refactor, I
>>still think my series from a few years back would make sense:
>>
>>drm/i915/display: start description-based ddi initialization
>>(https://lore.kernel.org/all/20191223195850.25997-1-lucas.demar...@intel.com/)
>>
>>I think that got stalled due to initialization in the intel_ddi.c trying
>>too much to group together the if/else ladder. But the overall intention
>>of the patch series I believe is still valid today:
>>
>> (...) create a table-based initialization approach in
>> which I keep the useful indexes for each platform: these indexes work
>> similarly to what we have on the pll part. "enum port" is mostly a
>> "driver thing" and when all the conversions take place, it would allow
>> us to stop using the port as indexes to register or register bits. "enum
>> tc_port", "enum phy", etc are not meaningful numbers from the spec POV
>> and change with every other platform.
>>
>>+Bala who apparently is going to a similar approach in the ddi_index
>>approach.
>>
>>Other possible approaches hat come to mind (just dumping some thoughts,
>>with no actual code/poc):
>>
>>1) Inside display strut we have:
>>
>> struct {
>> u8 version;
>> union {
>> struct {
>> i915_reg_t foo;
>> i915_reg_t bar;
>> i915_reg_t bla;
>> } v1;
>> struct {
>> i915_reg_t xyz;
>> i915_reg_t ijk;
>> } v2;
>> }
>> } regs;
>>
>>instead of vesion it could be the "first platform to use it" like we
>>currently have. Those registers would then be initialized during module
>>bind and then we stop doing these conversions to map a platform to a
>>register offset. It still needs some per-platform change for the
>>bitfields though.
>>
>>idea would be then to enforce using the right struct inside the union by
>>splitting the code in differen compilation units. One platform can
>>evolve from the other with the same compilation unit as long as it is
>>backward-compatible, i.e. we can add more registers, change offsets,
>>etc. But if the HW interface completely changes, it would need to use a
>>different version.
>>
>>2) Looking around what other teams do. In mesa the registers are actually
>>maintained in a xml. Example: gen12.xml
>>
>>
>> > type="bool"/>
>> > end="29" type="bool"/>
>>
>>
>>In code it's used like this:
>>
>>reg.HZDepthTestLEGEOptimizationDisable = true;
>>
>>3) Kind of going in the same direction, but more in the kernel side. Maybe
>>switching to regmap?
>>
>>
>>I think one of the things that block this kind of refactors is having to
>>bring them back to all the previous platforms. Maybe going back only
>>until HAS_DDI() would be a
[Intel-gfx] [PATCH 0/3] add track_remove_slot and remove track_flush_slot
This series is based on Sean's series https://lore.kernel.org/all/20221110014821.1548347-1-sea...@google.com/, which allows KVM internal user of page track not to rely on the page track hook .track_flush_slot. Page track hook track_flush_slot is for notification of slot flush and is called when a slot DELETE/MOVE is on-going. Page track hook track_remove_slot is for notification of slot removal and is called when the slot DELETE/MOVE has been committed. As KVMGT, the only external user of page track, actually only cares about when slot removal indeed happens, this series switches KVMGT to use the new hook .track_remove_slot. And as there are no users to .track_flush_slot any more, this hook is removed. Yan Zhao (3): KVM: x86: add a new page track hook track_remove_slot drm/i915/gvt: switch from track_flush_slot to track_remove_slot KVM: x86: Remove the unused page track hook track_flush_slot arch/x86/include/asm/kvm_page_track.h | 8 arch/x86/kvm/mmu/page_track.c | 8 arch/x86/kvm/x86.c| 5 +++-- drivers/gpu/drm/i915/gvt/kvmgt.c | 6 +++--- 4 files changed, 14 insertions(+), 13 deletions(-) -- 2.17.1
Re: [Intel-gfx] [PATCH 0/3] Fix timeout handling when retiring requests
On Wednesday, 9 November 2022 20:09:34 CET Janusz Krzysztofik wrote: > Fixes for issues discovered via code review while working on > https://gitlab.freedesktop.org/drm/intel/issues/7349. > > Janusz Krzysztofik (3): > drm/i915: Fix timeout handling when retiring requests > drm/i915: Fix unintended submission flush after retire times out > drm/i915: Fix 0 return value from DMA fence wait on i915 requests Based on some comments received, I'm going to rework this series and resubmit. Please ignore this one. Thanks, Janusz > > drivers/gpu/drm/i915/gt/intel_gt_requests.c | 19 +++ > drivers/gpu/drm/i915/i915_request.c | 2 +- > 2 files changed, 16 insertions(+), 5 deletions(-) > >
Re: [Intel-gfx] [PATCH 0/3] add guard padding around i915_vma
Hi Thomas, > This has been on the list before (three times I think) and at that > point it (the guard pages) was NAK'd by Daniel as yet another > complication, and a VT-d > scanout workaround was implemented and pushed using a different > approach, initially outlined by Daniel. I reckon that this is an old patch, but I've seen only reviews and acks. I haven't seen anything against this patch. So that as far as it concerns me, this patch should be good to go, unless I missed something or there is any technical concern. > Patch is 2ef6efa79fecd. Those suspend/resumes should now be fast. This patch is not actually resolving the boot time delays, that is the main concern coming from the users, and, just as a post-mortem review, as Tvrtko has pointed out, this: +/* Intel Rapid Start Technology ACPI device name */ +static const char irst_name[] = "INT3392"; is a bit scary because we are depending very much on the firmware and whatever happens there is not under our control. It's an hardcoded string that requires maintenance. In any case, the two patches are somehow doing different things: I don't see them conflicting and to me looks like a reasonable optimization (otherwise I wouldn't have put my signature on it :)) Thanks again a lot for your thoughts and inputs, Andi > I then also discussed patch 1 separately with Dave Airlie and Daniel > and since both me and Dave liked it, Daniel OK'd it, but it never made > it upstream. > > Just a short heads up on the history. > > /Thomas > > > On Wed, 2022-11-09 at 18:40 +0100, Andi Shyti wrote: > > Hi, > > > > This series adds guards around vma's but setting a pages at the > > beginning and at the end that work as padding. > > > > The first user of the vma guard are scanout objects which don't > > need anymore to add scratch to all the unused ggtt's and speeding > > up up considerably the boot and resume by several hundreds of > > milliseconds up to over a full second in slower machines. > > > > Andi > > > > Chris Wilson (3): > > drm/i915: Wrap all access to i915_vma.node.start|size > > drm/i915: Introduce guard pages to i915_vma > > drm/i915: Refine VT-d scanout workaround > > > > drivers/gpu/drm/i915/display/intel_fbdev.c | 2 +- > > drivers/gpu/drm/i915/gem/i915_gem_domain.c | 13 > > .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 33 ++- > > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- > > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +- > > drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 4 +- > > .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- > > .../i915/gem/selftests/i915_gem_client_blt.c | 23 > > .../drm/i915/gem/selftests/i915_gem_context.c | 15 +++-- > > .../drm/i915/gem/selftests/i915_gem_mman.c | 2 +- > > .../drm/i915/gem/selftests/igt_gem_utils.c | 7 ++- > > drivers/gpu/drm/i915/gt/gen7_renderclear.c | 2 +- > > drivers/gpu/drm/i915/gt/intel_ggtt.c | 39 > > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- > > drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- > > .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- > > drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 8 +-- > > drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++--- > > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 15 ++--- > > drivers/gpu/drm/i915/gt/selftest_lrc.c | 16 ++--- > > .../drm/i915/gt/selftest_ring_submission.c | 2 +- > > drivers/gpu/drm/i915/gt/selftest_rps.c | 12 ++-- > > .../gpu/drm/i915/gt/selftest_workarounds.c | 8 +-- > > drivers/gpu/drm/i915/i915_cmd_parser.c | 4 +- > > drivers/gpu/drm/i915/i915_debugfs.c | 2 +- > > drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +- > > drivers/gpu/drm/i915/i915_perf.c | 2 +- > > drivers/gpu/drm/i915/i915_vma.c | 59 + > > -- > > drivers/gpu/drm/i915/i915_vma.h | 52 +++- > > drivers/gpu/drm/i915/i915_vma_resource.c | 4 +- > > drivers/gpu/drm/i915/i915_vma_resource.h | 17 -- > > drivers/gpu/drm/i915/i915_vma_types.h | 3 +- > > drivers/gpu/drm/i915/selftests/i915_request.c | 20 +++ > > drivers/gpu/drm/i915/selftests/igt_spinner.c | 8 +-- > > 34 files changed, 246 insertions(+), 160 deletions(-) > >
Re: [Intel-gfx] [PATCH 0/3] add guard padding around i915_vma
Hi, On 09/11/2022 18:03, Thomas Hellström wrote: Hi, Andi, This has been on the list before (three times I think) and at that point it (the guard pages) was NAK'd by Daniel as yet another complication, and a VT-d scanout workaround was implemented and pushed using a different approach, initially outlined by Daniel. I can't find this discussion and NAKs on the list - do you have a link? Patch is 2ef6efa79fecd. Those suspend/resumes should now be fast. So the initiator to re-start this series was actually the boot time is failing KPIs by quite a margin. Which means we may need a way forward after all. Especially if the most churny patch 1 was deemed okay, then I don't see why the concept of guard pages should be a problem. But again, I couldn't find the discussion you mention to read what were the objections.. For 2ef6efa79fecd specifically. I only looked at it today - do you think that the heuristic of checking one PTE and deciding all content was preserved is safe? What if someone scribbled at random locations? On a first thought it is making me a bit uncomfortable. Regards, Tvrtko I then also discussed patch 1 separately with Dave Airlie and Daniel and since both me and Dave liked it, Daniel OK'd it, but it never made it upstream. Just a short heads up on the history. /Thomas On Wed, 2022-11-09 at 18:40 +0100, Andi Shyti wrote: Hi, This series adds guards around vma's but setting a pages at the beginning and at the end that work as padding. The first user of the vma guard are scanout objects which don't need anymore to add scratch to all the unused ggtt's and speeding up up considerably the boot and resume by several hundreds of milliseconds up to over a full second in slower machines. Andi Chris Wilson (3): drm/i915: Wrap all access to i915_vma.node.start|size drm/i915: Introduce guard pages to i915_vma drm/i915: Refine VT-d scanout workaround drivers/gpu/drm/i915/display/intel_fbdev.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c | 13 .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 33 ++- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 4 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- .../i915/gem/selftests/i915_gem_client_blt.c | 23 .../drm/i915/gem/selftests/i915_gem_context.c | 15 +++-- .../drm/i915/gem/selftests/i915_gem_mman.c | 2 +- .../drm/i915/gem/selftests/igt_gem_utils.c | 7 ++- drivers/gpu/drm/i915/gt/gen7_renderclear.c | 2 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 39 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 8 +-- drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++--- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 15 ++--- drivers/gpu/drm/i915/gt/selftest_lrc.c | 16 ++--- .../drm/i915/gt/selftest_ring_submission.c | 2 +- drivers/gpu/drm/i915/gt/selftest_rps.c | 12 ++-- .../gpu/drm/i915/gt/selftest_workarounds.c | 8 +-- drivers/gpu/drm/i915/i915_cmd_parser.c | 4 +- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +- drivers/gpu/drm/i915/i915_perf.c | 2 +- drivers/gpu/drm/i915/i915_vma.c | 59 + -- drivers/gpu/drm/i915/i915_vma.h | 52 +++- drivers/gpu/drm/i915/i915_vma_resource.c | 4 +- drivers/gpu/drm/i915/i915_vma_resource.h | 17 -- drivers/gpu/drm/i915/i915_vma_types.h | 3 +- drivers/gpu/drm/i915/selftests/i915_request.c | 20 +++ drivers/gpu/drm/i915/selftests/igt_spinner.c | 8 +-- 34 files changed, 246 insertions(+), 160 deletions(-)
[Intel-gfx] [PATCH 0/3] Fix timeout handling when retiring requests
Fixes for issues discovered via code review while working on https://gitlab.freedesktop.org/drm/intel/issues/7349. Janusz Krzysztofik (3): drm/i915: Fix timeout handling when retiring requests drm/i915: Fix unintended submission flush after retire times out drm/i915: Fix 0 return value from DMA fence wait on i915 requests drivers/gpu/drm/i915/gt/intel_gt_requests.c | 19 +++ drivers/gpu/drm/i915/i915_request.c | 2 +- 2 files changed, 16 insertions(+), 5 deletions(-) -- 2.25.1
Re: [Intel-gfx] [PATCH 0/3] add guard padding around i915_vma
Hi Thomas, On Wed, Nov 09, 2022 at 07:03:03PM +0100, Thomas Hellström wrote: > Hi, Andi, > > This has been on the list before (three times I think) and at that > point it (the guard pages) was NAK'd by Daniel as yet another > complication, and a VT-d > scanout workaround was implemented and pushed using a different > approach, initially outlined by Daniel. > > Patch is 2ef6efa79fecd. Those suspend/resumes should now be fast. > > I then also discussed patch 1 separately with Dave Airlie and Daniel > and since both me and Dave liked it, Daniel OK'd it, but it never made > it upstream. > > Just a short heads up on the history. Thanks for letting me know, I missed this part of the history. Will check what happened in the previous mails and your improvement on the vt-d suspend/resume. Thanks, Andi
Re: [Intel-gfx] [PATCH 0/3] add guard padding around i915_vma
Hi, Andi, This has been on the list before (three times I think) and at that point it (the guard pages) was NAK'd by Daniel as yet another complication, and a VT-d scanout workaround was implemented and pushed using a different approach, initially outlined by Daniel. Patch is 2ef6efa79fecd. Those suspend/resumes should now be fast. I then also discussed patch 1 separately with Dave Airlie and Daniel and since both me and Dave liked it, Daniel OK'd it, but it never made it upstream. Just a short heads up on the history. /Thomas On Wed, 2022-11-09 at 18:40 +0100, Andi Shyti wrote: > Hi, > > This series adds guards around vma's but setting a pages at the > beginning and at the end that work as padding. > > The first user of the vma guard are scanout objects which don't > need anymore to add scratch to all the unused ggtt's and speeding > up up considerably the boot and resume by several hundreds of > milliseconds up to over a full second in slower machines. > > Andi > > Chris Wilson (3): > drm/i915: Wrap all access to i915_vma.node.start|size > drm/i915: Introduce guard pages to i915_vma > drm/i915: Refine VT-d scanout workaround > > drivers/gpu/drm/i915/display/intel_fbdev.c | 2 +- > drivers/gpu/drm/i915/gem/i915_gem_domain.c | 13 > .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 33 ++- > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +- > drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 4 +- > .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- > .../i915/gem/selftests/i915_gem_client_blt.c | 23 > .../drm/i915/gem/selftests/i915_gem_context.c | 15 +++-- > .../drm/i915/gem/selftests/i915_gem_mman.c | 2 +- > .../drm/i915/gem/selftests/igt_gem_utils.c | 7 ++- > drivers/gpu/drm/i915/gt/gen7_renderclear.c | 2 +- > drivers/gpu/drm/i915/gt/intel_ggtt.c | 39 > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- > drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- > .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- > drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 8 +-- > drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++--- > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 15 ++--- > drivers/gpu/drm/i915/gt/selftest_lrc.c | 16 ++--- > .../drm/i915/gt/selftest_ring_submission.c | 2 +- > drivers/gpu/drm/i915/gt/selftest_rps.c | 12 ++-- > .../gpu/drm/i915/gt/selftest_workarounds.c | 8 +-- > drivers/gpu/drm/i915/i915_cmd_parser.c | 4 +- > drivers/gpu/drm/i915/i915_debugfs.c | 2 +- > drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +- > drivers/gpu/drm/i915/i915_perf.c | 2 +- > drivers/gpu/drm/i915/i915_vma.c | 59 + > -- > drivers/gpu/drm/i915/i915_vma.h | 52 +++- > drivers/gpu/drm/i915/i915_vma_resource.c | 4 +- > drivers/gpu/drm/i915/i915_vma_resource.h | 17 -- > drivers/gpu/drm/i915/i915_vma_types.h | 3 +- > drivers/gpu/drm/i915/selftests/i915_request.c | 20 +++ > drivers/gpu/drm/i915/selftests/igt_spinner.c | 8 +-- > 34 files changed, 246 insertions(+), 160 deletions(-) >
[Intel-gfx] [PATCH 0/3] add guard padding around i915_vma
Hi, This series adds guards around vma's but setting a pages at the beginning and at the end that work as padding. The first user of the vma guard are scanout objects which don't need anymore to add scratch to all the unused ggtt's and speeding up up considerably the boot and resume by several hundreds of milliseconds up to over a full second in slower machines. Andi Chris Wilson (3): drm/i915: Wrap all access to i915_vma.node.start|size drm/i915: Introduce guard pages to i915_vma drm/i915: Refine VT-d scanout workaround drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c| 13 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 33 ++- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- .../i915/gem/selftests/i915_gem_client_blt.c | 23 .../drm/i915/gem/selftests/i915_gem_context.c | 15 +++-- .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +- .../drm/i915/gem/selftests/igt_gem_utils.c| 7 ++- drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 39 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 8 +-- drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++--- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 15 ++--- drivers/gpu/drm/i915/gt/selftest_lrc.c| 16 ++--- .../drm/i915/gt/selftest_ring_submission.c| 2 +- drivers/gpu/drm/i915/gt/selftest_rps.c| 12 ++-- .../gpu/drm/i915/gt/selftest_workarounds.c| 8 +-- drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +- drivers/gpu/drm/i915/i915_perf.c | 2 +- drivers/gpu/drm/i915/i915_vma.c | 59 +-- drivers/gpu/drm/i915/i915_vma.h | 52 +++- drivers/gpu/drm/i915/i915_vma_resource.c | 4 +- drivers/gpu/drm/i915/i915_vma_resource.h | 17 -- drivers/gpu/drm/i915/i915_vma_types.h | 3 +- drivers/gpu/drm/i915/selftests/i915_request.c | 20 +++ drivers/gpu/drm/i915/selftests/igt_spinner.c | 8 +-- 34 files changed, 246 insertions(+), 160 deletions(-) -- 2.37.2
Re: [Intel-gfx] [PATCH 0/3] add guard patting around i915_vma
Please ignore, this series is rebased on the wrong branch. Andi On Wed, Nov 09, 2022 at 05:49:10PM +0100, Andi Shyti wrote: > Hi, > > This patch series adds a padding around i915_vma's reducing > consequently the need to add scratch to the unused GGTT. > > This speeds up considerably the boot and resume by several > hundreds of milliseconds up to over a full second in slower > machines. > > Andi > > Chris Wilson (3): > drm/i915: Wrap all access to i915_vma.node.start|size > drm/i915: Introduce guard pages to i915_vma > drm/i915: Refine VT-d scanout workaround > > drivers/gpu/drm/i915/display/intel_dpt.c | 4 +- > drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +- > drivers/gpu/drm/i915/gem/i915_gem_domain.c| 13 + > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 37 ++-- > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +- > drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +- > .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- > .../i915/gem/selftests/i915_gem_client_blt.c | 15 ++--- > .../drm/i915/gem/selftests/i915_gem_context.c | 19 -- > .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +- > .../drm/i915/gem/selftests/igt_gem_utils.c| 7 ++- > drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +- > drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +- > drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 8 +-- > drivers/gpu/drm/i915/gt/intel_ggtt.c | 39 - > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- > drivers/gpu/drm/i915/gt/intel_ppgtt.c | 7 ++- > drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- > .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- > drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 12 ++-- > drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++--- > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 17 +++--- > drivers/gpu/drm/i915/gt/selftest_lrc.c| 16 ++--- > .../drm/i915/gt/selftest_ring_submission.c| 2 +- > drivers/gpu/drm/i915/gt/selftest_rps.c| 12 ++-- > .../gpu/drm/i915/gt/selftest_workarounds.c| 8 +-- > drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +- > drivers/gpu/drm/i915/i915_debugfs.c | 3 +- > drivers/gpu/drm/i915/i915_gem_gtt.h | 1 + > drivers/gpu/drm/i915/i915_gpu_error.c | 4 +- > drivers/gpu/drm/i915/i915_perf.c | 2 +- > drivers/gpu/drm/i915/i915_vma.c | 58 ++- > drivers/gpu/drm/i915/i915_vma.h | 24 +++- > drivers/gpu/drm/i915/i915_vma_types.h | 3 +- > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 12 +++- > drivers/gpu/drm/i915/selftests/i915_request.c | 20 +++ > drivers/gpu/drm/i915/selftests/igt_spinner.c | 11 ++-- > 38 files changed, 238 insertions(+), 163 deletions(-) > > -- > 2.37.2
[Intel-gfx] [PATCH 0/3] add guard patting around i915_vma
Hi, This patch series adds a padding around i915_vma's reducing consequently the need to add scratch to the unused GGTT. This speeds up considerably the boot and resume by several hundreds of milliseconds up to over a full second in slower machines. Andi Chris Wilson (3): drm/i915: Wrap all access to i915_vma.node.start|size drm/i915: Introduce guard pages to i915_vma drm/i915: Refine VT-d scanout workaround drivers/gpu/drm/i915/display/intel_dpt.c | 4 +- drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c| 13 + .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 37 ++-- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 4 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- .../i915/gem/selftests/i915_gem_client_blt.c | 15 ++--- .../drm/i915/gem/selftests/i915_gem_context.c | 19 -- .../drm/i915/gem/selftests/i915_gem_mman.c| 2 +- .../drm/i915/gem/selftests/igt_gem_utils.c| 7 ++- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/gen7_renderclear.c| 2 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 8 +-- drivers/gpu/drm/i915/gt/intel_ggtt.c | 39 - drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 7 ++- drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 12 ++-- drivers/gpu/drm/i915/gt/selftest_execlists.c | 18 +++--- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 17 +++--- drivers/gpu/drm/i915/gt/selftest_lrc.c| 16 ++--- .../drm/i915/gt/selftest_ring_submission.c| 2 +- drivers/gpu/drm/i915/gt/selftest_rps.c| 12 ++-- .../gpu/drm/i915/gt/selftest_workarounds.c| 8 +-- drivers/gpu/drm/i915/i915_cmd_parser.c| 4 +- drivers/gpu/drm/i915/i915_debugfs.c | 3 +- drivers/gpu/drm/i915/i915_gem_gtt.h | 1 + drivers/gpu/drm/i915/i915_gpu_error.c | 4 +- drivers/gpu/drm/i915/i915_perf.c | 2 +- drivers/gpu/drm/i915/i915_vma.c | 58 ++- drivers/gpu/drm/i915/i915_vma.h | 24 +++- drivers/gpu/drm/i915/i915_vma_types.h | 3 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 12 +++- drivers/gpu/drm/i915/selftests/i915_request.c | 20 +++ drivers/gpu/drm/i915/selftests/igt_spinner.c | 11 ++-- 38 files changed, 238 insertions(+), 163 deletions(-) -- 2.37.2
[Intel-gfx] [PATCH 0/3] Documentation/gpu: reduce verbosity in toc
Checking some issues I was having i915 doc made me look at the toc for Documentation/gpu. I think it's too hard to read when extending the toc all levels for each driver. Reduce it to maxdepth=2. Also fix the usage-stats section appearing in the wrong place. Lucas De Marchi (3): Documentation/gpu: Fix section in the wrong scope Documentation/gpu: Limit index to maxdepth=2 Documentation/gpu: Limit drivers index to maxdepth=2 Documentation/gpu/drivers.rst | 1 + Documentation/gpu/drm-usage-stats.rst | 1 - Documentation/gpu/index.rst | 1 + 3 files changed, 2 insertions(+), 1 deletion(-) -- 2.38.1
Re: [Intel-gfx] [PATCH 0/3] Add _PICK_EVEN_RANGES
On Wed, Oct 12, 2022 at 12:05:31PM -0700, Lucas De Marchi wrote:
On Wed, Oct 12, 2022 at 11:51:48AM +0300, Jani Nikula wrote:
On Tue, 11 Oct 2022, Lucas De Marchi wrote:
Add a new macro, _PICK_EVEN_RANGES, that supports using 2 address
ranges. This should cover most of our needs for _MMIO_PLL3 and such.
To show what is achieved with the new macro, convert some PLL-related
macros to use it instead of _MMIO_PLL3.
While there's nothing particularly wrong about the solution when looked
at in isolation, I do have pretty strong reservations on the whole.
We have:
1) _PICK_EVEN() used in _PIPE() and friends
2) _PICK() used in _MMIO_PIPE3() and friends
3) ->pipe_offsets[] etc. adjustment used in _MMIO_PIPE2() and friends
4) ->ddi_index[] mapping proposed in [1]
5) _PICK_EVEN_RANGES() proposed here
Originally we only had the first one, when the hardware was
simpler. Every single addition since then made sense at the time, but if
we add 4 & 5 to the mix, I think it's just too many options.
I think it's time to take a step back and figure out if there's a more
generic approach that could be used.
true... I actually see this as replacing most of the uses of _PICK()
and giving and extra benefit of removing the worry we are doing
out-of-bounds array access. It also allows to more easily move ranges
for new platforms, which is my intention here.
Jani, any feedback here or in the possible things to do below? I'd like
to get a sketch of whatever solution we think could be the right
direction during next week.
thanks
Lucas De Marchi
So I think that we could have something like this if changing it to
something else means a bigger refactor. Talking about a big refactor, I
still think my series from a few years back would make sense:
drm/i915/display: start description-based ddi initialization
(https://lore.kernel.org/all/20191223195850.25997-1-lucas.demar...@intel.com/)
I think that got stalled due to initialization in the intel_ddi.c trying
too much to group together the if/else ladder. But the overall intention
of the patch series I believe is still valid today:
(...) create a table-based initialization approach in
which I keep the useful indexes for each platform: these indexes work
similarly to what we have on the pll part. "enum port" is mostly a
"driver thing" and when all the conversions take place, it would allow
us to stop using the port as indexes to register or register bits. "enum
tc_port", "enum phy", etc are not meaningful numbers from the spec POV
and change with every other platform.
+Bala who apparently is going to a similar approach in the ddi_index
approach.
Other possible approaches hat come to mind (just dumping some thoughts,
with no actual code/poc):
1) Inside display strut we have:
struct {
u8 version;
union {
struct {
i915_reg_t foo;
i915_reg_t bar;
i915_reg_t bla;
} v1;
struct {
i915_reg_t xyz;
i915_reg_t ijk;
} v2;
}
} regs;
instead of vesion it could be the "first platform to use it" like we
currently have. Those registers would then be initialized during module
bind and then we stop doing these conversions to map a platform to a
register offset. It still needs some per-platform change for the
bitfields though.
idea would be then to enforce using the right struct inside the union by
splitting the code in differen compilation units. One platform can
evolve from the other with the same compilation unit as long as it is
backward-compatible, i.e. we can add more registers, change offsets,
etc. But if the HW interface completely changes, it would need to use a
different version.
2) Looking around what other teams do. In mesa the registers are actually
maintained in a xml. Example: gen12.xml
In code it's used like this:
reg.HZDepthTestLEGEOptimizationDisable = true;
3) Kind of going in the same direction, but more in the kernel side. Maybe
switching to regmap?
I think one of the things that block this kind of refactors is having to
bring them back to all the previous platforms. Maybe going back only
until HAS_DDI() would be a good approach. Or maybe even spliting it on
DISPLAY_VER == 12? That might help more radical changes.
Lucas De Marchi
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/108833/
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH 0/3] Add hwmon support for dgfx selftests
Rename librapl library to libpower. Add hwmon support in libpower for dgfx. Riana Tauro (2): drm/i915/selftests: Rename librapl library to libpower drm/i915/hwmon: Add helper function to obtain energy values Tilak Tangudu (1): drm/i915/selftests: Add hwmon support in libpower for dgfx drivers/gpu/drm/i915/Makefile | 2 +- drivers/gpu/drm/i915/gt/selftest_rc6.c| 12 drivers/gpu/drm/i915/gt/selftest_rps.c| 26 - drivers/gpu/drm/i915/gt/selftest_slpc.c | 4 +-- drivers/gpu/drm/i915/i915_hwmon.c | 23 +-- drivers/gpu/drm/i915/i915_hwmon.h | 1 + drivers/gpu/drm/i915/selftests/libpower.c | 35 +++ drivers/gpu/drm/i915/selftests/libpower.h | 19 drivers/gpu/drm/i915/selftests/librapl.c | 34 -- drivers/gpu/drm/i915/selftests/librapl.h | 17 --- 10 files changed, 97 insertions(+), 76 deletions(-) create mode 100644 drivers/gpu/drm/i915/selftests/libpower.c create mode 100644 drivers/gpu/drm/i915/selftests/libpower.h delete mode 100644 drivers/gpu/drm/i915/selftests/librapl.c delete mode 100644 drivers/gpu/drm/i915/selftests/librapl.h -- 2.25.1
[Intel-gfx] [PATCH 0/3] i915: CAGF and RC6 changes for MTL
This series includes the code changes to get CAGF, RC State and C6 Residency of MTL. v2: Included "Use GEN12 RPSTAT register" patch v3: - Rebased - Dropped "Use GEN12 RPSTAT register" patch from this series going to send separate series for it v4: - Included "drm/i915/gt: Change RC6 residency functions to accept register ID's" based on code review feedback - Addressed review comments, please see individual patches for changelogs Ashutosh Dixit (1): drm/i915/gt: Change RC6 residency functions to accept register ID's Badal Nilawar (2): drm/i915/mtl: Modify CAGF functions for MTL drm/i915/mtl: C6 residency and C state type for MTL SAMedia drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 84 ++- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 9 ++ drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 12 +-- drivers/gpu/drm/i915/gt/intel_rc6.c | 65 +- drivers/gpu/drm/i915/gt/intel_rc6.h | 9 +- drivers/gpu/drm/i915/gt/intel_rc6_types.h | 10 +++ drivers/gpu/drm/i915/gt/intel_rps.c | 8 +- drivers/gpu/drm/i915/gt/selftest_rc6.c| 6 +- drivers/gpu/drm/i915/i915_pmu.c | 6 +- 9 files changed, 150 insertions(+), 59 deletions(-) -- 2.38.0
Re: [Intel-gfx] [PATCH 0/3] Add _PICK_EVEN_RANGES
On Wed, Oct 12, 2022 at 11:51:48AM +0300, Jani Nikula wrote:
On Tue, 11 Oct 2022, Lucas De Marchi wrote:
Add a new macro, _PICK_EVEN_RANGES, that supports using 2 address
ranges. This should cover most of our needs for _MMIO_PLL3 and such.
To show what is achieved with the new macro, convert some PLL-related
macros to use it instead of _MMIO_PLL3.
While there's nothing particularly wrong about the solution when looked
at in isolation, I do have pretty strong reservations on the whole.
We have:
1) _PICK_EVEN() used in _PIPE() and friends
2) _PICK() used in _MMIO_PIPE3() and friends
3) ->pipe_offsets[] etc. adjustment used in _MMIO_PIPE2() and friends
4) ->ddi_index[] mapping proposed in [1]
5) _PICK_EVEN_RANGES() proposed here
Originally we only had the first one, when the hardware was
simpler. Every single addition since then made sense at the time, but if
we add 4 & 5 to the mix, I think it's just too many options.
I think it's time to take a step back and figure out if there's a more
generic approach that could be used.
true... I actually see this as replacing most of the uses of _PICK()
and giving and extra benefit of removing the worry we are doing
out-of-bounds array access. It also allows to more easily move ranges
for new platforms, which is my intention here.
So I think that we could have something like this if changing it to
something else means a bigger refactor. Talking about a big refactor, I
still think my series from a few years back would make sense:
drm/i915/display: start description-based ddi initialization
(https://lore.kernel.org/all/20191223195850.25997-1-lucas.demar...@intel.com/)
I think that got stalled due to initialization in the intel_ddi.c trying
too much to group together the if/else ladder. But the overall intention
of the patch series I believe is still valid today:
(...) create a table-based initialization approach in
which I keep the useful indexes for each platform: these indexes work
similarly to what we have on the pll part. "enum port" is mostly a
"driver thing" and when all the conversions take place, it would allow
us to stop using the port as indexes to register or register bits. "enum
tc_port", "enum phy", etc are not meaningful numbers from the spec POV
and change with every other platform.
+Bala who apparently is going to a similar approach in the ddi_index
approach.
Other possible approaches hat come to mind (just dumping some thoughts,
with no actual code/poc):
1) Inside display strut we have:
struct {
u8 version;
union {
struct {
i915_reg_t foo;
i915_reg_t bar;
i915_reg_t bla;
} v1;
struct {
i915_reg_t xyz;
i915_reg_t ijk;
} v2;
}
} regs;
instead of vesion it could be the "first platform to use it" like we
currently have. Those registers would then be initialized during module
bind and then we stop doing these conversions to map a platform to a
register offset. It still needs some per-platform change for the
bitfields though.
idea would be then to enforce using the right struct inside the union by
splitting the code in differen compilation units. One platform can
evolve from the other with the same compilation unit as long as it is
backward-compatible, i.e. we can add more registers, change offsets,
etc. But if the HW interface completely changes, it would need to use a
different version.
2) Looking around what other teams do. In mesa the registers are actually
maintained in a xml. Example: gen12.xml
In code it's used like this:
reg.HZDepthTestLEGEOptimizationDisable = true;
3) Kind of going in the same direction, but more in the kernel side. Maybe
switching to regmap?
I think one of the things that block this kind of refactors is having to
bring them back to all the previous platforms. Maybe going back only
until HAS_DDI() would be a good approach. Or maybe even spliting it on
DISPLAY_VER == 12? That might help more radical changes.
Lucas De Marchi
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/108833/
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 0/3] Add _PICK_EVEN_RANGES
On Tue, 11 Oct 2022, Lucas De Marchi wrote: > Add a new macro, _PICK_EVEN_RANGES, that supports using 2 address > ranges. This should cover most of our needs for _MMIO_PLL3 and such. > To show what is achieved with the new macro, convert some PLL-related > macros to use it instead of _MMIO_PLL3. While there's nothing particularly wrong about the solution when looked at in isolation, I do have pretty strong reservations on the whole. We have: 1) _PICK_EVEN() used in _PIPE() and friends 2) _PICK() used in _MMIO_PIPE3() and friends 3) ->pipe_offsets[] etc. adjustment used in _MMIO_PIPE2() and friends 4) ->ddi_index[] mapping proposed in [1] 5) _PICK_EVEN_RANGES() proposed here Originally we only had the first one, when the hardware was simpler. Every single addition since then made sense at the time, but if we add 4 & 5 to the mix, I think it's just too many options. I think it's time to take a step back and figure out if there's a more generic approach that could be used. BR, Jani. [1] https://patchwork.freedesktop.org/series/108833/ -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH 0/3] Add _PICK_EVEN_RANGES
Add a new macro, _PICK_EVEN_RANGES, that supports using 2 address ranges. This should cover most of our needs for _MMIO_PLL3 and such. To show what is achieved with the new macro, convert some PLL-related macros to use it instead of _MMIO_PLL3. Signed-off-by: Lucas De Marchi --- Lucas De Marchi (3): drm/i915: Add _PICK_EVEN_RANGES() drm/i915: Fix coding style on DPLL*_ENABLE defines drm/i915: Convert pll macros to _PICK_EVEN_RANGES drivers/gpu/drm/i915/i915_reg.h | 91 +++-- 1 file changed, 52 insertions(+), 39 deletions(-) --- base-commit: caaf8c4c270b6b9ce1b8610b4eea888190fc087f change-id: 20221011-pick-even-ranges-76ad8a5007e9 Best regards, -- Lucas De Marchi
[Intel-gfx] [PATCH 0/3] drm/i915: Improve register state context init
Some small improvements to future-proof the initialization around the register state context. Lucas De Marchi (3): drm/i915: Fix __gen125_emit_bb_start() without WA drm/i915/gt: Document function to decode register state context drm/i915/gt: Fix platform prefix drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 26 +-- drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 12 +++--- .../drm/i915/gt/intel_execlists_submission.c | 4 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 43 ++- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +- 5 files changed, 56 insertions(+), 31 deletions(-) -- 2.37.3
[Intel-gfx] [PATCH 0/3] drm/i915: Relax fixed mode selection further
From: Ville Syrjälä After much head scratching I've concluded that the "static DRRS" stuff is useless for us and we should just ignore it. Instead we start to trust the EDID a bit more and use all the suitable fixed modes we find in there, whether or not we have DRRS/VRR/etc. Ville Syrjälä (3): drm/i915: Simplify intel_panel_add_edid_alt_fixed_modes() drm/i915: Allow alternate fixed modes always for eDP drm/i915: Allow alternate fixed modes always for LVDS drivers/gpu/drm/i915/display/intel_dp.c| 4 +--- drivers/gpu/drm/i915/display/intel_lvds.c | 4 +--- drivers/gpu/drm/i915/display/intel_panel.c | 4 ++-- drivers/gpu/drm/i915/display/intel_panel.h | 2 +- drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +- 5 files changed, 6 insertions(+), 10 deletions(-) -- 2.35.1
[Intel-gfx] [PATCH 0/3] Add SLPC selftest live_slpc_power
live_slpc_power tests if running at low frequency saves power Rev2 : Add multi-tile support Riana Tauro (3): drm/i915/guc/slpc: Run SLPC selftests on all tiles drm/i915/selftests: Add helper function measure_power drm/i915/guc/slpc: Add SLPC selftest live_slpc_power drivers/gpu/drm/i915/gt/selftest_rps.c | 12 +- drivers/gpu/drm/i915/gt/selftest_slpc.c | 172 +--- 2 files changed, 164 insertions(+), 20 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH 0/3] Enable YCbCr420 for VDSC
This patch series aims to enable the YCbCr420 format for DSC. Changes are mostly compute params related for hdmi,dp and dsi along with the addition of new rc_tables for native_420 and corresponding changes to macros used to fetch them. Ankit Nautiyal (1): drm/i915/dp: Check if DSC supports the given output_format Suraj Kandpal (2): drm/i915/vdsc: Enable YCbCr420 for VDSC drm/i915/display: Fill in native_420 field drivers/gpu/drm/i915/display/icl_dsi.c| 2 - drivers/gpu/drm/i915/display/intel_dp.c | 32 ++- .../gpu/drm/i915/display/intel_qp_tables.c| 187 -- .../gpu/drm/i915/display/intel_qp_tables.h| 4 +- drivers/gpu/drm/i915/display/intel_vdsc.c | 20 +- 5 files changed, 224 insertions(+), 21 deletions(-) -- 2.25.1
Re: [Intel-gfx] [PATCH 0/3] i915: freq caps and perf_limit_reasons changes for MTL
On Sat, Sep 10, 2022 at 07:38:41AM -0700, Ashutosh Dixit wrote: > Since https://patchwork.freedesktop.org/series/107908/ is now merged, > rebase this series on latest drm-tip and post a clean series. pushed to drm-intel-gt-next thansk for the patches > > Ashutosh Dixit (2): > drm/i915/mtl: PERF_LIMIT_REASONS changes for MTL > drm/i915/rps: Freq caps for MTL > > Tilak Tangudu (1): > drm/i915/debugfs: Add perf_limit_reasons in debugfs > > drivers/gpu/drm/i915/gt/intel_gt.c| 6 +++ > drivers/gpu/drm/i915/gt/intel_gt.h| 1 + > drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 + > drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 6 +-- > drivers/gpu/drm/i915/gt/intel_rps.c | 46 +++ > drivers/gpu/drm/i915/i915_reg.h | 11 + > 6 files changed, 89 insertions(+), 12 deletions(-) > > -- > 2.34.1 >
[Intel-gfx] [PATCH 0/3] i915: freq caps and perf_limit_reasons changes for MTL
Since https://patchwork.freedesktop.org/series/107908/ is now merged, rebase this series on latest drm-tip and post a clean series. Ashutosh Dixit (2): drm/i915/mtl: PERF_LIMIT_REASONS changes for MTL drm/i915/rps: Freq caps for MTL Tilak Tangudu (1): drm/i915/debugfs: Add perf_limit_reasons in debugfs drivers/gpu/drm/i915/gt/intel_gt.c| 6 +++ drivers/gpu/drm/i915/gt/intel_gt.h| 1 + drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 + drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 6 +-- drivers/gpu/drm/i915/gt/intel_rps.c | 46 +++ drivers/gpu/drm/i915/i915_reg.h | 11 + 6 files changed, 89 insertions(+), 12 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH 0/3] i915: freq caps and perf_limit_reasons changes for MTL
Since https://patchwork.freedesktop.org/series/107908/ is now merged, rebase this series on latest drm-tip and post a clean series. Ashutosh Dixit (2): drm/i915/mtl: PERF_LIMIT_REASONS changes for MTL drm/i915/rps: Freq caps for MTL Tilak Tangudu (1): drm/i915/debugfs: Add perf_limit_reasons in debugfs drivers/gpu/drm/i915/gt/intel_gt.c| 6 +++ drivers/gpu/drm/i915/gt/intel_gt.h| 1 + drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 + drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 6 +-- drivers/gpu/drm/i915/gt/intel_rps.c | 46 +++ drivers/gpu/drm/i915/i915_reg.h | 11 + 6 files changed, 89 insertions(+), 12 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH 0/3] drm/i915: Move skl+ wm code into its own file
From: Ville Syrjälä Hoist all the skl+ wm related stuff from intel_pm.c into its own file. Ville Syrjälä (3): drm/i915: Split intel_read_wm_latency() into per-platform versions drm/i915: Extract skl_watermark.c drm/i915: Use REG_FIELD_GET() to extract skl+ wm latencies drivers/gpu/drm/i915/Makefile |3 +- .../gpu/drm/i915/display/intel_atomic_plane.c |2 +- drivers/gpu/drm/i915/display/intel_bw.c |4 +- drivers/gpu/drm/i915/display/intel_cursor.c |2 +- drivers/gpu/drm/i915/display/intel_display.c |1 + .../drm/i915/display/intel_display_debugfs.c |1 + .../drm/i915/display/intel_display_power.c|2 +- .../i915/display/intel_display_power_well.c |2 +- .../drm/i915/display/intel_modeset_setup.c|1 + .../drm/i915/display/intel_modeset_verify.c |2 +- .../drm/i915/display/skl_universal_plane.c|2 +- drivers/gpu/drm/i915/display/skl_watermark.c | 3464 drivers/gpu/drm/i915/display/skl_watermark.h | 78 + drivers/gpu/drm/i915/i915_driver.c|1 + drivers/gpu/drm/i915/i915_reg.h |8 +- drivers/gpu/drm/i915/intel_pm.c | 3528 + drivers/gpu/drm/i915/intel_pm.h | 65 +- 17 files changed, 3609 insertions(+), 3557 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/skl_watermark.c create mode 100644 drivers/gpu/drm/i915/display/skl_watermark.h -- 2.35.1
[Intel-gfx] [PATCH 0/3] Enable Pipewriteback Framework
A patch series was floated in the drm mailing list which aimed to change the drm_connector and drm_encoder fields to pointer in the drm_connector_writeback structure, this received a huge pushback from the community but since i915 expects each connector present in the drm_device list to be a intel_connector but drm_writeback framework makes us have a connector which cannot be embedded in an intel_connector structure. [1] https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22119-1-suraj.kand...@intel.com/ [2] https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22261-6-suraj.kand...@intel.com/ Since no one had an issue with encoder field being changed into a pointer it was decided to break the connector and encoder pointer changes into two different series.The encoder field changes is currently being worked upon by Abhinav Kumar and the changes have been merged. [3]https://patchwork.kernel.org/project/dri-devel/list/?series=633565 Going forward we use a drm_connector which is not embedded in intel_connector. We also create a intel_encoder to avoid changes to many iterators but no intel_connector. We also changed all iterators that go through connectors and add a check to only cast connectors which are not writeback connectors. I had also floated a previous series to Enable writeback but floating a new one as i created an extra patch in this series as suggested by Jani, Nikula for intel_connector iterator changes. Please go check the below link if interested. [4]https://patchwork.freedesktop.org/series/106902/ Suraj Kandpal (3): drm/i915: Define WD trancoder for i915 drm/i915 : Changing intel_connector iterators drm/i915: Enabling WD Transcoder drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_acpi.c | 1 + drivers/gpu/drm/i915/display/intel_crtc.c | 6 + .../drm/i915/display/intel_crtc_state_dump.c | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 6 + drivers/gpu/drm/i915/display/intel_display.c | 65 +- drivers/gpu/drm/i915/display/intel_display.h | 18 +- .../drm/i915/display/intel_display_debugfs.c | 13 +- .../drm/i915/display/intel_display_types.h| 33 +- drivers/gpu/drm/i915/display/intel_dpll.c | 6 + .../drm/i915/display/intel_modeset_setup.c| 119 ++- .../drm/i915/display/intel_modeset_verify.c | 17 +- drivers/gpu/drm/i915/display/intel_opregion.c | 3 + .../gpu/drm/i915/display/intel_wb_connector.h | 20 + drivers/gpu/drm/i915/display/intel_wd.c | 699 ++ drivers/gpu/drm/i915/display/intel_wd.h | 48 ++ drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_irq.c | 8 +- drivers/gpu/drm/i915/i915_pci.c | 7 +- drivers/gpu/drm/i915/i915_reg.h | 139 20 files changed, 1156 insertions(+), 55 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h -- 2.25.1
[Intel-gfx] [PATCH 0/3] Enable Pipewriteback
A patch series was floated in the drm mailing list which aimed to change the drm_connector and drm_encoder fields to pointer in the drm_connector_writeback structure, this received a huge pushback from the community but since i915 expects each connector present in the drm_device list to be a intel_connector but drm_writeback framework makes us have a connector which cannot be embedded in an intel_connector structure. [1] https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22119-1-suraj.kand...@intel.com/ [2] https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22261-6-suraj.kand...@intel.com/ Since no one had an issue with encoder field being changed into a pointer it was decided to break the connector and encoder pointer changes into two different series.The encoder field changes is currently being worked upon by Abhinav Kumar and the changes have been merged. [3]https://patchwork.kernel.org/project/dri-devel/list/?series=633565 Going forward we use a drm_connector which is not embedded in intel_connector. We also create a intel_encoder to avoid changes to many iterators but no intel_connector. We also changed all iterators that go through connectors and add a check to only cast connectors which are not writeback connectors. I had also floated a previous series to Enable writeback but floating a new one as i created an extra patch in this series as suggested by Jani, Nikula for intel_connector iterator changes. Please go check the below link if interested. [4]https://patchwork.freedesktop.org/series/106902/ Suraj Kandpal (3): drm/i915: Define WD trancoder for i915 drm/i915 : Changing intel_connector iterators drm/i915: Enabling WD Transcoder drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_acpi.c | 1 + drivers/gpu/drm/i915/display/intel_crtc.c | 6 + .../drm/i915/display/intel_crtc_state_dump.c | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 6 + drivers/gpu/drm/i915/display/intel_display.c | 63 +- drivers/gpu/drm/i915/display/intel_display.h | 18 +- .../drm/i915/display/intel_display_debugfs.c | 13 +- .../drm/i915/display/intel_display_types.h| 33 +- drivers/gpu/drm/i915/display/intel_dpll.c | 6 + .../drm/i915/display/intel_modeset_setup.c| 114 ++- .../drm/i915/display/intel_modeset_verify.c | 17 +- drivers/gpu/drm/i915/display/intel_opregion.c | 3 + .../gpu/drm/i915/display/intel_wb_connector.h | 20 + drivers/gpu/drm/i915/display/intel_wd.c | 704 ++ drivers/gpu/drm/i915/display/intel_wd.h | 48 ++ drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_irq.c | 8 +- drivers/gpu/drm/i915/i915_pci.c | 7 +- drivers/gpu/drm/i915/i915_reg.h | 139 20 files changed, 1154 insertions(+), 55 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h -- 2.37.0
[Intel-gfx] [PATCH 0/3] drm/i915/dsi: fix DSI DCS backlight port handling
Hopefully fix a null pointer dereference in DSI DCS backlight handling. Jani Nikula (3): drm/i915/dsi: filter invalid backlight and CABC ports drm/i915/dsi: fix dual-link DSI backlight and CABC ports for display 11+ drm/i915/dsi: use VBT backlight and CABC port definitions directly drivers/gpu/drm/i915/display/icl_dsi.c | 7 +-- drivers/gpu/drm/i915/display/intel_bios.c | 10 ++ drivers/gpu/drm/i915/display/intel_dsi.h | 3 --- .../gpu/drm/i915/display/intel_dsi_dcs_backlight.c | 14 -- drivers/gpu/drm/i915/display/vlv_dsi.c | 7 +-- 5 files changed, 24 insertions(+), 17 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH 0/3] drm/i915: Replace kmap() with kmap_local_page()
kmap() is being deprecated in favor of kmap_local_page(). There are two main problems with kmap(): (1) It comes with an overhead as mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available. With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, the tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored and still valid. Since its use in drm/i915 is safe everywhere, it should be preferred. Therefore, replace kmap() with kmap_local_page() in drm/i915. These changes should be tested in an 32 bits system, booting a kernel with HIGHMEM enabled. Unfortunately I have no i915 based hardware, therefore any help with testing would be greatly appreciated. Suggested-by: Ira Weiny Signed-off-by: Fabio M. De Francesco Fabio M. De Francesco (3): drm/i915: Replace kmap() with kmap_local_page() drm/i915/gt: Replace kmap() with kmap_local_page() drm/i915/gem: Replace kmap() with kmap_local_page() drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 ++ drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 8 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++-- drivers/gpu/drm/i915/gt/shmem_utils.c | 11 --- drivers/gpu/drm/i915/i915_gem.c| 8 5 files changed, 16 insertions(+), 21 deletions(-) -- 2.37.1
[Intel-gfx] [PATCH 0/3] Fixes for damage clips handling
Currently damage clips handling is broken for planes when using big framebuffer + offset in case kms driver adjusts drm_plane_state.src coords. This is because damage clips are using coords relative to original coords from user-space. This patchset is fixing this by using original coords from user-space instead of drm_plane_state.src when iterating damage_clips. Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Jani Nikula Cc: Ville Syrjälä Cc: José Roberto de Souza Cc: Mika Kahola Jouni Högander (3): drm: Use original src rect while initializing damage iterator drm/i915/display: Use original src in psr2 sel fetch area calculation drm/i915/display: Use drm helper instead of own loop for damage clips drivers/gpu/drm/drm_damage_helper.c | 11 +++ drivers/gpu/drm/i915/display/intel_psr.c | 20 +++- 2 files changed, 14 insertions(+), 17 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH 0/3] drm/i915: Apply waitboosting before fence wait
Waitboost is a heuristic that detects latency sensitive workloads waiting for
the results from previous execution. The wait can be seen as GPU
under-utilisation by RPS, Render Power State management, which might lower the
GPU frequency to save power. Limiting the frequency means more waiting for
results, which is undesirable for submissions with tight time constraints.
To circumvent this, with waitboost we iteratively check the list of fences
during gem_wait to see if any of them is stalled waiting for GPU. If such is
found, and the request hasn't yet started its execution, we temporarily bump up
the GPU frequency, so we get the required results as soon as possible.
Commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv workaround") changes
the fences order and how they are iterated. Under this new scheme, we would wait
on each fence that starts executing, rendering them not suitable for waitboost.
To avoid situation like this, inspect the entire list of fences dma-resv
earlier, before gem_wait, instead of sequentially waiting for each of them,
applying the boost when needed.
Test-with: 20220705103551.3720180-1-karolina.drob...@intel.com
Chris Wilson (3):
drm/i915/gem: Look for waitboosting across the whole object prior to
individual waits
drm/i915: Bump GT idling delay to 2 jiffies
drm/i915/gt: Only kick the signal worker if there's been an update
drivers/gpu/drm/i915/gem/i915_gem_wait.c| 35 +
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 3 +-
drivers/gpu/drm/i915/i915_active.c | 2 +-
3 files changed, 38 insertions(+), 2 deletions(-)
--
2.25.1
[Intel-gfx] [PATCH 0/3] drm/i915: PCH type cleanup
From: Ville Syrjälä Clear out some unnecessary PCH types. Ville Syrjälä (3): drm/i915: Use short PCH names consistently drm/i915: Nuke PCH_MCC drm/i915: Nuke PCH_JSP drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- .../gpu/drm/i915/display/intel_display_power.c | 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c| 2 +- drivers/gpu/drm/i915/intel_pch.c | 16 +--- drivers/gpu/drm/i915/intel_pch.h | 8 ++-- 5 files changed, 14 insertions(+), 16 deletions(-) -- 2.35.1
Re: [Intel-gfx] [PATCH 0/3] drm/doc/rfc: i915 VM_BIND feature design + uapi
On Fri, Jun 10, 2022 at 12:07:08AM -0700, Niranjana Vishwanathapura wrote: This is the i915 driver VM_BIND feature design RFC patch series along with the required uapi definition and description of intended use cases. Some of us had an offline dicussion on this. Based on that, 1) The scope of this work (VM_BIND support in i915) will reduced to support simple Mesa use case. So, I will remove all compute related uapi for now. 2) VM_BIND/UNBIND will only support an 'out' fence. ie., it won't support 'in' fences and hence no timeline fence array as well. UMDs are expected to handle any 'in' fence requirement. 3) We will not support any VM_BIND/UNBIND queues. The binding and unbinding operations can get completed out of submission order. Normally, they will get completed synchronously, but if the object is being moved, the binding will happen once that is complete and out fence will be signaled after binding is complete. 4) We will still have execbuf3 for VM_BIND mode. I will update the patch series and send out. Thanks, Niranjana This series is an updated version of the below RFC series. It address the review feedback by adding execbuf3 ioctl for vm_bind, adding multiple queues support for vm_bind/unbind ioctls and some formatting and documentation updates. https://www.spinics.net/lists/dri-devel/msg347731.html Signed-off-by: Niranjana Vishwanathapura Niranjana Vishwanathapura (3): drm/doc/rfc: VM_BIND feature design document drm/i915: Update i915 uapi documentation drm/doc/rfc: VM_BIND uapi definition Documentation/driver-api/dma-buf.rst | 2 + Documentation/gpu/rfc/i915_vm_bind.h | 490 + Documentation/gpu/rfc/i915_vm_bind.rst | 309 Documentation/gpu/rfc/index.rst| 4 + include/uapi/drm/i915_drm.h| 203 +++--- 5 files changed, 963 insertions(+), 45 deletions(-) create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst -- 2.21.0.rc0.32.g243a4c7e27
[Intel-gfx] [PATCH 0/3] Break VM to rq reference loop
The i915_request holds a reference to intel_context, which in turn holds a reference on the VM. But the dma-resv update for VM_BIND feature would require VM hold a reference to the i915_request through dma-resv fences of VM_PRIVATE objects (which share a per VM dma-resv object). Thus, we have a circular reference pattern causing the VM reference to never reach 0, hence VM is not destroyed. Break this by reverting the below patch which is making the i915_request to hold a reference on intel_context. "drm/i915: Hold reference to intel_context over life of i915_request" This means we can't access rq->engine in i915_fence_get_driver_name() as user do not hold a reference on rq->engine here. So, instead store required device private pointer in 'rq->i915' and use it. Niranjana Vishwanathapura (2): drm/i915: Do not access rq->engine without a reference Revert "drm/i915: Hold reference to intel_context over life of i915_request" Ramalingam C (1): drm/i915: Do not use reserved requests for virtual engines drivers/gpu/drm/i915/i915_request.c | 55 ++--- drivers/gpu/drm/i915/i915_request.h | 2 ++ 2 files changed, 36 insertions(+), 21 deletions(-) -- 2.20.1
[Intel-gfx] [PATCH 0/3] remove shmem backend and region and unify them with TTM
This patch series will attempt to discard the shmem and phys gem object backends from the driver, and handle the dependent objects from TTM instead. The end goal of this and other patches to come is to delete all existing backends and bring their functionality into the current i915 TTM API callbacks. The first patch in the series was actually authored by Bob Beckett, who is working on removing the internal and stolen GEM backends. However his change was essential for this series, so I've included it with the purpose of making the CI system happy. An RFC for the current patch was discussed in https://lists.freedesktop.org/archives/intel-gfx/2022-May/298082.html. Adrian Larumbe (3): drm/i915/ttm: dont trample cache_level overrides during ttm move drm/i915/ttm: don't overwrite cache_dirty after setting coherency drm/i915/ttm: remove shmem memory region and gem object backend drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 10 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c| 4 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 14 +- drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 + drivers/gpu/drm/i915/gem/i915_gem_object.h| 6 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 1 + drivers/gpu/drm/i915/gem/i915_gem_phys.c | 29 +- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 392 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 346 ++-- drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 3 + drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 22 +- drivers/gpu/drm/i915/gt/shmem_utils.c | 36 +- drivers/gpu/drm/i915/intel_memory_region.c| 7 +- 13 files changed, 428 insertions(+), 443 deletions(-) -- 2.36.1
[Intel-gfx] [PATCH 0/3] drm/i915/bios: minor cleanups
Just a few cleanups. Jani Nikula (3): drm/i915/bios: use dvi and hdmi support helpers drm/i915/bios: no need to pass i915 to parse_ddi_port() drm/i915/bios: split ddi port parsing and debug printing drivers/gpu/drm/i915/display/intel_bios.c | 73 +-- 1 file changed, 41 insertions(+), 32 deletions(-) -- 2.30.2
