Bug 26430

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.