Using patches from http://people.freedesktop.org/~agd5f/ 0001-drm-radeon-kms-add-radeon-i2c-algo.patch 0002-drm-radeon-kms-add-support-for-hw-i2c-on-r1xx-r5xx.patch on top of mainline kernel (2.6.33-rc6-git2, one with locally reverted idr commit) i get strange resolution in X, probably related to [drm:r100_hw_i2c_xfer], i2c write error 0x04800302 [drm:edid_is_valid] *ERROR* Raw EDID: <3>00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff ................ <3>00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff ................ <3>00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff ................ <3>00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff ................ <3>00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff ................ <3>00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff ................ <3>00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff ................ <3>00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff ................
Created attachment 33075 [details] dmesg sorry guys, playing "add bug fast, until machine freeze over (under) you"
Created attachment 33076 [details] dmesg wrong log
For this experiment I used mainline kernel commit e9e70bc14ea5974e21f5baecf95a123844c412b9 Merge: c031d52 58424a4 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed Feb 3 16:08:50 2010 -0800 Merge branch 'for-linus' of git://git.monstr.eu/linux-2.6-microblaze with one commit revered: "idr: fix a critical misallocation bug" but it isn't stablest kernel in my life ....
I had similar problems with Alex's initial HW I2C changes, but it's fixed for me with current drm-radeon-testing. Can you try that?
(In reply to comment #4) > I had similar problems with Alex's initial HW I2C changes, but it's fixed for > me with current drm-radeon-testing. Can you try that? > No problems still here with drm-radeon-testing up to commit 6cb8e1f71c407930f0f07feceeea1da73881038b Author: Jerome Glisse <jglisse@redhat.com> Date: Mon Feb 15 21:36:33 2010 +0100 drm/radeon/kms: fix bo's fence association ---- i'll attach dmesg
Created attachment 33339 [details] dmesg Radeon module loaded manually, right after drm module loaded with debug=15. Log captured before X start.
Created attachment 33498 [details] dmesg with drm.debug=15 This is booting latest drm-radeon-testing kernel with drm.debug=15 and not starting X.
I am using latest (45fa67f404bb08ef4b04504766753c28e354ecb2 [rfc] drm/radeon/kms: pm debugging check for vbl.) drm-radeon-testing kernel on rv350 and I have a couple of issues that may be related. First, the resolution after starting X is default 800x600 with xrandr reporting max of 1024x768. I have to manually add 1280x1024 and switch to it. The expected behavior is 1280x1024 default. Also, 3D performance suffers a great deal, about 5% of what it is 'normally'. The kernel I built on Feb 2nd is ok for resolution and 3D but the kernel built on the 15th and 21st of this month exhibit both the resolution and performance (or lack thereof) issues. I have attached a dmesg with drm.debug=15 without starting X that may indicate the resolution problem is related to i2c changes.
Created attachment 33953 [details] dmesg from 2.6.34-rc1-005 This is using 2.6.34-rc1 mainline kernel + patches from http://article.gmane.org/gmane.comp.video.dri.devel/44144 0001-i2c-algo-bit-Add-pre-and-post-xfer-hooks.patch , 0002-drm-radeon-kms-use-new-pre-post_xfer-i2c-bit-algo-h.patch
Created attachment 33961 [details] [review] possible fix Does this patch help?
(In reply to comment #10) > Created an attachment (id=33961) [details] > possible fix > > Does this patch help? > No, same errors in dmesg and wrong resolution in X afterward.
Created attachment 33973 [details] dmesg Dmesg from 2.6.34-rc1 + i2c patches + possible fix
Created attachment 34005 [details] [review] fix i2c prescale calc This patch should hopefully do the trick. Can you try it with and without the previous patch from this bug?
You might also try setting i2c_clock to 50 if you are still having problems.
(In reply to comment #13) > Created an attachment (id=34005) [details] > fix i2c prescale calc > > This patch should hopefully do the trick. Can you try it with and without the > previous patch from this bug? > Tried with and without previous patch, with i2c_clock = 60 and i2c_clock = 50 (and also 40). No good results, slightly different errors about EDID still around.
Created attachment 34014 [details] last two attempt - 60, before - 50
Can you try setting m to the same thing as n? E.g., change: m = loop - 2; to: m = loop - 1; Also try i2c_clock values from 10 to 100;
(In reply to comment #17) > Can you try setting m to the same thing as n? E.g., > change: > m = loop - 2; > to: > m = loop - 1; > > Also try i2c_clock values from 10 to 100; > No luck ... (tried 10, 20, 27, 30, 33, 40, 50, 60, 70, 80, 90 and 100, with m = loop -1 and m=loop-2) Unfortunately, just reloading radeon module produces different results on each load.
Created attachment 34042 [details] random edid on few module load/unloads
Created attachment 34124 [details] [review] use default sclk Perhaps there's a problem reading back the sclk on your system... Does hard coding the sclk to the default value help? Make sure you disable the dynpm stuff (dynpm=0).
(In reply to comment #20) > Created an attachment (id=34124) [details] > use default sclk > > Perhaps there's a problem reading back the sclk on your system... Does hard > coding the sclk to the default value help? Make sure you disable the dynpm > stuff (dynpm=0). > No, original problem still here (I reverted things back to i2c_clock = 60 , m = loop - 2). I haven't tested multiple load/unload this time
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/97.
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.