[PATCH 0/3] drm/msm: Further expose UBWC tiling parameters
After testing, there are more parameters that we're programming which affect how UBWC tiles are laid out in memory and therefore affect the Mesa implementation of VK_EXT_host_image_copy [1], which includes a CPU implementation of tiling and detiling images. In particular we have: 1. ubwc_mode, which is used to enable level 1 bank swizzling to go back to UBWC 1.0 when the implementation supports UBWC 2.0. a610 sets this. 2. macrotile_mode, which we previously left as default but according to downstream we shouldn't for a680. 3. level2_swizzling_dis, which according to downstream has to be set differently for a663. I want as much as possible to avoid problems from people trying to upstream Mesa/kernel support not knowing what they're doing and blindly copying things, so let's make this very explicit that you must set the correct parameters in the kernel and then make sure that Mesa always gets the right parameters from the "source of truth" in the kernel by adding two new UAPI parameters. The Mesa MR has already been updated to use this if available. A secondary goal is to make the adreno settings look more like the MDSS settings, by combining ubwc_mode and level2_swizzling_dis into a single ubwc_swizzle parameter that matches the MDSS one. This will help with creating a single source of truth for all drivers later. The UAPI also matches this, and it makes the Mesa tiling and detiling implementation simpler/more straightforward. For more information on what all these parameters mean, see the comments I've added in the first commit and the giant comment in src/freedreno/fdl/fd6_tiled_memcpy.c I've added in [1]. Testing of the Mesa MR both with and without this series is appreciated, there are many different SoCs out there with different UBWC configurations and I cannot test them all. [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26578 Signed-off-by: Connor Abbott --- Connor Abbott (3): drm/msm: Update a6xx register XML drm/msm: Expand UBWC config setting drm/msm: Expose expanded UBWC config uapi drivers/gpu/drm/msm/adreno/a5xx_gpu.c |4 + drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 36 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c |6 + drivers/gpu/drm/msm/adreno/adreno_gpu.h |3 +- drivers/gpu/drm/msm/registers/adreno/a6xx.xml | 1617 - include/uapi/drm/msm_drm.h|2 + 6 files changed, 1644 insertions(+), 24 deletions(-) --- base-commit: c39e6f4f08c40710c15a372f5a29de7b84f47fd9 change-id: 20240701-msm-tiling-config-c5f222f5db1c Best regards, -- Connor Abbott
[PATCH 0/3] Correct WL-355608-A8 panel compatible
The previous patch adding support for this panel [1] referred to previously by
its serial number only. As discussed after the patch was committed, the
preference is to use the integrating device vendor and name in this
circumstance.
This series corrects the panel compatible to reflect the vendor (Anbernic,
already in the vendor prefix table), updates the NV3052C panel driver with the
new compatible, and lastly adds num-chipselects and sck-gpios to the DT binding
example, identified by make dt_bindings_check as required for bit-banged SPI
over GPIO lines.
Regards,
Ryan
[1] https://lore.kernel.org/dri-devel/20240530211415.44201-1-r...@testtoast.com/
Ryan Walklin (3):
dt-bindings: display: panel: Rename WL-355608-A8 panel
drm: panel: nv3052c: Correct WL-355608-A8 panel compatible
dt-bindings: display: panel: correct Anbernic RG35XX panel example
.../{wl-355608-a8.yaml => anbernic,rg35xx-panel.yaml} | 11 +++
drivers/gpu/drm/panel/panel-newvision-nv3052c.c | 2 +-
2 files changed, 8 insertions(+), 5 deletions(-)
rename Documentation/devicetree/bindings/display/panel/{wl-355608-a8.yaml =>
anbernic,rg35xx-panel.yaml} (76%)
--
2.45.2
[PATCH 0/3] Fix mst daisy chain light up issue after resume
Under DP mst daisy chain configuration, unplug one chained monitor during suspend and then resume, observe left connected monitor not light up. After analyzing, seems it's due to changing dpcd DP_MSTM_CTRL value after LT during reume. We used to defer handling UP request by disabling DP_UP_REQ_EN at the begining of resume process to avoid some problems. However, it turns out that it will cause problem on the hub if we change DP_UP_REQ_EN after LT. This series is trying to solve the problem by another way that we don't explicitly disable DP_UP_REQ_EN at source side. Instead, source should ignore the CSN event before source completeting topology probing during resume. Wayne Lin (3): drm/dp_mst: Fix all mstb marked as not probed after suspend/resume drm/dp_mst: Skip CSN if topology probing is not done yet drm/amd/display: Solve mst monitors blank out problem after resume drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++- drivers/gpu/drm/display/drm_dp_mst_topology.c | 15 +-- 2 files changed, 15 insertions(+), 3 deletions(-) -- 2.37.3
[PATCH 0/3] drm: panel: add support lincoln LCD197 panel
This patchset adds support for the Lincoln LCD197 1080x1920 DSI panel. Jerome Brunet (3): dt-bindings: vendor-prefixes: add prefix for lincoln dt-bindings: panel-simple-dsi: add lincoln LCD197 panel bindings drm/panel: add lincoln lcd197 support .../display/panel/panel-simple-dsi.yaml | 2 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-lincoln-lcd197.c | 333 ++ 5 files changed, 349 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-lincoln-lcd197.c -- 2.43.0
[PATCH 0/3] drm/mediatek: fixes for ovl_adaptor
The main fix is a possible memory leak on an early exit in the for_each_child_of_node() loop. That fix has been divided into a patch that can be backported (a simple of_node_put()), and another one that uses the scoped variant of the macro, removing the need for any of_node_put(). That prevents mistakes if new break/return instructions are added, but the macro might not be available in older kernels. When at it, an unused header has been dropped. Signed-off-by: Javier Carrasco --- Javier Carrasco (3): drm/mediatek: ovl_adaptor: drop unused mtk_crtc.h header drm/mediatek: ovl_adaptor: add missing of_node_put() drm/mediatek: ovl_adaptor: use scoped variant of for_each_child_of_node() drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- base-commit: f76698bd9a8ca01d3581236082d786e9a6b72bb7 change-id: 20240624-mtk_disp_ovl_adaptor_scoped-0702a6b23443 Best regards, -- Javier Carrasco
[PATCH 0/3] [CI] Extend Wa14019159160 and enable for ARL and DG2
From: John Harrison The context switch out workaround requires an extra piece on top. Also, it applies to more platforms. Signed-off-by: John Harrison John Harrison (3): drm/i915/arl: Enable Wa_14019159160 for ARL drm/i915/guc: Extend w/a 14019159160 drm/i915/dg2: Enable Wa_14019159160 for DG2 drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h | 1 + drivers/gpu/drm/i915/gt/uc/intel_guc.c| 3 ++- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 19 ++- 3 files changed, 13 insertions(+), 10 deletions(-) -- 2.43.2
Re: [PATCH 0/3] drm/panic: Fixes and graphical logo
Hi Maxime,
On Fri, Jun 14, 2024 at 10:35 AM Maxime Ripard wrote:
> On Fri, Jun 14, 2024 at 08:58:26AM GMT, Geert Uytterhoeven wrote:
> > Looks like the top commit of last drm-misc PR [1] is part of the
> > drm-misc-next branch. but not of the for-linux-next branch, while
> > Stephen pulls the latter.
> > Is that a drm-misc or a linux-next issue?
>
> This was a drm-misc issue, it should now be solved
Thanks, confirmed!
(and updated my .git/config for next renesas-drivers release again ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 0/3] drm/panic: Fixes and graphical logo
Hi, On Fri, Jun 14, 2024 at 08:58:26AM GMT, Geert Uytterhoeven wrote: > Hi Stephen and Maxime, > > On Fri, Jun 14, 2024 at 12:00 AM Stephen Rothwell > wrote: > > On Thu, 13 Jun 2024 11:48:15 +0200 Geert Uytterhoeven > > wrote: > > > > > Has the drm-misc git repo moved? > > > > > > > > It moved to gitlab recently, the new url is > > > > g...@gitlab.freedesktop.org:drm/misc/kernel.git > > > > > > Time to tell Stephen... > > > > linux-next has been using that URL for some time. > > OK. > > Looks like the top commit of last drm-misc PR [1] is part of the > drm-misc-next branch. but not of the for-linux-next branch, while > Stephen pulls the latter. > Is that a drm-misc or a linux-next issue? This was a drm-misc issue, it should now be solved Maxime signature.asc Description: PGP signature
Re: [PATCH 0/3] drm/panic: Fixes and graphical logo
Hi Stephen and Maxime,
On Fri, Jun 14, 2024 at 12:00 AM Stephen Rothwell wrote:
> On Thu, 13 Jun 2024 11:48:15 +0200 Geert Uytterhoeven
> wrote:
> > > > Has the drm-misc git repo moved?
> > >
> > > It moved to gitlab recently, the new url is
> > > g...@gitlab.freedesktop.org:drm/misc/kernel.git
> >
> > Time to tell Stephen...
>
> linux-next has been using that URL for some time.
OK.
Looks like the top commit of last drm-misc PR [1] is part of the
drm-misc-next branch. but not of the for-linux-next branch, while
Stephen pulls the latter.
Is that a drm-misc or a linux-next issue?
Thanks!
[1] a13aaf157467e694a3824d81304106b58d4c20d6
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 0/3] drm/panic: Fixes and graphical logo
Hi Geert, On Thu, 13 Jun 2024 11:48:15 +0200 Geert Uytterhoeven wrote: > > > > Has the drm-misc git repo moved? > > > > It moved to gitlab recently, the new url is > > g...@gitlab.freedesktop.org:drm/misc/kernel.git > > Time to tell Stephen... linux-next has been using that URL for some time. -- Cheers, Stephen Rothwell pgpVtS_J_n_oa.pgp Description: OpenPGP digital signature
Re: [PATCH 0/3] drm/panic: Fixes and graphical logo
On 13/06/2024 11:32, Geert Uytterhoeven wrote:
Hi Jocelyn,
On Thu, Jun 13, 2024 at 10:38 AM Jocelyn Falempe wrote:
On 12/06/2024 15:54, Geert Uytterhoeven wrote:
If drm/panic is enabled, a user-friendly message is shown on screen when
a kernel panic occurs, together with an ASCII art penguin logo.
Of course we can do better ;-)
Hence this patch series extends drm/panic to draw the monochrome
graphical boot logo, when available, preceded by the customary fix.
Thanks for your patch.
I've tested it, and it works great.
Thank you!
You need to rebase your series on top of drm-misc-next, because it
conflicts with a series I pushed last week:
https://patchwork.freedesktop.org/series/134286/
I had seen that you said you had pushed this to drm-misc-next[1]
before I posted my series, but couldn't find the actual commits in
drm-misc/for-linux-next, which is still at commit dfc1209ed5a3861c
("arm/komeda: Remove all CONFIG_DEBUG_FS conditional compilations",
so I assumed you just forgot to push?
However, the latest pull request[2] does include them, while linux-next
does not.
Has the drm-misc git repo moved?
It moved to gitlab recently, the new url is
g...@gitlab.freedesktop.org:drm/misc/kernel.git
and the drm_panic kmsg screen commit is there:
https://gitlab.freedesktop.org/drm/misc/kernel/-/commits/drm-misc-next?ref_type=heads
Thanks!
[1] https://lore.kernel.org/all/3649ff15-df2b-49ba-920f-c418355d7...@redhat.com/
[2] "[PULL] drm-misc-next"
https://lore.kernel.org/all/20240613-cicada-of-infinite-unity-0955ca@houat/
Gr{oetje,eeting}s,
Geert
Re: [PATCH 0/3] drm/panic: Fixes and graphical logo
Hi Jocelyn,
CC sfr
On Thu, Jun 13, 2024 at 11:41 AM Jocelyn Falempe wrote:
> On 13/06/2024 11:32, Geert Uytterhoeven wrote:
> > On Thu, Jun 13, 2024 at 10:38 AM Jocelyn Falempe
> > wrote:
> >> On 12/06/2024 15:54, Geert Uytterhoeven wrote:
> >>> If drm/panic is enabled, a user-friendly message is shown on screen when
> >>> a kernel panic occurs, together with an ASCII art penguin logo.
> >>> Of course we can do better ;-)
> >>> Hence this patch series extends drm/panic to draw the monochrome
> >>> graphical boot logo, when available, preceded by the customary fix.
> >>
> >> Thanks for your patch.
> >>
> >> I've tested it, and it works great.
> >
> > Thank you!
> >
> >> You need to rebase your series on top of drm-misc-next, because it
> >> conflicts with a series I pushed last week:
> >> https://patchwork.freedesktop.org/series/134286/
> >
> > I had seen that you said you had pushed this to drm-misc-next[1]
> > before I posted my series, but couldn't find the actual commits in
> > drm-misc/for-linux-next, which is still at commit dfc1209ed5a3861c
> > ("arm/komeda: Remove all CONFIG_DEBUG_FS conditional compilations",
> > so I assumed you just forgot to push?
> > However, the latest pull request[2] does include them, while linux-next
> > does not.
> >
> > Has the drm-misc git repo moved?
>
> It moved to gitlab recently, the new url is
> g...@gitlab.freedesktop.org:drm/misc/kernel.git
Time to tell Stephen...
> and the drm_panic kmsg screen commit is there:
>
> https://gitlab.freedesktop.org/drm/misc/kernel/-/commits/drm-misc-next?ref_type=heads
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 0/3] drm/panic: Fixes and graphical logo
Hi Jocelyn,
On Thu, Jun 13, 2024 at 10:38 AM Jocelyn Falempe wrote:
> On 12/06/2024 15:54, Geert Uytterhoeven wrote:
> > If drm/panic is enabled, a user-friendly message is shown on screen when
> > a kernel panic occurs, together with an ASCII art penguin logo.
> > Of course we can do better ;-)
> > Hence this patch series extends drm/panic to draw the monochrome
> > graphical boot logo, when available, preceded by the customary fix.
>
> Thanks for your patch.
>
> I've tested it, and it works great.
Thank you!
> You need to rebase your series on top of drm-misc-next, because it
> conflicts with a series I pushed last week:
> https://patchwork.freedesktop.org/series/134286/
I had seen that you said you had pushed this to drm-misc-next[1]
before I posted my series, but couldn't find the actual commits in
drm-misc/for-linux-next, which is still at commit dfc1209ed5a3861c
("arm/komeda: Remove all CONFIG_DEBUG_FS conditional compilations",
so I assumed you just forgot to push?
However, the latest pull request[2] does include them, while linux-next
does not.
Has the drm-misc git repo moved?
Thanks!
[1] https://lore.kernel.org/all/3649ff15-df2b-49ba-920f-c418355d7...@redhat.com/
[2] "[PULL] drm-misc-next"
https://lore.kernel.org/all/20240613-cicada-of-infinite-unity-0955ca@houat/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 0/3] drm/panic: Fixes and graphical logo
On 12/06/2024 15:54, Geert Uytterhoeven wrote: Hi all, If drm/panic is enabled, a user-friendly message is shown on screen when a kernel panic occurs, together with an ASCII art penguin logo. Of course we can do better ;-) Hence this patch series extends drm/panic to draw the monochrome graphical boot logo, when available, preceded by the customary fix. Thanks for your patch. I've tested it, and it works great. You need to rebase your series on top of drm-misc-next, because it conflicts with a series I pushed last week: https://patchwork.freedesktop.org/series/134286/ This rebase should simplify the draw_logo_mono() function. This has been tested with rcar-du. Thanks for your comments! Geert Uytterhoeven (3): drm/panic: Fix off-by-one logo size checks drm/panic: Rename logo to logo_ascii drm/panic: Add support for drawing a monochrome graphical logo drivers/gpu/drm/drm_panic.c | 81 + drivers/video/logo/Kconfig | 2 + 2 files changed, 75 insertions(+), 8 deletions(-)
[PATCH 0/3] drm/panic: Fixes and graphical logo
Hi all,
If drm/panic is enabled, a user-friendly message is shown on screen when
a kernel panic occurs, together with an ASCII art penguin logo.
Of course we can do better ;-)
Hence this patch series extends drm/panic to draw the monochrome
graphical boot logo, when available, preceded by the customary fix.
This has been tested with rcar-du.
Thanks for your comments!
Geert Uytterhoeven (3):
drm/panic: Fix off-by-one logo size checks
drm/panic: Rename logo to logo_ascii
drm/panic: Add support for drawing a monochrome graphical logo
drivers/gpu/drm/drm_panic.c | 81 +
drivers/video/logo/Kconfig | 2 +
2 files changed, 75 insertions(+), 8 deletions(-)
--
2.34.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH 0/3] CMRR patch fixes
Address following issues regarding CMRR 1. Describe target_rr_divider in struct drm_dp_as_sdp. 2. Compute vrr_vsync params when vrr.enable is set. 3. Use required macro to avoid overflow. Mitul Golani (3): drm/dp: Describe target_rr_divider in struct drm_dp_as_sdp drm/i915/display: Send vrr vsync params whne vrr is enabled drm/i915/display: Update calculation to avoid any overflow drivers/gpu/drm/i915/display/intel_vrr.c | 12 +++- include/drm/display/drm_dp_helper.h | 1 + 2 files changed, 8 insertions(+), 5 deletions(-) -- 2.45.2
[PATCH 0/3] drm/mst & drm/amd/display: switch to using guid_t
We have a guid_t type for GUIDs, switch to using it instead of hand rolling buffers. Convert to guid_gen() in separate patches to pinpoint the functional changes. BR, Jani. Jani Nikula (3): drm/mst: switch to guid_t type for GUID drm/mst: switch to guid_gen() to generate valid GUIDs drm/amd/display: switch to guid_gen() to generate valid GUIDs .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 --- drivers/gpu/drm/display/drm_dp_mst_topology.c | 67 ++- include/drm/display/drm_dp_mst_helper.h | 12 ++-- 3 files changed, 52 insertions(+), 50 deletions(-) -- 2.39.2
[PATCH 0/3] drm/panic: Add a kmsg dump screen
Add a kmsg dump option, which will display the last lines of kmsg, and should be similar to fbcon. Add a Kconfig choice for the panic screen, so that the user can choose between this new kmsg dump, or the userfriendly option. Patch 1-2 are the same as https://patchwork.freedesktop.org/series/133963/ and are here to avoid conflicts. Jocelyn Falempe (3): drm/panic: only draw the foreground color in drm_panic_blit() drm/panic: Add a set_pixel() callback to drm_scanout_buffer drm/panic: Add a kmsg dump screen drivers/gpu/drm/Kconfig | 21 +++ drivers/gpu/drm/drm_panic.c | 322 +++- include/drm/drm_panic.h | 9 + 3 files changed, 241 insertions(+), 111 deletions(-) base-commit: 86266829ea755f737762ebda614c59b136c8feac -- 2.45.1
[PATCH 0/3] amd, i915, xe: drop redundant warnings from driver makefiles
I'm sending these together, as they're related, and almost identical, but I expect them to be merged individually to each driver. BR, Jani. Jani Nikula (3): drm/i915: drop redundant W=1 warnings from Makefile drm/xe: drop redundant W=1 warnings from Makefile drm/amdgpu: drop redundant W=1 warnings from Makefile drivers/gpu/drm/amd/amdgpu/Makefile | 18 +- drivers/gpu/drm/i915/Makefile | 25 + drivers/gpu/drm/xe/Makefile | 25 + 3 files changed, 3 insertions(+), 65 deletions(-) -- 2.39.2
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Thu Feb 29, 2024 at 12:55 AM EET, Helen Koike wrote: > Dear Kernel Community, > > This patch introduces a `.gitlab-ci` file along with a `ci/` folder, defining > a > basic test pipeline triggered by code pushes to a GitLab-CI instance. This > initial version includes static checks (checkpatch and smatch for now) and > build > tests across various architectures and configurations. It leverages an > integrated cache for efficient build times and introduces a flexible > 'scenarios' > mechanism for subsystem-specific extensions. > > tl;dr: check this video to see a quick demo: https://youtu.be/TWiTjhjOuzg, > but don't forget to check the "Motivation for this work" below. Your feedback, > whether a simple thumbs up or down, is crucial to determine if it is > worthwhile > to pursue this initiative. > > GitLab is an Open Source platform that includes integrated CI/CD. The pipeline > provided in this patch is designed to work out-of-the-box with any GitLab > instance, including the gitlab.com Free Tier. If you reach the limits of the > Free Tier, consider using community instances like > https://gitlab.freedesktop.org/. > Alternatively, you can set up a local runner for more flexibility. The > bootstrap-gitlab-runner.sh script included with this patch simplifies this > process, enabling you to run tests on your preferred infrastructure, including > your own machine. > > For detailed information, please refer to the documentation included in the > patch, or check the rendered version here: > https://koike.pages.collabora.com/-/linux/-/jobs/298498/artifacts/artifacts/Documentation-output/ci/gitlab-ci/gitlab-ci.html > . > > > Motivation for this Work > > > We all know tests are a major topic in the community, so let's mention the > specificities of this approach: > > 1. **Built-in User Interface:** GitLab CI/CD is growing in popularity and has > an > user-friendly interface. Our experience with the upstream DRM-CI in the kernel > tree (see this blog post > [https://www.collabora.com/news-and-blog/blog/2024/02/08/drm-ci-a-gitlab-ci-pipeline-for-linux-kernel-testing/] > ) > has provided insights into how such a system can benefit the wider community. > > 2. **Distributed Infrastructure:** > The proposed GitLab-CI pipeline is designed with a distributed infrastructure > model, being possible to run in any gitlab instance. > > 3. **Reduce regressions:** Fostering a culture where people habitually run > validated tests and post their results can prevent many issues in post-merge > tests. > > 4. **Collaborative Testing Environment:** The kernel community is already > engaged in numerous testing efforts, including various GitLab-CI pipelines > such > as DRM-CI, which I maintain, along with other solutions like KernelCI and > BPF-CI. This proposal is designed to further stimulate contributions to the > evolving testing landscape. Our goal is to establish a comprehensive suite of > common tools and files. > > 5. **Ownership of QA:** > Discrepancies between kernel code and outdated tests often lead to > misattributed > failures, complicating regression tracking. This issue, often arising from > neglected or deprioritized test updates, creates uncertainty about the source > of > failures. Adopting an "always green pipeline" approach, as detailed in this > patch's documentation, encourages timely maintenance and validation of tests. > This ensures that testing accurately reflects the current state of the kernel, > thereby improving the effectiveness of our QA processes. > > Additionally, if we discover that this method isn't working for us, we can > easily remove it from the codebase, as it is primarily contained within the > ci/ > folder. Not to criticize but I can do tests I ever want with either Github or Gitlab simply by bootstrapping BuildRoot on top of whatever the CI runner has. So I essentially need just enough deps to make a BR build, and that's it. And e.g. could run x86 tests on ARM ISA runner with zero issues. And can even have emulated TPM chip in the QEMU VM by building swtpm. I had this for some time running actually Gitlab runner. It does not currently build QEMU but then it also did that: https://gitlab.com/jarkkojs/linux-tpmdd-test Essentially just executing this sequence: git clone https://gitlab.com/jarkkojs/linux-tpmdd-test.git cd linux-tpmdd-test cmake -Bbuild && make -Cbuild buildroot-prepare make -Cbuild/buildroot/build build/buildroot/build/images/run-tests.sh I use TCL's "expect" to make conclusions from the output :-) I'm assuming that this has a bigger point that I can understand right now but makes me a bit puzzled given that it is quite trivial problem to my understanding (if you want to pursue to it). Like one work week maybe but not more than that... Especially it feels weird that it needs kernel to be patched at all and when I did read the motivation but it has sort of whitepaperish stuff that does not really explain me the edge of this
[PATCH 0/3] A bunch of struct removals
From: "Dr. David Alan Gilbert" A bunch of deadcode/struct removals in drm/amd Signed-off-by: Dr. David Alan Gilbert Dr. David Alan Gilbert (3): drm/amdgpu: remove unused struct 'hqd_registers' drm/amd/display: remove unused struct 'aux_payloads' drm/amd/display: remove unused struct 'dc_reg_sequence' drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 38 --- drivers/gpu/drm/amd/display/dc/dc_helper.c| 5 --- .../amd/display/dc/link/protocols/link_ddc.c | 4 -- 3 files changed, 47 deletions(-) -- 2.45.1
[PATCH 0/3] Improve drm printer code
We already have some drm printk functions that need to duplicate a code to get a similar format of the final result, for example: [ ] :00:00.0: [drm:foo] bar [ ] :00:00.0: [drm] foo bar [ ] :00:00.0: [drm] *ERROR* foo Add a generic __drm_dev_vprintk() function that can format the final message like all other existing function do and allows us to keep the formatting code in one place. Above also allows to improve drm_dbg_printer() that today lacks of outputing symbolic name of the caller, like drm_dbg() does. Cc: Maxime Ripard Cc: Jani Nikula Michal Wajdeczko (3): drm/print: Add generic drm dev printk function drm/print: Improve drm_dbg_printer drm/i915: Don't use __func__ as prefix for drm_dbg_printer drivers/gpu/drm/drm_print.c| 50 -- drivers/gpu/drm/i915/gt/intel_reset.c | 2 +- drivers/gpu/drm/i915/gt/selftest_context.c | 2 +- include/drm/drm_print.h| 5 +++ 4 files changed, 34 insertions(+), 25 deletions(-) -- 2.43.0
Re: [PATCH 0/3] HW layer refactor
Applied to drm-misc-next On 15.05.2024 13:30, Jacek Lawrynowicz wrote: > The NPU device consists of two parts: NPU buttress and NPU IP. > Buttress is a platform specific part that integrates the NPU IP with > the CPU. > NPU IP is the platform agnostic part that does the inference. > > This refactor enables support for multiple platforms using > a single NPU IP, so for example NPU IP 37XX could be integrated into > MTL and LNL platforms. > > Jacek Lawrynowicz (1): > accel/ivpu: Replace wake_thread with kfifo > > Wachowski, Karol (2): > accel/ivpu: Split IP and buttress headers > accel/ivpu: Split IP and buttress code > > drivers/accel/ivpu/Makefile |5 +- > drivers/accel/ivpu/ivpu_debugfs.c |2 +- > drivers/accel/ivpu/ivpu_drv.c | 32 +- > drivers/accel/ivpu/ivpu_drv.h | 33 +- > drivers/accel/ivpu/ivpu_fw.c | 20 +- > drivers/accel/ivpu/ivpu_hw.c | 313 + > drivers/accel/ivpu/ivpu_hw.h | 196 ++-- > drivers/accel/ivpu/ivpu_hw_37xx.c | 1070 -- > drivers/accel/ivpu/ivpu_hw_37xx_reg.h | 72 -- > drivers/accel/ivpu/ivpu_hw_40xx.c | 1255 - > drivers/accel/ivpu/ivpu_hw_40xx_reg.h | 94 +- > drivers/accel/ivpu/ivpu_hw_btrs.c | 881 +++ > drivers/accel/ivpu/ivpu_hw_btrs.h | 46 + > drivers/accel/ivpu/ivpu_hw_btrs_lnl_reg.h | 108 ++ > drivers/accel/ivpu/ivpu_hw_btrs_mtl_reg.h | 83 ++ > drivers/accel/ivpu/ivpu_hw_ip.c | 1174 +++ > drivers/accel/ivpu/ivpu_hw_ip.h | 36 + > drivers/accel/ivpu/ivpu_ipc.c | 17 +- > drivers/accel/ivpu/ivpu_ipc.h |4 +- > drivers/accel/ivpu/ivpu_job.c |2 +- > 20 files changed, 2799 insertions(+), 2644 deletions(-) > create mode 100644 drivers/accel/ivpu/ivpu_hw.c > delete mode 100644 drivers/accel/ivpu/ivpu_hw_37xx.c > delete mode 100644 drivers/accel/ivpu/ivpu_hw_40xx.c > create mode 100644 drivers/accel/ivpu/ivpu_hw_btrs.c > create mode 100644 drivers/accel/ivpu/ivpu_hw_btrs.h > create mode 100644 drivers/accel/ivpu/ivpu_hw_btrs_lnl_reg.h > create mode 100644 drivers/accel/ivpu/ivpu_hw_btrs_mtl_reg.h > create mode 100644 drivers/accel/ivpu/ivpu_hw_ip.c > create mode 100644 drivers/accel/ivpu/ivpu_hw_ip.h > > -- > 2.43.2
[PATCH 0/3] drm/vkms: Reimplement line-per-line pixel conversion for writeback
This series re-introduce the line-by-line algorithm. This is simpler than the read part because no rotation/translations are involved. PATCH 1/2 is the re-introduction itself PATCH 2/2 is a proposition to avoid code repetition using a "big" macro. This series depends on [1]. [1]: https://lore.kernel.org/all/20240516-b4-new-color-formats-v1-0-74cf9fe07...@bootlin.com/ Signed-off-by: Louis Chauvet --- Louis Chauvet (3): drm/vkms: Re-introduce line-by-line algorithm for writeback drm/vkms: Add a macro for write_line functions drm/vkms: Add support for XRGB2101010 drivers/gpu/drm/vkms/vkms_composer.c | 18 ++ drivers/gpu/drm/vkms/vkms_drv.h | 20 --- drivers/gpu/drm/vkms/vkms_formats.c | 104 +++--- drivers/gpu/drm/vkms/vkms_formats.h | 2 +- drivers/gpu/drm/vkms/vkms_writeback.c | 6 +- 5 files changed, 105 insertions(+), 45 deletions(-) --- base-commit: 335e3c4175a113d1f5b089c4eb1738590d193fbc change-id: 20240222-writeback_line_by_line-8475605b1d5c Best regards, -- Louis Chauvet
Re: [PATCH 0/3] dt-bindings: display: panel: constrain 'reg'
On 14/05/2024 11:07, Krzysztof Kozlowski wrote: On 14/05/2024 10:44, Neil Armstrong wrote: On 13/05/2024 18:41, Dmitry Baryshkov wrote: On Mon, 13 May 2024 at 16:17, Rob Herring wrote: On Thu, May 09, 2024 at 11:42:50AM +0200, Krzysztof Kozlowski wrote: Hi, Cleanups for display panel bindings. Rob, maybe you could take entire set if it applies? I based it on linux-next, so letl me know if I need to rebase on your for-next. Applied. These 2 don't exist in my tree: It's most likely fine, but was there an ack from drm-misc maintainers? Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml Because those were added to drm-misc during the last cycle. So ideally the patch should have gone through drm-misc. Exact there's a conflict on today's next, Rob can you drop them so I can apply them via drm-misc ? It's almost the first time I see bindings picked up via drm-misc. Is this an exception or rather new trend (which would be awesome as this is what we prefer usually)? I usually pick up bindings along drivers like other subsystems, and when reviewed I take independent bindings fixes aswell when rob doesn't pick them before. Neil Best regards, Krzysztof
[PATCH 0/3] HW layer refactor
The NPU device consists of two parts: NPU buttress and NPU IP. Buttress is a platform specific part that integrates the NPU IP with the CPU. NPU IP is the platform agnostic part that does the inference. This refactor enables support for multiple platforms using a single NPU IP, so for example NPU IP 37XX could be integrated into MTL and LNL platforms. Jacek Lawrynowicz (1): accel/ivpu: Replace wake_thread with kfifo Wachowski, Karol (2): accel/ivpu: Split IP and buttress headers accel/ivpu: Split IP and buttress code drivers/accel/ivpu/Makefile |5 +- drivers/accel/ivpu/ivpu_debugfs.c |2 +- drivers/accel/ivpu/ivpu_drv.c | 32 +- drivers/accel/ivpu/ivpu_drv.h | 33 +- drivers/accel/ivpu/ivpu_fw.c | 20 +- drivers/accel/ivpu/ivpu_hw.c | 313 + drivers/accel/ivpu/ivpu_hw.h | 196 ++-- drivers/accel/ivpu/ivpu_hw_37xx.c | 1070 -- drivers/accel/ivpu/ivpu_hw_37xx_reg.h | 72 -- drivers/accel/ivpu/ivpu_hw_40xx.c | 1255 - drivers/accel/ivpu/ivpu_hw_40xx_reg.h | 94 +- drivers/accel/ivpu/ivpu_hw_btrs.c | 881 +++ drivers/accel/ivpu/ivpu_hw_btrs.h | 46 + drivers/accel/ivpu/ivpu_hw_btrs_lnl_reg.h | 108 ++ drivers/accel/ivpu/ivpu_hw_btrs_mtl_reg.h | 83 ++ drivers/accel/ivpu/ivpu_hw_ip.c | 1174 +++ drivers/accel/ivpu/ivpu_hw_ip.h | 36 + drivers/accel/ivpu/ivpu_ipc.c | 17 +- drivers/accel/ivpu/ivpu_ipc.h |4 +- drivers/accel/ivpu/ivpu_job.c |2 +- 20 files changed, 2799 insertions(+), 2644 deletions(-) create mode 100644 drivers/accel/ivpu/ivpu_hw.c delete mode 100644 drivers/accel/ivpu/ivpu_hw_37xx.c delete mode 100644 drivers/accel/ivpu/ivpu_hw_40xx.c create mode 100644 drivers/accel/ivpu/ivpu_hw_btrs.c create mode 100644 drivers/accel/ivpu/ivpu_hw_btrs.h create mode 100644 drivers/accel/ivpu/ivpu_hw_btrs_lnl_reg.h create mode 100644 drivers/accel/ivpu/ivpu_hw_btrs_mtl_reg.h create mode 100644 drivers/accel/ivpu/ivpu_hw_ip.c create mode 100644 drivers/accel/ivpu/ivpu_hw_ip.h -- 2.43.2
[PATCH 0/3] drm/rockchip: vop2: Add VP clock resets support
The clock reset must be used when the VOP is configured. Skipping it can put the VOP in an unknown state where the HDMI signal is either lost or not matching the selected mode. This adds support for rk3588(s) based SoCs. Detlev Casanova (3): drm/rockchip: vop2: Add clock resets support arm64: dts: rockchip: Add VOP clock resets for rk3588s dt-bindings: display: vop2: Add VP clock resets .../display/rockchip/rockchip-vop2.yaml | 27 + arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 8 + drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 30 +++ 3 files changed, 65 insertions(+) -- 2.43.2
Re: [PATCH 0/3] dt-bindings: display: panel: constrain 'reg'
On 14/05/2024 10:44, Neil Armstrong wrote: > On 13/05/2024 18:41, Dmitry Baryshkov wrote: >> On Mon, 13 May 2024 at 16:17, Rob Herring wrote: >>> >>> On Thu, May 09, 2024 at 11:42:50AM +0200, Krzysztof Kozlowski wrote: Hi, Cleanups for display panel bindings. Rob, maybe you could take entire set if it applies? I based it on linux-next, so letl me know if I need to rebase on your for-next. >>> >>> Applied. These 2 don't exist in my tree: >> >> It's most likely fine, but was there an ack from drm-misc maintainers? >> >>> Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml >>> Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml >> >> Because those were added to drm-misc during the last cycle. So ideally >> the patch should have gone through drm-misc. >> > > Exact there's a conflict on today's next, Rob can you drop them so I can > apply them via drm-misc ? It's almost the first time I see bindings picked up via drm-misc. Is this an exception or rather new trend (which would be awesome as this is what we prefer usually)? Best regards, Krzysztof
Re: [PATCH 0/3] dt-bindings: display: panel: constrain 'reg'
On 13/05/2024 18:41, Dmitry Baryshkov wrote: On Mon, 13 May 2024 at 16:17, Rob Herring wrote: On Thu, May 09, 2024 at 11:42:50AM +0200, Krzysztof Kozlowski wrote: Hi, Cleanups for display panel bindings. Rob, maybe you could take entire set if it applies? I based it on linux-next, so letl me know if I need to rebase on your for-next. Applied. These 2 don't exist in my tree: It's most likely fine, but was there an ack from drm-misc maintainers? Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml Because those were added to drm-misc during the last cycle. So ideally the patch should have gone through drm-misc. Exact there's a conflict on today's next, Rob can you drop them so I can apply them via drm-misc ? Thanks, Neil
Re: [PATCH 0/3] dt-bindings: display: panel: constrain 'reg'
On Mon, 13 May 2024 at 16:17, Rob Herring wrote: > > On Thu, May 09, 2024 at 11:42:50AM +0200, Krzysztof Kozlowski wrote: > > Hi, > > > > Cleanups for display panel bindings. > > > > Rob, maybe you could take entire set if it applies? I based it on > > linux-next, so letl me know if I need to rebase on your for-next. > > Applied. These 2 don't exist in my tree: It's most likely fine, but was there an ack from drm-misc maintainers? > Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml > Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml Because those were added to drm-misc during the last cycle. So ideally the patch should have gone through drm-misc. -- With best wishes Dmitry
Re: [PATCH 0/3] dt-bindings: display: panel: constrain 'reg'
On Thu, May 09, 2024 at 11:42:50AM +0200, Krzysztof Kozlowski wrote: > Hi, > > Cleanups for display panel bindings. > > Rob, maybe you could take entire set if it applies? I based it on > linux-next, so letl me know if I need to rebase on your for-next. Applied. These 2 don't exist in my tree: Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml Rob
[PATCH 0/3] drm/loongson: Introduce component framework support
Introduce the component framework to bind childs and siblings, for better modularity and paper over the deferral probe problems if it need to attach exterinal module someday. Hardware units come with PCI(e) are actually all ready to drive, but there has some board specific modules will return -EPROBE_DEFER. We need all other submodules ready to attach before we can register the drm device to userspace. The idea is to devide the exterinal module dependent part and exterinal module independent part clearly, for example, the display controller and the builtin GPIO-I2C just belong to exterinal module independent part. While the output is belong to exterinal module dependent part. Also for better reflecting the hardware, we intend to abstract the output ports as child devices. The output ports may consists of encoder phy and level shift, while the GPU and VPU are standalone siblings. As those units are relative separate hardware units from display controller itself. By design, the display controller PCI(e) is selected as the component master, gpio-i2c go with master. The manually created virtual child device are functional as agents for the master, it could return the -EPROBE_DEFER back to the component core. This allows the master don't have to tear down everything, the majority setups work can be preserved. The potential cyclic dependency problem can be solved with such framework. Sui Jingfeng (3): drm/loongson: Add helpers for creating subdevice drm/loongson: Introduce component framework support drm/loongson: Refactor lsdc device initialize and the output port drivers/gpu/drm/loongson/Makefile | 1 + drivers/gpu/drm/loongson/loongson_device.c| 42 drivers/gpu/drm/loongson/loongson_module.c| 17 +- drivers/gpu/drm/loongson/loongson_module.h| 1 + drivers/gpu/drm/loongson/lsdc_drv.c | 208 +++--- drivers/gpu/drm/loongson/lsdc_drv.h | 34 +-- drivers/gpu/drm/loongson/lsdc_output.c| 183 +++ drivers/gpu/drm/loongson/lsdc_output.h| 38 +++- drivers/gpu/drm/loongson/lsdc_output_7a1000.c | 3 +- drivers/gpu/drm/loongson/lsdc_output_7a2000.c | 15 +- 10 files changed, 422 insertions(+), 120 deletions(-) create mode 100644 drivers/gpu/drm/loongson/lsdc_output.c -- 2.34.1
[PATCH 0/3] dt-bindings: display: panel: constrain 'reg'
Hi, Cleanups for display panel bindings. Rob, maybe you could take entire set if it applies? I based it on linux-next, so letl me know if I need to rebase on your for-next. I actually do not know if devices affected here take more than one chip select or DSI virtual channel number. I assume DTS and examples are correct here. Worst case this can be fixed later - maxItems:2. Best regards, Krzysztof --- Krzysztof Kozlowski (3): dt-bindings: display: samsung,ams495qa01: add missing SPI properties ref dt-bindings: display: panel: constrain 'reg' in SPI panels dt-bindings: display: panel: constrain 'reg' in DSI panels Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml | 4 +++- .../devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml | 5 - .../devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml | 4 +++- Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml | 4 +++- .../devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml | 4 +++- .../devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml | 2 +- Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml | 5 - .../devicetree/bindings/display/panel/fascontek,fs035vg158.yaml | 3 +++ .../devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml | 5 - Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml | 4 +++- Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml | 3 ++- Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml | 4 +++- Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml | 3 +++ Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml | 3 ++- Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml | 4 +++- .../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 4 +++- .../devicetree/bindings/display/panel/innolux,ej030na.yaml | 4 +++- .../devicetree/bindings/display/panel/innolux,p097pfg.yaml | 4 +++- .../devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml | 3 ++- .../devicetree/bindings/display/panel/jdi,lpm102a188a.yaml | 4 +++- .../devicetree/bindings/display/panel/jdi,lt070me05000.yaml | 4 +++- .../devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml | 4 +++- .../devicetree/bindings/display/panel/leadtek,ltk035c5444t.yaml | 3 +++ .../devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml | 5 - .../devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml | 5 - Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml | 3 ++- Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml | 4 +++- .../devicetree/bindings/display/panel/lgphilips,lb035q02.yaml | 3 +++ Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml | 4 +++- .../devicetree/bindings/display/panel/newvision,nv3051d.yaml| 4 +++- .../devicetree/bindings/display/panel/novatek,nt35510.yaml | 5 - .../devicetree/bindings/display/panel/novatek,nt35950.yaml | 4 +++- .../devicetree/bindings/display/panel/novatek,nt36523.yaml | 4 +++- .../devicetree/bindings/display/panel/novatek,nt36672a.yaml | 4 +++- .../devicetree/bindings/display/panel/olimex,lcd-olinuxino.yaml | 4 +++- .../devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml | 3 +++ .../devicetree/bindings/display/panel/raydium,rm67191.yaml | 4 +++- .../devicetree/bindings/display/panel/raydium,rm692e5.yaml | 4 +++- .../devicetree/bindings/display/panel/raydium,rm69380.yaml | 5 +++-- Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml | 2 +- .../devicetree/bindings/display/panel/samsung,amoled-mipi-dsi.yaml | 4 +++- .../devicetree/bindings/display/panel/samsung,ams495qa01.yaml | 5 - Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml | 4 +++- .../devicetree/bindings/display/panel/samsung,lms380kf01.yaml | 3 ++- .../devicetree/bindings/display/panel/samsung,lms397kf04.yaml | 3 ++- .../devicetree/bindings/display/panel/samsung,s6d16d0.yaml | 4 +++- .../devicetree/bindings/display/panel/samsung,s6d27a1.yaml | 3 ++- .../devicetree/bindings/display/panel/samsung,s6d7aa0.yaml | 3 ++- .../devicetree/bindings/display/panel/samsung,s6e63m0.yaml | 4 +++- .../bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml | 5 - .../devicetree/bindings/display/panel/samsung,s6e8aa0.yaml | 4 +++- .../devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml| 4 +++- .../devicetree/bindings/display/panel/sharp,ls043t1le01.yaml| 4 +++- .../devicetree/bindings/display/panel/sharp,ls060t1sx01.yaml| 4 +++- .../devicetree/bindings/display/panel/sitronix,st7789v.yaml | 4 +++- Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml | 5
[PATCH 0/3] drm/panthor: Collection of tiler heap related fixes
Hello, This is a collection of tiler heap fixes for bugs/oddities found while looking at incremental rendering. We need to make sure those land before 6.10 is released (we still have plenty of time), so we don't need to increment the driver version to reflect the ABI changes. Regards, Boris Antonino Maniscalco (1): drm/panthor: Fix tiler OOM handling to allow incremental rendering Boris Brezillon (2): drm/panthor: Make sure the tiler initial/max chunks are consistent drm/panthor: Relax the check on the tiler chunk size drivers/gpu/drm/panthor/panthor_heap.c | 5 - drivers/gpu/drm/panthor/panthor_sched.c | 8 +++- 2 files changed, 11 insertions(+), 2 deletions(-) -- 2.44.0
[PATCH 0/3] drm/msm/mdp4: fix probe deferral issues
While testing MDP4 LVDS support I noticed several issues (two are related to probe deferral case and last one is a c error in LCDC part). Fix those issues. Signed-off-by: Dmitry Baryshkov --- Dmitry Baryshkov (3): drm/msm: don't clean up priv->kms prematurely drm/msm/mdp4: don't destroy mdp4_kms in mdp4_kms_init error path drm/msm/mdp4: correct LCDC regulator name drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 28 --- drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 2 +- drivers/gpu/drm/msm/msm_kms.c | 1 - 3 files changed, 10 insertions(+), 21 deletions(-) --- base-commit: 7b4f2bc91c15fdcf948bb2d9741a9d7d54303f8d change-id: 20240420-mdp4-fixes-f33b5a21308b Best regards, -- Dmitry Baryshkov
Re: [PATCH 0/3] drm: Multiple documentation update
Le 09/04/24 - 13:18, Jani Nikula a écrit : > On Tue, 09 Apr 2024, Louis Chauvet wrote: > > PATCH 1 and PATCH 2 focus on the rotation property. The rotation property > > can be challenging to understand, especially when it is combined with > > reflections. These patches aim to provide clearer explanations and > > examples to aid in comprehension. > > > > Patch 3 relates to the fourcc property. It includes additional details > > about block and char_per_block to provide a more comprehensive > > understanding of this feature. > > > > Regarding PATCH 1, I would appreciate some feedback on the expected > > behavior. During a recent VKMS refactor, I used drm_rect_rotate as a > > reference for the rotation. However, during my testing phase, I noticed > > that the original VKMS implementation interpreted the rotation > > differently. Therefore, I kindly request that someone validate or > > invalidate my interpretation before proceeding with the merge. > > Did you run 'make htmldocs' and check the results after your changes? > I'm almost certain this botches up the layout. I did not think about htmldocs. I have a new version ready where the layout is fixed. Sorry about that. I'll wait for more reviews before submitting it. Thanks, Louis Chauvet > BR, > Jani. > > > > > Signed-off-by: Louis Chauvet > > --- > > Louis Chauvet (3): > > drm: drm_blend.c: Add precision in drm_rotation_simplify kernel doc > > drm: drm_blend.c: Improve drm_plane_create_rotation_property kernel > > doc > > drm/fourcc: Add documentation around drm_format_info > > > > drivers/gpu/drm/drm_blend.c | 57 > > ++--- > > include/drm/drm_fourcc.h| 45 +-- > > 2 files changed, 81 insertions(+), 21 deletions(-) > > --- > > base-commit: e495e523b888a6155f82c767d34c8d712a41ee54 > > change-id: 20240327-google-drm-doc-cd275291792f > > > > Best regards, > > -- > Jani Nikula, Intel -- Louis Chauvet, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
[PATCH 0/3] drm/panel: sitronix-st7789v: fixes for jt240mhqs_hwt_ek_e3 panel
At the jt240mhqs_hwt_ek_e3 panel, noticeable flickering occurs. This is addressed by patch 1, which adjusts the vertical timing. Patch 2 and 3 are two more minor fixes for timing and dimension. Signed-off-by: Gerald Loacker --- Gerald Loacker (3): drm/panel: sitronix-st7789v: fix timing for jt240mhqs_hwt_ek_e3 panel drm/panel: sitronix-st7789v: tweak timing for jt240mhqs_hwt_ek_e3 panel drm/panel: sitronix-st7789v: fix display size for jt240mhqs_hwt_ek_e3 panel drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) --- base-commit: fec50db7033ea478773b159e0e2efb135270e3b7 change-id: 20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-d26983703b27 Best regards, -- Gerald Loacker
Re: [PATCH 0/3] drm: Multiple documentation update
On Tue, 09 Apr 2024, Louis Chauvet wrote: > PATCH 1 and PATCH 2 focus on the rotation property. The rotation property > can be challenging to understand, especially when it is combined with > reflections. These patches aim to provide clearer explanations and > examples to aid in comprehension. > > Patch 3 relates to the fourcc property. It includes additional details > about block and char_per_block to provide a more comprehensive > understanding of this feature. > > Regarding PATCH 1, I would appreciate some feedback on the expected > behavior. During a recent VKMS refactor, I used drm_rect_rotate as a > reference for the rotation. However, during my testing phase, I noticed > that the original VKMS implementation interpreted the rotation > differently. Therefore, I kindly request that someone validate or > invalidate my interpretation before proceeding with the merge. Did you run 'make htmldocs' and check the results after your changes? I'm almost certain this botches up the layout. BR, Jani. > > Signed-off-by: Louis Chauvet > --- > Louis Chauvet (3): > drm: drm_blend.c: Add precision in drm_rotation_simplify kernel doc > drm: drm_blend.c: Improve drm_plane_create_rotation_property kernel doc > drm/fourcc: Add documentation around drm_format_info > > drivers/gpu/drm/drm_blend.c | 57 > ++--- > include/drm/drm_fourcc.h| 45 +-- > 2 files changed, 81 insertions(+), 21 deletions(-) > --- > base-commit: e495e523b888a6155f82c767d34c8d712a41ee54 > change-id: 20240327-google-drm-doc-cd275291792f > > Best regards, -- Jani Nikula, Intel
[PATCH 0/3] drm: Multiple documentation update
PATCH 1 and PATCH 2 focus on the rotation property. The rotation property can be challenging to understand, especially when it is combined with reflections. These patches aim to provide clearer explanations and examples to aid in comprehension. Patch 3 relates to the fourcc property. It includes additional details about block and char_per_block to provide a more comprehensive understanding of this feature. Regarding PATCH 1, I would appreciate some feedback on the expected behavior. During a recent VKMS refactor, I used drm_rect_rotate as a reference for the rotation. However, during my testing phase, I noticed that the original VKMS implementation interpreted the rotation differently. Therefore, I kindly request that someone validate or invalidate my interpretation before proceeding with the merge. Signed-off-by: Louis Chauvet --- Louis Chauvet (3): drm: drm_blend.c: Add precision in drm_rotation_simplify kernel doc drm: drm_blend.c: Improve drm_plane_create_rotation_property kernel doc drm/fourcc: Add documentation around drm_format_info drivers/gpu/drm/drm_blend.c | 57 ++--- include/drm/drm_fourcc.h| 45 +-- 2 files changed, 81 insertions(+), 21 deletions(-) --- base-commit: e495e523b888a6155f82c767d34c8d712a41ee54 change-id: 20240327-google-drm-doc-cd275291792f Best regards, -- Louis Chauvet
Re: [PATCH 0/3] drm/edid & drm/display header spring cleaning
On Thu, 21 Mar 2024, Jani Nikula wrote: > Jani Nikula (3): > drm/displayid: move drm_displayid.h to drm_displayd_internal.h > drm/edid: move all internal declarations to drm_crtc_internal.h > drm/edid: group struct drm_edid based declarations together Resent as part of https://patchwork.freedesktop.org/series/132142/ > > drivers/gpu/drm/drm_crtc_internal.h | 6 ++ > drivers/gpu/drm/drm_displayid.c | 4 +++- > .../gpu/drm/drm_displayid_internal.h | 5 +++-- > drivers/gpu/drm/drm_edid.c| 2 +- > drivers/gpu/drm/drm_eld.c | 4 +++- > drivers/gpu/drm/drm_internal.h| 5 - > include/drm/drm_edid.h| 11 --- > 7 files changed, 20 insertions(+), 17 deletions(-) > rename include/drm/drm_displayid.h => > drivers/gpu/drm/drm_displayid_internal.h (98%) -- Jani Nikula, Intel
[PATCH 0/3] drm/ast: DDC improvements
One fix and two minor improvements to ast's DDC code. Follow-up to the recently added support for connector polling. [1] Tested on AST2500 hardware. [1] https://patchwork.freedesktop.org/series/131306/ Thomas Zimmermann (3): drm/ast: Set DDC timeout in milliseconds drm/ast: Group DDC init code by data structure drm/ast: Define struct ast_ddc in ast_ddc.c drivers/gpu/drm/ast/ast_ddc.c | 30 -- drivers/gpu/drm/ast/ast_ddc.h | 13 ++--- drivers/gpu/drm/ast/ast_mode.c | 8 3 files changed, 26 insertions(+), 25 deletions(-) -- 2.44.0
[PATCH 0/3] drm/panel: add support for LG SW43408 panel
The LG SW43408 panel is used on Google Pixel3 devices. For a long time we could not submit the driver, as the panel was not coming up from the reset. The panel seems to be picky about some of the delays during init and it also uses non-standard payload for MIPI_DSI_COMPRESSION_MODE. Signed-off-by: Dmitry Baryshkov --- Dmitry Baryshkov (1): drm/mipi-dsi: add mipi_dsi_compression_mode_raw() Sumit Semwal (2): dt-bindings: panel: Add LG SW43408 MIPI-DSI panel drm: panel: Add LG sw43408 panel driver .../bindings/display/panel/lg,sw43408.yaml | 37 +++ MAINTAINERS| 8 + drivers/gpu/drm/drm_mipi_dsi.c | 34 ++- drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-lg-sw43408.c | 322 + include/drm/drm_mipi_dsi.h | 1 + 7 files changed, 406 insertions(+), 8 deletions(-) --- base-commit: 13ee4a7161b6fd938aef6688ff43b163f6d83e37 change-id: 20240330-lg-sw43408-panel-b552f411c53e Best regards, -- Dmitry Baryshkov
[PATCH 0/3] DisplayPort support for SM6350/SM7225
Add the required changes to support DisplayPort (normally(?) available via the USB-C connector) on the SM6350/SM7225 SoC. This has been tested on a Fairphone 4 smartphone with additional changes not included in this series (mostly just wiring up TCPM and the SBU mux). Signed-off-by: Luca Weiss --- Luca Weiss (3): dt-bindings: display: msm: dp-controller: document SM8250 compatible dt-bindings: display: msm: sm6350-mdss: document DP controller subnode arm64: dts: qcom: sm6350: Add DisplayPort controller .../bindings/display/msm/dp-controller.yaml| 1 + .../bindings/display/msm/qcom,sm6350-mdss.yaml | 10 +++ arch/arm64/boot/dts/qcom/sm6350.dtsi | 88 ++ 3 files changed, 99 insertions(+) --- base-commit: 871760455183dc66b3e185f8d3ed2184cc9fac25 change-id: 20240328-sm6350-dp-41238153b448 Best regards, -- Luca Weiss
[PATCH 0/3] drm-panel: Don't make failures quite so fatal
This patch series is born out of the observation that after several Chromebooks transitioned over to the generic "edp-panel" compatible string that we received a number of in-the-field reports of the primary graphics device for the Chromebook not coming up. The current belief is that these Chromebooks are actually suffering from a true hardware failure and the panel is either fully disconnected or it has some type of intermittent connection. While we can't solve that problem, digging showed that we actually dealt with this situation better _before_ switching to the generic "edp-panel" compatible string. Before switching to "edp-panel", devices using eDP would finish their probe and would actually not show any failure until you tried to turn the panel on. That was a _good_ thing. The component model used by many DRM devices means that if the panel doesn't finish probing that the rest of the DRM device doesn't probe. In turn, that means that any other display adapters (like ones that would allow hooking up an external display) don't probe. The end result was that a device with a broken panel that could have continued to be a useful computer by hooking up an external display became e-waste. I won't say that this series is the most elegant/wonderful thing in the world. Ideally we could fail the probe of the panel and still use the external display. That's a pretty serious re-design, though. DRM devices work like they do with the component model because of some of their inherent complexities. Douglas Anderson (3): drm/panel-edp: Abstract out function to set conservative timings drm/panel-edp: If we fail to powerup/get EDID, use conservative timings drm-panel: If drm_panel_dp_aux_backlight() fails, don't fail panel probe drivers/gpu/drm/panel/panel-edp.c | 60 +++ .../gpu/drm/panel/panel-samsung-atna33xc20.c | 9 ++- 2 files changed, 41 insertions(+), 28 deletions(-) -- 2.44.0.396.g6e790dbe36-goog
[PATCH 0/3] drm/edid & drm/display header spring cleaning
Jani Nikula (3): drm/displayid: move drm_displayid.h to drm_displayd_internal.h drm/edid: move all internal declarations to drm_crtc_internal.h drm/edid: group struct drm_edid based declarations together drivers/gpu/drm/drm_crtc_internal.h | 6 ++ drivers/gpu/drm/drm_displayid.c | 4 +++- .../gpu/drm/drm_displayid_internal.h | 5 +++-- drivers/gpu/drm/drm_edid.c| 2 +- drivers/gpu/drm/drm_eld.c | 4 +++- drivers/gpu/drm/drm_internal.h| 5 - include/drm/drm_edid.h| 11 --- 7 files changed, 20 insertions(+), 17 deletions(-) rename include/drm/drm_displayid.h => drivers/gpu/drm/drm_displayid_internal.h (98%) -- 2.39.2
Re: [PATCH 0/3] drm/mediatek: Fixes for DDP component search/destroy
Il 01/02/24 13:53, AngeloGioacchino Del Regno ha scritto: This series performs some cleanups for DDP component CRTC search and correctly iounmaps the previously of_iomap() calls from drm_ddp_comp. Tested on MT8195 Cherry Tomato Hello CK, gentle ping for this series. Cheers, Angelo AngeloGioacchino Del Regno (3): drm/mediatek: drm_ddp_comp: Fix and cleanup DDP component CRTC search drm/mediatek: Perform iounmap on simple DDP component destruction drm/mediatek: drm_ddp_comp: Add mtk_ddp_is_simple_comp() internal helper drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 113 +--- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +- 3 files changed, 80 insertions(+), 38 deletions(-)
Re: (subset) [PATCH 0/3] drm/panel: Pixel 3a Panel
On Thu, 08 Feb 2024 19:16:41 -0500, Richard Acayan wrote: > This adds support for the AMS559NK06 panel with the S6E3FA7 display > controller and enables the display subsystem on the Pixel 3a. > > Richard Acayan (3): > dt-bindings: display: panel-simple-dsi: add s6e3fa7 ams559nk06 compat > drm/panel: add samsung s6e3fa7 panel driver > arm64: dts: qcom: sdm670-google-sargo: add panel > > [...] Applied, thanks! [3/3] arm64: dts: qcom: sdm670-google-sargo: add panel commit: 232490b925272d54dd91847a183bdbc2deec904b Best regards, -- Bjorn Andersson
[PATCH 0/3] drm/msm/dp: Improve DP AUX transfer vs. HPD interactions
The main goal of this patch series is to avoid problems running "fwupd" on Qualcomm devices. Right now several of the plugins used with fwupd try talking over all DP AUX busses and this results in a very long timeout on Qualcomm devices. As part of fixing this, I noticed a case where the MSM DP code wasn't respecing the timeout properly when asked to wait for HPD. I also noticed that, now that we've implemented wait_hpd_asserted(), we no longer need the long hardcoded timeout / special cse for eDP in the AUX transfer function. NOTE: I no longer have any hardware setup that uses this driver for eDP so I've only tested the DP case. The eDP changes are straightforward so hopefully there are no problems there. Douglas Anderson (3): drm/msm/dp: Avoid a long timeout for AUX transfer if nothing connected drm/msm/dp: Account for the timeout in wait_hpd_asserted() callback drm/msm/dp: Delete the old 500 ms wait for eDP HPD in aux transfer drivers/gpu/drm/msm/dp/dp_aux.c | 21 - drivers/gpu/drm/msm/dp/dp_catalog.c | 17 ++--- drivers/gpu/drm/msm/dp/dp_catalog.h | 4 +++- 3 files changed, 25 insertions(+), 17 deletions(-) -- 2.44.0.278.ge034bb2e1d-goog
[PATCH 0/3] accel/qaic: Add debugfs entries
Add 3 debugfs entries that can be useful in debugging a variety of issues. bootlog - output the device bootloader log fifo_size - output the configured dbc fifo size queued - output how many requests are queued in the dbc fifo Bootlog is unique to the device, where as fifo_size/queued is per-dbc. Jeffrey Hugo (3): accel/qaic: Add bootlog debugfs accel/qaic: Add fifo size debugfs accel/qaic: Add fifo queued debugfs drivers/accel/qaic/Makefile | 2 + drivers/accel/qaic/qaic.h | 9 + drivers/accel/qaic/qaic_data.c| 9 + drivers/accel/qaic/qaic_debugfs.c | 333 ++ drivers/accel/qaic/qaic_debugfs.h | 20 ++ drivers/accel/qaic/qaic_drv.c | 16 +- 6 files changed, 388 insertions(+), 1 deletion(-) create mode 100644 drivers/accel/qaic/qaic_debugfs.c create mode 100644 drivers/accel/qaic/qaic_debugfs.h -- 2.34.1
Re: [PATCH 0/3] drm/panthor: Fix 3 issues reported by the kernel test bot
On Mon, 4 Mar 2024 10:08:09 +0100
Boris Brezillon wrote:
> Hello,
>
> Here are three trivial fixes for bugs reported by the intel kernel test
> bot.
>
> Regards,
>
> Boris
>
> Boris Brezillon (3):
> drm/panthor: Fix panthor_devfreq kerneldoc
> drm/panthor: Explicitly include page.h for the {virt,__phys)_to_pfn()
> defs
> drm/panthor: Fix undefined panthor_device_suspend/resume symbol issue
Queued to drm-misc-next.
>
> drivers/gpu/drm/panthor/Kconfig | 1 +
> drivers/gpu/drm/panthor/panthor_devfreq.c | 2 +-
> drivers/gpu/drm/panthor/panthor_device.c | 4 ++--
> 3 files changed, 4 insertions(+), 3 deletions(-)
>
[PATCH 0/3] drm/msm/dsi: rework drm_connector instantiation
- Drop attempts to call drm_bridge_attach with 0 flags, require that downstream bridges support DRM_BRIDGE_ATTACH_NO_CONNECTOR - Acquire next bridge during dsi_bind, making sure that it doesn't cause -EPROBE_DEFER later during modeset_init. Signed-off-by: Dmitry Baryshkov --- Dmitry Baryshkov (3): drm/msm/dsi: remove the drm_bridge_attach fallback drm/msm/dsi: move next bridge acquisition to dsi_bind drm/msm/dsi: simplify connector creation drivers/gpu/drm/msm/dsi/dsi.c | 26 drivers/gpu/drm/msm/dsi/dsi.h | 7 ++-- drivers/gpu/drm/msm/dsi/dsi_manager.c | 79 --- 3 files changed, 48 insertions(+), 64 deletions(-) --- base-commit: 1843e16d2df9d98427ef8045589571749d627cf7 change-id: 20240309-fd-dsi-cleanup-bridges-22d5dc1c1341 Best regards, -- Dmitry Baryshkov
[PATCH 0/3] drm/panthor: Fix 3 issues reported by the kernel test bot
Hello,
Here are three trivial fixes for bugs reported by the intel kernel test
bot.
Regards,
Boris
Boris Brezillon (3):
drm/panthor: Fix panthor_devfreq kerneldoc
drm/panthor: Explicitly include page.h for the {virt,__phys)_to_pfn()
defs
drm/panthor: Fix undefined panthor_device_suspend/resume symbol issue
drivers/gpu/drm/panthor/Kconfig | 1 +
drivers/gpu/drm/panthor/panthor_devfreq.c | 2 +-
drivers/gpu/drm/panthor/panthor_device.c | 4 ++--
3 files changed, 4 insertions(+), 3 deletions(-)
--
2.43.0
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On 02/03/2024 10:48 pm, Gustavo Padovan wrote: On Friday, March 01, 2024 18:56 -03, Guillaume Tucker wrote: On 29/02/2024 17:28, Nicolas Dufresne wrote: Hi, Le jeudi 29 février 2024 à 16:16 +0200, Nikolai Kondrashov a écrit : On 2/29/24 2:20 PM, Guillaume Tucker wrote: Hello, On 28/02/2024 23:55, Helen Koike wrote: Dear Kernel Community, This patch introduces a `.gitlab-ci` file along with a `ci/` folder, defining a basic test pipeline triggered by code pushes to a GitLab-CI instance. This initial version includes static checks (checkpatch and smatch for now) and build tests across various architectures and configurations. It leverages an integrated cache for efficient build times and introduces a flexible 'scenarios' mechanism for subsystem-specific extensions. This sounds like a nice starting point to me as an additional way to run tests upstream. I have one particular question as I see a pattern through the rest of the email, please see below. [...] 4. **Collaborative Testing Environment:** The kernel community is already engaged in numerous testing efforts, including various GitLab-CI pipelines such as DRM-CI, which I maintain, along with other solutions like KernelCI and BPF-CI. This proposal is designed to further stimulate contributions to the evolving testing landscape. Our goal is to establish a comprehensive suite of common tools and files. [...] **Leveraging External Test Labs:** We can extend our testing to external labs, similar to what DRM-CI currently does. This includes: - Lava labs - Bare metal labs - Using KernelCI-provided labs **Other integrations** - Submit results to KCIDB [...] **Join Our Slack Channel:** We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance https://kernelci.slack.com/ . Feel free to join and contribute to the conversation. The KernelCI team has weekly calls where we also discuss the GitLab-CI pipeline. **Acknowledgments:** A special thanks to Nikolai Kondrashov, Tales da Aparecida - both from Red Hat - and KernelCI community for their valuable feedback and support in this proposal. Where does this fit on the KernelCI roadmap? I see it mentioned a few times but it's not entirely clear whether this initiative is an independent one or in some way linked to KernelCI. Say, are you planning to use the kci tool, new API, compiler toolchains, user-space and Docker images etc? Or, are KernelCI plans evolving to follow this move? I would say this is an important part of KernelCI the project, considering its aim to improve testing and CI in the kernel. It's not a part of KernelCI the service as it is right now, although I would say it would be good to have ability to submit KernelCI jobs from GitLab CI and pull results in the same pipeline, as we discussed earlier. Right, I think this needs a bit of disambiguation. The legacy KernelCI system from the Linaro days several years ago is really a service on its own like the many other CIs out there. However, the new KernelCI API and related tooling (kci command line, new web dashboard, modular runtime design etc.) is not that. It's about addressing all the community requirements and that includes being able to run a same test manually in a shell, or in a VM, or automatically from GitLab CI or using a main generic pipeline hosted by KernelCI itself. With this approach, there's no distinction between "the project" and "the service", and as we discussed before there shouldn't even be a distinction with KCIDB. Just KernelCI. However I don't really see this happening, unless I'm missing a part of the story or some upcoming announcement with an updated roadmap. For some reason the old and established paradigm seems unshakeable. The new KernelCI implementation is starting to look just like a refresh of the old one with newer components - which is a huge missed opportunity to really change things IMHO. Calling that a missed opportunity is a subjective perspective about the latest developments in KernelCI. The system implementation is one level less important than the actual kernel community engagement the project can generate. If one asks people around, the lack of community engagement with KernelCI is evident. Well I would argue that community engagement and technical development work side-by-side, not as a hierarchy. You can't run Android phones or data centers with community engagement, and you can't write the code without the people. I was enquiring about this in particluar because I'm preparing a LF webinar, so I've started another thread to avoid spamming this one as it's really a side topic: https://lore.kernel.org/all/71f59a56-aef3-4bae-867b-769a0cdd1...@gtucker.io/T/#u However, after the recent leadership change in the project there is a growing effort to bring the kernel community closer to the KernelCI project with a renewed focus on high quality test results, clean regression reporting, among other things. Then, with an increased number of community members
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On 29/02/2024 17:28, Nicolas Dufresne wrote: > Hi, > > Le jeudi 29 février 2024 à 16:16 +0200, Nikolai Kondrashov a écrit : >> On 2/29/24 2:20 PM, Guillaume Tucker wrote: >>> Hello, >>> >>> On 28/02/2024 23:55, Helen Koike wrote: Dear Kernel Community, This patch introduces a `.gitlab-ci` file along with a `ci/` folder, defining a basic test pipeline triggered by code pushes to a GitLab-CI instance. This initial version includes static checks (checkpatch and smatch for now) and build tests across various architectures and configurations. It leverages an integrated cache for efficient build times and introduces a flexible 'scenarios' mechanism for subsystem-specific extensions. >>> >>> This sounds like a nice starting point to me as an additional way >>> to run tests upstream. I have one particular question as I see a >>> pattern through the rest of the email, please see below. >>> >>> [...] >>> 4. **Collaborative Testing Environment:** The kernel community is already engaged in numerous testing efforts, including various GitLab-CI pipelines such as DRM-CI, which I maintain, along with other solutions like KernelCI and BPF-CI. This proposal is designed to further stimulate contributions to the evolving testing landscape. Our goal is to establish a comprehensive suite of common tools and files. >>> >>> [...] >>> **Leveraging External Test Labs:** We can extend our testing to external labs, similar to what DRM-CI currently does. This includes: - Lava labs - Bare metal labs - Using KernelCI-provided labs **Other integrations** - Submit results to KCIDB >>> >>> [...] >>> **Join Our Slack Channel:** We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance https://kernelci.slack.com/ . Feel free to join and contribute to the conversation. The KernelCI team has weekly calls where we also discuss the GitLab-CI pipeline. **Acknowledgments:** A special thanks to Nikolai Kondrashov, Tales da Aparecida - both from Red Hat - and KernelCI community for their valuable feedback and support in this proposal. >>> >>> Where does this fit on the KernelCI roadmap? >>> >>> I see it mentioned a few times but it's not entirely clear >>> whether this initiative is an independent one or in some way >>> linked to KernelCI. Say, are you planning to use the kci tool, >>> new API, compiler toolchains, user-space and Docker images etc? >>> Or, are KernelCI plans evolving to follow this move? >> >> I would say this is an important part of KernelCI the project, considering >> its >> aim to improve testing and CI in the kernel. It's not a part of KernelCI the >> service as it is right now, although I would say it would be good to have >> ability to submit KernelCI jobs from GitLab CI and pull results in the same >> pipeline, as we discussed earlier. Right, I think this needs a bit of disambiguation. The legacy KernelCI system from the Linaro days several years ago is really a service on its own like the many other CIs out there. However, the new KernelCI API and related tooling (kci command line, new web dashboard, modular runtime design etc.) is not that. It's about addressing all the community requirements and that includes being able to run a same test manually in a shell, or in a VM, or automatically from GitLab CI or using a main generic pipeline hosted by KernelCI itself. With this approach, there's no distinction between "the project" and "the service", and as we discussed before there shouldn't even be a distinction with KCIDB. Just KernelCI. However I don't really see this happening, unless I'm missing a part of the story or some upcoming announcement with an updated roadmap. For some reason the old and established paradigm seems unshakeable. The new KernelCI implementation is starting to look just like a refresh of the old one with newer components - which is a huge missed opportunity to really change things IMHO. This may sound like a bit of a tangent, facilitating GitLab CI for the upstream kernel is of course significant progress in any case - no question about that. My comment is more about why it's being driven hand-in-hand with KernelCI in what seems like a diverging direction from KernelCI's announced plans. Why push for a GitLab-centered orchestration when there's a more universal solution being proposed by the project? I would find it easier to understand - and I sense I'm not the only one here reading the thread - if KernelCI wasn't mentioned that many times in the cover letter and if the scripts didn't have KCI_* in so many places, basically if this was clearly an independent initiative such as KUnit, 0-day or regzbot. > I'd like to add that both CI have a different purpose in the Linux project. > This > CI work is a pre-merge verification. Everyone needs to run checkpatch and >
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Friday, March 01, 2024 18:56 -03, Guillaume Tucker wrote: > On 29/02/2024 17:28, Nicolas Dufresne wrote: > > Hi, > > > > Le jeudi 29 février 2024 à 16:16 +0200, Nikolai Kondrashov a écrit : > >> On 2/29/24 2:20 PM, Guillaume Tucker wrote: > >>> Hello, > >>> > >>> On 28/02/2024 23:55, Helen Koike wrote: > Dear Kernel Community, > > This patch introduces a `.gitlab-ci` file along with a `ci/` folder, > defining a > basic test pipeline triggered by code pushes to a GitLab-CI instance. > This > initial version includes static checks (checkpatch and smatch for now) > and build > tests across various architectures and configurations. It leverages an > integrated cache for efficient build times and introduces a flexible > 'scenarios' > mechanism for subsystem-specific extensions. > >>> > >>> This sounds like a nice starting point to me as an additional way > >>> to run tests upstream. I have one particular question as I see a > >>> pattern through the rest of the email, please see below. > >>> > >>> [...] > >>> > 4. **Collaborative Testing Environment:** The kernel community is already > engaged in numerous testing efforts, including various GitLab-CI > pipelines such > as DRM-CI, which I maintain, along with other solutions like KernelCI and > BPF-CI. This proposal is designed to further stimulate contributions to > the > evolving testing landscape. Our goal is to establish a comprehensive > suite of > common tools and files. > >>> > >>> [...] > >>> > **Leveraging External Test Labs:** > We can extend our testing to external labs, similar to what DRM-CI > currently > does. This includes: > - Lava labs > - Bare metal labs > - Using KernelCI-provided labs > > **Other integrations** > - Submit results to KCIDB > >>> > >>> [...] > >>> > **Join Our Slack Channel:** > We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance > https://kernelci.slack.com/ . > Feel free to join and contribute to the conversation. The KernelCI team > has > weekly calls where we also discuss the GitLab-CI pipeline. > > **Acknowledgments:** > A special thanks to Nikolai Kondrashov, Tales da Aparecida - both from > Red Hat - > and KernelCI community for their valuable feedback and support in this > proposal. > >>> > >>> Where does this fit on the KernelCI roadmap? > >>> > >>> I see it mentioned a few times but it's not entirely clear > >>> whether this initiative is an independent one or in some way > >>> linked to KernelCI. Say, are you planning to use the kci tool, > >>> new API, compiler toolchains, user-space and Docker images etc? > >>> Or, are KernelCI plans evolving to follow this move? > >> > >> I would say this is an important part of KernelCI the project, considering > >> its > >> aim to improve testing and CI in the kernel. It's not a part of KernelCI > >> the > >> service as it is right now, although I would say it would be good to have > >> ability to submit KernelCI jobs from GitLab CI and pull results in the > >> same > >> pipeline, as we discussed earlier. > > Right, I think this needs a bit of disambiguation. The legacy > KernelCI system from the Linaro days several years ago is really > a service on its own like the many other CIs out there. However, > the new KernelCI API and related tooling (kci command line, new > web dashboard, modular runtime design etc.) is not that. It's > about addressing all the community requirements and that includes > being able to run a same test manually in a shell, or in a VM, or > automatically from GitLab CI or using a main generic pipeline > hosted by KernelCI itself. With this approach, there's no > distinction between "the project" and "the service", and as we > discussed before there shouldn't even be a distinction with > KCIDB. Just KernelCI. > > However I don't really see this happening, unless I'm missing a > part of the story or some upcoming announcement with an updated > roadmap. For some reason the old and established paradigm seems > unshakeable. The new KernelCI implementation is starting to look > just like a refresh of the old one with newer components - which > is a huge missed opportunity to really change things IMHO. Calling that a missed opportunity is a subjective perspective about the latest developments in KernelCI. The system implementation is one level less important than the actual kernel community engagement the project can generate. If one asks people around, the lack of community engagement with KernelCI is evident. However, after the recent leadership change in the project there is a growing effort to bring the kernel community closer to the KernelCI project with a renewed focus on high quality test results, clean regression reporting, among other things. Then, with an increased number of community
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
Hi, Le jeudi 29 février 2024 à 16:16 +0200, Nikolai Kondrashov a écrit : > On 2/29/24 2:20 PM, Guillaume Tucker wrote: > > Hello, > > > > On 28/02/2024 23:55, Helen Koike wrote: > > > Dear Kernel Community, > > > > > > This patch introduces a `.gitlab-ci` file along with a `ci/` folder, > > > defining a > > > basic test pipeline triggered by code pushes to a GitLab-CI instance. This > > > initial version includes static checks (checkpatch and smatch for now) > > > and build > > > tests across various architectures and configurations. It leverages an > > > integrated cache for efficient build times and introduces a flexible > > > 'scenarios' > > > mechanism for subsystem-specific extensions. > > > > This sounds like a nice starting point to me as an additional way > > to run tests upstream. I have one particular question as I see a > > pattern through the rest of the email, please see below. > > > > [...] > > > > > 4. **Collaborative Testing Environment:** The kernel community is already > > > engaged in numerous testing efforts, including various GitLab-CI > > > pipelines such > > > as DRM-CI, which I maintain, along with other solutions like KernelCI and > > > BPF-CI. This proposal is designed to further stimulate contributions to > > > the > > > evolving testing landscape. Our goal is to establish a comprehensive > > > suite of > > > common tools and files. > > > > [...] > > > > > **Leveraging External Test Labs:** > > > We can extend our testing to external labs, similar to what DRM-CI > > > currently > > > does. This includes: > > > - Lava labs > > > - Bare metal labs > > > - Using KernelCI-provided labs > > > > > > **Other integrations** > > > - Submit results to KCIDB > > > > [...] > > > > > **Join Our Slack Channel:** > > > We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance > > > https://kernelci.slack.com/ . > > > Feel free to join and contribute to the conversation. The KernelCI team > > > has > > > weekly calls where we also discuss the GitLab-CI pipeline. > > > > > > **Acknowledgments:** > > > A special thanks to Nikolai Kondrashov, Tales da Aparecida - both from > > > Red Hat - > > > and KernelCI community for their valuable feedback and support in this > > > proposal. > > > > Where does this fit on the KernelCI roadmap? > > > > I see it mentioned a few times but it's not entirely clear > > whether this initiative is an independent one or in some way > > linked to KernelCI. Say, are you planning to use the kci tool, > > new API, compiler toolchains, user-space and Docker images etc? > > Or, are KernelCI plans evolving to follow this move? > > I would say this is an important part of KernelCI the project, considering > its > aim to improve testing and CI in the kernel. It's not a part of KernelCI the > service as it is right now, although I would say it would be good to have > ability to submit KernelCI jobs from GitLab CI and pull results in the same > pipeline, as we discussed earlier. I'd like to add that both CI have a different purpose in the Linux project. This CI work is a pre-merge verification. Everyone needs to run checkpatch and smatch, this is automating it (and will catch those that forgot or ran it incorrectly). But it can go further by effectively testing specific patches on real hardware (with pretty narrow filters). It will help catch submission issues earlier, and reduce kernelCI regression rate. As a side effect, kernelCI infra will endup catching the "integration" issues, which are the issue as a result of simultenous changes in different trees. They are also often more complex and benefit from the bisection capabilities. kernelCI tests are also a lot more intensive, they usually covers everything, but they bundle multiple changes per run. The pre-merge tests will be reduced to what seems meaningful for the changes. Its important to understand that pre- merge CI have a time cost, and we need to make sure CI time does not exceed the merge window period. Nicolas
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On 2/29/24 01:07, Laurent Pinchart wrote: On Wed, Feb 28, 2024 at 07:55:24PM -0300, Helen Koike wrote: **Join Our Slack Channel:** We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance https://kernelci.slack.com/ . Feel free to join and contribute to the conversation. The KernelCI team has weekly calls where we also discuss the GitLab-CI pipeline. Could we communicate using free software please ? Furthermore, it's not possible to create an account on that slack instance unless you have an e-mail address affiliated with a small number of companies (https://kernelci.slack.com/signup#/domain-signup). That's a big no-go for me. Yes, it's not ideal that we use closed-source software for communication, but FWIW I'd be happy to invite you there. Perhaps if you try logging in e.g. with a Google account, I'd be able to see and approve your attempt too. Otherwise, our video meetings are generally open to everyone and run in Jitsi. Nick
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
Hi Laurent, Helen, On Thu, Feb 29, 2024 at 01:07:25AM +0200, Laurent Pinchart wrote: > > **Join Our Slack Channel:** > > We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance > > https://kernelci.slack.com/ . > > Feel free to join and contribute to the conversation. The KernelCI team has > > weekly calls where we also discuss the GitLab-CI pipeline. > > Could we communicate using free software please ? Furthermore, it's not > possible to create an account on that slack instance unless you have an > e-mail address affiliated with a small number of companies > (https://kernelci.slack.com/signup#/domain-signup). That's a big no-go > for me. I agree. There is no shortage of good alternatives either: we have IRC, Matrix and XMPP for instance. Just pick one of them. -- Regards, Sakari Ailus
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On 2/29/24 2:25 PM, Laurent Pinchart wrote: On Thu, Feb 29, 2024 at 02:20:41PM +0200, Laurent Pinchart wrote: On Thu, Feb 29, 2024 at 12:53:38PM +0100, Guillaume Tucker wrote: On 29/02/2024 12:41, Mark Brown wrote: On Thu, Feb 29, 2024 at 01:19:19PM +0200, Laurent Pinchart wrote: On Thu, Feb 29, 2024 at 01:10:16PM +0200, Nikolai Kondrashov wrote: Of course. You're also welcome to join the #kernelci channel on libera.chat. Isn't that a bit pointless if it's no the main IM channel ? It *was* the original channel and still gets some usage (mostly started by me admittedly since I've never joined slack for a bunch of reasons that make it hassle), IIRC the Slack was started because there were some interns who had trouble figuring out IRC and intermittent connectivity but people seem to have migrated. In fact it was initially created for the members of the Linux Foundation project only, which is why registration is moderated for emails that don't have a domain linked to a member (BTW not any Google account will just work e.g. @gmail.com is moderated, only @google.com for Google employees isn't). And yes IRC is the "least common denominator" chat platform. Maybe having a bridge between the main Slack channel and IRC would help. If the gitlab CI pipeline proposal wants to be considered for inclusion in the kernel, I think it needs to switch to a free software solution for its *main* communication channels. And to clarify, I didn't meant the kernel CI project, but only the gitlab CI pipeline for the Linux kernel project. I don't know how tightly integrated the two projects are though. They're not tightly integrated so far. However, we're exploring the idea of letting GitLab CI submit jobs to KernelCI and get results as a part of the pipeline. Helen already joined the #kernelci channel, and we will maintain a presence there for the GitLab CI project. Nick
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
Hello, On 28/02/2024 23:55, Helen Koike wrote: > Dear Kernel Community, > > This patch introduces a `.gitlab-ci` file along with a `ci/` folder, defining > a > basic test pipeline triggered by code pushes to a GitLab-CI instance. This > initial version includes static checks (checkpatch and smatch for now) and > build > tests across various architectures and configurations. It leverages an > integrated cache for efficient build times and introduces a flexible > 'scenarios' > mechanism for subsystem-specific extensions. This sounds like a nice starting point to me as an additional way to run tests upstream. I have one particular question as I see a pattern through the rest of the email, please see below. [...] > 4. **Collaborative Testing Environment:** The kernel community is already > engaged in numerous testing efforts, including various GitLab-CI pipelines > such > as DRM-CI, which I maintain, along with other solutions like KernelCI and > BPF-CI. This proposal is designed to further stimulate contributions to the > evolving testing landscape. Our goal is to establish a comprehensive suite of > common tools and files. [...] > **Leveraging External Test Labs:** > We can extend our testing to external labs, similar to what DRM-CI currently > does. This includes: > - Lava labs > - Bare metal labs > - Using KernelCI-provided labs > > **Other integrations** > - Submit results to KCIDB [...] > **Join Our Slack Channel:** > We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance > https://kernelci.slack.com/ . > Feel free to join and contribute to the conversation. The KernelCI team has > weekly calls where we also discuss the GitLab-CI pipeline. > > **Acknowledgments:** > A special thanks to Nikolai Kondrashov, Tales da Aparecida - both from Red > Hat - > and KernelCI community for their valuable feedback and support in this > proposal. Where does this fit on the KernelCI roadmap? I see it mentioned a few times but it's not entirely clear whether this initiative is an independent one or in some way linked to KernelCI. Say, are you planning to use the kci tool, new API, compiler toolchains, user-space and Docker images etc? Or, are KernelCI plans evolving to follow this move? Thanks, Guillaume
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On 2/29/24 1:19 PM, Laurent Pinchart wrote: On Thu, Feb 29, 2024 at 01:10:16PM +0200, Nikolai Kondrashov wrote: On 2/29/24 11:34 AM, Laurent Pinchart wrote: On Thu, Feb 29, 2024 at 11:26:51AM +0200, Nikolai Kondrashov wrote: On 2/29/24 01:07, Laurent Pinchart wrote: On Wed, Feb 28, 2024 at 07:55:24PM -0300, Helen Koike wrote: **Join Our Slack Channel:** We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance https://kernelci.slack.com/ . Feel free to join and contribute to the conversation. The KernelCI team has weekly calls where we also discuss the GitLab-CI pipeline. Could we communicate using free software please ? Furthermore, it's not possible to create an account on that slack instance unless you have an e-mail address affiliated with a small number of companies (https://kernelci.slack.com/signup#/domain-signup). That's a big no-go for me. Yes, it's not ideal that we use closed-source software for communication, but FWIW I'd be happy to invite you there. Perhaps if you try logging in e.g. with a Google account, I'd be able to see and approve your attempt too. I don't use Google accounts to authenticate to third-party services, sorry. And in any case, that won't make slack free software. Of course. You're also welcome to join the #kernelci channel on libera.chat. Isn't that a bit pointless if it's no the main IM channel ? Yes, it's not ideal, but if more people come there, more discussions will happen there too. Nick
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On 2/29/24 11:34 AM, Laurent Pinchart wrote: On Thu, Feb 29, 2024 at 11:26:51AM +0200, Nikolai Kondrashov wrote: On 2/29/24 01:07, Laurent Pinchart wrote: On Wed, Feb 28, 2024 at 07:55:24PM -0300, Helen Koike wrote: **Join Our Slack Channel:** We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance https://kernelci.slack.com/ . Feel free to join and contribute to the conversation. The KernelCI team has weekly calls where we also discuss the GitLab-CI pipeline. Could we communicate using free software please ? Furthermore, it's not possible to create an account on that slack instance unless you have an e-mail address affiliated with a small number of companies (https://kernelci.slack.com/signup#/domain-signup). That's a big no-go for me. Yes, it's not ideal that we use closed-source software for communication, but FWIW I'd be happy to invite you there. Perhaps if you try logging in e.g. with a Google account, I'd be able to see and approve your attempt too. I don't use Google accounts to authenticate to third-party services, sorry. And in any case, that won't make slack free software. Of course. You're also welcome to join the #kernelci channel on libera.chat. It's much quieter there, though. Nick
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On 2/29/24 2:20 PM, Guillaume Tucker wrote: Hello, On 28/02/2024 23:55, Helen Koike wrote: Dear Kernel Community, This patch introduces a `.gitlab-ci` file along with a `ci/` folder, defining a basic test pipeline triggered by code pushes to a GitLab-CI instance. This initial version includes static checks (checkpatch and smatch for now) and build tests across various architectures and configurations. It leverages an integrated cache for efficient build times and introduces a flexible 'scenarios' mechanism for subsystem-specific extensions. This sounds like a nice starting point to me as an additional way to run tests upstream. I have one particular question as I see a pattern through the rest of the email, please see below. [...] 4. **Collaborative Testing Environment:** The kernel community is already engaged in numerous testing efforts, including various GitLab-CI pipelines such as DRM-CI, which I maintain, along with other solutions like KernelCI and BPF-CI. This proposal is designed to further stimulate contributions to the evolving testing landscape. Our goal is to establish a comprehensive suite of common tools and files. [...] **Leveraging External Test Labs:** We can extend our testing to external labs, similar to what DRM-CI currently does. This includes: - Lava labs - Bare metal labs - Using KernelCI-provided labs **Other integrations** - Submit results to KCIDB [...] **Join Our Slack Channel:** We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance https://kernelci.slack.com/ . Feel free to join and contribute to the conversation. The KernelCI team has weekly calls where we also discuss the GitLab-CI pipeline. **Acknowledgments:** A special thanks to Nikolai Kondrashov, Tales da Aparecida - both from Red Hat - and KernelCI community for their valuable feedback and support in this proposal. Where does this fit on the KernelCI roadmap? I see it mentioned a few times but it's not entirely clear whether this initiative is an independent one or in some way linked to KernelCI. Say, are you planning to use the kci tool, new API, compiler toolchains, user-space and Docker images etc? Or, are KernelCI plans evolving to follow this move? I would say this is an important part of KernelCI the project, considering its aim to improve testing and CI in the kernel. It's not a part of KernelCI the service as it is right now, although I would say it would be good to have ability to submit KernelCI jobs from GitLab CI and pull results in the same pipeline, as we discussed earlier. Nick
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On 29/02/2024 12:41, Mark Brown wrote: > On Thu, Feb 29, 2024 at 01:19:19PM +0200, Laurent Pinchart wrote: >> On Thu, Feb 29, 2024 at 01:10:16PM +0200, Nikolai Kondrashov wrote: > >>> Of course. You're also welcome to join the #kernelci channel on libera.chat. > >> Isn't that a bit pointless if it's no the main IM channel ? > > It *was* the original channel and still gets some usage (mostly started > by me admittedly since I've never joined slack for a bunch of reasons > that make it hassle), IIRC the Slack was started because there were some > interns who had trouble figuring out IRC and intermittent connectivity > but people seem to have migrated. In fact it was initially created for the members of the Linux Foundation project only, which is why registration is moderated for emails that don't have a domain linked to a member (BTW not any Google account will just work e.g. @gmail.com is moderated, only @google.com for Google employees isn't). And yes IRC is the "least common denominator" chat platform. Maybe having a bridge between the main Slack channel and IRC would help. Guillaume
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Thu, Feb 29, 2024 at 02:20:41PM +0200, Laurent Pinchart wrote: > On Thu, Feb 29, 2024 at 12:53:38PM +0100, Guillaume Tucker wrote: > > On 29/02/2024 12:41, Mark Brown wrote: > > > On Thu, Feb 29, 2024 at 01:19:19PM +0200, Laurent Pinchart wrote: > > >> On Thu, Feb 29, 2024 at 01:10:16PM +0200, Nikolai Kondrashov wrote: > > > > > >>> Of course. You're also welcome to join the #kernelci channel on > > >>> libera.chat. > > > > > >> Isn't that a bit pointless if it's no the main IM channel ? > > > > > > It *was* the original channel and still gets some usage (mostly started > > > by me admittedly since I've never joined slack for a bunch of reasons > > > that make it hassle), IIRC the Slack was started because there were some > > > interns who had trouble figuring out IRC and intermittent connectivity > > > but people seem to have migrated. > > > > In fact it was initially created for the members of the Linux > > Foundation project only, which is why registration is moderated > > for emails that don't have a domain linked to a member (BTW not > > any Google account will just work e.g. @gmail.com is moderated, > > only @google.com for Google employees isn't). > > > > And yes IRC is the "least common denominator" chat platform. > > Maybe having a bridge between the main Slack channel and IRC > > would help. > > If the gitlab CI pipeline proposal wants to be considered for inclusion > in the kernel, I think it needs to switch to a free software solution > for its *main* communication channels. And to clarify, I didn't meant the kernel CI project, but only the gitlab CI pipeline for the Linux kernel project. I don't know how tightly integrated the two projects are though. -- Regards, Laurent Pinchart
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Thu, Feb 29, 2024 at 12:53:38PM +0100, Guillaume Tucker wrote: > On 29/02/2024 12:41, Mark Brown wrote: > > On Thu, Feb 29, 2024 at 01:19:19PM +0200, Laurent Pinchart wrote: > >> On Thu, Feb 29, 2024 at 01:10:16PM +0200, Nikolai Kondrashov wrote: > > > >>> Of course. You're also welcome to join the #kernelci channel on > >>> libera.chat. > > > >> Isn't that a bit pointless if it's no the main IM channel ? > > > > It *was* the original channel and still gets some usage (mostly started > > by me admittedly since I've never joined slack for a bunch of reasons > > that make it hassle), IIRC the Slack was started because there were some > > interns who had trouble figuring out IRC and intermittent connectivity > > but people seem to have migrated. > > In fact it was initially created for the members of the Linux > Foundation project only, which is why registration is moderated > for emails that don't have a domain linked to a member (BTW not > any Google account will just work e.g. @gmail.com is moderated, > only @google.com for Google employees isn't). > > And yes IRC is the "least common denominator" chat platform. > Maybe having a bridge between the main Slack channel and IRC > would help. If the gitlab CI pipeline proposal wants to be considered for inclusion in the kernel, I think it needs to switch to a free software solution for its *main* communication channels. -- Regards, Laurent Pinchart
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Thu, Feb 29, 2024 at 01:19:19PM +0200, Laurent Pinchart wrote: > On Thu, Feb 29, 2024 at 01:10:16PM +0200, Nikolai Kondrashov wrote: > > Of course. You're also welcome to join the #kernelci channel on libera.chat. > Isn't that a bit pointless if it's no the main IM channel ? It *was* the original channel and still gets some usage (mostly started by me admittedly since I've never joined slack for a bunch of reasons that make it hassle), IIRC the Slack was started because there were some interns who had trouble figuring out IRC and intermittent connectivity but people seem to have migrated. signature.asc Description: PGP signature
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Thu, Feb 29, 2024 at 01:10:16PM +0200, Nikolai Kondrashov wrote: > On 2/29/24 11:34 AM, Laurent Pinchart wrote: > > On Thu, Feb 29, 2024 at 11:26:51AM +0200, Nikolai Kondrashov wrote: > >> On 2/29/24 01:07, Laurent Pinchart wrote: > >>> On Wed, Feb 28, 2024 at 07:55:24PM -0300, Helen Koike wrote: > **Join Our Slack Channel:** > We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance > https://kernelci.slack.com/ . > Feel free to join and contribute to the conversation. The KernelCI team > has > weekly calls where we also discuss the GitLab-CI pipeline. > >>> > >>> Could we communicate using free software please ? Furthermore, it's not > >>> possible to create an account on that slack instance unless you have an > >>> e-mail address affiliated with a small number of companies > >>> (https://kernelci.slack.com/signup#/domain-signup). That's a big no-go > >>> for me. > >> > >> Yes, it's not ideal that we use closed-source software for communication, > >> but > >> FWIW I'd be happy to invite you there. Perhaps if you try logging in e.g. > >> with > >> a Google account, I'd be able to see and approve your attempt too. > > > > I don't use Google accounts to authenticate to third-party services, > > sorry. And in any case, that won't make slack free software. > > Of course. You're also welcome to join the #kernelci channel on libera.chat. Isn't that a bit pointless if it's no the main IM channel ? > It's much quieter there, though. -- Regards, Laurent Pinchart
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Thu, Feb 29, 2024 at 09:39:01AM +, Sakari Ailus wrote: > On Thu, Feb 29, 2024 at 01:07:25AM +0200, Laurent Pinchart wrote: > > > We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance > > > https://kernelci.slack.com/ . > > > Feel free to join and contribute to the conversation. The KernelCI team > > > has > > > weekly calls where we also discuss the GitLab-CI pipeline. > > Could we communicate using free software please ? Furthermore, it's not > > possible to create an account on that slack instance unless you have an > > e-mail address affiliated with a small number of companies > > (https://kernelci.slack.com/signup#/domain-signup). That's a big no-go > > for me. > I agree. There is no shortage of good alternatives either: we have IRC, > Matrix and XMPP for instance. Just pick one of them. And indeed KernelCI does actually already have #kernelci on libera.chat. signature.asc Description: PGP signature
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Thu, Feb 29, 2024 at 11:26:51AM +0200, Nikolai Kondrashov wrote: > On 2/29/24 01:07, Laurent Pinchart wrote: > > On Wed, Feb 28, 2024 at 07:55:24PM -0300, Helen Koike wrote: > >> **Join Our Slack Channel:** > >> We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance > >> https://kernelci.slack.com/ . > >> Feel free to join and contribute to the conversation. The KernelCI team has > >> weekly calls where we also discuss the GitLab-CI pipeline. > > > > Could we communicate using free software please ? Furthermore, it's not > > possible to create an account on that slack instance unless you have an > > e-mail address affiliated with a small number of companies > > (https://kernelci.slack.com/signup#/domain-signup). That's a big no-go > > for me. > > Yes, it's not ideal that we use closed-source software for communication, but > FWIW I'd be happy to invite you there. Perhaps if you try logging in e.g. > with > a Google account, I'd be able to see and approve your attempt too. I don't use Google accounts to authenticate to third-party services, sorry. And in any case, that won't make slack free software. > Otherwise, our video meetings are generally open to everyone and run in Jitsi. -- Regards, Laurent Pinchart
Re: (subset) [PATCH 0/3] drm/panel: Pixel 3a Panel
Hi, On Thu, 08 Feb 2024 19:16:41 -0500, Richard Acayan wrote: > This adds support for the AMS559NK06 panel with the S6E3FA7 display > controller and enables the display subsystem on the Pixel 3a. > > Richard Acayan (3): > dt-bindings: display: panel-simple-dsi: add s6e3fa7 ams559nk06 compat > drm/panel: add samsung s6e3fa7 panel driver > arm64: dts: qcom: sdm670-google-sargo: add panel > > [...] Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [1/3] dt-bindings: display: panel-simple-dsi: add s6e3fa7 ams559nk06 compat https://cgit.freedesktop.org/drm/drm-misc/commit/?id=2689b33b88641a3b9a8cc411a0c8094cbed7e871 [2/3] drm/panel: add samsung s6e3fa7 panel driver https://cgit.freedesktop.org/drm/drm-misc/commit/?id=bf0390e2c95bf630b22dddc7cde5f83762b658e5 -- Neil
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Thu, Feb 29, 2024 at 01:07:25AM +0200, Laurent Pinchart wrote: > > Chat Discussions > > > > > > For those interested in further discussions: > > > > **Join Our Slack Channel:** > > We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance > > https://kernelci.slack.com/ . > > Feel free to join and contribute to the conversation. The KernelCI team has > > weekly calls where we also discuss the GitLab-CI pipeline. > > Could we communicate using free software please ? Furthermore, it's not > possible to create an account on that slack instance unless you have an > e-mail address affiliated with a small number of companies > (https://kernelci.slack.com/signup#/domain-signup). That's a big no-go > for me. Yeah, and that list looks super restrictive and arbitrary. Like, microsoft is there but kernel.org isn't? I'm sure there's a reason, but we should at the very least open it to everyone. Maxime signature.asc Description: PGP signature
[PATCH 0/3] Add GAMMA 12-bit LUT support for MT8188
From: Jason-jh Lin Since MT8195 supports GAMMA 12-bit LUT after the landing of [1] series, we can now add support for MT8188. [1] MediaTek DDP GAMMA - 12-bit LUT support - https://patchwork.kernel.org/project/linux-mediatek/list/?series=792516 Jason-JH.Lin (3): dt-bindings: display: mediatek: gamma: Change MT8195 to single enum group dt-bindings: display: mediatek: gamma: Add support for MT8188 drm/mediatek: Add gamma support for MT8195 .../bindings/display/mediatek/mediatek,gamma.yaml | 6 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++ 2 files changed, 7 insertions(+), 1 deletion(-) -- 2.18.0
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
Hi Helen, I appreciate the amount of work you've put into this, to improve testing of the kernel as a whole. I'll need more time to answer, but please see below for a quick comment already. On Wed, Feb 28, 2024 at 07:55:24PM -0300, Helen Koike wrote: > Dear Kernel Community, > > This patch introduces a `.gitlab-ci` file along with a `ci/` folder, defining > a > basic test pipeline triggered by code pushes to a GitLab-CI instance. This > initial version includes static checks (checkpatch and smatch for now) and > build > tests across various architectures and configurations. It leverages an > integrated cache for efficient build times and introduces a flexible > 'scenarios' > mechanism for subsystem-specific extensions. > > tl;dr: check this video to see a quick demo: https://youtu.be/TWiTjhjOuzg, > but don't forget to check the "Motivation for this work" below. Your feedback, > whether a simple thumbs up or down, is crucial to determine if it is > worthwhile > to pursue this initiative. > > GitLab is an Open Source platform that includes integrated CI/CD. The pipeline > provided in this patch is designed to work out-of-the-box with any GitLab > instance, including the gitlab.com Free Tier. If you reach the limits of the > Free Tier, consider using community instances like > https://gitlab.freedesktop.org/. > Alternatively, you can set up a local runner for more flexibility. The > bootstrap-gitlab-runner.sh script included with this patch simplifies this > process, enabling you to run tests on your preferred infrastructure, including > your own machine. > > For detailed information, please refer to the documentation included in the > patch, or check the rendered version here: > https://koike.pages.collabora.com/-/linux/-/jobs/298498/artifacts/artifacts/Documentation-output/ci/gitlab-ci/gitlab-ci.html > . > > > Motivation for this Work > > > We all know tests are a major topic in the community, so let's mention the > specificities of this approach: > > 1. **Built-in User Interface:** GitLab CI/CD is growing in popularity and has > an > user-friendly interface. Our experience with the upstream DRM-CI in the kernel > tree (see this blog post > [https://www.collabora.com/news-and-blog/blog/2024/02/08/drm-ci-a-gitlab-ci-pipeline-for-linux-kernel-testing/] > ) > has provided insights into how such a system can benefit the wider community. > > 2. **Distributed Infrastructure:** > The proposed GitLab-CI pipeline is designed with a distributed infrastructure > model, being possible to run in any gitlab instance. > > 3. **Reduce regressions:** Fostering a culture where people habitually run > validated tests and post their results can prevent many issues in post-merge > tests. > > 4. **Collaborative Testing Environment:** The kernel community is already > engaged in numerous testing efforts, including various GitLab-CI pipelines > such > as DRM-CI, which I maintain, along with other solutions like KernelCI and > BPF-CI. This proposal is designed to further stimulate contributions to the > evolving testing landscape. Our goal is to establish a comprehensive suite of > common tools and files. > > 5. **Ownership of QA:** > Discrepancies between kernel code and outdated tests often lead to > misattributed > failures, complicating regression tracking. This issue, often arising from > neglected or deprioritized test updates, creates uncertainty about the source > of > failures. Adopting an "always green pipeline" approach, as detailed in this > patch's documentation, encourages timely maintenance and validation of tests. > This ensures that testing accurately reflects the current state of the kernel, > thereby improving the effectiveness of our QA processes. > > Additionally, if we discover that this method isn't working for us, we can > easily remove it from the codebase, as it is primarily contained within the > ci/ > folder. > > > Future Work > === > > **Expanding Static Checks:** > We have the opportunity to integrate a variety of static analysis tools, > including: > - dtbs_checks > - sparse > - yamllint > - dt-doc-validate > - coccicheck > > **Adding Userspace Tests on VMs:** > To further our testing, we can implement userspace tests that run on virtual > machines (VMs), such as: > - kselftests > - kunit tests > - Subsystem-specific tests, customizable in the scenarios. > > **Leveraging External Test Labs:** > We can extend our testing to external labs, similar to what DRM-CI currently > does. This includes: > - Lava labs > - Bare metal labs > - Using KernelCI-provided labs > > **Other integrations** > - Submit results to KCIDB > > **Lightweight Implementation for All Developers:** > We aim to design these tests to be lightweight, ensuring developers with > limited > computing resources can still run essential tests. Resource-intensive tests > can > be set to trigger manually, rather than automatically, to accommodate diverse > development
[PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
Dear Kernel Community, This patch introduces a `.gitlab-ci` file along with a `ci/` folder, defining a basic test pipeline triggered by code pushes to a GitLab-CI instance. This initial version includes static checks (checkpatch and smatch for now) and build tests across various architectures and configurations. It leverages an integrated cache for efficient build times and introduces a flexible 'scenarios' mechanism for subsystem-specific extensions. tl;dr: check this video to see a quick demo: https://youtu.be/TWiTjhjOuzg, but don't forget to check the "Motivation for this work" below. Your feedback, whether a simple thumbs up or down, is crucial to determine if it is worthwhile to pursue this initiative. GitLab is an Open Source platform that includes integrated CI/CD. The pipeline provided in this patch is designed to work out-of-the-box with any GitLab instance, including the gitlab.com Free Tier. If you reach the limits of the Free Tier, consider using community instances like https://gitlab.freedesktop.org/. Alternatively, you can set up a local runner for more flexibility. The bootstrap-gitlab-runner.sh script included with this patch simplifies this process, enabling you to run tests on your preferred infrastructure, including your own machine. For detailed information, please refer to the documentation included in the patch, or check the rendered version here: https://koike.pages.collabora.com/-/linux/-/jobs/298498/artifacts/artifacts/Documentation-output/ci/gitlab-ci/gitlab-ci.html . Motivation for this Work We all know tests are a major topic in the community, so let's mention the specificities of this approach: 1. **Built-in User Interface:** GitLab CI/CD is growing in popularity and has an user-friendly interface. Our experience with the upstream DRM-CI in the kernel tree (see this blog post [https://www.collabora.com/news-and-blog/blog/2024/02/08/drm-ci-a-gitlab-ci-pipeline-for-linux-kernel-testing/] ) has provided insights into how such a system can benefit the wider community. 2. **Distributed Infrastructure:** The proposed GitLab-CI pipeline is designed with a distributed infrastructure model, being possible to run in any gitlab instance. 3. **Reduce regressions:** Fostering a culture where people habitually run validated tests and post their results can prevent many issues in post-merge tests. 4. **Collaborative Testing Environment:** The kernel community is already engaged in numerous testing efforts, including various GitLab-CI pipelines such as DRM-CI, which I maintain, along with other solutions like KernelCI and BPF-CI. This proposal is designed to further stimulate contributions to the evolving testing landscape. Our goal is to establish a comprehensive suite of common tools and files. 5. **Ownership of QA:** Discrepancies between kernel code and outdated tests often lead to misattributed failures, complicating regression tracking. This issue, often arising from neglected or deprioritized test updates, creates uncertainty about the source of failures. Adopting an "always green pipeline" approach, as detailed in this patch's documentation, encourages timely maintenance and validation of tests. This ensures that testing accurately reflects the current state of the kernel, thereby improving the effectiveness of our QA processes. Additionally, if we discover that this method isn't working for us, we can easily remove it from the codebase, as it is primarily contained within the ci/ folder. Future Work === **Expanding Static Checks:** We have the opportunity to integrate a variety of static analysis tools, including: - dtbs_checks - sparse - yamllint - dt-doc-validate - coccicheck **Adding Userspace Tests on VMs:** To further our testing, we can implement userspace tests that run on virtual machines (VMs), such as: - kselftests - kunit tests - Subsystem-specific tests, customizable in the scenarios. **Leveraging External Test Labs:** We can extend our testing to external labs, similar to what DRM-CI currently does. This includes: - Lava labs - Bare metal labs - Using KernelCI-provided labs **Other integrations** - Submit results to KCIDB **Lightweight Implementation for All Developers:** We aim to design these tests to be lightweight, ensuring developers with limited computing resources can still run essential tests. Resource-intensive tests can be set to trigger manually, rather than automatically, to accommodate diverse development environments. Chat Discussions For those interested in further discussions: **Join Our Slack Channel:** We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance https://kernelci.slack.com/ . Feel free to join and contribute to the conversation. The KernelCI team has weekly calls where we also discuss the GitLab-CI pipeline. **Acknowledgments:** A special thanks to Nikolai Kondrashov, Tales da Aparecida - both from Red Hat - and KernelCI community for their
Re: [PATCH 0/3] Fixes for the komeda driver
Hi Faiz, On Mon, Feb 19, 2024 at 03:39:12PM +0530, Faiz Abbas wrote: > The following patches add fixes to the komeda DPU driver. > > Patch 1 fixes an issue where the crtc always expects both pipelines to > always have remote nodes populated. > > Patch 2 is a cosmetic fix that ensures komeda does not print verbose > pipeline information unless the entire pipeline is actually up. > > Patch 3 adds a 40 bit DMA mask for each pipeline. Sorry for the delay in replying, I was on holiday last week. Patch series looks good, I will push it into drm-misc-next-fixes at the end of the week. Best regards, Liviu > > Amjad Ouled-Ameur (1): > drm/arm/komeda: update DMA mask to 40 bits > > Faiz Abbas (2): > drm/arm/komeda: Fix komeda probe failing if there are no links in the > secondary pipeline > drm/arm/komeda: Move pipeline prints to after the entire pipeline has > been enabled > > .../gpu/drm/arm/display/komeda/komeda_crtc.c | 45 ++- > .../gpu/drm/arm/display/komeda/komeda_drv.c | 4 ++ > .../gpu/drm/arm/display/komeda/komeda_kms.h | 1 + > .../drm/arm/display/komeda/komeda_pipeline.c | 4 +- > 4 files changed, 41 insertions(+), 13 deletions(-) > > -- > 2.25.1 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
[PATCH 0/3] panel-simple: add support for Crystal Clear CMT430B19N00
This patch series add support for the Crystal Clear Technology CMT430B19N00 4.3" 480x272 TFT-LCD panel. It also adds Crystal Clear Technology to vendor-prefixes.yaml. Please note that unfortunately there is no public datasheet available for this panel. Jérémie Dautheribes (3): dt-bindings: Add Crystal Clear Technology vendor prefix dt-bindings: display: simple: add support for Crystal Clear CMT430B19N00 drm/panel: simple: add CMT430B19N00 LCD panel support .../bindings/display/panel/panel-simple.yaml | 2 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 ++ drivers/gpu/drm/panel/panel-simple.c | 29 +++ 3 files changed, 33 insertions(+) -- 2.34.1
Re: [PATCH 0/3] drm/amdgpu: Use KMEM_CACHE instead of kmem_cache_create
Applied. Thanks! On Wed, Feb 21, 2024 at 6:08 AM Christian König wrote: > > Am 21.02.24 um 10:59 schrieb Kunwu Chan: > > For where the cache name and the structure name match. > > Use the new KMEM_CACHE() macro instead of direct kmem_cache_create > > to simplify the creation of SLAB caches. > > Reviewed-by: Christian König for the entire > series. > > > > > Kunwu Chan (3): > >drm/amdgpu: Simplify the allocation of fence slab caches > >drm/amdgpu: Simplify the allocation of mux_chunk slab caches > >drm/amdgpu: Simplify the allocation of sync slab caches > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c| 4 +--- > > drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c | 4 +--- > > drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 4 +--- > > 3 files changed, 3 insertions(+), 9 deletions(-) > > >
[PATCH 0/3] arch: Remove fbdev dependency from video helpers
Make architecture helpers for display functionality depend on general
video functionality instead of fbdev. This avoid the dependency on
fbdev and makes the functionality available for non-fbdev code.
Patch 1 replaces the variety of Kconfig options that control the
Makefiles with CONFIG_VIDEO. More fine-grained control of the build
can then be done within each video/ directory; see sparc for an
example.
Patch 2 replaces fb_is_primary_device() with video_is_primary_device(),
which has no dependencies on fbdev. The implementation remains identical
on all affected platforms. There's one minor change in fbcon, which is
the only caller of fb_is_primary_device().
Patch 3 renames the source and files from fbdev to video.
Thomas Zimmermann (3):
arch: Select fbdev helpers with CONFIG_VIDEO
arch: Remove struct fb_info from video helpers
arch: Rename fbdev header and source files
arch/arc/include/asm/fb.h| 8 --
arch/arc/include/asm/video.h | 8 ++
arch/arm/include/asm/fb.h| 6 -
arch/arm/include/asm/video.h | 6 +
arch/arm64/include/asm/fb.h | 10
arch/arm64/include/asm/video.h | 10
arch/loongarch/include/asm/{fb.h => video.h} | 8 +++---
arch/m68k/include/asm/{fb.h => video.h} | 8 +++---
arch/mips/include/asm/{fb.h => video.h} | 12 -
arch/parisc/Makefile | 2 +-
arch/parisc/include/asm/fb.h | 14 ---
arch/parisc/include/asm/video.h | 16
arch/parisc/video/Makefile | 2 +-
arch/parisc/video/{fbdev.c => video-sti.c} | 9 ---
arch/powerpc/include/asm/{fb.h => video.h} | 8 +++---
arch/powerpc/kernel/pci-common.c | 2 +-
arch/sh/include/asm/fb.h | 7 --
arch/sh/include/asm/video.h | 7 ++
arch/sparc/Makefile | 4 +--
arch/sparc/include/asm/{fb.h => video.h} | 15 +--
arch/sparc/video/Makefile| 2 +-
arch/sparc/video/fbdev.c | 26
arch/sparc/video/video.c | 25 +++
arch/x86/Makefile| 2 +-
arch/x86/include/asm/fb.h| 19 --
arch/x86/include/asm/video.h | 21
arch/x86/video/Makefile | 3 ++-
arch/x86/video/{fbdev.c => video.c} | 21 +++-
drivers/video/fbdev/core/fbcon.c | 2 +-
include/asm-generic/Kbuild | 2 +-
include/asm-generic/{fb.h => video.h}| 17 +++--
include/linux/fb.h | 2 +-
32 files changed, 154 insertions(+), 150 deletions(-)
delete mode 100644 arch/arc/include/asm/fb.h
create mode 100644 arch/arc/include/asm/video.h
delete mode 100644 arch/arm/include/asm/fb.h
create mode 100644 arch/arm/include/asm/video.h
delete mode 100644 arch/arm64/include/asm/fb.h
create mode 100644 arch/arm64/include/asm/video.h
rename arch/loongarch/include/asm/{fb.h => video.h} (86%)
rename arch/m68k/include/asm/{fb.h => video.h} (86%)
rename arch/mips/include/asm/{fb.h => video.h} (76%)
delete mode 100644 arch/parisc/include/asm/fb.h
create mode 100644 arch/parisc/include/asm/video.h
rename arch/parisc/video/{fbdev.c => video-sti.c} (78%)
rename arch/powerpc/include/asm/{fb.h => video.h} (76%)
delete mode 100644 arch/sh/include/asm/fb.h
create mode 100644 arch/sh/include/asm/video.h
rename arch/sparc/include/asm/{fb.h => video.h} (75%)
delete mode 100644 arch/sparc/video/fbdev.c
create mode 100644 arch/sparc/video/video.c
delete mode 100644 arch/x86/include/asm/fb.h
create mode 100644 arch/x86/include/asm/video.h
rename arch/x86/video/{fbdev.c => video.c} (66%)
rename include/asm-generic/{fb.h => video.h} (89%)
--
2.43.0
Re: [PATCH 0/3] drm/amdgpu: Use KMEM_CACHE instead of kmem_cache_create
Am 21.02.24 um 10:59 schrieb Kunwu Chan: For where the cache name and the structure name match. Use the new KMEM_CACHE() macro instead of direct kmem_cache_create to simplify the creation of SLAB caches. Reviewed-by: Christian König for the entire series. Kunwu Chan (3): drm/amdgpu: Simplify the allocation of fence slab caches drm/amdgpu: Simplify the allocation of mux_chunk slab caches drm/amdgpu: Simplify the allocation of sync slab caches drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c| 4 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c | 4 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 4 +--- 3 files changed, 3 insertions(+), 9 deletions(-)
[PATCH 0/3] drm/amdgpu: Use KMEM_CACHE instead of kmem_cache_create
For where the cache name and the structure name match. Use the new KMEM_CACHE() macro instead of direct kmem_cache_create to simplify the creation of SLAB caches. Kunwu Chan (3): drm/amdgpu: Simplify the allocation of fence slab caches drm/amdgpu: Simplify the allocation of mux_chunk slab caches drm/amdgpu: Simplify the allocation of sync slab caches drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c| 4 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c | 4 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 4 +--- 3 files changed, 3 insertions(+), 9 deletions(-) -- 2.39.2
[PATCH 0/3] drm/amd/display: add prefix to dc/clk_mgr/dcn10 functions
This patchset has three commits that add prefix to all the functions defined in dc/clk_mgr/dcn10 that indicate the file that they were defined. Enforcing this pattern makes filtering results in debug tools like ftrace better. David Tadokoro (3): drm/amd/display: add prefix to rv1_clk_mgr_clk.c function drm/amd/display: add prefix to rv1_clk_mgr.c functions drm/amd/display: add prefix to rv1_clk_mgr_vbios_smu.c functions .../display/dc/clk_mgr/dcn10/rv1_clk_mgr.c| 24 +-- .../dc/clk_mgr/dcn10/rv1_clk_mgr_clk.c| 2 +- .../dc/clk_mgr/dcn10/rv1_clk_mgr_vbios_smu.c | 14 +-- .../dc/clk_mgr/dcn10/rv1_clk_mgr_vbios_smu.h | 4 ++-- 4 files changed, 22 insertions(+), 22 deletions(-) -- 2.39.2
[PATCH 0/3] Fixes for the komeda driver
The following patches add fixes to the komeda DPU driver. Patch 1 fixes an issue where the crtc always expects both pipelines to always have remote nodes populated. Patch 2 is a cosmetic fix that ensures komeda does not print verbose pipeline information unless the entire pipeline is actually up. Patch 3 adds a 40 bit DMA mask for each pipeline. Amjad Ouled-Ameur (1): drm/arm/komeda: update DMA mask to 40 bits Faiz Abbas (2): drm/arm/komeda: Fix komeda probe failing if there are no links in the secondary pipeline drm/arm/komeda: Move pipeline prints to after the entire pipeline has been enabled .../gpu/drm/arm/display/komeda/komeda_crtc.c | 45 ++- .../gpu/drm/arm/display/komeda/komeda_drv.c | 4 ++ .../gpu/drm/arm/display/komeda/komeda_kms.h | 1 + .../drm/arm/display/komeda/komeda_pipeline.c | 4 +- 4 files changed, 41 insertions(+), 13 deletions(-) -- 2.25.1
Re: [PATCH 0/3] drm/panel: add one more Leadtek panel, the ltk101b4029w
On Thu, 15 Feb 2024 10:05:12 +0100, Heiko Stuebner wrote: > Similar in setup to the ltk500hd1829, group it with this driver. > > Heiko Stuebner (3): > drm/panel: ltk500hd1829: make room for more similar panels > dt-bindings: display: ltk500hd1829: add variant compatible for > ltk101b4029w > drm/panel: ltk500hd1829: add panel type for ltk101b4029w > > [...] Applied, thanks! Adapted the commit message in the binding patch to show where the panels are similar but also different (init-sequence) [1/3] drm/panel: ltk500hd1829: make room for more similar panels commit: f9488c160d6e8e5e548452a0d36057a1f8c04045 [2/3] dt-bindings: display: ltk500hd1829: add variant compatible for ltk101b4029w commit: c71efc6337135670164334404ef11506b31b7a81 [3/3] drm/panel: ltk500hd1829: add panel type for ltk101b4029w commit: 239cce651ea617002ff26f068f2568b2baf6421a Best regards, -- Heiko Stuebner
[PATCH 0/3] Move blender setup from individual planes to crtc commit in sun4i-drm
From: Ondrej Jirman This series refactors blender setup from individual planes to a common place where it can be performed at once and is easier to reason about. In the process this fixes a few bugs that allowed blender pipes to be disabled while corresponding DRM planes were requested to be enabled. Please take a look. :) Thank you very much, Ondřej Jirman Ondrej Jirman (3): drm/sun4i: Unify sun8i_*_layer structs drm/sun4i: Add more parameters to sunxi_engine commit callback drm/sun4i: Fix layer zpos change/atomic modesetting drivers/gpu/drm/sun4i/sun4i_backend.c | 4 +- drivers/gpu/drm/sun4i/sun4i_crtc.c | 2 +- drivers/gpu/drm/sun4i/sun8i_mixer.c| 82 +++- drivers/gpu/drm/sun4i/sun8i_mixer.h| 20 ++ drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 85 +++-- drivers/gpu/drm/sun4i/sun8i_ui_layer.h | 20 ++ drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 86 +++--- drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 20 ++ drivers/gpu/drm/sun4i/sunxi_engine.h | 13 +++- 9 files changed, 137 insertions(+), 195 deletions(-) -- 2.43.0
[PATCH 0/3] vc4 VEC (analogue video) updates - margins and monochrome
Hi All A couple of patches to vc4, including adding a new "TV mode" enum for monochrome output (yes we have some users who wish for monochrome). Adding mono has raised a query here as to whether the the TV_MODE is meant to describe the timing, or just the colour encoding. The description for NTSC references "CCIR System M (aka 525-lines)", and PAL references "CCIR System B" which is the 625 line standard. PAL-60 is absent from the enum, but support has been added to vc4 by selecting DRM_MODE_TV_MODE_PAL but with the NTSC (CCIR System M) timings. Is that the correct implementation? In which case the description for PAL should drop the CCIR System B reference as selecting the "TV mode" doesn't dictate the timing. Monochrome is in the same boat as it can adopt either 525 or 625 line timing, or indeed anything else. Pi5 can support System A 405-line and the French 819-line mono modes as well. If "TV mode" does dictate the timing as well as the colour encoding, then we need to add PAL-60, and 2 modes for mono (extending to 4 for 405 and 819 line modes later). If not, we ought to update the description. Thoughts? Thanks Dave Dave Stevenson (2): drm/vc4: Add monochrome mode to the VEC. drm/vc4: vec: Add the margin properties to the connector Nick Hollinghurst (1): drm: Add DRM_MODE_TV_MODE_MONOCHROME drivers/gpu/drm/drm_connector.c| 7 +++ drivers/gpu/drm/drm_modes.c| 5 - drivers/gpu/drm/drm_probe_helper.c | 5 +++-- drivers/gpu/drm/vc4/vc4_vec.c | 30 +- include/drm/drm_connector.h| 7 +++ 5 files changed, 50 insertions(+), 4 deletions(-) -- 2.25.1
[PATCH 0/3] PCI LNKCTL2 RMW Accessor Cleanup
This series converts open-coded LNKCTL2 RMW accesses to use RMW accessor. These patches used to be part of PCIe BW controller series [1] which will require RMW ops to LNKCTL2 be properly locked. However, since these RMW accessor patches are useful as cleanups on their own I chose to send them now separately to reduce the size of the BW controller series. [1] https://lore.kernel.org/linux-pci/20240105112547.7301-1-ilpo.jarvi...@linux.intel.com/ Ilpo Järvinen (3): drm/radeon: Use RMW accessors for changing LNKCTL2 drm/amdgpu: Use RMW accessors for changing LNKCTL2 RDMA/hfi1: Use RMW accessors for changing LNKCTL2 drivers/gpu/drm/amd/amdgpu/cik.c | 41 +++ drivers/gpu/drm/amd/amdgpu/si.c | 41 +++ drivers/gpu/drm/radeon/cik.c | 40 +++--- drivers/gpu/drm/radeon/si.c | 40 +++--- drivers/infiniband/hw/hfi1/pcie.c | 30 ++ 5 files changed, 68 insertions(+), 124 deletions(-) -- 2.39.2
Re: [PATCH 0/3] drm/panel: add one more Leadtek panel, the ltk101b4029w
Hi Heiko, On 2/15/24 10:05, Heiko Stuebner wrote: Similar in setup to the ltk500hd1829, group it with this driver. > Heiko Stuebner (3): drm/panel: ltk500hd1829: make room for more similar panels dt-bindings: display: ltk500hd1829: add variant compatible for ltk101b4029w drm/panel: ltk500hd1829: add panel type for ltk101b4029w For the whole series: Reviewed-by: Quentin Schulz Thanks, Quentin
[PATCH 0/3] drm/panel: add one more Leadtek panel, the ltk101b4029w
Similar in setup to the ltk500hd1829, group it with this driver. Heiko Stuebner (3): drm/panel: ltk500hd1829: make room for more similar panels dt-bindings: display: ltk500hd1829: add variant compatible for ltk101b4029w drm/panel: ltk500hd1829: add panel type for ltk101b4029w .../display/panel/leadtek,ltk500hd1829.yaml | 4 +- .../drm/panel/panel-leadtek-ltk500hd1829.c| 265 -- 2 files changed, 244 insertions(+), 25 deletions(-) -- 2.39.2
[PATCH 0/3] drm/amd/display: fix codestyle for some dmub files
Marcelo Mendes Spessoto Junior (3): drm/amd/display: clean codestyle errors drm/amd/display: clean codestyle errors drm/amd/display: clean codestyle errors drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 6 +++--- drivers/gpu/drm/amd/display/dmub/src/dmub_dcn32.c | 2 +- drivers/gpu/drm/amd/display/dmub/src/dmub_dcn35.c | 5 +++-- 3 files changed, 7 insertions(+), 6 deletions(-) -- 2.39.2
[PATCH 0/3] drm/panel: Pixel 3a Panel
This adds support for the AMS559NK06 panel with the S6E3FA7 display controller and enables the display subsystem on the Pixel 3a. Richard Acayan (3): dt-bindings: display: panel-simple-dsi: add s6e3fa7 ams559nk06 compat drm/panel: add samsung s6e3fa7 panel driver arm64: dts: qcom: sdm670-google-sargo: add panel .../display/panel/panel-simple-dsi.yaml | 2 + .../boot/dts/qcom/sdm670-google-sargo.dts | 64 drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-samsung-s6e3fa7.c | 285 ++ 5 files changed, 361 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3fa7.c -- 2.43.0
[PATCH 0/3] drm/mediatek: Fixes for DDP component search/destroy
This series performs some cleanups for DDP component CRTC search and correctly iounmaps the previously of_iomap() calls from drm_ddp_comp. Tested on MT8195 Cherry Tomato AngeloGioacchino Del Regno (3): drm/mediatek: drm_ddp_comp: Fix and cleanup DDP component CRTC search drm/mediatek: Perform iounmap on simple DDP component destruction drm/mediatek: drm_ddp_comp: Add mtk_ddp_is_simple_comp() internal helper drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 113 +--- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +- 3 files changed, 80 insertions(+), 38 deletions(-) -- 2.43.0
Re: [PATCH 0/3] accel/ivpu fixes for 6.8-rc1
Applied to drm-misc-fixes On 22.01.2024 13:09, Jacek Lawrynowicz wrote: > Stability fixes for reset, recovery and unbind. > > Jacek Lawrynowicz (3): > accel/ivpu: Fix dev open/close races with unbind > accel/ivpu: Improve stability of ivpu_submit_ioctl() > accel/ivpu: Improve recovery and reset support > > drivers/accel/ivpu/ivpu_debugfs.c | 20 +++- > drivers/accel/ivpu/ivpu_drv.c | 110 + > drivers/accel/ivpu/ivpu_drv.h | 3 +- > drivers/accel/ivpu/ivpu_gem.c | 18 ++-- > drivers/accel/ivpu/ivpu_gem.h | 2 +- > drivers/accel/ivpu/ivpu_hw_37xx.c | 14 +-- > drivers/accel/ivpu/ivpu_hw_40xx.c | 8 +- > drivers/accel/ivpu/ivpu_ipc.c | 6 +- > drivers/accel/ivpu/ivpu_job.c | 157 +- > drivers/accel/ivpu/ivpu_job.h | 3 +- > drivers/accel/ivpu/ivpu_mmu.c | 14 ++- > drivers/accel/ivpu/ivpu_pm.c | 48 ++--- > drivers/accel/ivpu/ivpu_pm.h | 6 +- > 13 files changed, 218 insertions(+), 191 deletions(-) > > -- > 2.43.0
[PATCH 0/3] Fixed-type GENMASK/BIT
Move the implementation of REG_GENMASK/REG_BIT to a more appropriate place to be shared by i915, xe and possibly other parts of the kernel. For now this re-defines the old macros. In future we may start using the new macros directly, but that's a more intrusive search-and-replace. Yury, I added a little bit more information to the commit message in patch 1. First 2 patches may go through your tree. For the last one we may have potential conflicts, so I'm not sure. +Jani from i915 side to chime in. v1: https://lore.kernel.org/intel-xe/20230509051403.2748545-1-lucas.demar...@intel.com/ Lucas De Marchi (2): bits: Introduce fixed-type BIT drm/i915: Convert REG_GENMASK* to fixed-width GENMASK_* Yury Norov (1): bits: introduce fixed-type genmasks drivers/gpu/drm/i915/i915_reg_defs.h | 108 +++ include/linux/bitops.h | 1 - include/linux/bits.h | 33 +--- 3 files changed, 33 insertions(+), 109 deletions(-) -- 2.43.0
[PATCH 0/3] accel/ivpu fixes for 6.8-rc1
Stability fixes for reset, recovery and unbind. Jacek Lawrynowicz (3): accel/ivpu: Fix dev open/close races with unbind accel/ivpu: Improve stability of ivpu_submit_ioctl() accel/ivpu: Improve recovery and reset support drivers/accel/ivpu/ivpu_debugfs.c | 20 +++- drivers/accel/ivpu/ivpu_drv.c | 110 + drivers/accel/ivpu/ivpu_drv.h | 3 +- drivers/accel/ivpu/ivpu_gem.c | 18 ++-- drivers/accel/ivpu/ivpu_gem.h | 2 +- drivers/accel/ivpu/ivpu_hw_37xx.c | 14 +-- drivers/accel/ivpu/ivpu_hw_40xx.c | 8 +- drivers/accel/ivpu/ivpu_ipc.c | 6 +- drivers/accel/ivpu/ivpu_job.c | 157 +- drivers/accel/ivpu/ivpu_job.h | 3 +- drivers/accel/ivpu/ivpu_mmu.c | 14 ++- drivers/accel/ivpu/ivpu_pm.c | 48 ++--- drivers/accel/ivpu/ivpu_pm.h | 6 +- 13 files changed, 218 insertions(+), 191 deletions(-) -- 2.43.0
[PATCH 0/3] LVDS Controller Support for SAM9X7 SoC
This patch series introduces LVDS controller support for the SAM9X7 SoC. The LVDS controller is designed to work with Microchip's sam9x7 series System-on-Chip (SoC) devices, providing Low Voltage Differential Signaling capabilities. Dharma Balasubiramani (3): dt-bindings: display: bridge: add sam9x7-lvds compatible drm/bridge: add lvds controller support for sam9x7 MAINTAINERS: add SAM9X7 SoC's LVDS controller .../display/bridge/microchip,sam9x7-lvds.yaml | 59 + MAINTAINERS | 8 + drivers/gpu/drm/bridge/Kconfig| 7 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/microchip-lvds.c | 250 ++ 5 files changed, 325 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/microchip,sam9x7-lvds.yaml create mode 100644 drivers/gpu/drm/bridge/microchip-lvds.c -- 2.25.1
[RFC PATCH 0/3] Add display sharing support in tidss
This adds display sharing support in tidss display driver along with an example overlay devicetree file using which can be used to enable display sharing on AM62x devices with device manager core i.e. R5F expected to run a custom firmware which supports corresponding display sharing configuration. As resources can be partitioned at different levels a flexible scheme is followed while designing devicetree bindings and driver changes keeping in mind possible scenarios in which resources can be partitioned and various DSS hardware IP's supported across different devices. A rebased version of this patch has been tested on AM62P SoC which also supports same DSS IP as AM62x and the patch with display sharing functionality is already available in vendor-specific kernel source tree [1] along with documentation which explains the design [2] and DM firmware support [3]. NOTE1: This is marked as RFC for upstream since AM62P is not yet supported in upstream tree and for AM62x SoC which is the target SoC for this patch, the dss sharing functionality is not validated on upstream tree due to missing OLDI support and display sharing DM firmware support, but we still wanted to get some feedback on this. NOTE2: This series depends on : https://lore.kernel.org/all/20240115125716.560363-1-devar...@ti.com/ [1] : https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=09.01.00.007=d805270609cfb6b2e67bd2fd5959d71f48393196 https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=09.01.00.007=93d751a94cbf9ad07c7f658e78aa510d919d7cd6 https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=09.01.00.007=665c17837dc8bed27e8d63388f8f7f7a85c0cd94 https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=ti-linux-6.1.y-cicd=f8d7f1a9617862af922c6bc10e0765ba4f4857d6 [2] : https://software-dl.ti.com/processor-sdk-linux/esd/AM62PX/09_01_00_08/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Display/DSS7.html#driver-features (Display Sharing mode feature description) https://software-dl.ti.com/processor-sdk-linux/esd/AM62PX/09_01_00_08/exports/docs/linux/How_to_Guides/Target/How_to_enable_display_sharing_between_remotecore_and_Linux.html (How To Guide) https://software-dl.ti.com/processor-sdk-linux/esd/AM62PX/09_01_00_08/exports/docs/system/Demo_User_Guides/Display_Cluster_User_Guide.html (Display Cluster user guide with demo details) [3] : https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-dm/am62pxx/dss_display_share.wkup-r5f0_0.release.strip.out?h=ti-linux-firmware-next Devarsh Thakkar (3): dt-bindings: display: ti,am65x-dss: Add support for display sharing mode drm/tidss: Add support for display sharing arm64: dts: ti: k3-am62x: Add overlay to use DSS in display sharing mode .../bindings/display/ti/ti,am65x-dss.yaml | 82 ++ arch/arm64/boot/dts/ti/Makefile | 1 + .../dts/ti/k3-am62x-sk-dss-shared-mode.dtso | 23 ++ drivers/gpu/drm/tidss/tidss_crtc.c| 120 - drivers/gpu/drm/tidss/tidss_dispc.c | 254 -- drivers/gpu/drm/tidss/tidss_dispc.h | 2 +- drivers/gpu/drm/tidss/tidss_drv.c | 33 ++- drivers/gpu/drm/tidss/tidss_drv.h | 6 + 8 files changed, 481 insertions(+), 40 deletions(-) create mode 100644 arch/arm64/boot/dts/ti/k3-am62x-sk-dss-shared-mode.dtso -- 2.34.1
[PATCH 0/3] video: Simplify Kconfig options
Replace CONFIG_VIDEO_CMDLINE and CONFIG_VIDEO_NOMODESET by the single
option CONFIG_VIDEO. Select the latter for DRM or fbdev. Both original
options used to be selected in most cases, so this change simplifies
the Kconfig rules.
Since commit ca6c080eef42 ("arch/parisc: Detect primary video device
from device instance") architecture helpers for fbdev do not longer
require fbdev in their implementation and could be used for non-fbdev
code as well. Eventually guarding them with CONFIG_VIDEO will make
them available to any subsystem.
Thomas Zimmermann (3):
video/cmdline: Introduce CONFIG_VIDEO for video= parameter
video/cmdline: Hide __video_get_options() behind CONFIG_FB_CORE
video/nomodeset: Select nomodeset= parameter with CONFIG_VIDEO
drivers/gpu/drm/Kconfig | 3 +--
drivers/staging/sm750fb/Kconfig | 1 -
drivers/video/Kconfig | 5 +
drivers/video/Makefile| 3 +--
drivers/video/cmdline.c | 2 ++
drivers/video/fbdev/Kconfig | 37 ---
drivers/video/fbdev/core/Kconfig | 2 +-
drivers/video/fbdev/core/fbmem.c | 2 --
drivers/video/fbdev/geode/Kconfig | 3 ---
include/linux/fb.h| 7 --
include/video/cmdline.h | 7 +-
11 files changed, 7 insertions(+), 65 deletions(-)
base-commit: 05b317e8457c8e2bd1a797c9440ec07b7f341584
--
2.43.0
Re: [PATCH 0/3] Update LLVM Phabricator and Bugzilla links
On Tue, Jan 9, 2024 at 5:26 PM Nathan Chancellor wrote: > > This series updates all instances of LLVM Phabricator and Bugzilla links > to point to GitHub commits directly and LLVM's Bugzilla to GitHub issue > shortlinks respectively. > > I split up the Phabricator patch into BPF selftests and the rest of the > kernel in case the BPF folks want to take it separately from the rest of > the series, there are obviously no dependency issues in that case. The > Bugzilla change was mechanical enough and should have no conflicts. > > I am aiming this at Andrew and CC'ing other lists, in case maintainers > want to chime in, but I think this is pretty uncontroversial (famous > last words...). > Acked-by: Alex Deucher > --- > Nathan Chancellor (3): > selftests/bpf: Update LLVM Phabricator links > arch and include: Update LLVM Phabricator links > treewide: Update LLVM Bugzilla links > > arch/arm64/Kconfig | 4 +-- > arch/powerpc/Makefile | 4 +-- > arch/powerpc/kvm/book3s_hv_nested.c| 2 +- > arch/riscv/Kconfig | 2 +- > arch/riscv/include/asm/ftrace.h| 2 +- > arch/s390/include/asm/ftrace.h | 2 +- > arch/x86/power/Makefile| 2 +- > crypto/blake2b_generic.c | 2 +- > drivers/firmware/efi/libstub/Makefile | 2 +- > drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 2 +- > drivers/media/test-drivers/vicodec/codec-fwht.c| 2 +- > drivers/regulator/Kconfig | 2 +- > include/asm-generic/vmlinux.lds.h | 2 +- > include/linux/compiler-clang.h | 2 +- > lib/Kconfig.kasan | 2 +- > lib/raid6/Makefile | 2 +- > lib/stackinit_kunit.c | 2 +- > mm/slab_common.c | 2 +- > net/bridge/br_multicast.c | 2 +- > security/Kconfig | 2 +- > tools/testing/selftests/bpf/README.rst | 32 > +++--- > tools/testing/selftests/bpf/prog_tests/xdpwall.c | 2 +- > .../selftests/bpf/progs/test_core_reloc_type_id.c | 2 +- > 23 files changed, 40 insertions(+), 40 deletions(-) > --- > base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a > change-id: 20240109-update-llvm-links-d03f9d649e1e > > Best regards, > -- > Nathan Chancellor >
Re: [PATCH 0/3] Update LLVM Phabricator and Bugzilla links
On Wed, Jan 10, 2024 at 4:46 PM Kees Cook wrote: > > On Tue, Jan 09, 2024 at 03:16:28PM -0700, Nathan Chancellor wrote: > > This series updates all instances of LLVM Phabricator and Bugzilla links > > to point to GitHub commits directly and LLVM's Bugzilla to GitHub issue > > shortlinks respectively. > > > > I split up the Phabricator patch into BPF selftests and the rest of the > > kernel in case the BPF folks want to take it separately from the rest of > > the series, there are obviously no dependency issues in that case. The > > Bugzilla change was mechanical enough and should have no conflicts. > > > > I am aiming this at Andrew and CC'ing other lists, in case maintainers > > want to chime in, but I think this is pretty uncontroversial (famous > > last words...). > > > > --- > > Nathan Chancellor (3): > > selftests/bpf: Update LLVM Phabricator links > > arch and include: Update LLVM Phabricator links > > treewide: Update LLVM Bugzilla links > > > > arch/arm64/Kconfig | 4 +-- > > arch/powerpc/Makefile | 4 +-- > > arch/powerpc/kvm/book3s_hv_nested.c| 2 +- > > arch/riscv/Kconfig | 2 +- > > arch/riscv/include/asm/ftrace.h| 2 +- > > arch/s390/include/asm/ftrace.h | 2 +- > > arch/x86/power/Makefile| 2 +- > > crypto/blake2b_generic.c | 2 +- > > drivers/firmware/efi/libstub/Makefile | 2 +- > > drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 2 +- > > drivers/media/test-drivers/vicodec/codec-fwht.c| 2 +- > > drivers/regulator/Kconfig | 2 +- > > include/asm-generic/vmlinux.lds.h | 2 +- > > include/linux/compiler-clang.h | 2 +- > > lib/Kconfig.kasan | 2 +- > > lib/raid6/Makefile | 2 +- > > lib/stackinit_kunit.c | 2 +- > > mm/slab_common.c | 2 +- > > net/bridge/br_multicast.c | 2 +- > > security/Kconfig | 2 +- > > tools/testing/selftests/bpf/README.rst | 32 > > +++--- > > tools/testing/selftests/bpf/prog_tests/xdpwall.c | 2 +- > > .../selftests/bpf/progs/test_core_reloc_type_id.c | 2 +- > > 23 files changed, 40 insertions(+), 40 deletions(-) > > --- > > base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a > > change-id: 20240109-update-llvm-links-d03f9d649e1e > > > > Best regards, > > -- > > Nathan Chancellor > > > > Excellent! Thanks for doing this. I spot checked a handful I was > familiar with and everything looks good to me. > > Reviewed-by: Kees Cook > > -- > Kees Cook > These reviews.llvm.org links would definitely be kept like https://lists.llvm.org/pipermail/llvm-dev/ or cfe-dev links (discussions have been migrated to Discourse). However, I agree that the github repo link looks more official. I have clicked a few links and they look good. Since I maintain reviews.llvm.org and created the static archive [1], Acked-by: Fangrui Song [1]: https://discourse.llvm.org/t/llvm-phabricator-turndown/76137 -- 宋方睿
