dri-devel September 2018

dri-devel@lists.freedesktop.org

276 participants
1899 discussions

[RFC] drm/amdgpu: Add macros and documentation for format modifiers.
by Bas Nieuwenhuizen 07 Sep '18

07 Sep '18

This is an initial proposal for format modifiers for AMD hardware. It uses 48 bits including a chip generation, leaving 8 bits for a format version number. On gfx6-gfx8 we have all the fields influencing sample locations in memory. Tile split bytes are optional for single sample buffers as no hardware reaches the split size with 1 sample and hence the actual size does not matter. The macrotile fields are duplicated for images with multiple planes. If the planes have different bitdepth they need different macro tile fields and different tile split bytes if multisample. I could not fit multiple copies in for tile split bytes, but multisample & multiplane images are very rare. Overall, I think we should punt on multisample for a later format version since they are generally not shared on any modifier aware windowing system, and we have more issues like fmask & cmask. We need these copies because the drm modifier of all planes in an image needs to be equal, so we need to fit these together. This adds fields for compression support, using metadata that is compatible with AMDVLK and for which radv and radeonsi can reasonably be extended. The big open question for compression is between which generations the format changed to see if we can share more. This explicitly does not try to solve the linear stride alignment issue, thoguh we could internally just use the tiling modes for the linear modes to indicate linear images with the stride for the given chip. Signed-off-by: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> CC: Chad Versace <chadversary(a)chromium.org> CC: Dave Airlie <airlied(a)redhat.com> CC: Marek Olšák <marek.olsak(a)amd.com> CC: Nicolai Hähnle <nicolai.haehnle(a)amd.com> CC: Alex Deucher <alexander.deucher(a)amd.com> CC: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- include/uapi/drm/amdgpu_drm.h | 130 ++++++++++++++++++++++++++++++++++ 1 file changed, 130 insertions(+) diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h index 94444eeba55b..4e1452161dbf 100644 --- a/include/uapi/drm/amdgpu_drm.h +++ b/include/uapi/drm/amdgpu_drm.h @@ -990,6 +990,136 @@ struct drm_amdgpu_info_vce_clock_table { #define AMDGPU_FAMILY_AI 141 /* Vega10 */ #define AMDGPU_FAMILY_RV 142 /* Raven */ +#define AMDGPU_CHIP_TAHITI 0 +#define AMDGPU_CHIP_PITCAIRN 1 +#define AMDGPU_CHIP_VERDE 2 +#define AMDGPU_CHIP_OLAND 3 +#define AMDGPU_CHIP_HAINAN 4 +#define AMDGPU_CHIP_BONAIRE 5 +#define AMDGPU_CHIP_KAVERI 6 +#define AMDGPU_CHIP_KABINI 7 +#define AMDGPU_CHIP_HAWAII 8 +#define AMDGPU_CHIP_MULLINS 9 +#define AMDGPU_CHIP_TOPAZ 10 +#define AMDGPU_CHIP_TONGA 11 +#define AMDGPU_CHIP_FIJI 12 +#define AMDGPU_CHIP_CARRIZO 13 +#define AMDGPU_CHIP_STONEY 14 +#define AMDGPU_CHIP_POLARIS10 15 +#define AMDGPU_CHIP_POLARIS11 16 +#define AMDGPU_CHIP_POLARIS12 17 +#define AMDGPU_CHIP_VEGAM 18 +#define AMDGPU_CHIP_VEGA10 19 +#define AMDGPU_CHIP_VEGA12 20 +#define AMDGPU_CHIP_VEGA20 21 +#define AMDGPU_CHIP_RAVEN 22 + +/* Format for GFX6-GFX8 DRM format modifiers. These are intentionally the same + * as AMDGPU_TILING_*. However, the the rules as to when to set them are + * different. + * + * Do not use linear ARRAY_MODEs or SWIZZLE_MODEs. Use DRM_FORMAT_MOD_LINEAR + * instead. + * + * If ARRAY_MODE is 1D, only the micro tile mode and the pipe config should be + * set. + * + * For other ARRAY_MODEs: + * - Only set TILE_SPLIT if the image is multisample. + * + * We have 1 extra bit for the micro tile mode, as GFX6 and GFX7+ have 1 + * different value there. The values are + * - depth : 0 + * - displayable : 1 + * - thin : 2 + * - thick (GFX6) : 3 + * - rotated (GFX7+) : 4 + * + * TODO: What to do with multisample multi plane images? More tile split + * fields don't fit if we want to keep a few bits for a format version. + */ +#define AMDGPU_MODIFIER_GFX8_ARRAY_MODE_SHIFT 0 +#define AMDGPU_MODIFIER_GFX8_ARRAY_MODE_MASK 0xf +#define AMDGPU_MODIFIER_GFX8_PIPE_CONFIG_SHIFT 4 +#define AMDGPU_MODIFIER_GFX8_PIPE_CONFIG_MASK 0x1f +#define AMDGPU_MODIFIER_GFX8_TILE_SPLIT_SHIFT 9 +#define AMDGPU_MODIFIER_GFX8_TILE_SPLIT_MASK 0x7 +#define AMDGPU_MODIFIER_GFX8_MICRO_TILE_MODE_SHIFT 12 +#define AMDGPU_MODIFIER_GFX8_MICRO_TILE_MODE_MASK 0x7 +#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_SHIFT 15 +#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_MASK 0x3 +#define AMDGPU_MODIFIER_GFX8_BANK_HEIGHT_SHIFT 17 +#define AMDGPU_MODIFIER_GFX8_BANK_HEIGHT_MASK 0x3 +#define AMDGPU_MODIFIER_GFX8_MACRO_TILE_ASPECT_SHIFT 19 +#define AMDGPU_MODIFIER_GFX8_MACRO_TILE_ASPECT_MASK 0x3 +#define AMDGPU_MODIFIER_GFX8_NUM_BANKS_SHIFT 21 +#define AMDGPU_MODIFIER_GFX8_NUM_BANKS_MASK 0x3 + +/* Macrotile parameters for a second plane if existing */ +#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_1_SHIFT 23 +#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_1_MASK 0x3 +#define AMDGPU_MODIFIER_GFX8_BANK_HEIGHT_1_SHIFT 25 +#define AMDGPU_MODIFIER_GFX8_BANK_HEIGHT_1_MASK 0x3 +#define AMDGPU_MODIFIER_GFX8_MACRO_TILE_ASPECT_1_SHIFT 27 +#define AMDGPU_MODIFIER_GFX8_MACRO_TILE_ASPECT_1_MASK 0x3 +#define AMDGPU_MODIFIER_GFX8_NUM_BANKS_1_SHIFT 29 +#define AMDGPU_MODIFIER_GFX8_NUM_BANKS_1_MASK 0x3 + +/* Macrotile parameters for a third plane if existing */ +#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_2_SHIFT 31 +#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_2_MASK 0x3 +#define AMDGPU_MODIFIER_GFX8_BANK_HEIGHT_2_SHIFT 33 +#define AMDGPU_MODIFIER_GFX8_BANK_HEIGHT_2_MASK 0x3 +#define AMDGPU_MODIFIER_GFX8_MACRO_TILE_ASPECT_2_SHIFT 35 +#define AMDGPU_MODIFIER_GFX8_MACRO_TILE_ASPECT_2_MASK 0x3 +#define AMDGPU_MODIFIER_GFX8_NUM_BANKS_2_SHIFT 37 +#define AMDGPU_MODIFIER_GFX8_NUM_BANKS_2_MASK 0x3 + +#define AMDGPU_MODIFIER_GFX9_SWIZZLE_MODE_SHIFT 0 +#define AMDGPU_MODIFIER_GFX9_SWIZZLE_MODE_MASK 0x1f + +/* Whether to enable DCC compression. + * + * If enabled, exporting the surface results in three + * planes: + * - color data + * - DCC data + * - a 64-byte block with + * - a 16 byte 0/1 bool as to whether the surface is currently DCC compressed. + * - a 16-byte 0/1 bool as to whether the surface has fastclear data + * - a 8-byte chunk with the current fastclear colors + * + * To ensure we do not keep compressing and decompressing the surface, once it + * has been decompressed no party may recompress again. + * + * Applications should not hand over images with fastclear data as not + * all users can support it, however, to help both Vulkan implementations + * with the allocation we keep it in the 64-byte block. + * + * TODO: Can scanout really not support fastclear data? + * TODO: What to do with multiplane images? + */ +#define AMDGPU_MODIFIER_COMPRESSION_SHIFT 39 +#define AMDGPU_MODIFIER_COMPRESSION_MASK 0x1 + +/* The chip this is compatible with. + * + * If compression is disabled, use + * - AMDGPU_CHIP_TAHITI for GFX6-GFX8 + * - AMDGPU_CHIP_VEGA10 for GFX9+ + * + * With compression enabled please use the exact chip. + * + * TODO: Do some generations share DCC format? + */ +#define AMDGPU_MODIFIER_CHIP_GEN_SHIFT 40 +#define AMDGPU_MODIFIER_CHIP_GEN_MASK 0xff + +#define AMDGPU_MODIFIER_SET(field, value) \ + (((__u64)(value) & AMDGPU_MODIFIER_##field##_MASK) << AMDGPU_MODIFIER_##field##_SHIFT) +#define AMDGPU_MODIFIER_GET(value, field) \ + (((__u64)(value) >> AMDGPU_MODIFIER_##field##_SHIFT) & AMDGPU_MODIFIER_##field##_MASK) + /* * Definition of free sync enter and exit signals * We may have more options in the future -- 2.18.0

7 30

[Bug 106671] Frequent lock ups for AMD RX 550 graphics card
by bugzilla-daemon＠freedesktop.org 07 Sep '18

07 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=106671 --- Comment #13 from Alan W. Irwin <Alan.W.Irwin1234(a)gmail.com> --- Well, after 1.5 (successful) days with the remote graphics experiment, I decided instead it made more sense to go after the quicker acting instability that I have previously experienced in direct graphics mode. So just now I have started a direct graphics experiment after a Debian Testing upgrade which included the following firmware and mesa changes: firmware-amd-graphics updated "(20180825+dfsg-1) over (20180518-1)" mesa updated "(18.1.7-1) over (18.1.6-1)" In addition for this experiment I installed the amd64-microcode package that contains "microcode patches for all AMD AMD64 processors". Also, as part of this experiment I have continued with the idle=nomwait kernel parameter as verified by irwin@merlin> cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.17.0-3-amd64 root=UUID=1e45a1ee-a5d6-4327-9a7b-2663ffc0b157 ro rootwait quiet idle=nomwait N.B. note those kernel parameters do not include any amdgpu-related parameters. Do you recommend any such parameters for the RX 550 such as amdgpu.dc=1 which is sometimes recommended for older versions of AMD new-generation graphics hardware? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH v5 00/19] clean up DPU for RM refactor
by Jeykumar Sankaran 07 Sep '18

07 Sep '18

Based on the comments received for the patch series[1] and to make the review process a bit more easy, spliting up the patches for cleanup and resource manager refactor. This series cleans up and prepares the DPU for upcoming RM changes. [1] https://patchwork.freedesktop.org/series/44669/ Thanks and Regards, Jeykumar S. Jeykumar Sankaran (19): drm/msm/dpu: remove debugfs support for misr drm/msm/dpu: squash power handle event types drm/msm/dpu: remove scalar config definitions drm/msm/dpu: remove resource pool manager drm/msm/dpu: remove ping pong split topology variables drm/msm/dpu: enable master-slave encoders explicitly drm/msm/dpu: use kms stored hw mdp block drm/msm/dpu: iterate for assigned hw ctl in virtual encoder drm/msm/dpu: avoid querying for hw intf before assignment drm/msm/dpu: make crtc get_mixer_width helper static drm/msm/dpu: move hw resource tracking to crtc state drm/msm/dpu: rename hw_ctl to lm_ctl drm/msm/dpu: clean up destination scaler residue drm/msm/dpu: remove cdm block support from resource manager drm/msm/dpu: remove LOCK/CLEAR support in RM drm/msm/dpu: remove display H_TILE from encoder drm/msm/dpu: remove RM dependency on connector state drm/msm/dpu: relax parameter validation in encoders drm/msm/dpu: remove RM topology definition drivers/gpu/drm/msm/Makefile | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 467 +++------------------ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 111 +---- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 216 ++-------- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 10 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 23 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 48 +-- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 125 +----- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 56 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 56 --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c | 323 -------------- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.h | 139 ------ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 14 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 4 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 29 -- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 7 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 29 -- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h | 7 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 33 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 18 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h | 17 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 3 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 16 - drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8 +- drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 15 +- drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 14 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 278 +++--------- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 44 -- drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 4 - 29 files changed, 216 insertions(+), 1899 deletions(-) delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

3 27

[PATCH] fbdev: fix kerneldoc
by Michał Mirosław 07 Sep '18

07 Sep '18

As noticed by kbuild test robot <lkp(a)intel.com>, remove_conflicting_pci_framebuffers()'s second argument is called res_id not resource_id. Fix this. Signed-off-by: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> --- * Against drm-misc-next, as this is the branch original patchset was applied to. --- drivers/video/fbdev/core/fbmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 5ffadc8e681d..4a2193fe3bc3 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -1834,7 +1834,7 @@ EXPORT_SYMBOL(remove_conflicting_framebuffers); /** * remove_conflicting_pci_framebuffers - remove firmware-configured framebuffers for PCI devices * @pdev: PCI device - * @resource_id: index of PCI BAR configuring framebuffer memory + * @res_id: index of PCI BAR configuring framebuffer memory * @name: requesting driver name * * This function removes framebuffer devices (eg. initialized by firmware) -- 2.18.0

2 2

[Bug 106928] When starting a match Rocket League crashes on "Go"
by bugzilla-daemon＠freedesktop.org 07 Sep '18

07 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=106928 Bug ID: 106928 Summary: When starting a match Rocket League crashes on "Go" Product: Mesa Version: 18.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel(a)lists.freedesktop.org Reporter: terikss(a)wedogames.se QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 140170 --> https://bugs.freedesktop.org/attachment.cgi?id=140170&action=edit Core dump from gdb while running Mesa 18.1.1-3 Overview: When starting a match in Rocket League it counts down 3, 2, 1, Go. The game always crashes on Go. Different game modes such as training where the countdown does not occur does not crash the game. I have tried different graphics settings in Rocket League ranging from lowest to highest. Changing graphics settings makes no difference the game always crashes in the same place. The reason I suspect the r600 driver is the cause of the issue (or at least part of it) is because of the back trace from gdb which starts with the following and looks like it includes a function name prefixed with "r600". #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007f52a1f85561 in __GI_abort () at abort.c:79 #2 0x00007f528e46fecd in std::__replacement_assert (__condition=0x7f528e697818 "__builtin_expect(__n < this->size(), true)", __function=<synthetic pointer>, __line=932, __file=0x7f528e699680 "/usr/include/c++/8/bits/stl_vector.h") at /usr/include/c++/8/x86_64-redhat-linux/bits/c++config.h:2389 #3 std::vector<r600_sb::value*, std::allocator<r600_sb::value*> >::operator[] (__n=2, this=0x7f51a1912120) at /usr/include/c++/8/bits/stl_vector.h:932 #4 r600_sb::expr_handler::fold_alu_op3 (this=0x7f51a1717ba8, n=...) at sb/sb_expr.cpp:952 Steps to Reproduce: 1. Start Rocket League 2. Click Play. 3. Click Play Local. 4. Click Exhibition. 5. Click Create Match. 6. Wait until the match has loaded, countdown begins and it says "Go". Actual Results: The game crashes. Expected Results: Game to not crash and playable match to begin. Build Date & Hardware: Graphics card: 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Juniper XT [Radeon HD 5770] I'm running Fedora 28. The crash can be recreated with both Mesa 18.0.2-1 and Mesa 18.1.1-3 from https://apps.fedoraproject.org/packages/mesa. Attached is a core dump from gdb and the output from steam from when starting Steam to after the game has crashed. The core dump and output is from when running Mesa 18.1.1-3. -- You are receiving this mail because: You are the assignee for the bug.

1 22

[PATCH] drm/fb-helper: document remove*_conflicting_framebuffers()
by Michał Mirosław 07 Sep '18

07 Sep '18

Copy remove*_conflicting_framebuffers() kerneldocs from fbdev code to make DRM developers' life easier. Signed-off-by: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> --- * Against drm-misc-next. --- include/drm/drm_fb_helper.h | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h index 8b6ab3200a2c..bb9acea61369 100644 --- a/include/drm/drm_fb_helper.h +++ b/include/drm/drm_fb_helper.h @@ -604,6 +604,16 @@ drm_fbdev_generic_setup(struct drm_device *dev, unsigned int preferred_bpp) #endif +/** + * drm_fb_helper_remove_conflicting_framebuffers - remove firmware-configured framebuffers + * @a: memory range, users of which are to be removed + * @name: requesting driver name + * @primary: also kick vga16fb if present + * + * This function removes framebuffer devices (initialized by firmware/bootloader) + * which use memory range described by @a. If @a is NULL all such devices are + * removed. + */ static inline int drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a, const char *name, bool primary) @@ -615,6 +625,18 @@ drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a, #endif } +/** + * drm_fb_helper_remove_conflicting_pci_framebuffers - remove firmware-configured framebuffers for PCI devices + * @pdev: PCI device + * @resource_id: index of PCI BAR configuring framebuffer memory + * @name: requesting driver name + * + * This function removes framebuffer devices (eg. initialized by firmware) + * using memory range configured for @pdev's BAR @resource_id. + * + * The function assumes that PCI device with shadowed ROM drives a primary + * display and so kicks out vga16fb. + */ static inline int drm_fb_helper_remove_conflicting_pci_framebuffers(struct pci_dev *pdev, int resource_id, -- 2.18.0

1 0

[PATCH v4 0/6] Backlight fixes and cleanup
by Lyude Paul 07 Sep '18

07 Sep '18

Refactor for Ben, hopefully this time this should apply to his tree. Next version of https://patchwork.freedesktop.org/series/48596/ No changes otherwise. Lyude Paul (6): drm/nouveau: Check backlight IDs are >= 0, not > 0 drm/nouveau: Add NV_PRINTK_ONCE and variants drm/nouveau: Move backlight device into nouveau_connector drm/nouveau: s/nouveau_backlight_exit/nouveau_backlight_fini/ drm/nouveau: Cleanup indenting in nouveau_backlight.c drm/nouveau: Refactor nvXX_backlight_init() drivers/gpu/drm/nouveau/nouveau_backlight.c | 220 ++++++++++---------- drivers/gpu/drm/nouveau/nouveau_connector.c | 20 ++ drivers/gpu/drm/nouveau/nouveau_connector.h | 33 +++ drivers/gpu/drm/nouveau/nouveau_display.c | 2 - drivers/gpu/drm/nouveau/nouveau_display.h | 25 --- drivers/gpu/drm/nouveau/nouveau_drv.h | 10 +- 6 files changed, 168 insertions(+), 142 deletions(-) -- 2.17.1

2 8

[PATCH] android:ion: the order and count are in the wrong position
by jun qian 07 Sep '18

07 Sep '18

The value in the wrong position will cause misunderstanding, when the debug infomations display in the window. Signed-off-by: jun qian <hangdianqj(a)163.com> --- drivers/staging/android/ion/ion_system_heap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c index 701eb9f3b0f1..54b8a7710958 100644 --- a/drivers/staging/android/ion/ion_system_heap.c +++ b/drivers/staging/android/ion/ion_system_heap.c @@ -225,10 +225,10 @@ static int ion_system_heap_debug_show(struct ion_heap *heap, struct seq_file *s, pool = sys_heap->pools[i]; seq_printf(s, "%d order %u highmem pages %lu total\n", - pool->high_count, pool->order, + pool->order, pool->high_count, (PAGE_SIZE << pool->order) * pool->high_count); seq_printf(s, "%d order %u lowmem pages %lu total\n", - pool->low_count, pool->order, + pool->order, pool->low_count, (PAGE_SIZE << pool->order) * pool->low_count); } -- 2.17.1

2 1

[Bug 103199] [CI] igt@drv_missed_irq - fail - Failed assertion: missed_rings == expect_rings
by bugzilla-daemon＠freedesktop.org 07 Sep '18

07 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=103199 --- Comment #7 from Chris Wilson <chris(a)chris-wilson.co.uk> --- It should do the trick. My memory of the test says that if we can't open the file we say the engine mask is 0. However, I do have an update to the igt pending review in case it doesn't. We shall see what happens over the w/e and if we need to open a new bug or not. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 103199] [CI] igt@drv_missed_irq - fail - Failed assertion: missed_rings == expect_rings
by bugzilla-daemon＠freedesktop.org 07 Sep '18

07 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=103199 Martin Peres <martin.peres(a)free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #6 from Martin Peres <martin.peres(a)free.fr> --- (In reply to Chris Wilson from comment #5) > (In reply to Chris Wilson from comment #4) > > (In reply to Martin Peres from comment #3) > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_93/fi-icl-u/ > > > igt(a)drv_missed_irq.html > > > > > > (drv_missed_irq:1510) CRITICAL: Test assertion failure function > > > __real_main96, file ../tests/drv_missed_irq.c:159: > > > (drv_missed_irq:1510) CRITICAL: Failed assertion: missed_rings == > > > expect_rings > > > (drv_missed_irq:1510) CRITICAL: Last errno: 9, Bad file descriptor > > > (drv_missed_irq:1510) CRITICAL: error: 0 != 0x57 > > > Test drv_missed_irq failed. > > > > icl is a different class of bug -- icl can't fake missed interrupts at all. > > commit 5f521722a2a2391d693afccdf6e12be2754382d8 (HEAD -> > drm-intel-next-queued, drm-intel/drm-intel-next-queued) > Author: Chris Wilson <chris(a)chris-wilson.co.uk> > Date: Fri Sep 7 12:28:51 2018 +0100 > > drm/i915: Missed interrupt simulation is no more, tell the world > > Using the guc, we cannot disable the user interrupt generation as we use > it for driving submission. And from Icelake, we no longer have the > ability to individually mask interrupt generation from each engine, > disabling our ability to fake missed interrupts. > > In both cases, report back to userspace that the missed interrupt > generator is no longer available. > > Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> > Cc: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> > Reviewed-by: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> > Link: > https://patchwork.freedesktop.org/patch/msgid/20180907112856.28242-1- > chris(a)chris-wilson.co.uk Do you think it will also fix the ICL bug or should I file another bug? -- You are receiving this mail because: You are the assignee for the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2018