In file radeon_atombios.c, function rhdAtomFirmwareInfoQuery, for firmware content revisions 2,3 and 4, usMinPixelClockPLL_Output is used instead of ulMinPixelClockPLL_Output and le16_to_cpu should be changed to le32_to_cpu for those cases.
The same bug is in radeonhd driver, file rhd_atombios.c, function rhdAtomFirmwareInfoQuery. Should I create an identical bug report in radeonhd category?
(In reply to comment #1) > Should I create an identical bug report in radeonhd category? Probably not, the radeonhd driver isn't being actively developed anymore. Can you create a Git patch fixing the problem and send it to the xorg-driver-ati mailing list at lists.x.org?
Can you submit a patch? Hardly anyone uses or maintains the UMS code any more and for those that do us it, it's working in most cases, so I'd don't think this is critical.
Created attachment 59084 [details] [review] the patch The function rhdAtomFirmwareInfoQuery has the same functionality as RADEONGetATOMClockInfo, we should try to eliminate duplicate code. RADEONGetATOMClockInfo did not have the bug, that is the reason no problems were detected before. rhdAtomFirmwareInfoQuery is used in radeon_bios.c (function RADEONGetBIOSInfo) for no reason (the results are not used) and is also used to report the values in the log, so the only problem was to see pll_out_min as 0 even when the used value was correct. If I find time I will try to fix all that or I will just wait until KMS replaces UMS for all of us. I do not use git, If you want to apply the patch, please do it. If you don't, everything will continue working ok.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.