Bug 200045 - black screen on 'radeon' module probing
Summary: black screen on 'radeon' module probing
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-12 21:00 UTC by Sergey Larin
Modified: 2018-06-16 13:22 UTC (History)
2 users (show)

See Also:
Kernel Version: 4.16
Subsystem:
Regression: No
Bisected commit-id:


Attachments
lspci -v (11.49 KB, text/plain)
2018-06-12 21:00 UTC, Sergey Larin
Details
print initial states to allow further debug (672 bytes, patch)
2018-06-14 15:27 UTC, Wolfram Sang
Details | Diff
WIP to test (1.33 KB, patch)
2018-06-15 13:28 UTC, Wolfram Sang
Details | Diff

Description Sergey Larin 2018-06-12 21:00:45 UTC
Created attachment 276499 [details]
lspci -v

Hi,

After updating to the 4.16 kernel I started to get a black screen on boot, without something useful in log. This bug also happens in latest version (4.17.1). I'm using HP Pavilion dv6-3090er laptop with an exotic ATI/AMD switchable graphics (radeon 4250 integrated/5650 discrete).

I bisected the issue down to commit 3e5f06bed72fe72166a6778f630241a893f67799
("i2c: algo-bit: init the bus to a known state") and reverting this fixes the problem. Also loading radeon module with hw_i2c=1 gives me working display with full brightness, and attempt to change it results in reboot.

Thanks.
Comment 1 Sergey Larin 2018-06-13 08:13:32 UTC
Ok, actually this is 4.17 issue; on 4.16 hw_i2c=1 fixes the issue completely, but on 4.17 changing backlight in Xorg (using keys) causes a reboot, fbcon works fine though.
Comment 2 Wolfram Sang 2018-06-13 09:35:24 UTC
Okay, these are actually two bug reports meanwhile:

1) 3e5f06bed72fe72166a6778f630241a893f67799 causes a regression when bit-banging I2C in software and results in keeping the screen black.

2) There is some regression when using the a HW interface for I2C which causes a reboot when changing the brightness.

I'd suggest to work only on 1) here and create a new bug report for 2). I should be able to give you some patches to test in a few minutes.

Thanks for the report and the bisecting!
Comment 3 Sergey Larin 2018-06-13 10:47:21 UTC
I did some more research and it turns out that 2) happens if I change brightness level right after X starts, even in 4.15 kernel. If I wait a bit, everything works good, including 4.17.1. Software I2C doesn't reproduce same results, so I'm not sure if I should report 2) because it's stated that it can cause issues, but with different kind of errors:

[drm] hw_i2c forced on, you may experience display detection problems!
Comment 4 Alex Deucher 2018-06-13 14:12:04 UTC
hw_i2c doesn't use bit banging, it uses the hw i2c engine.
Comment 5 Wolfram Sang 2018-06-14 01:30:45 UTC
Sure. But reading the original description above, I think the default use case is to not use hw_i2c. It was just added to try to work around the regression. And that led to another bug. Or am I wrong here?
Comment 6 Wolfram Sang 2018-06-14 01:33:03 UTC
So, I really posted the patches now. Sorry, I got side-tracked.

They can be found here:

http://patchwork.ozlabs.org/patch/929185/
http://patchwork.ozlabs.org/patch/929186/

I set you on CC as well. As indicated in the cover letter, could you try these patches one by one?

