RE: i915 IVB hangup after resume from s2mem since v6.6.x

[Saarinen, Jani]

Hi, 
Please file bug at #1. Would be also good to check our existing bug as I can 
see we have IVB on our CI 
https://intel-gfx-ci.01.org/tree/drm-tip/index.html?hosts=ivb .
So results from suspend issues could be at 
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?testfilter=suspend=ivb
 . 

Br,
Jani

#1:  https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html
> -Original Message-
> From: Intel-gfx  On Behalf Of
> Johannes Stezenbach
> Sent: Monday, 29 April 2024 22.34
> To: intel-gfx@lists.freedesktop.org
> Subject: i915 IVB hangup after resume from s2mem since v6.6.x
> 
> Hi,
> 
> I updated the Linux kernel on an old machine from v6.5.9 to current v6.8.8
> and found the display failed after resume from suspend to RAM. Then I tried
> v6.7.9 and v6.6.29, both also failed. v6.5.9 works.
> 
> - display connected via display port: hangup
> 
> - I also tried HDMI with v6.6.29: garbage (color noise) after wakeup,
>   after a bit of switching between Linux virtual consoles
>   the display came back to live, first flickering between
>   color noise and actual output, then stable output
> 
> CPU/GPU: Core i5-3550
> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd
> Gen Core processor Graphics Controller (rev 09)
> 00:02.0 0300: 8086:0152 (rev 09)
> 
> 
> HDMI generates this error in kernel log:
> 
> [C0] i915 :00:02.0: [drm] *ERROR* uncleared pch fifo underrun on pch
> transcoder A
> [C0] i915 :00:02.0: [drm] *ERROR* PCH transcoder A FIFO underrun
> 
> 
> DP genrates this error spew on v6.6.29:
> 
>  [C3] i915 :00:02.0: [drm] *ERROR* uncleared pch fifo underrun on
> pch transcoder A
>  [C3] i915 :00:02.0: [drm] *ERROR* PCH transcoder A FIFO underrun
>  [ T3502] PM: suspend entry (deep)
> ...
>  [ T3927] [ cut here ]  [ T3927] i915 :00:02.0:
> drm_WARN_ON((intel_de_read(dev_priv, intel_dp->output_reg) & (1 << 31))
> == 0)  [ T3927] WARNING: CPU: 2 PID: 3927 at
> drivers/gpu/drm/i915/display/g4x_dp.c:417
> intel_dp_link_down.isra.0+0x2e4/0x300
>  [ T3927] Modules linked in: mt76x0u mt76x0_common mt76x02_usb
> mt76_usb mt76x02_lib mt76 mac80211 kvm_intel cfg80211 kv>  [ T3927]
> CPU: 2 PID: 3927 Comm: kworker/u8:26 Not tainted 6.6.29 #1  [ T3927]
> Hardware name: System manufacturer System Product Name/P8H77-V, BIOS
> 1905 10/27/2014  [ T3927] Workqueue: events_unbound async_run_entry_fn
> [ T3927] RIP: 0010:intel_dp_link_down.isra.0+0x2e4/0x300
>  [ T3927] Code: 48 8b 5f 50 48 85 db 75 03 48 8b 1f e8 c5 0d 07 00 48 c7 c1 70
> 8c ac 89 48 89 da 48 c7 c7 f1 16 9d 89 4>  [ T3927] RSP:
> 0018:a41d41b37a68 EFLAGS: 00010246  [ T3927] RAX: 
> RBX: 9df340d79380 RCX:   [ T3927] RDX:
>  RSI:  RDI:   [
> T3927] RBP: 9df346478000 R08:  R09:
>   [ T3927] R10:  R11:
>  R12: 9df34647ad68  [ T3927] R13: 9df34649e000
> R14: 0001 R15:   [ T3927] FS:
> () GS:9df64f80()
> knlGS:  [ T3927] CS:  0010 DS:  ES:  CR0:
> 80050033  [ T3927] CR2: 7f026e63418c CR3:
> 00032bc50006 CR4: 001706e0  [ T3927] Call Trace:
>  [ T3927]  
>  [ T3927]  ? __warn+0x80/0x160
>  [ T3927]  ? intel_dp_link_down.isra.0+0x2e4/0x300
>  [ T3927]  ? report_bug+0x19e/0x1d0
>  [ T3927]  ? handle_bug+0x40/0x80
>  [ T3927]  ? exc_invalid_op+0x13/0x70
>  [ T3927]  ? asm_exc_invalid_op+0x16/0x20  [ T3927]  ?
> intel_dp_link_down.isra.0+0x2e4/0x300
>  [ T3927]  ? intel_dp_link_down.isra.0+0x2e4/0x300
>  [ T3927]  g4x_post_disable_dp+0x2e/0x120  [ T3927]
> intel_encoders_post_disable+0x72/0x90
>  [ T3927]  ilk_crtc_disable+0x80/0xe0
>  [ T3927]  intel_atomic_commit_tail+0x404/0xed0
>  [ T3927]  ? intel_atomic_commit+0x374/0x3c0  [ T3927]  ?
> intel_atomic_commit+0x30a/0x3c0  [ T3927]
> intel_atomic_commit+0x374/0x3c0  [ T3927]
> drm_atomic_commit+0x96/0xd0  [ T3927]  ?
> __pfx___drm_printfn_info+0x10/0x10
>  [ T3927]  drm_atomic_helper_disable_all+0x19a/0x1b0
>  [ T3927]  drm_atomic_helper_suspend+0xd5/0x240
>  [ T3927]  intel_display_driver_suspend+0x28/0x70
>  [ T3927]  i915_drm_suspend+0x42/0xf0
>  [ T3927]  pci_pm_suspend+0x73/0x170
>  [ T3927]  ? __pfx_pci_pm_suspend+0x10/0x10  [ T3927]
> dpm_run_callback+0x52/0x190  [ T3927]  __device_suspend+0xf3/0x4b0  [
> T3927]  ? process_one_work+0x1ad/0x510  [ T3927]
> async_suspend+0x1a/0x60  [ T3927]  async_run_entry_fn+0x30/0x160  [
> T3927]  ? process_one_work+0x1ad/0x510  [ T3927]
> process_one_work+0x219/0x510  [ T3927]  worker_thread+0x1d6/0x3e0  [
> T3927]  ? __pfx_worker_thread+0x10/0x10  [ T3927]  kthread+0xf6/0x130  [
> T3927]  ? __pfx_kthread+0x10/0x10  [ T3927]  ret_from_fork+0x30/0x50  [
> T3927]  ? __pfx_kthread+0x10/0x10  [ T3927]
> ret_from_fork_asm+0x1b/0x30  [ T3927][ T3927] ---[ end trace
>  ]---  [ T3502] 

RE: [REGRESSION] Divide-by-zero on DisplayPort MST unplug with nouveau

[Saarinen, Jani]

> -Original Message-
> From: Jani Nikula 
> Sent: Monday, 11 March 2024 18.03
> To: Saarinen, Jani ; Linux regressions mailing list
> ; Deak, Imre 
> Cc: Chris Bainbridge ; intel-gfx  g...@lists.freedesktop.org>; David Airlie ; Daniel Vetter
> ; ML dri-devel 
> Subject: RE: [REGRESSION] Divide-by-zero on DisplayPort MST unplug with
> nouveau
> 
> On Mon, 11 Mar 2024, "Saarinen, Jani"  wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Intel-gfx  On Behalf
> >> Of Linux regression tracking (Thorsten Leemhuis)
> >> Sent: Monday, 11 March 2024 17.53
> >> To: Deak, Imre 
> >> Cc: regressi...@lists.linux.dev; Chris Bainbridge
> >> ; intel-gfx
> >> ;
> >> David Airlie ; Daniel Vetter ; ML
> >> dri-devel 
> >> Subject: Re: [REGRESSION] Divide-by-zero on DisplayPort MST unplug
> >> with nouveau
> >>
> >> On 07.03.24 18:58, Chris Bainbridge wrote:
> >> > - Forwarded message from Chris Bainbridge
> >> >  -
> >> >
> >> > Date: Sat, 10 Feb 2024 21:24:59 +
> >>
> >> Hmm, it looks like nobody is looking into this regression. Is there a
> >> good reason?
> >>
> >> Imre, or did you maybe just miss that Chris' regression seems to be
> >> caused by a commit of yours? He initally proposed a fix (the
> >> forwarded mail that is quoted here) more a month ago already here:
> >> https://lore.kernel.org/all/ZcfpqwnkSoiJxeT9@debian.local/
> >>
> >> Chris recently filed a ticket, too:
> >> https://gitlab.freedesktop.org/drm/misc/kernel/-/issues/36
> > Please file
> > https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.htm
> > l
> 
> Well, please don't. It's *not* an i915 bug.
Right, sorry about this. Let Imre to comment then. 

> 
> BR,
> Jani.
> 
> >>
> >> Mostly silence there as well. :-/
> >>
> >> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker'
> >> hat)
> >>
> >> P.S: Chris, sorry, I had missed that you initially proposed the fix a
> >> month ago; if I had noticed this earlier I had sent a mail like this one 
> >> earlier.
> >> --
> >> Everything you wanna know about Linux kernel regression tracking:
> >> https://linux-regtracking.leemhuis.info/about/#tldr
> >> If I did something stupid, please tell me, as explained on that page.
> >>
> >> > From: Chris Bainbridge 
> >> > To: dri-de...@lists.freedesktop.org
> >> > Cc: ly...@redhat.com, ville.syrj...@linux.intel.com,
> >> stanislav.lisovs...@intel.com,
> >> >  mrip...@kernel.org, imre.d...@intel.com
> >> > Subject: [PATCH] Fix divide-by-zero on DP unplug with nouveau
> >> >
> >> > The following trace occurs when using nouveau and unplugging a DP
> >> > MST
> >> > adaptor:
> >> >>  divide error:  [#1] PREEMPT SMP PTI
> >> >  CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744  Hardware
> >> > name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018
> >> >  RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >> >  Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1
> >> > 04
> >> > 48 63 c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48>
> >> > f7
> >> > f7 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31
> >> >  RSP: 0018:b2c5c211fa30 EFLAGS: 00010206
> >> >  RAX:  RBX:  RCX: 00f59b00
> >> >  RDX:  RSI:  RDI:
> >> 
> >> >  RBP: b2c5c211fa48 R08: 0001 R09:
> >> 0020
> >> >  R10: 0004 R11:  R12:
> >> 00023b4a
> >> >  R13: 91d37d165800 R14: 91d36fac6d80 R15: 91d34a764010
> >> >  FS:  7f4a1ca3fa80() GS:91d6edbc()
> >> > knlGS:
> >> >  CS:  0010 DS:  ES:  CR0: 80050033
> >> >  CR2: 559491d49000 CR3: 00011d180002 CR4:
> >> 003706f0
> >> > Call Trace:
> >> >   
> >> >   ? show_regs+0x6d/0x80
> >> >   ? die+0x37/0xa0
> >> >   ? do_trap+0xd4/0xf0
> >> >   ? do_error_trap+0x71/0xb0
> >> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >> >   ? exc_divide_error+0x3a/0x70
> &g

RE: [REGRESSION] Divide-by-zero on DisplayPort MST unplug with nouveau

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Linux
> regression tracking (Thorsten Leemhuis)
> Sent: Monday, 11 March 2024 17.53
> To: Deak, Imre 
> Cc: regressi...@lists.linux.dev; Chris Bainbridge
> ; intel-gfx ;
> David Airlie ; Daniel Vetter ; ML dri-devel
> 
> Subject: Re: [REGRESSION] Divide-by-zero on DisplayPort MST unplug with
> nouveau
> 
> On 07.03.24 18:58, Chris Bainbridge wrote:
> > - Forwarded message from Chris Bainbridge
> >  -
> >
> > Date: Sat, 10 Feb 2024 21:24:59 +
> 
> Hmm, it looks like nobody is looking into this regression. Is there a good
> reason?
> 
> Imre, or did you maybe just miss that Chris' regression seems to be caused by
> a commit of yours? He initally proposed a fix (the forwarded mail that is
> quoted here) more a month ago already here:
> https://lore.kernel.org/all/ZcfpqwnkSoiJxeT9@debian.local/
> 
> Chris recently filed a ticket, too:
> https://gitlab.freedesktop.org/drm/misc/kernel/-/issues/36
Please file 
https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html 
> 
> Mostly silence there as well. :-/
> 
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> 
> P.S: Chris, sorry, I had missed that you initially proposed the fix a month 
> ago; if
> I had noticed this earlier I had sent a mail like this one earlier.
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
> 
> > From: Chris Bainbridge 
> > To: dri-de...@lists.freedesktop.org
> > Cc: ly...@redhat.com, ville.syrj...@linux.intel.com,
> stanislav.lisovs...@intel.com,
> > mrip...@kernel.org, imre.d...@intel.com
> > Subject: [PATCH] Fix divide-by-zero on DP unplug with nouveau
> >
> > The following trace occurs when using nouveau and unplugging a DP MST
> > adaptor:
> >>  divide error:  [#1] PREEMPT SMP PTI
> >  CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744  Hardware
> > name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018
> >  RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >  Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04
> > 48 63 c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7
> > f7 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31
> >  RSP: 0018:b2c5c211fa30 EFLAGS: 00010206
> >  RAX:  RBX:  RCX: 00f59b00
> >  RDX:  RSI:  RDI:
> 
> >  RBP: b2c5c211fa48 R08: 0001 R09:
> 0020
> >  R10: 0004 R11:  R12:
> 00023b4a
> >  R13: 91d37d165800 R14: 91d36fac6d80 R15: 91d34a764010
> >  FS:  7f4a1ca3fa80() GS:91d6edbc()
> > knlGS:
> >  CS:  0010 DS:  ES:  CR0: 80050033
> >  CR2: 559491d49000 CR3: 00011d180002 CR4:
> 003706f0
> > Call Trace:
> >   
> >   ? show_regs+0x6d/0x80
> >   ? die+0x37/0xa0
> >   ? do_trap+0xd4/0xf0
> >   ? do_error_trap+0x71/0xb0
> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >   ? exc_divide_error+0x3a/0x70
> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >   ? asm_exc_divide_error+0x1b/0x20
> >   ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]
> >   ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper]
> >   nv50_msto_atomic_check+0xda/0x120 [nouveau]
> >   drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper]
> >   drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper]
> >   nv50_disp_atomic_check+0x13f/0x2f0 [nouveau]
> >   drm_atomic_check_only+0x668/0xb20 [drm]
> >   ? drm_connector_list_iter_next+0x86/0xc0 [drm]
> >   drm_atomic_commit+0x58/0xd0 [drm]
> >   ? __pfx___drm_printfn_info+0x10/0x10 [drm]
> >   drm_atomic_connector_commit_dpms+0xd7/0x100 [drm]
> >   drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm]
> >   ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
> >   drm_connector_property_set_ioctl+0x3b/0x60 [drm]
> >   drm_ioctl_kernel+0xb9/0x120 [drm]
> >   drm_ioctl+0x2d0/0x550 [drm]
> >   ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]
> >   nouveau_drm_ioctl+0x61/0xc0 [nouveau]
> >   __x64_sys_ioctl+0xa0/0xf0
> >   do_syscall_64+0x76/0x140
> >   ? do_syscall_64+0x85/0x140
> >   ? do_syscall_64+0x85/0x140
> >   entry_SYSCALL_64_after_hwframe+0x6e/0x76
> >  RIP: 0033:0x7f4a1cd1a94f
> >  Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48
> > 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89
> > c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00
> >  RSP: 002b:7ffd2f1df520 EFLAGS: 0246 ORIG_RAX:
> > 0010
> >  RAX: ffda RBX: 7ffd2f1df5b0 RCX: 7f4a1cd1a94f
> >  RDX: 7ffd2f1df5b0 RSI: c01064ab RDI: 000f
> >  RBP: c01064ab R08: 56347932deb8 R09:
> 56347a7d99c0
> >  R10:  R11: 

RE: Linux 6.7 fails to boot on Core Ultra 155H with "i915 GT1 GSC proxy" error

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Saarinen, Jani
> Sent: Tuesday, February 27, 2024 6:58 PM
> To: Jani Nikula ; Roman Lozko
> ; intel-gfx@lists.freedesktop.org
> Subject: RE: Linux 6.7 fails to boot on Core Ultra 155H with "i915 GT1 GSC
> proxy" error
> 
> Hi,
> > -Original Message-
> > From: Intel-gfx  On Behalf Of
> > Jani Nikula
> > Sent: Tuesday, February 27, 2024 6:25 PM
> > To: Roman Lozko ;
> > intel-gfx@lists.freedesktop.org
> > Subject: Re: Linux 6.7 fails to boot on Core Ultra 155H with "i915 GT1 GSC 
> > proxy" error
You seems to have Meteorlake and all MTL systems do work fine. See 
https://intel-gfx-ci.01.org/tree/drm-tip/index.html?hosts=mtlp 

> > On Wed, 14 Feb 2024, Roman Lozko  wrote:
> > > Hi,
> > > I've first filled the bug in openSUSE Tumbleweed bugtracker
> > > (https://bugzilla.opensuse.org/show_bug.cgi?id=1219899) and then found 
> > > Intel GFX CI and that it reliably triggers the same error in Arrow Lake 
> > > BAT runs.
> > >
> > > Don't know what else to say, so yeah, system does not boot. Is it 
> > > expected? I'm trying to install other distributions now to see if there 
> > > is something different in their kernels.

Need to comment though you see from CI that our systems does boot so these are 
not reasons for that. And as you have MTL below patches do not help there. 
Please try latest drm-tip first on this MTL system. This I assume also 
described on instruction how to file bug. 

> > Please file a bug as described at [1].
> Same as https://gitlab.freedesktop.org/drm/intel/-/issues/10194 ?
> Does these help https://patchwork.freedesktop.org/series/130020/ ?
> >
> > BR,
> > Jani.
> >
> > [1]
> > https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.htm
> > l
> >
> > --
> > Jani Nikula, Intel

RE: Linux 6.7 fails to boot on Core Ultra 155H with "i915 GT1 GSC proxy" error

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: Tuesday, February 27, 2024 6:25 PM
> To: Roman Lozko ; intel-gfx@lists.freedesktop.org
> Subject: Re: Linux 6.7 fails to boot on Core Ultra 155H with "i915 GT1 GSC
> proxy" error
> 
> On Wed, 14 Feb 2024, Roman Lozko  wrote:
> > Hi,
> > I've first filled the bug in openSUSE Tumbleweed bugtracker
> > (https://bugzilla.opensuse.org/show_bug.cgi?id=1219899) and then found
> > Intel GFX CI and that it reliably triggers the same error in Arrow
> > Lake BAT runs.
> >
> > Don't know what else to say, so yeah, system does not boot. Is it
> > expected? I'm trying to install other distributions now to see if
> > there is something different in their kernels.
> 
> Please file a bug as described at [1].
Same as https://gitlab.freedesktop.org/drm/intel/-/issues/10194 ? 
Does these help https://patchwork.freedesktop.org/series/130020/ ? 
> 
> BR,
> Jani.
> 
> [1] https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html
> 
> --
> Jani Nikula, Intel

RE: Re: [PATCH v4 00/16] drm/i915: (stolen) memory region related fixes

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-xe  On Behalf Of Lucas De
> Marchi
> Sent: Monday, February 5, 2024 4:17 PM
> To: Jani Nikula 
> Cc: Ville Syrjala ; 
> intel-gfx@lists.freedesktop.org;
> Hellstrom, Thomas ; Oded Gabbay
> ; intel...@lists.freedesktop.org; Paz Zcharya
> 
> Subject: Re: Re: [PATCH v4 00/16] drm/i915: (stolen) memory region related 
> fixes
> 
> On Mon, Feb 05, 2024 at 01:38:45PM +0200, Jani Nikula wrote:
> >On Sat, 03 Feb 2024, Ville Syrjala  wrote:
> >>   drm/i915: Simplify intel_initial_plane_config() calling convention
> >>   drm/i915: Tweak BIOS fb reuse check
> >>   drm/i915: Try to relocate the BIOS fb to the start of ggtt
> >
> >>  drivers/gpu/drm/xe/display/xe_plane_initial.c |  67 +++--
> >
> >Lucas, Thomas, Oded -
> >
> >These three touch xe/display. Ack for merging via drm-intel-next?
> 
> as long as it passed CI,
> 
> Acked-by: Lucas De Marchi 
Seems so from https://patchwork.freedesktop.org/series/129498/ 
> 
> Lucas De Marchi
> 
> >
> >BR,
> >Jani.
> >
> >
> >--
> >Jani Nikula, Intel

RE: ✗ Fi.CI.BAT: failure for drm/i915: Cursor vblank evasion

[Saarinen, Jani]

Hi,

While re-reporting , please pay attention we are not re-reporting something we 
should not. Eg this request was from 
"Sent: Monday, December 18, 2023 4:05 PM"  ...so month old. 

@Ville Syrjälä, Do you see this as on issue now? 

Br,
Jani

> -Original Message-
> From: Illipilli, TejasreeX 
> Sent: Thursday, January 18, 2024 10:05 AM
> To: Saarinen, Jani ; intel-gfx@lists.freedesktop.org;
> Ville Syrjälä ; 
> i915-ci-in...@lists.freedesktop.org
> Subject: RE: ✗ Fi.CI.BAT: failure for drm/i915: Cursor vblank evasion
> 
> Hi,
> 
> https://patchwork.freedesktop.org/series/127744/ - Re-reported.
> 
> Thanks,
> Tejasree
> 
> -Original Message-
> From: I915-ci-infra  On Behalf Of
> Saarinen, Jani
> Sent: Monday, December 18, 2023 4:05 PM
> To: intel-gfx@lists.freedesktop.org; Ville Syrjälä 
> ;
> i915-ci-in...@lists.freedesktop.org
> Subject: RE: ✗ Fi.CI.BAT: failure for drm/i915: Cursor vblank evasion
> 
> Hi,
> > -Original Message-
> > From: Intel-gfx  On Behalf Of
> > Patchwork
> > Sent: Wednesday, December 13, 2023 11:08 PM
> > To: Ville Syrjälä 
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: ✗ Fi.CI.BAT: failure for drm/i915: Cursor vblank evasion
> >
> > Patch Details
> > Series: drm/i915: Cursor vblank evasion
> > URL:https://patchwork.freedesktop.org/series/127744/
> > State:  failure
> > Details:https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_127744v1/index.html
> >
> > CI Bug Log - changes from CI_DRM_14017 -> Patchwork_127744v1
> >
> >
> > Summary
> >
> >
> > FAILURE
> >
> > Serious unknown changes coming with Patchwork_127744v1 absolutely need
> > to be verified manually.
> >
> > If you think the reported changes have nothing to do with the changes
> > introduced in Patchwork_127744v1, please notify your bug team
> > (I915-ci-
> > in...@lists.freedesktop.org) to allow them to document this new
> > failure mode, which will reduce false positives in CI.
> >
> > External URL: https://intel-gfx-ci.01.org/tree/drm-
> > tip/Patchwork_127744v1/index.html
> >
> >
> > Participating hosts (37 -> 37)
> >
> >
> > Additional (1): bat-rpls-2
> > Missing (1): fi-snb-2520m
> >
> >
> > Possible new issues
> >
> >
> > Here are the unknown changes that may have been introduced in
> > Patchwork_127744v1:
> >
> >
> > IGT changes
> >
> >
> > Possible regressions
> >
> >
> > *   igt@kms_pm_rpm@basic-rte:
> >
> > *   bat-rpls-2: NOTRUN -> ABORT <https://intel-gfx-
> > ci.01.org/tree/drm-tip/Patchwork_127744v1/bat-rpls-2/igt@kms_pm_rpm@ba
> > sic-
> > rte.html>
> Unrelated. Please re-report
> >
> >
> > Known issues
> >
> >
> > Here are the changes found in Patchwork_127744v1 that come from known
> issues:
> >
> >
> > CI changes
> >
> >
> > Issues hit
> >
> >
> > *   boot:
> >
> > *   bat-jsl-1: PASS <https://intel-gfx-ci.01.org/tree/drm-
> > tip/CI_DRM_14017/bat-jsl-1/boot.html>  -> FAIL <https://intel-gfx-
> > ci.01.org/tree/drm-tip/Patchwork_127744v1/bat-jsl-1/boot.html>
> > (i915#8293 <https://gitlab.freedesktop.org/drm/intel/issues/8293> )
> >
> >
> > IGT changes
> >
> >
> > Issues hit
> >
> >
> > *   igt@debugfs_test@basic-hwmon:
> >
> > *   bat-rpls-2: NOTRUN -> SKIP <https://intel-gfx-
> ci.01.org/tree/drm-
> > tip/Patchwork_127744v1/bat-rpls-2/igt@debugfs_t...@basic-hwmon.html>
> > (i915#9318 <https://gitlab.freedesktop.org/drm/intel/issues/9318> )
> >
> > *   igt@gem_tiled_pread_basic:
> >
> > *   bat-rpls-2: NOTRUN -> SKIP <https://intel-gfx-
> ci.01.org/tree/drm-
> > tip/Patchwork_127744v1/bat-rpls-2/igt@gem_tiled_pread_basic.html>
> > (i915#3282 <https://gitlab.freedesktop.org/drm/intel/issues/3282> )
> >
> > *   igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
> >
> > *   bat-rpls-2: NOTRUN -> SKIP <https://intel-gfx-
> ci.01.org/tree/drm-
> > tip/Patchwork_127744v1/bat-rpls-2/igt@kms_cursor_legacy@basic-busy-fli
> > p- before-cursor-legacy.html>  (i915#4103
> > <https://gitlab.freedesktop.org/drm/intel/issues/4103> ) +1 other test
> > skip
> >
> > *   igt@kms_dsc@dsc-basic:
> >
> > *   bat-rpls-2: NOTRUN -> SKIP <https://intel-gfx-
> ci

RE: ✗ Fi.CI.BAT: failure for drm/i915: Cursor vblank evasion

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-gfx  On Behalf Of 
> Patchwork
> Sent: Wednesday, December 13, 2023 11:08 PM
> To: Ville Syrjälä 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✗ Fi.CI.BAT: failure for drm/i915: Cursor vblank evasion
> 
> Patch Details
> Series:   drm/i915: Cursor vblank evasion
> URL:  https://patchwork.freedesktop.org/series/127744/
> State:failure
> Details:  
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127744v1/index.html
> 
> CI Bug Log - changes from CI_DRM_14017 -> Patchwork_127744v1
> 
> 
> Summary
> 
> 
> FAILURE
> 
> Serious unknown changes coming with Patchwork_127744v1 absolutely need to be
> verified manually.
> 
> If you think the reported changes have nothing to do with the changes 
> introduced in
> Patchwork_127744v1, please notify your bug team (I915-ci-
> in...@lists.freedesktop.org) to allow them to document this new failure mode,
> which will reduce false positives in CI.
> 
> External URL: https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_127744v1/index.html
> 
> 
> Participating hosts (37 -> 37)
> 
> 
> Additional (1): bat-rpls-2
> Missing (1): fi-snb-2520m
> 
> 
> Possible new issues
> 
> 
> Here are the unknown changes that may have been introduced in
> Patchwork_127744v1:
> 
> 
> IGT changes
> 
> 
> Possible regressions
> 
> 
> * igt@kms_pm_rpm@basic-rte:
> 
>   *   bat-rpls-2: NOTRUN -> ABORT  ci.01.org/tree/drm-tip/Patchwork_127744v1/bat-rpls-2/igt@kms_pm_rpm@basic-
> rte.html>
Unrelated. Please re-report 
> 
> 
> Known issues
> 
> 
> Here are the changes found in Patchwork_127744v1 that come from known issues:
> 
> 
> CI changes
> 
> 
> Issues hit
> 
> 
> * boot:
> 
>   *   bat-jsl-1: PASS  tip/CI_DRM_14017/bat-jsl-1/boot.html>  -> FAIL  ci.01.org/tree/drm-tip/Patchwork_127744v1/bat-jsl-1/boot.html>  (i915#8293
>  )
> 
> 
> IGT changes
> 
> 
> Issues hit
> 
> 
> * igt@debugfs_test@basic-hwmon:
> 
>   *   bat-rpls-2: NOTRUN -> SKIP 
>  tip/Patchwork_127744v1/bat-rpls-2/igt@debugfs_t...@basic-hwmon.html>
> (i915#9318  )
> 
> * igt@gem_tiled_pread_basic:
> 
>   *   bat-rpls-2: NOTRUN -> SKIP 
>  tip/Patchwork_127744v1/bat-rpls-2/igt@gem_tiled_pread_basic.html>  (i915#3282
>  )
> 
> * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
> 
>   *   bat-rpls-2: NOTRUN -> SKIP 
>  tip/Patchwork_127744v1/bat-rpls-2/igt@kms_cursor_legacy@basic-busy-flip-
> before-cursor-legacy.html>  (i915#4103
>  ) +1 other test skip
> 
> * igt@kms_dsc@dsc-basic:
> 
>   *   bat-rpls-2: NOTRUN -> SKIP 
>  tip/Patchwork_127744v1/bat-rpls-2/igt@kms_...@dsc-basic.html>  (i915#3555
>   / i915#3840
>  )
> 
> * igt@kms_force_connector_basic@force-load-detect:
> 
>   *   bat-rpls-2: NOTRUN -> SKIP 
>  tip/Patchwork_127744v1/bat-rpls-2/igt@kms_force_connector_basic@force-load-
> detect.html>  (fdo#109285
>  )
> 
> * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
> 
>   *   bat-rplp-1: PASS  tip/CI_DRM_14017/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-
> seque...@pipe-d-edp-1.html>  -> ABORT  tip/Patchwork_127744v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-
> seque...@pipe-d-edp-1.html>  (i915#8668
>  )
> 
> * igt@kms_pm_backlight@basic-brightness:
> 
>   *   bat-rpls-2: NOTRUN -> SKIP 
>  tip/Patchwork_127744v1/bat-rpls-2/igt@kms_pm_backlight@basic-
> brightness.html>  (i915#5354
>  )
> 
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
> 
> 
> Build changes
> 
> 
> * Linux: CI_DRM_14017 -> Patchwork_127744v1
> 
> CI-20190529: 20190529
> CI_DRM_14017: 58ac4ffc75b62e6007e85ae6777820e77c113b01 @
> git://anongit.freedesktop.org/gfx-ci/linux
> IGT_7639: 18afc09e362b605a3c88c000331708f105d2c23a @
> https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
> Patchwork_127744v1: 58ac4ffc75b62e6007e85ae6777820e77c113b01 @
> git://anongit.freedesktop.org/gfx-ci/linux
> 
> 
> Linux commits
> 
> 
> e1c277f9ae55 Revert "drm/i915/xe2lpd: Treat cursor plane as 

RE: [PATCH 3/3] drm/i915/mtl: Rename the link_bit_rate to clock in C20 pll_state

[Saarinen, Jani]

Hi. 
> -Original Message-
> From: Intel-gfx  On Behalf Of 
> Sripada,
> Radhakrishna
> Sent: Friday, December 8, 2023 9:30 PM
> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> Subject: RE: [PATCH 3/3] drm/i915/mtl: Rename the link_bit_rate to clock in 
> C20
> pll_state
> 
> Thank you for the review. With clean CI pushed the patches upstream.
It seems these patches are causing some issues on certain MTL system and need 
to be re-thought? 
Mika, Imre? 

Should we revert or fix? 

> 
> Regards,
> Radhakrishna Sripada
> 
> > -Original Message-
> > From: Kahola, Mika 
> > Sent: Friday, December 8, 2023 4:01 AM
> > To: Sripada, Radhakrishna ; intel-
> > g...@lists.freedesktop.org
> > Cc: Taylor, Clinton A 
> > Subject: RE: [PATCH 3/3] drm/i915/mtl: Rename the link_bit_rate to
> > clock in C20 pll_state
> >
> > > -Original Message-
> > > From: Sripada, Radhakrishna 
> > > Sent: Friday, December 8, 2023 12:10 AM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Sripada, Radhakrishna ; Taylor,
> > > Clinton A
> > ; Kahola, Mika
> > > 
> > > Subject: [PATCH 3/3] drm/i915/mtl: Rename the link_bit_rate to clock
> > > in C20
> > pll_state
> > >
> > > With the cleanup of the misleading clock value to avoid extra
> > > calculations to
> > convert between link_bit_rate and clock, use one
> > > standard "clock" field for the c20 pll which works with
> > > crtc_state->port_clock
> > field.
> > >
> > > Cc: Clint Taylor 
> > > Cc: Mika Kahola 
> >
> > Reviewed-by: Mika Kahola 
> >
> > > Signed-off-by: Radhakrishna Sripada 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 42 +--
> > >  .../drm/i915/display/intel_display_types.h|  2 +-
> > >  2 files changed, 22 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > index d518b55d5150..4e6ea71ff629 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > @@ -745,7 +745,7 @@ static const struct intel_c10pll_state * const
> > mtl_c10_edp_tables[] = {
> > >
> > >  /* C20 basic DP 1.4 tables */
> > >  static const struct intel_c20pll_state mtl_c20_dp_rbr = {
> > > - .link_bit_rate = 162000,
> > > + .clock = 162000,
> > >   .tx = { 0xbe88, /* tx cfg0 */
> > >   0x5800, /* tx cfg1 */
> > >   0x, /* tx cfg2 */
> > > @@ -770,7 +770,7 @@ static const struct intel_c20pll_state
> > > mtl_c20_dp_rbr =
> > {  };
> > >
> > >  static const struct intel_c20pll_state mtl_c20_dp_hbr1 = {
> > > - .link_bit_rate = 27,
> > > + .clock = 27,
> > >   .tx = { 0xbe88, /* tx cfg0 */
> > >   0x4800, /* tx cfg1 */
> > >   0x, /* tx cfg2 */
> > > @@ -795,7 +795,7 @@ static const struct intel_c20pll_state
> > > mtl_c20_dp_hbr1
> > = {  };
> > >
> > >  static const struct intel_c20pll_state mtl_c20_dp_hbr2 = {
> > > - .link_bit_rate = 54,
> > > + .clock = 54,
> > >   .tx = { 0xbe88, /* tx cfg0 */
> > >   0x4800, /* tx cfg1 */
> > >   0x, /* tx cfg2 */
> > > @@ -820,7 +820,7 @@ static const struct intel_c20pll_state
> > > mtl_c20_dp_hbr2
> > = {  };
> > >
> > >  static const struct intel_c20pll_state mtl_c20_dp_hbr3 = {
> > > - .link_bit_rate = 81,
> > > + .clock = 81,
> > >   .tx = { 0xbe88, /* tx cfg0 */
> > >   0x4800, /* tx cfg1 */
> > >   0x, /* tx cfg2 */
> > > @@ -846,7 +846,7 @@ static const struct intel_c20pll_state
> > > mtl_c20_dp_hbr3
> > = {
> > >
> > >  /* C20 basic DP 2.0 tables */
> > >  static const struct intel_c20pll_state mtl_c20_dp_uhbr10 = {
> > > - .link_bit_rate = 100, /* 10 Gbps */
> > > + .clock = 100, /* 10 Gbps */
> > >   .tx = { 0xbe21, /* tx cfg0 */
> > >   0x4800, /* tx cfg1 */
> > >   0x, /* tx cfg2 */
> > > @@ -870,7 +870,7 @@ static const struct intel_c20pll_state
> > mtl_c20_dp_uhbr10 = {  };
> > >
> > >  static const struct intel_c20pll_state mtl_c20_dp_uhbr13_5 = {
> > > - .link_bit_rate = 135, /* 13.5 Gbps */
> > > + .clock = 135, /* 13.5 Gbps */
> > >   .tx = { 0xbea0, /* tx cfg0 */
> > >   0x4800, /* tx cfg1 */
> > >   0x, /* tx cfg2 */
> > > @@ -895,7 +895,7 @@ static const struct intel_c20pll_state
> > mtl_c20_dp_uhbr13_5 = {  };
> > >
> > >  static const struct intel_c20pll_state mtl_c20_dp_uhbr20 = {
> > > - .link_bit_rate = 200, /* 20 Gbps */
> > > + .clock = 200, /* 20 Gbps */
> > >   .tx = { 0xbe20, /* tx cfg0 */
> > >   0x4800, /* tx cfg1 */
> > >   0x, /* tx cfg2 */
> > > @@ -1514,7 +1514,7 @@ static const struct intel_c10pll_state * const
> > mtl_c10_hdmi_tables[] = {  };
> > >
> > >  static const struct intel_c20pll_state mtl_c20_hdmi_25_175 = {
> > > - .link_bit_rate = 25175,
> > > + .clock = 25175,
> > >   .tx = {  0xbe88, /* tx cfg0 */
> > > 0x9800, /* tx cfg1 */
> > > 0x, /* tx cfg2 */
> > > @@ -1539,7 

RE: ✗ Fi.CI.IGT: failure for ALSA: hda/hdmi: add force-connect quirk for ASUSTeK Z170M Pro

[Saarinen, Jani]

Hi,
> -Original Message-
> From: Intel-gfx  On Behalf Of
> Patchwork
> Sent: Friday, December 8, 2023 9:58 AM
> To: Kai Vehmanen 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✗ Fi.CI.IGT: failure for ALSA: hda/hdmi: add force-connect quirk for
> ASUSTeK Z170M Pro
> 
> Patch Details
> Series:   ALSA: hda/hdmi: add force-connect quirk for ASUSTeK Z170M Pro
> URL:  https://patchwork.freedesktop.org/series/127515/
> State:failure
> Details:  
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127515v1/index.html
> 
> 
> CI Bug Log - changes from CI_DRM_13995_full -> Patchwork_127515v1_full
> 
> 
> Summary
> 
> 
> FAILURE
> 
> Serious unknown changes coming with Patchwork_127515v1_full absolutely need
> to be
> verified manually.
> 
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_127515v1_full, please notify your bug team (I915-ci-
> in...@lists.freedesktop.org) to allow them
> to document this new failure mode, which will reduce false positives in CI.
> 
> 
> Participating hosts (8 -> 7)
> 
> 
> Missing (1): shard-glk-0
> 
> 
> Possible new issues
> 
> 
> Here are the unknown changes that may have been introduced in
> Patchwork_127515v1_full:
> 
> 
> IGT changes
> 
> 
> Possible regressions
> 
> 
> * igt@kms_flip@2x-flip-vs-panning@ab-hdmi-a1-hdmi-a2:
> 
>   *   shard-glk: PASS  tip/CI_DRM_13995/shard-glk9/igt@kms_flip@2x-flip-vs-panning@ab-hdmi-a1-
> hdmi-a2.html>  -> INCOMPLETE  tip/Patchwork_127515v1/shard-glk1/igt@kms_flip@2x-flip-vs-panning@ab-
> hdmi-a1-hdmi-a2.html>
> 
Kai, Ville, could this change cause this? 
 
> Warnings
> 
> 
> * igt@kms_content_protection@mei-interface:
> 
>   *   shard-snb: SKIP  tip/CI_DRM_13995/shard-snb6/igt@kms_content_protection@mei-
> interface.html>  (fdo#109271
>  ) -> INCOMPLETE
>  snb7/igt@kms_content_protect...@mei-interface.html>
> 
> 
> Known issues
> 
> 
> Here are the changes found in Patchwork_127515v1_full that come from known
> issues:
> 
> 
> CI changes
> 
> 
> Possible fixes
> 
> 
> * boot:
> 
>   *   shard-glk: (FAIL  tip/CI_DRM_13995/shard-glk1/boot.html> , PASS  ci.01.org/tree/drm-tip/CI_DRM_13995/shard-glk1/boot.html> , PASS
> 
> , PASS  glk2/boot.html> , PASS  tip/CI_DRM_13995/shard-glk3/boot.html> , PASS  ci.01.org/tree/drm-tip/CI_DRM_13995/shard-glk3/boot.html> , PASS
> 
> , PASS  glk4/boot.html> , PASS  tip/CI_DRM_13995/shard-glk4/boot.html> , PASS  ci.01.org/tree/drm-tip/CI_DRM_13995/shard-glk4/boot.html> , PASS
> 
> , PASS  glk5/boot.html> , PASS  tip/CI_DRM_13995/shard-glk5/boot.html> , PASS  ci.01.org/tree/drm-tip/CI_DRM_13995/shard-glk6/boot.html> , PASS
> 
> , PASS  glk6/boot.html> , PASS  tip/CI_DRM_13995/shard-glk7/boot.html> , PASS  ci.01.org/tree/drm-tip/CI_DRM_13995/shard-glk7/boot.html> , PASS
> 
> , PASS  glk8/boot.html> , PASS  tip/CI_DRM_13995/shard-glk8/boot.html> , PASS  ci.01.org/tree/drm-tip/CI_DRM_13995/shard-glk8/boot.html> , PASS
> 
> , PASS  glk9/boot.html> , PASS  tip/CI_DRM_13995/shard-glk9/boot.html> ) (i915#8293
>  ) -> (PASS 
>  gfx-ci.01.org/tree/drm-tip/Patchwork_127515v1/shard-glk9/boot.html> , PASS
>  glk9/boot.html> , PASS  tip/Patchwork_127515v1/shard-glk9/boot.html> , PASS  ci.01.org/tree/drm-tip/Patchwork_127515v1/shard-glk8/boot.html> , PASS
> 

RE: ✓ Fi.CI.BAT: success for ALSA: hda/hdmi: add force-connect quirk for ASUSTeK Z170M Pro

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of 
> Patchwork
> Sent: Friday, December 8, 2023 2:20 AM
> To: Kai Vehmanen 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✓ Fi.CI.BAT: success for ALSA: hda/hdmi: add force-connect quirk for
> ASUSTeK Z170M Pro
> 
> Patch Details
> Series:   ALSA: hda/hdmi: add force-connect quirk for ASUSTeK Z170M Pro
> URL:  https://patchwork.freedesktop.org/series/127515/
> State:success
> Details:  
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127515v1/index.html
This now passes on that kbl-guc so is this now ok? See below for Possible fixes 
section too
I assume we need this too on topic: core-for-ci after full CI results. 
> 
> CI Bug Log - changes from CI_DRM_13995 -> Patchwork_127515v1
> 
> 
> Summary
> 
> 
> SUCCESS
> 
> No regressions found.
> 
> External URL: https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_127515v1/index.html
> 
> 
> Participating hosts (34 -> 34)
> 
> 
> Additional (2): bat-mtlp-8 bat-dg1-5
> Missing (2): bat-dg2-9 fi-snb-2520m
> 
> 
> New tests
> 
> 
> New tests have been introduced between CI_DRM_13995 and Patchwork_127515v1:
> 
> 
> New IGT tests (12)
> 
> 
> * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-a-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [1.95] s
> 
> * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-c-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.98] s
> 
> * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.93] s
> 
> * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-a-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [2.13] s
> 
> * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.81] s
> 
> * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.99] s
> 
> * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-a-dp-7:
> 
>   *   Statuses : 1 abort(s)
>   *   Exec time: [1.99] s
> 
> * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-c-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.77] s
> 
> * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.86] s
> 
> * igt@kms_pipe_crc_basic@read-crc@pipe-a-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [2.04] s
> 
> * igt@kms_pipe_crc_basic@read-crc@pipe-c-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.86] s
> 
> * igt@kms_pipe_crc_basic@read-crc@pipe-d-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.77] s
> 
> 
> Known issues
> 
> 
> Here are the changes found in Patchwork_127515v1 that come from known issues:
> 
> 
> CI changes
> 
> 
> Possible fixes
> 
> 
> * boot:
> 
>   *   bat-adlp-11: FAIL  tip/CI_DRM_13995/bat-adlp-11/boot.html>  (i915#8293
>  ) -> PASS 
>  ci.01.org/tree/drm-tip/Patchwork_127515v1/bat-adlp-11/boot.html>
> 
> 
> IGT changes
> 
> 
> Issues hit
> 
> 
> * igt@debugfs_test@basic-hwmon:
> 
>   *   bat-mtlp-8: NOTRUN -> SKIP 
>  tip/Patchwork_127515v1/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html>
> (i915#9318  )
> 
>   *   bat-adlp-11: NOTRUN -> SKIP 
>  tip/Patchwork_127515v1/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html>
> (i915#9318  )
> 
> * igt@gem_lmem_swapping@verify-random:
> 
>   *   bat-mtlp-8: NOTRUN -> SKIP 
>  tip/Patchwork_127515v1/bat-mtlp-8/igt@gem_lmem_swapping@verify-
> random.html>  (i915#4613 
>  )
> +3 other tests skip
> 
> * igt@gem_mmap@basic:
> 
>   *   bat-dg1-5: NOTRUN -> SKIP  tip/Patchwork_127515v1/bat-dg1-5/igt@gem_m...@basic.html>  (i915#4083
>  )
> 
>   *   bat-mtlp-8: NOTRUN -> SKIP 
>  tip/Patchwork_127515v1/bat-mtlp-8/igt@gem_m...@basic.html>  (i915#4083
>  )
> 
> * igt@gem_mmap_gtt@basic:
> 
>   *   bat-mtlp-8: NOTRUN -> SKIP 
>  tip/Patchwork_127515v1/bat-mtlp-8/igt@gem_mmap_...@basic.html>  (i915#4077
>  ) +2 other tests skip
> 
> * 

Re: [Intel-gfx] [topic/core-for-CI] Revert "debugfs: annotate debugfs handlers vs. removal with lockdep"

[Saarinen, Jani]

> -Original Message-
> From: De Marchi, Lucas 
> Sent: Wednesday, December 6, 2023 11:33 PM
> To: Saarinen, Jani 
> Cc: Shankar, Uma ; Borah, Chaitanya Kumar
> ; intel-gfx@lists.freedesktop.org; Vivi, 
> Rodrigo
> 
> Subject: Re: [Intel-gfx] [topic/core-for-CI] Revert "debugfs: annotate debugfs
> handlers vs. removal with lockdep"
> 
> On Wed, Dec 06, 2023 at 07:41:04PM +, Jani Saarinen wrote:
> >Hi,
> >> -Original Message-
> >> From: Intel-gfx  On Behalf
> >> Of Shankar, Uma
> >> Sent: Wednesday, December 6, 2023 1:05 PM
> >> To: Borah, Chaitanya Kumar ; intel-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [topic/core-for-CI] Revert "debugfs:
> >> annotate debugfs handlers vs. removal with lockdep"
> >>
> >>
> >>
> >> > -Original Message-
> >> > From: Intel-gfx  On Behalf
> >> > Of Chaitanya Kumar Borah
> >> > Sent: Wednesday, December 6, 2023 12:17 PM
> >> > To: intel-gfx@lists.freedesktop.org
> >> > Subject: [Intel-gfx] [topic/core-for-CI] Revert "debugfs: annotate
> >> > debugfs handlers vs. removal with lockdep"
> >> >
> >> > From: Johannes Berg 
> >> >
> >> > This reverts commit f4acfcd4deb1 ("debugfs: annotate debugfs handlers vs.
> >> > removal with lockdep"), it appears to have false positives and
> >> > really shouldn't have been in the -rc series with the fixes anyway.
> >>
> >> Acked-by: Uma Shankar 
> >>
> >> Hi Chaitanya,
> >> Please get the full CI run executed with this change, once its green we 
> >> can plan
> merge.
> >Just commented on "issues" (no real issues ) on BAT and asked to re-report 
> >but we
> really should use sometimes by-pass shards when we see regression on this
> magnitude.
> >This has big impact on core/gem tests
> >https://intel-gfx-ci.01.org/tree/drm-tip/index.html?testfilter=module%7
> >Cgem%7Ccore Even on module load. I am leaning to break process and not
> >wait to Full CI if someone who has merge rights (eg @Vivi, Rodrigo, @De 
> >Marchi,
> Lucas) agree here?
> 
> I think this is the convincing link:
> https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_127359v2/index.html?testfilter=module%7Cgem%7Ccore
> 
> Applied with ack on irc by Rodrigo.
Thank you! 

> 
> Lucas De Marchi
> 
> >
> >Br,
> >Jani
> >>
> >> Regards,
> >> Uma Shankar
> >>
> >> > Link:https://patchwork.kernel.org/project/linux-
> >> > fsdevel/patch/20231202114936.fd55431ab160.I911aa53abeeca138126f69
> >> > 0d383a89b13eb05667@changeid/
> >> > Reference: https://gitlab.freedesktop.org/drm/intel/-/issues/9802
> >> > Signed-off-by: Johannes Berg 
> >> > Acked-by: Greg Kroah-Hartman 
> >> > ---
> >> >  fs/debugfs/file.c | 10 --
> >> >  fs/debugfs/inode.c|  7 ---
> >> >  fs/debugfs/internal.h |  6 --
> >> >  3 files changed, 23 deletions(-)
> >> >
> >> > diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c index
> >> > a5ade8c16375..5063434be0fc 100644
> >> > --- a/fs/debugfs/file.c
> >> > +++ b/fs/debugfs/file.c
> >> > @@ -108,12 +108,6 @@ int debugfs_file_get(struct dentry *dentry)
> >> >  kfree(fsd);
> >> >  fsd = READ_ONCE(dentry->d_fsdata);
> >> >  }
> >> > -#ifdef CONFIG_LOCKDEP
> >> > -fsd->lock_name = kasprintf(GFP_KERNEL, "debugfs:%pd",
> >> > dentry);
> >> > -lockdep_register_key(>key);
> >> > -lockdep_init_map(>lockdep_map, fsd->lock_name ?:
> >> > "debugfs",
> >> > - >key, 0);
> >> > -#endif
> >> >  INIT_LIST_HEAD(>cancellations);
> >> >  mutex_init(>cancellations_mtx);
> >> >  }
> >> > @@ -132,8 +126,6 @@ int debugfs_file_get(struct dentry *dentry)
> >> >  if (!refcount_inc_not_zero(>active_users))
> >> >  return -EIO;
> >> >
> >> > -lock_map_acquire_read(>lockdep_map);
> >> > -
> >> >  return 0;
> >> >  }
> >> >  EXPORT_SYMBOL_GPL(debugfs_file_get);
> 

Re: [Intel-gfx] [topic/core-for-CI] Revert "debugfs: annotate debugfs handlers vs. removal with lockdep"

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-gfx  On Behalf Of 
> Shankar,
> Uma
> Sent: Wednesday, December 6, 2023 1:05 PM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [topic/core-for-CI] Revert "debugfs: annotate debugfs
> handlers vs. removal with lockdep"
> 
> 
> 
> > -Original Message-
> > From: Intel-gfx  On Behalf Of
> > Chaitanya Kumar Borah
> > Sent: Wednesday, December 6, 2023 12:17 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [topic/core-for-CI] Revert "debugfs: annotate
> > debugfs handlers vs. removal with lockdep"
> >
> > From: Johannes Berg 
> >
> > This reverts commit f4acfcd4deb1 ("debugfs: annotate debugfs handlers vs.
> > removal with lockdep"), it appears to have false positives and really
> > shouldn't have been in the -rc series with the fixes anyway.
> 
> Acked-by: Uma Shankar 
> 
> Hi Chaitanya,
> Please get the full CI run executed with this change, once its green we can 
> plan merge.
Just commented on "issues" (no real issues ) on BAT and asked to re-report but 
we really should use sometimes by-pass shards when we see regression on this 
magnitude. 
This has big impact on core/gem tests 
https://intel-gfx-ci.01.org/tree/drm-tip/index.html?testfilter=module%7Cgem%7Ccore
 
Even on module load. I am leaning to break process and not wait to Full CI if 
someone who has merge rights (eg @Vivi, Rodrigo, @De Marchi, Lucas) agree here? 

Br,
Jani
> 
> Regards,
> Uma Shankar
> 
> > Link:https://patchwork.kernel.org/project/linux-
> > fsdevel/patch/20231202114936.fd55431ab160.I911aa53abeeca138126f69
> > 0d383a89b13eb05667@changeid/
> > Reference: https://gitlab.freedesktop.org/drm/intel/-/issues/9802
> > Signed-off-by: Johannes Berg 
> > Acked-by: Greg Kroah-Hartman 
> > ---
> >  fs/debugfs/file.c | 10 --
> >  fs/debugfs/inode.c|  7 ---
> >  fs/debugfs/internal.h |  6 --
> >  3 files changed, 23 deletions(-)
> >
> > diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c index
> > a5ade8c16375..5063434be0fc 100644
> > --- a/fs/debugfs/file.c
> > +++ b/fs/debugfs/file.c
> > @@ -108,12 +108,6 @@ int debugfs_file_get(struct dentry *dentry)
> > kfree(fsd);
> > fsd = READ_ONCE(dentry->d_fsdata);
> > }
> > -#ifdef CONFIG_LOCKDEP
> > -   fsd->lock_name = kasprintf(GFP_KERNEL, "debugfs:%pd",
> > dentry);
> > -   lockdep_register_key(>key);
> > -   lockdep_init_map(>lockdep_map, fsd->lock_name ?:
> > "debugfs",
> > ->key, 0);
> > -#endif
> > INIT_LIST_HEAD(>cancellations);
> > mutex_init(>cancellations_mtx);
> > }
> > @@ -132,8 +126,6 @@ int debugfs_file_get(struct dentry *dentry)
> > if (!refcount_inc_not_zero(>active_users))
> > return -EIO;
> >
> > -   lock_map_acquire_read(>lockdep_map);
> > -
> > return 0;
> >  }
> >  EXPORT_SYMBOL_GPL(debugfs_file_get);
> > @@ -151,8 +143,6 @@ void debugfs_file_put(struct dentry *dentry)  {
> > struct debugfs_fsdata *fsd = READ_ONCE(dentry->d_fsdata);
> >
> > -   lock_map_release(>lockdep_map);
> > -
> > if (refcount_dec_and_test(>active_users))
> > complete(>active_users_drained);
> >  }
> > diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c index
> > e4e7fe1bd9fb..034a617cb1a5 100644
> > --- a/fs/debugfs/inode.c
> > +++ b/fs/debugfs/inode.c
> > @@ -243,10 +243,6 @@ static void debugfs_release_dentry(struct dentry
> > *dentry)
> >
> > /* check it wasn't a dir (no fsdata) or automount (no real_fops) */
> > if (fsd && fsd->real_fops) {
> > -#ifdef CONFIG_LOCKDEP
> > -   lockdep_unregister_key(>key);
> > -   kfree(fsd->lock_name);
> > -#endif
> > WARN_ON(!list_empty(>cancellations));
> > mutex_destroy(>cancellations_mtx);
> > }
> > @@ -755,9 +751,6 @@ static void __debugfs_file_removed(struct dentry
> > *dentry)
> > if ((unsigned long)fsd & DEBUGFS_FSDATA_IS_REAL_FOPS_BIT)
> > return;
> >
> > -   lock_map_acquire(>lockdep_map);
> > -   lock_map_release(>lockdep_map);
> > -
> > /* if we hit zero, just wait for all to finish */
> > if (!refcount_dec_and_test(>active_users)) {
> > wait_for_completion(>active_users_drained);
> > diff --git a/fs/debugfs/internal.h b/fs/debugfs/internal.h index
> > 0c4c68cf161f..dae80c2a469e 100644
> > --- a/fs/debugfs/internal.h
> > +++ b/fs/debugfs/internal.h
> > @@ -7,7 +7,6 @@
> >
> >  #ifndef _DEBUGFS_INTERNAL_H_
> >  #define _DEBUGFS_INTERNAL_H_
> > -#include 
> >  #include 
> >
> >  struct file_operations;
> > @@ -25,11 +24,6 @@ struct debugfs_fsdata {
> > struct {
> > refcount_t active_users;
> > struct completion active_users_drained; -#ifdef
> CONFIG_LOCKDEP
> > -   struct lockdep_map lockdep_map;
> > -   struct lock_class_key key;
> > -   char *lock_name;
> > 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Revert "debugfs: annotate debugfs handlers vs. removal with lockdep" (rev2)

[Saarinen, Jani]

Hi. 

> -Original Message-
> From: Intel-gfx  On Behalf Of
> Patchwork
> Sent: Wednesday, December 6, 2023 9:58 AM
> To: Borah, Chaitanya Kumar 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✗ Fi.CI.BAT: failure for Revert "debugfs: annotate 
> debugfs
> handlers vs. removal with lockdep" (rev2)
> 
> Patch Details
> Series:   Revert "debugfs: annotate debugfs handlers vs. removal with 
> lockdep"
> (rev2)
> URL:  https://patchwork.freedesktop.org/series/127359/
> State:failure
> Details:  
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127359v2/index.html
> 
> 
> CI Bug Log - changes from CI_DRM_13983 -> Patchwork_127359v2
> 
> 
> Summary
> 
> 
> FAILURE
> 
> Serious unknown changes coming with Patchwork_127359v2 absolutely need to
> be verified manually.
> 
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_127359v2, please notify your bug team (I915-ci-
> in...@lists.freedesktop.org) to allow them to document this new failure mode,
> which will reduce false positives in CI.
> 
> External URL: https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_127359v2/index.html
> 
> 
> Participating hosts (35 -> 36)
> 
> 
> Additional (2): bat-dg2-8 bat-mtlp-8
> Missing (1): fi-snb-2520m
> 
> 
> Possible new issues
> 
> 
> Here are the unknown changes that may have been introduced in
> Patchwork_127359v2:
> 
> 
> IGT changes
> 
> 
> Possible regressions
> 
> 
> * igt@kms_pipe_crc_basic@suspend-read-crc:
> 
>   *   bat-mtlp-6: NOTRUN -> SKIP  ci.01.org/tree/drm-tip/Patchwork_127359v2/bat-mtlp-
> 6/igt@kms_pipe_crc_ba...@suspend-read-crc.html>
> 
> * igt@kms_psr@psr_cursor_plane_move:
Has been always skipping: 
https://intel-gfx-ci.01.org/tree/drm-tip/bat-all.html?testfilter=suspend-read-crc=mtlp-6
 
> 
>   *   bat-mtlp-8: NOTRUN -> SKIP  ci.01.org/tree/drm-tip/Patchwork_127359v2/bat-mtlp-
> 8/igt@kms_psr@psr_cursor_plane_move.html>  +3 other tests skip
Has been always skipping: 
https://intel-gfx-ci.01.org/tree/drm-tip/bat-all.html?testfilter=psr_cursor_plane_move=mtlp-8
 

No issues caused by patch. Bug-filing team, please report

> 
> 
> New tests
> 
> 
> New tests have been introduced between CI_DRM_13983 and
> Patchwork_127359v2:
> 
> 
> New IGT tests (12)
> 
> 
> * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-a-dp-
> 7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.0] s
> 
> * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-c-dp-
> 7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.0] s
> 
> * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-
> 7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.0] s
> 
> * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-a-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.0] s
> 
> * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.0] s
> 
> * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.0] s
> 
> * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-a-dp-7:
> 
>   *   Statuses : 1 abort(s)
>   *   Exec time: [0.0] s
> 
> * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-c-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.0] s
> 
> * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.0] s
> 
> * igt@kms_pipe_crc_basic@read-crc@pipe-a-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.0] s
> 
> * igt@kms_pipe_crc_basic@read-crc@pipe-c-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.0] s
> 
> * igt@kms_pipe_crc_basic@read-crc@pipe-d-dp-7:
> 
>   *   Statuses : 1 pass(s)
>   *   Exec time: [0.0] s
> 
> 
> Known issues
> 
> 
> Here are the changes found in Patchwork_127359v2 that come from known
> issues:
> 
> 
> IGT changes
> 
> 
> Issues hit
> 
> 
> * igt@debugfs_test@basic-hwmon:
> 
>   *   bat-mtlp-8: NOTRUN -> SKIP  ci.01.org/tree/drm-tip/Patchwork_127359v2/bat-mtlp-
> 8/igt@debugfs_t...@basic-hwmon.html>  (i915#9318
>  )
> 
> * igt@gem_lmem_swapping@basic:
> 
>   *   fi-apl-guc: NOTRUN -> SKIP 
>  tip/Patchwork_127359v2/fi-apl-guc/igt@gem_lmem_swapp...@basic.html>
> (fdo#109271   /
> i915#4613  ) +3 other
> tests skip
> 
>   *   bat-jsl-3: NOTRUN -> SKIP  tip/Patchwork_127359v2/bat-jsl-3/igt@gem_lmem_swapp...@basic.html>
> 

Re: [Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: add SKL/KBL connect-all quirks

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Saarinen, Jani
> Sent: Monday, December 4, 2023 4:26 PM
> To: Kai Vehmanen ; intel-
> g...@lists.freedesktop.org; Nikula, Jani 
> Subject: RE: [Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: add SKL/KBL connect-all 
> quirks
> 
> Hi,
> 
> > -Original Message-
> > From: Intel-gfx  On Behalf Of
> > Kai Vehmanen
> > Sent: Monday, December 4, 2023 4:10 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: add SKL/KBL
> > connect-all quirks
> >
> > Hi,
> >
> > I'll send this first to intel-gfx to verify the i915 CI results. If
> > all ok, I'll send this series to ALSA/sound upstream.
> >
> > This seriers is to address kms_hdmi_inject@inject-audio failures reported 
> > in:
> > https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/3
> >
> > Kai Vehmanen (3):
> >   ALSA: hda/hdmi: add connect-all quirk for NUC5CPYB
> >   ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Prime B560M-A
> 
> For the series,
> 
> Acked-By: Jani Saarinen  BSW already proven to work
> with https://patchwork.freedesktop.org/series/127208/
This now provenly fixing all platforms 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127305v1/index.html?testfilter=audio
 
> 
> @Nikula, Jani can we add this to core-for-ci?

Same question applies still to core-for-ci ? 
> 
> >   ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Z170 Pro
> >
> >  sound/pci/hda/patch_hdmi.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > --
> > 2.43.0

Re: [Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: add SKL/KBL connect-all quirks

[Saarinen, Jani]

Hi,

> -Original Message-
> From: Intel-gfx  On Behalf Of Kai
> Vehmanen
> Sent: Monday, December 4, 2023 4:10 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 0/3] ALSA: hda/hdmi: add SKL/KBL connect-all 
> quirks
> 
> Hi,
> 
> I'll send this first to intel-gfx to verify the i915 CI results. If all ok, 
> I'll send this
> series to ALSA/sound upstream.
> 
> This seriers is to address kms_hdmi_inject@inject-audio failures reported in:
> https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/3
> 
> Kai Vehmanen (3):
>   ALSA: hda/hdmi: add connect-all quirk for NUC5CPYB
>   ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Prime B560M-A

For the series, 

Acked-By: Jani Saarinen 
BSW already proven to work with https://patchwork.freedesktop.org/series/127208/

@Nikula, Jani can we add this to core-for-ci? 

>   ALSA: hda/hdmi: add connect-all quirk for ASUSTeK Z170 Pro
> 
>  sound/pci/hda/patch_hdmi.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> --
> 2.43.0

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsi: 4th attempt to get rid of IOSF GPIO (rev2)

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Musial, Ewelina 
> Sent: Wednesday, November 22, 2023 4:25 PM
> To: Saarinen, Jani ; Jani Nikula
> ; Illipilli, TejasreeX 
> ;
> LGCI Bug Filing ; Andy Shevchenko
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsi: 4th attempt 
> to get rid
> of IOSF GPIO (rev2)
> 
> But this list had only series which were in queue here https://intel-gfx-
> ci.01.org/queue/index.html and today I was checking exactly how queue for
> shards is created and there are jobs which are not displayed there. Directly 
> in
> Jenkins we do have multiple more jobs than in this queue only and I also 
> killed
> them. I was discussing exactly this case today with Michał and he pointed out 
> that
> in explanation below queues we do have highlighted:
> Due to technical limitation this is just an approximation of the queue. It is 
> good
> for assessing the length of the queue, but should not be considered as
> completely accurate.
OK. So could have been in the list but not sure. 
> 
> Regards,
> Ewelina
> 
> -Original Message-
> From: Saarinen, Jani 
> Sent: Wednesday, November 22, 2023 3:04 PM
> To: Musial, Ewelina ; Jani Nikula
> ; Illipilli, TejasreeX 
> ;
> LGCI Bug Filing ; Andy Shevchenko
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsi: 4th attempt 
> to get rid
> of IOSF GPIO (rev2)
> 
> HI,
> > -Original Message-
> > From: Intel-gfx  On Behalf Of
> > Musial, Ewelina
> > Sent: Wednesday, November 22, 2023 3:39 PM
> > To: Jani Nikula ; Illipilli, TejasreeX
> > ; LGCI Bug Filing
> > ; Andy Shevchenko
> > 
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsi: 4th
> > attempt to get rid of IOSF GPIO (rev2)
> >
> > Hi, I reviewed what I could, and my conclusion is that CI.FULL for
> > this series was killed due to my work around 126526v6 - yesterday I
> > was asked to do whatever I can to speed up shards testing for
> > mentioned series and I killed multiple sessions which were higher in
> > queue. We do not have option to simply bump priority for premerge
> > series and the only way (not recommended but sometimes needed) is to
> > drop everything what is higher. I've added this series back to queue.
> > Sorry for inconvenience
> Nope. It was not part of that list. We checked that with Jani too. See those
> pictures we discussed.
> >
> > Regards,
> > Ewelina
> 
> Br,
> Jani S

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsi: 4th attempt to get rid of IOSF GPIO (rev2)

[Saarinen, Jani]

HI, 
> -Original Message-
> From: Intel-gfx  On Behalf Of Musial,
> Ewelina
> Sent: Wednesday, November 22, 2023 3:39 PM
> To: Jani Nikula ; Illipilli, TejasreeX
> ; LGCI Bug Filing ; 
> Andy
> Shevchenko 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsi: 4th attempt 
> to get rid
> of IOSF GPIO (rev2)
> 
> Hi, I reviewed what I could, and my conclusion is that CI.FULL for this 
> series was
> killed due to my work around 126526v6 - yesterday I was asked to do whatever I
> can to speed up shards testing for mentioned series and I killed multiple 
> sessions
> which were higher in queue. We do not have option to simply bump priority for
> premerge series and the only way (not recommended but sometimes needed) is
> to drop everything what is higher. I've added this series back to queue. 
> Sorry for
> inconvenience
Nope. It was not part of that list. We checked that with Jani too. See those 
pictures we discussed. 
> 
> Regards,
> Ewelina

Br,
Jani S

Re: [Intel-gfx] [Intel-xe] [PATCH 11/14] ALSA: hda/intel: Move snd_hdac_i915_init to before probe_work.

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Maarten Lankhorst 
> Sent: Tuesday, November 14, 2023 3:30 PM
> To: Jani Nikula ; Ville Syrjälä
> 
> Cc: Takashi Iwai ; intel-gfx@lists.freedesktop.org; intel-
> x...@lists.freedesktop.org; alsa-de...@alsa-project.org; Saarinen, Jani
> ; Kurmi, Suresh Kumar
> 
> Subject: Re: [Intel-xe] [PATCH 11/14] ALSA: hda/intel: Move snd_hdac_i915_init
> to before probe_work.
> 
> Hey,
> 
> Den 2023-11-14 kl. 13:35, skrev Jani Nikula:
> > On Tue, 14 Nov 2023, Ville Syrjälä  wrote:
> >> On Mon, Oct 02, 2023 at 09:38:44PM +0200,
> maarten.lankho...@linux.intel.com wrote:
> >>> From: Maarten Lankhorst 
> >>>
> >>> Now that we can use -EPROBE_DEFER, it's no longer required to spin
> >>> off the snd_hdac_i915_init into a workqueue.
> >>>
> >>> Use the -EPROBE_DEFER mechanism instead, which must be returned in
> >>> the probe function.
> >> This completely broke i915 audio!
> >>
> >> I also can't see any trace of this stuff ever being posted to
> >> intel-gfx so it never went through the CI.
> >>
> >> Please fix or revert ASAP.
> > Cc: Jani, Suresh
> >
> > Ville, please file a bug at gitlab so we can track this, thanks.
> 
> I've originally tested this on TGL and DG2, so can you be more specific on 
> what
> broke?
Was this series tested on CI  ever as Ville saying no? How this got merged? 

> 
> Cheers,
> 
> ~Maarten
> 
> >>> Signed-off-by: Maarten Lankhorst 
> >>> Reviewed-by: Kai Vehmanen 
> >>> Reviewed-by: Pierre-Louis Bossart
> >>> 
> >>> Signed-off-by: Maarten Lankhorst 
> >>> ---
> >>>   sound/pci/hda/hda_intel.c | 54 +++
> >>>   1 file changed, 27 insertions(+), 27 deletions(-)
> >>>
> >>> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> >>> index e42ad0e816e1..9dad3607596a 100644
> >>> --- a/sound/pci/hda/hda_intel.c
> >>> +++ b/sound/pci/hda/hda_intel.c
> >>> @@ -2135,6 +2135,33 @@ static int azx_probe(struct pci_dev *pci,
> >>>
> >>>   pci_set_drvdata(pci, card);
> >>>
> >>> +#ifdef CONFIG_SND_HDA_I915
> >>> + /* bind with i915 if needed */
> >>> + if (chip->driver_caps & AZX_DCAPS_I915_COMPONENT) {
> >>> + err = snd_hdac_i915_init(azx_bus(chip), false);
> >>> + if (err < 0) {
> >>> + /* if the controller is bound only with HDMI/DP
> >>> +  * (for HSW and BDW), we need to abort the probe;
> >>> +  * for other chips, still continue probing as other
> >>> +  * codecs can be on the same link.
> >>> +  */
> >>> + if (HDA_CONTROLLER_IN_GPU(pci)) {
> >>> + goto out_free;
> >>> + } else {
> >>> + /* don't bother any longer */
> >>> + chip->driver_caps &=
> ~AZX_DCAPS_I915_COMPONENT;
> >>> + }
> >>> + }
> >>> +
> >>> + /* HSW/BDW controllers need this power */
> >>> + if (HDA_CONTROLLER_IN_GPU(pci))
> >>> + hda->need_i915_power = true;
> >>> + }
> >>> +#else
> >>> + if (HDA_CONTROLLER_IN_GPU(pci))
> >>> + dev_err(card->dev, "Haswell/Broadwell HDMI/DP must build in
> >>> +CONFIG_SND_HDA_I915\n"); #endif
> >>> +
> >>>   err = register_vga_switcheroo(chip);
> >>>   if (err < 0) {
> >>>   dev_err(card->dev, "Error registering vga_switcheroo 
> >>> client\n");
> >>> @@ -2162,11 +2189,6 @@ static int azx_probe(struct pci_dev *pci,
> >>>   }
> >>>   #endif /* CONFIG_SND_HDA_PATCH_LOADER */
> >>>
> >>> -#ifndef CONFIG_SND_HDA_I915
> >>> - if (HDA_CONTROLLER_IN_GPU(pci))
> >>> - dev_err(card->dev, "Haswell/Broadwell HDMI/DP must build in
> CONFIG_SND_HDA_I915\n");
> >>> -#endif
> >>> -
> >>>   if (schedule_probe)
> >>>   schedule_delayed_work(>probe_work, 0);
> >>>
> >>> @@ -2264,28 +2286,6 @@ static int azx_probe_continue(struct azx *chip)
> >>>

Re: [Intel-gfx] Getting black screen with stable kernel 6.6

[Saarinen, Jani]

Hi,
Please report with these instructions: 
https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html 

> -Original Message-
> From: Intel-gfx  On Behalf Of VDRU
> VDRU
> Sent: Friday, November 10, 2023 4:59 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] Getting black screen with stable kernel 6.6
> 
> Hi,
> I've been using kernel 6.5.10 on Debian Sid without issue. I just tried 
> kernel 6.6,
> (and consequently 6.6.1) but only get a black screen. The system doesn't run a
> desktop environment but runs as a Kodi client using GBM for display output. 
> The
> system is a Beelink Mini
> S12 Pro (12th gen Alder Lake N100 cpu w/integrated gpu Alder Lake-N [UHD
> Graphics] [8086:46D1]) connected to an LG tv.
> 
> I'm not sure if the issue is the i915 driver itself or something else that was
> changed between 6.5.10 and 6.6 and am hoping someone more knowledgeable
> can help/point me in the right direction to finding that out. If it is an 
> i915 driver
> bug, I'd like to get it reported correctly.
> 
> If this isn't the appropriate place for reporting this, please let me know.
> 
> Thanks,
> Derek

Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for file, i915: fix file reference for mmap_singleton()y

[Saarinen, Jani]

Hi, 
CI is always testing against https://cgit.freedesktop.org/drm-tip 

Br
Jani

> -Original Message-
> From: Intel-gfx  On Behalf Of 
> Christian
> Brauner
> Sent: Wednesday, October 25, 2023 11:39 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for file, i915: fix file 
> reference for
> mmap_singleton()y
> 
> On Wed, Oct 25, 2023 at 08:16:23PM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: file, i915: fix file reference for mmap_singleton()
> > URL   : https://patchwork.freedesktop.org/series/125570/
> > State : failure
> >
> > == Summary ==
> >
> > Error: patch
> > https://patchwork.freedesktop.org/api/1.0/series/125570/revisions/1/mb
> > ox/ not applied
> > Applying: file, i915: fix file reference for mmap_singleton() Using
> > index info to reconstruct a base tree...
> > M   drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > M   fs/file.c
> > M   include/linux/fs.h
> > Falling back to patching base and 3-way merge...
> > Auto-merging include/linux/fs.h
> > CONFLICT (content): Merge conflict in include/linux/fs.h Auto-merging
> > fs/file.c CONFLICT (content): Merge conflict in fs/file.c Auto-merging
> > drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > CONFLICT (content): Merge conflict in
> > drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > error: Failed to merge in the changes.
> > hint: Use 'git am --show-current-patch=diff' to see the failed patch
> > Patch failed at 0001 file, i915: fix file reference for
> > mmap_singleton() 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".
> > Build failed, no error log produced
> 
> I'm not sure what tree you're testing on but please test on whatever is in
> vfs.misc, I guess which has that patch.
> git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git

Re: [Intel-gfx] [PATCH v5 8/8] drm/i915/display: provision to suppress drm_warn in intel_get_crtc_new_encoder

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-gfx  On Behalf Of Jani 
> Nikula
> Sent: Tuesday, May 23, 2023 2:49 PM
> To: Lisovskiy, Stanislav ; Govindapillai, Vinod
> 
> Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville 
> Subject: Re: [Intel-gfx] [PATCH v5 8/8] drm/i915/display: provision to 
> suppress
> drm_warn in intel_get_crtc_new_encoder
> 
> On Mon, 22 May 2023, "Lisovskiy, Stanislav" 
> wrote:
> > On Fri, May 12, 2023 at 02:17:50AM +0300, Vinod Govindapillai wrote:
> >> While configuring pmdemand parameters, there could be
> >> intel_get_crtc_new_encoder call where encoders could be 0. To avoid
> >> invoking drm_warn in such cases, use a parameter to indicate drm_warn
> >> should be suppressed.
> >>
> >> v2: checkpatch warning fixes
> >
> > I thought, last time we discussed this, wasn't it so that you
> > mentioned that this patch will be removed?..
> 
> Yeah, the "bool warn" parameter is icky.
This was already removed at v6. So review/check that. 
> 
> BR,
> Jani.
> 
> 
> >
> >>
> >> Signed-off-by: Vinod Govindapillai 
> >> ---
> >>  drivers/gpu/drm/i915/display/intel_cx0_phy.c |  2 +-
> >>  drivers/gpu/drm/i915/display/intel_display.c | 10 ++
> >>  drivers/gpu/drm/i915/display/intel_display.h |  3 ++-
> >>  drivers/gpu/drm/i915/display/intel_dpll.c|  8 
> >>  drivers/gpu/drm/i915/display/intel_pch_display.c |  2 +-
> >>  drivers/gpu/drm/i915/display/intel_pmdemand.c|  2 +-
> >>  drivers/gpu/drm/i915/display/intel_snps_phy.c|  2 +-
> >>  7 files changed, 16 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >> index d94127e7448b..1a41a314f8d8 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >> @@ -2934,7 +2934,7 @@ void intel_c10pll_state_verify(struct
> intel_atomic_state *state,
> >>!intel_crtc_needs_fastset(new_crtc_state))
> >>return;
> >>
> >> -  encoder = intel_get_crtc_new_encoder(state, new_crtc_state);
> >> +  encoder = intel_get_crtc_new_encoder(state, new_crtc_state, true);
> >>phy = intel_port_to_phy(i915, encoder->port);
> >>
> >>if (!intel_is_c10phy(i915, phy))
> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> >> b/drivers/gpu/drm/i915/display/intel_display.c
> >> index dd390a0586ef..fb2b7769 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >> @@ -763,7 +763,8 @@ bool intel_has_pending_fb_unpin(struct
> drm_i915_private *dev_priv)
> >>   */
> >>  struct intel_encoder *
> >>  intel_get_crtc_new_encoder(const struct intel_atomic_state *state,
> >> - const struct intel_crtc_state *crtc_state)
> >> + const struct intel_crtc_state *crtc_state,
> >> + bool warn)
> >>  {
> >>const struct drm_connector_state *connector_state;
> >>const struct drm_connector *connector; @@ -782,9 +783,10 @@
> >> intel_get_crtc_new_encoder(const struct intel_atomic_state *state,
> >>num_encoders++;
> >>}
> >>
> >> -  drm_WARN(state->base.dev, num_encoders != 1,
> >> -   "%d encoders for pipe %c\n",
> >> -   num_encoders, pipe_name(master_crtc->pipe));
> >> +  if (warn)
> >> +  drm_WARN(state->base.dev, num_encoders != 1,
> >> +   "%d encoders for pipe %c\n",
> >> +   num_encoders, pipe_name(master_crtc->pipe));
> >>
> >>return encoder;
> >>  }
> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> >> b/drivers/gpu/drm/i915/display/intel_display.h
> >> index ac95961f68ba..4620ed991ff0 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_display.h
> >> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> >> @@ -501,7 +501,8 @@ bool intel_plane_uses_fence(const struct
> >> intel_plane_state *plane_state);
> >>
> >>  struct intel_encoder *
> >>  intel_get_crtc_new_encoder(const struct intel_atomic_state *state,
> >> - const struct intel_crtc_state *crtc_state);
> >> + const struct intel_crtc_state *crtc_state,
> >> + bool warn);
> >>  void intel_plane_disable_noatomic(struct intel_crtc *crtc,
> >>  struct intel_plane *plane);
> >>  void intel_set_plane_visible(struct intel_crtc_state *crtc_state,
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c
> >> b/drivers/gpu/drm/i915/display/intel_dpll.c
> >> index ca0f362a40e3..3101de274f9d 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dpll.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dpll.c
> >> @@ -940,7 +940,7 @@ static int hsw_crtc_compute_clock(struct
> intel_atomic_state *state,
> >>struct intel_crtc_state *crtc_state =
> >>intel_atomic_get_new_crtc_state(state, crtc);
> >>struct intel_encoder *encoder =
> >> -  intel_get_crtc_new_encoder(state, 

Re: [Intel-gfx] [PATCH 0/8] drm/i915: HuC loading and authentication for MTL

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Ye, 
> Tony
> Sent: perjantai 28. huhtikuuta 2023 6.11
> To: Ceraolo Spurio, Daniele ; intel-
> g...@lists.freedesktop.org
> Cc: Teres Alexis, Alan Previn ; dri-
> de...@lists.freedesktop.org; Zhang, Carl 
> Subject: Re: [Intel-gfx] [PATCH 0/8] drm/i915: HuC loading and authentication 
> for
> MTL
> 
> Acked-by: Tony Ye 
CI results would be also good to look at before... 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117080v1/index.html?
For some reason no single MTL tests and many aborts...

> 
> Thanks,
> 
> Tony
> 
> On 4/27/2023 7:34 PM, Daniele Ceraolo Spurio wrote:
> > The HuC loading and authentication flow is once again changing and a
> > new "clear-media only" authentication step is introduced. The flow is
> > as
> > follows:
> >
> > 1) The HuC is loaded via DMA - same as all non-GSC HuC binaries.
> >
> > 2) The HuC is authenticated by the GuC - this is the same step as
> > performed for all non-GSC HuC binaries and re-uses the same code, but
> > it is now resulting in a partial authentication that only allows
> > clear-media workloads.
> >
> > 3) The HuC is fully authenticated for all workloads by the GSC - this
> > is done via a new PXP command, submitted via the GSCCS.
> >
> > The advantage of this new flow is that we can start processing
> > clear-media workloads without having to wait for the GSC to be ready,
> > which can take several seconds.
> >
> > As part of this change, the HuC status getparam has been updated with
> > a new value to indicate a partial authentication. Note tha the media
> > driver is checking for value > 0 for clear media workloads, so no
> > changes are required in userspace for that to work.
> >
> > The SW proxy series [1] has been included, squashed in a single patch,
> > as some of some of the patches in this series depend on it. This is
> > not a functional dependencies, the patches just touch the same code;
> > the proxy patches are planned to be merged first, so it is easier to
> > base the new patches on top of it to avoid having to rebase them later.
> >
> > [1]https://patchwork.freedesktop.org/series/115806/
> > Cc: Alan Previn
> > Cc: Tony Ye
> >
> > Daniele Ceraolo Spurio (8):
> >DO NOT REVIEW: drm/i915: Add support for MTL GSC SW Proxy
> >drm/i915/uc: perma-pin firmwares
> >drm/i915/huc: Parse the GSC-enabled HuC binary
> >drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
> >drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow
> >drm/i915/mtl/huc: auth HuC via GSC
> >drm/i915/mtl/huc: Use the media gt for the HuC getparam
> >drm/i915/huc: define HuC FW version for MTL
> >
> >   drivers/gpu/drm/i915/Makefile |   1 +
> >   drivers/gpu/drm/i915/gt/intel_ggtt.c  |   3 +
> >   drivers/gpu/drm/i915/gt/intel_gt_irq.c|  22 +-
> >   drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   3 +
> >   .../drm/i915/gt/uc/intel_gsc_meu_headers.h|  74 +++
> >   drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c  | 424 ++
> >   drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.h  |  18 +
> >   drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c |  89 +++-
> >   drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h |  17 +-
> >   .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c |   2 +-
> >   .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h |   1 +
> >   drivers/gpu/drm/i915/gt/uc/intel_guc.c|   2 +-
> >   drivers/gpu/drm/i915/gt/uc/intel_huc.c| 182 +---
> >   drivers/gpu/drm/i915/gt/uc/intel_huc.h|  26 +-
> >   drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 214 -
> >   drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h |   6 +-
> >   drivers/gpu/drm/i915/gt/uc/intel_huc_print.h  |  21 +
> >   drivers/gpu/drm/i915/gt/uc/intel_uc.c |  10 +-
> >   drivers/gpu/drm/i915/gt/uc/intel_uc.h |   2 +
> >   drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 120 ++---
> >   drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |   9 +-
> >   drivers/gpu/drm/i915/i915_getparam.c  |   6 +-
> >   drivers/gpu/drm/i915/i915_reg.h   |   3 +
> >   .../drm/i915/pxp/intel_pxp_cmd_interface_43.h |  14 +-
> >   drivers/gpu/drm/i915/pxp/intel_pxp_huc.c  |   2 +-
> >   drivers/misc/mei/Kconfig  |   2 +-
> >   drivers/misc/mei/Makefile |   1 +
> >   drivers/misc/mei/gsc_proxy/Kconfig|  14 +
> >   drivers/misc/mei/gsc_proxy/Makefile   |   7 +
> >   drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c| 208 +
> >   include/drm/i915_component.h  |   3 +-
> >   include/drm/i915_gsc_proxy_mei_interface.h|  53 +++
> >   include/uapi/drm/i915_drm.h   |   3 +-
> >   33 files changed, 1428 insertions(+), 134 deletions(-)
> >   create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_meu_headers.h
> >   create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
> >   create mode 100644 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform

[Saarinen, Jani]

Hi,

> -Original Message-
> From: Saarinen, Jani
> Sent: tiistai 28. maaliskuuta 2023 9.35
> To: Zhang, Rui ; Deak, Imre 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: ✗ Fi.CI.BAT: failure for x86/topology: fix erroneous
> smp_num_siblings on Intel Hybrid platform
> 
> Hi.
> > -Original Message-
> > From: Zhang, Rui 
> > Sent: tiistai 28. maaliskuuta 2023 4.57
> > To: Deak, Imre 
> > Cc: Saarinen, Jani ;
> > intel-gfx@lists.freedesktop.org
> > Subject: Re: ✗ Fi.CI.BAT: failure for x86/topology: fix erroneous
> > smp_num_siblings on Intel Hybrid platform
> >
> > On Tue, 2023-03-28 at 09:14 +0800, Zhang Rui wrote:
> > > Hi, Imre,
> > >
> > > Thanks for raising this.
> > >
> > > On Tue, 2023-03-28 at 00:26 +0300, Imre Deak wrote:
> > > > Hi Rui,
> > > >
> > > > after applying your
> > > > "x86/topology: fix erroneous smp_num_siblings on Intel Hybrid
> > > > platform"
> > > >
> > > > fix on the drm-tip tree (see the patchwork URL below) the CI tests
> > > > show some regression on a HSW and a KBL machine (see [2] and [4]
> > > > below) in the i915 driver. However I think they can't be related
> > > > to your changes, since on these machines all cores will report the
> > > > same number of CPU siblings.
> > >
> > > Right.
> > >
> > > >  Could you confirm this and that in general the reported siblings
> > > > can only vary on platforms with both E and P cores (ADL-P being
> > > > the first such platform)?
> > >
> > > Right.
> > >
> > > I don't think the patch could bring any change related.
> > > It only affects hybrid platforms.
> >
> > Is this topology fix patch the only patch applied? or together with some 
> > other
> patches?
> This only.
> >
> > I can hardly imagine that the fix patch can trigger such issues, so I
> > suspect they are intermittent issues. say is the regression 100% 
> > reproducible?
> This is not regression. I assume drm-tip misses this patch (as was not part 
> of 6.3rc
> yet.)
Ignore this comment, badly read mail only. I assume it is hard to day as this 
test is done on CI (pre-merge)
Let Imre to comment here. 
> 
> > does the warning/failure ever show without the patch?
> Yes, On our local (3) system's seen on all.
Again. Ignore this too. 
> >
> > BTW, I just happened to see this thread
> >
> https://lore.kernel.org/all/DM8PR11MB565580BCF44661B6A392F0CEE08B9@DM8
> > P
> > R11MB5655.namprd11.prod.outlook.com/
> > If the problem on hand has been verified to be not related with the
> > topology fix, can we update in this thread as well?
> > https://lore.kernel.org/all/20230323015640.27906-1-rui.zh...@intel.com
> > / This is another issue that the patch fixes. And it's better to have
> > a Buglink/Tested-by tag in the commit.
> >
> > thanks,
> > rui
> >
> > >
> > > Thanks,
> > > rui
> > > > Thanks,
> > > > Imre
> > > >
> > > > On Mon, Mar 27, 2023 at 07:02:25PM +, Patchwork wrote:
> > > > > == Series Details ==
> > > > >
> > > > > Series: x86/topology: fix erroneous smp_num_siblings on Intel
> > > > > Hybrid platform
> > > > > URL   : https://patchwork.freedesktop.org/series/115661/
> > > > > State : failure
> > > > >
> > > > > == Summary ==
> > > > >
> > > > > CI Bug Log - changes from CI_DRM_12921 -> Patchwork_115661v1
> > > > > 
> > > > >
> > > > > Summary
> > > > > ---
> > > > >
> > > > >   **FAILURE**
> > > > >
> > > > >   Serious unknown changes coming with Patchwork_115661v1
> > > > > absolutely need to be
> > > > >   verified manually.
> > > > >
> > > > >   If you think the reported changes have nothing to do with the
> > > > > changes
> > > > >   introduced in Patchwork_115661v1, please notify your bug team
> > > > > to allow them
> > > > >   to document this new failure mode, which will reduce false
> > > > > positives in CI.
> > > > >
> > > > >   External URL:
> > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/index.
> > > 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform

[Saarinen, Jani]

Hi. 
> -Original Message-
> From: Zhang, Rui 
> Sent: tiistai 28. maaliskuuta 2023 4.57
> To: Deak, Imre 
> Cc: Saarinen, Jani ; intel-gfx@lists.freedesktop.org
> Subject: Re: ✗ Fi.CI.BAT: failure for x86/topology: fix erroneous 
> smp_num_siblings
> on Intel Hybrid platform
> 
> On Tue, 2023-03-28 at 09:14 +0800, Zhang Rui wrote:
> > Hi, Imre,
> >
> > Thanks for raising this.
> >
> > On Tue, 2023-03-28 at 00:26 +0300, Imre Deak wrote:
> > > Hi Rui,
> > >
> > > after applying your
> > > "x86/topology: fix erroneous smp_num_siblings on Intel Hybrid
> > > platform"
> > >
> > > fix on the drm-tip tree (see the patchwork URL below) the CI tests
> > > show some regression on a HSW and a KBL machine (see [2] and [4]
> > > below) in the i915 driver. However I think they can't be related to
> > > your changes, since on these machines all cores will report the same
> > > number of CPU siblings.
> >
> > Right.
> >
> > >  Could you confirm this and that in general the reported siblings
> > > can only vary on platforms with both E and P cores (ADL-P being the
> > > first such platform)?
> >
> > Right.
> >
> > I don't think the patch could bring any change related.
> > It only affects hybrid platforms.
> 
> Is this topology fix patch the only patch applied? or together with some 
> other patches?
This only. 
> 
> I can hardly imagine that the fix patch can trigger such issues, so I suspect 
> they are
> intermittent issues. say is the regression 100% reproducible?
This is not regression. I assume drm-tip misses this patch (as was not part of 
6.3rc yet.)

> does the warning/failure ever show without the patch?
Yes, On our local (3) system's seen on all. 
> 
> BTW, I just happened to see this thread
> https://lore.kernel.org/all/DM8PR11MB565580BCF44661B6A392F0CEE08B9@DM8P 
> R11MB5655.namprd11.prod.outlook.com/
> If the problem on hand has been verified to be not related with the topology 
> fix, can
> we update in this thread as well?
> https://lore.kernel.org/all/20230323015640.27906-1-rui.zh...@intel.com/
> This is another issue that the patch fixes. And it's better to have a 
> Buglink/Tested-by
> tag in the commit.
> 
> thanks,
> rui
> 
> >
> > Thanks,
> > rui
> > > Thanks,
> > > Imre
> > >
> > > On Mon, Mar 27, 2023 at 07:02:25PM +, Patchwork wrote:
> > > > == Series Details ==
> > > >
> > > > Series: x86/topology: fix erroneous smp_num_siblings on Intel
> > > > Hybrid platform
> > > > URL   : https://patchwork.freedesktop.org/series/115661/
> > > > State : failure
> > > >
> > > > == Summary ==
> > > >
> > > > CI Bug Log - changes from CI_DRM_12921 -> Patchwork_115661v1
> > > > 
> > > >
> > > > Summary
> > > > ---
> > > >
> > > >   **FAILURE**
> > > >
> > > >   Serious unknown changes coming with Patchwork_115661v1
> > > > absolutely need to be
> > > >   verified manually.
> > > >
> > > >   If you think the reported changes have nothing to do with the
> > > > changes
> > > >   introduced in Patchwork_115661v1, please notify your bug team to
> > > > allow them
> > > >   to document this new failure mode, which will reduce false
> > > > positives in CI.
> > > >
> > > >   External URL:
> > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115661v1/index.
> > > > html
> > > >
> > > > Participating hosts (37 -> 37)
> > > > --
> > > >
> > > >   No changes in participating hosts
> > > >
> > > > Possible new issues
> > > > ---
> > > >
> > > >   Here are the unknown changes that may have been introduced in
> > > > Patchwork_115661v1:
> > > >
> > > > ### IGT changes ###
> > > >
> > > >  Possible regressions 
> > > >
> > > >   * igt@i915_selftest@live@hangcheck:
> > > > - fi-hsw-4770:[PASS][1] -> [DMESG-WARN][2]
> > > >[1]:
> > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12921/fi-hsw-
> 4770/igt@i915_selftest@l...@hangcheck.html
> > > >[2]:
> > > > https://intel-gfx-ci.01.org/t

Re: [Intel-gfx] [core-for-CI] x86/topology: fix erroneous smp_num_siblings on Intel Hybrid platform

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-gfx  On Behalf Of Imre 
> Deak
> Sent: maanantai 27. maaliskuuta 2023 15.11
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [core-for-CI] x86/topology: fix erroneous 
> smp_num_siblings on
> Intel Hybrid platform
> 
> From: Zhang Rui 
> 
> The SMT siblings value returned by CPUID.1F SMT level EBX differs among CPUs 
> on
> Intel Hybrid platforms like AlderLake and MeteorLake.
> It returns 2 for Pcore CPUs which have SMT siblings and returns 1 for Ecore 
> CPUs
> which do not have SMT siblings.
> 
> Today, the CPU boot code sets the global variable smp_num_siblings when every
> CPU thread is brought up. The last thread to boot will overwrite it with the 
> number
> of siblings of *that* thread. That last thread to boot will "win". If the 
> thread is a
> Pcore, smp_num_siblings == 2.  If it is an Ecore, smp_num_siblings == 1.
> 
> smp_num_siblings describes if the *system* supports SMT.  It should specify 
> the
> maximum number of SMT threads among all cores.
> 
> Ensure that smp_num_siblings represents the system-wide maximum number of
> siblings by always increasing its value. Never allow it to decrease.
> 
> On MeteorLake-P platform, this fixes a problem that the Ecore CPUs are not 
> updated
> in any cpu sibling map because the system is treated as an UP system when 
> probing
> Ecore CPUs.
> 
> Below shows part of the CPU topology information before and after the fix, 
> for both
> Pcore and Ecore CPU (cpu0 is Pcore, cpu 12 is Ecore).

Tested-By: Jani Saarinen  on local MTL setup. Also 
tested earlier on other CI systems 
by: https://patchwork.freedesktop.org/series/115601/ trybot series. 
For this there is https://gitlab.freedesktop.org/drm/intel/-/issues/8317 

Br,
Jani

> ...
> -/sys/devices/system/cpu/cpu0/topology/package_cpus:000fff
> -/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-11
> +/sys/devices/system/cpu/cpu0/topology/package_cpus:3f
> +/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-21
> ...
> -/sys/devices/system/cpu/cpu12/topology/package_cpus:001000
> -/sys/devices/system/cpu/cpu12/topology/package_cpus_list:12
> +/sys/devices/system/cpu/cpu12/topology/package_cpus:3f
> +/sys/devices/system/cpu/cpu12/topology/package_cpus_list:0-21
> 
> And this also breaks userspace tools like lscpu
> -Core(s) per socket:  1
> -Socket(s):   11
> +Core(s) per socket:  16
> +Socket(s):   1
> 
> CC: sta...@kernel.org
> Fixes: bbb65d2d365e ("x86: use cpuid vector 0xb when available for detecting 
> cpu
> topology")
> Fixes: 95f3d39ccf7a ("x86/cpu/topology: Provide
> detect_extended_topology_early()")
> Suggested-by: Len Brown 
> Signed-off-by: Zhang Rui 
> Acked-by: Peter Zijlstra (Intel) 
> [Imre: resend for core-for-CI]
> References: https://lore.kernel.org/lkml/20230323015640.27906-1-
> rui.zh...@intel.com
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/8317
> Signed-off-by: Imre Deak 
> ---
>  arch/x86/kernel/cpu/topology.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c 
> index
> 5e868b62a7c4e..0270925fe013b 100644
> --- a/arch/x86/kernel/cpu/topology.c
> +++ b/arch/x86/kernel/cpu/topology.c
> @@ -79,7 +79,7 @@ int detect_extended_topology_early(struct cpuinfo_x86 *c)
>* initial apic id, which also represents 32-bit extended x2apic id.
>*/
>   c->initial_apicid = edx;
> - smp_num_siblings = LEVEL_MAX_SIBLINGS(ebx);
> + smp_num_siblings = max_t(int, smp_num_siblings,
> +LEVEL_MAX_SIBLINGS(ebx));
>  #endif
>   return 0;
>  }
> @@ -109,7 +109,8 @@ int detect_extended_topology(struct cpuinfo_x86 *c)
>*/
>   cpuid_count(leaf, SMT_LEVEL, , , , );
>   c->initial_apicid = edx;
> - core_level_siblings = smp_num_siblings = LEVEL_MAX_SIBLINGS(ebx);
> + core_level_siblings = LEVEL_MAX_SIBLINGS(ebx);
> + smp_num_siblings = max_t(int, smp_num_siblings,
> +LEVEL_MAX_SIBLINGS(ebx));
>   core_plus_mask_width = ht_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
>   die_level_siblings = LEVEL_MAX_SIBLINGS(ebx);
>   pkg_mask_width = die_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax);
> --
> 2.37.2

Re: [Intel-gfx] [PATCH] Revert "drm/shmem-helper: Switch to reservation lock"

[Saarinen, Jani]

> -Original Message-
> From: Intel-gfx  On Behalf Of Thomas
> Zimmermann
> Sent: tiistai 28. helmikuuta 2023 17.46
> To: Dmitry Osipenko ;
> maarten.lankho...@linux.intel.com; airl...@gmail.com; dan...@ffwll.ch; Nikula,
> Jani 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] Revert "drm/shmem-helper: Switch to
> reservation lock"
> 
> Hi
> 
> Am 28.02.23 um 16:28 schrieb Dmitry Osipenko:
> > On 2/28/23 18:26, Thomas Zimmermann wrote:
> >> This reverts commit 67b7836d4458790f1261e31fe0ce3250989784f0.
> >>
> >> The locking appears incomplete. A caller of SHMEM helper's pin
> >> function never acquires the dma-buf reservation lock. So we get
> >>
> >>WARNING: CPU: 3 PID: 967 at
> >> drivers/gpu/drm/drm_gem_shmem_helper.c:243
> >> drm_gem_shmem_pin+0x42/0x90 [drm_shmem_helper]
> >>
> >> Signed-off-by: Thomas Zimmermann 
> >> ---
> >
> > Thanks Thomas,
> >
> > Acked-by: Dmitry Osipenko 
> >
> 
> Thanks, merged now. I hope this fixes the immediate issues.
According to pre-merge results: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/index.html? 
So should fix. 

> 
> Best regards
> Thomas
> 
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev

Re: [Intel-gfx] [PATCH] drm/shmem-helper: Fix compile error

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Nikula, Jani 
> Sent: tiistai 28. helmikuuta 2023 16.40
> To: Andi Shyti 
> Cc: Andi Shyti ; Dmitry Osipenko
> ; dri-de...@lists.freedesktop.org; Maarten
> Lankhorst ; Maxime Ripard
> ; Thomas Zimmermann ; David
> Airlie ; Daniel Vetter ; Javier Martinez
> Canillas ; Asahi Lina ; Andi Shyti
> ; Intel GFX ; Tvrtko 
> Ursulin
> ; Vivi, Rodrigo ; 
> Joonas
> Lahtinen ; Saarinen, Jani
> 
> Subject: Re: [PATCH] drm/shmem-helper: Fix compile error
> 
> On Tue, 28 Feb 2023, Andi Shyti  wrote:
> > Hi,
> >
> >> >> > Commit 67b7836d4458 ("drm/shmem-helper: Switch to reservation
> >> >> > lock") removes the drm_gem_shmem_get_pages_locked() and
> >> >> > drm_gem_shmem_put_pages_locked().
> >> >> >
> >> >> > But then commit edaa0db9 ("drm/shmem-helper: Fix locking for
> >> >> > drm_gem_shmem_get_pages_sgt()") reintroduces it.
> >> >> >
> >> >> > Somehow these two commits got mixed up and produce the following
> >> >> > compile error:
> >> >>
> >> >> The 67b7836d4458 goes after edaa0db9 in misc-next. It was a
> >> >> bad merge conflict resolution in drm-tip that was fixed yesterday,
> >> >> there is no problem in misc-next. Where do you see this error?
> >> >
> >> > yes, indeed! I was indeed surprised to see this mismatch.
> >> >
> >> > I see it in the Intel's drm-tip branch[*]
> >>
> >> To set the record straight, drm-tip isn't Intel's, it's an
> >> integration branch shared by the drm community.
> >
> > yes of course... it's a matter of fast writing :)
> >
> >> Looks like the same bad merge resolution has resurrected itself
> >> somehow, maybe Thomas'
> >>
> >> commit 418ce969b4c8533c7c76cc0b7adeb432ccdc137e
> >> Author: Thomas Zimmermann 
> >> Date:   Tue Feb 28 10:03:24 2023 +0100
> >>
> >> 2023y-02m-28d-09h-02m-44s UTC: drm-tip rerere cache update
> >>
> >> git version 2.39.2
> >>
> >> in drm-rerere brought it back.
> >>
> >> And the build is indeed currently broken.
> >>
> >> Moreover, when the build was fine for a while, apparently the changes
> >> in shmem broke a bunch of machines in Intel CI. And due to this, we
> >> aren't getting any CI results for incoming patches right now.
> >
> > Is there any plans for fixing it?
> 
> Someone(tm) needs to step up and do it. Personally, I'm clueless.
> 
> The whole thing is made worse by the conflict and the various resolutions. At 
> this
> time, I'm not certain whether the whole thing was broken to begin with, or if 
> it's
> just the conflict resolution that caused the issues.
> 
> I'll just note that for future reference, Cc'ing intel-gfx for anything 
> non-trivial
> touching the guts of drm will be useful for running CI on our test farm 
> pre-merge.
> Now, we don't know.
Yeah, and sad story can be seen from 
https://intel-gfx-ci.01.org/tree/drm-tip/index.html? .
All systems now abort on BAT run. 
Just to pick one: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12789/fi-tgl-1115g4/igt@gem_exec_fence@basic-b...@vecs0.html
Please fix asap. Or revert from tree asap. 

> 
> 
> BR,
> Jani.
> 
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: implement async_flip mode per plane tracking (rev5)

[Saarinen, Jani]

Hi,
> -Original Message-
> From: Intel-gfx  On Behalf Of 
> Patchwork
> Sent: perjantai 27. tammikuuta 2023 21.24
> To: Hajda, Andrzej 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: implement async_flip 
> mode per
> plane tracking (rev5)
> 
> Patch Details
> Series:   drm/i915: implement async_flip mode per plane tracking (rev5)
> URL:  https://patchwork.freedesktop.org/series/108371/
> State:failure
> Details:  
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/index.html
> 
> CI Bug Log - changes from CI_DRM_12655_full -> Patchwork_108371v5_full
> 
> 
> Summary
> 
> 
> FAILURE
> 
> Serious unknown changes coming with Patchwork_108371v5_full absolutely need to
> be verified manually.
> 
> If you think the reported changes have nothing to do with the changes 
> introduced in
> Patchwork_108371v5_full, please notify your bug team to allow them to document
> this new failure mode, which will reduce false positives in CI.
> 
> External URL: https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_108371v5/index.html
> 
> 
> Participating hosts (10 -> 11)
> 
> 
> Additional (1): shard-rkl0
> 
> 
> Possible new issues
> 
> 
> Here are the unknown changes that may have been introduced in
> Patchwork_108371v5_full:
> 
> 
> IGT changes
> 
> 
> Possible regressions
> 
> 
> * igt@gen9_exec_parse@allowed-single:
> 
>   *   shard-glk: PASS  tip/CI_DRM_12655/shard-glk4/igt@gen9_exec_pa...@allowed-single.html>  ->
> ABORT  glk1/igt@gen9_exec_pa...@allowed-single.html>

Similar issue seen on CI_DRM_12656: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12656/shard-glk5/igt@gen9_exec_pa...@allowed-single.html
So I assume not due to this patch. 

> 
> 
> Suppressed
> 
> 
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
> 
> * igt@gem_ccs@suspend-resume:
> 
>   *   {shard-rkl}: SKIP  tip/CI_DRM_12655/shard-rkl-2/igt@gem_...@suspend-resume.html>  (i915#5325
>  ) -> SKIP 
>  ci.01.org/tree/drm-tip/Patchwork_108371v5/shard-rkl-5/igt@gem_ccs@suspend-
> resume.html>
> 
> 
> Known issues
> 
> 
> Here are the changes found in Patchwork_108371v5_full that come from known
> issues:
> 
> 
> IGT changes
> 
> 
> Issues hit
> 
> 
> * igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
> 
>   *   shard-glk: NOTRUN -> SKIP  tip/Patchwork_108371v5/shard-glk3/igt@kms_dither@fb-8bpc-vs-panel-
> 6...@pipe-a-hdmi-a-1.html>  (fdo#109271
>  )
> 
> 
> Possible fixes
> 
> 
> * igt@drm_fdinfo@virtual-idle:
> 
>   *   {shard-rkl}: FAIL  tip/CI_DRM_12655/shard-rkl-2/igt@drm_fdi...@virtual-idle.html>  (i915#7742
>  ) -> PASS 
>  ci.01.org/tree/drm-tip/Patchwork_108371v5/shard-rkl-5/igt@drm_fdinfo@virtual-
> idle.html>  +1 similar issue
> 
> * igt@gem_ctx_persistence@many-contexts:
> 
>   *   {shard-dg1}: ABORT  tip/CI_DRM_12655/shard-dg1-14/igt@gem_ctx_persiste...@many-contexts.html>
> (i915#4983  ) -> PASS
>  12/igt@gem_ctx_persiste...@many-contexts.html>
> 
> * igt@gem_eio@in-flight-suspend:
> 
>   *   {shard-rkl}: FAIL  tip/CI_DRM_12655/shard-rkl-4/igt@gem_...@in-flight-suspend.html>  (fdo#103375
>  ) -> PASS 
>  gfx-ci.01.org/tree/drm-tip/Patchwork_108371v5/shard-rkl-5/igt@gem_eio@in-
> flight-suspend.html>
> 
> * igt@gem_exec_endless@dispatch@bcs0:
> 
>   *   {shard-rkl}: SKIP  tip/CI_DRM_12655/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html>
> (i915#6247  ) -> PASS
>  4/igt@gem_exec_endless@dispa...@bcs0.html>
> 
> * igt@gem_exec_fair@basic-none@vcs0:
> 
>   *   {shard-rkl}: FAIL  tip/CI_DRM_12655/shard-rkl-2/igt@gem_exec_fair@basic-n...@vcs0.html>
> (i915#2842  ) -> PASS
>  5/igt@gem_exec_fair@basic-n...@vcs0.html>  +1 similar issue
> 
> * igt@gem_exec_fair@basic-pace-share@rcs0:
> 
>   *   shard-glk: FAIL  

Re: [Intel-gfx] BUG: i915: flickering/temporary artifacts after resume

[Saarinen, Jani]

Hi Russell,
Can you make new gitlab: 
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs  ? 

Br,
Jani

> -Original Message-
> From: Intel-gfx  On Behalf Of Russell
> King (Oracle)
> Sent: lauantai 5. marraskuuta 2022 17.17
> To: Jani Nikula ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> Tvrtko Ursulin 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] BUG: i915: flickering/temporary artifacts after resume
> 
> Hi,
> 
> I have a HP Pavilion 15" laptop that occasionally misbehaves after a resume 
> from
> suspend mode. The problem is obvious when the screen updates e.g. after
> moving the mouse and the window focus changing, or when a terminal scrolls, I
> get a ficker of random short horizontal white lines over the top of the 
> windows
> that then disappear. These appear to be predominantly focused towards the top
> of the screen, although they do also occur lower down but less obviously.
> 
> Soemtimes these artifacts don't disappear until the next update - I attempted 
> to
> capture them, but of course that provokes another screen update and they
> disappear.
> 
> When this problem occurs, suspending and resuming again doesn't appear to fix
> the issue - only a reboot does.
> 
> Environment:
> 
> 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02)
> (prog-if 00 [VGA controller])
> DeviceName: Intel Kabylake HD Graphics ULT GT2
> Subsystem: Hewlett-Packard Company HD Graphics 620
> Flags: bus master, fast devsel, latency 0, IRQ 130, IOMMU group 1
> Memory at a000 (64-bit, non-prefetchable) [size=16M]
> Memory at 9000 (64-bit, prefetchable) [size=256M]
> I/O ports at 4000 [size=64]
> Expansion ROM at 000c [virtual] [disabled] [size=128K]
> Capabilities: [40] Vendor Specific Information: Len=0c 
> Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
> Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
> Capabilities: [d0] Power Management version 2
> Capabilities: [100] Process Address Space ID (PASID)
> Capabilities: [200] Address Translation Service (ATS)
> Capabilities: [300] Page Request Interface (PRI)
> Kernel driver in use: i915
> Kernel modules: i915
> 
> Debian Bullseye (stable), Xorg 1.20.11, libdrm 2.4.104, intel xorg driver
> 2.99.917+git20200714.
> 
> Kernel messages related to DRM:
> 
> Linux version 5.10.0-19-amd64 (debian-ker...@lists.debian.org) (gcc-10 
> (Debian 1
> 0.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
> Debian
>  5.10.149-1 (2022-10-17)
> ...
> i915 :00:02.0: [drm] VT-d active for gfx access checking generic (9000
> 408000) vs hw (a000 100) checking generic (9000 408000) vs hw
> (9000 1000)
> fb0: switching to inteldrmfb from EFI VGA
> Console: switching to colour dummy device 80x25
> i915 :00:02.0: vgaarb: deactivate vga console
> i915 :00:02.0: vgaarb: changed VGA decodes:
> olddecodes=io+mem,decodes=io+mem:owns=io+mem
> i915 :00:02.0: firmware: direct-loading firmware i915/kbl_dmc_ver1_04.bin
> i915 :00:02.0: [drm] Finished loading DMC firmware
> i915/kbl_dmc_ver1_04.bin (v1.4) [drm] Initialized i915 1.6.0 20200917 for
> :00:02.0 on minor 0
> ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
> input: Video Bus as
> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input6
> fbcon: i915drmfb (fb0) is primary device
> Console: switching to colour frame buffer device 170x48
> i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device mei_hdcp
> :00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound :00:02.0 (ops
> i915_hdcp_component_ops [i915]) snd_hda_intel :00:1f.3: bound
> :00:02.0 (ops i915_audio_component_bind_ops [i915]) (NULL device *):
> firmware: direct-loading firmware i915/kbl_dmc_ver1_04.bin mei_hdcp
> :00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound :00:02.0 ( ops
> i915_hdcp_component_ops [i915])
> 
> The last two lines repeat each time the system is suspended/resumed.
> 
> No errors or warnings appear to be logged either from the kernel nor in the 
> Xorg
> log file specific to i915 (there's the usual Xorg whinging about the system 
> being
> too slow... so an i5-7200U 2.5GHz isn't fast enough for Xorg!)
> 
> It feels like some setting within the Intel GPU hardware that controls memory
> access timing isn't being properly restored.
> 
> Is this a known issue?
> 
> Thanks.
> 
> Russell.
> 
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [Intel-gfx] Random submitter change in Freedesktop Patchwork

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-gfx  On Behalf Of Ville 
> Syrjälä
> Sent: torstai 20. lokakuuta 2022 19.21
> To: Jani Nikula 
> Cc: Sarvela, Tomi P ; 
> intel-gfx@lists.freedesktop.org;
> dri-de...@lists.freedesktop.org; Vivi, Rodrigo 
> Subject: Re: [Intel-gfx] Random submitter change in Freedesktop Patchwork
> 
> On Thu, Oct 20, 2022 at 07:07:22PM +0300, Jani Nikula wrote:
> > On Thu, 20 Oct 2022, "Dixit, Ashutosh"  wrote:
> > > The freedesktop Patchwork seems to have a "feature" where in some
> > > cases the submitter for a series changes randomly to a person who
> > > did not actually submit a version of the series.
> > >
> > > Not sure but this changed submitter seems to be a maintainer:
> > >
> > > 
> > > https://patchwork.freedesktop.org/series/108156/
> > >
> > > Original submission by badal.nila...@intel.com and subsequent
> > > submissions by me (ashutosh.di...@intel.com) but current submitter
> > > is jani.nik...@linux.intel.com.
> > >
> > > For the above series I believe the submitter changed at v7 where
> > > perhaps a rebuild or a retest was scheduled (not sure if Jani did it
> > > and that changed
> > > something) but the build failed at v7. Also note root msg-id's for
> > > v6 and
> > > v7 are the same.
> > > 
> > > https://patchwork.freedesktop.org/series/108091/
> > >
> > > Original submission by me (ashutosh.di...@intel.com) but current
> > > submitter is rodrigo.v...@intel.com.
> > >
> > > Similarly here submitter seems to have changed at v3 where again the
> > > build failed. Also note root msg-id's for v2 and v3 are the same.
> > > 
> > >
> > > The problem this change of submitter causes is that if the actual
> > > original submitter wants to schedule a retest they cannot do it
> > > using the retest button.
> >
> > I presume it's caused by me responding with a review comment that
> > patchwork interpreted as a new patch in the series [1], and changed
> > the series submitter too.
> >
> > Sorry about that. It's a known issue that I sometimes forget to work
> > around when replying with diffs.
Yes, known issue. +@Latvala, Petri too. 

> 
> I just permenently stuck a 'my_hdr X-Patchwork-Hint: comment'
> into my .muttrc to avoid that.
> 
> --
> Ville Syrjälä
> Intel

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: disable FBC if its pipe is fused off

[Saarinen, Jani]

+Lakshmi.  

> -Original Message-
> From: Intel-gfx  On Behalf Of Coelho,
> Luciano
> Sent: tiistai 27. syyskuuta 2022 14.28
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: disable FBC if 
> its pipe is
> fused off
> 
> Hi,
> 
> This failure is not a real issue.  For some reason the
> igt@kms_writeback@writeback-check-output test was not running before and
> now it is.  The test is always getting skipped (even in local tests), so this 
> result is as
> expected.  The test is also skipped without this patch.
> 
> This failure can be ignored.
> 
> --
> Cheers,
> Luca.
> 
> On Mon, 2022-09-26 at 19:13 +, Patchwork wrote:
> 
>   Patch Details
> Series:drm/i915: disable FBC if its pipe is fused off
> URL:   https://patchwork.freedesktop.org/series/109044/
> State: failure
> Details:   https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_109044v1/index.html
> 
>   CI Bug Log - changes from CI_DRM_12182_full ->
> Patchwork_109044v1_full
> 
> 
>   Summary
> 
> 
>   FAILURE
> 
>   Serious unknown changes coming with Patchwork_109044v1_full
> absolutely need to be
>   verified manually.
> 
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_109044v1_full, please notify your bug team to
> allow them
>   to document this new failure mode, which will reduce false positives in
> CI.
> 
> 
>   Participating hosts (9 -> 11)
> 
> 
>   Additional (2): shard-rkl shard-tglu
> 
> 
>   Possible new issues
> 
> 
>   Here are the unknown changes that may have been introduced in
> Patchwork_109044v1_full:
> 
> 
>   IGT changes
> 
> 
>   Possible regressions
> 
> 
>   *   igt@kms_writeback@writeback-check-output:
> 
>   *   shard-tglb: NOTRUN -> SKIP  ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-
> tglb7/igt@kms_writeb...@writeback-check-output.html>
> 
> 
>   Known issues
> 
> 
>   Here are the changes found in Patchwork_109044v1_full that come from
> known issues:
> 
> 
>   CI changes
> 
> 
>   IGT changes
> 
> 
>   Issues hit
> 
> 
>   *   igt@gem_eio@wait-immediate:
> 
>   *   shard-apl: PASS  tip/CI_DRM_12182/shard-apl6/igt@gem_...@wait-immediate.html>  -> DMESG-
> WARN  apl2/igt@gem_...@wait-immediate.html>  (i915#62
>  ) +13 similar issues
> 
>   *   igt@gem_exec_balancer@parallel:
> 
>   *   shard-iclb: PASS  tip/CI_DRM_12182/shard-iclb1/igt@gem_exec_balan...@parallel.html>  -> SKIP
>  iclb5/igt@gem_exec_balan...@parallel.html>  (i915#4525
>  ) +1 similar issue
> 
>   *   igt@gem_exec_fair@basic-none@bcs0:
> 
>   *   shard-tglb: NOTRUN -> FAIL  ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-
> tglb7/igt@gem_exec_fair@basic-n...@bcs0.html>  (i915#2842
>  ) +4 similar issues
> 
>   *   igt@gem_exec_fair@basic-pace@vecs0:
> 
>   *   shard-iclb: PASS  tip/CI_DRM_12182/shard-iclb7/igt@gem_exec_fair@basic-p...@vecs0.html>  ->
> FAIL  iclb5/igt@gem_exec_fair@basic-p...@vecs0.html>  (i915#2842
>  )
> 
>   *   igt@gem_huc_copy@huc-copy:
> 
>   *   shard-tglb: PASS  tip/CI_DRM_12182/shard-tglb5/igt@gem_huc_c...@huc-copy.html>  -> SKIP
>  tglb7/igt@gem_huc_c...@huc-copy.html>  (i915#2190
>  )
> 
>   *   igt@gem_lmem_swapping@heavy-multi:
> 
>   *   shard-tglb: NOTRUN -> SKIP  ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-
> tglb7/igt@gem_lmem_swapp...@heavy-multi.html>  (i915#4613
>  )
> 
>   *   igt@gem_render_copy@linear-to-vebox-yf-tiled:
> 
>   *   shard-iclb: NOTRUN -> SKIP  ci.01.org/tree/drm-tip/Patchwork_109044v1/shard-
> iclb7/igt@gem_render_c...@linear-to-vebox-yf-tiled.html>  (i915#768
>  )
> 
>   *   igt@gem_workarounds@suspend-resume:
> 
>   *   shard-apl: PASS  tip/CI_DRM_12182/shard-apl7/igt@gem_workarou...@suspend-resume.html>
> -> DMESG-WARN 

Re: [Intel-gfx] i915 w/5.19: wild flickering glitching technicolor pyrotechnics on resumption from suspend

[Saarinen, Jani]

Hi, 
Please file issue at: 
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs 

Br,

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



> -Original Message-
> From: Intel-gfx  On Behalf Of Jason 
> A.
> Donenfeld
> Sent: torstai 9. kesäkuuta 2022 0.32
> To: dri-devel ; 
> intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] i915 w/5.19: wild flickering glitching technicolor 
> pyrotechnics
> on resumption from suspend
> 
> Hi,
> 
> Using the i7-11850H's iGPU, when I wake my Thinkpad X1 Extreme Gen 4 from
> suspend on 5.19-rc1, the display shows wild flickering with strobing colors 
> and
> more artifacts than real pixels in an utter disaster explosion of pantone, as
> though bombs were dropped on the leprechauns at the base of the rainbow.
> That sounds ridiculous, but the strobing pattern really is a sight to be seen.
> 
> I can only stop it by rebooting.
> 
> I took a video, but I worry about having private info in my video buffer, so 
> if
> you'd like to see it, email me privately.
> 
> The system is otherwise operational and fine. Nothing in dmesg, even with i915
> debugging enabled, and if it weren't for the display artifacts, I believe the 
> actual
> rendering in video memory would be fine. So this sort of looks like a display
> driver or some sort of psr problem.
> 
> Let me know if there's anything else I can do to provide more debug info. It's
> pretty trivial to reproduce: I just put my laptop to sleep and wake it back 
> up.
> 
> Jason

Re: [Intel-gfx] commit 15512021eb3975a8c2366e3883337e252bb0eee5 causes white spots in console screens

[Saarinen, Jani]

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani
> Nikula
> Sent: torstai 14. huhtikuuta 2022 11.32
> To: François Valenduc ; Lisovskiy, Stanislav
> 
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] commit 15512021eb3975a8c2366e3883337e252bb0eee5
> causes white spots in console screens
> 
> On Thu, 14 Apr 2022, François Valenduc  wrote:
> > Le 14/04/22 à 10:03, Lisovskiy, Stanislav a écrit :
> >> On Thu, Apr 14, 2022 at 08:33:35AM +0200, François Valenduc wrote:
> >>> Le 14/04/22 à 08:31, Lisovskiy, Stanislav a écrit :
>  On Wed, Apr 13, 2022 at 08:12:20PM +0300, Jani Nikula wrote:
> > On Wed, 13 Apr 2022, François Valenduc 
> wrote:
> >> Commit 15512021eb3975a8c2366e3883337e252bb0eee5
> >> (15512021eb3975a8c2366e3883337e252bb0eee5) causes a lof of white
> >> spots to appears on the right upper corner of all console screens
> >> (see
> https://drive.google.com/file/d/13GabEvOIKSAj5yox6ybAZEDu3Ixncw5Q/view).
> >> git-bisect shows that this is the offending commit and if I
> >> revert it, the problem goes away. The problem still occurs with
> >> kernel 5.18-rc2 and to all stable trees where it was applied.
> >> Can somebody explains what happens ?
> >>
> >> The video card is the following: VGA compatible controller: Intel
> >> Corporation WhiskeyLake-U GT2 [UHD Graphics 620] (rev 02)
> >> (prog-if 00 [VGA controller])
> >>
> >> Please tell me if you need more info.
> > That's commit 15512021eb39 ("drm/i915: Workaround broken BIOS DBUF
> > configuration on TGL/RKL"), adding Cc's.
> >
> > Please file a report at fdo gitlab [1] and attach dmesg etc. there.
>  That commit looks like it is just disabling all the planes, if
>  wrong dbuf/wm configuration is detected.
>  However it should do that only once during boot as I understand.
> 
>  Are you sure that is exactly this commit which is causing this?
>  Does the issue appear always?
> 
>  Ville Syrjälä, thoughts?
> 
>  Stan
> 
> > Thanks,
> > Jani.
> >
> >
> > [1]
> > https://gitlab.freedesktop.org/drm/intel/wikis/How-to-file-i915-bu
> > gs
> >
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
> >>> As I said, git-bisect shows it's the offending commit and if I
> >>> revert it, the problem doesn't happens. Otherwise, it always occurs.
> >>>
> >>> François
> >>>
> >> Does it just happen all the time or some steps/certain circumstances
> >> needed for it to happen?
> >>
> >> Only suspicion after looking briefly is that once suspend/resume is
> >> done it might be messing something up. Just a quick guess..
> >>
> >> Stan
> >
> > It occurs permantently as soon as I boot my computer.
> 
> I'd appreciate that bug being filed, and the discussion moved there, so all 
> the
> details and history are in one place.
Agree. 

> 
> Thanks,
> Jani.
> 
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [bug report] High refresh rates broken on eDP display with Optimus

[Saarinen, Jani]

Hi,
Please file bug to gitlab: 
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs 

> -Original Message-
> From: Intel-gfx  On Behalf Of Jeffrey
> Ellison
> Sent: tiistai 29. maaliskuuta 2022 5.38
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [bug report] High refresh rates broken on eDP display 
> with
> Optimus
> 
> Hello,
> 
> I have an Optimus laptop with Intel Tiger Lake H GT1 integrated graphics (i7-
> 11800H) and NVIDIA RTX 3080 Mobile GPU. The inbuilt display is 165 Hz and is
> connected to the IGPU by eDP. As of any Kernel version 5.16 onwards, Xrandr
> only detects 60 Hz as a possible refresh rate. The problem also occurs on
> Wayland. Downgrading to 5.15.13 resolves the problem.
> 
> Another user of a laptop with similar specs also reports the same issue and
> provides Xrandr output: https://bbs.archlinux.org/viewtopic.php?id=274012
> 
> Distro: Arch Linux
> Laptop: Razer Blade 15" Advanced 2021 (RZ09-0409CEA3)
> 
> CPU: i7-11800H
> IGPU: Tiger Lake H GT1 [UHD Graphics]
> DGPU: NVIDIA RTX 3080 Laptop (Ampere GA104M)
> 
> Drivers: NVIDIA Proprietary (510.54-9), Mesa (21.3.7)

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display/vrr: Reset VRR capable property on a long hpd (rev4)

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Navare, Manasi D 
> Sent: torstai 24. helmikuuta 2022 21.00
> To: intel-gfx@lists.freedesktop.org
> Cc: Sarvela, Tomi P ; Syrjala, Ville
> ; Saarinen, Jani ; Nikula, 
> Jani
> 
> Subject: RE: ✗ Fi.CI.BAT: failure for drm/i915/display/vrr: Reset VRR capable
> property on a long hpd (rev4)
> 
> Hi,
> 
> 
> 
> I fixed the regression in this patch and resent it, it still has BAT 
> failures, I wanted
> to understand if it failed to boot some of the machines again or the errors 
> flagged
> here are the known errors.
> 
> 
> 
> Regards
> 
> Manasi
> 
> 
> 
> From: Patchwork 
> Sent: Thursday, February 24, 2022 10:45 AM
> To: Navare, Manasi D 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✗ Fi.CI.BAT: failure for drm/i915/display/vrr: Reset VRR capable 
> property
> on a long hpd (rev4)
> 
> 
> 
> Patch Details
> 
> Series:
> 
> drm/i915/display/vrr: Reset VRR capable property on a long hpd (rev4)
> 
> URL:
> 
> https://patchwork.freedesktop.org/series/98801/
> 
> State:
> 
> failure
> 
> Details:
> 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22394/index.html
> 
> 
> CI Bug Log - changes from CI_DRM_11279 -> Patchwork_22394
> 
> 
> Summary
> 
> 
> FAILURE
> 
> Serious unknown changes coming with Patchwork_22394 absolutely need to be
> verified manually.
> 
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_22394, please notify your bug team to allow them to
> document this new failure mode, which will reduce false positives in CI.
> 
> External URL: https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_22394/index.html
> 
> 
> Participating hosts (43 -> 32)
> 
> 
> Missing (11): fi-kbl-soraka fi-cml-u2 fi-bsw-cyan fi-ilk-650 fi-apl-guc 
> fi-kbl-7500u fi-
> kbl-x1275 fi-cfl-8109u fi-bsw-kefka fi-bdw-samus fi-skl-6600u
Would be good to understand why there is this many systems down still. Also are 
these same than on previous series...
Previous was missing:
--
Missing (29): fi-kbl-soraka fi-bdw-gvtdvm fi-apl-guc fi-snb-2520m fi-skl-6600u 
fi-snb-2600 fi-cml-u2 fi-bxt-dsi fi-bdw-5557u shard-tglu fi-bsw-n3050 
fi-glk-dsi fi-ilk-650 fi-kbl-7500u fi-hsw-4770 fi-ivb-3770 fi-elk-e7500 
fi-bsw-nick fi-skl-6700k2 fi-kbl-7567u fi-skl-guc fi-cfl-8700k fi-bsw-cyan 
fi-cfl-guc fi-kbl-guc fi-kbl-x1275 fi-cfl-8109u fi-kbl-8809g fi-bsw-kefka
--
So there are same systems. Tomi, what is threshold how many systems need to 
have boot issues and having 
Just looking some same systems on both...:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22394/filelist.html 
eg. 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22394/fi-kbl-soraka/run0.txt 
and 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22394/fi-kbl-7500u/run0.txt 
, there is also oops 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22394/fi-kbl-7500u/pstore0-1645726566_Oops_1.txt
 
I would say not clean really yet


> 
> 
> Possible new issues
> 
> 
> Here are the unknown changes that may have been introduced in
> Patchwork_22394:
> 
> 
> IGT changes
> 
> 
> Possible regressions
> 
> 
> * igt@gem_exec_suspend@basic-s0@smem:
> 
>   *   fi-skl-6700k2: PASS <https://intel-gfx-ci.01.org/tree/drm-
> tip/CI_DRM_11279/fi-skl-6700k2/igt@gem_exec_suspend@basic-
> s...@smem.html>  -> DMESG-WARN <https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_22394/fi-skl-6700k2/igt@gem_exec_suspend@basic-
> s...@smem.html>
> 
> 
> Known issues
> 
> 
> Here are the changes found in Patchwork_22394 that come from known issues:
> 
> 
> IGT changes
> 
> 
> Issues hit
> 
> 
> * igt@amdgpu/amd_basic@cs-multi-fence:
> 
>   *   fi-blb-e6850: NOTRUN -> SKIP <https://intel-gfx-
> ci.01.org/tree/drm-tip/Patchwork_22394/fi-blb-
> e6850/igt@amdgpu/amd_ba...@cs-multi-fence.html>  (fdo#109271
> <https://bugs.freedesktop.org/show_bug.cgi?id=109271> ) +17 similar issues
> 
> * igt@runner@aborted:
> 
>   *   fi-skl-6700k2: NOTRUN -> FAIL <https://intel-gfx-
> ci.01.org/tree/drm-tip/Patchwork_22394/fi-skl-
> 6700k2/igt@run...@aborted.html>  (i915#4312
> <https://gitlab.freedesktop.org/drm/intel/issues/4312> )
> 
> 
> Possible fixes
> 
> 
> * igt@i915_selftest@live@hangcheck:
> 
>   *   bat-dg1-6: DMESG-FAIL <https://intel-gfx-ci.01.org/tree/drm-
> tip/CI_DRM_11279/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html>
> (i915#4494 <https://gitlab.freedesktop.org/drm/intel/issues/4494>  / i915#4957
> <https://gitlab.freedesktop.org/drm/intel/issues/4957>

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Bump DMC to v2.14 on ADL-P (rev2)

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of 
> Patchwork
> Sent: torstai 2. joulukuuta 2021 1.35
> To: Tolakanahalli Pradeep, Madhumitha
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✓ Fi.CI.BAT: success for Bump DMC to v2.14 on ADL-P 
> (rev2)
> 
> Patch Details
> Series:   Bump DMC to v2.14 on ADL-P (rev2)
> URL:  https://patchwork.freedesktop.org/series/97477/
> State:success
> Details:  
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21722/index.html
> 
> CI Bug Log - changes from CI_DRM_10951 -> Patchwork_21722
> 
> 
> Summary
> 
> 
> SUCCESS
> 
> No regressions found.
This actually caused now regression on ADL-P's that was not caught by CI. 
Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/4731
+ Lucas who merged. 

> 
> External URL: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21722/index.html
> 
> 
> Participating hosts (39 -> 33)
> 
> 
> Additional (2): fi-kbl-soraka fi-icl-u2 Missing (8): fi-rkl-11600 bat-dg1-6 
> bat-dg1-5 fi-
> bsw-cyan bat-adlp-6 fi-pnv-d510 bat-jsl-2 bat-jsl-1
> 
> 
> Known issues
> 
> 
> Here are the changes found in Patchwork_21722 that come from known issues:
> 
> 
> IGT changes
> 
> 
> Issues hit
> 
> 
> * igt@amdgpu/amd_cs_nop@fork-gfx0:
> 
>   *   fi-icl-u2: NOTRUN -> SKIP  tip/Patchwork_21722/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html>
> (fdo#109315  ) +17 
> similar
> issues
> 
> * igt@gem_exec_fence@basic-busy@bcs0:
> 
>   *   fi-kbl-soraka: NOTRUN -> SKIP  ci.01.org/tree/drm-tip/Patchwork_21722/fi-kbl-
> soraka/igt@gem_exec_fence@basic-b...@bcs0.html>  (fdo#109271
>  ) +8 similar issues
> 
> * igt@gem_exec_suspend@basic-s3:
> 
>   *   fi-bdw-5557u: PASS  tip/CI_DRM_10951/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html>  ->
> INCOMPLETE  5557u/igt@gem_exec_susp...@basic-s3.html>  (i915#146
>  )
> 
> * igt@gem_flink_basic@bad-flink:
> 
>   *   fi-skl-6600u: PASS  tip/CI_DRM_10951/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html>  ->
> INCOMPLETE  6600u/igt@gem_flink_ba...@bad-flink.html>  (i915#198
>  )
> 
> * igt@gem_huc_copy@huc-copy:
> 
>   *   fi-kbl-soraka: NOTRUN -> SKIP  ci.01.org/tree/drm-tip/Patchwork_21722/fi-kbl-soraka/igt@gem_huc_copy@huc-
> copy.html>  (fdo#109271 
> / i915#2190  )
> 
>   *   fi-icl-u2: NOTRUN -> SKIP  tip/Patchwork_21722/fi-icl-u2/igt@gem_huc_c...@huc-copy.html>  (i915#2190
>  )
> 
> * igt@gem_lmem_swapping@basic:
> 
>   *   fi-kbl-soraka: NOTRUN -> SKIP  ci.01.org/tree/drm-tip/Patchwork_21722/fi-kbl-
> soraka/igt@gem_lmem_swapp...@basic.html>  (fdo#109271
>   / i915#4613
>  ) +3 similar issues
> 
> * igt@gem_lmem_swapping@parallel-random-engines:
> 
>   *   fi-icl-u2: NOTRUN -> SKIP  tip/Patchwork_21722/fi-icl-u2/igt@gem_lmem_swapping@parallel-random-
> engines.html>  (i915#4613 
>  )
> +3 similar issues
> 
> * igt@i915_selftest@live@gt_pm:
> 
>   *   fi-kbl-soraka: NOTRUN -> DMESG-FAIL  ci.01.org/tree/drm-tip/Patchwork_21722/fi-kbl-
> soraka/igt@i915_selftest@live@gt_pm.html>  (i915#1886
>   / i915#2291
>  )
> 
> * igt@kms_chamelium@common-hpd-after-suspend:
> 
>   *   fi-kbl-soraka: NOTRUN -> SKIP  ci.01.org/tree/drm-tip/Patchwork_21722/fi-kbl-
> soraka/igt@kms_chamel...@common-hpd-after-suspend.html>  (fdo#109271
>   / fdo#111827
>  ) +8 similar issues
> 
> * igt@kms_chamelium@hdmi-hpd-fast:
> 
>   *   fi-icl-u2: NOTRUN -> SKIP  tip/Patchwork_21722/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html>
> (fdo#111827  ) +8 similar
> issues
> 
> * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
> 
>   *   fi-icl-u2: NOTRUN -> SKIP 

Re: [Intel-gfx] Can't drive 4K monitor at full resolution over DP

[Saarinen, Jani]

Hi Bryan. 
Can you file new bug: 
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs 

Br,

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



> -Original Message-
> From: Intel-gfx  On Behalf Of Bryan
> O'Sullivan
> Sent: sunnuntai 14. marraskuuta 2021 6.36
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] Can't drive 4K monitor at full resolution over DP
> 
> I have a new Framework laptop running Fedora 35, stock kernel package 5.14.16-
> 301, BDB version 240.
> 
> My CPU/GPU is an 11th gen i7-1165G7, connected via a USB-C-to-DP cable to a
> 2014-era Dell P2715Q monitor that supports 3840x2160@60Hz over DP (my Mac
> drives it this way just fine).
> 
> With i915 debugging enabled, I can see the 4K modeline being detected and
> discarded because CLOCK_HIGH. Here's some debug output in a paste as it's 
> longish
> and verbose: https://pastebin.com/reGcmxYF
> 
> Line 17 of that paste seems weird, where the value of everything is zero for 
> some
> reason?
> 
> Here's some output from the monitor-edid tool. If there's any more 
> information I
> can supply to track this down, I'm happy to do what I can.
> 
> Name: DELL P2715Q
> EISA ID: DEL40bd
> EDID version: 1.4
> EDID extension blocks: 1
> Screen size: 59.7 cm x 33.6 cm (26.97 inches, aspect ratio 16/9 = 1.78)
> Gamma: 2.2
> Digital signal
> Max video bandwidth: 540 MHz
> 
> HorizSync 31-140
> VertRefresh 29-75
> 
> # Monitor preferred modeline (60.0 Hz vsync, 133.3 kHz hsync, ratio 
> 16/9, 163
> dpi)
> ModeLine "3840x2160" 533.25 3840 3888 3920 4000 2160 2163 2168  -
> hsync +vsync
> 
> # Monitor supported CEA modeline (60.0 Hz vsync, 67.5 kHz hsync, 
> ratio 16/9,
> 81 dpi)
> ModeLine "1920x1080" 148.5 1920 2008 2052 2200 1080 1084 1089 1125
> +hsync +vsync

Re: [Intel-gfx] [PATCH 01/24] drm/i915/uncore: split the fw get function into separate vfunc

[Saarinen, Jani]

> -Original Message-
> From: Intel-gfx  On Behalf Of Dave 
> Airlie
> Sent: maanantai 4. lokakuuta 2021 3.33
> To: Ville Syrjälä 
> Cc: Nikula, Jani ; Intel Graphics Development  g...@lists.freedesktop.org>; Dave Airlie ; Sarvela, Tomi P
> 
> Subject: Re: [Intel-gfx] [PATCH 01/24] drm/i915/uncore: split the fw get 
> function
> into separate vfunc
> 
> On Sun, 3 Oct 2021 at 05:27, Ville Syrjälä  
> wrote:
> >
> > On Wed, Sep 29, 2021 at 01:57:45AM +0300, Jani Nikula wrote:
> > > From: Dave Airlie 
> > >
> > > constify it while here. drop the put function since it was never
> > > overloaded and always has done the same thing, no point in
> > > indirecting it for show.
> > >
> > > Reviewed-by: Jani Nikula 
> > > Signed-off-by: Dave Airlie 
> > > Signed-off-by: Jani Nikula 
> >
> > This has totally broken snb and ivb machines. Total death ensues
> > somewhere in uncore init after some backtraces fly by.
> > Didn't get any logs out to disk unfortunately. Please revert.
> >
> > Sadly CI is still afraid to report when machines disappear.
> > For the bat report you at least get a list of machines that were awol,
> > but the shard run seems to not even mention that all snbs suddenly
> > vanished.
> >
> > I've said it before and I'll say it again. We really should
> > *not* be loading i915 when the machine boots. That way we'd at least
> > get the machine up and running and can report that loading i915 is the
> > thing that killed it...
> 
> That is frustrating, I've sent a oneline fix that should fix it up.
> hopefully CI will pick it up.
It seems it did (this for ivb, snb only):
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21231/index.html?hosts=snb%7Civb

> 
> Dave.

Re: [Intel-gfx] [PATCH 00/23] i915/display: split and constify vtable (v3)

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Dave 
> Airlie
> Sent: torstai 9. syyskuuta 2021 4.53
> To: intel-gfx@lists.freedesktop.org
> Cc: jani.nik...@linux.intel.com
> Subject: [Intel-gfx] [PATCH 00/23] i915/display: split and constify vtable 
> (v3)
> 
> (v3 just adds some missing ,)
> 
>   Details below, I've taken all the review feedback (thanks Jani).
> I added 3 patches moving to wrappers before refactoring, and one other patch 
> is
> unreviewed (07) but the main comment was wanting the wrappers.
> 
> Jani if you are happy with the final 4 patches can you land this series, I 
> don't think I
> have drm-intel commit rights.
Not right Jani to answer but in my view CI in not healthy at all if looking 
from: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20995/index.html? 
See taints in the boot. 

> 
> v1:
> This is orthogonal to my display ptr refactoring and should probably be 
> applied first.
> 
> The display funcs vtable was a bit of mess, lots of intermixing of internal 
> display
> functionality and interfaces to watermarks/irqs.
> 
> It's also considered not great security practice to leave writeable function 
> pointers
> around for exploits to get into.
> 
> This series attempts to address both problems, first there are a few 
> cleanups, then it
> splits the function table into multiple pieces.
> Some of the splits might be bikesheds but I think we should apply first and 
> merge
> things later if there is good reason.
> 
> The second half converts all the vtables to static const structs, I've used 
> macros in
> some of them to make it less messy, the cdclk one is probably the worst one.
> 
> v2:
> Added some patches adding wrappers around things before refactoring them as
> suggested by Jani.
> Fixed up all struct names as suggested by Jani.
> Added s-o-b lines
> Added commit msgs.
> 
> v3:
> added missing , (Jani)
> 
> Dave.
> 

Re: [Intel-gfx] i915 with Dell XPS 9310

[Saarinen, Jani]

Hi, 
Please report actual bug using instructions: 
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs ?

Br,
Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



> -Original Message-
> From: Intel-gfx  On Behalf Of wi nk
> Sent: perjantai 3. syyskuuta 2021 15.38
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] i915 with Dell XPS 9310
> 
> Hello all,
> 
>I've been following recent kernels on this dell laptop for almost a year 
> now to work
> through some issues with the ath11k module.  I've been experiencing random
> occasional video artifacts for most of that time.  These artifacts would 
> cause the
> i915 module to report some kind of underrun (sorry I don't have those logs any
> longer).  At some point around 5.10 the artifacts turned into full panics 
> that needed a
> reboot instead of some waiting and jiggling.  Kalle reported here:
> http://lists.infradead.org/pipermail/ath11k/2021-August/001451.html
> that there was a commit he could revert to fix it.  I was unable to reproduce 
> that fix
> by reverting it.
> 
> I'm now running 5.14.0 and it seems to have changed behavior again.
> Instead of the machine hard locking (ie: no caps lock even), it seems to 
> recover after
> a bit and then I can see this in dmesg:
> 
> [226387.152234] DMAR: DRHD: handling fault status reg 3 [226387.152244] DMAR:
> [DMA Write NO_PASID] Request device [0x00:0x02.0] fault addr 0xf0afc000 [fault
> reason 0x07] Next page table ptr is invalid [226402.058857] i915 :00:02.0:
> [drm] GPU HANG: ecode 12:0: [226402.058876] i915 :00:02.0: [drm]
> Resetting rcs0 for stopped heartbeat on rcs0 [276353.590922] clocksource:
> timekeeping watchdog on CPU4: hpet retried 2 times before success
> 
> 
> 
> [345312.963065] DMAR: DRHD: handling fault status reg 3 [345312.963077] DMAR:
> [DMA Write NO_PASID] Request device [0x00:0x02.0] fault addr 0xf21ec000 [fault
> reason 0x07] Next page table ptr is invalid [345323.814583] Asynchronous wait 
> on
> fence
> :00:02.0:gnome-shell[2707]:1a15a6 timed out
> (hint:intel_atomic_commit_ready [i915]) [345327.672581] i915 :00:02.0: 
> [drm]
> GPU HANG: ecode 12:1:85db, in signal-desktop [26051] [345327.672606] i915
> :00:02.0: [drm] Resetting rcs0 for stopped heartbeat on rcs0 
> [345327.672656]
> i915 :00:02.0: [drm] signal-desktop[26051] context reset due to GPU hang
> 
> I'm not sure what the DMAR messages are about, I included them in case they're
> relevant.  How can I debug this further?  I'll gladly enable whatever is 
> needed :)
> 
> Thanks!

Re: [Intel-gfx] [PATCH] drm/i915/dp: return proper DPRX link training result

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre 
> Deak
> Sent: maanantai 30. elokuuta 2021 9.45
> To: Ville Syrjälä 
> Cc: Lee, Shawn C ; Almahallawy, Khaled
> ; intel-gfx@lists.freedesktop.org; Chiou, Cooper
> ; Tseng, William 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: return proper DPRX link 
> training result
> 
> On Sat, Aug 21, 2021 at 02:02:03AM +0300, Imre Deak wrote:
> > On Sat, Aug 21, 2021 at 01:20:04AM +0300, Ville Syrjälä wrote:
> > > On Wed, Aug 18, 2021 at 07:17:12PM +0300, Imre Deak wrote:
> > > > On Wed, Aug 18, 2021 at 06:09:43PM +0300, Lee, Shawn C wrote:
> > > > > On Tue, 2021-07-07, Lee Shawn C  wrote:
> > > > > >On Tue, 2021-07-07, Almahallawy, Khaled 
> > > > > >
> wrote:
> > > > > >>I believe Imre's LT fallback:
> > > > > >>https://github.com/ideak/linux/commits/linktraining-fallback-fix  
> > > > > >>and
> Chrome user space fix:
> > > > > >>https://chromium-review.googlesource.com/c/chromium/src/+/3003
> > > > > >>487 should address Chrome concerns for LT failure and LTTPRs
> > > > > >>
> > > > > >
> > > > > >Thanks for comment! The new fallback patch should help on this DPRX
> problem.
> > > > > >One more thing. If driver did not handle DPRX link train failed 
> > > > > >properly.
> > > > > >It would impact link layer compliance test case in below.
> > > > > >
> > > > > >400.3.1.3
> > > > > >400.3.1.4
> > > > > >400.3.1.6
> > > > > >400.3.1.12
> > > > > >400.3.1.13
> > > > > >400.3.1.14
> > > > > >
> > > > > >Best regards,
> > > > > >Shawn
> > > > > >
> > > > >
> > > > > Hi all, before Imre's patch series land on upstream driver. The
> > > > > link train failed handling works for LTTPR only. But DPRX does
> > > > > not. Could you please consider to have this change as temporary 
> > > > > solution?
> Thanks!
> > > >
> > > > I sent already fixing this, see
> > > > https://lore.kernel.org/intel-gfx/20201027133600.3656665-1-imre.de
> > > > a...@intel.com/
> > > >
> > > > but it fell through the cracks. Applied now your patch, thanks.
> > >
> > > We seem to have a tgl that fails consistently at DPRX link training:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/fi-tgl-1115g4.html
> > >
> > > Previously the error went unnoticed.
> >
> > Yea, didn't notice this. Can't see anything obvious, besides that it's
> > a DPCD rev 1.1 monitor, so maybe not compatible with LTTPRs. I follow
> > up if I find something.
> 
> Power cycling the machine and replugging the monitor and Type C dongle and 
> native
> DP cable fixed it. So, it could be a flaky connection (unlikely, because 
> detection
> worked), or the port in a stuck state even across warm-reboots. The latter 
> would
> mean the machine wasn't power cycled for a long time and that's likely 
> because the
> pstore kernel didn't boot (grub failed to load it due to a missing initrd).
Thanks Imre for checking. 

> 
> One possibile root cause is the TypeC PHY getting stuck across warm reboots 
> issue
> (and nothing recovering it besides a power-cycle), that was fixed by
> 151ec347b06a2fb ("drm/i915: Force a TypeC PHY disconnect during
> suspend/shutdown")
> 
> I'll re-check this after more CI testruns.
Ack but now looks indeed green again. 

> 
> > > --
> > > Ville Syrjälä
> > > Intel

Re: [Intel-gfx] [PATCH] drm/i915/dp: return proper DPRX link training result

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville 
> Syrjälä
> Sent: lauantai 21. elokuuta 2021 1.20
> To: Deak, Imre 
> Cc: Lee, Shawn C ; Almahallawy, Khaled
> ; intel-gfx@lists.freedesktop.org; Chiou, Cooper
> ; Tseng, William 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: return proper DPRX link 
> training result
> 
> On Wed, Aug 18, 2021 at 07:17:12PM +0300, Imre Deak wrote:
> > On Wed, Aug 18, 2021 at 06:09:43PM +0300, Lee, Shawn C wrote:
> > > On Tue, 2021-07-07, Lee Shawn C  wrote:
> > > >On Tue, 2021-07-07, Almahallawy, Khaled 
> wrote:
> > > >>I believe Imre's LT fallback:
> > > >>https://github.com/ideak/linux/commits/linktraining-fallback-fix  and 
> > > >>Chrome
> user space fix:
> > > >>https://chromium-review.googlesource.com/c/chromium/src/+/3003487
> > > >>should address Chrome concerns for LT failure and LTTPRs
> > > >>
> > > >
> > > >Thanks for comment! The new fallback patch should help on this DPRX 
> > > >problem.
> > > >One more thing. If driver did not handle DPRX link train failed properly.
> > > >It would impact link layer compliance test case in below.
> > > >
> > > >400.3.1.3
> > > >400.3.1.4
> > > >400.3.1.6
> > > >400.3.1.12
> > > >400.3.1.13
> > > >400.3.1.14
> > > >
> > > >Best regards,
> > > >Shawn
> > > >
> > >
> > > Hi all, before Imre's patch series land on upstream driver. The link
> > > train failed handling works for LTTPR only. But DPRX does not. Could
> > > you please consider to have this change as temporary solution? Thanks!
> >
> > I sent already fixing this, see
> > https://lore.kernel.org/intel-gfx/20201027133600.3656665-1-imre.deak@i
> > ntel.com/
> >
> > but it fell through the cracks. Applied now your patch, thanks.
> 
> We seem to have a tgl that fails consistently at DPRX link training:
> https://intel-gfx-ci.01.org/tree/drm-tip/fi-tgl-1115g4.html
Yes, @Vudum, Lakshminarayana what is gitlab issue for this? 

> 
> Previously the error went unnoticed.
> 
> --
> Ville Syrjälä
> Intel

Re: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant checks in DSC disable

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-gfx  On Behalf Of Vandita
> Kulkarni
> Sent: torstai 3. kesäkuuta 2021 9.54
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani 
> Subject: [Intel-gfx] [PATCH] drm/i915/dsc: Remove redundant checks in DSC 
> disable
> 
> There can be a chance that pre os has enabled DSC and driver's compute config
> would not need dsc to be enabled, in such case if we check on compute config's
> compression state to disable, we might end up in state mismatch.

I assume this fixes real gitlab issue too? 

> 
> Signed-off-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 19cd9531c115..b05a96011d93 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -1161,10 +1161,6 @@ void intel_dsc_disable(const struct intel_crtc_state
> *old_crtc_state)
>   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> 
> - if (!(old_crtc_state->dsc.compression_enable &&
> -   old_crtc_state->bigjoiner))
> - return;
> -
>   intel_de_write(dev_priv, dss_ctl1_reg(old_crtc_state), 0);
>   intel_de_write(dev_priv, dss_ctl2_reg(old_crtc_state), 0);  }
> --
> 2.21.0.5.gaeb582a
> 
> ___
> 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] NVIDIA GPU fallen off the bus after exiting s2idle

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Chris 
> Chiu
> Sent: perjantai 21. toukokuuta 2021 7.02
> To: Rafael J. Wysocki 
> Cc: Brown, Len ; Karol Herbst ; Linux
> PM ; Linux PCI ;
> Westerberg, Mika ; Rafael J. Wysocki
> ; dri-devel ; Bjorn 
> Helgaas
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] NVIDIA GPU fallen off the bus after exiting s2idle
> 
> On Thu, May 6, 2021 at 5:46 PM Rafael J. Wysocki  wrote:
> >
> > On Tue, May 4, 2021 at 10:08 AM Chris Chiu  wrote:
> > >
> > > Hi,
> > > We have some Intel laptops (11th generation CPU) with NVIDIA GPU
> > > suffering the same GPU falling off the bus problem while exiting
> > > s2idle with external display connected. These laptops connect the
> > > external display via the HDMI/DisplayPort on a USB Type-C interfaced
> > > dock. If we enter and exit s2idle with the dock connected, the
> > > NVIDIA GPU (confirmed on 10de:24b6 and 10de:25b8) and the PCIe port
> > > can come back to D0 w/o problem. If we enter the s2idle, disconnect
> > > the dock, then exit the s2idle, both external display and the panel
> > > will remain with no output. The dmesg as follows shows the "nvidia
> :01:00.0:
> > > can't change power state from D3cold to D0 (config space
> > > inaccessible)" due to the following ACPI error [ 154.446781] [
> > > 154.446783] [ 154.446783] Initialized Local Variables for Method
> > > [IPCS]:
> > > [ 154.446784] Local0: 9863e365  Integer
> > > 09C5 [ 154.446790] [ 154.446791] Initialized Arguments
> > > for Method [IPCS]: (7 arguments defined for method invocation) [
> > > 154.446792] Arg0: 25568fbd  Integer 00AC [
> > > 154.446795] Arg1: 9ef30e76  Integer  [
> > > 154.446798] Arg2: fdf820f0  Integer 0010 [
> > > 154.446801] Arg3: 9fc2a088  Integer 0001 [
> > > 154.446804] Arg4: 3a3418f7  Integer 0001 [
> > > 154.446807] Arg5: 20c4b87c  Integer  [
> > > 154.446810] Arg6: 8b965a8a  Integer  [
> > > 154.446813] [ 154.446815] ACPI Error: Aborting method \IPCS due to
> > > previous error
> > > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529) [ 154.446824] ACPI
> > > Error: Aborting method \MCUI due to previous error
> > > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529) [ 154.446829] ACPI
> > > Error: Aborting method \SPCX due to previous error
> > > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529) [ 154.446835] ACPI
> > > Error: Aborting method \_SB.PC00.PGSC due to previous error
> > > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529) [ 154.446841] ACPI
> > > Error: Aborting method \_SB.PC00.PGON due to previous error
> > > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529) [ 154.446846] ACPI
> > > Error: Aborting method \_SB.PC00.PEG1.NPON due to previous error
> > > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529) [ 154.446852] ACPI
> > > Error: Aborting method \_SB.PC00.PEG1.PG01._ON due to previous error
> > > (AE_AML_LOOP_TIMEOUT) (20200925/psparse-529) [ 154.446860] acpi
> > > device:02: Failed to change power state to D0 [ 154.690760] video
> > > LNXVIDEO:00: Cannot transition to power state D0 for parent in
> > > (unknown)
> >
> > If I were to guess, I would say that AML tries to access memory that
> > is not accessible while suspended, probably PCI config space.
> >
> > > The IPCS is the last function called from \_SB.PC00.PEG1.PG01._ON
> > > which we expect it to prepare everything before bringing back the
> > > NVIDIA GPU but it's stuck in the infinite loop as described below.
> > > Please refer to
> > > https://gist.github.com/mschiu77/fa4f5a97297749d0d66fe60c1d421c44
> > > for the full DSDT.dsl.
> >
> > The DSDT alone may not be sufficient.
> >
> > Can you please create a bug entry at bugzilla.kernel.org for this
> > issue and attach the full output of acpidump from one of the affected
> > machines to it?  And please let me know the number of the bug.
> >
> > Also please attach the output of dmesg including a suspend-resume
> > cycle including dock disconnection while suspended and the ACPI
> > messages quoted below.
> >
> > >While (One)
> > > {
> > > If ((!IBSY || (IERR == One)))
> > > {
> > > Break
> > > }
> > >
> > > If ((Local0 > TMOV))
> > > {
> > > RPKG [Zero] = 0x03
> > > Return (RPKG) /* \IPCS.RPKG */
> > > }
> > >
> > > Sleep (One)
> > > Local0++
> > > }
> > >
> > > And the upstream PCIe port of NVIDIA seems to become inaccessible
> > > due to the messages as follows.
> > > [ 292.746508] pcieport :00:01.0: waiting 100 ms for downstream
> > > link, after activation [ 292.882296] pci :01:00.0: waiting
> > > additional 100 ms to become accessible [ 316.876997] pci
> > > :01:00.0: can't change power state from 

Re: [Intel-gfx] i915 flickering with 5.12.X kernels

[Saarinen, Jani]

See: https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs

From: Intel-gfx  On Behalf Of Risto 
Paavola
Sent: torstai 6. toukokuuta 2021 8.20
To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo 
; airl...@linux.ie; dan...@ffwll.ch; 
intel-gfx@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org; dri-de...@lists.freedesktop.org
Subject: Re: [Intel-gfx] i915 flickering with 5.12.X kernels

Hello again,

I am trying to repost this message with one smaller video since I got many 
error messages about oversized attachments.

BR,
-Risto

to 6. toukok. 2021 klo 7.57 Risto Paavola 
(risto.paav...@gmail.com) kirjoitti:
Hello!

I noticed that when I compiled 5.12 and 5.12.1 kernels my display started to 
flicker maybe in once a second.

With kernel 5.11.16 or below that there is no flickering. I'm using Gentoo 
testing and all other packages remained the same when I switched between 
5.11.16 and 5.12.X.

I have attached a couple of videos to this email to demonstrate the problem 
with kernel version 5.12.1. Sorry about the file sizes.

These are the errors I am seeing in journal:
May 06 07:49:24 nyrkki kernel: ACPI Error: Needed type [Reference], found 
[Integer] 90bcaee8 (20210105/exresop-66)
May 06 07:49:24 nyrkki kernel: ACPI Error: AE_AML_OPERAND_TYPE, While resolving 
operands for [OpcodeName unavailable] (20210105/dswexec-431)
May 06 07:49:24 nyrkki kernel: ACPI Error: Aborting method \_PR.CPU0._PDC due 
to previous error (AE_AML_OPERAND_TYPE) (20210105/psparse-529)
May 06 07:49:47 nyrkki kernel: DMAR: DRHD: handling fault status reg 2
May 06 07:49:47 nyrkki kernel: DMAR: [DMA Write] Request device [00:02.0] PASID 
 fault addr c7fe5000 [fault reason 05] PTE Write access is not set
May 06 07:49:47 nyrkki kernel: Bluetooth: hci0: unexpected event for opcode 
0xfc2f
May 06 07:49:49 nyrkki sddm-helper[2258]: gkr-pam: unable to locate daemon 
control file
May 06 07:49:52 nyrkki kwin_x11[2322]: kwin_xkbcommon: XKB: couldn't find a 
Compose file for locale "en_FI.UTF-8"
May 06 07:49:58 nyrkki systemd-coredump[4290]: [] Process 2376 (baloo_file) of 
user 1000 dumped core.

I have noticed that people were having these kinds of issues a couple of years 
ago with pstates and/or psr. Maybe this bug in the latest kernel is also 
related to them?

Hardware:
Lenovo Thinkpad X1 Carbon, gen 2
Latest BIOS 1.40
Intel(R) Core(TM) i7-4550U CPU with Intel HD Graphics 5000
14.0" WQHD (2560x1440), 300nit, IPS

Best Regards,
-Risto


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen12: Add display render clear color decompression support (rev5)

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Imre 
> Deak
> Sent: torstai 21. tammikuuta 2021 14.57
> To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana
> 
> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen12: Add display 
> render
> clear color decompression support (rev5)
> 
> Hi Lakshmi,
> 
> On Wed, Jan 20, 2021 at 11:23:24PM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915/gen12: Add display render clear color decompression support
> (rev5)
> > URL   : https://patchwork.freedesktop.org/series/85877/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_9650 -> Patchwork_19433
> > 
> >
> > Summary
> > ---
> >
> >   **FAILURE**
> >
> >   Serious unknown changes coming with Patchwork_19433 absolutely need to be
> >   verified manually.
> >
> >   If you think the reported changes have nothing to do with the changes
> >   introduced in Patchwork_19433, please notify your bug team to allow them
> >   to document this new failure mode, which will reduce false positives in 
> > CI.
> >
> >   External URL:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19433/index.html
> >
> > Possible new issues
> > ---
> >
> >   Here are the unknown changes that may have been introduced in
> Patchwork_19433:
> >
> > ### IGT changes ###
> >
> >  Possible regressions 
> >
> >   * igt@i915_selftest@live@hangcheck:
> > - fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2]
> >[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9650/fi-bsw-
> nick/igt@i915_selftest@l...@hangcheck.html
> >[2]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19433/fi-bsw-nick/i
> > gt@i915_selftest@l...@hangcheck.html
> 
> The above is on an unrelated platform, could you check if there's a related 
> ticket for
> it already?
Possibly this: https://gitlab.freedesktop.org/drm/intel/-/issues/2639 ? 

> 
> Thanks,
> Imre
> 
> >
> >
> > Known issues
> > 
> >
> >   Here are the changes found in Patchwork_19433 that come from known issues:
> >
> > ### IGT changes ###
> >
> >  Issues hit 
> >
> >   * igt@amdgpu/amd_basic@memory-alloc:
> > - fi-tgl-y:   NOTRUN -> [SKIP][3] ([fdo#109315] / [i915#2575]) 
> > +2 similar
> issues
> >[3]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19433/fi-tgl-y/igt@
> > amdgpu/amd_ba...@memory-alloc.html
> >
> >   * igt@amdgpu/amd_prime@i915-to-amd:
> > - fi-snb-2520m:   NOTRUN -> [SKIP][4] ([fdo#109271]) +17 similar 
> > issues
> >[4]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19433/fi-snb-2520m/
> > igt@amdgpu/amd_pr...@i915-to-amd.html
> >
> >   * igt@gem_exec_suspend@basic-s3:
> > - fi-tgl-y:   [PASS][5] -> [DMESG-WARN][6] ([i915#2411] / 
> > [i915#402])
> >[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9650/fi-tgl-
> y/igt@gem_exec_susp...@basic-s3.html
> >[6]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19433/fi-tgl-y/igt@
> > gem_exec_susp...@basic-s3.html
> >
> >   * igt@kms_chamelium@hdmi-crc-fast:
> > - fi-kbl-7500u:   [PASS][7] -> [DMESG-WARN][8] ([i915#2868])
> >[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9650/fi-kbl-
> 7500u/igt@kms_chamel...@hdmi-crc-fast.html
> >[8]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19433/fi-kbl-7500u/
> > igt@kms_chamel...@hdmi-crc-fast.html
> >
> >   * igt@prime_self_import@basic-with_one_bo:
> > - fi-tgl-y:   [PASS][9] -> [DMESG-WARN][10] ([i915#402])
> >[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9650/fi-tgl-
> y/igt@prime_self_import@basic-with_one_bo.html
> >[10]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19433/fi-tgl-y/igt@
> > prime_self_import@basic-with_one_bo.html
> >
> >   * igt@runner@aborted:
> > - fi-bsw-nick:NOTRUN -> [FAIL][11] ([i915#1436])
> >[11]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19433/fi-bsw-nick/i
> > gt@run...@aborted.html
> >
> >
> >  Possible fixes 
> >
> >   * igt@i915_selftest@live@hangcheck:
> > - fi-snb-2520m:   [INCOMPLETE][12] -> [PASS][13]
> >[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9650/fi-snb-
> 2520m/igt@i915_selftest@l...@hangcheck.html
> >[13]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19433/fi-snb-2520m/
> > igt@i915_selftest@l...@hangcheck.html
> >
> >   * igt@prime_self_import@basic-with_one_bo_two_files:
> > - fi-tgl-y:   [DMESG-WARN][14] ([i915#402]) -> [PASS][15]
> >[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9650/fi-tgl-
> y/igt@prime_self_import@basic-with_one_bo_two_files.html
> >[15]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19433/fi-tgl-y/igt@
> > prime_self_import@basic-with_one_bo_two_files.html
> >
> >
> >   {name}: This element is suppressed. This means it is ignored when 
> > computing
> >   the status of the 

Re: [Intel-gfx] [v6 0/2] Re-enable FBC on TGL

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-gfx  On Behalf Of Chris 
> Wilson
> Sent: perjantai 4. joulukuuta 2020 13.55
> To: Shankar, Uma ; Souza, Jose ;
> intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [v6 0/2] Re-enable FBC on TGL
> 
> Quoting Shankar, Uma (2020-12-02 13:09:34)
> >
> >
> > > -Original Message-
> > > From: Souza, Jose 
> > > Sent: Wednesday, December 2, 2020 12:01 AM
> > > To: Shankar, Uma ;
> > > intel-gfx@lists.freedesktop.org
> > > Cc: ville.syrj...@linux.intel.com
> > > Subject: Re: [v6 0/2] Re-enable FBC on TGL
> > >
> > > LGTM, thanks for doing the changes.
> >
> > Pushed the series to dinq.
> > Thanks Jose and Ville for the review and feedback.
> 
> And CI is reporting pipe underruns again, that seem to date back to 
> re-enabling FBC.
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9441/fi-tgl-
> y/igt@gem_exec_gttf...@basic.html
This still old step/ifwi. 

> -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] [CI 00/15] Rebased remaining big joiner series

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Navare,
> Manasi
> Sent: torstai 19. marraskuuta 2020 7.58
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson 
> Subject: Re: [Intel-gfx] [CI 00/15] Rebased remaining big joiner series
> 
> On Wed, Nov 18, 2020 at 11:49:25AM -0800, Navare, Manasi wrote:
> > Series pushed to dinq
> >
> > Manasi
> 
> By Chris Wilson:
> 
> Oops on boot:
> 
> <1>[   44.315382] BUG: unable to handle page fault for address: 
> c90049e02100
> <1>[   44.315422] #PF: supervisor read access in kernel mode
> <1>[   44.315442] #PF: error_code(0x) - not-present page
> <6>[   44.315462] PGD 10067 P4D 10067 PUD 0
> <4>[   44.315497] Oops:  [#1] PREEMPT SMP NOPTI
> <4>[   44.315522] CPU: 7 PID: 276 Comm: systemd-udevd Tainted: G U
> 5.10.0-rc3-CI-CI_DRM_9355+ #1
> <4>[   44.315552] Hardware name: Intel Corporation Tiger Lake Client
> Platform/TigerLake Y LPDDR4x T4 Crb, BIOS TGLSFWI1.R00.2527.A03.2001170231
> 01/17/2020
> <4>[   44.315981] RIP: 0010:gen12_fwtable_read32+0x6f/0x2f0 [i915]
> <4>[   44.316016] Code: c6 48 8b 43 08 8b b0 98 0d 00 00 85 f6 0f 85 53 01 00 
> 00 89
> ee 48 89 df e8 fe a6 ff ff 85 c0 0f 85 bc 00 00 00 89 e8 48 03 03 <44> 8b 38 
> 48 8b 43
> 08 8b 90 98 0d 00 00 85 d2 0f 85 a8 01 00 00 4c
> 16893]  hsw_crtc_enable+0x188/0x780 [i915]
> <4>[   44.317423]  intel_enable_crtc+0x56/0x70 [i915]
> <4>[   44.317931]  skl_commit_modeset_enables+0x34a/0x530 [i915]
> <4>[   44.318444]  intel_atomic_commit_tail+0x3a0/0x1330 [i915]
> <4>[   44.318488]  ? queue_work_on+0x5e/0x70
> <4>[   44.318965]  intel_atomic_commit+0x371/0x3f0 [i915]
> <4>[   44.319458]  intel_initial_commit+0x156/0x1e0 [i915]
> <4>[   44.319949]  intel_modeset_init_nogem+0xb59/0x1c00 [i915]
> <4>[   44.320336]  i915_driver_probe+0x79c/0xd90 [i915]
> <4>[   44.320374]  ? __pm_runtime_resume+0x4f/0x80
> <4>[   44.320741]  i915_pci_probe+0x43/0x1d0 [i915]
> <4>[   44.320772]  ? _raw_spin_unlock_irqrestore+0x2f/0x50
> <4>[   44.320804]  pci_device_probe+0x9e/0x110
> <4>[   44.320830]  really_probe+0x1c4/0x430
> <4>[   44.320852]  driver_probe_device+0xd9/0x140
> <4>[   44.320875]  device_driver_attach+0x4a/0x50
> <4>[   44.320897]  __driver_attach+0x83/0x140
> <4>[   44.320917]  ? device_driver_attach+0x50/0x50
> <4>[   44.320938]  ? device_driver_attach+0x50/0x50
> 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 
> 8b 0d 1f
> f6 2c 00 f7 d8 64 89 01 48
> <4>[   44.321749] RSP: 002b:7ffda8ea9358 EFLAGS: 0246 ORIG_RAX:
> 0139
> <4>[   44.321782] RAX: ffda RBX: 56004d10ffc0 RCX:
> 7fad885f5839
> <4>[   44.321808] RDX:  RSI: 56004d0f5490 RDI:
> 000f
> <4>[   44.321834] RBP: 56004d0f5490 R08:  R09:
> 7ffda8ea9470
> <4>[   44.321859] R10: 000f R11: 0246 R12:
> 
> <4>[   44.321884] R13: 56004d0f20c0 R14: 0002 R15:
> 
> <4>[   44.321921] Modules linked in: i915(+) mei_hdcp x86_pkg_temp_thermal
> coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel snd_intel_dspcfg
> ghash_clmulni_intel snd_hda_codec cdc_ether snd_hwdep usbnet snd_hda_core mii
> e1000e ptp snd_pcm pps_core mei_me mei prime_numbers intel_lpss_pci(+)
> <4>[   44.322105] CR2: c90049e02100
> <4>[   44.322130] ---[ end trace 87c6ef683da5ac08 ]---
> 
> 
> But Chris, we havent seen this on CI nor in our testing.
It was at least on 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18904/index.html?testfilter=boot
 

> 
> Manasi
> 
> >
> > On Tue, Nov 17, 2020 at 11:47:03AM -0800, Manasi Navare wrote:
> > >
> > >
> > > Maarten Lankhorst (4):
> > >   drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
> > >   drm/i915: Try to make bigjoiner work in atomic check
> > >   drm/i915: Add bigjoiner aware plane clipping checks
> > >   drm/i915: Add debugfs dumping for bigjoiner, v3.
> > >
> > > Manasi Navare (3):
> > >   drm/i915/dp: Modify VDSC helpers to configure DSC for Bigjoiner slave
> > >   drm/i915/dp: Master/Slave enable/disable sequence for bigjoiner
> > >   drm/i915: HW state readout for Bigjoiner case
> > >
> > > Ville Syrjälä (8):
> > >   drm/i915: Copy the plane hw state directly for Y planes
> > >   drm/i915: Add crtcs affected by bigjoiner to the state
> > >   drm/i915: Add planes affected by bigjoiner to the state
> > >   drm/i915: Get the uapi state from the correct plane when bigjoiner is
> > > used
> > >   drm/i915: Disable legacy cursor fastpath for bigjoiner
> > >   drm/i915: Fix cursor src/dst rectangle with bigjoiner
> > >   drm/i915: Add bigjoiner state dump
> > >   drm/i915: Enable bigjoiner
> > >
> > >  drivers/gpu/drm/i915/display/icl_dsi.c|   2 -
> > >  .../gpu/drm/i915/display/intel_atomic_plane.c | 131 +++-
> > >  .../gpu/drm/i915/display/intel_atomic_plane.h |   9 +-
> > >  drivers/gpu/drm/i915/display/intel_ddi.c  |  69 +-
> > >  

Re: [Intel-gfx] USB-C DP mode problem on linux

[Saarinen, Jani]

Hi,
What is exact gitlab issue for this, can you send link? 

> -Original Message-
> From: Intel-gfx  On Behalf Of 
> Andrzej Kre
> Sent: perjantai 13. marraskuuta 2020 22.28
> To: Deak, Imre 
> Cc: intel-gfx@lists.freedesktop.org; Heikki Krogerus
> 
> Subject: Re: [Intel-gfx] USB-C DP mode problem on linux
> 
> Got it.
> 
> Thank You for quick replying. Due to coronavirus I was not able to issue a 
> ticket
> quickly . But I created it.
> 
> 
> Best Regards,
> 
> 
> wt., 20 paź 2020 o 16:25 Imre Deak   > napisał(a):
> 
> 
>   Hi,
> 
>   On Mon, Oct 19, 2020 at 05:24:59PM +0300, Heikki Krogerus wrote:
>   > Hi Andrzej,
>   >
>   > On Sat, Oct 17, 2020 at 01:34:54PM +0200, Andrzej Kre wrote:
>   > > Hi,
>   > >
>   > > I know that You were involved in working on USB-C DP drivers.
>   > > You are my last chance to resolve my issue.
>   > >
>   > > On my HP laptop I have Intel UHD Graphics 620.
>   > > When I'm connecting my 4K monitor to Display Port. It is assigning 
> to
>   > > DP-2-2 socket and  I have full 3840x2160 with 60.00Hz
>   > > But, when I'm connecting the same monitor to the USB-C port, then 
> it is
>   > > connecting to the DP-1 socket and the maximum that it can achieve is
>   > > 3840x2160 with only 30.00Hz.
>   > > But I'm making some trick: I'm connecting the same monitor through
> HDMI, so
>   > > it is connecting to DP-1 socket, and simultaneously I'm connecting 
> USB-
> C,
>   > > and now USB-C is connecting to DP-2-2 socket (because DP-1 is 
> occupied
> by
>   > > HDMI) and I can have full 4K with 60Hz.
>   > > Please, help me, how to force USB-C to connect always to DP-2-2
> socket?
>   > > Or do You know maybe where is the problem?
>   >
>   > Unfortunately we have no control over the mux in the operating system
>   > on Skylakes, at least in USB subsystem. It all happens in firmware.
>   > Maybe graphics side can do something.
>   >
>   > Adding Jani, Imre, Ville and the Intel GFX list.
> 
>   On SKL/KBL the USB-C -> native DP/HDMI conversion is done by an off-CPU
>   chip and the display driver doesn't have a way either to affect the
>   muxing.
> 
>   Not sure why things work on DP-2 and not on DP-1, there is no port
>   specific limits on the CPU side that would explain this. There is a link
>   training failure in the log, so would be good to see more details on
>   that. Could you file a ticket at
>   https://gitlab.freedesktop.org/drm/intel/-/issues
>   providing a full log booting with drm.debug=0x1e for the working and
>   non-working cases?
> 
>   Thanks,
>   Imre
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI on ASUS GL552VW

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Kai-Heng Feng 
> Sent: tiistai 13. lokakuuta 2020 15.18
> To: Saarinen, Jani 
> Cc: Ville Syrjälä ; intel-gfx  g...@lists.freedesktop.org>; Runyan, Arthur J 
> Subject: Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143"
> breaks HDMI on ASUS GL552VW
> 
> 
> 
> > On Oct 13, 2020, at 19:50, Saarinen, Jani  wrote:
> >
> > Hi,
> >> -Original Message-
> >> From: Intel-gfx  On Behalf
> >> Of Ville Syrjälä
> >> Sent: tiistai 13. lokakuuta 2020 14.16
> >> To: Kai-Heng Feng 
> >> Cc: intel-gfx ; Runyan, Arthur J
> >> 
> >> Subject: Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a
> #1143"
> >> breaks HDMI on ASUS GL552VW
> >>
> >> On Tue, Oct 13, 2020 at 01:20:35PM +0800, Kai-Heng Feng wrote:
> >>>
> >>>
> >>>> On Sep 3, 2020, at 14:26, Kai-Heng Feng
> >>>> 
> >> wrote:
> >>>>
> >>>>
> >>>>
> >>>>> On Aug 26, 2020, at 21:05, Ville Syrjälä
> >>>>> 
> >> wrote:
> >>>>>
> >>>>> On Wed, Aug 26, 2020 at 12:40:15PM +0800, Kai-Heng Feng wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>>> On Aug 25, 2020, at 02:46, Runyan, Arthur J
> >>  wrote:
> >>>>>>>
> >>>>>>> I remember some strangeness about the blnclegdisbl.  I'll see if
> >>>>>>> I can dig
> >> up some more.
> >>>>>>
> >>>>>>
> >>>>>> The register read can be found at [1] and [2].
> >>>>>>
> >>>>>> [1]
> >>>>>>
> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comme
> >>>>>> nts/119 [2]
> >>>>>>
> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comme
> >>>>>> nts/120
> >>>>>
> >>>>> Looks like it's using the 400mV/0dB setting. Can we get the same
> >>>>> dumps with the driver loaded just to confirm whether we're using
> >>>>> different settings?
> >>>>>
> >>>>> Also a dump of /sys/kernel/debug/dri/0/i915_vbt would be good to
> >>>>> have.
> >>>>
> >>>>
> >>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comment
> >>>> s/124
> >>>>
> >>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comment
> >>>> s/125
> >>>>
> >>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comment
> >>>> s/126
> >>>
> >>> A gentle ping...
> >>
> >> I cooked up some hacks for you to try:
> >> git://github.com/vsyrjala/linux.git skl_vswing_wa_hacks
> >>
> >> An upstream bug report would probably be a good idea so that the
> >> communication doesn't have to go through a middle man over email...
> > Agree, please make gitlab issue on this.
> 
> It was filed two months ago: 
> https://gitlab.freedesktop.org/drm/intel/-/issues/2181
Sigh, thanks. 

> 
> 
> >
> >>
> >>>
> >>>>
> >>>> Kai-Heng
> >>>>
> >>>>>
> >>>>>>
> >>>>>> Kai-Heng
> >>>>>>
> >>>>>>>
> >>>>>>> -Original Message-
> >>>>>>> From: Ville Syrjälä 
> >>>>>>> Sent: Monday, August 24, 2020 11:05 AM
> >>>>>>> To: Kai-Heng Feng 
> >>>>>>> Cc: Runyan, Arthur J ; Vivi, Rodrigo
> >>>>>>> ; intel-gfx
> >>>>>>> 
> >>>>>>> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143"
> >>>>>>> breaks HDMI on ASUS GL552VW
> >>>>>>>
> >>>>>>> On Mon, Aug 17, 2020 at 02:17:49PM +0800, Kai-Heng Feng wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Aug 17, 2020, at 00:22, Runyan, Arthur J
> >>  wrote:
> >>>>>>>>>
> >>>>>>>>> You'll need to read out the DDI_BUF_TRANS_* and
> >> DISPIO_CR_TX_BMU_CR0 registers at boot before i9

Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143" breaks HDMI on ASUS GL552VW

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjälä
> Sent: tiistai 13. lokakuuta 2020 14.16
> To: Kai-Heng Feng 
> Cc: intel-gfx ; Runyan, Arthur J
> 
> Subject: Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143"
> breaks HDMI on ASUS GL552VW
> 
> On Tue, Oct 13, 2020 at 01:20:35PM +0800, Kai-Heng Feng wrote:
> >
> >
> > > On Sep 3, 2020, at 14:26, Kai-Heng Feng 
> wrote:
> > >
> > >
> > >
> > >> On Aug 26, 2020, at 21:05, Ville Syrjälä 
> wrote:
> > >>
> > >> On Wed, Aug 26, 2020 at 12:40:15PM +0800, Kai-Heng Feng wrote:
> > >>> Hi,
> > >>>
> >  On Aug 25, 2020, at 02:46, Runyan, Arthur J
>  wrote:
> > 
> >  I remember some strangeness about the blnclegdisbl.  I'll see if I can 
> >  dig
> up some more.
> > >>>
> > >>>
> > >>> The register read can be found at [1] and [2].
> > >>>
> > >>> [1]
> > >>>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comme
> > >>> nts/119 [2]
> > >>>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comme
> > >>> nts/120
> > >>
> > >> Looks like it's using the 400mV/0dB setting. Can we get the same
> > >> dumps with the driver loaded just to confirm whether we're using
> > >> different settings?
> > >>
> > >> Also a dump of /sys/kernel/debug/dri/0/i915_vbt would be good to
> > >> have.
> > >
> > >
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comment
> > > s/124
> > >
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comment
> > > s/125
> > >
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comment
> > > s/126
> >
> > A gentle ping...
> 
> I cooked up some hacks for you to try:
> git://github.com/vsyrjala/linux.git skl_vswing_wa_hacks
> 
> An upstream bug report would probably be a good idea so that the
> communication doesn't have to go through a middle man over email...
Agree, please make gitlab issue on this. 

> 
> >
> > >
> > > Kai-Heng
> > >
> > >>
> > >>>
> > >>> Kai-Heng
> > >>>
> > 
> >  -Original Message-
> >  From: Ville Syrjälä 
> >  Sent: Monday, August 24, 2020 11:05 AM
> >  To: Kai-Heng Feng 
> >  Cc: Runyan, Arthur J ; Vivi, Rodrigo
> >  ; intel-gfx
> >  
> >  Subject: Re: [Regression] "drm/i915: Implement display w/a #1143"
> >  breaks HDMI on ASUS GL552VW
> > 
> >  On Mon, Aug 17, 2020 at 02:17:49PM +0800, Kai-Heng Feng wrote:
> > >
> > >
> > >> On Aug 17, 2020, at 00:22, Runyan, Arthur J
>  wrote:
> > >>
> > >> You'll need to read out the DDI_BUF_TRANS_* and
> DISPIO_CR_TX_BMU_CR0 registers at boot before i915 programs them and
> compare with what driver programs.
> > >> Rodrigo can probably show you how.
> > >
> > > Right, I'll wait for a patch then :)
> > 
> >  To grab the BIOS reg values we just have to make sure the driver 
> >  doesn't
> load. Eg. pass something like "modprobe.blacklist=i915,snd_hda_intel 3" to the
> kernel cmdline (+ whatever other magic ubuntu might require). Confirm with
> something like "lsmod | grep i915" to make sure the driver didn't sneak in
> despite our best efforts.
> > 
> >  Then we can dump the registers with intel_reg from igt-gpu-tools:
> >  intel_reg read --count 20 0x64E00 0x64E60 0x64EC0 0x64F20 0x64F80
> >  intel_reg read 0x64000 0x64100 0x64200 0x64300 0x64400 0x6C00C
> > 
> >  The only somewhat suspicious thing I noticed is that we treat
> DISPIO_CR_TX_BMU_CR0:tx_blnclegdisbl as a bitmask (bit 23 -> DDI A, bit 24 ->
> DDI B, etc.) whereas the spec seems to be saying that we should just zero out 
> all
> the bits of tx_blnclegdisbl when any DDI needs iboost. Art, is our 
> interpretation
> of the bits correct or just a fairy tale?
> > 
> > >
> > > Kai-Heng
> > >
> > >>
> > >> -Original Message-
> > >> From: Kai-Heng Feng 
> > >> Sent: Thursday, August 13, 2020 10:14 PM
> > >> To: Runyan, Arthur J 
> > >> Cc: Vivi, Rodrigo ; Ville Syrjälä
> > >> ; intel-gfx
> > >> 
> > >> Subject: Re: [Regression] "drm/i915: Implement display w/a #1143"
> > >> breaks HDMI on ASUS GL552VW
> > >>
> > >> Hi,
> > >>
> > >>> On Aug 14, 2020, at 01:56, Runyan, Arthur J
>  wrote:
> > >>>
> > >>> The workaround is freeing up stuck vswing values to let new vswing
> programming kick in.  Maybe the new vswing values are wrong.
> > >>> Try checking the vswing that driver programs against what
> BIOS/GOP programs.
> > >>
> > >> Do you mean to print out value of I915_READ()?
> > >> val = I915_READ(CHICKEN_TRANS(transcoder));
> > >>
> > >> Kai-Heng
> > >>
> > >>>
> > >>> -Original Message-
> > >>> From: Vivi, Rodrigo 
> > >>> Sent: Thursday, August 13, 2020 9:50 AM
> > >>> To: Kai-Heng Feng ; Runyan,
> > >>> Arthur J 
> > >>> Cc: Ville Syrjälä ; intel-gfx
> > >>> 
> > >>> Subject: Re: [Regression] "drm/i915: Implement display w/a 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Update to GuC v49

[Saarinen, Jani]

+ Tomi

> -Original Message-
> From: John Harrison 
> Sent: torstai 17. syyskuuta 2020 4.23
> To: intel-gfx@lists.freedesktop.org; Latvala, Petri ;
> Saarinen, Jani ; Szwichtenberg, Radoslaw
> 
> Subject: Re: ✗ Fi.CI.BAT: failure for drm/i915/guc: Update to GuC v49
> 
> Hello,
> 
> The failures below all appear to be because the new GuC firmware was not 
> found on
> the test system.
> 
> My understanding is that all we need to do to get the CI system to update 
> with new
> firmwares is to push the firmware to a branch on the FDO drm-firmware repo and
> then send a pull request to this mailing list. That was done yesterday.
> 
> Is there some other step we need to do? Or do I just need to wait longer 
> between
> the PR and sending the patches?
> 
> John.
> 
> 
> On 9/16/2020 11:35, Patchwork wrote:
> 
> 
>   Patch Details
> Series:drm/i915/guc: Update to GuC v49
> URL:   https://patchwork.freedesktop.org/series/81761/
> State: failure
> Details:   
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18516/index.html
> 
>   CI Bug Log - changes from CI_DRM_9019 -> Patchwork_18516
> 
> 
>   Summary
> 
> 
>   FAILURE
> 
>   Serious unknown changes coming with Patchwork_18516 absolutely need to
> be
>   verified manually.
> 
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_18516, please notify your bug team to allow them
>   to document this new failure mode, which will reduce false positives in 
> CI.
> 
>   External URL: https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_18516/index.html
> 
> 
>   Possible new issues
> 
> 
>   Here are the unknown changes that may have been introduced in
> Patchwork_18516:
> 
> 
>   IGT changes
> 
> 
>   Possible regressions
> 
> 
>   *   igt@gem_huc_copy@huc-copy:
> 
>   *   fi-cfl-guc: PASS <https://intel-gfx-ci.01.org/tree/drm-
> tip/CI_DRM_9019/fi-cfl-guc/igt@gem_huc_c...@huc-copy.html>  -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18516/fi-cfl-
> guc/igt@gem_huc_c...@huc-copy.html>
> 
>   *   fi-kbl-guc: PASS <https://intel-gfx-ci.01.org/tree/drm-
> tip/CI_DRM_9019/fi-kbl-guc/igt@gem_huc_c...@huc-copy.html>  -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18516/fi-kbl-
> guc/igt@gem_huc_c...@huc-copy.html>
> 
>   *   fi-skl-guc: PASS <https://intel-gfx-ci.01.org/tree/drm-
> tip/CI_DRM_9019/fi-skl-guc/igt@gem_huc_c...@huc-copy.html>  -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18516/fi-skl-
> guc/igt@gem_huc_c...@huc-copy.html>
> 
> 
>   Warnings
> 
> 
>   *   igt@gem_huc_copy@huc-copy:
> 
>   *   fi-cml-u2: SKIP <https://intel-gfx-ci.01.org/tree/drm-
> tip/CI_DRM_9019/fi-cml-u2/igt@gem_huc_c...@huc-copy.html>  (i915#2190
> <https://gitlab.freedesktop.org/drm/intel/issues/2190> ) -> SKIP 
> <https://intel-gfx-
> ci.01.org/tree/drm-tip/Patchwork_18516/fi-cml-u2/igt@gem_huc_copy@huc-
> copy.html>
> 
>   *   fi-cml-s: SKIP <https://intel-gfx-ci.01.org/tree/drm-
> tip/CI_DRM_9019/fi-cml-s/igt@gem_huc_c...@huc-copy.html>  (i915#2190
> <https://gitlab.freedesktop.org/drm/intel/issues/2190> ) -> SKIP 
> <https://intel-gfx-
> ci.01.org/tree/drm-tip/Patchwork_18516/fi-cml-s/igt@gem_huc_copy@huc-
> copy.html>
> 
>   *   fi-icl-y: SKIP <https://intel-gfx-ci.01.org/tree/drm-
> tip/CI_DRM_9019/fi-icl-y/igt@gem_huc_c...@huc-copy.html>  (i915#2190
> <https://gitlab.freedesktop.org/drm/intel/issues/2190> ) -> FAIL 
> <https://intel-gfx-
> ci.01.org/tree/drm-tip/Patchwork_18516/fi-icl-y/igt@gem_huc_copy@huc-
> copy.html>
> 
>   *   fi-icl-u2: SKIP <https://intel-gfx-ci.01.org/tree/drm-
> tip/CI_DRM_9019/fi-icl-u2/igt@gem_huc_c...@huc-copy.html>  (i915#2190
> <https://gitlab.freedesktop.org/drm/intel/issues/2190> ) -> FAIL 
> <https://intel-gfx-
> ci.01.org/tree/drm-tip/Patchwork_18516/fi-icl-u2/igt@gem_huc_copy@huc-
> copy.html>
> 
> 
>   Suppressed
> 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   *   igt@gem_huc_copy@huc-copy:
> 
>   *   {fi-ehl-1}: SKIP <https://intel-gfx-ci.01.org/tree/drm-
> tip/CI_DRM_9019/fi-ehl-1/igt@gem_huc_c...@huc-copy.html>  (i915#2190
> <https://gitlab.freedesktop.org/drm/intel/issues/2190>

Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to <64usec

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Ville Syrjälä 
> Sent: perjantai 26. kesäkuuta 2020 17.09
> To: Saarinen, Jani 
> Cc: Lisovskiy, Stanislav ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to <64usec
> 
> On Fri, Jun 26, 2020 at 02:03:23PM +, Saarinen, Jani wrote:
> > Hi,
> >
> > > -Original Message-
> > > From: Intel-gfx  On Behalf
> > > Of Ville Syrjälä
> > > Sent: perjantai 26. kesäkuuta 2020 16.47
> > > To: Lisovskiy, Stanislav 
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to
> > > <64usec
> > >
> > > On Fri, Jun 26, 2020 at 12:16:06PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Thu, Jun 25, 2020 at 11:00:03PM +0300, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä 
> > > > >
> > > > > The linetime watermark is a 9 bit value, which gives us a
> > > > > maximum linetime of just below 64 usec. If the linetime exceeds
> > > > > that value we currently just discard the high bits and program
> > > > > the rest into the register, which angers the state checker.
> > > > >
> > > > > To avoid that let's just clamp the value to the max. I believe
> > > > > it should be perfectly fine to program a smaller linetime wm
> > > > > than strictly required, just means the hardware may fetch data
> > > > > sooner than strictly needed. We are further reassured by the
> > > > > fact that with DRRS the spec tells us to program the smaller of
> > > > > the two linetimes corresponding to the two refresh rates.
> > > > >
> > > > > Cc: Stanislav Lisovskiy 
> > > > > Signed-off-by: Ville Syrjälä 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/display/intel_display.c | 18
> > > > > --
> > > > >  1 file changed, 12 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > index a11bb675f9b3..d486d675166f 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > @@ -12581,12 +12581,15 @@ static u16 hsw_linetime_wm(const
> > > > > struct intel_crtc_state *crtc_state)  {
> > > > >   const struct drm_display_mode *adjusted_mode =
> > > > >   _state->hw.adjusted_mode;
> > > > > + int linetime_wm;
> > > > >
> > > > >   if (!crtc_state->hw.enable)
> > > > >   return 0;
> > > > >
> > > > > - return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 *
> > > 8,
> > > > > -  adjusted_mode-
> > > >crtc_clock);
> > > > > + linetime_wm = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal *
> > > 1000 * 8,
> > > > > +
> > >   adjusted_mode->crtc_clock);
> > > > > +
> > > > > + return min(linetime_wm, 0x1ff);
> > > >
> > > > Are we actually doing the right thing here? I just mean that we
> > > > get value
> > > > 543 in the bug because pixel rate is 14874 which doesn't seem correct.
> > >
> > > As explained in the commit msg programming this to lower than
> > > necessary value should be totally fine. It just won't be optimal.
> > >
> > > The values in the jira (was there an actual gitlab bug for this
> > > btw?) look quite sensible
> > No, there is no gtilab issue as no tiled display at CI.
> 
> Can't see what this has to do with tiled displays. I guess we're talking 
> about some
> specific display that just happens to have that super slow mode?
Perhaps, issue where seen in Dell UP2715K. 

> 
> >
> > > to me. Some kind of low res 848xsomething mode with dotclock of
> > > 14.874 Mhz, which gives us that linetime of ~68 usec.
> > >
> > > >
> > > > Stan
> > > > >  }
> > > > >
> > > > >  static u16 hsw_ips_linetime_wm(const struct intel_crtc_state
> > > > > *crtc_state, @@ -12594,12 +12597,15 @@ static u16
> > > > > hsw_ips_linetime_wm(const struct intel_crtc_state

Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to <64usec

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville 
> Syrjälä
> Sent: perjantai 26. kesäkuuta 2020 16.47
> To: Lisovskiy, Stanislav 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to <64usec
> 
> On Fri, Jun 26, 2020 at 12:16:06PM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Jun 25, 2020 at 11:00:03PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > >
> > > The linetime watermark is a 9 bit value, which gives us a maximum
> > > linetime of just below 64 usec. If the linetime exceeds that value
> > > we currently just discard the high bits and program the rest into
> > > the register, which angers the state checker.
> > >
> > > To avoid that let's just clamp the value to the max. I believe it
> > > should be perfectly fine to program a smaller linetime wm than
> > > strictly required, just means the hardware may fetch data sooner
> > > than strictly needed. We are further reassured by the fact that with
> > > DRRS the spec tells us to program the smaller of the two linetimes
> > > corresponding to the two refresh rates.
> > >
> > > Cc: Stanislav Lisovskiy 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display.c | 18
> > > --
> > >  1 file changed, 12 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index a11bb675f9b3..d486d675166f 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -12581,12 +12581,15 @@ static u16 hsw_linetime_wm(const struct
> > > intel_crtc_state *crtc_state)  {
> > >   const struct drm_display_mode *adjusted_mode =
> > >   _state->hw.adjusted_mode;
> > > + int linetime_wm;
> > >
> > >   if (!crtc_state->hw.enable)
> > >   return 0;
> > >
> > > - return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 *
> 8,
> > > -  adjusted_mode-
> >crtc_clock);
> > > + linetime_wm = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal *
> 1000 * 8,
> > > +
>   adjusted_mode->crtc_clock);
> > > +
> > > + return min(linetime_wm, 0x1ff);
> >
> > Are we actually doing the right thing here? I just mean that we get
> > value
> > 543 in the bug because pixel rate is 14874 which doesn't seem correct.
> 
> As explained in the commit msg programming this to lower than necessary value
> should be totally fine. It just won't be optimal.
> 
> The values in the jira (was there an actual gitlab bug for this btw?) look 
> quite sensible
No, there is no gtilab issue as no tiled display at CI. 

> to me. Some kind of low res 848xsomething mode with dotclock of 14.874 Mhz,
> which gives us that linetime of ~68 usec.
> 
> >
> > Stan
> > >  }
> > >
> > >  static u16 hsw_ips_linetime_wm(const struct intel_crtc_state
> > > *crtc_state, @@ -12594,12 +12597,15 @@ static u16
> > > hsw_ips_linetime_wm(const struct intel_crtc_state *crtc_state,  {
> > >   const struct drm_display_mode *adjusted_mode =
> > >   _state->hw.adjusted_mode;
> > > + int linetime_wm;
> > >
> > >   if (!crtc_state->hw.enable)
> > >   return 0;
> > >
> > > - return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 *
> 8,
> > > -  cdclk_state-
> >logical.cdclk);
> > > + linetime_wm = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal *
> 1000 * 8,
> > > +
>   cdclk_state->logical.cdclk);
> > > +
> > > + return min(linetime_wm, 0x1ff);
> > >  }
> > >
> > >  static u16 skl_linetime_wm(const struct intel_crtc_state
> > > *crtc_state) @@ -12608,7 +12614,7 @@ static u16 skl_linetime_wm(const
> struct intel_crtc_state *crtc_state)
> > >   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > >   const struct drm_display_mode *adjusted_mode =
> > >   _state->hw.adjusted_mode;
> > > - u16 linetime_wm;
> > > + int linetime_wm;
> > >
> > >   if (!crtc_state->hw.enable)
> > >   return 0;
> > > @@ -12620,7 +12626,7 @@ static u16 skl_linetime_wm(const struct
> intel_crtc_state *crtc_state)
> > >   if (IS_GEN9_LP(dev_priv) && dev_priv->ipc_enabled)
> > >   linetime_wm /= 2;
> > >
> > > - return linetime_wm;
> > > + return min(linetime_wm, 0x1ff);
> > >  }
> > >
> > >  static int hsw_compute_linetime_wm(struct intel_atomic_state
> > > *state,
> > > --
> > > 2.26.2
> > >
> 
> --
> Ville Syrjälä
> Intel
> ___
> 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] A panic and a hang in the i915 drm driver

[Saarinen, Jani]

HI, 
> -Original Message-
> From: Intel-gfx  On Behalf Of Jani 
> Nikula
> Sent: maanantai 8. kesäkuuta 2020 10.49
> To: David Howells ; Joonas Lahtinen
> ; Vivi, Rodrigo 
> Cc: intel-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; dhowe...@redhat.com; airl...@redhat.com
> Subject: Re: [Intel-gfx] A panic and a hang in the i915 drm driver
> 
> On Sun, 07 Jun 2020, David Howells  wrote:
> > Hi,
> >
> > I'm seeing the attached oops and panic from the i915 drm driver.  I've tried
> > bisecting it, but there's a problem in that one of the merged branches 
> > causes
> > the machine to hang without output.
It was not this one? 
https://gitlab.freedesktop.org/drm/intel/-/issues/1892


> 
> Cc: Ville and GG, I thought this was fixed (reverted) already.
> 
> BR,
> Jani.
> 
> 
> >
> > The oops for commit c41219fda6e04255c44d37fd2c0d898c1c46abf1 looks like:
> >
> > BUG: kernel NULL pointer dereference, address: 
> > #PF: supervisor read access in kernel mode
> > #PF: error_code(0x) - not-present page
> > PGD 0 P4D 0
> > Oops:  [#1] SMP PTI
> > CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc2-fscache+ #883
> > Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
> > RIP: 0010:intel_psr_enabled+0xb/0x6e
> > Code: 8b 44 24 08 65 48 33 04 25 28 00 00 00 74 05 e8 7e ff 97 ff 48 83 c4 
> > 10 5b 5d
> 41 5c 41 5d c3 0f 1f 44 00 00 41 55 41 54 55 53 <48> 8b 9f d8 fe ff ff f6 83 
> 5e 08 00
> 00 20 75 05 45 31 e4 eb 44 80
> > RSP: :88840dedfa18 EFLAGS: 00010246
> > RAX:  RBX: 8884086f9000 RCX: 
> > RDX: 0001 RSI: 8884086f9000 RDI: 0128
> > RBP: 8884086fb000 R08:  R09: 0001
> > R10: 0001 R11: 00ff R12: 88840868
> > R13:  R14:  R15: 8884086fb200
> > FS:  () GS:88840fb0()
> knlGS:
> > CS:  0010 DS:  ES:  CR0: 80050033
> > CR2:  CR3: 0440c001 CR4: 001606e0
> > Call Trace:
> >  intel_read_dp_sdp+0x71/0x2c5
> >  hsw_crt_get_config+0x18/0x41
> >  intel_modeset_readout_hw_state+0x24d/0x662
> >  ? do_raw_spin_lock+0x8b/0xcd
> >  ? _raw_spin_lock_irqsave+0x10/0x16
> >  intel_modeset_setup_hw_state+0xa8/0xb59
> >  ? __next_node_in+0x39/0x42
> >  ? ww_mutex_lock+0x3d/0x1da
> >  ? modeset_lock+0xd4/0x114
> >  ? drm_modeset_lock_all_ctx+0x86/0xcc
> >  intel_modeset_init+0x285/0x5bf
> >  ? intel_irq_postinstall+0x485/0x4d1
> >  i915_driver_probe+0x1b4/0x49c
> >  ? __kernfs_new_node+0x161/0x1b2
> >  ? rpm_resume+0x45e/0x485
> >  i915_pci_probe+0xfd/0x11d
> >  ? __pm_runtime_resume+0x51/0x5e
> >  local_pci_probe+0x39/0x7a
> >  pci_device_probe+0xf5/0x14f
> >  ? sysfs_do_create_link_sd.isra.0+0x77/0xa3
> >  really_probe+0x140/0x2a9
> >  driver_probe_device+0x9c/0xd1
> >  device_driver_attach+0x3c/0x55
> >  __driver_attach+0x97/0x9f
> >  ? device_driver_attach+0x55/0x55
> >  bus_for_each_dev+0x72/0xa8
> >  bus_add_driver+0x108/0x1b9
> >  driver_register+0x9e/0xd7
> >  ? mipi_dsi_bus_init+0x11/0x11
> >  i915_init+0x58/0x6b
> >  do_one_initcall+0x83/0x18a
> >  kernel_init_freeable+0x19b/0x1fd
> >  ? rest_init+0x9f/0x9f
> >  kernel_init+0xa/0xfa
> >  ret_from_fork+0x1f/0x30
> > Modules linked in:
> > CR2: 
> > ---[ end trace d0c4f561618aeb37 ]---
> > RIP: 0010:intel_psr_enabled+0xb/0x6e
> > Code: 8b 44 24 08 65 48 33 04 25 28 00 00 00 74 05 e8 7e ff 97 ff 48 83 c4 
> > 10 5b 5d
> 41 5c 41 5d c3 0f 1f 44 00 00 41 55 41 54 55 53 <48> 8b 9f d8 fe ff ff f6 83 
> 5e 08 00
> 00 20 75 05 45 31 e4 eb 44 80
> > RSP: :88840dedfa18 EFLAGS: 00010246
> > RAX:  RBX: 8884086f9000 RCX: 
> > RDX: 0001 RSI: 8884086f9000 RDI: 0128
> > RBP: 8884086fb000 R08:  R09: 0001
> > R10: 0001 R11: 00ff R12: 88840868
> > R13:  R14:  R15: 8884086fb200
> > FS:  () GS:88840fb0()
> knlGS:
> > CS:  0010 DS:  ES:  CR0: 80050033
> > CR2:  CR3: 0440c001 CR4: 001606e0
> > Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009
> > Kernel Offset: disabled
> > ---[ end Kernel panic - not syncing: Attempted to kill init! 
> > exitcode=0x0009 ]---
> >
> >
> > Decoding the RIP gives:
> >
> > RIP: 0010:intel_psr_enabled (/data/fs/linux-
> fs/build3/../drivers/gpu/drm/i915/display/intel_display_types.h:1595 
> /data/fs/linux-
> fs/build3/../drivers/gpu/drm/i915/display/intel_psr.c:1598)
> >
> >
> >
> > Commit c41219fda6e04255c44d37fd2c0d898c1c46abf1 ("Merge tag
> > 'drm-intel-next-fixes-2020-05-20' of
> > git://anongit.freedesktop.org/drm/drm-intel into drm-next") is definitely 
> > bad
> > and logs an oops to the console and panics, but it's 

Re: [Intel-gfx] intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

[Saarinen, Jani]

Please make gitlab issue if not already done. Lakshmi, please guide.

From: Intel-gfx  On Behalf Of Arno
Sent: maanantai 18. toukokuuta 2020 10.07
To: intel-gfx@lists.freedesktop.org; ch...@chris-wilson.co.uk
Subject: Re: [Intel-gfx] intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* 
CPU pipe A FIFO underrun


Is there another place to report this kind of issue? Didn't get any feedback. 
Did I make mistakes in my mail? I already tried the Ubuntu bug-tracker (see 
below) with no success.

Thank you,

Arno


Am 11.05.20 um 10:18 schrieb Arno:

My laptop (core m5-6y54) starts flickering after returning from Suspend (to 
RAM) or other commands touching the video driver (xrandr, powertop --calibrate, 
...)

From kernel (tested with up to 5.7) I get the message:

[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO 
underrun

I added a bug with more details here:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872760

but guys from Ubuntu seems not able to help (as it is an upstream bug) !?

This happend not in older kernels, but these have the problem not to go in 
power save states. So I think the fix of that

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1863489

causes this regression.

Hope someone can help. For a  laptop it is better to have both - standby and 
power saving. Thank you.

Arno





___

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 v12 00/14] In order to readout DP SDPs, refactors the handling of DP SDPs

[Saarinen, Jani]

Hi,

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani 
> Nikula
> Sent: perjantai 15. toukokuuta 2020 16.13
> To: Ville Syrjälä 
> Cc: linux-fb...@vger.kernel.org; daniel.vet...@ffwll.ch; intel-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> laurent.pinch...@ideasonboard.com
> Subject: Re: [Intel-gfx] [PATCH v12 00/14] In order to readout DP SDPs, 
> refactors the
> handling of DP SDPs
> 
> On Fri, 15 May 2020, Ville Syrjälä  wrote:
> > On Thu, May 14, 2020 at 02:19:23PM +0300, Jani Nikula wrote:
> >> On Thu, 14 May 2020, Gwan-gyeong Mun 
> wrote:
> >> > In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata
> >> > Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes.
> >> > It adds new compute routines for DP HDR Metadata Infoframe SDP and
> >> > DP VSC SDP.
> >> > And new writing routines of DP SDPs (Secondary Data Packet) that
> >> > uses computed configs.
> >> > New reading routines of DP SDPs are added for readout.
> >> > It adds a logging function for DP VSC SDP.
> >> > When receiving video it is very useful to be able to log DP VSC SDP.
> >> > This greatly simplifies debugging.
> >> > In order to use a common VSC SDP Colorimetry calculating code on
> >> > PSR, it uses a new psr vsc sdp compute routine.
> >>
> >> Pushed the series to drm-intel-next-queued with Daniel's irc ack for
> >> merging the two non-i915 patches that route too.
> >
> > fi-hsw-4770 now oopses at boot:
> 
> /o\
> 
> What did I miss? What part about the CI report did I overlook?
Damn, indeed:
https://patchwork.freedesktop.org/series/72853/
Ci results is success but it has:
Known issues


  Here are the changes found in Patchwork_17654 that come from known issues:

### CI changes ###

 Issues hit 

  * boot:
- fi-hsw-4770:[PASS][1] -> [FAIL][2] ([CI#80])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8481/fi-hsw-4770/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17654/fi-hsw-4770/boot.html

> 
> BR,
> Jani.
> 
> 
> >
> > <1>[3.736903] BUG: kernel NULL pointer dereference, address:
> 
> > <1>[3.736916] #PF: supervisor read access in kernel mode
> > <1>[3.736916] #PF: error_code(0x) - not-present page
> > <6>[3.736917] PGD 0 P4D 0
> > <4>[3.736919] Oops:  [#1] PREEMPT SMP PTI
> > <4>[3.736921] CPU: 0 PID: 363 Comm: systemd-udevd Not tainted 
> > 5.7.0-rc5-CI-
> CI_DRM_8485+ #1
> > <4>[3.736922] Hardware name: LENOVO 10AGS00601/SHARKBAY, BIOS
> FBKT34AUS 04/24/2013
> > <4>[3.736986] RIP: 0010:intel_psr_enabled+0x8/0x70 [i915]
> > <4>[3.736988] Code: 18 48 c7 c6 40 09 79 a0 e8 e3 e2 04 e1 0f b6 44 24 
> > 03 e9 f4
> fd ff ff 90 66 2e 0f 1f 84 00 00 00 00 00 41 54 55 53 48 83 ec 08 <48> 8b 9f 
> d8 fe ff ff
> f6 83 5e 0d 00 00 20 74 09 80 bb 6c b6 00 00
> > <4>[3.737036] RSP: 0018:c947f8a0 EFLAGS: 00010286
> > <4>[3.737042] RAX: 0002 RBX: 8883ffd04000 RCX:
> 0001
> > <4>[3.737048] RDX: 0007 RSI: 8883ffd04000 RDI:
> 0128
> > <4>[3.737055] RBP: 888406afe200 R08: 000f R09:
> 0001
> > <4>[3.737061] R10:  R11:  R12:
> 
> > <4>[3.737068] R13: 8883f75d R14: 888406afe200 R15:
> 8883f75d0870
> > <4>[3.737075] FS:  7f71618f9680() GS:88840ec0()
> knlGS:
> > <4>[3.737082] CS:  0010 DS:  ES:  CR0: 80050033
> > <4>[3.737088] CR2:  CR3: 000402510002 CR4:
> 001606f0
> > <4>[3.737094] DR0:  DR1:  DR2:
> 
> > <4>[3.737101] DR3:  DR6: fffe0ff0 DR7:
> 0400
> > <4>[3.737107] Call Trace:
> > <4>[3.737175]  intel_read_dp_sdp+0x1a4/0x380 [i915]
> > <4>[3.737246]  hsw_crt_get_config+0x12/0x40 [i915]
> > <4>[3.737317]  intel_modeset_setup_hw_state+0x3b3/0x16a0 [i915]
> > ...
> 
> --
> Jani Nikula, Intel Open Source Graphics 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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Adding YUV444 packed format support for skl+ (rev5)

[Saarinen, Jani]

+ Lakshmi. 

> -Original Message-
> From: Intel-gfx  On Behalf Of Paauwe,
> Bob J
> Sent: keskiviikko 8. huhtikuuta 2020 2.49
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Adding YUV444 packed format
> support for skl+ (rev5)
> 
> I don't see how the patch would have any effect on execlist selftest. This 
> seems to
> be some random machine error.
> 
> Bob
> --
> Bob Paauwe
> bob.j.paa...@intel.com
> IOTG / Platform Software Engineering
> Intel Corp.  Folsom, CA
> (916) 356-6193
> (530) 409-0831 (cell)
> 
> > -Original Message-
> > From: Patchwork 
> > Sent: Tuesday, April 07, 2020 4:19 PM
> > To: Paauwe, Bob J 
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: ✗ Fi.CI.BAT: failure for Adding YUV444 packed format support
> > for skl+
> > (rev5)
> >
> > == Series Details ==
> >
> > Series: Adding YUV444 packed format support for skl+ (rev5)
> > URL   : https://patchwork.freedesktop.org/series/73020/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_8269 -> Patchwork_17241
> > 
> >
> > Summary
> > ---
> >
> >   **FAILURE**
> >
> >   Serious unknown changes coming with Patchwork_17241 absolutely need
> > to be
> >   verified manually.
> >
> >   If you think the reported changes have nothing to do with the changes
> >   introduced in Patchwork_17241, please notify your bug team to allow them
> >   to document this new failure mode, which will reduce false positives in 
> > CI.
> >
> >   External URL: https://intel-gfx-ci.01.org/tree/drm-
> > tip/Patchwork_17241/index.html
> >
> > Possible new issues
> > ---
> >
> >   Here are the unknown changes that may have been introduced in
> > Patchwork_17241:
> >
> > ### IGT changes ###
> >
> >  Possible regressions 
> >
> >   * igt@i915_selftest@live@execlists:
> > - fi-icl-dsi: [PASS][1] -> [INCOMPLETE][2]
> >[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/fi-icl-
> > dsi/igt@i915_selftest@l...@execlists.html
> >[2]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/fi-icl-
> > dsi/igt@i915_selftest@l...@execlists.html
> >
> >
> > Known issues
> > 
> >
> >   Here are the changes found in Patchwork_17241 that come from known
> > issues:
> >
> > ### IGT changes ###
> >
> >  Issues hit 
> >
> >   * igt@i915_pm_rpm@basic-pci-d3-state:
> > - fi-hsw-4770:[PASS][3] -> [SKIP][4] ([fdo#109271]) +2 similar 
> > issues
> >[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/fi-hsw-
> > 4770/igt@i915_pm_...@basic-pci-d3-state.html
> >[4]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/fi-hsw-
> > 4770/igt@i915_pm_...@basic-pci-d3-state.html
> >
> >
> >  Warnings 
> >
> >   * igt@i915_pm_rpm@module-reload:
> > - fi-kbl-x1275:   [DMESG-FAIL][5] ([i915#62] / [i915#95]) -> 
> > [SKIP][6]
> > ([fdo#109271])
> >[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/fi-kbl-
> > x1275/igt@i915_pm_...@module-reload.html
> >[6]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/fi-kbl-
> > x1275/igt@i915_pm_...@module-reload.html
> >
> >   * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
> > - fi-kbl-x1275:   [DMESG-WARN][7] ([i915#62] / [i915#92]) -> [DMESG-
> > WARN][8] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
> >[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/fi-kbl-
> > x1275/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html
> >[8]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/fi-kbl-
> > x1275/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html
> >
> >   * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
> > - fi-kbl-x1275:   [DMESG-WARN][9] ([i915#62] / [i915#92] / 
> > [i915#95]) ->
> > [DMESG-WARN][10] ([i915#62] / [i915#92]) +6 similar issues
> >[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8269/fi-kbl-
> > x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
> >[10]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17241/fi-kbl-
> > x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
> >
> >
> >   [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
> >   [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
> >   [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
> >   [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
> >
> >
> > Participating hosts (53 -> 47)
> > --
> >
> >   Additional (1): fi-kbl-r
> >   Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
> > fi-ctg-
> > p8600 fi-byt-clapper fi-bdw-samus
> >
> >
> > Build changes
> > -
> >
> >   * CI: CI-20190529 -> None
> >   * IGT: IGT_5577 -> IGTPW_4428
> >   * Linux: CI_DRM_8269 -> Patchwork_17241
> >
> >   CI-20190529: 20190529
> >   CI_DRM_8269: 301d0427e2e3108839bf6c36f58dd0b2b5258c25 @
> > 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dp: Modeset only the tiled connectors with CRTC

[Saarinen, Jani]

+ Martin to re-report. 

> -Original Message-
> From: Navare, Manasi D 
> Sent: lauantai 25. tammikuuta 2020 4.19
> To: intel-gfx@lists.freedesktop.org
> Cc: Sarvela, Tomi P ; Saarinen, Jani
> ; Nautiyal, Ankit K ;
> Nikkanen, Kimmo 
> Subject: RE: ✗ Fi.CI.BAT: failure for drm/i915/dp: Modeset only the tiled 
> connectors
> with CRTC
> 
> This Gem related failure is not relevant to this patch, but because of this 
> it doesn’t
> run full IGT, I want to make sure that the kms_flip tests are not getting 
> hung.
> 
> Or can we confirm this with manual testing?
> 
> Manasi
> 
> -Original Message-
> From: Patchwork 
> Sent: Friday, January 24, 2020 5:47 PM
> To: Navare, Manasi D 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✗ Fi.CI.BAT: failure for drm/i915/dp: Modeset only the tiled 
> connectors
> with CRTC
> 
> == Series Details ==
> 
> Series: drm/i915/dp: Modeset only the tiled connectors with CRTC
> URL   : https://patchwork.freedesktop.org/series/72559/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_7811 -> Patchwork_16267
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_16267 absolutely need to be
>   verified manually.
> 
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_16267, please notify your bug team to allow them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   External URL: https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_16267/index.html
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in
> Patchwork_16267:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@gem_close_race@basic-threads:
> - fi-hsw-peppy:   [PASS][1] -> [INCOMPLETE][2]
>[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/fi-hsw-
> peppy/igt@gem_close_r...@basic-threads.html
>[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16267/fi-hsw-
> peppy/igt@gem_close_r...@basic-threads.html
> 
> 
> Known issues
> 
> 
>   Here are the changes found in Patchwork_16267 that come from known issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@kms_chamelium@hdmi-hpd-fast:
> - fi-kbl-7500u:   [PASS][3] -> [FAIL][4] ([fdo#111096] / [i915#323])
>[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/fi-kbl-
> 7500u/igt@kms_chamel...@hdmi-hpd-fast.html
>[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16267/fi-kbl-
> 7500u/igt@kms_chamel...@hdmi-hpd-fast.html
> 
> 
>  Possible fixes 
> 
>   * igt@gem_exec_parallel@fds:
> - fi-byt-n2820:   [TIMEOUT][5] ([fdo#112271]) -> [PASS][6]
>[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/fi-byt-
> n2820/igt@gem_exec_paral...@fds.html
>[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16267/fi-byt-
> n2820/igt@gem_exec_paral...@fds.html
> 
>   * igt@i915_module_load@reload-with-fault-injection:
> - fi-cfl-8700k:   [DMESG-WARN][7] ([i915#889]) -> [PASS][8]
>[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/fi-cfl-
> 8700k/igt@i915_module_l...@reload-with-fault-injection.html
>[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16267/fi-cfl-
> 8700k/igt@i915_module_l...@reload-with-fault-injection.html
> 
>   * igt@i915_selftest@live_blt:
> - fi-hsw-4770:[DMESG-FAIL][9] ([i915#725]) -> [PASS][10]
>[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/fi-hsw-
> 4770/igt@i915_selftest@live_blt.html
>[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16267/fi-hsw-
> 4770/igt@i915_selftest@live_blt.html
> 
>   * igt@i915_selftest@live_gem_contexts:
> - fi-byt-n2820:   [DMESG-FAIL][11] ([i915#722]) -> [PASS][12]
>[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/fi-byt-
> n2820/igt@i915_selftest@live_gem_contexts.html
>[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16267/fi-byt-
> n2820/igt@i915_selftest@live_gem_contexts.html
> 
>   * igt@i915_selftest@live_gtt:
> - fi-bdw-5557u:   [TIMEOUT][13] ([fdo#112271]) -> [PASS][14]
>[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7811/fi-bdw-
> 5557u/igt@i915_selftest@live_gtt.html
>[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16267/fi-bdw-
> 5557u/igt@i915_selftest@live_gtt.html
> 
> 
>  Warnings 
> 
>   * igt@gem_exec_parallel@contexts:
> - fi-byt-n2820:   [FAIL][15]

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Bump up CDCLK to eliminate underruns on TGL (rev3)

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Peres, Martin 
> Sent: maanantai 13. tammikuuta 2020 10.55
> To: Lisovskiy, Stanislav ; intel-
> g...@lists.freedesktop.org; Vudum, Lakshminarayana
> ; Saarinen, Jani 
> Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915: Bump up CDCLK to eliminate
> underruns on TGL (rev3)
> 
> On 13/01/2020 10:32, Lisovskiy, Stanislav wrote:
> > Yet again unrelated gem failure, do we have a bug about this?
> >
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=112271
> 
> 
> > That CDCLK change is crucial to get in and has nothing to do with gem
> > tests, i.e can't anyhow affect the outcome.
> 
> Btw, TGL shards were not included in these results because I rushed its
> reporting... so please wait for the second email that will have both the TGL 
> shards
But they were. 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16045/runtimes-tglb.txt
> results AND the false positive fixed (I already filed it).
Perhaps we have first all as notruns and then ontop this and thus we have ~6200 
tests reported. 

> 
> Martin
> >
> >
> > Best Regards,
> >
> > Lisovskiy Stanislav
> >
> > Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7,
> > 02160 Espoo
> > --
> > --
> > *From:* Patchwork 
> > *Sent:* Monday, January 13, 2020 10:00:44 AM
> > *To:* Lisovskiy, Stanislav
> > *Cc:* intel-gfx@lists.freedesktop.org
> > *Subject:* ✗ Fi.CI.IGT: failure for drm/i915: Bump up CDCLK to
> > eliminate underruns on TGL (rev3)
> >
> > == Series Details ==
> >
> > Series: drm/i915: Bump up CDCLK to eliminate underruns on TGL (rev3)
> > URL   : https://patchwork.freedesktop.org/series/71760/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_7714_full -> Patchwork_16045_full
> > 
> >
> > Summary
> > ---
> >
> >   **FAILURE**
> >
> >   Serious unknown changes coming with Patchwork_16045_full absolutely
> > need to be
> >   verified manually.
> >
> >   If you think the reported changes have nothing to do with the
> > changes
> >   introduced in Patchwork_16045_full, please notify your bug team to
> > allow them
> >   to document this new failure mode, which will reduce false positives
> > in CI.
> >
> >
> >
> > Possible new issues
> > ---
> >
> >   Here are the unknown changes that may have been introduced in
> > Patchwork_16045_full:
> >
> > ### IGT changes ###
> >
> >  Possible regressions 
> >
> >   * igt@gem_busy@close-race:
> >     - shard-hsw:  NOTRUN -> [TIMEOUT][1]
> >    [1]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16045/shard-hsw5/ig
> > t@gem_b...@close-race.html
> >
> >
> > New tests
> > -
> >
> >   New tests have been introduced between CI_DRM_7714_full and
> > Patchwork_16045_full:
> >
> > ### New IGT tests (2) ###
> >
> >   * igt@kms_dp_dsc@basic-dsc-enable-dp:
> >     - Statuses : 8 skip(s)
> >     - Exec time: [0.0, 0.00] s
> >
> >   * igt@kms_dp_dsc@basic-dsc-enable-edp:
> >     - Statuses : 1 pass(s) 7 skip(s)
> >     - Exec time: [0.0, 4.92] s
> >
> >
> >
> > Known issues
> > 
> >
> >   Here are the changes found in Patchwork_16045_full that come from
> > known issues:
> >
> > ### IGT changes ###
> >
> >  Issues hit 
> >
> >   * igt@gem_ctx_isolation@vcs1-dirty-create:
> >     - shard-iclb: [PASS][2] -> [SKIP][3] ([fdo#109276] /
> > [fdo#112080])
> >    [2]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-iclb1/igt@g
> > em_ctx_isolat...@vcs1-dirty-create.html
> >    [3]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16045/shard-iclb7/i
> > gt@gem_ctx_isolat...@vcs1-dirty-create.html
> >
> >   * igt@gem_ctx_isolation@vecs0-s3:
> >     - shard-kbl:  [PASS][4] -> [INCOMPLETE][5] ([fdo#103665])
> >    [4]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-kbl7/igt@ge
> > m_ctx_isolat...@vecs0-s3.html
> >    [5]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16045/shard-kbl4/ig
> > t@gem_ctx_isolat...@vecs0-s3.html
> >
> >   * igt@gem_ctx_shared@exec-single-timeline-bsd:
> >     - shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#11084

Re: [Intel-gfx] [PATCH v7 7/7] drm/i915/tgl: Add Clear Color support for TGL Render Decompression

[Saarinen, Jani]

+ Imre

> -Original Message-
> From: Intel-gfx  On Behalf Of Matt
> Roper
> Sent: tiistai 26. marraskuuta 2019 22.49
> To: Sripada, Radhakrishna 
> Cc: Chery, Nanley G ; intel-
> g...@lists.freedesktop.org; Pandiyan, Dhinakaran
> ; Syrjala, Ville 
> Subject: Re: [Intel-gfx] [PATCH v7 7/7] drm/i915/tgl: Add Clear Color support 
> for
> TGL Render Decompression
> 
> On Mon, Nov 25, 2019 at 04:26:35PM -0800, Radhakrishna Sripada wrote:
> > Render Decompression is supported with Y-Tiled main surface. The CCS
> > is linear and has 4 bits of data for each main surface cache line
> > pair, a ratio of 1:256. Additional Clear Color information is passed
> > from the user-space through an offset in the GEM BO. Add a new
> > modifier to identify and parse new Clear Color information and extend
> > Gen12 render decompression functionality to the newly added modifier.
> >
> > v2: Fix has_alpha flag for modifiers, omit CC modifier during initial
> > plane config(Matt). Fix Lookup error.
> > v3: Fix the panic while running kms_cube
> > v4: Add alignment check and reuse the comments for
> > ge12_ccs_formats(Matt)
> > v5: Fix typos and wrap comments(Matt)
> > v6: Rebase
> > v7: Rebase, Add missing case in intel_tile_height(RK)
> >
> > Cc: Dhinakaran Pandiyan 
> > Cc: Ville Syrjala 
> > Cc: Shashank Sharma 
> > Cc: Rafael Antognolli 
> > Cc: Nanley G Chery 
> > Cc: Matt Roper 
> > Signed-off-by: Radhakrishna Sripada 
> 
> A few minor comments below, but none of them are critical.
> 
> Reviewed-by: Matt Roper 
> 
> What's the current status of the underlying compression series this work is 
> based
> on?
> 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c  | 64 ++-
> >  .../drm/i915/display/intel_display_types.h|  3 +
> >  drivers/gpu/drm/i915/display/intel_sprite.c   | 10 ++-
> >  drivers/gpu/drm/i915/i915_reg.h   | 12 
> >  4 files changed, 86 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 6c4274c1564d..69e70be86f57 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -1975,6 +1975,10 @@ intel_tile_width_bytes(const struct
> drm_framebuffer *fb, int color_plane)
> > if (color_plane == 1)
> > return 64;
> > /* fall through */
> 
> Since this one (GEN12_RC_CCS) now falls through to the new
> GEN12_RC_CCS_CC, you can probably drop these lines since they'll be handled
> the same way in the next case down.
> 
> > +   case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> > +   if (color_plane == 1 || color_plane == 2)
> 
> I've reviewed a lot of versions of these compression series so I might be 
> getting
> confused, but didn't DK have a version at one time that added some kind of
> is_ccs_plane(mod, plane) helper function?  I'm not sure what happened to that,
> but it did seem like a nice way to consolidate the "these planes contain CCS 
> stuff"
> logic rather than having to hardcode the plane ID's all over the place like 
> this.
> 
> 
> > +   return 64;
> > +   /* fall through */
> > case I915_FORMAT_MOD_Y_TILED:
> > if (IS_GEN(dev_priv, 2) ||
> HAS_128_BYTE_Y_TILING(dev_priv))
> > return 128;
> > @@ -2013,6 +2017,10 @@ intel_tile_height(const struct drm_framebuffer *fb,
> int color_plane)
> > if (color_plane == 1)
> > return 1;
> > /* fall through */
> 
> As above, you can now consolidate this with the new block below if you want.
> 
> > +   case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> > +   if (color_plane == 1 || color_plane == 2)
> > +   return 1;
> > +   /* fall through */
> > default:
> > return intel_tile_size(to_i915(fb->dev)) /
> > intel_tile_width_bytes(fb,
> color_plane); @@ -2116,6 +2124,7 @@
> > static unsigned int intel_surf_alignment(const struct drm_framebuffer *fb,
> > return 256 * 1024;
> > return 0;
> > case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> > +   case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> > return 16 * 1024;
> > case I915_FORMAT_MOD_Y_TILED_CCS:
> > case I915_FORMAT_MOD_Yf_TILED_CCS:
> > @@ -2313,8 +2322,16 @@ static u32 intel_adjust_tile_offset(int *x, int
> > *y,
> >
> >  static bool is_surface_linear(u64 modifier, int color_plane)  {
> > -   return modifier == DRM_FORMAT_MOD_LINEAR ||
> > -  (modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS
> && color_plane == 1);
> > +   switch (modifier) {
> > +   case DRM_FORMAT_MOD_LINEAR:
> > +   return true;
> > +   case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> > +   return color_plane == 1;
> > +   case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> > +   return color_plane == 1 || color_plane == 2;
> > +   default:
> 

Re: [Intel-gfx] [PATCH v2] drm/i915: Support more QGV points

[Saarinen, Jani]

Hi,

> -Original Message-
> From: Lisovskiy, Stanislav 
> Sent: maanantai 25. marraskuuta 2019 17.55
> To: ville.syrj...@linux.intel.com
> Cc: Saarinen, Jani ; intel-gfx@lists.freedesktop.org;
> Roper, Matthew D ; jani.nik...@linux.intel.com;
> Sarvela, Tomi P 
> Subject: Re: [PATCH v2] drm/i915: Support more QGV points
> 
> On Mon, 2019-11-25 at 17:31 +0200, Ville Syrjälä wrote:
> > On Fri, Nov 22, 2019 at 04:10:49PM +0200, Stanislav Lisovskiy wrote:
> > > According to BSpec 53998, there is a mask of max 8 SAGV/QGV points
> > > we need to support.
> > >
> > > Bumping this up to keep the CI happy(currently preventing tests to
> > > run), until all SAGV changes land.
> > >
> > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=112189
> > > Signed-off-by: Stanislav Lisovskiy 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_bw.c | 22 +--
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h |  6 +-
> > >  2 files changed, 22 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> > > b/drivers/gpu/drm/i915/display/intel_bw.c
> > > index 86e75e858008..d1b805b30177 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > > @@ -15,7 +15,7 @@ struct intel_qgv_point {  };
> > >
> > >  struct intel_qgv_info {
> > > - struct intel_qgv_point points[3];
> > > + struct intel_qgv_point points[I915_NUM_SAGV_POINTS];
> > >   u8 num_points;
> > >   u8 num_channels;
> > >   u8 t_bl;
> > > @@ -276,15 +276,27 @@ void intel_bw_init_hw(struct drm_i915_private
> > > *dev_priv)
> > >  static unsigned int intel_max_data_rate(struct drm_i915_private
> > > *dev_priv,
> > >   int
> num_planes)
> > >  {
> > > - if (INTEL_GEN(dev_priv) >= 11)
> > > + if (INTEL_GEN(dev_priv) >= 11) {
> > > + /*
> > > +  * Any bw group has same amount of QGV points
> > > +  */
> > > + const struct intel_bw_info *bi =
> > > + _priv->max_bw[0];
> > > + unsigned int min_bw = UINT_MAX;
> > > + int i;
> > > +
> > >   /*
> > >* FIXME with SAGV disabled maybe we can assume
> > >* point 1 will always be used? Seems to match
> > >* the behaviour observed in the wild.
> > >*/
> > > - return min3(icl_max_bw(dev_priv, num_planes, 0),
> > > - icl_max_bw(dev_priv, num_planes,
> 1),
> > > - icl_max_bw(dev_priv, num_planes,
> 2));
> > > + for (i = 0; i < bi->num_qgv_points; i++) {
> > > + unsigned int bw = icl_max_bw(dev_priv,
> > > num_planes, i);
> > > +
> > > + min_bw = min(bw, min_bw);
> > > + }
> > > + return min_bw;
> > > + }
> > >   else
> > >   return UINT_MAX;
> > >  }
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h index fdae5a919bc8..d45a9ffaed4f
> > > 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -621,6 +621,9 @@ struct i915_gem_mm {
> > >
> > >  #define I915_ENGINE_WEDGED_TIMEOUT  (60 * HZ)  /* Reset but no
> > > recovery? */
> > >
> > > +/* BSpec precisely defines this */
> > > +#define I915_NUM_SAGV_POINTS 8
> >
> > I think everything else talks about "QGV points" rather than "SAGV
> > points" now? Would be nice to be consistent.
> 
> Agree, _SAGV_ is not that accurate here.
> Will change the naming.
Can we do that while merging? 

> 
> Stan
> 
> >
> > Apart from that
> > Reviewed-by: Ville Syrjälä 
> >
> > > +
> > >  struct ddi_vbt_port_info {
> > >   /* Non-NULL if port present. */
> > >   const struct child_device_config *child; @@ -1232,7 +1235,8 @@
> > > struct drm_i915_private {
> > >   } dram_info;
> > >
> > >   struct intel_bw_info {
> > > - unsigned int deratedbw[3]; /* for each QGV point */
> > > + /* for each QGV point */
> > > + unsigned int deratedbw[I915_NUM_SAGV_POINTS];
> > >   u8 num_qgv_points;
> > >   u8 num_planes;
> > >   } max_bw[6];
> > > --
> > > 2.17.1
> >
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/vbt: Parse panel options separately from timing data

[Saarinen, Jani]

HI, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Jesse
> Barnes
> Sent: perjantai 15. marraskuuta 2019 2.05
> To: Roper, Matthew D 
> Cc: Nikula, Jani ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/vbt: Parse panel options
> separately from timing data
> 
> LGTM.
> 
> Reviewed-by: Jesse Barnes 
Thanks Jesse  
> 
> On Thu, Nov 14, 2019 at 9:07 AM Matt Roper 
> wrote:
> >
> > Newer VBT versions will add an alternate way to read panel DTD
> > information, so let's split parsing of the general panel information
> > from the timing data in preparation.
> >
> > Cc: Jani Nikula 
> > Signed-off-by: Matt Roper 
> > ---
> >  drivers/gpu/drm/i915/display/intel_bios.c | 27
> > +++
> >  1 file changed, 18 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index 6d7b1a83cb07..d13ce0b7db8b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -208,17 +208,12 @@ get_lvds_fp_timing(const struct bdb_header *bdb,
> > return (const struct lvds_fp_timing *)((const u8 *)bdb + ofs);
> > }
> >
> > -/* Try to find integrated panel data */
> > +/* Parse general panel options */
> >  static void
> > -parse_lfp_panel_data(struct drm_i915_private *dev_priv,
> > -const struct bdb_header *bdb)
> > +parse_panel_options(struct drm_i915_private *dev_priv,
> > +   const struct bdb_header *bdb)
> >  {
> > const struct bdb_lvds_options *lvds_options;
> > -   const struct bdb_lvds_lfp_data *lvds_lfp_data;
> > -   const struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs;
> > -   const struct lvds_dvo_timing *panel_dvo_timing;
> > -   const struct lvds_fp_timing *fp_timing;
> > -   struct drm_display_mode *panel_fixed_mode;
> > int panel_type;
> > int drrs_mode;
> > int ret;
> > @@ -267,6 +262,19 @@ parse_lfp_panel_data(struct drm_i915_private
> *dev_priv,
> > DRM_DEBUG_KMS("DRRS not supported (VBT input)\n");
> > break;
> > }
> > +}
> > +
> > +/* Try to find integrated panel timing data */ static void
> > +parse_lfp_panel_dtd(struct drm_i915_private *dev_priv,
> > +   const struct bdb_header *bdb) {
> > +   const struct bdb_lvds_lfp_data *lvds_lfp_data;
> > +   const struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs;
> > +   const struct lvds_dvo_timing *panel_dvo_timing;
> > +   const struct lvds_fp_timing *fp_timing;
> > +   struct drm_display_mode *panel_fixed_mode;
> > +   int panel_type = dev_priv->vbt.panel_type;
> >
> > lvds_lfp_data = find_section(bdb, BDB_LVDS_LFP_DATA);
> > if (!lvds_lfp_data)
> > @@ -1868,7 +1876,8 @@ void intel_bios_init(struct drm_i915_private
> *dev_priv)
> > /* Grab useful general definitions */
> > parse_general_features(dev_priv, bdb);
> > parse_general_definitions(dev_priv, bdb);
> > -   parse_lfp_panel_data(dev_priv, bdb);
> > +   parse_panel_options(dev_priv, bdb);
> > +   parse_lfp_panel_dtd(dev_priv, bdb);
> > parse_lfp_backlight(dev_priv, bdb);
> > parse_sdvo_panel_data(dev_priv, bdb);
> > parse_driver_features(dev_priv, bdb);
> > --
> > 2.21.0
> >
> > ___
> > 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

Re: [Intel-gfx] [PATCH] drm/i915: Split a setting of MSA to MST and SST

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Mun, Gwan-gyeong 
> Sent: maanantai 11. marraskuuta 2019 17.04
> To: Saarinen, Jani ; Nikula, Jani 
> ;
> intel-gfx@lists.freedesktop.org; Souza, Jose 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Split a setting of MSA to MST and 
> SST
> 
> On Mon, 2019-11-11 at 11:46 +, Saarinen, Jani wrote:
> > Hi,
> >
> > > -Original Message-
> > > From: Intel-gfx  On Behalf
> > > Of Souza, Jose
> > > Sent: torstai 7. marraskuuta 2019 23.16
> > > To: Mun, Gwan-gyeong ; intel-
> > > g...@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Split a setting of MSA to
> > > MST and SST
> > >
> > > On Wed, 2019-11-06 at 23:26 +0200, Gwan-gyeong Mun wrote:
> > > > The setting of MSA is done by the DDI .pre_enable() hook. And when
> > > > we are using MST, the MSA is only set to first mst stream by
> > > > calling of DDI .pre_eanble() hook. It raies issues to non-first
> > > > mst streams.
> > > > Wrong MSA or missed MSA packets might show scrambled screen or
> > > > wrong screen.
> > > >
> > > > This splits a setting of MSA to MST and SST cases. And In the MST
> > > > case it will call a setting of MSA after an allocating of Virtual
> > > > Channel from MST encoder pre_enable callback.
> > >
> > > Reviewed-by: José Roberto de Souza 
> > Also Tested-by: Jani Saarinen  On Dell XPS
> > without patch even booting with console (runlevel 3) screen black on
> > second monitor after DP MST monitor.
> > Dell XPS  (KBL) > TypeC-to DP tp Dell 4K MST monitor and from that to
> > DP monitor (Dell) and this last in the chain black.
> > But with patched kernel screen visible.
> >
> > GG, is issues seen in Shards real or can this be merged now?
> Hi Jani Saarinen,
> IMHO, the reported possible regression seemed not related to this patch.
> I commented and replied to the regression report mail of Rev 3.
> 
> Jani N, if you are available, could you review and merge the patch?
Ville already did  

> 
> Br,
> 
> G.G.
> > > > Cc: Ville Syrjälä 
> > > > Cc: Stanislav Lisovskiy 
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112212
> > > > Fixes: 0c06fa156006 ("drm/i915/dp: Add support of BT.2020
> > > > Colorimetry to DP MSA")
> > > > Fixes: d4a415dcda35 ("drm/i915: Fix MST oops due to MSA changes")
> > > > Signed-off-by: Gwan-gyeong Mun 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_ddi.c| 10 ++
> > > >  drivers/gpu/drm/i915/display/intel_dp_mst.c |  3 +++
> > > >  2 files changed, 9 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > index c91521bcf06a..ef41fa0f77f0 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > @@ -1794,10 +1794,8 @@ void intel_ddi_set_dp_msa(const struct
> > > > intel_crtc_state *crtc_state,
> > > >  * of Color Encoding Format and Content Color Gamut] while
> > > sending
> > > >  * YCBCR 420, HDR BT.2020 signals we should program MSA MISC1
> > > fields
> > > >  * which indicate VSC SDP for the Pixel Encoding/Colorimetry
> > > Format.
> > > > -*
> > > > -* FIXME MST doesn't pass in the conn_state
> > > >  */
> > > > -   if (conn_state && intel_dp_needs_vsc_sdp(crtc_state,
> > > > conn_state))
> > > > +   if (intel_dp_needs_vsc_sdp(crtc_state, conn_state))
> > > > temp |= DP_MSA_MISC_COLOR_VSC_SDP;
> > > >
> > > > I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp); @@ -
> > > 3606,7
> > > > +3604,11 @@ static void intel_ddi_pre_enable_dp(struct
> > > > intel_encoder
> > > > *encoder,
> > > > else
> > > > hsw_ddi_pre_enable_dp(encoder, crtc_state,
> > > conn_state);
> > > > -   intel_ddi_set_dp_msa(crtc_state, conn_state);
> > > > +   /* MST will call a setting of MSA after an allocating of
> > > > Virtual Channel
> > > > +* from MST encoder pre_enable callback.
> > > > +*/
> > > > +   if (!intel_c

Re: [Intel-gfx] [PATCH] drm/i915: Split a setting of MSA to MST and SST

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Souza,
> Jose
> Sent: torstai 7. marraskuuta 2019 23.16
> To: Mun, Gwan-gyeong ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Split a setting of MSA to MST and 
> SST
> 
> On Wed, 2019-11-06 at 23:26 +0200, Gwan-gyeong Mun wrote:
> > The setting of MSA is done by the DDI .pre_enable() hook. And when we
> > are using MST, the MSA is only set to first mst stream by calling of
> > DDI .pre_eanble() hook. It raies issues to non-first mst streams.
> > Wrong MSA or missed MSA packets might show scrambled screen or wrong
> > screen.
> >
> > This splits a setting of MSA to MST and SST cases. And In the MST case
> > it will call a setting of MSA after an allocating of Virtual Channel
> > from MST encoder pre_enable callback.
> 
> Reviewed-by: José Roberto de Souza 
Also Tested-by: Jani Saarinen 
On Dell XPS without patch even booting with console (runlevel 3) screen black 
on second monitor after DP MST monitor.
Dell XPS  (KBL) > TypeC-to DP tp Dell 4K MST monitor and from that to DP 
monitor (Dell) and this last in the chain black.
But with patched kernel screen visible. 

GG, is issues seen in Shards real or can this be merged now? 
> 
> >
> > Cc: Ville Syrjälä 
> > Cc: Stanislav Lisovskiy 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112212
> > Fixes: 0c06fa156006 ("drm/i915/dp: Add support of BT.2020 Colorimetry
> > to DP MSA")
> > Fixes: d4a415dcda35 ("drm/i915: Fix MST oops due to MSA changes")
> > Signed-off-by: Gwan-gyeong Mun 
> > ---
> >  drivers/gpu/drm/i915/display/intel_ddi.c| 10 ++
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c |  3 +++
> >  2 files changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index c91521bcf06a..ef41fa0f77f0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -1794,10 +1794,8 @@ void intel_ddi_set_dp_msa(const struct
> > intel_crtc_state *crtc_state,
> >  * of Color Encoding Format and Content Color Gamut] while
> sending
> >  * YCBCR 420, HDR BT.2020 signals we should program MSA MISC1
> fields
> >  * which indicate VSC SDP for the Pixel Encoding/Colorimetry
> Format.
> > -*
> > -* FIXME MST doesn't pass in the conn_state
> >  */
> > -   if (conn_state && intel_dp_needs_vsc_sdp(crtc_state,
> > conn_state))
> > +   if (intel_dp_needs_vsc_sdp(crtc_state, conn_state))
> > temp |= DP_MSA_MISC_COLOR_VSC_SDP;
> >
> > I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp); @@ -
> 3606,7
> > +3604,11 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
> > *encoder,
> > else
> > hsw_ddi_pre_enable_dp(encoder, crtc_state,
> conn_state);
> >
> > -   intel_ddi_set_dp_msa(crtc_state, conn_state);
> > +   /* MST will call a setting of MSA after an allocating of
> > Virtual Channel
> > +* from MST encoder pre_enable callback.
> > +*/
> > +   if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
> > +   intel_ddi_set_dp_msa(crtc_state, conn_state);
> >  }
> >
> >  static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index 5e267c5b4c20..cb77f8072820 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -345,6 +345,9 @@ static void intel_mst_pre_enable_dp(struct
> > intel_encoder *encoder,
> >  */
> > if (INTEL_GEN(dev_priv) < 12 || !first_mst_stream)
> > intel_ddi_enable_pipe_clock(pipe_config);
> > +
> > +   intel_ddi_set_dp_msa(pipe_config, conn_state);
> > +
> >  }
> >
> >  static void intel_mst_enable_dp(struct intel_encoder *encoder,
> ___
> 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.BAT: success for drm/i915/aml: Allow SPT PCH for all AML devices (rev2)

[Saarinen, Jani]

> -Original Message-
> From: Intel-gfx  On Behalf Of 
> Patchwork
> Sent: perjantai 18. lokakuuta 2019 6.33
> To: Ausmus, James 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/aml: Allow SPT PCH for 
> all AML
> devices (rev2)
> 
> == Series Details ==
> 
> Series: drm/i915/aml: Allow SPT PCH for all AML devices (rev2)
> URL   : https://patchwork.freedesktop.org/series/68176/
> State : success
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_7125 -> Patchwork_14872
> 
> 
> Summary
> ---
> 
>   **SUCCESS**
> 
>   No regressions found.
> 
>   External URL: https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_14872/index.html
> 
> Known issues
> 
> 
>   Here are the changes found in Patchwork_14872 that come from known issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@i915_selftest@live_execlists:
> - fi-skl-lmem:[PASS][1] -> [INCOMPLETE][2] ([fdo#111934])
>[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-skl-
> lmem/igt@i915_selftest@live_execlists.html
>[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/fi-skl-
> lmem/igt@i915_selftest@live_execlists.html
If 111934 is fixed (resolved) how this can be happening? @Vudum, Lakshminarayana

> 
>   * igt@prime_vgem@basic-fence-flip:
> - fi-icl-u3:  [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +1 
> similar issue
>[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-icl-
> u3/igt@prime_v...@basic-fence-flip.html
>[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/fi-icl-
> u3/igt@prime_v...@basic-fence-flip.html
> 
> 
>  Possible fixes 
> 
>   * igt@gem_exec_suspend@basic-s4-devices:
> - fi-icl-u3:  [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6] +1 
> similar issue
>[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-icl-
> u3/igt@gem_exec_susp...@basic-s4-devices.html
>[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/fi-icl-
> u3/igt@gem_exec_susp...@basic-s4-devices.html
> 
>   * igt@i915_selftest@live_execlists:
> - fi-icl-u2:  [INCOMPLETE][7] ([fdo#107713]) -> [PASS][8]
>[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-icl-
> u2/igt@i915_selftest@live_execlists.html
>[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/fi-icl-
> u2/igt@i915_selftest@live_execlists.html
> - fi-apl-guc: [DMESG-FAIL][9] -> [PASS][10]
>[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-apl-
> guc/igt@i915_selftest@live_execlists.html
>[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/fi-apl-
> guc/igt@i915_selftest@live_execlists.html
> 
>   * igt@i915_selftest@live_hangcheck:
> - fi-icl-u3:  [INCOMPLETE][11] ([fdo#107713] / [fdo#108569]) -> 
> [PASS][12]
>[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-icl-
> u3/igt@i915_selftest@live_hangcheck.html
>[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/fi-icl-
> u3/igt@i915_selftest@live_hangcheck.html
> 
> 
>   {name}: This element is suppressed. This means it is ignored when computing
>   the status of the difference (SUCCESS, WARNING, or FAILURE).
> 
>   [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
>   [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
>   [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
>   [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
>   [fdo#111887]: https://bugs.freedesktop.org/show_bug.cgi?id=111887
>   [fdo#111934]: https://bugs.freedesktop.org/show_bug.cgi?id=111934
> 
> 
> Participating hosts (53 -> 44)
> --
> 
>   Missing(9): fi-icl-u4 fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
> fi-bsw-cyan fi-byt-
> clapper fi-icl-y fi-icl-dsi fi-bdw-samus
> 
> 
> Build changes
> -
> 
>   * CI: CI-20190529 -> None
>   * Linux: CI_DRM_7125 -> Patchwork_14872
> 
>   CI-20190529: 20190529
>   CI_DRM_7125: f1ac92f5feb18678a3191a45be0ee4a4d255fc61 @
> git://anongit.freedesktop.org/gfx-ci/linux
>   IGT_5232: bb5735423eaf6fdbf6b2f94ef0b8520e74eab993 @
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
>   Patchwork_14872: 22a8727caa6d0720da77b693cdf317d8fc1b4054 @
> git://anongit.freedesktop.org/gfx-ci/linux
> 
> 
> == Linux commits ==
> 
> 22a8727caa6d drm/i915/aml: Allow SPT PCH for all AML devices
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_14872/index.html
> ___
> 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.BAT: failure for series starting with [CI,1/5] drm/i915: simplify setting of ddi_io_power_domain (rev3)

[Saarinen, Jani]

Hi,

> -Original Message-
> From: Intel-gfx  On Behalf Of 
> Patchwork
> Sent: perjantai 18. lokakuuta 2019 5.42
> To: De Marchi, Lucas 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/5] 
> drm/i915:
> simplify setting of ddi_io_power_domain (rev3)
> 
> == Series Details ==
> 
> Series: series starting with [CI,1/5] drm/i915: simplify setting of
> ddi_io_power_domain (rev3)
> URL   : https://patchwork.freedesktop.org/series/68069/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_7125 -> Patchwork_14870
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_14870 absolutely need to be
>   verified manually.
> 
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_14870, please notify your bug team to allow them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   External URL: https://intel-gfx-ci.01.org/tree/drm-
> tip/Patchwork_14870/index.html
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in
> Patchwork_14870:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@i915_selftest@live_execlists:
> - fi-icl-u3:  NOTRUN -> [DMESG-FAIL][1]
>[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14870/fi-icl-
> u3/igt@i915_selftest@live_execlists.html
> - fi-glk-dsi: [PASS][2] -> [DMESG-FAIL][3]
>[2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-glk-
> dsi/igt@i915_selftest@live_execlists.html
>[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14870/fi-glk-
> dsi/igt@i915_selftest@live_execlists.html
> - fi-kbl-x1275:   [PASS][4] -> [DMESG-FAIL][5]
>[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-kbl-
> x1275/igt@i915_selftest@live_execlists.html
>[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14870/fi-kbl-
> x1275/igt@i915_selftest@live_execlists.html
> - fi-skl-6770hq:  [PASS][6] -> [DMESG-FAIL][7]
>[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-skl-
> 6770hq/igt@i915_selftest@live_execlists.html
>[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14870/fi-skl-
> 6770hq/igt@i915_selftest@live_execlists.html
> 
Same here again, what is really causing these ? 

> 
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * {igt@i915_selftest@live_perf}:
> - {fi-tgl-u2}:NOTRUN -> [INCOMPLETE][8]
>[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14870/fi-tgl-
> u2/igt@i915_selftest@live_perf.html
> 
> 
> Known issues
> 
> 
>   Here are the changes found in Patchwork_14870 that come from known issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_ctx_create@basic-files:
> - fi-bxt-dsi: [PASS][9] -> [INCOMPLETE][10] ([fdo#103927])
>[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-bxt-
> dsi/igt@gem_ctx_cre...@basic-files.html
>[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14870/fi-bxt-
> dsi/igt@gem_ctx_cre...@basic-files.html
> 
> 
>  Possible fixes 
> 
>   * igt@gem_mmap_gtt@basic-small-bo:
> - fi-icl-u3:  [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12]
>[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-icl-
> u3/igt@gem_mmap_...@basic-small-bo.html
>[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14870/fi-icl-
> u3/igt@gem_mmap_...@basic-small-bo.html
> 
>   * igt@i915_selftest@live_execlists:
> - fi-icl-u2:  [INCOMPLETE][13] ([fdo#107713]) -> [PASS][14]
>[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-icl-
> u2/igt@i915_selftest@live_execlists.html
>[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14870/fi-icl-
> u2/igt@i915_selftest@live_execlists.html
> - fi-apl-guc: [DMESG-FAIL][15] -> [PASS][16]
>[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-apl-
> guc/igt@i915_selftest@live_execlists.html
>[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14870/fi-apl-
> guc/igt@i915_selftest@live_execlists.html
> - {fi-icl-dsi}:   [DMESG-FAIL][17] -> [PASS][18]
>[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-icl-
> dsi/igt@i915_selftest@live_execlists.html
>[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14870/fi-icl-
> dsi/igt@i915_selftest@live_execlists.html
> - fi-skl-6260u:   [DMESG-FAIL][19] -> [PASS][20]
>[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-skl-
> 6260u/igt@i915_selftest@live_execlists.html
>[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14870/fi-skl-
> 6260u/igt@i915_selftest@live_execlists.html
> 
>   * 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/aml: Allow SPT PCH for all AML devices

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-gfx  On Behalf Of James
> Ausmus
> Sent: perjantai 18. lokakuuta 2019 4.19
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/aml: Allow SPT PCH 
> for all
> AML devices
> 
> On Fri, Oct 18, 2019 at 01:00:59AM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915/aml: Allow SPT PCH for all AML devices
> > URL   : https://patchwork.freedesktop.org/series/68176/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_7125 -> Patchwork_14867
> > 
> >
> > Summary
> > ---
> >
> >   **FAILURE**
> >
> >   Serious unknown changes coming with Patchwork_14867 absolutely need to be
> >   verified manually.
> >
> >   If you think the reported changes have nothing to do with the changes
> >   introduced in Patchwork_14867, please notify your bug team to allow them
> >   to document this new failure mode, which will reduce false positives in 
> > CI.
> >
> >   External URL:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14867/index.html
> >
> > Possible new issues
> > ---
> >
> >   Here are the unknown changes that may have been introduced in
> Patchwork_14867:
> >
> > ### IGT changes ###
> >
> >  Possible regressions 
> >
> >   * igt@i915_selftest@live_execlists:
> > - fi-icl-u3:  NOTRUN -> [DMESG-FAIL][1]
> >[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14867/fi-icl-
> u3/igt@i915_selftest@live_execlists.html
> > - fi-skl-6600u:   [PASS][2] -> [DMESG-FAIL][3]
> >[2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-skl-
> 6600u/igt@i915_selftest@live_execlists.html
> >[3]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14867/fi-skl-6600u/
> > igt@i915_selftest@live_execlists.html
> 
> Not related at all to this patch, hitting the retest button...
Yes, and if you look pretty much all series on BAT these 
igt@i915_selftest@live_execlists and 
@live_gem_contexts seems to blow lately, Chris, do we know reason why? 

> 
> -James
> 
> >
> >
> > Known issues
> > 
> >
> >   Here are the changes found in Patchwork_14867 that come from known issues:
> >
> > ### IGT changes ###
> >
> >  Issues hit 
> >
> >   * igt@gem_mmap_gtt@basic-read-write:
> > - fi-icl-u3:  [PASS][4] -> [DMESG-WARN][5] ([fdo#107724])
> >[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-icl-
> u3/igt@gem_mmap_...@basic-read-write.html
> >[5]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14867/fi-icl-u3/igt
> > @gem_mmap_...@basic-read-write.html
> >
> >
> >  Possible fixes 
> >
> >   * igt@gem_mmap_gtt@basic-small-bo:
> > - fi-icl-u3:  [DMESG-WARN][6] ([fdo#107724]) -> [PASS][7]
> >[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-icl-
> u3/igt@gem_mmap_...@basic-small-bo.html
> >[7]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14867/fi-icl-u3/igt
> > @gem_mmap_...@basic-small-bo.html
> >
> >   * igt@i915_selftest@live_execlists:
> > - fi-icl-u2:  [INCOMPLETE][8] ([fdo#107713]) -> [PASS][9]
> >[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-icl-
> u2/igt@i915_selftest@live_execlists.html
> >[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14867/fi-icl-
> u2/igt@i915_selftest@live_execlists.html
> > - fi-apl-guc: [DMESG-FAIL][10] -> [PASS][11]
> >[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-apl-
> guc/igt@i915_selftest@live_execlists.html
> >[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14867/fi-apl-
> guc/igt@i915_selftest@live_execlists.html
> > - fi-skl-6260u:   [DMESG-FAIL][12] -> [PASS][13]
> >[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-skl-
> 6260u/igt@i915_selftest@live_execlists.html
> >[13]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14867/fi-skl-6260u/
> > igt@i915_selftest@live_execlists.html
> >
> >   * igt@i915_selftest@live_hangcheck:
> > - fi-icl-u3:  [INCOMPLETE][14] ([fdo#107713] / [fdo#108569]) -> 
> > [PASS][15]
> >[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-icl-
> u3/igt@i915_selftest@live_hangcheck.html
> >[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14867/fi-icl-
> u3/igt@i915_selftest@live_hangcheck.html
> > - {fi-icl-u4}:[INCOMPLETE][16] ([fdo#107713] / [fdo#108569]) -> 
> > [PASS][17]
> >[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-icl-
> u4/igt@i915_selftest@live_hangcheck.html
> >[17]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14867/fi-icl-u4/igt
> > @i915_selftest@live_hangcheck.html
> >
> >   * igt@kms_chamelium@common-hpd-after-suspend:
> > - fi-icl-u2:  [DMESG-WARN][18] ([fdo#102505] / [fdo#110390]) -> 
> > [PASS][19]
> >[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/fi-icl-
> 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Correct the PCH type in irq postinstall

[Saarinen, Jani]

> -Original Message-
> From: Intel-gfx  On Behalf Of Matt 
> Roper
> Sent: torstai 17. lokakuuta 2019 18.47
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Correct the PCH 
> type in irq
> postinstall
> 
> On Thu, Oct 17, 2019 at 01:35:20AM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: Correct the PCH type in irq postinstall
> > URL   : https://patchwork.freedesktop.org/series/68116/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_7114 -> Patchwork_14843
> > 
> >
> > Summary
> > ---
> >
> >   **FAILURE**
> >
> >   Serious unknown changes coming with Patchwork_14843 absolutely need to be
> >   verified manually.
> >
> >   If you think the reported changes have nothing to do with the changes
> >   introduced in Patchwork_14843, please notify your bug team to allow them
> >   to document this new failure mode, which will reduce false positives in 
> > CI.
> >
> >   External URL:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14843/index.html
> >
> > Possible new issues
> > ---
> >
> >   Here are the unknown changes that may have been introduced in
> Patchwork_14843:
> >
> > ### IGT changes ###
> >
> >  Possible regressions 
> >
> >   * igt@i915_selftest@live_execlists:
> > - fi-icl-u2:  [PASS][1] -> [DMESG-FAIL][2]
> >[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7114/fi-icl-
> u2/igt@i915_selftest@live_execlists.html
> >[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14843/fi-icl-
> u2/igt@i915_selftest@live_execlists.html
> > - fi-icl-u3:  [PASS][3] -> [DMESG-FAIL][4]
> >[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7114/fi-icl-
> u3/igt@i915_selftest@live_execlists.html
> >[4]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14843/fi-icl-u3/igt
> > @i915_selftest@live_execlists.html
> 
> These appear to be a GPU hang and "i915/intel_execlists_live_selftests:
> live_timeslice_preempt failed with error -5;" not related to the PCH fix in 
> this patch.

These are seen lately on many series, don’t we have bug about these? 
> 
> >
> >   * igt@i915_selftest@live_gem_contexts:
> > - fi-cfl-8109u:   [PASS][5] -> [DMESG-FAIL][6]
> >[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7114/fi-cfl-
> 8109u/igt@i915_selftest@live_gem_contexts.html
> >[6]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14843/fi-cfl-8109u/
> > igt@i915_selftest@live_gem_contexts.html
> 
> 
> This is some kind of a timeout during a GEM selftest
> ("i915/i915_gem_context_live_selftests: live_parallel_switch failed with 
> error -62").
> Errno -62 is -ETIME.  Also not related to this patch.
Same this too. 


> 
> Will poke CI for a retest.
> 
> 
> Matt
> 
> 
> >
> >
> > Known issues
> > 
> >
> >   Here are the changes found in Patchwork_14843 that come from known issues:
> >
> > ### IGT changes ###
> >
> >  Issues hit 
> >
> >   * igt@prime_busy@basic-wait-after-default:
> > - fi-icl-u3:  [PASS][7] -> [DMESG-WARN][8] ([fdo#107724]) +2 
> > similar issues
> >[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7114/fi-icl-
> u3/igt@prime_b...@basic-wait-after-default.html
> >[8]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14843/fi-icl-u3/igt
> > @prime_b...@basic-wait-after-default.html
> >
> >
> >  Possible fixes 
> >
> >   * igt@gem_ctx_create@basic-files:
> > - fi-bdw-gvtdvm:  [DMESG-WARN][9] -> [PASS][10]
> >[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7114/fi-bdw-
> gvtdvm/igt@gem_ctx_cre...@basic-files.html
> >[10]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14843/fi-bdw-gvtdvm
> > /igt@gem_ctx_cre...@basic-files.html
> >
> >   * igt@gem_flink_basic@double-flink:
> > - fi-icl-u3:  [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +2 
> > similar
> issues
> >[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7114/fi-icl-
> u3/igt@gem_flink_ba...@double-flink.html
> >[12]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14843/fi-icl-u3/igt
> > @gem_flink_ba...@double-flink.html
> >
> >   * igt@i915_selftest@live_execlists:
> > - fi-cfl-guc: [DMESG-FAIL][13] -> [PASS][14]
> >[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7114/fi-cfl-
> guc/igt@i915_selftest@live_execlists.html
> >[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14843/fi-cfl-
> guc/igt@i915_selftest@live_execlists.html
> > - fi-cml-u:   [DMESG-FAIL][15] -> [PASS][16]
> >[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7114/fi-cml-
> u/igt@i915_selftest@live_execlists.html
> >[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14843/fi-cml-
> u/igt@i915_selftest@live_execlists.html
> > - fi-whl-u:   [INCOMPLETE][17] -> [PASS][18]
> >[17]: 

Re: [Intel-gfx] [PATCH 0/4] fix broken state checker and enable state checker for icl+

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Swati
> Sharma
> Sent: perjantai 4. lokakuuta 2019 11.26
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Nautiyal, Ankit K
> 
> Subject: [Intel-gfx] [PATCH 0/4] fix broken state checker and enable state 
> checker
> for icl+
> 
> In this patch series, basically added 3 patches  1. Fixing broken 
> state-checker during
> boot since legacy platforms
> i.e. platforms for which state checker was already enabled  2. Moving
> gamma_enable checks in bit_precision func() to platform
Tested in BSW that was showing fancy colors previously  and now booting to 
console with clean colors.

Tested-by: Jani Saarinen 

> specific func()
>  3. Enabling state checker for ICL and TGL
> 
> Swati Sharma (4):
>   [v2] drm/i915/color: fix broken gamma state-checker during boot
>   drm/i915/color: move check of gamma_enable to specific func/platform
>   [v5] drm/i915/color: Extract icl_read_luts()
>   FOR_TESTING_ONLY: Print rgb values of hw and sw blobs
> 
>  drivers/gpu/drm/i915/display/intel_color.c | 166 ++---
>  drivers/gpu/drm/i915/i915_reg.h|   6 +
>  2 files changed, 152 insertions(+), 20 deletions(-)
> 
> --
> 2.23.0
> 
> ___
> 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/color: fix broken display in icl+

[Saarinen, Jani]

HI, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville 
> Syrjälä
> Sent: tiistai 1. lokakuuta 2019 17.21
> To: Nikula, Jani 
> Cc: intel-gfx@lists.freedesktop.org; Nautiyal, Ankit K 
> 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/color: fix broken display in icl+
> 
> On Tue, Oct 01, 2019 at 11:03:08AM +0300, Jani Nikula wrote:
> > On Tue, 01 Oct 2019, Swati Sharma  wrote:
> > > Premature gamma lut prepration and loading which was getting
> > > reflected in first modeset causing different colors on screen during
> > > boot.
> > >
> > > Issue: In BIOS, gamma is disabled by default. However,
> > > legacy_read_luts() was getting called even before the
> > > legacy_load_luts() which was setting crtc_state->base.gamma_lut and
> > > gamma_lut was programmed with junk values which led to visual
> > > artifacts (different colored screens instead of usual black during boot).
> > >
> > > Fix: Calling read_luts() only when gamma is enabled which will
> > > happen after first modeset.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111809
> >
> > I'm confused. Is there a current problem upstream after the revert
> > 1b8588741fdc ("Revert "drm/i915/color: Extract icl_read_luts()"")?
> >
> > Or does this fix a problem that only occurs in conjunction with the
> > reverted commit? Then say so.
> >
> > Note inline.
> >
> > > Signed-off-by: Swati Sharma 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index f1328c08f4ad..f89aa4bb9f42 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -10528,7 +10528,9 @@ static bool haswell_get_pipe_config(struct
> intel_crtc *crtc,
> > >   i9xx_get_pipe_color_config(pipe_config);
> > >   }
> > >
> > > - intel_color_get_config(pipe_config);
> > > + if ((INTEL_GEN(dev_priv) >= 11 && (pipe_config->gamma_mode &
> POST_CSC_GAMMA_ENABLE)) ||
> > > +(INTEL_GEN(dev_priv) >= 9 && (pipe_config->gamma_enable)))
> > > + intel_color_get_config(pipe_config);
> >
> > Put all of the conditions inside intel_color_get_config().
> 
> In fact inside the .read_luts() since these checks are platform specific.
> 
> Also this check is wrong for CHV since it has a separate enable knob for the 
> CGM LUT
> (gamma_enable only deals with the legacy LUT).
Could this be also reason that on BSW I was able to see some color issue with 
BSW on latest drm-tip still with Tapani? 

> 
> --
> Ville Syrjälä
> Intel
> ___
> 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] Revert "drm/i915/color: Extract icl_read_luts()"

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Swati
> Sharma
> Sent: tiistai 24. syyskuuta 2019 16.58
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; daniel.vet...@ffwll.ch; Nautiyal, 
> Ankit K
> 
> Subject: [Intel-gfx] [PATCH] Revert "drm/i915/color: Extract icl_read_luts()"
> 
> This reverts commit 84af7649188194a74cdd6437235a5e3c86108f0f.
> 
> This is causing problems with the display, displays are all bright colors.

Tested-by: Jani Saarinen 
Bugzilla:  https://bugs.freedesktop.org/show_bug.cgi?id=111809

> 
> Signed-off-by: Swati Sharma 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 126 +++--
>  drivers/gpu/drm/i915/i915_reg.h|   6 -
>  2 files changed, 15 insertions(+), 117 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 402151128e1f..9ab34902663e 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1420,9 +1420,6 @@ static int icl_color_check(struct intel_crtc_state
> *crtc_state)
> 
>  static int i9xx_gamma_precision(const struct intel_crtc_state *crtc_state)  {
> - if (!crtc_state->gamma_enable)
> - return 0;
> -
>   switch (crtc_state->gamma_mode) {
>   case GAMMA_MODE_MODE_8BIT:
>   return 8;
> @@ -1436,9 +1433,6 @@ static int i9xx_gamma_precision(const struct
> intel_crtc_state *crtc_state)
> 
>  static int ilk_gamma_precision(const struct intel_crtc_state *crtc_state)  {
> - if (!crtc_state->gamma_enable)
> - return 0;
> -
>   if ((crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0)
>   return 0;
> 
> @@ -1455,9 +1449,6 @@ static int ilk_gamma_precision(const struct
> intel_crtc_state *crtc_state)
> 
>  static int chv_gamma_precision(const struct intel_crtc_state *crtc_state)  {
> - if (!crtc_state->gamma_enable)
> - return 0;
> -
>   if (crtc_state->cgm_mode & CGM_PIPE_MODE_GAMMA)
>   return 10;
>   else
> @@ -1466,9 +1457,6 @@ static int chv_gamma_precision(const struct
> intel_crtc_state *crtc_state)
> 
>  static int glk_gamma_precision(const struct intel_crtc_state *crtc_state)  {
> - if (!crtc_state->gamma_enable)
> - return 0;
> -
>   switch (crtc_state->gamma_mode) {
>   case GAMMA_MODE_MODE_8BIT:
>   return 8;
> @@ -1480,39 +1468,21 @@ static int glk_gamma_precision(const struct
> intel_crtc_state *crtc_state)
>   }
>  }
> 
> -static int icl_gamma_precision(const struct intel_crtc_state *crtc_state) -{
> - if ((crtc_state->gamma_mode & POST_CSC_GAMMA_ENABLE) == 0)
> - return 0;
> -
> - switch (crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) {
> - case GAMMA_MODE_MODE_8BIT:
> - return 8;
> - case GAMMA_MODE_MODE_10BIT:
> - return 10;
> - case GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED:
> - return 16;
> - default:
> - MISSING_CASE(crtc_state->gamma_mode);
> - return 0;
> - }
> -
> -}
> -
>  int intel_color_get_gamma_bit_precision(const struct intel_crtc_state 
> *crtc_state)
> {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> 
> + if (!crtc_state->gamma_enable)
> + return 0;
> +
>   if (HAS_GMCH(dev_priv)) {
>   if (IS_CHERRYVIEW(dev_priv))
>   return
> chv_gamma_precision(crtc_state);
>   else
>   return
> i9xx_gamma_precision(crtc_state);
>   } else {
> - if (INTEL_GEN(dev_priv) >= 11)
> - return
> icl_gamma_precision(crtc_state);
> - else if (IS_CANNONLAKE(dev_priv) ||
> IS_GEMINILAKE(dev_priv))
> + if (IS_CANNONLAKE(dev_priv) ||
> IS_GEMINILAKE(dev_priv))
>   return
> glk_gamma_precision(crtc_state);
>   else if (IS_IRONLAKE(dev_priv))
>   return
> ilk_gamma_precision(crtc_state); @@ -1543,20 +1513,6 @@ static bool
> intel_color_lut_entry_equal(struct drm_color_lut *lut1,
>   return true;
>  }
> 
> -static bool intel_color_lut_entry_multi_equal(struct drm_color_lut *lut1,
> -   struct
> drm_color_lut *lut2,
> -   int
> lut_size, u32 err)
> -{
> - int i;
> -
> - for (i = 0; i < 9; i++) {
> - if (!err_check([i], [i], err))
> - return false;
> - }
> -
> - return true;
> -}
> -
>  bool intel_color_lut_equal(struct drm_property_blob *blob1,
>  struct drm_property_blob *blob2,
>  u32 gamma_mode, u32 bit_precision)
> @@ -1575,8 +1531,16 @@ bool intel_color_lut_equal(struct drm_property_blob
> *blob1,
>   lut_size2 = drm_color_lut_size(blob2);
> 
>   /* check sw and hw lut 

Re: [Intel-gfx] [v4][PATCH 2/3] drm/i915/color: Extract icl_read_luts()

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani 
> Nikula
> Sent: tiistai 24. syyskuuta 2019 15.18
> To: Sharma, Swati2 ; intel-gfx@lists.freedesktop.org
> Cc: daniel.vet...@ffwll.ch; Nautiyal, Ankit K 
> Subject: Re: [Intel-gfx] [v4][PATCH 2/3] drm/i915/color: Extract 
> icl_read_luts()
> 
> On Sun, 22 Sep 2019, Swati Sharma  wrote:
> > For icl+, have hw read out to create hw blob of gamma lut values. icl+
> > platforms supports multi segmented gamma mode by default, add hw lut
> > creation for this mode.
> >
> > This will be used to validate gamma programming using dsb (display
> > state buffer) which is a tgl specific feature.
> >
> > Major change done-removal of readouts of coarse and fine segments
> > because PAL_PREC_DATA register isn't giving propoer values.
> > State checker limited only to "fine segment"
> >
> > v2: -readout code for multisegmented gamma has to come
> >  up with some intermediate entries that aren't preserved
> >  in hardware (Jani N)
> > -linear interpolation (Ville)
> > -moved common code to check gamma_enable to specific funcs,
> >  since icl doesn't support that
> > v3: -use u16 instead of __u16 [Jani N]
> > -used single lut [Jani N]
> > -improved and more readable for loops [Jani N]
> > -read values directly to actual locations and then fill gaps [Jani N]
> > -moved cleaning to patch 1 [Jani N]
> > -renamed icl_read_lut_multi_seg() to icl_read_lut_multi_segment to
> >  make it similar to icl_load_luts()
> > -renamed icl_compute_interpolated_gamma_blob() to
> >  icl_compute_interpolated_gamma_lut_values() more sensible, I
> > guess
> > v4: -removed interpolated func for creating gamma lut values
> > -removed readouts of fine and coarse segments, failure to read 
> > PAL_PREC_DATA
> >  correctly
> >
> > Signed-off-by: Swati Sharma 
> > ---
> >  drivers/gpu/drm/i915/display/intel_color.c | 126 
> > +--
> --
> >  drivers/gpu/drm/i915/i915_reg.h|   6 ++
> >  2 files changed, 117 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index f774938..299ada5b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -1371,6 +1371,9 @@ static int icl_color_check(struct
> > intel_crtc_state *crtc_state)
> >
> >  static int i9xx_gamma_precision(const struct intel_crtc_state
> > *crtc_state)  {
> > +   if (!crtc_state->gamma_enable)
> > +   return 0;
> > +
> > switch (crtc_state->gamma_mode) {
> > case GAMMA_MODE_MODE_8BIT:
> > return 8;
> > @@ -1384,6 +1387,9 @@ static int i9xx_gamma_precision(const struct
> > intel_crtc_state *crtc_state)
> >
> >  static int ilk_gamma_precision(const struct intel_crtc_state
> > *crtc_state)  {
> > +   if (!crtc_state->gamma_enable)
> > +   return 0;
> > +
> > if ((crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0)
> > return 0;
> >
> > @@ -1400,6 +1406,9 @@ static int ilk_gamma_precision(const struct
> > intel_crtc_state *crtc_state)
> >
> >  static int chv_gamma_precision(const struct intel_crtc_state
> > *crtc_state)  {
> > +   if (!crtc_state->gamma_enable)
> > +   return 0;
> > +
> > if (crtc_state->cgm_mode & CGM_PIPE_MODE_GAMMA)
> > return 10;
> > else
> > @@ -1408,6 +1417,9 @@ static int chv_gamma_precision(const struct
> > intel_crtc_state *crtc_state)
> >
> >  static int glk_gamma_precision(const struct intel_crtc_state
> > *crtc_state)  {
> > +   if (!crtc_state->gamma_enable)
> > +   return 0;
> > +
> > switch (crtc_state->gamma_mode) {
> > case GAMMA_MODE_MODE_8BIT:
> > return 8;
> > @@ -1419,21 +1431,39 @@ static int glk_gamma_precision(const struct
> intel_crtc_state *crtc_state)
> > }
> >  }
> >
> > +static int icl_gamma_precision(const struct intel_crtc_state
> > +*crtc_state) {
> > +   if ((crtc_state->gamma_mode & POST_CSC_GAMMA_ENABLE) == 0)
> > +   return 0;
> > +
> > +   switch (crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) {
> > +   case GAMMA_MODE_MODE_8BIT:
> > +   return 8;
> > +   case GAMMA_MODE_MODE_10BIT:
> > +   return 10;
> > +   case GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED:
> > +   return 16;
> > +   default:
> > +   MISSING_CASE(crtc_state->gamma_mode);
> > +   return 0;
> > +   }
> > +
> > +}
> > +
> >  int intel_color_get_gamma_bit_precision(const struct intel_crtc_state
> > *crtc_state)  {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >
> > -   if (!crtc_state->gamma_enable)
> > -   return 0;
> > -
> > if (HAS_GMCH(dev_priv)) {
> > if (IS_CHERRYVIEW(dev_priv))
> > return
> chv_gamma_precision(crtc_state);
> > else
> >   

Re: [Intel-gfx] [PATCH] drm/i915/cml: Add second PCH ID for CMP

[Saarinen, Jani]

HI, 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
> Matt
> Roper
> Sent: tiistai 17. syyskuuta 2019 3.35
> To: Lucas De Marchi 
> Cc: Intel Graphics 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/cml: Add second PCH ID for CMP
> 
> On Mon, Sep 16, 2019 at 05:26:10PM -0700, Lucas De Marchi wrote:
> > On Mon, Sep 16, 2019 at 4:33 PM Matt Roper 
> wrote:
> > >
> > > The CMP PCH ID we have in the driver is correct for the CML-U
> > > machines we have in our CI system, but the CML-S and CML-H CI
> > > machines appear to use a
> >
> > CML-S is back to life, but CML-H is still failing. Is CML-H actually
> > using the same PCH?
> >
> 
> According to the CI's lspci output for each machine, CML-S has 0x0681 and 
> CML-H
> has 0x068C.  We only care about the upper 9 bits, so a DEVICE_ID_TYPE of 
> 0x0680
> should handle both of them.
> 
> It looks like CML-H wasn't even attempted by CI (no failure for igt@runner 
> like we
> had before, just no results at all for anything).
> The CI BAT email say it wasn't a participating host (along with a handful of 
> others),
> but I'm not sure what leads to that --- does it just mean the platform has 
> been
> temporarily taken offline?
No, it probably just did not boot properly or something else, Tomi? 
It did something: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14423/fi-cml-h/ ... 

> 
> 
> Matt
> 
> > Lucas De Marchi
> >
> > > different PCH ID, leading our driver to detect no PCH for them.
> > >
> > > Cc: Rodrigo Vivi 
> > > Cc: Anusha Srivatsa 
> > > References: 729ae330a0f2e2 ("drm/i915/cml: Introduce Comet Lake
> > > PCH")
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111461
> > > Signed-off-by: Matt Roper 
> > > ---
> > >  drivers/gpu/drm/i915/intel_pch.c | 1 +
> > > drivers/gpu/drm/i915/intel_pch.h | 1 +
> > >  2 files changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_pch.c
> > > b/drivers/gpu/drm/i915/intel_pch.c
> > > index fa864d8f2b73..15f8bff141f9 100644
> > > --- a/drivers/gpu/drm/i915/intel_pch.c
> > > +++ b/drivers/gpu/drm/i915/intel_pch.c
> > > @@ -69,6 +69,7 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
> unsigned short id)
> > > WARN_ON(!IS_CANNONLAKE(dev_priv) && 
> > > !IS_COFFEELAKE(dev_priv));
> > > return PCH_CNP;
> > > case INTEL_PCH_CMP_DEVICE_ID_TYPE:
> > > +   case INTEL_PCH_CMP2_DEVICE_ID_TYPE:
> > > DRM_DEBUG_KMS("Found Comet Lake PCH (CMP)\n");
> > > WARN_ON(!IS_COFFEELAKE(dev_priv));
> > > /* CometPoint is CNP Compatible */ diff --git
> > > a/drivers/gpu/drm/i915/intel_pch.h
> > > b/drivers/gpu/drm/i915/intel_pch.h
> > > index e6a2d65f19c6..c29c81ec7971 100644
> > > --- a/drivers/gpu/drm/i915/intel_pch.h
> > > +++ b/drivers/gpu/drm/i915/intel_pch.h
> > > @@ -41,6 +41,7 @@ enum intel_pch {
> > >  #define INTEL_PCH_CNP_DEVICE_ID_TYPE   0xA300
> > >  #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
> > >  #define INTEL_PCH_CMP_DEVICE_ID_TYPE   0x0280
> > > +#define INTEL_PCH_CMP2_DEVICE_ID_TYPE  0x0680
> > >  #define INTEL_PCH_ICP_DEVICE_ID_TYPE   0x3480
> > >  #define INTEL_PCH_MCC_DEVICE_ID_TYPE   0x4B00
> > >  #define INTEL_PCH_MCC2_DEVICE_ID_TYPE  0x3880
> > > --
> > > 2.21.0
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >
> >
> > --
> > Lucas De Marchi
> 
> --
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
> (916) 356-2795
> ___
> 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 v6 3/7] drm: Add DisplayPort colorspace property

[Saarinen, Jani]

Hi,

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Gwan-gyeong Mun
> Sent: torstai 12. syyskuuta 2019 6.25
> To: intel-gfx@lists.freedesktop.org
> Cc: imir...@alum.mit.edu; dri-de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v6 3/7] drm: Add DisplayPort colorspace property
> 
> Becasue between HDMI and DP have different colorspaces, it renames
Typo ^^

> drm_mode_create_colorspace_property() function to
> drm_mode_create_hdmi_colorspace_property() function for HDMI connector.
> And it adds drm_mode_create_dp_colorspace_property() function for creating of 
> DP
> colorspace property.
> In order to apply changed and added drm api, i915 driver has channged.
> 
> v3: Addressed review comments from Ville
> - Add new colorimetry options for DP 1.4a spec.
> - Separate set of colorimetry enum values for DP.
> v4: Add additional comments to struct drm_prop_enum_list.
> Polishing an enum string of struct drm_prop_enum_list
> v5: Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI prefix and
> DP abbreviations.
> Add missed variables on dp_colorspaces.
> Fix typo. [Uma]
> v6: Addressed review comments from Ilia and Ville
>- Split drm_mode_create_colorspace_property() to DP and HDMI connector.
> 
> Signed-off-by: Gwan-gyeong Mun 
> Reviewed-by: Uma Shankar 
> ---
>  drivers/gpu/drm/drm_connector.c   | 110 +++---
>  .../gpu/drm/i915/display/intel_connector.c|  21 +++-
>  include/drm/drm_connector.h   |  11 +-
>  3 files changed, 121 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 4c766624b20d..48f4058c6d96 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -882,6 +882,47 @@ static const struct drm_prop_enum_list
> hdmi_colorspaces[] = {
>   { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-
> P3_RGB_Theater" },  };
> 
> +/*
> + * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel
> +Encoding/Colorimetry
> + * Format Table 2-120
> + */
> +static const struct drm_prop_enum_list dp_colorspaces[] = {
> + /* For Default case, driver will set the colorspace */
> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> + /* Colorimetry based on sRGB (IEC 61966-2-1) */
> + { DRM_MODE_COLORIMETRY_CEA_RGB, "CEA_RGB" },
> + { DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED,
> "RGB_Wide_Gamut_Fixed_Point" },
> + /* Colorimetry based on scRGB (IEC 61966-2-2) */
> + { DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT,
> "RGB_Wide_Gamut_Floating_Point" },
> + /* Colorimetry based on IEC 61966-2-5 */
> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> + /* Colorimetry based on SMPTE RP 431-2 */
> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> + { DRM_MODE_COLORIMETRY_RGB_CUSTOM_COLOR_PROFILE,
> "RGB_Custom_Color_Profile" },
> + /* Colorimetry based on ITU-R BT.2020 */
> + { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> + { DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
> + { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> + { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> + { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
> + /* Colorimetry based on IEC 61966-2-5 [33] */
> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
> + /* Colorimetry based on ITU-R BT.2020 */
> + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
> + /* Colorimetry based on ITU-R BT.2020 */
> + { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> + /*
> +  * Colorimetry based on Digital Imaging and Communications in Medicine
> +  * (DICOM) Part 14: Grayscale Standard Display Function
> +  */
> + { DRM_MODE_COLORIMETRY_Y_ONLY_DICOM_P14_GRAYSCALE,
> "Y_ONLY_DICOM_Part_14_Grayscale" },
> + { DRM_MODE_COLORIMETRY_RAW_CUSTOM_COLOR_PROFILE,
> +"Raw_Custom_Color_Profile" }, };
> +
>  /**
>   * DOC: standard connector properties
>   *
> @@ -1674,7 +1715,6 @@
> EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
>   * DOC: standard connector properties
>   *
>   * Colorspace:
> - * drm_mode_create_colorspace_property - create colorspace property
>   * This property helps select a suitable colorspace based on the sink
>   * capability. Modern sink devices support wider gamut like BT2020.
>   * This helps switch to BT2020 mode if the BT2020 encoded video stream
> @@ -1694,32 +1734,68 @@
> EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
>   *  - This property is just to inform sink what colorspace
>   *source is trying to drive.
>   *
> + * Becasue between HDMI and DP have different colorspaces,
> + * 

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Fix CD2X pipe select masking during cdclk sanitation

[Saarinen, Jani]

HI, 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
> Chris
> Wilson
> Sent: keskiviikko 11. syyskuuta 2019 18.09
> To: Roper, Matthew D ; Ville Syrjala
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/4] drm/i915: Fix CD2X pipe select masking 
> during
> cdclk sanitation
> 
> Quoting Matt Roper (2019-09-11 16:00:44)
> > I'm confused why pre-merge CI flagged the results as a success if TGL
> > was hitting this?
> 
> We've only just (Fri) got CI's Tigerlake surviving boot, so a second failure 
> during boot
> would have been missed. For the summary report, Tigerlake is currently 
> suppressed
> as it is not yet proven itself as being a stable result. (Which is a bit of a 
> nuisance as
> you have to remind yourself to actually check the details.) -Chris
Exactly. 

> ___
> 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 2/4] drm/i915: Fix CD2X pipe select masking during cdclk sanitation

[Saarinen, Jani]

HI, 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
> Matt
> Roper
> Sent: keskiviikko 11. syyskuuta 2019 18.01
> To: Ville Syrjala 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/4] drm/i915: Fix CD2X pipe select masking 
> during
> cdclk sanitation
> 
> On Wed, Sep 11, 2019 at 04:31:27PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > We're forgetting to mask off all three pipe select bits from the
> > CDCLK_CTL value on icl+ which may lead to the extra bit being left in.
> > That will cause us to consider the current hardware cdclk state as
> > invalid, and we proceed to sanitize it even though the hardware may
> > have active pipes and whatnot.
> >
> > Fix up the mask so we get rid of all three pipe select bits and thus
> > hopefully no longer sanitize cdclk when it's already correctly
> > programmed.
> >
> > Cc: Matt Roper 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111641
> > Fixes: 0c1279b58fc7 ("drm/i915: Consolidate {bxt,cnl,icl}_init_cdclk")
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Matt Roper 
> 
> I'm confused why pre-merge CI flagged the results as a success if TGL was 
> hitting
> this?
It died also on CI: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14345/?
Martin, Tomi can you explain? 

> 
> 
> Matt
> 
> > ---
> >  drivers/gpu/drm/i915/display/intel_cdclk.c | 42
> > --
> >  1 file changed, 23 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 6b75d2a91cd9..f59a6f775177 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1464,6 +1464,26 @@ static void cnl_cdclk_pll_enable(struct
> drm_i915_private *dev_priv, int vco)
> > dev_priv->cdclk.hw.vco = vco;
> >  }
> >
> > +static u32 bxt_cdclk_cd2x_pipe(struct drm_i915_private *dev_priv,
> > +enum pipe pipe) {
> > +   if (INTEL_GEN(dev_priv) >= 12) {
> > +   if (pipe == INVALID_PIPE)
> > +   return TGL_CDCLK_CD2X_PIPE_NONE;
> > +   else
> > +   return TGL_CDCLK_CD2X_PIPE(pipe);
> > +   } else if (INTEL_GEN(dev_priv) >= 11) {
> > +   if (pipe == INVALID_PIPE)
> > +   return ICL_CDCLK_CD2X_PIPE_NONE;
> > +   else
> > +   return ICL_CDCLK_CD2X_PIPE(pipe);
> > +   } else {
> > +   if (pipe == INVALID_PIPE)
> > +   return BXT_CDCLK_CD2X_PIPE_NONE;
> > +   else
> > +   return BXT_CDCLK_CD2X_PIPE(pipe);
> > +   }
> > +}
> > +
> >  static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> >   const struct intel_cdclk_state *cdclk_state,
> >   enum pipe pipe)
> > @@ -1534,24 +1554,8 @@ static void bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
> > bxt_de_pll_enable(dev_priv, vco);
> > }
> >
> > -   val = divider | skl_cdclk_decimal(cdclk);
> > -
> > -   if (INTEL_GEN(dev_priv) >= 12) {
> > -   if (pipe == INVALID_PIPE)
> > -   val |= TGL_CDCLK_CD2X_PIPE_NONE;
> > -   else
> > -   val |= TGL_CDCLK_CD2X_PIPE(pipe);
> > -   } else if (INTEL_GEN(dev_priv) >= 11) {
> > -   if (pipe == INVALID_PIPE)
> > -   val |= ICL_CDCLK_CD2X_PIPE_NONE;
> > -   else
> > -   val |= ICL_CDCLK_CD2X_PIPE(pipe);
> > -   } else {
> > -   if (pipe == INVALID_PIPE)
> > -   val |= BXT_CDCLK_CD2X_PIPE_NONE;
> > -   else
> > -   val |= BXT_CDCLK_CD2X_PIPE(pipe);
> > -   }
> > +   val = divider | skl_cdclk_decimal(cdclk) |
> > +   bxt_cdclk_cd2x_pipe(dev_priv, pipe);
> >
> > /*
> >  * Disable SSA Precharge when CD clock frequency < 500 MHz, @@
> > -1620,7 +1624,7 @@ static void bxt_sanitize_cdclk(struct drm_i915_private
> *dev_priv)
> >  * dividers both synching to an active pipe, or asynchronously
> >  * (PIPE_NONE).
> >  */
> > -   cdctl &= ~BXT_CDCLK_CD2X_PIPE_NONE;
> > +   cdctl &= ~bxt_cdclk_cd2x_pipe(dev_priv, INVALID_PIPE);
> >
> > /* Make sure this is a legal cdclk value for the platform */
> > cdclk = bxt_calc_cdclk(dev_priv, dev_priv->cdclk.hw.cdclk);
> > --
> > 2.21.0
> >
> 
> --
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
> (916) 356-2795
> ___
> 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: success for cdclk consolidation and rework for BXT-TGL (rev6)

[Saarinen, Jani]

Hi, 


> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
> Matt
> Roper
> Sent: keskiviikko 11. syyskuuta 2019 6.43
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✓ Fi.CI.IGT: success for cdclk consolidation and 
> rework for
> BXT-TGL (rev6)
> 
> On Tue, Sep 10, 2019 at 11:55:40PM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: cdclk consolidation and rework for BXT-TGL (rev6)
> > URL   : https://patchwork.freedesktop.org/series/66365/
> > State : success
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_6861_full -> Patchwork_14345_full
> > 
> >
> > Summary
> > ---
> >
> >   **SUCCESS**
> >
> >   No regressions found.
> >
> 
> Applied to dinq.  Thanks Ville for the reviews.
Matt, this seems to break TGL now. 
See: 
http://gfx-ci.fi.intel.com/tree/drm-tip/CI_DRM_6864/fi-tgl-u/boot0.txt
WARN_ON_ONCE(!crtc_clock || max_dotclk < crtc_clock)
<4>[   11.971515] WARNING: CPU: 6 PID: 331 at 
drivers/gpu/drm/i915/display/intel_display.c:14556 skl_max_scale+0xa4/0xb0 
[i915]

And
http://gfx-ci.fi.intel.com/tree/drm-tip/CI_DRM_6864/git-log-oneline.txt
Martin, is there bug already? 


> 
> Matt
> 
> >
> >
> > New tests
> > -
> >
> >   New tests have been introduced between CI_DRM_6861_full and
> Patchwork_14345_full:
> >
> > ### New Piglit tests (7) ###
> >
> >   * spec@arb_gpu_shader5@texturegather@vs-rgba-2-float-2darray:
> > - Statuses : 1 incomplete(s)
> > - Exec time: [0.0] s
> >
> >   * spec@arb_gpu_shader5@texturegather@vs-rgba-3-float-2darray:
> > - Statuses : 1 incomplete(s)
> > - Exec time: [0.0] s
> >
> >   * spec@arb_gpu_shader5@texturegatheroffset@vs-rgba-0-float-2darray:
> > - Statuses : 1 incomplete(s)
> > - Exec time: [0.0] s
> >
> >   * spec@arb_gpu_shader5@texturegatheroffset@vs-rgba-0-float-2darray-const:
> > - Statuses : 1 incomplete(s)
> > - Exec time: [0.0] s
> >
> >   * spec@arb_gpu_shader5@texturegatheroffsets@vs-rgba-1-float-2d:
> > - Statuses : 1 incomplete(s)
> > - Exec time: [0.0] s
> >
> >   * spec@arb_gpu_shader5@texturegatheroffsets@vs-rgba-2-float-2d:
> > - Statuses : 1 incomplete(s)
> > - Exec time: [0.0] s
> >
> >   * spec@arb_gpu_shader5@texturegatheroffsets@vs-rgba-3-float-2d:
> > - Statuses : 1 incomplete(s)
> > - Exec time: [0.0] s
> >
> >
> >
> > Known issues
> > 
> >
> >   Here are the changes found in Patchwork_14345_full that come from known
> issues:
> >
> > ### IGT changes ###
> >
> >  Issues hit 
> >
> >   * igt@gem_busy@basic-hang-rcs0:
> > - shard-glk:  [PASS][1] -> [INCOMPLETE][2] ([fdo#103359] / 
> > [k.org#198133])
> >[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/shard-
> glk6/igt@gem_b...@basic-hang-rcs0.html
> >[2]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14345/shard-glk3/ig
> > t@gem_b...@basic-hang-rcs0.html
> >
> >   * igt@gem_ctx_isolation@rcs0-s3:
> > - shard-apl:  [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +4 
> > similar issues
> >[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/shard-
> apl4/igt@gem_ctx_isolat...@rcs0-s3.html
> >[4]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14345/shard-apl7/ig
> > t@gem_ctx_isolat...@rcs0-s3.html
> >
> >   * igt@gem_exec_schedule@preempt-contexts-bsd2:
> > - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +14 similar 
> > issues
> >[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/shard-
> iclb4/igt@gem_exec_sched...@preempt-contexts-bsd2.html
> >[6]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14345/shard-iclb6/i
> > gt@gem_exec_sched...@preempt-contexts-bsd2.html
> >
> >   * igt@gem_exec_schedule@preempt-hang-vebox:
> > - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713])
> >[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/shard-
> iclb1/igt@gem_exec_sched...@preempt-hang-vebox.html
> >[8]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14345/shard-iclb7/i
> > gt@gem_exec_sched...@preempt-hang-vebox.html
> >
> >   * igt@gem_exec_schedule@reorder-wide-bsd:
> > - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#111325]) +9 similar 
> > issues
> >[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/shard-
> iclb3/igt@gem_exec_sched...@reorder-wide-bsd.html
> >[10]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14345/shard-iclb4/i
> > gt@gem_exec_sched...@reorder-wide-bsd.html
> >
> >   * igt@i915_pm_rpm@modeset-stress-extra-wait:
> > - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713] /
> [fdo#108840])
> >[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6861/shard-
> iclb7/igt@i915_pm_...@modeset-stress-extra-wait.html
> >[12]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14345/shard-iclb2/i
> > gt@i915_pm_...@modeset-stress-extra-wait.html
> 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ehl: Allow combo PHY A to drive a third external display (rev3)

[Saarinen, Jani]

HI, 


> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Matt Roper
> Sent: keskiviikko 19. kesäkuuta 2019 21.31
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ehl: Allow combo 
> PHY A to
> drive a third external display (rev3)
> 
> On Wed, Jun 19, 2019 at 01:28:04PM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915/ehl: Allow combo PHY A to drive a third external display 
> > (rev3)
> > URL   : https://patchwork.freedesktop.org/series/62131/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_6297_full -> Patchwork_13334_full
> > 
> >
> > Summary
> > ---
> >
> >   **FAILURE**
> >
> >   Serious unknown changes coming with Patchwork_13334_full absolutely need
> to be
> >   verified manually.
> >
> >   If you think the reported changes have nothing to do with the changes
> >   introduced in Patchwork_13334_full, please notify your bug team to allow
> them
> >   to document this new failure mode, which will reduce false positives in 
> > CI.
> >
> >
> >
> > Possible new issues
> > ---
> >
> >   Here are the unknown changes that may have been introduced in
> Patchwork_13334_full:
> >
> > ### IGT changes ###
> >
> >  Possible regressions 
> >
> >   * igt@runner@aborted:
> > - shard-kbl:  NOTRUN -> ([FAIL][1], [FAIL][2], [FAIL][3], 
> > [FAIL][4], [FAIL][5],
> [FAIL][6], [FAIL][7]) ([fdo#108903] / [fdo#108904] / [fdo#108905] / 
> [fdo#110938])
> >[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/shard-
> kbl4/igt@run...@aborted.html
> >[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/shard-
> kbl4/igt@run...@aborted.html
> >[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/shard-
> kbl4/igt@run...@aborted.html
> >[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/shard-
> kbl7/igt@run...@aborted.html
> >[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/shard-
> kbl4/igt@run...@aborted.html
> >[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/shard-
> kbl4/igt@run...@aborted.html
> >[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/shard-
> kbl4/igt@run...@aborted.html
> 
> I'm not sure I understand what CI is saying here; link #4 here gives a
> 404, and the other six links are all the same, but show empty boot/dmesg
> logs.  There are some fdo bug numbers reported here for known bugs, so I
> guess those are what CI detected, even though the logfiles themselves
> appear to be empty?
It tries to say that each of these run none of the run was done as  eg.
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/shard-kbl4/run33.log
It seems that CI files are not sent. Anyway on this normally dmesg logs should 
tell that there has been kernel tainted and that is why
no tests run on these runs...perhaps, Tomi, Martin?  

> 
> Anyway, whatever is going on with this KBL system doesn't appear to be
> caused by my patch since I'm updating code that only runs on gen11
> platforms.
> 
> The rest of the CI results look okay, so applied to dinq.  Thanks Ville
> for the review.
> 
> 
> Matt
> 
> 
> >
> >
> > Known issues
> > 
> >
> >   Here are the changes found in Patchwork_13334_full that come from known
> issues:
> >
> > ### IGT changes ###
> >
> >  Issues hit 
> >
> >   * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
> > - shard-snb:  [PASS][8] -> [DMESG-WARN][9] ([fdo#110913 ])
> >[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6297/shard-
> snb5/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html
> >[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/shard-
> snb6/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html
> >
> >   * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
> > - shard-kbl:  [PASS][10] -> [DMESG-WARN][11] ([fdo#110913 ])
> >[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6297/shard-
> kbl4/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
> >[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/shard-
> kbl4/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
> > - shard-apl:  [PASS][12] -> [DMESG-WARN][13] ([fdo#110913 ]) +2 
> > similar
> issues
> >[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6297/shard-
> apl8/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
> >[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/shard-
> apl4/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
> >
> >   * igt@i915_selftest@live_evict:
> > - shard-kbl:  [PASS][14] -> [INCOMPLETE][15] ([fdo#103665] /
> [fdo#110938])
> >[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6297/shard-
> kbl6/igt@i915_selftest@live_evict.html
> >[15]: 

Re: [Intel-gfx] [PATCH] drm/i915: remove duplicated WaDisableBankHangMode:icl

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: torstai 30. toukokuuta 2019 18.23
> To: Ceraolo Spurio, Daniele ; intel-
> g...@lists.freedesktop.org
> Cc: Ceraolo Spurio, Daniele ; Saarinen, Jani
> 
> Subject: Re: [PATCH] drm/i915: remove duplicated WaDisableBankHangMode:icl
> 
> Quoting Daniele Ceraolo Spurio (2019-05-30 16:16:21)
> > Accidentally added during the merge of drm-next.
> 
> It's a dim issue. A dinq patch cherry-picked into dif that git isn't 
> eliminating the
> duplication when dim build tips.
> https://drm.pages.freedesktop.org/maintainer-tools/drm-tip.html#resolving-
> conflicts-when-rebuilding-drm-tip
> See "Fixing Silent Conflicts"
> 
> Note already fixed up.
When this can be seen also in CI? 

> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [CI 0/5] Refactor to expand subslice mask

[Saarinen, Jani]

Hi, 


> -Original Message-
> From: Summers, Stuart
> Sent: keskiviikko 29. toukokuuta 2019 19.02
> To: Saarinen, Jani ; Ceraolo Spurio, Daniele
> ; Navare, Manasi D
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [CI 0/5] Refactor to expand subslice mask
> 
> On Wed, 2019-05-29 at 07:21 -0700, Daniele Ceraolo Spurio wrote:
> >
> > On 5/28/19 11:48 PM, Saarinen, Jani wrote:
> > > Hi,
> > >
> > > > -Original Message-
> > > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org]
> > > > On Behalf Of
> > > > Summers, Stuart
> > > > Sent: tiistai 28. toukokuuta 2019 21.33
> > > > To: Navare, Manasi D 
> > > > Cc: intel-gfx@lists.freedesktop.org
> > > > Subject: Re: [Intel-gfx] [CI 0/5] Refactor to expand subslice
> > > > mask
> > > >
> > > > On Tue, 2019-05-28 at 11:32 -0700, Manasi Navare wrote:
> > > > > Pushed to dinq, thanks for the patches and the reviews!
> > > >
> > > > Thanks for the push Manasi and the reviews Daniele and others!
> > >
> > > This broke all the ICL systems because CI data was not looked that
> > > they did not actually even boot at all.
> > > All ICL's in BAT and whole ICL shards.
> > >
> >
> > Can we change the CI reply for the case where there are extra
> > missing
> > machines compared to the reference run from SUCCESS to WARNING or
> > something like that, so people have a clearer indication that
> > something
> > might have gone wrong?
> 
> I agree here. I'm sure with time and experience these types of things
> will get easier to parse, but this was very unobvious to me when
> posting. I have no problem reworking, but would really appreciate a
> solution to this from the CI side to ensure we don't hit this type of
> thing in the future.
Sure, CI team already discussed on this. 
But going forward. Can you fix this still today that ICL's systems are green 
not orange on ci-grid.
So would be good to get to the state that was on CI_DRM_6158. 
Reference eg. : https://intel-gfx-ci.01.org/tree/drm-tip/fi-icl-u2.html so 
clearly after module reload we fail.
<3> [415.887946] [drm:_wa_add [i915]] *ERROR* Discarding overwritten w/a for 
reg 7034 (mask: , value: 8280)

Br,
Jani
> 
> Thanks,
> Stuart
> 
> >
> > Daniele
> >
> > >
> > > >
> > > > -Stuart
> > > >
> > > > >
> > > > > Regards
> > > > > Manasi
> > > > >
> > > > > On Fri, May 24, 2019 at 08:40:17AM -0700, Stuart Summers wrote:
> > > > > > This patch series contains a few code clean-up patches,
> > > > > > followed by
> > > > > > a patch which changes the storage of the subslice mask to
> > > > > > better
> > > > > > match the userspace access through the
> > > > > > I915_QUERY_TOPOLOGY_INFO
> > > > > > ioctl. The index into the subslice_mask array is then
> > > > > > calculated:
> > > > > >slice * subslice stride + subslice index / 8
> > > > > >
> > > > > > v2: fix i915_pm_sseu test failure
> > > > > > v3: no changes to patches in the series, just resending to
> > > > > > pick up
> > > > > >  in CI correctly
> > > > > > v4: rebase
> > > > > > v5: fix header test
> > > > > > v6: address review comments from Jari
> > > > > >  address minor checkpatch warning in existing code
> > > > > >  use eu_stride for EU div-by-8
> > > > > > v7: another rebase
> > > > > > v8: address review comments from Tvrtko and Daniele
> > > > > > v9: address review comments from Daniele
> > > > > > v10: add reviewed-by on last patch with minor suggested
> > > > > > change,
> > > > > >   rebase, and repost for CI
> > > > > >
> > > > > > Stuart Summers (5):
> > > > > >drm/i915: Use local variable for SSEU info in GETPARAM
> > > > > > ioctl
> > > > > >drm/i915: Add macro for SSEU stride calculation
> > > > > >drm/i915: Move calculation of subslices per slice to new
> > > > > > function
> > > > > >drm/i915: Refactor sseu helper functions
> > > > > >drm/i915: Expand subslice mask
>

Re: [Intel-gfx] [PATCH] drm/i915: Fix off-by-one in looking up icl sseu slice

[Saarinen, Jani]

HI, 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
> Jani
> Nikula
> Sent: keskiviikko 29. toukokuuta 2019 17.23
> To: Chris Wilson ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix off-by-one in looking up icl 
> sseu slice
> 
> On Wed, 29 May 2019, Jani Nikula  wrote:
> > On Tue, 28 May 2019, Chris Wilson  wrote:
> >> We want the index corresponding to the set bit but fls() returns the
> >> 1-index value.
> >>
> >> Otherwise, we trigger the sanitycheck
> >>intel_sseu_get_subslices:46 GEM_BUG_ON(slice >= sseu->max_slices)
> >> when we look up the invalid slice.
> >>
> >> The only remaining question then is just how reliable the rest of
> >> intel_calculate_mcr_s_ss_select() is -- how many more of those fls()
> >> are also off-by-one.
> >>
> >> Fixes: 1ac159e23c2c ("drm/i915: Expand subslice mask")
> >
> > I sent a revert of this commit [1] for reasons explained in the commit
> > message.
> 
> I've gone ahead and pushed the revert.
> 
> We can now calmly get back to the drawing board, and get this sorted out.
Ack ;)

> 
> BR,
> Jani.
> 
> 
> >
> > BR,
> > Jani.
> >
> >
> > [1]
> > http://patchwork.freedesktop.org/patch/msgid/20190529082150.31526-1-ja
> > ni.nik...@intel.com
> >
> >
> >> Fixes: 1e40d4aea57b ("drm/i915/cnl: Implement
> >> WaProgramMgsrForCorrectSliceSpecificMmioReads")
> >> Signed-off-by: Chris Wilson 
> >> Cc: Daniele Ceraolo Spurio 
> >> Cc: Lionel Landwerlin 
> >> Cc: Stuart Summers 
> >> Cc: Manasi Navare 
> >> ---
> >>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >> index fbc853085809..485cd1c8ecc4 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >> @@ -781,7 +781,7 @@ wa_init_mcr(struct drm_i915_private *i915, struct
> i915_wa_list *wal)
> >> * read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches
> >> * enabled subslice, no need to redirect MCR packet
> >> */
> >> -  u32 slice = fls(sseu->slice_mask);
> >> +  u32 slice = __fls(sseu->slice_mask);
> >>u32 fuse3 =
> >>intel_uncore_read(>uncore,
> GEN10_MIRROR_FUSE3);
> >>u32 ss_mask = intel_sseu_get_subslices(sseu, slice);
> 
> --
> Jani Nikula, Intel Open Source Graphics 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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915: Expand subslice mask"

[Saarinen, Jani]

Hi,
Decisions here? 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Patchwork
> Sent: keskiviikko 29. toukokuuta 2019 14.38
> To: Nikula, Jani 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915: Expand 
> subslice mask"
> 
> == Series Details ==
> 
> Series: Revert "drm/i915: Expand subslice mask"
> URL   : https://patchwork.freedesktop.org/series/61293/
> State : success
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_6160 -> Patchwork_13123
> 
> 
> Summary
> ---
> 
>   **SUCCESS**
> 
>   No regressions found.
> 
>   External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13123/
> 
> Known issues
> 
> 
>   Here are the changes found in Patchwork_13123 that come from known issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@i915_selftest@live_contexts:
> - fi-bdw-gvtdvm:  [PASS][1] -> [DMESG-FAIL][2] ([fdo#110235])
>[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6160/fi-bdw-
> gvtdvm/igt@i915_selftest@live_contexts.html
>[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13123/fi-bdw-
> gvtdvm/igt@i915_selftest@live_contexts.html
> 
> 
>  Possible fixes 
> 
>   * igt@gem_exec_suspend@basic-s4-devices:
> - fi-blb-e6850:   [INCOMPLETE][3] ([fdo#107718]) -> [PASS][4]
>[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6160/fi-blb-
> e6850/igt@gem_exec_susp...@basic-s4-devices.html
>[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13123/fi-blb-
> e6850/igt@gem_exec_susp...@basic-s4-devices.html
> 
>   * igt@kms_chamelium@dp-crc-fast:
> - fi-cml-u2:  [FAIL][5] ([fdo#110627]) -> [PASS][6]
>[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6160/fi-cml-
> u2/igt@kms_chamel...@dp-crc-fast.html
>[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13123/fi-cml-
> u2/igt@kms_chamel...@dp-crc-fast.html
> 
> 
>   [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
>   [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
>   [fdo#110627]: https://bugs.freedesktop.org/show_bug.cgi?id=110627
> 
> 
> Participating hosts (47 -> 46)
> --
> 
>   Additional (5): fi-icl-u2 fi-icl-u3 fi-icl-y fi-icl-guc fi-icl-dsi
Seems to boot. Are we waiting shards or ? 

>   Missing(6): fi-kbl-soraka fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
> fi-byt-clapper
> fi-bdw-samus
> 
> 
> Build changes
> -
> 
>   * Linux: CI_DRM_6160 -> Patchwork_13123
> 
>   CI_DRM_6160: 43905c26d4fd15cba890e62f271befc0eca8de4c @
> git://anongit.freedesktop.org/gfx-ci/linux
>   IGT_5023: 0cb925e7f145ba2535924d9a298a62d757707e2a @
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
>   Patchwork_13123: 2ec02f472bf84b234fca1d6a7ee0c7b914c842e0 @
> git://anongit.freedesktop.org/gfx-ci/linux
> 
> 
> == Linux commits ==
> 
> 2ec02f472bf8 Revert "drm/i915: Expand subslice mask"
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13123/
> ___
> 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] [CI 0/5] Refactor to expand subslice mask

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Summers, Stuart
> Sent: tiistai 28. toukokuuta 2019 21.33
> To: Navare, Manasi D 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [CI 0/5] Refactor to expand subslice mask
> 
> On Tue, 2019-05-28 at 11:32 -0700, Manasi Navare wrote:
> > Pushed to dinq, thanks for the patches and the reviews!
> 
> Thanks for the push Manasi and the reviews Daniele and others!
This broke all the ICL systems because CI data was not looked that they did not 
actually even boot at all.
All ICL's in BAT and whole ICL shards. 


> 
> -Stuart
> 
> >
> > Regards
> > Manasi
> >
> > On Fri, May 24, 2019 at 08:40:17AM -0700, Stuart Summers wrote:
> > > This patch series contains a few code clean-up patches, followed by
> > > a patch which changes the storage of the subslice mask to better
> > > match the userspace access through the I915_QUERY_TOPOLOGY_INFO
> > > ioctl. The index into the subslice_mask array is then calculated:
> > >   slice * subslice stride + subslice index / 8
> > >
> > > v2: fix i915_pm_sseu test failure
> > > v3: no changes to patches in the series, just resending to pick up
> > > in CI correctly
> > > v4: rebase
> > > v5: fix header test
> > > v6: address review comments from Jari
> > > address minor checkpatch warning in existing code
> > > use eu_stride for EU div-by-8
> > > v7: another rebase
> > > v8: address review comments from Tvrtko and Daniele
> > > v9: address review comments from Daniele
> > > v10: add reviewed-by on last patch with minor suggested change,
> > >  rebase, and repost for CI
> > >
> > > Stuart Summers (5):
> > >   drm/i915: Use local variable for SSEU info in GETPARAM ioctl
> > >   drm/i915: Add macro for SSEU stride calculation
> > >   drm/i915: Move calculation of subslices per slice to new function
> > >   drm/i915: Refactor sseu helper functions
> > >   drm/i915: Expand subslice mask
> > >
> > >  drivers/gpu/drm/i915/gt/intel_engine_cs.c|  24 ++-
> > >  drivers/gpu/drm/i915/gt/intel_engine_types.h |  30 ++--
> > >  drivers/gpu/drm/i915/gt/intel_hangcheck.c|   3 +-
> > >  drivers/gpu/drm/i915/gt/intel_sseu.c |  62 +++
> > >  drivers/gpu/drm/i915/gt/intel_sseu.h |  35 +++-
> > >  drivers/gpu/drm/i915/gt/intel_workarounds.c  |   2 +-
> > >  drivers/gpu/drm/i915/i915_debugfs.c  |  46 ++---
> > >  drivers/gpu/drm/i915/i915_drv.c  |  15 +-
> > >  drivers/gpu/drm/i915/i915_gpu_error.c|   5 +-
> > >  drivers/gpu/drm/i915/i915_query.c|  15 +-
> > >  drivers/gpu/drm/i915/intel_device_info.c | 176 +++--
> > > --
> > >  drivers/gpu/drm/i915/intel_device_info.h |  47 -
> > >  12 files changed, 280 insertions(+), 180 deletions(-)
> > >
> > > --
> > > 2.21.0.5.gaeb582a983
> > >
> > > ___
> > > 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 v5 00/17] GuC 32.0.3

[Saarinen, Jani]

Hi,

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
> Chris
> Wilson
> Sent: tiistai 28. toukokuuta 2019 12.46
> To: Latvala, Petri 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v5 00/17] GuC 32.0.3
> 
> Quoting Petri Latvala (2019-05-28 10:40:31)
> > On Tue, May 28, 2019 at 10:23:24AM +0100, Chris Wilson wrote:
> > > Quoting Michal Wajdeczko (2019-05-27 19:35:56)
> > > > New GuC firmwares (for SKL, BXT, KBL, GLK, ICL) with updated ABI 
> > > > interface.
> > >
> > > All reviewed/acked, and I trust the failures will be fixed in time,
> > > so pushed. Thanks.
> > > -Chris
> >
> >
> > But without telling Martin to file cibuglog filters for known issues?
> 
> fi-icl-guc should remain suppressed.
> fi-apl-guc should be retired.
Meaning to get to without guc usage ? 

> -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] [PATCH] Revert "ICL HACK: Disable ACPI idle driver"

[Saarinen, Jani]

HI, 

> -Original Message-
> From: Vivi, Rodrigo
> Sent: tiistai 21. toukokuuta 2019 3.12
> To: Saarinen, Jani 
> Cc: Swarup, Aditya ; Gupta, Anshuman
> ; Vetter, Daniel ; intel-
> g...@lists.freedesktop.org; Syrjala, Ville ; Peres, 
> Martin
> ; Wilson, Chris P 
> Subject: Re: [Intel-gfx] [PATCH] Revert "ICL HACK: Disable ACPI idle driver"
> 
> On Mon, May 20, 2019 at 01:42:35PM +, Saarinen, Jani wrote:
> > HI,
> >
> > > -Original Message-
> > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> > > Behalf Of Aditya Swarup
> > > Sent: lauantai 18. toukokuuta 2019 1.00
> > > To: Gupta, Anshuman 
> > > Cc: Vetter, Daniel ;
> > > intel-gfx@lists.freedesktop.org; Syrjala, Ville
> > > ; Peres, Martin 
> > > Subject: Re: [Intel-gfx] [PATCH] Revert "ICL HACK: Disable ACPI idle 
> > > driver"
> > >
> > > The patch looks fine to me.
> > > On Thu, May 16, 2019 at 10:41:56PM +0530, Anshuman Gupta wrote:
> > > > This reverts commit 99b69db57544ec7ed427607f1a2a1858a7d43b61
> > > > Core-for-CI:ICL_only  Disable ACPI idle driver.
> > > >
> > > > This hack has been provided considering the Bug assessment that
> > > > ACPI idle driver page fault causes below bug.
> > > > FDO https://bugs.freedesktop.org/show_bug.cgi?id=108840
> > > > But this bug is still reproducible after disabling ACPI idle driver.
> > > >
> > > > It looks "rcu_preempt self-detected stall on CPU" causes to hung
> > > > kworker and followed by panic resulted this bug.
> > > >
> > > > Hence it make sense to revert this patch.
> > > >
> > > > Cc: martin.pe...@intel.com
> > > > Cc: daniel.vet...@intel.com
> > > > Cc: ville.syrj...@intel.com
> > >
> > > Reviewed-by: Aditya Swarup 
> > Are we now ok to merge this or? Chris, Ville?
> 
> We shouldn't merge this. Instead we just need to go there and remove from  
> topic/core-for-CI and force push with dim to rebuild drm-tip.
Yes, this was my ask here, isnt't this change for reverting that from 
topic/core-for-CI (so basically remove) or no? 
> 
> If this is the wish from CI perspective, let's do it.
If other players agree first. Ville, Chris? 

> 
> >
> > >
> > > > Signed-off-by: Anshuman Gupta 
> > > > ---
> > > >  drivers/acpi/processor_driver.c | 18 +-
> > > >  1 file changed, 1 insertion(+), 17 deletions(-)
> > > >
> > > > diff --git a/drivers/acpi/processor_driver.c
> > > > b/drivers/acpi/processor_driver.c index ee842a2f..9d6aff2 100644
> > > > --- a/drivers/acpi/processor_driver.c
> > > > +++ b/drivers/acpi/processor_driver.c
> > > > @@ -35,12 +35,6 @@
> > > >
> > > >  #include 
> > > >
> > > > -/* Only for Core-for-CI so don't want ia64 to fail compilation.*/
> > > > -#ifdef CONFIG_X86 -#include  -#include
> > > >  -#endif
> > > > -
> > > >  #include "internal.h"
> > > >
> > > >  #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 @@ -64,13 +58,6
> @@
> > > > static const struct acpi_device_id processor_device_ids[] = {  };
> > > > MODULE_DEVICE_TABLE(acpi, processor_device_ids);
> > > >
> > > > -#define ICPU(model){ X86_VENDOR_INTEL, 6, model,
> X86_FEATURE_ANY, }
> > > > -static const struct x86_cpu_id intel_cpu_ids[] = {
> > > > -   ICPU(INTEL_FAM6_ICELAKE_MOBILE),/* ICL */
> > > > -   {}
> > > > -};
> > > > -MODULE_DEVICE_TABLE(x86cpu, intel_cpu_ids);
> > > > -
> > > >  static struct device_driver acpi_processor_driver = {
> > > > .name = "processor",
> > > > .bus = _subsys,
> > > > @@ -239,7 +226,6 @@ static inline void acpi_pss_perf_exit(struct
> > > > acpi_processor *pr,  static int __acpi_processor_start(struct
> > > > acpi_device *device)  {
> > > > struct acpi_processor *pr = acpi_driver_data(device);
> > > > -   const struct x86_cpu_id *id;
> > > > acpi_status status;
> > > > int result = 0;
> > > >
> > > > @@ -253,9 +239,7 @@ static int __acpi_processor_start(struct
> > > > acpi_device
> > > *device)
> > > > if (result && !IS_ENABLED(CONFIG_ACPI_CPU_FR

Re: [Intel-gfx] [PATCH] Revert "ICL HACK: Disable ACPI idle driver"

[Saarinen, Jani]

HI, 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Aditya Swarup
> Sent: lauantai 18. toukokuuta 2019 1.00
> To: Gupta, Anshuman 
> Cc: Vetter, Daniel ; intel-gfx@lists.freedesktop.org;
> Syrjala, Ville ; Peres, Martin 
> 
> Subject: Re: [Intel-gfx] [PATCH] Revert "ICL HACK: Disable ACPI idle driver"
> 
> The patch looks fine to me.
> On Thu, May 16, 2019 at 10:41:56PM +0530, Anshuman Gupta wrote:
> > This reverts commit 99b69db57544ec7ed427607f1a2a1858a7d43b61
> > Core-for-CI:ICL_only  Disable ACPI idle driver.
> >
> > This hack has been provided considering the Bug assessment that ACPI
> > idle driver page fault causes below bug.
> > FDO https://bugs.freedesktop.org/show_bug.cgi?id=108840
> > But this bug is still reproducible after disabling ACPI idle driver.
> >
> > It looks "rcu_preempt self-detected stall on CPU" causes to hung
> > kworker and followed by panic resulted this bug.
> >
> > Hence it make sense to revert this patch.
> >
> > Cc: martin.pe...@intel.com
> > Cc: daniel.vet...@intel.com
> > Cc: ville.syrj...@intel.com
> 
> Reviewed-by: Aditya Swarup 
Are we now ok to merge this or? Chris, Ville? 

> 
> > Signed-off-by: Anshuman Gupta 
> > ---
> >  drivers/acpi/processor_driver.c | 18 +-
> >  1 file changed, 1 insertion(+), 17 deletions(-)
> >
> > diff --git a/drivers/acpi/processor_driver.c
> > b/drivers/acpi/processor_driver.c index ee842a2f..9d6aff2 100644
> > --- a/drivers/acpi/processor_driver.c
> > +++ b/drivers/acpi/processor_driver.c
> > @@ -35,12 +35,6 @@
> >
> >  #include 
> >
> > -/* Only for Core-for-CI so don't want ia64 to fail compilation.*/
> > -#ifdef CONFIG_X86 -#include  -#include
> >  -#endif
> > -
> >  #include "internal.h"
> >
> >  #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 @@ -64,13 +58,6 @@
> > static const struct acpi_device_id processor_device_ids[] = {  };
> > MODULE_DEVICE_TABLE(acpi, processor_device_ids);
> >
> > -#define ICPU(model){ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
> > -static const struct x86_cpu_id intel_cpu_ids[] = {
> > -   ICPU(INTEL_FAM6_ICELAKE_MOBILE),/* ICL */
> > -   {}
> > -};
> > -MODULE_DEVICE_TABLE(x86cpu, intel_cpu_ids);
> > -
> >  static struct device_driver acpi_processor_driver = {
> > .name = "processor",
> > .bus = _subsys,
> > @@ -239,7 +226,6 @@ static inline void acpi_pss_perf_exit(struct
> > acpi_processor *pr,  static int __acpi_processor_start(struct
> > acpi_device *device)  {
> > struct acpi_processor *pr = acpi_driver_data(device);
> > -   const struct x86_cpu_id *id;
> > acpi_status status;
> > int result = 0;
> >
> > @@ -253,9 +239,7 @@ static int __acpi_processor_start(struct acpi_device
> *device)
> > if (result && !IS_ENABLED(CONFIG_ACPI_CPU_FREQ_PSS))
> > dev_dbg(>dev, "CPPC data invalid or not present\n");
> >
> > -   id = x86_match_cpu(intel_cpu_ids);
> > -   if (!id && (!cpuidle_get_driver() || cpuidle_get_driver() ==
> > -   _idle_driver))
> > +   if (!cpuidle_get_driver() || cpuidle_get_driver() ==
> > +_idle_driver)
> > acpi_processor_power_init(pr);
> >
> > result = acpi_pss_perf_init(pr, device);
> > --
> > 2.7.4
> >
> > ___
> > 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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and handling in DRM layer (rev10)

[Saarinen, Jani]

+ Martin for real. 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Shankar, Uma
> Sent: keskiviikko 15. toukokuuta 2019 12.00
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and
> handling in DRM layer (rev10)
> 
> 
> 
> >-Original Message-
> >From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
> >Sent: Wednesday, May 15, 2019 6:54 AM
> >To: Shankar, Uma 
> >Cc: intel-gfx@lists.freedesktop.org
> >Subject: ✗ Fi.CI.IGT: failure for Add HDR Metadata Parsing and handling
> >in DRM layer
> >(rev10)
> >
> >== Series Details ==
> >
> >Series: Add HDR Metadata Parsing and handling in DRM layer (rev10)
> >URL   : https://patchwork.freedesktop.org/series/25091/
> >State : failure
> >
> >== Summary ==
> >
> >CI Bug Log - changes from CI_DRM_6081_full -> Patchwork_13017_full
> >
> >
> >Summary
> >---
> >
> >  **FAILURE**
> >
> >  Serious unknown changes coming with Patchwork_13017_full absolutely
> > need to be  verified manually.
> >
> >  If you think the reported changes have nothing to do with the changes
> > introduced in Patchwork_13017_full, please notify your bug team to
> > allow them  to document this new failure mode, which will reduce false 
> > positives in
> CI.
> >
> >
> >
> >Possible new issues
> >---
> >
> >  Here are the unknown changes that may have been introduced in
> >Patchwork_13017_full:
> >
> >### IGT changes ###
> >
> > Possible regressions 
> >
> >  * igt@gem_exec_suspend@basic-s3:
> >- shard-iclb: [PASS][1] -> [SKIP][2] +43 similar issues
> >   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-
> >iclb6/igt@gem_exec_susp...@basic-s3.html
> >   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-
> >iclb5/igt@gem_exec_susp...@basic-s3.html
> >
> >  * igt@kms_prop_blob@invalid-set-prop-any:
> >- shard-iclb: [PASS][3] -> [FAIL][4]
> >   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-
> >iclb6/igt@kms_prop_b...@invalid-set-prop-any.html
> >   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-
> >iclb5/igt@kms_prop_b...@invalid-set-prop-any.html
> >
> 
> Hi Martin,
> These issues are unrelated to the changes made in this series. Can you please 
> have a
> look and confirm.
> 
> Regards,
> Uma Shankar
> 
> > Warnings 
> >
> >  * igt@gem_mocs_settings@mocs-settings-ctx-dirty-render:
> >- shard-iclb: [SKIP][5] ([fdo#110206]) -> [SKIP][6]
> >   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-
> >iclb6/igt@gem_mocs_setti...@mocs-settings-ctx-dirty-render.html
> >   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-
> >iclb5/igt@gem_mocs_setti...@mocs-settings-ctx-dirty-render.html
> >
> >  * igt@kms_atomic_transition@3x-modeset-transitions-nonblocking:
> >- shard-iclb: [SKIP][7] ([fdo#109278]) -> [SKIP][8] +1 similar 
> > issue
> >   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-
> >iclb6/igt@kms_atomic_transit...@3x-modeset-transitions-nonblocking.html
> >   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-
> >iclb5/igt@kms_atomic_transit...@3x-modeset-transitions-nonblocking.html
> >
> >  * igt@kms_chamelium@hdmi-crc-abgr:
> >- shard-iclb: [SKIP][9] ([fdo#109284]) -> [SKIP][10]
> >   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-
> >iclb6/igt@kms_chamel...@hdmi-crc-abgr.html
> >   [10]:
> >https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-
> >iclb5/igt@kms_chamel...@hdmi-crc-abgr.html
> >
> >  * igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-shrfb-draw-blt:
> >- shard-iclb: [SKIP][11] ([fdo#109280]) -> [SKIP][12] +6 similar 
> > issues
> >   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-
> >iclb6/igt@kms_frontbuffer_track...@psr-2p-primscrn-pri-shrfb-draw-blt.html
> >   [12]:
> >https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-
> >iclb5/igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-shrfb-draw-blt.h
> >tml
> >
> >
> > Suppressed 
> >
> >  The following results come from untrusted machines, tests, or statuses.
> >  They do not affect the overall result.
> >
> >  * {igt@gem_exec_schedule@semaphore-resolve}:
> >- shard-iclb: [FAIL][13] ([fdo#110519]) -> [SKIP][14]
> >   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-
> >iclb6/igt@gem_exec_sched...@semaphore-resolve.html
> >   [14]:
> >https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13017/shard-
> >iclb5/igt@gem_exec_sched...@semaphore-resolve.html
> >
> >  * {igt@kms_cursor_crc@pipe-b-cursor-64x21-random}:
> >- shard-iclb: [PASS][15] -> [SKIP][16] +2 similar issues
> >   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6081/shard-
> 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color (rev8)

[Saarinen, Jani]

Hi,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Aditya Swarup
> Sent: lauantai 4. toukokuuta 2019 2.04
> To: intel-gfx@lists.freedesktop.org
> Cc: Peres, Martin 
> Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/icl: Set
> GCP_COLOR_INDICATION only for 10/12 bit deep color (rev8)
> 
> On Tue, Apr 30, 2019 at 01:46:15PM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep color
> (rev8)
> > URL   : https://patchwork.freedesktop.org/series/58912/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_6012_full -> Patchwork_12900_full
> > 
> >
> > Summary
> > ---
> >
> >   **FAILURE**
> >
> >   Serious unknown changes coming with Patchwork_12900_full absolutely need 
> > to
> be
> >   verified manually.
> >
> >   If you think the reported changes have nothing to do with the changes
> >   introduced in Patchwork_12900_full, please notify your bug team to allow 
> > them
> >   to document this new failure mode, which will reduce false positives in 
> > CI.
> >
> >
> >
> > Possible new issues
> > ---
> >
> >   Here are the unknown changes that may have been introduced in
> Patchwork_12900_full:
> >
> > ### IGT changes ###
> >
> >  Possible regressions 
> >
> >   * igt@gem_caching@read-writes:
> > - shard-skl:  [PASS][1] -> [INCOMPLETE][2] +6 similar issues
> >[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-
> skl9/igt@gem_cach...@read-writes.html
> >[2]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl9/ig
> > t@gem_cach...@read-writes.html
> >
> >   * igt@gem_mmap_gtt@forked-big-copy-odd:
> > - shard-skl:  NOTRUN -> [INCOMPLETE][3] +1 similar issue
> >[3]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl2/ig
> > t@gem_mmap_...@forked-big-copy-odd.html
> Hi Martin,
> 
> These failures shouldn't be due to my patch. Is there a separate bug filed for
> gem_caching and gem_mmap_gtt failures?
Yes, this still I guess due to : 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl2/run25.log 
=> Tomi, still happening: https://bugs.freedesktop.org/show_bug.cgi?id=110581

Br,
Jani
> 
> Regards,
> Aditya Swarup
> >
> >
> >  Warnings 
> >
> >   * igt@kms_cursor_legacy@cursorb-vs-flipa-varying-size:
> > - shard-skl:  [SKIP][4] ([fdo#109271]) -> [INCOMPLETE][5] +1 
> > similar issue
> >[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-
> skl6/igt@kms_cursor_leg...@cursorb-vs-flipa-varying-size.html
> >[5]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl8/ig
> > t@kms_cursor_leg...@cursorb-vs-flipa-varying-size.html
> >
> >
> > Known issues
> > 
> >
> >   Here are the changes found in Patchwork_12900_full that come from known
> issues:
> >
> > ### IGT changes ###
> >
> >  Issues hit 
> >
> >   * igt@gem_cpu_reloc@forked:
> > - shard-iclb: [PASS][6] -> [INCOMPLETE][7] ([fdo#107713] / 
> > [fdo#109100])
> >[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-
> iclb4/igt@gem_cpu_re...@forked.html
> >[7]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-iclb3/i
> > gt@gem_cpu_re...@forked.html
> >
> >   * igt@i915_pm_rpm@pm-tiling:
> > - shard-skl:  [PASS][8] -> [INCOMPLETE][9] ([fdo#107807])
> >[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-
> skl10/igt@i915_pm_...@pm-tiling.html
> >[9]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl9/ig
> > t@i915_pm_...@pm-tiling.html
> >
> >   * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
> > - shard-snb:  [PASS][10] -> [SKIP][11] ([fdo#109271] / 
> > [fdo#109278]) +1
> similar issue
> >[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-
> snb1/igt@kms_b...@extended-pageflip-modeset-hang-oldfb-render-b.html
> >[11]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-snb6/ig
> > t@kms_b...@extended-pageflip-modeset-hang-oldfb-render-b.html
> >
> >   * igt@kms_cursor_crc@cursor-64x21-offscreen:
> > - shard-skl:  [PASS][12] -> [FAIL][13] ([fdo#103232])
> >[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-
> skl2/igt@kms_cursor_...@cursor-64x21-offscreen.html
> >[13]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12900/shard-skl3/ig
> > t@kms_cursor_...@cursor-64x21-offscreen.html
> >
> >   * igt@kms_flip@flip-vs-suspend-interruptible:
> > - shard-glk:  [PASS][14] -> [INCOMPLETE][15] ([fdo#103359] /
> [k.org#198133]) +2 similar issues
> >[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6012/shard-
> glk5/igt@kms_f...@flip-vs-suspend-interruptible.html
> >[15]: 

Re: [Intel-gfx] [PATCH v2] drm/i915: Corrupt DSI picture fix for GeminiLake

[Saarinen, Jani]

HI, 
> -Original Message-
> From: Lisovskiy, Stanislav
> Sent: tiistai 30. huhtikuuta 2019 11.01
> To: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com
> Cc: Saarinen, Jani ; Peres, Martin
> 
> Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Corrupt DSI picture fix for 
> GeminiLake
> 
> On Tue, 2019-04-30 at 10:43 +0300, Jani Nikula wrote:
> > On Tue, 30 Apr 2019, Stanislav Lisovskiy <
> > stanislav.lisovs...@intel.com> wrote:
> > > Currently due to regression CI machine displays show corrupt
> > > picture.
> > > Problem is when CDCLK is as low as 79200, picture gets unstable,
> > > while DSI and DE pll values were confirmed to be correct.
> > > Limiting to 158400 as agreed with Ville.
> > >
> > > We could not come up with any better solution yet, as PLL divider
> > > values both for MIPI(DSI PLL) and CDCLK(DE PLL) are correct, however
> > > seems that due to some boundary conditions, when clocking is too low
> > > we get wrong timings for DSI display.
> > > Similar workaround exists for VLV though, so just took similar
> > > condition into use. At least that way GLK platform will start to be
> > > usable again, with current drm-tip.
> > >
> > > v2: Fixed commit subject as suggested.
> > >
> > > Signed-off-by: Stanislav Lisovskiy 
> > > Acked-by: Ville Syrjälä 
> >
> > Do we have a bugzilla link?
> >
> > BR,
> > Jani.
> 
> No, or at least I'm not aware of. I just got a machine from CI for 
> investigation :) I
> guess it might be worth to create a bug for that.
> 
> 
> Martin: do we have a bug for CI GLK issue?
We did had some bugs, but not sure if those are related to this issue. 

> 
> -Stanislav
> 
> >
> >
> > > ---
> > >  drivers/gpu/drm/i915/intel_cdclk.c | 9 +
> > >  1 file changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/intel_cdclk.c
> > > index ae40a8679314..2b23f8500362 100644
> > > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > > @@ -2277,6 +2277,15 @@ int intel_crtc_compute_min_cdclk(const
> > > struct intel_crtc_state *crtc_state)
> > >   IS_VALLEYVIEW(dev_priv))
> > >   min_cdclk = max(32, min_cdclk);
> > >
> > > + /*
> > > +  * On Geminilake once the CDCLK gets as low as 79200
> > > +  * picture gets unstable, despite that values are
> > > +  * correct for DSI PLL and DE PLL.
> > > +  */
> > > + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) &&
> > > + IS_GEMINILAKE(dev_priv))
> > > + min_cdclk = max(158400, min_cdclk);
> > > +
> > >   if (min_cdclk > dev_priv->max_cdclk_freq) {
> > >   DRM_DEBUG_KMS("required cdclk (%d kHz) exceeds max (%d
> kHz)\n",
> > > min_cdclk, dev_priv->max_cdclk_freq);
> >
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Core-for-CI:ICL_only Disable ACPI idle driver

[Saarinen, Jani]

+ Rafael, Mika. 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Anshuman Gupta
> Sent: maanantai 8. huhtikuuta 2019 15.22
> To: intel-gfx@lists.freedesktop.org
> Cc: Peres, Martin ; Vetter, Daniel
> 
> Subject: [Intel-gfx] [PATCH] Core-for-CI:ICL_only Disable ACPI idle driver
> 
> There were system hung observed while running i915_pm_rpm test.
> FDO https://bugs.freedesktop.org/show_bug.cgi?id=108840
> Root cause is believed to due to page fault in ACPI idle (FDO comment 18) 
> driver, it
> has been suggested by Daniel to disable ACPI idle driver for CI system, this 
> patch only
> meant for ICL.
> 
> Cc: martin.pe...@intel.com
> Cc: daniel.vet...@intel.com
> 
> Signed-off-by: Anshuman Gupta 
> ---
>  drivers/acpi/processor_driver.c | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/processor_driver.c 
> b/drivers/acpi/processor_driver.c index
> 9d6aff2..6e3ef2d 100644
> --- a/drivers/acpi/processor_driver.c
> +++ b/drivers/acpi/processor_driver.c
> @@ -35,6 +35,9 @@
> 
>  #include 
> 
> +#include 
> +#include 
> +
>  #include "internal.h"
> 
>  #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 @@ -58,6 +61,13 @@
> static const struct acpi_device_id processor_device_ids[] = {  };
> MODULE_DEVICE_TABLE(acpi, processor_device_ids);
> 
> +#define ICPU(model)  { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
> +static const struct x86_cpu_id intel_cpu_ids[] = {
> + ICPU(INTEL_FAM6_ICELAKE_MOBILE),/* ICL */
> + {}
> +};
> +MODULE_DEVICE_TABLE(x86cpu, intel_pmc_core_ids);
> +
>  static struct device_driver acpi_processor_driver = {
>   .name = "processor",
>   .bus = _subsys,
> @@ -226,6 +236,7 @@ static inline void acpi_pss_perf_exit(struct 
> acpi_processor
> *pr,  static int __acpi_processor_start(struct acpi_device *device)  {
>   struct acpi_processor *pr = acpi_driver_data(device);
> + const struct x86_cpu_id *id;
>   acpi_status status;
>   int result = 0;
> 
> @@ -239,7 +250,9 @@ static int __acpi_processor_start(struct acpi_device 
> *device)
>   if (result && !IS_ENABLED(CONFIG_ACPI_CPU_FREQ_PSS))
>   dev_dbg(>dev, "CPPC data invalid or not present\n");
> 
> - if (!cpuidle_get_driver() || cpuidle_get_driver() == _idle_driver)
> + id = x86_match_cpu(intel_cpu_ids);
> + if (!id && (!cpuidle_get_driver() || cpuidle_get_driver() ==
> + _idle_driver))
>   acpi_processor_power_init(pr);
> 
>   result = acpi_pss_perf_init(pr, device);
> --
> 2.7.4
> 
> ___
> 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.BAT: success for drm/i915: Fix pipe_bpp readout for BXT/GLK DSI

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Patchwork
> Sent: perjantai 5. huhtikuuta 2019 20.14
> To: Ville Syrjälä 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix pipe_bpp readout 
> for
> BXT/GLK DSI
> 
> == Series Details ==
> 
> Series: drm/i915: Fix pipe_bpp readout for BXT/GLK DSI
> URL   : https://patchwork.freedesktop.org/series/59067/
> State : success
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_5881 -> Patchwork_12701
> 
> 
> Summary
> ---
> 
>   **SUCCESS**
> 
>   No regressions found.
> 
>   External URL:
> https://patchwork.freedesktop.org/api/1.0/series/59067/revisions/1/mbox/
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in
> Patchwork_12701:
> 
> ### IGT changes ###
> 
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * igt@gem_ctx_exec@basic:
> - {fi-icl-u3}:PASS -> INCOMPLETE
> 
> 
> Known issues
> 
> 
>   Here are the changes found in Patchwork_12701 that come from known issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_exec_gttfill@basic:
> - fi-icl-y:   PASS -> INCOMPLETE [fdo#110209]
> 
>   * igt@gem_exec_store@basic-bsd2:
> - fi-bxt-dsi: NOTRUN -> SKIP [fdo#109271] +47
> 
>   * igt@i915_pm_rpm@module-reload:
> - fi-glk-dsi: NOTRUN -> DMESG-FAIL [fdo#105538] / [fdo#107732]
> 
>   * igt@i915_selftest@live_hangcheck:
> - fi-skl-iommu:   PASS -> INCOMPLETE [fdo#108602] / [fdo#108744]
> - fi-bxt-dsi: NOTRUN -> INCOMPLETE [fdo#103927]
> 
>   * igt@kms_force_connector_basic@force-edid:
> - fi-glk-dsi: NOTRUN -> SKIP [fdo#109271] +29
> 
>   * igt@kms_frontbuffer_tracking@basic:
> - fi-glk-dsi: NOTRUN -> FAIL [fdo#103167]
> - fi-byt-clapper: PASS -> FAIL [fdo#103167]
> 
>   * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
> - fi-blb-e6850:   PASS -> INCOMPLETE [fdo#107718]
> 
>   * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
> - fi-ivb-3770:PASS -> SKIP [fdo#109271]
> 
>   * igt@runner@aborted:
> - fi-skl-iommu:   NOTRUN -> FAIL [fdo#104108] / [fdo#108602]
> 
> 
>  Possible fixes 
> 
>   * igt@i915_pm_rpm@module-reload:
> - fi-skl-6770hq:  FAIL [fdo#108511] -> PASS
> 
>   * igt@i915_selftest@live_execlists:
> - fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS
> 
>   * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
> - fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
> 
> 
>   {name}: This element is suppressed. This means it is ignored when computing
>   the status of the difference (SUCCESS, WARNING, or FAILURE).
> 
>   [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
>   [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
>   [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
>   [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
>   [fdo#105538]: https://bugs.freedesktop.org/show_bug.cgi?id=105538
>   [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
>   [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
>   [fdo#107732]: https://bugs.freedesktop.org/show_bug.cgi?id=107732
>   [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
>   [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
>   [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
>   [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
>   [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
>   [fdo#110209]: https://bugs.freedesktop.org/show_bug.cgi?id=110209
> 
> 
> Participating hosts (49 -> 43)
> --
> 
>   Missing(6): fi-ilk-m540 fi-bdw-5557u fi-hsw-peppy fi-byt-squawks 
> fi-bsw-cyan fi-
> bdw-samus
> 
> 
> Build changes
> -
> 
> * Linux: CI_DRM_5881 -> Patchwork_12701
> 
>   CI_DRM_5881: b070175c76da1440a747fd023ee6253e573055f8 @
> git://anongit.freedesktop.org/gfx-ci/linux
>   IGT_4931: 019f892e5d1a0a9643cb726c47ce2d99c14b444f @
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
>   Patchwork_12701: aaabc22c7f568ba125526c7a9171dab1aa7170e6 @
> git://anongit.freedesktop.org/gfx-ci/linux
> 
> 
> == Linux commits ==
> 
> aaabc22c7f56 drm/i915: Fix pipe_bpp readout for BXT/GLK DSI
Both BXT and GLK now seems to boot and test with BAT. Looks much better ;). 

> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12701/
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/i915/dsi: Fix pipe_bpp for handling for 6 bpc pixel-formats

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
> Jani
> Nikula
> Sent: perjantai 5. huhtikuuta 2019 9.35
> To: Hans de Goede ; Joonas Lahtinen
> ; Vivi, Rodrigo ; 
> Ville
> Syrjälä 
> Cc: intel-gfx ; 
> dri-de...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/4] drm/i915/dsi: Fix pipe_bpp for handling 
> for 6 bpc
> pixel-formats
> 
> On Sat, 01 Dec 2018, Hans de Goede  wrote:
> > There are 3 problems with the dsi code's pipe_bpp handling for 6 bpc
> > pixel-formats which this commit addresses:
> >
> > 1) It assumes that the pipe_bpp is the same as the bpp going over the
> > dsi lanes. This assumption is not valid for MIPI_DSI_FMT_RGB666, where
> > pipe_bpp should be 18 so that we do proper dithering but we actually
> > send 24 bpp over the dsi lanes (MIPI_DSI_FMT_RGB666_PACKED sends 18 bpp).
> >
> > This assumption is enforced by an assert in *_dsi_get_pclk(). This
> > assert triggers on the initial hw-state readback on BYT/CHT devices
> > which use MIPI_DSI_FMT_RGB666, such as the Prowise PT301 tablet.
> > PIPECONF is set to 6BPC / 18 bpp by the GOP, while
> mipi_dsi_pixel_format_to_bpp() returns 24.
> >
> > This commits switches the calculations in *_dsi_get_pclk() to use the
> > bpp from mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format) which
> > returns the bpp going over the mipi lanes and drops the assert.
> >
> > 2) On BXT bxt_dsi_get_pipe_config() wrongly overrides the pipe_bpp
> > which
> > i9xx_get_pipe_config() reads from PIPECONF with the return value from
> > mipi_dsi_pixel_format_to_bpp(). This avoids the assert from 1. but is
> > wrong since the pipe is actually running at the value configured in 
> > PIPECONF.
> >
> > This commit drops the override of pipe_bpp from bxt_dsi_get_pipe_config().
> >
> > 3) The dsi encoder's compute_config() never assigns a value to
> > pipe_bpp, unlike most other encoders. Falling back on
> > compute_baseline_pipe_bpp() which always picks 24. 24 is only correct
> > for MIPI_DSI_FMT_RGB88 for the others we should use 18 bpp so that we
> correctly do 6bpc color dithering.
> >
> > This commit adds code to intel_dsi_compute_config() to properly set
> > pipe_bpp based on intel_dsi->pixel_format.
> >
> > Signed-off-by: Hans de Goede 
> > ---
> >  drivers/gpu/drm/i915/intel_dsi.h   |  4 ++--
> >  drivers/gpu/drm/i915/vlv_dsi.c | 17 
> >  drivers/gpu/drm/i915/vlv_dsi_pll.c | 31
> > ++
> >  3 files changed, 17 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> > b/drivers/gpu/drm/i915/intel_dsi.h
> > index c888c219835f..c796a2962a43 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.h
> > +++ b/drivers/gpu/drm/i915/intel_dsi.h
> > @@ -160,7 +160,7 @@ int vlv_dsi_pll_compute(struct intel_encoder
> > *encoder,  void vlv_dsi_pll_enable(struct intel_encoder *encoder,
> > const struct intel_crtc_state *config);  void
> > vlv_dsi_pll_disable(struct intel_encoder *encoder);
> > -u32 vlv_dsi_get_pclk(struct intel_encoder *encoder, int pipe_bpp,
> > +u32 vlv_dsi_get_pclk(struct intel_encoder *encoder,
> >  struct intel_crtc_state *config);  void
> > vlv_dsi_reset_clocks(struct intel_encoder *encoder, enum port port);
> >
> > @@ -170,7 +170,7 @@ int bxt_dsi_pll_compute(struct intel_encoder
> > *encoder,  void bxt_dsi_pll_enable(struct intel_encoder *encoder,
> > const struct intel_crtc_state *config);  void
> > bxt_dsi_pll_disable(struct intel_encoder *encoder);
> > -u32 bxt_dsi_get_pclk(struct intel_encoder *encoder, int pipe_bpp,
> > +u32 bxt_dsi_get_pclk(struct intel_encoder *encoder,
> >  struct intel_crtc_state *config);  void
> > bxt_dsi_reset_clocks(struct intel_encoder *encoder, enum port port);
> >
> > diff --git a/drivers/gpu/drm/i915/vlv_dsi.c
> > b/drivers/gpu/drm/i915/vlv_dsi.c index be3af5f6c7a0..c10def5efa22
> > 100644
> > --- a/drivers/gpu/drm/i915/vlv_dsi.c
> > +++ b/drivers/gpu/drm/i915/vlv_dsi.c
> > @@ -322,6 +322,11 @@ static bool intel_dsi_compute_config(struct
> intel_encoder *encoder,
> > /* DSI uses short packets for sync events, so clear mode flags for DSI 
> > */
> > adjusted_mode->flags = 0;
> >
> > +   if (intel_dsi->pixel_format == MIPI_DSI_FMT_RGB888)
> > +   pipe_config->pipe_bpp = 24;
> > +   else
> > +   pipe_config->pipe_bpp = 18;
> > +
> > if (IS_GEN9_LP(dev_priv)) {
> > /* Enable Frame time stamp based scanline reporting */
> > adjusted_mode->private_flags |=
> > @@ -1097,10 +1102,8 @@ static void bxt_dsi_get_pipe_config(struct
> intel_encoder *encoder,
> > }
> >
> > fmt = I915_READ(MIPI_DSI_FUNC_PRG(port)) &
> VID_MODE_FORMAT_MASK;
> > -   pipe_config->pipe_bpp =
> > -   mipi_dsi_pixel_format_to_bpp(
> > -   pixel_format_from_register_bits(fmt));
> 
> This part here was crucial for BXT/GLK hardware state 

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm: connector firmware nodes

[Saarinen, Jani]

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
> Heikki
> Krogerus
> Sent: tiistai 26. maaliskuuta 2019 10.32
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm: connector firmware 
> nodes
> 
> On Mon, Mar 25, 2019 at 08:57:44PM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm: connector firmware nodes
> > URL   : https://patchwork.freedesktop.org/series/58531/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_5810_full -> Patchwork_12592_full
> > 
> >
> > Summary
> > ---
> >
> >   **FAILURE**
> >
> >   Serious unknown changes coming with Patchwork_12592_full absolutely need 
> > to
> be
> >   verified manually.
> >
> >   If you think the reported changes have nothing to do with the changes
> >   introduced in Patchwork_12592_full, please notify your bug team to allow 
> > them
> >   to document this new failure mode, which will reduce false positives in 
> > CI.
> >
> >
> >
> > Possible new issues
> > ---
> >
> >   Here are the unknown changes that may have been introduced in
> Patchwork_12592_full:
> >
> > ### IGT changes ###
> >
> >  Possible regressions 
> >
> >   * igt@perf_pmu@idle-no-semaphores-bcs0:
> > - shard-iclb: PASS -> INCOMPLETE
> 
> 
> I have not idea what this is about? Is there something I need to do?
Do you see from logs if relevant to your patche(s) ? 
If not read above. But also copying here:
> >   If you think the reported changes have nothing to do with the changes
> >   introduced in Patchwork_12592_full, please notify your bug team to allow 
> > them
> >   to document this new failure mode, which will reduce false positives in 
> > CI.


> 
> thanks,
> 
> --
> heikki
> ___
> 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.BAT: success for series starting with [1/2] drm/i915: Turn dram_info.num_channels into a bitmask (rev3)

[Saarinen, Jani]

Finally, now need shards data ;). 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Patchwork
> Sent: torstai 21. maaliskuuta 2019 8.34
> To: Ville Syrjala 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] 
> drm/i915: Turn
> dram_info.num_channels into a bitmask (rev3)
> 
> == Series Details ==
> 
> Series: series starting with [1/2] drm/i915: Turn dram_info.num_channels into 
> a
> bitmask (rev3)
> URL   : https://patchwork.freedesktop.org/series/58299/
> State : success
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_5785 -> Patchwork_12540
> 
> 
> Summary
> ---
> 
>   **SUCCESS**
> 
>   No regressions found.
> 
>   External URL:
> https://patchwork.freedesktop.org/api/1.0/series/58299/revisions/3/mbox/
> 
> Known issues
> 
> 
>   Here are the changes found in Patchwork_12540 that come from known issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_exec_suspend@basic-s4-devices:
> - fi-blb-e6850:   PASS -> INCOMPLETE [fdo#107718]
> 
>   * igt@i915_pm_rpm@basic-pci-d3-state:
> - fi-hsw-4770:PASS -> SKIP [fdo#109271] +3
> 
>   * igt@i915_pm_rpm@module-reload:
> - fi-skl-6770hq:  PASS -> FAIL [fdo#108511]
> - fi-skl-6600u:   PASS -> INCOMPLETE [fdo#107807]
> 
>   * igt@i915_selftest@live_evict:
> - fi-bsw-kefka:   PASS -> DMESG-WARN [fdo#107709]
> 
>   * igt@prime_vgem@basic-fence-flip:
> - fi-gdg-551: PASS -> FAIL [fdo#103182]
> 
>   * igt@runner@aborted:
> - fi-bxt-j4205:   NOTRUN -> FAIL [fdo#109516]
> - fi-bsw-kefka:   NOTRUN -> FAIL [fdo#107709]
> - fi-apl-guc: NOTRUN -> FAIL [fdo#109373]
> 
> 
>  Possible fixes 
> 
>   * igt@kms_busy@basic-flip-b:
> - fi-gdg-551: FAIL [fdo#103182] -> PASS
> 
>   * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
> - fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
> 
>   * igt@prime_vgem@basic-fence-flip:
> - fi-ilk-650: FAIL [fdo#104008] -> PASS
> 
> 
>   [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
>   [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
>   [fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
>   [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
>   [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
>   [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
>   [fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
>   [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
>   [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
>   [fdo#109373]: https://bugs.freedesktop.org/show_bug.cgi?id=109373
>   [fdo#109516]: https://bugs.freedesktop.org/show_bug.cgi?id=109516
> 
> 
> Participating hosts (47 -> 38)
> --
> 
>   Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy 
> fi-byt-squawks fi-
> bsw-cyan fi-ctg-p8600 fi-pnv-d510 fi-bdw-samus
> 
> 
> Build changes
> -
> 
> * Linux: CI_DRM_5785 -> Patchwork_12540
> 
>   CI_DRM_5785: 1e3d80c25878b7d97ad6c0680a452d55baeb28e0 @
> git://anongit.freedesktop.org/gfx-ci/linux
>   IGT_4894: fedd92f4022837e2c20e472b65bd7d0849f484a3 @
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
>   Patchwork_12540: 155ce7c6724938faf44c0c40a5d77581be26512f @
> git://anongit.freedesktop.org/gfx-ci/linux
> 
> 
> == Linux commits ==
> 
> 155ce7c67249 drm/i915: Make sure we have enough memory bandwidth on ICL
> 77f4b2fd475a drm/i915: Turn dram_info.num_channels into a bitmask
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12540/
> ___
> 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 v2] drm/i915/icl: Fix CRC mismatch error for DP link layer compliance

[Saarinen, Jani]

Ping, ok to merge? 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Kahola, Mika
> Sent: torstai 7. maaliskuuta 2019 9.52
> To: intel-gfx@lists.freedesktop.org; Swarup, Aditya 
> Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/icl: Fix CRC mismatch error for 
> DP link
> layer compliance
> 
> The patch looks ok to me.
> 
> On Wed, 2019-03-06 at 18:14 -0800, Aditya Swarup wrote:
> > Setting the pixel rounding bit to 1 in PIPE_CHICKEN register allows to
> > passthrough FB pixels unmodified across pipe. This fixes the failures
> > for DP link layer compliance tests 4.4.1.1, 4.4.1.2 & 4.4.1.3.
> > (Lineage #1605353570)
> >
> > v2: This is also needed to fix failing IGT test case kms_cursor_crc on
> > ICL.(Mika Kahola) Make macros consistent with i915_reg.h
> > comments.(Jani Nikula)
> >
> > Cc: Clint Taylor 
> > Cc: Mika Kahola 
> > Cc: Jani Nikula 
> 
> Reviewed-by: Mika Kahola 
> 
> > Signed-off-by: Aditya Swarup 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  | 13 +++--
> >  drivers/gpu/drm/i915/intel_display.c |  8 +++-
> >  2 files changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index c9b868347481..cf15a9a97d74
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7659,12 +7659,13 @@ enum {
> >  #define  GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE (1 << 2)
> >
> >  /*GEN11 chicken */
> > -#define _PIPEA_CHICKEN 0x70038
> > -#define _PIPEB_CHICKEN 0x71038
> > -#define _PIPEC_CHICKEN 0x72038
> > -#define  PER_PIXEL_ALPHA_BYPASS_EN (1 << 7)
> > -#define PIPE_CHICKEN(pipe) _MMIO_PIPE(pipe,
> > _PIPEA_CHICKEN,\
> > -  _PIPEB_CHICKEN)
> > +#define _PIPEA_CHICKEN 0x70038
> > +#define _PIPEB_CHICKEN 0x71038
> > +#define _PIPEC_CHICKEN 0x72038
> > +#define PIPE_CHICKEN(pipe) _MMIO_PIPE(pipe,
> > _PIPEA_CHICKEN,\
> > +  _PIPEB_CHICK
> > EN)
> > +#define   PIXEL_ROUNDING_TRUNC_FB_PASSTHRU (1 << 15)
> > +#define   PER_PIXEL_ALPHA_BYPASS_EN(1 << 7)
> >
> >  /* PCH */
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index d852cb282060..92be3476fef1 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3970,7 +3970,13 @@ static void icl_set_pipe_chicken(struct
> > intel_crtc *crtc)
> >  * and rounding for per-pixel values 00 and 0xff
> >  */
> > tmp |= PER_PIXEL_ALPHA_BYPASS_EN;
> > -
> > +   /*
> > +* Display WA # 1605353570: icl
> > +* Set the pixel rounding bit to 1 for allowing
> > +* passthrough of Frame buffer pixels unmodified
> > +* across pipe
> > +*/
> > +   tmp |= PIXEL_ROUNDING_TRUNC_FB_PASSTHRU;
> > I915_WRITE(PIPE_CHICKEN(pipe), tmp);  }
> >
> ___
> 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/icl: Remove alpha support protection

[Saarinen, Jani]

Hi, 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Rodrigo Vivi
> Sent: keskiviikko 6. maaliskuuta 2019 1.22
> To: Souza, Jose 
> Cc: Nikula, Jani ; intel-gfx@lists.freedesktop.org; 
> Zanoni,
> Paulo R 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Remove alpha support protection
> 
> On Tue, Mar 05, 2019 at 02:11:53PM -0800, José Roberto de Souza wrote:
> > Now with the watermarks fixes merged, Icelake is stable enough to have
> > the alpha support protection flag removed.
> >
> > We have a few ICL machines in our CI and it is mostly green with
> > failures in tests that will not impact future linux installations.
> > Also there is no warnings, errors, flickering or any visual defects
> > while doing ordinary tasks like browsing and editing documents in a
> > dual monitor setup.
> >
> > As a reminder i915.alpha_support was created to protect future linux
> > installation's iso images that might contain a kernel from the
> > enabling time of the new platform. Without this protection most of
> > linux installation was recommending nomodeset option during
> > installation that was getting stick there after installation.
> >
> > Specifically, alpha support says nothing about the development state
> > of the hardware, and everything about the state of the driver in a
> > kernel release.
> >
> > This is semantically no different from the old preliminary_hw_support
> > flag, but the old one was all too often interpreted as (preliminary
> > hw) support instead of the intended
> > (preliminary) hw support, and it was misleading for everyone.
> > Hence the rename.
> >
> > Reference: https://intel-gfx-ci.01.org/tree/drm-tip/fi-icl-y.html
> 
> This view is great. It is unfortunate we cannot save this and this link will 
> be invalid in
> few runs.
> 
> > Reference: https://intel-gfx-ci.01.org/tree/drm-tip/shard-iclb.html
> 
> This picture doesn't help, but taking your word, and the BAT results and 
> quoting Jani
> Saarinen: "Nice improvement here what comes to passes..."
> 
> Old: f2-icl-u total:262  pass:107  dwarn:98  dfail:0   fail:1   
> skip:55  time:429s
> f2-icl-u total:263  pass:222  dwarn:9   dfail:0   fail:3   skip:29  
> time:339s
> 
> Old: f2-icl-y total:262  pass:105  dwarn:98  dfail:0   fail:4   
> skip:54  time:430s
> f2-icl-y total:476  pass:225  dwarn:7   dfail:0   fail:4   skip:240 
> time:470s
> 
> Reviewed-by: Rodrigo Vivi 

Acked-by: Jani Saarinen 

> 
> > Cc: James Ausmus 
> > Cc: Jani Saarinen 
> > Cc: Paulo Zanoni 
> > Cc: Rodrigo Vivi 
> > Cc: Jani Nikula 
> > Cc: Ville Syrjälä 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/i915_pci.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c index c42c5ccf38fe..527bd1ceb9ac
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -658,7 +658,6 @@ static const struct intel_device_info
> > intel_cannonlake_info = {  static const struct intel_device_info
> intel_icelake_11_info = {
> > GEN11_FEATURES,
> > PLATFORM(INTEL_ICELAKE),
> > -   .is_alpha_support = 1,
> > .engine_mask =
> > BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),  };
> > --
> > 2.21.0
> >
> > ___
> > 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

Re: [Intel-gfx] [PATCH v6 0/3] drm & vgaarb: handle vgacon removal in vgaarb.

[Saarinen, Jani]

Hi,

> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: perjantai 1. maaliskuuta 2019 8.12
> To: Saarinen, Jani 
> Cc: Hiler, Arkadiusz ; Sarvela, Tomi P
> ; intel-gfx 
> Subject: Re: [Intel-gfx] [PATCH v6 0/3] drm & vgaarb: handle vgacon removal in
> vgaarb.
> 
>   Hi,
> 
> > > Hmm, I see the test results in patchwork, but I can't remember having 
> > > seen a
> mail.
> > > So the next question: where the results are sent to?
> > From page above sent by Arek:
> > " Since we accept patches through mailing lists, this is where you can
> > find the results - they are sent out as a replies to the original
> > mail. Here are the mailing lists we currently support:"
> 
> Hmm, I'm not subscribed to intel-gfx, so that explains why I havn't seen the 
> result
> mails.  Any chance to sent the results also to the patch submitter?
It patches are sent to mailing list(s) (intel-gfx, trybot or igt-dev) and 
patches apply or not cleanly to latest drm-tip then results are sent both to 
developer and list as cc. 
Arek, Tomi, any other comments?

> 
> thanks,
>   Gerd

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 0/3] drm & vgaarb: handle vgacon removal in vgaarb.

[Saarinen, Jani]

HI, 

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
> Gerd
> Hoffmann
> Sent: torstai 28. helmikuuta 2019 15.28
> To: Hiler, Arkadiusz 
> Cc: Sarvela, Tomi P ; intel-gfx  g...@lists.freedesktop.org>
> Subject: Re: [Intel-gfx] [PATCH v6 0/3] drm & vgaarb: handle vgacon removal in
> vgaarb.
> 
> On Thu, Feb 28, 2019 at 01:03:14PM +0200, Arkadiusz Hiler wrote:
> > On Thu, Feb 28, 2019 at 11:52:39AM +0100, Daniel Vetter wrote:
> > > Adding intel-gfx and CI folks.
> > >
> > > On Thu, Feb 28, 2019 at 9:22 AM Gerd Hoffmann  wrote:
> > > > Quick question on the Intel CI:  How does it work?  I've seen it
> > > > sending mails.  Does it report failures only, i.e. no news is good
> > > > news?  How long does it usually take to run the tests?  Is waiting a 
> > > > day enough?
> > > > Is there a website where I can see the test results?
> > >
> > > It always reports, and result links also get dumped onto patchwork
> > > (in the series view). There's 2 main runs: BAT and IGT (first with
> > > more machines, 2nd with more tests). BAT should be there within a
> > > few hours at most, IGT sometimes takes 1 day when there's a big backlog.
> > >
> > > -Daniel
> >
> > Hey,
> >
> > We try to explain our CI here: https://intel-gfx-ci.01.org/
> >
> > By the questions you have asked I already see that we should add
> > information on the results being sent out for successes too and give
> > some time estimations.
> 
> Hmm, I see the test results in patchwork, but I can't remember having seen a 
> mail.
> So the next question: where the results are sent to?
From page above sent by Arek:
" Since we accept patches through mailing lists, this is where you can find the 
results - they are sent out as a replies to the original mail. Here are the 
mailing lists we currently support:"

> 
> cheers,
>   Gerd
Br,
Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

> 
> ___
> 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