Re: [PATCH v10] drm: Add initial ci/ subdirectory
On 31/07/2023 10:38, Juan A. Suárez wrote: On Sat, 2023-07-29 at 12:08 +0300, David Heidelberg wrote: Hello Maira, Regarding the second question about V3D and V3DV: in the Mesa3D CI, we currently use downstream kernels, so we don't build the kernel for Raspberry Pi. BM_BOOTFS option can point to a link tarball containing an alternative kernel to use instead of downstream one. The only drawback is that this tarball must be an already compiled kernel; it won't compile it. It would be great if you could fill in missing kernel config options for machines you use for V3D(V) in the `kernel/configs/mesa*.config` within the `gfx-ci/Linux repository (the config files here origin from there). If the compiled kernel will work on RPis, then the next step would be adding kernel format and DTB names to the `src/broadcom/ci/gitlab-ci.yml` in the Mesa repository so that you can use my Mesa draft MR [1] to quickly test if your jobs would work with the mainline kernel and any other board that won't break due to your changes. When this integration is done ‒ it's easy to run drm-ci testing on these machines. David [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23563 However, I've been thinking about the possibility of adding an override for the kernel from an external source to our CI. This way, we can also test with a provided kernel and override the default option of using the downstream kernel on Raspberry Pi. If we proceed with this, it would be sensible to include V3D* options in our kernel builds. I'm including Juan and Eric for their input on this topic. The idea sounds great. Aren't we already compiling kernels for other hardware? Maybe we can include specific versions for Rpi. J.A. -- David Heidelberg Consultant Software Engineer Collabora Ltd. Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK Registered in England & Wales, no. 5513718 OpenPGP_0x69F567861C1EC014.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH v10] drm: Add initial ci/ subdirectory
On Mon, Jul 31, 2023 at 5:25 AM Helen Mae Koike Fornazier
wrote:
>
> Hello all,
>
> Thanks for your comments.
>
> On Friday, July 28, 2023 11:37 -03, Rob Clark wrote:
>
> > On Thu, Jul 27, 2023 at 10:26 PM Daniel Stone wrote:
> > >
> > > On Thu, 27 Jul 2023 at 22:47, Rob Clark wrote:
> > > > > I did run into a bit of a chicken vs. egg problem with testing the "in
> > > > > tree" version (compared to earlier versions which kept most of the yml
> > > > > and scripts in a separate tree), is that it actually requires this
> > > > > commit to exist in the branch you want to run CI on. My earlier
> > > > > workaround of pulling the drm/ci commit in via
> > > > > ${branchname}-external-fixes no longer works.
> > > >
> > > > After unwinding some more gitlab repo settings that were for the
> > > > previous out-of-tree yml setup, I have this working.
> > > >
> > > > Tested-by: Rob Clark
> > > > Acked-by: Rob Clark
> > >
> > > And it's also:
> > > Acked-by: Daniel Stone
> > >
> > > It's been back and forth a few times by now and reviewed pretty
> > > heavily by all the people who are across the CI details. I think the
> > > next step is to answer all the workflow questions by actually getting
> > > it into trees and using it in anger. There was some discussion about
> > > whether this should come in from drm-misc, or the core DRM tree, or a
> > > completely separate pull, but I'm not sure what the conclusion was ...
> > > maintainers, thoughts?
> >
> > I'd prefer a separate pull, so that I could merge it into msm-next as
> > well without having to pull in all of drm-misc
>
> Should we create a drm-ci ?
I guess we can just wait and see how often it is that drm/ci updates
need to be merged into multiple driver trees. Hopefully most of the
drm/ci changes are just expectation file updates which should go via
driver tree. Maybe i-g-t uprevs, if they have a lot of expectation
changes would be something drivers would want to merge into their own
tree? But I guess we can see how it goes.
> >
> > Possibly some other driver trees would like to do similar?
> >
> > BR,
> > -R
>
> Also, please wait for v11, I have a few adjustments to make as pointer by
> some comments, and also regarding xfails list and how the configs should
> be organized (unless if you are fine merging this version and I can submit
> the adjustments later).
Ok
BR,
-R
> Thanks,
> Helen
>
Re: [PATCH v10] drm: Add initial ci/ subdirectory
Hello all,
Thanks for your comments.
On Friday, July 28, 2023 11:37 -03, Rob Clark wrote:
> On Thu, Jul 27, 2023 at 10:26 PM Daniel Stone wrote:
> >
> > On Thu, 27 Jul 2023 at 22:47, Rob Clark wrote:
> > > > I did run into a bit of a chicken vs. egg problem with testing the "in
> > > > tree" version (compared to earlier versions which kept most of the yml
> > > > and scripts in a separate tree), is that it actually requires this
> > > > commit to exist in the branch you want to run CI on. My earlier
> > > > workaround of pulling the drm/ci commit in via
> > > > ${branchname}-external-fixes no longer works.
> > >
> > > After unwinding some more gitlab repo settings that were for the
> > > previous out-of-tree yml setup, I have this working.
> > >
> > > Tested-by: Rob Clark
> > > Acked-by: Rob Clark
> >
> > And it's also:
> > Acked-by: Daniel Stone
> >
> > It's been back and forth a few times by now and reviewed pretty
> > heavily by all the people who are across the CI details. I think the
> > next step is to answer all the workflow questions by actually getting
> > it into trees and using it in anger. There was some discussion about
> > whether this should come in from drm-misc, or the core DRM tree, or a
> > completely separate pull, but I'm not sure what the conclusion was ...
> > maintainers, thoughts?
>
> I'd prefer a separate pull, so that I could merge it into msm-next as
> well without having to pull in all of drm-misc
Should we create a drm-ci ?
>
> Possibly some other driver trees would like to do similar?
>
> BR,
> -R
Also, please wait for v11, I have a few adjustments to make as pointer by
some comments, and also regarding xfails list and how the configs should
be organized (unless if you are fine merging this version and I can submit
the adjustments later).
Thanks,
Helen
Re: [PATCH v10] drm: Add initial ci/ subdirectory
On Sat, 2023-07-29 at 12:08 +0300, David Heidelberg wrote: > Hello Maira, > > Regarding the second question about V3D and V3DV: in the Mesa3D CI, > we > currently use downstream kernels, so we don't build the kernel for > Raspberry Pi. > > > BM_BOOTFS option can point to a link tarball containing an alternative kernel to use instead of downstream one. The only drawback is that this tarball must be an already compiled kernel; it won't compile it. > However, I've been thinking about the possibility of adding an > override > for the kernel from an external source to our CI. This way, we can > also > test with a provided kernel and override the default option of using > the > downstream kernel on Raspberry Pi. > > If we proceed with this, it would be sensible to include V3D* options > in > our kernel builds. > > I'm including Juan and Eric for their input on this topic. > > The idea sounds great. Aren't we already compiling kernels for other hardware? Maybe we can include specific versions for Rpi. J.A.
Re: [PATCH v10] drm: Add initial ci/ subdirectory
On Thu, Jul 27, 2023 at 10:26 PM Daniel Stone wrote:
>
> On Thu, 27 Jul 2023 at 22:47, Rob Clark wrote:
> > > I did run into a bit of a chicken vs. egg problem with testing the "in
> > > tree" version (compared to earlier versions which kept most of the yml
> > > and scripts in a separate tree), is that it actually requires this
> > > commit to exist in the branch you want to run CI on. My earlier
> > > workaround of pulling the drm/ci commit in via
> > > ${branchname}-external-fixes no longer works.
> >
> > After unwinding some more gitlab repo settings that were for the
> > previous out-of-tree yml setup, I have this working.
> >
> > Tested-by: Rob Clark
> > Acked-by: Rob Clark
>
> And it's also:
> Acked-by: Daniel Stone
>
> It's been back and forth a few times by now and reviewed pretty
> heavily by all the people who are across the CI details. I think the
> next step is to answer all the workflow questions by actually getting
> it into trees and using it in anger. There was some discussion about
> whether this should come in from drm-misc, or the core DRM tree, or a
> completely separate pull, but I'm not sure what the conclusion was ...
> maintainers, thoughts?
I'd prefer a separate pull, so that I could merge it into msm-next as
well without having to pull in all of drm-misc
Possibly some other driver trees would like to do similar?
BR,
-R
Re: [PATCH v10] drm: Add initial ci/ subdirectory
Hi Helen,
Great to see this coming to the DRM!
Just wondering, any chance we could add a stage to perform tests on
VKMS? The main way of validating VKMS is through IGT tests, so I feel
it would be a perfect match to have VKMS as a stage on the CI. As a
generic KMS driver, VKMS is also great to validate changes on DRM core.
Another question, could we add V3D to the default arm and arm64 config?
Best Regards,
- Maíra
On 7/20/23 12:27, Helen Koike wrote:
From: Tomeu Vizoso
Developers can easily execute several tests on different devices
by just pushing their branch to their fork in a repository hosted
on gitlab.freedesktop.org which has an infrastructure to run jobs
in several runners and farms with different devices.
There are also other automated tools that uprev dependencies,
monitor the infra, and so on that are already used by the Mesa
project, and we can reuse them too.
Also, store expectations about what the DRM drivers are supposed
to pass in the IGT test suite. By storing the test expectations
along with the code, we can make sure both stay in sync with each
other so we can know when a code change breaks those expectations.
Also, include a configuration file that points to the out-of-tree
CI scripts.
This will allow all contributors to drm to reuse the infrastructure
already in gitlab.freedesktop.org to test the driver on several
generations of the hardware.
Signed-off-by: Tomeu Vizoso
Signed-off-by: Helen Koike
---
Hello,
I'm re-spining this patch sent originally by Tomeu.
This is meant to be an auxiliary tool where developers and
maintainers can just submit their code to fdo and see if
tests passes, than they can decide if it is worthy merging
it or not.
This tool has proven its value on the Mesa community
and it can bring a lot of value here too.
Please review and let me know your thoughts.
You can also see this patch on
https://gitlab.freedesktop.org/helen.fornazier/linux/-/tree/drm-ci-tests
Thanks!
v2:
- Fix names of result expectation files to match SoC
- Don't execute tests that are going to skip on all boards
v3:
- Remove tracking of dmesg output during test execution
v4:
- Move up to drivers/gpu/drm
- Add support for a bunch of other drivers
- Explain how to incorporate fixes for CI from a
${TARGET_BRANCH}-external-fixes branch
- Remove tests that pass from expected results file, to reduce the
size of in-tree files
- Add docs about how to deal with outages in automated testing labs
- Specify the exact SHA of the CI scripts to be used
v5:
- Remove unneeded skips from Meson expectations file
- Use a more advanced runner that detects flakes automatically
- Use a more succint format for the expectations
- Run many more tests (and use sharding to finish in time)
- Use skip lists to avoid hanging machines
- Add some build testing
- Build IGT in each pipeline for faster uprevs
- List failures in the GitLab UI
v6:
- Rebase on top of latest drm-next
- Lower priority of LAVA jobs to not impact Mesa CI as much
- Update docs
v7:
- Rebase on top of latest drm-next
v8:
- Move all files specific to testing the kernel into the kernel tree
(thus I have dropped the r-bs I had collected so far)
- Uprev Gitlab CI infrastructure scripts to the latest from Mesa
- Add MAINTAINERS entry
- Fix boot on MT8173 by adding some Kconfigs that are now needed
- Link to the docs from index.rst and hard-wrap the file
v9:
- Only automatically run the pipelines for merge requests
- Switch to zstd for the build artifacts to align with Mesa
- Add Qcom USB PHYs to config as they are now =m in the defconfig
v10:
- Include ci yml files from mesa/mesa (where the development is
current active) instead of a spin off project.
- Uprev Gitlab CI infrastructure scripts to the latest from Mesa
- Update MAINTAINERS entry
- Uprev igt tool
- add LAVA_JOB_PRIORITY: 30
- pipeline example:
https://gitlab.freedesktop.org/helen.fornazier/linux/-/pipelines/940506
---
Documentation/gpu/automated_testing.rst | 144 +
Documentation/gpu/index.rst |1 +
MAINTAINERS |8 +
drivers/gpu/drm/ci/arm.config | 69 +
drivers/gpu/drm/ci/arm64.config | 199 ++
drivers/gpu/drm/ci/build-igt.sh | 35 +
drivers/gpu/drm/ci/build.sh | 157 +
drivers/gpu/drm/ci/build.yml | 110 +
drivers/gpu/drm/ci/check-patch.py | 57 +
drivers/gpu/drm/ci/container.yml | 61 +
drivers/gpu/drm/ci/gitlab-ci.yml | 252 ++
drivers/gpu/drm/ci/igt_runner.sh | 77 +
drivers/gpu/drm/ci/image-tags.yml | 15 +
drivers/gpu/drm/ci/lava-submit.sh | 57 +
drivers/gpu/drm/ci/static-checks.yml | 12 +
drivers/gpu/drm/ci/test.yml | 335 ++
drivers/gpu/drm/ci/testli
Re: [PATCH v10] drm: Add initial ci/ subdirectory
Hi,
On Fri, Jul 28, 2023 at 06:26:39AM +0100, Daniel Stone wrote:
> On Thu, 27 Jul 2023 at 22:47, Rob Clark wrote:
> > > I did run into a bit of a chicken vs. egg problem with testing the "in
> > > tree" version (compared to earlier versions which kept most of the yml
> > > and scripts in a separate tree), is that it actually requires this
> > > commit to exist in the branch you want to run CI on. My earlier
> > > workaround of pulling the drm/ci commit in via
> > > ${branchname}-external-fixes no longer works.
> >
> > After unwinding some more gitlab repo settings that were for the
> > previous out-of-tree yml setup, I have this working.
> >
> > Tested-by: Rob Clark
> > Acked-by: Rob Clark
>
> And it's also:
> Acked-by: Daniel Stone
>
> It's been back and forth a few times by now and reviewed pretty
> heavily by all the people who are across the CI details. I think the
> next step is to answer all the workflow questions by actually getting
> it into trees and using it in anger. There was some discussion about
> whether this should come in from drm-misc, or the core DRM tree, or a
> completely separate pull, but I'm not sure what the conclusion was ...
> maintainers, thoughts?
I'd be ok with merging it through drm-misc
Maxime
signature.asc
Description: PGP signature
Re: [PATCH v10] drm: Add initial ci/ subdirectory
On Thu, 27 Jul 2023 at 22:47, Rob Clark wrote:
> > I did run into a bit of a chicken vs. egg problem with testing the "in
> > tree" version (compared to earlier versions which kept most of the yml
> > and scripts in a separate tree), is that it actually requires this
> > commit to exist in the branch you want to run CI on. My earlier
> > workaround of pulling the drm/ci commit in via
> > ${branchname}-external-fixes no longer works.
>
> After unwinding some more gitlab repo settings that were for the
> previous out-of-tree yml setup, I have this working.
>
> Tested-by: Rob Clark
> Acked-by: Rob Clark
And it's also:
Acked-by: Daniel Stone
It's been back and forth a few times by now and reviewed pretty
heavily by all the people who are across the CI details. I think the
next step is to answer all the workflow questions by actually getting
it into trees and using it in anger. There was some discussion about
whether this should come in from drm-misc, or the core DRM tree, or a
completely separate pull, but I'm not sure what the conclusion was ...
maintainers, thoughts?
Cheers,
Daniel
Re: [PATCH v10] drm: Add initial ci/ subdirectory
On Thu, Jul 27, 2023 at 12:49 PM Rob Clark wrote:
>
> On Thu, Jul 20, 2023 at 8:27 AM Helen Koike wrote:
> >
> > From: Tomeu Vizoso
> >
> > Developers can easily execute several tests on different devices
> > by just pushing their branch to their fork in a repository hosted
> > on gitlab.freedesktop.org which has an infrastructure to run jobs
> > in several runners and farms with different devices.
> >
> > There are also other automated tools that uprev dependencies,
> > monitor the infra, and so on that are already used by the Mesa
> > project, and we can reuse them too.
> >
> > Also, store expectations about what the DRM drivers are supposed
> > to pass in the IGT test suite. By storing the test expectations
> > along with the code, we can make sure both stay in sync with each
> > other so we can know when a code change breaks those expectations.
> >
> > Also, include a configuration file that points to the out-of-tree
> > CI scripts.
> >
> > This will allow all contributors to drm to reuse the infrastructure
> > already in gitlab.freedesktop.org to test the driver on several
> > generations of the hardware.
> >
> > Signed-off-by: Tomeu Vizoso
> > Signed-off-by: Helen Koike
> >
> > ---
> >
> > Hello,
> >
> > I'm re-spining this patch sent originally by Tomeu.
> >
> > This is meant to be an auxiliary tool where developers and
> > maintainers can just submit their code to fdo and see if
> > tests passes, than they can decide if it is worthy merging
> > it or not.
> >
> > This tool has proven its value on the Mesa community
> > and it can bring a lot of value here too.
> >
> > Please review and let me know your thoughts.
> >
> > You can also see this patch on
> > https://gitlab.freedesktop.org/helen.fornazier/linux/-/tree/drm-ci-tests
> >
> > Thanks!
> >
> > v2:
> > - Fix names of result expectation files to match SoC
> > - Don't execute tests that are going to skip on all boards
> >
> > v3:
> > - Remove tracking of dmesg output during test execution
> >
> > v4:
> > - Move up to drivers/gpu/drm
> > - Add support for a bunch of other drivers
> > - Explain how to incorporate fixes for CI from a
> > ${TARGET_BRANCH}-external-fixes branch
> > - Remove tests that pass from expected results file, to reduce the
> > size of in-tree files
> > - Add docs about how to deal with outages in automated testing labs
> > - Specify the exact SHA of the CI scripts to be used
> >
> > v5:
> > - Remove unneeded skips from Meson expectations file
> > - Use a more advanced runner that detects flakes automatically
> > - Use a more succint format for the expectations
> > - Run many more tests (and use sharding to finish in time)
> > - Use skip lists to avoid hanging machines
> > - Add some build testing
> > - Build IGT in each pipeline for faster uprevs
> > - List failures in the GitLab UI
> >
> > v6:
> > - Rebase on top of latest drm-next
> > - Lower priority of LAVA jobs to not impact Mesa CI as much
> > - Update docs
> >
> > v7:
> > - Rebase on top of latest drm-next
> >
> > v8:
> > - Move all files specific to testing the kernel into the kernel tree
> > (thus I have dropped the r-bs I had collected so far)
> > - Uprev Gitlab CI infrastructure scripts to the latest from Mesa
> > - Add MAINTAINERS entry
> > - Fix boot on MT8173 by adding some Kconfigs that are now needed
> > - Link to the docs from index.rst and hard-wrap the file
> >
> > v9:
> > - Only automatically run the pipelines for merge requests
> > - Switch to zstd for the build artifacts to align with Mesa
> > - Add Qcom USB PHYs to config as they are now =m in the defconfig
> >
> > v10:
> > - Include ci yml files from mesa/mesa (where the development is
> > current active) instead of a spin off project.
> > - Uprev Gitlab CI infrastructure scripts to the latest from Mesa
> > - Update MAINTAINERS entry
> > - Uprev igt tool
> > - add LAVA_JOB_PRIORITY: 30
> > - pipeline example:
> > https://gitlab.freedesktop.org/helen.fornazier/linux/-/pipelines/940506
> > ---
> > Documentation/gpu/automated_testing.rst | 144 +
> > Documentation/gpu/index.rst |1 +
> > MAINTAINERS |8 +
> > drivers/gpu/drm/ci/arm.config | 69 +
> > drivers/gpu/drm/ci/arm64.config | 199 ++
> > drivers/gpu/drm/ci/build-igt.sh | 35 +
> > drivers/gpu/drm/ci/build.sh | 157 +
> > drivers/gpu/drm/ci/build.yml | 110 +
> > drivers/gpu/drm/ci/check-patch.py | 57 +
> > drivers/gpu/drm/ci/container.yml | 61 +
> > drivers/gpu/drm/ci/gitlab-ci.yml | 252 ++
> > drivers/gpu/drm/ci/igt_runner.sh | 77 +
> > drivers/gpu/drm/ci/image-tags.yml | 15 +
> > drivers/gpu/drm/ci/lava-submit.sh | 57 +
> > drivers/gpu/drm/ci/static-checks.yml | 12 +
> > drivers/gpu/drm/ci/test.yml
Re: [PATCH v10] drm: Add initial ci/ subdirectory
On Thu, Jul 20, 2023 at 8:27 AM Helen Koike wrote:
>
> From: Tomeu Vizoso
>
> Developers can easily execute several tests on different devices
> by just pushing their branch to their fork in a repository hosted
> on gitlab.freedesktop.org which has an infrastructure to run jobs
> in several runners and farms with different devices.
>
> There are also other automated tools that uprev dependencies,
> monitor the infra, and so on that are already used by the Mesa
> project, and we can reuse them too.
>
> Also, store expectations about what the DRM drivers are supposed
> to pass in the IGT test suite. By storing the test expectations
> along with the code, we can make sure both stay in sync with each
> other so we can know when a code change breaks those expectations.
>
> Also, include a configuration file that points to the out-of-tree
> CI scripts.
>
> This will allow all contributors to drm to reuse the infrastructure
> already in gitlab.freedesktop.org to test the driver on several
> generations of the hardware.
>
> Signed-off-by: Tomeu Vizoso
> Signed-off-by: Helen Koike
>
> ---
>
> Hello,
>
> I'm re-spining this patch sent originally by Tomeu.
>
> This is meant to be an auxiliary tool where developers and
> maintainers can just submit their code to fdo and see if
> tests passes, than they can decide if it is worthy merging
> it or not.
>
> This tool has proven its value on the Mesa community
> and it can bring a lot of value here too.
>
> Please review and let me know your thoughts.
>
> You can also see this patch on
> https://gitlab.freedesktop.org/helen.fornazier/linux/-/tree/drm-ci-tests
>
> Thanks!
>
> v2:
> - Fix names of result expectation files to match SoC
> - Don't execute tests that are going to skip on all boards
>
> v3:
> - Remove tracking of dmesg output during test execution
>
> v4:
> - Move up to drivers/gpu/drm
> - Add support for a bunch of other drivers
> - Explain how to incorporate fixes for CI from a
> ${TARGET_BRANCH}-external-fixes branch
> - Remove tests that pass from expected results file, to reduce the
> size of in-tree files
> - Add docs about how to deal with outages in automated testing labs
> - Specify the exact SHA of the CI scripts to be used
>
> v5:
> - Remove unneeded skips from Meson expectations file
> - Use a more advanced runner that detects flakes automatically
> - Use a more succint format for the expectations
> - Run many more tests (and use sharding to finish in time)
> - Use skip lists to avoid hanging machines
> - Add some build testing
> - Build IGT in each pipeline for faster uprevs
> - List failures in the GitLab UI
>
> v6:
> - Rebase on top of latest drm-next
> - Lower priority of LAVA jobs to not impact Mesa CI as much
> - Update docs
>
> v7:
> - Rebase on top of latest drm-next
>
> v8:
> - Move all files specific to testing the kernel into the kernel tree
> (thus I have dropped the r-bs I had collected so far)
> - Uprev Gitlab CI infrastructure scripts to the latest from Mesa
> - Add MAINTAINERS entry
> - Fix boot on MT8173 by adding some Kconfigs that are now needed
> - Link to the docs from index.rst and hard-wrap the file
>
> v9:
> - Only automatically run the pipelines for merge requests
> - Switch to zstd for the build artifacts to align with Mesa
> - Add Qcom USB PHYs to config as they are now =m in the defconfig
>
> v10:
> - Include ci yml files from mesa/mesa (where the development is
> current active) instead of a spin off project.
> - Uprev Gitlab CI infrastructure scripts to the latest from Mesa
> - Update MAINTAINERS entry
> - Uprev igt tool
> - add LAVA_JOB_PRIORITY: 30
> - pipeline example:
> https://gitlab.freedesktop.org/helen.fornazier/linux/-/pipelines/940506
> ---
> Documentation/gpu/automated_testing.rst | 144 +
> Documentation/gpu/index.rst |1 +
> MAINTAINERS |8 +
> drivers/gpu/drm/ci/arm.config | 69 +
> drivers/gpu/drm/ci/arm64.config | 199 ++
> drivers/gpu/drm/ci/build-igt.sh | 35 +
> drivers/gpu/drm/ci/build.sh | 157 +
> drivers/gpu/drm/ci/build.yml | 110 +
> drivers/gpu/drm/ci/check-patch.py | 57 +
> drivers/gpu/drm/ci/container.yml | 61 +
> drivers/gpu/drm/ci/gitlab-ci.yml | 252 ++
> drivers/gpu/drm/ci/igt_runner.sh | 77 +
> drivers/gpu/drm/ci/image-tags.yml | 15 +
> drivers/gpu/drm/ci/lava-submit.sh | 57 +
> drivers/gpu/drm/ci/static-checks.yml | 12 +
> drivers/gpu/drm/ci/test.yml | 335 ++
> drivers/gpu/drm/ci/testlist.txt | 2912 +
> drivers/gpu/drm/ci/x86_64.config | 111 +
> .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 22 +
> .../drm/ci/xfails/amdgpu-stoney-flakes.txt| 19 +
> .../gpu/drm/ci/xfails/