Thanks and kind regards.
Comment 7 Alex Deucher 2018-06-14 13:09:50 UTC
(In reply to Wolfram Sang from comment #5)
> Sure. But reading the original description above, I think the default use
> case is to not use hw_i2c. It was just added to try to work around the
> regression. And that led to another bug. Or am I wrong here?

Correct.  I was just clarifying that that option does.
Comment 8 Sergey Larin 2018-06-14 13:58:07 UTC
Ok, I tested the patches, but they did not fix the problem. Nothing changed, and the log is empty. I tried to apply them separately and both at the same time. Note that second one seems to depend on the first, so I had to apply it manually.

Thanks for trying to fix the issue!
Comment 9 Wolfram Sang 2018-06-14 15:27:55 UTC
Created attachment 276551 [details]
print initial states to allow further debug

Thanks for testing the patches, pity it didn't help.

Would you mind testing with the attached patch? It should give some output about the initial states. Let's hope that will lead to something...
Comment 10 Sergey Larin 2018-06-14 15:47:59 UTC
Here is the output:

[   23.056329]  (null): initial SCL state 1
[   23.056330]  (null): initial SDA state 1
[   23.056532]  (null): initial SCL state 1
[   23.056534]  (null): initial SDA state 1
[   23.056578]  (null): initial SCL state 0
[   23.056580]  (null): initial SDA state 0
[   23.056617]  (null): initial SCL state 0
[   23.056618]  (null): initial SDA state 0
[   23.056656]  (null): initial SCL state 0
[   23.056657]  (null): initial SDA state 0
Comment 11 Wolfram Sang 2018-06-15 05:19:36 UTC
I have sent another patch, let's hope it really is this issue:

http://patchwork.ozlabs.org/patch/929798/
Comment 12 Sergey Larin 2018-06-15 06:03:58 UTC
Teset this, but it did not help.
Comment 13 Wolfram Sang 2018-06-15 13:28:50 UTC
Created attachment 276571 [details]
WIP to test

Pity that it didn't work. The thing is that I am quite sure the pre/post_xfer calls are needed. I am running out of ideas now.

The best thing I can come up with is this patch which adds all the stuff altogether. I don't have high hopes, but maybe all 3 improvements make it work. At least, the debug output will be better, it was a bit meaningless before.

If this still doesn't work, could you move the new code block from this patch after the add_adapter() call and try again (with the old block still deleted)?

Thanks for all the testing!
Comment 14 Sergey Larin 2018-06-15 14:59:45 UTC
Still nothing changed... This is what I got in both cases:

[   57.656675] Radeon i2c bit bus 0x90: initial SCL state 1
[   57.656678] Radeon i2c bit bus 0x90: initial SDA state 1
[   57.656805] Radeon i2c bit bus 0x91: initial SCL state 1
[   57.656807] Radeon i2c bit bus 0x91: initial SDA state 1
[   57.656921] Radeon i2c bit bus 0x92: initial SCL state 0
[   57.656924] Radeon i2c bit bus 0x92: initial SDA state 1
[   57.660108] Radeon i2c bit bus 0x93: initial SCL state 0
[   57.660111] Radeon i2c bit bus 0x93: initial SDA state 0
[   57.664128] Radeon i2c bit bus 0x14: initial SCL state 0
[   57.664131] Radeon i2c bit bus 0x14: initial SDA state 0

And if I leave only printing code (i.e get the working state):

[   23.992763] Radeon i2c bit bus 0x90: initial SCL state 1
[   23.992766] Radeon i2c bit bus 0x90: initial SDA state 1
[   23.992851] Radeon i2c bit bus 0x91: initial SCL state 1
[   23.992854] Radeon i2c bit bus 0x91: initial SDA state 1
[   23.992938] Radeon i2c bit bus 0x92: initial SCL state 0
[   23.992941] Radeon i2c bit bus 0x92: initial SDA state 0
[   23.993080] Radeon i2c bit bus 0x93: initial SCL state 0
[   23.993082] Radeon i2c bit bus 0x93: initial SDA state 0
[   23.993146] Radeon i2c bit bus 0x14: initial SCL state 0
[   23.993148] Radeon i2c bit bus 0x14: initial SDA state 0
Comment 15 Wolfram Sang 2018-06-16 12:25:45 UTC
I will just revert this commit. I have no further ideas for remote debugging. I think reverting is the safest solution for now, I can't find any patches since v4.16 which added users to this bitbanging algorithm. So, there can't be anyone depending on the new functionality. And I will try to fix my original issue one layer above at the i2c-gpio level.

Thanks for reporting! Would you reveal your real name for a proper "Reported-by:" tag?
Comment 16 Sergey Larin 2018-06-16 13:22:42 UTC
My name is Sergey Larin, I added it to my account. Thanks for your help!

Note You need to log in before you can comment on or make changes to this bug.