Re: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component intialization before audio driver use it
> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Thursday, March 29, 2018 7:56 PM > To: Shi, Yang A ; intel-gfx@lists.freedesktop.org > Cc: Shi, Yang A ; He, Bo > Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component > intialization > before audio driver use it > > Quoting Yang (2018-03-29 08:12:13) > > From: Yang Shi > > > > snd_hdac driver would use the component interface from i915 driver. > > if i915 driver do the audio component intialization too late, snd_hdac > > driver will meet ipanic. > > > > Signed-off-by: Bo He > > Signed-off-by: Yang Shi > > --- > > drivers/gpu/drm/i915/i915_drv.c | 2 -- > > drivers/gpu/drm/i915/intel_display.c | 2 ++ > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > b/drivers/gpu/drm/i915/i915_drv.c index 2f5209d..9d25d7e 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.c > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > @@ -1243,8 +1243,6 @@ static void i915_driver_register(struct > > drm_i915_private > *dev_priv) > > if (IS_GEN5(dev_priv)) > > intel_gpu_ips_init(dev_priv); > > > > - intel_audio_init(dev_priv); > > - > > /* > > * Some ports require correctly set-up hpd registers for detection > > to > > * work properly (leading to ghost connected connector > > status), e.g. VGA diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index f288bcc..a471c88 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -14468,6 +14468,8 @@ int intel_modeset_init(struct drm_device *dev) > > > > dev->mode_config.funcs = &intel_mode_funcs; > > > > + intel_audio_init(dev_priv); > > Has info->num_pipes been finalized yet? Does the component framework expose > the > device to the external clients (if so, it can not be done before we are > ready). > -Chris Yes, info->num_pipes is finalized yet. This audio component will be used in audio driver snd_hdac_i915_init. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: move audio component initialization before audio driver use it
== Series Details == Series: drm/i915: move audio component initialization before audio driver use it URL : https://patchwork.freedesktop.org/series/41428/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7a227be93975 drm/i915: move audio component initialization before audio driver use it -:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #15: And whole snd_soc_skl initialization will be failed, audio can't work normally total: 0 errors, 1 warnings, 0 checks, 16 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12
Op 10-04-18 om 04:37 schreef Srinivas, Vidya: > >> -Original Message- >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] >> Sent: Monday, April 9, 2018 5:15 PM >> To: Srinivas, Vidya ; intel- >> g...@lists.freedesktop.org >> Cc: Kamath, Sunil >> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12 >> >> Op 09-04-18 om 11:41 schreef Srinivas, Vidya: -Original Message- From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] Sent: Monday, April 9, 2018 2:38 PM To: Srinivas, Vidya ; intel- g...@lists.freedesktop.org Cc: Kamath, Sunil Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for NV12 Op 09-04-18 om 10:57 schreef Srinivas, Vidya: >> -Original Message- >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] >> Sent: Monday, April 9, 2018 2:04 PM >> To: Srinivas, Vidya ; intel- >> g...@lists.freedesktop.org >> Subject: Re: [Intel-gfx] [PATCH v1 00/14] Preparation patches for >> NV12 >> >> Op 09-04-18 om 05:40 schreef Vidya Srinivas: >>> Series contain preparation patches for NV12 support Enabling NV12 >>> KMD support will follow the series >>> >>> Chandra Konduru (3): >>> drm/i915: Set scaler mode for NV12 >>> drm/i915: Update format_is_yuv() to include NV12 >>> drm/i915: Upscale scaler max scale for NV12 >>> >>> Mahesh Kumar (9): >>> drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values >>> drm/i915/skl+: refactor WM calculation for NV12 >>> drm/i915/skl+: add NV12 in skl_format_to_fourcc >>> drm/i915/skl+: support verification of DDB HW state for NV12 >>> drm/i915/skl+: NV12 related changes for WM >>> drm/i915/skl+: pass skl_wm_level struct to wm compute func >>> drm/i915/skl+: make sure higher latency level has higher wm value >>> drm/i915/skl+: nv12 workaround disable WM level 1-7 >>> drm/i915/skl: split skl_compute_ddb function >>> >>> Vidya Srinivas (2): >>> drm/i915: Display WA 827 >>> drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg >>> >>> drivers/gpu/drm/i915/i915_drv.h | 10 +- >>> drivers/gpu/drm/i915/i915_reg.h | 5 + >>> drivers/gpu/drm/i915/intel_atomic.c | 14 +- >>> drivers/gpu/drm/i915/intel_display.c | 93 ++-- >>> drivers/gpu/drm/i915/intel_drv.h | 11 +- >>> drivers/gpu/drm/i915/intel_pm.c | 438 >> ++-- --- >> >>> drivers/gpu/drm/i915/intel_sprite.c | 7 +- >>> 7 files changed, 393 insertions(+), 185 deletions(-) >> This series looks good, so for any patches I missed: >> >> Reviewed-by: Maarten Lankhorst >> >> Do you have commit rights, or should I push them? > Thank you. I don’t have commit rights I think. > Also, Should I add your RB for all the patches and push them again? > I'll push them. :) >>> Thank you so much :) >>> >> Pushed! > Thank you so much. > > Regards > Vidya Found a bug in the application of the workaround, could you look at https://patchwork.freedesktop.org/patch/215928/ ? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component intialization before audio driver use it
>-Original Message- >From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >Sent: Thursday, March 29, 2018 9:16 PM >To: Chris Wilson ; Shi, Yang A >; >intel-gfx@lists.freedesktop.org >Cc: Shi, Yang A ; He, Bo >Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component >intialization >before audio driver use it > >On Thu, 29 Mar 2018, Chris Wilson wrote: >> Quoting Yang (2018-03-29 08:12:13) >>> From: Yang Shi >>> >>> snd_hdac driver would use the component interface from i915 driver. >>> if i915 driver do the audio component intialization too late, >>> snd_hdac driver will meet ipanic. >>> >>> Signed-off-by: Bo He >>> Signed-off-by: Yang Shi >>> --- >>> drivers/gpu/drm/i915/i915_drv.c | 2 -- >>> drivers/gpu/drm/i915/intel_display.c | 2 ++ >>> 2 files changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/i915/i915_drv.c >>> b/drivers/gpu/drm/i915/i915_drv.c index 2f5209d..9d25d7e 100644 >>> --- a/drivers/gpu/drm/i915/i915_drv.c >>> +++ b/drivers/gpu/drm/i915/i915_drv.c >>> @@ -1243,8 +1243,6 @@ static void i915_driver_register(struct >>> drm_i915_private >*dev_priv) >>> if (IS_GEN5(dev_priv)) >>> intel_gpu_ips_init(dev_priv); >>> >>> - intel_audio_init(dev_priv); >>> - >>> /* >>> * Some ports require correctly set-up hpd registers for detection >>> to >>> * work properly (leading to ghost connected connector >>> status), e.g. VGA diff --git a/drivers/gpu/drm/i915/intel_display.c >>> b/drivers/gpu/drm/i915/intel_display.c >>> index f288bcc..a471c88 100644 >>> --- a/drivers/gpu/drm/i915/intel_display.c >>> +++ b/drivers/gpu/drm/i915/intel_display.c >>> @@ -14468,6 +14468,8 @@ int intel_modeset_init(struct drm_device >>> *dev) >>> >>> dev->mode_config.funcs = &intel_mode_funcs; >>> >>> + intel_audio_init(dev_priv); >> >> Has info->num_pipes been finalized yet? Does the component framework >> expose the device to the external clients (if so, it can not be done >> before we are ready). > >Hmmh, the same patch seems to have been sent twice. I replied at [1]. > >BR, >Jani. issue: snd_soc_skl meet "failed to add i915 component master (-19)" when platform don't connect any display output. i915 do initialization before than skl_probe, but if there is no display output connect, in function drm_dp_dpcd_access, there is a 32 retry for aux i2c transactions. It will meet timeout and do usleep. Then skl_probe function will be scheduled. It will call snd_hdac_i915_init, and it will meet "failed to add i915 component master" error. And whole snd_soc_skl initialization will be failed, audio can't work normally anymore. So i915 driver need to move intel_audio_init at the beginning of intel_modeset_init. This will make sure i915_audio_component_init process before snd_hdac_i915_init call it. BR. Yang. > > >[1] 87k1tvciec.fsf@intel.com">http://mid.mail-archive.com/87k1tvciec.fsf@intel.com > > >> -Chris >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > >-- >Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: move audio component initialization before audio driver use it
== Series Details == Series: drm/i915: move audio component initialization before audio driver use it URL : https://patchwork.freedesktop.org/series/41428/ State : failure == Summary == Series 41428v1 drm/i915: move audio component initialization before audio driver use it https://patchwork.freedesktop.org/api/1.0/series/41428/revisions/1/mbox/ Possible new issues: Test kms_chamelium: Subgroup common-hpd-after-suspend: pass -> INCOMPLETE (fi-skl-6700k2) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-a: pass -> DMESG-WARN (fi-glk-j4005) Subgroup suspend-read-crc-pipe-c: pass -> DMESG-WARN (fi-glk-j4005) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (fi-glk-j4005) Known issues: Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (fi-glk-j4005) fdo#103359 Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (fi-glk-j4005) fdo#100368 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:440s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:448s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:382s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:538s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:299s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:514s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:524s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:514s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:414s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:565s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:510s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:576s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:426s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:317s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:540s fi-glk-j4005 total:285 pass:253 dwarn:3 dfail:0 fail:0 skip:29 time:492s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:425s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:472s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:433s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:471s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:461s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:509s fi-pnv-d510 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:661s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:451s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:535s fi-skl-6700k2total:207 pass:190 dwarn:0 dfail:0 fail:0 skip:16 fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:491s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:431s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:445s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:593s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:402s 617cdf0bd4fd2cb0dcc64ddf07fbb56572ba800a drm-tip: 2018y-04m-09d-19h-55m-54s UTC integration manifest 7a227be93975 drm/i915: move audio component initialization before audio driver use it == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8650/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tools/aubdump: Fix ISO C90 forbids mixed declarations and code warning
On 09/04/2018 18:03, Scott D Phillips wrote:
Tvrtko Ursulin writes:
From: Tvrtko Ursulin
Back to a clean build with no warnings, at least for me.
Why c90? If that's the language we mean to target then we should
probably add it to the build system so people with gcc 5.1 and later
will see the warnings too. fwiw, my build with clang 6 gives a couple
dozen warnings.
I am building under Ubuntu 17.10 with GCC 7.2.0. Normal configure &&
make, and get this warning. And since I can't spot that IGT is setting
the C standard explicitly, I guess that's the default.
This one is the only warning on my build btw.
Regards,
Tvrtko
Signed-off-by: Tvrtko Ursulin
Cc: Jordan Justen
Cc: Scott D Phillips
---
tools/aubdump.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tools/aubdump.c b/tools/aubdump.c
index 267061b0fc2b..2d2b6c607a43 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -394,10 +394,11 @@ gen8_emit_ggtt_pte_for_range(uint64_t start, uint64_t end)
entry_addr = start & ~(4096 - 1);
do {
+ uint64_t last_page_entry, num_entries;
+
page_num = entry_addr >> 21;
- uint64_t last_page_entry =
- min((page_num + 1) << 21, end_aligned);
- uint64_t num_entries = (last_page_entry - entry_addr) >> 12;
+ last_page_entry = min((page_num + 1) << 21, end_aligned);
+ num_entries = (last_page_entry - entry_addr) >> 12;
mem_trace_memory_write_header_out(
entry_addr >> 9, num_entries * GEN8_PTE_SIZE,
AUB_MEM_TRACE_MEMORY_ADDRESS_SPACE_GGTT_ENTRY);
--
2.14.1
___
igt-dev mailing list
igt-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component intialization before audio driver use it
On Tue, 10 Apr 2018, "Shi, Yang A" wrote: > issue: snd_soc_skl meet "failed to add i915 component master (-19)" > when platform don't connect any display output. > > i915 do initialization before than skl_probe, but if there is no > display output connect, in function drm_dp_dpcd_access, there is a 32 > retry for aux i2c transactions. It will meet timeout and do > usleep. Then skl_probe function will be scheduled. It will call > snd_hdac_i915_init, and it will meet "failed to add i915 component > master" error. And whole snd_soc_skl initialization will be failed, > audio can't work normally anymore. > > So i915 driver need to move intel_audio_init at the beginning of > intel_modeset_init. This will make sure i915_audio_component_init > process before snd_hdac_i915_init call it. We do intel_audio_init() and register the audio component when we are ready to handle the audio component calls. We are ready at i915_driver_register(). We are not ready at intel_modeset_init(). BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: set minimum CD clock to twice the BCLK.
On Mon, 09 Apr 2018, "Kumar, Abhay" wrote: > Dynamic cdclk is disabled in BIOS/GOP hence gop makes it to highest > clock i.e 316.8. Will attach logs with drm debug enabled in bug. > I am also inclined towards 192 which will make max cdclk.. Please also attach /sys/kernel/debug/dri/0/i915_vbt to the bug. It doesn't look like we look at the VBT dynamic cdclk field. Does dynamic debug disabled mean we should go for max? BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component intialization before audio driver use it
>-Original Message- >From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >Sent: Tuesday, April 10, 2018 3:57 PM >To: Shi, Yang A ; Chris Wilson >; >intel-gfx@lists.freedesktop.org >Cc: He, Bo >Subject: RE: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component >intialization >before audio driver use it > >On Tue, 10 Apr 2018, "Shi, Yang A" wrote: >> issue: snd_soc_skl meet "failed to add i915 component master (-19)" >> when platform don't connect any display output. >> >> i915 do initialization before than skl_probe, but if there is no >> display output connect, in function drm_dp_dpcd_access, there is a 32 >> retry for aux i2c transactions. It will meet timeout and do usleep. >> Then skl_probe function will be scheduled. It will call >> snd_hdac_i915_init, and it will meet "failed to add i915 component >> master" error. And whole snd_soc_skl initialization will be failed, >> audio can't work normally anymore. >> >> So i915 driver need to move intel_audio_init at the beginning of >> intel_modeset_init. This will make sure i915_audio_component_init >> process before snd_hdac_i915_init call it. > >We do intel_audio_init() and register the audio component when we are ready to >handle >the audio component calls. We are ready at i915_driver_register(). We are not >ready at >intel_modeset_init(). > >BR, >Jani. Thanks to comments my patch. After I check the whole driver code, I think all ops in i915_audio_component_ops should be ready at the beginning of function intel_modeset_init. So can we move intel_audio_init as early as we can. Would you like to suggest a better place to do intel_audio_init? Thanks. BR. Yang. > > >-- >Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: set minimum CD clock to twice the BCLK.
On Tue, 10 Apr 2018, Jani Nikula wrote: > On Mon, 09 Apr 2018, "Kumar, Abhay" wrote: >> Dynamic cdclk is disabled in BIOS/GOP hence gop makes it to highest >> clock i.e 316.8. Will attach logs with drm debug enabled in bug. >> I am also inclined towards 192 which will make max cdclk.. > > Please also attach /sys/kernel/debug/dri/0/i915_vbt to the bug. > > It doesn't look like we look at the VBT dynamic cdclk field. Does > dynamic debug disabled mean we should go for max? Ville, I tried to look at how to disable dynamic cdclk for some platforms based on the VBT, but it gets a bit hairy. The code seems pretty wired for going to lowest possible. I've got the trivial VBT parsing part, but plugging that into the cdclk code in a clean way that could *also* be backported to stable is driving me nuts. Any ideas? I'd like to fix the issue first, and (then have you ;) embark on the refactoring afterwards. It's trivial to plug the check into intel_crtc_compute_min_cdclk() and return dev_priv->max_cdclk_freq, but a) I think that place should be reserved for crtc_state related limitations, and seems the completely wrong place to do system level things, b) it's not optimal to go through all the cdclk code to do nothing in the end, and c) it doesn't work for the no crtc's active case at init time. Just setting the .set_cdclk and .modeset_calc_cdclk hooks to NULL was another idea, but the hooks get initialized before VBT parsing. And I don't think that works for init either. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/icl: Add Voltage swing table for MG PHY DDI Buffer
Quoting Paulo Zanoni (2018-03-23 17:24:16)
> From: Manasi Navare
>
> This table is used for voltage swing programming sequence during DDI
> Buffer initialization for MG PHY DDI Buffers on Icelake.
Except it is not used at all...
drivers/gpu/drm/i915/intel_ddi.c:601:46: error: ‘icl_mg_phy_ddi_translations’
defined but not used [-Werror=unused-const-variable=]
static const struct icl_mg_phy_ddi_buf_trans icl_mg_phy_ddi_translations[] = {
^~~
drivers/gpu/drm/i915/intel_ddi.c:581:49: error:
‘icl_combo_phy_ddi_translations_edp_1_05V’ defined but not used
[-Werror=unused-const-variable=]
static const struct icl_combo_phy_ddi_buf_trans
icl_combo_phy_ddi_translations_edp_1_05V[] = {
^~~~
drivers/gpu/drm/i915/intel_ddi.c:565:49: error:
‘icl_combo_phy_ddi_translations_dp_hdmi_1_05V’ defined but not used
[-Werror=unused-const-variable=]
static const struct icl_combo_phy_ddi_buf_trans
icl_combo_phy_ddi_translations_dp_hdmi_1_05V[] = {
^~~~
drivers/gpu/drm/i915/intel_ddi.c:550:49: error:
‘icl_combo_phy_ddi_translations_edp_0_95V’ defined but not used
[-Werror=unused-const-variable=]
static const struct icl_combo_phy_ddi_buf_trans
icl_combo_phy_ddi_translations_edp_0_95V[] = {
^~~~
drivers/gpu/drm/i915/intel_ddi.c:534:49: error:
‘icl_combo_phy_ddi_translations_dp_hdmi_0_95V’ defined but not used
[-Werror=unused-const-variable=]
static const struct icl_combo_phy_ddi_buf_trans
icl_combo_phy_ddi_translations_dp_hdmi_0_95V[] = {
^~~~
drivers/gpu/drm/i915/intel_ddi.c:519:49: error:
‘icl_combo_phy_ddi_translations_edp_0_85V’ defined but not used
[-Werror=unused-const-variable=]
static const struct icl_combo_phy_ddi_buf_trans
icl_combo_phy_ddi_translations_edp_0_85V[] = {
^~~~
drivers/gpu/drm/i915/intel_ddi.c:503:49: error:
‘icl_combo_phy_ddi_translations_dp_hdmi_0_85V’ defined but not used
[-Werror=unused-const-variable=]
static const struct icl_combo_phy_ddi_buf_trans
icl_combo_phy_ddi_translations_dp_hdmi_0_85V[] = {
^~~~
cc1: all warnings being treated as errors
> v2 (from Paulo):
> * Fix white space issues.
>
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Reviewed-by: Paulo Zanoni
> Signed-off-by: Manasi Navare
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 229b9d5250c4..359acbfec4b1 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -592,6 +592,26 @@ static const struct icl_combo_phy_ddi_buf_trans
> icl_combo_phy_ddi_translations_e
> { 0x0, 0x00, 0x00 },/* 350 0.0 */
> };
>
> +struct icl_mg_phy_ddi_buf_trans {
> + u32 cri_txdeemph_override_5_0;
> + u32 cri_txdeemph_override_11_6;
> + u32 cri_txdeemph_override_17_12;
> +};
> +
> +static const struct icl_mg_phy_ddi_buf_trans icl_mg_phy_ddi_translations[] =
> {
> + /* Voltage swing pre-emphasis */
> + { 0x0, 0x1B, 0x00 },/* 0 0 */
> + { 0x0, 0x23, 0x08 },/* 0 1 */
> + { 0x0, 0x2D, 0x12 },/* 0 2 */
> + { 0x0, 0x00, 0x00 },/* 0 3 */
> + { 0x0, 0x23, 0x00 },/* 1 0 */
> + { 0x0, 0x2B, 0x09 },/* 1 1 */
> + { 0x0, 0x2E, 0x11 },/* 1 2 */
> + { 0x0, 0x2F, 0x00 },/* 2 0 */
> + { 0x0, 0x33, 0x0C },/* 2 1 */
> + { 0x0, 0x00, 0x00 },/* 3 0 */
> +};
> +
> static const struct ddi_buf_trans *
> bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
> {
> --
> 2.14.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/guc: Check that the breadcrumb irq is enabled
Quoting Patchwork (2018-04-10 00:57:45) > == Series Details == > > Series: series starting with [1/2] drm/i915/guc: Check that the breadcrumb > irq is enabled > URL : https://patchwork.freedesktop.org/series/41396/ > State : failure > > == Summary == > > Possible new issues: > > Test gem_eio: > Subgroup execbuf: > pass -> INCOMPLETE (shard-apl) > Subgroup throttle: > pass -> INCOMPLETE (shard-apl) > Test kms_frontbuffer_tracking: > Subgroup fbc-rgb565-draw-mmap-gtt: > pass -> FAIL (shard-apl) > Test perf: > Subgroup gen8-unprivileged-single-ctx-counters: > pass -> FAIL (shard-apl) As expected, after the wedging the pinning of the breadcrumb irq is unbalanced, leading to guc_submission_tasklet being run while interrupts are disabled. A terminal condition. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/bios: remove duplicated code
Apparently caused by a merge fail at some point. Due to the nature of
the duplicated block, the second one will have no effect, and there's no
need to backport.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index fc14bab9c798..7f95d405d585 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1276,13 +1276,6 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
is_hdmi = false;
}
- if (port == PORT_A && is_dvi) {
- DRM_DEBUG_KMS("VBT claims port A supports DVI%s, ignoring\n",
- is_hdmi ? "/HDMI" : "");
- is_dvi = false;
- is_hdmi = false;
- }
-
info->supports_dvi = is_dvi;
info->supports_hdmi = is_hdmi;
info->supports_dp = is_dp;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/guc: Replace %phn with %phN
%phn is not a valid specifier, so I presume %phN was meant for an
encoded hex string with no separator (and not that the hex string should
be followed by the letter 'n'!).
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be
followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be
followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be
followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:669 ct_handle_response() warn: '%ph' cannot
be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:679 ct_handle_response() warn: '%ph' cannot
be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:693 ct_handle_response() warn: '%ph' cannot
be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:707 ct_handle_response() warn: '%ph' cannot
be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:727 ct_process_request() warn: '%ph' cannot
be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:803 ct_handle_request() warn: '%ph' cannot
be followed by 'n'
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_guc_ct.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 990141d5f195..319abf5a4710 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -361,7 +361,7 @@ static int ctb_write(struct intel_guc_ct_buffer *ctb,
(want_response ? GUC_CT_MSG_SEND_STATUS : 0) |
(action[0] << GUC_CT_MSG_ACTION_SHIFT);
- CT_DEBUG_DRIVER("CT: writing %*phn %*phn %*phn\n",
+ CT_DEBUG_DRIVER("CT: writing %*phN %*phN %*phN\n",
4, &header, 4, &fence,
4 * (len - 1), &action[1]);
@@ -613,7 +613,7 @@ static int ctb_read(struct intel_guc_ct_buffer *ctb, u32
*data)
/* message len with header */
len = ct_header_get_len(data[0]) + 1;
if (unlikely(len > (u32)available)) {
- DRM_ERROR("CT: incomplete message %*phn %*phn %*phn\n",
+ DRM_ERROR("CT: incomplete message %*phN %*phN %*phN\n",
4, data,
4 * (head + available - 1 > size ?
size - head : available - 1), &cmds[head],
@@ -626,7 +626,7 @@ static int ctb_read(struct intel_guc_ct_buffer *ctb, u32
*data)
data[i] = cmds[head];
head = (head + 1) % size;
}
- CT_DEBUG_DRIVER("CT: received %*phn\n", 4 * len, data);
+ CT_DEBUG_DRIVER("CT: received %*phN\n", 4 * len, data);
desc->head = head * 4;
return 0;
@@ -666,7 +666,7 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
/* Response payload shall at least include fence and status */
if (unlikely(len < 2)) {
- DRM_ERROR("CT: corrupted response %*phn\n", 4 * msglen, msg);
+ DRM_ERROR("CT: corrupted response %*phN\n", 4 * msglen, msg);
return -EPROTO;
}
@@ -676,7 +676,7 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
/* Format of the status follows RESPONSE message */
if (unlikely(!INTEL_GUC_MSG_IS_RESPONSE(status))) {
- DRM_ERROR("CT: corrupted response %*phn\n", 4 * msglen, msg);
+ DRM_ERROR("CT: corrupted response %*phN\n", 4 * msglen, msg);
return -EPROTO;
}
@@ -690,7 +690,7 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
continue;
}
if (unlikely(datalen > req->response_len)) {
- DRM_ERROR("CT: response %u too long %*phn\n",
+ DRM_ERROR("CT: response %u too long %*phN\n",
req->fence, 4 * msglen, msg);
datalen = 0;
}
@@ -704,7 +704,7 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
spin_unlock(&ct->lock);
if (!found)
- DRM_ERROR("CT: unsolicited response %*phn\n", 4 * msglen, msg);
+ DRM_ERROR("CT: unsolicited response %*phN\n", 4 * msglen, msg);
return 0;
}
@@ -713,7 +713,7 @@ static void ct_process_request(struct intel_guc_ct *ct,
{
struct intel_guc *guc = ct_to_guc(ct);
- CT_DEBUG_DRIVER("CT: request %x %*phn\n", action, 4 * len, payload);
+ CT_DEBUG_DRIVER("CT: request %x %*phN\n", action, 4 * len, payload);
switch (action) {
case INTEL_GUC_ACTION_DEFAULT:
@@ -724,7 +724,7 @@ static void ct_process_request(struct intel_guc_ct *ct,
default:
fail_unexpected:
- DRM_ERROR("CT: unexpected request %x %*phn\n",
+ DRM_ERROR("CT: unexpected request %x %*phN\n",
action, 4 * len, payload);
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v8,01/12] drm/i915: Park before resetting the submission backend
Quoting Sagar Arun Kamble (2018-04-10 06:32:29) > > > On 4/9/2018 9:02 PM, Michal Wajdeczko wrote: > > On Mon, 09 Apr 2018 17:09:18 +0200, Patchwork > > wrote: > > > >> == Series Details == > >> > >> Series: series starting with [v8,01/12] drm/i915: Park before > >> resetting the submission backend > >> URL : https://patchwork.freedesktop.org/series/41365/ > >> State : failure > >> > >> == Summary == > >> > >> Possible new issues: > > > > two variants: > > > >> > >> Test drm_mm: > >> Subgroup sanitycheck: > >> pass -> INCOMPLETE (shard-apl) > > > > #1 > > > > <0>[ 400.245461] drv_self-5775 1 400208508us : > > intel_guc_submission_disable: intel_guc_submission_disable:1255 > > GEM_BUG_ON(dev_priv->gt.awake) > > > > <4>[ 400.245871] Call Trace: > > <4>[ 400.245959] intel_uc_fini_hw+0x4b/0xe0 [i915] > > <4>[ 400.246047] i915_gem_fini_hw+0x16/0x30 [i915] > > <4>[ 400.246129] i915_reset+0x1e8/0x2b0 [i915] > > <4>[ 400.246222] igt_global_reset+0x38/0xe0 [i915] > > > Without gem_set_wedged if i915_reset path is invoked we can face this issue. > igt_global_reset and gem_eio resets are directly invoking > i915_handle_error/i915_reset so I think we should fix the IGTs. No, wrong answer. > >> Test drv_hangman: > >> Subgroup error-state-capture-blt: > >> pass -> INCOMPLETE (shard-apl) > >> Subgroup error-state-capture-bsd: > >> pass -> INCOMPLETE (shard-apl) > >> Subgroup error-state-capture-render: > >> pass -> INCOMPLETE (shard-apl) > >> Subgroup error-state-capture-vebox: > >> pass -> INCOMPLETE (shard-apl) > >> Test drv_selftest: > >> Subgroup live_guc: > >> pass -> SKIP (shard-apl) > >> Subgroup live_hangcheck: > >> pass -> DMESG-FAIL (shard-apl) > >> Test gem_eio: > >> Subgroup execbuf: > >> pass -> INCOMPLETE (shard-apl) > > > > #2: > > > > <3>[ 227.833798] intel_engine_unpin_breadcrumbs_irq:219 > > GEM_BUG_ON(!b->irq_enabled) > > > > <4>[ 227.834607] Call Trace: > > <4>[ 227.834691] intel_engines_park+0xef/0x180 [i915] > > <4>[ 227.834709] ? synchronize_irq+0x3e/0xb0 > > <4>[ 227.834781] __i915_gem_park+0x3e/0x160 [i915] > > <4>[ 227.834850] i915_gem_idle_work_handler+0x1cd/0x220 [i915] > > <4>[ 227.834868] process_one_work+0x21a/0x640 > > > > > irq disabling with GuC submission is not taking into consideration if it > was enabled by waiter. irqs cannot be disabled while in guc mode. It is still the same problem of being unbalanced across enabling. (i.e. we switch to another mode to submit the request and then enable the guc, ergo the guc never pins the irq for itself.) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6
From: Tvrtko Ursulin
While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
on some CI machines I have concluded that: a) the PMU readout of RC6 can
race against runtime PM transitions, and b) there are other reasons than
being runtime suspended which can cause intel_runtime_pm_get_if_in_use to
fail.
Therefore when estimating RC6 the code needs to assert we are indeed in
suspended state and if not the best we can do is return the last known RC6
value.
Signed-off-by: Tvrtko Ursulin
Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105010
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Imre Deak
---
I was able to trigger state != RPM_SUSPENDED on the shards, but not yet
the actual estimation overaccounting. As such this fix is based partially
on speculation that it will fix the sporadic perf_pmu/rc6* failures.
Nevertheless I think it is correct to add this check regardless.
---
drivers/gpu/drm/i915/i915_pmu.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index bd7e695fc663..e92a9571db77 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -473,6 +473,30 @@ static u64 get_rc6(struct drm_i915_private *i915)
spin_lock_irqsave(&i915->pmu.lock, flags);
spin_lock(&kdev->power.lock);
+ /*
+* After the above branch intel_runtime_pm_get_if_in_use failed
+* to get the runtime PM reference we cannot assume we are in
+* runtime suspend since we can either: a) race with coming out
+* of it before we took the power.lock, or b) there are other
+* states than suspended which can bring us here.
+*
+* We need to double-check that we are indeed currently runtime
+* suspended and if not we cannot do better than report the last
+* known RC6 value.
+*/
+ if (kdev->power.runtime_status != RPM_SUSPENDED) {
+ spin_unlock(&kdev->power.lock);
+
+ if (i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
+ val =
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
+ else
+ val = i915->pmu.sample[__I915_SAMPLE_RC6].cur;
+
+ spin_unlock_irqrestore(&i915->pmu.lock, flags);
+
+ return val;
+ }
+
if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
i915->pmu.suspended_jiffies_last =
kdev->power.suspended_jiffies;
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Check that the breadcrumb irq is enabled
Quoting Chris Wilson (2018-04-09 15:49:22)
> Quoting Michal Wajdeczko (2018-04-09 15:08:40)
> > On Mon, 09 Apr 2018 14:42:19 +0200, Chris Wilson
> > wrote:
> >
> > > Our execlists emulation for GuC requires use of the breadcrumb following
> > > every request as a simulcrum for the context-switch interrupt, which we
> > > then use to drive the submission tasklet. Therefore, when we unpark the
> > > engine for use with the GuC, we pin the breadcrumb interrupt to keep it
> > > enabled for the duration. This has to be remain so across all resets,
> > > wedging and resume, so check we do have the irq enabled when we start
> > > submitting requests to the GuC and on all submissions thereafter.
> > >
> > > Signed-off-by: Chris Wilson
> > > Cc: Michal Wajdeczko
> > > Cc: Michał Winiarski
> > > ---
> > > drivers/gpu/drm/i915/intel_guc_submission.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
> > > b/drivers/gpu/drm/i915/intel_guc_submission.c
> > > index 97121230656c..a7957b669b68 100644
> > > --- a/drivers/gpu/drm/i915/intel_guc_submission.c
> > > +++ b/drivers/gpu/drm/i915/intel_guc_submission.c
> > > @@ -758,6 +758,8 @@ static void guc_submission_tasklet(unsigned long
> > > data)
> > > struct execlist_port *port = execlists->port;
> > > struct i915_request *rq;
> > > + GEM_BUG_ON(!READ_ONCE(engine->breadcrumbs.irq_enabled));
> > > +
> > > rq = port_request(port);
> > > while (rq && i915_request_completed(rq)) {
> > > trace_i915_request_out(rq);
> >
> > LGTM, but can you run this with GuC enabled ?
>
> Are you afraid? If gem_eio isn't hitting this, I need to tweak gem_eio
> ;)
That run confirms that the existing test coverage is enough to hit this
error - the same tests we know are broken atm due to the unbalance this
is detecting.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bios: remove duplicated code
== Series Details == Series: drm/i915/bios: remove duplicated code URL : https://patchwork.freedesktop.org/series/41448/ State : success == Summary == Series 41448v1 drm/i915/bios: remove duplicated code https://patchwork.freedesktop.org/api/1.0/series/41448/revisions/1/mbox/ Known issues: Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (fi-glk-j4005) fdo#103359 Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (fi-glk-j4005) fdo#100368 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:428s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:444s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:384s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:537s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:518s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:513s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:524s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:510s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:410s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:563s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:513s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:582s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:424s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:317s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:488s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:427s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:472s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:434s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:476s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:460s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:516s fi-pnv-d510 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:666s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:440s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:537s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:502s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:500s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:430s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:448s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:588s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:402s 617cdf0bd4fd2cb0dcc64ddf07fbb56572ba800a drm-tip: 2018y-04m-09d-19h-55m-54s UTC integration manifest ade5a4637437 drm/i915/bios: remove duplicated code == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8651/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6
Quoting Tvrtko Ursulin (2018-04-10 10:23:28)
> From: Tvrtko Ursulin
>
> While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
> on some CI machines I have concluded that: a) the PMU readout of RC6 can
> race against runtime PM transitions, and b) there are other reasons than
> being runtime suspended which can cause intel_runtime_pm_get_if_in_use to
> fail.
>
> Therefore when estimating RC6 the code needs to assert we are indeed in
> suspended state and if not the best we can do is return the last known RC6
> value.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105010
> Cc: Tvrtko Ursulin
> Cc: Chris Wilson
> Cc: Imre Deak
> ---
> I was able to trigger state != RPM_SUSPENDED on the shards, but not yet
> the actual estimation overaccounting. As such this fix is based partially
> on speculation that it will fix the sporadic perf_pmu/rc6* failures.
> Nevertheless I think it is correct to add this check regardless.
> ---
> drivers/gpu/drm/i915/i915_pmu.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index bd7e695fc663..e92a9571db77 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -473,6 +473,30 @@ static u64 get_rc6(struct drm_i915_private *i915)
> spin_lock_irqsave(&i915->pmu.lock, flags);
> spin_lock(&kdev->power.lock);
>
> + /*
> +* After the above branch intel_runtime_pm_get_if_in_use
> failed
> +* to get the runtime PM reference we cannot assume we are in
> +* runtime suspend since we can either: a) race with coming
> out
> +* of it before we took the power.lock, or b) there are other
> +* states than suspended which can bring us here.
> +*
> +* We need to double-check that we are indeed currently
> runtime
> +* suspended and if not we cannot do better than report the
> last
> +* known RC6 value.
> +*/
> + if (kdev->power.runtime_status != RPM_SUSPENDED) {
> + spin_unlock(&kdev->power.lock);
> +
> + if (i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> + val =
> i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
> + else
> + val = i915->pmu.sample[__I915_SAMPLE_RC6].cur;
If rpm awake, but having lost the race to read the regs, report the last
known value.
This is because we don't know if another thread is in the other branch,
and so we will have one updating the estimate while it being compared
against.
But I'm not understanding the failure -- why is the estimate bad? At the
very least we still ensure that it is monotonic? Is it just the jitter
you are worrying about? (If the estimate is bad here, isn't it always
bad?)
> +
> + spin_unlock_irqrestore(&i915->pmu.lock, flags);
> +
> + return val;
> + }
I'd prefer moving the RPM_SUSPENDED code into an else branch to avoid
another unlock/early return here. (It just fits into 80cols, so no
excuses ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Replace %phn with %phN
== Series Details == Series: drm/i915/guc: Replace %phn with %phN URL : https://patchwork.freedesktop.org/series/41452/ State : success == Summary == Series 41452v1 drm/i915/guc: Replace %phn with %phN https://patchwork.freedesktop.org/api/1.0/series/41452/revisions/1/mbox/ Known issues: Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (fi-glk-j4005) fdo#103359 Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (fi-glk-j4005) fdo#100368 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:434s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:443s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:380s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:535s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:516s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:511s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:520s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:506s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:416s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:560s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:509s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:582s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:416s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:315s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:540s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:484s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:419s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:473s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:440s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:474s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:464s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:506s fi-pnv-d510 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:668s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:440s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:534s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:505s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:494s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:428s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:444s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:585s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:403s 617cdf0bd4fd2cb0dcc64ddf07fbb56572ba800a drm-tip: 2018y-04m-09d-19h-55m-54s UTC integration manifest 192690c2c009 drm/i915/guc: Replace %phn with %phN == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8652/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6
== Series Details == Series: drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6 URL : https://patchwork.freedesktop.org/series/41453/ State : warning == Summary == Series 41453v1 drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6 https://patchwork.freedesktop.org/api/1.0/series/41453/revisions/1/mbox/ Possible new issues: Test gem_exec_gttfill: Subgroup basic: pass -> SKIP (fi-pnv-d510) Known issues: Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (fi-glk-j4005) fdo#103359 Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (fi-glk-j4005) fdo#100368 +1 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:431s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:446s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:379s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:539s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:297s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:513s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:510s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:520s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:508s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:410s fi-cfl-s3total:285 pass:258 dwarn:0 dfail:0 fail:1 skip:26 time:550s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:511s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:585s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:427s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:316s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:536s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:491s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:405s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:428s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:466s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:441s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:470s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:465s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:511s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:633s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:439s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:541s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:506s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:502s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:425s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:564s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:409s 617cdf0bd4fd2cb0dcc64ddf07fbb56572ba800a drm-tip: 2018y-04m-09d-19h-55m-54s UTC integration manifest b1c4a2bf8bb8 drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8653/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gen9_lp: Increase DDI PHY0 power well enabling timeout
On Mon, Apr 09, 2018 at 04:17:43PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/gen9_lp: Increase DDI PHY0 power well enabling timeout > URL : https://patchwork.freedesktop.org/series/41366/ > State : success Pushed to -dinq, thanks for the review. > > == Summary == > > Known issues: > > Test kms_flip: > Subgroup 2x-wf_vblank-ts-check: > fail -> PASS (shard-hsw) fdo#100368 > > fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 > > shard-apltotal:2680 pass:1835 dwarn:1 dfail:0 fail:7 skip:836 > time:12687s > shard-hswtotal:2680 pass:1786 dwarn:1 dfail:0 fail:1 skip:891 > time:11445s > Blacklisted hosts: > shard-snbtotal:2680 pass:1377 dwarn:1 dfail:0 fail:3 skip:1299 > time:6957s > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8641/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6
On 10/04/2018 10:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-10 10:23:28)
From: Tvrtko Ursulin
While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
on some CI machines I have concluded that: a) the PMU readout of RC6 can
race against runtime PM transitions, and b) there are other reasons than
being runtime suspended which can cause intel_runtime_pm_get_if_in_use to
fail.
Therefore when estimating RC6 the code needs to assert we are indeed in
suspended state and if not the best we can do is return the last known RC6
value.
Signed-off-by: Tvrtko Ursulin
Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105010
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Imre Deak
---
I was able to trigger state != RPM_SUSPENDED on the shards, but not yet
the actual estimation overaccounting. As such this fix is based partially
on speculation that it will fix the sporadic perf_pmu/rc6* failures.
Nevertheless I think it is correct to add this check regardless.
---
drivers/gpu/drm/i915/i915_pmu.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index bd7e695fc663..e92a9571db77 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -473,6 +473,30 @@ static u64 get_rc6(struct drm_i915_private *i915)
spin_lock_irqsave(&i915->pmu.lock, flags);
spin_lock(&kdev->power.lock);
+ /*
+* After the above branch intel_runtime_pm_get_if_in_use failed
+* to get the runtime PM reference we cannot assume we are in
+* runtime suspend since we can either: a) race with coming out
+* of it before we took the power.lock, or b) there are other
+* states than suspended which can bring us here.
+*
+* We need to double-check that we are indeed currently runtime
+* suspended and if not we cannot do better than report the last
+* known RC6 value.
+*/
+ if (kdev->power.runtime_status != RPM_SUSPENDED) {
+ spin_unlock(&kdev->power.lock);
+
+ if (i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
+ val =
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
+ else
+ val = i915->pmu.sample[__I915_SAMPLE_RC6].cur;
If rpm awake, but having lost the race to read the regs, report the last
known value.
This is because we don't know if another thread is in the other branch,
and so we will have one updating the estimate while it being compared
against.
No, the race is intel_runtime_pm_get_if_in_use telling us the device is
not active, but a) that doesn't mean it is suspended, and b) it doesn't
mean it is still suspended after the check.
Also PMU internal state is serialized by the spinlock so there is no
inconsistency there.
But I'm not understanding the failure -- why is the estimate bad? At the
very least we still ensure that it is monotonic? Is it just the jitter
you are worrying about? (If the estimate is bad here, isn't it always
bad?)
As far as I have seen failures from CI are all estimate being too large.
(no jitter and no going backwards)
What I suspect is going bad in either case, is that we must not add the
delta from current jiffies to internal runtime pm counters if state is
not suspended. If we do that we are accounting an unknown period of time
as suspended time and that would explain the over-estimation.
In other words we are only allowed to estimate if the current state is
definitely suspended. If it is anything else we need to report either
the last estimated value, or the last real value, depending what is more
recent.
I've done a CI run which definitely shows we can end up in this path
when state is not suspended.
+
+ spin_unlock_irqrestore(&i915->pmu.lock, flags);
+
+ return val;
+ }
I'd prefer moving the RPM_SUSPENDED code into an else branch to avoid
another unlock/early return here. (It just fits into 80cols, so no
excuses ;)
Okay makes sense.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/bios: remove duplicated code
== Series Details == Series: drm/i915/bios: remove duplicated code URL : https://patchwork.freedesktop.org/series/41448/ State : success == Summary == Known issues: Test kms_cursor_legacy: Subgroup flip-vs-cursor-varying-size: pass -> FAIL (shard-hsw) fdo#102670 Test kms_flip: Subgroup dpms-vs-vblank-race: fail -> PASS (shard-hsw) fdo#103060 Test kms_plane: Subgroup pixel-format-pipe-b-planes: dmesg-warn -> PASS (shard-hsw) fdo#102614 +1 Test kms_sysfs_edid_timing: warn -> PASS (shard-apl) fdo#100047 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:2680 pass:1836 dwarn:1 dfail:0 fail:7 skip:836 time:12680s shard-hswtotal:2680 pass:1785 dwarn:1 dfail:0 fail:2 skip:891 time:11362s Blacklisted hosts: shard-kbltotal:2680 pass:1961 dwarn:1 dfail:0 fail:7 skip:711 time:9236s shard-snbtotal:2680 pass:1377 dwarn:1 dfail:0 fail:3 skip:1299 time:6885s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8651/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Chase psr.enabled only under the psr.lock
Quoting Souza, Jose (2018-04-06 19:12:27)
> On Thu, 2018-04-05 at 12:49 +0100, Chris Wilson wrote:
> > Inside the psr work function, we want to wait for PSR to idle first
> > and
> > wish to do so without blocking the normal modeset path, so we do so
> > without holding the PSR lock. However, we first have to find which
> > pipe
> > PSR was enabled on, which requires chasing into the PSR struct and
> > requires locking to prevent intel_psr_disable() from concurrently
> > setting our pointer to NULL.
> >
> > Fixes: 995d30477496 ("drm/i915: VLV/CHV PSR Software timer mode")
> > Signed-off-by: Chris Wilson
> > Cc: Durgadoss R
> > Cc: Rodrigo Vivi
> > Cc: # v4.0+
>
> Feel free to add:
> Reviewed-by: Jose Roberto de Souza
>
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 82 +-
> > --
> > 1 file changed, 44 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 2d53f7398a6d..69a5b276f4d8 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -775,53 +775,59 @@ void intel_psr_disable(struct intel_dp
> > *intel_dp,
> > cancel_delayed_work_sync(&dev_priv->psr.work);
> > }
> >
> > -static void intel_psr_work(struct work_struct *work)
> > +static bool psr_wait_for_idle(struct drm_i915_private *dev_priv)
> > {
> > - struct drm_i915_private *dev_priv =
> > - container_of(work, typeof(*dev_priv),
> > psr.work.work);
> > - struct intel_dp *intel_dp = dev_priv->psr.enabled;
> > - struct drm_crtc *crtc = dp_to_dig_port(intel_dp)-
> > >base.base.crtc;
> > - enum pipe pipe = to_intel_crtc(crtc)->pipe;
> > + struct intel_dp *intel_dp;
>
> nitpick: Why not already set it?
> struct intel_dp *intel_dp = dev_priv->psr.enabled;
I have a very strong personal preference for coupling logic together and
not splitting it up into an early init and later test. It certainly
helps against falling into the trap of using the variable inside the init
block before you test.
> > + i915_reg_t reg;
> > + u32 mask;
> > + int err;
> > +
> > + intel_dp = dev_priv->psr.enabled;
> > + if (!intel_dp)
> > + return false;
> >
> > - /* We have to make sure PSR is ready for re-enable
> > - * otherwise it keeps disabled until next full
> > enable/disable cycle.
> > - * PSR might take some time to get fully disabled
> > - * and be ready for re-enable.
> > - */
> > if (HAS_DDI(dev_priv)) {
>
>
> nitpick: While on that you could replace this for:
>
> if (!(IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))) {
That I leave to others ;) Though I would suggest making the branch
around the
VLV_PSRSTAT(pipe)
explicit as that is only applicable to a subset, and easier to extend as
we typically end up with
if (GEN >= 10) {
} else if (bxt_special_case_1) {
} else if (GEN >= 8) {
} else if (vlv_or_chv_special_case_2) {
} else if (GEN >= 6) {
} else {
MISSING_CASE();
}
or whatever is required.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6
Quoting Tvrtko Ursulin (2018-04-10 11:22:55) > > On 10/04/2018 10:57, Chris Wilson wrote: > > But I'm not understanding the failure -- why is the estimate bad? At the > > very least we still ensure that it is monotonic? Is it just the jitter > > you are worrying about? (If the estimate is bad here, isn't it always > > bad?) > > As far as I have seen failures from CI are all estimate being too large. > (no jitter and no going backwards) > > What I suspect is going bad in either case, is that we must not add the > delta from current jiffies to internal runtime pm counters if state is > not suspended. If we do that we are accounting an unknown period of time > as suspended time and that would explain the over-estimation. > > In other words we are only allowed to estimate if the current state is > definitely suspended. If it is anything else we need to report either > the last estimated value, or the last real value, depending what is more > recent. i.e. we must not use kdev->power.suspended_jiffies before we know it is set. Ok, that is stating to make sense. Thanks, can you update the commitmsg with this (pretty much verbatim as it is a good explanation). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6
From: Tvrtko Ursulin
While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
on some CI machines I have concluded that: a) the PMU readout of RC6 can
race against runtime PM transitions, and b) there are other reasons than
being runtime suspended which can cause intel_runtime_pm_get_if_in_use to
fail.
Therefore when estimating RC6 the code needs to assert we are indeed in
suspended state and if not the best we can do is return the last known RC6
value.
v2:
* Re-arrange the code a bit to avoid second unlock and return branch.
(Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105010
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Imre Deak
---
drivers/gpu/drm/i915/i915_pmu.c | 39 +++
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index bd7e695fc663..247a050f816e 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -473,20 +473,35 @@ static u64 get_rc6(struct drm_i915_private *i915)
spin_lock_irqsave(&i915->pmu.lock, flags);
spin_lock(&kdev->power.lock);
- if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
- i915->pmu.suspended_jiffies_last =
- kdev->power.suspended_jiffies;
-
- val = kdev->power.suspended_jiffies -
- i915->pmu.suspended_jiffies_last;
- val += jiffies - kdev->power.accounting_timestamp;
+ /*
+* After the above branch intel_runtime_pm_get_if_in_use failed
+* to get the runtime PM reference we cannot assume we are in
+* runtime suspend since we can either: a) race with coming out
+* of it before we took the power.lock, or b) there are other
+* states than suspended which can bring us here.
+*
+* We need to double-check that we are indeed currently runtime
+* suspended and if not we cannot do better than report the last
+* known RC6 value.
+*/
+ if (kdev->power.runtime_status == RPM_SUSPENDED) {
+ if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
+ i915->pmu.suspended_jiffies_last =
+ kdev->power.suspended_jiffies;
+
+ val = kdev->power.suspended_jiffies -
+ i915->pmu.suspended_jiffies_last;
+ val += jiffies - kdev->power.accounting_timestamp;
+ val = jiffies_to_nsecs(val);
+ val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
+ i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
+ } else if (i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
+ val = i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
+ } else {
+ val = i915->pmu.sample[__I915_SAMPLE_RC6].cur;
+ }
spin_unlock(&kdev->power.lock);
-
- val = jiffies_to_nsecs(val);
- val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
- i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
-
spin_unlock_irqrestore(&i915->pmu.lock, flags);
}
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/bios: remove duplicated code
== Series Details == Series: drm/i915/bios: remove duplicated code URL : https://patchwork.freedesktop.org/series/41448/ State : warning == Summary == = CI Bug Log - changes from CI_DRM_4038_full -> Patchwork_8651_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8651_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8651_full, please notify your bug team to allow them to document this new failure mode, which will reduce the CI noise. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8651/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8651_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-dirty-render: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8651_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_legacy@flip-vs-cursor-varying-size: shard-hsw: PASS -> FAIL (fdo#102670) Possible fixes igt@kms_flip@dpms-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_plane@pixel-format-pipe-b-planes: shard-hsw: DMESG-WARN (fdo#102614) -> PASS +1 igt@kms_sysfs_edid_timing: shard-apl: WARN (fdo#100047) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 == Participating hosts (6 -> 4) == Missing(2): shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4038 -> Patchwork_8651 * Piglit: None -> piglit_4418 CI_DRM_4038: 617cdf0bd4fd2cb0dcc64ddf07fbb56572ba800a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4418: 7c474e011548d35df6b80ceed81d3e6ca560c71d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8651: ade5a46374378cdcb3f392bc70f1557c52f2ab17 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4418: 45e115f293fd6acc0c9647cf2d3b76be78819ba5 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8651/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6
Quoting Tvrtko Ursulin (2018-04-10 11:34:40)
> From: Tvrtko Ursulin
>
> While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
> on some CI machines I have concluded that: a) the PMU readout of RC6 can
> race against runtime PM transitions, and b) there are other reasons than
> being runtime suspended which can cause intel_runtime_pm_get_if_in_use to
> fail.
>
> Therefore when estimating RC6 the code needs to assert we are indeed in
> suspended state and if not the best we can do is return the last known RC6
> value.
>
> v2:
> * Re-arrange the code a bit to avoid second unlock and return branch.
>(Chris Wilson)
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105010
> Cc: Tvrtko Ursulin
> Cc: Chris Wilson
> Cc: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_pmu.c | 39 +++
> 1 file changed, 27 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index bd7e695fc663..247a050f816e 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -473,20 +473,35 @@ static u64 get_rc6(struct drm_i915_private *i915)
> spin_lock_irqsave(&i915->pmu.lock, flags);
> spin_lock(&kdev->power.lock);
>
> - if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> - i915->pmu.suspended_jiffies_last =
> - kdev->power.suspended_jiffies;
> -
> - val = kdev->power.suspended_jiffies -
> - i915->pmu.suspended_jiffies_last;
> - val += jiffies - kdev->power.accounting_timestamp;
> + /*
> +* After the above branch intel_runtime_pm_get_if_in_use
> failed
> +* to get the runtime PM reference we cannot assume we are in
> +* runtime suspend since we can either: a) race with coming
> out
> +* of it before we took the power.lock, or b) there are other
> +* states than suspended which can bring us here.
> +*
> +* We need to double-check that we are indeed currently
> runtime
> +* suspended and if not we cannot do better than report the
> last
> +* known RC6 value.
> +*/
> + if (kdev->power.runtime_status == RPM_SUSPENDED) {
> + if
> (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> + i915->pmu.suspended_jiffies_last =
> +
> kdev->power.suspended_jiffies;
> +
> + val = kdev->power.suspended_jiffies -
> + i915->pmu.suspended_jiffies_last;
> + val += jiffies - kdev->power.accounting_timestamp;
Keep the line of white space here? Breaks up the computation of val from
the power timestamps with the accumulation of sample.
> + val = jiffies_to_nsecs(val);
> + val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
Then probably one more line of whitespace here to break up the
computation of val with it's assignment. We definitely want the
assignment on this branch to stand out from the no assignments later.
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6
On 10/04/2018 11:34, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-04-10 11:22:55) On 10/04/2018 10:57, Chris Wilson wrote: But I'm not understanding the failure -- why is the estimate bad? At the very least we still ensure that it is monotonic? Is it just the jitter you are worrying about? (If the estimate is bad here, isn't it always bad?) As far as I have seen failures from CI are all estimate being too large. (no jitter and no going backwards) What I suspect is going bad in either case, is that we must not add the delta from current jiffies to internal runtime pm counters if state is not suspended. If we do that we are accounting an unknown period of time as suspended time and that would explain the over-estimation. In other words we are only allowed to estimate if the current state is definitely suspended. If it is anything else we need to report either the last estimated value, or the last real value, depending what is more recent. i.e. we must not use kdev->power.suspended_jiffies before we know it is set. Ok, that is stating to make sense. Thanks, can you update the commitmsg with this (pretty much verbatim as it is a good explanation). Can do. The patch makes sense - but I still cannot explain the failures since the test is supposed to be running in an controlled environment: 1. enter runtime suspend 2. sample rc6 (this sets the estimation state) 3. sleep for 2s 4. sample rc6 And the diff between two rc6 states can show from 10% - 50% more RC6 elapsed time than sleep time, even to 300% more in some reports. If i915 is runtime suspended the whole time, and dmesg says it is, I don't know how this is possible. There must be another flaw somewhere which I am not seeing currently. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component intialization before audio driver use it
On Tue, 10 Apr 2018, "Shi, Yang A" wrote: >>On Tue, 10 Apr 2018, "Shi, Yang A" wrote: >>> issue: snd_soc_skl meet "failed to add i915 component master (-19)" >>> when platform don't connect any display output. >>> >>> i915 do initialization before than skl_probe, but if there is no >>> display output connect, in function drm_dp_dpcd_access, there is a 32 >>> retry for aux i2c transactions. It will meet timeout and do usleep. >>> Then skl_probe function will be scheduled. It will call >>> snd_hdac_i915_init, and it will meet "failed to add i915 component >>> master" error. And whole snd_soc_skl initialization will be failed, >>> audio can't work normally anymore. >>> >>> So i915 driver need to move intel_audio_init at the beginning of >>> intel_modeset_init. This will make sure i915_audio_component_init >>> process before snd_hdac_i915_init call it. >> >>We do intel_audio_init() and register the audio component when we are >>ready to handle the audio component calls. We are ready at >>i915_driver_register(). We are not ready at intel_modeset_init(). >> >>BR, >>Jani. > > Thanks to comments my patch. > After I check the whole driver code, I think all ops in > i915_audio_component_ops should be ready at the beginning of function > intel_modeset_init. So can we move intel_audio_init as early as we > can. No, that's not true. Just as an example, dev_priv->cdclk.hw.cdclk hasn't been initialized. > Would you like to suggest a better place to do intel_audio_init? I think the call is already where it is supposed to be. We expose ourselves to the rest of the system when we are ready. If it takes long, it takes long. I think you have a race in your driver, and you need to deal with it properly in your driver. In snd_hdac_i915_init(), I don't think there are any guarantees that the request_module() call is the one actually probing i915. We might already be mid-probe. You don't even check or log request_module() return value. I'm also not 100% sure at what point of driver loading request_module() returns. I think it's when the module init hook returns, which should be all right, but again, I don't think you can count on that if it isn't your request_module() that actually probes i915. I think the patch at hand is a hack that reduces the window for the race, and not a real fix. Moreover, it makes the i915 audio component code fragile by introducing tricky probe order dependencies that we've been systematically trying to reduce by placing the call where it is now. Cc: Lucas for any further input on module probing. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Replace %phn with %phN
On Tue, 10 Apr 2018 11:14:35 +0200, Chris Wilson
wrote:
%phn is not a valid specifier,
Well, implementation allows that as alias for default separator ;)
switch (fmt[1]) {
case 'C':
separator = ':';
break;
case 'D':
separator = '-';
break;
case 'N':
separator = 0;
break;
default:
separator = ' ';
break;
}
so I presume %phN was meant for an
encoded hex string with no separator
No, default ' ' separator is desired as it is more readable:
[] writing 05 45 00 00 00 34 a2 0d 40 00 00 00 01 00 00 00
vs
[] writing 05450034a20d4100
(and not that the hex string should
be followed by the letter 'n'!).
'n' was never added to the output, as it was consumed by fmt specifier ;)
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be
followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be
followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be
followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:669 ct_handle_response() warn: '%ph'
cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:679 ct_handle_response() warn: '%ph'
cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:693 ct_handle_response() warn: '%ph'
cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:707 ct_handle_response() warn: '%ph'
cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:727 ct_process_request() warn: '%ph'
cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:803 ct_handle_request() warn: '%ph'
cannot be followed by 'n'
hmm, I can't see these warnings, how to get them?
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
with s/%phN/%ph
Reviewed-by: Michal Wajdeczko
Thanks,
Michal
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Chase psr.enabled only under the psr.lock
Quoting Rodrigo Vivi (2018-04-09 20:14:32) > On Sat, Apr 07, 2018 at 10:05:25AM +0100, Chris Wilson wrote: > > Quoting Rodrigo Vivi (2018-04-06 23:18:16) > > > On Fri, Apr 06, 2018 at 11:12:27AM -0700, Souza, Jose wrote: > > > > On Thu, 2018-04-05 at 12:49 +0100, Chris Wilson wrote: > > > > > + struct drm_crtc *crtc = > > > > > + dp_to_dig_port(intel_dp)->base.base.crtc; > > > > > > I'm afraid that the issue is this pointer here. So this will only mask > > > the issue. > > > > > > Should we maybe stash the pipe? :/ > > > > It's not that bad. pipe cannot change until after psr_disable is called, > > right? And psr_disable ensures that this worker is flushed. The current > > problem is just the coordination of cancelling the worker, where we may > > set psr.enabled to NULL right before the worker grabs it and > > dereferences it. > > > > So if we lock until we have the pipe, we know that dereference chain is > > valid, and we know that psr_disable() cannot complete until we complete > > the wait. So the pipe remains valid until we return (so long as the pipe > > exists when we start). > > hmm... it makes sense and I have no better suggestion actually. > So, as long it really fixes the regression we introduced: > > Acked-by: Rodrigo Vivi It does fix the abstract race, but I have no evidence of this being hit in practice. Pushed, but up to you if you care about this being backported. Note this race is different from the GPF CI reported. Hmm, I think https://bugs.freedesktop.org/show_bug.cgi?id=105959 is the same one as hit on the kasan run earlier. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/audio: Fix audio detection issue on GLK
On Mon, 09 Apr 2018, "Kumar, Abhay" wrote: > On 4/9/2018 4:20 PM, Pandiyan, Dhinakaran wrote: >> >> >> On Mon, 2018-04-09 at 12:18 -0700, Kumar, Abhay wrote: >>> On 4/9/2018 12:10 PM, Rodrigo Vivi wrote: On Mon, Apr 09, 2018 at 05:07:31PM +0300, Jani Nikula wrote: > On Sun, 08 Apr 2018, Gaurav K Singh wrote: >> On Geminilake, sometimes audio card is not getting >> detected after reboot. This is a spurious issue happening on >> Geminilake. HW codec and HD audio controller link was going >> out of sync for which there was a fix in i915 driver but >> was not getting invoked for GLK. Extending this fix to GLK as well. >> >> Tested by Du,Wenkai on GLK board. >> >> Signed-off-by: Gaurav K Singh >> --- >>drivers/gpu/drm/i915/intel_audio.c | 3 ++- >>1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_audio.c >> b/drivers/gpu/drm/i915/intel_audio.c >> index 656f6c931341..73b1e0b96f88 100644 >> --- a/drivers/gpu/drm/i915/intel_audio.c >> +++ b/drivers/gpu/drm/i915/intel_audio.c >> @@ -729,7 +729,8 @@ static void >> i915_audio_component_codec_wake_override(struct device *kdev, >> struct drm_i915_private *dev_priv = kdev_to_i915(kdev); >> u32 tmp; >> >> -if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv)) >> +if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv) && >> + >> !IS_GEMINILAKE(dev_priv)) > That could be written as > > if (!IS_GEN9_BC(dev_priv) && !IS_GEN9_LP(dev_priv)) > > which in turn could just be written as > > if (!IS_GEN9(dev_priv)) > > ...but since GLK has gen 10 display, so I'm wondering if the same issue > will be present in gen 10 too, and whether this should just become > > if (INTEL_GEN(dev_priv) < 9) +1. I opened here to exactly add same comment. >>> I am checking with DINQ and without this patch for GLK it can enumerate >>> HDA codec. Ofcourse after cdclk fix. >> How about the other way around? i.e., does codec enumeration work this >> patch but without the cdclk change? > Nop. with DINQ we need to have cdclk change to make Codec detection > work. With or without this patch. Basically what you're saying is that this patch is not needed? Gaurav, can you check with the CDCLK patch [1] if that fixes the issue for you? BR, Jani. PS. The CDCLK patch is not enough to fix the issue completely (probe without display outputs will still choose a low CDCLK) but that's work in progress. [1] http://patchwork.freedesktop.org/patch/msgid/1508968932-32208-1-git-send-email-abhay.ku...@intel.com > >> >> >> > BR, > Jani. > > > >> return; >> >> i915_audio_component_get_power(kdev); > -- > Jani Nikula, Intel Open Source Technology Center > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx >>> ___ >>> Intel-gfx mailing list >>> Intel-gfx@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Replace %phn with %phN
== Series Details == Series: drm/i915/guc: Replace %phn with %phN URL : https://patchwork.freedesktop.org/series/41452/ State : failure == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup fbc-rgb565-draw-mmap-gtt: pass -> FAIL (shard-apl) Known issues: Test kms_flip: Subgroup dpms-vs-vblank-race: fail -> PASS (shard-hsw) fdo#103060 Subgroup flip-vs-expired-vblank-interruptible: pass -> FAIL (shard-hsw) fdo#102887 Test kms_plane: Subgroup pixel-format-pipe-b-planes: dmesg-warn -> PASS (shard-hsw) fdo#102614 +1 Test kms_rotation_crc: Subgroup sprite-rotation-270: pass -> FAIL (shard-apl) fdo#103356 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103356 https://bugs.freedesktop.org/show_bug.cgi?id=103356 shard-apltotal:2680 pass:1833 dwarn:1 dfail:0 fail:9 skip:836 time:12700s shard-hswtotal:2680 pass:1785 dwarn:1 dfail:0 fail:2 skip:891 time:11338s Blacklisted hosts: shard-kbltotal:2680 pass:1961 dwarn:1 dfail:0 fail:8 skip:710 time:9242s shard-snbtotal:2680 pass:1377 dwarn:1 dfail:0 fail:3 skip:1299 time:6824s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8652/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Replace %phn with %phN
Quoting Michal Wajdeczko (2018-04-10 11:57:03)
> On Tue, 10 Apr 2018 11:14:35 +0200, Chris Wilson
> wrote:
>
> > %phn is not a valid specifier,
>
> Well, implementation allows that as alias for default separator ;)
>
> switch (fmt[1]) {
> case 'C':
> separator = ':';
> break;
> case 'D':
> separator = '-';
> break;
> case 'N':
> separator = 0;
> break;
> default:
> separator = ' ';
> break;
> }
>
> > so I presume %phN was meant for an
> > encoded hex string with no separator
>
> No, default ' ' separator is desired as it is more readable:
>
> [] writing 05 45 00 00 00 34 a2 0d 40 00 00 00 01 00 00 00
> vs
> [] writing 05450034a20d4100
>
> > (and not that the hex string should
> > be followed by the letter 'n'!).
>
> 'n' was never added to the output, as it was consumed by fmt specifier ;)
>
> >
> > drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be
> > followed by 'n'
> > drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be
> > followed by 'n'
> > drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be
> > followed by 'n'
> > drivers/gpu/drm/i915/intel_guc_ct.c:669 ct_handle_response() warn: '%ph'
> > cannot be followed by 'n'
> > drivers/gpu/drm/i915/intel_guc_ct.c:679 ct_handle_response() warn: '%ph'
> > cannot be followed by 'n'
> > drivers/gpu/drm/i915/intel_guc_ct.c:693 ct_handle_response() warn: '%ph'
> > cannot be followed by 'n'
> > drivers/gpu/drm/i915/intel_guc_ct.c:707 ct_handle_response() warn: '%ph'
> > cannot be followed by 'n'
> > drivers/gpu/drm/i915/intel_guc_ct.c:727 ct_process_request() warn: '%ph'
> > cannot be followed by 'n'
> > drivers/gpu/drm/i915/intel_guc_ct.c:803 ct_handle_request() warn: '%ph'
> > cannot be followed by 'n'
>
> hmm, I can't see these warnings, how to get them?
The extended format specifiers are known to smatch. I shall keep
prodding to his this included it the litany of checkpatch tools. It has
a higher false positive than say gcc, but not so high as checkpatch ;)
But when it finds a bug, it is invaluable.
> > Signed-off-by: Chris Wilson
> > Cc: Michal Wajdeczko
> > Cc: Daniele Ceraolo Spurio
>
> with s/%phN/%ph
Ok, will respin.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Replace %phn with %phN
== Series Details == Series: drm/i915/guc: Replace %phn with %phN URL : https://patchwork.freedesktop.org/series/41452/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4038_full -> Patchwork_8652_full = == Summary - SUCCESS == No regressions found, the changes are of acceptable quality. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8652/ == Known issues == Here are the changes found in Patchwork_8652_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-hsw: PASS -> FAIL (fdo#105189) igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-gtt: shard-apl: PASS -> FAIL (fdo#103167) igt@kms_rotation_crc@sprite-rotation-270: shard-apl: PASS -> FAIL (fdo#103925) igt@perf_pmu@busy-accuracy-50-bcs0: shard-kbl: PASS -> FAIL (fdo#105157) Possible fixes igt@kms_flip@dpms-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_plane@pixel-format-pipe-b-planes: shard-hsw: DMESG-WARN (fdo#102614) -> PASS +1 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#105157 https://bugs.freedesktop.org/show_bug.cgi?id=105157 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 == Participating hosts (6 -> 4) == Missing(2): shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4038 -> Patchwork_8652 * Piglit: None -> piglit_4418 CI_DRM_4038: 617cdf0bd4fd2cb0dcc64ddf07fbb56572ba800a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4418: 7c474e011548d35df6b80ceed81d3e6ca560c71d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8652: 192690c2c0093caa4a5e48a0f2051335f4db35db @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4418: 45e115f293fd6acc0c9647cf2d3b76be78819ba5 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8652/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/guc: Replace %phn with %ph
%phn is not a valid specifier, and the trailing 'n' is being eaten by
the format-specifier and defaulting to the ' ' separator. Avoid angering
smatch by using the unknown specifier, and use the default we expect.
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be
followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be
followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be
followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:669 ct_handle_response() warn: '%ph' cannot
be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:679 ct_handle_response() warn: '%ph' cannot
be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:693 ct_handle_response() warn: '%ph' cannot
be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:707 ct_handle_response() warn: '%ph' cannot
be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:727 ct_process_request() warn: '%ph' cannot
be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:803 ct_handle_request() warn: '%ph' cannot
be followed by 'n'
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/intel_guc_ct.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 990141d5f195..371b6005954a 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -361,7 +361,7 @@ static int ctb_write(struct intel_guc_ct_buffer *ctb,
(want_response ? GUC_CT_MSG_SEND_STATUS : 0) |
(action[0] << GUC_CT_MSG_ACTION_SHIFT);
- CT_DEBUG_DRIVER("CT: writing %*phn %*phn %*phn\n",
+ CT_DEBUG_DRIVER("CT: writing %*ph %*ph %*ph\n",
4, &header, 4, &fence,
4 * (len - 1), &action[1]);
@@ -613,7 +613,7 @@ static int ctb_read(struct intel_guc_ct_buffer *ctb, u32
*data)
/* message len with header */
len = ct_header_get_len(data[0]) + 1;
if (unlikely(len > (u32)available)) {
- DRM_ERROR("CT: incomplete message %*phn %*phn %*phn\n",
+ DRM_ERROR("CT: incomplete message %*ph %*ph %*ph\n",
4, data,
4 * (head + available - 1 > size ?
size - head : available - 1), &cmds[head],
@@ -626,7 +626,7 @@ static int ctb_read(struct intel_guc_ct_buffer *ctb, u32
*data)
data[i] = cmds[head];
head = (head + 1) % size;
}
- CT_DEBUG_DRIVER("CT: received %*phn\n", 4 * len, data);
+ CT_DEBUG_DRIVER("CT: received %*ph\n", 4 * len, data);
desc->head = head * 4;
return 0;
@@ -666,7 +666,7 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
/* Response payload shall at least include fence and status */
if (unlikely(len < 2)) {
- DRM_ERROR("CT: corrupted response %*phn\n", 4 * msglen, msg);
+ DRM_ERROR("CT: corrupted response %*ph\n", 4 * msglen, msg);
return -EPROTO;
}
@@ -676,7 +676,7 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
/* Format of the status follows RESPONSE message */
if (unlikely(!INTEL_GUC_MSG_IS_RESPONSE(status))) {
- DRM_ERROR("CT: corrupted response %*phn\n", 4 * msglen, msg);
+ DRM_ERROR("CT: corrupted response %*ph\n", 4 * msglen, msg);
return -EPROTO;
}
@@ -690,7 +690,7 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
continue;
}
if (unlikely(datalen > req->response_len)) {
- DRM_ERROR("CT: response %u too long %*phn\n",
+ DRM_ERROR("CT: response %u too long %*ph\n",
req->fence, 4 * msglen, msg);
datalen = 0;
}
@@ -704,7 +704,7 @@ static int ct_handle_response(struct intel_guc_ct *ct,
const u32 *msg)
spin_unlock(&ct->lock);
if (!found)
- DRM_ERROR("CT: unsolicited response %*phn\n", 4 * msglen, msg);
+ DRM_ERROR("CT: unsolicited response %*ph\n", 4 * msglen, msg);
return 0;
}
@@ -713,7 +713,7 @@ static void ct_process_request(struct intel_guc_ct *ct,
{
struct intel_guc *guc = ct_to_guc(ct);
- CT_DEBUG_DRIVER("CT: request %x %*phn\n", action, 4 * len, payload);
+ CT_DEBUG_DRIVER("CT: request %x %*ph\n", action, 4 * len, payload);
switch (action) {
case INTEL_GUC_ACTION_DEFAULT:
@@ -724,7 +724,7 @@ static void ct_process_request(struct intel_guc_ct *ct,
default:
fail_unexpected:
- DRM_ERROR("CT: unexpected request %x %*phn\n",
+ DRM_ERROR("CT: unexpected request %x %*ph
[Intel-gfx] [PATCH v3] drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6
From: Tvrtko Ursulin
While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
on some CI machines I have concluded that: a) the PMU readout of RC6 can
race against runtime PM transitions, and b) there are other reasons than
being runtime suspended which can cause intel_runtime_pm_get_if_in_use to
fail.
Therefore when estimating RC6 the code needs to assert we are indeed in
suspended state, and if not, the best we can do is return the last known
RC6 value.
Without this check we can calculate the estimated value based on un-
initialized or inappropriate internal state, which can result in over-
estimation, or in any case incorrect value being returned.
v2:
* Re-arrange the code a bit to avoid second unlock and return branch.
(Chris Wilson)
v3:
* Insert some strategic blank lines and improve commit msg.
(Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105010
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Imre Deak
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_pmu.c | 37 +++--
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index bd7e695fc663..9135d0ada128 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -473,20 +473,37 @@ static u64 get_rc6(struct drm_i915_private *i915)
spin_lock_irqsave(&i915->pmu.lock, flags);
spin_lock(&kdev->power.lock);
- if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
- i915->pmu.suspended_jiffies_last =
- kdev->power.suspended_jiffies;
+ /*
+* After the above branch intel_runtime_pm_get_if_in_use failed
+* to get the runtime PM reference we cannot assume we are in
+* runtime suspend since we can either: a) race with coming out
+* of it before we took the power.lock, or b) there are other
+* states than suspended which can bring us here.
+*
+* We need to double-check that we are indeed currently runtime
+* suspended and if not we cannot do better than report the last
+* known RC6 value.
+*/
+ if (kdev->power.runtime_status == RPM_SUSPENDED) {
+ if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
+ i915->pmu.suspended_jiffies_last =
+ kdev->power.suspended_jiffies;
- val = kdev->power.suspended_jiffies -
- i915->pmu.suspended_jiffies_last;
- val += jiffies - kdev->power.accounting_timestamp;
+ val = kdev->power.suspended_jiffies -
+ i915->pmu.suspended_jiffies_last;
+ val += jiffies - kdev->power.accounting_timestamp;
- spin_unlock(&kdev->power.lock);
+ val = jiffies_to_nsecs(val);
+ val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
- val = jiffies_to_nsecs(val);
- val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
- i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
+ i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
+ } else if (i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
+ val = i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
+ } else {
+ val = i915->pmu.sample[__I915_SAMPLE_RC6].cur;
+ }
+ spin_unlock(&kdev->power.lock);
spin_unlock_irqrestore(&i915->pmu.lock, flags);
}
--
2.14.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Replace %phn with %phN (rev2)
== Series Details == Series: drm/i915/guc: Replace %phn with %phN (rev2) URL : https://patchwork.freedesktop.org/series/41452/ State : success == Summary == Series 41452v2 drm/i915/guc: Replace %phn with %phN https://patchwork.freedesktop.org/api/1.0/series/41452/revisions/2/mbox/ Possible new issues: Test gem_exec_gttfill: Subgroup basic: skip -> PASS (fi-pnv-d510) Known issues: Test gem_exec_suspend: Subgroup basic-s3: pass -> DMESG-WARN (fi-skl-6700k2) fdo#104108 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:429s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:440s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:380s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:537s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:297s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:516s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:514s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:519s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:511s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:408s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:561s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:511s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:596s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:427s fi-gdg-551 total:285 pass:177 dwarn:0 dfail:0 fail:0 skip:108 time:314s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:493s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:405s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:426s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:471s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:442s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:471s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:463s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:510s fi-pnv-d510 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:638s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:441s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:530s fi-skl-6700k2total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:500s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:505s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:430s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:414s 8e7a3b1c5ebd06c5740b0fea76f46ff23d373bd5 drm-tip: 2018y-04m-10d-10h-47m-52s UTC integration manifest b5d880211cf1 drm/i915/guc: Replace %phn with %ph == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8654/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path
From: Colin Ian King
The error exit path when a duplicate is found does not kfree and cmd_entry
struct and hence there is a small memory leak. Fix this by kfree'ing it.
Detected by CoverityScan, CID#1370198 ("Resource Leak")
Fixes: be1da7070aea ("drm/i915/gvt: vGPU command scanner")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index d85939bd7b47..3b6d26c44e37 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -2864,6 +2864,7 @@ static int init_cmd_table(struct intel_gvt *gvt)
if (info) {
gvt_err("%s %s duplicated\n", e->info->name,
info->name);
+ kfree(e);
return -EEXIST;
}
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/36] drm/i915: Split control of rps and rc6
Quoting Sagar Arun Kamble (2018-03-16 13:03:03)
>
>
> On 3/16/2018 2:22 PM, Sagar Arun Kamble wrote:
> >
> >
> > On 3/14/2018 3:07 PM, Chris Wilson wrote:
> >> Allow ourselves to individually toggle rps or rc6. This will be used
> >> later when we want to enable rps/rc6 at different phases during the
> >> device bring up.
> >>
> >> Whilst here, convert the intel_$verb_gt_powersave over to
> >> intel_gt_pm_$verb scheme.
> >>
> >> Signed-off-by: Chris Wilson
> >
> >> +void intel_gt_pm_init(struct drm_i915_private *dev_priv)
> >> {
> >> struct intel_rps *rps = &dev_priv->gt_pm.rps;
> >> @@ -2475,22 +2477,13 @@ void intel_init_gt_powersave(struct
> >> drm_i915_private *dev_priv)
> >> /* Finally allow us to boost to max by default */
> >> rps->boost_freq = rps->max_freq;
> >> - mutex_unlock(&rps->lock);
> >> -}
> >> -
> >> -static inline void intel_enable_llc_pstate(struct drm_i915_private
> >> *i915)
> >> -{
> >> - lockdep_assert_held(&i915->gt_pm.rps.lock);
> >> -
> >> - if (i915->gt_pm.llc_pstate.enabled)
> >> - return;
> >> -
> >> - gen6_update_ring_freq(i915);
> >> + if (HAS_LLC(dev_priv))
> >> + gen6_update_ring_freq(dev_priv);
> > Ring frequency table update has to be done on resuming from sleep or
> > reset as well hence we will
> not required on resume from reset :)
Good. Then it should be covered by the code that enables the powersaving
on init/resume; and we are good to remove the gunk from reset.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 28/36] drm/i915: Enabling rc6 and rps have different requirements, so separate them
Quoting Sagar Arun Kamble (2018-03-16 14:01:22)
>
>
> On 3/14/2018 3:07 PM, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index b9c7b21e5cc8..8a5bf1e26515 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3165,10 +3165,12 @@ void i915_gem_reset(struct drm_i915_private
> > *dev_priv)
> >
> > i915_gem_restore_fences(dev_priv);
> >
> > - if (dev_priv->gt.awake) {
> > - intel_gt_pm_sanitize(dev_priv);
> > - intel_gt_pm_enable_rps(dev_priv);
> > + if (dev_priv->gt_pm.rc6.enabled) {
> > + dev_priv->gt_pm.rc6.enabled = false;
> > intel_gt_pm_enable_rc6(dev_priv);
> > + }
> > +
> I think patch 31 should precede this one to avoid above changes.
I was always a bit doubtful about patch 31 "Don't fiddle with rps/rc6
across reset", so I left it towards the end so I could easily drop it if
need be. ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 29/36] drm/i915: Simplify rc6/rps enabling
Quoting Sagar Arun Kamble (2018-03-16 14:28:27)
>
>
> On 3/14/2018 3:07 PM, Chris Wilson wrote:
> > void intel_gt_pm_irq_handler(struct drm_i915_private *dev_priv, u32
> > pm_iir)
> > {
> > struct intel_rps *rps = &dev_priv->gt_pm.rps;
> >
> > - if (pm_iir & rps->pm_events) {
> > + if (rps->active && pm_iir & rps->pm_events) {
> rps->active is updated under struct_mutex rps->lock so i think it will
> not be synchronized properly
It's an optimistic read, later on inside the worker is where we do the
check. On the enable path, it doesn't matter as we don't care about the
early interrupt, there will be more and we want to set our own
frequency; on the disable path the interrupt is serialised.
> > spin_lock(&dev_priv->irq_lock);
> > gen6_mask_pm_irq(dev_priv, pm_iir & rps->pm_events);
> > - if (rps->interrupts_enabled) {
> > - rps->pm_iir |= pm_iir & rps->pm_events;
> > - schedule_work(&rps->work);
> > - }
> > + rps->pm_iir |= pm_iir & rps->pm_events;
> > spin_unlock(&dev_priv->irq_lock);
> > +
> > + schedule_work(&rps->work);
> > }
> > }
> >
> > -void gen6_rps_busy(struct drm_i915_private *dev_priv)
> > +void intel_gt_pm_busy(struct drm_i915_private *dev_priv)
> > {
> > struct intel_rps *rps = &dev_priv->gt_pm.rps;
> > + u8 freq;
> >
> > if (!HAS_RPS(dev_priv))
> > return;
> >
> > - mutex_lock(&rps->lock);
> > - if (rps->enabled) {
> > - u8 freq;
> > + GEM_BUG_ON(rps->pm_iir);
> > + GEM_BUG_ON(rps->active);
> this BUG_ON should move under rps->lock
It's sufficiently serialised by the caller.
> >
> > - I915_WRITE(GEN6_PMINTRMSK,
> > -gen6_rps_pm_mask(dev_priv, rps->cur_freq));
> > + mutex_lock(&rps->lock);
> > + rps->active = true;
> >
> > - enable_rps_interrupts(dev_priv);
> > - memset(&rps->ei, 0, sizeof(rps->ei));
> > + /*
> > + * Use the user's desired frequency as a guide, but for better
> > + * performance, jump directly to RPe as our starting frequency.
> > + */
> > + freq = max(rps->cur_freq, rps->efficient_freq);
> > + if (intel_set_rps(dev_priv,
> > + clamp(freq,
> > + rps->min_freq_softlimit,
> > + rps->max_freq_softlimit)))
> > + DRM_DEBUG_DRIVER("Failed to set busy frequency\n");
> >
> > - /*
> > - * Use the user's desired frequency as a guide, but for better
> > - * performance, jump directly to RPe as our starting
> > frequency.
> > - */
> > - freq = max(rps->cur_freq,
> > -rps->efficient_freq);
> > + rps->last_adj = 0;
> >
> > - if (intel_set_rps(dev_priv,
> > - clamp(freq,
> > - rps->min_freq_softlimit,
> > - rps->max_freq_softlimit)))
> > - DRM_DEBUG_DRIVER("Failed to set idle frequency\n");
> > + if (INTEL_GEN(dev_priv) >= 6) {
> > + memset(&rps->ei, 0, sizeof(rps->ei));
> > + enable_rps_interrupts(dev_priv);
> > }
> > +
> > mutex_unlock(&rps->lock);
> > }
> >
> > -void gen6_rps_idle(struct drm_i915_private *dev_priv)
> > +void intel_gt_pm_idle(struct drm_i915_private *dev_priv)
> > {
> > struct intel_rps *rps = &dev_priv->gt_pm.rps;
> >
> > - if (!HAS_RPS(dev_priv))
> > + if (!rps->active)
> this too
Again, serialised by the caller. This is important later...
> > return;
> >
> > - /*
> > - * Flush our bottom-half so that it does not race with us
> > - * setting the idle frequency and so that it is bounded by
> > - * our rpm wakeref. And then disable the interrupts to stop any
> > - * futher RPS reclocking whilst we are asleep.
> > - */
> > + mutex_lock(&rps->lock);
> > +
> > disable_rps_interrupts(dev_priv);
> >
> this is not protected by INTEL_GEN() >=6 check.
We don't guard this for it has to handle all gen.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [v2]drm/i915: move audio component initialization before audio driver use it
On Tue, 10 Apr 2018, Yang wrote: > From: Yang Shi > > issue: snd_soc_skl meet "failed to add i915 component master (-19)" when > platform don't connect any display output. > > i915 do initialization before than skl_probe, but if there is no display > output connect, in function drm_dp_dpcd_access, there is a 32 retry for > aux i2c transactions. It will meet timeout and do usleep. Then skl_probe > function will be scheduled. It will call snd_hdac_i915_init, and it will > meet "failed to add i915 component master" error. > And whole snd_soc_skl initialization will be failed, audio can't work normally > anymore. > > So i915 driver need to move intel_audio_init at the beginning of > intel_modeset_init. This will make sure i915_audio_component_init process > before snd_hdac_i915_init call it. No. Please don't send updated versions of patches while the discussion is still ongoing in the previous thread. This is not the fix. BR, Jani. > > V2: edit comments more clearly > > Signed-off-by: Bo He > Signed-off-by: Yang Shi > --- > drivers/gpu/drm/i915/i915_drv.c | 2 -- > drivers/gpu/drm/i915/intel_display.c | 2 ++ > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 2f5209d..9d25d7e 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -1243,8 +1243,6 @@ static void i915_driver_register(struct > drm_i915_private *dev_priv) > if (IS_GEN5(dev_priv)) > intel_gpu_ips_init(dev_priv); > > - intel_audio_init(dev_priv); > - > /* >* Some ports require correctly set-up hpd registers for detection to >* work properly (leading to ghost connected connector status), e.g. VGA > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index f288bcc..a471c88 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -14468,6 +14468,8 @@ int intel_modeset_init(struct drm_device *dev) > > dev->mode_config.funcs = &intel_mode_funcs; > > + intel_audio_init(dev_priv); > + > init_llist_head(&dev_priv->atomic_helper.free_list); > INIT_WORK(&dev_priv->atomic_helper.free_work, > intel_atomic_helper_free_state_worker); -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 30/36] drm/i915: Refactor frequency bounds computation
Quoting Sagar Arun Kamble (2018-03-17 15:10:08)
>
>
> On 3/14/2018 3:07 PM, Chris Wilson wrote:
> > When choosing the initial frequency in intel_gt_pm_busy() we also need
> > to calculate the current min/max bounds. As this calculation is going to
> > become more complex with the intersection of several different limits,
> > refactor it to a common function. The alternative wold be to feed the
> typo
> > initial reclocking through the RPS worker, but the latency in this case
> > is undesirable.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_gt_pm.c | 58
> > +++---
> > 1 file changed, 22 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_gt_pm.c
> > b/drivers/gpu/drm/i915/intel_gt_pm.c
> > index 8630c30a7e48..f8e029b4a8a7 100644
> > --- a/drivers/gpu/drm/i915/intel_gt_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_gt_pm.c
> > @@ -382,15 +382,25 @@ static int __intel_set_rps(struct drm_i915_private
> > *dev_priv, u8 val)
> > return 0;
> > }
> >
> > -static int intel_set_rps(struct drm_i915_private *dev_priv, u8 val)
> > +static int adjust_rps(struct drm_i915_private *dev_priv, int freq, int adj)
> > {
> > struct intel_rps *rps = &dev_priv->gt_pm.rps;
> > + int min, max, val;
> Can we move to u8 type in this patch itself
No. Check the math, that presumes int clamping, so just use native
register types until after the clamping.
> > int err;
> >
> > lockdep_assert_held(&rps->lock);
> > GEM_BUG_ON(!rps->active);
> > - GEM_BUG_ON(val > rps->max_freq);
> > - GEM_BUG_ON(val < rps->min_freq);
> > +
> > + min = rps->min_freq_softlimit;
> > + max = rps->max_freq_softlimit;
> > + if (atomic_read(&rps->num_waiters) && max < rps->boost_freq)
> > + max = rps->boost_freq;
> > +
> > + GEM_BUG_ON(min < rps->min_freq);
> > + GEM_BUG_ON(max > rps->max_freq);
> > + GEM_BUG_ON(max < min);
> > +
> > + val = clamp(freq + adj, min, max);
> >
> > err = __intel_set_rps(dev_priv, val);
> > if (err)
> > @@ -401,6 +411,8 @@ static int intel_set_rps(struct drm_i915_private
> > *dev_priv, u8 val)
> > rps->cur_freq = val;
> > }
> >
> > + rps->last_adj = val == freq ? adj : 0;
> > +
> I think this should be:
> rps->last_adj = val == freq ? 0 : adj;
If we make the adjustment, store the new adj; if we overrule the
selection, then cancel the adj so that we don't keep on accumulating adj
upon hitting the bounds.
Hmm, should have been val == freq + adj.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 36/36] drm/i915: Support per-context user requests for GPU frequency control
Quoting Sagar Arun Kamble (2018-03-19 09:51:08)
>
>
> On 3/14/2018 3:07 PM, Chris Wilson wrote:
> > @@ -757,8 +767,10 @@ static void guc_submission_tasklet(unsigned long data)
> >
> > rq = port_request(&port[0]);
> > }
> > - if (!rq)
> > + if (!rq) {
> > execlists_clear_active(execlists, EXECLISTS_ACTIVE_USER);
> > + intel_rps_update_engine(engine, NULL);
> I think we also need to do this (update_engine(NULL)) while handling
> preemption completion for both GuC and execlists also.
> Doing it as part of execlists_cancel_port_requests will cover all those
> cases including reset.
> Am I right?
While we don't need it in the intermediate (internal) context switches to
preempt. That is always preceded by execlists_user_end (cancelling the
context frequency selection) or succeeded by the next
execlists_user_begin (selecting the next frequency). However, that was
change was already made to simplify execlists->active handling ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6 (rev3)
== Series Details == Series: drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6 (rev3) URL : https://patchwork.freedesktop.org/series/41453/ State : success == Summary == Series 41453v3 drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6 https://patchwork.freedesktop.org/api/1.0/series/41453/revisions/3/mbox/ Possible new issues: Test gem_exec_gttfill: Subgroup basic: skip -> PASS (fi-pnv-d510) Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-bxt-dsi) fdo#103927 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:428s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:446s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:382s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:537s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-dsi total:243 pass:216 dwarn:0 dfail:0 fail:0 skip:26 fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:512s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:518s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:507s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:416s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:559s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:512s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:584s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:430s fi-gdg-551 total:285 pass:177 dwarn:0 dfail:0 fail:0 skip:108 time:311s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:538s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:485s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:422s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:470s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:439s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:473s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:461s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:508s fi-pnv-d510 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:671s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:444s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:530s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:503s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:492s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:429s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:447s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:565s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:401s 8e7a3b1c5ebd06c5740b0fea76f46ff23d373bd5 drm-tip: 2018y-04m-10d-10h-47m-52s UTC integration manifest 96beacaac4c3 drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8655/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path
Quoting Colin King (2018-04-10 13:33:12)
> From: Colin Ian King
>
> The error exit path when a duplicate is found does not kfree and cmd_entry
> struct and hence there is a small memory leak. Fix this by kfree'ing it.
>
> Detected by CoverityScan, CID#1370198 ("Resource Leak")
>
> Fixes: be1da7070aea ("drm/i915/gvt: vGPU command scanner")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/gvt/cmd_parser.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> index d85939bd7b47..3b6d26c44e37 100644
> --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> @@ -2864,6 +2864,7 @@ static int init_cmd_table(struct intel_gvt *gvt)
> if (info) {
> gvt_err("%s %s duplicated\n", e->info->name,
> info->name);
> + kfree(e);
e kzalloc'ed moments above, not yet added to any lists, so fine to use
kfree.
Alternatively, the find_cmd_entry_any_ring() could be moved ahead of the
kzalloc as this function must be externally serialised.
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/guc: Replace %phn with %phN (rev2)
== Series Details == Series: drm/i915/guc: Replace %phn with %phN (rev2) URL : https://patchwork.freedesktop.org/series/41452/ State : warning == Summary == = CI Bug Log - changes from CI_DRM_4040_full -> Patchwork_8654_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8654_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8654_full, please notify your bug team to allow them to document this new failure mode, which will reduce the CI noise. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8654/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8654_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-bsd2: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_8654_full that come from known issues: === IGT changes === Issues hit igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-wc: shard-hsw: PASS -> DMESG-FAIL (fdo#103167) Possible fixes igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: shard-hsw: FAIL (fdo#104873) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#105189) -> PASS igt@kms_sysfs_edid_timing: shard-apl: WARN (fdo#100047) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 == Participating hosts (6 -> 4) == Missing(2): shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4040 -> Patchwork_8654 CI_DRM_4040: 8e7a3b1c5ebd06c5740b0fea76f46ff23d373bd5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4418: 7c474e011548d35df6b80ceed81d3e6ca560c71d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8654: b5d880211cf1bd2eb6443d506f99e63d69543f89 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4418: 45e115f293fd6acc0c9647cf2d3b76be78819ba5 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8654/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path
== Series Details == Series: drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path URL : https://patchwork.freedesktop.org/series/41469/ State : success == Summary == Series 41469v1 drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path https://patchwork.freedesktop.org/api/1.0/series/41469/revisions/1/mbox/ Possible new issues: Test gem_exec_gttfill: Subgroup basic: skip -> PASS (fi-pnv-d510) Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test kms_chamelium: Subgroup dp-edid-read: pass -> FAIL (fi-kbl-7500u) fdo#102505 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-bxt-dsi) fdo#103927 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:435s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:445s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:383s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:535s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:296s fi-bxt-dsi total:243 pass:216 dwarn:0 dfail:0 fail:0 skip:26 fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:514s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:519s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:506s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:413s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:560s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:513s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:579s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:422s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:317s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:482s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:426s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:464s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:434s fi-kbl-7500u total:285 pass:259 dwarn:1 dfail:0 fail:1 skip:24 time:472s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:460s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:511s fi-pnv-d510 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:658s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:443s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:533s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:503s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:497s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:437s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:447s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:576s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:400s 8e7a3b1c5ebd06c5740b0fea76f46ff23d373bd5 drm-tip: 2018y-04m-10d-10h-47m-52s UTC integration manifest 7573f7c3a226 drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8656/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Don't fiddle with rps/rc6 across GPU reset
Resetting the GPU doesn't affect the RPS/RC6 state, so we can stop
forcibly reloading the registers.
Ville suggested this many moons ago, I said at that time that sanitizing
was no harm and meant that our bookkeeping was kept consistent with the
HW. However, in a forthcoming series, we want to split rps/rc6 GT
powermanagement and one of the key simplifications is the control of
when we enable it. Performing a crude sanitize in the middle of
i915_gem_reset() is then a huge wart.
Suggested-by: Ville Syrjälä
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Reviewed-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_gem.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 28ab0beff86c..60cf7cfc24ee 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3254,13 +3254,6 @@ void i915_gem_reset(struct drm_i915_private *dev_priv,
}
i915_gem_restore_fences(dev_priv);
-
- if (dev_priv->gt.awake) {
- intel_sanitize_gt_powersave(dev_priv);
- intel_enable_gt_powersave(dev_priv);
- if (INTEL_GEN(dev_priv) >= 6)
- gen6_rps_busy(dev_priv);
- }
}
void i915_gem_reset_finish_engine(struct intel_engine_cs *engine)
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6 (rev3)
== Series Details == Series: drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6 (rev3) URL : https://patchwork.freedesktop.org/series/41453/ State : warning == Summary == = CI Bug Log - changes from CI_DRM_4040_full -> Patchwork_8655_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8655_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8655_full, please notify your bug team to allow them to document this new failure mode, which will reduce the CI noise. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8655/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8655_full: === IGT changes === Warnings igt@pm_rc6_residency@rc6-accuracy: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8655_full that come from known issues: === IGT changes === Issues hit igt@gem_mmap_wc@write: shard-kbl: PASS -> DMESG-WARN (fdo#103558) +1 igt@kms_flip@2x-flip-vs-wf_vblank-interruptible: shard-hsw: PASS -> FAIL (fdo#103928) igt@kms_flip@2x-plain-flip-ts-check: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c-frame-sequence: shard-hsw: PASS -> FAIL (fdo#103481) Possible fixes igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: shard-hsw: FAIL (fdo#104873) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#105189) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS shard-kbl: FAIL (fdo#99912) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (6 -> 4) == Missing(2): shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4040 -> Patchwork_8655 CI_DRM_4040: 8e7a3b1c5ebd06c5740b0fea76f46ff23d373bd5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4418: 7c474e011548d35df6b80ceed81d3e6ca560c71d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8655: 96beacaac4c34004b6f38db046f75416785a9016 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4418: 45e115f293fd6acc0c9647cf2d3b76be78819ba5 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8655/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component intialization before audio driver use it
On Tue, 10 Apr 2018, Jani Nikula wrote: > On Tue, 10 Apr 2018, "Shi, Yang A" wrote: >>>On Tue, 10 Apr 2018, "Shi, Yang A" wrote: issue: snd_soc_skl meet "failed to add i915 component master (-19)" when platform don't connect any display output. i915 do initialization before than skl_probe, but if there is no display output connect, in function drm_dp_dpcd_access, there is a 32 retry for aux i2c transactions. It will meet timeout and do usleep. Then skl_probe function will be scheduled. It will call snd_hdac_i915_init, and it will meet "failed to add i915 component master" error. And whole snd_soc_skl initialization will be failed, audio can't work normally anymore. So i915 driver need to move intel_audio_init at the beginning of intel_modeset_init. This will make sure i915_audio_component_init process before snd_hdac_i915_init call it. >>> >>>We do intel_audio_init() and register the audio component when we are >>>ready to handle the audio component calls. We are ready at >>>i915_driver_register(). We are not ready at intel_modeset_init(). >>> >>>BR, >>>Jani. >> >> Thanks to comments my patch. >> After I check the whole driver code, I think all ops in >> i915_audio_component_ops should be ready at the beginning of function >> intel_modeset_init. So can we move intel_audio_init as early as we >> can. > > No, that's not true. Just as an example, dev_priv->cdclk.hw.cdclk hasn't > been initialized. > >> Would you like to suggest a better place to do intel_audio_init? > > I think the call is already where it is supposed to be. We expose > ourselves to the rest of the system when we are ready. If it takes long, > it takes long. I think you have a race in your driver, and you need to > deal with it properly in your driver. > > In snd_hdac_i915_init(), I don't think there are any guarantees that the > request_module() call is the one actually probing i915. We might already > be mid-probe. You don't even check or log request_module() return value. > > I'm also not 100% sure at what point of driver loading request_module() > returns. I think it's when the module init hook returns, which should be > all right, but again, I don't think you can count on that if it isn't > your request_module() that actually probes i915. > > I think the patch at hand is a hack that reduces the window for the > race, and not a real fix. Moreover, it makes the i915 audio component > code fragile by introducing tricky probe order dependencies that we've > been systematically trying to reduce by placing the call where it is > now. > > Cc: Lucas for any further input on module probing. Apparently there was also a bug in some version of kmod/modprobe which could have lead to what you're experiencing. Are you running the fixed version? See [1]. BR, Jani. [1] https://github.com/lucasdemarchi/kmod/commit/fd44a98ae2eb5eb32161088954ab21e58e19dfc4 -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/18] drm/i915/execlists: Set queue priority from secondary port
On 09/04/2018 12:13, Chris Wilson wrote:
We can refine our current execlists->queue_priority if we inspect
ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
the unsubmitted queue and say that if a subsequent request is more than
important than the current queue, we will rerun the submission tasklet
s/more than important/more important/
to evaluate the need for preemption. However, we only want to preempt if
we need to jump ahead of a currently executing request in ELSP. The
second reason for running the submission tasklet is amalgamate requests
into the active context on ELSP[0] to avoid a stall when ELSP[0] drains.
(Though repeatedly amalgamating requests into the active context and
triggering many lite-restore is off question gain, the goal really is to
put a context into ELSP[1] to cover the interrupt.) So if instead of
looking at the head of the queue, we look at the context in ELSP[1] we
can answer both of the questions more accurately -- we don't need to
rerun the submission tasklet unless our new request is important enough
to feed into, at least, ELSP[1].
References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between submission
ports")
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
Cc: Michel Thierry
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3592288e4696..b47d53d284ca 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -713,7 +713,8 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
kmem_cache_free(engine->i915->priorities, p);
}
done:
- execlists->queue_priority = rb ? to_priolist(rb)->priority : INT_MIN;
+ execlists->queue_priority =
+ port != execlists->port ? rq_prio(last) : INT_MIN;
Please bear with my questions since I am not 100% up to date with
preemption.
Should this be rq_prio("port[1]") for future proofing? Or you really
mean last port? In which case it wouldn't be the highest pending
priority as kerneldoc for execlists->queue_priority says.
So this patch changes the meaning of "pending". From pending == "not
submitted to ELSP" to pending == "not submitted to ELSP[0]". Which seems
to make sense, although it is not the easiest job to figure out the
consequences.
It even feels like a bugfix since it prevents tasklet scheduling when
all ports are filled with higher priority requests than the new one.
Although I failed to understand what do we do in both cases if a new
request arrives of higher prio than the one in ELSP[1]. Looks like
nothing? Wait until GPU moves it to ELSP[0] and preempt then? Is this so
because we can't safely or I misread something?
Also, don't you need to manage execlists->queue_priority after CSB
processing now? So that it correctly reflects the priority of request in
ELSP[1] after ELSP[0] gets completed? It seems that without it would get
stuck at the previous value and then submission could decide to skip
scheduling the tasklet if new priority is lower than what was in ELSP[1]
before, and so would fail to fill ELSP[1].
execlists->first = rb;
if (submit)
port_assign(port, last);
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't fiddle with rps/rc6 across GPU reset
== Series Details == Series: drm/i915: Don't fiddle with rps/rc6 across GPU reset URL : https://patchwork.freedesktop.org/series/41474/ State : success == Summary == Series 41474v1 drm/i915: Don't fiddle with rps/rc6 across GPU reset https://patchwork.freedesktop.org/api/1.0/series/41474/revisions/1/mbox/ Possible new issues: Test gem_exec_gttfill: Subgroup basic: skip -> PASS (fi-pnv-d510) fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:430s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:445s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:389s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:536s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:518s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:516s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:521s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:510s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:412s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:564s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:513s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:587s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:426s fi-gdg-551 total:285 pass:177 dwarn:0 dfail:0 fail:0 skip:108 time:317s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:548s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:487s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:406s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:421s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:467s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:439s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:473s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:464s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:510s fi-pnv-d510 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:669s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:445s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:537s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:509s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:508s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:431s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:444s fi-snb-2520m total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:400s 8e7a3b1c5ebd06c5740b0fea76f46ff23d373bd5 drm-tip: 2018y-04m-10d-10h-47m-52s UTC integration manifest 59682cbe5c9f drm/i915: Don't fiddle with rps/rc6 across GPU reset == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8657/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/18] drm/i915/execlists: Set queue priority from secondary port
Quoting Tvrtko Ursulin (2018-04-10 15:05:33)
>
> On 09/04/2018 12:13, Chris Wilson wrote:
> > We can refine our current execlists->queue_priority if we inspect
> > ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
> > the unsubmitted queue and say that if a subsequent request is more than
> > important than the current queue, we will rerun the submission tasklet
>
> s/more than important/more important/
>
> > to evaluate the need for preemption. However, we only want to preempt if
> > we need to jump ahead of a currently executing request in ELSP. The
> > second reason for running the submission tasklet is amalgamate requests
> > into the active context on ELSP[0] to avoid a stall when ELSP[0] drains.
> > (Though repeatedly amalgamating requests into the active context and
> > triggering many lite-restore is off question gain, the goal really is to
> > put a context into ELSP[1] to cover the interrupt.) So if instead of
> > looking at the head of the queue, we look at the context in ELSP[1] we
> > can answer both of the questions more accurately -- we don't need to
> > rerun the submission tasklet unless our new request is important enough
> > to feed into, at least, ELSP[1].
> >
> > References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between
> > submission ports")
> > Signed-off-by: Chris Wilson
> > Cc: Michał Winiarski
> > Cc: Michel Thierry
> > Cc: Mika Kuoppala
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 3592288e4696..b47d53d284ca 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -713,7 +713,8 @@ static void execlists_dequeue(struct intel_engine_cs
> > *engine)
> > kmem_cache_free(engine->i915->priorities, p);
> > }
> > done:
> > - execlists->queue_priority = rb ? to_priolist(rb)->priority : INT_MIN;
> > + execlists->queue_priority =
> > + port != execlists->port ? rq_prio(last) : INT_MIN;
>
> Please bear with my questions since I am not 100% up to date with
> preemption.
>
> Should this be rq_prio("port[1]") for future proofing? Or you really
> mean last port? In which case it wouldn't be the highest pending
> priority as kerneldoc for execlists->queue_priority says.
I mean "secondary" port, so yes using last executing port under the
assumption that we grow into a ring of many useless submission ports.
The kerneldoc is no more or no less accurate. :)
> So this patch changes the meaning of "pending". From pending == "not
> submitted to ELSP" to pending == "not submitted to ELSP[0]". Which seems
> to make sense, although it is not the easiest job to figure out the
> consequences.
Yes.
> It even feels like a bugfix since it prevents tasklet scheduling when
> all ports are filled with higher priority requests than the new one.
It won't fix any bugs, since we just reduce the number of kicks. Kicking
and evaluating we have nothing to do is just wasted work. So yes I do
agree that it is a bug fix, just not enough to merit a Fixes.
> Although I failed to understand what do we do in both cases if a new
> request arrives of higher prio than the one in ELSP[1]. Looks like
> nothing? Wait until GPU moves it to ELSP[0] and preempt then? Is this so
> because we can't safely or I misread something?
This is covered by igt/gem_exec_schedule/preempt-queue*. If we receive a
request higher than ELSP[1], we start a preemption as
if (need_preempt(engine, last, execlists->queue_priority)) {
will evaluate to true. It's either the lowest executing priority (new
code), or lowest pending priority (old code). In either case, if the new
request is more important than the queue_priority, we preempt.
We won't evaluate preemption if we are still awaiting the HWACK from the
last ELSP write, or if we are still preempting. In both of those cases,
we expect to receive an interrupt promptly, upon which we then redo our
evaluations.
> Also, don't you need to manage execlists->queue_priority after CSB
> processing now? So that it correctly reflects the priority of request in
> ELSP[1] after ELSP[0] gets completed? It seems that without it would get
> stuck at the previous value and then submission could decide to skip
> scheduling the tasklet if new priority is lower than what was in ELSP[1]
> before, and so would fail to fill ELSP[1].
Yes, that is also done here. Since we are always looking one request
ahead, we either update the priority based on the queue following the
resubmission on interrupt, or it is left as INT_MIN on completion.
Indeed, making sure we reset back to INT_MIN is essential so that we
don't any future submissions from idle.
We can add GEM_BUG_ON(queue_priority != INT_MIN) in engines_park to
check this condition.
-Chris
[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path
== Series Details == Series: drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path URL : https://patchwork.freedesktop.org/series/41469/ State : warning == Summary == = CI Bug Log - changes from CI_DRM_4040_full -> Patchwork_8656_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8656_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8656_full, please notify your bug team to allow them to document this new failure mode, which will reduce the CI noise. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8656/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8656_full: === IGT changes === Warnings igt@perf_pmu@rc6: shard-kbl: SKIP -> PASS +1 == Known issues == Here are the changes found in Patchwork_8656_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@dpms-vs-vblank-race: shard-hsw: PASS -> FAIL (fdo#103060) Possible fixes igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: shard-hsw: FAIL (fdo#104873) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#105189) -> PASS igt@kms_sysfs_edid_timing: shard-apl: WARN (fdo#100047) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 == Participating hosts (6 -> 4) == Missing(2): shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4040 -> Patchwork_8656 CI_DRM_4040: 8e7a3b1c5ebd06c5740b0fea76f46ff23d373bd5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4418: 7c474e011548d35df6b80ceed81d3e6ca560c71d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8656: 7573f7c3a226d4f56ea7a50c6c938e40c96a2c63 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4418: 45e115f293fd6acc0c9647cf2d3b76be78819ba5 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8656/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add debugfs file to clear FIFO underruns.
Op 09-04-18 om 21:48 schreef Rodrigo Vivi: > On Wed, Mar 28, 2018 at 06:20:26PM +0200, Maarten Lankhorst wrote: >> Op 28-03-18 om 12:21 schreef Jani Nikula: >>> On Wed, 28 Mar 2018, Maarten Lankhorst >>> wrote: Adding a i915_fifo_underrun_reset debugfs file will make it possible for IGT tests to clear FIFO underrun fallout at the start of each subtest, and make re-enable FBC so tests always have maximum exposure to features used by IGT. FIFO underruns and FBC bugs will no longer hide when an earlier subtests disables both. Signed-off-by: Maarten Lankhorst Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105685 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105681 >>> FWIW, ack on the idea, didn't look at the implementation. >> Well I had a NV12 test that produced FIFO underruns, did some quick testing >> against the i915_fifo_underrun_reset file and manually writing it does reset >> FIFO underruns. >> Immediately after i915_fbc_status still reads "FBC disabled: underrun >> detected", but this is cleared by the next atomic commit. So I think it >> works, and can be used for igt in the way I wrote it. > What about a error message change on fbc_status to reflect this temporary > state? > Just to avoid later confusion on expectation. Done, if an underrun is cleared, the reason will be set to 'FIFO underrun cleared'. > But the approach and code look sane for me, so anyways: > > Reviewed-by: Rodrigo Vivi Thanks for reviewing, pushed. :) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/18] drm/i915/execlists: Set queue priority from secondary port
On 10/04/2018 15:24, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-10 15:05:33)
On 09/04/2018 12:13, Chris Wilson wrote:
We can refine our current execlists->queue_priority if we inspect
ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
the unsubmitted queue and say that if a subsequent request is more than
important than the current queue, we will rerun the submission tasklet
s/more than important/more important/
to evaluate the need for preemption. However, we only want to preempt if
we need to jump ahead of a currently executing request in ELSP. The
second reason for running the submission tasklet is amalgamate requests
into the active context on ELSP[0] to avoid a stall when ELSP[0] drains.
(Though repeatedly amalgamating requests into the active context and
triggering many lite-restore is off question gain, the goal really is to
put a context into ELSP[1] to cover the interrupt.) So if instead of
looking at the head of the queue, we look at the context in ELSP[1] we
can answer both of the questions more accurately -- we don't need to
rerun the submission tasklet unless our new request is important enough
to feed into, at least, ELSP[1].
References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between submission
ports")
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
Cc: Michel Thierry
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3592288e4696..b47d53d284ca 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -713,7 +713,8 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
kmem_cache_free(engine->i915->priorities, p);
}
done:
- execlists->queue_priority = rb ? to_priolist(rb)->priority : INT_MIN;
+ execlists->queue_priority =
+ port != execlists->port ? rq_prio(last) : INT_MIN;
Please bear with my questions since I am not 100% up to date with
preemption.
Should this be rq_prio("port[1]") for future proofing? Or you really
mean last port? In which case it wouldn't be the highest pending
priority as kerneldoc for execlists->queue_priority says.
I mean "secondary" port, so yes using last executing port under the
assumption that we grow into a ring of many useless submission ports.
The kerneldoc is no more or no less accurate. :)
"That we _don't_ grow"?
So this patch changes the meaning of "pending". From pending == "not
submitted to ELSP" to pending == "not submitted to ELSP[0]". Which seems
to make sense, although it is not the easiest job to figure out the
consequences.
Yes.
It even feels like a bugfix since it prevents tasklet scheduling when
all ports are filled with higher priority requests than the new one.
It won't fix any bugs, since we just reduce the number of kicks. Kicking
and evaluating we have nothing to do is just wasted work. So yes I do
agree that it is a bug fix, just not enough to merit a Fixes.
Yeah that's fine.
Although I failed to understand what do we do in both cases if a new
request arrives of higher prio than the one in ELSP[1]. Looks like
nothing? Wait until GPU moves it to ELSP[0] and preempt then? Is this so
because we can't safely or I misread something?
This is covered by igt/gem_exec_schedule/preempt-queue*. If we receive a
request higher than ELSP[1], we start a preemption as
if (need_preempt(engine, last, execlists->queue_priority)) {
will evaluate to true. It's either the lowest executing priority (new
code), or lowest pending priority (old code). In either case, if the new
request is more important than the queue_priority, we preempt.
How when "last" is request from ELSP[0]? And also
execlists->queue_priority has not yet been updated to reflect the new
priority?
Then there is also "if (port_count(port0)) goto unlock;" suggesting that
if there were any appends to ELSP[0] we will also fail to act in this
situation?
We won't evaluate preemption if we are still awaiting the HWACK from the
last ELSP write, or if we are still preempting. In both of those cases,
we expect to receive an interrupt promptly, upon which we then redo our
evaluations.
Also, don't you need to manage execlists->queue_priority after CSB
processing now? So that it correctly reflects the priority of request in
ELSP[1] after ELSP[0] gets completed? It seems that without it would get
stuck at the previous value and then submission could decide to skip
scheduling the tasklet if new priority is lower than what was in ELSP[1]
before, and so would fail to fill ELSP[1].
Yes, that is also done here. Since we are always looking one request
ahead, we either update the priority based on the queue following the
resubmission on interrupt, or it is left as INT_MIN on completion.
Indeed, making sure we reset back to INT_MIN is essential s
Re: [Intel-gfx] [PATCH 01/18] drm/i915/execlists: Set queue priority from secondary port
Quoting Tvrtko Ursulin (2018-04-10 15:42:07)
>
> On 10/04/2018 15:24, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-04-10 15:05:33)
> >>
> >> On 09/04/2018 12:13, Chris Wilson wrote:
> >>> We can refine our current execlists->queue_priority if we inspect
> >>> ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
> >>> the unsubmitted queue and say that if a subsequent request is more than
> >>> important than the current queue, we will rerun the submission tasklet
> >>
> >> s/more than important/more important/
> >>
> >>> to evaluate the need for preemption. However, we only want to preempt if
> >>> we need to jump ahead of a currently executing request in ELSP. The
> >>> second reason for running the submission tasklet is amalgamate requests
> >>> into the active context on ELSP[0] to avoid a stall when ELSP[0] drains.
> >>> (Though repeatedly amalgamating requests into the active context and
> >>> triggering many lite-restore is off question gain, the goal really is to
> >>> put a context into ELSP[1] to cover the interrupt.) So if instead of
> >>> looking at the head of the queue, we look at the context in ELSP[1] we
> >>> can answer both of the questions more accurately -- we don't need to
> >>> rerun the submission tasklet unless our new request is important enough
> >>> to feed into, at least, ELSP[1].
> >>>
> >>> References: f6322eddaff7 ("drm/i915/preemption: Allow preemption between
> >>> submission ports")
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Michał Winiarski
> >>> Cc: Michel Thierry
> >>> Cc: Mika Kuoppala
> >>> Cc: Tvrtko Ursulin
> >>> ---
> >>>drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
> >>>1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> >>> b/drivers/gpu/drm/i915/intel_lrc.c
> >>> index 3592288e4696..b47d53d284ca 100644
> >>> --- a/drivers/gpu/drm/i915/intel_lrc.c
> >>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> >>> @@ -713,7 +713,8 @@ static void execlists_dequeue(struct intel_engine_cs
> >>> *engine)
> >>>kmem_cache_free(engine->i915->priorities, p);
> >>>}
> >>>done:
> >>> - execlists->queue_priority = rb ? to_priolist(rb)->priority :
> >>> INT_MIN;
> >>> + execlists->queue_priority =
> >>> + port != execlists->port ? rq_prio(last) : INT_MIN;
> >>
> >> Please bear with my questions since I am not 100% up to date with
> >> preemption.
> >>
> >> Should this be rq_prio("port[1]") for future proofing? Or you really
> >> mean last port? In which case it wouldn't be the highest pending
> >> priority as kerneldoc for execlists->queue_priority says.
> >
> > I mean "secondary" port, so yes using last executing port under the
> > assumption that we grow into a ring of many useless submission ports.
> > The kerneldoc is no more or no less accurate. :)
>
> "That we _don't_ grow"?
Hmm, no, when we get "last_port" it slots right into here. I just don't
have the future facing code to prevent Mika from having to think a
little. The intent is that when there is a ELSP slot available,
queue_priority is INT_MIN, when there are none, then rq_prio(last).
My bad for remembering what I want the code to be without remembering
what the code says.
> >> Although I failed to understand what do we do in both cases if a new
> >> request arrives of higher prio than the one in ELSP[1]. Looks like
> >> nothing? Wait until GPU moves it to ELSP[0] and preempt then? Is this so
> >> because we can't safely or I misread something?
> >
> > This is covered by igt/gem_exec_schedule/preempt-queue*. If we receive a
> > request higher than ELSP[1], we start a preemption as
> >
> > if (need_preempt(engine, last, execlists->queue_priority)) {
> >
> > will evaluate to true. It's either the lowest executing priority (new
> > code), or lowest pending priority (old code). In either case, if the new
> > request is more important than the queue_priority, we preempt.
>
> How when "last" is request from ELSP[0]? And also
> execlists->queue_priority has not yet been updated to reflect the new
> priority?
When we start executing last on ELSP[0] there will have been another
execlists_dequeue() where we see an empty slot (or fill it) and update
queue_priority. If we are down to the last request, it will be set to
INT_MIN. Upon its completion, it will remain INT_MIN.
> Then there is also "if (port_count(port0)) goto unlock;" suggesting that
> if there were any appends to ELSP[0] we will also fail to act in this
> situation?
If we only write into ELSP[0], then ELSP[1] remains empty and the
queue_priority still needs to INT_MIN so that we service any new
i915_request_add immediately.
> > We won't evaluate preemption if we are still awaiting the HWACK from the
> > last ELSP write, or if we are still preempting. In both of those cases,
> > we expect to receive an interrupt promptly, upon which we then redo our
> > evaluations.
> >
> >> Also, don't you need to manage
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tools/aubdump: Fix ISO C90 forbids mixed declarations and code warning
Tvrtko Ursulin writes:
> On 09/04/2018 18:03, Scott D Phillips wrote:
>> Tvrtko Ursulin writes:
>>
>>> From: Tvrtko Ursulin
>>>
>>> Back to a clean build with no warnings, at least for me.
>>
>> Why c90? If that's the language we mean to target then we should
>> probably add it to the build system so people with gcc 5.1 and later
>> will see the warnings too. fwiw, my build with clang 6 gives a couple
>> dozen warnings.
>
> I am building under Ubuntu 17.10 with GCC 7.2.0. Normal configure &&
> make, and get this warning. And since I can't spot that IGT is setting
> the C standard explicitly, I guess that's the default.
Ah, turns out it's not -std=c90, but an explicit
-Wdeclaration-after-statement that we pick up through
XORG_DEFAULT_OPTIONS. Clang seems to emit that warning only if it's in
c90 mode, which is why I didn't see it. So I'll say
Reviewed-by: Scott D Phillips
> This one is the only warning on my build btw.
>
> Regards,
>
> Tvrtko
>
>>> Signed-off-by: Tvrtko Ursulin
>>> Cc: Jordan Justen
>>> Cc: Scott D Phillips
>>> ---
>>> tools/aubdump.c | 7 ---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/tools/aubdump.c b/tools/aubdump.c
>>> index 267061b0fc2b..2d2b6c607a43 100644
>>> --- a/tools/aubdump.c
>>> +++ b/tools/aubdump.c
>>> @@ -394,10 +394,11 @@ gen8_emit_ggtt_pte_for_range(uint64_t start, uint64_t
>>> end)
>>>
>>> entry_addr = start & ~(4096 - 1);
>>> do {
>>> + uint64_t last_page_entry, num_entries;
>>> +
>>> page_num = entry_addr >> 21;
>>> - uint64_t last_page_entry =
>>> - min((page_num + 1) << 21, end_aligned);
>>> - uint64_t num_entries = (last_page_entry - entry_addr) >> 12;
>>> + last_page_entry = min((page_num + 1) << 21, end_aligned);
>>> + num_entries = (last_page_entry - entry_addr) >> 12;
>>> mem_trace_memory_write_header_out(
>>> entry_addr >> 9, num_entries * GEN8_PTE_SIZE,
>>> AUB_MEM_TRACE_MEMORY_ADDRESS_SPACE_GGTT_ENTRY);
>>> --
>>> 2.14.1
>> ___
>> igt-dev mailing list
>> igt-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/18] drm/i915/execlists: Set queue priority from secondary port
Quoting Chris Wilson (2018-04-10 15:56:03)
> Quoting Tvrtko Ursulin (2018-04-10 15:42:07)
> >
> > On 10/04/2018 15:24, Chris Wilson wrote:
> > > Quoting Tvrtko Ursulin (2018-04-10 15:05:33)
> > >> Although I failed to understand what do we do in both cases if a new
> > >> request arrives of higher prio than the one in ELSP[1]. Looks like
> > >> nothing? Wait until GPU moves it to ELSP[0] and preempt then? Is this so
> > >> because we can't safely or I misread something?
> > >
> > > This is covered by igt/gem_exec_schedule/preempt-queue*. If we receive a
> > > request higher than ELSP[1], we start a preemption as
> > >
> > > if (need_preempt(engine, last, execlists->queue_priority)) {
> > >
> > > will evaluate to true. It's either the lowest executing priority (new
> > > code), or lowest pending priority (old code). In either case, if the new
> > > request is more important than the queue_priority, we preempt.
> >
> > How when "last" is request from ELSP[0]? And also
> > execlists->queue_priority has not yet been updated to reflect the new
> > priority?
>
> When we start executing last on ELSP[0] there will have been another
> execlists_dequeue() where we see an empty slot (or fill it) and update
> queue_priority. If we are down to the last request, it will be set to
> INT_MIN. Upon its completion, it will remain INT_MIN.
>
> > Then there is also "if (port_count(port0)) goto unlock;" suggesting that
> > if there were any appends to ELSP[0] we will also fail to act in this
> > situation?
>
> If we only write into ELSP[0], then ELSP[1] remains empty and the
> queue_priority still needs to INT_MIN so that we service any new
> i915_request_add immediately.
>
> > > We won't evaluate preemption if we are still awaiting the HWACK from the
> > > last ELSP write, or if we are still preempting. In both of those cases,
> > > we expect to receive an interrupt promptly, upon which we then redo our
> > > evaluations.
> > >
> > >> Also, don't you need to manage execlists->queue_priority after CSB
> > >> processing now? So that it correctly reflects the priority of request in
> > >> ELSP[1] after ELSP[0] gets completed? It seems that without it would get
> > >> stuck at the previous value and then submission could decide to skip
> > >> scheduling the tasklet if new priority is lower than what was in ELSP[1]
> > >> before, and so would fail to fill ELSP[1].
> > >
> > > Yes, that is also done here. Since we are always looking one request
> > > ahead, we either update the priority based on the queue following the
> > > resubmission on interrupt, or it is left as INT_MIN on completion.
> > > Indeed, making sure we reset back to INT_MIN is essential so that we
> > > don't any future submissions from idle.
> >
> > Okay I see it - because execlists_dequeue is called and runs to the
> > queue_priority update bit even when there is nothing in the queue.
>
> Phew, I can get away from having to draw ascii diagrams. I'll leave that
> to Mika as he figures out how to hook up N ports ;)
/*
* Here be a bit of magic! Or sleight-of-hand, whichever you prefer.
*
* We choose queue_priority such that if we add a request of greater
* priority than this, we kick the submission tasklet to decide on
* the right order of submitting the requests to hardware. We must
* also be prepared to reorder requests as they are in-flight on the
* HW. We derive the queue_priority then as the first "hole" in
* the HW submission ports and if there are no available slots,
* it the priority of the lowest executing request, i.e. the last one.
*/
execlists->queue_priority =
port != execlists->port ? rq_prio(last) : INT_MIN;
Does that help, or do I need ASCII art?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Replace use of pipe_crc->lock with an atomic
pipe_crc->lock only protects pipe_crc->skipped. Replace the lock with
atomic operations instead, it should work just as well, without the
spinlock. In the case we don't skip CRC in the irq, the fastpath is
only a single atomic_read().
Signed-off-by: Maarten Lankhorst
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 1 -
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_irq.c | 15 ---
drivers/gpu/drm/i915/intel_pipe_crc.c | 20 +++-
4 files changed, 12 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f770be18b2d7..8cb61e51eb33 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -938,7 +938,6 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
intel_init_display_hooks(dev_priv);
intel_init_clock_gating_hooks(dev_priv);
intel_init_audio_hooks(dev_priv);
- intel_display_crc_init(dev_priv);
intel_detect_preproduction_hw(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4f139ab95547..648c41bb5bd1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1264,8 +1264,7 @@ enum intel_pipe_crc_source {
#define INTEL_PIPE_CRC_ENTRIES_NR 128
struct intel_pipe_crc {
- spinlock_t lock;
- int skipped;
+ atomic_t skipped;
enum intel_pipe_crc_source source;
};
@@ -3323,12 +3322,10 @@ u32 i915_gem_fence_alignment(struct drm_i915_private
*dev_priv, u32 size,
#ifdef CONFIG_DEBUG_FS
int i915_debugfs_register(struct drm_i915_private *dev_priv);
int i915_debugfs_connector_add(struct drm_connector *connector);
-void intel_display_crc_init(struct drm_i915_private *dev_priv);
#else
static inline int i915_debugfs_register(struct drm_i915_private *dev_priv)
{return 0;}
static inline int i915_debugfs_connector_add(struct drm_connector *connector)
{ return 0; }
-static inline void intel_display_crc_init(struct drm_i915_private *dev_priv) {}
#endif
const char *i915_cache_level_str(struct drm_i915_private *i915, int type);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d8751881b0d2..20174b98aad9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1682,8 +1682,8 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
uint32_t crcs[5];
+ int to_skip;
- spin_lock(&pipe_crc->lock);
/*
* For some not yet identified reason, the first CRC is
* bonkers. So let's just wait for the next vblank and read
@@ -1692,13 +1692,14 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
* On GEN8+ sometimes the second CRC is bonkers as well, so
* don't trust that one either.
*/
- if (pipe_crc->skipped <= 0 ||
- (INTEL_GEN(dev_priv) >= 8 && pipe_crc->skipped == 1)) {
- pipe_crc->skipped++;
- spin_unlock(&pipe_crc->lock);
+
+ if (INTEL_GEN(dev_priv) >= 8)
+ to_skip = 2;
+ else
+ to_skip = 1;
+
+ if (atomic_add_unless(&pipe_crc->skipped, 1, to_skip))
return;
- }
- spin_unlock(&pipe_crc->lock);
crcs[0] = crc0;
crcs[1] = crc1;
diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index 0e38c382e231..5320c1fcb3dc 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -458,17 +458,6 @@ display_crc_ctl_parse_source(const char *buf, enum
intel_pipe_crc_source *s)
return -EINVAL;
}
-void intel_display_crc_init(struct drm_i915_private *dev_priv)
-{
- enum pipe pipe;
-
- for_each_pipe(dev_priv, pipe) {
- struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
-
- spin_lock_init(&pipe_crc->lock);
- }
-}
-
int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char *source_name,
size_t *values_cnt)
{
@@ -508,7 +497,7 @@ int intel_crtc_set_crc_source(struct drm_crtc *crtc, const
char *source_name,
hsw_pipe_A_crc_wa(dev_priv, false);
}
- pipe_crc->skipped = 0;
+ atomic_set(&pipe_crc->skipped, 0);
*values_cnt = 5;
out:
@@ -530,8 +519,7 @@ void intel_crtc_enable_pipe_crc(struct intel_crtc
*intel_crtc)
if (get_new_crc_ctl_reg(dev_priv, crtc->index, &pipe_crc->source, &val,
false) < 0)
return;
- /* Don't need pipe_crc->lock here, IRQs are not generated. */
- pipe_crc->skipped = 0;
+ atomic_set(&pipe_crc->skipped, 0);
I915_WRITE(PIPE_CRC_CTL(crtc->index), va
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Replace use of pipe_crc->lock with an atomic
== Series Details == Series: drm/i915: Replace use of pipe_crc->lock with an atomic URL : https://patchwork.freedesktop.org/series/41485/ State : failure == Summary == Applying: drm/i915: Replace use of pipe_crc->lock with an atomic error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_drv.h). error: could not build fake ancestor Patch failed at 0001 drm/i915: Replace use of pipe_crc->lock with an atomic The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Don't fiddle with rps/rc6 across GPU reset
== Series Details == Series: drm/i915: Don't fiddle with rps/rc6 across GPU reset URL : https://patchwork.freedesktop.org/series/41474/ State : warning == Summary == = CI Bug Log - changes from CI_DRM_4040_full -> Patchwork_8657_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8657_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8657_full, please notify your bug team to allow them to document this new failure mode, which will reduce the CI noise. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8657/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8657_full: === IGT changes === Warnings igt@perf_pmu@rc6: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_8657_full that come from known issues: === IGT changes === Possible fixes igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: shard-hsw: FAIL (fdo#104873) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-hsw: FAIL (fdo#105189) -> PASS fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 == Participating hosts (6 -> 4) == Missing(2): shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4040 -> Patchwork_8657 CI_DRM_4040: 8e7a3b1c5ebd06c5740b0fea76f46ff23d373bd5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4418: 7c474e011548d35df6b80ceed81d3e6ca560c71d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8657: 59682cbe5c9fe2607aec878cf7151289d90a8ccb @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4418: 45e115f293fd6acc0c9647cf2d3b76be78819ba5 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8657/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
Hi All,
I see the latest BAT test failed but the only thing I changed in this
new patchset is comment. It should be false alarm, not sure if this is
halting the further review. Please see if the code needs more change.
Thanks,
Yunwei
On 3/29/2018 8:44 AM, Yunwei Zhang wrote:
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate 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. Otherwise, incorrect value will be returned.
However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all cases
across slice/subslice. There are rare occasions such as INSTDONE that this
value will be dependent on slice/subslice combo, in such cases, we need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.
Also, 0xFDC will lose its information after TDR/engine reset/power state
change.
References: HSD#1405586840, BSID#0575
v2:
- use fls() instead of find_last_bit() (Chris)
- added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
- rebase on latest tip
v5:
- Added references (Mika)
- Change the ordered of passing arguments and etc. (Ursulin)
v6:
- Updated the comment that conflict with the patch. (Chris)
Cc: Oscar Mateo
Cc: Michel Thierry
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Signed-off-by: Yunwei Zhang
---
drivers/gpu/drm/i915/intel_engine_cs.c | 42 +++---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 12486d8..4c50bee 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -796,6 +796,27 @@ const char *i915_cache_level_str(struct drm_i915_private
*i915, int type)
}
}
+static u32 calculate_mcr(struct drm_i915_private *dev_priv, u32 mcr)
+{
+ const struct sseu_dev_info *sseu = &(INTEL_INFO(dev_priv)->sseu);
+ u32 slice = fls(sseu->slice_mask);
+ u32 subslice = fls(sseu->subslice_mask[slice]);
+
+ mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
+ mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
+
+ return mcr;
+}
+
+static void wa_init_mcr(struct drm_i915_private *dev_priv)
+{
+ u32 mcr;
+
+ mcr = I915_READ(GEN8_MCR_SELECTOR);
+ mcr = calculate_mcr(dev_priv, mcr);
+ I915_WRITE(GEN8_MCR_SELECTOR, mcr);
+}
+
static inline uint32_t
read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
int subslice, i915_reg_t reg)
@@ -828,18 +849,30 @@ read_subslice_reg(struct drm_i915_private *dev_priv, int
slice,
intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
mcr = I915_READ_FW(GEN8_MCR_SELECTOR);
+
/*
* The HW expects the slice and sublice selectors to be reset to 0
-* after reading out the registers.
+* before GEN10 or to a enabled s/ss post GEN10 after reading out the
+* registers.
*/
- WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
+ WARN_ON_ONCE(INTEL_GEN(dev_priv) < 10 &&
+(mcr & mcr_slice_subslice_mask));
mcr &= ~mcr_slice_subslice_mask;
mcr |= mcr_slice_subslice_select;
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
ret = I915_READ_FW(reg);
- mcr &= ~mcr_slice_subslice_mask;
+ /*
+* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl
+* expects mcr to be programed to a enabled slice/subslice pair
+* before any MMIO read into slice/subslice register
+*/
+ if (INTEL_GEN(dev_priv) < 10)
+ mcr &= ~mcr_slice_subslice_mask;
+ else
+ mcr = calculate_mcr(dev_priv, mcr);
+
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
intel_uncore_forcewake_put__locked(dev_priv, fw_domains);
@@ -1307,6 +1340,9 @@ static int cnl_init_workarounds(struct intel_engine_cs
*engine)
struct drm_i915_private *dev_priv = engine->i915;
int ret;
+ /* WaProgramMgsrForCorrectSliceSpecificMmioReads: cnl */
+ wa_init_mcr(dev_priv);
+
/* WaDisableI2mCycleOnWRPort:cnl (pre-prod) */
if (IS_CNL_REVID(dev_priv, CNL_REVID_B0, CNL_REVID_B0))
I915_WRITE(GAMT_CHKN_BIT_REG,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Move a bunch of workaround-related code to its own file
This has grown to be a sizable amount of code, so move it to
its own file before we try to refactor anything. For the moment,
we are leaving behind the WA BB code and the WAs that get applied
(incorrectly) in init_clock_gating, but we will deal with it later.
v2: Use intel_ prefix for code that deals with the hardware (Chris)
v3: Rebased
v4:
- Rebased
- New license header
v5:
- Rebased
- Added some organisational notes to the file (Chris)
v6: Include DOC section in the documentation build (Jani)
Signed-off-by: Oscar Mateo
Cc: Mika Kuoppala
Cc: Jani Nikula
Reviewed-by: Chris Wilson
---
Documentation/gpu/i915.rst | 6 +
drivers/gpu/drm/i915/Makefile| 3 +-
drivers/gpu/drm/i915/intel_engine_cs.c | 634
drivers/gpu/drm/i915/intel_lrc.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 -
drivers/gpu/drm/i915/intel_workarounds.c | 684 +++
drivers/gpu/drm/i915/intel_workarounds.h | 13 +
8 files changed, 707 insertions(+), 638 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_workarounds.c
create mode 100644 drivers/gpu/drm/i915/intel_workarounds.h
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 34d22f2..055df45 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -58,6 +58,12 @@ Intel GVT-g Host Support(vGPU device model)
.. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c
:internal:
+Workarounds
+---
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_workarounds.c
+ :doc: Hardware workarounds
+
Display Hardware Handling
=
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0c79c19..9bee52a9 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -43,7 +43,8 @@ i915-y := i915_drv.o \
intel_csr.o \
intel_device_info.o \
intel_pm.o \
- intel_runtime_pm.o
+ intel_runtime_pm.o \
+ intel_workarounds.o
i915-$(CONFIG_COMPAT) += i915_ioc32.o
i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 12486d8..67b4eeb 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -903,640 +903,6 @@ void intel_engine_get_instdone(struct intel_engine_cs
*engine,
}
}
-static int wa_add(struct drm_i915_private *dev_priv,
- i915_reg_t addr,
- const u32 mask, const u32 val)
-{
- const u32 idx = dev_priv->workarounds.count;
-
- if (WARN_ON(idx >= I915_MAX_WA_REGS))
- return -ENOSPC;
-
- dev_priv->workarounds.reg[idx].addr = addr;
- dev_priv->workarounds.reg[idx].value = val;
- dev_priv->workarounds.reg[idx].mask = mask;
-
- dev_priv->workarounds.count++;
-
- return 0;
-}
-
-#define WA_REG(addr, mask, val) do { \
- const int r = wa_add(dev_priv, (addr), (mask), (val)); \
- if (r) \
- return r; \
- } while (0)
-
-#define WA_SET_BIT_MASKED(addr, mask) \
- WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
-
-#define WA_CLR_BIT_MASKED(addr, mask) \
- WA_REG(addr, (mask), _MASKED_BIT_DISABLE(mask))
-
-#define WA_SET_FIELD_MASKED(addr, mask, value) \
- WA_REG(addr, mask, _MASKED_FIELD(mask, value))
-
-static int wa_ring_whitelist_reg(struct intel_engine_cs *engine,
-i915_reg_t reg)
-{
- struct drm_i915_private *dev_priv = engine->i915;
- struct i915_workarounds *wa = &dev_priv->workarounds;
- const uint32_t index = wa->hw_whitelist_count[engine->id];
-
- if (WARN_ON(index >= RING_MAX_NONPRIV_SLOTS))
- return -EINVAL;
-
- I915_WRITE(RING_FORCE_TO_NONPRIV(engine->mmio_base, index),
- i915_mmio_reg_offset(reg));
- wa->hw_whitelist_count[engine->id]++;
-
- return 0;
-}
-
-static int gen8_init_workarounds(struct intel_engine_cs *engine)
-{
- struct drm_i915_private *dev_priv = engine->i915;
-
- WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING);
-
- /* WaDisableAsyncFlipPerfMode:bdw,chv */
- WA_SET_BIT_MASKED(MI_MODE, ASYNC_FLIP_PERF_DISABLE);
-
- /* WaDisablePartialInstShootdown:bdw,chv */
- WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN,
- PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
-
- /* Use Force Non-Coherent whenever executing a 3D context. This is a
-* workaround for for a possible hang in the unlikely event a TLB
-* invalidation occurs during a PSD flush.
-*/
- /* WaForceEnableNonCoherent:bdw,chv */
- /* WaHdcDisableFetchWhenMasked:bdw,chv */
- WA_SET_BIT_MASKED(HDC_CHICKEN0,
- HDC_DONOT_FETCH_MEM_WHEN_MASKED |
- H
[Intel-gfx] [PATCH 2/2] drm/i915: Split out functions for different kinds of workarounds
There are different kind of workarounds (those that modify registers that
live in the context image, those that modify global registers, those that
whitelist registers, etc...) and they have different requirements in terms
of where they are applied and how. Also, by splitting them apart, it should
be easier to decide where a new workaround should go.
v2:
- Add multiple MISSING_CASE
- Rebased
v3:
- Rename mmio_workarounds to gt_workarounds (Chris, Mika)
- Create empty placeholders for BDW and CHV GT WAs
- Rebased
v4: Rebased
v5:
- Rebased
- FORCE_TO_NONPRIV register exists since BDW, so make a path
for it to achieve universality, even if empty (Chris)
Signed-off-by: Oscar Mateo
Cc: Mika Kuoppala
Cc: Ville Syrjälä
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 3 +
drivers/gpu/drm/i915/i915_gem_context.c | 6 +
drivers/gpu/drm/i915/intel_lrc.c | 14 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 8 +-
drivers/gpu/drm/i915/intel_workarounds.c | 636 +++
drivers/gpu/drm/i915/intel_workarounds.h | 8 +-
6 files changed, 433 insertions(+), 242 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 28ab0be..ab846f8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -35,6 +35,7 @@
#include "intel_drv.h"
#include "intel_frontbuffer.h"
#include "intel_mocs.h"
+#include "intel_workarounds.h"
#include "i915_gemfs.h"
#include
#include
@@ -5198,6 +5199,8 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
}
}
+ intel_gt_workarounds_apply(dev_priv);
+
i915_gem_init_swizzling(dev_priv);
/*
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5cfac02..9b3834a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -90,6 +90,7 @@
#include
#include "i915_drv.h"
#include "i915_trace.h"
+#include "intel_workarounds.h"
#define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
@@ -459,11 +460,16 @@ static bool needs_preempt_context(struct drm_i915_private
*i915)
int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
{
struct i915_gem_context *ctx;
+ int ret;
/* Reassure ourselves we are only called once */
GEM_BUG_ON(dev_priv->kernel_context);
GEM_BUG_ON(dev_priv->preempt_context);
+ ret = intel_ctx_workarounds_init(dev_priv);
+ if (ret)
+ return ret;
+
INIT_LIST_HEAD(&dev_priv->contexts.list);
INIT_WORK(&dev_priv->contexts.free_work, contexts_free_worker);
init_llist_head(&dev_priv->contexts.free_list);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c250c8b..568a59b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1725,6 +1725,10 @@ static int gen8_init_render_ring(struct intel_engine_cs
*engine)
if (ret)
return ret;
+ ret = intel_whitelist_workarounds_apply(engine);
+ if (ret)
+ return ret;
+
/* We need to disable the AsyncFlip performance optimisations in order
* to use MI_WAIT_FOR_EVENT within the CS. It should already be
* programmed to '1' on all products.
@@ -1735,7 +1739,7 @@ static int gen8_init_render_ring(struct intel_engine_cs
*engine)
I915_WRITE(INSTPM, _MASKED_BIT_ENABLE(INSTPM_FORCE_ORDERING));
- return init_workarounds_ring(engine);
+ return 0;
}
static int gen9_init_render_ring(struct intel_engine_cs *engine)
@@ -1746,7 +1750,11 @@ static int gen9_init_render_ring(struct intel_engine_cs
*engine)
if (ret)
return ret;
- return init_workarounds_ring(engine);
+ ret = intel_whitelist_workarounds_apply(engine);
+ if (ret)
+ return ret;
+
+ return 0;
}
static void reset_common_ring(struct intel_engine_cs *engine,
@@ -2071,7 +2079,7 @@ static int gen8_init_rcs_context(struct i915_request *rq)
{
int ret;
- ret = intel_ring_workarounds_emit(rq);
+ ret = intel_ctx_workarounds_emit(rq);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 36acc32..757bb09 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -600,7 +600,7 @@ static int intel_rcs_ctx_init(struct i915_request *rq)
{
int ret;
- ret = intel_ring_workarounds_emit(rq);
+ ret = intel_ctx_workarounds_emit(rq);
if (ret != 0)
return ret;
@@ -618,6 +618,10 @@ static int init_render_ring(struct intel_engine_cs *engine)
if (ret)
return ret;
+ ret = intel_whitelist_workarounds_apply(engine);
+ if (ret)
+ return ret;
+
Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Don't fiddle with rps/rc6 across GPU reset
Quoting Patchwork (2018-04-10 16:46:06) > == Series Details == > > Series: drm/i915: Don't fiddle with rps/rc6 across GPU reset > URL : https://patchwork.freedesktop.org/series/41474/ > State : warning > > == Summary == > > = CI Bug Log - changes from CI_DRM_4040_full -> Patchwork_8657_full = > > == Summary - WARNING == > > Minor unknown changes coming with Patchwork_8657_full need to be verified > manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_8657_full, please notify your bug team to allow them > to document this new failure mode, which will reduce the CI noise. > > External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8657/ > > == Possible new issues == > > Here are the unknown changes that may have been introduced in > Patchwork_8657_full: > > === IGT changes === > > Warnings > > igt@perf_pmu@rc6: > shard-kbl: SKIP -> PASS > > > == Known issues == > > Here are the changes found in Patchwork_8657_full that come from known > issues: > > === IGT changes === > > Possible fixes > > igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: > shard-hsw: FAIL (fdo#104873) -> PASS > > igt@kms_flip@flip-vs-expired-vblank-interruptible: > shard-hsw: FAIL (fdo#105189) -> PASS > > > fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 > fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 > > > == Participating hosts (6 -> 4) == > > Missing(2): shard-glk shard-glkb Even without glk, looks like rps across reset was not affected. \o/ -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move a bunch of workaround-related code to its own file
Quoting Oscar Mateo (2018-04-10 17:12:46) > This has grown to be a sizable amount of code, so move it to > its own file before we try to refactor anything. For the moment, > we are leaving behind the WA BB code and the WAs that get applied > (incorrectly) in init_clock_gating, but we will deal with it later. > > v2: Use intel_ prefix for code that deals with the hardware (Chris) > v3: Rebased > v4: > - Rebased > - New license header > v5: > - Rebased > - Added some organisational notes to the file (Chris) > v6: Include DOC section in the documentation build (Jani) > > Signed-off-by: Oscar Mateo > Cc: Mika Kuoppala > Cc: Jani Nikula > Reviewed-by: Chris Wilson I presume this impacts your work. Would you rather have this patch in place or land your w/a series first? (Assuming all goes well!) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move a bunch of workaround-related code to its own file
On 4/10/2018 9:16 AM, Chris Wilson wrote: Quoting Oscar Mateo (2018-04-10 17:12:46) This has grown to be a sizable amount of code, so move it to its own file before we try to refactor anything. For the moment, we are leaving behind the WA BB code and the WAs that get applied (incorrectly) in init_clock_gating, but we will deal with it later. v2: Use intel_ prefix for code that deals with the hardware (Chris) v3: Rebased v4: - Rebased - New license header v5: - Rebased - Added some organisational notes to the file (Chris) v6: Include DOC section in the documentation build (Jani) Signed-off-by: Oscar Mateo Cc: Mika Kuoppala Cc: Jani Nikula Reviewed-by: Chris Wilson I presume this impacts your work. Would you rather have this patch in place or land your w/a series first? (Assuming all goes well!) -Chris I can do this patch first and I'll rebase the Gen11 WAs series later, no problem (in fact, this refactoring started because it was quite problematic to decide where each Gen11 WA should go). Thanks for asking! Oscar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable LVDS on Radiant P845
Hello,
any news about this patch? The bug is rotting here:
https://bugs.freedesktop.org/show_bug.cgi?id=105468
On Monday 12 March 2018 08:25:34 Jani Nikula wrote:
> On Fri, 09 Mar 2018, Ondrej Zary wrote:
> > Radiant P845 does not have LVDS, only VGA.
>
> Hi, thanks for the patch. Would you mind filing a bug at [1], stating
> the issue here, and attaching dmesg from boot with drm.debug=14 set, as
> well as /sys/kernel/debug/dri/0/i915_vbt. I'd just like to have a bit
> more background info to look at before pushing that patch. And then we
> can reference the bug for posterity.
>
> Thanks,
> Jani.
>
>
> [1]
> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
>
> > Signed-off-by: Ondrej Zary
> > ---
> > drivers/gpu/drm/i915/intel_lvds.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> > b/drivers/gpu/drm/i915/intel_lvds.c index ef80499113ee..6939e63d8bae
> > 100644
> > --- a/drivers/gpu/drm/i915/intel_lvds.c
> > +++ b/drivers/gpu/drm/i915/intel_lvds.c
> > @@ -819,6 +819,14 @@ static const struct dmi_system_id intel_no_lvds[] =
> > { DMI_EXACT_MATCH(DMI_BOARD_NAME, "D525MW"),
> > },
> > },
> > + {
> > + .callback = intel_no_lvds_dmi_callback,
> > + .ident = "Radiant P845",
> > + .matches = {
> > + DMI_MATCH(DMI_SYS_VENDOR, "Radiant Systems Inc"),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "P845"),
> > + },
> > + },
> >
> > { } /* terminating entry */
> > };
--
Ondrej Zary
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Move a bunch of workaround-related code to its own file
== Series Details ==
Series: series starting with [1/2] drm/i915: Move a bunch of workaround-related
code to its own file
URL : https://patchwork.freedesktop.org/series/41486/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8044c5a3e8e3 drm/i915: Move a bunch of workaround-related code to its own file
-:742: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#742:
new file mode 100644
-:791: ERROR:TRAILING_WHITESPACE: trailing whitespace
#791: FILE: drivers/gpu/drm/i915/intel_workarounds.c:45:
+ * $
-:816: WARNING:MACRO_WITH_FLOW_CONTROL: Macros with flow control statements
should be avoided
#816: FILE: drivers/gpu/drm/i915/intel_workarounds.c:70:
+#define WA_REG(addr, mask, val) do { \
+ const int r = wa_add(dev_priv, (addr), (mask), (val)); \
+ if (r) \
+ return r; \
+ } while (0)
-:822: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mask' - possible
side-effects?
#822: FILE: drivers/gpu/drm/i915/intel_workarounds.c:76:
+#define WA_SET_BIT_MASKED(addr, mask) \
+ WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
-:825: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mask' - possible
side-effects?
#825: FILE: drivers/gpu/drm/i915/intel_workarounds.c:79:
+#define WA_CLR_BIT_MASKED(addr, mask) \
+ WA_REG(addr, (mask), _MASKED_BIT_DISABLE(mask))
-:828: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mask' - possible
side-effects?
#828: FILE: drivers/gpu/drm/i915/intel_workarounds.c:82:
+#define WA_SET_FIELD_MASKED(addr, mask, value) \
+ WA_REG(addr, mask, _MASKED_FIELD(mask, value))
-:955: WARNING:LONG_LINE: line over 100 characters
#955: FILE: drivers/gpu/drm/i915/intel_workarounds.c:209:
+ I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,
_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));
-:1246: ERROR:SPACING: spaces required around that '=' (ctx:VxW)
#1246: FILE: drivers/gpu/drm/i915/intel_workarounds.c:500:
+ ret= wa_ring_whitelist_reg(engine, GEN8_CS_CHICKEN1);
^
-:1290: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#1290: FILE: drivers/gpu/drm/i915/intel_workarounds.c:544:
+ WA_SET_BIT_MASKED(
-:1350: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#1350: FILE: drivers/gpu/drm/i915/intel_workarounds.c:604:
+ WA_SET_BIT_MASKED(
-:1430: WARNING:MISSING_EOF_NEWLINE: adding a line without newline at end of
file
#1430: FILE: drivers/gpu/drm/i915/intel_workarounds.c:684:
+}
total: 2 errors, 4 warnings, 5 checks, 1381 lines checked
e9f5cebfbf56 drm/i915: Split out functions for different kinds of workarounds
-:409: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#409: FILE: drivers/gpu/drm/i915/intel_workarounds.c:364:
+ WA_SET_BIT_MASKED(
-:456: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#456: FILE: drivers/gpu/drm/i915/intel_workarounds.c:399:
+ WA_SET_BIT_MASKED(
-:512: CHECK:BRACES: braces {} should be used on all arms of this statement
#512: FILE: drivers/gpu/drm/i915/intel_workarounds.c:450:
+ if (INTEL_GEN(dev_priv) < 8)
[...]
+ else if (IS_BROADWELL(dev_priv))
[...]
+ else if (IS_CHERRYVIEW(dev_priv))
[...]
+ else if (IS_SKYLAKE(dev_priv))
[...]
+ else if (IS_BROXTON(dev_priv))
[...]
+ else if (IS_KABYLAKE(dev_priv))
[...]
+ else if (IS_GEMINILAKE(dev_priv))
[...]
+ else if (IS_COFFEELAKE(dev_priv))
[...]
+ else if (IS_CANNONLAKE(dev_priv))
[...]
+ else {
[...]
-:530: CHECK:BRACES: Unbalanced braces around else statement
#530: FILE: drivers/gpu/drm/i915/intel_workarounds.c:468:
+ else {
-:822: WARNING:LINE_SPACING: Missing a blank line after declarations
#822: FILE: drivers/gpu/drm/i915/intel_workarounds.c:744:
+ int ret = gen9_whitelist_workarounds_apply(engine);
+ if (ret)
-:851: WARNING:LINE_SPACING: Missing a blank line after declarations
#851: FILE: drivers/gpu/drm/i915/intel_workarounds.c:767:
+ int ret = gen9_whitelist_workarounds_apply(engine);
+ if (ret)
-:868: WARNING:LINE_SPACING: Missing a blank line after declarations
#868: FILE: drivers/gpu/drm/i915/intel_workarounds.c:781:
+ int ret = gen9_whitelist_workarounds_apply(engine);
+ if (ret)
-:889: WARNING:LINE_SPACING: Missing a blank line after declarations
#889: FILE: drivers/gpu/drm/i915/intel_workarounds.c:795:
+ int ret = gen9_whitelist_workarounds_apply(engine);
+ if (ret)
-:933: CHECK:BRACES: braces {} should be used on all arms of this statement
#933: FILE: drivers/gpu/drm/i915/intel_workarounds.c:822:
+ if (INTEL_GEN(dev_priv) < 8)
[...]
+ else if (IS_BROADWELL(dev_priv))
[...]
else if (IS_CHERRYVIEW(dev_priv))
[...]
+ err = chv_whitelist_workarounds_apply(engine);
[...]
- err = skl_init_workarounds(engine);
[...]
else if (IS_BROXTON(dev_priv))
[...]
+ err = bxt_whitelist_workarounds_apply(engine);
[...]
- err =
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Move a bunch of workaround-related code to its own file
== Series Details == Series: series starting with [1/2] drm/i915: Move a bunch of workaround-related code to its own file URL : https://patchwork.freedesktop.org/series/41486/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Move a bunch of workaround-related code to its own file +drivers/gpu/drm/i915/intel_workarounds.c:684:1: warning: no newline at end of file Commit: drm/i915: Split out functions for different kinds of workarounds -O:drivers/gpu/drm/i915/intel_workarounds.c:684:1: warning: no newline at end of file + ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Move a bunch of workaround-related code to its own file
== Series Details == Series: series starting with [1/2] drm/i915: Move a bunch of workaround-related code to its own file URL : https://patchwork.freedesktop.org/series/41486/ State : success == Summary == Series 41486v1 series starting with [1/2] drm/i915: Move a bunch of workaround-related code to its own file https://patchwork.freedesktop.org/api/1.0/series/41486/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:434s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:440s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:380s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:535s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:296s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:510s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:514s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:522s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:512s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:414s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:560s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:512s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:424s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:313s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:538s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:487s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:408s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:427s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:471s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:429s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:473s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:461s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:511s fi-pnv-d510 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:662s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:443s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:533s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:505s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:492s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:429s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:444s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:580s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:404s df88a0c8d65abb40b39bd5f19b5290dac6746cb9 drm-tip: 2018y-04m-10d-14h-31m-39s UTC integration manifest e9f5cebfbf56 drm/i915: Split out functions for different kinds of workarounds 8044c5a3e8e3 drm/i915: Move a bunch of workaround-related code to its own file == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8659/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Split out functions for different kinds of workarounds
There are different kind of workarounds (those that modify registers that
live in the context image, those that modify global registers, those that
whitelist registers, etc...) and they have different requirements in terms
of where they are applied and how. Also, by splitting them apart, it should
be easier to decide where a new workaround should go.
v2:
- Add multiple MISSING_CASE
- Rebased
v3:
- Rename mmio_workarounds to gt_workarounds (Chris, Mika)
- Create empty placeholders for BDW and CHV GT WAs
- Rebased
v4: Rebased
v5:
- Rebased
- FORCE_TO_NONPRIV register exists since BDW, so make a path
for it to achieve universality, even if empty (Chris)
v6:
- Rebased
- A few stylistic changes to please checkpatch and sparse
Signed-off-by: Oscar Mateo
Cc: Mika Kuoppala
Cc: Ville Syrjälä
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 3 +
drivers/gpu/drm/i915/i915_gem_context.c | 6 +
drivers/gpu/drm/i915/intel_lrc.c | 14 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 8 +-
drivers/gpu/drm/i915/intel_workarounds.c | 637 ---
drivers/gpu/drm/i915/intel_workarounds.h | 8 +-
6 files changed, 438 insertions(+), 238 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 28ab0be..ab846f8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -35,6 +35,7 @@
#include "intel_drv.h"
#include "intel_frontbuffer.h"
#include "intel_mocs.h"
+#include "intel_workarounds.h"
#include "i915_gemfs.h"
#include
#include
@@ -5198,6 +5199,8 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
}
}
+ intel_gt_workarounds_apply(dev_priv);
+
i915_gem_init_swizzling(dev_priv);
/*
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5cfac02..9b3834a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -90,6 +90,7 @@
#include
#include "i915_drv.h"
#include "i915_trace.h"
+#include "intel_workarounds.h"
#define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
@@ -459,11 +460,16 @@ static bool needs_preempt_context(struct drm_i915_private
*i915)
int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
{
struct i915_gem_context *ctx;
+ int ret;
/* Reassure ourselves we are only called once */
GEM_BUG_ON(dev_priv->kernel_context);
GEM_BUG_ON(dev_priv->preempt_context);
+ ret = intel_ctx_workarounds_init(dev_priv);
+ if (ret)
+ return ret;
+
INIT_LIST_HEAD(&dev_priv->contexts.list);
INIT_WORK(&dev_priv->contexts.free_work, contexts_free_worker);
init_llist_head(&dev_priv->contexts.free_list);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c250c8b..568a59b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1725,6 +1725,10 @@ static int gen8_init_render_ring(struct intel_engine_cs
*engine)
if (ret)
return ret;
+ ret = intel_whitelist_workarounds_apply(engine);
+ if (ret)
+ return ret;
+
/* We need to disable the AsyncFlip performance optimisations in order
* to use MI_WAIT_FOR_EVENT within the CS. It should already be
* programmed to '1' on all products.
@@ -1735,7 +1739,7 @@ static int gen8_init_render_ring(struct intel_engine_cs
*engine)
I915_WRITE(INSTPM, _MASKED_BIT_ENABLE(INSTPM_FORCE_ORDERING));
- return init_workarounds_ring(engine);
+ return 0;
}
static int gen9_init_render_ring(struct intel_engine_cs *engine)
@@ -1746,7 +1750,11 @@ static int gen9_init_render_ring(struct intel_engine_cs
*engine)
if (ret)
return ret;
- return init_workarounds_ring(engine);
+ ret = intel_whitelist_workarounds_apply(engine);
+ if (ret)
+ return ret;
+
+ return 0;
}
static void reset_common_ring(struct intel_engine_cs *engine,
@@ -2071,7 +2079,7 @@ static int gen8_init_rcs_context(struct i915_request *rq)
{
int ret;
- ret = intel_ring_workarounds_emit(rq);
+ ret = intel_ctx_workarounds_emit(rq);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 36acc32..757bb09 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -600,7 +600,7 @@ static int intel_rcs_ctx_init(struct i915_request *rq)
{
int ret;
- ret = intel_ring_workarounds_emit(rq);
+ ret = intel_ctx_workarounds_emit(rq);
if (ret != 0)
return ret;
@@ -618,6 +618,10 @@ static int init_render_ring(struct intel_engine_cs *engine)
if (ret)
return ret;
+ ret = intel_white
[Intel-gfx] [PATCH 1/2] drm/i915: Move a bunch of workaround-related code to its own file
This has grown to be a sizable amount of code, so move it to
its own file before we try to refactor anything. For the moment,
we are leaving behind the WA BB code and the WAs that get applied
(incorrectly) in init_clock_gating, but we will deal with it later.
v2: Use intel_ prefix for code that deals with the hardware (Chris)
v3: Rebased
v4:
- Rebased
- New license header
v5:
- Rebased
- Added some organisational notes to the file (Chris)
v6: Include DOC section in the documentation build (Jani)
v7: A few stylistic changes to please checkpatch and sparse
Signed-off-by: Oscar Mateo
Cc: Mika Kuoppala
Cc: Jani Nikula
Reviewed-by: Chris Wilson
---
Documentation/gpu/i915.rst | 6 +
drivers/gpu/drm/i915/Makefile| 3 +-
drivers/gpu/drm/i915/intel_engine_cs.c | 634
drivers/gpu/drm/i915/intel_lrc.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 -
drivers/gpu/drm/i915/intel_workarounds.c | 683 +++
drivers/gpu/drm/i915/intel_workarounds.h | 13 +
8 files changed, 706 insertions(+), 638 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_workarounds.c
create mode 100644 drivers/gpu/drm/i915/intel_workarounds.h
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 34d22f2..055df45 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -58,6 +58,12 @@ Intel GVT-g Host Support(vGPU device model)
.. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c
:internal:
+Workarounds
+---
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_workarounds.c
+ :doc: Hardware workarounds
+
Display Hardware Handling
=
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0c79c19..9bee52a9 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -43,7 +43,8 @@ i915-y := i915_drv.o \
intel_csr.o \
intel_device_info.o \
intel_pm.o \
- intel_runtime_pm.o
+ intel_runtime_pm.o \
+ intel_workarounds.o
i915-$(CONFIG_COMPAT) += i915_ioc32.o
i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 12486d8..67b4eeb 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -903,640 +903,6 @@ void intel_engine_get_instdone(struct intel_engine_cs
*engine,
}
}
-static int wa_add(struct drm_i915_private *dev_priv,
- i915_reg_t addr,
- const u32 mask, const u32 val)
-{
- const u32 idx = dev_priv->workarounds.count;
-
- if (WARN_ON(idx >= I915_MAX_WA_REGS))
- return -ENOSPC;
-
- dev_priv->workarounds.reg[idx].addr = addr;
- dev_priv->workarounds.reg[idx].value = val;
- dev_priv->workarounds.reg[idx].mask = mask;
-
- dev_priv->workarounds.count++;
-
- return 0;
-}
-
-#define WA_REG(addr, mask, val) do { \
- const int r = wa_add(dev_priv, (addr), (mask), (val)); \
- if (r) \
- return r; \
- } while (0)
-
-#define WA_SET_BIT_MASKED(addr, mask) \
- WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
-
-#define WA_CLR_BIT_MASKED(addr, mask) \
- WA_REG(addr, (mask), _MASKED_BIT_DISABLE(mask))
-
-#define WA_SET_FIELD_MASKED(addr, mask, value) \
- WA_REG(addr, mask, _MASKED_FIELD(mask, value))
-
-static int wa_ring_whitelist_reg(struct intel_engine_cs *engine,
-i915_reg_t reg)
-{
- struct drm_i915_private *dev_priv = engine->i915;
- struct i915_workarounds *wa = &dev_priv->workarounds;
- const uint32_t index = wa->hw_whitelist_count[engine->id];
-
- if (WARN_ON(index >= RING_MAX_NONPRIV_SLOTS))
- return -EINVAL;
-
- I915_WRITE(RING_FORCE_TO_NONPRIV(engine->mmio_base, index),
- i915_mmio_reg_offset(reg));
- wa->hw_whitelist_count[engine->id]++;
-
- return 0;
-}
-
-static int gen8_init_workarounds(struct intel_engine_cs *engine)
-{
- struct drm_i915_private *dev_priv = engine->i915;
-
- WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING);
-
- /* WaDisableAsyncFlipPerfMode:bdw,chv */
- WA_SET_BIT_MASKED(MI_MODE, ASYNC_FLIP_PERF_DISABLE);
-
- /* WaDisablePartialInstShootdown:bdw,chv */
- WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN,
- PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
-
- /* Use Force Non-Coherent whenever executing a 3D context. This is a
-* workaround for for a possible hang in the unlikely event a TLB
-* invalidation occurs during a PSD flush.
-*/
- /* WaForceEnableNonCoherent:bdw,chv */
- /* WaHdcDisableFetchWhenMasked:bdw,chv */
- WA_SET_BIT_MASKED(HDC_CHICKEN0,
- H
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Move a bunch of workaround-related code to its own file
== Series Details ==
Series: series starting with [1/2] drm/i915: Move a bunch of workaround-related
code to its own file
URL : https://patchwork.freedesktop.org/series/41491/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
18b0bd9fdeb1 drm/i915: Move a bunch of workaround-related code to its own file
-:743: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#743:
new file mode 100644
-:817: WARNING:MACRO_WITH_FLOW_CONTROL: Macros with flow control statements
should be avoided
#817: FILE: drivers/gpu/drm/i915/intel_workarounds.c:70:
+#define WA_REG(addr, mask, val) do { \
+ const int r = wa_add(dev_priv, (addr), (mask), (val)); \
+ if (r) \
+ return r; \
+ } while (0)
-:823: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mask' - possible
side-effects?
#823: FILE: drivers/gpu/drm/i915/intel_workarounds.c:76:
+#define WA_SET_BIT_MASKED(addr, mask) \
+ WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
-:826: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mask' - possible
side-effects?
#826: FILE: drivers/gpu/drm/i915/intel_workarounds.c:79:
+#define WA_CLR_BIT_MASKED(addr, mask) \
+ WA_REG(addr, (mask), _MASKED_BIT_DISABLE(mask))
-:829: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mask' - possible
side-effects?
#829: FILE: drivers/gpu/drm/i915/intel_workarounds.c:82:
+#define WA_SET_FIELD_MASKED(addr, mask, value) \
+ WA_REG(addr, mask, _MASKED_FIELD(mask, value))
total: 0 errors, 2 warnings, 3 checks, 1380 lines checked
5e751eea41c4 drm/i915: Split out functions for different kinds of workarounds
-:514: CHECK:BRACES: braces {} should be used on all arms of this statement
#514: FILE: drivers/gpu/drm/i915/intel_workarounds.c:448:
+ if (INTEL_GEN(dev_priv) < 8)
[...]
+ else if (IS_BROADWELL(dev_priv))
[...]
+ else if (IS_CHERRYVIEW(dev_priv))
[...]
+ else if (IS_SKYLAKE(dev_priv))
[...]
+ else if (IS_BROXTON(dev_priv))
[...]
+ else if (IS_KABYLAKE(dev_priv))
[...]
+ else if (IS_GEMINILAKE(dev_priv))
[...]
+ else if (IS_COFFEELAKE(dev_priv))
[...]
+ else if (IS_CANNONLAKE(dev_priv))
[...]
+ else {
[...]
-:532: CHECK:BRACES: Unbalanced braces around else statement
#532: FILE: drivers/gpu/drm/i915/intel_workarounds.c:466:
+ else {
-:939: CHECK:BRACES: braces {} should be used on all arms of this statement
#939: FILE: drivers/gpu/drm/i915/intel_workarounds.c:830:
+ if (INTEL_GEN(dev_priv) < 8)
[...]
+ else if (IS_BROADWELL(dev_priv))
[...]
else if (IS_CHERRYVIEW(dev_priv))
[...]
+ err = chv_whitelist_workarounds_apply(engine);
[...]
- err = skl_init_workarounds(engine);
[...]
else if (IS_BROXTON(dev_priv))
[...]
+ err = bxt_whitelist_workarounds_apply(engine);
[...]
- err = kbl_init_workarounds(engine);
[...]
else if (IS_GEMINILAKE(dev_priv))
[...]
+ err = glk_whitelist_workarounds_apply(engine);
[...]
-:965: CHECK:BRACES: Unbalanced braces around else statement
#965: FILE: drivers/gpu/drm/i915/intel_workarounds.c:848:
+ else {
total: 0 errors, 0 warnings, 4 checks, 938 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Move a bunch of workaround-related code to its own file
== Series Details == Series: series starting with [1/2] drm/i915: Move a bunch of workaround-related code to its own file URL : https://patchwork.freedesktop.org/series/41491/ State : success == Summary == Series 41491v1 series starting with [1/2] drm/i915: Move a bunch of workaround-related code to its own file https://patchwork.freedesktop.org/api/1.0/series/41491/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:431s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:443s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:385s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:543s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:296s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:514s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:511s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:517s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:507s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:411s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:562s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:513s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:428s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:317s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:540s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:488s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:412s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:429s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:469s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:431s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:471s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:465s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:507s fi-pnv-d510 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:669s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:442s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:536s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:503s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:505s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:430s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:565s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:405s df88a0c8d65abb40b39bd5f19b5290dac6746cb9 drm-tip: 2018y-04m-10d-14h-31m-39s UTC integration manifest 5e751eea41c4 drm/i915: Split out functions for different kinds of workarounds 18b0bd9fdeb1 drm/i915: Move a bunch of workaround-related code to its own file == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8660/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v4] drm/i915: Enable edp psr error interrupts on hsw (rev3)
On Tue, Apr 10, 2018 at 12:49:25AM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v4] drm/i915: Enable edp psr error interrupts
> on hsw (rev3)
> URL : https://patchwork.freedesktop.org/series/41095/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
> 0a22dbbae8f8 drm/i915: Enable edp psr error interrupts on hsw
> -:111: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
> #111: FILE: drivers/gpu/drm/i915/i915_reg.h:4032:
> +#define EDP_PSR_ERROR (1<<2)
> ^
>
> -:112: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
> #112: FILE: drivers/gpu/drm/i915/i915_reg.h:4033:
> +#define EDP_PSR_POST_EXIT (1<<1)
> ^
>
> -:113: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
> #113: FILE: drivers/gpu/drm/i915/i915_reg.h:4034:
> +#define EDP_PSR_PRE_ENTRY (1<<0)
> ^
>
> -:122: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
> #122: FILE: drivers/gpu/drm/i915/i915_reg.h:6847:
> +#define DE_EDP_PSR_INT_HSW (1<<19)
> ^
>
> total: 0 errors, 0 warnings, 4 checks, 78 lines checked
> 7fdf2eed9ed4 drm/i915: Enable edp psr error interrupts on bdw+
> -:159: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
> parentheses
> #159: FILE: drivers/gpu/drm/i915/intel_display.h:221:
> +#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
> + for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++) \
> + for_each_if ((__mask) & (1 << (__t)))
This showed up on red on dim when I was going to push here...
DK, could you please address this one here before we can push?
Thanks,
Rodrigo.
>
> -:159: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__t' - possible
> side-effects?
> #159: FILE: drivers/gpu/drm/i915/intel_display.h:221:
> +#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
> + for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++) \
> + for_each_if ((__mask) & (1 << (__t)))
>
> -:160: CHECK:SPACING: No space is necessary after a cast
> #160: FILE: drivers/gpu/drm/i915/intel_display.h:222:
> + for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++) \
>
> -:161: WARNING:SPACING: space prohibited between function name and open
> parenthesis '('
> #161: FILE: drivers/gpu/drm/i915/intel_display.h:223:
> + for_each_if ((__mask) & (1 << (__t)))
>
> total: 1 errors, 1 warnings, 2 checks, 123 lines checked
> 003ec0005027 drm/i915/psr: Control PSR interrupts via debugfs
> d8186b823b62 drm/i915/psr: Timestamps for PSR entry and exit interrupts.
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Chase psr.enabled only under the psr.lock
On Tue, Apr 10, 2018 at 12:00:26PM +0100, Chris Wilson wrote: > Quoting Rodrigo Vivi (2018-04-09 20:14:32) > > On Sat, Apr 07, 2018 at 10:05:25AM +0100, Chris Wilson wrote: > > > Quoting Rodrigo Vivi (2018-04-06 23:18:16) > > > > On Fri, Apr 06, 2018 at 11:12:27AM -0700, Souza, Jose wrote: > > > > > On Thu, 2018-04-05 at 12:49 +0100, Chris Wilson wrote: > > > > > > + struct drm_crtc *crtc = > > > > > > + dp_to_dig_port(intel_dp)->base.base.crtc; > > > > > > > > I'm afraid that the issue is this pointer here. So this will only mask > > > > the issue. > > > > > > > > Should we maybe stash the pipe? :/ > > > > > > It's not that bad. pipe cannot change until after psr_disable is called, > > > right? And psr_disable ensures that this worker is flushed. The current > > > problem is just the coordination of cancelling the worker, where we may > > > set psr.enabled to NULL right before the worker grabs it and > > > dereferences it. > > > > > > So if we lock until we have the pipe, we know that dereference chain is > > > valid, and we know that psr_disable() cannot complete until we complete > > > the wait. So the pipe remains valid until we return (so long as the pipe > > > exists when we start). > > > > hmm... it makes sense and I have no better suggestion actually. > > So, as long it really fixes the regression we introduced: > > > > Acked-by: Rodrigo Vivi > > It does fix the abstract race, but I have no evidence of this being hit > in practice. Pushed, but up to you if you care about this being > backported. > > Note this race is different from the GPF CI reported. Hmm, I think > https://bugs.freedesktop.org/show_bug.cgi?id=105959 is the same one as > hit on the kasan run earlier. Ouch, thanks for the clarification... I was really considering that this was the case... but I should have noticed that there was no bugzilla referenced here... > -Chris > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v4] drm/i915: Enable edp psr error interrupts on hsw (rev3)
On Tue, 2018-04-10 at 10:59 -0700, Rodrigo Vivi wrote:
> On Tue, Apr 10, 2018 at 12:49:25AM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: series starting with [v4] drm/i915: Enable edp psr error interrupts
> > on hsw (rev3)
> > URL : https://patchwork.freedesktop.org/series/41095/
> > State : warning
> >
> > == Summary ==
> >
> > $ dim checkpatch origin/drm-tip
> > 0a22dbbae8f8 drm/i915: Enable edp psr error interrupts on hsw
> > -:111: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
> > #111: FILE: drivers/gpu/drm/i915/i915_reg.h:4032:
> > +#define EDP_PSR_ERROR(1<<2)
> > ^
> >
> > -:112: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
> > #112: FILE: drivers/gpu/drm/i915/i915_reg.h:4033:
> > +#define EDP_PSR_POST_EXIT(1<<1)
> > ^
> >
> > -:113: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
> > #113: FILE: drivers/gpu/drm/i915/i915_reg.h:4034:
> > +#define EDP_PSR_PRE_ENTRY(1<<0)
> > ^
> >
> > -:122: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
> > #122: FILE: drivers/gpu/drm/i915/i915_reg.h:6847:
> > +#define DE_EDP_PSR_INT_HSW (1<<19)
> > ^
> >
> > total: 0 errors, 0 warnings, 4 checks, 78 lines checked
> > 7fdf2eed9ed4 drm/i915: Enable edp psr error interrupts on bdw+
> > -:159: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed
> > in parentheses
> > #159: FILE: drivers/gpu/drm/i915/intel_display.h:221:
> > +#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
> > + for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++) \
> > + for_each_if ((__mask) & (1 << (__t)))
>
> This showed up on red on dim when I was going to push here...
>
> DK, could you please address this one here before we can push?
>
The macros look correct to me, that is how other macros are written too.
check_patch is confused?
> Thanks,
> Rodrigo.
>
> >
> > -:159: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__t' - possible
> > side-effects?
> > #159: FILE: drivers/gpu/drm/i915/intel_display.h:221:
> > +#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
> > + for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++) \
> > + for_each_if ((__mask) & (1 << (__t)))
> >
> > -:160: CHECK:SPACING: No space is necessary after a cast
> > #160: FILE: drivers/gpu/drm/i915/intel_display.h:222:
> > + for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++) \
> >
> > -:161: WARNING:SPACING: space prohibited between function name and open
> > parenthesis '('
> > #161: FILE: drivers/gpu/drm/i915/intel_display.h:223:
> > + for_each_if ((__mask) & (1 << (__t)))
> >
> > total: 1 errors, 1 warnings, 2 checks, 123 lines checked
> > 003ec0005027 drm/i915/psr: Control PSR interrupts via debugfs
> > d8186b823b62 drm/i915/psr: Timestamps for PSR entry and exit interrupts.
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/edp: Only use alternate fixed mode when requested
From: Clint Taylor
In commit dc911f5bd8aa ("drm/i915/edp: Allow alternate fixed mode for eDP
if available."), the patch was always selecting the alternate refresh rate
even though user space was asking for the higher rate. This patch adds a
check for vrefresh rate as well as the rest of the mode geometry.
Fixes: dc911f5bd8aac ("Allow alternate fixed mode for eDP if available.")
Cc: David Weinehall
Cc: Rodrigo Vivi
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/intel_dp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4..c4c0e79 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1681,7 +1681,8 @@ static bool intel_edp_compare_alt_mode(struct
drm_display_mode *m1,
m1->vdisplay == m2->vdisplay &&
m1->vsync_start == m2->vsync_start &&
m1->vsync_end == m2->vsync_end &&
- m1->vtotal == m2->vtotal);
+ m1->vtotal == m2->vtotal &&
+ m1->vrefresh == m2->vrefresh);
return bres;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/edp: Only use alternate fixed mode when requested
== Series Details == Series: drm/i915/edp: Only use alternate fixed mode when requested URL : https://patchwork.freedesktop.org/series/41492/ State : warning == Summary == Series 41492v1 drm/i915/edp: Only use alternate fixed mode when requested https://patchwork.freedesktop.org/api/1.0/series/41492/revisions/1/mbox/ Possible new issues: Test gem_exec_gttfill: Subgroup basic: pass -> SKIP (fi-pnv-d510) Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-bxt-dsi) fdo#103927 Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (fi-ilk-650) fdo#104008 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:431s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:445s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:382s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:548s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-dsi total:243 pass:216 dwarn:0 dfail:0 fail:0 skip:26 fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:515s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:527s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:513s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:413s fi-cfl-s3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:563s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:515s fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:424s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:314s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:542s fi-glk-j4005 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:490s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:403s fi-ilk-650 total:285 pass:224 dwarn:0 dfail:0 fail:1 skip:60 time:423s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:461s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:433s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:471s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:462s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:510s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:632s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:446s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:531s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:510s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:509s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:432s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:448s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:568s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:404s df88a0c8d65abb40b39bd5f19b5290dac6746cb9 drm-tip: 2018y-04m-10d-14h-31m-39s UTC integration manifest 04feae3dcd19 drm/i915/edp: Only use alternate fixed mode when requested == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8661/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/i915: Move a bunch of workaround-related code to its own file
== Series Details == Series: series starting with [1/2] drm/i915: Move a bunch of workaround-related code to its own file URL : https://patchwork.freedesktop.org/series/41486/ State : warning == Summary == = CI Bug Log - changes from CI_DRM_4041_full -> Patchwork_8659_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8659_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8659_full, please notify your bug team to allow them to document this new failure mode, which will reduce the CI noise. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8659/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8659_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-bsd2: shard-kbl: SKIP -> PASS igt@gem_mocs_settings@mocs-rc6-dirty-render: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_8659_full that come from known issues: === IGT changes === Issues hit igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_cursor_legacy@basic-flip-after-cursor-legacy: shard-snb: PASS -> FAIL (fdo#105798) igt@kms_flip@2x-dpms-vs-vblank-race: shard-hsw: PASS -> FAIL (fdo#103060) +1 igt@kms_flip@2x-flip-vs-absolute-wf_vblank: shard-hsw: PASS -> FAIL (fdo#100368) +1 igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: PASS -> FAIL (fdo#102887) igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-pwrite: shard-snb: SKIP -> FAIL (fdo#105798) Possible fixes igt@kms_cursor_legacy@flip-vs-cursor-legacy: shard-hsw: FAIL (fdo#102670) -> PASS igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible: shard-hsw: FAIL (fdo#103928) -> PASS igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-wc: shard-apl: FAIL (fdo#103167) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS shard-hsw: FAIL (fdo#99912) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#105798 https://bugs.freedesktop.org/show_bug.cgi?id=105798 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (6 -> 4) == Missing(2): shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4041 -> Patchwork_8659 CI_DRM_4041: df88a0c8d65abb40b39bd5f19b5290dac6746cb9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4418: 7c474e011548d35df6b80ceed81d3e6ca560c71d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8659: e9f5cebfbf56eec2c3e6411b1370274e5e602099 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4418: 45e115f293fd6acc0c9647cf2d3b76be78819ba5 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8659/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/i915: Move a bunch of workaround-related code to its own file
== Series Details == Series: series starting with [1/2] drm/i915: Move a bunch of workaround-related code to its own file URL : https://patchwork.freedesktop.org/series/41491/ State : warning == Summary == = CI Bug Log - changes from CI_DRM_4041_full -> Patchwork_8660_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8660_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8660_full, please notify your bug team to allow them to document this new failure mode, which will reduce the CI noise. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8660/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8660_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-blt: shard-kbl: PASS -> SKIP igt@gem_mocs_settings@mocs-rc6-bsd2: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_8660_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_crc@cursor-128x128-suspend: shard-kbl: PASS -> DMESG-WARN (fdo#103313) igt@kms_flip@2x-wf_vblank-ts-check: shard-hsw: PASS -> FAIL (fdo#100368) Possible fixes igt@kms_cursor_legacy@flip-vs-cursor-legacy: shard-hsw: FAIL (fdo#102670) -> PASS igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible: shard-hsw: FAIL (fdo#103928) -> PASS igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-wc: shard-apl: FAIL (fdo#103167) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (6 -> 4) == Missing(2): shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4041 -> Patchwork_8660 CI_DRM_4041: df88a0c8d65abb40b39bd5f19b5290dac6746cb9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4418: 7c474e011548d35df6b80ceed81d3e6ca560c71d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8660: 5e751eea41c49f00527ff93005be294d2def7846 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4418: 45e115f293fd6acc0c9647cf2d3b76be78819ba5 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8660/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/edp: Only use alternate fixed mode when requested
Quoting clinton.a.tay...@intel.com (2018-04-10 19:33:36)
> From: Clint Taylor
>
> In commit dc911f5bd8aa ("drm/i915/edp: Allow alternate fixed mode for eDP
> if available."), the patch was always selecting the alternate refresh rate
> even though user space was asking for the higher rate. This patch adds a
> check for vrefresh rate as well as the rest of the mode geometry.
>
> Fixes: dc911f5bd8aac ("Allow alternate fixed mode for eDP if available.")
> Cc: David Weinehall
> Cc: Rodrigo Vivi
> Signed-off-by: Clint Taylor
Please see 20180313092855.32376-1-maarten.lankho...@linux.intel.com in
particular the part where Ville has to fix vrefresh to be meaningful...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/icl: Add Voltage swing table for MG PHY DDI Buffer
Em Ter, 2018-04-10 às 09:51 +0100, Chris Wilson escreveu:
> Quoting Paulo Zanoni (2018-03-23 17:24:16)
> > From: Manasi Navare
> >
> > This table is used for voltage swing programming sequence during
> > DDI
> > Buffer initialization for MG PHY DDI Buffers on Icelake.
>
> Except it is not used at all...
It's going to be used later in the series.
>
> drivers/gpu/drm/i915/intel_ddi.c:601:46: error:
> ‘icl_mg_phy_ddi_translations’ defined but not used [-Werror=unused-
> const-variable=]
I have all of the I915 debugging options enabled, including
CONFIG_DRM_I915_WERROR=y, and I don't get this error. I'm using Fedora
27's gcc. Would it be the case that you have somehow enabled the
unused-const-variable warning through some non-traditional way that's
not upstream?
If that's the case, and if we decide that we want Werror=unused-const-
variable to block patches from being merged, then I think we should put
this error/warning under the i915 debugging .config options and force
CI to also use them and tell us about them.
Because I'm pretty sure if we start enabling random gcc warning/error
flags we'll be able to block a huge number of patches from being
upstreamed. I just don't think this is something we should do.
> static const struct icl_mg_phy_ddi_buf_trans
> icl_mg_phy_ddi_translations[] = {
> ^~~
>
> drivers/gpu/drm/i915/intel_ddi.c:581:49: error:
> ‘icl_combo_phy_ddi_translations_edp_1_05V’ defined but not used [-
> Werror=unused-const-variable=]
> static const struct icl_combo_phy_ddi_buf_trans
> icl_combo_phy_ddi_translations_edp_1_05V[] = {
> ^~~~
>
> drivers/gpu/drm/i915/intel_ddi.c:565:49: error:
> ‘icl_combo_phy_ddi_translations_dp_hdmi_1_05V’ defined but not used
> [-Werror=unused-const-variable=]
> static const struct icl_combo_phy_ddi_buf_trans
> icl_combo_phy_ddi_translations_dp_hdmi_1_05V[] = {
> ^~~~
>
> drivers/gpu/drm/i915/intel_ddi.c:550:49: error:
> ‘icl_combo_phy_ddi_translations_edp_0_95V’ defined but not used [-
> Werror=unused-const-variable=]
> static const struct icl_combo_phy_ddi_buf_trans
> icl_combo_phy_ddi_translations_edp_0_95V[] = {
> ^~~~
>
> drivers/gpu/drm/i915/intel_ddi.c:534:49: error:
> ‘icl_combo_phy_ddi_translations_dp_hdmi_0_95V’ defined but not used
> [-Werror=unused-const-variable=]
> static const struct icl_combo_phy_ddi_buf_trans
> icl_combo_phy_ddi_translations_dp_hdmi_0_95V[] = {
> ^~~~
>
> drivers/gpu/drm/i915/intel_ddi.c:519:49: error:
> ‘icl_combo_phy_ddi_translations_edp_0_85V’ defined but not used [-
> Werror=unused-const-variable=]
> static const struct icl_combo_phy_ddi_buf_trans
> icl_combo_phy_ddi_translations_edp_0_85V[] = {
> ^~~~
>
> drivers/gpu/drm/i915/intel_ddi.c:503:49: error:
> ‘icl_combo_phy_ddi_translations_dp_hdmi_0_85V’ defined but not used
> [-Werror=unused-const-variable=]
> static const struct icl_combo_phy_ddi_buf_trans
> icl_combo_phy_ddi_translations_dp_hdmi_0_85V[] = {
> ^~~~
>
> cc1: all warnings being treated as errors
>
>
> > v2 (from Paulo):
> > * Fix white space issues.
> >
> > Cc: Rodrigo Vivi
> > Cc: Jani Nikula
> > Reviewed-by: Paulo Zanoni
> > Signed-off-by: Manasi Navare
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 20
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 229b9d5250c4..359acbfec4b1 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -592,6 +592,26 @@ static const struct
> > icl_combo_phy_ddi_buf_trans icl_combo_phy_ddi_translations_e
> > { 0x0, 0x00, 0x00 },/* 350 0.0 */
> > };
> >
> > +struct icl_mg_phy_ddi_buf_trans {
> > + u32 cri_txdeemph_override_5_0;
> > + u32 cri_txdeemph_override_11_6;
> > + u32 cri_txdeemph_override_17_12;
> > +};
> > +
> > +static const struct icl_mg_phy_ddi_buf_trans
> > icl_mg_phy_ddi_translations[] = {
> > + /* Voltage swing pre-emphasis */
> > + { 0x0, 0x1B, 0x00 },/* 0 0 */
> > + { 0x0, 0x23, 0x08 },/* 0 1 */
> > + { 0x0, 0x2D, 0x12 },/* 0 2 */
> > + { 0x0, 0x00, 0x00 },/* 0 3 */
> > + { 0x0, 0x23, 0x00 },/* 1 0 */
> > + { 0x0, 0x2B, 0x09 },/* 1 1 */
> > +
[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/edp: Only use alternate fixed mode when requested
== Series Details == Series: drm/i915/edp: Only use alternate fixed mode when requested URL : https://patchwork.freedesktop.org/series/41492/ State : warning == Summary == = CI Bug Log - changes from CI_DRM_4041_full -> Patchwork_8661_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8661_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8661_full, please notify your bug team to allow them to document this new failure mode, which will reduce the CI noise. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8661/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8661_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-bsd2: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_8661_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: shard-hsw: PASS -> FAIL (fdo#104873) igt@kms_flip@2x-blocking-wf_vblank: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-hsw: PASS -> FAIL (fdo#105189) igt@kms_flip@flip-vs-modeset-interruptible: shard-hsw: PASS -> DMESG-WARN (fdo#102614) Possible fixes igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible: shard-hsw: FAIL (fdo#103928) -> PASS igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-wc: shard-apl: FAIL (fdo#103167) -> PASS igt@kms_sysfs_edid_timing: shard-apl: WARN (fdo#100047) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 == Participating hosts (6 -> 4) == Missing(2): shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4041 -> Patchwork_8661 CI_DRM_4041: df88a0c8d65abb40b39bd5f19b5290dac6746cb9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4418: 7c474e011548d35df6b80ceed81d3e6ca560c71d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8661: 04feae3dcd1986ad0d2cac9db0f791af399fbc8c @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4418: 45e115f293fd6acc0c9647cf2d3b76be78819ba5 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8661/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/icl: Add Voltage swing table for MG PHY DDI Buffer
Quoting Paulo Zanoni (2018-04-10 21:39:31) > Em Ter, 2018-04-10 às 09:51 +0100, Chris Wilson escreveu: > > Quoting Paulo Zanoni (2018-03-23 17:24:16) > > > From: Manasi Navare > > > > > > This table is used for voltage swing programming sequence during > > > DDI > > > Buffer initialization for MG PHY DDI Buffers on Icelake. > > > > Except it is not used at all... > > It's going to be used later in the series. > > > > > drivers/gpu/drm/i915/intel_ddi.c:601:46: error: > > ‘icl_mg_phy_ddi_translations’ defined but not used [-Werror=unused- > > const-variable=] > > I have all of the I915 debugging options enabled, including > CONFIG_DRM_I915_WERROR=y, and I don't get this error. I'm using Fedora > 27's gcc. Would it be the case that you have somehow enabled the > unused-const-variable warning through some non-traditional way that's > not upstream? Try make W=1 (which includes kerneldoc checks!). Or clang (don't try clang unless you are a masochist, especially not right now as -Wvla upsets it). > If that's the case, and if we decide that we want Werror=unused-const- > variable to block patches from being merged, then I think we should put > this error/warning under the i915 debugging .config options and force > CI to also use them and tell us about them. I'm trying to get W=1 as part of the pre-merge warning set, at the same level of severity as ignoring checkpatch. > Because I'm pretty sure if we start enabling random gcc warning/error > flags we'll be able to block a huge number of patches from being > upstreamed. I just don't think this is something we should do. We do. Our code is clean at W=1 except for the odd mistake. Let's keep it that way. As new gcc warnings are developed, we will squash petty nuisances and sometimes outright bugs from the code (it has happened before and will happen again). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bios: remove duplicated code
Em Ter, 2018-04-10 às 12:12 +0300, Jani Nikula escreveu:
> Apparently caused by a merge fail at some point. Due to the nature of
> the duplicated block, the second one will have no effect, and there's
> no
> need to backport.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_bios.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index fc14bab9c798..7f95d405d585 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1276,13 +1276,6 @@ static void parse_ddi_port(struct
> drm_i915_private *dev_priv, enum port port,
> is_hdmi = false;
> }
>
> - if (port == PORT_A && is_dvi) {
> - DRM_DEBUG_KMS("VBT claims port A supports DVI%s,
> ignoring\n",
> - is_hdmi ? "/HDMI" : "");
> - is_dvi = false;
> - is_hdmi = false;
> - }
> -
> info->supports_dvi = is_dvi;
> info->supports_hdmi = is_hdmi;
> info->supports_dp = is_dp;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/icl: Add Voltage swing table for MG PHY DDI Buffer
Quoting Chris Wilson (2018-04-10 22:01:33) > Quoting Paulo Zanoni (2018-04-10 21:39:31) > > Em Ter, 2018-04-10 às 09:51 +0100, Chris Wilson escreveu: > > > Quoting Paulo Zanoni (2018-03-23 17:24:16) > > > > From: Manasi Navare > > > > > > > > This table is used for voltage swing programming sequence during > > > > DDI > > > > Buffer initialization for MG PHY DDI Buffers on Icelake. > > > > > > Except it is not used at all... > > > > It's going to be used later in the series. In the context of this patch in merged series, it means that we have added unexecuted, untested code. Please justify that. (Unused data tables have in the past remain unused, leaving the code using old tables; a bug that would have been caught by the compiler.) We know our test coverage is lacking, this makes it worse. Yes, it's icl, yes we won't even have sim coverage for the entire set of freq tables, so what's stopping us from writing unittests to double check the code at least conforms to our expectations and is exercised? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/icl: Add Voltage swing table for MG PHY DDI Buffer
Em Ter, 2018-04-10 às 22:07 +0100, Chris Wilson escreveu: > Quoting Chris Wilson (2018-04-10 22:01:33) > > Quoting Paulo Zanoni (2018-04-10 21:39:31) > > > Em Ter, 2018-04-10 às 09:51 +0100, Chris Wilson escreveu: > > > > Quoting Paulo Zanoni (2018-03-23 17:24:16) > > > > > From: Manasi Navare > > > > > > > > > > This table is used for voltage swing programming sequence > > > > > during > > > > > DDI > > > > > Buffer initialization for MG PHY DDI Buffers on Icelake. > > > > > > > > Except it is not used at all... > > > > > > It's going to be used later in the series. > > In the context of this patch in merged series, it means that we have > added unexecuted, untested code. Please justify that. (Unused data > tables have in the past remain unused, leaving the code using old > tables; a bug that would have been caught by the compiler.) > > We know our test coverage is lacking, this makes it worse. Yes, it's > icl, yes we won't even have sim coverage for the entire set of freq > tables, so what's stopping us from writing unittests to double check > the > code at least conforms to our expectations and is exercised? We have properly tested this code and verified it works. It's just that we didn't upstream the whole series yet since it's too big. Almost 100 ICL patches already made it to the list already, and about 60 were merged, but the specific patch that uses that table is not here yet. I'll take the blame for missing that patch from this series. > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/icl: Add Voltage swing table for MG PHY DDI Buffer
Em Ter, 2018-04-10 às 22:01 +0100, Chris Wilson escreveu: > Quoting Paulo Zanoni (2018-04-10 21:39:31) > > Em Ter, 2018-04-10 às 09:51 +0100, Chris Wilson escreveu: > > > Quoting Paulo Zanoni (2018-03-23 17:24:16) > > > > From: Manasi Navare > > > > > > > > This table is used for voltage swing programming sequence > > > > during > > > > DDI > > > > Buffer initialization for MG PHY DDI Buffers on Icelake. > > > > > > Except it is not used at all... > > > > It's going to be used later in the series. > > > > > > > > drivers/gpu/drm/i915/intel_ddi.c:601:46: error: > > > ‘icl_mg_phy_ddi_translations’ defined but not used [- > > > Werror=unused- > > > const-variable=] > > > > I have all of the I915 debugging options enabled, including > > CONFIG_DRM_I915_WERROR=y, and I don't get this error. I'm using > > Fedora > > 27's gcc. Would it be the case that you have somehow enabled the > > unused-const-variable warning through some non-traditional way > > that's > > not upstream? > > Try make W=1 (which includes kerneldoc checks!). Or clang (don't try > clang unless you are a masochist, especially not right now as -Wvla > upsets it). > > > If that's the case, and if we decide that we want Werror=unused- > > const- > > variable to block patches from being merged, then I think we should > > put > > this error/warning under the i915 debugging .config options and > > force > > CI to also use them and tell us about them. > > I'm trying to get W=1 as part of the pre-merge warning set, at the > same > level of severity as ignoring checkpatch. Good. Perhaps some CONFIG_I915_DEBUG_SOMETHING option could also force W=1 for us so developers get it for free? > > > Because I'm pretty sure if we start enabling random gcc > > warning/error > > flags we'll be able to block a huge number of patches from being > > upstreamed. I just don't think this is something we should do. > > We do. Our code is clean at W=1 except for the odd mistake. Ok, I'm convinced. I'll add W=1 to my compilation script. If you want we can revert this patch and I'll squash it to the patch that actually uses the table. > Let's keep > it that way. As new gcc warnings are developed, we will squash petty > nuisances and sometimes outright bugs from the code (it has happened > before and will happen again). > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Replace %phn with %ph
Quoting Chris Wilson (2018-04-10 12:14:17) > %phn is not a valid specifier, and the trailing 'n' is being eaten by > the format-specifier and defaulting to the ' ' separator. Avoid angering > smatch by using the unknown specifier, and use the default we expect. > > drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be > followed by 'n' > drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be > followed by 'n' > drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be > followed by 'n' > drivers/gpu/drm/i915/intel_guc_ct.c:669 ct_handle_response() warn: '%ph' > cannot be followed by 'n' > drivers/gpu/drm/i915/intel_guc_ct.c:679 ct_handle_response() warn: '%ph' > cannot be followed by 'n' > drivers/gpu/drm/i915/intel_guc_ct.c:693 ct_handle_response() warn: '%ph' > cannot be followed by 'n' > drivers/gpu/drm/i915/intel_guc_ct.c:707 ct_handle_response() warn: '%ph' > cannot be followed by 'n' > drivers/gpu/drm/i915/intel_guc_ct.c:727 ct_process_request() warn: '%ph' > cannot be followed by 'n' > drivers/gpu/drm/i915/intel_guc_ct.c:803 ct_handle_request() warn: '%ph' > cannot be followed by 'n' > > Signed-off-by: Chris Wilson > Cc: Michal Wajdeczko > Cc: Daniele Ceraolo Spurio > Reviewed-by: Michal Wajdeczko And pushed. Thanks for the correction about intent to use %ph and not %phN, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.
Francisco Jerez writes: > This series attempts to solve an energy efficiency problem of the > current active-mode non-HWP governor of the intel_pstate driver used > for the most part on low-power platforms. Under heavy IO load the > current controller tends to increase frequencies to the maximum turbo > P-state, partly due to IO wait boosting, partly due to the roughly > flat frequency response curve of the current controller (see > [6]), which causes it to ramp frequencies up and down repeatedly for > any oscillating workload (think of graphics, audio or disk IO when any > of them becomes a bottleneck), severely increasing energy usage > relative to a (throughput-wise equivalent) controller able to provide > the same average frequency without fluctuation. The core energy > efficiency improvement has been observed to be of the order of 20% via > RAPL, but it's expected to vary substantially between workloads (see > perf-per-watt comparison [2]). > > One might expect that this could come at some cost in terms of system > responsiveness, but the governor implemented in PATCH 6 has a variable > response curve controlled by a heuristic that keeps the controller in > a low-latency state unless the system is under heavy IO load for an > extended period of time. The low-latency behavior is actually > significantly more aggressive than the current governor, allowing it > to achieve better throughput in some scenarios where the load > ping-pongs between the CPU and some IO device (see PATCH 6 for more of > the rationale). The controller offers relatively lower latency than > the upstream one particularly while C0 residency is low (which by > itself contributes to mitigate the increased energy usage while on > C0). However under certain conditions the low-latency heuristic may > increase power consumption (see perf-per-watt comparison [2], the > apparent regressions are correlated with an increase in performance in > the same benchmark due to the use of the low-latency heuristic) -- If > this is a problem a different trade-off between latency and energy > usage shouldn't be difficult to achieve, but it will come at a > performance cost in some cases. I couldn't observe a statistically > significant increase in idle power consumption due to this behavior > (on BXT J3455): > > package-0 RAPL (W):XX ±0.14% x8 -> XX ±0.15% x9 > d=-0.04% ±0.14% p=61.73% > For the case anyone is wondering what's going on, Srinivas pointed me at a larger idle power usage increase off-list, ultimately caused by the low-latency heuristic as discussed in the paragraph above. I have a v2 of PATCH 6 that gives the controller a third response curve roughly intermediate between the low-latency and low-power states of this revision, which avoids the energy usage increase while C0 residency is low (e.g. during idle) expected for v1. The low-latency behavior of this revision is still going to be available based on a heuristic (in particular when a realtime-priority task is scheduled). We're carrying out some additional testing, I'll post the code here eventually. > [Absolute benchmark results are unfortunately omitted from this letter > due to company policies, but the percent change and Student's T > p-value are included above and in the referenced benchmark results] > > The most obvious impact of this series will likely be the overall > improvement in graphics performance on systems with an IGP integrated > into the processor package (though for the moment this is only enabled > on BXT+), because the TDP budget shared among CPU and GPU can > frequently become a limiting factor in low-power devices. On heavily > TDP-bound devices this series improves performance of virtually any > non-trivial graphics rendering by a significant amount (of the order > of the energy efficiency improvement for that workload assuming the > optimization didn't cause it to become non-TDP-bound). > > See [1]-[5] for detailed numbers including various graphics benchmarks > and a sample of the Phoronix daily-system-tracker. Some popular > graphics benchmarks like GfxBench gl_manhattan31 and gl_4 improve > between 5% and 11% on our systems. The exact improvement can vary > substantially between systems (compare the benchmark results from the > two different J3455 systems [1] and [3]) due to a number of factors, > including the ratio between CPU and GPU processing power, the behavior > of the userspace graphics driver, the windowing system and resolution, > the BIOS (which has an influence on the package TDP), the thermal > characteristics of the system, etc. > > Unigine Valley and Heaven improve by a similar factor on some systems > (see the J3455 results [1]), but on others the improvement is lower > because the benchmark fails to fully utilize the GPU, which causes the > heuristic to remain in low-latency state for longer, which leaves a > reduced TDP budget available to the GPU, which prevents performance > from increasing fur
Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: Resize CFB in non-full modeset paths
On Fri, 2018-04-06 at 22:03 +0100, Chris Wilson wrote: > Quoting José Roberto de Souza (2018-04-06 21:53:49) > > A simple page flip can cause the CFB required size to increase and > > if it is bigger than the currently allocated CFB it needs to be > > resized to activate FBC again. > > I would have expected the answer to be to plug into atomic. During > the > prepare phase, you evaluate the planes for compatibility with FBC, > and > record what actions you plan to take in the commit (including > allocating > the next slab of stolen if required). Everything now goes through the > same atomic prepare/commit, so it should be possible to eliminate all > guess work. > > Hopefully Maarten can either explain it better or why it shouldn't be > done that at all. ;) > -Chris Hi Chris You mean check if FBC needs to resize CFB inside intel_crtc_compute_config() if so set state->mode_changed=true, to cause a full modeset? This way intel_fbc_disable() and intel_fbc_enable() will be called. Yeah looks better than current solution, do you have any objections Paulo? Thanks ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component intialization before audio driver use it
On Tue, Apr 10, 2018 at 10:58:28AM -0300, Jani Nikula wrote: > On Tue, 10 Apr 2018, Jani Nikula wrote: > > On Tue, 10 Apr 2018, "Shi, Yang A" wrote: > >>>On Tue, 10 Apr 2018, "Shi, Yang A" wrote: > issue: snd_soc_skl meet "failed to add i915 component master (-19)" > when platform don't connect any display output. > > i915 do initialization before than skl_probe, but if there is no > display output connect, in function drm_dp_dpcd_access, there is a 32 > retry for aux i2c transactions. It will meet timeout and do usleep. You should not really rely on "module is loaded, I can use it". It may not be bound to the device yet in case of async probe for example. You should rather wait for the service you want to use from the driver to be ready. See documentation of __request_module(). > Then skl_probe function will be scheduled. It will call > snd_hdac_i915_init, and it will meet "failed to add i915 component > master" error. And whole snd_soc_skl initialization will be failed, > audio can't work normally anymore. Humn... I fail to see how the usleep() would cause any of this. If the probe is synchronous (see below) we an eventual call to request_module() will/should wait for the first probe to finish nonetheless. To me it seems the error is elsewhere. > > So i915 driver need to move intel_audio_init at the beginning of > intel_modeset_init. This will make sure i915_audio_component_init > process before snd_hdac_i915_init call it. > >>> > >>>We do intel_audio_init() and register the audio component when we are > >>>ready to handle the audio component calls. We are ready at > >>>i915_driver_register(). We are not ready at intel_modeset_init(). > >>> > >>>BR, > >>>Jani. > >> > >> Thanks to comments my patch. > >> After I check the whole driver code, I think all ops in > >> i915_audio_component_ops should be ready at the beginning of function > >> intel_modeset_init. So can we move intel_audio_init as early as we > >> can. > > > > No, that's not true. Just as an example, dev_priv->cdclk.hw.cdclk hasn't > > been initialized. > > > >> Would you like to suggest a better place to do intel_audio_init? > > > > I think the call is already where it is supposed to be. We expose > > ourselves to the rest of the system when we are ready. If it takes long, > > it takes long. I think you have a race in your driver, and you need to > > deal with it properly in your driver. > > > > In snd_hdac_i915_init(), I don't think there are any guarantees that the > > request_module() call is the one actually probing i915. We might already This should not be relevant in this case. Even if the module is already mid-probe, request_module() will only return after modprobe returns (since request_module forces UMH_WAIT_PROC). If a second call races with the first, it will try to find the module in the module list and end up waiting for it to complete. See add_unformed_module(). > > be mid-probe. You don't even check or log request_module() return value. Checking the return value of request_module() is absolutely the first thing to do. It's plain broken otherwise... there are many reasons why a call to request_module() could fail. If your driver is being loaded from a work queue, if the modprobe binary is not where it should be, if there's a bug in modprobe, etc etc etc. > > > > I'm also not 100% sure at what point of driver loading request_module() > > returns. I think it's when the module init hook returns, which should be > > all right, but again, I don't think you can count on that if it isn't > > your request_module() that actually probes i915. You can, except if the pci probe is async... In this case modprobe would return before the rest of the initialization. I'm not totally sure about this without giving it a deeper look. But then, moving the call anywhere in that function should produce the same results with enough tries. > > > > I think the patch at hand is a hack that reduces the window for the > > race, and not a real fix. Moreover, it makes the i915 audio component > > code fragile by introducing tricky probe order dependencies that we've > > been systematically trying to reduce by placing the call where it is > > now. > > > > Cc: Lucas for any further input on module probing. > > Apparently there was also a bug in some version of kmod/modprobe which > could have lead to what you're experiencing. Are you running the fixed > version? See [1]. Yep, this might explain as well. But only if i915 is builtin rather than a module. Is this the case here? Lucas De Marchi > > BR, > Jani. > > > [1] > https://github.com/lucasdemarchi/kmod/commit/fd44a98ae2eb5eb32161088954ab21e58e19dfc4 > > > -- > Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component intialization before audio driver use it
>-Original Message- >From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >Sent: Tuesday, April 10, 2018 6:57 PM >To: Shi, Yang A ; Chris Wilson >; >intel-gfx@lists.freedesktop.org >Cc: He, Bo ; De Marchi, Lucas >Subject: RE: [Intel-gfx] [PATCH 1/1] drm/i915: move audio component >intialization >before audio driver use it > >On Tue, 10 Apr 2018, "Shi, Yang A" wrote: >>>On Tue, 10 Apr 2018, "Shi, Yang A" wrote: issue: snd_soc_skl meet "failed to add i915 component master (-19)" when platform don't connect any display output. i915 do initialization before than skl_probe, but if there is no display output connect, in function drm_dp_dpcd_access, there is a 32 retry for aux i2c transactions. It will meet timeout and do usleep. Then skl_probe function will be scheduled. It will call snd_hdac_i915_init, and it will meet "failed to add i915 component master" error. And whole snd_soc_skl initialization will be failed, audio can't work normally anymore. So i915 driver need to move intel_audio_init at the beginning of intel_modeset_init. This will make sure i915_audio_component_init process before snd_hdac_i915_init call it. >>> >>>We do intel_audio_init() and register the audio component when we are >>>ready to handle the audio component calls. We are ready at >>>i915_driver_register(). We are not ready at intel_modeset_init(). >>> >>>BR, >>>Jani. >> >> Thanks to comments my patch. >> After I check the whole driver code, I think all ops in >> i915_audio_component_ops should be ready at the beginning of function >> intel_modeset_init. So can we move intel_audio_init as early as we >> can. > >No, that's not true. Just as an example, dev_priv->cdclk.hw.cdclk hasn't been >initialized. i915_load_modeset_init->intel_power_domains_init_hw->bxt_display_core_init->bxt_init_cdclk dev_priv->cdclk.hw.cdclk will be initialized here. It happened before driver enter into intel_modeset_init. So it should be safe to be used from audio driver. > >> Would you like to suggest a better place to do intel_audio_init? > >I think the call is already where it is supposed to be. We expose ourselves to >the rest of >the system when we are ready. If it takes long, it takes long. I think you >have a race in >your driver, and you need to deal with it properly in your driver. > No, display driver consume too much time to do initialization when it don't connect any display Output device.It influence whole audio driver and cause whole audio driver can't works well. This don't make sense. >In snd_hdac_i915_init(), I don't think there are any guarantees that the >request_module() call is the one actually probing i915. We might already be >mid-probe. >You don't even check or log request_module() return value. This is the issue in audio driver itself. Need be checked by audio driver owner. BR. Yang. Yang Shi, Intel Open Source Technology Center > >I'm also not 100% sure at what point of driver loading request_module() >returns. I think >it's when the module init hook returns, which should be all right, but again, >I don't think >you can count on that if it isn't your request_module() that actually probes >i915. > >I think the patch at hand is a hack that reduces the window for the race, and >not a real >fix. Moreover, it makes the i915 audio component code fragile by introducing >tricky >probe order dependencies that we've been systematically trying to reduce by >placing the >call where it is now. > >Cc: Lucas for any further input on module probing. > >BR, >Jani. > >-- >Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
