drm/amd/display: Simply VRR state handling

[KyleGospo]

No description provided.

[NeroReflex]

When you send patches what you want to do is send them correct right away for linux maintainers to pickup not adding fixes as more commits.

The way I do it is that, if I need to rework 2 commits:

git format-patch -2
# this creates two .patch files

git reset --hard HEAD~2
# this removes the latest two commits

git am 0001-*.patch
# apply the first patch
# modify the file manually to resolve issues

git add <file>
git commit --amend

# and 0001 is fixed in-tree with the backup file untouched

# now do the same for 0002, 0003, etc....

note that this is how I do it and there are other ways such as interactive rebase, though I find backing up revisions of my patch files is useful.

Be mindful not to remove all your patches after a reset or you will lose work.

When the thing is fixed I can regenerate the patchset to send upstream with -v{2,3,4,5,....} --cover-letter or do git push --force to brutally overwrite the remote.

[andy10115]

I'm at least partially following you. I was trying to modify my original commits, which seems should have been 1. (Been working in web editor up until recently so still learning vscodium). But this helps. I see the point here as well. Makes something they can instantly pull into they like it.

Seeing this title format is helpful too.

I do want to ask though. Is this actually upstreamable? Works around a issue rather than addressing it. Ha sorry can you tell I just started doing this like maybe a month or two ago?

So what needs to be done on this still?

[NeroReflex]

I'm at least partially following you. I was trying to modify my original commits, which seems should have been 1. (Been working in web editor up until recently so still learning vscodium). But this helps. I see the point here as well. Makes something they can instantly pull into they like it.

Seeing this title format is helpful too.

I do want to ask though. Is this actually upstreamable? Works around a issue rather than addressing it. Ha sorry can you tell I just started doing this like maybe a month or two ago?

That I don't know, but I'd say that if this commit makes something work that before didn't work it has a reason to be sent upstream even if just to make other devs aware of what worked for you.

So what needs to be done on this still?

From your message I understand that this is meant to be a single patch, so make these three patches one again:

1. backup them as I told you before
2. reset the branch into a clean state with the git reset --hard HEAD~3
3. use following commands (*)

commands (*):

patch -p1 < 0001-*.patch
patch -p1 < 0002-*.patch
patch -p1 < 0003-*.patch

git add .

git commit

The commit message begins with drm/amd/display: <title>

The commit message has to respect guidelines, basically write the why you are doing something and what you do as if you were giving git itself a command.

Link: the amd issue you linked to me

or, if this patch solves the issue:

Closes: that same link

Signed-off-by: you

[NeroReflex]

A piece got lost. What's happening here?

[andy10115]

I believe Kyle just included the 2 correct commits. Rather than the first that I corrected.

[KyleGospo]

A piece got lost. What's happening here?

The two commits do two different things, one enables HDMI Desktop VRR, the other makes it so VRR on and off are the same thing, off just sets a single refresh rate.

Both should be applied, but they do different things individually and dont require eachother.

[andy10115]

Looking like maybe this one should be closed?

Appreciate the assist on this either way. Hope I can learn a bit more and try and help here as I'm able.

[NeroReflex]

Looking like maybe this one should be closed?

Appreciate the assist on this either way. Hope I can learn a bit more and try and help here as I'm able.

I am waiting to merge to leave others time to review. Merge will wait at least until tomorrow (a week from first send)

[pastaq]

When you send patches what you want to do is send them correct right away for linux maintainers to pickup not adding fixes as more commits.

The way I do it is that, if I need to rework 2 commits:

git format-patch -2
# this creates two .patch files

git reset --hard HEAD~2
# this removes the latest two commits

git am 0001-*.patch
# apply the first patch
# modify the file manually to resolve issues

git add <file>
git commit --amend

# and 0001 is fixed in-tree with the backup file untouched

# now do the same for 0002, 0003, etc....

note that this is how I do it and there are other ways such as interactive rebase, though I find backing up revisions of my patch files is useful.

Be mindful not to remove all your patches after a reset or you will lose work.

When the thing is fixed I can regenerate the patchset to send upstream with -v{2,3,4,5,....} --cover-letter or do git push --force to brutally overwrite the remote.

