Re: [PATCH v2] docs/gpu: ci: update flake tests requirements
On 9/26/2024 12:06 AM, Vignesh Raman wrote:
Update the documentation to require linking to a relevant GitLab
issue for each new flake entry instead of an email report. Added
specific GitLab issue URLs for i915, xe and other drivers.
Signed-off-by: Vignesh Raman
---
v2:
- Add gitlab issue link for msm driver.
---
Documentation/gpu/automated_testing.rst | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/Documentation/gpu/automated_testing.rst
b/Documentation/gpu/automated_testing.rst
index 2d5a28866afe..f918fe56f2b0 100644
--- a/Documentation/gpu/automated_testing.rst
+++ b/Documentation/gpu/automated_testing.rst
@@ -67,20 +67,26 @@ Lists the tests that for a given driver on a specific
hardware revision are
known to behave unreliably. These tests won't cause a job to fail regardless
of
the result. They will still be run.
-Each new flake entry must be associated with a link to the email reporting the
-bug to the author of the affected driver, the board name or Device Tree name of
-the board, the first kernel version affected, the IGT version used for tests,
-and an approximation of the failure rate.
+Each new flake entry must include a link to the relevant GitLab issue, the
board
+name or Device Tree name, the first kernel version affected, the IGT version
used
+for tests and an approximation of the failure rate.
They should be provided under the following format::
- # Bug Report: $LORE_OR_PATCHWORK_URL
+ # Bug Report: $GITLAB_ISSUE
# Board Name: broken-board.dtb
# Linux Version: 6.6-rc1
# IGT Version: 1.28-gd2af13d9f
# Failure Rate: 100
flaky-test
+The GitLab issue must include the logs and the pipeline link. Use the appropriate
+link below to create an issue.
+https://gitlab.freedesktop.org/drm/i915/kernel/-/issues for i915 driver
+https://gitlab.freedesktop.org/drm/xe/kernel/-/issues for xe driver
+https://gitlab.freedesktop.org/drm/msm/-/issues for msm driver
+https://gitlab.freedesktop.org/drm/misc/kernel/-/issues for other drivers
+
Acked for MSM.
Thanks
Abhinav
drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-skips.txt
---
Re: [PATCH v3 4/6] drm/ci: uprev IGT
On 5/29/2024 2:48 AM, Vignesh Raman wrote:
Hi Dmitry,
On 29/05/24 13:39, Dmitry Baryshkov wrote:
On Wed, May 29, 2024 at 08:10:47AM +0530, Vignesh Raman wrote:
test-list.txt and test-list-full.txt are not generated for
cross-builds and they are required by drm-ci for testing
arm32 targets. This is fixed in igt-gpu-tools. So uprev
IGT to include the commit which fixes this issue. Also
disable building xe driver tests for non-intel platforms.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Vignesh Raman
---
v2:
- Split IGT uprev to seperate patch.
v3:
- No changes.
---
drivers/gpu/drm/ci/build-igt.sh | 4
drivers/gpu/drm/ci/gitlab-ci.yml | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ci/build-igt.sh
b/drivers/gpu/drm/ci/build-igt.sh
index b7d2a49a6db3..eddb5f782a5e 100644
--- a/drivers/gpu/drm/ci/build-igt.sh
+++ b/drivers/gpu/drm/ci/build-igt.sh
@@ -45,6 +45,10 @@
MESON_OPTIONS="-Doverlay=disabled \
-Dlibunwind=enabled \
-Dprefix=/igt"
+if [[ "$KERNEL_ARCH" = "arm64" ]] || [[ "$KERNEL_ARCH" = "arm" ]]; then
+ MESON_OPTIONS="$MESON_OPTIONS -Dxe_driver=disabled"
+fi
+
mkdir -p /igt
meson build $MESON_OPTIONS $EXTRA_MESON_ARGS
ninja -C build -j${FDO_CI_CONCURRENT:-4} || ninja -C build -j 1
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml
b/drivers/gpu/drm/ci/gitlab-ci.yml
index 8f32de63d92e..1b29c3b6406b 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -5,7 +5,7 @@ variables:
UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm
TARGET_BRANCH: drm-next
- IGT_VERSION: d2af13d9f5be5ce23d996e4afd3e45990f5ab977
+ IGT_VERSION: 0df7b9b97f9da0e364f5ee30fe331004b8c86b56
Let's land this, then I'll ask to uprev to
dc2d7fb4f978048b87707ea9ec32da748b01b378, which fixes an issue with the
writeback tests on MSM devices.
Sure. Once this is merged, we can uprev to the latest IGT.
Regards,
Vignesh
Thanks, yes moving to latest IGT after this is merged will be great.
DEQP_RUNNER_GIT_URL:
https://gitlab.freedesktop.org/anholt/deqp-runner.git
DEQP_RUNNER_GIT_TAG: v0.15.0
--
2.40.1
Re: [PATCH v5 01/32] drm/drm_mode_object: increase max objects to accommodate new color props
On 11/16/2023 11:57 AM, Melissa Wen wrote:
DRM_OBJECT_MAX_PROPERTY limits the number of properties to be attached
and we are increasing that value all time we add a new property (generic
or driver-specific).
In this series, we are adding 13 new KMS driver-specific properties for
AMD color manage:
- CRTC Gamma enumerated Transfer Function
- Plane: Degamma LUT+size+TF, HDR multiplier, shaper LUT+size+TF, 3D
LUT+size, blend LUT+size+TF (12)
Therefore, just increase DRM_OBJECT_MAX_PROPERTY to a number (64) that
accomodates these new properties and gives some room for others,
avoiding change this number everytime we add a new KMS property.
Reviewed-by: Harry Wentland
Reviewed-by: Simon Ser
Signed-off-by: Melissa Wen
Reviewed-by: Abhinav Kumar
---
include/drm/drm_mode_object.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
index 912f1e415685..08d7a7f0188f 100644
--- a/include/drm/drm_mode_object.h
+++ b/include/drm/drm_mode_object.h
@@ -60,7 +60,7 @@ struct drm_mode_object {
void (*free_cb)(struct kref *kref);
};
-#define DRM_OBJECT_MAX_PROPERTY 24
+#define DRM_OBJECT_MAX_PROPERTY 64
/**
* struct drm_object_properties - property tracking for &drm_mode_object
*/
Re: [PATCH v3 3/5] drm/msm: add trailing newlines to drm_dbg msgs
Hi Jim On 9/6/2023 12:02 PM, Jim Cromie wrote: By at least strong convention, a print-buffer's trailing newline says "message complete, send it". The exception (no TNL, followed by a call to pr_cont) proves the general rule. Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG, 1288 drm_dbg. Clean up the remainders, in maintainer sized chunks. May I know what 207, 1288 mean here? Is it the number of callers already having \n? If so, this might be a big confusing as its subjective to the code-base you are referring to. So I will just stop with "Most DRM.debug calls already comport with this". No functional changes. Signed-off-by: Jim Cromie --- drivers/gpu/drm/msm/msm_fb.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) The change itself LGTM, hence Reviewed-by: Abhinav Kumar
Re: [PATCH -next 3/7] drm/msm: Remove unnecessary NULL values
On 8/8/2023 8:44 PM, Ruan Jinjie wrote: The NULL initialization of the pointers assigned by kzalloc() first is not necessary, because if the kzalloc() failed, the pointers will be assigned NULL, otherwise it works as usual. so remove it. Signed-off-by: Ruan Jinjie --- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Abhinav Kumar
Re: [PATCH] drm/client: Send hotplug event after registering a client
On 7/10/2023 2:10 AM, Thomas Zimmermann wrote:
Generate a hotplug event after registering a client to allow the
client to configure its display. Remove the hotplug calls from the
existing clients for fbdev emulation. This change fixes a concurrency
bug between registering a client and receiving events from the DRM
core. The bug is present in the fbdev emulation of all drivers.
The fbdev emulation currently generates a hotplug event before
registering the client to the device. For each new output, the DRM
core sends an additional hotplug event to each registered client.
If the DRM core detects first output between sending the artificial
hotplug and registering the device, the output's hotplug event gets
lost. If this is the first output, the fbdev console display remains
dark. This has been observed with amdgpu and fbdev-generic.
Fix this by adding hotplug generation directly to the client's
register helper drm_client_register(). Registering the client and
receiving events are serialized by struct drm_device.clientlist_mutex.
So an output is either configured by the initial hotplug event, or
the client has already been registered.
The bug was originally added in commit 6e3f17ee73f7 ("drm/fb-helper:
generic: Call drm_client_add() after setup is done"), in which adding
a client and receiving a hotplug event switched order. It was hidden,
as most hardware and drivers have at least on static output configured.
Other drivers didn't use the internal DRM client or still had struct
drm_mode_config_funcs.output_poll_changed set. That callback handled
hotplug events as well. After not setting the callback in amdgpu in
commit 0e3172bac3f4 ("drm/amdgpu: Don't set struct
drm_driver.output_poll_changed"), amdgpu did not show a framebuffer
console if output events got lost. The bug got copy-pasted from
fbdev-generic into the other fbdev emulation.
Reported-by: Moritz Duge
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2649
Fixes: 6e3f17ee73f7 ("drm/fb-helper: generic: Call drm_client_add() after setup is
done")
Fixes: 8ab59da26bc0 ("drm/fb-helper: Move generic fbdev emulation into separate
source file")
Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for GEM DMA
helpers")
Fixes: 63c381552f69 ("drm/armada: Implement fbdev emulation as in-kernel
client")
Fixes: 49953b70e7d3 ("drm/exynos: Implement fbdev emulation as in-kernel
client")
Fixes: 8f1aaccb04b7 ("drm/gma500: Implement client-based fbdev emulation")
Fixes: 940b869c2f2f ("drm/msm: Implement fbdev emulation as in-kernel client")
Fixes: 9e69bcd88e45 ("drm/omapdrm: Implement fbdev emulation as in-kernel
client")
Fixes: e317a69fe891 ("drm/radeon: Implement client-based fbdev emulation")
Fixes: 71ec16f45ef8 ("drm/tegra: Implement fbdev emulation as in-kernel client")
Signed-off-by: Thomas Zimmermann
Tested-by: Moritz Duge
Tested-by: Torsten Krah
Tested-by: Paul Schyska
Cc: Daniel Vetter
Cc: David Airlie
Cc: Noralf Trønnes
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Javier Martinez Canillas
Cc: Russell King
Cc: Inki Dae
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Krzysztof Kozlowski
Cc: Patrik Jakobsson
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Tomi Valkeinen
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: Thierry Reding
Cc: Mikko Perttunen
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: # v5.2+
---
drivers/gpu/drm/armada/armada_fbdev.c | 4
drivers/gpu/drm/drm_client.c | 21 +
drivers/gpu/drm/drm_fbdev_dma.c | 4
drivers/gpu/drm/drm_fbdev_generic.c | 4
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4
drivers/gpu/drm/gma500/fbdev.c| 4
drivers/gpu/drm/msm/msm_fbdev.c | 4
drivers/gpu/drm/omapdrm/omap_fbdev.c | 4
drivers/gpu/drm/radeon/radeon_fbdev.c | 4
drivers/gpu/drm/tegra/fbdev.c | 4
10 files changed, 21 insertions(+), 36 deletions(-)
Reviewed-by: Abhinav Kumar
Re: [PATCH v5 11/13] drm/msm: Use regular fbdev I/O helpers
On 5/30/2023 8:02 AM, Thomas Zimmermann wrote: Use the regular fbdev helpers for framebuffer I/O instead of DRM's helpers. Msm does not use damage handling, so DRM's fbdev helpers are mere wrappers around the fbdev code. By using fbdev helpers directly within each DRM fbdev emulation, we can eventually remove DRM's wrapper functions entirely. Msm's fbdev emulation has been incomplete as it didn't implement damage handling. Partilly fix this by implementing damage handling for write and draw operation. It is still missing for mmaped pages. v4: * use initializer macros for struct fb_ops * partially support damage handling v2: * use FB_SYS_HELPERS option Signed-off-by: Thomas Zimmermann Reviewed-by: Dmitry Baryshkov Acked-by: Sam Ravnborg Cc: Rob Clark Cc: Abhinav Kumar Cc: Dmitry Baryshkov Cc: Sean Paul --- Reviewed-by: Abhinav Kumar
Re: [PATCH 00/22] drm: Review of mode copies
On 3/23/2022 3:39 AM, Dmitry Baryshkov wrote: On 22/03/2022 01:37, Ville Syrjälä wrote: On Tue, Mar 15, 2022 at 02:52:38PM -0400, Alex Deucher wrote: On Mon, Mar 14, 2022 at 6:12 PM Ville Syrjälä wrote: On Fri, Feb 18, 2022 at 12:03:41PM +0200, Ville Syrjala wrote: drm: Add drm_mode_init() drm/bridge: Use drm_mode_copy() drm/imx: Use drm_mode_duplicate() drm/panel: Use drm_mode_duplicate() drm/vc4: Use drm_mode_copy() These have been pushed to drm-misc-next. drm/amdgpu: Remove pointless on stack mode copies drm/amdgpu: Use drm_mode_init() for on-stack modes drm/amdgpu: Use drm_mode_copy() amdgpu ones are reviewed, but I'll leave them for the AMD folks to push to whichever tree they prefer. I pulled patches 2, 4, 5 into my tree. Thanks. For 3, I'm happy to have it land via drm-misc with the rest of the mode_init changes if you'd prefer. Either way works for me. I don't yet have reviews yet for the other drivers, so I'll proably hold off for a bit more at least. And the i915 patch I'll be merging via drm-intel. drm/radeon: Use drm_mode_copy() drm/gma500: Use drm_mode_copy() drm/tilcdc: Use drm_mode_copy() drm/i915: Use drm_mode_copy() Those are now all in. Which leaves us with these stragglers: drm/hisilicon: Use drm_mode_init() for on-stack modes drm/msm: Nuke weird on stack mode copy drm/msm: Use drm_mode_init() for on-stack modes drm/msm: Use drm_mode_copy() These three patches went beneath my radar for some reason. I have just sent a replacement for the first patch ([1]). Other two patches can be pulled in msm/msm-next (or msm/msm-fixes) during the next development cycle if that works for you. [1] https://patchwork.freedesktop.org/series/101682/ Agree with this approach. We can replace the first patch with https://patchwork.freedesktop.org/series/101682/. Thanks Abhinav drm/mtk: Use drm_mode_init() for on-stack modes drm/rockchip: Use drm_mode_copy() drm/sti: Use drm_mode_copy() drm: Use drm_mode_init() for on-stack modes drm: Use drm_mode_copy()
Re: [PATCH v2 1/2] drm: Add GPU reset sysfs event
On 3/10/2022 9:40 AM, Rob Clark wrote: On Thu, Mar 10, 2022 at 9:19 AM Sharma, Shashank wrote: On 3/10/2022 6:10 PM, Rob Clark wrote: On Thu, Mar 10, 2022 at 8:21 AM Sharma, Shashank wrote: On 3/10/2022 4:24 PM, Rob Clark wrote: On Thu, Mar 10, 2022 at 1:55 AM Christian König wrote: Am 09.03.22 um 19:12 schrieb Rob Clark: On Tue, Mar 8, 2022 at 11:40 PM Shashank Sharma wrote: From: Shashank Sharma This patch adds a new sysfs event, which will indicate the userland about a GPU reset, and can also provide some information like: - process ID of the process involved with the GPU reset - process name of the involved process - the GPU status info (using flags) This patch also introduces the first flag of the flags bitmap, which can be appended as and when required. Why invent something new, rather than using the already existing devcoredump? Yeah, that's a really valid question. I don't think we need (or should encourage/allow) something drm specific when there is already an existing solution used by both drm and non-drm drivers. Userspace should not have to learn to support yet another mechanism to do the same thing. Question is how is userspace notified about new available core dumps? I haven't looked into it too closely, as the CrOS userspace crash-reporter already had support for devcoredump, so it "just worked" out of the box[1]. I believe a udev event is what triggers the crash-reporter to go read the devcore dump out of sysfs. I had a quick look at the devcoredump code, and it doesn't look like that is sending an event to the user, so we still need an event to indicate a GPU reset. There definitely is an event to userspace, I suspect somewhere down the device_add() path? Let me check that out as well, hope that is not due to a driver-private event for GPU reset, coz I think I have seen some of those in a few DRM drivers. Definitely no driver private event for drm/msm .. I haven't dug through it all but this is the collector for devcoredump, triggered somehow via udev. Most likely from event triggered by device_add() https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/crash-reporter/udev_collector.cc Yes, that is correct. the uevent for devcoredump is from device_add() https://github.com/torvalds/linux/blob/master/drivers/base/core.c#L3340 BR, -R
