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 --- drivers/gpu/drm/radeon/radeon_display.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 1eca0ac..f8e776c 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);
Is something similar required for AMDGPU too?
On Mon, 25 Jan 2016 at 23:06 Rob Clark robdclark@gmail.com wrote:
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
drivers/gpu/drm/radeon/radeon_display.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 1eca0ac..f8e776c 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);-- 2.5.0
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
from a quick look, I think so..
It was something I ran across on an older kernel which didn't have amdgpu, but I don't see anything obvious that would cause drm_fb_helper_init() to be skipped in amdgpu if there are no connectors.. (but nouveau seems to check for dev->mode_config.num_crtc, for (I assume) similar reasons)
BR, -R
On Mon, Jan 25, 2016 at 6:57 PM, Mike Lothian mike@fireburn.co.uk wrote:
Is something similar required for AMDGPU too?
On Mon, 25 Jan 2016 at 23:06 Rob Clark robdclark@gmail.com wrote:
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
drivers/gpu/drm/radeon/radeon_display.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 1eca0ac..f8e776c 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);-- 2.5.0
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Jan 25, 2016 at 7:49 PM, Rob Clark robdclark@gmail.com wrote:
from a quick look, I think so..
It was something I ran across on an older kernel which didn't have amdgpu, but I don't see anything obvious that would cause drm_fb_helper_init() to be skipped in amdgpu if there are no connectors.. (but nouveau seems to check for dev->mode_config.num_crtc, for (I assume) similar reasons)
We don't enable fbdev on amdgpu if the chip in question has no display block, but we still could enable it if the chip has a display block, but no connectors. The same may be true in nouveau so the check for num_crtc may not be enough. Attached patch should rectify that.
Alex
BR, -R
On Mon, Jan 25, 2016 at 6:57 PM, Mike Lothian mike@fireburn.co.uk wrote:
Is something similar required for AMDGPU too?
On Mon, 25 Jan 2016 at 23:06 Rob Clark robdclark@gmail.com wrote:
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
drivers/gpu/drm/radeon/radeon_display.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 1eca0ac..f8e776c 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);-- 2.5.0
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Jan 25, 2016 at 6:06 PM, Rob Clark robdclark@gmail.com wrote:
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
Applied. thanks!
Alex
drivers/gpu/drm/radeon/radeon_display.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 1eca0ac..f8e776c 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);-- 2.5.0
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Mike Lothian -
Rob Clark