|Summary:||DRM_RADEON should depend on and initialize after DRM_FBDEV_EMULATION and I2C_CHARDEV.|
|Component:||Console/Framebuffers||Assignee:||James Simmons (jsimmons)|
|Kernel Version:||Versions that include DRM_RADEON, DRM_FBDEV_EMULATION, and I2C_CHARDEV||Tree:||Mainline|
|Attachments:||White DRM_RADEON framebuffer console|
Description crocket 2019-03-03 01:11:53 UTC
Created attachment 281469 [details] White DRM_RADEON framebuffer console My GPU is Radeon HD6450. When DRM_FBDEV_EMULATION=n, DRM_RADEON framebuffer loses video signal on all virtual consoles and garbles an X session for the first few seconds. I don't think DRM_FBDEV_EMULATION needs initialization. If I2C_CHARDEV=n or I2C_CHARDEV initializes after DRM_RADEON does, DRM_RADEON framebuffer looks white until an X session is launched. If I2C_CHARDEV=y and DRM_RADEON=m, I2C_CHARDEV always initializes before DRM_RADEON. If I2C_CHARDEV=y and DRM_RADEON=y, I2C_CHARDEV may or may not initialize before DRM_RADEON. If I2C_CHARDEV=m and DRM_RADEON=y, I2C_CHARDEV never initializes before DRM_RADEON. If I2C_CHARDEV=m and DRM_RADEON=m, I2C_CHARDEV may or may not initialize before DRM_RADEON. Note that when DRM_RADEON=y, I set EXTRA_FIRMWARE to (radeon/BTC_rlc.bin radeon/CAICOS_mc.bin radeon/CAICOS_me.bin radeon/CAICOS_pfp.bin radeon/CAICOS_smc.bin radeon/SUMO_uvd.bin) so that DRM_RADEON works properly with Radeon HD6450. * My suggestions 1. DRM_RADEON should depend on DRM_FBDEV_EMULATION. 2. DRM_RADEON should depend on and initialize after I2C_CHARDEV.
Comment 1 crocket 2019-03-04 04:49:11 UTC
Shall I report this issue on freedesktop bugzilla, too? It seems freedesktop bugzilla deals with radeon drivers.
Comment 2 Michel Dänzer 2019-03-05 09:03:15 UTC
(In reply to crocket from comment #0) > When DRM_FBDEV_EMULATION=n, DRM_RADEON framebuffer loses video signal on all > virtual consoles That's expected, as nothing uses the radeon driver for displaying anything in that case. > and garbles an X session for the first few seconds. That sounds like a Xorg driver issue, make sure you're using current xf86-video-ati. > If I2C_CHARDEV=n or I2C_CHARDEV initializes after DRM_RADEON does, > DRM_RADEON framebuffer looks white until an X session is launched. That's probably just bug 198123, which happens randomly, not directly related to I2C_CHARDEV.
Comment 3 crocket 2019-03-05 10:14:59 UTC
(In reply to Michel Dänzer from comment #2) > That's probably just bug 198123, which happens randomly, not directly > related to I2C_CHARDEV. I tested various combinations of I2C_CHARDEV and DRM_RADEON several times by compiling kernel and kernel modules. I could reproduce the issue reliably. With I2C_CHARDEV=y and DRM_RADEON=y, whenever I2C_CHARDEV initializes after DRM_RADEON, DRM_RADEON framebuffer becomes white. With I2C_CHARDEV=y and DRM_RADEON=m, I2C_CHARDEV always initializes before DRM_RADEON, and DRM_RADEON framebuffer never becomes white.
Comment 4 crocket 2019-03-05 10:18:58 UTC
`grep -ri i2c /usr/src/linux/drivers/gpu/drm/radeon` reveals that DRM_RADEON depends on i2c_bus. The dependence on i2c_bus explains why I2C_CHARDEV is critical to DRM_RADEON.
Comment 5 crocket 2019-09-07 22:14:15 UTC
Even with DRM_FBDEV_EMULATION=y and I2C_CHARDEV=y, radeondrmfb sometimes becomes white during boot. I don't understand the reason, yet. Perhaps, God is telling me to buy a new graphics card.