Hi Greg, Sasha,
Please cherry pick upstream commit b17ef04bf3a4 ("drm/amd/display: Pass pwrseq inst for backlight and ABM") to stable kernel 6.6.x and newer.
This fixes broken backlight adjustment on some AMD platforms with eDP panels.
Thanks,
Alex
On Wed, Jan 17, 2024 at 11:16:27AM -0500, Alex Deucher wrote:
Hi Greg, Sasha,
Please cherry pick upstream commit b17ef04bf3a4 ("drm/amd/display: Pass pwrseq inst for backlight and ABM") to stable kernel 6.6.x and newer.
It does not apply to 6.6.y, how did you test this? I've applied it to 6.7.y now.
For 6.6.y, we need a backported, and tested, version of the commit to do anything here.
thanks,
greg k-h
On Wed, Jan 17, 2024 at 11:49 AM Greg KH gregkh@linuxfoundation.org wrote:
On Wed, Jan 17, 2024 at 11:16:27AM -0500, Alex Deucher wrote:
Hi Greg, Sasha,
Please cherry pick upstream commit b17ef04bf3a4 ("drm/amd/display: Pass pwrseq inst for backlight and ABM") to stable kernel 6.6.x and newer.
It does not apply to 6.6.y, how did you test this? I've applied it to 6.7.y now.
For 6.6.y, we need a backported, and tested, version of the commit to do anything here.
Weird. `git cherry-pick -x b17ef04bf3a4346d66404454d6a646343ddc9749` worked fine here and we tested that.
Oh, I see, there is an unused variable warning in the cherry-pick depending on the config. That must have been what failed. Attached patch should resolve that. Sorry for the confusion.
Alex
On Wed, Jan 17, 2024 at 12:21:27PM -0500, Alex Deucher wrote:
On Wed, Jan 17, 2024 at 11:49 AM Greg KH gregkh@linuxfoundation.org wrote:
On Wed, Jan 17, 2024 at 11:16:27AM -0500, Alex Deucher wrote:
Hi Greg, Sasha,
Please cherry pick upstream commit b17ef04bf3a4 ("drm/amd/display: Pass pwrseq inst for backlight and ABM") to stable kernel 6.6.x and newer.
It does not apply to 6.6.y, how did you test this? I've applied it to 6.7.y now.
For 6.6.y, we need a backported, and tested, version of the commit to do anything here.
Weird. `git cherry-pick -x b17ef04bf3a4346d66404454d6a646343ddc9749` worked fine here and we tested that.
Oh, I see, there is an unused variable warning in the cherry-pick depending on the config. That must have been what failed. Attached patch should resolve that. Sorry for the confusion.
Thanks, now queued up.
greg k-h
Alex Deucher wrote... [ back in January ]
Please cherry pick upstream commit b17ef04bf3a4 ("drm/amd/display: Pass pwrseq inst for backlight and ABM") to stable kernel 6.6.x and newer.
This fixes broken backlight adjustment on some AMD platforms with eDP panels.
Hello,
tl;dr: Was it possible to have this in 6.1.y?
after a lenghty bisect session it seems[1] this commit b17ef04bf3a4 ("drm/amd/display: Pass pwrseq inst for backlight and ABM") indeed fixes an issue with a HP mt645[2]: Without it, the backlight stays at full brightness all the time, writing various values to the usual sysfs place has no effect.
That commit was backported to 6.6.y (as 71be0f674070) but not to 6.1.y - which is the series where I'd like to see that issue fixed. However, is does not apply, lot of failed hunks and missing files. So I was wondering whether it had been skipped deliberately because a backport was deemed impossible - or whether it might be doable with some more-than-usual effort. In the latter case, I might be willing to do the task, but quite frankly, lacking any understanding of what the code does, I'd only try to resolve the conflicts and check whether things work.
So I'd be glad if you could give me some insight here: Would it be worth the efforts trying to bring this to 6.1.y?
Kind regards,
Christoph
[1] Being a bit blurry here for a reason: I bisected on the 6.6.y branch, had to skip several commits as X would no longer start, and ended up with
| There are only 'skip'ped commits left to test. | The first bad commit could be any of: | 18562b1691e2280858f291d00678468cf70bda5a | a5ba95c226b5c25cd5c8b9df29a1953c85a1531e | 71be0f674070a5ad54a1c4fb112bb2923b28ea50 | We cannot bisect more!
where the last one looks like the most obvious candidate, even more after reading this thread, and re-testing with that one on top of the last usable commit indeed gave a positive result.
[2] From lspci:
| e5:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] [1002:1681] (rev 0d)
On Mon, Dec 02, 2024 at 12:33:48PM +0100, Christoph Biedl wrote:
Alex Deucher wrote... [ back in January ]
Please cherry pick upstream commit b17ef04bf3a4 ("drm/amd/display: Pass pwrseq inst for backlight and ABM") to stable kernel 6.6.x and newer.
This fixes broken backlight adjustment on some AMD platforms with eDP panels.
Hello,
tl;dr: Was it possible to have this in 6.1.y?
after a lenghty bisect session it seems[1] this commit b17ef04bf3a4 ("drm/amd/display: Pass pwrseq inst for backlight and ABM") indeed fixes an issue with a HP mt645[2]: Without it, the backlight stays at full brightness all the time, writing various values to the usual sysfs place has no effect.
That commit was backported to 6.6.y (as 71be0f674070) but not to 6.1.y - which is the series where I'd like to see that issue fixed. However, is does not apply, lot of failed hunks and missing files. So I was wondering whether it had been skipped deliberately because a backport was deemed impossible - or whether it might be doable with some more-than-usual effort. In the latter case, I might be willing to do the task, but quite frankly, lacking any understanding of what the code does, I'd only try to resolve the conflicts and check whether things work.
So I'd be glad if you could give me some insight here: Would it be worth the efforts trying to bring this to 6.1.y?
Why not just move to 6.6.y instead? What's preventing that from happening?
thanks,
greg k-h
Greg KH wrote...
On Mon, Dec 02, 2024 at 12:33:48PM +0100, Christoph Biedl wrote:
tl;dr: Was it possible to have this in 6.1.y?
(...)
Why not just move to 6.6.y instead? What's preventing that from happening?
Reasons are mostly political, also switching series this is a bigger change that naturally requires way more careful testing for regressions. It will happen somewhen in the next year anyway, a cherry-picked fix could have been shipped now-ish. But it seems this is not an option.
Christoph
On Thu, Dec 05, 2024 at 02:02:29PM +0100, Christoph Biedl wrote:
Greg KH wrote...
On Mon, Dec 02, 2024 at 12:33:48PM +0100, Christoph Biedl wrote:
tl;dr: Was it possible to have this in 6.1.y?
(...)
Why not just move to 6.6.y instead? What's preventing that from happening?
Reasons are mostly political, also switching series this is a bigger change that naturally requires way more careful testing for regressions.
Then your testing infrastructure is wrong. You need to do careful testing for every stable release, as we sometimes do "major" things in them (like rewrite the syscall path, no one noticed that...)
Your testing framework should be the same for any kernel change, "major" or "minor".
It will happen somewhen in the next year anyway, a cherry-picked fix could have been shipped now-ish. But it seems this is not an option.
Feel free to take it for your own tree if you feel it is needed.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Alex Deucher -
Christoph Biedl -
Greg KH