,
On Tue, 29 Jul 2025 at 14:06, Dave Airlie <airl...@gmail.com> wrote:
>
> I've done a pass at merging mostly taking from drm-tip:
> https://github.com/airlied/linux/tree/drm-next-6.17-rc1-merged
Hmm. My resolution is pretty different, but part of it is that your
test-merge has a different top-of-tree than the tree you actually sent
me. I think you added commits
b213eb34f857 ("drm/tidss: oldi: convert to devm_drm_bridge_alloc() API")
66cdf05f8548 ("drm/tidss: encoder: convert to devm_drm_bridge_alloc()")
to the drm tree after you did your test merge.
That said, ignoring those differences, the other ones I'm pretty sure
your merge is wrong. For example, you left a duplicate
err = xe_gt_pagefault_init(gt);
if (err)
return err;
in xe_gt_init().
Also, you didn't undo the dma_buf addition to 'struct
virtio_gpu_object', that was added by commit 44b6535d8ace
("drm/virtio: Fix NULL pointer deref in virtgpu_dma_buf_free_obj()"),
but that commit was a fix for the problems that were reverted by
0ecfb8ddb953 ("Revert "drm/virtio: Use dma_buf from GEM object
instance"").
In etnaviv_sched.c, you seem to have missed the "Rename
DRM_GPU_SCHED_STAT_NOMINAL to DRM_GPU_SCHED_STAT_RESET" in commit
0a5dc1b67ef5.
And you have missing MEDIA_VERSION / GRAPHICS_VERSION entries in
xe_wa_oob.rules from commits c96e0df4e9f5f and b1c37a0030b27.
ANYWAY.
My point isn't so much that I think your merge is wrong - it's very
possible that I have made other mistakes to make up for yours. But my
point really is that these drm merges are rather messy and
error-prone.
And yes, I'm pretty good at sorting merges out, and this was by no
means the messiest merge I've ever seen.
But I do think that the drm people are doing actively wrong things
with the random cherry-picks back and forth: they cause these
conflicts, and I *really* think you should look at maybe using stable
fixes branches instead.
Would that require more care and cleaner trees? Yes. And that's kind
of the point. You are being messy, and it's affecting the quality of
the end result.
And maybe I did get the merge perfectly right. And maybe I didn't.
But the fact that you have *so* many conflicts, and that I'm pretty
damn sure that your example merge was not correct, makes me really go
"your development model is messy and leads to problems".
Again: I'm not going to guarantee that I got it right. I *think* I did
- I'm not feeling particularly unhappy with my merge end result. The
merge was annoying but largely straightforward. And it builds ok for
me ("ship it, it's perfect!"), although I do see an objtool warning:
drivers/gpu/drm/msm/msm.o: warning: objtool:
submit_lock_objects+0x44d: sibling call from callable instruction with
modified stack frame
that makes me go "Hmm".
But that one looks like gcc doing some very strange things with
coverage tracing, so I am currently inclined to blame it on odd
compiler output and objtool rather than the drm tree itself.
But I really wish you had a better model for "backport fixes" than the
mess you have now.
Because it clearly is causing potential problem spots.
Linus
