summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/radeon/radeon_display.c
diff options
context:
space:
mode:
authorRob Clark <robdclark@gmail.com>2016-01-25 18:06:48 -0500
committerAlex Deucher <alexander.deucher@amd.com>2016-01-26 00:35:49 -0500
commitf95429eccc570dc45d589c327bfcfddcdc3e8228 (patch)
tree5c61dd84f3cc6a1465ac0b983dd49a1868d62f55 /drivers/gpu/drm/radeon/radeon_display.c
parent186bac815227a4c26a0ad2f18c7450015d93ed0a (diff)
downloadop-kernel-dev-f95429eccc570dc45d589c327bfcfddcdc3e8228.zip
op-kernel-dev-f95429eccc570dc45d589c327bfcfddcdc3e8228.tar.gz
drm/radeon: only init fbdev if we have connectors
This fixes an issue that was noticed on an optimus/prime laptop with a kernel that was old enough to not support the integrated intel gfx (which was driving all the outputs), but did have support for the discrete radeon gpu. The end result was not falling back to VESA and leaving the user with a black screen. (Plus it is kind of silly to create an framebuffer device if there are no outputs hooked up to the gpu.) Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Diffstat (limited to 'drivers/gpu/drm/radeon/radeon_display.c')
-rw-r--r--drivers/gpu/drm/radeon/radeon_display.c6
1 files changed, 4 insertions, 2 deletions
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
index b3bb923..298ea1c 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1670,8 +1670,10 @@ int radeon_modeset_init(struct radeon_device *rdev)
/* setup afmt */
radeon_afmt_init(rdev);
- radeon_fbdev_init(rdev);
- drm_kms_helper_poll_init(rdev->ddev);
+ if (!list_empty(&rdev->ddev->mode_config.connector_list)) {
+ radeon_fbdev_init(rdev);
+ drm_kms_helper_poll_init(rdev->ddev);
+ }
/* do pm late init */
ret = radeon_pm_late_init(rdev);
OpenPOWER on IntegriCloud