Re: [Intel-gfx] [PATCH 11/11] video/aperture: Only remove sysfb on the default vga pci device
Hi
Am 11.01.23 um 20:21 schrieb Aaron Plattner:
On 1/11/23 8:58 AM, Javier Martinez Canillas wrote:
Hello Daniel,
On 1/11/23 16:41, Daniel Vetter wrote:
This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable
sysfb device registration when removing conflicting FBs"), where we
remove the sysfb when loading a driver for an unrelated pci device,
resulting in the user loosing their efifb console or similar.
Note that in practice this only is a problem with the nvidia blob,
because that's the only gpu driver people might install which does not
come with an fbdev driver of it's own. For everyone else the real gpu
driver will restor a working console.
restore
Also note that in the referenced bug there's confusion that this same
bug also happens on amdgpu. But that was just another amdgpu specific
regression, which just happened to happen at roughly the same time and
with the same user-observable symptons. That bug is fixed now, see
symptoms
https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15
For the above reasons the cc: stable is just notionally, this patch
will need a backport and that's up to nvidia if they care enough.
Maybe adding a Fixes: ee7a69aa38d8 tag here too ?
References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28
Signed-off-by: Daniel Vetter
Cc: Aaron Plattner
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Cc: Helge Deller
Cc: Sam Ravnborg
Cc: Alex Deucher
Cc: # v5.19+ (if someone else does the
backport)
---
drivers/video/aperture.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index ba565515480d..a1821d369bb1 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -321,15 +321,16 @@ int
aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const
char *na
primary = pdev == vga_default_device();
+ if (primary)
+ sysfb_disable();
+
for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
continue;
base = pci_resource_start(pdev, bar);
size = pci_resource_len(pdev, bar);
- ret = aperture_remove_conflicting_devices(base, size, name);
- if (ret)
- return ret;
+ aperture_detach_devices(base, size);
Maybe mention in the commit message that you are doing this change,
something like:
"Instead of calling aperture_remove_conflicting_devices() to remove
the conflicting
devices, just call to aperture_detach_devices() to detach the device
that matches
the same PCI BAR / aperture range. Since the former is just a wrapper
of the latter
plus a sysfb_disable() call, and now that's done in this function but
only for the
primary devices"
Patch looks good to me:
Reviewed-by: Javier Martinez Canillas
Thanks Daniel and Javier!
I wasn't able to reproduce the original problem on my hybrid laptop
since it refuses to boot with the console on an external display, but I
was able to reproduce it by switching the configuration around: booting
with i915.modeset=0 and with an experimental version of nvidia-drm that
registers a framebuffer console. I verified that loading nvidia-drm
Thank you for testing.
One thing I'd like to note is that using DRM's fbdev emulation is the
correct way to support a console. Nvidia-drm's current approach of
utilizing efifb is fragile and requires workarounds from distributions
(at least here at SUSE). Steps towards fbdev emulation are much appreciated.
Best regards
Thomas
breaks the efi-firmware framebuffer on Intel on Arch's
linux-6.1.4-arch1-1 kernel and that applying this patch series fixes it. So
Tested-by: Aaron Plattner
FWIW, the bug ought to be reproducible with i915.modeset=0 + any other
drm driver that registers a framebuffer.
-- Aaron
--
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
OpenPGP_signature
Description: OpenPGP digital signature
[Intel-gfx] [OA][RFC] Exposing low-resolution engine business via sysfs
Hi, I am the developer of MangoHud[1], a Vulkan and OpenGL overlay for monitoring FPS / temperatures / CPU/GPU load and more. I would like to add support for i915 (and xe in the future) but I am currently unable to do this easily because not everything I need is exposed directly to non-root users. Namely: * Engine business (RCS) * CPU, iGPU and dGPU power usage * IMC bandwith (nice to have but not mandatory) This is a problem because it would require us to ship a setuid binary to poll these metrics for the overlay (we can't run games as root). For your information, this is Intel-specific as AMD and NVIDIA are exposing these values directly. I understand the security concerns, but we are not asking for super precise information (1% accuracy is perfect). Can we work together on this, what are your thoughts? Thanks for your consideration. //Simon Hallsten [1] https://github.com/flightlessmango/MangoHud
Re: [Intel-gfx] [PATCH 11/11] video/aperture: Only remove sysfb on the default vga pci device
Hi
Am 11.01.23 um 17:37 schrieb Daniel Vetter:
On Wed, Jan 11, 2023 at 05:20:00PM +0100, Thomas Zimmermann wrote:
Hi
Am 11.01.23 um 16:41 schrieb Daniel Vetter:
This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable
sysfb device registration when removing conflicting FBs"), where we
remove the sysfb when loading a driver for an unrelated pci device,
resulting in the user loosing their efifb console or similar.
Note that in practice this only is a problem with the nvidia blob,
because that's the only gpu driver people might install which does not
come with an fbdev driver of it's own. For everyone else the real gpu
driver will restor a working console.
Also note that in the referenced bug there's confusion that this same
bug also happens on amdgpu. But that was just another amdgpu specific
regression, which just happened to happen at roughly the same time and
with the same user-observable symptons. That bug is fixed now, see
https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15
For the above reasons the cc: stable is just notionally, this patch
will need a backport and that's up to nvidia if they care enough.
References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28
Signed-off-by: Daniel Vetter
Cc: Aaron Plattner
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Cc: Helge Deller
Cc: Sam Ravnborg
Cc: Alex Deucher
Cc: # v5.19+ (if someone else does the backport)
---
drivers/video/aperture.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index ba565515480d..a1821d369bb1 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -321,15 +321,16 @@ int aperture_remove_conflicting_pci_devices(struct
pci_dev *pdev, const char *na
primary = pdev == vga_default_device();
+ if (primary)
+ sysfb_disable();
+
There's another sysfb_disable() in aperture_remove_conflicting_devices()
without the branch but with a long comment. I find this slightly confusing.
I'd rather add a branched sysfb_disable() plus the comment to
aperture_detach_devices(). And then add a 'primary' parameter to
aperture_detach_devices(). In aperture_remove_conflicting_devices() the
parameter would be unconditionally true.
Yeah I was on the fence, but should be easy to redo with all the prep work
out of the way. It does mean we call sysfb_disable once for every bar, but
that shouldn't matter in any reasonable case :-)
Or leave it as is. It's not so important. The idea of the current design
was that aperture_remove_conflicting_device() would be the general
implementation and aperture_remove_conflicting_pci_device() would be a
helper that only detects the correct PCI BAR. That never really worked
in practice.
Best regards
Thomas
-Daniel
Best regards
Thomas
for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
continue;
base = pci_resource_start(pdev, bar);
size = pci_resource_len(pdev, bar);
- ret = aperture_remove_conflicting_devices(base, size, name);
- if (ret)
- return ret;
+ aperture_detach_devices(base, size);
}
if (!primary)
--
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
--
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
OpenPGP_signature
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH 0/2] Defeature Interlace modes for Display >= 12
> -Original Message- > From: Nautiyal, Ankit K > Sent: Monday, October 17, 2022 8:01 PM > To: intel-gfx@lists.freedesktop.org > Cc: Navare, Manasi D ; > ville.syrj...@linux.intel.com; > jani.nik...@linux.intel.com; Shankar, Uma ; Kulkarni, > Vandita > Subject: [PATCH 0/2] Defeature Interlace modes for Display >= 12 > > This patch series is a contination of patch: > https://patchwork.freedesktop.org/patch/506835/?series=109646=1 > > Added change for DP as well as HDMI in the patch series. > Also added a clean up patch to remove check for doublescan modes as that is no > longer required. Changes pushed to drm-intel-next. Thanks for the patch and reviews. Regards, Uma Shankar > Ankit Nautiyal (2): > drm/i915/display: Drop check for doublescan mode in modevalid > drm/i915/display: Prune Interlace modes for Display >=12 > > drivers/gpu/drm/i915/display/intel_dp.c | 7 ++- > drivers/gpu/drm/i915/display/intel_hdmi.c | 11 +++ > 2 files changed, 9 insertions(+), 9 deletions(-) > > -- > 2.25.1
Re: [Intel-gfx] [PATCH 11/11] video/aperture: Only remove sysfb on the default vga pci device
On 1/11/23 8:58 AM, Javier Martinez Canillas wrote:
Hello Daniel,
On 1/11/23 16:41, Daniel Vetter wrote:
This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable
sysfb device registration when removing conflicting FBs"), where we
remove the sysfb when loading a driver for an unrelated pci device,
resulting in the user loosing their efifb console or similar.
Note that in practice this only is a problem with the nvidia blob,
because that's the only gpu driver people might install which does not
come with an fbdev driver of it's own. For everyone else the real gpu
driver will restor a working console.
restore
Also note that in the referenced bug there's confusion that this same
bug also happens on amdgpu. But that was just another amdgpu specific
regression, which just happened to happen at roughly the same time and
with the same user-observable symptons. That bug is fixed now, see
symptoms
https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15
For the above reasons the cc: stable is just notionally, this patch
will need a backport and that's up to nvidia if they care enough.
Maybe adding a Fixes: ee7a69aa38d8 tag here too ?
References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28
Signed-off-by: Daniel Vetter
Cc: Aaron Plattner
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Cc: Helge Deller
Cc: Sam Ravnborg
Cc: Alex Deucher
Cc: # v5.19+ (if someone else does the backport)
---
drivers/video/aperture.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
index ba565515480d..a1821d369bb1 100644
--- a/drivers/video/aperture.c
+++ b/drivers/video/aperture.c
@@ -321,15 +321,16 @@ int aperture_remove_conflicting_pci_devices(struct
pci_dev *pdev, const char *na
primary = pdev == vga_default_device();
+ if (primary)
+ sysfb_disable();
+
for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
continue;
base = pci_resource_start(pdev, bar);
size = pci_resource_len(pdev, bar);
- ret = aperture_remove_conflicting_devices(base, size, name);
- if (ret)
- return ret;
+ aperture_detach_devices(base, size);
Maybe mention in the commit message that you are doing this change, something
like:
"Instead of calling aperture_remove_conflicting_devices() to remove the
conflicting
devices, just call to aperture_detach_devices() to detach the device that
matches
the same PCI BAR / aperture range. Since the former is just a wrapper of the
latter
plus a sysfb_disable() call, and now that's done in this function but only for
the
primary devices"
Patch looks good to me:
Reviewed-by: Javier Martinez Canillas
Thanks Daniel and Javier!
I wasn't able to reproduce the original problem on my hybrid laptop
since it refuses to boot with the console on an external display, but I
was able to reproduce it by switching the configuration around: booting
with i915.modeset=0 and with an experimental version of nvidia-drm that
registers a framebuffer console. I verified that loading nvidia-drm
breaks the efi-firmware framebuffer on Intel on Arch's
linux-6.1.4-arch1-1 kernel and that applying this patch series fixes it. So
Tested-by: Aaron Plattner
FWIW, the bug ought to be reproducible with i915.modeset=0 + any other
drm driver that registers a framebuffer.
-- Aaron
[Intel-gfx] ✓ Fi.CI.IGT: success for Allow error capture without a request / on reset failure (rev2)
== Series Details ==
Series: Allow error capture without a request / on reset failure (rev2)
URL : https://patchwork.freedesktop.org/series/111454/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12574_full -> Patchwork_111454v2_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/index.html
Participating hosts (13 -> 9)
--
Missing(4): shard-rkl0 pig-kbl-iris pig-glk-j5005 pig-skl-6260u
Known issues
Here are the changes found in Patchwork_111454v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none@vcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-glk7/igt@gem_exec_fair@basic-n...@vcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/shard-glk4/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: NOTRUN -> [FAIL][3] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/shard-glk5/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_lmem_swapping@heavy-multi:
- shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/shard-glk5/igt@gem_lmem_swapp...@heavy-multi.html
* igt@gem_pread@exhaustion:
- shard-glk: NOTRUN -> [WARN][5] ([i915#2658])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/shard-glk5/igt@gem_pr...@exhaustion.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][6] -> [DMESG-WARN][7] ([i915#5566] /
[i915#716])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-glk9/igt@gen9_exec_pa...@allowed-single.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/shard-glk5/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886]) +3
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/shard-glk5/igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium_color@ctm-blue-to-red:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271]) +33 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/shard-glk5/igt@kms_chamelium_co...@ctm-blue-to-red.html
* igt@runner@aborted:
- shard-glk: NOTRUN -> [FAIL][10] ([i915#4312])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/shard-glk5/igt@run...@aborted.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][11] ([i915#7742]) -> [PASS][12] +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-rkl-3/igt@drm_fdi...@virtual-idle.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/shard-rkl-5/igt@drm_fdi...@virtual-idle.html
* igt@drm_read@short-buffer-nonblock:
- {shard-rkl}:[SKIP][13] ([i915#4098]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-rkl-3/igt@drm_r...@short-buffer-nonblock.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/shard-rkl-6/igt@drm_r...@short-buffer-nonblock.html
* igt@fbdev@unaligned-read:
- {shard-rkl}:[SKIP][15] ([i915#2582]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-rkl-3/igt@fb...@unaligned-read.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/shard-rkl-6/igt@fb...@unaligned-read.html
* igt@gem_ctx_persistence@hang:
- {shard-rkl}:[SKIP][17] ([i915#6252]) -> [PASS][18] +1 similar
issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-rkl-5/igt@gem_ctx_persiste...@hang.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/shard-rkl-4/igt@gem_ctx_persiste...@hang.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-glk: [FAIL][19] ([i915#2842]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-glk3/igt@gem_exec_fair@basic-p...@vcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/shard-glk8/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- {shard-rkl}:[SKIP][21] ([fdo#109313]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-rkl-3/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/shard-rkl-5/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html
*
[Intel-gfx] ✓ Fi.CI.IGT: success for Clean up some GuC related failure paths
== Series Details ==
Series: Clean up some GuC related failure paths
URL : https://patchwork.freedesktop.org/series/112708/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12574_full -> Patchwork_112708v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/index.html
Participating hosts (13 -> 9)
--
Missing(4): shard-rkl0 pig-kbl-iris pig-glk-j5005 pig-skl-6260u
Known issues
Here are the changes found in Patchwork_112708v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none@vcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-glk7/igt@gem_exec_fair@basic-n...@vcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/shard-glk1/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: NOTRUN -> [FAIL][3] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/shard-glk6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_lmem_swapping@heavy-verify-random-ccs:
- shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +2
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/shard-glk2/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html
* igt@gem_pread@exhaustion:
- shard-glk: NOTRUN -> [WARN][5] ([i915#2658])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/shard-glk6/igt@gem_pr...@exhaustion.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][6] -> [DMESG-WARN][7] ([i915#5566] /
[i915#716])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-glk9/igt@gen9_exec_pa...@allowed-single.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/shard-glk1/igt@gen9_exec_pa...@allowed-single.html
* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#658])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/shard-glk2/igt@i915_pm...@dc3co-vpb-simulation.html
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#3886]) +4
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/shard-glk2/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium_color@ctm-blue-to-red:
- shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271]) +55 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/shard-glk6/igt@kms_chamelium_co...@ctm-blue-to-red.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@b-hdmi-a2:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#79])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-glk5/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a2.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/shard-glk9/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a2.html
* igt@runner@aborted:
- shard-glk: NOTRUN -> [FAIL][13] ([i915#4312])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/shard-glk1/igt@run...@aborted.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][14] ([i915#7742]) -> [PASS][15] +1 similar
issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-rkl-4/igt@drm_fdinfo@i...@rcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/shard-rkl-3/igt@drm_fdinfo@i...@rcs0.html
* igt@drm_read@empty-block:
- {shard-rkl}:[SKIP][16] ([i915#4098]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-rkl-3/igt@drm_r...@empty-block.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/shard-rkl-6/igt@drm_r...@empty-block.html
* igt@gem_ctx_persistence@hang:
- {shard-rkl}:[SKIP][18] ([i915#6252]) -> [PASS][19] +1 similar
issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-rkl-5/igt@gem_ctx_persiste...@hang.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/shard-rkl-3/igt@gem_ctx_persiste...@hang.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-glk: [FAIL][20] ([i915#2842]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-glk3/igt@gem_exec_fair@basic-p...@vcs0.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/shard-glk2/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_exec_reloc@basic-gtt-cpu:
- {shard-rkl}:[SKIP][22] ([i915#3281]) -> [PASS][23]
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pxp: Add missing cleanup steps for PXP global-teardown
== Series Details ==
Series: drm/i915/pxp: Add missing cleanup steps for PXP global-teardown
URL : https://patchwork.freedesktop.org/series/112704/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12574_full -> Patchwork_112704v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/index.html
Participating hosts (13 -> 10)
--
Missing(3): pig-skl-6260u pig-kbl-iris pig-glk-j5005
Known issues
Here are the changes found in Patchwork_112704v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none@vcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-glk7/igt@gem_exec_fair@basic-n...@vcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/shard-glk8/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: NOTRUN -> [FAIL][3] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/shard-glk3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_lmem_swapping@heavy-verify-random-ccs:
- shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +2
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/shard-glk1/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html
* igt@gem_pread@exhaustion:
- shard-glk: NOTRUN -> [WARN][5] ([i915#2658])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/shard-glk3/igt@gem_pr...@exhaustion.html
* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#658])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/shard-glk1/igt@i915_pm...@dc3co-vpb-simulation.html
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3886]) +4
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/shard-glk1/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium_color@ctm-blue-to-red:
- shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271]) +55 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/shard-glk3/igt@kms_chamelium_co...@ctm-blue-to-red.html
* igt@perf@stress-open-close:
- shard-glk: [PASS][9] -> [INCOMPLETE][10] ([i915#5213])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-glk2/igt@p...@stress-open-close.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/shard-glk1/igt@p...@stress-open-close.html
* igt@runner@aborted:
- shard-glk: NOTRUN -> [FAIL][11] ([i915#4312])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/shard-glk1/igt@run...@aborted.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][12] ([i915#7742]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-rkl-2/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/shard-rkl-2/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@fbdev@read:
- {shard-rkl}:[SKIP][14] ([i915#2582]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-rkl-2/igt@fb...@read.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/shard-rkl-6/igt@fb...@read.html
* igt@gem_ctx_persistence@hang:
- {shard-rkl}:[SKIP][16] ([i915#6252]) -> [PASS][17] +1 similar
issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-rkl-5/igt@gem_ctx_persiste...@hang.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/shard-rkl-1/igt@gem_ctx_persiste...@hang.html
* igt@gem_exec_fair@basic-none@vecs0:
- {shard-rkl}:[FAIL][18] ([i915#2842]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-rkl-6/igt@gem_exec_fair@basic-n...@vecs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/shard-rkl-5/igt@gem_exec_fair@basic-n...@vecs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-glk: [FAIL][20] ([i915#2842]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-glk3/igt@gem_exec_fair@basic-p...@vcs0.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/shard-glk1/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_exec_reloc@basic-gtt-cpu:
- {shard-rkl}:[SKIP][22] ([i915#3281]) -> [PASS][23] +6 similar
issues
[22]:
[Intel-gfx] ✓ Fi.CI.IGT: success for Misc Meteorlake patches
== Series Details ==
Series: Misc Meteorlake patches
URL : https://patchwork.freedesktop.org/series/112700/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12574_full -> Patchwork_112700v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/index.html
Participating hosts (13 -> 9)
--
Missing(4): shard-rkl0 pig-kbl-iris pig-glk-j5005 pig-skl-6260u
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_112700v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rps@min-max-config-idle:
- {shard-dg1}:[SKIP][1] ([i915#6621]) -> [FAIL][2] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-dg1-14/igt@i915_pm_...@min-max-config-idle.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/shard-dg1-14/igt@i915_pm_...@min-max-config-idle.html
* igt@kms_color@ctm-0-50:
- {shard-rkl}:[SKIP][3] ([i915#3546] / [i915#4098]) -> [SKIP][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-rkl-3/igt@kms_co...@ctm-0-50.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/shard-rkl-5/igt@kms_co...@ctm-0-50.html
* igt@kms_cursor_crc@cursor-random-512x170:
- {shard-rkl}:[SKIP][5] ([i915#4098]) -> [SKIP][6] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-rkl-3/igt@kms_cursor_...@cursor-random-512x170.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/shard-rkl-5/igt@kms_cursor_...@cursor-random-512x170.html
* igt@kms_cursor_legacy@torture-move:
- {shard-rkl}:NOTRUN -> [SKIP][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/shard-rkl-5/igt@kms_cursor_leg...@torture-move.html
Known issues
Here are the changes found in Patchwork_112700v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-glk8/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/shard-glk9/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: NOTRUN -> [FAIL][10] ([i915#2842])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/shard-glk6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_lmem_swapping@heavy-verify-random-ccs:
- shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +2
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/shard-glk3/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html
* igt@gem_pread@exhaustion:
- shard-glk: NOTRUN -> [WARN][12] ([i915#2658])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/shard-glk6/igt@gem_pr...@exhaustion.html
* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#658])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/shard-glk3/igt@i915_pm...@dc3co-vpb-simulation.html
* igt@kms_async_flips@alternate-sync-async-flip@pipe-c-hdmi-a-1:
- shard-glk: [PASS][14] -> [FAIL][15] ([i915#2521])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-glk5/igt@kms_async_flips@alternate-sync-async-f...@pipe-c-hdmi-a-1.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/shard-glk1/igt@kms_async_flips@alternate-sync-async-f...@pipe-c-hdmi-a-1.html
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3886]) +4
similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/shard-glk3/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium_color@ctm-blue-to-red:
- shard-glk: NOTRUN -> [SKIP][17] ([fdo#109271]) +55 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/shard-glk6/igt@kms_chamelium_co...@ctm-blue-to-red.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][18] ([i915#7742]) -> [PASS][19] +1 similar
issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/shard-rkl-3/igt@drm_fdi...@virtual-idle.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/shard-rkl-2/igt@drm_fdi...@virtual-idle.html
* igt@fbdev@read:
- {shard-rkl}:
[Intel-gfx] ✓ Fi.CI.BAT: success for Allow error capture without a request / on reset failure (rev2)
== Series Details == Series: Allow error capture without a request / on reset failure (rev2) URL : https://patchwork.freedesktop.org/series/111454/ State : success == Summary == CI Bug Log - changes from CI_DRM_12574 -> Patchwork_111454v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/index.html Participating hosts (35 -> 33) -- Missing(2): fi-bsw-kefka fi-snb-2520m Known issues Here are the changes found in Patchwork_111454v2 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_pm_rpm@module-reload: - bat-dg1-5: [SKIP][1] -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/bat-dg1-5/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/bat-dg1-5/igt@i915_pm_...@module-reload.html Build changes - * Linux: CI_DRM_12574 -> Patchwork_111454v2 CI-20190529: 20190529 CI_DRM_12574: bf7f7c53ac622a3f6d6738d062e59dd21ce28bd7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7116: 79eb8984acd309108be713a8831e60667db67e21 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_111454v2: bf7f7c53ac622a3f6d6738d062e59dd21ce28bd7 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 7174352a1af9 drm/i915/guc: Add a debug print on GuC triggered reset 64b28fa8d1a2 drm/i915/guc: Look for a guilty context when an engine reset fails c5e5df132fda drm/i915: Allow error capture of a pending request 876a26a4e1cb drm/i915: Allow error capture without a request == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111454v2/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Allow error capture without a request / on reset failure (rev2)
== Series Details == Series: Allow error capture without a request / on reset failure (rev2) URL : https://patchwork.freedesktop.org/series/111454/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./drivers/gpu/drm/i915/intel_uncore.h:346:1: warning: trying to copy expression type 31 +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced symbol 'return'
Re: [Intel-gfx] [PATCH v3 1/1] drm/i915/pxp: Use drm_dbg if arb session failed due to fw version
On 12/21/2022 9:49 AM, Alan Previn wrote:
If PXP arb-session is being attempted on older hardware SKUs or
on hardware with older, unsupported, firmware versions, then don't
report the failure with a drm_error. Instead, look specifically for
the API-version error reply and drm_dbg that reply. In this case, the
user-space will eventually get a -ENODEV for the protected context
creation which is the correct behavior and we don't create unnecessary
drm_error's in our dmesg (for what is unsupported platforms).
LGTM. Is there a link to where these pxp status codes are documented?
Reviewed-by: Vinay Belgaumkar
Changes from prio revs:
v2 : - remove unnecessary newline. (Jani)
v1 : - print incorrect version from input packet, not output.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
index c2f23394f9b8..aaa8187a0afb 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
@@ -17,6 +17,7 @@
*/
enum pxp_status {
PXP_STATUS_SUCCESS = 0x0,
+ PXP_STATUS_ERROR_API_VERSION = 0x1002,
PXP_STATUS_OP_NOT_PERMITTED = 0x4013
};
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index d50354bfb993..73aa8015f828 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -298,6 +298,10 @@ int intel_pxp_tee_cmd_create_arb_session(struct intel_pxp
*pxp,
if (ret)
drm_err(>drm, "Failed to send tee msg ret=[%d]\n", ret);
+ else if (msg_out.header.status == PXP_STATUS_ERROR_API_VERSION)
+ drm_dbg(>drm, "PXP firmware version unsupported, requested:
"
+ "CMD-ID-[0x%08x] on API-Ver-[0x%08x]\n",
+ msg_in.header.command_id, msg_in.header.api_version);
else if (msg_out.header.status != 0x0)
drm_warn(>drm, "PXP firmware failed arb session init request
ret=[0x%08x]\n",
msg_out.header.status);
base-commit: cc44a1e87ea6b788868878295119398966f98a81
[Intel-gfx] [PATCH 4/4] drm/i915/guc: Add a debug print on GuC triggered reset
From: John Harrison
For understanding bug reports, it can be useful to have an explicit
dmesg print when a reset notification is received from GuC. As opposed
to simply inferring that this happened from other messages.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 99d09e3394597..0be7c27a436dd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4665,6 +4665,10 @@ static void guc_handle_context_reset(struct intel_guc
*guc,
{
trace_intel_context_reset(ce);
+ drm_dbg(_to_gt(guc)->i915->drm, "Got GuC reset of 0x%04X, exiting =
%d, banned = %d\n",
+ ce->guc_id.id, test_bit(CONTEXT_EXITING, >flags),
+ test_bit(CONTEXT_BANNED, >flags));
+
if (likely(intel_context_is_schedulable(ce))) {
capture_error_state(guc, ce);
guc_context_replay(ce);
--
2.39.0
[Intel-gfx] [PATCH 3/4] drm/i915/guc: Look for a guilty context when an engine reset fails
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown reasons that normally come down to a missing
w/a), it is useful to get as much information out of the system as
possible. Given that the GuC effectively dies on such a situation, it
is not possible to get a guilty context notification back. So do a
manual search instead. Given that GuC is dead, this is safe because
GuC won't be changing the engine state asynchronously.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b436dd7f12e42..99d09e3394597 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4754,11 +4754,24 @@ static void reset_fail_worker_func(struct work_struct
*w)
guc->submission_state.reset_fail_mask = 0;
spin_unlock_irqrestore(>submission_state.lock, flags);
- if (likely(reset_fail_mask))
+ if (likely(reset_fail_mask)) {
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ /*
+* GuC is toast at this point - it dead loops after sending the
failed
+* reset notification. So need to manually determine the guilty
context.
+* Note that it should be safe/reliable to do this here because
the GuC
+* is toast and will not be scheduling behind the KMD's back.
+*/
+ for_each_engine_masked(engine, gt, reset_fail_mask, id)
+ intel_guc_find_hung_context(engine);
+
intel_gt_handle_error(gt, reset_fail_mask,
I915_ERROR_CAPTURE,
- "GuC failed to reset engine mask=0x%x\n",
+ "GuC failed to reset engine mask=0x%x",
reset_fail_mask);
+ }
}
int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
--
2.39.0
[Intel-gfx] [PATCH 1/4] drm/i915: Allow error capture without a request
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active requests. For example, if the hang was in the context switch
itself then the breadcrumb write would have occurred and the KMD would
see an idle context.
In the interests of attempting to provide as much information as
possible about a hang, it seems wise to include the engine info
regardless of whether a request was found or not. As opposed to just
prentending there was no hang at all.
So update the error capture code to always record engine information
if an engine is given. Which means updating record_context() to take a
context instead of a request (which it only ever used to find the
context anyway). And split the request agnostic parts of
intel_engine_coredump_add_request() out into a seaprate function.
v2: Remove a duplicate 'if' statement (Umesh) and fix a put of a null
pointer.
Signed-off-by: John Harrison
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_gpu_error.c | 61 +++
1 file changed, 43 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9d5d5a397b64e..bd2cf7d235df0 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1370,14 +1370,14 @@ static void engine_record_execlists(struct
intel_engine_coredump *ee)
}
static bool record_context(struct i915_gem_context_coredump *e,
- const struct i915_request *rq)
+ struct intel_context *ce)
{
struct i915_gem_context *ctx;
struct task_struct *task;
bool simulated;
rcu_read_lock();
- ctx = rcu_dereference(rq->context->gem_context);
+ ctx = rcu_dereference(ce->gem_context);
if (ctx && !kref_get_unless_zero(>ref))
ctx = NULL;
rcu_read_unlock();
@@ -1396,8 +1396,8 @@ static bool record_context(struct
i915_gem_context_coredump *e,
e->guilty = atomic_read(>guilty_count);
e->active = atomic_read(>active_count);
- e->total_runtime = intel_context_get_total_runtime_ns(rq->context);
- e->avg_runtime = intel_context_get_avg_runtime_ns(rq->context);
+ e->total_runtime = intel_context_get_total_runtime_ns(ce);
+ e->avg_runtime = intel_context_get_avg_runtime_ns(ce);
simulated = i915_gem_context_no_error_capture(ctx);
@@ -1532,15 +1532,37 @@ intel_engine_coredump_alloc(struct intel_engine_cs
*engine, gfp_t gfp, u32 dump_
return ee;
}
+static struct intel_engine_capture_vma *
+engine_coredump_add_context(struct intel_engine_coredump *ee,
+ struct intel_context *ce,
+ gfp_t gfp)
+{
+ struct intel_engine_capture_vma *vma = NULL;
+
+ ee->simulated |= record_context(>context, ce);
+ if (ee->simulated)
+ return NULL;
+
+ /*
+* We need to copy these to an anonymous buffer
+* as the simplest method to avoid being overwritten
+* by userspace.
+*/
+ vma = capture_vma(vma, ce->ring->vma, "ring", gfp);
+ vma = capture_vma(vma, ce->state, "HW context", gfp);
+
+ return vma;
+}
+
struct intel_engine_capture_vma *
intel_engine_coredump_add_request(struct intel_engine_coredump *ee,
struct i915_request *rq,
gfp_t gfp)
{
- struct intel_engine_capture_vma *vma = NULL;
+ struct intel_engine_capture_vma *vma;
- ee->simulated |= record_context(>context, rq);
- if (ee->simulated)
+ vma = engine_coredump_add_context(ee, rq->context, gfp);
+ if (!vma)
return NULL;
/*
@@ -1550,8 +1572,6 @@ intel_engine_coredump_add_request(struct
intel_engine_coredump *ee,
*/
vma = capture_vma_snapshot(vma, rq->batch_res, gfp, "batch");
vma = capture_user(vma, rq, gfp);
- vma = capture_vma(vma, rq->ring->vma, "ring", gfp);
- vma = capture_vma(vma, rq->context->state, "HW context", gfp);
ee->rq_head = rq->head;
ee->rq_post = rq->postfix;
@@ -1608,8 +1628,11 @@ capture_engine(struct intel_engine_cs *engine,
if (ce) {
intel_engine_clear_hung_context(engine);
rq = intel_context_find_active_request(ce);
- if (!rq || !i915_request_started(rq))
- goto no_request_capture;
+ if (rq && !i915_request_started(rq)) {
+ drm_info(>gt->i915->drm, "Got hung context on
%s with no active request!\n",
+engine->name);
+ rq = NULL;
+ }
} else {
[Intel-gfx] [PATCH 2/4] drm/i915: Allow error capture of a pending request
From: John Harrison
A hang situation has been observed where the only requests on the
context were either completed or not yet started according to the
breaadcrumbs. However, the register state claimed a batch was (maybe)
in progress. So, allow capture of the pending request on the grounds
that this might be better than nothing.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gpu_error.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index bd2cf7d235df0..2e338a9667a4b 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1628,11 +1628,9 @@ capture_engine(struct intel_engine_cs *engine,
if (ce) {
intel_engine_clear_hung_context(engine);
rq = intel_context_find_active_request(ce);
- if (rq && !i915_request_started(rq)) {
- drm_info(>gt->i915->drm, "Got hung context on
%s with no active request!\n",
-engine->name);
- rq = NULL;
- }
+ if (rq && !i915_request_started(rq))
+ drm_info(>gt->i915->drm, "Confused - active
request not yet started: %lld:%lld, ce = 0x%04X/%s!\n",
+rq->fence.context, rq->fence.seqno,
ce->guc_id.id, engine->name);
} else {
/*
* Getting here with GuC enabled means it is a forced error
capture
--
2.39.0
[Intel-gfx] [PATCH 0/4] Allow error capture without a request / on reset failure
From: John Harrison It is technically possible to get a hung context without a valid request. In such a situation, try to provide as much information in the error capture as possible rather than just aborting and capturing nothing. Similarly, in the case of an engine reset failure the GuC is not able to report the guilty context. So try a manual search instead of reporting nothing. Signed-off-by: John Harrison John Harrison (4): drm/i915: Allow error capture without a request drm/i915: Allow error capture of a pending request drm/i915/guc: Look for a guilty context when an engine reset fails drm/i915/guc: Add a debug print on GuC triggered reset .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 21 ++- drivers/gpu/drm/i915/i915_gpu_error.c | 59 +-- 2 files changed, 60 insertions(+), 20 deletions(-) -- 2.39.0
Re: [Intel-gfx] [PATCH 4/5] drm/vmwgfx: Remove redundant framebuffer format check
On Mon, 2023-01-09 at 07:58 -0300, Maíra Canal wrote:
> Now that framebuffer_check() verifies that the format is properly
> supported, there is no need to check it again on vmwgfx's inside
> helpers.
>
> Therefore, remove the redundant framebuffer format check from the
> vmw_kms_new_framebuffer_surface() and vmw_kms_new_framebuffer_bo()
> functions, letting framebuffer_check() perform the framebuffer
> validation.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 18 --
> 1 file changed, 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 257f090071f1..05b8d8f912bf 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -1317,15 +1317,6 @@ static int vmw_kms_new_framebuffer_surface(struct
> vmw_private *dev_priv,
> * Sanity checks.
> */
>
> - if (!drm_any_plane_has_format(_priv->drm,
> - mode_cmd->pixel_format,
> - mode_cmd->modifier[0])) {
> - drm_dbg(_priv->drm,
> - "unsupported pixel format %p4cc / modifier 0x%llx\n",
> - _cmd->pixel_format, mode_cmd->modifier[0]);
> - return -EINVAL;
> - }
> -
> /* Surface must be marked as a scanout. */
> if (unlikely(!surface->metadata.scanout))
> return -EINVAL;
> @@ -1648,15 +1639,6 @@ static int vmw_kms_new_framebuffer_bo(struct
> vmw_private
> *dev_priv,
> return -EINVAL;
> }
>
> - if (!drm_any_plane_has_format(_priv->drm,
> - mode_cmd->pixel_format,
> - mode_cmd->modifier[0])) {
> - drm_dbg(_priv->drm,
> - "unsupported pixel format %p4cc / modifier 0x%llx\n",
> - _cmd->pixel_format, mode_cmd->modifier[0]);
> - return -EINVAL;
> - }
> -
> vfbd = kzalloc(sizeof(*vfbd), GFP_KERNEL);
> if (!vfbd) {
> ret = -ENOMEM;
That's a nice cleanup. Thanks.
Reviewed-by: Zack Rusin
[Intel-gfx] ✓ Fi.CI.BAT: success for Clean up some GuC related failure paths
== Series Details == Series: Clean up some GuC related failure paths URL : https://patchwork.freedesktop.org/series/112708/ State : success == Summary == CI Bug Log - changes from CI_DRM_12574 -> Patchwork_112708v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/index.html Participating hosts (35 -> 34) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_112708v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_gttfill@basic: - fi-pnv-d510:[PASS][1] -> [FAIL][2] ([i915#7229]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/fi-pnv-d510/igt@gem_exec_gttf...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html Possible fixes * igt@i915_pm_rpm@module-reload: - bat-dg1-5: [SKIP][3] -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/bat-dg1-5/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/bat-dg1-5/igt@i915_pm_...@module-reload.html [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229 Build changes - * Linux: CI_DRM_12574 -> Patchwork_112708v1 CI-20190529: 20190529 CI_DRM_12574: bf7f7c53ac622a3f6d6738d062e59dd21ce28bd7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7116: 79eb8984acd309108be713a8831e60667db67e21 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_112708v1: bf7f7c53ac622a3f6d6738d062e59dd21ce28bd7 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 6aa0e5127b05 drm/i915/guc: Fix missing return code checks in submission init 882f4daee3b3 drm/i915/guc: Improve clean up of busyness stats worker == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112708v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Clean up some GuC related failure paths
== Series Details == Series: Clean up some GuC related failure paths URL : https://patchwork.freedesktop.org/series/112708/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] [PATCH 2/2] drm/i915/guc: Fix missing return code checks in submission init
From: John Harrison
The CI results for the 'fast request' patch set (enables error return
codes for fire-and-forget H2G messages) hit an issue with the KMD
sending context submission requests on an invalid context. That was
caused by a fault injection probe failing the context creation of a
kernel context. However, there was no return code checking on any of
the kernel context registration paths. So the driver kept going and
tried to use the kernel context for the record defaults process.
This would not cause any actual problems. The invalid requests would
be rejected by GuC and ultimately the start up sequence would
correctly wedge due to the context creation failure. But fixing the
issue correctly rather ignoring it means we won't get CI complaining
when the fast request patch lands and enables the extra error checking.
So fix it by checking for errors and aborting as appropriate when
creating kernel contexts. While at it, clean up some other submission
init related failure cleanup paths. Also, rename guc_init_lrc_mapping
to guc_init_submission as the former name hasn't been valid in a long
time.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 91 ++-
.../gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 7 +-
3 files changed, 75 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 982364777d0c6..dd856fd92945b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1431,7 +1431,7 @@ static int guc_action_enable_usage_stats(struct intel_guc
*guc)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
}
-static void guc_init_engine_stats(struct intel_guc *guc)
+static int guc_init_engine_stats(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
intel_wakeref_t wakeref;
@@ -1447,6 +1447,8 @@ static void guc_init_engine_stats(struct intel_guc *guc)
cancel_delayed_work_sync(>timestamp.work);
drm_err(>i915->drm, "Failed to enable usage stats: %d!\n",
ret);
}
+
+ return ret;
}
static void guc_park_engine_stats(struct intel_guc *guc)
@@ -4108,9 +4110,11 @@ static void guc_set_default_submission(struct
intel_engine_cs *engine)
engine->submit_request = guc_submit_request;
}
-static inline void guc_kernel_context_pin(struct intel_guc *guc,
- struct intel_context *ce)
+static inline int guc_kernel_context_pin(struct intel_guc *guc,
+struct intel_context *ce)
{
+ int ret;
+
/*
* Note: we purposefully do not check the returns below because
* the registration can only fail if a reset is just starting.
@@ -4118,16 +4122,24 @@ static inline void guc_kernel_context_pin(struct
intel_guc *guc,
* isn't happening and even it did this code would be run again.
*/
- if (context_guc_id_invalid(ce))
- pin_guc_id(guc, ce);
+ if (context_guc_id_invalid(ce)) {
+ int ret = pin_guc_id(guc, ce);
+
+ if (ret < 0)
+ return ret;
+ }
if (!test_bit(CONTEXT_GUC_INIT, >flags))
guc_context_init(ce);
- try_context_registration(ce, true);
+ ret = try_context_registration(ce, true);
+ if (ret)
+ unpin_guc_id(guc, ce);
+
+ return ret;
}
-static inline void guc_init_lrc_mapping(struct intel_guc *guc)
+static inline int guc_init_submission(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
struct intel_engine_cs *engine;
@@ -4154,9 +4166,17 @@ static inline void guc_init_lrc_mapping(struct intel_guc
*guc)
struct intel_context *ce;
list_for_each_entry(ce, >pinned_contexts_list,
- pinned_contexts_link)
- guc_kernel_context_pin(guc, ce);
+ pinned_contexts_link) {
+ int ret = guc_kernel_context_pin(guc, ce);
+
+ if (ret) {
+ /* No point in trying to clean up as i915 will
wedge on failure */
+ return ret;
+ }
+ }
}
+
+ return 0;
}
static void guc_release(struct intel_engine_cs *engine)
@@ -4400,30 +4420,57 @@ static int guc_init_global_schedule_policy(struct
intel_guc *guc)
return ret;
}
-void intel_guc_submission_enable(struct intel_guc *guc)
+static void guc_route_semaphores(struct intel_guc *guc, bool to_guc)
{
struct intel_gt *gt = guc_to_gt(guc);
+ u32 val;
- /* Enable and route to GuC */
- if (GRAPHICS_VER(gt->i915) >= 12)
-
[Intel-gfx] [PATCH 0/2] Clean up some GuC related failure paths
From: John Harrison Improve failure code handling during GuC intialisation. Signed-off-by: John Harrison John Harrison (2): drm/i915/guc: Improve clean up of busyness stats worker drm/i915/guc: Fix missing return code checks in submission init .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 113 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 7 +- 3 files changed, 89 insertions(+), 33 deletions(-) -- 2.39.0
[Intel-gfx] [PATCH 1/2] drm/i915/guc: Improve clean up of busyness stats worker
From: John Harrison
The stats worker thread management was mis-matched between
enable/disable call sites. Fix those up. Also, abstract the cancel
code into a helper function rather than replicating in multiple places.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 22 ---
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b436dd7f12e42..982364777d0c6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1435,19 +1435,25 @@ static void guc_init_engine_stats(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
intel_wakeref_t wakeref;
+ int ret;
mod_delayed_work(system_highpri_wq, >timestamp.work,
guc->timestamp.ping_delay);
- with_intel_runtime_pm(>i915->runtime_pm, wakeref) {
- int ret = guc_action_enable_usage_stats(guc);
+ with_intel_runtime_pm(>i915->runtime_pm, wakeref)
+ ret = guc_action_enable_usage_stats(guc);
- if (ret)
- drm_err(>i915->drm,
- "Failed to enable usage stats: %d!\n", ret);
+ if (ret) {
+ cancel_delayed_work_sync(>timestamp.work);
+ drm_err(>i915->drm, "Failed to enable usage stats: %d!\n",
ret);
}
}
+static void guc_park_engine_stats(struct intel_guc *guc)
+{
+ cancel_delayed_work_sync(>timestamp.work);
+}
+
void intel_guc_busyness_park(struct intel_gt *gt)
{
struct intel_guc *guc = >uc.guc;
@@ -1460,7 +1466,7 @@ void intel_guc_busyness_park(struct intel_gt *gt)
* and causes an unclaimed register access warning. Cancel the worker
* synchronously here.
*/
- cancel_delayed_work_sync(>timestamp.work);
+ guc_park_engine_stats(guc);
/*
* Before parking, we should sample engine busyness stats if we need to.
@@ -4409,11 +4415,11 @@ void intel_guc_submission_enable(struct intel_guc *guc)
guc_init_global_schedule_policy(guc);
}
+/* Note: By the time we're here, GuC may have already been reset */
void intel_guc_submission_disable(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
-
- /* Note: By the time we're here, GuC may have already been reset */
+ guc_park_engine_stats(guc);
/* Disable and route to host */
if (GRAPHICS_VER(gt->i915) >= 12)
--
2.39.0
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: Add missing cleanup steps for PXP global-teardown
== Series Details == Series: drm/i915/pxp: Add missing cleanup steps for PXP global-teardown URL : https://patchwork.freedesktop.org/series/112704/ State : success == Summary == CI Bug Log - changes from CI_DRM_12574 -> Patchwork_112704v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/index.html Participating hosts (35 -> 33) -- Missing(2): fi-bsw-kefka fi-snb-2520m Known issues Here are the changes found in Patchwork_112704v1 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_pm_rpm@module-reload: - bat-dg1-5: [SKIP][1] -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/bat-dg1-5/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/bat-dg1-5/igt@i915_pm_...@module-reload.html Build changes - * Linux: CI_DRM_12574 -> Patchwork_112704v1 CI-20190529: 20190529 CI_DRM_12574: bf7f7c53ac622a3f6d6738d062e59dd21ce28bd7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7116: 79eb8984acd309108be713a8831e60667db67e21 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_112704v1: bf7f7c53ac622a3f6d6738d062e59dd21ce28bd7 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 7e462680cadc drm/i915/pxp: Pxp hw init should be in resume_complete 346c8e86046a drm/i915/pxp: Trigger the global teardown for before suspending 1a20b32177dc drm/i915/pxp: Invalidate all PXP fw sessions during teardown cf3e6afaf4b7 mei: clean pending read with vtag on bus fcc41bb6264f drm/i915/pxp: add device link between i915 and mei_pxp d32aca4b9d05 mei: mei-me: resume device in prepare == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112704v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pxp: Add missing cleanup steps for PXP global-teardown
== Series Details == Series: drm/i915/pxp: Add missing cleanup steps for PXP global-teardown URL : https://patchwork.freedesktop.org/series/112704/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning:
[Intel-gfx] ✓ Fi.CI.BAT: success for Misc Meteorlake patches
== Series Details ==
Series: Misc Meteorlake patches
URL : https://patchwork.freedesktop.org/series/112700/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12574 -> Patchwork_112700v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/index.html
Participating hosts (35 -> 34)
--
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_112700v1 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_pm_rpm@module-reload:
- bat-dg1-5: [SKIP][1] -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/bat-dg1-5/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/bat-dg1-5/igt@i915_pm_...@module-reload.html
* igt@i915_pm_rps@basic-api:
- {bat-adlp-9}: [SKIP][3] ([i915#6621]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/bat-adlp-9/igt@i915_pm_...@basic-api.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/bat-adlp-9/igt@i915_pm_...@basic-api.html
- fi-rkl-guc: [SKIP][5] ([i915#6621]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/fi-rkl-guc/igt@i915_pm_...@basic-api.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/fi-rkl-guc/igt@i915_pm_...@basic-api.html
- {bat-adlp-6}: [SKIP][7] ([i915#6621]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/bat-adlp-6/igt@i915_pm_...@basic-api.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/bat-adlp-6/igt@i915_pm_...@basic-api.html
- bat-dg1-5: [SKIP][9] ([i915#6621]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/bat-dg1-5/igt@i915_pm_...@basic-api.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/bat-dg1-5/igt@i915_pm_...@basic-api.html
- {bat-atsm-1}: [SKIP][11] ([i915#6621]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/bat-atsm-1/igt@i915_pm_...@basic-api.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/bat-atsm-1/igt@i915_pm_...@basic-api.html
- {bat-dg2-9}:[SKIP][13] ([i915#6621]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/bat-dg2-9/igt@i915_pm_...@basic-api.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/bat-dg2-9/igt@i915_pm_...@basic-api.html
- {bat-dg2-8}:[SKIP][15] ([i915#6621]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/bat-dg2-8/igt@i915_pm_...@basic-api.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/bat-dg2-8/igt@i915_pm_...@basic-api.html
- {bat-adlm-1}: [SKIP][17] ([i915#6621]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/bat-adlm-1/igt@i915_pm_...@basic-api.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/bat-adlm-1/igt@i915_pm_...@basic-api.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
Build changes
-
* Linux: CI_DRM_12574 -> Patchwork_112700v1
CI-20190529: 20190529
CI_DRM_12574: bf7f7c53ac622a3f6d6738d062e59dd21ce28bd7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7116: 79eb8984acd309108be713a8831e60667db67e21 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_112700v1: bf7f7c53ac622a3f6d6738d062e59dd21ce28bd7 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
ac7077d92aa1 drm/i915/display/mtl: Program latch to phy reset
2c4b63164d72 drm/i915/mtl: Skip pcode qgv restrictions for MTL
a71018c5f934 drm/i915/fbdev: lock the fbdev obj before vma pin
d59786576cb6 drm/i915/debugfs: Multiplex upper layer interfaces to act on all
gt's
93359bcaba20 drm/i915/gt: generate per gt debugfs files
414d49e9bfe9 drm/i915/mtl: make IRQ reset and postinstall multi-gt aware
4a6231255325 drm/i915/mtl: Fix Wa_14015855405 implementation
b04d2feafbdb drm/i915/mtl: Initialize empty clockgating hooks for MTL
9a5a36096d5d drm/i915/mtl: Fix bcs default context
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112700v1/index.html
[Intel-gfx] [PATCH v4 6/6] drm/i915/pxp: Pxp hw init should be in resume_complete
During suspend flow, i915 currently achors' on the pm_suspend_prepare
callback as the location where we quiesce the entire GPU and perform
all necessary cleanup in order to go into suspend. PXP is also called
during this time to perform the arbitration session teardown (with
the assurance no additional GEM IOCTLs will come after that could
restart the session).
However, if other devices or drivers fail their suspend_prepare, the
system will not go into suspend and i915 will be expected to resume
operation. In this case, we need to re-initialize the PXP hardware
and this really should be done within the pm_resume_complete callback
which is the correct opposing function in the resume sequence to
match pm_suspend_prepare of the suspend sequence.
Because this callback is the last thing at the end of resuming
we expect little to no impact to the rest of the i915 resume sequence
with this change.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/intel_gt_pm.h | 1 +
drivers/gpu/drm/i915/i915_driver.c | 20 ++--
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 6 +++---
4 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index 6c9a46452364..fd1a23621222 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -77,6 +77,7 @@ void intel_gt_pm_fini(struct intel_gt *gt);
void intel_gt_suspend_prepare(struct intel_gt *gt);
void intel_gt_suspend_late(struct intel_gt *gt);
+
int intel_gt_resume(struct intel_gt *gt);
void intel_gt_runtime_suspend(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index c1e427ba57ae..c3e7c40daaeb 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1170,6 +1170,13 @@ static bool suspend_to_idle(struct drm_i915_private
*dev_priv)
return false;
}
+static void i915_drm_complete(struct drm_device *dev)
+{
+ struct drm_i915_private *i915 = to_i915(dev);
+
+ intel_pxp_resume_complete(i915->pxp);
+}
+
static int i915_drm_prepare(struct drm_device *dev)
{
struct drm_i915_private *i915 = to_i915(dev);
@@ -1370,8 +1377,6 @@ static int i915_drm_resume(struct drm_device *dev)
i915_gem_resume(dev_priv);
- intel_pxp_resume(dev_priv->pxp);
-
intel_modeset_init_hw(dev_priv);
intel_init_clock_gating(dev_priv);
intel_hpd_init(dev_priv);
@@ -1484,6 +1489,16 @@ int i915_driver_resume_switcheroo(struct
drm_i915_private *i915)
return i915_drm_resume(>drm);
}
+static void i915_pm_complete(struct device *kdev)
+{
+ struct drm_i915_private *i915 = kdev_to_i915(kdev);
+
+ if (!i915)
+ dev_err(kdev, "DRM not initialized, aborting suspend.\n");
+
+ i915_drm_complete(>drm);
+}
+
static int i915_pm_prepare(struct device *kdev)
{
struct drm_i915_private *i915 = kdev_to_i915(kdev);
@@ -1779,6 +1794,7 @@ const struct dev_pm_ops i915_pm_ops = {
* PMSG_RESUME]
*/
.prepare = i915_pm_prepare,
+ .complete = i915_pm_complete,
.suspend = i915_pm_suspend,
.suspend_late = i915_pm_suspend_late,
.resume_early = i915_pm_resume_early,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index e427464aa131..4f836b317424 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -34,7 +34,7 @@ void intel_pxp_suspend(struct intel_pxp *pxp)
}
}
-void intel_pxp_resume(struct intel_pxp *pxp)
+void intel_pxp_resume_complete(struct intel_pxp *pxp)
{
if (!intel_pxp_is_enabled(pxp))
return;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
index 586be769104f..06b46f535b42 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
@@ -11,7 +11,7 @@ struct intel_pxp;
#ifdef CONFIG_DRM_I915_PXP
void intel_pxp_suspend_prepare(struct intel_pxp *pxp);
void intel_pxp_suspend(struct intel_pxp *pxp);
-void intel_pxp_resume(struct intel_pxp *pxp);
+void intel_pxp_resume_complete(struct intel_pxp *pxp);
void intel_pxp_runtime_suspend(struct intel_pxp *pxp);
#else
static inline void intel_pxp_suspend_prepare(struct intel_pxp *pxp)
@@ -22,7 +22,7 @@ static inline void intel_pxp_suspend(struct intel_pxp *pxp)
{
}
-static inline void intel_pxp_resume(struct intel_pxp *pxp)
+static inline void intel_pxp_resume_complete(struct intel_pxp *pxp)
{
}
@@ -32,6 +32,6 @@ static inline void intel_pxp_runtime_suspend(struct intel_pxp
*pxp)
#endif
static inline void intel_pxp_runtime_resume(struct intel_pxp *pxp)
{
- intel_pxp_resume(pxp);
+ intel_pxp_resume_complete(pxp);
}
#endif /* __INTEL_PXP_PM_H__ */
--
2.39.0
[Intel-gfx] [PATCH v4 5/6] drm/i915/pxp: Trigger the global teardown for before suspending
A driver bug was recently discovered where the security firmware was
receiving internal HW signals indicating that session key expirations
had occurred. Architecturally, the firmware was expecting a response
from the GuC to acknowledge the event with the firmware side.
However the OS was in a suspended state and GuC had been reset.
Internal specifications actually required the driver to ensure
that all active sessions be properly cleaned up in such cases where
the system is suspended and the GuC potentially unable to respond.
This patch adds the global teardown code in i915's suspend_prepare
code path.
Signed-off-by: Alan Previn
Reviewed-by: Juston Li
---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 60 +---
drivers/gpu/drm/i915/pxp/intel_pxp.h | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 9 ++-
drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 5 ++
5 files changed, 64 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index cfc9af8b3d21..f3d9e7989eb7 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -270,6 +270,55 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
return bound;
}
+static int __pxp_global_teardown_locked(struct intel_pxp *pxp, bool
terminate_for_cleanup)
+{
+ if (terminate_for_cleanup) {
+ if (!pxp->arb_is_valid)
+ return 0;
+ /*
+* To ensure synchronous and coherent session teardown
completion
+* in response to suspend or shutdown triggers, don't use a
worker.
+*/
+ intel_pxp_mark_termination_in_progress(pxp);
+ intel_pxp_terminate(pxp, false);
+ } else {
+ if (pxp->arb_is_valid)
+ return 0;
+ /*
+* If we are not in final termination, and the arb-session is
currently
+* inactive, we are doing a reset and restart due to some
runtime event.
+* Use the worker that was designed for this.
+*/
+ pxp_queue_termination(pxp);
+ }
+
+ if (!wait_for_completion_timeout(>termination,
msecs_to_jiffies(250)))
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
+void intel_pxp_end(struct intel_pxp *pxp)
+{
+ struct drm_i915_private *i915 = pxp->ctrl_gt->i915;
+ intel_wakeref_t wakeref;
+
+ if (!intel_pxp_is_enabled(pxp))
+ return;
+
+ wakeref = intel_runtime_pm_get(>runtime_pm);
+
+ mutex_lock(>arb_mutex);
+
+ if (__pxp_global_teardown_locked(pxp, true))
+ drm_dbg(>drm, "PXP end timed out\n");
+
+ mutex_unlock(>arb_mutex);
+
+ intel_pxp_fini_hw(pxp);
+ intel_runtime_pm_put(>runtime_pm, wakeref);
+}
+
/*
* the arb session is restarted from the irq work when we receive the
* termination completion interrupt
@@ -286,16 +335,9 @@ int intel_pxp_start(struct intel_pxp *pxp)
mutex_lock(>arb_mutex);
- if (pxp->arb_is_valid)
- goto unlock;
-
- pxp_queue_termination(pxp);
-
- if (!wait_for_completion_timeout(>termination,
- msecs_to_jiffies(250))) {
- ret = -ETIMEDOUT;
+ ret = __pxp_global_teardown_locked(pxp, false);
+ if (ret)
goto unlock;
- }
/* make sure the compiler doesn't optimize the double access */
barrier();
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 9658d3005222..3ded0890cd27 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -27,6 +27,7 @@ void intel_pxp_mark_termination_in_progress(struct intel_pxp
*pxp);
void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
arb_session_id);
int intel_pxp_start(struct intel_pxp *pxp);
+void intel_pxp_end(struct intel_pxp *pxp);
int intel_pxp_key_check(struct intel_pxp *pxp,
struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 892d39cc61c1..e427464aa131 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -16,7 +16,7 @@ void intel_pxp_suspend_prepare(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return;
- pxp->arb_is_valid = false;
+ intel_pxp_end(pxp);
intel_pxp_invalidate(pxp);
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 74ed7e16e481..d8278c4002e3 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -115,11 +115,14 @@ static int
[Intel-gfx] [PATCH v4 2/6] drm/i915/pxp: add device link between i915 and mei_pxp
From: Alexander Usyskin
Add device link with i915 as consumer and mei_pxp as supplier
to ensure proper ordering of power flows.
V2: condition on absence of heci_pxp to filter out DG
Signed-off-by: Alexander Usyskin
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index d50354bfb993..bef6d7f8ac55 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -127,6 +127,10 @@ static int i915_pxp_tee_component_bind(struct device
*i915_kdev,
intel_wakeref_t wakeref;
int ret = 0;
+ if (!HAS_HECI_PXP(i915) &&
+ drm_WARN_ON(>drm, !device_link_add(i915_kdev, tee_kdev,
DL_FLAG_STATELESS)))
+ return -ENOMEM;
+
mutex_lock(>tee_mutex);
pxp->pxp_component = data;
pxp->pxp_component->tee_dev = tee_kdev;
@@ -169,6 +173,9 @@ static void i915_pxp_tee_component_unbind(struct device
*i915_kdev,
mutex_lock(>tee_mutex);
pxp->pxp_component = NULL;
mutex_unlock(>tee_mutex);
+
+ if (!HAS_HECI_PXP(i915))
+ device_link_remove(i915_kdev, tee_kdev);
}
static const struct component_ops i915_pxp_tee_component_ops = {
--
2.39.0
[Intel-gfx] [PATCH v4 4/6] drm/i915/pxp: Invalidate all PXP fw sessions during teardown
A gap was recently discovered where if an application did not
invalidate all of the stream keys (intentionally or not), and the
driver did a full PXP global teardown on the GT subsystem, we
find that future session creation would fail on the security
firmware's side of the equation. i915 is the entity that needs
ensure the sessions' state across both iGT and security firmware
are at a known clean point when performing a full global teardown.
Architecturally speaking, i915 should inspect all active sessions
and submit the invalidate-stream-key PXP command to the security
firmware for each of them. However, for the upstream i915 driver
we only support the arbitration session that can be created
so that will be the only session we will cleanup.
Signed-off-by: Alan Previn
Reviewed-by: Juston Li
---
drivers/gpu/drm/i915/pxp/intel_pxp.h | 1 +
.../drm/i915/pxp/intel_pxp_cmd_interface_42.h | 15
.../i915/pxp/intel_pxp_cmd_interface_cmn.h| 3 ++
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 ++
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 35 +++
5 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 04440fada711..9658d3005222 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -24,6 +24,7 @@ void intel_pxp_init_hw(struct intel_pxp *pxp);
void intel_pxp_fini_hw(struct intel_pxp *pxp);
void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
+void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
arb_session_id);
int intel_pxp_start(struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
index 739f9072fa5f..26f7d9f01bf3 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
@@ -12,6 +12,9 @@
/* PXP-Opcode for Init Session */
#define PXP42_CMDID_INIT_SESSION 0x1e
+/* PXP-Opcode for Invalidate Stream Key */
+#define PXP42_CMDID_INVALIDATE_STREAM_KEY 0x0007
+
/* PXP-Input-Packet: Init Session (Arb-Session) */
struct pxp42_create_arb_in {
struct pxp_cmd_header header;
@@ -25,4 +28,16 @@ struct pxp42_create_arb_out {
struct pxp_cmd_header header;
} __packed;
+/* PXP-Input-Packet: Invalidate Stream Key */
+struct pxp42_inv_stream_key_in {
+ struct pxp_cmd_header header;
+ u32 rsvd[3];
+} __packed;
+
+/* PXP-Output-Packet: Invalidate Stream Key */
+struct pxp42_inv_stream_key_out {
+ struct pxp_cmd_header header;
+ u32 rsvd;
+} __packed;
+
#endif /* __INTEL_PXP_FW_INTERFACE_42_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
index c2f23394f9b8..69e34ec49e78 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
@@ -27,6 +27,9 @@ struct pxp_cmd_header {
union {
u32 status; /* out */
u32 stream_id; /* in */
+#define PXP_CMDHDR_EXTDATA_SESSION_VALID GENMASK(0, 0)
+#define PXP_CMDHDR_EXTDATA_APP_TYPE GENMASK(1, 1)
+#define PXP_CMDHDR_EXTDATA_SESSION_ID GENMASK(17, 2)
};
/* Length of the message (excluding the header) */
u32 buffer_len;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index ae413580b81a..74ed7e16e481 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -110,6 +110,8 @@ static int pxp_terminate_arb_session_and_global(struct
intel_pxp *pxp)
intel_uncore_write(gt->uncore, PXP_GLOBAL_TERMINATE, 1);
+ intel_pxp_tee_end_arb_fw_session(pxp, ARB_SESSION);
+
return ret;
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index bef6d7f8ac55..9e247f38f3bd 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -311,3 +311,38 @@ int intel_pxp_tee_cmd_create_arb_session(struct intel_pxp
*pxp,
return ret;
}
+
+void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32 session_id)
+{
+ struct drm_i915_private *i915 = pxp->ctrl_gt->i915;
+ struct pxp42_inv_stream_key_in msg_in = {0};
+ struct pxp42_inv_stream_key_out msg_out = {0};
+ int ret, trials = 0;
+
+try_again:
+ memset(_in, 0, sizeof(msg_in));
+ memset(_out, 0, sizeof(msg_out));
+ msg_in.header.api_version = PXP_APIVER(4, 2);
+ msg_in.header.command_id = PXP42_CMDID_INVALIDATE_STREAM_KEY;
+ msg_in.header.buffer_len = sizeof(msg_in) - sizeof(msg_in.header);
+
+ msg_in.header.stream_id = FIELD_PREP(PXP_CMDHDR_EXTDATA_SESSION_VALID,
1);
+ msg_in.header.stream_id |= FIELD_PREP(PXP_CMDHDR_EXTDATA_APP_TYPE, 0);
+
[Intel-gfx] [PATCH v4 3/6] mei: clean pending read with vtag on bus
From: Alexander Usyskin
Client on bus have only one vtag map slot and should disregard the vtag
value when cleaning pending read flag.
Fixes read flow control message unexpectedly generated when
clent on bus send messages with different vtags.
Signed-off-by: Alexander Usyskin
Signed-off-by: Alan Previn
---
drivers/misc/mei/client.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 9ddb854b8155..5c19097266fe 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -1343,7 +1343,9 @@ static void mei_cl_reset_read_by_vtag(const struct mei_cl
*cl, u8 vtag)
struct mei_cl_vtag *vtag_l;
list_for_each_entry(vtag_l, >vtag_map, list) {
- if (vtag_l->vtag == vtag) {
+ /* The client on bus has one fixed vtag map */
+ if ((cl->cldev && mei_cldev_enabled(cl->cldev)) ||
+ vtag_l->vtag == vtag) {
vtag_l->pending_read = false;
break;
}
--
2.39.0
[Intel-gfx] [PATCH v4 0/6] drm/i915/pxp: Add missing cleanup steps for PXP global-teardown
A customer issue was recently discovered and in the process a gap in i915's PXP interaction with HW+FW architecure was also realized. This series adds those missing pieces. This fix includes changes where i915 calls into the mei component interface in order to submit requests to the security firmware during the i915's suspend_prepare flow. This change did expose a blocking issue in the mei component side that was discovered while testing in rev1. The issue being the mei-pxp component driver not being able to runtime-resume while being within the suspend_prepare callstack. Thus, we have now included the mei patches (from Alexander) that fixes that issue by adding a device-link based on the interface type to ensure mei side runtime resume during the i915's suspend_prepare call. That said, as per request from Alexander, we seek Greg's and Tomas' review for the mei patches (Patch 1, 2 and 3). Patch 2, although is a change in the i915 code, is the mei component device link change. The individual patches explain more details. Patch 7 can be ignored as it won't be merged and is only meant to ensure the CI run's the PXP subtests with PXP support enabled in KConfig. Changes from prior revs: v1: - Dont need to teardown non-arbitration sessions (Juston). - Fix builds when PXP is enabled in config (Alan/CI-build). - Fix the broken pm-suspend-resume symmetry when we do this pxp-session-teardown during i915s pm_suspend_prepare by ensuring the init is done during i915s pm_resume_complete. v2: - Rebase on latest drm-tip after PXP subsytem was promoted to global. - Remove "INTEL_PXP_MAX_HWDRM_SESSIONS" unneeded (Juston Li). - Added mei patches that are dependencies for this series to successfully pass testing when PXP config is enabled. v3: - Added fix for mei patch when CONFIG_PM_SLEEP is off (reported by kernel test robot ). Alan Previn (3): drm/i915/pxp: Invalidate all PXP fw sessions during teardown drm/i915/pxp: Trigger the global teardown for before suspending drm/i915/pxp: Pxp hw init should be in resume_complete Alexander Usyskin (3): mei: mei-me: resume device in prepare drm/i915/pxp: add device link between i915 and mei_pxp mei: clean pending read with vtag on bus drivers/gpu/drm/i915/gt/intel_gt_pm.h | 1 + drivers/gpu/drm/i915/i915_driver.c| 20 ++- drivers/gpu/drm/i915/pxp/intel_pxp.c | 60 --- drivers/gpu/drm/i915/pxp/intel_pxp.h | 2 + .../drm/i915/pxp/intel_pxp_cmd_interface_42.h | 15 + .../i915/pxp/intel_pxp_cmd_interface_cmn.h| 3 + drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 4 +- drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 6 +- drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 11 +++- drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 5 ++ drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 42 + drivers/misc/mei/client.c | 4 +- drivers/misc/mei/pci-me.c | 20 ++- 13 files changed, 172 insertions(+), 21 deletions(-) base-commit: bf7f7c53ac622a3f6d6738d062e59dd21ce28bd7 -- 2.39.0
[Intel-gfx] [PATCH v4 1/6] mei: mei-me: resume device in prepare
From: Alexander Usyskin
Asynchronous runtime resume is not possible while the system
is suspending.
The power management subsystem resumes the device only in the
suspend phase, not in the prepare phase.
Force resume device in prepare to allow drivers on mei bus
to communicate in their prepare callbacks.
Signed-off-by: Alexander Usyskin
Signed-off-by: Alan Previn
---
drivers/misc/mei/pci-me.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
index 704cd0caa172..4280759739f0 100644
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -340,6 +340,12 @@ static void mei_me_remove(struct pci_dev *pdev)
}
#ifdef CONFIG_PM_SLEEP
+static int mei_me_pci_prepare(struct device *device)
+{
+ pm_runtime_resume(device);
+ return 0;
+}
+
static int mei_me_pci_suspend(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
@@ -396,7 +402,17 @@ static int mei_me_pci_resume(struct device *device)
return 0;
}
-#endif /* CONFIG_PM_SLEEP */
+
+static void mei_me_pci_complete(struct device *device)
+{
+ pm_runtime_suspend(device);
+}
+#else /* CONFIG_PM_SLEEP */
+
+#define mei_me_pci_prepare NULL
+#define mei_me_pci_suspend NULL
+
+#endif /* !CONFIG_PM_SLEEP */
#ifdef CONFIG_PM
static int mei_me_pm_runtime_idle(struct device *device)
@@ -499,6 +515,8 @@ static inline void mei_me_unset_pm_domain(struct mei_device
*dev)
}
static const struct dev_pm_ops mei_me_pm_ops = {
+ .prepare = mei_me_pci_prepare,
+ .complete = mei_me_pci_complete,
SET_SYSTEM_SLEEP_PM_OPS(mei_me_pci_suspend,
mei_me_pci_resume)
SET_RUNTIME_PM_OPS(
--
2.39.0
Re: [Intel-gfx] [PATCH dii-client 1/9] drm/i915/mtl: Fix bcs default context
On Wed, Jan 11, 2023 at 03:55:23PM -0800, Radhakrishna Sripada wrote:
> From: Lucas De Marchi
>
> Commit 0d0e7d1eea9e ("drm/i915/mtl: Define engine context layouts")
> added the engine context for Meteor Lake. In a second revision of the
> patch it was believed the xcs offsets were wrong due to a tagging
> issue in the spec. The first version was actually correct, as shown
> by the intel_lrc_live_selftests/live_lrc_layout test:
>
> i915: Running gt_lrc
> i915: Running intel_lrc_live_selftests/live_lrc_layout
> bcs0: LRI command mismatch at dword 1, expected 1108101d found 11081019
> [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]]
> [CONNECTOR:236:DP-1] disconnected
> bcs0: HW register image:
> [] 1108101d 00022244 0008 00022034 0088 00022030
> 0088
> ...
> bcs0: SW register image:
> [] 11081019 00022244 00090009 00022034 00022030
>
>
> The difference in the 2 additional dwords (0x1d vs 0x19) are the offsets
> 0x120 / 0x124 that are indeed part of the context image.
>
> Bspec: 45585
>
> Fixes: 0d0e7d1eea9e ("drm/i915/mtl: Define engine context layouts")
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Radhakrishna Sripada
Reviewed-by: Matt Roper
I'll poke the bspec people about getting the platform information fixed
for this so that we don't run into confusion here again.
Matt
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 37 +
> 1 file changed, 1 insertion(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 7771a19008c6..bbeeb6dde7ae 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -288,39 +288,6 @@ static const u8 dg2_xcs_offsets[] = {
> END
> };
>
> -static const u8 mtl_xcs_offsets[] = {
> - NOP(1),
> - LRI(13, POSTED),
> - REG16(0x244),
> - REG(0x034),
> - REG(0x030),
> - REG(0x038),
> - REG(0x03c),
> - REG(0x168),
> - REG(0x140),
> - REG(0x110),
> - REG(0x1c0),
> - REG(0x1c4),
> - REG(0x1c8),
> - REG(0x180),
> - REG16(0x2b4),
> - NOP(4),
> -
> - NOP(1),
> - LRI(9, POSTED),
> - REG16(0x3a8),
> - REG16(0x28c),
> - REG16(0x288),
> - REG16(0x284),
> - REG16(0x280),
> - REG16(0x27c),
> - REG16(0x278),
> - REG16(0x274),
> - REG16(0x270),
> -
> - END
> -};
> -
> static const u8 gen8_rcs_offsets[] = {
> NOP(1),
> LRI(14, POSTED),
> @@ -739,9 +706,7 @@ static const u8 *reg_offsets(const struct intel_engine_cs
> *engine)
> else
> return gen8_rcs_offsets;
> } else {
> - if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 70))
> - return mtl_xcs_offsets;
> - else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
> + if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
> return dg2_xcs_offsets;
> else if (GRAPHICS_VER(engine->i915) >= 12)
> return gen12_xcs_offsets;
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
[Intel-gfx] [PATCH dii-client 8/9] drm/i915/mtl: Skip pcode qgv restrictions for MTL
Communicating QGV points restriction to PUnit happens via PM Demand
instead of the Pcode mailbox in the previous platforms. GV point
restriction is handled by the PM demand code.
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_bw.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 1c236f02b380..6791b25eb72d 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -124,6 +124,9 @@ int icl_pcode_restrict_qgv_points(struct drm_i915_private
*dev_priv,
{
int ret;
+ if (DISPLAY_VER(dev_priv) >= 14)
+ return 0;
+
/* bspec says to keep retrying for at least 1 ms */
ret = skl_pcode_request(_priv->uncore,
ICL_PCODE_SAGV_DE_MEM_SS_CONFIG,
points_mask,
--
2.34.1
[Intel-gfx] [PATCH dii-client 1/9] drm/i915/mtl: Fix bcs default context
From: Lucas De Marchi
Commit 0d0e7d1eea9e ("drm/i915/mtl: Define engine context layouts")
added the engine context for Meteor Lake. In a second revision of the
patch it was believed the xcs offsets were wrong due to a tagging
issue in the spec. The first version was actually correct, as shown
by the intel_lrc_live_selftests/live_lrc_layout test:
i915: Running gt_lrc
i915: Running intel_lrc_live_selftests/live_lrc_layout
bcs0: LRI command mismatch at dword 1, expected 1108101d found 11081019
[drm:drm_helper_probe_single_connector_modes [drm_kms_helper]]
[CONNECTOR:236:DP-1] disconnected
bcs0: HW register image:
[] 1108101d 00022244 0008 00022034 0088 00022030
0088
...
bcs0: SW register image:
[] 11081019 00022244 00090009 00022034 00022030
The difference in the 2 additional dwords (0x1d vs 0x19) are the offsets
0x120 / 0x124 that are indeed part of the context image.
Bspec: 45585
Fixes: 0d0e7d1eea9e ("drm/i915/mtl: Define engine context layouts")
Signed-off-by: Lucas De Marchi
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 37 +
1 file changed, 1 insertion(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 7771a19008c6..bbeeb6dde7ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -288,39 +288,6 @@ static const u8 dg2_xcs_offsets[] = {
END
};
-static const u8 mtl_xcs_offsets[] = {
- NOP(1),
- LRI(13, POSTED),
- REG16(0x244),
- REG(0x034),
- REG(0x030),
- REG(0x038),
- REG(0x03c),
- REG(0x168),
- REG(0x140),
- REG(0x110),
- REG(0x1c0),
- REG(0x1c4),
- REG(0x1c8),
- REG(0x180),
- REG16(0x2b4),
- NOP(4),
-
- NOP(1),
- LRI(9, POSTED),
- REG16(0x3a8),
- REG16(0x28c),
- REG16(0x288),
- REG16(0x284),
- REG16(0x280),
- REG16(0x27c),
- REG16(0x278),
- REG16(0x274),
- REG16(0x270),
-
- END
-};
-
static const u8 gen8_rcs_offsets[] = {
NOP(1),
LRI(14, POSTED),
@@ -739,9 +706,7 @@ static const u8 *reg_offsets(const struct intel_engine_cs
*engine)
else
return gen8_rcs_offsets;
} else {
- if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 70))
- return mtl_xcs_offsets;
- else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
+ if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
return dg2_xcs_offsets;
else if (GRAPHICS_VER(engine->i915) >= 12)
return gen12_xcs_offsets;
--
2.34.1
[Intel-gfx] [PATCH dii-client 4/9] drm/i915/mtl: make IRQ reset and postinstall multi-gt aware
From: Paulo Zanoni
Meteorlake has separate Media and render gt, it is necessary
to process the interrupts for the gt separately. As part of it
make sure IRQ reset and postinstall also work on Media gt.
Signed-off-by: Paulo Zanoni
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/i915_irq.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 54ea28cf8a1a..26d176ec4a66 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3170,14 +3170,19 @@ static void dg1_irq_reset(struct drm_i915_private
*dev_priv)
{
struct intel_gt *gt = to_gt(dev_priv);
struct intel_uncore *uncore = gt->uncore;
+ unsigned int i;
dg1_master_intr_disable(dev_priv->uncore.regs);
- gen11_gt_irq_reset(gt);
- gen11_display_irq_reset(dev_priv);
+ for_each_gt(gt, dev_priv, i) {
+ gen11_gt_irq_reset(gt);
- GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
- GEN3_IRQ_RESET(uncore, GEN8_PCU_);
+ uncore = gt->uncore;
+ GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
+ GEN3_IRQ_RESET(uncore, GEN8_PCU_);
+ }
+
+ gen11_display_irq_reset(dev_priv);
}
void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
@@ -3837,13 +3842,16 @@ static void gen11_irq_postinstall(struct
drm_i915_private *dev_priv)
static void dg1_irq_postinstall(struct drm_i915_private *dev_priv)
{
- struct intel_gt *gt = to_gt(dev_priv);
- struct intel_uncore *uncore = gt->uncore;
u32 gu_misc_masked = GEN11_GU_MISC_GSE;
+ struct intel_gt *gt;
+ unsigned int i;
- gen11_gt_irq_postinstall(gt);
+ for_each_gt(gt, dev_priv, i) {
+ gen11_gt_irq_postinstall(gt);
- GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
+ GEN3_IRQ_INIT(gt->uncore, GEN11_GU_MISC_, ~gu_misc_masked,
+ gu_misc_masked);
+ }
if (HAS_DISPLAY(dev_priv)) {
icp_irq_postinstall(dev_priv);
@@ -3852,8 +3860,8 @@ static void dg1_irq_postinstall(struct drm_i915_private
*dev_priv)
GEN11_DISPLAY_IRQ_ENABLE);
}
- dg1_master_intr_enable(uncore->regs);
- intel_uncore_posting_read(uncore, DG1_MSTR_TILE_INTR);
+ dg1_master_intr_enable(to_gt(dev_priv)->uncore->regs);
+ intel_uncore_posting_read(to_gt(dev_priv)->uncore, DG1_MSTR_TILE_INTR);
}
static void cherryview_irq_postinstall(struct drm_i915_private *dev_priv)
--
2.34.1
[Intel-gfx] [PATCH dii-client 6/9] drm/i915/debugfs: Multiplex upper layer interfaces to act on all gt's
From: Andi Shyti
Commit 82a149a62b6b5 ('drm/i915/gt: move remaining debugfs
interfaces into gt') moves gt related debugfs files in the gtX/
directories to act on specific gt's individually.
The original files are kept intact in the same location in order
to not break userspace users. But they were performing only on
the root tile (tile 0).
Add a multiplexing functionality to the higher directories files
so that they can perform the operations on all the tiles in a
with a single write.
In the read case they provide an or'ed value amongst the tiles.
Cc: Maciej Patelczyk
Signed-off-by: Andi Shyti
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/i915_debugfs.c | 38 ++---
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a356ca490159..d64e9e3a439d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -575,14 +575,36 @@ static int i915_wa_registers(struct seq_file *m, void
*unused)
static int i915_wedged_get(void *data, u64 *val)
{
struct drm_i915_private *i915 = data;
+ struct intel_gt *gt;
+ unsigned int i;
- return intel_gt_debugfs_reset_show(to_gt(i915), val);
+ *val = 0;
+
+ for_each_gt(gt, i915, i) {
+ int ret;
+ u64 v;
+
+ ret = intel_gt_debugfs_reset_show(gt, );
+ if (ret)
+ return ret;
+
+ /* at least one tile should be wedged */
+ *val |= !!v;
+ if (*val)
+ break;
+ }
+
+ return 0;
}
static int i915_wedged_set(void *data, u64 val)
{
struct drm_i915_private *i915 = data;
- intel_gt_debugfs_reset_store(to_gt(i915), val);
+ struct intel_gt *gt;
+ unsigned int i;
+
+ for_each_gt(gt, i915, i)
+ intel_gt_debugfs_reset_store(gt, val);
return 0;
}
@@ -732,7 +754,11 @@ static int i915_sseu_status(struct seq_file *m, void
*unused)
static int i915_forcewake_open(struct inode *inode, struct file *file)
{
struct drm_i915_private *i915 = inode->i_private;
- intel_gt_pm_debugfs_forcewake_user_open(to_gt(i915));
+ struct intel_gt *gt;
+ unsigned int i;
+
+ for_each_gt(gt, i915, i)
+ intel_gt_pm_debugfs_forcewake_user_open(gt);
return 0;
}
@@ -740,7 +766,11 @@ static int i915_forcewake_open(struct inode *inode, struct
file *file)
static int i915_forcewake_release(struct inode *inode, struct file *file)
{
struct drm_i915_private *i915 = inode->i_private;
- intel_gt_pm_debugfs_forcewake_user_release(to_gt(i915));
+ struct intel_gt *gt;
+ unsigned int i;
+
+ for_each_gt(gt, i915, i)
+ intel_gt_pm_debugfs_forcewake_user_release(gt);
return 0;
}
--
2.34.1
[Intel-gfx] [PATCH dii-client 9/9] drm/i915/display/mtl: Program latch to phy reset
From: José Roberto de Souza
Latch reset of phys during DC9 and when driver is unloaded to avoid
phy reset.
Specification ask us to program it closer to the step that enables
DC9 in DC_STATE_EN but doing this way allow us to sanitize the phy
latch during driver load.
BSpec: 49197
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_display_power.c | 8
drivers/gpu/drm/i915/i915_reg.h| 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 1a23ecd4623a..9b6dfd5f1259 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1646,6 +1646,10 @@ static void icl_display_core_init(struct
drm_i915_private *dev_priv,
intel_power_well_enable(dev_priv, well);
mutex_unlock(_domains->lock);
+ if (DISPLAY_VER(dev_priv) == 14)
+ intel_de_rmw(dev_priv, DC_STATE_EN,
+HOLD_PHY_PG1_LATCH | HOLD_PHY_CLKREQ_PG1_LATCH, 0);
+
/* 4. Enable CDCLK. */
intel_cdclk_init_hw(dev_priv);
@@ -1700,6 +1704,10 @@ static void icl_display_core_uninit(struct
drm_i915_private *dev_priv)
/* 3. Disable CD clock */
intel_cdclk_uninit_hw(dev_priv);
+ if (DISPLAY_VER(dev_priv) == 14)
+ intel_de_rmw(dev_priv, DC_STATE_EN, 0,
+HOLD_PHY_PG1_LATCH | HOLD_PHY_CLKREQ_PG1_LATCH);
+
/*
* 4. Disable Power Well 1 (PG1).
*The AUX IO power wells are toggled on demand, so they are already
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d43f0f8e061c..d84d05cc49de 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7383,6 +7383,8 @@ enum skl_power_gate {
#define DC_STATE_DISABLE 0
#define DC_STATE_EN_DC3CO REG_BIT(30)
#define DC_STATE_DC3CO_STATUS REG_BIT(29)
+#define HOLD_PHY_CLKREQ_PG1_LATCH REG_BIT(21)
+#define HOLD_PHY_PG1_LATCHREG_BIT(20)
#define DC_STATE_EN_UPTO_DC5 (1 << 0)
#define DC_STATE_EN_DC9 (1 << 3)
#define DC_STATE_EN_UPTO_DC6 (2 << 0)
--
2.34.1
[Intel-gfx] [PATCH dii-client 5/9] drm/i915/gt: generate per gt debugfs files
From: Andi Shyti
In the view of multi-gt we want independent per gt debug files.
In debugfs create gt0/ gt1/ ... gtN/ for gt related files. In
platforms with 2 gt's, the debugfs would be structured as follows:
/sys/kernel/debug/dri
└── 0
├── gt0
│ ├── drpc
│ ├── engines
│ ├── forcewake
│ ├── frequency
│ └── rps_boost
└─- gt1
: ├── drpc
: ├── engines
: ├── forcewake
├── frequency
└── rps_boost
Cc: Tvrtko Ursulin
Signed-off-by: Andi Shyti
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 4 +++-
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 5 -
drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 2 ++
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
index 5fc2df01aa0d..4dc23b8d3aa2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
@@ -83,11 +83,13 @@ static void gt_debugfs_register(struct intel_gt *gt, struct
dentry *root)
void intel_gt_debugfs_register(struct intel_gt *gt)
{
struct dentry *root;
+ char gtname[4];
if (!gt->i915->drm.primary->debugfs_root)
return;
- root = debugfs_create_dir("gt", gt->i915->drm.primary->debugfs_root);
+ snprintf(gtname, sizeof(gtname), "gt%u", gt->info.id);
+ root = debugfs_create_dir(gtname, gt->i915->drm.primary->debugfs_root);
if (IS_ERR(root))
return;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index bb4dfe707a7d..e46aac1a41e6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -42,6 +42,8 @@ struct intel_guc {
/** @capture: the error-state-capture module's data and objects */
struct intel_guc_state_capture *capture;
+ struct dentry *dbgfs_node;
+
/** @sched_engine: Global engine used to submit requests to GuC */
struct i915_sched_engine *sched_engine;
/**
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 68331c538b0a..71b1f23b64c1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -542,8 +542,11 @@ static int guc_log_relay_create(struct intel_guc_log *log)
*/
n_subbufs = 8;
+ if (!guc->dbgfs_node)
+ return -ENOENT;
+
guc_log_relay_chan = relay_open("guc_log",
- dev_priv->drm.primary->debugfs_root,
+ guc->dbgfs_node,
subbuf_size, n_subbufs,
_callbacks, dev_priv);
if (!guc_log_relay_chan) {
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
index 284d6fbc2d08..2f93cc4e408a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
@@ -54,6 +54,8 @@ void intel_uc_debugfs_register(struct intel_uc *uc, struct
dentry *gt_root)
if (IS_ERR(root))
return;
+ uc->guc.dbgfs_node = root;
+
intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), uc);
intel_guc_debugfs_register(>guc, root);
--
2.34.1
[Intel-gfx] [PATCH dii-client 7/9] drm/i915/fbdev: lock the fbdev obj before vma pin
From: Tejas Upadhyay
lock the fbdev obj before calling into
i915_vma_pin_iomap(). This helps to solve below :
<7>[ 93.563308] i915 :00:02.0: [drm:intelfb_create [i915]] no BIOS fb,
allocating a new one
<4>[ 93.581844] [ cut here ]
<4>[ 93.581855] WARNING: CPU: 12 PID: 625 at
drivers/gpu/drm/i915/gem/i915_gem_pages.c:424
i915_gem_object_pin_map+0x152/0x1c0 [i915]
v2 :
- Remove err variable - Chris
- Pass false as its not interruptible - Chris
Bug-id: VLK-38439
Fixes: b473df22760f9 ("backport "drm/i915: Add ww context to intel_dpt_pin,
v2.")
Cc: Chris Wilson
Cc: Matthew Auld
Signed-off-by: Tejas Upadhyay
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 24 --
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 03ed4607a46d..40808d57f0d0 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -210,6 +210,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
bool prealloc = false;
void __iomem *vaddr;
struct drm_i915_gem_object *obj;
+ struct i915_gem_ww_ctx ww;
int ret;
mutex_lock(>hpd_lock);
@@ -290,13 +291,24 @@ static int intelfb_create(struct drm_fb_helper *helper,
info->fix.smem_len = vma->size;
}
- vaddr = i915_vma_pin_iomap(vma);
- if (IS_ERR(vaddr)) {
- drm_err(_priv->drm,
- "Failed to remap framebuffer into virtual memory
(%pe)\n", vaddr);
- ret = PTR_ERR(vaddr);
- goto out_unpin;
+ for_i915_gem_ww(, ret, false) {
+ ret = i915_gem_object_lock(vma->obj, );
+
+ if (ret)
+ continue;
+
+ vaddr = i915_vma_pin_iomap(vma);
+ if (IS_ERR(vaddr)) {
+ drm_err(_priv->drm,
+ "Failed to remap framebuffer into
virtual memory (%pe)\n", vaddr);
+ ret = PTR_ERR(vaddr);
+ continue;
+ }
}
+
+ if (ret)
+ goto out_unpin;
+
info->screen_base = vaddr;
info->screen_size = vma->size;
--
2.34.1
[Intel-gfx] [PATCH dii-client 0/9] Misc Meteorlake patches
This series adds patches needed for Meteorlake platform. Yjere are 4 GT related patches 1 to handle interrupts for both render and media gt, 2 patches to generate per gt debug files, and the fourth patch to fix the bcs default context. There are 5 display patches, 1 for the phy to hold its values during dc9 entry/exit, 1 fbdev related fix, 1 patch fixes an earlier workaround, 1 patch to init empty clock gating hooks and 1 patch to skip informing punit about bw changes through mail box. Signed-off-by: Radhakrishna Sripada Andi Shyti (2): drm/i915/gt: generate per gt debugfs files drm/i915/debugfs: Multiplex upper layer interfaces to act on all gt's José Roberto de Souza (1): drm/i915/display/mtl: Program latch to phy reset Lucas De Marchi (1): drm/i915/mtl: Fix bcs default context Paulo Zanoni (1): drm/i915/mtl: make IRQ reset and postinstall multi-gt aware Radhakrishna Sripada (3): drm/i915/mtl: Initialize empty clockgating hooks for MTL drm/i915/mtl: Fix Wa_14015855405 implementation drm/i915/mtl: Skip pcode qgv restrictions for MTL Tejas Upadhyay (1): drm/i915/fbdev: lock the fbdev obj before vma pin drivers/gpu/drm/i915/display/intel_bw.c | 3 ++ .../drm/i915/display/intel_display_power.c| 8 drivers/gpu/drm/i915/display/intel_dmc.c | 35 ++--- drivers/gpu/drm/i915/display/intel_fbdev.c| 24 +--- drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 4 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 37 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 + drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 5 ++- drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 2 + drivers/gpu/drm/i915/i915_debugfs.c | 38 +-- drivers/gpu/drm/i915/i915_irq.c | 28 +- drivers/gpu/drm/i915/i915_reg.h | 12 -- drivers/gpu/drm/i915/intel_pm.c | 4 +- 13 files changed, 135 insertions(+), 67 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH dii-client 3/9] drm/i915/mtl: Fix Wa_14015855405 implementation
The patch "2357f2b271ad drm/i915/mtl: Initial display workarounds"
extended the workaround Wa_16015201720 to MTL. However the registers
that the original WA implamented moved for MTL.
Implement the workaround with the correct register.
Fixes: 2357f2b271ad ("drm/i915/mtl: Initial display workarounds")
Cc: Matt Atwood
Cc: Lucas De Marchi
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_dmc.c | 35
drivers/gpu/drm/i915/i915_reg.h | 10 +--
2 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 4124b3d37110..216915256eb6 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -372,15 +372,12 @@ static void disable_all_event_handlers(struct
drm_i915_private *i915)
}
}
-static void pipedmc_clock_gating_wa(struct drm_i915_private *i915, bool enable)
+static void adlp_pipedmc_clock_gating_wa(struct drm_i915_private *i915, bool
enable)
{
enum pipe pipe;
- if (DISPLAY_VER(i915) < 13)
- return;
-
/*
-* Wa_16015201720:adl-p,dg2, mtl
+* Wa_16015201720:adl-p,dg2
* The WA requires clock gating to be disabled all the time
* for pipe A and B.
* For pipe C and D clock gating needs to be disabled only
@@ -396,6 +393,34 @@ static void pipedmc_clock_gating_wa(struct
drm_i915_private *i915, bool enable)
PIPEDMC_GATING_DIS, 0);
}
+static void mtl_pipedmc_clock_gating_wa(struct drm_i915_private *i915, bool
enable)
+{
+ /*
+* Wa_14015855405
+* The WA requires clock gating to be disabled all the time
+* for pipe A and B.
+* For pipe C and D clock gating needs to be disabled only
+* during initializing the firmware.
+* TODO/FIXME: WA deviates wrt. enable/disable for Pipes C, D. Needs
recheck.
+* For now carry-forward the implementation for dg2.
+*/
+ if (enable)
+ intel_de_rmw(i915, GEN9_CLKGATE_DIS_0, 0,
+MTL_PIPEDMC_GATING_DIS_A |
MTL_PIPEDMC_GATING_DIS_B |
+MTL_PIPEDMC_GATING_DIS_C |
MTL_PIPEDMC_GATING_DIS_D);
+ else
+ intel_de_rmw(i915, GEN9_CLKGATE_DIS_0,
+MTL_PIPEDMC_GATING_DIS_C |
MTL_PIPEDMC_GATING_DIS_D, 0);
+}
+
+static void pipedmc_clock_gating_wa(struct drm_i915_private *i915, bool enable)
+{
+ if (DISPLAY_VER(i915) >= 14)
+ return mtl_pipedmc_clock_gating_wa(i915, enable);
+ else if (DISPLAY_VER(i915) == 13)
+ return adlp_pipedmc_clock_gating_wa(i915, enable);
+}
+
/**
* intel_dmc_load_program() - write the firmware from memory to register.
* @dev_priv: i915 drm device.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8b2cf980f323..d43f0f8e061c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1786,9 +1786,13 @@
* GEN9 clock gating regs
*/
#define GEN9_CLKGATE_DIS_0 _MMIO(0x46530)
-#define DARBF_GATING_DIS (1 << 27)
-#define PWM2_GATING_DIS (1 << 14)
-#define PWM1_GATING_DIS (1 << 13)
+#define DARBF_GATING_DIS REG_BIT(27)
+#define MTL_PIPEDMC_GATING_DIS_A REG_BIT(15)
+#define MTL_PIPEDMC_GATING_DIS_B REG_BIT(14)
+#define PWM2_GATING_DIS REG_BIT(14)
+#define MTL_PIPEDMC_GATING_DIS_C REG_BIT(13)
+#define PWM1_GATING_DIS REG_BIT(13)
+#define MTL_PIPEDMC_GATING_DIS_D REG_BIT(12)
#define GEN9_CLKGATE_DIS_3 _MMIO(0x46538)
#define TGL_VRH_GATING_DIS REG_BIT(31)
--
2.34.1
[Intel-gfx] [PATCH dii-client 2/9] drm/i915/mtl: Initialize empty clockgating hooks for MTL
Clock gating hooks to be initialized for MTL are yet to be implemented.
Use a nop till we identify relevant WA's here.
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_pm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 73c88b1c9545..41046ceca9db 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4819,7 +4819,9 @@ CG_FUNCS(nop);
*/
void intel_init_clock_gating_hooks(struct drm_i915_private *dev_priv)
{
- if (IS_PONTEVECCHIO(dev_priv))
+ if (IS_METEORLAKE(dev_priv))
+ dev_priv->clock_gating_funcs = _clock_gating_funcs;
+ else if (IS_PONTEVECCHIO(dev_priv))
dev_priv->clock_gating_funcs = _clock_gating_funcs;
else if (IS_DG2(dev_priv))
dev_priv->clock_gating_funcs = _clock_gating_funcs;
--
2.34.1
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Avoid full proxy f_ops debug attributes (rev2)
== Series Details ==
Series: drm/i915: Avoid full proxy f_ops debug attributes (rev2)
URL : https://patchwork.freedesktop.org/series/112625/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12573_full -> Patchwork_112625v2_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/index.html
Participating hosts (12 -> 10)
--
Additional (1): shard-rkl0
Missing(3): pig-skl-6260u pig-kbl-iris pig-glk-j5005
Known issues
Here are the changes found in Patchwork_112625v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12573/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: NOTRUN -> [FAIL][3] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/shard-glk4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_lmem_swapping@heavy-verify-random-ccs:
- shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +2
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/shard-glk6/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html
* igt@gem_pread@exhaustion:
- shard-glk: NOTRUN -> [WARN][5] ([i915#2658])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/shard-glk4/igt@gem_pr...@exhaustion.html
* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#658])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/shard-glk6/igt@i915_pm...@dc3co-vpb-simulation.html
* igt@i915_selftest@live@gt_heartbeat:
- shard-glk: NOTRUN -> [DMESG-FAIL][7] ([i915#5334])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/shard-glk4/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886]) +4
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/shard-glk6/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium_color@ctm-blue-to-red:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271]) +56 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/shard-glk4/igt@kms_chamelium_co...@ctm-blue-to-red.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][10] ([i915#7742]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12573/shard-rkl-1/igt@drm_fdinfo@i...@rcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/shard-rkl-5/igt@drm_fdinfo@i...@rcs0.html
* igt@drm_read@fault-buffer:
- {shard-rkl}:[SKIP][12] ([i915#4098]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12573/shard-rkl-3/igt@drm_r...@fault-buffer.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/shard-rkl-6/igt@drm_r...@fault-buffer.html
* igt@feature_discovery@psr2:
- {shard-rkl}:[SKIP][14] ([i915#658]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12573/shard-rkl-3/igt@feature_discov...@psr2.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/shard-rkl-6/igt@feature_discov...@psr2.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][16] ([i915#6268]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12573/shard-rkl-3/igt@gem_ctx_e...@basic-nohangcheck.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/shard-rkl-5/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_exec_create@forked@smem:
- shard-glk: [DMESG-WARN][18] ([i915#118]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12573/shard-glk1/igt@gem_exec_create@for...@smem.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/shard-glk2/igt@gem_exec_create@for...@smem.html
* igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][20] ([i915#2842]) -> [PASS][21] +2 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12573/shard-rkl-1/igt@gem_exec_fair@basic-p...@rcs0.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/shard-rkl-5/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-glk: [FAIL][22] ([i915#2842]) -> [PASS][23]
[22]:
Re: [Intel-gfx] [RFC PATCH 00/17] DRM_USE_DYNAMIC_DEBUG regression
On Mon, Dec 05, 2022 at 05:34:07PM -0700, Jim Cromie wrote: > Hi everyone, > > DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-* > > Regression is due to a chicken-egg problem loading modules; on > `modprobe i915`, drm is loaded 1st, and drm.debug is set. When > drm_debug_enabled() tested __drm_debug at runtime, that just worked. > > But with DRM_USE_DYNAMIC_DEBUG=y, the runtime test is replaced with a > post-load enablement of drm_dbg/dyndbg callsites (static-keys), via > dyndbg's callback on __drm_debug. Since all drm-drivers need drm.ko, > it is loaded 1st, then drm.debug=X is applied, then drivers load, but > too late for drm_dbgs to be enabled. > > STATUS > > For all-loadable drm,i915,amdgpu configs, it almost works, but > propagating drm.debug to dependent modules doesnt actually apply, > though the motions are there. This is not the problem I want to chase > here. > > The more basic trouble is: > > For builtin drm + helpers, things are broken pretty early; at the > beginning of dynamic_debug_init(). As the ddebug_sanity() commit-msg > describes in some detail, the records added by _USE fail to reference > the struct ddebug_class_map created and exported by _DEFINE, but get > separate addresses to "other" data that segv's when used as the > expected pointer. FWIW, the pointer val starts with "revi". So I honestly have no idea here, linker stuff is way beyond where I have clue. So what's the way forward here? The DEFINE/USE split does like the right thing to do at least from the "how it's used in drivers" pov. But if we're just running circles not quite getting there I dunno :-/ -Daniel > > OVERVIEW > > DECLARE_DYNDBG_CLASSMAP is broken: it is one-size-fits-all-poorly. > It muddles the distinction between a (single) definition, and multiple > references. Something exported should suffice. > > The core of this patchset splits it into: > > DYNDBG_CLASSMAP_DEFINEused once per subsystem to define each classmap > DYNDBG_CLASSMAP_USE declare dependence on a DEFINEd classmap > > This makes the weird coordinated-changes-by-identical-classmaps > "feature" unnecessary; the DEFINE can export the var, and USE refers > to the exported var. > > So this patchset adds another section: __dyndbg_class_refs. > > It is like __dyndbg_classes; it is scanned under ddebug_add_module(), > and attached to each module's ddebug_table. Once attached, it can be > used like classes to validate and apply class FOO >control queries. > > It also maps the class user -> definer explicitly, so that when the > module is loaded, the section scan can find the kernel-param that is > wired to dyndbg's kparam-callback, and apply its state-var, forex: > __drm_debug to the just loaded helper/driver module. > > Theres plenty to address Im sure. > > Jim Cromie (17): > test-dyndbg: fixup CLASSMAP usage error > test-dyndbg: show that DEBUG enables prdbgs at compiletime > dyndbg: fix readback value on LEVEL_NAMES interfaces > dyndbg: replace classmap list with a vector > dyndbg: make ddebug_apply_class_bitmap more selective > dyndbg: dynamic_debug_init - use pointer inequality, not strcmp > dyndbg: drop NUM_TYPE_ARRAY > dyndbg: reduce verbose/debug clutter > dyndbg-API: replace DECLARE_DYNDBG_CLASSMAP with > DYNDBG_CLASSMAP(_DEFINE|_USE) > dyndbg-API: specialize DYNDBG_CLASSMAP_(DEFINE|USE) > dyndbg-API: DYNDBG_CLASSMAP_USE drop extra args > dyndbg-API: DYNDBG_CLASSMAP_DEFINE() improvements > drm_print: fix stale macro-name in comment > dyndbg: unwrap __ddebug_add_module inner function NOTYET > dyndbg: ddebug_sanity() > dyndbg: mess-w-dep-class > dyndbg: miss-on HACK > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 14 +- > drivers/gpu/drm/display/drm_dp_helper.c | 14 +- > drivers/gpu/drm/drm_crtc_helper.c | 14 +- > drivers/gpu/drm/drm_print.c | 22 +-- > drivers/gpu/drm/i915/i915_params.c | 14 +- > drivers/gpu/drm/nouveau/nouveau_drm.c | 14 +- > include/asm-generic/vmlinux.lds.h | 3 + > include/drm/drm_print.h | 6 +- > include/linux/dynamic_debug.h | 57 -- > include/linux/map.h | 54 ++ > kernel/module/main.c| 2 + > lib/dynamic_debug.c | 240 +++- > lib/test_dynamic_debug.c| 47 ++--- > 13 files changed, 344 insertions(+), 157 deletions(-) > create mode 100644 include/linux/map.h > > -- > 2.38.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] [RFC PATCH 13/17] drm_print: fix stale macro-name in comment
On Mon, Dec 05, 2022 at 05:34:20PM -0700, Jim Cromie wrote:
> Cited commit uses stale macro name, fix this, and explain better.
>
> When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
> onto BITs in drm.debug. This still uses enum drm_debug_category, but
> it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
> This requires that the macro args: DRM_UT_* list must be kept in sync
> and in order.
>
> Fixes: f158936b60a7 ("drm: POC drm on dyndbg - use in core, 2 helpers, 3
> drivers.")
> Signed-off-by: Jim Cromie
Should I land this already?
-Daniel
> ---
> . emphasize ABI non-change despite enum val change - Jani Nikula
> . reorder to back of patchset to follow API name changes.
> ---
> include/drm/drm_print.h | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 6a27e8f26770..7695ba31b3a4 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -276,7 +276,10 @@ static inline struct drm_printer drm_err_printer(const
> char *prefix)
> *
> */
> enum drm_debug_category {
> - /* These names must match those in DYNAMIC_DEBUG_CLASSBITS */
> + /*
> + * Keep DYNDBG_CLASSMAP_DEFINE args in sync with changes here,
> + * the enum-values define BIT()s in drm.debug, so are ABI.
> + */
> /**
>* @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
>* drm_memory.c, ...
> --
> 2.38.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Wed, Jan 11, 2023 at 4:32 PM Matthew Brost
wrote:
> On Wed, Jan 11, 2023 at 04:18:01PM -0600, Jason Ekstrand wrote:
> > On Wed, Jan 11, 2023 at 2:50 AM Tvrtko Ursulin <
> > tvrtko.ursu...@linux.intel.com> wrote:
> >
> > >
> > > On 10/01/2023 14:08, Jason Ekstrand wrote:
> > > > On Tue, Jan 10, 2023 at 5:28 AM Tvrtko Ursulin
> > > > tvrtko.ursu...@linux.intel.com>>
> > >
> > > > wrote:
> > > >
> > > >
> > > >
> > > > On 09/01/2023 17:27, Jason Ekstrand wrote:
> > > >
> > > > [snip]
> > > >
> > > > > >>> AFAICT it proposes to have 1:1 between *userspace*
> > > created
> > > > > contexts (per
> > > > > >>> context _and_ engine) and drm_sched. I am not sure
> > > avoiding
> > > > > invasive changes
> > > > > >>> to the shared code is in the spirit of the overall
> idea
> > > > and instead
> > > > > >>> opportunity should be used to look at way to
> > > > refactor/improve
> > > > > drm_sched.
> > > > >
> > > > >
> > > > > Maybe? I'm not convinced that what Xe is doing is an abuse at
> > > > all or
> > > > > really needs to drive a re-factor. (More on that later.)
> > > > There's only
> > > > > one real issue which is that it fires off potentially a lot of
> > > > kthreads.
> > > > > Even that's not that bad given that kthreads are pretty light
> and
> > > > you're
> > > > > not likely to have more kthreads than userspace threads which
> are
> > > > much
> > > > > heavier. Not ideal, but not the end of the world either.
> > > > Definitely
> > > > > something we can/should optimize but if we went through with
> Xe
> > > > without
> > > > > this patch, it would probably be mostly ok.
> > > > >
> > > > > >> Yes, it is 1:1 *userspace* engines and drm_sched.
> > > > > >>
> > > > > >> I'm not really prepared to make large changes to DRM
> > > > scheduler
> > > > > at the
> > > > > >> moment for Xe as they are not really required nor does
> > > Boris
> > > > > seem they
> > > > > >> will be required for his work either. I am interested
> to
> > > see
> > > > > what Boris
> > > > > >> comes up with.
> > > > > >>
> > > > > >>> Even on the low level, the idea to replace drm_sched
> > > threads
> > > > > with workers
> > > > > >>> has a few problems.
> > > > > >>>
> > > > > >>> To start with, the pattern of:
> > > > > >>>
> > > > > >>>while (not_stopped) {
> > > > > >>> keep picking jobs
> > > > > >>>}
> > > > > >>>
> > > > > >>> Feels fundamentally in disagreement with workers
> (while
> > > > > obviously fits
> > > > > >>> perfectly with the current kthread design).
> > > > > >>
> > > > > >> The while loop breaks and worker exists if no jobs are
> > > ready.
> > > > >
> > > > >
> > > > > I'm not very familiar with workqueues. What are you saying
> would
> > > fit
> > > > > better? One scheduling job per work item rather than one big
> work
> > > > item
> > > > > which handles all available jobs?
> > > >
> > > > Yes and no, it indeed IMO does not fit to have a work item which
> is
> > > > potentially unbound in runtime. But it is a bit moot conceptual
> > > > mismatch
> > > > because it is a worst case / theoretical, and I think due more
> > > > fundamental concerns.
> > > >
> > > > If we have to go back to the low level side of things, I've
> picked
> > > this
> > > > random spot to consolidate what I have already mentioned and
> perhaps
> > > > expand.
> > > >
> > > > To start with, let me pull out some thoughts from workqueue.rst:
> > > >
> > > > """
> > > > Generally, work items are not expected to hog a CPU and consume
> many
> > > > cycles. That means maintaining just enough concurrency to prevent
> > > work
> > > > processing from stalling should be optimal.
> > > > """
> > > >
> > > > For unbound queues:
> > > > """
> > > > The responsibility of regulating concurrency level is on the
> users.
> > > > """
> > > >
> > > > Given the unbound queues will be spawned on demand to service all
> > > > queued
> > > > work items (more interesting when mixing up with the
> > > > system_unbound_wq),
> > > > in the proposed design the number of instantiated worker threads
> does
> > > > not correspond to the number of user threads (as you have
> elsewhere
> > > > stated), but pessimistically to the number of active user
> contexts.
> > > >
> > > >
> > > > Those are pretty much the same in practice. Rather, user threads is
> > > > typically an upper bound on the number of contexts. Yes, a single
> user
> > > > thread could have a bunch of contexts but basically nothing
Re: [Intel-gfx] [PATCH 5/5] drm/plane: Unexport drm_any_plane_has_format()
On Mon, Jan 09, 2023 at 07:58:08AM -0300, Maíra Canal wrote: > As the format validation is being dealt with exclusively > inside framebuffer_check(), there is no need to export the > drm_any_plane_has_format() symbol. > > Therefore, unexport the drm_any_plane_has_format() symbol, reinforcing > that format validation is being dealt with by the DRM API. > > Signed-off-by: Maíra Canal Usually we also delete the kerneldoc at that point, since that's mainly for driver authors and they don't need this anymore. With that Also please move the function decl to the drm_crtc_internal.h since this is no longer used outside of drm core/helper code. Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/drm_plane.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > index 24e7998d1731..67c0ab60c7b6 100644 > --- a/drivers/gpu/drm/drm_plane.c > +++ b/drivers/gpu/drm/drm_plane.c > @@ -837,7 +837,6 @@ bool drm_any_plane_has_format(struct drm_device *dev, > > return false; > } > -EXPORT_SYMBOL(drm_any_plane_has_format); > > /* > * __setplane_internal - setplane handler for internal callers > -- > 2.39.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 1/5] drm/framebuffer: Check for valid formats
On Mon, Jan 09, 2023 at 07:58:04AM -0300, Maíra Canal wrote:
> Currently, framebuffer_check() doesn't check if the pixel format is
> supported, which can lead to the acceptance of invalid pixel formats
> e.g. the acceptance of invalid modifiers. Therefore, add a check for
> valid formats on framebuffer_check(), so that the ADDFB2 IOCTL rejects
> calls with invalid formats.
>
> Moreover, note that this check is only valid for atomic drivers,
> because, for non-atomic drivers, checking drm_any_plane_has_format() is
> not possible since the format list for the primary plane is fake, and
> we'd therefore reject valid formats.
>
> Signed-off-by: Maíra Canal
Reviewed-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst| 9 -
> drivers/gpu/drm/drm_framebuffer.c | 8
> 2 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 1f8a5ebe188e..3a79c26c5cc7 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -276,11 +276,10 @@ Various hold-ups:
> - Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom
> fb
>setup code can't be deleted.
>
> -- Many drivers wrap drm_gem_fb_create() only to check for valid formats. For
> - atomic drivers we could check for valid formats by calling
> - drm_plane_check_pixel_format() against all planes, and pass if any plane
> - supports the format. For non-atomic that's not possible since like the
> format
> - list for the primary plane is fake and we'd therefor reject valid formats.
> +- Need to switch to drm_gem_fb_create(), as now framebuffer_check() checks
> for
> + valid formats for atomic drivers.
> +
> +- Add an addfb format validation for non-atomic drivers.
>
> - Many drivers subclass drm_framebuffer, we'd need a embedding compatible
>version of the varios drm_gem_fb_create functions. Maybe called
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index aff3746dedfb..605642bf3650 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -280,6 +280,14 @@ static int framebuffer_check(struct drm_device *dev,
> }
> }
>
> + /* Verify that the modifier is supported. */
> + if (drm_drv_uses_atomic_modeset(dev) &&
> + !drm_any_plane_has_format(dev, r->pixel_format, r->modifier[0])) {
> + drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier
> 0x%llx\n",
> + >pixel_format, r->modifier[0]);
> + return -EINVAL;
> + }
> +
> return 0;
> }
>
> --
> 2.39.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Wed, Jan 11, 2023 at 04:18:01PM -0600, Jason Ekstrand wrote:
> On Wed, Jan 11, 2023 at 2:50 AM Tvrtko Ursulin <
> tvrtko.ursu...@linux.intel.com> wrote:
>
> >
> > On 10/01/2023 14:08, Jason Ekstrand wrote:
> > > On Tue, Jan 10, 2023 at 5:28 AM Tvrtko Ursulin
> > > mailto:tvrtko.ursu...@linux.intel.com>>
> >
> > > wrote:
> > >
> > >
> > >
> > > On 09/01/2023 17:27, Jason Ekstrand wrote:
> > >
> > > [snip]
> > >
> > > > >>> AFAICT it proposes to have 1:1 between *userspace*
> > created
> > > > contexts (per
> > > > >>> context _and_ engine) and drm_sched. I am not sure
> > avoiding
> > > > invasive changes
> > > > >>> to the shared code is in the spirit of the overall idea
> > > and instead
> > > > >>> opportunity should be used to look at way to
> > > refactor/improve
> > > > drm_sched.
> > > >
> > > >
> > > > Maybe? I'm not convinced that what Xe is doing is an abuse at
> > > all or
> > > > really needs to drive a re-factor. (More on that later.)
> > > There's only
> > > > one real issue which is that it fires off potentially a lot of
> > > kthreads.
> > > > Even that's not that bad given that kthreads are pretty light and
> > > you're
> > > > not likely to have more kthreads than userspace threads which are
> > > much
> > > > heavier. Not ideal, but not the end of the world either.
> > > Definitely
> > > > something we can/should optimize but if we went through with Xe
> > > without
> > > > this patch, it would probably be mostly ok.
> > > >
> > > > >> Yes, it is 1:1 *userspace* engines and drm_sched.
> > > > >>
> > > > >> I'm not really prepared to make large changes to DRM
> > > scheduler
> > > > at the
> > > > >> moment for Xe as they are not really required nor does
> > Boris
> > > > seem they
> > > > >> will be required for his work either. I am interested to
> > see
> > > > what Boris
> > > > >> comes up with.
> > > > >>
> > > > >>> Even on the low level, the idea to replace drm_sched
> > threads
> > > > with workers
> > > > >>> has a few problems.
> > > > >>>
> > > > >>> To start with, the pattern of:
> > > > >>>
> > > > >>>while (not_stopped) {
> > > > >>> keep picking jobs
> > > > >>>}
> > > > >>>
> > > > >>> Feels fundamentally in disagreement with workers (while
> > > > obviously fits
> > > > >>> perfectly with the current kthread design).
> > > > >>
> > > > >> The while loop breaks and worker exists if no jobs are
> > ready.
> > > >
> > > >
> > > > I'm not very familiar with workqueues. What are you saying would
> > fit
> > > > better? One scheduling job per work item rather than one big work
> > > item
> > > > which handles all available jobs?
> > >
> > > Yes and no, it indeed IMO does not fit to have a work item which is
> > > potentially unbound in runtime. But it is a bit moot conceptual
> > > mismatch
> > > because it is a worst case / theoretical, and I think due more
> > > fundamental concerns.
> > >
> > > If we have to go back to the low level side of things, I've picked
> > this
> > > random spot to consolidate what I have already mentioned and perhaps
> > > expand.
> > >
> > > To start with, let me pull out some thoughts from workqueue.rst:
> > >
> > > """
> > > Generally, work items are not expected to hog a CPU and consume many
> > > cycles. That means maintaining just enough concurrency to prevent
> > work
> > > processing from stalling should be optimal.
> > > """
> > >
> > > For unbound queues:
> > > """
> > > The responsibility of regulating concurrency level is on the users.
> > > """
> > >
> > > Given the unbound queues will be spawned on demand to service all
> > > queued
> > > work items (more interesting when mixing up with the
> > > system_unbound_wq),
> > > in the proposed design the number of instantiated worker threads does
> > > not correspond to the number of user threads (as you have elsewhere
> > > stated), but pessimistically to the number of active user contexts.
> > >
> > >
> > > Those are pretty much the same in practice. Rather, user threads is
> > > typically an upper bound on the number of contexts. Yes, a single user
> > > thread could have a bunch of contexts but basically nothing does that
> > > except IGT. In real-world usage, it's at most one context per user
> > thread.
> >
> > Typically is the key here. But I am not sure it is good enough. Consider
> > this example - Intel Flex 170:
> >
> > * Delivers up to 36 streams 1080p60 transcode throughput per card.
> > * When scaled to 10 cards in a
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/pxp: Add MTL PXP Support (rev2)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev2) URL : https://patchwork.freedesktop.org/series/112647/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12574 -> Patchwork_112647v2 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_112647v2 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_112647v2, 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_112647v2/index.html Participating hosts (35 -> 34) -- Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_112647v2: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - fi-skl-guc: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v2/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html Known issues Here are the changes found in Patchwork_112647v2 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_gttfill@basic: - fi-pnv-d510:[PASS][3] -> [FAIL][4] ([i915#7229]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/fi-pnv-d510/igt@gem_exec_gttf...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v2/fi-pnv-d510/igt@gem_exec_gttf...@basic.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#7828]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v2/fi-rkl-11600/igt@kms_chamelium_...@common-hpd-after-suspend.html Possible fixes * igt@i915_pm_rpm@module-reload: - bat-dg1-5: [SKIP][6] -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/bat-dg1-5/igt@i915_pm_...@module-reload.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v2/bat-dg1-5/igt@i915_pm_...@module-reload.html * igt@i915_suspend@basic-s3-without-i915: - fi-rkl-11600: [INCOMPLETE][8] ([i915#4817]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v2/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html [i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817 [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 Build changes - * Linux: CI_DRM_12574 -> Patchwork_112647v2 CI-20190529: 20190529 CI_DRM_12574: bf7f7c53ac622a3f6d6738d062e59dd21ce28bd7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7116: 79eb8984acd309108be713a8831e60667db67e21 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_112647v2: bf7f7c53ac622a3f6d6738d062e59dd21ce28bd7 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 966c9a8ccd4d drm/i915/pxp: Enable PXP with MTL-GSC-CS 612b0507176c drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component 66a12447df07 drm/i915/pxp: MTL-KCR interrupt ctrl's are in GT-0 7afc2deecd67 drm/i915/pxp: Add ARB session creation with new PXP API Ver4.3 8557f581adbe drm/i915/pxp: Add GSC-CS backend to send GSC fw messages 287e475fad72 drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC ba55dbbffae8 drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation 51b5f77c9e5e drm/i915/pxp: Add GSC-CS back-end resource init and cleanup 9670575abe0b drm/i915/pxp: Add MTL PXP GSC-CS back-end skeleton == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v2/index.html
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Wed, Jan 11, 2023 at 2:50 AM Tvrtko Ursulin <
tvrtko.ursu...@linux.intel.com> wrote:
>
> On 10/01/2023 14:08, Jason Ekstrand wrote:
> > On Tue, Jan 10, 2023 at 5:28 AM Tvrtko Ursulin
> > mailto:tvrtko.ursu...@linux.intel.com>>
>
> > wrote:
> >
> >
> >
> > On 09/01/2023 17:27, Jason Ekstrand wrote:
> >
> > [snip]
> >
> > > >>> AFAICT it proposes to have 1:1 between *userspace*
> created
> > > contexts (per
> > > >>> context _and_ engine) and drm_sched. I am not sure
> avoiding
> > > invasive changes
> > > >>> to the shared code is in the spirit of the overall idea
> > and instead
> > > >>> opportunity should be used to look at way to
> > refactor/improve
> > > drm_sched.
> > >
> > >
> > > Maybe? I'm not convinced that what Xe is doing is an abuse at
> > all or
> > > really needs to drive a re-factor. (More on that later.)
> > There's only
> > > one real issue which is that it fires off potentially a lot of
> > kthreads.
> > > Even that's not that bad given that kthreads are pretty light and
> > you're
> > > not likely to have more kthreads than userspace threads which are
> > much
> > > heavier. Not ideal, but not the end of the world either.
> > Definitely
> > > something we can/should optimize but if we went through with Xe
> > without
> > > this patch, it would probably be mostly ok.
> > >
> > > >> Yes, it is 1:1 *userspace* engines and drm_sched.
> > > >>
> > > >> I'm not really prepared to make large changes to DRM
> > scheduler
> > > at the
> > > >> moment for Xe as they are not really required nor does
> Boris
> > > seem they
> > > >> will be required for his work either. I am interested to
> see
> > > what Boris
> > > >> comes up with.
> > > >>
> > > >>> Even on the low level, the idea to replace drm_sched
> threads
> > > with workers
> > > >>> has a few problems.
> > > >>>
> > > >>> To start with, the pattern of:
> > > >>>
> > > >>>while (not_stopped) {
> > > >>> keep picking jobs
> > > >>>}
> > > >>>
> > > >>> Feels fundamentally in disagreement with workers (while
> > > obviously fits
> > > >>> perfectly with the current kthread design).
> > > >>
> > > >> The while loop breaks and worker exists if no jobs are
> ready.
> > >
> > >
> > > I'm not very familiar with workqueues. What are you saying would
> fit
> > > better? One scheduling job per work item rather than one big work
> > item
> > > which handles all available jobs?
> >
> > Yes and no, it indeed IMO does not fit to have a work item which is
> > potentially unbound in runtime. But it is a bit moot conceptual
> > mismatch
> > because it is a worst case / theoretical, and I think due more
> > fundamental concerns.
> >
> > If we have to go back to the low level side of things, I've picked
> this
> > random spot to consolidate what I have already mentioned and perhaps
> > expand.
> >
> > To start with, let me pull out some thoughts from workqueue.rst:
> >
> > """
> > Generally, work items are not expected to hog a CPU and consume many
> > cycles. That means maintaining just enough concurrency to prevent
> work
> > processing from stalling should be optimal.
> > """
> >
> > For unbound queues:
> > """
> > The responsibility of regulating concurrency level is on the users.
> > """
> >
> > Given the unbound queues will be spawned on demand to service all
> > queued
> > work items (more interesting when mixing up with the
> > system_unbound_wq),
> > in the proposed design the number of instantiated worker threads does
> > not correspond to the number of user threads (as you have elsewhere
> > stated), but pessimistically to the number of active user contexts.
> >
> >
> > Those are pretty much the same in practice. Rather, user threads is
> > typically an upper bound on the number of contexts. Yes, a single user
> > thread could have a bunch of contexts but basically nothing does that
> > except IGT. In real-world usage, it's at most one context per user
> thread.
>
> Typically is the key here. But I am not sure it is good enough. Consider
> this example - Intel Flex 170:
>
> * Delivers up to 36 streams 1080p60 transcode throughput per card.
> * When scaled to 10 cards in a 4U server configuration, it can support
> up to 360 streams of HEVC/HEVC 1080p60 transcode throughput.
>
I had a feeling it was going to be media
> One transcode stream from my experience typically is 3-4 GPU contexts
> (buffer travels from vcs -> rcs -> vcs, maybe vecs) used from a single
> CPU thread. 4
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pxp: Add MTL PXP Support (rev2)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev2) URL : https://patchwork.freedesktop.org/series/112647/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Tue, 10 Jan 2023 at 09:46, Boris Brezillon wrote: > > Hi Daniel, > > On Mon, 9 Jan 2023 21:40:21 +0100 > Daniel Vetter wrote: > > > On Mon, Jan 09, 2023 at 06:17:48PM +0100, Boris Brezillon wrote: > > > Hi Jason, > > > > > > On Mon, 9 Jan 2023 09:45:09 -0600 > > > Jason Ekstrand wrote: > > > > > > > On Thu, Jan 5, 2023 at 1:40 PM Matthew Brost > > > > wrote: > > > > > > > > > On Mon, Jan 02, 2023 at 08:30:19AM +0100, Boris Brezillon wrote: > > > > > > On Fri, 30 Dec 2022 12:55:08 +0100 > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > On Fri, 30 Dec 2022 11:20:42 +0100 > > > > > > > Boris Brezillon wrote: > > > > > > > > > > > > > > > Hello Matthew, > > > > > > > > > > > > > > > > On Thu, 22 Dec 2022 14:21:11 -0800 > > > > > > > > Matthew Brost wrote: > > > > > > > > > > > > > > > > > In XE, the new Intel GPU driver, a choice has made to have a > > > > > > > > > 1 to 1 > > > > > > > > > mapping between a drm_gpu_scheduler and drm_sched_entity. At > > > > > > > > > first > > > > > this > > > > > > > > > seems a bit odd but let us explain the reasoning below. > > > > > > > > > > > > > > > > > > 1. In XE the submission order from multiple drm_sched_entity > > > > > > > > > is not > > > > > > > > > guaranteed to be the same completion even if targeting the > > > > > > > > > same > > > > > hardware > > > > > > > > > engine. This is because in XE we have a firmware scheduler, > > > > > > > > > the > > > > > GuC, > > > > > > > > > which allowed to reorder, timeslice, and preempt submissions. > > > > > > > > > If a > > > > > using > > > > > > > > > shared drm_gpu_scheduler across multiple drm_sched_entity, > > > > > > > > > the TDR > > > > > falls > > > > > > > > > apart as the TDR expects submission order == completion order. > > > > > Using a > > > > > > > > > dedicated drm_gpu_scheduler per drm_sched_entity solve this > > > > > problem. > > > > > > > > > > > > > > > > Oh, that's interesting. I've been trying to solve the same sort > > > > > > > > of > > > > > > > > issues to support Arm's new Mali GPU which is relying on a > > > > > FW-assisted > > > > > > > > scheduling scheme (you give the FW N streams to execute, and it > > > > > > > > does > > > > > > > > the scheduling between those N command streams, the kernel > > > > > > > > driver > > > > > > > > does timeslice scheduling to update the command streams passed > > > > > > > > to the > > > > > > > > FW). I must admit I gave up on using drm_sched at some point, > > > > > > > > mostly > > > > > > > > because the integration with drm_sched was painful, but also > > > > > > > > because > > > > > I > > > > > > > > felt trying to bend drm_sched to make it interact with a > > > > > > > > timeslice-oriented scheduling model wasn't really future proof. > > > > > Giving > > > > > > > > drm_sched_entity exlusive access to a drm_gpu_scheduler probably > > > > > might > > > > > > > > help for a few things (didn't think it through yet), but I feel > > > > > > > > it's > > > > > > > > coming short on other aspects we have to deal with on Arm GPUs. > > > > > > > > > > > > > > Ok, so I just had a quick look at the Xe driver and how it > > > > > > > instantiates the drm_sched_entity and drm_gpu_scheduler, and I > > > > > > > think I > > > > > > > have a better understanding of how you get away with using > > > > > > > drm_sched > > > > > > > while still controlling how scheduling is really done. Here > > > > > > > drm_gpu_scheduler is just a dummy abstract that let's you use the > > > > > > > drm_sched job queuing/dep/tracking mechanism. The whole run-queue > > > > > > > > > > You nailed it here, we use the DRM scheduler for queuing jobs, > > > > > dependency tracking and releasing jobs to be scheduled when > > > > > dependencies > > > > > are met, and lastly a tracking mechanism of inflights jobs that need > > > > > to > > > > > be cleaned up if an error occurs. It doesn't actually do any > > > > > scheduling > > > > > aside from the most basic level of not overflowing the submission ring > > > > > buffer. In this sense, a 1 to 1 relationship between entity and > > > > > scheduler fits quite well. > > > > > > > > > > > > > Yeah, I think there's an annoying difference between what > > > > AMD/NVIDIA/Intel > > > > want here and what you need for Arm thanks to the number of FW queues > > > > available. I don't remember the exact number of GuC queues but it's at > > > > least 1k. This puts it in an entirely different class from what you > > > > have on > > > > Mali. Roughly, there's about three categories here: > > > > > > > > 1. Hardware where the kernel is placing jobs on actual HW rings. This > > > > is > > > > old Mali, Intel Haswell and earlier, and probably a bunch of others. > > > > (Intel BDW+ with execlists is a weird case that doesn't fit in this > > > > categorization.) > > > > > > > > 2. Hardware (or firmware) with a very limited number of queues where > > > > you're going to have to juggle in the kernel in order to
[Intel-gfx] [PATCH v2 9/9] drm/i915/pxp: Enable PXP with MTL-GSC-CS
Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the timeouts for new GSC-CS + firmware specs.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index bc1af7e8f398..0cac8cce1f7b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1148,6 +1148,7 @@ static const struct intel_device_info mtl_info = {
.has_guc_deprivilege = 1,
.has_mslice_steering = 0,
.has_snoop = 1,
+ .has_pxp = 1,
.__runtime.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
.require_force_probe = 1,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 7bb06e67b155..e4e60e3b9216 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -56,7 +56,7 @@ static int pxp_wait_for_session_state(struct intel_pxp *pxp,
u32 id, bool in_pla
reg,
mask,
in_play ? mask : 0,
- 100);
+ 250);
intel_runtime_pm_put(uncore->rpm, wakeref);
--
2.39.0
[Intel-gfx] [PATCH v2 4/9] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
Add helper functions into (new) common heci-packet-submission files
to handle generating the MTL GSC-CS Memory-Header and emitting of
the Heci-Cmd-Packet instructions that gets submitted to the engine.
NOTE1: This common functions for heci-packet-submission will be used by
different i915 callers:
1- GSC-SW-Proxy: This is pending upstream publication awaiting
a few remaining opens
2- MTL-HDCP: An equivalent patch has also been published at:
https://patchwork.freedesktop.org/series/111876/. (Patch 1)
3- PXP: This series.
NOTE2: A difference in this patch vs what is appearing is in bullet 2
above is that HDCP (and SW-Proxy) will be using priveleged submission
(GGTT and common gsc-uc-context) while PXP will be using non-priveleged
PPGTT, context and batch buffer. Therefore this patch will only slightly
overlap with the MTL-HDCP patches despite have very similar function
names (emit_foo vs emit_nonpriv_foo). This is because HECI_CMD_PKT
instructions require very different flows and hw-specific code when done
via PPGTT based submission (not different from other engines). MTL-HDCP
contains the same intel_gsc_mtl_header_t structures as this but the
helpers there are different. Both add the same new file names.
NOTE3: Additional clarity about the heci-cmd-pkt layout and where the
common helpers come in:
- When an internal subsystem needs to send a command request
to the security firmware on MTL onwards, it will send that
via the GSC-engine-command-streamer.
- However those commands, (lets call them "gsc_specific_fw_api"
calls), are not understood by the GSC command streamer hw.
- The command streamer DOES understand GSC_HECI_CMD_PKT but
requires an additional header before the "gsc_specific_fw_api"
is sent by the hw engine to the firmware (with additional
metadata).
- Thus, the structural layout of the request submitted would
need to look like the diagram below (for non-priv PXP).
- In the diagram, the common helper for HDCP, (GSC-Sw-Proxy) and
PXP (i.e. new function intel_gsc_uc_heci_cmd_emit_mtl_header)
will populate blob (C) while additional helpers different for
GGTT (not in this series) vs PPGTT (this patch) will populate
blobs (A) and (B) below.
___
(A) | MI_BATCH_BUFFER_START (ppgtt, batchbuff-addr, ...) |
| | |
|_| |
| (B)| GSC_HECI_CMD_PKT (pkt-addr-in, pkt-size-in,| |
|| pkt-addr-out, pkt-size-out) |
|| MI_BATCH_BUFFER_END| | |
||| | |
| | |
|_| |
|
-
|
\|/
__V___
| _|
|(C)| ||
| | struct intel_gsc_mtl_header { ||
| | validity marker ||
| | heci_clent_id ||
| | ... ||
| | }||
| |___||
|(D)| ||
| | struct gsc_fw_specific_api_foobar { ||
| | ... ||
| | For an example, see ||
| | 'struct pxp43_create_arb_in' at ||
| | intel_pxp_cmd_interface_43.h ||
| | ||
| | } ||
| | Struture depends on command type ||
| | struct gsc_fw_specific_api_foobar { ||
| |___||
||
That said, this patch provides basic helpers but leaves the
PXP subsystem (i.e. the caller) to handle everything else from
input/output packet size verification to handling the
responses from security firmware (such as requiring a retry).
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 +
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 107 ++
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 69 +++
4 files changed, 179 insertions(+)
create mode 100644
[Intel-gfx] [PATCH v2 7/9] drm/i915/pxp: MTL-KCR interrupt ctrl's are in GT-0
Despite KCR subsystem being in the media-tile (close to the
GSC-CS), the IRQ controls for it are on GT-0 with other global
IRQ controls. Thus, add a helper for KCR hw interrupt
enable/disable functions to get the correct gt structure (for
uncore) for MTL.
In the helper, we get GT-0's handle for uncore when touching
IRQ registers despite the pxp->ctrl_gt being the media-tile.
No difference for legacy of course.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 23 +---
drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 8 +++
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 4b8e70caa3ad..9f6e300486b4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -44,7 +44,7 @@ static int pxp_terminate_get(void *data, u64 *val)
static int pxp_terminate_set(void *data, u64 val)
{
struct intel_pxp *pxp = data;
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
if (!intel_pxp_is_active(pxp))
return -ENODEV;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
index 91e9622c07d0..2eef0c19e91a 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
@@ -8,6 +8,7 @@
#include "gt/intel_gt_regs.h"
#include "gt/intel_gt_types.h"
+#include "i915_drv.h"
#include "i915_irq.h"
#include "i915_reg.h"
@@ -17,6 +18,22 @@
#include "intel_pxp_types.h"
#include "intel_runtime_pm.h"
+/**
+ * intel_pxp_get_irq_gt - Find the correct GT that owns KCR interrupts
+ * @pxp: pointer to pxp struct
+ *
+ * For platforms with a single GT, we return the pxp->ctrl_gt (as expected)
+ * but for MTL+ that has a media-tile, although the KCR engine is in the
+ * media-tile (i.e. pxp->ctrl_gt), the IRQ controls are on the root tile.
+ */
+struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp)
+{
+ if (pxp->uses_gsccs)
+ return to_gt(pxp->ctrl_gt->i915);
+
+ return pxp->ctrl_gt;
+}
+
/**
* intel_pxp_irq_handler - Handles PXP interrupts.
* @pxp: pointer to pxp struct
@@ -29,7 +46,7 @@ void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
if (GEM_WARN_ON(!intel_pxp_is_enabled(pxp)))
return;
- gt = pxp->ctrl_gt;
+ gt = intel_pxp_get_irq_gt(pxp);
lockdep_assert_held(gt->irq_lock);
@@ -68,7 +85,7 @@ static inline void pxp_irq_reset(struct intel_gt *gt)
void intel_pxp_irq_enable(struct intel_pxp *pxp)
{
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
spin_lock_irq(gt->irq_lock);
@@ -83,7 +100,7 @@ void intel_pxp_irq_enable(struct intel_pxp *pxp)
void intel_pxp_irq_disable(struct intel_pxp *pxp)
{
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
/*
* We always need to submit a global termination when we re-enable the
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
index 8c292dc86f68..eea87c9eb62b 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
@@ -9,6 +9,7 @@
#include
struct intel_pxp;
+struct intel_gt;
#define GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT BIT(1)
#define GEN12_DISPLAY_APP_TERMINATED_PER_FW_REQ_INTERRUPT BIT(2)
@@ -23,6 +24,8 @@ struct intel_pxp;
void intel_pxp_irq_enable(struct intel_pxp *pxp);
void intel_pxp_irq_disable(struct intel_pxp *pxp);
void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir);
+struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp);
+
#else
static inline void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
{
@@ -35,6 +38,11 @@ static inline void intel_pxp_irq_enable(struct intel_pxp
*pxp)
static inline void intel_pxp_irq_disable(struct intel_pxp *pxp)
{
}
+
+static inline struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp)
+{
+ return NULL;
+}
#endif
#endif /* __INTEL_PXP_IRQ_H__ */
--
2.39.0
[Intel-gfx] [PATCH v2 2/9] drm/i915/pxp: Add GSC-CS back-end resource init and cleanup
For MTL, PXP transport back-end uses the GSC engine to submit
HECI packets for PXP arb session management. The command submission
that uses non-priveleged mode requires us to allocate (or free)
a set of execution submission resources (buffer-object, batch-buffer
and context). Thus, do this one time allocation of resources in
GSC-CS init and clean them up in fini.
Signed-off-by: Alan Previn
---
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 6 +-
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 216 +-
drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 5 +
3 files changed, 225 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index ad67e3f49c20..52b9a61bcdd4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -10,7 +10,11 @@
#include "intel_pxp_cmd_interface_cmn.h"
/* PXP-Cmd-Op definitions */
-#define PXP43_CMDID_START_HUC_AUTH 0x003A
+#define PXP43_CMDID_START_HUC_AUTH 0x003A
+
+/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
+#define PXP43_MAX_HECI_IN_SIZE (SZ_32K)
+#define PXP43_MAX_HECI_OUT_SIZE(SZ_32K)
/* PXP-Input-Packet: HUC-Authentication */
struct pxp43_start_huc_auth_in {
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 21400650fc86..97ca187e6fde 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -3,9 +3,41 @@
* Copyright(c) 2023 Intel Corporation.
*/
+#include "gem/i915_gem_internal.h"
+
+#include "gt/intel_context.h"
+
#include "i915_drv.h"
-#include "intel_pxp_types.h"
+#include "intel_pxp_cmd_interface_43.h"
#include "intel_pxp_gsccs.h"
+#include "intel_pxp_types.h"
+
+struct gsccs_session_resources {
+ struct mutex cmd_mutex; /* Protects submission for arb session */
+ u64 host_session_handle; /* used by firmware to link commands to
sessions */
+
+ struct intel_context *ce; /* context for gsc command submission */
+ struct i915_ppgtt *ppgtt; /* ppgtt for gsc command submission */
+
+ struct drm_i915_gem_object *pkt_obj; /* PXP HECI message packet buffer
*/
+ struct i915_vma *pkt_vma; /* PXP HECI message packet vma */
+ void *pkt_vaddr; /* PXP HECI message packet virt memory pointer */
+
+ /* Buffer info for GSC engine batch buffer: */
+ struct drm_i915_gem_object *bb_obj; /* batch buffer object */
+ struct i915_vma *bb_vma; /* batch buffer vma */
+ void *bb_vaddr; /* batch buffer virtual memory pointer */
+};
+
+struct gsccs_teelink_priv {
+ /** @arb_exec_res: resources for arb-session GSC-CS PXP command
submission */
+ struct gsccs_session_resources arb_exec_res;
+};
+
+static inline struct gsccs_teelink_priv *pxp_to_gsccs_priv(struct intel_pxp
*pxp)
+{
+ return (struct gsccs_teelink_priv *)pxp->gsccs_priv;
+}
int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
int arb_session_id)
@@ -13,11 +45,193 @@ int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
return -ENODEV;
}
+static void
+gsccs_destroy_buffer(struct drm_i915_private *i915, struct i915_vma *vma,
+struct drm_i915_gem_object *obj)
+{
+ int err;
+
+ i915_vma_unpin(vma);
+ err = i915_vma_unbind(vma);
+ if (err)
+ drm_dbg(>drm, "Unexpected failure when vma-unbinding =
%d\n", err);
+
+ i915_gem_object_unpin_map(obj);
+ i915_gem_object_unpin_pages(obj);
+ i915_gem_object_put(obj);
+}
+
+static int
+gsccs_create_buffer(struct drm_i915_private *i915, const char *bufname,
+ size_t size, struct i915_ppgtt *ppgtt,
+ struct drm_i915_gem_object **obj,
+ struct i915_vma **vma, void **map)
+{
+ int err = 0;
+
+ *obj = i915_gem_object_create_internal(i915, size);
+ if (IS_ERR(*obj)) {
+ drm_err(>drm, "Failed to allocate gsccs backend %s.\n",
bufname);
+ err = PTR_ERR(*obj);
+ goto out_none;
+ }
+
+ *vma = i915_vma_instance(*obj, >vm, NULL);
+ if (IS_ERR(*vma)) {
+ drm_err(>drm, "Failed to vma-instance gsccs backend
%s.\n", bufname);
+ err = PTR_ERR(*vma);
+ goto out_put;
+ }
+
+ err = i915_gem_object_pin_pages_unlocked(*obj);
+ if (err) {
+ drm_err(>drm, "Failed to pin gsccs backend %s.\n",
bufname);
+ goto out_put;
+ }
+
+ /* map to the virtual memory pointer */
+ *map = i915_gem_object_pin_map_unlocked(*obj,
i915_coherent_map_type(i915, *obj, true));
+ if (IS_ERR(*map)) {
+ drm_err(>drm, "Failed to map gsccs backend %s.\n",
bufname);
+ err = PTR_ERR(*map);
+ goto
[Intel-gfx] [PATCH v2 8/9] drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component
On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on the tee-component
operation before we can start sending GSC-CS firmware messages.
Thus, immediately enable KCR HW on PXP's init, fini and resume.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 52 ++--
drivers/gpu/drm/i915/pxp/intel_pxp.h | 4 +-
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 10 ++---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 13 +-
4 files changed, 49 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 809b49f59594..90e739345924 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -143,10 +143,12 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
- if (pxp->uses_gsccs)
+ if (pxp->uses_gsccs) {
ret = intel_pxp_gsccs_init(pxp);
- else
+ intel_pxp_init_hw(pxp, true);
+ } else {
ret = intel_pxp_tee_component_init(pxp);
+ }
if (ret)
goto out_context;
@@ -249,10 +251,12 @@ void intel_pxp_fini(struct drm_i915_private *i915)
i915->pxp->arb_is_valid = false;
- if (i915->pxp->uses_gsccs)
+ if (i915->pxp->uses_gsccs) {
+ intel_pxp_fini_hw(i915->pxp, true);
intel_pxp_gsccs_fini(i915->pxp);
- else
+ } else {
intel_pxp_tee_component_fini(i915->pxp);
+ }
destroy_vcs_context(i915->pxp);
@@ -304,8 +308,9 @@ int intel_pxp_start(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
- if (wait_for(pxp_component_bound(pxp), 250))
- return -ENXIO;
+ if (!pxp->uses_gsccs)
+ if (wait_for(pxp_component_bound(pxp), 250))
+ return -ENXIO;
mutex_lock(>arb_mutex);
@@ -331,16 +336,39 @@ int intel_pxp_start(struct intel_pxp *pxp)
return ret;
}
-void intel_pxp_init_hw(struct intel_pxp *pxp)
+static void
+intel_pxp_hw_state_change(struct intel_pxp *pxp, bool enable,
+ bool skip_if_runtime_pm_off)
+{
+ intel_wakeref_t wakeref;
+
+ if (skip_if_runtime_pm_off) {
+ /* if we are suspended, the HW will be re-initialized on resume
*/
+ wakeref =
intel_runtime_pm_get_if_in_use(>ctrl_gt->i915->runtime_pm);
+ if (!wakeref)
+ return;
+ }
+
+ if (enable) {
+ kcr_pxp_enable(pxp);
+ intel_pxp_irq_enable(pxp);
+ } else {
+ kcr_pxp_disable(pxp);
+ intel_pxp_irq_disable(pxp);
+ }
+
+ if (skip_if_runtime_pm_off)
+ intel_runtime_pm_put(>ctrl_gt->i915->runtime_pm, wakeref);
+}
+
+void intel_pxp_init_hw(struct intel_pxp *pxp, bool skip_if_runtime_pm_off)
{
- kcr_pxp_enable(pxp);
- intel_pxp_irq_enable(pxp);
+ intel_pxp_hw_state_change(pxp, true, skip_if_runtime_pm_off);
}
-void intel_pxp_fini_hw(struct intel_pxp *pxp)
+void intel_pxp_fini_hw(struct intel_pxp *pxp, bool skip_if_runtime_pm_off)
{
- kcr_pxp_disable(pxp);
- intel_pxp_irq_disable(pxp);
+ intel_pxp_hw_state_change(pxp, false, skip_if_runtime_pm_off);
}
int intel_pxp_key_check(struct intel_pxp *pxp,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 04440fada711..6c1fe3f0a20c 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -20,8 +20,8 @@ bool intel_pxp_is_active(const struct intel_pxp *pxp);
int intel_pxp_init(struct drm_i915_private *i915);
void intel_pxp_fini(struct drm_i915_private *i915);
-void intel_pxp_init_hw(struct intel_pxp *pxp);
-void intel_pxp_fini_hw(struct intel_pxp *pxp);
+void intel_pxp_init_hw(struct intel_pxp *pxp, bool skip_if_runtime_pm_off);
+void intel_pxp_fini_hw(struct intel_pxp *pxp, bool skip_if_runtime_pm_off);
void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 892d39cc61c1..94c1b2fe1eb2 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -29,7 +29,7 @@ void intel_pxp_suspend(struct intel_pxp *pxp)
return;
with_intel_runtime_pm(>ctrl_gt->i915->runtime_pm, wakeref) {
- intel_pxp_fini_hw(pxp);
+ intel_pxp_fini_hw(pxp, false);
pxp->hw_state_invalidated = false;
}
}
@@ -40,14 +40,14 @@ void intel_pxp_resume(struct intel_pxp *pxp)
return;
/*
-* The PXP component gets automatically unbound when we go into S3 and
+* On
[Intel-gfx] [PATCH v2 1/9] drm/i915/pxp: Add MTL PXP GSC-CS back-end skeleton
Add MTL PXP GSC-CS back-end stub functions hook them
up from PXP front-end and PXP session management functions.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/pxp/intel_pxp.c | 19 +++--
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 23 +++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h | 30
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 6 +++-
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 6
6 files changed, 81 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f47f00b162a4..eae4325310e8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -330,6 +330,7 @@ i915-y += \
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
pxp/intel_pxp_debugfs.o \
+ pxp/intel_pxp_gsccs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index cfc9af8b3d21..be52bf92e847 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -12,6 +12,7 @@
#include "i915_drv.h"
#include "intel_pxp.h"
+#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
@@ -132,7 +133,10 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
- ret = intel_pxp_tee_component_init(pxp);
+ if (pxp->uses_gsccs)
+ ret = intel_pxp_gsccs_init(pxp);
+ else
+ ret = intel_pxp_tee_component_init(pxp);
if (ret)
goto out_context;
@@ -157,6 +161,11 @@ static struct intel_gt
*find_gt_for_required_teelink(struct drm_i915_private *i9
return NULL;
}
+static bool pxp_has_gsccs(struct drm_i915_private *i915)
+{
+ return (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0));
+}
+
static struct intel_gt *find_gt_for_required_protected_content(struct
drm_i915_private *i915)
{
if (!IS_ENABLED(CONFIG_DRM_I915_PXP) || !INTEL_INFO(i915)->has_pxp)
@@ -167,7 +176,7 @@ static struct intel_gt
*find_gt_for_required_protected_content(struct drm_i915_p
* on the media GT. NOTE: if we have a media-tile with a GSC-engine,
* the VDBOX is already present so skip that check
*/
- if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0))
+ if (pxp_has_gsccs(i915))
return i915->media_gt;
/*
@@ -208,6 +217,7 @@ int intel_pxp_init(struct drm_i915_private *i915)
return -ENOMEM;
i915->pxp->ctrl_gt = gt;
+ i915->pxp->uses_gsccs = pxp_has_gsccs(i915);
/*
* If full PXP feature is not available but HuC is loaded by GSC on
pre-MTL
@@ -229,7 +239,10 @@ void intel_pxp_fini(struct drm_i915_private *i915)
i915->pxp->arb_is_valid = false;
- intel_pxp_tee_component_fini(i915->pxp);
+ if (i915->pxp->uses_gsccs)
+ intel_pxp_gsccs_fini(i915->pxp);
+ else
+ intel_pxp_tee_component_fini(i915->pxp);
destroy_vcs_context(i915->pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
new file mode 100644
index ..21400650fc86
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2023 Intel Corporation.
+ */
+
+#include "i915_drv.h"
+#include "intel_pxp_types.h"
+#include "intel_pxp_gsccs.h"
+
+int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
+ int arb_session_id)
+{
+ return -ENODEV;
+}
+
+void intel_pxp_gsccs_fini(struct intel_pxp *pxp)
+{
+}
+
+int intel_pxp_gsccs_init(struct intel_pxp *pxp)
+{
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
new file mode 100644
index ..07f8c9b6f636
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2022, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_GSCCS_H__
+#define __INTEL_PXP_GSCCS_H__
+
+#include
+
+struct intel_pxp;
+
+#ifdef CONFIG_DRM_I915_PXP
+int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
+ int arb_session_id);
+void intel_pxp_gsccs_fini(struct intel_pxp *pxp);
+int intel_pxp_gsccs_init(struct intel_pxp *pxp);
+
+#else
+static inline void intel_pxp_gsccs_fini(struct intel_pxp *pxp)
+{
+}
+
+static inline int intel_pxp_gsccs_init(struct intel_pxp *pxp)
+{
+ return 0;
+}
+#endif
+
+#endif /*__INTEL_PXP_GSCCS_H__ */
diff --git
[Intel-gfx] [PATCH v2 3/9] drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation
Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:
1. Updating 'pick-gt' to get the media tile for
KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
(init, status-checking, etc.).
While doing #2, lets create a separate registers header file for PXP
to be consistent with other i915 global subsystems.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 3 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 35
drivers/gpu/drm/i915/pxp/intel_pxp_regs.h| 26 +++
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 29 +++-
4 files changed, 70 insertions(+), 23 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 8fac2660e16b..957fa11373fc 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -100,7 +100,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8
class, u8 instance)
case VIDEO_ENHANCEMENT_CLASS:
return media_gt;
case OTHER_CLASS:
- if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt,
GSC0))
+ if ((instance == OTHER_GSC_INSTANCE || instance ==
OTHER_KCR_INSTANCE) &&
+ HAS_ENGINE(media_gt, GSC0))
return media_gt;
fallthrough;
default:
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index be52bf92e847..809b49f59594 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -14,6 +14,7 @@
#include "intel_pxp.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
+#include "intel_pxp_regs.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
#include "intel_pxp_types.h"
@@ -61,21 +62,30 @@ bool intel_pxp_is_active(const struct intel_pxp *pxp)
return IS_ENABLED(CONFIG_DRM_I915_PXP) && pxp && pxp->arb_is_valid;
}
-/* KCR register definitions */
-#define KCR_INIT _MMIO(0x320f0)
-/* Setting KCR Init bit is required after system boot */
-#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+static i915_reg_t get_kcr_reg(const struct intel_pxp *pxp)
+{
+ if (pxp->gsccs_priv)
+ return MTL_KCR_INIT;
+ return GEN12_KCR_INIT;
+}
-static void kcr_pxp_enable(struct intel_gt *gt)
+static void kcr_pxp_set_status(const struct intel_pxp *pxp, bool enable)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ i915_reg_t reg = get_kcr_reg(pxp);
+ u32 val = enable ? _MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES)
:
+ _MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
+
+ intel_uncore_write(pxp->ctrl_gt->uncore, reg, val);
}
-static void kcr_pxp_disable(struct intel_gt *gt)
+static void kcr_pxp_enable(const struct intel_pxp *pxp)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ kcr_pxp_set_status(pxp, true);
+}
+
+static void kcr_pxp_disable(const struct intel_pxp *pxp)
+{
+ kcr_pxp_set_status(pxp, false);
}
static int create_vcs_context(struct intel_pxp *pxp)
@@ -323,14 +333,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
void intel_pxp_init_hw(struct intel_pxp *pxp)
{
- kcr_pxp_enable(pxp->ctrl_gt);
+ kcr_pxp_enable(pxp);
intel_pxp_irq_enable(pxp);
}
void intel_pxp_fini_hw(struct intel_pxp *pxp)
{
- kcr_pxp_disable(pxp->ctrl_gt);
-
+ kcr_pxp_disable(pxp);
intel_pxp_irq_disable(pxp);
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
new file mode 100644
index ..dd4131903d4e
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2023, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_REGS_H__
+#define __INTEL_PXP_REGS_H__
+
+#include "i915_reg_defs.h"
+
+/* KCR enable/disable control */
+#define GEN12_KCR_INIT _MMIO(0x320f0)
+#define MTL_KCR_INIT _MMIO(0x3860f0)
+
+/* Setting KCR Init bit is required after system boot */
+#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+
+/* KCR hwdrm session in play status 0-31 */
+#define GEN12_KCR_SIP _MMIO(0x32260)
+#define MTL_KCR_SIP _MMIO(0x386260)
+
+/* PXP global terminate register for session termination */
+#define GEN12_KCR_GLOBAL_TERMINATE _MMIO(0x320f8)
+#define MTL_KCR_GLOBAL_TERMINATE _MMIO(0x3860f8)
+
+#endif /* __INTEL_PXP_REGS_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 080aa2209c5b..7bb06e67b155 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++
[Intel-gfx] [PATCH v2 6/9] drm/i915/pxp: Add ARB session creation with new PXP API Ver4.3
Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.
Before checking the return status, look at the GSC-CS-Mem-Header's
pending-bit which means the GSC firmware is busy and we should
resubmit.
Signed-off-by: Alan Previn
---
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 21 +++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 56 ++-
2 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index 52b9a61bcdd4..ee78c0817ba1 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -11,6 +11,7 @@
/* PXP-Cmd-Op definitions */
#define PXP43_CMDID_START_HUC_AUTH 0x003A
+#define PXP43_CMDID_INIT_SESSION 0x0036
/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
#define PXP43_MAX_HECI_IN_SIZE (SZ_32K)
@@ -27,4 +28,24 @@ struct pxp43_start_huc_auth_out {
struct pxp_cmd_header header;
} __packed;
+/* PXP-Input-Packet: Init PXP session */
+struct pxp43_create_arb_in {
+ struct pxp_cmd_header header;
+ /* header.stream_id fields for vesion 4.3 of Init PXP session:
*/
+ #define PXP43_INIT_SESSION_VALID GENMASK(0, 0)
+ #define PXP43_INIT_SESSION_APPTYPE GENMASK(1, 1)
+ #define PXP43_INIT_SESSION_APPID GENMASK(17, 2)
+ u32 protection_mode;
+ #define PXP43_INIT_SESSION_PROTECTION_ARB 0x2
+ u32 sub_session_id;
+ u32 init_flags;
+ u32 rsvd[12];
+} __packed;
+
+/* PXP-Input-Packet: Init PXP session */
+struct pxp43_create_arb_out {
+ struct pxp_cmd_header header;
+ u32 rsvd[8];
+} __packed;
+
#endif /* __INTEL_PXP_FW_INTERFACE_43_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index ff235822743e..1b06629ac16e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -43,7 +43,8 @@ static inline struct gsccs_teelink_priv
*pxp_to_gsccs_priv(struct intel_pxp *pxp
static int gsccs_send_message(struct intel_pxp *pxp,
void *msg_in, size_t msg_in_size,
void *msg_out, size_t msg_out_size_max,
- size_t *msg_out_len)
+ size_t *msg_out_len,
+ u64 *gsc_msg_handle_retry)
{
struct intel_gt *gt = pxp->ctrl_gt;
struct drm_i915_private *i915 = gt->i915;
@@ -75,6 +76,9 @@ static int gsccs_send_message(struct intel_pxp *pxp,
msg_in_size + sizeof(*header),
exec->host_session_handle);
+ /* copy caller provided gsc message handle if this is polling for a
prior msg completion */
+ header->gsc_message_handle = *gsc_msg_handle_retry;
+
memcpy(exec->pkt_vaddr + sizeof(*header), msg_in, msg_in_size);
pkt.addr_in = i915_vma_offset(exec->pkt_vma);
@@ -91,7 +95,7 @@ static int gsccs_send_message(struct intel_pxp *pxp,
goto unlock;
}
- /* we keep separate location for reply, so get the response header loc
first */
+ /* we keep separate location for reply, so go to the response header
now */
header = exec->pkt_vaddr + PXP43_MAX_HECI_IN_SIZE;
/* Response validity marker, status and busyness */
@@ -108,6 +112,13 @@ static int gsccs_send_message(struct intel_pxp *pxp,
}
if (header->flags & GSC_HECI_FLAG_MSG_PENDING) {
drm_dbg(>drm, "gsc PXP reply is busy\n");
+ /*
+* When the GSC firmware replies with pending bit, it means
that the requested
+* operation has begun but the completion is pending and the
caller needs
+* to re-request with the gsc_message_handle that was returned
by the firmware.
+* until the pending bit is turned off.
+*/
+ *gsc_msg_handle_retry = header->gsc_message_handle;
ret = -EAGAIN;
goto unlock;
}
@@ -135,7 +146,46 @@ static int gsccs_send_message(struct intel_pxp *pxp,
int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
int arb_session_id)
{
- return -ENODEV;
+ struct gsccs_session_resources *exec =
_to_gsccs_priv(pxp)->arb_exec_res;
+ struct pxp43_create_arb_in msg_in = {0};
+ struct pxp43_create_arb_out msg_out = {0};
+ u64 gsc_session_retry = 0;
+ int insize, outsize, ret, tries = 0;
+ void *inptr, *outptr;
+
+ /* get a unique host-session-handle (used later in HW cmds) at time of
session creation */
+ get_random_bytes(>host_session_handle,
sizeof(exec->host_session_handle));
+
+
[Intel-gfx] [PATCH v2 5/9] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages
Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products. Use the newly
added helpers to populate the GSC-CS memory header and send the
message packet to the FW by dispatching the GSC_HECI_CMD_PKT
instruction on the GSC engine.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 93 ++
1 file changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 97ca187e6fde..ff235822743e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -6,6 +6,7 @@
#include "gem/i915_gem_internal.h"
#include "gt/intel_context.h"
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
#include "i915_drv.h"
#include "intel_pxp_cmd_interface_43.h"
@@ -39,6 +40,98 @@ static inline struct gsccs_teelink_priv
*pxp_to_gsccs_priv(struct intel_pxp *pxp
return (struct gsccs_teelink_priv *)pxp->gsccs_priv;
}
+static int gsccs_send_message(struct intel_pxp *pxp,
+ void *msg_in, size_t msg_in_size,
+ void *msg_out, size_t msg_out_size_max,
+ size_t *msg_out_len)
+{
+ struct intel_gt *gt = pxp->ctrl_gt;
+ struct drm_i915_private *i915 = gt->i915;
+ struct gsccs_session_resources *exec =
_to_gsccs_priv(pxp)->arb_exec_res;
+ struct intel_gsc_mtl_header *header = exec->pkt_vaddr;
+ struct intel_gsc_heci_non_priv_pkt pkt;
+ size_t max_msg_size;
+ u32 reply_size;
+ int ret;
+
+ if (!intel_uc_uses_gsc_uc(>uc))
+ return -ENODEV;
+
+ if (!exec->ce)
+ return -ENODEV;
+
+ max_msg_size = PXP43_MAX_HECI_IN_SIZE - sizeof(*header);
+
+ if (msg_in_size > max_msg_size || msg_out_size_max > max_msg_size)
+ return -ENOSPC;
+
+ mutex_lock(>cmd_mutex);
+
+ if (!exec->pkt_vma || !exec->bb_vma)
+ return -ENOENT;
+
+ memset(header, 0, sizeof(*header));
+ intel_gsc_uc_heci_cmd_emit_mtl_header(header, GSC_HECI_MEADDRESS_PXP,
+ msg_in_size + sizeof(*header),
+ exec->host_session_handle);
+
+ memcpy(exec->pkt_vaddr + sizeof(*header), msg_in, msg_in_size);
+
+ pkt.addr_in = i915_vma_offset(exec->pkt_vma);
+ pkt.size_in = header->message_size;
+ pkt.addr_out = pkt.addr_in + PXP43_MAX_HECI_IN_SIZE;
+ pkt.size_out = msg_out_size_max + sizeof(*header);
+ pkt.heci_pkt_vma = exec->pkt_vma;
+ pkt.bb_vma = exec->bb_vma;
+
+ ret = intel_gsc_uc_heci_cmd_submit_nonpriv(>ctrl_gt->uc.gsc,
+ exec->ce, ,
exec->bb_vaddr, 500);
+ if (ret) {
+ drm_err(>drm, "failed to send gsc PXP msg (%d)\n", ret);
+ goto unlock;
+ }
+
+ /* we keep separate location for reply, so get the response header loc
first */
+ header = exec->pkt_vaddr + PXP43_MAX_HECI_IN_SIZE;
+
+ /* Response validity marker, status and busyness */
+ if (header->validity_marker != GSC_HECI_VALIDITY_MARKER) {
+ drm_err(>drm, "gsc PXP reply with invalid validity
marker\n");
+ ret = -EINVAL;
+ goto unlock;
+ }
+ if (header->status != 0) {
+ drm_dbg(>drm, "gsc PXP reply status has error = 0x%08x\n",
+ header->status);
+ ret = -EINVAL;
+ goto unlock;
+ }
+ if (header->flags & GSC_HECI_FLAG_MSG_PENDING) {
+ drm_dbg(>drm, "gsc PXP reply is busy\n");
+ ret = -EAGAIN;
+ goto unlock;
+ }
+
+ reply_size = header->message_size - sizeof(*header);
+ if (reply_size > msg_out_size_max) {
+ drm_warn(>drm, "caller with insufficient PXP reply size
%u (%ld)\n",
+reply_size, msg_out_size_max);
+ reply_size = msg_out_size_max;
+ } else if (reply_size != msg_out_size_max) {
+ drm_dbg(>drm, "caller unexpected PXP reply size %u
(%ld)\n",
+ reply_size, msg_out_size_max);
+ }
+
+ memcpy(msg_out, exec->pkt_vaddr + PXP43_MAX_HECI_IN_SIZE +
sizeof(*header),
+ reply_size);
+ if (msg_out_len)
+ *msg_out_len = reply_size;
+
+unlock:
+ mutex_unlock(>cmd_mutex);
+ return ret;
+}
+
int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
int arb_session_id)
{
--
2.39.0
[Intel-gfx] [PATCH v2 0/9] drm/i915/pxp: Add MTL PXP Support
This series enables PXP on MTL. On ADL/TGL platforms, we rely on the mei driver via the i915-mei PXP component interface to establish a connection to the security firmware via the HECI device interface. That interface is used to create and teardown the PXP ARB session. PXP ARB session is created when protected contexts are created. In this series, the front end behaviors and interfaces (uapi) remain the same. We add backend support for MTL but with MTL we directly use the GSC-CS engine on the MTL GPU device to send messages to the PXP (a.k.a. GSC a.k.a graphics-security) firmware. With MTL, the format of the message is slightly different with a 2-layer packetization that is explained in detail in Patch #4. Also, the second layer which is the actual PXP firmware packet is now rev'd to version 4.3 for MTL that is defined in Patch #6. Changes from prior revs: v1 : - fixed when building with CONFIG_PXP disabled. - more alignment with gsc_mtl_header structure from the HDCP Alan Previn (9): drm/i915/pxp: Add MTL PXP GSC-CS back-end skeleton drm/i915/pxp: Add GSC-CS back-end resource init and cleanup drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC drm/i915/pxp: Add GSC-CS backend to send GSC fw messages drm/i915/pxp: Add ARB session creation with new PXP API Ver4.3 drm/i915/pxp: MTL-KCR interrupt ctrl's are in GT-0 drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component drm/i915/pxp: Enable PXP with MTL-GSC-CS drivers/gpu/drm/i915/Makefile | 2 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 + drivers/gpu/drm/i915/gt/intel_gt_irq.c| 3 +- .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 107 + .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 69 drivers/gpu/drm/i915/i915_pci.c | 1 + drivers/gpu/drm/i915/pxp/intel_pxp.c | 92 - drivers/gpu/drm/i915/pxp/intel_pxp.h | 4 +- .../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 27 +- drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 2 +- drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 380 ++ drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h| 30 ++ drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 23 +- drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 8 + drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 10 +- drivers/gpu/drm/i915/pxp/intel_pxp_regs.h | 26 ++ drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 37 +- drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 13 +- drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 11 + 19 files changed, 791 insertions(+), 56 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h base-commit: bf7f7c53ac622a3f6d6738d062e59dd21ce28bd7 -- 2.39.0
Re: [Intel-gfx] [PATCH] drm/i915/display: assume some pixelrate for src smaller than 1
On 11.1.2023 22.09, Drew Davenport wrote:
On Wed, Jan 11, 2023 at 09:39:26PM +0200, Ville Syrjälä wrote:
On Wed, Jan 11, 2023 at 11:28:51AM -0700, Drew Davenport wrote:
On Wed, Jan 11, 2023 at 04:19:00PM +0200, Ville Syrjälä wrote:
On Wed, Jan 04, 2023 at 02:44:48PM +0200, Juha-Pekka Heikkila wrote:
intel_adjusted_rate() didn't take into account src rectangle
can be less than 1 in width or height.
This should not get called in those cases. What does the
backtrace look like?
In my repro of this issue, the backtrace looks as follows:
[ 180.798331] RIP: 0010:intel_plane_pixel_rate+0x4a/0x53
[ 180.798336] Code:
[ 180.798338] RSP: 0018:b080ce4179b8 EFLAGS: 00010246
[ 180.798341] RAX: RBX: 98cd22a24000 RCX: 0a00
[ 180.798343] RDX: RSI: 98cccbae7000 RDI:
[ 180.798346] RBP: b080ce4179b8 R08: 00087780 R09: 0002
[ 180.798348] R10: 0a00 R11: R12:
[ 180.798350] R13: 98cd0e495400 R14: 98ccc34e R15: 98cccbae7000
[ 180.798352] FS: 7b84119b5000() GS:98d02f90()
knlGS:
[ 180.798354] CS: 0010 DS: ES: CR0: 80050033
[ 180.798357] CR2: 7ffc2d5e4080 CR3: 0001042ee006 CR4: 00770ee0
[ 180.798359] PKRU: 5554
[ 180.798361] Call Trace:
[ 180.798364]
[ 180.798366] intel_plane_atomic_check_with_state+0x1fd/0x6ea
[ 180.798370] ? intel_plane_atomic_check+0x11b/0x145
[ 180.798373] intel_atomic_check_planes+0x263/0x7ce
[ 180.798376] ? drm_atomic_helper_check_modeset+0x189/0x923
[ 180.798380] intel_atomic_check+0x14e4/0x184d
[ 180.798382] ? intel_rps_mark_interactive+0x23/0x6a
[ 180.798386] drm_atomic_check_only+0x3ec/0x98f
[ 180.798391] drm_atomic_commit+0xa2/0x105
[ 180.798394] ? drm_atomic_set_fb_for_plane+0x96/0xa5
[ 180.798397] drm_atomic_helper_update_plane+0xdc/0x11f
[ 180.798400] drm_mode_setplane+0x236/0x30c
[ 180.798404] ? drm_any_plane_has_format+0x51/0x51
[ 180.798407] drm_ioctl_kernel+0xda/0x14d
[ 180.798411] drm_ioctl+0x27e/0x3b4
[ 180.798414] ? drm_any_plane_has_format+0x51/0x51
[ 180.798418] __se_sys_ioctl+0x7a/0xbc
[ 180.798421] do_syscall_64+0x55/0x9d
[ 180.798424] ? exit_to_user_mode_prepare+0x3c/0x8b
[ 180.798427] entry_SYSCALL_64_after_hwframe+0x61/0xcb
If this function shouldn't be called in such a case, then perhaps
I should revist my original attempt at fixing this in
https://patchwork.freedesktop.org/patch/516060 by rejecting such a
configuration?
I'm saying that this should be impossible already. At least
I can't immediately see anything that could call this with
an invisible plane.
In my repro case, I called drmModeSetPlane with the src_h parameter set
to 65535 (so the largest 16.16 number that's less than one). This got
through any existing checks on the height of the src rect, resulting in
the divide-by-zero error in intel_plane_pixel_rate.
While investigating this, I tried setting src_h to 0, but this
configuration got rejected somewhere along the line before it got
through the intel_plane_pixel_rate.
Here's one of the igt tests I had come up when debugging this:
---
#include "igt.h"
igt_main
{
igt_subtest_f("testi") {
int drm_fd = drm_open_driver_master(DRIVER_INTEL);
igt_display_t display;
igt_plane_t* plane;
igt_output_t *output;
igt_fb_t fb;
kmstest_set_vt_graphics_mode();
igt_display_require(, drm_fd);
igt_display_require_output();
output = igt_get_single_output_for_pipe(, PIPE_A);
igt_output_set_pipe(output, PIPE_A);
igt_display_commit_atomic(,
DRM_MODE_ATOMIC_ALLOW_MODESET, NULL);
igt_create_pattern_fb(drm_fd, 256, 256,
DRM_FORMAT_XRGB,
DRM_FORMAT_MOD_NONE,
);
plane = igt_output_get_plane_type(output,
DRM_PLANE_TYPE_PRIMARY);
igt_plane_set_position(plane, 0, 0);
igt_plane_set_fb(plane, );
igt_plane_set_prop_value(plane, IGT_PLANE_SRC_H, IGT_FIXED(0,
30));
igt_plane_set_size(plane, 256, 8);
igt_display_commit_atomic(,
DRM_MODE_ATOMIC_ALLOW_MODESET, NULL);
}
}
---
This should give callstack ending same way as what Drew had seen. With
my patch in place this test will die with einval coming from kernel from
skl_update_scaler(..) where it doesn't pass range checks (and will note
on dmesg about it)
/Juha-Pekka
I'll respond to Alan on that thread.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
[Intel-gfx] ✗ Fi.CI.BAT: failure for Add module oriented dmesg output (rev4)
== Series Details == Series: Add module oriented dmesg output (rev4) URL : https://patchwork.freedesktop.org/series/111050/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12574 -> Patchwork_111050v4 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_111050v4 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_111050v4, 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_111050v4/index.html Participating hosts (35 -> 34) -- Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_111050v4: ### IGT changes ### Possible regressions * igt@i915_suspend@basic-s2idle-without-i915: - fi-ilk-650: [PASS][1] -> [DMESG-WARN][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/fi-ilk-650/igt@i915_susp...@basic-s2idle-without-i915.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111050v4/fi-ilk-650/igt@i915_susp...@basic-s2idle-without-i915.html Known issues Here are the changes found in Patchwork_111050v4 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_pm_rpm@module-reload: - bat-dg1-5: [SKIP][3] -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12574/bat-dg1-5/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111050v4/bat-dg1-5/igt@i915_pm_...@module-reload.html Build changes - * Linux: CI_DRM_12574 -> Patchwork_111050v4 CI-20190529: 20190529 CI_DRM_12574: bf7f7c53ac622a3f6d6738d062e59dd21ce28bd7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7116: 79eb8984acd309108be713a8831e60667db67e21 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_111050v4: bf7f7c53ac622a3f6d6738d062e59dd21ce28bd7 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 73b4e474fcee drm/i915/gt: Start adding module oriented dmesg output == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111050v4/index.html
[Intel-gfx] ✗ Fi.CI.BUILD: failure for kvm/vfio: fix potential deadlock on vfio group lock (rev3)
== Series Details == Series: kvm/vfio: fix potential deadlock on vfio group lock (rev3) URL : https://patchwork.freedesktop.org/series/112568/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/112568/revisions/3/mbox/ not applied Applying: KVM: async kvm_destroy_vm for vfio devices Using index info to reconstruct a base tree... M drivers/vfio/vfio_main.c M include/linux/vfio.h Falling back to patching base and 3-way merge... Auto-merging include/linux/vfio.h Auto-merging drivers/vfio/vfio_main.c CONFLICT (content): Merge conflict in drivers/vfio/vfio_main.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 KVM: async kvm_destroy_vm for vfio devices When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add module oriented dmesg output (rev4)
== Series Details ==
Series: Add module oriented dmesg output (rev4)
URL : https://patchwork.freedesktop.org/series/111050/
State : warning
== Summary ==
Error: dim checkpatch failed
78c5a1428bb1 drm/i915/gt: Start adding module oriented dmesg output
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 6, in
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:363: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#363:
new file mode 100644
-:380: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_gt' - possible
side-effects?
#380: FILE: drivers/gpu/drm/i915/gt/intel_gt_print.h:13:
+#define gt_err(_gt, _fmt, ...) \
+ drm_err(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id, ##__VA_ARGS__)
-:383: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_gt' - possible
side-effects?
#383: FILE: drivers/gpu/drm/i915/gt/intel_gt_print.h:16:
+#define gt_warn(_gt, _fmt, ...) \
+ drm_warn(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id,
##__VA_ARGS__)
-:386: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_gt' - possible
side-effects?
#386: FILE: drivers/gpu/drm/i915/gt/intel_gt_print.h:19:
+#define gt_notice(_gt, _fmt, ...) \
+ drm_notice(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id,
##__VA_ARGS__)
-:389: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_gt' - possible
side-effects?
#389: FILE: drivers/gpu/drm/i915/gt/intel_gt_print.h:22:
+#define gt_info(_gt, _fmt, ...) \
+ drm_info(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id,
##__VA_ARGS__)
-:392: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_gt' - possible
side-effects?
#392: FILE: drivers/gpu/drm/i915/gt/intel_gt_print.h:25:
+#define gt_dbg(_gt, _fmt, ...) \
+ drm_dbg(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id, ##__VA_ARGS__)
-:395: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_gt' - possible
side-effects?
#395: FILE: drivers/gpu/drm/i915/gt/intel_gt_print.h:28:
+#define gt_err_ratelimited(_gt, _fmt, ...) \
+ drm_err_ratelimited(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id,
##__VA_ARGS__)
-:398: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_gt' - possible
side-effects?
#398: FILE: drivers/gpu/drm/i915/gt/intel_gt_print.h:31:
+#define gt_probe_error(_gt, _fmt, ...) \
+ do { \
+ if (i915_error_injected()) \
+ gt_dbg(_gt, _fmt, ##__VA_ARGS__); \
+ else \
+ gt_err(_gt, _fmt, ##__VA_ARGS__); \
+ } while (0)
-:398: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_fmt' - possible
side-effects?
#398: FILE: drivers/gpu/drm/i915/gt/intel_gt_print.h:31:
+#define gt_probe_error(_gt, _fmt, ...) \
+ do { \
+ if (i915_error_injected()) \
+ gt_dbg(_gt, _fmt, ##__VA_ARGS__); \
+ else \
+ gt_err(_gt, _fmt, ##__VA_ARGS__); \
+ } while (0)
-:406: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_gt' - possible
side-effects?
#406: FILE: drivers/gpu/drm/i915/gt/intel_gt_print.h:39:
+#define gt_WARN(_gt, _condition, _fmt, ...) \
+ drm_WARN(&(_gt)->i915->drm, _condition, "GT%u: " _fmt, (_gt)->info.id,
##__VA_ARGS__)
-:409: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_gt' - possible
side-effects?
#409: FILE: drivers/gpu/drm/i915/gt/intel_gt_print.h:42:
+#define gt_WARN_ONCE(_gt, _condition, _fmt, ...) \
+ drm_WARN_ONCE(&(_gt)->i915->drm, _condition, "GT%u: " _fmt,
(_gt)->info.id, ##__VA_ARGS__)
total: 0 errors, 1 warnings, 10 checks, 459 lines checked
Re: [Intel-gfx] [PATCH 1/2] KVM: async kvm_destroy_vm for vfio devices
On Wed, Jan 11, 2023, Jason Gunthorpe wrote:
> On Wed, Jan 11, 2023 at 07:54:51PM +, Sean Christopherson wrote:
>
> > Something feels off. If KVM's refcount is 0, then accessing
> > device->group->kvm
> > in vfio_device_open() can't happen unless there's a refcounting bug
> > somewhere.
>
> The problem is in close, not open.
The deadlock problem is, yes. My point is that if group_lock needs to be taken
when nullifying group->kvm during kvm_vfio_destroy(), then there is also a
refcounting
prolem with respect to open(). If there is no refcounting problem, then
nullifying
group->kvm during kvm_vfio_destroy() is unnecessary (but again, I doubt this is
the case).
The two things aren't directly related, but it seems possible to solve both
while
making this all slightly less ugly. Well, at least from KVM's perspective,
whether
or not it'd be an improvement on the VFIO side is definitely debatable.
> Specifically it would be very hard to avoid holding the group_lock
> during close which is when the put is done.
>
> > Rather than force devices to get KVM references, why not handle that in
> > common
> > VFIO code and drop KVM refcountin from devices? Worst case scenario KVM is
> > pinned
> > by a device that doesn't need KVM but is in a group associated with KVM.
> > If that's
> > a concern, it seems easy enough to add a flag to vfio_device_ops to
> > enumerate
> > whether or not the device depends on KVM.
>
> We can't make cross-dependencies between kvm and core VFIO - it is why
> so much of this is soo ugly.
Ugh, right, modules for everyone.
> The few device drivers that unavoidably have KVM involvment already
> have a KVM module dependency, so they can safely do the get/put
Rather than store a "struct kvm *" in vfio_device, what about adding a new set
of optional ops to get/put KVM references? Having dedicated KVM ops is gross,
but IMO it's less gross than backdooring the KVM pointer into open_device() by
stashing KVM into the device, e.g. it formalizes the VFIO API for devices that
depend on KVM instead of making devices pinky-swear to grab a reference during
open_device().
To further harden things, KVM could export only kvm_get_safe_kvm() if there are
no vendor modules. I.e. make kvm_get_kvm() an internal-only helper when
possible
and effectively force VFIO devices to use the safe variant. That would work
even
x86, as kvm_get_kvm() wouldn't be exported if neither KVM_AMD nor KVM_INTEL is
built as a module.
---
drivers/vfio/vfio_main.c | 20 +---
include/linux/vfio.h | 9 +++--
2 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 6e8804fe0095..b3a84d65baa6 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -772,7 +772,12 @@ static struct file *vfio_device_open(struct vfio_device
*device)
* reference and release it during close_device.
*/
mutex_lock(>group->group_lock);
- device->kvm = device->group->kvm;
+
+ if (device->kvm_ops && device->group->kvm) {
+ ret = device->kvm_ops->get_kvm(device->group->kvm);
+ if (ret)
+ goto err_undo_count;
+ }
if (device->ops->open_device) {
ret = device->ops->open_device(device);
@@ -823,8 +828,9 @@ static struct file *vfio_device_open(struct vfio_device
*device)
err_undo_count:
mutex_unlock(>group->group_lock);
device->open_count--;
- if (device->open_count == 0 && device->kvm)
- device->kvm = NULL;
+ if (device->open_count == 0 && device->kvm_ops)
+ device->kvm_ops->put_kvm();
+
mutex_unlock(>dev_set->lock);
module_put(device->dev->driver->owner);
err_unassign_container:
@@ -1039,8 +1045,8 @@ static int vfio_device_fops_release(struct inode *inode,
struct file *filep)
}
mutex_unlock(>group->group_lock);
device->open_count--;
- if (device->open_count == 0)
- device->kvm = NULL;
+ if (device->open_count == 0 && device->kvm_ops)
+ device->kvm_ops->put_kvm();
mutex_unlock(>dev_set->lock);
module_put(device->dev->driver->owner);
@@ -1656,8 +1662,8 @@ EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
* @file: VFIO group file
* @kvm: KVM to link
*
- * When a VFIO device is first opened the KVM will be available in
- * device->kvm if one was associated with the group.
+ * When a VFIO device is first opened, the device's kvm_ops->get_kvm() will be
+ * invoked with the KVM instance associated with the group (if applicable).
*/
void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
{
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index fdd393f70b19..d6dcbe0546bf 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -18,6 +18,11 @@
struct
[Intel-gfx] ✗ Fi.CI.BUILD: failure for kvm/vfio: fix potential deadlock on vfio group lock (rev2)
== Series Details == Series: kvm/vfio: fix potential deadlock on vfio group lock (rev2) URL : https://patchwork.freedesktop.org/series/112568/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/112568/revisions/2/mbox/ not applied Applying: KVM: async kvm_destroy_vm for vfio devices Using index info to reconstruct a base tree... M drivers/vfio/vfio_main.c Falling back to patching base and 3-way merge... Auto-merging drivers/vfio/vfio_main.c CONFLICT (content): Merge conflict in drivers/vfio/vfio_main.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 KVM: async kvm_destroy_vm for vfio devices 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".
Re: [Intel-gfx] [PATCH v2] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops
On Wed, Jan 11, 2023 at 9:23 PM Hans de Goede wrote:
>
> Hi,
>
> On 1/11/23 21:16, Rafael J. Wysocki wrote:
> > On Tue, Jan 10, 2023 at 4:30 PM Hans de Goede wrote:
> >>
> >> The Dell Latitude E6430 both with and without the optional NVidia dGPU
> >> has a bug in its ACPI tables which is causing Linux to assign the wrong
> >> ACPI fwnode / companion to the pci_device for the i915 iGPU.
> >>
> >> Specifically under the PCI root bridge there are these 2 ACPI Device()s :
> >>
> >> Scope (_SB.PCI0)
> >> {
> >> Device (GFX0)
> >> {
> >> Name (_ADR, 0x0002) // _ADR: Address
> >> }
> >>
> >> ...
> >>
> >> Device (VID)
> >> {
> >> Name (_ADR, 0x0002) // _ADR: Address
> >> ...
> >>
> >> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching
> >> {
> >> VDP8 = Arg0
> >> VDP1 (One, VDP8)
> >> }
> >>
> >> Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices
> >> {
> >> ...
> >> }
> >> ...
> >> }
> >> }
> >>
> >> The non-functional GFX0 ACPI device is a problem, because this gets
> >> returned as ACPI companion-device by acpi_find_child_device() for the iGPU.
> >>
> >> This is a long standing problem and the i915 driver does use the ACPI
> >> companion for some things, but works fine without it.
> >>
> >> However since commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
> >> acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device
> >> and that is set on the wrong acpi_device because of the wrong
> >> acpi_find_child_device() return. This breaks the ACPI video code,
> >> leading to non working backlight control in some cases.
> >>
> >> Add a type.backlight flag, mark ACPI video bus devices with this and make
> >> find_child_checks() return a higher score for children with this flag set,
> >> so that it picks the right companion-device.
> >>
> >> Co-developed-by: Rafael J. Wysocki
> >> Signed-off-by: Hans de Goede
> >> ---
> >> Changes in v2:
> >> - Switch to Rafael's suggested implementation using a type.backlight flag
> >> and only make find_child_checks() return a higher score when this is set
> >> ---
> >> drivers/acpi/glue.c | 14 --
> >> drivers/acpi/scan.c | 7 +--
> >> include/acpi/acpi_bus.h | 3 ++-
> >> 3 files changed, 19 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> >> index 204fe94c7e45..a194f30876c5 100644
> >> --- a/drivers/acpi/glue.c
> >> +++ b/drivers/acpi/glue.c
> >> @@ -75,7 +75,8 @@ static struct acpi_bus_type *acpi_get_bus_type(struct
> >> device *dev)
> >> }
> >>
> >> #define FIND_CHILD_MIN_SCORE 1
> >> -#define FIND_CHILD_MAX_SCORE 2
> >> +#define FIND_CHILD_MID_SCORE 2
> >> +#define FIND_CHILD_MAX_SCORE 3
> >>
> >> static int match_any(struct acpi_device *adev, void *not_used)
> >> {
> >> @@ -96,8 +97,17 @@ static int find_child_checks(struct acpi_device *adev,
> >> bool check_children)
> >> return -ENODEV;
> >>
> >> status = acpi_evaluate_integer(adev->handle, "_STA", NULL, );
> >> - if (status == AE_NOT_FOUND)
> >> + if (status == AE_NOT_FOUND) {
> >> + /*
> >> +* Special case: backlight device objects without _STA are
> >> +* preferred to other objects with the same _ADR value,
> >> because
> >> +* it is more likely that they are actually useful.
> >> +*/
> >> + if (adev->pnp.type.backlight)
> >> + return FIND_CHILD_MID_SCORE;
> >> +
> >> return FIND_CHILD_MIN_SCORE;
> >> + }
> >>
> >> if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_ENABLED))
> >> return -ENODEV;
> >> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> >> index 274344434282..0c6f06abe3f4 100644
> >> --- a/drivers/acpi/scan.c
> >> +++ b/drivers/acpi/scan.c
> >> @@ -1370,9 +1370,12 @@ static void acpi_set_pnp_ids(acpi_handle handle,
> >> struct acpi_device_pnp *pnp,
> >> * Some devices don't reliably have _HIDs & _CIDs, so add
> >> * synthetic HIDs to make sure drivers can find them.
> >> */
> >> - if (acpi_is_video_device(handle))
> >> + if (acpi_is_video_device(handle)) {
> >> acpi_add_id(pnp, ACPI_VIDEO_HID);
> >> - else if (acpi_bay_match(handle))
> >> + pnp->type.backlight = 1;
> >> + break;
> >> + }
> >> + if (acpi_bay_match(handle))
> >> acpi_add_id(pnp, ACPI_BAY_HID);
> >> else if (acpi_dock_match(handle))
> >> acpi_add_id(pnp, ACPI_DOCK_HID);
> >> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> >> index cd3b75e08ec3..e44be31115a6
Re: [Intel-gfx] [PATCH v2] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops
Hi,
On 1/11/23 21:16, Rafael J. Wysocki wrote:
> On Tue, Jan 10, 2023 at 4:30 PM Hans de Goede wrote:
>>
>> The Dell Latitude E6430 both with and without the optional NVidia dGPU
>> has a bug in its ACPI tables which is causing Linux to assign the wrong
>> ACPI fwnode / companion to the pci_device for the i915 iGPU.
>>
>> Specifically under the PCI root bridge there are these 2 ACPI Device()s :
>>
>> Scope (_SB.PCI0)
>> {
>> Device (GFX0)
>> {
>> Name (_ADR, 0x0002) // _ADR: Address
>> }
>>
>> ...
>>
>> Device (VID)
>> {
>> Name (_ADR, 0x0002) // _ADR: Address
>> ...
>>
>> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching
>> {
>> VDP8 = Arg0
>> VDP1 (One, VDP8)
>> }
>>
>> Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices
>> {
>> ...
>> }
>> ...
>> }
>> }
>>
>> The non-functional GFX0 ACPI device is a problem, because this gets
>> returned as ACPI companion-device by acpi_find_child_device() for the iGPU.
>>
>> This is a long standing problem and the i915 driver does use the ACPI
>> companion for some things, but works fine without it.
>>
>> However since commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
>> acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device
>> and that is set on the wrong acpi_device because of the wrong
>> acpi_find_child_device() return. This breaks the ACPI video code,
>> leading to non working backlight control in some cases.
>>
>> Add a type.backlight flag, mark ACPI video bus devices with this and make
>> find_child_checks() return a higher score for children with this flag set,
>> so that it picks the right companion-device.
>>
>> Co-developed-by: Rafael J. Wysocki
>> Signed-off-by: Hans de Goede
>> ---
>> Changes in v2:
>> - Switch to Rafael's suggested implementation using a type.backlight flag
>> and only make find_child_checks() return a higher score when this is set
>> ---
>> drivers/acpi/glue.c | 14 --
>> drivers/acpi/scan.c | 7 +--
>> include/acpi/acpi_bus.h | 3 ++-
>> 3 files changed, 19 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
>> index 204fe94c7e45..a194f30876c5 100644
>> --- a/drivers/acpi/glue.c
>> +++ b/drivers/acpi/glue.c
>> @@ -75,7 +75,8 @@ static struct acpi_bus_type *acpi_get_bus_type(struct
>> device *dev)
>> }
>>
>> #define FIND_CHILD_MIN_SCORE 1
>> -#define FIND_CHILD_MAX_SCORE 2
>> +#define FIND_CHILD_MID_SCORE 2
>> +#define FIND_CHILD_MAX_SCORE 3
>>
>> static int match_any(struct acpi_device *adev, void *not_used)
>> {
>> @@ -96,8 +97,17 @@ static int find_child_checks(struct acpi_device *adev,
>> bool check_children)
>> return -ENODEV;
>>
>> status = acpi_evaluate_integer(adev->handle, "_STA", NULL, );
>> - if (status == AE_NOT_FOUND)
>> + if (status == AE_NOT_FOUND) {
>> + /*
>> +* Special case: backlight device objects without _STA are
>> +* preferred to other objects with the same _ADR value,
>> because
>> +* it is more likely that they are actually useful.
>> +*/
>> + if (adev->pnp.type.backlight)
>> + return FIND_CHILD_MID_SCORE;
>> +
>> return FIND_CHILD_MIN_SCORE;
>> + }
>>
>> if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_ENABLED))
>> return -ENODEV;
>> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> index 274344434282..0c6f06abe3f4 100644
>> --- a/drivers/acpi/scan.c
>> +++ b/drivers/acpi/scan.c
>> @@ -1370,9 +1370,12 @@ static void acpi_set_pnp_ids(acpi_handle handle,
>> struct acpi_device_pnp *pnp,
>> * Some devices don't reliably have _HIDs & _CIDs, so add
>> * synthetic HIDs to make sure drivers can find them.
>> */
>> - if (acpi_is_video_device(handle))
>> + if (acpi_is_video_device(handle)) {
>> acpi_add_id(pnp, ACPI_VIDEO_HID);
>> - else if (acpi_bay_match(handle))
>> + pnp->type.backlight = 1;
>> + break;
>> + }
>> + if (acpi_bay_match(handle))
>> acpi_add_id(pnp, ACPI_BAY_HID);
>> else if (acpi_dock_match(handle))
>> acpi_add_id(pnp, ACPI_DOCK_HID);
>> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
>> index cd3b75e08ec3..e44be31115a6 100644
>> --- a/include/acpi/acpi_bus.h
>> +++ b/include/acpi/acpi_bus.h
>> @@ -230,7 +230,8 @@ struct acpi_pnp_type {
>> u32 hardware_id:1;
>> u32 bus_address:1;
>> u32 platform_id:1;
>> - u32 reserved:29;
>> + u32 backlight:1;
>> + u32 reserved:28;
>> };
>>
>>
Re: [Intel-gfx] [PATCH v2] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops
On Tue, Jan 10, 2023 at 4:30 PM Hans de Goede wrote:
>
> The Dell Latitude E6430 both with and without the optional NVidia dGPU
> has a bug in its ACPI tables which is causing Linux to assign the wrong
> ACPI fwnode / companion to the pci_device for the i915 iGPU.
>
> Specifically under the PCI root bridge there are these 2 ACPI Device()s :
>
> Scope (_SB.PCI0)
> {
> Device (GFX0)
> {
> Name (_ADR, 0x0002) // _ADR: Address
> }
>
> ...
>
> Device (VID)
> {
> Name (_ADR, 0x0002) // _ADR: Address
> ...
>
> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching
> {
> VDP8 = Arg0
> VDP1 (One, VDP8)
> }
>
> Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices
> {
> ...
> }
> ...
> }
> }
>
> The non-functional GFX0 ACPI device is a problem, because this gets
> returned as ACPI companion-device by acpi_find_child_device() for the iGPU.
>
> This is a long standing problem and the i915 driver does use the ACPI
> companion for some things, but works fine without it.
>
> However since commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
> acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device
> and that is set on the wrong acpi_device because of the wrong
> acpi_find_child_device() return. This breaks the ACPI video code,
> leading to non working backlight control in some cases.
>
> Add a type.backlight flag, mark ACPI video bus devices with this and make
> find_child_checks() return a higher score for children with this flag set,
> so that it picks the right companion-device.
>
> Co-developed-by: Rafael J. Wysocki
> Signed-off-by: Hans de Goede
> ---
> Changes in v2:
> - Switch to Rafael's suggested implementation using a type.backlight flag
> and only make find_child_checks() return a higher score when this is set
> ---
> drivers/acpi/glue.c | 14 --
> drivers/acpi/scan.c | 7 +--
> include/acpi/acpi_bus.h | 3 ++-
> 3 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index 204fe94c7e45..a194f30876c5 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -75,7 +75,8 @@ static struct acpi_bus_type *acpi_get_bus_type(struct
> device *dev)
> }
>
> #define FIND_CHILD_MIN_SCORE 1
> -#define FIND_CHILD_MAX_SCORE 2
> +#define FIND_CHILD_MID_SCORE 2
> +#define FIND_CHILD_MAX_SCORE 3
>
> static int match_any(struct acpi_device *adev, void *not_used)
> {
> @@ -96,8 +97,17 @@ static int find_child_checks(struct acpi_device *adev,
> bool check_children)
> return -ENODEV;
>
> status = acpi_evaluate_integer(adev->handle, "_STA", NULL, );
> - if (status == AE_NOT_FOUND)
> + if (status == AE_NOT_FOUND) {
> + /*
> +* Special case: backlight device objects without _STA are
> +* preferred to other objects with the same _ADR value,
> because
> +* it is more likely that they are actually useful.
> +*/
> + if (adev->pnp.type.backlight)
> + return FIND_CHILD_MID_SCORE;
> +
> return FIND_CHILD_MIN_SCORE;
> + }
>
> if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_ENABLED))
> return -ENODEV;
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 274344434282..0c6f06abe3f4 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1370,9 +1370,12 @@ static void acpi_set_pnp_ids(acpi_handle handle,
> struct acpi_device_pnp *pnp,
> * Some devices don't reliably have _HIDs & _CIDs, so add
> * synthetic HIDs to make sure drivers can find them.
> */
> - if (acpi_is_video_device(handle))
> + if (acpi_is_video_device(handle)) {
> acpi_add_id(pnp, ACPI_VIDEO_HID);
> - else if (acpi_bay_match(handle))
> + pnp->type.backlight = 1;
> + break;
> + }
> + if (acpi_bay_match(handle))
> acpi_add_id(pnp, ACPI_BAY_HID);
> else if (acpi_dock_match(handle))
> acpi_add_id(pnp, ACPI_DOCK_HID);
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index cd3b75e08ec3..e44be31115a6 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -230,7 +230,8 @@ struct acpi_pnp_type {
> u32 hardware_id:1;
> u32 bus_address:1;
> u32 platform_id:1;
> - u32 reserved:29;
> + u32 backlight:1;
> + u32 reserved:28;
> };
>
> struct acpi_device_pnp {
> --
Applied as 6.2-rc material, thanks!
Re: [Intel-gfx] [PATCH] drm/i915/display: assume some pixelrate for src smaller than 1
On Wed, Jan 11, 2023 at 09:39:26PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 11, 2023 at 11:28:51AM -0700, Drew Davenport wrote:
> > On Wed, Jan 11, 2023 at 04:19:00PM +0200, Ville Syrjälä wrote:
> > > On Wed, Jan 04, 2023 at 02:44:48PM +0200, Juha-Pekka Heikkila wrote:
> > > > intel_adjusted_rate() didn't take into account src rectangle
> > > > can be less than 1 in width or height.
> > >
> > > This should not get called in those cases. What does the
> > > backtrace look like?
> >
> > In my repro of this issue, the backtrace looks as follows:
> >
> > [ 180.798331] RIP: 0010:intel_plane_pixel_rate+0x4a/0x53
> > [ 180.798336] Code:
> > [ 180.798338] RSP: 0018:b080ce4179b8 EFLAGS: 00010246
> > [ 180.798341] RAX: RBX: 98cd22a24000 RCX:
> > 0a00
> > [ 180.798343] RDX: RSI: 98cccbae7000 RDI:
> >
> > [ 180.798346] RBP: b080ce4179b8 R08: 00087780 R09:
> > 0002
> > [ 180.798348] R10: 0a00 R11: R12:
> >
> > [ 180.798350] R13: 98cd0e495400 R14: 98ccc34e R15:
> > 98cccbae7000
> > [ 180.798352] FS: 7b84119b5000() GS:98d02f90()
> > knlGS:
> > [ 180.798354] CS: 0010 DS: ES: CR0: 80050033
> > [ 180.798357] CR2: 7ffc2d5e4080 CR3: 0001042ee006 CR4:
> > 00770ee0
> > [ 180.798359] PKRU: 5554
> > [ 180.798361] Call Trace:
> > [ 180.798364]
> > [ 180.798366] intel_plane_atomic_check_with_state+0x1fd/0x6ea
> > [ 180.798370] ? intel_plane_atomic_check+0x11b/0x145
> > [ 180.798373] intel_atomic_check_planes+0x263/0x7ce
> > [ 180.798376] ? drm_atomic_helper_check_modeset+0x189/0x923
> > [ 180.798380] intel_atomic_check+0x14e4/0x184d
> > [ 180.798382] ? intel_rps_mark_interactive+0x23/0x6a
> > [ 180.798386] drm_atomic_check_only+0x3ec/0x98f
> > [ 180.798391] drm_atomic_commit+0xa2/0x105
> > [ 180.798394] ? drm_atomic_set_fb_for_plane+0x96/0xa5
> > [ 180.798397] drm_atomic_helper_update_plane+0xdc/0x11f
> > [ 180.798400] drm_mode_setplane+0x236/0x30c
> > [ 180.798404] ? drm_any_plane_has_format+0x51/0x51
> > [ 180.798407] drm_ioctl_kernel+0xda/0x14d
> > [ 180.798411] drm_ioctl+0x27e/0x3b4
> > [ 180.798414] ? drm_any_plane_has_format+0x51/0x51
> > [ 180.798418] __se_sys_ioctl+0x7a/0xbc
> > [ 180.798421] do_syscall_64+0x55/0x9d
> > [ 180.798424] ? exit_to_user_mode_prepare+0x3c/0x8b
> > [ 180.798427] entry_SYSCALL_64_after_hwframe+0x61/0xcb
> >
> > If this function shouldn't be called in such a case, then perhaps
> > I should revist my original attempt at fixing this in
> > https://patchwork.freedesktop.org/patch/516060 by rejecting such a
> > configuration?
>
> I'm saying that this should be impossible already. At least
> I can't immediately see anything that could call this with
> an invisible plane.
In my repro case, I called drmModeSetPlane with the src_h parameter set
to 65535 (so the largest 16.16 number that's less than one). This got
through any existing checks on the height of the src rect, resulting in
the divide-by-zero error in intel_plane_pixel_rate.
While investigating this, I tried setting src_h to 0, but this
configuration got rejected somewhere along the line before it got
through the intel_plane_pixel_rate.
>
> >
> > I'll respond to Alan on that thread.
> >
> > >
> > > >
> > > > Signed-off-by: Juha-Pekka Heikkila
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_atomic_plane.c | 8 +---
> > > > 1 file changed, 5 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > index 10e1fc9d0698..a9948e8d3543 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > @@ -144,7 +144,7 @@ unsigned int intel_adjusted_rate(const struct
> > > > drm_rect *src,
> > > > const struct drm_rect *dst,
> > > > unsigned int rate)
> > > > {
> > > > - unsigned int src_w, src_h, dst_w, dst_h;
> > > > + unsigned int src_w, src_h, dst_w, dst_h, dst_wh;
> > > >
> > > > src_w = drm_rect_width(src) >> 16;
> > > > src_h = drm_rect_height(src) >> 16;
> > > > @@ -155,8 +155,10 @@ unsigned int intel_adjusted_rate(const struct
> > > > drm_rect *src,
> > > > dst_w = min(src_w, dst_w);
> > > > dst_h = min(src_h, dst_h);
> > > >
> > > > - return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h),
> > > > - dst_w * dst_h);
> > > > + /* in case src contained only fractional part */
> > > > + dst_wh = max(dst_w * dst_h, (unsigned) 1);
> > > > +
> > > > + return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h),
> > > > dst_wh);
> > > > }
> > > >
> > > > unsigned int
Re: [Intel-gfx] [PATCH 1/2] KVM: async kvm_destroy_vm for vfio devices
On Wed, Jan 11, 2023 at 07:54:51PM +, Sean Christopherson wrote: > Something feels off. If KVM's refcount is 0, then accessing > device->group->kvm > in vfio_device_open() can't happen unless there's a refcounting bug somewhere. The problem is in close, not open. Specifically it would be very hard to avoid holding the group_lock during close which is when the put is done. > Rather than force devices to get KVM references, why not handle that in common > VFIO code and drop KVM refcountin from devices? Worst case scenario KVM is > pinned > by a device that doesn't need KVM but is in a group associated with KVM. If > that's > a concern, it seems easy enough to add a flag to vfio_device_ops to enumerate > whether or not the device depends on KVM. We can't make cross-dependencies between kvm and core VFIO - it is why so much of this is soo ugly. The few device drivers that unavoidably have KVM involvment already have a KVM module dependency, so they can safely do the get/put Jason
[Intel-gfx] [PATCH v4 1/1] drm/i915/gt: Start adding module oriented dmesg output
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a GT# prefix on it.
v2: Go back to using lower case names (combined review feedback).
Convert intel_gt.c as a first step.
v3: Add gt_err_ratelimited() as well, undo one conversation that might
not have a GT pointer in some scenarios (review feedback from Michal W).
Split definitions into separate header (review feedback from Jani).
Convert all intel_gt*.c files.
v4: Re-order some macro definitions (Andi S), update (c) date (Tvrtko)
Signed-off-by: John Harrison
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt.c| 96 +--
.../gpu/drm/i915/gt/intel_gt_clock_utils.c| 8 +-
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 9 +-
drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 9 +-
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 9 +-
drivers/gpu/drm/i915/gt/intel_gt_print.h | 51 ++
drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 4 +-
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 34 ++-
drivers/gpu/drm/i915/gt/intel_gtt.c | 7 +-
9 files changed, 129 insertions(+), 98 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_print.h
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 5721bf85d1197..f0dbfc434e077 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -22,6 +22,7 @@
#include "intel_gt_debugfs.h"
#include "intel_gt_mcr.h"
#include "intel_gt_pm.h"
+#include "intel_gt_print.h"
#include "intel_gt_regs.h"
#include "intel_gt_requests.h"
#include "intel_migrate.h"
@@ -89,9 +90,8 @@ static int intel_gt_probe_lmem(struct intel_gt *gt)
if (err == -ENODEV)
return 0;
- drm_err(>drm,
- "Failed to setup region(%d) type=%d\n",
- err, INTEL_MEMORY_LOCAL);
+ gt_err(gt, "Failed to setup region(%d) type=%d\n",
+ err, INTEL_MEMORY_LOCAL);
return err;
}
@@ -200,14 +200,14 @@ int intel_gt_init_hw(struct intel_gt *gt)
ret = i915_ppgtt_init_hw(gt);
if (ret) {
- drm_err(>drm, "Enabling PPGTT failed (%d)\n", ret);
+ gt_err(gt, "Enabling PPGTT failed (%d)\n", ret);
goto out;
}
/* We can't enable contexts until all firmware is loaded */
ret = intel_uc_init_hw(>uc);
if (ret) {
- i915_probe_error(i915, "Enabling uc failed (%d)\n", ret);
+ gt_probe_error(gt, "Enabling uc failed (%d)\n", ret);
goto out;
}
@@ -257,7 +257,7 @@ intel_gt_clear_error_registers(struct intel_gt *gt,
* some errors might have become stuck,
* mask them.
*/
- drm_dbg(>i915->drm, "EIR stuck: 0x%08x, masking\n", eir);
+ gt_dbg(gt, "EIR stuck: 0x%08x, masking\n", eir);
intel_uncore_rmw(uncore, EMR, 0, eir);
intel_uncore_write(uncore, GEN2_IIR,
I915_MASTER_ERROR_INTERRUPT);
@@ -291,16 +291,16 @@ static void gen6_check_faults(struct intel_gt *gt)
for_each_engine(engine, gt, id) {
fault = GEN6_RING_FAULT_REG_READ(engine);
if (fault & RING_FAULT_VALID) {
- drm_dbg(>i915->drm, "Unexpected fault\n"
- "\tAddr: 0x%08lx\n"
- "\tAddress space: %s\n"
- "\tSource ID: %d\n"
- "\tType: %d\n",
- fault & PAGE_MASK,
- fault & RING_FAULT_GTTSEL_MASK ?
- "GGTT" : "PPGTT",
- RING_FAULT_SRCID(fault),
- RING_FAULT_FAULT_TYPE(fault));
+ gt_dbg(gt, "Unexpected fault\n"
+ "\tAddr: 0x%08lx\n"
+ "\tAddress space: %s\n"
+ "\tSource ID: %d\n"
+ "\tType: %d\n",
+ fault & PAGE_MASK,
+ fault & RING_FAULT_GTTSEL_MASK ?
+ "GGTT" : "PPGTT",
+ RING_FAULT_SRCID(fault),
+ RING_FAULT_FAULT_TYPE(fault));
}
}
}
@@ -327,17 +327,17 @@ static void xehp_check_faults(struct intel_gt *gt)
fault_addr = ((u64)(fault_data1 & FAULT_VA_HIGH_BITS) << 44) |
((u64)fault_data0 << 12);
- drm_dbg(>i915->drm,
[Intel-gfx] [PATCH v4 0/1] Add module oriented dmesg output
From: John Harrison When trying to analyse bug reports from CI, customers, etc. it can be difficult to work out exactly what is happening on which GT in a multi-GT system. So add GT oriented debug/error message wrappers. If used instead of the drm_ equivalents, you get the same output but with a GT# prefix on it. This patch set updates the gt/intel_gt*.c files to use the new helpers as a first step. The intention would be to convert all output messages throughout the driver as long as they have access to a GT structure. v2: Go back to using lower case names, add more wrapper sets (combined review feedback). Also, wrap up probe injection and WARN entries. v3: Split definitions out to separate header files. Tweak some messages. Wrap a couple more functions. (review feedback from Jani and Michal W). Convert all gt/intel_gt*.c but drop the GuC/HuC/CT files as too much bikeshedding about formatting. v4: Re-order some macro definitions (Andi S), update (c) date (Tvrtko) Signed-off-by: John Harrison Reviewed-by: Tvrtko Ursulin John Harrison (1): drm/i915/gt: Start adding module oriented dmesg output drivers/gpu/drm/i915/gt/intel_gt.c| 96 +-- .../gpu/drm/i915/gt/intel_gt_clock_utils.c| 8 +- drivers/gpu/drm/i915/gt/intel_gt_irq.c| 9 +- drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 9 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 9 +- drivers/gpu/drm/i915/gt/intel_gt_print.h | 51 ++ drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 4 +- drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 34 ++- drivers/gpu/drm/i915/gt/intel_gtt.c | 7 +- 9 files changed, 129 insertions(+), 98 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_print.h -- 2.39.0
Re: [Intel-gfx] [PATCH 1/2] KVM: async kvm_destroy_vm for vfio devices
On Mon, Jan 09, 2023, Matthew Rosato wrote:
> Currently it is possible that the final put of a KVM reference comes from
> vfio during its device close operation. This occurs while the vfio group
> lock is held; however, if the vfio device is still in the kvm device list,
> then the following call chain could result in a deadlock:
>
> kvm_put_kvm
> -> kvm_destroy_vm
> -> kvm_destroy_devices
>-> kvm_vfio_destroy
> -> kvm_vfio_file_set_kvm
> -> vfio_file_set_kvm
> -> group->group_lock/group_rwsem
>
> Avoid this scenario by adding kvm_put_kvm_async which will perform the
> kvm_destroy_vm asynchronously if the refcount reaches 0.
Something feels off. If KVM's refcount is 0, then accessing device->group->kvm
in vfio_device_open() can't happen unless there's a refcounting bug somewhere.
E.g. if this snippet holds group_lock
mutex_lock(>group->group_lock);
device->kvm = device->group->kvm;
if (device->ops->open_device) {
ret = device->ops->open_device(device);
if (ret)
goto err_undo_count;
}
vfio_device_container_register(device);
mutex_unlock(>group->group_lock);
and kvm_vfio_destroy() has already been invoked and is waiting on group_lock in
vfio_file_set_kvm(), then device->ops->open_device() is being called with a
non-NULL device->kvm that has kvm->users_count==0. And intel_vgpu_open_device()
at least uses kvm_get_kvm(), i.e. assumes kvm->users_count > 0.
If there's no refcounting bug then kvm_vfio_destroy() doesn't need to call
kvm_vfio_file_set_kvm() since the only way there isn't a refcounting bug is if
group->kvm is unreachable. This seems unlikely.
Assuming there is indeed a refcounting issue, one solution would be to harden
all
->open_device() implementations to use kvm_get_kvm_safe(). I'd prefer not to
have
to do that since it will complicate those implementations and also requires KVM
to support an async put.
Rather than force devices to get KVM references, why not handle that in common
VFIO code and drop KVM refcountin from devices? Worst case scenario KVM is
pinned
by a device that doesn't need KVM but is in a group associated with KVM. If
that's
a concern, it seems easy enough to add a flag to vfio_device_ops to enumerate
whether or not the device depends on KVM.
---
drivers/vfio/vfio_main.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 6e8804fe0095..fb43212d77a0 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -772,6 +772,13 @@ static struct file *vfio_device_open(struct vfio_device
*device)
* reference and release it during close_device.
*/
mutex_lock(>group->group_lock);
+
+ if (device->group->kvm &&
+ !kvm_get_kvm_safe(device->group->kvm->kvm)) {
+ ret = -ENODEV;
+ goto err_undo_count;
+ }
+
device->kvm = device->group->kvm;
if (device->ops->open_device) {
@@ -823,8 +830,10 @@ static struct file *vfio_device_open(struct vfio_device
*device)
err_undo_count:
mutex_unlock(>group->group_lock);
device->open_count--;
- if (device->open_count == 0 && device->kvm)
+ if (device->open_count == 0 && device->kvm) {
+ kvm_put_kvm(device->kvm);
device->kvm = NULL;
+ }
mutex_unlock(>dev_set->lock);
module_put(device->dev->driver->owner);
err_unassign_container:
@@ -1039,8 +1048,10 @@ static int vfio_device_fops_release(struct inode *inode,
struct file *filep)
}
mutex_unlock(>group->group_lock);
device->open_count--;
- if (device->open_count == 0)
+ if (device->open_count == 0 && device->kvm) {
+ kvm_put_kvm(device->kvm);
device->kvm = NULL;
+ }
mutex_unlock(>dev_set->lock);
module_put(device->dev->driver->owner);
base-commit: d52444c7a90fc551b4c3b0bda7d3f0b2ca9fc84d
--
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Wed, Jan 11, 2023 at 08:50:37AM +, Tvrtko Ursulin wrote:
>
> On 10/01/2023 14:08, Jason Ekstrand wrote:
> > On Tue, Jan 10, 2023 at 5:28 AM Tvrtko Ursulin
> > mailto:tvrtko.ursu...@linux.intel.com>>
> > wrote:
> >
> >
> >
> > On 09/01/2023 17:27, Jason Ekstrand wrote:
> >
> > [snip]
> >
> > > >>> AFAICT it proposes to have 1:1 between *userspace* created
> > > contexts (per
> > > >>> context _and_ engine) and drm_sched. I am not sure avoiding
> > > invasive changes
> > > >>> to the shared code is in the spirit of the overall idea
> > and instead
> > > >>> opportunity should be used to look at way to
> > refactor/improve
> > > drm_sched.
> > >
> > >
> > > Maybe? I'm not convinced that what Xe is doing is an abuse at
> > all or
> > > really needs to drive a re-factor. (More on that later.)
> > There's only
> > > one real issue which is that it fires off potentially a lot of
> > kthreads.
> > > Even that's not that bad given that kthreads are pretty light and
> > you're
> > > not likely to have more kthreads than userspace threads which are
> > much
> > > heavier. Not ideal, but not the end of the world either.
> > Definitely
> > > something we can/should optimize but if we went through with Xe
> > without
> > > this patch, it would probably be mostly ok.
> > >
> > > >> Yes, it is 1:1 *userspace* engines and drm_sched.
> > > >>
> > > >> I'm not really prepared to make large changes to DRM
> > scheduler
> > > at the
> > > >> moment for Xe as they are not really required nor does Boris
> > > seem they
> > > >> will be required for his work either. I am interested to see
> > > what Boris
> > > >> comes up with.
> > > >>
> > > >>> Even on the low level, the idea to replace drm_sched threads
> > > with workers
> > > >>> has a few problems.
> > > >>>
> > > >>> To start with, the pattern of:
> > > >>>
> > > >>> while (not_stopped) {
> > > >>> keep picking jobs
> > > >>> }
> > > >>>
> > > >>> Feels fundamentally in disagreement with workers (while
> > > obviously fits
> > > >>> perfectly with the current kthread design).
> > > >>
> > > >> The while loop breaks and worker exists if no jobs are ready.
> > >
> > >
> > > I'm not very familiar with workqueues. What are you saying would fit
> > > better? One scheduling job per work item rather than one big work
> > item
> > > which handles all available jobs?
> >
> > Yes and no, it indeed IMO does not fit to have a work item which is
> > potentially unbound in runtime. But it is a bit moot conceptual
> > mismatch
> > because it is a worst case / theoretical, and I think due more
> > fundamental concerns.
> >
> > If we have to go back to the low level side of things, I've picked this
> > random spot to consolidate what I have already mentioned and perhaps
> > expand.
> >
> > To start with, let me pull out some thoughts from workqueue.rst:
> >
> > """
> > Generally, work items are not expected to hog a CPU and consume many
> > cycles. That means maintaining just enough concurrency to prevent work
> > processing from stalling should be optimal.
> > """
> >
> > For unbound queues:
> > """
> > The responsibility of regulating concurrency level is on the users.
> > """
> >
> > Given the unbound queues will be spawned on demand to service all
> > queued
> > work items (more interesting when mixing up with the
> > system_unbound_wq),
> > in the proposed design the number of instantiated worker threads does
> > not correspond to the number of user threads (as you have elsewhere
> > stated), but pessimistically to the number of active user contexts.
> >
> >
> > Those are pretty much the same in practice. Rather, user threads is
> > typically an upper bound on the number of contexts. Yes, a single user
> > thread could have a bunch of contexts but basically nothing does that
> > except IGT. In real-world usage, it's at most one context per user
> > thread.
>
> Typically is the key here. But I am not sure it is good enough. Consider
> this example - Intel Flex 170:
>
> * Delivers up to 36 streams 1080p60 transcode throughput per card.
> * When scaled to 10 cards in a 4U server configuration, it can support up
> to 360 streams of HEVC/HEVC 1080p60 transcode throughput.
>
> One transcode stream from my experience typically is 3-4 GPU contexts
> (buffer travels from vcs -> rcs -> vcs, maybe vecs) used from a single CPU
> thread. 4 contexts * 36 streams = 144 active contexts. Multiply by 60fps =
> 8640 jobs submitted and
Re: [Intel-gfx] [PATCH] drm/i915/display: assume some pixelrate for src smaller than 1
On Wed, Jan 11, 2023 at 11:28:51AM -0700, Drew Davenport wrote:
> On Wed, Jan 11, 2023 at 04:19:00PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 04, 2023 at 02:44:48PM +0200, Juha-Pekka Heikkila wrote:
> > > intel_adjusted_rate() didn't take into account src rectangle
> > > can be less than 1 in width or height.
> >
> > This should not get called in those cases. What does the
> > backtrace look like?
>
> In my repro of this issue, the backtrace looks as follows:
>
> [ 180.798331] RIP: 0010:intel_plane_pixel_rate+0x4a/0x53
> [ 180.798336] Code:
> [ 180.798338] RSP: 0018:b080ce4179b8 EFLAGS: 00010246
> [ 180.798341] RAX: RBX: 98cd22a24000 RCX:
> 0a00
> [ 180.798343] RDX: RSI: 98cccbae7000 RDI:
>
> [ 180.798346] RBP: b080ce4179b8 R08: 00087780 R09:
> 0002
> [ 180.798348] R10: 0a00 R11: R12:
>
> [ 180.798350] R13: 98cd0e495400 R14: 98ccc34e R15:
> 98cccbae7000
> [ 180.798352] FS: 7b84119b5000() GS:98d02f90()
> knlGS:
> [ 180.798354] CS: 0010 DS: ES: CR0: 80050033
> [ 180.798357] CR2: 7ffc2d5e4080 CR3: 0001042ee006 CR4:
> 00770ee0
> [ 180.798359] PKRU: 5554
> [ 180.798361] Call Trace:
> [ 180.798364]
> [ 180.798366] intel_plane_atomic_check_with_state+0x1fd/0x6ea
> [ 180.798370] ? intel_plane_atomic_check+0x11b/0x145
> [ 180.798373] intel_atomic_check_planes+0x263/0x7ce
> [ 180.798376] ? drm_atomic_helper_check_modeset+0x189/0x923
> [ 180.798380] intel_atomic_check+0x14e4/0x184d
> [ 180.798382] ? intel_rps_mark_interactive+0x23/0x6a
> [ 180.798386] drm_atomic_check_only+0x3ec/0x98f
> [ 180.798391] drm_atomic_commit+0xa2/0x105
> [ 180.798394] ? drm_atomic_set_fb_for_plane+0x96/0xa5
> [ 180.798397] drm_atomic_helper_update_plane+0xdc/0x11f
> [ 180.798400] drm_mode_setplane+0x236/0x30c
> [ 180.798404] ? drm_any_plane_has_format+0x51/0x51
> [ 180.798407] drm_ioctl_kernel+0xda/0x14d
> [ 180.798411] drm_ioctl+0x27e/0x3b4
> [ 180.798414] ? drm_any_plane_has_format+0x51/0x51
> [ 180.798418] __se_sys_ioctl+0x7a/0xbc
> [ 180.798421] do_syscall_64+0x55/0x9d
> [ 180.798424] ? exit_to_user_mode_prepare+0x3c/0x8b
> [ 180.798427] entry_SYSCALL_64_after_hwframe+0x61/0xcb
>
> If this function shouldn't be called in such a case, then perhaps
> I should revist my original attempt at fixing this in
> https://patchwork.freedesktop.org/patch/516060 by rejecting such a
> configuration?
I'm saying that this should be impossible already. At least
I can't immediately see anything that could call this with
an invisible plane.
>
> I'll respond to Alan on that thread.
>
> >
> > >
> > > Signed-off-by: Juha-Pekka Heikkila
> > > ---
> > > drivers/gpu/drm/i915/display/intel_atomic_plane.c | 8 +---
> > > 1 file changed, 5 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > index 10e1fc9d0698..a9948e8d3543 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > @@ -144,7 +144,7 @@ unsigned int intel_adjusted_rate(const struct
> > > drm_rect *src,
> > >const struct drm_rect *dst,
> > >unsigned int rate)
> > > {
> > > - unsigned int src_w, src_h, dst_w, dst_h;
> > > + unsigned int src_w, src_h, dst_w, dst_h, dst_wh;
> > >
> > > src_w = drm_rect_width(src) >> 16;
> > > src_h = drm_rect_height(src) >> 16;
> > > @@ -155,8 +155,10 @@ unsigned int intel_adjusted_rate(const struct
> > > drm_rect *src,
> > > dst_w = min(src_w, dst_w);
> > > dst_h = min(src_h, dst_h);
> > >
> > > - return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h),
> > > - dst_w * dst_h);
> > > + /* in case src contained only fractional part */
> > > + dst_wh = max(dst_w * dst_h, (unsigned) 1);
> > > +
> > > + return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h), dst_wh);
> > > }
> > >
> > > unsigned int intel_plane_pixel_rate(const struct intel_crtc_state
> > > *crtc_state,
> > > --
> > > 2.37.3
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Wed, Jan 11, 2023 at 10:52:54AM -0800, John Harrison wrote:
> On 1/11/2023 10:07, Matthew Brost wrote:
> > On Wed, Jan 11, 2023 at 09:17:01AM +, Tvrtko Ursulin wrote:
> > > On 10/01/2023 19:01, Matthew Brost wrote:
> > > > On Tue, Jan 10, 2023 at 04:50:55PM +, Tvrtko Ursulin wrote:
> > > > > On 10/01/2023 15:55, Matthew Brost wrote:
> > > > > > On Tue, Jan 10, 2023 at 12:19:35PM +, Tvrtko Ursulin wrote:
> > > > > > > On 10/01/2023 11:28, Tvrtko Ursulin wrote:
> > > > > > > > On 09/01/2023 17:27, Jason Ekstrand wrote:
> > > > > > > >
> > > > > > > > [snip]
> > > > > > > >
> > > > > > > > > >>> AFAICT it proposes to have 1:1 between
> > > > > > > > > *userspace* created
> > > > > > > > > contexts (per
> > > > > > > > > >>> context _and_ engine) and drm_sched. I am not
> > > > > > > > > sure avoiding
> > > > > > > > > invasive changes
> > > > > > > > > >>> to the shared code is in the spirit of the
> > > > > > > > > overall idea and
> > > > > > > > > instead
> > > > > > > > > >>> opportunity should be used to look at way to
> > > > > > > > > refactor/improve
> > > > > > > > > drm_sched.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Maybe? I'm not convinced that what Xe is doing is an abuse
> > > > > > > > > at all
> > > > > > > > > or really needs to drive a re-factor. (More on that later.)
> > > > > > > > > There's only one real issue which is that it fires off
> > > > > > > > > potentially a
> > > > > > > > > lot of kthreads. Even that's not that bad given that kthreads
> > > > > > > > > are
> > > > > > > > > pretty light and you're not likely to have more kthreads than
> > > > > > > > > userspace threads which are much heavier. Not ideal, but not
> > > > > > > > > the
> > > > > > > > > end of the world either. Definitely something we can/should
> > > > > > > > > optimize but if we went through with Xe without this patch,
> > > > > > > > > it would
> > > > > > > > > probably be mostly ok.
> > > > > > > > >
> > > > > > > > > >> Yes, it is 1:1 *userspace* engines and drm_sched.
> > > > > > > > > >>
> > > > > > > > > >> I'm not really prepared to make large changes to
> > > > > > > > > DRM scheduler
> > > > > > > > > at the
> > > > > > > > > >> moment for Xe as they are not really required nor
> > > > > > > > > does Boris
> > > > > > > > > seem they
> > > > > > > > > >> will be required for his work either. I am
> > > > > > > > > interested to see
> > > > > > > > > what Boris
> > > > > > > > > >> comes up with.
> > > > > > > > > >>
> > > > > > > > > >>> Even on the low level, the idea to replace
> > > > > > > > > drm_sched threads
> > > > > > > > > with workers
> > > > > > > > > >>> has a few problems.
> > > > > > > > > >>>
> > > > > > > > > >>> To start with, the pattern of:
> > > > > > > > > >>>
> > > > > > > > > >>> while (not_stopped) {
> > > > > > > > > >>> keep picking jobs
> > > > > > > > > >>> }
> > > > > > > > > >>>
> > > > > > > > > >>> Feels fundamentally in disagreement with workers
> > > > > > > > > (while
> > > > > > > > > obviously fits
> > > > > > > > > >>> perfectly with the current kthread design).
> > > > > > > > > >>
> > > > > > > > > >> The while loop breaks and worker exists if no jobs
> > > > > > > > > are ready.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I'm not very familiar with workqueues. What are you saying
> > > > > > > > > would fit
> > > > > > > > > better? One scheduling job per work item rather than one big
> > > > > > > > > work
> > > > > > > > > item which handles all available jobs?
> > > > > > > > Yes and no, it indeed IMO does not fit to have a work item
> > > > > > > > which is
> > > > > > > > potentially unbound in runtime. But it is a bit moot conceptual
> > > > > > > > mismatch
> > > > > > > > because it is a worst case / theoretical, and I think due more
> > > > > > > > fundamental concerns.
> > > > > > > >
> > > > > > > > If we have to go back to the low level side of things, I've
> > > > > > > > picked this
> > > > > > > > random spot to consolidate what I have already mentioned and
> > > > > > > > perhaps
> > > > > > > > expand.
> > > > > > > >
> > > > > > > > To start with, let me pull out some thoughts from workqueue.rst:
> > > > > > > >
> > > > > > > > """
> > > > > > > > Generally, work items are not expected to hog a CPU and consume
> > > > > > > > many
> > > > > > > > cycles. That means maintaining just enough concurrency to
> > > > > > > > prevent work
> > > > > > > > processing from stalling should be optimal.
> > > > > > > > """
> > > > > > > >
> > > > > > > > For unbound queues:
> > > > > > > > """
> > > > > > > > The responsibility of regulating concurrency level is on the
> > > > > > > > users.
> > > > > > > > """
> > > > > >
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On 1/11/2023 10:07, Matthew Brost wrote:
On Wed, Jan 11, 2023 at 09:17:01AM +, Tvrtko Ursulin wrote:
On 10/01/2023 19:01, Matthew Brost wrote:
On Tue, Jan 10, 2023 at 04:50:55PM +, Tvrtko Ursulin wrote:
On 10/01/2023 15:55, Matthew Brost wrote:
On Tue, Jan 10, 2023 at 12:19:35PM +, Tvrtko Ursulin wrote:
On 10/01/2023 11:28, Tvrtko Ursulin wrote:
On 09/01/2023 17:27, Jason Ekstrand wrote:
[snip]
>>> AFAICT it proposes to have 1:1 between *userspace* created
contexts (per
>>> context _and_ engine) and drm_sched. I am not sure avoiding
invasive changes
>>> to the shared code is in the spirit of the overall idea and
instead
>>> opportunity should be used to look at way to refactor/improve
drm_sched.
Maybe? I'm not convinced that what Xe is doing is an abuse at all
or really needs to drive a re-factor. (More on that later.)
There's only one real issue which is that it fires off potentially a
lot of kthreads. Even that's not that bad given that kthreads are
pretty light and you're not likely to have more kthreads than
userspace threads which are much heavier. Not ideal, but not the
end of the world either. Definitely something we can/should
optimize but if we went through with Xe without this patch, it would
probably be mostly ok.
>> Yes, it is 1:1 *userspace* engines and drm_sched.
>>
>> I'm not really prepared to make large changes to DRM scheduler
at the
>> moment for Xe as they are not really required nor does Boris
seem they
>> will be required for his work either. I am interested to see
what Boris
>> comes up with.
>>
>>> Even on the low level, the idea to replace drm_sched threads
with workers
>>> has a few problems.
>>>
>>> To start with, the pattern of:
>>>
>>> while (not_stopped) {
>>> keep picking jobs
>>> }
>>>
>>> Feels fundamentally in disagreement with workers (while
obviously fits
>>> perfectly with the current kthread design).
>>
>> The while loop breaks and worker exists if no jobs are ready.
I'm not very familiar with workqueues. What are you saying would fit
better? One scheduling job per work item rather than one big work
item which handles all available jobs?
Yes and no, it indeed IMO does not fit to have a work item which is
potentially unbound in runtime. But it is a bit moot conceptual mismatch
because it is a worst case / theoretical, and I think due more
fundamental concerns.
If we have to go back to the low level side of things, I've picked this
random spot to consolidate what I have already mentioned and perhaps
expand.
To start with, let me pull out some thoughts from workqueue.rst:
"""
Generally, work items are not expected to hog a CPU and consume many
cycles. That means maintaining just enough concurrency to prevent work
processing from stalling should be optimal.
"""
For unbound queues:
"""
The responsibility of regulating concurrency level is on the users.
"""
Given the unbound queues will be spawned on demand to service all queued
work items (more interesting when mixing up with the system_unbound_wq),
in the proposed design the number of instantiated worker threads does
not correspond to the number of user threads (as you have elsewhere
stated), but pessimistically to the number of active user contexts. That
is the number which drives the maximum number of not-runnable jobs that
can become runnable at once, and hence spawn that many work items, and
in turn unbound worker threads.
Several problems there.
It is fundamentally pointless to have potentially that many more threads
than the number of CPU cores - it simply creates a scheduling storm.
To make matters worse, if I follow the code correctly, all these per user
context worker thread / work items end up contending on the same lock or
circular buffer, both are one instance per GPU:
guc_engine_run_job
-> submit_engine
a) wq_item_append
-> wq_wait_for_space
-> msleep
a) is dedicated per xe_engine
Hah true, what its for then? I thought throttling the LRCA ring is done via:
This is a per guc_id 'work queue' which is used for parallel submission
(e.g. multiple LRC tail values need to written atomically by the GuC).
Again in practice there should always be space.
Speaking of guc id, where does blocking when none are available happen in
the non parallel case?
We have 64k guc_ids on native, 1k guc_ids with 64k VFs. Either way we
think that is more than enough and can just reject xe_engine creation if
we run out of guc_ids. If this proves to false, we can fix this but the
guc_id stealing the i915 is rather complicated and hopefully not needed.
We will limit the number of guc_ids allowed per user pid to reasonible
number to prevent a DoS. Elevated pids (e.g. IGTs) will be able do to
whatever they
Re: [Intel-gfx] [PATCH] drm/i915/display: Check source height is > 0
On Tue, Dec 27, 2022 at 05:55:17PM +, Teres Alexis, Alan Previn wrote:
> Is there a better place for this check higher up the intel specific
> atomic-check? (so the check won't be skl specific - i notice that
> intel_adjusted_rate is also called by
> ilk_foo as well and non-backend-specific functions). Else, perhaps
> intel_adjusted_rate should add a check + WARN? (if we are trying to propagate
> this slowly across HW).
Would intel_plane_atomic_check_with_state be a more appropriate
place to check that the src width and height are at least 1? This is
where skl_plane_check and other HW's foo_plane_check functions are called
from.
I don't think that the potential divide-by-zero will be hit in the case
where intel_adjusted_rate is called from ilk_pipe_pixel_rate because the
src rect will not have a fractional part to it in this case. I'm assuming
that something earlier on would catch and reject a src with zero
width/height.
Drew
>
>
> ...alan
>
> On Mon, 2022-12-26 at 22:53 -0700, Drew Davenport wrote:
> > The error message suggests that the height of the src rect must be at
> > least 1. Reject source with height of 0.
> >
> > Signed-off-by: Drew Davenport
> >
> > ---
> > I was investigating some divide-by-zero crash reports on ChromeOS which
> > pointed to the intel_adjusted_rate function. Further prodding showed
> > that I could reproduce this in a simple test program if I made src_h
> > some value less than 1 but greater than 0.
> >
> > This seemed to be a sensible place to check that the source height is at
> > least 1. I tried to repro this issue on an amd device I had on hand, and
> > the configuration was rejected.
> >
> > Would it make sense to add a check that source dimensions are at least 1
> > somewhere in core, like in drm_atomic_plane_check? Or is that a valid
> > use case on some devices, and thus any such check should be done on a
> > per-driver basis?
> >
> > Thanks.
> >
> > drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index 4b79c2d2d6177..9b172a1e90deb 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -1627,7 +1627,7 @@ static int skl_check_main_surface(struct
> > intel_plane_state *plane_state)
> > u32 offset;
> > int ret;
> >
> > - if (w > max_width || w < min_width || h > max_height) {
> > + if (w > max_width || w < min_width || h > max_height || h < 1) {
> > drm_dbg_kms(_priv->drm,
> > "requested Y/RGB source size %dx%d outside limits
> > (min: %dx1 max: %dx%d)\n",
> > w, h, min_width, max_width, max_height);
> > --
> > 2.39.0.314.g84b9a713c41-goog
> >
>
Re: [Intel-gfx] [PATCH] drm/i915/display: assume some pixelrate for src smaller than 1
On Wed, Jan 11, 2023 at 04:19:00PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 04, 2023 at 02:44:48PM +0200, Juha-Pekka Heikkila wrote:
> > intel_adjusted_rate() didn't take into account src rectangle
> > can be less than 1 in width or height.
>
> This should not get called in those cases. What does the
> backtrace look like?
In my repro of this issue, the backtrace looks as follows:
[ 180.798331] RIP: 0010:intel_plane_pixel_rate+0x4a/0x53
[ 180.798336] Code:
[ 180.798338] RSP: 0018:b080ce4179b8 EFLAGS: 00010246
[ 180.798341] RAX: RBX: 98cd22a24000 RCX: 0a00
[ 180.798343] RDX: RSI: 98cccbae7000 RDI:
[ 180.798346] RBP: b080ce4179b8 R08: 00087780 R09: 0002
[ 180.798348] R10: 0a00 R11: R12:
[ 180.798350] R13: 98cd0e495400 R14: 98ccc34e R15: 98cccbae7000
[ 180.798352] FS: 7b84119b5000() GS:98d02f90()
knlGS:
[ 180.798354] CS: 0010 DS: ES: CR0: 80050033
[ 180.798357] CR2: 7ffc2d5e4080 CR3: 0001042ee006 CR4: 00770ee0
[ 180.798359] PKRU: 5554
[ 180.798361] Call Trace:
[ 180.798364]
[ 180.798366] intel_plane_atomic_check_with_state+0x1fd/0x6ea
[ 180.798370] ? intel_plane_atomic_check+0x11b/0x145
[ 180.798373] intel_atomic_check_planes+0x263/0x7ce
[ 180.798376] ? drm_atomic_helper_check_modeset+0x189/0x923
[ 180.798380] intel_atomic_check+0x14e4/0x184d
[ 180.798382] ? intel_rps_mark_interactive+0x23/0x6a
[ 180.798386] drm_atomic_check_only+0x3ec/0x98f
[ 180.798391] drm_atomic_commit+0xa2/0x105
[ 180.798394] ? drm_atomic_set_fb_for_plane+0x96/0xa5
[ 180.798397] drm_atomic_helper_update_plane+0xdc/0x11f
[ 180.798400] drm_mode_setplane+0x236/0x30c
[ 180.798404] ? drm_any_plane_has_format+0x51/0x51
[ 180.798407] drm_ioctl_kernel+0xda/0x14d
[ 180.798411] drm_ioctl+0x27e/0x3b4
[ 180.798414] ? drm_any_plane_has_format+0x51/0x51
[ 180.798418] __se_sys_ioctl+0x7a/0xbc
[ 180.798421] do_syscall_64+0x55/0x9d
[ 180.798424] ? exit_to_user_mode_prepare+0x3c/0x8b
[ 180.798427] entry_SYSCALL_64_after_hwframe+0x61/0xcb
If this function shouldn't be called in such a case, then perhaps
I should revist my original attempt at fixing this in
https://patchwork.freedesktop.org/patch/516060 by rejecting such a
configuration?
I'll respond to Alan on that thread.
>
> >
> > Signed-off-by: Juha-Pekka Heikkila
> > ---
> > drivers/gpu/drm/i915/display/intel_atomic_plane.c | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > index 10e1fc9d0698..a9948e8d3543 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > @@ -144,7 +144,7 @@ unsigned int intel_adjusted_rate(const struct drm_rect
> > *src,
> > const struct drm_rect *dst,
> > unsigned int rate)
> > {
> > - unsigned int src_w, src_h, dst_w, dst_h;
> > + unsigned int src_w, src_h, dst_w, dst_h, dst_wh;
> >
> > src_w = drm_rect_width(src) >> 16;
> > src_h = drm_rect_height(src) >> 16;
> > @@ -155,8 +155,10 @@ unsigned int intel_adjusted_rate(const struct drm_rect
> > *src,
> > dst_w = min(src_w, dst_w);
> > dst_h = min(src_h, dst_h);
> >
> > - return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h),
> > - dst_w * dst_h);
> > + /* in case src contained only fractional part */
> > + dst_wh = max(dst_w * dst_h, (unsigned) 1);
> > +
> > + return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h), dst_wh);
> > }
> >
> > unsigned int intel_plane_pixel_rate(const struct intel_crtc_state
> > *crtc_state,
> > --
> > 2.37.3
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/pxp: Add MTL PXP Support
Forgot to test with .config PXP set to off - will re-rev On Wed, 2023-01-11 at 01:32 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/pxp: Add MTL PXP Support > URL : https://patchwork.freedesktop.org/series/112647/ > State : failure > > == Summary == > > Error: make failed > CALL scripts/checksyscalls.sh > DESCEND objtool > CC [M] drivers/gpu/drm/i915/gt/intel_gt_irq.o > In file included from drivers/gpu/drm/i915/gt/intel_gt_irq.c:16: > ./drivers/gpu/drm/i915/pxp/intel_pxp_irq.h:42:21: error: expected > ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘intel_pxp_get_irq_gt’ > 42 | struct intel_gt *gt intel_pxp_get_irq_gt(struct intel_pxp > *pxp) > | ^~~~ > make[5]: *** [scripts/Makefile.build:252: > drivers/gpu/drm/i915/gt/intel_gt_irq.o] Error 1 > make[4]: *** [scripts/Makefile.build:504: drivers/gpu/drm/i915] Error > 2 > make[3]: *** [scripts/Makefile.build:504: drivers/gpu/drm] Error 2 > make[2]: *** [scripts/Makefile.build:504: drivers/gpu] Error 2 > make[1]: *** [scripts/Makefile.build:504: drivers] Error 2 > make: *** [Makefile:2008: .] Error 2 > >
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Wed, Jan 11, 2023 at 09:17:01AM +, Tvrtko Ursulin wrote:
>
> On 10/01/2023 19:01, Matthew Brost wrote:
> > On Tue, Jan 10, 2023 at 04:50:55PM +, Tvrtko Ursulin wrote:
> > >
> > > On 10/01/2023 15:55, Matthew Brost wrote:
> > > > On Tue, Jan 10, 2023 at 12:19:35PM +, Tvrtko Ursulin wrote:
> > > > >
> > > > > On 10/01/2023 11:28, Tvrtko Ursulin wrote:
> > > > > >
> > > > > >
> > > > > > On 09/01/2023 17:27, Jason Ekstrand wrote:
> > > > > >
> > > > > > [snip]
> > > > > >
> > > > > > > >>> AFAICT it proposes to have 1:1 between *userspace*
> > > > > > > created
> > > > > > > contexts (per
> > > > > > > >>> context _and_ engine) and drm_sched. I am not sure
> > > > > > > avoiding
> > > > > > > invasive changes
> > > > > > > >>> to the shared code is in the spirit of the overall
> > > > > > > idea and
> > > > > > > instead
> > > > > > > >>> opportunity should be used to look at way to
> > > > > > > refactor/improve
> > > > > > > drm_sched.
> > > > > > >
> > > > > > >
> > > > > > > Maybe? I'm not convinced that what Xe is doing is an abuse at all
> > > > > > > or really needs to drive a re-factor. (More on that later.)
> > > > > > > There's only one real issue which is that it fires off
> > > > > > > potentially a
> > > > > > > lot of kthreads. Even that's not that bad given that kthreads are
> > > > > > > pretty light and you're not likely to have more kthreads than
> > > > > > > userspace threads which are much heavier. Not ideal, but not the
> > > > > > > end of the world either. Definitely something we can/should
> > > > > > > optimize but if we went through with Xe without this patch, it
> > > > > > > would
> > > > > > > probably be mostly ok.
> > > > > > >
> > > > > > > >> Yes, it is 1:1 *userspace* engines and drm_sched.
> > > > > > > >>
> > > > > > > >> I'm not really prepared to make large changes to DRM
> > > > > > > scheduler
> > > > > > > at the
> > > > > > > >> moment for Xe as they are not really required nor does
> > > > > > > Boris
> > > > > > > seem they
> > > > > > > >> will be required for his work either. I am interested
> > > > > > > to see
> > > > > > > what Boris
> > > > > > > >> comes up with.
> > > > > > > >>
> > > > > > > >>> Even on the low level, the idea to replace drm_sched
> > > > > > > threads
> > > > > > > with workers
> > > > > > > >>> has a few problems.
> > > > > > > >>>
> > > > > > > >>> To start with, the pattern of:
> > > > > > > >>>
> > > > > > > >>> while (not_stopped) {
> > > > > > > >>> keep picking jobs
> > > > > > > >>> }
> > > > > > > >>>
> > > > > > > >>> Feels fundamentally in disagreement with workers (while
> > > > > > > obviously fits
> > > > > > > >>> perfectly with the current kthread design).
> > > > > > > >>
> > > > > > > >> The while loop breaks and worker exists if no jobs are
> > > > > > > ready.
> > > > > > >
> > > > > > >
> > > > > > > I'm not very familiar with workqueues. What are you saying would
> > > > > > > fit
> > > > > > > better? One scheduling job per work item rather than one big work
> > > > > > > item which handles all available jobs?
> > > > > >
> > > > > > Yes and no, it indeed IMO does not fit to have a work item which is
> > > > > > potentially unbound in runtime. But it is a bit moot conceptual
> > > > > > mismatch
> > > > > > because it is a worst case / theoretical, and I think due more
> > > > > > fundamental concerns.
> > > > > >
> > > > > > If we have to go back to the low level side of things, I've picked
> > > > > > this
> > > > > > random spot to consolidate what I have already mentioned and perhaps
> > > > > > expand.
> > > > > >
> > > > > > To start with, let me pull out some thoughts from workqueue.rst:
> > > > > >
> > > > > > """
> > > > > > Generally, work items are not expected to hog a CPU and consume many
> > > > > > cycles. That means maintaining just enough concurrency to prevent
> > > > > > work
> > > > > > processing from stalling should be optimal.
> > > > > > """
> > > > > >
> > > > > > For unbound queues:
> > > > > > """
> > > > > > The responsibility of regulating concurrency level is on the users.
> > > > > > """
> > > > > >
> > > > > > Given the unbound queues will be spawned on demand to service all
> > > > > > queued
> > > > > > work items (more interesting when mixing up with the
> > > > > > system_unbound_wq),
> > > > > > in the proposed design the number of instantiated worker threads
> > > > > > does
> > > > > > not correspond to the number of user threads (as you have elsewhere
> > > > > > stated), but pessimistically to the number of active user contexts.
> > > > > > That
> > > > > > is the number which drives the maximum number of not-runnable jobs
> > > > > > that
> > > > > > can become runnable at once, and hence spawn
Re: [Intel-gfx] [PATCH 03/27] drm/i915/gvt: Incorporate KVM memslot info into check for 2MiB GTT entry
On Mon, Jan 09, 2023, Yan Zhao wrote:
> On Fri, Jan 06, 2023 at 11:01:53PM +, Sean Christopherson wrote:
> > On Fri, Jan 06, 2023, Yan Zhao wrote:
> > > On Thu, Jan 05, 2023 at 05:40:32PM +, Sean Christopherson wrote:
> > > > On Thu, Jan 05, 2023, Yan Zhao wrote:
> > > > I'm totally fine if KVMGT's ABI is that VFIO is the source of truth for
> > > > mappings
> > > > and permissions, and that the only requirement for KVM memslots is that
> > > > GTT page
> > > > tables need to be visible in KVM's memslots. But if that's the ABI,
> > > > then
> > > > intel_gvt_is_valid_gfn() should be probing VFIO, not KVM (commit
> > > > cc753fbe1ac4
> > > > ("drm/i915/gvt: validate gfn before set shadow page entry").
> > > >
> > > > In other words, pick either VFIO or KVM. Checking that X is valid
> > > > according to
> > > > KVM and then mapping X through VFIO is confusing and makes assumptions
> > > > about how
> > > > userspace configures KVM and VFIO. It works because QEMU always
> > > > configures KVM
> > > > and VFIO as expected, but IMO it's unnecessarily fragile and again
> > > > confusing for
> > > > unaware readers because the code is technically flawed.
> > > >
> > > Agreed.
> > > Then after some further thought, I think maybe we can just remove
> > > intel_gvt_is_valid_gfn() in KVMGT, because
> > >
> > > (1) both intel_gvt_is_valid_gfn() in emulate_ggtt_mmio_write() and
> > > ppgtt_populate_spt() are not for page track purpose, but to validate bogus
> > > GFN.
> > > (2) gvt_pin_guest_page() with gfn and size can do the validity checking,
> > > which is called in intel_gvt_dma_map_guest_page(). So, we can move the
> > > mapping of scratch page to the error path after
> > > intel_gvt_dma_map_guest_page().
> >
> > IIUC, that will re-introduce the problem commit cc753fbe1ac4
> > ("drm/i915/gvt: validate
> > gfn before set shadow page entry") solved by poking into KVM. Lack of
> > pre-validation
> > means that bogus GFNs will trigger error messages, e.g.
> >
> > gvt_vgpu_err("vfio_pin_pages failed for iova %pad, ret
> > %d\n",
> > _iova, ret);
> >
> > and
> >
> > gvt_vgpu_err("fail to populate guest ggtt entry\n");
>
> Thanks for pointing it out.
> I checked this commit message and found below original intentions to introduce
> pre-validation:
...
> (I actually found that the original code will print "invalid entry type"
> warning which indicates it's broken for a while due to lack of test in
> this invalid gfn path)
>
>
> > One thought would be to turn those printks into tracepoints to eliminate
> > unwanted
> > noise, and to prevent the guest from spamming the host kernel log by
> > programming
> > garbage into the GTT (gvt_vgpu_err() isn't ratelimited).
> As those printks would not happen in normal conditions and printks may have
> some advantages to discover the attack or bug, could we just convert
> gvt_vgpu_err() to be ratelimited ?
That's ultimately a decision that needs to be made by the GVT maintainers, as
the
answer depends on the use case. E.g. if most users of KVMGT run a single VM and
the guest user is also the host admin, then pr_err_ratelimited() is likely an
acceptable/preferable choice as there's a decent chance a human will see the
errors
in the host kernel logs and be able to take action.
But if there's unlikely to be a human monitoring the host logs, and/or the guest
user is unrelated to the host admin, then a ratelimited printk() is less useful.
E.g. if there's no one monitoring the logs, then losing messages due to
ratelimiting provides a worse debug experience overall than having to manually
enable tracepoints. And if there may be many tens of VMs (seems unlikely?),
then
ratelimited printk() is even less useful because errors for a specific VM may be
lost, i.e. the printk() can't be relied upon in any way to detect issues.
FWIW, in KVM proper, use of printk() to capture guest "errors" is strongly
discourage
for exactly these reasons.
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Wed, Jan 11, 2023 at 09:09:45AM +, Tvrtko Ursulin wrote:
>
> On 11/01/2023 01:13, Matthew Brost wrote:
> > On Tue, Jan 10, 2023 at 04:39:00PM +, Matthew Brost wrote:
> > > On Tue, Jan 10, 2023 at 11:28:08AM +, Tvrtko Ursulin wrote:
> > > >
> > > >
> > > > On 09/01/2023 17:27, Jason Ekstrand wrote:
> > > >
> > > > [snip]
> > > >
> > > > > >>> AFAICT it proposes to have 1:1 between *userspace* created
> > > > > contexts (per
> > > > > >>> context _and_ engine) and drm_sched. I am not sure avoiding
> > > > > invasive changes
> > > > > >>> to the shared code is in the spirit of the overall idea and
> > > > > instead
> > > > > >>> opportunity should be used to look at way to
> > > > > refactor/improve
> > > > > drm_sched.
> > > > >
> > > > >
> > > > > Maybe? I'm not convinced that what Xe is doing is an abuse at all or
> > > > > really needs to drive a re-factor. (More on that later.) There's
> > > > > only
> > > > > one real issue which is that it fires off potentially a lot of
> > > > > kthreads.
> > > > > Even that's not that bad given that kthreads are pretty light and
> > > > > you're
> > > > > not likely to have more kthreads than userspace threads which are much
> > > > > heavier. Not ideal, but not the end of the world either. Definitely
> > > > > something we can/should optimize but if we went through with Xe
> > > > > without
> > > > > this patch, it would probably be mostly ok.
> > > > >
> > > > > >> Yes, it is 1:1 *userspace* engines and drm_sched.
> > > > > >>
> > > > > >> I'm not really prepared to make large changes to DRM
> > > > > scheduler
> > > > > at the
> > > > > >> moment for Xe as they are not really required nor does Boris
> > > > > seem they
> > > > > >> will be required for his work either. I am interested to see
> > > > > what Boris
> > > > > >> comes up with.
> > > > > >>
> > > > > >>> Even on the low level, the idea to replace drm_sched threads
> > > > > with workers
> > > > > >>> has a few problems.
> > > > > >>>
> > > > > >>> To start with, the pattern of:
> > > > > >>>
> > > > > >>> while (not_stopped) {
> > > > > >>> keep picking jobs
> > > > > >>> }
> > > > > >>>
> > > > > >>> Feels fundamentally in disagreement with workers (while
> > > > > obviously fits
> > > > > >>> perfectly with the current kthread design).
> > > > > >>
> > > > > >> The while loop breaks and worker exists if no jobs are ready.
> > > > >
> > > > >
> > > > > I'm not very familiar with workqueues. What are you saying would fit
> > > > > better? One scheduling job per work item rather than one big work item
> > > > > which handles all available jobs?
> > > >
> > > > Yes and no, it indeed IMO does not fit to have a work item which is
> > > > potentially unbound in runtime. But it is a bit moot conceptual mismatch
> > > > because it is a worst case / theoretical, and I think due more
> > > > fundamental
> > > > concerns.
> > > >
> > > > If we have to go back to the low level side of things, I've picked this
> > > > random spot to consolidate what I have already mentioned and perhaps
> > > > expand.
> > > >
> > > > To start with, let me pull out some thoughts from workqueue.rst:
> > > >
> > > > """
> > > > Generally, work items are not expected to hog a CPU and consume many
> > > > cycles.
> > > > That means maintaining just enough concurrency to prevent work
> > > > processing
> > > > from stalling should be optimal.
> > > > """
> > > >
> > > > For unbound queues:
> > > > """
> > > > The responsibility of regulating concurrency level is on the users.
> > > > """
> > > >
> > > > Given the unbound queues will be spawned on demand to service all queued
> > > > work items (more interesting when mixing up with the
> > > > system_unbound_wq), in
> > > > the proposed design the number of instantiated worker threads does not
> > > > correspond to the number of user threads (as you have elsewhere
> > > > stated), but
> > > > pessimistically to the number of active user contexts. That is the
> > > > number
> > > > which drives the maximum number of not-runnable jobs that can become
> > > > runnable at once, and hence spawn that many work items, and in turn
> > > > unbound
> > > > worker threads.
> > > >
> > > > Several problems there.
> > > >
> > > > It is fundamentally pointless to have potentially that many more threads
> > > > than the number of CPU cores - it simply creates a scheduling storm.
> > > >
> > >
> > > We can use a different work queue if this is an issue, have a FIXME
> > > which indicates we should allow the user to pass in the work queue.
> > >
> > > > Unbound workers have no CPU / cache locality either and no connection
> > > > with
> > > > the CPU scheduler to optimize scheduling patterns. This may matter
> > > > either on
> > > > large systems or on
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: implement async_flip mode per plane tracking (rev2)
== Series Details ==
Series: drm/i915: implement async_flip mode per plane tracking (rev2)
URL : https://patchwork.freedesktop.org/series/108371/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12573 -> Patchwork_108371v2
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_108371v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_108371v2, 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_108371v2/index.html
Participating hosts (34 -> 33)
--
Additional (1): fi-kbl-soraka
Missing(2): fi-rkl-11600 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108371v2:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@guc:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v2/fi-kbl-soraka/igt@i915_selftest@l...@guc.html
Known issues
Here are the changes found in Patchwork_108371v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][4] ([i915#5334])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v2/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][5] ([i915#1886])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271]) +15 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v2/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-rkl-guc: NOTRUN -> [SKIP][7] ([i915#7828])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v2/fi-rkl-guc/igt@kms_chamelium_...@common-hpd-after-suspend.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [INCOMPLETE][8] ([i915#4983]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12573/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v2/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@migrate:
- {bat-atsm-1}: [DMESG-FAIL][10] ([i915#7699]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12573/bat-atsm-1/igt@i915_selftest@l...@migrate.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v2/bat-atsm-1/igt@i915_selftest@l...@migrate.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
Build changes
-
* Linux: CI_DRM_12573 -> Patchwork_108371v2
CI-20190529: 20190529
CI_DRM_12573: 05a39ecbd04e67fb2617819fc138eca0ac61 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7116: 79eb8984acd309108be713a8831e60667db67e21 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_108371v2: 05a39ecbd04e67fb2617819fc138eca0ac61 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
01304089b052 drm/i915: implement async_flip mode per plane tracking
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v2/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: implement async_flip mode per plane tracking (rev2)
== Series Details == Series: drm/i915: implement async_flip mode per plane tracking (rev2) URL : https://patchwork.freedesktop.org/series/108371/ State : warning == Summary == Error: dim checkpatch failed a083ebdf19ad drm/i915: implement async_flip mode per plane tracking -:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #14: DMAR: [DMA Read NO_PASID] Request device [00:02.0] fault addr 0x0 [fault reason 0x06] PTE Read access is not set total: 0 errors, 1 warnings, 0 checks, 52 lines checked
Re: [Intel-gfx] [PATCH] drm/i915/pcode: Wait 10 seconds for pcode to settle
On Wed, Jan 11, 2023 at 04:39:36PM +0100, Andi Shyti wrote:
> Hi Rodrigo,
>
> On Wed, Jan 11, 2023 at 10:25:56AM -0500, Rodrigo Vivi wrote:
> > On Wed, Jan 11, 2023 at 11:44:47AM +0100, Andi Shyti wrote:
> > > From: Aravind Iddamsetty
> > >
> > > During module load not all the punit transaction have completed
> > > and we might end up timing out, as shown by the following
> > > warning:
> > >
> > >i915 :4d:00.0: drm_WARN_ON_ONCE(timeout_base_ms > 3)
> > >
> > > Wait 10 seconds for the punit to settle and complete any
> > > outstanding transactions upon module load.
> >
> > 10 *SECONDS* ?!
>
> Don't be alarmed :)
>
> It's up to 10 seconds, otherwise we would end up waiting up to 3
> minutes.
>
> And I've seen a version (and you did as well) where those 3
> minutes were raised to 6 (for the PVC particular case).
Oh yeap! and that case is funny! Because the indication from PCODE
is that 10 seconds is enough, but there are some rare cases where
it gets stuck and end up taking a very long time. Then they multiplied
the bad rare case to 3, and no idea why how that become 6.
But anyway, thanks for refreshing my memory. When I first noticed this
patch I thought it was in all the platforms, where this wouldn't make
sense. But on discrete where the pcode needs to bring the memory and
gt up before we can really use it, it makes sense.
And then I noticed that your patch is indeed for dgfx only, so it
would be okay. And 10 seconds is okay.
However I also noticed that you do this before the other pcode_init
check that we were told by pcode folks to use. So, I don't understand
how your patch is helping now... you wait for 10 seconds and then you
will wait more 10 seconds on the pcode_ready... why the pcode_ready
check that we have in case already doesn't cover yours?
And why that return?
>
> Thanks for checking this,
> Andi
>
> > >
> > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7814
> > >
> > > Signed-off-by: Aravind Iddamsetty
> > > Co-developed-by: Chris Wilson
> > > Cc: Rodrigo Vivi
> > > Signed-off-by: Andi Shyti
> > > ---
> > > drivers/gpu/drm/i915/intel_pcode.c | 35 ++
> > > 1 file changed, 31 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_pcode.c
> > > b/drivers/gpu/drm/i915/intel_pcode.c
> > > index a234d9b4ed14..3db2ba439bb5 100644
> > > --- a/drivers/gpu/drm/i915/intel_pcode.c
> > > +++ b/drivers/gpu/drm/i915/intel_pcode.c
> > > @@ -204,15 +204,42 @@ int skl_pcode_request(struct intel_uncore *uncore,
> > > u32 mbox, u32 request,
> > > #undef COND
> > > }
> > >
> > > +static int pcode_init_wait(struct intel_uncore *uncore, int timeout_ms)
> > > +{
> > > + if (__intel_wait_for_register_fw(uncore,
> > > + GEN6_PCODE_MAILBOX,
> > > + GEN6_PCODE_READY, 0,
> > > + 500, timeout_ms,
> > > + NULL))
> > > + return -EPROBE_DEFER;
> > > +
> > > + return skl_pcode_request(uncore,
> > > + DG1_PCODE_STATUS,
> > > + DG1_UNCORE_GET_INIT_STATUS,
> > > + DG1_UNCORE_INIT_STATUS_COMPLETE,
> > > + DG1_UNCORE_INIT_STATUS_COMPLETE, timeout_ms);
> > > +}
> > > +
> > > int intel_pcode_init(struct intel_uncore *uncore)
> > > {
> > > + int err;
> > > +
> > > if (!IS_DGFX(uncore->i915))
> > > return 0;
> > >
> > > - return skl_pcode_request(uncore, DG1_PCODE_STATUS,
> > > - DG1_UNCORE_GET_INIT_STATUS,
> > > - DG1_UNCORE_INIT_STATUS_COMPLETE,
> > > - DG1_UNCORE_INIT_STATUS_COMPLETE, 18);
> > > + /*
> > > + * Wait 10 seconds so that the punit to settle and complete
> > > + * any outstanding transactions upon module load
> > > + */
> > > + err = pcode_init_wait(uncore, 1);
> > > +
> > > + if (err) {
> > > + drm_notice(>i915->drm,
> > > +"Waiting for HW initialisation...\n");
> > > + err = pcode_init_wait(uncore, 18);
> > > + }
> > > +
> > > + return err;
> > > }
> > >
> > > int snb_pcode_read_p(struct intel_uncore *uncore, u32 mbcmd, u32 p1, u32
> > > p2, u32 *val)
> > > --
> > > 2.34.1
> > >
Re: [Intel-gfx] [PATCH 01/11] drm/ast: Use drm_aperture_remove_conflicting_pci_framebuffers
On Wed, Jan 11, 2023 at 04:48:39PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.01.23 um 16:41 schrieb Daniel Vetter:
> > It's just open coded and matches.
> >
> > Note that Thomas said that his version apparently failed for some
> > reason, but hey maybe we should try again.
>
> I'll give this patch a test tomorrow.
Thanks a lot!
-Daniel
>
> Best regards
> Thomas
>
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Dave Airlie
> > Cc: Thomas Zimmermann
> > Cc: Javier Martinez Canillas
> > Cc: Helge Deller
> > Cc: linux-fb...@vger.kernel.org
> > ---
> > drivers/gpu/drm/ast/ast_drv.c | 16 +---
> > 1 file changed, 1 insertion(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
> > index 420fc75c240e..3ac24a780f50 100644
> > --- a/drivers/gpu/drm/ast/ast_drv.c
> > +++ b/drivers/gpu/drm/ast/ast_drv.c
> > @@ -90,27 +90,13 @@ static const struct pci_device_id ast_pciidlist[] = {
> > MODULE_DEVICE_TABLE(pci, ast_pciidlist);
> > -static int ast_remove_conflicting_framebuffers(struct pci_dev *pdev)
> > -{
> > - bool primary = false;
> > - resource_size_t base, size;
> > -
> > - base = pci_resource_start(pdev, 0);
> > - size = pci_resource_len(pdev, 0);
> > -#ifdef CONFIG_X86
> > - primary = pdev->resource[PCI_ROM_RESOURCE].flags &
> > IORESOURCE_ROM_SHADOW;
> > -#endif
> > -
> > - return drm_aperture_remove_conflicting_framebuffers(base, size,
> > primary, _driver);
> > -}
> > -
> > static int ast_pci_probe(struct pci_dev *pdev, const struct pci_device_id
> > *ent)
> > {
> > struct ast_private *ast;
> > struct drm_device *dev;
> > int ret;
> > - ret = ast_remove_conflicting_framebuffers(pdev);
> > + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev,
> > _driver);
> > if (ret)
> > return ret;
>
> --
> 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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoid full proxy f_ops debug attributes (rev2)
== Series Details ==
Series: drm/i915: Avoid full proxy f_ops debug attributes (rev2)
URL : https://patchwork.freedesktop.org/series/112625/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12573 -> Patchwork_112625v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/index.html
Participating hosts (34 -> 34)
--
Additional (1): fi-bsw-kefka
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_112625v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[PASS][1] -> [FAIL][2] ([i915#7229])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12573/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@prime_vgem@basic-fence-flip:
- fi-bsw-kefka: NOTRUN -> [SKIP][3] ([fdo#109271]) +26 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@i915_selftest@live@migrate:
- {bat-atsm-1}: [DMESG-FAIL][4] ([i915#7699]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12573/bat-atsm-1/igt@i915_selftest@l...@migrate.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/bat-atsm-1/igt@i915_selftest@l...@migrate.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
Build changes
-
* Linux: CI_DRM_12573 -> Patchwork_112625v2
CI-20190529: 20190529
CI_DRM_12573: 05a39ecbd04e67fb2617819fc138eca0ac61 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7116: 79eb8984acd309108be713a8831e60667db67e21 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_112625v2: 05a39ecbd04e67fb2617819fc138eca0ac61 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
7893926ce485 drm/i915/fbc: Avoid full proxy f_ops for FBC debug attributes
ad8f48a488ad drm/i915/display: Avoid full proxy f_ops for DRRS debug attributes
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v2/index.html
Re: [Intel-gfx] [PATCH 11/11] video/aperture: Only remove sysfb on the default vga pci device
Hello Daniel,
On 1/11/23 16:41, Daniel Vetter wrote:
> This fixes a regression introduced by ee7a69aa38d8 ("fbdev: Disable
> sysfb device registration when removing conflicting FBs"), where we
> remove the sysfb when loading a driver for an unrelated pci device,
> resulting in the user loosing their efifb console or similar.
>
> Note that in practice this only is a problem with the nvidia blob,
> because that's the only gpu driver people might install which does not
> come with an fbdev driver of it's own. For everyone else the real gpu
> driver will restor a working console.
restore
>
> Also note that in the referenced bug there's confusion that this same
> bug also happens on amdgpu. But that was just another amdgpu specific
> regression, which just happened to happen at roughly the same time and
> with the same user-observable symptons. That bug is fixed now, see
symptoms
> https://bugzilla.kernel.org/show_bug.cgi?id=216331#c15
>
> For the above reasons the cc: stable is just notionally, this patch
> will need a backport and that's up to nvidia if they care enough.
>
Maybe adding a Fixes: ee7a69aa38d8 tag here too ?
> References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28
> Signed-off-by: Daniel Vetter
> Cc: Aaron Plattner
> Cc: Javier Martinez Canillas
> Cc: Thomas Zimmermann
> Cc: Helge Deller
> Cc: Sam Ravnborg
> Cc: Alex Deucher
> Cc: # v5.19+ (if someone else does the backport)
> ---
> drivers/video/aperture.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
> index ba565515480d..a1821d369bb1 100644
> --- a/drivers/video/aperture.c
> +++ b/drivers/video/aperture.c
> @@ -321,15 +321,16 @@ int aperture_remove_conflicting_pci_devices(struct
> pci_dev *pdev, const char *na
>
> primary = pdev == vga_default_device();
>
> + if (primary)
> + sysfb_disable();
> +
> for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
> if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
> continue;
>
> base = pci_resource_start(pdev, bar);
> size = pci_resource_len(pdev, bar);
> - ret = aperture_remove_conflicting_devices(base, size, name);
> - if (ret)
> - return ret;
> + aperture_detach_devices(base, size);
Maybe mention in the commit message that you are doing this change, something
like:
"Instead of calling aperture_remove_conflicting_devices() to remove the
conflicting
devices, just call to aperture_detach_devices() to detach the device that
matches
the same PCI BAR / aperture range. Since the former is just a wrapper of the
latter
plus a sysfb_disable() call, and now that's done in this function but only for
the
primary devices"
Patch looks good to me:
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [Intel-gfx] [PATCH 05/11] video/aperture: Only kick vgacon when the pdev is decoding vga
On Wed, Jan 11, 2023 at 05:03:02PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.01.23 um 16:41 schrieb Daniel Vetter:
> > Otherwise it's bit silly, and we might throw out the driver for the
> > screen the user is actually looking at. I haven't found a bug report
> > for this case yet, but we did get bug reports for the analog case
> > where we're throwing out the efifb driver.
> >
> > References: https://bugzilla.kernel.org/show_bug.cgi?id=216303
> > Signed-off-by: Daniel Vetter
> > Cc: Thomas Zimmermann
> > Cc: Javier Martinez Canillas
> > Cc: Helge Deller
> > Cc: linux-fb...@vger.kernel.org
> > ---
> > drivers/video/aperture.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
> > index 3d8c925c7365..6f351a58f6c6 100644
> > --- a/drivers/video/aperture.c
> > +++ b/drivers/video/aperture.c
> > @@ -341,6 +341,9 @@ int aperture_remove_conflicting_pci_devices(struct
> > pci_dev *pdev, const char *na
> > return ret;
> > }
> > + if (!primary)
> > + return 0;
> > +
>
> The original code from fbdev didn't do this, so this code didn't either.
>
> It appears more to be a special case than an early-out branch. So can we
> write it as
Yeah I think this was a mistake going way back to when I added this to
i915 originally. It is a real change, but also I guess the people who have
machines without efifb or vesafb are ... really not many :-) Iirc you had
some very funny kernels going way back when vgacon was considered the only
safe choice to even hit this stuff.
> if (primary) {
> // kick_vgacon
> }
Yeah, but next patch adds the vga aperture, and then I think it makes a
bit more sense.
-Daniel
>
> ?
>
> Best regards
> Thomas
>
> > /*
> > * WARNING: Apparently we must kick fbdev drivers before vgacon,
> > * otherwise the vga fbdev driver falls over.
>
> --
> 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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 04/11] video/aperture: use generic code to figure out the vga default device
On Wed, Jan 11, 2023 at 04:59:30PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.01.23 um 16:41 schrieb Daniel Vetter:
> > Since vgaarb has been promoted to be a core piece of the pci subsystem
> > we don't have to open code random guesses anymore, we actually know
> > this in a platform agnostic way, and there's no need for an x86
> > specific hack. See also 1d38fe6ee6a8 ("PCI/VGA: Move vgaarb to
> > drivers/pci")
> >
> > This should not result in any functional change, and the non-x86
> > multi-gpu pci systems are probably rare enough to not matter (I don't
> > know of any tbh). But it's a nice cleanup, so let's do it.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Thomas Zimmermann
> > Cc: Javier Martinez Canillas
> > Cc: Helge Deller
> > Cc: linux-fb...@vger.kernel.org
> > Cc: Bjorn Helgaas
> > Cc: linux-...@vger.kernel.org
> > ---
> > drivers/video/aperture.c | 6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c
> > index 41e77de1ea82..3d8c925c7365 100644
> > --- a/drivers/video/aperture.c
> > +++ b/drivers/video/aperture.c
> > @@ -324,13 +324,11 @@ EXPORT_SYMBOL(aperture_remove_conflicting_devices);
> >*/
> > int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const
> > char *name)
> > {
> > - bool primary = false;
> > + bool primary;
> > resource_size_t base, size;
> > int bar, ret;
> > -#ifdef CONFIG_X86
> > - primary = pdev->resource[PCI_ROM_RESOURCE].flags &
> > IORESOURCE_ROM_SHADOW;
> > -#endif
> > + primary = pdev == vga_default_device();
>
> vga_default_device() is part of vgaarb and can return NULL. [1] That new
> test is likely to be incorrect on many systems.
>
> I suggest to implement a helper like fb_is_primary_device() on x86: it uses
> the default VGA if set, or falls back to the original test. [2]
>
> It's noteworthy that on most architectures, fb_is_primary_device() returns
> 0. But at least on Sparc [3] and some Parisc [4] machines, it does not.
Afaik these neither do legacy vga nor sysfb, so we should be fine. I'll
augment the commit message.
> I've long wanted to rework this helper anyway. So this is a good
> opportunity.
Hm yeah that sounds like a good thing to copy. I'm honestly not sure
whether it's needed, but at least it shouldn't hurt. I thought at least
that the boot default device should be set on all pci architectures.
I'll also reorder this with the previous patch to avoid the compile fail.
-Daniel
>
> Best regards
> Thomas
>
> [1]
> https://elixir.bootlin.com/linux/latest/source/include/linux/vgaarb.h#L69
> [2]
> https://elixir.bootlin.com/linux/latest/source/arch/x86/video/fbdev.c#L14
> [3]
> https://elixir.bootlin.com/linux/latest/source/arch/sparc/include/asm/fb.h#L18
> [4]
> https://elixir.bootlin.com/linux/latest/source/drivers/video/console/sticore.c#L1153
>
>
> > for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
> > if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
>
> --
> 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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Avoid full proxy f_ops debug attributes (rev2)
== Series Details == Series: drm/i915: Avoid full proxy f_ops debug attributes (rev2) URL : https://patchwork.freedesktop.org/series/112625/ State : warning == Summary == Error: dim checkpatch failed 35a859d3f0a9 drm/i915/display: Avoid full proxy f_ops for DRRS debug attributes -:21: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #21: make coccicheck M=drivers/gpu/drm/i915/ MODE=patch COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci total: 0 errors, 1 warnings, 0 checks, 20 lines checked 736b7b4acf64 drm/i915/fbc: Avoid full proxy f_ops for FBC debug attributes -:20: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #20: make coccicheck M=drivers/gpu/drm/i915/ MODE=patch COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci total: 0 errors, 1 warnings, 0 checks, 24 lines checked
Re: [Intel-gfx] [PATCH 11/11] video/aperture: Only remove sysfb on the default vga pci device
On 1/11/23 17:20, Thomas Zimmermann wrote: [...] >> >> diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c >> index ba565515480d..a1821d369bb1 100644 >> --- a/drivers/video/aperture.c >> +++ b/drivers/video/aperture.c >> @@ -321,15 +321,16 @@ int aperture_remove_conflicting_pci_devices(struct >> pci_dev *pdev, const char *na >> >> primary = pdev == vga_default_device(); >> >> +if (primary) >> +sysfb_disable(); >> + > > There's another sysfb_disable() in aperture_remove_conflicting_devices() > without the branch but with a long comment. I find this slightly confusing. > > I'd rather add a branched sysfb_disable() plus the comment to > aperture_detach_devices(). And then add a 'primary' parameter to > aperture_detach_devices(). In aperture_remove_conflicting_devices() the > parameter would be unconditionally true. > Or just remove that long comment since there's already kernel-doc for the sysfb_disable() function definition. This feels to me that any approach to parameterize this will lead to code that is harder to read. Since is just a single function call, I would just duplicate like $subject does to be honest. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [Intel-gfx] [PATCH] drm/i915/pcode: Wait 10 seconds for pcode to settle
On Wed, 11 Jan 2023, Andi Shyti wrote:
> On Wed, Jan 11, 2023 at 03:18:38PM +0200, Jani Nikula wrote:
>> On Wed, 11 Jan 2023, Andi Shyti wrote:
>> > From: Aravind Iddamsetty
>> >
>> > During module load not all the punit transaction have completed
>> > and we might end up timing out, as shown by the following
>> > warning:
>>
>> Root cause?
>>
>> >
>> >i915 :4d:00.0: drm_WARN_ON_ONCE(timeout_base_ms > 3)
>> >
>> > Wait 10 seconds for the punit to settle and complete any
>> > outstanding transactions upon module load.
>> >
>> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7814
>> >
>>
>> No blank lines between the tag lines please.
>
> I don't consider "Closes:" to be a tag even if someone is using
> it as such. AFAIK is not mentioned it in any of the kernel docs
> (e.g. Documentation/process/maintainer-tip.rst).
Basically all of the Something: lines should be bundled together.
BR,
Jani.
>
> Not to confuse it with a normal tag, I wanted to put it in
> parenthesis or rephrase it.
>
>> > Signed-off-by: Aravind Iddamsetty
>> > Co-developed-by: Chris Wilson
>> > Cc: Rodrigo Vivi
>> > Signed-off-by: Andi Shyti
>> > ---
>> > drivers/gpu/drm/i915/intel_pcode.c | 35 ++
>> > 1 file changed, 31 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_pcode.c
>> > b/drivers/gpu/drm/i915/intel_pcode.c
>> > index a234d9b4ed14..3db2ba439bb5 100644
>> > --- a/drivers/gpu/drm/i915/intel_pcode.c
>> > +++ b/drivers/gpu/drm/i915/intel_pcode.c
>> > @@ -204,15 +204,42 @@ int skl_pcode_request(struct intel_uncore *uncore,
>> > u32 mbox, u32 request,
>> > #undef COND
>> > }
>> >
>> > +static int pcode_init_wait(struct intel_uncore *uncore, int timeout_ms)
>> > +{
>> > + if (__intel_wait_for_register_fw(uncore,
>> > + GEN6_PCODE_MAILBOX,
>> > + GEN6_PCODE_READY, 0,
>> > + 500, timeout_ms,
>> > + NULL))
>> > + return -EPROBE_DEFER;
>>
>> This is already done within skl_pcode_request -> skl_pcode_try_request
>> -> __snb_pcode_rw path, with waits in skl_pcode_request.
>
> the idea is to check for PCODE_READY even before checking if
> data are sent/received by pcode. And this is only during boot
> time. While skl_pcode_request is called in other contexts as
> well.
>
> In other words here I want to start the communication when I
> already know that the punit is ready. Otherwise I would hit an
> -EAGAIN and fail.
>
>> Is there anyone who still understands what's being waited for, where,
>> for how long, and why in the different code paths? I know I don't, and
>> this isn't helping.
>
> I think it depends on hardware. There are some documents roaming
> around with some boot time and reset time calculation.
>
>> There's also no explanation on the -EPROBE_DEFER return in the commit
>> message or comments or anywhere.
>
> we haven't really failed, right? We just need some time for the
> punit to be ready and try to probe again (remember we are here in
> module probe).
>
> Thanks for the review,
> Andi
>
>> Again, root cause?
>>
>> BR,
>> Jani.
>>
>>
>> > +
>> > + return skl_pcode_request(uncore,
>> > + DG1_PCODE_STATUS,
>> > + DG1_UNCORE_GET_INIT_STATUS,
>> > + DG1_UNCORE_INIT_STATUS_COMPLETE,
>> > + DG1_UNCORE_INIT_STATUS_COMPLETE, timeout_ms);
>> > +}
>> > +
>> > int intel_pcode_init(struct intel_uncore *uncore)
>> > {
>> > + int err;
>> > +
>> >if (!IS_DGFX(uncore->i915))
>> >return 0;
>> >
>> > - return skl_pcode_request(uncore, DG1_PCODE_STATUS,
>> > - DG1_UNCORE_GET_INIT_STATUS,
>> > - DG1_UNCORE_INIT_STATUS_COMPLETE,
>> > - DG1_UNCORE_INIT_STATUS_COMPLETE, 18);
>> > + /*
>> > + * Wait 10 seconds so that the punit to settle and complete
>> > + * any outstanding transactions upon module load
>> > + */
>> > + err = pcode_init_wait(uncore, 1);
>> > +
>> > + if (err) {
>> > + drm_notice(>i915->drm,
>> > + "Waiting for HW initialisation...\n");
>> > + err = pcode_init_wait(uncore, 18);
>> > + }
>> > +
>> > + return err;
>> > }
>> >
>> > int snb_pcode_read_p(struct intel_uncore *uncore, u32 mbcmd, u32 p1, u32
>> > p2, u32 *val)
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
