[KMS] Hw i2c patch doesn't work fully on rv280

Submitted by Andrew Randrianasulu

Assigned to Default DRI bug account

Link to original bug (#26430)

Description

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 ................

added Radeon bugzilla labels

Andrew Randrianasulu uploaded an attachment:

sorry guys, playing "add bug fast, until machine freeze over (under) you"

Attachment 33075, "dmesg":
dmesg

Andrew Randrianasulu uploaded an attachment:

wrong log

Attachment 33076, "dmesg":
dmesg_failed_edid.log

Andrew Randrianasulu said:

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 ....

Michel Dänzer @daenzer said:

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?

Andrew Randrianasulu said:

(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
Date: Mon Feb 15 21:36:33 2010 +0100

drm/radeon/kms: fix bo's fence association
----

i'll attach dmesg

Andrew Randrianasulu uploaded an attachment:

Radeon module loaded manually, right after drm module loaded with debug=15. Log captured before X start.

Attachment 33339, "dmesg":
dmesg_failed_edid_5.log

Scott Moreau @oreaus uploaded an attachment:

This is booting latest drm-radeon-testing kernel with drm.debug=15 and not starting X.

Attachment 33498, "dmesg with drm.debug=15":
dmesg.drm-debug

Scott Moreau @oreaus said:

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.

Andrew Randrianasulu uploaded an attachment:

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

Attachment 33953, "dmesg from 2.6.34-rc1-005":
rv280_i2c_dmesg.log

Alex Deucher @agd5f submitted a patch:

Does this patch help?

Patch 33961, "possible fix":
0001-drm-radeon-kms-fix-for-hw-i2c.patch

Andrew Randrianasulu said:

(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.

Andrew Randrianasulu uploaded an attachment:

Dmesg from 2.6.34-rc1 + i2c patches + possible fix

Attachment 33973, "dmesg":
rv280_i2c_dmesg_2.log

Alex Deucher @agd5f submitted a patch:

This patch should hopefully do the trick. Can you try it with and without the previous patch from this bug?

Patch 34005, "fix i2c prescale calc":
0001-drm-radeon-kms-fix-i2c-prescale-calc-on-older-radeo.patch

Alex Deucher @agd5f said:

You might also try setting i2c_clock to 50 if you are still having problems.

Andrew Randrianasulu said:

(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.

Andrew Randrianasulu uploaded an attachment:

Attachment 34014, "last two attempt - 60, before - 50":
rv280_i2c_dmesg_prescale_50_60.log

Alex Deucher @agd5f said:

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;

Andrew Randrianasulu said:

(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.

Andrew Randrianasulu uploaded an attachment:

Attachment 34042, "random edid on few module load/unloads":
rv280_i2c_dmesg_random.log

Alex Deucher @agd5f submitted a patch:

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).

Patch 34124, "use default sclk":
bug26430.diff

Andrew Randrianasulu said:

(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

closed