This isn't the ideal pattern. Instead of resetting your HEAD you can use this pattern:
git rebase -i <sha to upstream HEAD, the commit before your first commit> (you can get this from git log)
for each patch you want to change, replace pick with edit
This will rewind to the first patch you said edit on, preserving the rest of the series. Make your edits then commit them with git commit --amend, update your commit message and add your change notes under the --- below your signature.

When done, git rebase --continue
This will then jump to one of hte following:

• The first merge conflict. Handle this normally, but don't commit the changes, the next rebase --continue will update the patch. if you git commit --amend it will apply the changes to the previous commit.
• The next patch you changed to edit. Handle this the same way you did for the first edit.
• It will complete and update HEAD.

No reset, no git am, no failed merges from git am on subsequent files. if you make a mistake you can git rebase --abort to reset to previous HEAD and start over.

[NeroReflex]

When you send patches what you want to do is send them correct right away for linux maintainers to pickup not adding fixes as more commits.

The way I do it is that, if I need to rework 2 commits:

git format-patch -2
# this creates two .patch files

git reset --hard HEAD~2
# this removes the latest two commits

git am 0001-*.patch
# apply the first patch
# modify the file manually to resolve issues

git add <file>
git commit --amend

# and 0001 is fixed in-tree with the backup file untouched

# now do the same for 0002, 0003, etc....

note that this is how I do it and there are other ways such as interactive rebase, though I find backing up revisions of my patch files is useful.

Be mindful not to remove all your patches after a reset or you will lose work.

When the thing is fixed I can regenerate the patchset to send upstream with -v{2,3,4,5,....} --cover-letter or do git push --force to brutally overwrite the remote.

This isn't the ideal pattern. Instead of resetting your HEAD you can use this pattern:
git rebase -i <sha to upstream HEAD, the commit before your first commit> (you can get this from git log)
for each patch you want to change, replace pick with edit
This will rewind to the first patch you said edit on, preserving the rest of the series. Make your edits then commit them with git commit --amend, update your commit message and add your change notes under the --- below your signature.

When done, git rebase --continue
This will then jump to one of hte following:

• The first merge conflict. Handle this normally, but don't commit the changes, the next rebase --continue will update the patch. if you git commit --amend it will apply the changes to the previous commit.
• The next patch you changed to edit. Handle this the same way you did for the first edit.
• It will complete and update HEAD.

No reset, no git am, no failed merges from git am on subsequent files. if you make a mistake you can git rebase --abort to reset to previous HEAD and start over.

I tried for ally v3 because I wanted to... I made a mess and doing the v4 took a long time. I will postpone learning this for now, but thanks for the suggestion!

[NeroReflex]

I merged this. Will wait for it to build to get an artifact, but the last patch doesn't apply anymore on top of linux-next master and it's blocking the auto-sync together with another patch so if you need newer releases to cantain these please open another PR pointing to this one: in a few hours I will reset the master of this repo with what applies cleanly.

NVM I'm stupid

[hphilm]

Does this conflict with this VRR patch series? https://lore.kernel.org/dri-devel/20260901191251.2653684-1-jerry.zuo@amd.com/ @andy10115

[andy10115]

Intended to workaround an issue, but intent is for it to work with that patch.

…

On Wed, Sep 2, 2026, 6:34 AM Philip Müller ***@***.***> wrote: *hphilm* left a comment (OpenGamingCollective/linux-unstable#6) <#6 (comment)> Does this conflict with this VRR patch series? ***@***.***/ @andy10115 <https://github.com/andy10115> — Reply to this email directly, view it on GitHub <#6?email_source=notifications&email_token=BG3END3RS7RACAPX5DN2YTL5M7ZUVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJQHAZDCMBSGI3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5508210226>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BG3END5GDFAPKUAZJ55NBTD5M7ZUVAVCNFSNUABGKJSXA33TNF2G64TZHMYTGMZWGAZDAMZTHE5US43TOVSTWNJSGQ4TENJSGYZDJILWAI> . You are receiving this because you were mentioned.Message ID: ***@***.***>