Re: [Intel-gfx] [PATCH 2/3] drm/i915/hwmon: Add HWMON energy support
> -Original Message- > From: Dixit, Ashutosh > Sent: Wednesday, May 25, 2022 10:27 AM > To: Nilawar, Badal > Cc: intel-gfx@lists.freedesktop.org; Gupta, Anshuman > ; Ewins, Jon ; Tauro, > Riana ; Joonas Lahtinen > > Subject: Re: [PATCH 2/3] drm/i915/hwmon: Add HWMON energy support > > On Mon, 23 May 2022 04:08:40 -0700, Badal Nilawar wrote: > > > > From: Dale B Stimson > > > > As part of the System Managemenent Interface (SMI), use the HWMON > > subsystem to display energy utilization > > Energy seems to be hardly ever exposed in the kernel. Searching for > 'hwmon_energy' shows only a single hit in drivers/hwmon/scmi-hwmon.c. > We should see if there are real consumers for this and the reason for > exposing this. rc6_idle test opens energy sys fs to test the Entergy numbers via rapl interface(AFAIR that interface is via x86 MSR) but that interface is not available to use for dgfx. If we can use hwmon energy interface. It can be leverage for IGT tests? Thanks, Anshuman Gupta.
Re: [Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Add HWMON current voltage support
On Mon, 23 May 2022 04:08:41 -0700, Badal Nilawar wrote:
>
> +static umode_t
> +i915_in_is_visible(const struct i915_hwmon_drvdata *ddat, u32 attr)
> +{
> + struct drm_i915_private *i915 = ddat->dd_uncore->i915;
> +
> + switch (attr) {
> + case hwmon_in_input:
> + return (IS_DG1(i915) || IS_DG2(i915)) ? 0444 : 0;
Nit but maybe we should change this to:
return i915_mmio_reg_valid() ? 0444 : 0;
So that the platform checks are in one place in
i915_hwmon_get_preregistration_info()?
Re: [Intel-gfx] [PATCH 2/3] drm/i915/hwmon: Add HWMON energy support
On Mon, 23 May 2022 04:08:40 -0700, Badal Nilawar wrote: > > From: Dale B Stimson > > As part of the System Managemenent Interface (SMI), use the HWMON > subsystem to display energy utilization Energy seems to be hardly ever exposed in the kernel. Searching for 'hwmon_energy' shows only a single hit in drivers/hwmon/scmi-hwmon.c. We should see if there are real consumers for this and the reason for exposing this.
Re: [Intel-gfx] [PATCH 2/3] drm/i915/hwmon: Add HWMON energy support
On Mon, 23 May 2022 04:08:40 -0700, Badal Nilawar wrote: > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c > b/drivers/gpu/drm/i915/i915_hwmon.c > index b94c11f2517f..b35c4de73f30 100644 > --- a/drivers/gpu/drm/i915/i915_hwmon.c > +++ b/drivers/gpu/drm/i915/i915_hwmon.c > @@ -18,8 +18,10 @@ > /* > * SF_* - scale factors for particular quantities according to hwmon spec. > * - power - microwatts > + * - energy - microjoules > */ > #define SF_POWER 100 > +#define SF_ENERGY100 > > #define FIELD_SHIFT(__mask) \ > (BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) + \ > @@ -94,6 +96,136 @@ _field_scale_and_write(struct i915_hwmon_drvdata *ddat, > i915_reg_t rgadr, >bits_to_clear, bits_to_set); > } > > +/* > + * _i915_energy1_input_sub - A custom function to obtain energy1_input. > + * Use a custom function instead of the usual hwmon helpers in order to > + * guarantee 64-bits of result to user-space. We need to look into whether energy needs to be a custom interface or can it just be the standard interface. The justification for custom interface is that energy needs to be a u64 but the standard interface is already a long which is at least 63 bits already. So the question is is that extra bit needed which justifies a custom interface? > + * Units are microjoules. > + * > + * The underlying hardware register is 32-bits and is subject to overflow. > + * This function compensates for overflow of the 32-bit register by detecting > + * wrap-around and incrementing an overflow counter. > + * This only works if the register is sampled often enough to avoid > + * missing an instance of overflow - achieved either by repeated > + * queries through the API, or via a possible timer (future - TBD) that > + * ensures values are read often enough to catch all overflows. > + * > + * How long before overflow? For example, with an example scaling bit > + * shift of 14 bits (see register *PACKAGE_POWER_SKU_UNIT) and a power draw > of > + * 1000 watts, the 32-bit counter will overflow in approximately 4.36 > minutes. > + * > + * Examples: > + *1 watt: (2^32 >> 14) /1 W / (60 * 60 * 24) secs/day -> 3 days > + * 1000 watts: (2^32 >> 14) / 1000 W / 60 secs/min -> 4.36 > minutes We need to "sample" the energy often enough to avoid 32 bit counter overflow. But that can be a later patch.
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/display: Implement seamless mode switch
Hello,
Apologies for bothering. May we kindly know if this solution is approved?
I have provided the Tested-by. Thanks much.
Regards
Vidya
> -Original Message-
> From: Srinivas, Vidya
> Sent: Monday, May 9, 2022 8:44 PM
> To: Souza, Jose ; intel-gfx@lists.freedesktop.org
> Cc: Sean Paul ; Ville Syrjälä
>
> Subject: RE: [PATCH v2 3/3] drm/i915/display: Implement seamless mode
> switch
>
> Hello Jose,
>
> Thanks much for the patch. I tested it on chrome system and the patch
> works.
> Adding my Tested-by.
> Tested-by: Vidya Srinivas
>
> Regards
> Vidya
>
> > -Original Message-
> > From: Souza, Jose
> > Sent: Tuesday, May 3, 2022 2:11 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Srinivas, Vidya ; Sean Paul
> > ; Ville Syrjälä
> > ; Souza, Jose
> > Subject: [PATCH v2 3/3] drm/i915/display: Implement seamless mode
> > switch
> >
> > So far the i915's DRRS feature was automatically changing between
> > preferred panel mode and downclock mode based on idleness but
> ChromeOS
> > compositor team is asking to be in control of the mode switch.
> > So for certain types of content it can switch to a mode with a lower
> > refresh rate without the user noticing a thing and saving more power.
> >
> > This seamless mode switch will be triggered when user-space dispatches
> > an atomic commit with the new mode and clears the
> > DRM_MODE_ATOMIC_ALLOW_MODESET flag.
> >
> > The main steps to acomplish that are:
> >
> > - as mode changed in atomic state drm_atomic_helper_check_modeset()
> > will set mode_changed and it will trigger the crtc state computation
> > so
> > intel_dp_compute_config() will be called and dp_m_n will be computed
> > for the new mode
> >
> > - then intel_dp_drrs_compute_config() will check for the necessary
> > conditions to do a seamless mode switch, if possible crtc_state-
> > >seamless_mode_switch will be set and has_drrs will not be set, so
> > >i915 will
> > not automatically switch between modes
> >
> > - then intel_crtc_compute_config() will call
> > intel_crtc_compute_pixel_rate() that will take the hint that it is
> > trying to do a seamless mode switch and set pixel_rate to the
> > pixel_rate of the old state
> >
> > - then if nothing else changed in the state intel_crtc_check_fastset()
> > will be able to set mode_changed to false and i915 can do fastset
> > otherwise the commit will fail during the check phase
> >
> > - now on the atomic commit phase, intel_ddi_update_pipe_dp() will be
> > called and will program the new dp_m_n
> >
> > - nothing else is different in the commit phase until the step to
> > verify programmed state, the most important change here is that need
> > to save the pixel_rate in DRRS global state as there is no other way
> > to get that from hardware or atomic state
> >
> > v2:
> > - not overwritten dp_m_n values in intel_crtc_copy_fastset() when
> > doing a seamless_mode_switch
> >
> > Cc: Vidya Srinivas
> > Cc: Sean Paul
> > Cc: Ville Syrjälä
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 10 +++
> > drivers/gpu/drm/i915/display/intel_display.c | 61
> > --- .../drm/i915/display/intel_display_debugfs.c | 3 +
> > .../drm/i915/display/intel_display_types.h| 3 +
> > drivers/gpu/drm/i915/display/intel_dp.c | 56 ++---
> > drivers/gpu/drm/i915/display/intel_drrs.c | 38 +---
> > drivers/gpu/drm/i915/display/intel_drrs.h | 3 +
> > 7 files changed, 151 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 9e6fa59eabba7..732e5d425412e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -46,6 +46,7 @@
> > #include "intel_dp_link_training.h"
> > #include "intel_dp_mst.h"
> > #include "intel_dpio_phy.h"
> > +#include "intel_drrs.h"
> > #include "intel_dsi.h"
> > #include "intel_fdi.h"
> > #include "intel_fifo_underrun.h"
> > @@ -3010,6 +3011,14 @@ static void intel_ddi_update_pipe_dp(struct
> > intel_atomic_state *state,
> >
> > intel_backlight_update(state, encoder, crtc_state, conn_state);
> > drm_connector_update_privacy_screen(conn_state);
> > +
> > + if (crtc_state->seamless_mode_switch) {
> > + struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state-
> > >uapi.crtc);
> > +
> > + intel_cpu_transcoder_set_m1_n1(intel_crtc,
> > + crtc_state->cpu_transcoder,
> > + _state->dp_m_n);
> > + }
> > }
> >
> > void intel_ddi_update_pipe(struct intel_atomic_state *state, @@
> > -3484,6
> > +3493,7 @@ static void intel_ddi_get_config(struct intel_encoder
> > +*encoder,
> > intel_read_dp_sdp(encoder, pipe_config, DP_SDP_VSC);
> >
> > intel_psr_get_config(encoder, pipe_config);
> > + intel_drrs_get_config(encoder, pipe_config);
> > }
> >
> > void
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hwconfig: Future-proof platform checks
== Series Details ==
Series: drm/i915/hwconfig: Future-proof platform checks
URL : https://patchwork.freedesktop.org/series/104338/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11696 -> Patchwork_104338v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104338v1/index.html
Participating hosts (45 -> 45)
--
Additional (2): fi-hsw-4770 bat-atsm-1
Missing(2): bat-adlm-1 fi-rkl-11600
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104338v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_lmem_swapping@verify-random@lmem0:
- {bat-atsm-1}: NOTRUN -> [INCOMPLETE][1] +4 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104338v1/bat-atsm-1/igt@gem_lmem_swapping@verify-ran...@lmem0.html
* igt@kms_addfb_basic@bad-pitch-256:
- {bat-atsm-1}: NOTRUN -> [SKIP][2] +91 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104338v1/bat-atsm-1/igt@kms_addfb_ba...@bad-pitch-256.html
* igt@kms_flip@basic-flip-vs-modeset:
- {bat-atsm-1}: NOTRUN -> [FAIL][3] +8 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104338v1/bat-atsm-1/igt@kms_f...@basic-flip-vs-modeset.html
Known issues
Here are the changes found in Patchwork_104338v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271]) +9 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104338v1/fi-hsw-4770/igt@gem_huc_c...@huc-copy.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#3012])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104338v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@execlists:
- fi-bsw-kefka: [PASS][6] -> [INCOMPLETE][7] ([i915#2940] /
[i915#5801])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11696/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104338v1/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [PASS][8] -> [INCOMPLETE][9] ([i915#4418])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11696/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104338v1/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@mman:
- fi-icl-u2: [PASS][10] -> [INCOMPLETE][11] ([i915#4890])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11696/fi-icl-u2/igt@i915_selftest@l...@mman.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104338v1/fi-icl-u2/igt@i915_selftest@l...@mman.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][12] -> [DMESG-FAIL][13] ([i915#4528])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11696/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104338v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104338v1/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-snb-2600:NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104338v1/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-edp1:
- bat-adlp-4: [PASS][16] -> [DMESG-WARN][17] ([i915#3576]) +2
similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11696/bat-adlp-4/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104338v1/bat-adlp-4/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-hsw-4770:NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#533])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104338v1/fi-hsw-4770/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@primary_mmap_gtt:
- fi-hsw-4770:NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#1072]) +3
similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104338v1/fi-hsw-4770/igt@kms_psr@primary_mmap_gtt.html
* igt@runner@aborted:
- fi-bsw-kefka: NOTRUN
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Media freq factor and per-gt enhancements/fixes (rev9)
== Series Details == Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev9) URL : https://patchwork.freedesktop.org/series/102665/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Media freq factor and per-gt enhancements/fixes (rev9)
== Series Details == Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev9) URL : https://patchwork.freedesktop.org/series/102665/ State : warning == Summary == Error: dim checkpatch failed 63e0ab0ed664 drm/i915/gt: Add media freq factor to per-gt sysfs 2e706c2fdf7e drm/i915/pcode: Init pcode on different gt's 7fd38d4f289e drm/i915/gt: Add media RP0/RPn to per-gt sysfs -:83: CHECK:CAMELCASE: Avoid CamelCase: #83: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:720: +static DEVICE_ATTR_RO(media_RPn_freq_mhz); -:89: CHECK:CAMELCASE: Avoid CamelCase: #89: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:726: + _attr_media_RPn_freq_mhz.attr, total: 0 errors, 0 warnings, 2 checks, 80 lines checked e18539ed7c20 drm/i915/gt: Fix memory leaks in per-gt sysfs
[Intel-gfx] [PATCH] drm/i915/hwconfig: Future-proof platform checks
PVC also has a hwconfig table. Actually the current expectation is that
all future platforms will have hwconfig, so let's just change the
condition to an IP version check so that we don't need to keep updating
this for each new platform that shows up.
Cc: John Harrison
Cc: Radhakrishna Sripada
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
index 5aaa3948de74..4781fccc2687 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -96,7 +96,7 @@ static bool has_table(struct drm_i915_private *i915)
{
if (IS_ALDERLAKE_P(i915) && !IS_ADLP_N(i915))
return true;
- if (IS_DG2(i915))
+ if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 55))
return true;
return false;
--
2.35.3
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/hwconfig: Report no hwconfig support on ADL-N
On Mon, May 23, 2022 at 08:16:36PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/hwconfig: Report no hwconfig support on ADL-N
> URL : https://patchwork.freedesktop.org/series/104270/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11690_full -> Patchwork_104270v1_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_104270v1_full absolutely need
> to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_104270v1_full, please notify your bug team to allow
> them
> to document this new failure mode, which will reduce false positives in CI.
>
>
>
> Participating hosts (13 -> 12)
> --
>
> Missing(1): shard-rkl
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_104270v1_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@kms_cursor_crc@pipe-a-cursor-256x256-sliding:
> - shard-tglb: [PASS][1] -> [INCOMPLETE][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11690/shard-tglb1/igt@kms_cursor_...@pipe-a-cursor-256x256-sliding.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-tglb8/igt@kms_cursor_...@pipe-a-cursor-256x256-sliding.html
Seems like the machine or network died; the logs just cut off with no
indication of a problem before that point. And ADL-N hwconfig change
wouldn't impact the behavior of a TGL display test, so not related to
Bala's patch here.
Patch applied to drm-intel-gt-next. Thanks for the patch.
Matt
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * {igt@kms_hdr@bpc-switch@pipe-a-hdmi-a-1}:
> - {shard-dg1}:NOTRUN -> [SKIP][3]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-dg1-16/igt@kms_hdr@bpc-swi...@pipe-a-hdmi-a-1.html
>
>
> New tests
> -
>
> New tests have been introduced between CI_DRM_11690_full and
> Patchwork_104270v1_full:
>
> ### New IGT tests (7) ###
>
> * igt@gem_busy@parallel:
> - Statuses :
> - Exec time: [None] s
>
> * igt@kms_flip@modeset-vs-vblank-race@a-dp1:
> - Statuses : 2 pass(s)
> - Exec time: [4.03, 4.20] s
>
> * igt@kms_flip@modeset-vs-vblank-race@b-dp1:
> - Statuses : 2 pass(s)
> - Exec time: [3.92, 4.06] s
>
> * igt@kms_flip@modeset-vs-vblank-race@c-dp1:
> - Statuses : 2 pass(s)
> - Exec time: [3.99, 4.11] s
>
> * igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1:
> - Statuses : 1 pass(s)
> - Exec time: [11.53] s
>
> * igt@perf_pmu@busy-accuracy-2:
> - Statuses :
> - Exec time: [None] s
>
> * igt@perf_pmu@most-busy-idle-check-all:
> - Statuses :
> - Exec time: [None] s
>
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_104270v1_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@feature_discovery@display-2x:
> - shard-iclb: NOTRUN -> [SKIP][4] ([i915#1839])
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-iclb5/igt@feature_discov...@display-2x.html
>
> * igt@gem_exec_fair@basic-deadline:
> - shard-kbl: NOTRUN -> [FAIL][5] ([i915#2846])
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-kbl6/igt@gem_exec_f...@basic-deadline.html
> - shard-apl: NOTRUN -> [FAIL][6] ([i915#2846])
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-apl2/igt@gem_exec_f...@basic-deadline.html
>
> * igt@gem_exec_fair@basic-none@vecs0:
> - shard-apl: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar
> issue
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11690/shard-apl6/igt@gem_exec_fair@basic-n...@vecs0.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-apl4/igt@gem_exec_fair@basic-n...@vecs0.html
>
> * igt@gem_exec_fair@basic-pace-solo@rcs0:
> - shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842]) +1 similar issue
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-iclb6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
>
> * igt@gem_exec_fair@basic-pace@vcs0:
> - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842])
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11690/shard-glk8/igt@gem_exec_fair@basic-p...@vcs0.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-glk3/igt@gem_exec_fair@basic-p...@vcs0.html
>
> * igt@gem_lmem_swapping@basic:
> - shard-iclb: NOTRUN -> [SKIP][12] ([i915#4613])
>[12]:
>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/edid: expand on struct drm_edid usage (rev2)
== Series Details ==
Series: drm/edid: expand on struct drm_edid usage (rev2)
URL : https://patchwork.freedesktop.org/series/104309/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11694_full -> Patchwork_104309v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104309v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_color@pipe-b-deep-color:
- {shard-rkl}:[SKIP][1] ([i915#4070] / [i915#4098]) ->
[INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/shard-rkl-2/igt@kms_co...@pipe-b-deep-color.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/shard-rkl-6/igt@kms_co...@pipe-b-deep-color.html
* {igt@kms_hdr@bpc-switch-suspend@pipe-a-hdmi-a-1}:
- {shard-dg1}:NOTRUN -> [SKIP][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/shard-dg1-17/igt@kms_hdr@bpc-switch-susp...@pipe-a-hdmi-a-1.html
* {igt@kms_hdr@bpc-switch@pipe-a-hdmi-a-1}:
- shard-glk: [SKIP][4] ([fdo#109271]) -> [FAIL][5] +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/shard-glk8/igt@kms_hdr@bpc-swi...@pipe-a-hdmi-a-1.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/shard-glk4/igt@kms_hdr@bpc-swi...@pipe-a-hdmi-a-1.html
Known issues
Here are the changes found in Patchwork_104309v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ccs@block-copy-uncompressed:
- shard-iclb: NOTRUN -> [SKIP][6] ([i915#5327])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/shard-iclb7/igt@gem_...@block-copy-uncompressed.html
* igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#4793])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/shard-skl4/igt@gem_ctx_isolation@preservation...@bcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/shard-skl7/igt@gem_ctx_isolation@preservation...@bcs0.html
* igt@gem_eio@kms:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#5784])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/shard-tglb7/igt@gem_...@kms.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/shard-tglb2/igt@gem_...@kms.html
* igt@gem_exec_balancer@parallel-ordering:
- shard-iclb: NOTRUN -> [SKIP][11] ([i915#4525])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/shard-iclb7/igt@gem_exec_balan...@parallel-ordering.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar
issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
- shard-glk: [PASS][14] -> [FAIL][15] ([i915#2842])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fence@basic-wait@bcs0:
- shard-kbl: NOTRUN -> [SKIP][16] ([fdo#109271]) +44 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/shard-kbl3/igt@gem_exec_fence@basic-w...@bcs0.html
* igt@gem_lmem_swapping@heavy-verify-random-ccs:
- shard-kbl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/shard-kbl3/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html
* igt@gem_lmem_swapping@parallel-random-verify:
- shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/shard-skl6/igt@gem_lmem_swapp...@parallel-random-verify.html
* igt@gem_lmem_swapping@verify:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#4613])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/shard-iclb7/igt@gem_lmem_swapp...@verify.html
- shard-glk: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/shard-glk7/igt@gem_lmem_swapp...@verify.html
* igt@gem_pxp@verify-pxp-stale-buf-optout-execution:
- shard-iclb: NOTRUN -> [SKIP][21] ([i915#4270])
[21]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Individualize fences before adding to dma_resv obj (rev4)
== Series Details ==
Series: drm/i915: Individualize fences before adding to dma_resv obj (rev4)
URL : https://patchwork.freedesktop.org/series/104074/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11694_full -> Patchwork_104074v4_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_104074v4_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_104074v4_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104074v4_full:
### IGT changes ###
Warnings
* igt@gem_exec_balancer@parallel-ordering:
- shard-tglb: [DMESG-FAIL][1] ([i915#5076] / [i915#5614]) ->
[FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/shard-tglb7/igt@gem_exec_balan...@parallel-ordering.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/shard-tglb7/igt@gem_exec_balan...@parallel-ordering.html
- shard-kbl: [DMESG-FAIL][3] ([i915#5076] / [i915#5614]) ->
[FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/shard-kbl1/igt@gem_exec_balan...@parallel-ordering.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/shard-kbl4/igt@gem_exec_balan...@parallel-ordering.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_balancer@parallel-ordering:
- {shard-tglu}: [DMESG-FAIL][5] ([i915#5076] / [i915#5614]) ->
[FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/shard-tglu-8/igt@gem_exec_balan...@parallel-ordering.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/shard-tglu-4/igt@gem_exec_balan...@parallel-ordering.html
* {igt@kms_hdr@bpc-switch@pipe-a-hdmi-a-1}:
- shard-glk: [SKIP][7] ([fdo#109271]) -> [FAIL][8] +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/shard-glk8/igt@kms_hdr@bpc-swi...@pipe-a-hdmi-a-1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/shard-glk7/igt@kms_hdr@bpc-swi...@pipe-a-hdmi-a-1.html
* igt@perf@i915-ref-count:
- {shard-dg1}:[PASS][9] -> [FAIL][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/shard-dg1-19/igt@p...@i915-ref-count.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/shard-dg1-17/igt@p...@i915-ref-count.html
Known issues
Here are the changes found in Patchwork_104074v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@drm_buddy@all@buddy_alloc_smoke:
- shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#5800])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/shard-skl9/igt@drm_buddy@all@buddy_alloc_smoke.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/shard-skl6/igt@drm_buddy@all@buddy_alloc_smoke.html
* igt@gem_ccs@block-copy-compressed:
- shard-tglb: NOTRUN -> [SKIP][13] ([i915#3555] / [i915#5325])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/shard-tglb6/igt@gem_...@block-copy-compressed.html
* igt@gem_ccs@block-copy-uncompressed:
- shard-iclb: NOTRUN -> [SKIP][14] ([i915#5327])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/shard-iclb7/igt@gem_...@block-copy-uncompressed.html
* igt@gem_ctx_persistence@engines-hostile-preempt:
- shard-snb: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#1099])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/shard-snb4/igt@gem_ctx_persiste...@engines-hostile-preempt.html
* igt@gem_eio@in-flight-contexts-immediate:
- shard-iclb: [PASS][16] -> [TIMEOUT][17] ([i915#3070])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/shard-iclb5/igt@gem_...@in-flight-contexts-immediate.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/shard-iclb5/igt@gem_...@in-flight-contexts-immediate.html
* igt@gem_eio@kms:
- shard-tglb: [PASS][18] -> [FAIL][19] ([i915#5784])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/shard-tglb7/igt@gem_...@kms.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/shard-tglb8/igt@gem_...@kms.html
* igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][20] -> [SKIP][21] ([i915#4525])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/shard-iclb4/igt@gem_exec_balan...@parallel-balancer.html
[21]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/edid: expand on struct drm_edid usage (rev2)
== Series Details == Series: drm/edid: expand on struct drm_edid usage (rev2) URL : https://patchwork.freedesktop.org/series/104309/ State : success == Summary == CI Bug Log - changes from CI_DRM_11694 -> Patchwork_104309v2 Summary --- **WARNING** Minor unknown changes coming with Patchwork_104309v2 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_104309v2, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/index.html Participating hosts (46 -> 46) -- Additional (2): fi-hsw-4770 bat-jsl-2 Missing(2): bat-adlm-1 fi-icl-u2 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_104309v2: ### IGT changes ### Warnings * igt@debugfs_test@read_all_entries: - fi-apl-guc: [DMESG-WARN][1] ([i915#5595]) -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/fi-apl-guc/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/fi-apl-guc/igt@debugfs_test@read_all_entries.html Known issues Here are the changes found in Patchwork_104309v2 that come from known issues: ### CI changes ### Possible fixes * boot: - fi-bxt-dsi: [FAIL][3] ([i915#6003]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/fi-bxt-dsi/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/fi-bxt-dsi/boot.html ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271]) +9 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/fi-hsw-4770/igt@gem_huc_c...@huc-copy.html - fi-bxt-dsi: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - fi-bxt-dsi: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/fi-bxt-dsi/igt@gem_lmem_swapp...@verify-random.html * igt@i915_pm_backlight@basic-brightness: - fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3012]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gem_contexts: - fi-bdw-5557u: [PASS][9] -> [INCOMPLETE][10] ([i915#5502] / [i915#5801]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html * igt@i915_selftest@live@hangcheck: - fi-hsw-4770:NOTRUN -> [INCOMPLETE][11] ([i915#4785]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@requests: - fi-pnv-d510:[PASS][12] -> [DMESG-FAIL][13] ([i915#4528]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/fi-pnv-d510/igt@i915_selftest@l...@requests.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/fi-pnv-d510/igt@i915_selftest@l...@requests.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-bxt-dsi: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/fi-bxt-dsi/igt@kms_chamel...@common-hpd-after-suspend.html - fi-bsw-kefka: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/fi-bsw-kefka/igt@kms_chamel...@common-hpd-after-suspend.html - fi-snb-2600:NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html - fi-rkl-11600: NOTRUN -> [SKIP][17] ([fdo#111827]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/fi-rkl-11600/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@dp-crc-fast: - fi-hsw-4770:NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +7 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v2/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html * igt@kms_flip@basic-flip-vs-modeset@b-edp1: - bat-adlp-4: [PASS][19] -> [DMESG-WARN][20] ([i915#3576]) [19]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Media freq factor and per-gt enhancements/fixes (rev8)
== Series Details ==
Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev8)
URL : https://patchwork.freedesktop.org/series/102665/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11694 -> Patchwork_102665v8
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_102665v8 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_102665v8, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v8/index.html
Participating hosts (46 -> 9)
--
ERROR: It appears as if the changes made in Patchwork_102665v8 prevented too
many machines from booting.
Additional (2): bat-jsl-2 bat-atsm-1
Missing(39): fi-kbl-soraka fi-rkl-11600 fi-rkl-guc fi-bdw-gvtdvm
fi-icl-u2 fi-snb-2520m fi-apl-guc fi-pnv-d510 fi-blb-e6850 fi-skl-6600u
fi-snb-2600 fi-bxt-dsi fi-bdw-5557u fi-bsw-n3050 fi-adl-ddr5 bat-dg2-8
fi-tgl-u2 bat-adlm-1 fi-bwr-2160 fi-glk-dsi fi-hsw-g3258 fi-ilk-650 fi-ivb-3770
fi-elk-e7500 fi-bsw-nick fi-skl-6700k2 fi-kbl-7567u fi-tgl-dsi fi-skl-guc
fi-cfl-8700k fi-glk-j4005 fi-ehl-2 fi-jsl-1 fi-tgl-1115g4 fi-cfl-guc fi-kbl-guc
fi-cfl-8109u fi-kbl-8809g fi-bsw-kefka
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_102665v8:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_lmem_swapping@verify-random@lmem0:
- {bat-atsm-1}: NOTRUN -> [INCOMPLETE][1] +4 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v8/bat-atsm-1/igt@gem_lmem_swapping@verify-ran...@lmem0.html
* igt@kms_addfb_basic@bad-pitch-256:
- {bat-atsm-1}: NOTRUN -> [SKIP][2] +95 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v8/bat-atsm-1/igt@kms_addfb_ba...@bad-pitch-256.html
* igt@kms_flip@basic-flip-vs-modeset:
- {bat-atsm-1}: NOTRUN -> [FAIL][3] +8 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v8/bat-atsm-1/igt@kms_f...@basic-flip-vs-modeset.html
Known issues
Here are the changes found in Patchwork_102665v8 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-rte:
- bat-dg1-5: [PASS][4] -> [SKIP][5] ([i915#4078]) +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/bat-dg1-5/igt@i915_pm_...@basic-rte.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v8/bat-dg1-5/igt@i915_pm_...@basic-rte.html
* igt@i915_pm_rpm@module-reload:
- bat-adlp-4: [PASS][6] -> [DMESG-WARN][7] ([i915#3576])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/bat-adlp-4/igt@i915_pm_...@module-reload.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v8/bat-adlp-4/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@common-hpd-after-suspend:
- bat-dg1-6: NOTRUN -> [SKIP][8] ([fdo#111827])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v8/bat-dg1-6/igt@kms_chamel...@common-hpd-after-suspend.html
- bat-dg1-5: NOTRUN -> [SKIP][9] ([fdo#111827])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v8/bat-dg1-5/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- bat-dg1-5: NOTRUN -> [SKIP][10] ([i915#4078])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v8/bat-dg1-5/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][11] ([i915#4494] / [i915#4957]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v8/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- bat-adlp-4: [DMESG-WARN][13] ([i915#3576]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v8/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
* igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- {bat-adlp-6}: [DMESG-WARN][15] ([i915#3576]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
[16]:
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for i915: Introduce Ponte Vecchio (rev4)
On Wed, May 11, 2022 at 11:17:34PM +, Patchwork wrote: > == Series Details == > > Series: i915: Introduce Ponte Vecchio (rev4) > URL : https://patchwork.freedesktop.org/series/103443/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_11632_full -> Patchwork_103443v4_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > Fixed the commit message typos and extra blank line flagged by checkpatch and pushed to drm-intel-gt-next. Thanks Matt Atwood for the reviews. Matt > > > Participating hosts (12 -> 12) > -- > > No changes in participating hosts > > Known issues > > > Here are the changes found in Patchwork_103443v4_full that come from known > issues: > > ### CI changes ### > > Possible fixes > > * boot: > - shard-apl: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], > [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], > [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], > [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], > [PASS][23], [PASS][24], [FAIL][25]) ([i915#4386]) -> ([PASS][26], [PASS][27], > [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], > [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], > [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], > [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl1/boot.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl8/boot.html >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl8/boot.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl8/boot.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl7/boot.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl7/boot.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl7/boot.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl6/boot.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl6/boot.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl6/boot.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl6/boot.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl4/boot.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl4/boot.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl4/boot.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl3/boot.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl3/boot.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl3/boot.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl3/boot.html >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl3/boot.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl2/boot.html >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl2/boot.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl2/boot.html >[23]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl2/boot.html >[24]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl1/boot.html >[25]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11632/shard-apl1/boot.html >[26]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v4/shard-apl8/boot.html >[27]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v4/shard-apl8/boot.html >[28]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v4/shard-apl8/boot.html >[29]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v4/shard-apl7/boot.html >[30]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v4/shard-apl7/boot.html >[31]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v4/shard-apl7/boot.html >[32]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v4/shard-apl6/boot.html >[33]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v4/shard-apl6/boot.html >[34]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v4/shard-apl6/boot.html >[35]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v4/shard-apl6/boot.html >[36]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v4/shard-apl6/boot.html >[37]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v4/shard-apl4/boot.html >[38]: >
Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/guc: XEHPSDV and PVC do not use HuC
On Tue, May 10, 2022 at 11:02:28PM -0700, Matt Roper wrote: > From: Daniele Ceraolo Spurio > > Disable HuC loading since it is not used on these platforms. > > Cc: Stuart Summers Reviewed-by: Matt Atwood > Signed-off-by: Daniele Ceraolo Spurio > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c > b/drivers/gpu/drm/i915/gt/uc/intel_uc.c > index ecf149c5fdb0..55e1eb8f3612 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c > @@ -45,6 +45,10 @@ static void uc_expand_default_options(struct intel_uc *uc) > > /* Default: enable HuC authentication and GuC submission */ > i915->params.enable_guc = ENABLE_GUC_LOAD_HUC | ENABLE_GUC_SUBMISSION; > + > + /* XEHPSDV and PVC do not use HuC */ > + if (IS_XEHPSDV(i915) || IS_PONTEVECCHIO(i915)) > + i915->params.enable_guc &= ~ENABLE_GUC_LOAD_HUC; > } > > /* Reset GuC providing us with fresh state for both GuC and HuC. > -- > 2.35.1 >
Re: [Intel-gfx] [PATCH v3 4/5] drm/i915/pvc: Add new BCS engines to GuC engine list
On Tue, May 10, 2022 at 11:02:27PM -0700, Matt Roper wrote:
> Intialize ADS system info to reflect the availablity of new BCS engines
>
> Original-author: CQ Tang
> Cc: Stuart Summers
> Cc: John Harrison
Reviewed-by: Matt Atwood
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h| 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index 3eabf4cf8eec..bb197610fd5b 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -457,7 +457,7 @@ static void fill_engine_enable_masks(struct intel_gt *gt,
> {
> info_map_write(info_map, engine_enabled_masks[GUC_RENDER_CLASS],
> RCS_MASK(gt));
> info_map_write(info_map, engine_enabled_masks[GUC_COMPUTE_CLASS],
> CCS_MASK(gt));
> - info_map_write(info_map, engine_enabled_masks[GUC_BLITTER_CLASS], 1);
> + info_map_write(info_map, engine_enabled_masks[GUC_BLITTER_CLASS],
> BCS_MASK(gt));
> info_map_write(info_map, engine_enabled_masks[GUC_VIDEO_CLASS],
> VDBOX_MASK(gt));
> info_map_write(info_map, engine_enabled_masks[GUC_VIDEOENHANCE_CLASS],
> VEBOX_MASK(gt));
> }
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 54e9c2a5493d..4b147fd90ec4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1223,6 +1223,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> })
> #define RCS_MASK(gt) \
> ENGINE_INSTANCES_MASK(gt, RCS0, I915_MAX_RCS)
> +#define BCS_MASK(gt) \
> + ENGINE_INSTANCES_MASK(gt, BCS0, I915_MAX_BCS)
> #define VDBOX_MASK(gt) \
> ENGINE_INSTANCES_MASK(gt, VCS0, I915_MAX_VCS)
> #define VEBOX_MASK(gt) \
> --
> 2.35.1
>
Re: [Intel-gfx] [PATCH v3 3/5] drm/i915/pvc: Remove additional 3D flags from PIPE_CONTROL
On Tue, May 10, 2022 at 11:02:26PM -0700, Matt Roper wrote: > From: Stuart Summers > > Although we already strip 3D-specific flags from PIPE_CONTROL > instructions when submitting to a compute engine, there are some > additional flags that need to be removed when the platform as a whole > lacks a 3D pipeline. Add those restrictions here. > > v2: > - Replace LACKS_3D_PIPELINE checks with !HAS_3D_PIPELINE and add >has_3d_pipeline to all platforms except PVC. (Lucas) > > Bspec: 47112 > Cc: Lucas De Marchi Reviewed-by: Matt Atwood > Signed-off-by: Stuart Summers > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 18 -- > drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 15 +-- > drivers/gpu/drm/i915/i915_drv.h | 2 ++ > drivers/gpu/drm/i915/i915_pci.c | 10 ++ > drivers/gpu/drm/i915/intel_device_info.h | 1 + > 5 files changed, 38 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c > b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c > index daa1a61972f4..98645797962f 100644 > --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c > +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c > @@ -197,8 +197,10 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 > mode) > > flags |= PIPE_CONTROL_CS_STALL; > > - if (engine->class == COMPUTE_CLASS) > - flags &= ~PIPE_CONTROL_3D_FLAGS; > + if (!HAS_3D_PIPELINE(engine->i915)) > + flags &= ~PIPE_CONTROL_3D_ARCH_FLAGS; > + else if (engine->class == COMPUTE_CLASS) > + flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS; > > cs = intel_ring_begin(rq, 6); > if (IS_ERR(cs)) > @@ -227,8 +229,10 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 > mode) > > flags |= PIPE_CONTROL_CS_STALL; > > - if (engine->class == COMPUTE_CLASS) > - flags &= ~PIPE_CONTROL_3D_FLAGS; > + if (!HAS_3D_PIPELINE(engine->i915)) > + flags &= ~PIPE_CONTROL_3D_ARCH_FLAGS; > + else if (engine->class == COMPUTE_CLASS) > + flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS; > > if (!HAS_FLAT_CCS(rq->engine->i915)) > count = 8 + 4; > @@ -717,8 +721,10 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request > *rq, u32 *cs) > /* Wa_1409600907 */ > flags |= PIPE_CONTROL_DEPTH_STALL; > > - if (rq->engine->class == COMPUTE_CLASS) > - flags &= ~PIPE_CONTROL_3D_FLAGS; > + if (!HAS_3D_PIPELINE(rq->engine->i915)) > + flags &= ~PIPE_CONTROL_3D_ARCH_FLAGS; > + else if (rq->engine->class == COMPUTE_CLASS) > + flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS; > > cs = gen12_emit_ggtt_write_rcs(cs, > rq->fence.seqno, > diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h > b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h > index 556bca3be804..964fe376c7fa 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h > +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h > @@ -288,8 +288,11 @@ > #define PIPE_CONTROL_DEPTH_CACHE_FLUSH (1<<0) > #define PIPE_CONTROL_GLOBAL_GTT (1<<2) /* in addr dword */ > > -/* 3D-related flags can't be set on compute engine */ > -#define PIPE_CONTROL_3D_FLAGS (\ > +/* > + * 3D-related flags that can't be set on _engines_ that lack access to the 3D > + * pipeline (i.e., CCS engines). > + */ > +#define PIPE_CONTROL_3D_ENGINE_FLAGS (\ > PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH | \ > PIPE_CONTROL_DEPTH_CACHE_FLUSH | \ > PIPE_CONTROL_TILE_CACHE_FLUSH | \ > @@ -300,6 +303,14 @@ > PIPE_CONTROL_VF_CACHE_INVALIDATE | \ > PIPE_CONTROL_GLOBAL_SNAPSHOT_RESET) > > +/* 3D-related flags that can't be set on _platforms_ that lack a 3D pipeline > */ > +#define PIPE_CONTROL_3D_ARCH_FLAGS ( \ > + PIPE_CONTROL_3D_ENGINE_FLAGS | \ > + PIPE_CONTROL_INDIRECT_STATE_DISABLE | \ > + PIPE_CONTROL_FLUSH_ENABLE | \ > + PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE | \ > + PIPE_CONTROL_DC_FLUSH_ENABLE) > + > #define MI_MATH(x) MI_INSTR(0x1a, (x) - 1) > #define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | > (op2)) > /* Opcodes for MI_MATH_INSTR */ > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 10f273800645..54e9c2a5493d 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1405,6 +1405,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > > #define HAS_MBUS_JOINING(i915) (IS_ALDERLAKE_P(i915)) > > +#define HAS_3D_PIPELINE(i915)(INTEL_INFO(i915)->has_3d_pipeline) > + > /* i915_gem.c */ > void i915_gem_init_early(struct
Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/pvc: Add forcewake support
On Tue, May 10, 2022 at 11:02:25PM -0700, Matt Roper wrote:
> Add PVC's forcewake ranges.
>
> v2:
> - Drop replicated comment completely; move general cleanup of the
>documentation to a separate patch.
>
> Bspec: 67609
> Cc: Daniele Ceraolo Spurio
> Cc: Stuart Summers
Reviewed-by: Matt Atwood
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 142 +-
> drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 +
> 2 files changed, 143 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 095e071e4053..fac0ff60bfbf 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1076,6 +1076,45 @@ static const struct i915_range dg2_shadowed_regs[] = {
> { .start = 0x1F8510, .end = 0x1F8550 },
> };
>
> +static const struct i915_range pvc_shadowed_regs[] = {
> + { .start = 0x2030, .end = 0x2030 },
> + { .start = 0x2510, .end = 0x2550 },
> + { .start = 0xA008, .end = 0xA00C },
> + { .start = 0xA188, .end = 0xA188 },
> + { .start = 0xA278, .end = 0xA278 },
> + { .start = 0xA540, .end = 0xA56C },
> + { .start = 0xC4C8, .end = 0xC4C8 },
> + { .start = 0xC4E0, .end = 0xC4E0 },
> + { .start = 0xC600, .end = 0xC600 },
> + { .start = 0xC658, .end = 0xC658 },
> + { .start = 0x22030, .end = 0x22030 },
> + { .start = 0x22510, .end = 0x22550 },
> + { .start = 0x1C0030, .end = 0x1C0030 },
> + { .start = 0x1C0510, .end = 0x1C0550 },
> + { .start = 0x1C4030, .end = 0x1C4030 },
> + { .start = 0x1C4510, .end = 0x1C4550 },
> + { .start = 0x1C8030, .end = 0x1C8030 },
> + { .start = 0x1C8510, .end = 0x1C8550 },
> + { .start = 0x1D0030, .end = 0x1D0030 },
> + { .start = 0x1D0510, .end = 0x1D0550 },
> + { .start = 0x1D4030, .end = 0x1D4030 },
> + { .start = 0x1D4510, .end = 0x1D4550 },
> + { .start = 0x1D8030, .end = 0x1D8030 },
> + { .start = 0x1D8510, .end = 0x1D8550 },
> + { .start = 0x1E0030, .end = 0x1E0030 },
> + { .start = 0x1E0510, .end = 0x1E0550 },
> + { .start = 0x1E4030, .end = 0x1E4030 },
> + { .start = 0x1E4510, .end = 0x1E4550 },
> + { .start = 0x1E8030, .end = 0x1E8030 },
> + { .start = 0x1E8510, .end = 0x1E8550 },
> + { .start = 0x1F0030, .end = 0x1F0030 },
> + { .start = 0x1F0510, .end = 0x1F0550 },
> + { .start = 0x1F4030, .end = 0x1F4030 },
> + { .start = 0x1F4510, .end = 0x1F4550 },
> + { .start = 0x1F8030, .end = 0x1F8030 },
> + { .start = 0x1F8510, .end = 0x1F8550 },
> +};
> +
> static int mmio_range_cmp(u32 key, const struct i915_range *range)
> {
> if (key < range->start)
> @@ -1525,6 +1564,103 @@ static const struct intel_forcewake_range
> __dg2_fw_ranges[] = {
> XEHP_FWRANGES(FORCEWAKE_RENDER)
> };
>
> +static const struct intel_forcewake_range __pvc_fw_ranges[] = {
> + GEN_FW_RANGE(0x0, 0xaff, 0),
> + GEN_FW_RANGE(0xb00, 0xbff, FORCEWAKE_GT),
> + GEN_FW_RANGE(0xc00, 0xfff, 0),
> + GEN_FW_RANGE(0x1000, 0x1fff, FORCEWAKE_GT),
> + GEN_FW_RANGE(0x2000, 0x26ff, FORCEWAKE_RENDER),
> + GEN_FW_RANGE(0x2700, 0x2fff, FORCEWAKE_GT),
> + GEN_FW_RANGE(0x3000, 0x3fff, FORCEWAKE_RENDER),
> + GEN_FW_RANGE(0x4000, 0x813f, FORCEWAKE_GT), /*
> + 0x4000 - 0x4aff: gt
> + 0x4b00 - 0x4fff: reserved
> + 0x5000 - 0x51ff: gt
> + 0x5200 - 0x52ff: reserved
> + 0x5300 - 0x53ff: gt
> + 0x5400 - 0x7fff: reserved
> + 0x8000 - 0x813f: gt */
> + GEN_FW_RANGE(0x8140, 0x817f, FORCEWAKE_RENDER),
> + GEN_FW_RANGE(0x8180, 0x81ff, 0),
> + GEN_FW_RANGE(0x8200, 0x94cf, FORCEWAKE_GT), /*
> + 0x8200 - 0x82ff: gt
> + 0x8300 - 0x84ff: reserved
> + 0x8500 - 0x887f: gt
> + 0x8880 - 0x8a7f: reserved
> + 0x8a80 - 0x8aff: gt
> + 0x8b00 - 0x8fff: reserved
> + 0x9000 - 0x947f: gt
> + 0x9480 - 0x94cf: reserved */
> + GEN_FW_RANGE(0x94d0, 0x955f, FORCEWAKE_RENDER),
> + GEN_FW_RANGE(0x9560, 0x967f, 0), /*
> + 0x9560 - 0x95ff: always on
> + 0x9600 - 0x967f: reserved */
> + GEN_FW_RANGE(0x9680, 0x97ff, FORCEWAKE_RENDER), /*
> + 0x9680 - 0x96ff: render
> + 0x9700 - 0x97ff: reserved */
> + GEN_FW_RANGE(0x9800, 0xcfff, FORCEWAKE_GT), /*
> + 0x9800 - 0xb4ff: gt
> + 0xb500 - 0xbfff: reserved
> + 0xc000 - 0xcfff: gt */
> + GEN_FW_RANGE(0xd000, 0xd3ff, 0),
> + GEN_FW_RANGE(0xd400, 0xdbff, FORCEWAKE_GT),
> + GEN_FW_RANGE(0xdc00, 0xdcff, FORCEWAKE_RENDER),
> + GEN_FW_RANGE(0xdd00, 0xde7f, FORCEWAKE_GT), /*
> + 0xdd00 - 0xddff: gt
> + 0xde00 - 0xde7f: reserved */
> + GEN_FW_RANGE(0xde80, 0xe8ff, FORCEWAKE_RENDER), /*
> +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Individualize fences before adding to dma_resv obj (rev4)
== Series Details ==
Series: drm/i915: Individualize fences before adding to dma_resv obj (rev4)
URL : https://patchwork.freedesktop.org/series/104074/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11694 -> Patchwork_104074v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/index.html
Participating hosts (46 -> 46)
--
Additional (3): fi-hsw-4770 bat-jsl-2 bat-atsm-1
Missing(3): bat-dg2-8 fi-rkl-11600 fi-icl-u2
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104074v4:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_lmem_swapping@verify-random@lmem0:
- {bat-atsm-1}: NOTRUN -> [INCOMPLETE][1] +4 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/bat-atsm-1/igt@gem_lmem_swapping@verify-ran...@lmem0.html
* igt@kms_addfb_basic@bad-pitch-256:
- {bat-atsm-1}: NOTRUN -> [SKIP][2] +91 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/bat-atsm-1/igt@kms_addfb_ba...@bad-pitch-256.html
* igt@kms_flip@basic-flip-vs-modeset:
- {bat-atsm-1}: NOTRUN -> [FAIL][3] +8 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/bat-atsm-1/igt@kms_f...@basic-flip-vs-modeset.html
Known issues
Here are the changes found in Patchwork_104074v4 that come from known issues:
### CI changes ###
Possible fixes
* boot:
- fi-bxt-dsi: [FAIL][4] ([i915#6003]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/fi-bxt-dsi/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/fi-bxt-dsi/boot.html
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-hsw-4770:NOTRUN -> [SKIP][6] ([fdo#109271]) +9 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/fi-hsw-4770/igt@gem_huc_c...@huc-copy.html
- fi-bxt-dsi: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@verify-random:
- fi-bxt-dsi: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/fi-bxt-dsi/igt@gem_lmem_swapp...@verify-random.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#3012])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@gem:
- fi-blb-e6850: NOTRUN -> [DMESG-FAIL][10] ([i915#4528])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/fi-blb-e6850/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [PASS][11] -> [INCOMPLETE][12] ([i915#4418])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[PASS][13] -> [DMESG-FAIL][14] ([i915#4528])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-kbl-soraka: [PASS][15] -> [DMESG-WARN][16] ([i915#1982])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/fi-kbl-soraka/igt@i915_susp...@basic-s2idle-without-i915.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/fi-kbl-soraka/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][17] -> [DMESG-WARN][18] ([i915#3576])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11694/bat-adlp-4/igt@kms_busy@ba...@flip.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/bat-adlp-4/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bxt-dsi: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +8
similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v4/fi-bxt-dsi/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-hsw-4770:NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) +8
similar issues
[20]:
Re: [Intel-gfx] [PATCH] drm/i915/dg2: Catch and log more unexpected values in DG1_MSTR_TILE_INTR
On Tue, May 24, 2022 at 10:43:39AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Catch and log any garbage in the register, including no tiles marked, or
> multiple tiles marked.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Matt Roper
> ---
> We caught garbage in DG1_MSTR_TILE_INTR with DG2 (actual value 0xF9D2C008)
> during glmark and more badness. So I thought lets log all possible failure
> modes from here and also use per device logging.
> ---
> drivers/gpu/drm/i915/i915_irq.c | 33 ++---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 73cebc6aa650..79853d3fc1ed 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2778,24 +2778,30 @@ static irqreturn_t dg1_irq_handler(int irq, void *arg)
> u32 gu_misc_iir;
>
> if (!intel_irqs_enabled(i915))
> - return IRQ_NONE;
> + goto none;
>
> master_tile_ctl = dg1_master_intr_disable(regs);
> - if (!master_tile_ctl) {
> - dg1_master_intr_enable(regs);
> - return IRQ_NONE;
> + if (!master_tile_ctl)
> + goto enable_none;
> +
> + if (master_tile_ctl & ~(DG1_MSTR_IRQ | DG1_MSTR_TILE_MASK)) {
> + drm_warn(>drm, "Garbage in master_tile_ctl: 0x%08x!\n",
> + master_tile_ctl);
I know we have a bunch of them already, but shouldn't we be avoiding
printk-based stuff like this inside interrupt handlers? Should we be
migrating all these error messages over to trace_printk or something
similar that's safer to use?
Matt
> + goto enable_none;
> }
>
> /* FIXME: we only support tile 0 for now. */
> - if (master_tile_ctl & DG1_MSTR_TILE(0)) {
> - master_ctl = raw_reg_read(regs, GEN11_GFX_MSTR_IRQ);
> - raw_reg_write(regs, GEN11_GFX_MSTR_IRQ, master_ctl);
> - } else {
> - DRM_ERROR("Tile not supported: 0x%08x\n", master_tile_ctl);
> - dg1_master_intr_enable(regs);
> - return IRQ_NONE;
> + if (REG_FIELD_GET(DG1_MSTR_TILE_MASK, master_tile_ctl) !=
> + DG1_MSTR_TILE(0)) {
> + drm_warn(>drm, "Unexpected irq from tile %u!\n",
> + ilog2(REG_FIELD_GET(DG1_MSTR_TILE_MASK,
> + master_tile_ctl)));
> + goto enable_none;
> }
>
> + master_ctl = raw_reg_read(regs, GEN11_GFX_MSTR_IRQ);
> + raw_reg_write(regs, GEN11_GFX_MSTR_IRQ, master_ctl);
> +
> gen11_gt_irq_handler(gt, master_ctl);
>
> if (master_ctl & GEN11_DISPLAY_IRQ)
> @@ -2810,6 +2816,11 @@ static irqreturn_t dg1_irq_handler(int irq, void *arg)
> pmu_irq_stats(i915, IRQ_HANDLED);
>
> return IRQ_HANDLED;
> +
> +enable_none:
> + dg1_master_intr_enable(regs);
> +none:
> + return IRQ_NONE;
> }
>
> /* Called from drm generic code, passed 'crtc' which
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index d8579ab9384c..eefa301c6430 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5774,6 +5774,7 @@
>
> #define DG1_MSTR_TILE_INTR _MMIO(0x190008)
> #define DG1_MSTR_IRQ REG_BIT(31)
> +#define DG1_MSTR_TILE_MASK REG_GENMASK(3, 0)
> #define DG1_MSTR_TILE(t) REG_BIT(t)
>
> #define GEN11_DISPLAY_INT_CTL_MMIO(0x44200)
> --
> 2.32.0
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915/uncore: Reorganize and document shadow and forcewake tables
On Tue, May 10, 2022 at 11:02:24PM -0700, Matt Roper wrote:
> Let's reorganize some of the forcewake/shadow handling in intel_uncore.c
> and consolidate the cargo-cult comments on each table into more general
> comments that apply to all tables.
>
> We'll probably move forcewake handling to its own dedicated file in the
> near future and further enhance this with true kerneldoc. But this is a
> good intermediate step to help clarify the behavior a bit.
>
> Cc: Stuart Summers
Reviewed-by: Matt Atwood
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 125 ++--
> 1 file changed, 80 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 83517a703eb6..095e071e4053 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -938,36 +938,32 @@ find_fw_domain(struct intel_uncore *uncore, u32 offset)
> return entry->domains;
> }
>
> -#define GEN_FW_RANGE(s, e, d) \
> - { .start = (s), .end = (e), .domains = (d) }
> -
> -/* *Must* be sorted by offset ranges! See intel_fw_table_check(). */
> -static const struct intel_forcewake_range __vlv_fw_ranges[] = {
> - GEN_FW_RANGE(0x2000, 0x3fff, FORCEWAKE_RENDER),
> - GEN_FW_RANGE(0x5000, 0x7fff, FORCEWAKE_RENDER),
> - GEN_FW_RANGE(0xb000, 0x11fff, FORCEWAKE_RENDER),
> - GEN_FW_RANGE(0x12000, 0x13fff, FORCEWAKE_MEDIA),
> - GEN_FW_RANGE(0x22000, 0x23fff, FORCEWAKE_MEDIA),
> - GEN_FW_RANGE(0x2e000, 0x2, FORCEWAKE_RENDER),
> - GEN_FW_RANGE(0x3, 0x3, FORCEWAKE_MEDIA),
> -};
> -
> -#define __fwtable_reg_read_fw_domains(uncore, offset) \
> -({ \
> - enum forcewake_domains __fwd = 0; \
> - if (NEEDS_FORCE_WAKE((offset))) \
> - __fwd = find_fw_domain(uncore, offset); \
> - __fwd; \
> -})
> +/*
> + * Shadowed register tables describe special register ranges that i915 is
> + * allowed to write to without acquiring forcewake. If these registers'
> power
> + * wells are down, the hardware will save values written by i915 to a shadow
> + * copy and automatically transfer them into the real register the next time
> + * the power well is woken up. Shadowing only applies to writes; forcewake
> + * must still be acquired when reading from registers in these ranges.
> + *
> + * The documentation for shadowed registers is somewhat spotty on older
> + * platforms. However missing registers from these lists is non-fatal; it
> just
> + * means we'll wake up the hardware for some register accesses where we
> didn't
> + * really need to.
> + *
> + * The ranges listed in these tables must be sorted by offset.
> + *
> + * When adding new tables here, please also add them to
> + * intel_shadow_table_check() in selftests/intel_uncore.c so that they will
> be
> + * scanned for obvious mistakes or typos by the selftests.
> + */
>
> -/* *Must* be sorted by offset! See intel_shadow_table_check(). */
> static const struct i915_range gen8_shadowed_regs[] = {
> { .start = 0x2030, .end = 0x2030 },
> { .start = 0xA008, .end = 0xA00C },
> { .start = 0x12030, .end = 0x12030 },
> { .start = 0x1a030, .end = 0x1a030 },
> { .start = 0x22030, .end = 0x22030 },
> - /* TODO: Other registers are not yet used */
> };
>
> static const struct i915_range gen11_shadowed_regs[] = {
> @@ -1107,11 +1103,71 @@ gen6_reg_write_fw_domains(struct intel_uncore
> *uncore, i915_reg_t reg)
> return FORCEWAKE_RENDER;
> }
>
> +#define __fwtable_reg_read_fw_domains(uncore, offset) \
> +({ \
> + enum forcewake_domains __fwd = 0; \
> + if (NEEDS_FORCE_WAKE((offset))) \
> + __fwd = find_fw_domain(uncore, offset); \
> + __fwd; \
> +})
> +
> +#define __fwtable_reg_write_fw_domains(uncore, offset) \
> +({ \
> + enum forcewake_domains __fwd = 0; \
> + const u32 __offset = (offset); \
> + if (NEEDS_FORCE_WAKE((__offset)) && !is_shadowed(uncore, __offset)) \
> + __fwd = find_fw_domain(uncore, __offset); \
> + __fwd; \
> +})
> +
> +#define GEN_FW_RANGE(s, e, d) \
> + { .start = (s), .end = (e), .domains = (d) }
> +
> +/*
> + * All platforms' forcewake tables below must be sorted by offset ranges.
> + * Furthermore, new forcewake tables added should be "watertight" and have
> + * no gaps between ranges.
> + *
> + * When there are multiple consecutive ranges listed in the bspec with
> + * the same forcewake domain, it is customary to combine them into a single
> + * row in the tables below to keep the tables small and lookups fast.
> + * Likewise, reserved/unused ranges may be combined with the preceding and/or
> + * following ranges since the driver will never be making MMIO accesses in
> + * those ranges.
> + *
> + * For example, if the bspec were to list:
> + *
> + *...
> + *0x1000 - 0x1fff: GT
> + *0x2000 - 0x2cff: GT
> + *0x2d00 - 0x2fff: unused/reserved
> + *
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for i915: SSEU handling updates (rev2)
CI: boot test failure seems to fail always in the same manner. https://gitlab.freedesktop.org/drm/intel/-/issues/6074 BDW: CI:Boot - fail - No warnings/errors I believe the shards failures is unrelated (as there no logs) to this patch. So I created a generic bug for GEN9 to track of failures that doesn't have logs. This bug will be reviewed weekly by the team. https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl3/igt@i915_selftest@l...@dmabuf.html https://gitlab.freedesktop.org/drm/intel/-/issues/6075 Thanks, Lakshmi. -Original Message- From: Roper, Matthew D Sent: Monday, May 23, 2022 4:32 PM To: intel-gfx@lists.freedesktop.org Cc: Vudum, Lakshminarayana Subject: Re: ✗ Fi.CI.BAT: failure for i915: SSEU handling updates (rev2) On Mon, May 23, 2022 at 09:23:33PM +, Patchwork wrote: > == Series Details == > > Series: i915: SSEU handling updates (rev2) > URL : https://patchwork.freedesktop.org/series/104244/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_11693 -> Patchwork_104244v2 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_104244v2 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_104244v2, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/index.html > > Participating hosts (44 -> 45) > -- > > Additional (2): fi-icl-u2 fi-tgl-u2 > Missing(1): fi-hsw-4770 > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_104244v2: > > ### CI changes ### > > Possible regressions > > * boot: > - fi-bdw-5557u: [PASS][1] -> [FAIL][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-bdw-5557u/boot.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-bdw-555 > 7u/boot.html I don't see a boot failure here? It looks like i915 loaded successfully, without errors. It also looks like more tests ran successfully on the machine after that as well. Matt > > > Known issues > > > Here are the changes found in Patchwork_104244v2 that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_gttfill@basic: > - fi-icl-u2: NOTRUN -> [INCOMPLETE][3] ([i915#4890]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-icl-u2/ > igt@gem_exec_gttf...@basic.html > > * igt@gem_huc_copy@huc-copy: > - fi-tgl-u2: NOTRUN -> [SKIP][4] ([i915#2190]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/ > igt@gem_huc_c...@huc-copy.html > > * igt@i915_selftest@live@hangcheck: > - bat-dg1-6: [PASS][5] -> [DMESG-FAIL][6] ([i915#4494] / > [i915#4957]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html > - fi-snb-2600:[PASS][7] -> [INCOMPLETE][8] ([i915#3921]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-snb-260 > 0/igt@i915_selftest@l...@hangcheck.html > > * igt@kms_busy@basic@flip: > - fi-tgl-u2: NOTRUN -> [DMESG-WARN][9] ([i915#402]) +3 similar > issues >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/ > igt@kms_busy@ba...@flip.html > > * igt@kms_chamelium@dp-hpd-fast: > - fi-tgl-u2: NOTRUN -> [SKIP][10] ([fdo#109284] / [fdo#111827]) > +7 similar issues >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/ > igt@kms_chamel...@dp-hpd-fast.html > > * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: > - fi-tgl-u2: NOTRUN -> [SKIP][11] ([i915#4103]) +1 similar issue >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/ > igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html > > * igt@kms_flip@basic-flip-vs-modeset@b-edp1: > - bat-adlp-4: [PASS][12] -> [DMESG-WARN][13] ([i915#3576]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/bat-adlp-4 > /igt@kms_flip@basic-flip-vs-mode...@b-edp1.html > > * igt@kms_force_connector_basic@force-load-detect: > - fi-tgl-u2: NOTRUN -> [SKIP][14] ([fdo#109285]) >
[Intel-gfx] ✓ Fi.CI.IGT: success for i915: SSEU handling updates (rev2)
== Series Details ==
Series: i915: SSEU handling updates (rev2)
URL : https://patchwork.freedesktop.org/series/104244/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11693_full -> Patchwork_104244v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (12 -> 13)
--
Additional (1): shard-rkl
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104244v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_color@pipe-b-deep-color:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-rkl-6/igt@kms_co...@pipe-b-deep-color.html
Known issues
Here are the changes found in Patchwork_104244v2_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-skl: ([PASS][2], [PASS][3], [PASS][4], [PASS][5],
[PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12],
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18],
[PASS][19], [PASS][20], [PASS][21]) -> ([PASS][22], [PASS][23], [PASS][24],
[PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30],
[PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36],
[FAIL][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42],
[PASS][43]) ([i915#5032])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl7/boot.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl6/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl6/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl5/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl5/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl4/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl4/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl2/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl2/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl1/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl1/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl10/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl10/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl10/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl9/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl9/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl8/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl8/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl8/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl7/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl9/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl9/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl9/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl9/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl8/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl8/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl8/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl7/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl7/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl6/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl6/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl4/boot.html
[34]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl4/boot.html
[35]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl3/boot.html
[36]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl3/boot.html
[37]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl3/boot.html
[38]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl2/boot.html
[39]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl2/boot.html
[40]:
Re: [Intel-gfx] [PATCH v1 2/2] drm/i915: Reject the atomic modeset if an associated Type-C port is disconnected
On Tue, May 24, 2022 at 11:29:54AM +0300, Kasireddy, Vivek wrote: > Hi Imre, > > > On Fri, May 20, 2022 at 10:28:31AM +0300, Kasireddy, Vivek wrote: > > > Hi Imre, > > > [...] > > > > > > > @@ -131,6 +137,20 @@ int > > > > > > > intel_digital_connector_atomic_check(struct > > drm_connector *conn, > > > > > > > > > > > > > > crtc_state = drm_atomic_get_new_crtc_state(state, > > > > > > > new_state->crtc); > > > > > > > > > > > > > > + /* > > > > > > > + * The spec says that it is not safe to use a disconnected > > > > > > > Type-C port. > > > > > > > + * Therefore, check to see if this connector is connected and > > > > > > > reject > > > > > > > + * the modeset if there is no sink detected. > > > > > > > + */ > > > > > > > + if (dig_port && !dig_port->connected(encoder) && > > > > > > > > > > > > This check is racy, as right after dig_port->connected() returns > > > > > > true, > > > > > > the port can become disconnected. > > > > > > > > > > [Kasireddy, Vivek] Given that, do you think the only way to reliably > > > > > determine > > > > > if the Type-C port has a sink is to check the live status and ignore > > > > > dig_port- > > >tc_mode? > > > > > > > > > > If that is the case, should I just add a function pointer to dig_port > > > > > to call > > > > > tc_port_live_status_mask()? Or, should I just change > > > > > intel_tc_port_connected() > > > > > to ignore dig_port->tc_mode like below: > > > > > @@ -764,8 +764,7 @@ bool intel_tc_port_connected(struct intel_encoder > > *encoder) > > > > > > > > > > intel_tc_port_lock(dig_port); > > > > > > > > > > - is_connected = tc_port_live_status_mask(dig_port) & > > > > > - BIT(dig_port->tc_mode); > > > > > + is_connected = tc_port_live_status_mask(dig_port); > > > > > > > > > > Or, are there any other elegant ways that you can think of to > > > > > determine whether > > > > > a tc port has a sink or not? > > > > > > > > I meant that I don't think there is a way to prevent a modeset on a > > > > disconnected port. > > > > > > But we need to find a way right given that the spec clearly states that > > > the driver > > > must not use or access (PHY/FIA registers of) a disconnected tc port. > > > > The driver does not access the PHY/FIA regs on a disconnected port/PHY. > > [Kasireddy, Vivek] I think it does after the first patch in this series is > applied if > the userspace (Weston) forces a modeset on a disconnected tc legacy port > (HDMI). > For instance, some of the FIA/PHY regs accesses I noticed include programming > the lane count (intel_tc_port_set_fia_lane_count() called by > intel_ddi_pre_pll_enable()), > reading the pin assignment mask (intel_tc_port_get_pin_assignment_mask() > called > by icl_program_mg_dp_mode() which is called by intel_ddi_pre_enable_hdmi()), > etc. The FW/HW will setup a legacy TC port's PHY once during system boot and resume, so I don't see any problem modesetting those later, regardless of a sink being plugged on them or not. We need the first patch which fixes a bug selecting the wrong PLL. > Of-course, these accesses would probably not occur if the disconnected tc port > defaults to TBT mode but this brings other problems like I described in the > commit description of the first patch and the cover letter. > > > > > Live status is what provides the connected state, but > > > > it can change right after it is read out. > > > > > > Does this change happen after giving up the ownership (in > > > icl_tc_phy_disconnect)? > > > > The HPD live status changes whenever a user plugs/unplugs a sink. > > > > > But shouldn't we distinguish between the cases where we are > > > deliberately disconnecting the phy for power-savings reason vs when > > > the port actually becomes disconnected? The port can still be > > > considered connected in the former case right? > > > > The driver - based on the spec - needs to avoid accessing the PHY/FIA > > regs whenever the PHY is disconnected either by FW/HW (because the user > > unplugged the sink) or the driver (during the suspend, modeset disable > > sequence). > > [Kasireddy, Vivek] Regardless of whether the PHY/FIA regs are accessed or > not, I don't think the driver should let the userspace's modeset to succeed on > a disconnected tc port. Do you not agree? I don't think a modeset can or should be prevented if the user unplugs a monitor midway. > > > Under what other situations would the live status change or become > > > unreliable after the port has a connected sink? > > > > It's not unreliable, it reflects the state of a sink being plugged to > > the connector or not. > > [Kasireddy, Vivek] Ok, assuming that the state of the sink is "connected" > during intel_atomic_check() phase (which is where this patch checks for > connected status), are you concerned about the case where the user may > unplug the sink before we get to the intel_atomic_commit() phase? Is > this what you meant when you said this earlier: "This check is
Re: [Intel-gfx] [PATCH v3 0/1] vfio: remove VFIO_GROUP_NOTIFY_SET_KVM
On Thu, 19 May 2022 14:33:10 -0400
Matthew Rosato wrote:
> As discussed in this thread:
>
> https://lore.kernel.org/kvm/20220516172734.ge1343...@nvidia.com/
>
> Let's remove VFIO_GROUP_NOTIFY_SET_KVM and instead assume the association
> has already been established prior to device_open. For the types today
> that need a KVM (GVT, vfio-ap) these will fail if a KVM is not found.
> Looking ahead, vfio-pci-zdev will optionally want the KVM association
> (enable hardware assists) but it will not be a hard requirement (still
> want to allow other, non-KVM userspace usage).
>
> This is built on top of vfio-next and tested with s390x-pci
> (zdev-kvm series) and vfio-ap (GVT changes are compile-tested only)
>
> Changes for v3:
> - merge branches under if (device->open_count == 1) (Kevin)
> - move device->open_count-- out from group_rwsem (Kevin)
> - drop null KVM check (Christoph)
> - remove extra kvm_{get,put}_kvm from vfio_ap_ops, it was already getting
> a reference (Jason)
> - Add comment about kvm reference in vfio.h (Jason)
> - Return -EINVAL if !kvm for vfio-ap (Tony)
>
> Changes for v2:
> - gvt no longer needs release_work, get rid of it (Christoph)
> - a few compile fixes for gvt
> - update commit to mention fixes gvt oops (Jason)
> - s/down_write/down_read/ in a few spots (Jason)
> - avoid kvm build dependency by holding group read lock over device
> open/close and put the onus on the driver to obtain a reference if
> it will actually use the kvm pointer. Document the requirement,
> use lockdep_assert to ensure lock is held during register_notifer;
> today all callers are from driver open_device.
>
> Matthew Rosato (1):
> vfio: remove VFIO_GROUP_NOTIFY_SET_KVM
>
> drivers/gpu/drm/i915/gvt/gtt.c| 4 +-
> drivers/gpu/drm/i915/gvt/gvt.h| 3 -
> drivers/gpu/drm/i915/gvt/kvmgt.c | 82 ++
> drivers/s390/crypto/vfio_ap_ops.c | 35 ++-
> drivers/s390/crypto/vfio_ap_private.h | 3 -
> drivers/vfio/vfio.c | 83 ++-
> include/linux/vfio.h | 6 +-
> 7 files changed, 57 insertions(+), 159 deletions(-)
Applied to vfio next branch for v5.19. Thanks,
Alex
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/edid: expand on struct drm_edid usage (rev2)
== Series Details == Series: drm/edid: expand on struct drm_edid usage (rev2) URL : https://patchwork.freedesktop.org/series/104309/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/edid: expand on struct drm_edid usage (rev2)
== Series Details == Series: drm/edid: expand on struct drm_edid usage (rev2) URL : https://patchwork.freedesktop.org/series/104309/ State : warning == Summary == Error: dim checkpatch failed 7612cb14248e drm/edid: add block count and data helper functions for drm_edid 9eeec287d5f2 drm/edid: keep track of alloc size in drm_do_get_edid() c7dcec98a0cc drm/edid: add new interfaces around struct drm_edid -:320: WARNING:LONG_LINE: line length of 118 exceeds 100 columns #320: FILE: include/drm/drm_edid.h:591: + int (*read_block)(void *context, u8 *buf, unsigned int block, size_t len), total: 0 errors, 1 warnings, 0 checks, 291 lines checked 91a306b9cb2d drm/edid: add drm_edid_connector_update() 087ad6784c6b drm/probe-helper: abstract .get_modes() connector helper call fbea584d2418 drm/probe-helper: make .get_modes() optional, add default action 07140404e28d drm/probe-helper: add .get_edid() callback 44318f22ac06 drm/edid: add drm_edid_raw() to access the raw EDID data 6f596216ec50 drm/i915/edid: convert DP, HDMI and LVDS to drm_edid -:256: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "drm_edid" #256: FILE: drivers/gpu/drm/i915/display/intel_hdmi.c:2429: + intel_hdmi_dp_dual_mode_detect(connector, drm_edid != NULL); total: 0 errors, 0 warnings, 1 checks, 300 lines checked 566ed1f89cfc drm/edid: do invalid block filtering in-place fafa54709930 drm/edid: add HF-EEODB support to EDID read and allocation 0681dc768b5c drm/edid: take HF-EEODB extension count into account 83df341dc8d8 drm/todo: add entry for converting the subsystem to struct drm_edid
Re: [Intel-gfx] linux-next: Tree for May 24 (drivers/gpu/drm/i915/display/intel_backlight.o)
On 5/24/22 02:26, Stephen Rothwell wrote: > Hi all, > > Note: please do not add any v5.20 material to your linux-next included > branches until after v5.19-rc1 has been related. > > Changes since 20220523: > on i386: drivers/gpu/drm/i915/display/intel_backlight.o: in function `intel_backlight_device_register': intel_backlight.c:(.text+0x301e): undefined reference to `backlight_device_register' ld: intel_backlight.c:(.text+0x3181): undefined reference to `backlight_device_register' ld: drivers/gpu/drm/i915/display/intel_backlight.o: in function `intel_backlight_device_unregister': intel_backlight.c:(.text+0x31c9): undefined reference to `backlight_device_unregister' CONFIG_DRM_I915=y CONFIG_BACKLIGHT_CLASS_DEVICE=m Full randconfig file is attached. -- ~Randy config-i915-backlight.gz Description: application/gzip
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Media freq factor and per-gt enhancements/fixes (rev8)
== Series Details == Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev8) URL : https://patchwork.freedesktop.org/series/102665/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave & Daniel - Some i915 fixes for v5.19 merge window. drm-intel-next-fixes-2022-05-24: drm/i915 fixes for v5.19 merge window: - Build, sparse, UB, and CFI fixes - Variable scope fix - Audio pipe logging fix - ICL+ DSI NULL dereference fix BR, Jani. The following changes since commit f83493f7d34da258310ecd3d07f0cc78f884c954: Merge tag 'drm-msm-next-2022-05-09' of https://gitlab.freedesktop.org/drm/msm into drm-next (2022-05-11 12:40:47 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2022-05-24 for you to fetch changes up to 0ea917819d12fed41ea4662cc26ffa0060a5c354: drm/i915/dsi: fix VBT send packet port selection for ICL+ (2022-05-23 12:08:58 +0300) drm/i915 fixes for v5.19 merge window: - Build, sparse, UB, and CFI fixes - Variable scope fix - Audio pipe logging fix - ICL+ DSI NULL dereference fix Andi Shyti (1): drm/i915/gt: Fix use of static in macro mismatch Borislav Petkov (1): drm/i915/uc: Fix undefined behavior due to shift overflowing the constant Imre Deak (1): drm/i915: Fix 'mixing different enum types' warnings in intel_display_power.c Jani Nikula (3): drm/i915/audio: fix audio code enable/disable pipe logging drm/i915/reg: fix undefined behavior due to shift overflowing the constant drm/i915/dsi: fix VBT send packet port selection for ICL+ Nathan Chancellor (1): drm/i915: Fix CFI violation with show_dynamic_id() YueHaibing (1): drm/i915/gt: Fix build error without CONFIG_PM drivers/gpu/drm/i915/display/intel_audio.c | 4 +-- drivers/gpu/drm/i915/display/intel_display_power.c | 8 +++--- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 33 ++ drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c| 23 +++ drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 2 +- .../drm/i915/gt/uc/abi/guc_communication_ctb_abi.h | 2 +- drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 2 +- drivers/gpu/drm/i915/i915_perf.c | 4 +-- drivers/gpu/drm/i915/i915_perf_types.h | 2 +- drivers/gpu/drm/i915/i915_reg.h| 32 ++--- 11 files changed, 63 insertions(+), 51 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v1 01/13] drm/edid: add block count and data helper functions for drm_edid
On Tue, 24 May 2022, Andrzej Hajda wrote:
> On 24.05.2022 12:39, Jani Nikula wrote:
>> Add drm_edid based block count and data access helper functions that
>> take the EDID allocated size into account.
>>
>> At the moment, the allocated size should always match the EDID size
>> indicated by the extension count, but this will change in the future.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_edid.c | 42 +++---
>> 1 file changed, 35 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 929fc0e46751..682d954a9e42 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -1613,6 +1613,35 @@ static const void *edid_extension_block_data(const
>> struct edid *edid, int index)
>> return edid_block_data(edid, index + 1);
>> }
>>
>> +static int drm_edid_block_count(const struct drm_edid *drm_edid)
>> +{
>> +int num_blocks;
>> +
>> +/* Starting point */
>> +num_blocks = edid_block_count(drm_edid->edid);
>> +
>> +/* Limit by allocated size */
>> +num_blocks = min(num_blocks, (int)drm_edid->size / EDID_LENGTH);
>> +
>> +return num_blocks;
>> +}
>> +
>> +static int drm_edid_extension_block_count(const struct drm_edid *drm_edid)
>> +{
>> +return drm_edid_block_count(drm_edid) - 1;
>> +}
>> +
>> +static const void *drm_edid_block_data(const struct drm_edid *drm_edid, int
>> index)
>> +{
>> +return edid_block_data(drm_edid->edid, index);
>> +}
>> +
>> +static const void *drm_edid_extension_block_data(const struct drm_edid
>> *drm_edid,
>> + int index)
>> +{
>> +return edid_extension_block_data(drm_edid->edid, index);
>> +}
>> +
>> /*
>>* Initializer helper for legacy interfaces, where we have no choice but to
>>* trust edid size. Not for general purpose use.
>> @@ -1665,8 +1694,8 @@ static const void *__drm_edid_iter_next(struct
>> drm_edid_iter *iter)
>> if (!iter->drm_edid)
>> return NULL;
>>
>> -if (iter->index < edid_block_count(iter->drm_edid->edid))
>> -block = edid_block_data(iter->drm_edid->edid, iter->index++);
>> +if (iter->index < drm_edid_block_count(iter->drm_edid))
>> +block = drm_edid_block_data(iter->drm_edid, iter->index++);
>>
>> return block;
>> }
>> @@ -3574,22 +3603,21 @@ static int add_detailed_modes(struct drm_connector
>> *connector,
>> const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
>>int ext_id, int *ext_index)
>> {
>> -const struct edid *edid = drm_edid ? drm_edid->edid : NULL;
>
> Do we still need this var?
I am removing it...?
>
>
>> const u8 *edid_ext = NULL;
>> int i;
>>
>> /* No EDID or EDID extensions */
>> -if (!edid || !edid_extension_block_count(edid))
>> +if (!drm_edid || !drm_edid_extension_block_count(drm_edid))
>> return NULL;
>>
>> /* Find CEA extension */
>> -for (i = *ext_index; i < edid_extension_block_count(edid); i++) {
>> -edid_ext = edid_extension_block_data(edid, i);
>> +for (i = *ext_index; i < drm_edid_extension_block_count(drm_edid); i++)
>> {
>> +edid_ext = drm_edid_extension_block_data(drm_edid, i);
>> if (edid_block_tag(edid_ext) == ext_id)
>> break;
>> }
>>
>> -if (i >= edid_extension_block_count(edid))
>> +if (i >= drm_edid_extension_block_count(drm_edid))
>> return NULL;
>>
>> *ext_index = i + 1;
>
> It looks OK. Some suggestions to consider:
> 1. While at it, refactor little bit the code to return ext from 'for'
> loop and NULL later (to kill after-loop checks, and better code IMO).
> 2. Implement kind of iterator, for example
> drm_edid_extension_block_next(drm_edid, edid_ext), then use loop:
> for (edid_ext = NULL; edid_ext = drm_edid_extension_block_next(drm_edid,
> edid_ext;)
> ...
>
> Up to you.
> Reviewed-by: Andrzej Hajda
There's already the struct drm_edid_iter stuff that this could be
converted to, but just haven't gotten around to it yet. I'll follow up
with that later. Thanks for the review.
BR,
Jani.
>
> Regards
> Andrzej
>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v1 01/13] drm/edid: add block count and data helper functions for drm_edid
On 24.05.2022 12:39, Jani Nikula wrote:
Add drm_edid based block count and data access helper functions that
take the EDID allocated size into account.
At the moment, the allocated size should always match the EDID size
indicated by the extension count, but this will change in the future.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 42 +++---
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 929fc0e46751..682d954a9e42 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1613,6 +1613,35 @@ static const void *edid_extension_block_data(const
struct edid *edid, int index)
return edid_block_data(edid, index + 1);
}
+static int drm_edid_block_count(const struct drm_edid *drm_edid)
+{
+ int num_blocks;
+
+ /* Starting point */
+ num_blocks = edid_block_count(drm_edid->edid);
+
+ /* Limit by allocated size */
+ num_blocks = min(num_blocks, (int)drm_edid->size / EDID_LENGTH);
+
+ return num_blocks;
+}
+
+static int drm_edid_extension_block_count(const struct drm_edid *drm_edid)
+{
+ return drm_edid_block_count(drm_edid) - 1;
+}
+
+static const void *drm_edid_block_data(const struct drm_edid *drm_edid, int
index)
+{
+ return edid_block_data(drm_edid->edid, index);
+}
+
+static const void *drm_edid_extension_block_data(const struct drm_edid
*drm_edid,
+int index)
+{
+ return edid_extension_block_data(drm_edid->edid, index);
+}
+
/*
* Initializer helper for legacy interfaces, where we have no choice but to
* trust edid size. Not for general purpose use.
@@ -1665,8 +1694,8 @@ static const void *__drm_edid_iter_next(struct
drm_edid_iter *iter)
if (!iter->drm_edid)
return NULL;
- if (iter->index < edid_block_count(iter->drm_edid->edid))
- block = edid_block_data(iter->drm_edid->edid, iter->index++);
+ if (iter->index < drm_edid_block_count(iter->drm_edid))
+ block = drm_edid_block_data(iter->drm_edid, iter->index++);
return block;
}
@@ -3574,22 +3603,21 @@ static int add_detailed_modes(struct drm_connector
*connector,
const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
int ext_id, int *ext_index)
{
- const struct edid *edid = drm_edid ? drm_edid->edid : NULL;
Do we still need this var?
const u8 *edid_ext = NULL;
int i;
/* No EDID or EDID extensions */
- if (!edid || !edid_extension_block_count(edid))
+ if (!drm_edid || !drm_edid_extension_block_count(drm_edid))
return NULL;
/* Find CEA extension */
- for (i = *ext_index; i < edid_extension_block_count(edid); i++) {
- edid_ext = edid_extension_block_data(edid, i);
+ for (i = *ext_index; i < drm_edid_extension_block_count(drm_edid); i++)
{
+ edid_ext = drm_edid_extension_block_data(drm_edid, i);
if (edid_block_tag(edid_ext) == ext_id)
break;
}
- if (i >= edid_extension_block_count(edid))
+ if (i >= drm_edid_extension_block_count(drm_edid))
return NULL;
*ext_index = i + 1;
It looks OK. Some suggestions to consider:
1. While at it, refactor little bit the code to return ext from 'for'
loop and NULL later (to kill after-loop checks, and better code IMO).
2. Implement kind of iterator, for example
drm_edid_extension_block_next(drm_edid, edid_ext), then use loop:
for (edid_ext = NULL; edid_ext = drm_edid_extension_block_next(drm_edid,
edid_ext;)
...
Up to you.
Reviewed-by: Andrzej Hajda
Regards
Andrzej
Re: [Intel-gfx] [PATCH] drm/i915: Update tiled blits selftest
Hi Andrzej,
On 5/24/2022 1:56 PM, Andrzej Hajda wrote:
On 16.05.2022 10:20, Nirmoy Das wrote:
From: Bommu Krishnaiah
Update the selftest to include Tile 4 mode and switch to Tile 4 on
platforms that supports Tile 4 but no Tile Y and vice versa.
Also switch to XY_FAST_COPY_BLT on platforms that supports it.
v4: update commit message to reflect the code changes properly.
v3: add a function to find X-tile availability for a platform.
v2: disable Tile X for iGPU in fastblit and
fix checkpath --strict warnings.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5879
Signed-off-by: Bommu Krishnaiah
Co-developed-by: Nirmoy Das
Signed-off-by: Nirmoy Das
---
.../i915/gem/selftests/i915_gem_client_blt.c | 250 ++
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 22 ++
2 files changed, 227 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index ddd0772fd828..3cfc621ef363 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -6,6 +6,7 @@
#include "i915_selftest.h"
#include "gt/intel_context.h"
+#include "gt/intel_engine_regs.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gpu_commands.h"
#include "gt/intel_gt.h"
@@ -18,10 +19,71 @@
#include "huge_gem_object.h"
#include "mock_context.h"
+#define OW_SIZE 16 /* in bytes */
+#define F_SUBTILE_SIZE 64 /* in bytes */
+#define F_TILE_WIDTH 128 /* in bytes */
+#define F_TILE_HEIGHT 32 /* in pixels */
+#define F_SUBTILE_WIDTH OW_SIZE /* in bytes */
+#define F_SUBTILE_HEIGHT 4 /* in pixels */
+
+static int linear_x_y_to_ftiled_pos(int x, int y, u32 stride, int bpp)
+{
+ int tile_base;
+ int tile_x, tile_y;
+ int swizzle, subtile;
+ int pixel_size = bpp / 8;
+ int pos;
+
+ /*
+ * Subtile remapping for F tile. Note that map[a]==b implies
map[b]==a
+ * so we can use the same table to tile and until.
+ */
+ static const u8 f_subtile_map[] = {
+ 0, 1, 2, 3, 8, 9, 10, 11,
+ 4, 5, 6, 7, 12, 13, 14, 15,
+ 16, 17, 18, 19, 24, 25, 26, 27,
+ 20, 21, 22, 23, 28, 29, 30, 31,
+ 32, 33, 34, 35, 40, 41, 42, 43,
+ 36, 37, 38, 39, 44, 45, 46, 47,
+ 48, 49, 50, 51, 56, 57, 58, 59,
+ 52, 53, 54, 55, 60, 61, 62, 63
+ };
f_subtile_map[i] == (i with swapped bits 2,3)
This is looks neat but can't think of any nice C expression either.
but I do not know if there is nice C expression/core function to use
here,
(i & ^12u) | (( i & 4) << 1) | ((i & 8) >> 1)
does not looks nice.
+
+ x *= pixel_size;
+ /*
+ * Where does the 4k tile start (in bytes)? This is the same
for Y and
+ * F so we can use the Y-tile algorithm to get to that point.
+ */
+ tile_base =
+ y / F_TILE_HEIGHT * stride * F_TILE_HEIGHT +
+ x / F_TILE_WIDTH * 4096;
+
+ /* Find pixel within tile */
+ tile_x = x % F_TILE_WIDTH;
+ tile_y = y % F_TILE_HEIGHT;
+
+ /* And figure out the subtile within the 4k tile */
+ subtile = tile_y / F_SUBTILE_HEIGHT * 8 + tile_x / F_SUBTILE_WIDTH;
+
+ /* Swizzle the subtile number according to the bspec diagram */
+ swizzle = f_subtile_map[subtile];
+
+ /* Calculate new position */
+ pos = tile_base +
+ swizzle * F_SUBTILE_SIZE +
+ tile_y % F_SUBTILE_HEIGHT * OW_SIZE +
+ tile_x % F_SUBTILE_WIDTH;
+
+ GEM_BUG_ON(!IS_ALIGNED(pos, pixel_size));
+
+ return pos / pixel_size * 4;
+}
+
enum client_tiling {
CLIENT_TILING_LINEAR,
CLIENT_TILING_X,
CLIENT_TILING_Y,
+ CLIENT_TILING_4,
CLIENT_NUM_TILING_TYPES
};
@@ -45,6 +107,36 @@ struct tiled_blits {
u32 height;
};
+static bool supports_x_tiling(const struct drm_i915_private *i915)
+{
+ int gen = GRAPHICS_VER(i915);
+
+ if (gen < 12)
+ return true;
Why gen variable? you can use expression directly.
Oversight from my side :/ Matt merged this an hour ago. I can
post a small patch to fix that up.
Anyway:
Reviewed-by: Andrzej Hajda
Thanks,
Nirmoy
Regards
Andrzej
+
+ if (!HAS_LMEM(i915) || IS_DG1(i915))
+ return false;
+
+ return true;
+}
+
+static bool fast_blit_ok(const struct blit_buffer *buf)
+{
+ int gen = GRAPHICS_VER(buf->vma->vm->i915);
+
+ if (gen < 9)
+ return false;
+
+ if (gen < 12)
+ return true;
+
+ /* filter out platforms with unsupported X-tile support in
fastblit */
+ if (buf->tiling == CLIENT_TILING_X &&
!supports_x_tiling(buf->vma->vm->i915))
+ return false;
+
+ return true;
+}
+
static int prepare_blit(const struct tiled_blits *t,
struct blit_buffer *dst,
struct blit_buffer *src,
@@ -59,51 +151,103 @@ static int prepare_blit(const struct
Re: [Intel-gfx] [PATCH] drm/i915: Update tiled blits selftest
On 16.05.2022 10:20, Nirmoy Das wrote:
From: Bommu Krishnaiah
Update the selftest to include Tile 4 mode and switch to Tile 4 on
platforms that supports Tile 4 but no Tile Y and vice versa.
Also switch to XY_FAST_COPY_BLT on platforms that supports it.
v4: update commit message to reflect the code changes properly.
v3: add a function to find X-tile availability for a platform.
v2: disable Tile X for iGPU in fastblit and
fix checkpath --strict warnings.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5879
Signed-off-by: Bommu Krishnaiah
Co-developed-by: Nirmoy Das
Signed-off-by: Nirmoy Das
---
.../i915/gem/selftests/i915_gem_client_blt.c | 250 ++
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 22 ++
2 files changed, 227 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index ddd0772fd828..3cfc621ef363 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -6,6 +6,7 @@
#include "i915_selftest.h"
#include "gt/intel_context.h"
+#include "gt/intel_engine_regs.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gpu_commands.h"
#include "gt/intel_gt.h"
@@ -18,10 +19,71 @@
#include "huge_gem_object.h"
#include "mock_context.h"
+#define OW_SIZE 16 /* in bytes */
+#define F_SUBTILE_SIZE 64 /* in bytes */
+#define F_TILE_WIDTH 128/* in bytes */
+#define F_TILE_HEIGHT 32/* in pixels */
+#define F_SUBTILE_WIDTH OW_SIZE/* in bytes */
+#define F_SUBTILE_HEIGHT 4 /* in pixels */
+
+static int linear_x_y_to_ftiled_pos(int x, int y, u32 stride, int bpp)
+{
+ int tile_base;
+ int tile_x, tile_y;
+ int swizzle, subtile;
+ int pixel_size = bpp / 8;
+ int pos;
+
+ /*
+* Subtile remapping for F tile. Note that map[a]==b implies map[b]==a
+* so we can use the same table to tile and until.
+*/
+ static const u8 f_subtile_map[] = {
+0, 1, 2, 3, 8, 9, 10, 11,
+4, 5, 6, 7, 12, 13, 14, 15,
+ 16, 17, 18, 19, 24, 25, 26, 27,
+ 20, 21, 22, 23, 28, 29, 30, 31,
+ 32, 33, 34, 35, 40, 41, 42, 43,
+ 36, 37, 38, 39, 44, 45, 46, 47,
+ 48, 49, 50, 51, 56, 57, 58, 59,
+ 52, 53, 54, 55, 60, 61, 62, 63
+ };
f_subtile_map[i] == (i with swapped bits 2,3)
but I do not know if there is nice C expression/core function to use here,
(i & ^12u) | (( i & 4) << 1) | ((i & 8) >> 1)
does not looks nice.
+
+ x *= pixel_size;
+ /*
+* Where does the 4k tile start (in bytes)? This is the same for Y and
+* F so we can use the Y-tile algorithm to get to that point.
+*/
+ tile_base =
+ y / F_TILE_HEIGHT * stride * F_TILE_HEIGHT +
+ x / F_TILE_WIDTH * 4096;
+
+ /* Find pixel within tile */
+ tile_x = x % F_TILE_WIDTH;
+ tile_y = y % F_TILE_HEIGHT;
+
+ /* And figure out the subtile within the 4k tile */
+ subtile = tile_y / F_SUBTILE_HEIGHT * 8 + tile_x / F_SUBTILE_WIDTH;
+
+ /* Swizzle the subtile number according to the bspec diagram */
+ swizzle = f_subtile_map[subtile];
+
+ /* Calculate new position */
+ pos = tile_base +
+ swizzle * F_SUBTILE_SIZE +
+ tile_y % F_SUBTILE_HEIGHT * OW_SIZE +
+ tile_x % F_SUBTILE_WIDTH;
+
+ GEM_BUG_ON(!IS_ALIGNED(pos, pixel_size));
+
+ return pos / pixel_size * 4;
+}
+
enum client_tiling {
CLIENT_TILING_LINEAR,
CLIENT_TILING_X,
CLIENT_TILING_Y,
+ CLIENT_TILING_4,
CLIENT_NUM_TILING_TYPES
};
@@ -45,6 +107,36 @@ struct tiled_blits {
u32 height;
};
+static bool supports_x_tiling(const struct drm_i915_private *i915)
+{
+ int gen = GRAPHICS_VER(i915);
+
+ if (gen < 12)
+ return true;
Why gen variable? you can use expression directly.
Anyway:
Reviewed-by: Andrzej Hajda
Regards
Andrzej
+
+ if (!HAS_LMEM(i915) || IS_DG1(i915))
+ return false;
+
+ return true;
+}
+
+static bool fast_blit_ok(const struct blit_buffer *buf)
+{
+ int gen = GRAPHICS_VER(buf->vma->vm->i915);
+
+ if (gen < 9)
+ return false;
+
+ if (gen < 12)
+ return true;
+
+ /* filter out platforms with unsupported X-tile support in fastblit */
+ if (buf->tiling == CLIENT_TILING_X &&
!supports_x_tiling(buf->vma->vm->i915))
+ return false;
+
+ return true;
+}
+
static int prepare_blit(const struct tiled_blits *t,
struct blit_buffer *dst,
struct blit_buffer *src,
@@ -59,51 +151,103 @@ static int prepare_blit(const
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: Catch and log more unexpected values in DG1_MSTR_TILE_INTR
== Series Details ==
Series: drm/i915/dg2: Catch and log more unexpected values in DG1_MSTR_TILE_INTR
URL : https://patchwork.freedesktop.org/series/104305/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11693_full -> Patchwork_104305v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_104305v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_104305v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (12 -> 13)
--
Additional (1): shard-rkl
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104305v1_full:
### IGT changes ###
Possible regressions
* igt@api_intel_allocator@fork-simple-stress-signal:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-tglb1/igt@api_intel_alloca...@fork-simple-stress-signal.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/shard-tglb6/igt@api_intel_alloca...@fork-simple-stress-signal.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_hdr@bpc-switch@pipe-a-hdmi-a-1}:
- {shard-dg1}:NOTRUN -> [SKIP][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/shard-dg1-15/igt@kms_hdr@bpc-swi...@pipe-a-hdmi-a-1.html
Known issues
Here are the changes found in Patchwork_104305v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-2x:
- shard-iclb: NOTRUN -> [SKIP][4] ([i915#1839])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/shard-iclb7/igt@feature_discov...@display-2x.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: NOTRUN -> [FAIL][5] ([i915#2846])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/shard-glk6/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl: [PASS][6] -> [FAIL][7] ([i915#2842])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-apl8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/shard-apl3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-tglb: NOTRUN -> [FAIL][8] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/shard-tglb5/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) +3 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/shard-kbl4/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@gem_exec_flush@basic-batch-kernel-default-uc:
- shard-snb: [PASS][11] -> [SKIP][12] ([fdo#109271]) +4 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-snb2/igt@gem_exec_fl...@basic-batch-kernel-default-uc.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-uc.html
* igt@gem_lmem_swapping@basic:
- shard-tglb: NOTRUN -> [SKIP][13] ([i915#4613])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/shard-tglb5/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@random:
- shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +1
similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/shard-apl1/igt@gem_lmem_swapp...@random.html
* igt@gem_lmem_swapping@verify-random-ccs:
- shard-skl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613]) +3
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/shard-skl2/igt@gem_lmem_swapp...@verify-random-ccs.html
* igt@gem_pxp@create-regular-context-1:
- shard-iclb: NOTRUN -> [SKIP][16] ([i915#4270]) +1 similar issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/shard-iclb7/igt@gem_...@create-regular-context-1.html
* igt@gem_pxp@verify-pxp-stale-buf-optout-execution:
- shard-tglb: NOTRUN -> [SKIP][17] ([i915#4270])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/shard-tglb5/igt@gem_...@verify-pxp-stale-buf-optout-execution.html
* igt@gem_render_copy@yf-tiled-to-vebox-yf-tiled:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#768])
[18]:
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/edid: expand on struct drm_edid usage
> From: Nikula, Jani > > On Tue, 24 May 2022, Patchwork > wrote: > > == Series Details == > > > > Series: drm/edid: expand on struct drm_edid usage > > URL : https://patchwork.freedesktop.org/series/104309/ > > State : failure > > > > == Summary == > > > > > > Possible regressions > > > > * igt@i915_pm_rpm@module-reload: > > - fi-skl-guc: [PASS][1] -> [FAIL][2] > >[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-skl- > guc/igt@i915_pm_...@module-reload.html > >[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-skl- > guc/igt@i915_pm_...@module-reload.html > > Tomi, this link is giving me access denied. Both links work. Patchwork posting is done before results are synced to upstream service. This is noticeable with 404 if the transfer is slow. The issue is known and will be fixed when priorities allow. Tomi > > > > > > Known issues > > > > > > Here are the changes found in Patchwork_104309v1 that come from > known issues: > > > > ### IGT changes ### > > > > Issues hit > > > > * igt@fbdev@write: > > - bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#2582]) +4 similar > > issues > >[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat- > dg1-5/igt@fb...@write.html > > > > * igt@gem_huc_copy@huc-copy: > > - fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#2190]) > >[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-icl- > u2/igt@gem_huc_c...@huc-copy.html > > > > * igt@gem_lmem_swapping@parallel-random-engines: > > - fi-icl-u2: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar > > issues > >[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-icl- > u2/igt@gem_lmem_swapp...@parallel-random-engines.html > > > > * igt@gem_mmap@basic: > > - bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4083]) > >[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat- > dg1-5/igt@gem_m...@basic.html > > > > * igt@gem_tiled_fence_blits@basic: > > - bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#4077]) +2 similar > > issues > >[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat- > dg1-5/igt@gem_tiled_fence_bl...@basic.html > > > > * igt@gem_tiled_pread_basic: > > - bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#4079]) +1 similar issue > >[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat- > dg1-5/igt@gem_tiled_pread_basic.html > > > > * igt@i915_pm_backlight@basic-brightness: > > - bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#1155]) > >[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat- > dg1-5/igt@i915_pm_backli...@basic-brightness.html > > > > * igt@i915_pm_rpm@module-reload: > > - fi-cfl-8109u: [PASS][10] -> [DMESG-WARN][11] ([i915#62]) +16 > > similar > issues > >[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-cfl- > 8109u/igt@i915_pm_...@module-reload.html > >[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-cfl- > 8109u/igt@i915_pm_...@module-reload.html > > > > * igt@i915_selftest@live@hangcheck: > > - bat-dg1-5: NOTRUN -> [DMESG-FAIL][12] ([i915#4494] / > [i915#4957]) > >[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat- > dg1-5/igt@i915_selftest@l...@hangcheck.html > > - bat-dg1-6: [PASS][13] -> [DMESG-FAIL][14] ([i915#4494] / > [i915#4957]) > >[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-dg1- > 6/igt@i915_selftest@l...@hangcheck.html > >[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat- > dg1-6/igt@i915_selftest@l...@hangcheck.html > > - fi-snb-2600:[PASS][15] -> [INCOMPLETE][16] ([i915#3921]) > >[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-snb- > 2600/igt@i915_selftest@l...@hangcheck.html > >[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi- > snb-2600/igt@i915_selftest@l...@hangcheck.html > > > > * igt@i915_selftest@live@late_gt_pm: > > - fi-bsw-nick:[PASS][17] -> [DMESG-FAIL][18] ([i915#3428]) > >[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-bsw- > nick/igt@i915_selftest@live@late_gt_pm.html > >[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi- > bsw-nick/igt@i915_selftest@live@late_gt_pm.html > > > > * igt@i915_suspend@basic-s2idle-without-i915: > > - bat-dg1-5: NOTRUN -> [INCOMPLETE][19] ([i915#6011]) > >[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat- > dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html > > > > * igt@i915_suspend@basic-s3-without-i915: > > - fi-icl-u2: NOTRUN -> [SKIP][20] ([i915#5903]) > >[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-icl- > u2/igt@i915_susp...@basic-s3-without-i915.html > > > > * igt@kms_addfb_basic@basic-y-tiled-legacy: > > - bat-dg1-5:
Re: [Intel-gfx] [PATCH v3 1/1] vfio: remove VFIO_GROUP_NOTIFY_SET_KVM
On 5/23/22 4:41 PM, Alex Williamson wrote:
>
> Hi Zhi & Zhenyu,
>
> Please review gvt changes below, I'd prefer to get your ack included.
> Thanks!
>
> Alex
>
> On Thu, 19 May 2022 14:33:11 -0400
> Matthew Rosato wrote:
>
>> Rather than relying on a notifier for associating the KVM with
>> the group, let's assume that the association has already been
>> made prior to device_open. The first time a device is opened
>> associate the group KVM with the device.
>>
>> This fixes a user-triggerable oops in GVT.
>>
>> Reviewed-by: Tony Krowiak
>> Reviewed-by: Kevin Tian
>> Reviewed-by: Christoph Hellwig
>> Signed-off-by: Jason Gunthorpe
>> Signed-off-by: Matthew Rosato
>> ---
>> drivers/gpu/drm/i915/gvt/gtt.c| 4 +-
>> drivers/gpu/drm/i915/gvt/gvt.h| 3 -
>> drivers/gpu/drm/i915/gvt/kvmgt.c | 82 ++
>> drivers/s390/crypto/vfio_ap_ops.c | 35 ++-
>> drivers/s390/crypto/vfio_ap_private.h | 3 -
>> drivers/vfio/vfio.c | 83 ++-
>> include/linux/vfio.h | 6 +-
>> 7 files changed, 57 insertions(+), 159 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
>> index 9c5cc2800975..b4f69364f9a1 100644
>> --- a/drivers/gpu/drm/i915/gvt/gtt.c
>> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
>> @@ -51,7 +51,7 @@ static int preallocated_oos_pages = 8192;
>>
>> static bool intel_gvt_is_valid_gfn(struct intel_vgpu *vgpu, unsigned long
>> gfn)
>> {
>> -struct kvm *kvm = vgpu->kvm;
>> +struct kvm *kvm = vgpu->vfio_device.kvm;
>> int idx;
>> bool ret;
>>
>> @@ -1185,7 +1185,7 @@ static int is_2MB_gtt_possible(struct intel_vgpu *vgpu,
>>
>> if (!vgpu->attached)
>> return -EINVAL;
>> -pfn = gfn_to_pfn(vgpu->kvm, ops->get_pfn(entry));
>> +pfn = gfn_to_pfn(vgpu->vfio_device.kvm, ops->get_pfn(entry));
>> if (is_error_noslot_pfn(pfn))
>> return -EINVAL;
>> return PageTransHuge(pfn_to_page(pfn));
>> diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
>> index 2af4c83e733c..aee1a45da74b 100644
>> --- a/drivers/gpu/drm/i915/gvt/gvt.h
>> +++ b/drivers/gpu/drm/i915/gvt/gvt.h
>> @@ -227,9 +227,6 @@ struct intel_vgpu {
>> struct mutex cache_lock;
>>
>> struct notifier_block iommu_notifier;
>> -struct notifier_block group_notifier;
>> -struct kvm *kvm;
>> -struct work_struct release_work;
>> atomic_t released;
>>
>> struct kvm_page_track_notifier_node track_node;
>> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
>> b/drivers/gpu/drm/i915/gvt/kvmgt.c
>> index 7655ffa97d51..e2f6c56ab342 100644
>> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
>> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
>> @@ -228,8 +228,6 @@ static void intel_gvt_cleanup_vgpu_type_groups(struct
>> intel_gvt *gvt)
>> }
>> }
>>
>> -static void intel_vgpu_release_work(struct work_struct *work);
>> -
>> static void gvt_unpin_guest_page(struct intel_vgpu *vgpu, unsigned long gfn,
>> unsigned long size)
>> {
>> @@ -761,23 +759,6 @@ static int intel_vgpu_iommu_notifier(struct
>> notifier_block *nb,
>> return NOTIFY_OK;
>> }
>>
>> -static int intel_vgpu_group_notifier(struct notifier_block *nb,
>> - unsigned long action, void *data)
>> -{
>> -struct intel_vgpu *vgpu =
>> -container_of(nb, struct intel_vgpu, group_notifier);
>> -
>> -/* the only action we care about */
>> -if (action == VFIO_GROUP_NOTIFY_SET_KVM) {
>> -vgpu->kvm = data;
>> -
>> -if (!data)
>> -schedule_work(>release_work);
>> -}
>> -
>> -return NOTIFY_OK;
>> -}
>> -
>> static bool __kvmgt_vgpu_exist(struct intel_vgpu *vgpu)
>> {
>> struct intel_vgpu *itr;
>> @@ -789,7 +770,7 @@ static bool __kvmgt_vgpu_exist(struct intel_vgpu *vgpu)
>> if (!itr->attached)
>> continue;
>>
>> -if (vgpu->kvm == itr->kvm) {
>> +if (vgpu->vfio_device.kvm == itr->vfio_device.kvm) {
>> ret = true;
>> goto out;
>> }
>> @@ -806,7 +787,6 @@ static int intel_vgpu_open_device(struct vfio_device
>> *vfio_dev)
>> int ret;
>>
>> vgpu->iommu_notifier.notifier_call = intel_vgpu_iommu_notifier;
>> -vgpu->group_notifier.notifier_call = intel_vgpu_group_notifier;
>>
>> events = VFIO_IOMMU_NOTIFY_DMA_UNMAP;
>> ret = vfio_register_notifier(vfio_dev, VFIO_IOMMU_NOTIFY, ,
>> @@ -817,38 +797,32 @@ static int intel_vgpu_open_device(struct vfio_device
>> *vfio_dev)
>> goto out;
>> }
>>
>> -events = VFIO_GROUP_NOTIFY_SET_KVM;
>> -ret = vfio_register_notifier(vfio_dev, VFIO_GROUP_NOTIFY, ,
>> - >group_notifier);
>> -if (ret != 0) {
>> -gvt_vgpu_err("vfio_register_notifier for group failed: %d\n",
>> -
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/edid: expand on struct drm_edid usage
On Tue, 24 May 2022, Patchwork wrote: > == Series Details == > > Series: drm/edid: expand on struct drm_edid usage > URL : https://patchwork.freedesktop.org/series/104309/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_11693 -> Patchwork_104309v1 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_104309v1 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_104309v1, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/index.html > > Participating hosts (44 -> 45) > -- > > Additional (2): fi-icl-u2 bat-dg1-5 > Missing(1): fi-pnv-d510 > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_104309v1: > > ### IGT changes ### > > Possible regressions > > * igt@i915_pm_rpm@module-reload: > - fi-skl-guc: [PASS][1] -> [FAIL][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-skl-guc/igt@i915_pm_...@module-reload.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-skl-guc/igt@i915_pm_...@module-reload.html Tomi, this link is giving me access denied. BR, Jani. > > > Known issues > > > Here are the changes found in Patchwork_104309v1 that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@fbdev@write: > - bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#2582]) +4 similar issues >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat-dg1-5/igt@fb...@write.html > > * igt@gem_huc_copy@huc-copy: > - fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#2190]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html > > * igt@gem_lmem_swapping@parallel-random-engines: > - fi-icl-u2: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html > > * igt@gem_mmap@basic: > - bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4083]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat-dg1-5/igt@gem_m...@basic.html > > * igt@gem_tiled_fence_blits@basic: > - bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#4077]) +2 similar issues >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html > > * igt@gem_tiled_pread_basic: > - bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#4079]) +1 similar issue >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat-dg1-5/igt@gem_tiled_pread_basic.html > > * igt@i915_pm_backlight@basic-brightness: > - bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#1155]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html > > * igt@i915_pm_rpm@module-reload: > - fi-cfl-8109u: [PASS][10] -> [DMESG-WARN][11] ([i915#62]) +16 > similar issues >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-cfl-8109u/igt@i915_pm_...@module-reload.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-cfl-8109u/igt@i915_pm_...@module-reload.html > > * igt@i915_selftest@live@hangcheck: > - bat-dg1-5: NOTRUN -> [DMESG-FAIL][12] ([i915#4494] / > [i915#4957]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html > - bat-dg1-6: [PASS][13] -> [DMESG-FAIL][14] ([i915#4494] / > [i915#4957]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html > - fi-snb-2600:[PASS][15] -> [INCOMPLETE][16] ([i915#3921]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html > > * igt@i915_selftest@live@late_gt_pm: > - fi-bsw-nick:[PASS][17] -> [DMESG-FAIL][18] ([i915#3428]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html > > * igt@i915_suspend@basic-s2idle-without-i915: > - bat-dg1-5:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/edid: expand on struct drm_edid usage
== Series Details == Series: drm/edid: expand on struct drm_edid usage URL : https://patchwork.freedesktop.org/series/104309/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11693 -> Patchwork_104309v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_104309v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_104309v1, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/index.html Participating hosts (44 -> 45) -- Additional (2): fi-icl-u2 bat-dg1-5 Missing(1): fi-pnv-d510 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_104309v1: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@module-reload: - fi-skl-guc: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-skl-guc/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-skl-guc/igt@i915_pm_...@module-reload.html Known issues Here are the changes found in Patchwork_104309v1 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@write: - bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#2582]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat-dg1-5/igt@fb...@write.html * igt@gem_huc_copy@huc-copy: - fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-icl-u2: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4083]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#4077]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#4079]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat-dg1-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#1155]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@module-reload: - fi-cfl-8109u: [PASS][10] -> [DMESG-WARN][11] ([i915#62]) +16 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-cfl-8109u/igt@i915_pm_...@module-reload.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-cfl-8109u/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: NOTRUN -> [DMESG-FAIL][12] ([i915#4494] / [i915#4957]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html - bat-dg1-6: [PASS][13] -> [DMESG-FAIL][14] ([i915#4494] / [i915#4957]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html - fi-snb-2600:[PASS][15] -> [INCOMPLETE][16] ([i915#3921]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@late_gt_pm: - fi-bsw-nick:[PASS][17] -> [DMESG-FAIL][18] ([i915#3428]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html * igt@i915_suspend@basic-s2idle-without-i915: - bat-dg1-5: NOTRUN -> [INCOMPLETE][19] ([i915#6011]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v1/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html * igt@i915_suspend@basic-s3-without-i915: - fi-icl-u2: NOTRUN -> [SKIP][20] ([i915#5903]) [20]:
[Intel-gfx] [PATCH v5] drm/i915: Individualize fences before adding to dma_resv obj
_i915_vma_move_to_active() can receive > 1 fences for
multiple batch buffers submission. Because dma_resv_add_fence()
can only accept one fence at a time, change _i915_vma_move_to_active()
to be aware of multiple fences so that it can add individual
fences to the dma resv object.
v5: remove double fence reservation for batch VMAs.
v4: Reserve fences for composite_fence on multi-batch contexts and
also reserve fence slots to composite_fence for each VMAs.
v3: dma_resv_reserve_fences is not cumulative so pass num_fences.
v2: make sure to reserve enough fence slots before adding.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5614
Signed-off-by: Nirmoy Das
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_vma.c | 47 +++
2 files changed, 29 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b279588c0672..8880d38d36b6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1010,7 +1010,8 @@ static int eb_validate_vmas(struct i915_execbuffer *eb)
}
}
- err = dma_resv_reserve_fences(vma->obj->base.resv, 1);
+ /* Reserve enough slots to accommodate composite fences */
+ err = dma_resv_reserve_fences(vma->obj->base.resv,
eb->num_batches);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 4f6db539571a..4a5222fc3a4a 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -23,6 +23,7 @@
*/
#include
+#include
#include
#include "display/intel_frontbuffer.h"
@@ -1823,6 +1824,20 @@ int _i915_vma_move_to_active(struct i915_vma *vma,
if (unlikely(err))
return err;
+ /* Reserve fences slot early to prevent an allocation after preparing
+* the workload and associating fences with dma_resv.
+*/
+ if (fence && !(flags & __EXEC_OBJECT_NO_RESERVE)) {
+ struct dma_fence *curr;
+ int idx;
+
+ dma_fence_array_for_each(curr, idx, fence)
+ ;
+ err = dma_resv_reserve_fences(vma->obj->base.resv, idx);
+ if (unlikely(err))
+ return err;
+ }
+
if (flags & EXEC_OBJECT_WRITE) {
struct intel_frontbuffer *front;
@@ -1832,31 +1847,23 @@ int _i915_vma_move_to_active(struct i915_vma *vma,
i915_active_add_request(>write, rq);
intel_frontbuffer_put(front);
}
+ }
- if (!(flags & __EXEC_OBJECT_NO_RESERVE)) {
- err = dma_resv_reserve_fences(vma->obj->base.resv, 1);
- if (unlikely(err))
- return err;
- }
+ if (fence) {
+ struct dma_fence *curr;
+ enum dma_resv_usage usage;
+ int idx;
- if (fence) {
- dma_resv_add_fence(vma->obj->base.resv, fence,
- DMA_RESV_USAGE_WRITE);
+ obj->read_domains = 0;
+ if (flags & EXEC_OBJECT_WRITE) {
+ usage = DMA_RESV_USAGE_WRITE;
obj->write_domain = I915_GEM_DOMAIN_RENDER;
- obj->read_domains = 0;
- }
- } else {
- if (!(flags & __EXEC_OBJECT_NO_RESERVE)) {
- err = dma_resv_reserve_fences(vma->obj->base.resv, 1);
- if (unlikely(err))
- return err;
+ } else {
+ usage = DMA_RESV_USAGE_READ;
}
- if (fence) {
- dma_resv_add_fence(vma->obj->base.resv, fence,
- DMA_RESV_USAGE_READ);
- obj->write_domain = 0;
- }
+ dma_fence_array_for_each(curr, idx, fence)
+ dma_resv_add_fence(vma->obj->base.resv, curr, usage);
}
if (flags & EXEC_OBJECT_NEEDS_FENCE && vma->fence)
--
2.35.1
[Intel-gfx] [PATCH] drm/i915: Individualize fences before adding to dma_resv obj
_i915_vma_move_to_active() can receive > 1 fences for
multiple batch buffers submission. Because dma_resv_add_fence()
can only accept one fence at a time, change _i915_vma_move_to_active()
to be aware of multiple fences so that it can add individual
fences to the dma resv object.
v4: Reserve fences for composite_fence on multi-batch contexts and
also reserve fence slots to composite_fence for each VMAs.
v3: dma_resv_reserve_fences is not cumulative so pass num_fences.
v2: make sure to reserve enough fence slots before adding.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5614
Signed-off-by: Nirmoy Das
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 +++-
drivers/gpu/drm/i915/i915_vma.c | 47 +++
2 files changed, 36 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b279588c0672..56539f7b0978 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1010,7 +1010,8 @@ static int eb_validate_vmas(struct i915_execbuffer *eb)
}
}
- err = dma_resv_reserve_fences(vma->obj->base.resv, 1);
+ /* Reserve enough slots to accommodate composite fences */
+ err = dma_resv_reserve_fences(vma->obj->base.resv,
eb->num_batches);
if (err)
return err;
@@ -3146,6 +3147,7 @@ eb_composite_fence_create(struct i915_execbuffer *eb, int
out_fence_fd)
struct dma_fence_array *fence_array;
struct dma_fence **fences;
unsigned int i;
+ int err;
GEM_BUG_ON(!intel_context_is_parent(eb->context));
@@ -3154,6 +3156,12 @@ eb_composite_fence_create(struct i915_execbuffer *eb,
int out_fence_fd)
return ERR_PTR(-ENOMEM);
for_each_batch_create_order(eb, i) {
+ err =
dma_resv_reserve_fences(eb->batches[i]->vma->obj->base.resv, eb->num_batches);
+ if (err) {
+ kfree(fences);
+ return ERR_PTR(err);
+ }
+
fences[i] = >requests[i]->fence;
__set_bit(I915_FENCE_FLAG_COMPOSITE,
>requests[i]->fence.flags);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 4f6db539571a..4a5222fc3a4a 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -23,6 +23,7 @@
*/
#include
+#include
#include
#include "display/intel_frontbuffer.h"
@@ -1823,6 +1824,20 @@ int _i915_vma_move_to_active(struct i915_vma *vma,
if (unlikely(err))
return err;
+ /* Reserve fences slot early to prevent an allocation after preparing
+* the workload and associating fences with dma_resv.
+*/
+ if (fence && !(flags & __EXEC_OBJECT_NO_RESERVE)) {
+ struct dma_fence *curr;
+ int idx;
+
+ dma_fence_array_for_each(curr, idx, fence)
+ ;
+ err = dma_resv_reserve_fences(vma->obj->base.resv, idx);
+ if (unlikely(err))
+ return err;
+ }
+
if (flags & EXEC_OBJECT_WRITE) {
struct intel_frontbuffer *front;
@@ -1832,31 +1847,23 @@ int _i915_vma_move_to_active(struct i915_vma *vma,
i915_active_add_request(>write, rq);
intel_frontbuffer_put(front);
}
+ }
- if (!(flags & __EXEC_OBJECT_NO_RESERVE)) {
- err = dma_resv_reserve_fences(vma->obj->base.resv, 1);
- if (unlikely(err))
- return err;
- }
+ if (fence) {
+ struct dma_fence *curr;
+ enum dma_resv_usage usage;
+ int idx;
- if (fence) {
- dma_resv_add_fence(vma->obj->base.resv, fence,
- DMA_RESV_USAGE_WRITE);
+ obj->read_domains = 0;
+ if (flags & EXEC_OBJECT_WRITE) {
+ usage = DMA_RESV_USAGE_WRITE;
obj->write_domain = I915_GEM_DOMAIN_RENDER;
- obj->read_domains = 0;
- }
- } else {
- if (!(flags & __EXEC_OBJECT_NO_RESERVE)) {
- err = dma_resv_reserve_fences(vma->obj->base.resv, 1);
- if (unlikely(err))
- return err;
+ } else {
+ usage = DMA_RESV_USAGE_READ;
}
- if (fence) {
- dma_resv_add_fence(vma->obj->base.resv, fence,
- DMA_RESV_USAGE_READ);
- obj->write_domain = 0;
- }
+
Re: [Intel-gfx] [PATCH] drm/i915: fix typos in comments
On Sat, 21 May 2022, Julia Lawall wrote:
> Spelling mistakes (triple letters) in comments.
> Detected with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
Thanks, pushed to drm-intel-next.
BR,
Jani.
>
> ---
> drivers/gpu/drm/i915/display/intel_color.c |2 +-
> drivers/gpu/drm/i915/display/intel_pps.c |2 +-
> drivers/gpu/drm/i915/gt/intel_execlists_submission.c |2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c |2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 34128c9c635c..a27ce874a9e8 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1638,7 +1638,7 @@ static u32 icl_gamma_mode(const struct intel_crtc_state
> *crtc_state)
> /*
>* Enable 10bit gamma for D13
>* ToDo: Extend to Logarithmic Gamma once the new UAPI
> - * is acccepted and implemented by a userspace consumer
> + * is accepted and implemented by a userspace consumer
>*/
> else if (DISPLAY_VER(i915) >= 13)
> gamma_mode |= GAMMA_MODE_MODE_10BIT;
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index 5a598dd06039..4bc0563dde92 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -509,7 +509,7 @@ static void wait_panel_power_cycle(struct intel_dp
> *intel_dp)
>
> drm_dbg_kms(>drm, "Wait for panel power cycle\n");
>
> - /* take the difference of currrent time and panel power off time
> + /* take the difference of current time and panel power off time
>* and then make panel wait for t11_t12 if needed. */
> panel_power_on_time = ktime_get_boottime();
> panel_power_off_duration = ktime_ms_delta(panel_power_on_time,
> intel_dp->pps.panel_power_off_time);
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 86f7a9ac1c39..aa0d2cc4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -1350,7 +1350,7 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
>* submission. If we don't cancel the timer now,
>* we will see that the timer has expired and
>* reschedule the tasklet; continually until the
> - * next context switch or other preeemption event.
> + * next context switch or other preemption event.
>*
>* Since we have decided to reschedule based on
>* consumption of this timeslice, if we submit the
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> index 78d2989fe917..02311ad90264 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> @@ -588,7 +588,7 @@ int intel_guc_log_relay_open(struct intel_guc_log *log)
> /*
>* We require SSE 4.1 for fast reads from the GuC log buffer and
>* it should be present on the chipsets supporting GuC based
> - * submisssions.
> + * submissions.
>*/
> if (!i915_has_memcpy_from_wc()) {
> ret = -ENXIO;
>
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/edid: expand on struct drm_edid usage
== Series Details == Series: drm/edid: expand on struct drm_edid usage URL : https://patchwork.freedesktop.org/series/104309/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/edid: expand on struct drm_edid usage
== Series Details == Series: drm/edid: expand on struct drm_edid usage URL : https://patchwork.freedesktop.org/series/104309/ State : warning == Summary == Error: dim checkpatch failed b8427e0da67f drm/edid: add block count and data helper functions for drm_edid 77f40495d3e1 drm/edid: keep track of alloc size in drm_do_get_edid() e5215f6adce1 drm/edid: add new interfaces around struct drm_edid -:320: WARNING:LONG_LINE: line length of 118 exceeds 100 columns #320: FILE: include/drm/drm_edid.h:591: + int (*read_block)(void *context, u8 *buf, unsigned int block, size_t len), total: 0 errors, 1 warnings, 0 checks, 291 lines checked c3d9eeb29af8 drm/edid: add drm_edid_connector_update() dafd9f6bcb68 drm/probe-helper: abstract .get_modes() connector helper call f84ce12be004 drm/probe-helper: make .get_modes() optional, add default action a4b185749eca drm/probe-helper: add .get_edid() callback 3766c2b5154e drm/edid: add drm_edid_raw() to access the raw EDID data db9189e6b617 drm/i915/edid: convert DP, HDMI and LVDS to drm_edid -:256: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "drm_edid" #256: FILE: drivers/gpu/drm/i915/display/intel_hdmi.c:2429: + intel_hdmi_dp_dual_mode_detect(connector, drm_edid != NULL); total: 0 errors, 0 warnings, 1 checks, 300 lines checked 3efc0a0e941b drm/edid: do invalid block filtering in-place f9f6a03e8733 drm/edid: add HF-EEODB support to EDID read and allocation 820655b13081 drm/edid: take HF-EEODB extension count into account 8f94d9ed7f40 drm/todo: add entry for converting the subsystem to struct drm_edid
[Intel-gfx] [PATCH v1 13/13] drm/todo: add entry for converting the subsystem to struct drm_edid
We need to stop duplicating EDID validation and parsing all over the
subsystem in various broken ways.
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
Documentation/gpu/todo.rst | 25 +
1 file changed, 25 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 513b20ccef1e..982e4e29825f 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -480,6 +480,31 @@ Contact: Thomas Zimmermann
Level: Starter
+Convert core and drivers from struct edid to struct drm_edid
+
+
+Go through all drivers and drm core KMS code to convert all raw struct edid
+usage to the opaque struct drm_edid. See commit e4ccf9a777d3 ("drm/edid: add
+struct drm_edid container") for rationale.
+
+Convert drm_get_edid() and drm_do_get_edid() usage to drm_edid_read(),
+drm_edid_read_ddc(), or drm_edid_read_custom().
+
+Convert drm_add_edid_modes() and drm_connector_update_edid_property() to
+drm_edid_connector_update(). See drm_helper_probe_get_modes() for reference for
+converting the ->get_modes() hooks.
+
+Convert decentralized, direct struct edid parsing to centralized parsing in
+drm_edid.c. Prefer one-time parsing as part of drm_edid_connector_update() and
+storing the result in drm_connector->display_info over adding individual,
+exported parser functions.
+
+During the transition period, it may be necessary to use drm_edid_raw(), but do
+use it sparingly. Eventually, all of them need to go.
+
+Contact: Jani Nikula
+
+Level: Intermediate
Core refactorings
=
--
2.30.2
[Intel-gfx] [PATCH v1 12/13] drm/edid: take HF-EEODB extension count into account
Take the HF-EEODB extension count override into account.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ba0c880dc133..6b1284b895eb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1629,6 +1629,19 @@ static int drm_edid_block_count(const struct drm_edid
*drm_edid)
/* Starting point */
num_blocks = edid_block_count(drm_edid->edid);
+ /* HF-EEODB override */
+ if (drm_edid->size >= edid_size_by_blocks(2)) {
+ int eeodb;
+
+ /*
+* Note: HF-EEODB may specify a smaller extension count than the
+* regular one. Unlike in buffer allocation, here we can use it.
+*/
+ eeodb = edid_hfeeodb_block_count(drm_edid->edid);
+ if (eeodb)
+ num_blocks = eeodb;
+ }
+
/* Limit by allocated size */
num_blocks = min(num_blocks, (int)drm_edid->size / EDID_LENGTH);
--
2.30.2
[Intel-gfx] [PATCH v1 11/13] drm/edid: add HF-EEODB support to EDID read and allocation
HDMI 2.1 section 10.3.6 defines an HDMI Forum EDID Extension Override
Data Block, which may contain a different extension count than the base
block claims. Add support for reading more EDID data if available. The
extra blocks aren't parsed yet, though.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 81 --
1 file changed, 78 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5e0a91da565e..ba0c880dc133 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1581,6 +1581,15 @@ static bool version_greater(const struct drm_edid
*drm_edid,
(edid->version == version && edid->revision > revision);
}
+static int edid_hfeeodb_extension_block_count(const struct edid *edid);
+
+static int edid_hfeeodb_block_count(const struct edid *edid)
+{
+ int eeodb = edid_hfeeodb_extension_block_count(edid);
+
+ return eeodb ? eeodb + 1 : 0;
+}
+
static int edid_extension_block_count(const struct edid *edid)
{
return edid->extensions;
@@ -2026,6 +2035,11 @@ static struct edid *edid_filter_invalid_blocks(struct
edid *edid,
struct edid *new;
int i, valid_blocks = 0;
+ /*
+* Note: If the EDID uses HF-EEODB, but has invalid blocks, we'll revert
+* back to regular extension count here. We don't want to start
+* modifying the HF-EEODB extension too.
+*/
for (i = 0; i < edid_block_count(edid); i++) {
const void *src_block = edid_block_data(edid, i);
@@ -2235,7 +2249,7 @@ static struct edid *_drm_do_get_edid(struct drm_connector
*connector,
size_t *size)
{
enum edid_block_status status;
- int i, invalid_blocks = 0;
+ int i, num_blocks, invalid_blocks = 0;
struct edid *edid, *new;
size_t alloc_size = EDID_LENGTH;
@@ -2277,7 +2291,8 @@ static struct edid *_drm_do_get_edid(struct drm_connector
*connector,
goto fail;
edid = new;
- for (i = 1; i < edid_block_count(edid); i++) {
+ num_blocks = edid_block_count(edid);
+ for (i = 1; i < num_blocks; i++) {
void *block = (void *)edid_block_data(edid, i);
status = edid_block_read(block, i, read_block, context);
@@ -2288,11 +2303,31 @@ static struct edid *_drm_do_get_edid(struct
drm_connector *connector,
if (status == EDID_BLOCK_READ_FAIL)
goto fail;
invalid_blocks++;
+ } else if (i == 1) {
+ /*
+* If the first EDID extension is a CTA extension, and
+* the first Data Block is HF-EEODB, override the
+* extension block count.
+*
+* Note: HF-EEODB could specify a smaller extension
+* count too, but we can't risk allocating a smaller
+* amount.
+*/
+ int eeodb = edid_hfeeodb_block_count(edid);
+
+ if (eeodb > num_blocks) {
+ num_blocks = eeodb;
+ alloc_size = edid_size_by_blocks(num_blocks);
+ new = krealloc(edid, alloc_size, GFP_KERNEL);
+ if (!new)
+ goto fail;
+ edid = new;
+ }
}
}
if (invalid_blocks) {
- connector_bad_edid(connector, edid, edid_block_count(edid));
+ connector_bad_edid(connector, edid, num_blocks);
edid = edid_filter_invalid_blocks(edid, _size);
}
@@ -3825,6 +3860,7 @@ static int add_detailed_modes(struct drm_connector
*connector,
#define CTA_EXT_DB_HDR_STATIC_METADATA 6
#define CTA_EXT_DB_420_VIDEO_DATA 14
#define CTA_EXT_DB_420_VIDEO_CAP_MAP 15
+#define CTA_EXT_DB_HF_EEODB0x78
#define CTA_EXT_DB_HF_SCDB 0x79
#define EDID_BASIC_AUDIO (1 << 6)
@@ -4868,6 +4904,12 @@ static bool cea_db_is_hdmi_forum_vsdb(const struct
cea_db *db)
cea_db_payload_len(db) >= 7;
}
+static bool cea_db_is_hdmi_forum_eeodb(const void *db)
+{
+ return cea_db_is_extended_tag(db, CTA_EXT_DB_HF_EEODB) &&
+ cea_db_payload_len(db) >= 2;
+}
+
static bool cea_db_is_microsoft_vsdb(const struct cea_db *db)
{
return cea_db_is_vendor(db, MICROSOFT_IEEE_OUI) &&
@@ -4902,6 +4944,39 @@ static bool cea_db_is_hdmi_hdr_metadata_block(const
struct cea_db *db)
cea_db_payload_len(db) >= 3;
}
+/*
+ * Get the HF-EEODB override extension block count from EDID.
+ *
+ * The passed in EDID may be partially read, as long as it has at least two
+ * blocks (base block and one extension
[Intel-gfx] [PATCH v1 10/13] drm/edid: do invalid block filtering in-place
Rewrite edid_filter_invalid_blocks() to filter invalid blocks
in-place. The main motivation is to not rely on passed in information on
invalid block count or the allocation size, which will be helpful in
follow-up work on HF-EEODB.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 43 --
1 file changed, 23 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6617ea70ae5c..5e0a91da565e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2020,33 +2020,37 @@ bool drm_edid_is_valid(struct edid *edid)
}
EXPORT_SYMBOL(drm_edid_is_valid);
-static struct edid *edid_filter_invalid_blocks(const struct edid *edid,
- int invalid_blocks,
+static struct edid *edid_filter_invalid_blocks(struct edid *edid,
size_t *alloc_size)
{
- struct edid *new, *dest_block;
- int valid_extensions = edid->extensions - invalid_blocks;
- int i;
+ struct edid *new;
+ int i, valid_blocks = 0;
- *alloc_size = edid_size_by_blocks(valid_extensions + 1);
+ for (i = 0; i < edid_block_count(edid); i++) {
+ const void *src_block = edid_block_data(edid, i);
- new = kmalloc(*alloc_size, GFP_KERNEL);
- if (!new)
- goto out;
+ if (edid_block_valid(src_block, i == 0)) {
+ void *dst_block = (void *)edid_block_data(edid,
valid_blocks);
- dest_block = new;
- for (i = 0; i < edid_block_count(edid); i++) {
- const void *block = edid_block_data(edid, i);
+ memmove(dst_block, src_block, EDID_LENGTH);
+ valid_blocks++;
+ }
+ }
- if (edid_block_valid(block, i == 0))
- memcpy(dest_block++, block, EDID_LENGTH);
+ /* We already trusted the base block to be valid here... */
+ if (WARN_ON(!valid_blocks)) {
+ kfree(edid);
+ return NULL;
}
- new->extensions = valid_extensions;
- new->checksum = edid_block_compute_checksum(new);
+ edid->extensions = valid_blocks - 1;
+ edid->checksum = edid_block_compute_checksum(edid);
-out:
- kfree(edid);
+ *alloc_size = edid_size_by_blocks(valid_blocks);
+
+ new = krealloc(edid, *alloc_size, GFP_KERNEL);
+ if (!new)
+ kfree(edid);
return new;
}
@@ -2290,8 +2294,7 @@ static struct edid *_drm_do_get_edid(struct drm_connector
*connector,
if (invalid_blocks) {
connector_bad_edid(connector, edid, edid_block_count(edid));
- edid = edid_filter_invalid_blocks(edid, invalid_blocks,
- _size);
+ edid = edid_filter_invalid_blocks(edid, _size);
}
ok:
--
2.30.2
[Intel-gfx] [PATCH v1 09/13] drm/i915/edid: convert DP, HDMI and LVDS to drm_edid
Convert all the connectors that use cached connector edid and
detect_edid to drm_edid.
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_connector.c| 4 +-
.../drm/i915/display/intel_display_types.h| 4 +-
drivers/gpu/drm/i915/display/intel_dp.c | 72 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 26 +++
drivers/gpu/drm/i915/display/intel_lvds.c | 35 -
5 files changed, 77 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index 1dcc268927a2..d83b2a64f618 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -95,12 +95,12 @@ void intel_connector_destroy(struct drm_connector
*connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
- kfree(intel_connector->detect_edid);
+ drm_edid_free(intel_connector->detect_edid);
intel_hdcp_cleanup(intel_connector);
if (!IS_ERR_OR_NULL(intel_connector->edid))
- kfree(intel_connector->edid);
+ drm_edid_free(intel_connector->edid);
intel_panel_fini(intel_connector);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 408152f9f46a..b72724918761 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -519,8 +519,8 @@ struct intel_connector {
struct intel_panel panel;
/* Cached EDID for eDP and LVDS. May hold ERR_PTR for invalid EDID. */
- struct edid *edid;
- struct edid *detect_edid;
+ const struct drm_edid *edid;
+ const struct drm_edid *detect_edid;
/* Number of times hotplug detection was tried after an HPD interrupt */
int hotplug_retries;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index e4a79c11fd25..771857ed0052 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3511,12 +3511,11 @@ static u8 intel_dp_autotest_edid(struct intel_dp
*intel_dp)
intel_dp->aux.i2c_defer_count);
intel_dp->compliance.test_data.edid =
INTEL_DP_RESOLUTION_FAILSAFE;
} else {
- struct edid *block = intel_connector->detect_edid;
+ /* FIXME: Get rid of drm_edid_raw() */
+ const struct edid *block =
drm_edid_raw(intel_connector->detect_edid);
- /* We have to write the checksum
-* of the last block read
-*/
- block += intel_connector->detect_edid->extensions;
+ /* We have to write the checksum of the last block read */
+ block += block->extensions;
if (drm_dp_dpcd_writeb(_dp->aux, DP_TEST_EDID_CHECKSUM,
block->checksum) <= 0)
@@ -4395,7 +4394,7 @@ bool intel_digital_port_connected(struct intel_encoder
*encoder)
return is_connected;
}
-static struct edid *
+static const struct drm_edid *
intel_dp_get_edid(struct intel_dp *intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
@@ -4406,18 +4405,22 @@ intel_dp_get_edid(struct intel_dp *intel_dp)
if (IS_ERR(intel_connector->edid))
return NULL;
- return drm_edid_duplicate(intel_connector->edid);
+ return drm_edid_dup(intel_connector->edid);
} else
- return drm_get_edid(_connector->base,
- _dp->aux.ddc);
+ return drm_edid_read_ddc(_connector->base,
+_dp->aux.ddc);
}
static void
intel_dp_update_dfp(struct intel_dp *intel_dp,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_connector *connector = intel_dp->attached_connector;
+ const struct edid *edid;
+
+ /* FIXME: Get rid of drm_edid_raw() */
+ edid = drm_edid_raw(drm_edid);
intel_dp->dfp.max_bpc =
drm_dp_downstream_max_bpc(intel_dp->dpcd,
@@ -4517,21 +4520,24 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_connector *connector = intel_dp->attached_connector;
- struct edid *edid;
+ const struct drm_edid *drm_edid;
+ const struct edid *edid;
bool vrr_capable;
intel_dp_unset_edid(intel_dp);
- edid = intel_dp_get_edid(intel_dp);
- connector->detect_edid = edid;
+ drm_edid = intel_dp_get_edid(intel_dp);
+ connector->detect_edid = drm_edid;
vrr_capable =
[Intel-gfx] [PATCH v1 08/13] drm/edid: add drm_edid_raw() to access the raw EDID data
Unfortunately, there are still plenty of interfaces around that require
a struct edid pointer, and it's impossible to change them all at
once. Add an accessor to the raw EDID data to help the transition.
While there are no such cases now, be defensive against raw EDID
extension count indicating bigger EDID than is actually allocated.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 26 ++
include/drm/drm_edid.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 09328298aabf..6617ea70ae5c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2333,6 +2333,32 @@ struct edid *drm_do_get_edid(struct drm_connector
*connector,
}
EXPORT_SYMBOL_GPL(drm_do_get_edid);
+/**
+ * drm_edid_raw - Get a pointer to the raw EDID data.
+ * @drm_edid: drm_edid container
+ *
+ * Get a pointer to the raw EDID data.
+ *
+ * This is for transition only. Avoid using this like the plague.
+ *
+ * Return: Pointer to raw EDID data.
+ */
+const struct edid *drm_edid_raw(const struct drm_edid *drm_edid)
+{
+ if (!drm_edid || !drm_edid->size)
+ return NULL;
+
+ /*
+* Do not return pointers where relying on EDID extension count would
+* lead to buffer overflow.
+*/
+ if (WARN_ON(edid_size(drm_edid->edid) > drm_edid->size))
+ return NULL;
+
+ return drm_edid->edid;
+}
+EXPORT_SYMBOL(drm_edid_raw);
+
/* Allocate struct drm_edid container *without* duplicating the edid data */
static const struct drm_edid *_drm_edid_alloc(const void *edid, size_t size)
{
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 289b956d31ea..f74ec9f7439b 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -584,6 +584,7 @@ drm_display_mode_from_cea_vic(struct drm_device *dev,
const struct drm_edid *drm_edid_alloc(const void *edid, size_t size);
const struct drm_edid *drm_edid_dup(const struct drm_edid *drm_edid);
void drm_edid_free(const struct drm_edid *drm_edid);
+const struct edid *drm_edid_raw(const struct drm_edid *drm_edid);
const struct drm_edid *drm_edid_read(struct drm_connector *connector);
const struct drm_edid *drm_edid_read_ddc(struct drm_connector *connector,
struct i2c_adapter *adapter);
--
2.30.2
[Intel-gfx] [PATCH v1 07/13] drm/probe-helper: add .get_edid() callback
Add a hook for custom .get_edid() when .get_modes() is not set.
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_probe_helper.c | 11 +--
include/drm/drm_modeset_helper_vtables.h | 21 ++---
2 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 9df17f0ae225..42481dc9e6db 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -361,12 +361,19 @@ static int drm_helper_probe_get_modes(struct
drm_connector *connector)
int count;
if (connector_funcs->get_modes) {
+ /* No point in having both set */
+ drm_WARN_ON_ONCE(connector->dev, connector_funcs->get_edid);
+
count = connector_funcs->get_modes(connector);
} else {
const struct drm_edid *drm_edid;
- /* Note: This requires connector->ddc is set */
- drm_edid = drm_edid_read(connector);
+ if (connector_funcs->get_edid) {
+ drm_edid = connector_funcs->get_edid(connector);
+ } else {
+ /* Note: This requires connector->ddc is set */
+ drm_edid = drm_edid_read(connector);
+ }
/* Update modes etc. from the EDID */
count = drm_edid_connector_update(connector, drm_edid);
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index b4402bc64e57..f4defbdf1768 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -49,6 +49,7 @@
*/
enum mode_set_atomic;
+struct drm_edid;
struct drm_writeback_connector;
struct drm_writeback_job;
@@ -894,9 +895,10 @@ struct drm_connector_helper_funcs {
* libraries always call this with the _mode_config.connection_mutex
* held. Because of this it's safe to inspect _connector->state.
*
-* This callback is optional. By default, it reads the EDID using
-* drm_edid_read() and updates the connector display info, modes, and
-* properties using drm_edid_connector_update().
+* This callback is optional. By default, it reads the EDID using the
+* .get_edid() callback if set, drm_edid_read() otherwise, and updates
+* the connector display info, modes, and properties using
+* drm_edid_connector_update().
*
* RETURNS:
*
@@ -904,6 +906,19 @@ struct drm_connector_helper_funcs {
*/
int (*get_modes)(struct drm_connector *connector);
+ /**
+* @get_edid:
+*
+* If the get_modes() callback is not set, this function gets called to
+* retrieve the EDID. This callback is optional. By default,
+* drm_edid_read() is used.
+*
+* This function must return a copy of the EDID; the returned pointer
+* will be freed using drm_edid_free(). Usually it would be a copy of a
+* previously cached EDID.
+*/
+ const struct drm_edid *(*get_edid)(struct drm_connector *connector);
+
/**
* @detect_ctx:
*
--
2.30.2
[Intel-gfx] [PATCH v1 06/13] drm/probe-helper: make .get_modes() optional, add default action
Add default action when .get_modes() not set. This also defines what a
.get_modes() hook should do.
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_probe_helper.c | 14 +-
include/drm/drm_modeset_helper_vtables.h | 4
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 836bcd5b4cb6..9df17f0ae225 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -360,7 +360,19 @@ static int drm_helper_probe_get_modes(struct drm_connector
*connector)
connector->helper_private;
int count;
- count = connector_funcs->get_modes(connector);
+ if (connector_funcs->get_modes) {
+ count = connector_funcs->get_modes(connector);
+ } else {
+ const struct drm_edid *drm_edid;
+
+ /* Note: This requires connector->ddc is set */
+ drm_edid = drm_edid_read(connector);
+
+ /* Update modes etc. from the EDID */
+ count = drm_edid_connector_update(connector, drm_edid);
+
+ drm_edid_free(drm_edid);
+ }
/*
* Fallback for when DDC probe failed in drm_get_edid() and thus skipped
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index fafa70ac1337..b4402bc64e57 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -894,6 +894,10 @@ struct drm_connector_helper_funcs {
* libraries always call this with the _mode_config.connection_mutex
* held. Because of this it's safe to inspect _connector->state.
*
+* This callback is optional. By default, it reads the EDID using
+* drm_edid_read() and updates the connector display info, modes, and
+* properties using drm_edid_connector_update().
+*
* RETURNS:
*
* The number of modes added by calling drm_mode_probed_add().
--
2.30.2
[Intel-gfx] [PATCH v1 05/13] drm/probe-helper: abstract .get_modes() connector helper call
Abstract the .get_modes() connector helper call, including the
override/firmware EDID fallback, to make it easier to extend it.
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_probe_helper.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 425f56280d51..836bcd5b4cb6 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -354,6 +354,24 @@ drm_helper_probe_detect(struct drm_connector *connector,
}
EXPORT_SYMBOL(drm_helper_probe_detect);
+static int drm_helper_probe_get_modes(struct drm_connector *connector)
+{
+ const struct drm_connector_helper_funcs *connector_funcs =
+ connector->helper_private;
+ int count;
+
+ count = connector_funcs->get_modes(connector);
+
+ /*
+* Fallback for when DDC probe failed in drm_get_edid() and thus skipped
+* override/firmware EDID.
+*/
+ if (count == 0 && connector->status == connector_status_connected)
+ count = drm_add_override_edid_modes(connector);
+
+ return count;
+}
+
static int __drm_helper_update_and_validate(struct drm_connector *connector,
uint32_t maxX, uint32_t maxY,
struct drm_modeset_acquire_ctx *ctx)
@@ -473,8 +491,6 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
{
struct drm_device *dev = connector->dev;
struct drm_display_mode *mode;
- const struct drm_connector_helper_funcs *connector_funcs =
- connector->helper_private;
int count = 0, ret;
enum drm_connector_status old_status;
struct drm_modeset_acquire_ctx ctx;
@@ -559,14 +575,7 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
goto exit;
}
- count = (*connector_funcs->get_modes)(connector);
-
- /*
-* Fallback for when DDC probe failed in drm_get_edid() and thus skipped
-* override/firmware EDID.
-*/
- if (count == 0 && connector->status == connector_status_connected)
- count = drm_add_override_edid_modes(connector);
+ count = drm_helper_probe_get_modes(connector);
if (count == 0 && (connector->status == connector_status_connected ||
connector->status == connector_status_unknown))
--
2.30.2
[Intel-gfx] [PATCH v1 04/13] drm/edid: add drm_edid_connector_update()
Add a new function drm_edid_connector_update() to replace the
combination of calls drm_connector_update_edid_property() and
drm_add_edid_modes(). Usually they are called in the drivers in this
order, however the former needs information from the latter.
This is all in drm_edid.c simply to keep struct drm_edid opaque.
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_connector.c | 2 +
drivers/gpu/drm/drm_edid.c | 71 +++--
include/drm/drm_edid.h | 2 +
3 files changed, 71 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 1c48d162c77e..ae9c640a641a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2088,6 +2088,8 @@ EXPORT_SYMBOL(drm_connector_set_tile_property);
* set the connector's tile property here. See
drm_connector_set_tile_property()
* for more details.
*
+ * This function is deprecated. Use drm_edid_connector_update() instead.
+ *
* Returns:
* Zero on success, negative errno on failure.
*/
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0d640e7dcff7..09328298aabf 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6127,8 +6127,8 @@ static int add_displayid_detailed_modes(struct
drm_connector *connector,
return num_modes;
}
-static int drm_edid_connector_update(struct drm_connector *connector,
-const struct drm_edid *drm_edid)
+static int _drm_edid_connector_update(struct drm_connector *connector,
+ const struct drm_edid *drm_edid)
{
int num_modes = 0;
u32 quirks;
@@ -6191,6 +6191,67 @@ static int drm_edid_connector_update(struct
drm_connector *connector,
return num_modes;
}
+static void _drm_update_tile_info(struct drm_connector *connector,
+ const struct drm_edid *drm_edid);
+
+/**
+ * drm_edid_connector_update - Update connector information from EDID
+ * @connector: Connector
+ * @drm_edid: EDID
+ *
+ * Update the connector mode list, display info, ELD, HDR metadata, relevant
+ * properties, etc. from the passed in EDID.
+ *
+ * If EDID is NULL, reset the information.
+ *
+ * Return: The number of modes added or 0 if we couldn't find any.
+ */
+int drm_edid_connector_update(struct drm_connector *connector,
+ const struct drm_edid *drm_edid)
+{
+ struct drm_device *dev = connector->dev;
+ const struct edid *old_edid = connector->edid_blob_ptr ?
+ connector->edid_blob_ptr->data : NULL;
+ const struct edid *edid = drm_edid ? drm_edid->edid : NULL;
+ size_t size = drm_edid ? drm_edid->size : 0;
+ int count, ret;
+
+ count = _drm_edid_connector_update(connector, drm_edid);
+
+ _drm_update_tile_info(connector, drm_edid);
+
+ if (old_edid && !drm_edid_are_equal(edid, old_edid)) {
+ connector->epoch_counter++;
+
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] EDID changed, epoch counter
%llu\n",
+ connector->base.id, connector->name,
+ connector->epoch_counter);
+ }
+
+ ret = drm_property_replace_global_blob(dev, >edid_blob_ptr,
+ size, edid,
+ >base,
+ dev->mode_config.edid_property);
+ if (ret)
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] EDID property update failed
(%d)\n",
+ connector->base.id, connector->name, ret);
+
+ ret = drm_object_property_set_value(>base,
+
dev->mode_config.non_desktop_property,
+
connector->display_info.non_desktop);
+ if (ret)
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Non-desktop property update
failed (%d)\n",
+ connector->base.id, connector->name, ret);
+
+ ret = drm_connector_set_tile_property(connector);
+ if (ret)
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Tile property update failed
(%d)\n",
+ connector->base.id, connector->name, ret);
+
+ return count;
+}
+EXPORT_SYMBOL(drm_edid_connector_update);
+
/**
* drm_add_edid_modes - add modes from EDID data, if available
* @connector: connector we're probing
@@ -6200,6 +6261,8 @@ static int drm_edid_connector_update(struct drm_connector
*connector,
* _display_info structure and ELD in @connector with any information which
* can be derived from the edid.
*
+ * This function is deprecated. Use drm_edid_connector_update() instead.
+ *
* Return: The number of modes added or 0 if we couldn't find any.
*/
int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
@@ -6212,8
[Intel-gfx] [PATCH v1 03/13] drm/edid: add new interfaces around struct drm_edid
Add new functions drm_edid_read(), drm_edid_read_ddc(), and
drm_edid_read_custom() to replace drm_get_edid() and drm_do_get_edid()
for reading the EDID. The transition is expected to happen over a fairly
long time.
Note that the new drm_edid_read*() functions do not do any of the
connector updates anymore. The reading and parsing will be completely
separated from each other.
Add new functions drm_edid_alloc(), drm_edid_dup(), and drm_edid_free()
for allocating and freeing drm_edid containers.
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 245 +
include/drm/drm_edid.h | 9 ++
2 files changed, 230 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2132a38ed701..0d640e7dcff7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2226,29 +2226,9 @@ static enum edid_block_status edid_block_read(void
*block, unsigned int block_nu
return status;
}
-/**
- * drm_do_get_edid - get EDID data using a custom EDID block read function
- * @connector: connector we're probing
- * @read_block: EDID block read function
- * @context: private data passed to the block read function
- *
- * When the I2C adapter connected to the DDC bus is hidden behind a device that
- * exposes a different interface to read EDID blocks this function can be used
- * to get EDID data using a custom block read function.
- *
- * As in the general case the DDC bus is accessible by the kernel at the I2C
- * level, drivers must make all reasonable efforts to expose it as an I2C
- * adapter and use drm_get_edid() instead of abusing this function.
- *
- * The EDID may be overridden using debugfs override_edid or firmware EDID
- * (drm_load_edid_firmware() and drm.edid_firmware parameter), in this priority
- * order. Having either of them bypasses actual EDID reads.
- *
- * Return: Pointer to valid EDID or NULL if we couldn't find any.
- */
-struct edid *drm_do_get_edid(struct drm_connector *connector,
-read_block_fn read_block,
-void *context)
+static struct edid *_drm_do_get_edid(struct drm_connector *connector,
+read_block_fn read_block, void *context,
+size_t *size)
{
enum edid_block_status status;
int i, invalid_blocks = 0;
@@ -2315,14 +2295,125 @@ struct edid *drm_do_get_edid(struct drm_connector
*connector,
}
ok:
+ if (size)
+ *size = alloc_size;
+
return edid;
fail:
kfree(edid);
return NULL;
}
+
+/**
+ * drm_do_get_edid - get EDID data using a custom EDID block read function
+ * @connector: connector we're probing
+ * @read_block: EDID block read function
+ * @context: private data passed to the block read function
+ *
+ * When the I2C adapter connected to the DDC bus is hidden behind a device that
+ * exposes a different interface to read EDID blocks this function can be used
+ * to get EDID data using a custom block read function.
+ *
+ * As in the general case the DDC bus is accessible by the kernel at the I2C
+ * level, drivers must make all reasonable efforts to expose it as an I2C
+ * adapter and use drm_get_edid() instead of abusing this function.
+ *
+ * The EDID may be overridden using debugfs override_edid or firmware EDID
+ * (drm_load_edid_firmware() and drm.edid_firmware parameter), in this priority
+ * order. Having either of them bypasses actual EDID reads.
+ *
+ * Return: Pointer to valid EDID or NULL if we couldn't find any.
+ */
+struct edid *drm_do_get_edid(struct drm_connector *connector,
+read_block_fn read_block,
+void *context)
+{
+ return _drm_do_get_edid(connector, read_block, context, NULL);
+}
EXPORT_SYMBOL_GPL(drm_do_get_edid);
+/* Allocate struct drm_edid container *without* duplicating the edid data */
+static const struct drm_edid *_drm_edid_alloc(const void *edid, size_t size)
+{
+ struct drm_edid *drm_edid;
+
+ if (!edid || !size || size < EDID_LENGTH)
+ return NULL;
+
+ drm_edid = kzalloc(sizeof(*drm_edid), GFP_KERNEL);
+ if (drm_edid) {
+ drm_edid->edid = edid;
+ drm_edid->size = size;
+ }
+
+ return drm_edid;
+}
+
+/**
+ * drm_edid_alloc - Allocate a new drm_edid container
+ * @edid: Pointer to raw EDID data
+ * @size: Size of memory allocated for EDID
+ *
+ * Allocate a new drm_edid container. Do not calculate edid size from edid,
pass
+ * the actual size that has been allocated for the data. There is no validation
+ * of the raw EDID data against the size, but at least the EDID base block must
+ * fit in the buffer.
+ *
+ * The returned pointer must be freed using drm_edid_free().
+ *
+ * Return: drm_edid container, or NULL on errors
+ */
+const struct drm_edid *drm_edid_alloc(const
[Intel-gfx] [PATCH v1 02/13] drm/edid: keep track of alloc size in drm_do_get_edid()
We'll want to return the allocated buffer size in the future. Keep track
of it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 682d954a9e42..2132a38ed701 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2021,13 +2021,16 @@ bool drm_edid_is_valid(struct edid *edid)
EXPORT_SYMBOL(drm_edid_is_valid);
static struct edid *edid_filter_invalid_blocks(const struct edid *edid,
- int invalid_blocks)
+ int invalid_blocks,
+ size_t *alloc_size)
{
struct edid *new, *dest_block;
int valid_extensions = edid->extensions - invalid_blocks;
int i;
- new = kmalloc(edid_size_by_blocks(valid_extensions + 1), GFP_KERNEL);
+ *alloc_size = edid_size_by_blocks(valid_extensions + 1);
+
+ new = kmalloc(*alloc_size, GFP_KERNEL);
if (!new)
goto out;
@@ -2140,7 +2143,8 @@ static void connector_bad_edid(struct drm_connector
*connector,
}
/* Get override or firmware EDID */
-static struct edid *drm_get_override_edid(struct drm_connector *connector)
+static struct edid *drm_get_override_edid(struct drm_connector *connector,
+ size_t *alloc_size)
{
struct edid *override = NULL;
@@ -2150,6 +2154,10 @@ static struct edid *drm_get_override_edid(struct
drm_connector *connector)
if (!override)
override = drm_load_edid_firmware(connector);
+ /* FIXME: Get alloc size from deeper down the stack */
+ if (!IS_ERR_OR_NULL(override) && alloc_size)
+ *alloc_size = edid_size(override);
+
return IS_ERR(override) ? NULL : override;
}
@@ -2169,7 +2177,7 @@ int drm_add_override_edid_modes(struct drm_connector
*connector)
struct edid *override;
int num_modes = 0;
- override = drm_get_override_edid(connector);
+ override = drm_get_override_edid(connector, NULL);
if (override) {
drm_connector_update_edid_property(connector, override);
num_modes = drm_add_edid_modes(connector, override);
@@ -2245,12 +2253,13 @@ struct edid *drm_do_get_edid(struct drm_connector
*connector,
enum edid_block_status status;
int i, invalid_blocks = 0;
struct edid *edid, *new;
+ size_t alloc_size = EDID_LENGTH;
- edid = drm_get_override_edid(connector);
+ edid = drm_get_override_edid(connector, _size);
if (edid)
goto ok;
- edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
+ edid = kmalloc(alloc_size, GFP_KERNEL);
if (!edid)
return NULL;
@@ -2278,7 +2287,8 @@ struct edid *drm_do_get_edid(struct drm_connector
*connector,
if (!edid_extension_block_count(edid))
goto ok;
- new = krealloc(edid, edid_size(edid), GFP_KERNEL);
+ alloc_size = edid_size(edid);
+ new = krealloc(edid, alloc_size, GFP_KERNEL);
if (!new)
goto fail;
edid = new;
@@ -2300,7 +2310,8 @@ struct edid *drm_do_get_edid(struct drm_connector
*connector,
if (invalid_blocks) {
connector_bad_edid(connector, edid, edid_block_count(edid));
- edid = edid_filter_invalid_blocks(edid, invalid_blocks);
+ edid = edid_filter_invalid_blocks(edid, invalid_blocks,
+ _size);
}
ok:
--
2.30.2
[Intel-gfx] [PATCH v1 01/13] drm/edid: add block count and data helper functions for drm_edid
Add drm_edid based block count and data access helper functions that
take the EDID allocated size into account.
At the moment, the allocated size should always match the EDID size
indicated by the extension count, but this will change in the future.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 42 +++---
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 929fc0e46751..682d954a9e42 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1613,6 +1613,35 @@ static const void *edid_extension_block_data(const
struct edid *edid, int index)
return edid_block_data(edid, index + 1);
}
+static int drm_edid_block_count(const struct drm_edid *drm_edid)
+{
+ int num_blocks;
+
+ /* Starting point */
+ num_blocks = edid_block_count(drm_edid->edid);
+
+ /* Limit by allocated size */
+ num_blocks = min(num_blocks, (int)drm_edid->size / EDID_LENGTH);
+
+ return num_blocks;
+}
+
+static int drm_edid_extension_block_count(const struct drm_edid *drm_edid)
+{
+ return drm_edid_block_count(drm_edid) - 1;
+}
+
+static const void *drm_edid_block_data(const struct drm_edid *drm_edid, int
index)
+{
+ return edid_block_data(drm_edid->edid, index);
+}
+
+static const void *drm_edid_extension_block_data(const struct drm_edid
*drm_edid,
+int index)
+{
+ return edid_extension_block_data(drm_edid->edid, index);
+}
+
/*
* Initializer helper for legacy interfaces, where we have no choice but to
* trust edid size. Not for general purpose use.
@@ -1665,8 +1694,8 @@ static const void *__drm_edid_iter_next(struct
drm_edid_iter *iter)
if (!iter->drm_edid)
return NULL;
- if (iter->index < edid_block_count(iter->drm_edid->edid))
- block = edid_block_data(iter->drm_edid->edid, iter->index++);
+ if (iter->index < drm_edid_block_count(iter->drm_edid))
+ block = drm_edid_block_data(iter->drm_edid, iter->index++);
return block;
}
@@ -3574,22 +3603,21 @@ static int add_detailed_modes(struct drm_connector
*connector,
const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
int ext_id, int *ext_index)
{
- const struct edid *edid = drm_edid ? drm_edid->edid : NULL;
const u8 *edid_ext = NULL;
int i;
/* No EDID or EDID extensions */
- if (!edid || !edid_extension_block_count(edid))
+ if (!drm_edid || !drm_edid_extension_block_count(drm_edid))
return NULL;
/* Find CEA extension */
- for (i = *ext_index; i < edid_extension_block_count(edid); i++) {
- edid_ext = edid_extension_block_data(edid, i);
+ for (i = *ext_index; i < drm_edid_extension_block_count(drm_edid); i++)
{
+ edid_ext = drm_edid_extension_block_data(drm_edid, i);
if (edid_block_tag(edid_ext) == ext_id)
break;
}
- if (i >= edid_extension_block_count(edid))
+ if (i >= drm_edid_extension_block_count(drm_edid))
return NULL;
*ext_index = i + 1;
--
2.30.2
[Intel-gfx] [PATCH v1 00/13] drm/edid: expand on struct drm_edid usage
Hey all, I'm adding a bunch of people to the cover letter, sorry for the
noise.
I've been putting a lot of effort lately into cleaning up our EDID
parsing. It's been long overdue. Here, we finally leverage all that prep
work to implement the HDMI Forum HF-EEODB extension. In short, HF-EEODB
lets an EDID extension override the number of extensions indicated in
the base block. That has a lot of implications when it comes to EDID
parsing and memory allocation that is currently spread around the
subsystem.
I've added the opaque struct drm_edid in commit e4ccf9a777d3 ("drm/edid:
add struct drm_edid container"). The commit message is worth a
read. Here, I'm expanding struct drm_edid to the interfaces for EDID
reading and parsing. They all get an overhaul, along with the probe
helper .get_modes() hook.
In my mind, there is really no alternative to centralizing the EDID
parsing, and hiding the details in drm_edid.c.
I'm also adding a TODO entry; there's still a bunch of work to be done
across the subsystem.
BR,
Jani.
Cc: Adam Jackson
Cc: Alex Deucher
Cc: Andrzej Hajda
Cc: Ben Skeggs
Cc: Christian König
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Harry Wentland
Cc: Karol Herbst
Cc: Laurent Pinchart
Cc: Lyude Paul
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Thomas Zimmermann
Cc: Ville Syrjälä
Cc: Xinhui Pan
Cc: amd-...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Jani Nikula (13):
drm/edid: add block count and data helper functions for drm_edid
drm/edid: keep track of alloc size in drm_do_get_edid()
drm/edid: add new interfaces around struct drm_edid
drm/edid: add drm_edid_connector_update()
drm/probe-helper: abstract .get_modes() connector helper call
drm/probe-helper: make .get_modes() optional, add default action
drm/probe-helper: add .get_edid() callback
drm/edid: add drm_edid_raw() to access the raw EDID data
drm/i915/edid: convert DP, HDMI and LVDS to drm_edid
drm/edid: do invalid block filtering in-place
drm/edid: add HF-EEODB support to EDID read and allocation
drm/edid: take HF-EEODB extension count into account
drm/todo: add entry for converting the subsystem to struct drm_edid
Documentation/gpu/todo.rst| 25 +
drivers/gpu/drm/drm_connector.c | 2 +
drivers/gpu/drm/drm_edid.c| 538 --
drivers/gpu/drm/drm_probe_helper.c| 48 +-
.../gpu/drm/i915/display/intel_connector.c| 4 +-
.../drm/i915/display/intel_display_types.h| 4 +-
drivers/gpu/drm/i915/display/intel_dp.c | 72 +--
drivers/gpu/drm/i915/display/intel_hdmi.c | 26 +-
drivers/gpu/drm/i915/display/intel_lvds.c | 35 +-
include/drm/drm_edid.h| 12 +
include/drm/drm_modeset_helper_vtables.h | 19 +
11 files changed, 650 insertions(+), 135 deletions(-)
--
2.30.2
Re: [Intel-gfx] [PATCH] drm/i915/hwconfig: Report no hwconfig support on ADL-N
On 23.05.2022 09:51, Balasubramani Vivekanandan wrote:
ADL-N being a subplatform of ADL-P, it lacks support for hwconfig
table. Explicit check added to skip ADL-N.
Signed-off-by: Balasubramani Vivekanandan
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
index 79c66b6b51a3..5aaa3948de74 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -94,7 +94,7 @@ static int guc_hwconfig_fill_buffer(struct intel_guc *guc,
struct intel_hwconfig
static bool has_table(struct drm_i915_private *i915)
{
- if (IS_ALDERLAKE_P(i915))
+ if (IS_ALDERLAKE_P(i915) && !IS_ADLP_N(i915))
return true;
if (IS_DG2(i915))
return true;
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: Catch and log more unexpected values in DG1_MSTR_TILE_INTR
== Series Details == Series: drm/i915/dg2: Catch and log more unexpected values in DG1_MSTR_TILE_INTR URL : https://patchwork.freedesktop.org/series/104305/ State : success == Summary == CI Bug Log - changes from CI_DRM_11693 -> Patchwork_104305v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/index.html Participating hosts (44 -> 46) -- Additional (4): fi-tgl-u2 bat-adlm-1 fi-icl-u2 bat-dg1-5 Missing(2): bat-dg2-8 fi-rkl-11600 Known issues Here are the changes found in Patchwork_104305v1 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@write: - bat-dg1-5: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/bat-dg1-5/igt@fb...@write.html * igt@gem_huc_copy@huc-copy: - fi-tgl-u2: NOTRUN -> [SKIP][2] ([i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html - fi-icl-u2: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#4083]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4077]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#4079]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/bat-dg1-5/igt@gem_tiled_pread_basic.html * igt@i915_module_load@reload: - fi-kbl-soraka: [PASS][8] -> [DMESG-WARN][9] ([i915#1982]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-kbl-soraka/igt@i915_module_l...@reload.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/fi-kbl-soraka/igt@i915_module_l...@reload.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-5: NOTRUN -> [SKIP][10] ([i915#1155]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@hangcheck: - bat-dg1-6: [PASS][11] -> [DMESG-FAIL][12] ([i915#4494] / [i915#4957]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html * igt@i915_suspend@basic-s2idle-without-i915: - bat-dg1-5: NOTRUN -> [INCOMPLETE][13] ([i915#6011]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html * igt@i915_suspend@basic-s3-without-i915: - fi-icl-u2: NOTRUN -> [SKIP][14] ([i915#5903]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/fi-icl-u2/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#4215]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_addfb_basic@tile-pitch-mismatch: - bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#4212]) +7 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/bat-dg1-5/igt@kms_addfb_ba...@tile-pitch-mismatch.html * igt@kms_busy@basic: - bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#4303]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/bat-dg1-5/igt@kms_b...@basic.html * igt@kms_busy@basic@flip: - fi-tgl-u2: NOTRUN -> [DMESG-WARN][18] ([i915#402]) +2 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/fi-tgl-u2/igt@kms_busy@ba...@flip.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-hsw-4770:NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html - fi-blb-e6850: NOTRUN -> [SKIP][20] ([fdo#109271]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104305v1/fi-blb-e6850/igt@kms_chamel...@common-hpd-after-suspend.html *
Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
On 20/05/2022 01:52, Zanoni, Paulo R wrote: On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote: VM_BIND design document with description of intended use cases. v2: Add more documentation and format as per review comments from Daniel. Signed-off-by: Niranjana Vishwanathapura --- diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst new file mode 100644 index ..f1be560d313c --- /dev/null +++ b/Documentation/gpu/rfc/i915_vm_bind.rst @@ -0,0 +1,304 @@ +== +I915 VM_BIND feature design and use cases +== + +VM_BIND feature + +DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer +objects (BOs) or sections of a BOs at specified GPU virtual addresses on a +specified address space (VM). These mappings (also referred to as persistent +mappings) will be persistent across multiple GPU submissions (execbuff calls) +issued by the UMD, without user having to provide a list of all required +mappings during each submission (as required by older execbuff mode). + +VM_BIND/UNBIND ioctls will support 'in' and 'out' fences to allow userpace +to specify how the binding/unbinding should sync with other operations +like the GPU job submission. These fences will be timeline 'drm_syncobj's +for non-Compute contexts (See struct drm_i915_vm_bind_ext_timeline_fences). +For Compute contexts, they will be user/memory fences (See struct +drm_i915_vm_bind_ext_user_fence). + +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND. +User has to opt-in for VM_BIND mode of binding for an address space (VM) +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. + +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the mapping in an +async worker. The binding and unbinding will work like a special GPU engine. +The binding and unbinding operations are serialized and will wait on specified +input fences before the operation and will signal the output fences upon the +completion of the operation. Due to serialization, completion of an operation +will also indicate that all previous operations are also complete. + +VM_BIND features include: + +* Multiple Virtual Address (VA) mappings can map to the same physical pages + of an object (aliasing). +* VA mapping can map to a partial section of the BO (partial binding). +* Support capture of persistent mappings in the dump upon GPU error. +* TLB is flushed upon unbind completion. Batching of TLB flushes in some + use cases will be helpful. +* Asynchronous vm_bind and vm_unbind support with 'in' and 'out' fences. +* Support for userptr gem objects (no special uapi is required for this). + +Execbuff ioctl in VM_BIND mode +--- +The execbuff ioctl handling in VM_BIND mode differs significantly from the +older method. A VM in VM_BIND mode will not support older execbuff mode of +binding. In VM_BIND mode, execbuff ioctl will not accept any execlist. Hence, +no support for implicit sync. It is expected that the below work will be able +to support requirements of object dependency setting in all use cases: + +"dma-buf: Add an API for exporting sync files" +(https://lwn.net/Articles/859290/) I would really like to have more details here. The link provided points to new ioctls and we're not very familiar with those yet, so I think you should really clarify the interaction between the new additions here. Having some sample code would be really nice too. For Mesa at least (and I believe for the other drivers too) we always have a few exported buffers in every execbuf call, and we rely on the implicit synchronization provided by execbuf to make sure everything works. The execbuf ioctl also has some code to flush caches during implicit synchronization AFAIR, so I would guess we rely on it too and whatever else the Kernel does. Is that covered by the new ioctls? In addition, as far as I remember, one of the big improvements of vm_bind was that it would help reduce ioctl latency and cpu overhead. But if making execbuf faster comes at the cost of requiring additional ioctls calls for implicit synchronization, which is required on ever execbuf call, then I wonder if we'll even get any faster at all. Comparing old execbuf vs plain new execbuf without the new required ioctls won't make sense. But maybe I'm wrong and we won't need to call these new ioctls around every single execbuf ioctl we submit? Again, more clarification and some code examples here would be really nice. This is a big change on an important part of the API, we should clarify the new expected usage. Hey Paulo, I think in the case of X11/Wayland, we'll be doing 1 or 2 extra ioctls per frame which seems pretty reasonable. Essentially we need to set the dependencies on the buffer we´re going to tell the display engine (gnome-shell/kde/bare-display-hw) to use. In the Vulkan case, we're
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Complete and clarify per client usage stats documentation
== Series Details == Series: drm/i915: Complete and clarify per client usage stats documentation URL : https://patchwork.freedesktop.org/series/104297/ State : success == Summary == CI Bug Log - changes from CI_DRM_11693_full -> Patchwork_104297v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 13) -- Additional (1): shard-rkl Known issues Here are the changes found in Patchwork_104297v1_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-2x: - shard-iclb: NOTRUN -> [SKIP][1] ([i915#1839]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/shard-iclb5/igt@feature_discov...@display-2x.html * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-kbl: [PASS][2] -> [DMESG-WARN][3] ([i915#180]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-kbl4/igt@gem_ctx_isolation@preservation...@vcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_eio@in-flight-suspend: - shard-kbl: [PASS][4] -> [INCOMPLETE][5] ([i915#3614]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-kbl1/igt@gem_...@in-flight-suspend.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/shard-kbl4/igt@gem_...@in-flight-suspend.html * igt@gem_exec_fair@basic-deadline: - shard-glk: NOTRUN -> [FAIL][6] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/shard-glk2/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-tglb: NOTRUN -> [FAIL][9] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/shard-tglb2/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][10] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_flush@basic-uc-set-default: - shard-snb: [PASS][13] -> [SKIP][14] ([fdo#109271]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-snb7/igt@gem_exec_fl...@basic-uc-set-default.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/shard-snb6/igt@gem_exec_fl...@basic-uc-set-default.html * igt@gem_lmem_swapping@basic: - shard-tglb: NOTRUN -> [SKIP][15] ([i915#4613]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/shard-tglb2/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@random: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/shard-apl6/igt@gem_lmem_swapp...@random.html * igt@gem_lmem_swapping@verify-random-ccs: - shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/shard-skl1/igt@gem_lmem_swapp...@verify-random-ccs.html * igt@gem_pxp@create-regular-context-1: - shard-iclb: NOTRUN -> [SKIP][18] ([i915#4270]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/shard-iclb5/igt@gem_...@create-regular-context-1.html * igt@gem_pxp@verify-pxp-stale-buf-optout-execution: - shard-tglb: NOTRUN -> [SKIP][19] ([i915#4270]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/shard-tglb2/igt@gem_...@verify-pxp-stale-buf-optout-execution.html * igt@gem_render_copy@yf-tiled-to-vebox-yf-tiled: - shard-iclb: NOTRUN -> [SKIP][20] ([i915#768]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/shard-iclb5/igt@gem_render_c...@yf-tiled-to-vebox-yf-tiled.html * igt@gem_userptr_blits@input-checking: - shard-skl: NOTRUN -> [DMESG-WARN][21] ([i915#4991]) [21]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dg2: Catch and log more unexpected values in DG1_MSTR_TILE_INTR
== Series Details == Series: drm/i915/dg2: Catch and log more unexpected values in DG1_MSTR_TILE_INTR URL : https://patchwork.freedesktop.org/series/104305/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] [PATCH] drm/i915/dg2: Catch and log more unexpected values in DG1_MSTR_TILE_INTR
From: Tvrtko Ursulin
Catch and log any garbage in the register, including no tiles marked, or
multiple tiles marked.
Signed-off-by: Tvrtko Ursulin
Cc: Matt Roper
---
We caught garbage in DG1_MSTR_TILE_INTR with DG2 (actual value 0xF9D2C008)
during glmark and more badness. So I thought lets log all possible failure
modes from here and also use per device logging.
---
drivers/gpu/drm/i915/i915_irq.c | 33 ++---
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 73cebc6aa650..79853d3fc1ed 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2778,24 +2778,30 @@ static irqreturn_t dg1_irq_handler(int irq, void *arg)
u32 gu_misc_iir;
if (!intel_irqs_enabled(i915))
- return IRQ_NONE;
+ goto none;
master_tile_ctl = dg1_master_intr_disable(regs);
- if (!master_tile_ctl) {
- dg1_master_intr_enable(regs);
- return IRQ_NONE;
+ if (!master_tile_ctl)
+ goto enable_none;
+
+ if (master_tile_ctl & ~(DG1_MSTR_IRQ | DG1_MSTR_TILE_MASK)) {
+ drm_warn(>drm, "Garbage in master_tile_ctl: 0x%08x!\n",
+master_tile_ctl);
+ goto enable_none;
}
/* FIXME: we only support tile 0 for now. */
- if (master_tile_ctl & DG1_MSTR_TILE(0)) {
- master_ctl = raw_reg_read(regs, GEN11_GFX_MSTR_IRQ);
- raw_reg_write(regs, GEN11_GFX_MSTR_IRQ, master_ctl);
- } else {
- DRM_ERROR("Tile not supported: 0x%08x\n", master_tile_ctl);
- dg1_master_intr_enable(regs);
- return IRQ_NONE;
+ if (REG_FIELD_GET(DG1_MSTR_TILE_MASK, master_tile_ctl) !=
+ DG1_MSTR_TILE(0)) {
+ drm_warn(>drm, "Unexpected irq from tile %u!\n",
+ilog2(REG_FIELD_GET(DG1_MSTR_TILE_MASK,
+master_tile_ctl)));
+ goto enable_none;
}
+ master_ctl = raw_reg_read(regs, GEN11_GFX_MSTR_IRQ);
+ raw_reg_write(regs, GEN11_GFX_MSTR_IRQ, master_ctl);
+
gen11_gt_irq_handler(gt, master_ctl);
if (master_ctl & GEN11_DISPLAY_IRQ)
@@ -2810,6 +2816,11 @@ static irqreturn_t dg1_irq_handler(int irq, void *arg)
pmu_irq_stats(i915, IRQ_HANDLED);
return IRQ_HANDLED;
+
+enable_none:
+ dg1_master_intr_enable(regs);
+none:
+ return IRQ_NONE;
}
/* Called from drm generic code, passed 'crtc' which
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d8579ab9384c..eefa301c6430 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5774,6 +5774,7 @@
#define DG1_MSTR_TILE_INTR _MMIO(0x190008)
#define DG1_MSTR_IRQ REG_BIT(31)
+#define DG1_MSTR_TILE_MASK REG_GENMASK(3, 0)
#define DG1_MSTR_TILE(t) REG_BIT(t)
#define GEN11_DISPLAY_INT_CTL _MMIO(0x44200)
--
2.32.0
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: fix typos in comments
== Series Details ==
Series: drm/i915: fix typos in comments
URL : https://patchwork.freedesktop.org/series/104296/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11693_full -> Patchwork_104296v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (12 -> 12)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104296v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_hdr@bpc-switch@pipe-a-hdmi-a-1}:
- {shard-dg1}:NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/shard-dg1-12/igt@kms_hdr@bpc-swi...@pipe-a-hdmi-a-1.html
Known issues
Here are the changes found in Patchwork_104296v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-2x:
- shard-iclb: NOTRUN -> [SKIP][2] ([i915#1839])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/shard-iclb6/igt@feature_discov...@display-2x.html
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#4793])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl7/igt@gem_ctx_isolation@preservation...@vcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/shard-skl4/igt@gem_ctx_isolation@preservation...@vcs0.html
* igt@gem_eio@in-flight-contexts-immediate:
- shard-apl: [PASS][5] -> [TIMEOUT][6] ([i915#3063])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-apl7/igt@gem_...@in-flight-contexts-immediate.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/shard-apl1/igt@gem_...@in-flight-contexts-immediate.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: NOTRUN -> [FAIL][7] ([i915#2846])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/shard-glk4/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-apl: [PASS][8] -> [FAIL][9] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-apl4/igt@gem_exec_fair@basic-n...@vcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/shard-apl3/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-tglb: NOTRUN -> [FAIL][12] ([i915#2842])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/shard-tglb8/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) +2 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html
* igt@gem_exec_flush@basic-wb-ro-before-default:
- shard-snb: [PASS][15] -> [SKIP][16] ([fdo#109271])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-snb4/igt@gem_exec_fl...@basic-wb-ro-before-default.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/shard-snb6/igt@gem_exec_fl...@basic-wb-ro-before-default.html
* igt@gem_lmem_swapping@basic:
- shard-tglb: NOTRUN -> [SKIP][17] ([i915#4613])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/shard-tglb8/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@random:
- shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613]) +2
similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/shard-apl3/igt@gem_lmem_swapp...@random.html
* igt@gem_lmem_swapping@verify-random-ccs:
- shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) +3
similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/shard-skl10/igt@gem_lmem_swapp...@verify-random-ccs.html
* igt@gem_pxp@create-regular-context-1:
- shard-iclb: NOTRUN -> [SKIP][20] ([i915#4270]) +1 similar issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/shard-iclb6/igt@gem_...@create-regular-context-1.html
* igt@gem_pxp@verify-pxp-stale-buf-optout-execution:
- shard-tglb: NOTRUN -> [SKIP][21]
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK
On 20/05/2022 21:42, Matt Roper wrote: On Fri, May 20, 2022 at 10:15:32AM +0100, Tvrtko Ursulin wrote: On 17/05/2022 04:20, Matt Roper wrote: Slice/subslice/EU information should be obtained via the topology queries provided by the I915_QUERY interface; let's turn off support for the old GETPARAM lookups on Xe_HP and beyond where we can't return meaningful values. The slice mask lookup is meaningless since Xe_HP doesn't support traditional slices (and we make no attempt to return the various new units like gslices, cslices, mslices, etc.) here. The subslice mask lookup is even more problematic; given the distinct masks for geometry vs compute purposes, the combined mask returned here is likely not what userspace would want to act upon anyway. The value is also limited to 32-bits by the nature of the GETPARAM ioctl which is sufficient for the initial Xe_HP platforms, but is unable to convey the larger masks that will be needed on other upcoming platforms. Finally, the value returned here becomes even less meaningful when used on multi-tile platforms where each tile will have its own masks. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/i915_getparam.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_getparam.c b/drivers/gpu/drm/i915/i915_getparam.c index c12a0adefda5..ac9767c56619 100644 --- a/drivers/gpu/drm/i915/i915_getparam.c +++ b/drivers/gpu/drm/i915/i915_getparam.c @@ -148,11 +148,19 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data, value = intel_engines_has_context_isolation(i915); break; case I915_PARAM_SLICE_MASK: + /* Not supported from Xe_HP onward; use topology queries */ + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) + return -EINVAL; + value = sseu->slice_mask; if (!value) return -ENODEV; break; case I915_PARAM_SUBSLICE_MASK: + /* Not supported from Xe_HP onward; use topology queries */ + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) + return -EINVAL; + /* Only copy bits from the first slice */ memcpy(, sseu->subslice_mask, min(sseu->ss_stride, (u8)sizeof(value))); Just in case lets run this by Jordan and Lionel since it affects DG2. Anyone else on the userspace side who might be affected? When I grep'd Mesa, I found two uses of I915_PARAM_SLICE_MASK and I915_PARAM_SUBSLICE_MASK: * oa_metrics_kernel_support: The topology query is used on gen10+ so the getparam code is only called on gen9 and below * getparam_topology: Invoked via intel_get_device_info_from_fd(). The topology query is attempted first. Only if that fails _and_ we're on a pre-gen10 platform does it fall back to GETPARAM. I also checked https://github.com/intel/compute-runtime and only see these being issued in one place: * HwInfoConfig::configureHwInfoDrm: Only used if drm->queryTopology() returns a failure first. I think those are the only relevant userspace for SSEU topology, so as far as I can tell nobody is still relying on the legacy getparams by the time we get to Xe_HP hardware. Sounds good to me - I also had a look at the media and compute drivers and couldn't find any use. However I still think it is best if UMD teams would ack this patch. Regards, Tvrtko
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Complete and clarify per client usage stats documentation
== Series Details ==
Series: drm/i915: Complete and clarify per client usage stats documentation
URL : https://patchwork.freedesktop.org/series/104297/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11693 -> Patchwork_104297v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/index.html
Participating hosts (44 -> 48)
--
Additional (4): fi-tgl-u2 fi-icl-u2 bat-atsm-1 bat-dg1-5
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104297v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_create@basic:
- {bat-atsm-1}: NOTRUN -> [SKIP][1] +153 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/bat-atsm-1/igt@gem_ctx_cre...@basic.html
* igt@i915_selftest@live@gt_mocs:
- {bat-atsm-1}: NOTRUN -> [FAIL][2] +35 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/bat-atsm-1/igt@i915_selftest@live@gt_mocs.html
Known issues
Here are the changes found in Patchwork_104297v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@write:
- bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#2582]) +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/bat-dg1-5/igt@fb...@write.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-icl-u2: NOTRUN -> [DMESG-WARN][4] ([i915#4890])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/fi-icl-u2/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_huc_copy@huc-copy:
- fi-tgl-u2: NOTRUN -> [SKIP][5] ([i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2: NOTRUN -> [SKIP][6] ([i915#2190])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_mmap@basic:
- bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#4083])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/bat-dg1-5/igt@gem_m...@basic.html
* igt@gem_tiled_fence_blits@basic:
- bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#4077]) +2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html
* igt@gem_tiled_pread_basic:
- bat-dg1-5: NOTRUN -> [SKIP][10] ([i915#4079]) +1 similar issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/bat-dg1-5/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5: NOTRUN -> [SKIP][11] ([i915#1155])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [PASS][12] -> [DMESG-FAIL][13] ([i915#4494] /
[i915#4957])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-5: NOTRUN -> [INCOMPLETE][14] ([i915#6011])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-icl-u2: NOTRUN -> [SKIP][15] ([i915#5903])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/fi-icl-u2/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#4215])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html
* igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#4212]) +7 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/bat-dg1-5/igt@kms_addfb_ba...@tile-pitch-mismatch.html
* igt@kms_busy@basic:
- bat-dg1-5: NOTRUN -> [SKIP][18] ([i915#4303])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104297v1/bat-dg1-5/igt@kms_b...@basic.html
* igt@kms_busy@basic@flip:
- fi-tgl-u2: NOTRUN -> [DMESG-WARN][19] ([i915#402]) +1 similar
issue
[19]:
Re: [Intel-gfx] [PATCH v1 2/2] drm/i915: Reject the atomic modeset if an associated Type-C port is disconnected
Hi Imre, > > On Fri, May 20, 2022 at 10:28:31AM +0300, Kasireddy, Vivek wrote: > > Hi Imre, > > [...] > > > > > > @@ -131,6 +137,20 @@ int intel_digital_connector_atomic_check(struct > drm_connector *conn, > > > > > > > > > > > > crtc_state = drm_atomic_get_new_crtc_state(state, > > > > > > new_state->crtc); > > > > > > > > > > > > + /* > > > > > > +* The spec says that it is not safe to use a disconnected > > > > > > Type-C port. > > > > > > +* Therefore, check to see if this connector is connected and > > > > > > reject > > > > > > +* the modeset if there is no sink detected. > > > > > > +*/ > > > > > > + if (dig_port && !dig_port->connected(encoder) && > > > > > > > > > > This check is racy, as right after dig_port->connected() returns true, > > > > > the port can become disconnected. > > > > > > > > [Kasireddy, Vivek] Given that, do you think the only way to reliably > > > > determine > > > > if the Type-C port has a sink is to check the live status and ignore > > > > dig_port- > >tc_mode? > > > > > > > > If that is the case, should I just add a function pointer to dig_port > > > > to call > > > > tc_port_live_status_mask()? Or, should I just change > > > > intel_tc_port_connected() > > > > to ignore dig_port->tc_mode like below: > > > > @@ -764,8 +764,7 @@ bool intel_tc_port_connected(struct intel_encoder > *encoder) > > > > > > > > intel_tc_port_lock(dig_port); > > > > > > > > - is_connected = tc_port_live_status_mask(dig_port) & > > > > - BIT(dig_port->tc_mode); > > > > + is_connected = tc_port_live_status_mask(dig_port); > > > > > > > > Or, are there any other elegant ways that you can think of to determine > > > > whether > > > > a tc port has a sink or not? > > > > > > I meant that I don't think there is a way to prevent a modeset on a > > > disconnected port. > > > > But we need to find a way right given that the spec clearly states that the > > driver > > must not use or access (PHY/FIA registers of) a disconnected tc port. > > The driver does not access the PHY/FIA regs on a disconnected port/PHY. [Kasireddy, Vivek] I think it does after the first patch in this series is applied if the userspace (Weston) forces a modeset on a disconnected tc legacy port (HDMI). For instance, some of the FIA/PHY regs accesses I noticed include programming the lane count (intel_tc_port_set_fia_lane_count() called by intel_ddi_pre_pll_enable()), reading the pin assignment mask (intel_tc_port_get_pin_assignment_mask() called by icl_program_mg_dp_mode() which is called by intel_ddi_pre_enable_hdmi()), etc. Of-course, these accesses would probably not occur if the disconnected tc port defaults to TBT mode but this brings other problems like I described in the commit description of the first patch and the cover letter. > > > > Live status is what provides the connected state, but > > > it can change right after it is read out. > > > > Does this change happen after giving up the ownership (in > > icl_tc_phy_disconnect)? > > The HPD live status changes whenever a user plugs/unplugs a sink. > > > But shouldn't we distinguish between the cases where we are > > deliberately disconnecting the phy for power-savings reason vs when > > the port actually becomes disconnected? The port can still be > > considered connected in the former case right? > > The driver - based on the spec - needs to avoid accessing the PHY/FIA > regs whenever the PHY is disconnected either by FW/HW (because the user > unplugged the sink) or the driver (during the suspend, modeset disable > sequence). [Kasireddy, Vivek] Regardless of whether the PHY/FIA regs are accessed or not, I don't think the driver should let the userspace's modeset to succeed on a disconnected tc port. Do you not agree? > > > Under what other situations would the live status change or become > > unreliable after the port has a connected sink? > > It's not unreliable, it reflects the state of a sink being plugged to > the connector or not. [Kasireddy, Vivek] Ok, assuming that the state of the sink is "connected" during intel_atomic_check() phase (which is where this patch checks for connected status), are you concerned about the case where the user may unplug the sink before we get to the intel_atomic_commit() phase? Is this what you meant when you said this earlier: "This check is racy, as right after dig_port->connected() returns true, the port can become disconnected"? I am just trying to figure out the scenarios when this might happen. > > > And, since we rely on SDEISR to detect the live status for tc legacy > > ports, could this not be considered reliable? > > Changes in the HPD live status is used as a hint to user space to > follow up with connector detection and modeset enable/disable requests > as necessary. [Kasireddy, Vivek] Right, that is the ideal case but user/userspace can commit mistakes where for example they can assume that HDMI-A-1 is connected (while it is not)
Re: [Intel-gfx] [PATCH] drm/i915: Update tiled blits selftest
On Mon, May 16, 2022 at 10:20:15AM +0200, Nirmoy Das wrote:
> From: Bommu Krishnaiah
>
> Update the selftest to include Tile 4 mode and switch to Tile 4 on
> platforms that supports Tile 4 but no Tile Y and vice versa.
> Also switch to XY_FAST_COPY_BLT on platforms that supports it.
>
> v4: update commit message to reflect the code changes properly.
> v3: add a function to find X-tile availability for a platform.
> v2: disable Tile X for iGPU in fastblit and
> fix checkpath --strict warnings.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5879
> Signed-off-by: Bommu Krishnaiah
> Co-developed-by: Nirmoy Das
> Signed-off-by: Nirmoy Das
I keep my rb if there're no other commit msg objections:
Reviewed-by: Zbigniew Kempczyński
--
Zbigniew
> ---
> .../i915/gem/selftests/i915_gem_client_blt.c | 250 ++
> drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 22 ++
> 2 files changed, 227 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> index ddd0772fd828..3cfc621ef363 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> @@ -6,6 +6,7 @@
> #include "i915_selftest.h"
>
> #include "gt/intel_context.h"
> +#include "gt/intel_engine_regs.h"
> #include "gt/intel_engine_user.h"
> #include "gt/intel_gpu_commands.h"
> #include "gt/intel_gt.h"
> @@ -18,10 +19,71 @@
> #include "huge_gem_object.h"
> #include "mock_context.h"
>
> +#define OW_SIZE 16 /* in bytes */
> +#define F_SUBTILE_SIZE 64 /* in bytes */
> +#define F_TILE_WIDTH 128/* in bytes */
> +#define F_TILE_HEIGHT 32/* in pixels */
> +#define F_SUBTILE_WIDTH OW_SIZE/* in bytes */
> +#define F_SUBTILE_HEIGHT 4 /* in pixels */
> +
> +static int linear_x_y_to_ftiled_pos(int x, int y, u32 stride, int bpp)
> +{
> + int tile_base;
> + int tile_x, tile_y;
> + int swizzle, subtile;
> + int pixel_size = bpp / 8;
> + int pos;
> +
> + /*
> + * Subtile remapping for F tile. Note that map[a]==b implies map[b]==a
> + * so we can use the same table to tile and until.
> + */
> + static const u8 f_subtile_map[] = {
> + 0, 1, 2, 3, 8, 9, 10, 11,
> + 4, 5, 6, 7, 12, 13, 14, 15,
> + 16, 17, 18, 19, 24, 25, 26, 27,
> + 20, 21, 22, 23, 28, 29, 30, 31,
> + 32, 33, 34, 35, 40, 41, 42, 43,
> + 36, 37, 38, 39, 44, 45, 46, 47,
> + 48, 49, 50, 51, 56, 57, 58, 59,
> + 52, 53, 54, 55, 60, 61, 62, 63
> + };
> +
> + x *= pixel_size;
> + /*
> + * Where does the 4k tile start (in bytes)? This is the same for Y and
> + * F so we can use the Y-tile algorithm to get to that point.
> + */
> + tile_base =
> + y / F_TILE_HEIGHT * stride * F_TILE_HEIGHT +
> + x / F_TILE_WIDTH * 4096;
> +
> + /* Find pixel within tile */
> + tile_x = x % F_TILE_WIDTH;
> + tile_y = y % F_TILE_HEIGHT;
> +
> + /* And figure out the subtile within the 4k tile */
> + subtile = tile_y / F_SUBTILE_HEIGHT * 8 + tile_x / F_SUBTILE_WIDTH;
> +
> + /* Swizzle the subtile number according to the bspec diagram */
> + swizzle = f_subtile_map[subtile];
> +
> + /* Calculate new position */
> + pos = tile_base +
> + swizzle * F_SUBTILE_SIZE +
> + tile_y % F_SUBTILE_HEIGHT * OW_SIZE +
> + tile_x % F_SUBTILE_WIDTH;
> +
> + GEM_BUG_ON(!IS_ALIGNED(pos, pixel_size));
> +
> + return pos / pixel_size * 4;
> +}
> +
> enum client_tiling {
> CLIENT_TILING_LINEAR,
> CLIENT_TILING_X,
> CLIENT_TILING_Y,
> + CLIENT_TILING_4,
> CLIENT_NUM_TILING_TYPES
> };
>
> @@ -45,6 +107,36 @@ struct tiled_blits {
> u32 height;
> };
>
> +static bool supports_x_tiling(const struct drm_i915_private *i915)
> +{
> + int gen = GRAPHICS_VER(i915);
> +
> + if (gen < 12)
> + return true;
> +
> + if (!HAS_LMEM(i915) || IS_DG1(i915))
> + return false;
> +
> + return true;
> +}
> +
> +static bool fast_blit_ok(const struct blit_buffer *buf)
> +{
> + int gen = GRAPHICS_VER(buf->vma->vm->i915);
> +
> + if (gen < 9)
> + return false;
> +
> + if (gen < 12)
> + return true;
> +
> + /* filter out platforms with unsupported X-tile support in fastblit */
> + if (buf->tiling == CLIENT_TILING_X &&
> !supports_x_tiling(buf->vma->vm->i915))
> + return false;
> +
> + return true;
> +}
> +
> static int prepare_blit(const struct tiled_blits *t,
> struct blit_buffer *dst,
> struct blit_buffer *src,
> @@ -59,51 +151,103 @@ static int prepare_blit(const struct tiled_blits *t,
> if
[Intel-gfx] [PATCH] drm/i915: Complete and clarify per client usage stats documentation
From: Tvrtko Ursulin Mention the compute engine which was recently added to the driver and also clarify that userspace should be written in a forward compatible way. Signed-off-by: Tvrtko Ursulin --- Documentation/gpu/i915.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 54060cd6c419..3e28b08ba6f6 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -723,5 +723,6 @@ the currently possible format options: drm-engine-capacity-video: 2 drm-engine-video-enhance: 0 ns -Possible `drm-engine-` key names are: `render`, `copy`, `video` and -`video-enhance`. +Possible `drm-engine-` key names are: `render`, `copy`, `video`, +`video-enhance` and `compute`. This list may not be complete and userspace +parsers should in any case handle new names appearing with new kernel releases. -- 2.32.0
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: fix typos in comments
== Series Details == Series: drm/i915: fix typos in comments URL : https://patchwork.freedesktop.org/series/104296/ State : success == Summary == CI Bug Log - changes from CI_DRM_11693 -> Patchwork_104296v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/index.html Participating hosts (44 -> 44) -- Additional (2): fi-tgl-u2 bat-dg1-5 Missing(2): fi-rkl-11600 fi-bdw-5557u Known issues Here are the changes found in Patchwork_104296v1 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@write: - bat-dg1-5: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/bat-dg1-5/igt@fb...@write.html * igt@gem_huc_copy@huc-copy: - fi-tgl-u2: NOTRUN -> [SKIP][2] ([i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#4083]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/bat-dg1-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#1155]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [PASS][7] -> [INCOMPLETE][8] ([i915#2940] / [i915#5801]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gem: - fi-pnv-d510:NOTRUN -> [DMESG-FAIL][9] ([i915#4528]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/fi-pnv-d510/igt@i915_selftest@l...@gem.html * igt@i915_selftest@live@gt_mocs: - fi-tgl-1115g4: [PASS][10] -> [DMESG-WARN][11] ([i915#2867]) +18 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.html * igt@i915_selftest@live@gt_pm: - fi-tgl-1115g4: [PASS][12] -> [DMESG-FAIL][13] ([i915#2867] / [i915#3987]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: NOTRUN -> [DMESG-FAIL][14] ([i915#4494] / [i915#4957]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html - bat-dg1-6: [PASS][15] -> [DMESG-FAIL][16] ([i915#4494] / [i915#4957]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html - fi-snb-2600:[PASS][17] -> [INCOMPLETE][18] ([i915#3921]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@i915_suspend@basic-s2idle-without-i915: - bat-dg1-5: NOTRUN -> [INCOMPLETE][19] ([i915#6011]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/bat-dg1-5/igt@i915_susp...@basic-s2idle-without-i915.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][20] ([i915#4215]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_addfb_basic@tile-pitch-mismatch: - bat-dg1-5: NOTRUN -> [SKIP][21] ([i915#4212]) +7 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104296v1/bat-dg1-5/igt@kms_addfb_ba...@tile-pitch-mismatch.html * igt@kms_busy@basic: - bat-dg1-5: NOTRUN -> [SKIP][22] ([i915#4303]) [22]:
Re: [Intel-gfx] [PATCH v4 0/6] i915: SSEU handling updates
On 21/05/2022 00:04, Matt Roper wrote:
This series reworks i915's internal handling of slice/subslice/EU (SSEU)
data to represent platforms like Xe_HP in a more natural manner and to
prepare for future platforms where the masks will need to grow in size.
One key idea of this series is that although we have a fixed ABI to
convey SSEU data to userspace (i.e., multiple u8[] arrays with data
stored at different strides), we don't need to use this cumbersome
format for the driver's own internal storage. As long as we can convert
into the uapi form properly when responding to the I915_QUERY ioctl,
it's preferable to use an internal storage format that's easier for the
driver to work with.
Another key point here is that we're reaching the point where subslice
(DSS) masks will soon not fit within simple u32/u64 integer values.
Xe_HP SDV and DG2 platforms today have subslice (DSS) masks that are 32
bits, which maxes out the current storage of a u32. With PVC the masks
are represented by a pair of 32-bit registers, requiring a bump up to at
least 64-bits of storage internally. We could switch to u64 for that in
the short term, but since we already know that upcoming architectures
intend to provide DSS fuse bits via three or more registers it's best to
switch to a representation that's more future-proof but still easy to
work with in the driver code. To accomodate this, we start storing our
subslice mask for Xe_HP and beyond in a new typedef that can be
processed by the linux/bitmap.h operations.
Finally, since no userspace for Xe_HP or beyond is using the legacy
I915_GETPARAM ioctl lookups for I915_PARAM_SLICE_MASK and
I915_PARAM_SUBSLICE_MASK (since they've migrated to the more flexible
I915_QUERY ioctl that can return more than a simple u32 value), we take
the opportunity to officially drop support for those GETPARAM lookups on
modern platforms. Maintaining support for these GETPARAM lookups don't
make sense for a number of reasons:
* Traditional slices no longer exist, and newer ideas like gslices,
cslices, mslices, etc. aren't something userspace needs to query
since it can be inferred from other information.
* The GETPARAM ioctl doesn't have a way to distinguish between geometry
subslice masks and compute subslice masks, which are distinct on
Xe_HP and beyond.
* The I915_GETPARAM ioctl is limited to returning a 32-bit value, so
when subslice masks begin to exceed 32-bits (on PVC), it simply can't
return the entire mask.
* The GETPARAM ioctl doesn't have a way to give sensible information
for multi-tile devices.
v2:
- Switch to union of hsw/xehp formats to keep the representation in a
natural format for different types of hardware.
- Avoid accessing internals of intel_sseu_ss_mask_t directly outside of
intel_sseu.[ch].
- Include PVC SSEU which needs the larger SS mask storage enabled by
this series.
v3:
- Correct a BIT(s) typo that should have been BIT(ss), causing
incorrect handling on gen9 platforms.
v4:
- Eliminate sseu->{ss,eu}_stride fields and just calculate the proper
value in the UAPI code that needs them.
- Handle unwanted ~u8 sign extension at the callsite instead of inside
sseu_set_eus.
- Use BITMAP_BITS() macro rather than passing I915_MAX_SS_FUSE_BITS
around directly to bitmap operations.
- Improved debugfs / dmesg reporting for Xe_HP dumps
- Various assertion check improvements.
Cc: Tvrtko Ursulin
Matt Roper (6):
drm/i915/xehp: Use separate sseu init function
drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK
drm/i915/sseu: Simplify gen11+ SSEU handling
drm/i915/sseu: Don't try to store EU mask internally in UAPI format
drm/i915/sseu: Disassociate internal subslice mask representation from
uapi
drm/i915/pvc: Add SSEU changes
For the series:
Acked-by: Tvrtko Ursulin
Almost r-b actually, but I do not feel completely comfortable that I
read everything closely enough to not have missed something. So I prefer
someone else does a really detailed pass to be sure.
Regards,
Tvrtko
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 12 +-
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_sseu.c | 450 ---
drivers/gpu/drm/i915/gt/intel_sseu.h | 94 ++--
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 30 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_getparam.c | 11 +-
drivers/gpu/drm/i915/i915_pci.c | 3 +-
drivers/gpu/drm/i915/i915_query.c| 26 +-
drivers/gpu/drm/i915/intel_device_info.h | 1 +
13 files changed, 398 insertions(+), 265 deletions(-)
Re: [Intel-gfx] [PATCH 09/14] ACPI: video: Make backlight class device registration a separate step
Hi, On 5/24/22 01:25, Daniel Dadap wrote: > On 5/20/22 16:41, Daniel Dadap wrote: >> >> On 5/17/22 10:23, Hans de Goede wrote: >>> On x86/ACPI boards the acpi_video driver will usually initializing before >>> the kms driver (except i915). This causes /sys/class/backlight/acpi_video0 >>> to show up and then the kms driver registers its own native backlight >>> device after which the drivers/acpi/video_detect.c code unregisters >>> the acpi_video0 device (when acpi_video_get_backlight_type()==native). >>> >>> This means that userspace briefly sees 2 devices and the disappearing of >>> acpi_video0 after a brief time confuses the systemd backlight level >>> save/restore code, see e.g.: >>> https://bbs.archlinux.org/viewtopic.php?id=269920 >>> >>> To fix this make backlight class device registration a separate step >>> done by a new acpi_video_register_backlight() function. The intend is for >>> this to be called by the drm/kms driver *after* it is done setting up its >>> own native backlight device. So that acpi_video_get_backlight_type() knows >>> if a native backlight will be available or not at acpi_video backlight >>> registration time, avoiding the add + remove dance. >> >> >> If I'm understanding this correctly, it seems we will want to call >> acpi_video_register_backlight() from the NVIDIA proprietary driver in a >> fallback path in case the driver's own GPU-controlled backlight handler >> either should not be used, or fails to register. That sounds reasonable >> enough, but I'm not sure what should be done about drivers like >> nvidia-wmi-ec-backlight, which are independent of the GPU hardware, and >> wouldn't be part of the acpi_video driver, either. There are a number of >> other similar vendor-y/platform-y type backlight drivers in >> drivers/video/backlight and drivers/platform/x86 that I think would be in a >> similar situation. >> >> From a quick skim of the ACPI video driver, it seems that perhaps >> nvidia-wmi-ec-backlight is missing a call to >> acpi_video_set_dmi_backlight_type(), perhaps with the acpi_backlight_vendor >> value? But I'm not familiar enough with this code to be sure that nobody >> will be checking acpi_video_get_backlight_type() before >> nvidia-wmi-ec-backlight loads. I'll take a closer look to try to convince >> myself that it makes sense. >> >> >>> Note the new acpi_video_register_backlight() function is also called from >>> a delayed work to ensure that the acpi_video backlight devices does get >>> registered if necessary even if there is no drm/kms driver or when it is >>> disabled. >> >> >> It sounds like maybe everything should be fine as long as >> nvidia-wmi-ec-backlight (and other vendor-y/platform-y type drivers) gets >> everything set up before the delayed work which calls >> acpi_video_register_backlight()? But then is it really necessary to >> explicitly call acpi_video_register_backlight() from the DRM drivers if it's >> going to be called later if no GPU driver registered a backlight handler, >> anyway? Then we'd just need to make sure that the iGPU and dGPU drivers >> won't attempt to register a backlight handler on systems where a >> vendor-y/platform-y driver is supposed to handle the backlight instead, >> which sounds like it has the potential to be quite messy. >> > > Ah, I see you addressed this concern in your RFC (sorry for missing that, > earlier): > >> The above only takes native vs acpi_video backlight issues into >> account, there are also a couple of other scenarios which may >> lead to multiple backlight-devices getting registered: >> >> 1) Apple laptops using the apple_gmux driver >> 2) Nvidia laptops using the (new) nvidia-wmi-ec-backlight driver >> 3) drivers/platform/x86 drivers calling acpi_video_set_dmi_backlight_type() >>to override the normal acpi_video_get_backlight_type() heuristics after >>the native/acpi_video drivers have already loaded >> >> The plan for 1) + 2) is to extend the acpi_backlight_type enum with >> acpi_backlight_gmux and acpi_backlight_nvidia_wmi_ec values and to add >> detection of these 2 to acpi_video_get_backlight_type(). > > Is there a reason these shouldn't have the same, generic, type, rather than > separate, driver-specific ones? In case it is not clear, this needs to be separate from "vendor" because vendor is meant for the old (often pre windows XP) vendor specific BIOS interfaces used by the likes of dell-laptopo, thinkpad_acpi, etc. And acpi_video_get_backlight_type() returns vendor when it cannot find any other types, iow it is the type of last resort. So vendor is the fallback where as nvidia_wmi_ec and apple_gmux both must take precedence over anything else if detected. As for why not have a single type for nvidia_wmi_ec and apple_gmux, these will have 2 separate detection helper functions, so it seems cleaner to me to use 2 separate types to match this. Most drivers check for type != my-type, so an extra type does not hurt. > I don't foresee any situation
[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: SSEU handling updates (rev2)
== Series Details == Series: i915: SSEU handling updates (rev2) URL : https://patchwork.freedesktop.org/series/104244/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11693_full -> Patchwork_104244v2_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_104244v2_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_104244v2_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (12 -> 12) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_104244v2_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live@dmabuf: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl4/igt@i915_selftest@l...@dmabuf.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl3/igt@i915_selftest@l...@dmabuf.html Known issues Here are the changes found in Patchwork_104244v2_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-skl: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22]) -> ([PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [FAIL][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44]) ([i915#5032]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl6/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl5/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl5/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl4/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl4/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl2/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl2/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl1/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl1/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl10/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl10/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl10/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl9/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl9/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl8/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl8/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl8/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl7/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl7/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/shard-skl6/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl6/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl4/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl4/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl3/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl3/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl3/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl2/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl1/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl1/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl10/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl10/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl9/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/shard-skl9/boot.html [37]:
[Intel-gfx] [PATCH] drm/i915: fix typos in comments
Spelling mistakes (triple letters) in comments.
Detected with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/i915/display/intel_color.c |2 +-
drivers/gpu/drm/i915/display/intel_pps.c |2 +-
drivers/gpu/drm/i915/gt/intel_execlists_submission.c |2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 34128c9c635c..a27ce874a9e8 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1638,7 +1638,7 @@ static u32 icl_gamma_mode(const struct intel_crtc_state
*crtc_state)
/*
* Enable 10bit gamma for D13
* ToDo: Extend to Logarithmic Gamma once the new UAPI
-* is acccepted and implemented by a userspace consumer
+* is accepted and implemented by a userspace consumer
*/
else if (DISPLAY_VER(i915) >= 13)
gamma_mode |= GAMMA_MODE_MODE_10BIT;
diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
b/drivers/gpu/drm/i915/display/intel_pps.c
index 5a598dd06039..4bc0563dde92 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -509,7 +509,7 @@ static void wait_panel_power_cycle(struct intel_dp
*intel_dp)
drm_dbg_kms(>drm, "Wait for panel power cycle\n");
- /* take the difference of currrent time and panel power off time
+ /* take the difference of current time and panel power off time
* and then make panel wait for t11_t12 if needed. */
panel_power_on_time = ktime_get_boottime();
panel_power_off_duration = ktime_ms_delta(panel_power_on_time,
intel_dp->pps.panel_power_off_time);
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 86f7a9ac1c39..aa0d2cc4 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1350,7 +1350,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
* submission. If we don't cancel the timer now,
* we will see that the timer has expired and
* reschedule the tasklet; continually until the
-* next context switch or other preeemption event.
+* next context switch or other preemption event.
*
* Since we have decided to reschedule based on
* consumption of this timeslice, if we submit the
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 78d2989fe917..02311ad90264 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -588,7 +588,7 @@ int intel_guc_log_relay_open(struct intel_guc_log *log)
/*
* We require SSE 4.1 for fast reads from the GuC log buffer and
* it should be present on the chipsets supporting GuC based
-* submisssions.
+* submissions.
*/
if (!i915_has_memcpy_from_wc()) {
ret = -ENXIO;
Re: [Intel-gfx] [PATCH v3] drm/i915: Enable Tile4 tiling mode
On Fri, May 13, 2022 at 10:47:54AM +0200, Nirmoy Das wrote:
> From: Bommu Krishnaiah
>
> Enable Tile4 tiling mode on platform that supports
> Tile4 but no TileY like DG2.
>
> v3: add a function to find X-tile availability for a platform.
> v2: disable X-tile for iGPU in fastblit
> fix checkpath --strict warnings
>
> Signed-off-by: Bommu Krishnaiah
> Co-developed-by: Nirmoy Das
> Signed-off-by: Nirmoy Das
Looks good for me, X is skipped on DG1 and integrated (gen12):
Reviewed-by: Zbigniew Kempczyński
--
Zbigniew
> ---
> .../i915/gem/selftests/i915_gem_client_blt.c | 250 ++
> drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 22 ++
> 2 files changed, 227 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> index ddd0772fd828..3cfc621ef363 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> @@ -6,6 +6,7 @@
> #include "i915_selftest.h"
>
> #include "gt/intel_context.h"
> +#include "gt/intel_engine_regs.h"
> #include "gt/intel_engine_user.h"
> #include "gt/intel_gpu_commands.h"
> #include "gt/intel_gt.h"
> @@ -18,10 +19,71 @@
> #include "huge_gem_object.h"
> #include "mock_context.h"
>
> +#define OW_SIZE 16 /* in bytes */
> +#define F_SUBTILE_SIZE 64 /* in bytes */
> +#define F_TILE_WIDTH 128/* in bytes */
> +#define F_TILE_HEIGHT 32/* in pixels */
> +#define F_SUBTILE_WIDTH OW_SIZE/* in bytes */
> +#define F_SUBTILE_HEIGHT 4 /* in pixels */
> +
> +static int linear_x_y_to_ftiled_pos(int x, int y, u32 stride, int bpp)
> +{
> + int tile_base;
> + int tile_x, tile_y;
> + int swizzle, subtile;
> + int pixel_size = bpp / 8;
> + int pos;
> +
> + /*
> + * Subtile remapping for F tile. Note that map[a]==b implies map[b]==a
> + * so we can use the same table to tile and until.
> + */
> + static const u8 f_subtile_map[] = {
> + 0, 1, 2, 3, 8, 9, 10, 11,
> + 4, 5, 6, 7, 12, 13, 14, 15,
> + 16, 17, 18, 19, 24, 25, 26, 27,
> + 20, 21, 22, 23, 28, 29, 30, 31,
> + 32, 33, 34, 35, 40, 41, 42, 43,
> + 36, 37, 38, 39, 44, 45, 46, 47,
> + 48, 49, 50, 51, 56, 57, 58, 59,
> + 52, 53, 54, 55, 60, 61, 62, 63
> + };
> +
> + x *= pixel_size;
> + /*
> + * Where does the 4k tile start (in bytes)? This is the same for Y and
> + * F so we can use the Y-tile algorithm to get to that point.
> + */
> + tile_base =
> + y / F_TILE_HEIGHT * stride * F_TILE_HEIGHT +
> + x / F_TILE_WIDTH * 4096;
> +
> + /* Find pixel within tile */
> + tile_x = x % F_TILE_WIDTH;
> + tile_y = y % F_TILE_HEIGHT;
> +
> + /* And figure out the subtile within the 4k tile */
> + subtile = tile_y / F_SUBTILE_HEIGHT * 8 + tile_x / F_SUBTILE_WIDTH;
> +
> + /* Swizzle the subtile number according to the bspec diagram */
> + swizzle = f_subtile_map[subtile];
> +
> + /* Calculate new position */
> + pos = tile_base +
> + swizzle * F_SUBTILE_SIZE +
> + tile_y % F_SUBTILE_HEIGHT * OW_SIZE +
> + tile_x % F_SUBTILE_WIDTH;
> +
> + GEM_BUG_ON(!IS_ALIGNED(pos, pixel_size));
> +
> + return pos / pixel_size * 4;
> +}
> +
> enum client_tiling {
> CLIENT_TILING_LINEAR,
> CLIENT_TILING_X,
> CLIENT_TILING_Y,
> + CLIENT_TILING_4,
> CLIENT_NUM_TILING_TYPES
> };
>
> @@ -45,6 +107,36 @@ struct tiled_blits {
> u32 height;
> };
>
> +static bool supports_x_tiling(const struct drm_i915_private *i915)
> +{
> + int gen = GRAPHICS_VER(i915);
> +
> + if (gen < 12)
> + return true;
> +
> + if (!HAS_LMEM(i915) || IS_DG1(i915))
> + return false;
> +
> + return true;
> +}
> +
> +static bool fast_blit_ok(const struct blit_buffer *buf)
> +{
> + int gen = GRAPHICS_VER(buf->vma->vm->i915);
> +
> + if (gen < 9)
> + return false;
> +
> + if (gen < 12)
> + return true;
> +
> + /* filter out platforms with unsupported X-tile support in fastblit */
> + if (buf->tiling == CLIENT_TILING_X &&
> !supports_x_tiling(buf->vma->vm->i915))
> + return false;
> +
> + return true;
> +}
> +
> static int prepare_blit(const struct tiled_blits *t,
> struct blit_buffer *dst,
> struct blit_buffer *src,
> @@ -59,51 +151,103 @@ static int prepare_blit(const struct tiled_blits *t,
> if (IS_ERR(cs))
> return PTR_ERR(cs);
>
> - *cs++ = MI_LOAD_REGISTER_IMM(1);
> - *cs++ = i915_mmio_reg_offset(BCS_SWCTRL);
> - cmd = (BCS_SRC_Y | BCS_DST_Y) << 16;
> - if (src->tiling == CLIENT_TILING_Y)
> -
