[Intel-gfx] [PATCH] drm/i915: Update HDMI max TMDS data rate definition for VBT
VBT version 212 defined HDMI max. bit-rate 2.97Gbps is 0x02 and 1.65Gbps is 0x04, so changed HDMI_MAX_DATA_RATE_297/HDMI_MAX_DATA_RATE_165 to map correct values Per VBT BSpec definition in HDMI max. data rate, Bits7-5 is HDMI max. data rate 000=Default, 001=2.97Gbps, 010=1.65Gbps, so HDMI_MAX_DATA_RATE_297 should be 2 and HDMI_MAX_DATA_RATE_165 should be 4 TEST: Validated PASS on GLK RVP platform Cc: Jani Nikula Signed-off-by: Chiou, Cooper --- drivers/gpu/drm/i915/intel_vbt_defs.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h b/drivers/gpu/drm/i915/intel_vbt_defs.h index bf3662ad5fed..e2b8d042912b 100644 --- a/drivers/gpu/drm/i915/intel_vbt_defs.h +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h @@ -307,8 +307,8 @@ struct bdb_general_features { #define DVO_PORT_MIPID 24 /* 171 */ #define HDMI_MAX_DATA_RATE_PLATFORM0 /* 204 */ -#define HDMI_MAX_DATA_RATE_297 1 /* 204 */ -#define HDMI_MAX_DATA_RATE_165 2 /* 204 */ +#define HDMI_MAX_DATA_RATE_297 2 /* 212 */ +#define HDMI_MAX_DATA_RATE_165 4 /* 212 */ #define LEGACY_CHILD_DEVICE_CONFIG_SIZE33 -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Update HDMI max TMDS data rate definition for VBT
Hi Ville, The bits is 5-7 means it’s 001x for 2.97Gbps, and 010x for 1.65Gbps. So correct value should be 2 not 1 for HDMI_MAX_DATA_RATE_297. And HDMI_MAX_DATA_RATE_165 is 4 not 2. I checked kernel i915 log and modified VBT to limit HDMI 1.4 from HDMI 2.0 then found this error. And I run CrOS on GLK with changed VBT to validate it. Thanks, Best Regards, Cooper On Apr 9, 2019, at 8:45 PM, Ville Syrjälä mailto:ville.syrj...@linux.intel.com>> wrote: On Tue, Apr 09, 2019 at 06:07:08PM +0800, Chiou, Cooper wrote: VBT version 212 defined HDMI max. bit-rate 2.97Gbps is 0x02 and 1.65Gbps is 0x04, so changed HDMI_MAX_DATA_RATE_297/HDMI_MAX_DATA_RATE_165 to map correct values Eh what? Did someone just change the interpretation of these bits? Per VBT BSpec definition in HDMI max. data rate, Bits7-5 is HDMI max. data rate 000=Default, 001=2.97Gbps, 010=1.65Gbps, Here you're quoting the values we already use... so HDMI_MAX_DATA_RATE_297 should be 2 and HDMI_MAX_DATA_RATE_165 should be 4 ...but here you're using different values again? Which way is it? TEST: Validated PASS on GLK RVP platform Cc: Jani Nikula mailto:jani.nik...@intel.com>> Signed-off-by: Chiou, Cooper mailto:cooper.ch...@intel.com>> --- drivers/gpu/drm/i915/intel_vbt_defs.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h b/drivers/gpu/drm/i915/intel_vbt_defs.h index bf3662ad5fed..e2b8d042912b 100644 --- a/drivers/gpu/drm/i915/intel_vbt_defs.h +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h @@ -307,8 +307,8 @@ struct bdb_general_features { #define DVO_PORT_MIPID24/* 171 */ #define HDMI_MAX_DATA_RATE_PLATFORM0/* 204 */ -#define HDMI_MAX_DATA_RATE_2971/* 204 */ -#define HDMI_MAX_DATA_RATE_1652/* 204 */ +#define HDMI_MAX_DATA_RATE_2972/* 212 */ +#define HDMI_MAX_DATA_RATE_1654/* 212 */ #define LEGACY_CHILD_DEVICE_CONFIG_SIZE33 -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org<mailto:Intel-gfx@lists.freedesktop.org> https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Update HDMI max TMDS data rate definition for VBT
Hi Ville, From Intel BSpec, this is HDMI max data rate bits field definition as the following, and please find my experiment/log below. And as I knew, all platforms are using Default 000 for max data rate. (No any platform used 2.97/1.65 definition in VBT so far). That’s why I correct HDMI max. data rate definition to be right value in 2.97 & 1.65Gbps. Thanks, “HDMI max data rate and level shifter value” defined in BSpec: Bits 7 – 5 = HDMI Maximum Data Rate 000 = Default (Software should choose the maximum data rate as supported by platform BSpec) 001 = 2.97 GT/s 010 = 1.65 GT/s Bit 4 - 0 = HDMI Level shifter value selection Values differ from platform to platform 1. When I set HDMI TMDS = 2.97Gbps in GLK VBT, then i915 intel_bios.c parse_ddi_port() function got “hdmi_max_data_rate=2”. [cid:image003.jpg@01D4EFC8.6DB4F360] DEBUG kernel: [0.172359] [drm:intel_bios_init] Port B VBT info: DP:0 HDMI:1 DVI:1 EDP:0 CRT:0 DEBUG kernel: [0.172360] [drm:intel_bios_init] VBT HDMI level shift for port B: 8 DEBUG kernel: [0.172362] [drm:intel_bios_init] [Cooper] bdb_version=212 DEBUG kernel: [0.172363] [drm:intel_bios_init] [Cooper] hdmi_max_data_rate=2 DEBUG kernel: [0.172364] [drm:intel_bios_init] [Cooper] max_tmds_clock=165000 DEBUG kernel: [0.172365] [drm:intel_bios_init] VBT HDMI max TMDS clock for port B: 165000 kHz 2. When I set HDMI TMDS = 1,65Gbps in GLK VBT, then i915 intel_bios.c parse_ddi_port() function got “hdmi_max_data_rate=4”. DEBUG kernel: [0.172363] [drm:intel_bios_init] Port B VBT info: DP:0 HDMI:1 DVI:1 EDP:0 CRT:0 DEBUG kernel: [0.172364] [drm:intel_bios_init] VBT HDMI level shift for port B: 8 DEBUG kernel: [0.172365] [drm:intel_bios_init] [Cooper] bdb_version=212 DEBUG kernel: [0.172366] [drm:intel_bios_init] [Cooper] hdmi_max_data_rate=4 WARNING kernel: [0.172367] [ cut here ] WARNING kernel: [0.172369] Missing switch case (4) in parse_ddi_port Best Regards, Cooper +886-2-6622-1166 -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] Sent: Tuesday, April 9, 2019 23:57 PM To: Chiou, Cooper Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ; ch...@freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915: Update HDMI max TMDS data rate definition for VBT On Tue, Apr 09, 2019 at 03:46:20PM +0000, Chiou, Cooper wrote: > Hi Ville, > > The bits is 5-7 means it’s 001x for 2.97Gbps, and 010x for 1.65Gbps. > So correct value should be 2 not 1 for HDMI_MAX_DATA_RATE_297. No. The bitfield is defined as something:3. > And HDMI_MAX_DATA_RATE_165 is 4 not 2. > > I checked kernel i915 log and modified VBT to limit HDMI 1.4 from HDMI > 2.0 then found this error. And I run CrOS on GLK with changed VBT to > validate it. Thanks, > > Best Regards, > Cooper > > On Apr 9, 2019, at 8:45 PM, Ville Syrjälä > mailto:ville.syrj...@linux.intel.com<mailto:ville.syrj...@linux.intel.com%3cmailto:ville.syrj...@linux.intel.com>>> > wrote: > > On Tue, Apr 09, 2019 at 06:07:08PM +0800, Chiou, Cooper wrote: > VBT version 212 defined HDMI max. bit-rate 2.97Gbps is 0x02 and > 1.65Gbps is 0x04, so changed > HDMI_MAX_DATA_RATE_297/HDMI_MAX_DATA_RATE_165 to map correct values > > Eh what? Did someone just change the interpretation of these bits? > > Per VBT BSpec definition in HDMI max. data rate, Bits7-5 is HDMI max. > data rate 000=Default, 001=2.97Gbps, 010=1.65Gbps, > > Here you're quoting the values we already use... > > so HDMI_MAX_DATA_RATE_297 > should be 2 and HDMI_MAX_DATA_RATE_165 should be 4 > > ...but here you're using different values again? Which way is it? > > > TEST: Validated PASS on GLK RVP platform > > Cc: Jani Nikula > mailto:jani.nik...@intel.com<mailto:jani.nik...@intel.com%3cmailto:jani.nik...@intel.com>>> > Signed-off-by: Chiou, Cooper > mailto:cooper.ch...@intel.com<mailto:cooper.ch...@intel.com%3cmailto:cooper.ch...@intel.com>>> > --- > drivers/gpu/drm/i915/intel_vbt_defs.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h > b/drivers/gpu/drm/i915/intel_vbt_defs.h > index bf3662ad5fed..e2b8d042912b 100644 > --- a/drivers/gpu/drm/i915/intel_vbt_defs.h > +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h > @@ -307,8 +307,8 @@ struct bdb_general_features { > #define DVO_PORT_MIPID24/* 171 */ > > #define HDMI_MAX_DATA_RATE_PLATFORM0/* 204 */ > -#define HDMI_MAX_DATA_RATE_2971/* 204 */ > -#define HDMI_MAX_DATA_RATE_1652/* 204 */ > +#define HDMI_MAX_DATA_RATE_2972
Re: [Intel-gfx] [PATCH] drm/i915: Update HDMI max TMDS data rate definition for VBT
Thanks Ville, I'll backport your patch (drm/i915/vbt: Fix HDMI level shifter and max data rate bitfield sizes) to CrOS kernel for resolving this issue. Please abandon my patch. Best Regards, Cooper ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm/i915] 04ff178484: phoronix-test-suite.supertuxkart.1024x768.Fullscreen.Ultimate.1.GranParadisoIsland.frames_per_second -30.4% regression
I run “phoronix-test-suite run supertuxkart-1.5.2” on my CML Ubuntu 18.04.5 LTS device, and compared the fps between patch and original upstream, there is no any fps performance drop issue. 5.10.0-rc3 upstream / 5.10.0-rc3+patch fps 12.586326 / 12.687711 Best Regards, Cooper +886-2-6622-1166 -Original Message- From: kernel test robot Sent: Monday, September 21, 2020 5:22 PM To: Chiou, Cooper Cc: intel-gfx@lists.freedesktop.org; Chiou, Cooper ; Tseng, William ; Nikula, Jani ; Chris Wilson ; lkp ; Ville Syrjälä ; Vivi, Rodrigo ; Tvrtko Ursulin ; Lee, Shawn C ; LKML ; l...@lists.01.org; Huang, Ying ; Tang, Feng ; Xing, Zhengjun ; Chen, Guobing ; Chen, Ming A ; Du, Frank ; Fan, Shuhua ; Guo, Wangyang ; Huang, Wenhuan ; Ji, Jessica ; Kang, Shan ; Li, Guangli ; Li, Tiejun ; Ma, Yu ; Mi, Dapeng1 ; Sun, Jiebin ; Xie, Gengxin ; Zhao, Fan Subject: [drm/i915] 04ff178484: phoronix-test-suite.supertuxkart.1024x768.Fullscreen.Ultimate.1.GranParadisoIsland.frames_per_second -30.4% regression Greeting, FYI, we noticed a -30.4% regression of phoronix-test-suite.supertuxkart.1024x768.Fullscreen.Ultimate.1.GranParadisoIsland.frames_per_second due to commit: commit: 04ff1784840f5f954a656c7e8795c76467e29128 ("[Intel-gfx] [PATCH] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9") url: https://github.com/0day-ci/linux/commits/Cooper-Chiou/drm-i915-Enable-WaProgramMgsrForCorrectSliceSpecificMmioReads-for-Gen9/20200917-021540 base: git://anongit.freedesktop.org/drm-intel for-linux-next in testcase: phoronix-test-suite on test machine: 4 threads Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz with 32G memory with following parameters: need_x: true test: supertuxkart-1.5.2 option_a: Fullscreen option_b: Ultimate option_c: 1 option_d: Gran Paradiso Island [Approximately 275k triangles; advanced graphics] cpufreq_governor: performance ucode: 0xd6 test-description: The Phoronix Test Suite is the most comprehensive testing and benchmarking platform available that provides an extensible framework for which new tests can be easily added. test-url: http://www.phoronix-test-suite.com/ If you fix the issue, kindly add following tag Reported-by: kernel test robot Details are as below: --> To reproduce: git clone https://github.com/intel/lkp-tests.git cd lkp-tests bin/lkp install job.yaml # job file is attached in this email bin/lkp run job.yaml = compiler/cpufreq_governor/kconfig/need_x/option_a/option_b/option_c/option_d/rootfs/tbox_group/test/testcase/ucode: gcc-9/performance/x86_64-rhel-8.3/true/Fullscreen/Ultimate/1/Gran Paradiso Island [Approximately 275k triangles; advanced graphics]/debian-x86_64-phoronix/lkp-kbl-nuc1/supertuxkart-1.5.2/phoronix-test-suite/0xd6 commit: 400d4953f1 ("drm/i915/pll: Centralize PLL_ENABLE register lookup") 04ff178484 ("drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9") 400d4953f1f434d5 04ff1784840f5f954a656c7e879 --- %stddev %change %stddev \ |\ 35.32 -30.4% 24.59 phoronix-test-suite.supertuxkart.1024x768.Fullscreen.Ultimate.1.GranParadisoIsland.frames_per_second 3638 ± 15% -39.2% 2211 ± 4% phoronix-test-suite.time.involuntary_context_switches 32.00 -30.5% 22.25 phoronix-test-suite.time.percent_of_cpu_this_job_got 36 +--+ |.+.+..+.+.+.+..+.+.+.+.+..+.+.+.+..+.+.+.+.+..+.+.+.+.+..+ +.+..+.+.| 34 |-+| | | | | 32 |-+| | | 30 |-+| | | 28 |-+| | | |
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 (rev2)
From this CI warning log, there are all known warning message in i915 driver and is not caused by my patch. Warning 1: <3> [69.081809] [drm:wa_verify [i915]] *ERROR* engine workaround lost on application! (reg[b004]=0x0, relevant bits were 0x0 vs expected 0x80) Warning 2: <3> [619.188270] i915/intel_lrc_live_selftests: live_lrc_isolation failed with error -22 Warning 3: <3> [282.248111] i915 :00:02.0: [drm] *ERROR* CPU pipe A FIFO underrun ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm/i915] 04ff178484: phoronix-test-suite.supertuxkart.1024x768.Fullscreen.Ultimate.1.GranParadisoIsland.frames_per_second -30.4% regression
Hi upstream committee, Please consider to merge this patch which resolved VP8 hardware encoding GPU hang critical issue on Gen9 sku, and there is no performance regression on this fix. Best Regards, Cooper -Original Message- From: kernel test robot Sent: Monday, February 8, 2021 8:46 AM To: Chiou, Cooper Cc: Tang, Feng ; Li, Tiejun ; Chris Wilson ; Du, Frank ; Chen, Guobing ; Tseng, William ; Xie, Gengxin ; Fan, Shuhua ; Zhao, Fan ; Huang, Ying ; Kang, Shan ; Xing, Zhengjun ; Huang, Wenhuan ; Nikula, Jani ; intel-gfx@lists.freedesktop.org; l...@lists.01.org; Chen, Ming A ; Ma, Yu ; Ji, Jessica ; Li, Guangli ; Guo, Wangyang ; Mi, Dapeng1 ; LKML ; Sun, Jiebin Subject: Re: [Intel-gfx] [drm/i915] 04ff178484: phoronix-test-suite.supertuxkart.1024x768.Fullscreen.Ultimate.1.GranParadisoIsland.frames_per_second -30.4% regression Hi all, The problem can't be reproduced after test environment changed, there's no regression found on this patch now, we don't know yet why it caused a regression in September 2020, but we'll continue to root cause. Best Regards, Rong Chen ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9
Hi upstream committee, Please consider to merge this patch which resolved VP8 hardware encoding GPU hang critical issue on Gen9 sku and there is no any performance regression on this fix. Meanwhile it's critical for Chrome projects need your help to review to merge it. Thanks, Best Regards, Cooper -Original Message- From: Chiou, Cooper Sent: Thursday, September 17, 2020 2:08 AM To: intel-gfx@lists.freedesktop.org Cc: Chiou, Cooper ; Ville Syrjälä ; Vivi, Rodrigo ; Nikula, Jani ; Chris Wilson ; Tvrtko Ursulin ; Tseng, William ; Lee, Shawn C Subject: [PATCH] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 WaProgramMgsrForCorrectSliceSpecificMmioReads applies for Gen9 to resolve VP8 hardware encoding system hang up on GT1 sku Reference: HSD#1508045018 Cc: Ville Syrjälä Cc: Rodrigo Vivi Cc: Jani Nikula Cc: Chris Wilson Cc: Tvrtko Ursulin Cc: William Tseng Cc: Lee Shawn C Signed-off-by: Cooper Chiou --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 5726cd0a37e0..53ea4359545b 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -935,9 +935,13 @@ hsw_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list *wal) wa_masked_en(wal, HALF_SLICE_CHICKEN3, HSW_SAMPLE_C_PERFORMANCE); } +static void wa_init_mcr(struct drm_i915_private *i915, struct +i915_wa_list *wal); + static void gen9_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list *wal) { + wa_init_mcr(i915, wal); + /* WaDisableKillLogic:bxt,skl,kbl */ if (!IS_COFFEELAKE(i915) && !IS_COMETLAKE(i915)) wa_write_or(wal, @@ -1040,7 +1044,7 @@ wa_init_mcr(struct drm_i915_private *i915, struct i915_wa_list *wal) unsigned int slice, subslice; u32 l3_en, mcr, mcr_mask; - GEM_BUG_ON(INTEL_GEN(i915) < 10); + GEM_BUG_ON(INTEL_GEN(i915) < 9); /* * WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl @@ -1049,7 +1053,7 @@ wa_init_mcr(struct drm_i915_private *i915, struct i915_wa_list *wal) * by default, to make sure we correctly read certain registers * later on (in the range 0xB100 - 0xB3FF). * -* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl +* WaProgramMgsrForCorrectSliceSpecificMmioReads:gen9,cnl,icl * Before any MMIO read into slice/subslice specific registers, MCR * packet control register needs to be programmed to point to any * enabled s/ss pair. Otherwise, incorrect values will be returned. -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9
Hi Tvrtko, This WaProgramMgsrForCorrectSliceSpecificMmioReads info can be found on bspec WA#0575 and it's necessary for GT subslice fuse sku on PC7 exit case while running VP8 hw encode, it impacted CrOS projects since google disabled VP8 HW encode feature on Gen9 sku, so that's why we need this patch. Best Regards, Cooper > > WaProgramMgsrForCorrectSliceSpecificMmioReads applies for Gen9 to > resolve VP8 hardware encoding system hang up on GT1 sku for ChromiumOS > projects > > Slice specific MMIO read inaccurate so MGSR needs to be programmed > appropriately to get correct reads from these slicet-related MMIOs. > > It dictates that before any MMIO read into Slice/Subslice specific registers, > MCR packet control register(0xFDC) needs to be programmed to point to > any enabled slice/subslice pair, especially GT1 fused sku since this issue can > be reproduced on VP8 hardware encoding via ffmpeg on ChromiumOS > devices. > When exit PC7, MGSR will reset so that we have to skip fused subslice ID. > > Reference: HSD#1508045018,1405586840, BSID#0575 > > Cc: Ville Syrjälä > Cc: Rodrigo Vivi > Cc: Jani Nikula > Cc: Chris Wilson > Cc: Tvrtko Ursulin > Cc: William Tseng > Cc: Lee Shawn C > > Signed-off-by: Cooper Chiou > --- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 38 > + > 1 file changed, 38 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index 3b4a7da60f0b..4ad598a727a6 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -878,9 +878,47 @@ hsw_gt_workarounds_init(struct drm_i915_private > *i915, struct i915_wa_list *wal) > wa_write_clr(wal, GEN7_FF_THREAD_MODE, > GEN7_FF_VS_REF_CNT_FFME); } > > +static void > +gen9_wa_init_mcr(struct drm_i915_private *i915, struct i915_wa_list > +*wal) { > + const struct sseu_dev_info *sseu = &i915->gt.info.sseu; > + unsigned int slice, subslice; > + u32 mcr, mcr_mask; > + > + GEM_BUG_ON(INTEL_GEN(i915) < 9); > + > + /* > + * WaProgramMgsrForCorrectSliceSpecificMmioReads:glk,kbl,cml > + * Before any MMIO read into slice/subslice specific registers, MCR > + * packet control register needs to be programmed to point to any > + * enabled s/ss pair. Otherwise, incorrect values will be returned. > + * This means each subsequent MMIO read will be forwarded to an > + * specific s/ss combination, but this is OK since these registers > + * are consistent across s/ss in almost all cases. In the rare > + * occasions, such as INSTDONE, where this value is dependent > + * on s/ss combo, the read should be done with read_subslice_reg. > + */ > + slice = fls(sseu->slice_mask) - 1; > + GEM_BUG_ON(slice >= ARRAY_SIZE(sseu->subslice_mask)); > + subslice = fls(intel_sseu_get_subslices(sseu, slice)); > + GEM_BUG_ON(!subslice); > + subslice--; > + > + mcr = GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice); > + mcr_mask = GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK; > + > + drm_dbg(&i915->drm, "MCR slice:%d/subslice:%d = %x\n", slice, > +subslice, mcr); > + > + wa_write_clr_set(wal, GEN8_MCR_SELECTOR, mcr_mask, mcr); } > + > static void > gen9_gt_workarounds_init(struct drm_i915_private *i915, struct > i915_wa_list *wal) { > + /* WaProgramMgsrForCorrectSliceSpecificMmioReads:glk,kbl,cml */ > + if (!IS_COFFEELAKE(i915)) > + gen9_wa_init_mcr(i915, wal); > + > /* WaDisableKillLogic:bxt,skl,kbl */ > if (!IS_COFFEELAKE(i915) && !IS_COMETLAKE(i915)) > wa_write_or(wal, > -- > 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 (rev2)
> <3> [198.221812] [drm:wa_verify [i915]] *ERROR* engine workaround lost > on application! (reg[b004]=0x0, relevant bits were 0x0 vs expected 0x80) <3> > [198.222751] [drm:wa_verify [i915]] *ERROR* engine workaround lost on > application! (reg[b118]=0x0, relevant bits were 0x0 vs expected 0x20) > <3> [198.223076] [drm:wa_verify [i915]] *ERROR* engine workaround lost > on application! (reg[b11c]=0x0, relevant bits were 0x0 vs expected 0x4) > > ? > > CI does not think they are old warnings and registers are the MCR affected > range. So more digging would be needed to be sure. You are saying those > happen in our CI without the patch? Hi Tvrtko, This patch only programmed 0xfdc register in reg[fdc]=0x1200, no touch reg[b004]=0x0 & reg[b118]=0x0 & reg[b11c]=0x0, so I don't think this error is caused by this change. This error might be due to wa_write_masked_or() Meanwhile, as you can see this 2 kbl devices has different CI result. 1. fi-kbl-7500u - no any error log - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19752/fi-kbl-7500u/igt@gem_exec_susp...@basic-s0.html 2. fi-kbl-7567u- has register read/write error log: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19752/fi-kbl-7567u/igt@gem_exec_susp...@basic-s0.html Cooper > > Then with regards to the reported perf drop - something to check would be if > the CML system you tested on has the same slice/subslice config as the one > from which the original report originated. Might be hard if the test farm has > been re-configured. But essentially running the benchmark on a few Gen9 > machine with fused ss would be needed I think. > > And finally I couldn't find the WA entry in bspec, but maybe I just don't know > where to look. Someone better versed to finding WA. Maybe Matt you would > have time for a quick check if > WaProgramMgsrForCorrectSliceSpecificMmioReads is documented as > applicable to Gen9? > > Regards, > > Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9
After switched to ffs from fls in "patch v5"(https://patchwork.freedesktop.org/series/81764/#rev7), now CI result is PASS no regression in wa_verify warning. @Chen, Rong Could you please run “phoronix-test-suite.supertuxkart.1024x768.Fullscreen.Ultimate.1.GranParadisoIsland.frames_per_second” with this latest patch v5 on test box to see if any performance impact. Thanks, Best Regards, Cooper > Quoting Tvrtko Ursulin (2021-03-05 09:23:02) > > I am not sure if PC8 and DMC could also be involved from what Cooper > > was saying in a different thread. Maybe another CI run without the > > DMC, both ffs and fls. Another for limiting cstates. > > Disabling the dmc leaves the display code in an inconsistent state so we don't > complete a BAT run; but since the warnings are thrown during boot we can > say that disabling the dmc does clear up the workaround issues on > ehl/jsl: > > https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7612/fi-ehl-2/boot0.txt > https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7612/fi-jsl-1/boot0.txt > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9
Hi Rong, Please help to trigger 3D performance test on several Gen9 CI test boxes which different fusing sku with/without “patch v5”. Thanks, Best Regards, Cooper > On Mar 6, 2021, at 12:01 AM, Tvrtko Ursulin > wrote: > > >> On 05/03/2021 15:24, Chiou, Cooper wrote: >> After switched to ffs from fls in "patch >> v5"(https://patchwork.freedesktop.org/series/81764/#rev7), now CI result is >> PASS no regression in wa_verify warning. >> @Chen, Rong >> Could you please run >> “phoronix-test-suite.supertuxkart.1024x768.Fullscreen.Ultimate.1.GranParadisoIsland.frames_per_second” >> with this latest patch v5 on test box to see if any performance impact. > > We need testing on more that one box I'm afraid. Need to cover different > fusing configs of Gen9 with and without the patch. I don't have any useful > ideas on how to do it though. :( > > Regards, > > Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9
Hi Rong, Please help to trigger 3D performance test on several Gen9 CI test boxes which different fusing sku with/without “patch v5”, and share the results. Thanks, Best Regards, Cooper ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9
I've tested on GLK, KBL, CFL Intel NUC devices and got the following performance results, there is no performance regression per my testing. Patch: [v5] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 Test suite: phoronix-test-suite.supertuxkart.1024x768.Fullscreen.Ultimate.1.GranParadisoIsland.frames_per_second Kernel version: 5.12.0-rc1 (drm-tip) a. Device: Intel NUC kit NUC7JY Gemini Lake Celeron J4005 @2.7GHz (2 Cores) Without patch, fps=57.45 With patch, fps=57.49 b. Device: Intel NUC kit NUC8BEH Coffee Lake Core i3-8109U @3.6GHz(4 Cores) Without patch, fps=117.23 With patch, fps=117.27 c. Device: Intel NUC kit NUC7i3BNH Kaby Lake Core i3-7100U @2.4GHz(4 Cores) Without patch, fps=114.05 With patch, fps=114.34 Meanwhile, Intel lkp team has validated performance on lkp-kbl-nuc1 and no regression. f69d02e37a85645a d912096c40cdc3bc9364966971 testcase/testparams/testbox -- --- %stddev change %stddev \ |\ 29.79 29.67 phoronix-test-suite/performance-true-Fullscreen-Ultimate-1-Gran_Paradiso_Island__Approxima-supertuxkart-1.5.2-ucode=0xde/lkp-kbl-nuc1 29.79 29.67GEO-MEAN phoronix-test-suite.supertuxkart.1280x1024.Fullscreen.Ultimate.1.GranParadisoIsland.frames_per_second Best Regards, Cooper > We need testing on more that one box I'm afraid. Need to cover different > fusing configs of Gen9 with and without the patch. I don't have any useful > ideas on how to do it though. :( > > Regards, > > Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9
I've tested on GLK, KBL, CFL Intel NUC devices and got the following performance results, there is no performance regression per my testing. and CI build test has passed as well. Patch: [v5] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 Test suite: phoronix-test-suite.supertuxkart.1024x768.Fullscreen.Ultimate.1.GranParadisoIsland.frames_per_second Kernel version: 5.12.0-rc1 (drm-tip) a. Device: Intel NUC kit NUC7JY Gemini Lake Celeron J4005 @2.7GHz (2 Cores) Without patch, fps=57.45 With patch, fps=57.49 b. Device: Intel NUC kit NUC8BEH Coffee Lake Core i3-8109U @3.6GHz(4 Cores) Without patch, fps=117.23 With patch, fps=117.27 c. Device: Intel NUC kit NUC7i3BNH Kaby Lake Core i3-7100U @2.4GHz(4 Cores) Without patch, fps=114.05 With patch, fps=114.34 Meanwhile, Intel lkp team has validated performance test on lkp-kbl-nuc1 and no regression as the following. f69d02e37a85645a d912096c40cdc3bc9364966971 testcase/testparams/testbox -- --- %stddev change %stddev \ |\ 29.79 29.67 phoronix-test-suite/performance-true-Fullscreen-Ultimate-1-Gran_Paradiso_Island__Approxima-supertuxkart-1.5.2-ucode=0xde/lkp-kbl-nuc1 29.79 29.67GEO-MEAN phoronix-test-suite.supertuxkart.1280x1024.Fullscreen.Ultimate.1.GranParadisoIsland.frames_per_second Hi Tvrtko, Please help to review this patch since this is urgent for Google Chrome KBL/CML/GLK projects. Best Regards, Cooper ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9
> From: Tvrtko Ursulin > Hi, > > On 08/03/2021 17:32, Chiou, Cooper wrote: > > I've tested on GLK, KBL, CFL Intel NUC devices and got the following > performance results, there is no performance regression per my testing. > > > > Patch: [v5] drm/i915: Enable > > WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 Test suite: > > phoronix-test-suite.supertuxkart.1024x768.Fullscreen.Ultimate.1.GranPa > > radisoIsland.frames_per_second > > Kernel version: 5.12.0-rc1 (drm-tip) > > > > a. Device: Intel NUC kit NUC7JY Gemini Lake Celeron J4005 @2.7GHz (2 > Cores) > > Without patch, fps=57.45 > > With patch, fps=57.49 > > b. Device: Intel NUC kit NUC8BEH Coffee Lake Core i3-8109U @3.6GHz(4 > Cores) > > Without patch, fps=117.23 > > With patch, fps=117.27 > > c. Device: Intel NUC kit NUC7i3BNH Kaby Lake Core i3-7100U @2.4GHz(4 > Cores) > > Without patch, fps=114.05 > > With patch, fps=114.34 > > > > Meanwhile, Intel lkp team has validated performance on lkp-kbl-nuc1 and > no regression. > > f69d02e37a85645a d912096c40cdc3bc9364966971 > > testcase/testparams/testbox > > -- --- > >%stddev change %stddev > >\ |\ > >29.79 29.67 > > phoronix-test-suite/performance-true-Fullscreen-Ultimate-1- > Gran_Paradiso_Island__Approxima-supertuxkart-1.5.2-ucode=0xde/lkp-kbl- > nuc1 > >29.79 29.67GEO-MEAN phoronix-test- > suite.supertuxkart.1280x1024.Fullscreen.Ultimate.1.GranParadisoIsland.fram > es_per_second > > > > CI results are green so that is good. > > Do the machines used for performance testing include unusual fusing? [Chiou, Cooper] Yes, this performance test included fusing sku as following NUC GLK Celeron Linux device, Intel NUC kit NUC7JY Gemini Lake Celeron J4005 @2.7GHz (2 Cores) Without patch, fps=57.45 With patch, fps=57.49 > Worrying thing is that we were never able to reproduce the reported > regression in house due lack of identical machine, right? [Chiou, Cooper] Yes, if device is core-i3/5/7 GT2, then hang issue isn’t able to reproduce due to there is no fused/disabled subslice0. But VP8 hw encoding GPU hang issue can be 100% reproduced on CML/KBL Pentium/Celeron GT1 sku, explain root cause as the following, on Chrome CML Pentium 6450u GT1 sku, we observed when system exit PC7 power state, MGSR(0xFDC) is reset to 0x1000, read its reg(fuse2:0x9120)=0x02988480 bit 20-23=1001 means subslice0/3 are fused disabled, it's defined in bspec as well. on CML core-i5 sku, reg(fuse2)=0x22889140 bit 20-23=1000 only subslice3 is fused. so we have to skip this "fused/disabled" subslice 0/3 on GT1 sku in i915, then use sublice 1 or 2 and re-program 0xFDC=0x1100 or 0x1200 since reg[0xfdc]=0x1000 to use subslice0, but sublice0 is fused/disabled, so once go this fused disabled subslice0 then GPU hang happened. In some OEM Linux projects, they only have core-i sku no Pentium/Celeron sku as I knew and vp8 hw encoding is rare to use on Ubuntu, as this two reasons then Linux didn't reproduce this fused subslice0 gpu hang issue before, but it does happen on Chrome projects. Cooper > Worrying thing is that we were never able to reproduce the reported > regression in house due lack of identical machine, right? Although I guess > avoiding hangs trumps performance. > > Regards, > > Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9
> The issue is that if the regression is reproducible it means that the > broadcast > mask is no longer correct (or never was, one or the other ;) And another w/a > is going astray because it depends on the previous undefined value of the > mcr. [Chiou, Cooper] I think we might focus on this w/a WaProgramMgsrForCorrectSliceSpecificMmioReads, this w/a is not only for CNL/ICL/TGL, but need to be applied in Gen9 as well. I'm ok to add wa_init_mcr() in gen9_gt_workarounds_init() as patch v1 to make it simple, and this patch can resolve Chrome VP8 hw encoding issue and no performance regression as well. > > Which raises the question as to whether the hang prevention seen here is > also because some other w/a (or other mmio) is not being applied to the > relevant units. Or vice versa. > > Either way there remains an underlying issue in that some register writes for > gen9 require mcr being set that were are not handling correctly. Changing the > mask here changing results elsewhere indicate that the issues are fully > addressed, and the fear that undoing some other mmio is going to introduce > other subtle hangs. And we are all blindly poking at the issue as no one has > access to the affected skus. > > What would be useful is if we print the value before changing it so that we > can see if we have any machines in CI where we are making significant > changes to the broadcast mask. > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9
> I was referring to the original performance regression report which came > from LKP which was on "i7-7567U" so Kabylake. Can yo find such machine to > test on? [Chiou, Cooper] Yes, lkp-tests team has tested this patch on lkp-kbl-nuc1 (KBL i7-7567U) as the following mail thread and there is no performance regression per their confirmed. From: Chen, Rong A Sent: Thursday, March 4, 2021 9:56 PM Hi Cooper, There's no regression with this patch: d912096c40cdc drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 f69d02e37a856 Merge tag 'misc-5.12-2021-03-02' of git://git.kernel.dk/linux-block f69d02e37a85645a d912096c40cdc3bc9364966971 testcase/testparams/testbox -- --- %stddev change %stddev \ |\ 29.79 29.67 phoronix-test-suite/performance-true-Fullscreen-Ultimate-1-Gran_Paradiso_Island__Approxima-supertuxkart-1.5.2-ucode=0xde/lkp-kbl-nuc1 29.79 29.67GEO-MEAN phoronix-test-suite.supertuxkart.1280x1024.Fullscreen.Ultimate.1.GranParadisoIsland.frames_per_second ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx