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.