DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
/*
|
|
|
|
* Copyright © 2007 David Airlie
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the next
|
|
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
* Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
|
|
|
|
* DEALINGS IN THE SOFTWARE.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* David Airlie
|
|
|
|
*/
|
|
|
|
|
2014-05-29 04:39:03 +07:00
|
|
|
#include <linux/async.h>
|
2014-08-13 19:09:46 +07:00
|
|
|
#include <linux/console.h>
|
2019-04-05 18:00:16 +07:00
|
|
|
#include <linux/delay.h>
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
#include <linux/errno.h>
|
2019-04-05 18:00:16 +07:00
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/kernel.h>
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
#include <linux/mm.h>
|
2019-04-05 18:00:16 +07:00
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/string.h>
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
#include <linux/sysrq.h>
|
2019-04-05 18:00:16 +07:00
|
|
|
#include <linux/tty.h>
|
2010-02-01 12:38:10 +07:00
|
|
|
#include <linux/vga_switcheroo.h>
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
|
2012-10-03 00:01:07 +07:00
|
|
|
#include <drm/drm_crtc.h>
|
|
|
|
#include <drm/drm_fb_helper.h>
|
2019-01-18 04:03:34 +07:00
|
|
|
#include <drm/drm_fourcc.h>
|
2019-04-05 18:00:16 +07:00
|
|
|
#include <drm/i915_drm.h>
|
2019-01-18 04:03:34 +07:00
|
|
|
|
2019-04-05 18:00:16 +07:00
|
|
|
#include "i915_drv.h"
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
#include "intel_drv.h"
|
2019-04-05 18:00:16 +07:00
|
|
|
#include "intel_fbdev.h"
|
2016-08-04 22:32:35 +07:00
|
|
|
#include "intel_frontbuffer.h"
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
|
2017-02-15 17:59:19 +07:00
|
|
|
static void intel_fbdev_invalidate(struct intel_fbdev *ifbdev)
|
|
|
|
{
|
2018-05-18 21:30:07 +07:00
|
|
|
struct drm_i915_gem_object *obj = intel_fb_obj(&ifbdev->fb->base);
|
2018-02-20 20:42:07 +07:00
|
|
|
unsigned int origin =
|
|
|
|
ifbdev->vma_flags & PLANE_HAS_FENCE ? ORIGIN_GTT : ORIGIN_CPU;
|
2017-02-15 17:59:19 +07:00
|
|
|
|
|
|
|
intel_fb_obj_invalidate(obj, origin);
|
|
|
|
}
|
|
|
|
|
2014-06-18 20:05:19 +07:00
|
|
|
static int intel_fbdev_set_par(struct fb_info *info)
|
|
|
|
{
|
|
|
|
struct drm_fb_helper *fb_helper = info->par;
|
|
|
|
struct intel_fbdev *ifbdev =
|
|
|
|
container_of(fb_helper, struct intel_fbdev, helper);
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = drm_fb_helper_set_par(info);
|
2017-02-15 17:59:19 +07:00
|
|
|
if (ret == 0)
|
|
|
|
intel_fbdev_invalidate(ifbdev);
|
2014-06-18 20:05:19 +07:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2015-03-10 07:57:07 +07:00
|
|
|
static int intel_fbdev_blank(int blank, struct fb_info *info)
|
|
|
|
{
|
|
|
|
struct drm_fb_helper *fb_helper = info->par;
|
|
|
|
struct intel_fbdev *ifbdev =
|
|
|
|
container_of(fb_helper, struct intel_fbdev, helper);
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = drm_fb_helper_blank(blank, info);
|
2017-02-15 17:59:19 +07:00
|
|
|
if (ret == 0)
|
|
|
|
intel_fbdev_invalidate(ifbdev);
|
2015-03-10 07:57:07 +07:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2015-05-29 00:26:58 +07:00
|
|
|
static int intel_fbdev_pan_display(struct fb_var_screeninfo *var,
|
|
|
|
struct fb_info *info)
|
|
|
|
{
|
|
|
|
struct drm_fb_helper *fb_helper = info->par;
|
|
|
|
struct intel_fbdev *ifbdev =
|
|
|
|
container_of(fb_helper, struct intel_fbdev, helper);
|
|
|
|
int ret;
|
|
|
|
|
2017-02-15 17:59:19 +07:00
|
|
|
ret = drm_fb_helper_pan_display(var, info);
|
|
|
|
if (ret == 0)
|
|
|
|
intel_fbdev_invalidate(ifbdev);
|
2015-05-29 00:26:58 +07:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
static struct fb_ops intelfb_ops = {
|
|
|
|
.owner = THIS_MODULE,
|
2016-11-14 06:03:27 +07:00
|
|
|
DRM_FB_HELPER_DEFAULT_OPS,
|
2014-06-18 20:05:19 +07:00
|
|
|
.fb_set_par = intel_fbdev_set_par,
|
2015-07-31 17:51:56 +07:00
|
|
|
.fb_fillrect = drm_fb_helper_cfb_fillrect,
|
|
|
|
.fb_copyarea = drm_fb_helper_cfb_copyarea,
|
|
|
|
.fb_imageblit = drm_fb_helper_cfb_imageblit,
|
2015-05-29 00:26:58 +07:00
|
|
|
.fb_pan_display = intel_fbdev_pan_display,
|
2015-03-10 07:57:07 +07:00
|
|
|
.fb_blank = intel_fbdev_blank,
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
};
|
|
|
|
|
2013-11-26 06:51:16 +07:00
|
|
|
static int intelfb_alloc(struct drm_fb_helper *helper,
|
|
|
|
struct drm_fb_helper_surface_size *sizes)
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
{
|
2013-06-01 00:07:05 +07:00
|
|
|
struct intel_fbdev *ifbdev =
|
|
|
|
container_of(helper, struct intel_fbdev, helper);
|
2015-12-19 21:40:39 +07:00
|
|
|
struct drm_framebuffer *fb;
|
2013-06-01 00:07:05 +07:00
|
|
|
struct drm_device *dev = helper->dev;
|
2015-09-23 22:52:23 +07:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2012-05-25 01:08:56 +07:00
|
|
|
struct drm_mode_fb_cmd2 mode_cmd = {};
|
2017-02-15 17:59:18 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2010-12-21 02:10:39 +07:00
|
|
|
int size, ret;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
|
2009-10-06 10:54:01 +07:00
|
|
|
/* we don't do packed 24bpp */
|
2010-03-30 12:34:13 +07:00
|
|
|
if (sizes->surface_bpp == 24)
|
|
|
|
sizes->surface_bpp = 32;
|
2009-10-06 10:54:01 +07:00
|
|
|
|
2010-03-30 12:34:13 +07:00
|
|
|
mode_cmd.width = sizes->surface_width;
|
|
|
|
mode_cmd.height = sizes->surface_height;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
|
2013-10-19 04:48:24 +07:00
|
|
|
mode_cmd.pitches[0] = ALIGN(mode_cmd.width *
|
|
|
|
DIV_ROUND_UP(sizes->surface_bpp, 8), 64);
|
2011-11-15 05:51:28 +07:00
|
|
|
mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
|
|
|
|
sizes->surface_depth);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
|
2011-11-15 05:51:28 +07:00
|
|
|
size = mode_cmd.pitches[0] * mode_cmd.height;
|
2014-07-02 01:39:41 +07:00
|
|
|
size = PAGE_ALIGN(size);
|
2015-09-23 22:52:23 +07:00
|
|
|
|
|
|
|
/* If the FB is too big, just don't use it since fbdev is not very
|
|
|
|
* important and we should probably use that space with FBC or other
|
|
|
|
* features. */
|
2017-02-15 17:59:18 +07:00
|
|
|
obj = NULL;
|
2017-12-11 22:18:21 +07:00
|
|
|
if (size * 2 < dev_priv->stolen_usable_size)
|
2016-12-01 21:16:36 +07:00
|
|
|
obj = i915_gem_object_create_stolen(dev_priv, size);
|
2012-11-15 18:32:27 +07:00
|
|
|
if (obj == NULL)
|
2016-12-01 21:16:37 +07:00
|
|
|
obj = i915_gem_object_create(dev_priv, size);
|
2016-04-25 19:32:13 +07:00
|
|
|
if (IS_ERR(obj)) {
|
2009-06-29 05:42:17 +07:00
|
|
|
DRM_ERROR("failed to allocate framebuffer\n");
|
2016-04-25 19:32:13 +07:00
|
|
|
ret = PTR_ERR(obj);
|
2017-02-15 17:59:18 +07:00
|
|
|
goto err;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
}
|
|
|
|
|
2017-02-15 17:59:18 +07:00
|
|
|
fb = intel_framebuffer_create(obj, &mode_cmd);
|
2014-02-11 00:00:39 +07:00
|
|
|
if (IS_ERR(fb)) {
|
|
|
|
ret = PTR_ERR(fb);
|
2017-02-15 17:59:18 +07:00
|
|
|
goto err_obj;
|
2014-10-30 23:39:38 +07:00
|
|
|
}
|
|
|
|
|
2014-02-11 00:00:39 +07:00
|
|
|
ifbdev->fb = to_intel_framebuffer(fb);
|
2013-11-26 06:51:16 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2017-02-15 17:59:18 +07:00
|
|
|
err_obj:
|
|
|
|
i915_gem_object_put(obj);
|
|
|
|
err:
|
2013-11-26 06:51:16 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int intelfb_create(struct drm_fb_helper *helper,
|
|
|
|
struct drm_fb_helper_surface_size *sizes)
|
|
|
|
{
|
|
|
|
struct intel_fbdev *ifbdev =
|
|
|
|
container_of(helper, struct intel_fbdev, helper);
|
2014-02-08 03:10:38 +07:00
|
|
|
struct intel_framebuffer *intel_fb = ifbdev->fb;
|
2013-11-26 06:51:16 +07:00
|
|
|
struct drm_device *dev = helper->dev;
|
2016-03-30 20:57:10 +07:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2016-08-22 17:32:44 +07:00
|
|
|
struct pci_dev *pdev = dev_priv->drm.pdev;
|
2016-03-30 20:57:10 +07:00
|
|
|
struct i915_ggtt *ggtt = &dev_priv->ggtt;
|
2018-09-07 22:24:06 +07:00
|
|
|
const struct i915_ggtt_view view = {
|
|
|
|
.type = I915_GGTT_VIEW_NORMAL,
|
|
|
|
};
|
2013-11-26 06:51:16 +07:00
|
|
|
struct drm_framebuffer *fb;
|
2019-01-14 21:21:19 +07:00
|
|
|
intel_wakeref_t wakeref;
|
|
|
|
struct fb_info *info;
|
2016-04-28 15:56:39 +07:00
|
|
|
struct i915_vma *vma;
|
2018-02-20 20:42:06 +07:00
|
|
|
unsigned long flags = 0;
|
2014-03-07 23:57:51 +07:00
|
|
|
bool prealloc = false;
|
2016-07-20 19:31:55 +07:00
|
|
|
void __iomem *vaddr;
|
2016-04-28 15:56:39 +07:00
|
|
|
int ret;
|
2013-11-26 06:51:16 +07:00
|
|
|
|
2014-04-23 14:54:31 +07:00
|
|
|
if (intel_fb &&
|
|
|
|
(sizes->fb_width > intel_fb->base.width ||
|
|
|
|
sizes->fb_height > intel_fb->base.height)) {
|
|
|
|
DRM_DEBUG_KMS("BIOS fb too small (%dx%d), we require (%dx%d),"
|
|
|
|
" releasing it\n",
|
|
|
|
intel_fb->base.width, intel_fb->base.height,
|
|
|
|
sizes->fb_width, sizes->fb_height);
|
2017-10-09 19:06:43 +07:00
|
|
|
drm_framebuffer_put(&intel_fb->base);
|
2014-04-23 14:54:31 +07:00
|
|
|
intel_fb = ifbdev->fb = NULL;
|
|
|
|
}
|
2018-05-18 21:30:07 +07:00
|
|
|
if (!intel_fb || WARN_ON(!intel_fb_obj(&intel_fb->base))) {
|
2013-11-27 02:25:54 +07:00
|
|
|
DRM_DEBUG_KMS("no BIOS fb, allocating a new one\n");
|
2013-11-26 06:51:16 +07:00
|
|
|
ret = intelfb_alloc(helper, sizes);
|
|
|
|
if (ret)
|
2015-06-30 16:06:27 +07:00
|
|
|
return ret;
|
2014-02-08 03:10:38 +07:00
|
|
|
intel_fb = ifbdev->fb;
|
2013-11-26 06:51:16 +07:00
|
|
|
} else {
|
2013-11-27 02:25:54 +07:00
|
|
|
DRM_DEBUG_KMS("re-using BIOS fb\n");
|
2014-03-07 23:57:51 +07:00
|
|
|
prealloc = true;
|
2013-11-26 06:51:16 +07:00
|
|
|
sizes->fb_width = intel_fb->base.width;
|
|
|
|
sizes->fb_height = intel_fb->base.height;
|
|
|
|
}
|
|
|
|
|
2015-06-30 16:06:27 +07:00
|
|
|
mutex_lock(&dev->struct_mutex);
|
2019-01-14 21:21:19 +07:00
|
|
|
wakeref = intel_runtime_pm_get(dev_priv);
|
2015-06-30 16:06:27 +07:00
|
|
|
|
2015-12-04 23:05:26 +07:00
|
|
|
/* Pin the GGTT vma for our access via info->screen_base.
|
|
|
|
* This also validates that any existing fb inherited from the
|
|
|
|
* BIOS is suitable for own access.
|
|
|
|
*/
|
2018-02-20 20:42:06 +07:00
|
|
|
vma = intel_pin_and_fence_fb_obj(&ifbdev->fb->base,
|
2018-09-07 22:24:06 +07:00
|
|
|
&view, false, &flags);
|
2016-08-15 16:49:06 +07:00
|
|
|
if (IS_ERR(vma)) {
|
|
|
|
ret = PTR_ERR(vma);
|
2015-12-04 23:05:26 +07:00
|
|
|
goto out_unlock;
|
2016-08-15 16:49:06 +07:00
|
|
|
}
|
2015-12-04 23:05:26 +07:00
|
|
|
|
2018-03-07 10:34:18 +07:00
|
|
|
fb = &ifbdev->fb->base;
|
|
|
|
intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_DIRTYFB);
|
|
|
|
|
2015-07-31 17:51:56 +07:00
|
|
|
info = drm_fb_helper_alloc_fbi(helper);
|
|
|
|
if (IS_ERR(info)) {
|
2015-11-18 22:29:51 +07:00
|
|
|
DRM_ERROR("Failed to allocate fb_info\n");
|
2015-07-31 17:51:56 +07:00
|
|
|
ret = PTR_ERR(info);
|
2009-02-11 21:26:36 +07:00
|
|
|
goto out_unpin;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
}
|
|
|
|
|
2010-03-30 12:34:13 +07:00
|
|
|
ifbdev->helper.fb = fb;
|
2009-08-28 12:46:53 +07:00
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
info->fbops = &intelfb_ops;
|
|
|
|
|
2009-06-17 05:34:38 +07:00
|
|
|
/* setup aperture base/size for vesafb takeover */
|
2010-05-16 22:27:03 +07:00
|
|
|
info->apertures->ranges[0].base = dev->mode_config.fb_base;
|
2016-03-30 20:57:10 +07:00
|
|
|
info->apertures->ranges[0].size = ggtt->mappable_end;
|
2009-06-17 05:34:38 +07:00
|
|
|
|
2016-08-15 16:49:07 +07:00
|
|
|
info->fix.smem_start = dev->mode_config.fb_base + i915_ggtt_offset(vma);
|
2016-04-28 15:56:39 +07:00
|
|
|
info->fix.smem_len = vma->node.size;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
|
2016-04-28 15:56:39 +07:00
|
|
|
vaddr = i915_vma_pin_iomap(vma);
|
|
|
|
if (IS_ERR(vaddr)) {
|
2015-11-18 22:29:51 +07:00
|
|
|
DRM_ERROR("Failed to remap framebuffer into virtual memory\n");
|
2016-04-28 15:56:39 +07:00
|
|
|
ret = PTR_ERR(vaddr);
|
2017-02-07 23:16:03 +07:00
|
|
|
goto out_unpin;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
}
|
2016-04-28 15:56:39 +07:00
|
|
|
info->screen_base = vaddr;
|
|
|
|
info->screen_size = vma->node.size;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
|
2019-03-26 20:19:58 +07:00
|
|
|
drm_fb_helper_fill_info(info, &ifbdev->helper, sizes);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
|
2012-12-16 19:15:41 +07:00
|
|
|
/* If the object is shmemfs backed, it will have given us zeroed pages.
|
|
|
|
* If the object is stolen however, it will be full of whatever
|
|
|
|
* garbage was left in there.
|
|
|
|
*/
|
2018-05-18 21:30:07 +07:00
|
|
|
if (intel_fb_obj(fb)->stolen && !prealloc)
|
2012-12-16 19:15:41 +07:00
|
|
|
memset_io(info->screen_base, 0, info->screen_size);
|
|
|
|
|
2012-02-06 16:58:19 +07:00
|
|
|
/* Use default scratch pixmap (info->pixmap.flags = FB_PIXMAP_SYSTEM) */
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
|
2016-08-15 16:49:07 +07:00
|
|
|
DRM_DEBUG_KMS("allocated %dx%d fb: 0x%08x\n",
|
|
|
|
fb->width, fb->height, i915_ggtt_offset(vma));
|
2016-08-15 16:49:06 +07:00
|
|
|
ifbdev->vma = vma;
|
2018-02-20 20:42:06 +07:00
|
|
|
ifbdev->vma_flags = flags;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
|
2019-01-14 21:21:19 +07:00
|
|
|
intel_runtime_pm_put(dev_priv, wakeref);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2016-08-22 17:32:44 +07:00
|
|
|
vga_switcheroo_client_fb_set(pdev, info);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
return 0;
|
|
|
|
|
2009-02-11 21:26:36 +07:00
|
|
|
out_unpin:
|
2018-02-20 20:42:06 +07:00
|
|
|
intel_unpin_fb_vma(vma, flags);
|
2015-12-04 23:05:26 +07:00
|
|
|
out_unlock:
|
2019-01-14 21:21:19 +07:00
|
|
|
intel_runtime_pm_put(dev_priv, wakeref);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-06-27 22:19:23 +07:00
|
|
|
static const struct drm_fb_helper_funcs intel_fb_helper_funcs = {
|
2013-01-22 05:42:49 +07:00
|
|
|
.fb_probe = intelfb_create,
|
2010-03-30 12:34:18 +07:00
|
|
|
};
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
|
2016-06-21 15:16:54 +07:00
|
|
|
static void intel_fbdev_destroy(struct intel_fbdev *ifbdev)
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
{
|
2015-12-04 23:05:26 +07:00
|
|
|
/* We rely on the object-free to release the VMA pinning for
|
|
|
|
* the info->screen_base mmaping. Leaking the VMA is simpler than
|
|
|
|
* trying to rectify all the possible error paths leading here.
|
|
|
|
*/
|
2013-08-06 23:43:07 +07:00
|
|
|
|
2010-03-30 12:34:18 +07:00
|
|
|
drm_fb_helper_fini(&ifbdev->helper);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
|
2017-06-22 23:02:11 +07:00
|
|
|
if (ifbdev->vma) {
|
2016-06-21 15:16:54 +07:00
|
|
|
mutex_lock(&ifbdev->helper.dev->struct_mutex);
|
2018-02-20 20:42:06 +07:00
|
|
|
intel_unpin_fb_vma(ifbdev->vma, ifbdev->vma_flags);
|
2016-06-21 15:16:54 +07:00
|
|
|
mutex_unlock(&ifbdev->helper.dev->struct_mutex);
|
2017-06-22 23:02:11 +07:00
|
|
|
}
|
2016-04-28 15:56:35 +07:00
|
|
|
|
2017-06-22 23:02:11 +07:00
|
|
|
if (ifbdev->fb)
|
2015-11-18 19:43:20 +07:00
|
|
|
drm_framebuffer_remove(&ifbdev->fb->base);
|
2016-06-21 15:16:54 +07:00
|
|
|
|
|
|
|
kfree(ifbdev);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
}
|
2010-03-30 12:34:13 +07:00
|
|
|
|
2014-03-07 23:57:51 +07:00
|
|
|
/*
|
|
|
|
* Build an intel_fbdev struct using a BIOS allocated framebuffer, if possible.
|
|
|
|
* The core display code will have read out the current plane configuration,
|
|
|
|
* so we use that to figure out if there's an object for us to use as the
|
|
|
|
* fb, and if so, we re-use it for the fbdev configuration.
|
|
|
|
*
|
|
|
|
* Note we only support a single fb shared across pipes for boot (mostly for
|
|
|
|
* fbcon), so we just find the biggest and use that.
|
|
|
|
*/
|
|
|
|
static bool intel_fbdev_init_bios(struct drm_device *dev,
|
|
|
|
struct intel_fbdev *ifbdev)
|
|
|
|
{
|
|
|
|
struct intel_framebuffer *fb = NULL;
|
|
|
|
struct drm_crtc *crtc;
|
|
|
|
struct intel_crtc *intel_crtc;
|
|
|
|
unsigned int max_size = 0;
|
|
|
|
|
|
|
|
/* Find the largest fb */
|
2014-05-14 05:32:24 +07:00
|
|
|
for_each_crtc(dev, crtc) {
|
2015-07-13 21:30:16 +07:00
|
|
|
struct drm_i915_gem_object *obj =
|
|
|
|
intel_fb_obj(crtc->primary->state->fb);
|
2014-03-07 23:57:51 +07:00
|
|
|
intel_crtc = to_intel_crtc(crtc);
|
|
|
|
|
2015-08-27 20:44:03 +07:00
|
|
|
if (!crtc->state->active || !obj) {
|
2014-03-07 23:57:51 +07:00
|
|
|
DRM_DEBUG_KMS("pipe %c not active or no fb, skipping\n",
|
|
|
|
pipe_name(intel_crtc->pipe));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2015-07-13 21:30:16 +07:00
|
|
|
if (obj->base.size > max_size) {
|
2014-03-07 23:57:51 +07:00
|
|
|
DRM_DEBUG_KMS("found possible fb from plane %c\n",
|
|
|
|
pipe_name(intel_crtc->pipe));
|
2015-07-13 21:30:16 +07:00
|
|
|
fb = to_intel_framebuffer(crtc->primary->state->fb);
|
|
|
|
max_size = obj->base.size;
|
2014-03-07 23:57:51 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!fb) {
|
|
|
|
DRM_DEBUG_KMS("no active fbs found, not using BIOS config\n");
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now make sure all the pipes will fit into it */
|
2014-05-14 05:32:24 +07:00
|
|
|
for_each_crtc(dev, crtc) {
|
2014-03-07 23:57:51 +07:00
|
|
|
unsigned int cur_size;
|
|
|
|
|
|
|
|
intel_crtc = to_intel_crtc(crtc);
|
|
|
|
|
2015-08-27 20:44:03 +07:00
|
|
|
if (!crtc->state->active) {
|
2014-03-07 23:57:51 +07:00
|
|
|
DRM_DEBUG_KMS("pipe %c not active, skipping\n",
|
|
|
|
pipe_name(intel_crtc->pipe));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
DRM_DEBUG_KMS("checking plane %c for BIOS fb\n",
|
|
|
|
pipe_name(intel_crtc->pipe));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* See if the plane fb we found above will fit on this
|
2014-03-20 22:11:21 +07:00
|
|
|
* pipe. Note we need to use the selected fb's pitch and bpp
|
|
|
|
* rather than the current pipe's, since they differ.
|
2014-03-07 23:57:51 +07:00
|
|
|
*/
|
2018-10-04 16:46:01 +07:00
|
|
|
cur_size = crtc->state->adjusted_mode.crtc_hdisplay;
|
2016-12-15 04:32:20 +07:00
|
|
|
cur_size = cur_size * fb->base.format->cpp[0];
|
2014-03-20 22:11:21 +07:00
|
|
|
if (fb->base.pitches[0] < cur_size) {
|
|
|
|
DRM_DEBUG_KMS("fb not wide enough for plane %c (%d vs %d)\n",
|
|
|
|
pipe_name(intel_crtc->pipe),
|
|
|
|
cur_size, fb->base.pitches[0]);
|
|
|
|
fb = NULL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2018-10-04 16:46:01 +07:00
|
|
|
cur_size = crtc->state->adjusted_mode.crtc_vdisplay;
|
2017-03-08 02:42:06 +07:00
|
|
|
cur_size = intel_fb_align_height(&fb->base, 0, cur_size);
|
2014-03-20 22:11:21 +07:00
|
|
|
cur_size *= fb->base.pitches[0];
|
|
|
|
DRM_DEBUG_KMS("pipe %c area: %dx%d, bpp: %d, size: %d\n",
|
|
|
|
pipe_name(intel_crtc->pipe),
|
2018-10-04 16:46:01 +07:00
|
|
|
crtc->state->adjusted_mode.crtc_hdisplay,
|
|
|
|
crtc->state->adjusted_mode.crtc_vdisplay,
|
2016-12-15 04:32:20 +07:00
|
|
|
fb->base.format->cpp[0] * 8,
|
2014-03-07 23:57:51 +07:00
|
|
|
cur_size);
|
|
|
|
|
|
|
|
if (cur_size > max_size) {
|
|
|
|
DRM_DEBUG_KMS("fb not big enough for plane %c (%d vs %d)\n",
|
|
|
|
pipe_name(intel_crtc->pipe),
|
|
|
|
cur_size, max_size);
|
|
|
|
fb = NULL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
DRM_DEBUG_KMS("fb big enough for plane %c (%d >= %d)\n",
|
|
|
|
pipe_name(intel_crtc->pipe),
|
|
|
|
max_size, cur_size);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!fb) {
|
|
|
|
DRM_DEBUG_KMS("BIOS fb not suitable for all pipes, not using\n");
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2016-12-15 04:32:20 +07:00
|
|
|
ifbdev->preferred_bpp = fb->base.format->cpp[0] * 8;
|
2014-03-07 23:57:51 +07:00
|
|
|
ifbdev->fb = fb;
|
|
|
|
|
2017-10-09 19:06:43 +07:00
|
|
|
drm_framebuffer_get(&ifbdev->fb->base);
|
2014-03-07 23:57:51 +07:00
|
|
|
|
|
|
|
/* Final pass to check if any active pipes don't have fbs */
|
2014-05-14 05:32:24 +07:00
|
|
|
for_each_crtc(dev, crtc) {
|
2014-03-07 23:57:51 +07:00
|
|
|
intel_crtc = to_intel_crtc(crtc);
|
|
|
|
|
2015-08-27 20:44:03 +07:00
|
|
|
if (!crtc->state->active)
|
2014-03-07 23:57:51 +07:00
|
|
|
continue;
|
|
|
|
|
2018-03-22 22:22:59 +07:00
|
|
|
WARN(!crtc->primary->state->fb,
|
2014-03-07 23:57:51 +07:00
|
|
|
"re-used BIOS config but lost an fb on crtc %d\n",
|
|
|
|
crtc->base.id);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
DRM_DEBUG_KMS("using BIOS fb for initial console\n");
|
|
|
|
return true;
|
|
|
|
|
|
|
|
out:
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-08-13 19:09:46 +07:00
|
|
|
static void intel_fbdev_suspend_worker(struct work_struct *work)
|
|
|
|
{
|
2016-07-05 16:40:23 +07:00
|
|
|
intel_fbdev_set_suspend(&container_of(work,
|
|
|
|
struct drm_i915_private,
|
|
|
|
fbdev_suspend_work)->drm,
|
2014-08-13 19:09:46 +07:00
|
|
|
FBINFO_STATE_RUNNING,
|
|
|
|
true);
|
|
|
|
}
|
|
|
|
|
2010-03-30 12:34:13 +07:00
|
|
|
int intel_fbdev_init(struct drm_device *dev)
|
|
|
|
{
|
2016-07-04 17:34:36 +07:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2016-11-09 18:30:45 +07:00
|
|
|
struct intel_fbdev *ifbdev;
|
2010-06-06 16:50:03 +07:00
|
|
|
int ret;
|
2010-03-30 12:34:14 +07:00
|
|
|
|
2018-12-01 06:20:47 +07:00
|
|
|
if (WARN_ON(!HAS_DISPLAY(dev_priv)))
|
2014-03-07 23:57:51 +07:00
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
ifbdev = kzalloc(sizeof(struct intel_fbdev), GFP_KERNEL);
|
|
|
|
if (ifbdev == NULL)
|
2010-03-30 12:34:14 +07:00
|
|
|
return -ENOMEM;
|
|
|
|
|
drm/i915: Block fbdev HPD processing during suspend
When resuming, we check whether or not any previously connected
MST topologies are still present and if so, attempt to resume them. If
this fails, we disable said MST topologies and fire off a hotplug event
so that userspace knows to reprobe.
However, sending a hotplug event involves calling
drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a
connector reprobe in the caller's thread - something we can't do at the
point in which i915 calls drm_dp_mst_topology_mgr_resume() since
hotplugging hasn't been fully initialized yet.
This currently causes some rather subtle but fatal issues. For example,
on my T480s the laptop dock connected to it usually disappears during a
suspend cycle, and comes back up a short while after the system has been
resumed. This guarantees pretty much every suspend and resume cycle,
drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn,
a connector hotplug will occur. Now it's Rute Goldberg time: when the
connector hotplug occurs, i915 reprobes /all/ of the connectors,
including eDP. However, eDP probing requires that we power on the panel
VDD which in turn, grabs a wakeref to the appropriate power domain on
the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where
things start breaking, since this all happens before
intel_power_domains_enable() is called we end up leaking the wakeref
that was acquired and never releasing it later. Come next suspend/resume
cycle, this causes us to fail to shut down the GPU properly, which
causes it not to resume properly and die a horrible complicated death.
(as a note: this only happens when there's both an eDP panel and MST
topology connected which is removed mid-suspend. One or the other seems
to always be OK).
We could try to fix the VDD wakeref leak, but this doesn't seem like
it's worth it at all since we aren't able to handle hotplug detection
while resuming anyway. So, let's go with a more robust solution inspired
by nouveau: block fbdev from handling hotplug events until we resume
fbdev. This allows us to still send sysfs hotplug events to be handled
later by user space while we're resuming, while also preventing us from
actually processing any hotplug events we receive until it's safe.
This fixes the wakeref leak observed on the T480s and as such, also
fixes suspend/resume with MST topologies connected on this machine.
Changes since v2:
* Don't call drm_fb_helper_hotplug_event() under lock, do it after lock
(Chris Wilson)
* Don't call drm_fb_helper_hotplug_event() in
intel_fbdev_output_poll_changed() under lock (Chris Wilson)
* Always set ifbdev->hpd_waiting (Chris Wilson)
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: Todd Previte <tprevite@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v3.17+
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129191001.442-2-lyude@redhat.com
2019-01-30 02:09:59 +07:00
|
|
|
mutex_init(&ifbdev->hpd_lock);
|
2014-06-27 22:19:24 +07:00
|
|
|
drm_fb_helper_prepare(dev, &ifbdev->helper, &intel_fb_helper_funcs);
|
|
|
|
|
2014-03-07 23:57:51 +07:00
|
|
|
if (!intel_fbdev_init_bios(dev, ifbdev))
|
|
|
|
ifbdev->preferred_bpp = 32;
|
2010-03-30 12:34:18 +07:00
|
|
|
|
drm: Rely on mode_config data for fb_helper initialization
Instead of receiving the num_crts as a parameter, we can read it
directly from the mode_config structure. I audited the drivers that
invoke this helper and I believe all of them initialize the mode_config
struct accordingly, prior to calling the fb_helper.
I used the following coccinelle hack to make this transformation, except
for the function headers and comment updates. The first and second
rules are split because I couldn't find a way to remove the unused
temporary variables at the same time I removed the parameter.
// <smpl>
@r@
expression A,B,D,E;
identifier C;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)
@@
expression A,B,C,D,E;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)
@@
identifier r.C;
type T;
expression V;
@@
- T C;
<...
when != C
- C = V;
...>
// </smpl>
Changes since v1:
- Rebased on top of the tip of drm-misc-next.
- Remove mention to sti since a proper fix got merged.
Suggested-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202162640.27261-1-krisman@collabora.co.uk
2017-02-02 23:26:40 +07:00
|
|
|
ret = drm_fb_helper_init(dev, &ifbdev->helper, 4);
|
2010-06-06 16:50:03 +07:00
|
|
|
if (ret) {
|
|
|
|
kfree(ifbdev);
|
|
|
|
return ret;
|
|
|
|
}
|
2010-03-30 12:34:14 +07:00
|
|
|
|
2014-03-07 23:57:51 +07:00
|
|
|
dev_priv->fbdev = ifbdev;
|
2014-08-13 19:09:46 +07:00
|
|
|
INIT_WORK(&dev_priv->fbdev_suspend_work, intel_fbdev_suspend_worker);
|
|
|
|
|
2010-03-30 12:34:15 +07:00
|
|
|
drm_fb_helper_single_add_all_connectors(&ifbdev->helper);
|
2012-12-11 20:05:07 +07:00
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 05:24:08 +07:00
|
|
|
return 0;
|
|
|
|
}
|
2010-03-30 12:34:13 +07:00
|
|
|
|
2015-11-06 20:08:33 +07:00
|
|
|
static void intel_fbdev_initial_config(void *data, async_cookie_t cookie)
|
2012-12-11 20:05:07 +07:00
|
|
|
{
|
2016-06-21 15:16:54 +07:00
|
|
|
struct intel_fbdev *ifbdev = data;
|
2012-12-11 20:05:07 +07:00
|
|
|
|
|
|
|
/* Due to peculiar init order wrt to hpd handling this is separate. */
|
2015-11-18 22:29:51 +07:00
|
|
|
if (drm_fb_helper_initial_config(&ifbdev->helper,
|
2017-11-26 02:41:55 +07:00
|
|
|
ifbdev->preferred_bpp))
|
2017-07-15 05:46:55 +07:00
|
|
|
intel_fbdev_unregister(to_i915(ifbdev->helper.dev));
|
2012-12-11 20:05:07 +07:00
|
|
|
}
|
|
|
|
|
2015-11-06 20:08:33 +07:00
|
|
|
void intel_fbdev_initial_config_async(struct drm_device *dev)
|
|
|
|
{
|
2016-06-21 15:16:54 +07:00
|
|
|
struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
|
|
|
|
|
2017-01-19 04:38:43 +07:00
|
|
|
if (!ifbdev)
|
|
|
|
return;
|
|
|
|
|
2016-06-21 15:16:54 +07:00
|
|
|
ifbdev->cookie = async_schedule(intel_fbdev_initial_config, ifbdev);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void intel_fbdev_sync(struct intel_fbdev *ifbdev)
|
|
|
|
{
|
|
|
|
if (!ifbdev->cookie)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Only serialises with all preceding async calls, hence +1 */
|
|
|
|
async_synchronize_cookie(ifbdev->cookie + 1);
|
|
|
|
ifbdev->cookie = 0;
|
2015-11-06 20:08:33 +07:00
|
|
|
}
|
|
|
|
|
2017-07-15 05:46:55 +07:00
|
|
|
void intel_fbdev_unregister(struct drm_i915_private *dev_priv)
|
2010-03-30 12:34:13 +07:00
|
|
|
{
|
2016-06-21 15:16:54 +07:00
|
|
|
struct intel_fbdev *ifbdev = dev_priv->fbdev;
|
|
|
|
|
|
|
|
if (!ifbdev)
|
2010-03-30 12:34:14 +07:00
|
|
|
return;
|
|
|
|
|
2016-07-14 00:34:44 +07:00
|
|
|
cancel_work_sync(&dev_priv->fbdev_suspend_work);
|
2015-11-18 22:29:51 +07:00
|
|
|
if (!current_is_async())
|
2016-06-21 15:16:54 +07:00
|
|
|
intel_fbdev_sync(ifbdev);
|
|
|
|
|
2017-07-15 05:46:55 +07:00
|
|
|
drm_fb_helper_unregister_fbi(&ifbdev->helper);
|
|
|
|
}
|
|
|
|
|
|
|
|
void intel_fbdev_fini(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
|
|
|
struct intel_fbdev *ifbdev = fetch_and_zero(&dev_priv->fbdev);
|
|
|
|
|
|
|
|
if (!ifbdev)
|
|
|
|
return;
|
|
|
|
|
2016-06-21 15:16:54 +07:00
|
|
|
intel_fbdev_destroy(ifbdev);
|
2010-03-30 12:34:13 +07:00
|
|
|
}
|
2012-03-28 16:48:49 +07:00
|
|
|
|
drm/i915: Block fbdev HPD processing during suspend
When resuming, we check whether or not any previously connected
MST topologies are still present and if so, attempt to resume them. If
this fails, we disable said MST topologies and fire off a hotplug event
so that userspace knows to reprobe.
However, sending a hotplug event involves calling
drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a
connector reprobe in the caller's thread - something we can't do at the
point in which i915 calls drm_dp_mst_topology_mgr_resume() since
hotplugging hasn't been fully initialized yet.
This currently causes some rather subtle but fatal issues. For example,
on my T480s the laptop dock connected to it usually disappears during a
suspend cycle, and comes back up a short while after the system has been
resumed. This guarantees pretty much every suspend and resume cycle,
drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn,
a connector hotplug will occur. Now it's Rute Goldberg time: when the
connector hotplug occurs, i915 reprobes /all/ of the connectors,
including eDP. However, eDP probing requires that we power on the panel
VDD which in turn, grabs a wakeref to the appropriate power domain on
the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where
things start breaking, since this all happens before
intel_power_domains_enable() is called we end up leaking the wakeref
that was acquired and never releasing it later. Come next suspend/resume
cycle, this causes us to fail to shut down the GPU properly, which
causes it not to resume properly and die a horrible complicated death.
(as a note: this only happens when there's both an eDP panel and MST
topology connected which is removed mid-suspend. One or the other seems
to always be OK).
We could try to fix the VDD wakeref leak, but this doesn't seem like
it's worth it at all since we aren't able to handle hotplug detection
while resuming anyway. So, let's go with a more robust solution inspired
by nouveau: block fbdev from handling hotplug events until we resume
fbdev. This allows us to still send sysfs hotplug events to be handled
later by user space while we're resuming, while also preventing us from
actually processing any hotplug events we receive until it's safe.
This fixes the wakeref leak observed on the T480s and as such, also
fixes suspend/resume with MST topologies connected on this machine.
Changes since v2:
* Don't call drm_fb_helper_hotplug_event() under lock, do it after lock
(Chris Wilson)
* Don't call drm_fb_helper_hotplug_event() in
intel_fbdev_output_poll_changed() under lock (Chris Wilson)
* Always set ifbdev->hpd_waiting (Chris Wilson)
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: Todd Previte <tprevite@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v3.17+
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129191001.442-2-lyude@redhat.com
2019-01-30 02:09:59 +07:00
|
|
|
/* Suspends/resumes fbdev processing of incoming HPD events. When resuming HPD
|
|
|
|
* processing, fbdev will perform a full connector reprobe if a hotplug event
|
|
|
|
* was received while HPD was suspended.
|
|
|
|
*/
|
|
|
|
static void intel_fbdev_hpd_set_suspend(struct intel_fbdev *ifbdev, int state)
|
|
|
|
{
|
|
|
|
bool send_hpd = false;
|
|
|
|
|
|
|
|
mutex_lock(&ifbdev->hpd_lock);
|
|
|
|
ifbdev->hpd_suspended = state == FBINFO_STATE_SUSPENDED;
|
|
|
|
send_hpd = !ifbdev->hpd_suspended && ifbdev->hpd_waiting;
|
|
|
|
ifbdev->hpd_waiting = false;
|
|
|
|
mutex_unlock(&ifbdev->hpd_lock);
|
|
|
|
|
|
|
|
if (send_hpd) {
|
|
|
|
DRM_DEBUG_KMS("Handling delayed fbcon HPD event\n");
|
|
|
|
drm_fb_helper_hotplug_event(&ifbdev->helper);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-08-13 19:09:46 +07:00
|
|
|
void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool synchronous)
|
2012-03-28 16:48:49 +07:00
|
|
|
{
|
2016-07-04 17:34:36 +07:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2013-05-07 22:54:05 +07:00
|
|
|
struct intel_fbdev *ifbdev = dev_priv->fbdev;
|
|
|
|
struct fb_info *info;
|
|
|
|
|
2017-06-22 23:02:11 +07:00
|
|
|
if (!ifbdev || !ifbdev->vma)
|
2012-03-28 16:48:49 +07:00
|
|
|
return;
|
|
|
|
|
2013-05-07 22:54:05 +07:00
|
|
|
info = ifbdev->helper.fbdev;
|
|
|
|
|
2014-08-13 19:09:46 +07:00
|
|
|
if (synchronous) {
|
|
|
|
/* Flush any pending work to turn the console on, and then
|
|
|
|
* wait to turn it off. It must be synchronous as we are
|
|
|
|
* about to suspend or unload the driver.
|
|
|
|
*
|
|
|
|
* Note that from within the work-handler, we cannot flush
|
|
|
|
* ourselves, so only flush outstanding work upon suspend!
|
|
|
|
*/
|
|
|
|
if (state != FBINFO_STATE_RUNNING)
|
|
|
|
flush_work(&dev_priv->fbdev_suspend_work);
|
drm/i915: Block fbdev HPD processing during suspend
When resuming, we check whether or not any previously connected
MST topologies are still present and if so, attempt to resume them. If
this fails, we disable said MST topologies and fire off a hotplug event
so that userspace knows to reprobe.
However, sending a hotplug event involves calling
drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a
connector reprobe in the caller's thread - something we can't do at the
point in which i915 calls drm_dp_mst_topology_mgr_resume() since
hotplugging hasn't been fully initialized yet.
This currently causes some rather subtle but fatal issues. For example,
on my T480s the laptop dock connected to it usually disappears during a
suspend cycle, and comes back up a short while after the system has been
resumed. This guarantees pretty much every suspend and resume cycle,
drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn,
a connector hotplug will occur. Now it's Rute Goldberg time: when the
connector hotplug occurs, i915 reprobes /all/ of the connectors,
including eDP. However, eDP probing requires that we power on the panel
VDD which in turn, grabs a wakeref to the appropriate power domain on
the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where
things start breaking, since this all happens before
intel_power_domains_enable() is called we end up leaking the wakeref
that was acquired and never releasing it later. Come next suspend/resume
cycle, this causes us to fail to shut down the GPU properly, which
causes it not to resume properly and die a horrible complicated death.
(as a note: this only happens when there's both an eDP panel and MST
topology connected which is removed mid-suspend. One or the other seems
to always be OK).
We could try to fix the VDD wakeref leak, but this doesn't seem like
it's worth it at all since we aren't able to handle hotplug detection
while resuming anyway. So, let's go with a more robust solution inspired
by nouveau: block fbdev from handling hotplug events until we resume
fbdev. This allows us to still send sysfs hotplug events to be handled
later by user space while we're resuming, while also preventing us from
actually processing any hotplug events we receive until it's safe.
This fixes the wakeref leak observed on the T480s and as such, also
fixes suspend/resume with MST topologies connected on this machine.
Changes since v2:
* Don't call drm_fb_helper_hotplug_event() under lock, do it after lock
(Chris Wilson)
* Don't call drm_fb_helper_hotplug_event() in
intel_fbdev_output_poll_changed() under lock (Chris Wilson)
* Always set ifbdev->hpd_waiting (Chris Wilson)
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: Todd Previte <tprevite@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v3.17+
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129191001.442-2-lyude@redhat.com
2019-01-30 02:09:59 +07:00
|
|
|
|
2014-08-13 19:09:46 +07:00
|
|
|
console_lock();
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* The console lock can be pretty contented on resume due
|
|
|
|
* to all the printk activity. Try to keep it out of the hot
|
|
|
|
* path of resume if possible.
|
|
|
|
*/
|
|
|
|
WARN_ON(state != FBINFO_STATE_RUNNING);
|
|
|
|
if (!console_trylock()) {
|
|
|
|
/* Don't block our own workqueue as this can
|
|
|
|
* be run in parallel with other i915.ko tasks.
|
|
|
|
*/
|
|
|
|
schedule_work(&dev_priv->fbdev_suspend_work);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-07 22:54:05 +07:00
|
|
|
/* On resume from hibernation: If the object is shmemfs backed, it has
|
|
|
|
* been restored from swap. If the object is stolen however, it will be
|
|
|
|
* full of whatever garbage was left in there.
|
|
|
|
*/
|
2018-05-18 21:30:07 +07:00
|
|
|
if (state == FBINFO_STATE_RUNNING &&
|
|
|
|
intel_fb_obj(&ifbdev->fb->base)->stolen)
|
2013-05-07 22:54:05 +07:00
|
|
|
memset_io(info->screen_base, 0, info->screen_size);
|
|
|
|
|
2015-07-31 17:51:56 +07:00
|
|
|
drm_fb_helper_set_suspend(&ifbdev->helper, state);
|
2014-08-13 19:09:46 +07:00
|
|
|
console_unlock();
|
drm/i915: Block fbdev HPD processing during suspend
When resuming, we check whether or not any previously connected
MST topologies are still present and if so, attempt to resume them. If
this fails, we disable said MST topologies and fire off a hotplug event
so that userspace knows to reprobe.
However, sending a hotplug event involves calling
drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a
connector reprobe in the caller's thread - something we can't do at the
point in which i915 calls drm_dp_mst_topology_mgr_resume() since
hotplugging hasn't been fully initialized yet.
This currently causes some rather subtle but fatal issues. For example,
on my T480s the laptop dock connected to it usually disappears during a
suspend cycle, and comes back up a short while after the system has been
resumed. This guarantees pretty much every suspend and resume cycle,
drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn,
a connector hotplug will occur. Now it's Rute Goldberg time: when the
connector hotplug occurs, i915 reprobes /all/ of the connectors,
including eDP. However, eDP probing requires that we power on the panel
VDD which in turn, grabs a wakeref to the appropriate power domain on
the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where
things start breaking, since this all happens before
intel_power_domains_enable() is called we end up leaking the wakeref
that was acquired and never releasing it later. Come next suspend/resume
cycle, this causes us to fail to shut down the GPU properly, which
causes it not to resume properly and die a horrible complicated death.
(as a note: this only happens when there's both an eDP panel and MST
topology connected which is removed mid-suspend. One or the other seems
to always be OK).
We could try to fix the VDD wakeref leak, but this doesn't seem like
it's worth it at all since we aren't able to handle hotplug detection
while resuming anyway. So, let's go with a more robust solution inspired
by nouveau: block fbdev from handling hotplug events until we resume
fbdev. This allows us to still send sysfs hotplug events to be handled
later by user space while we're resuming, while also preventing us from
actually processing any hotplug events we receive until it's safe.
This fixes the wakeref leak observed on the T480s and as such, also
fixes suspend/resume with MST topologies connected on this machine.
Changes since v2:
* Don't call drm_fb_helper_hotplug_event() under lock, do it after lock
(Chris Wilson)
* Don't call drm_fb_helper_hotplug_event() in
intel_fbdev_output_poll_changed() under lock (Chris Wilson)
* Always set ifbdev->hpd_waiting (Chris Wilson)
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: Todd Previte <tprevite@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v3.17+
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129191001.442-2-lyude@redhat.com
2019-01-30 02:09:59 +07:00
|
|
|
|
|
|
|
intel_fbdev_hpd_set_suspend(ifbdev, state);
|
2012-03-28 16:48:49 +07:00
|
|
|
}
|
|
|
|
|
2013-10-08 22:44:49 +07:00
|
|
|
void intel_fbdev_output_poll_changed(struct drm_device *dev)
|
2010-05-07 13:42:51 +07:00
|
|
|
{
|
2016-07-14 00:34:45 +07:00
|
|
|
struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
|
drm/i915: Block fbdev HPD processing during suspend
When resuming, we check whether or not any previously connected
MST topologies are still present and if so, attempt to resume them. If
this fails, we disable said MST topologies and fire off a hotplug event
so that userspace knows to reprobe.
However, sending a hotplug event involves calling
drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a
connector reprobe in the caller's thread - something we can't do at the
point in which i915 calls drm_dp_mst_topology_mgr_resume() since
hotplugging hasn't been fully initialized yet.
This currently causes some rather subtle but fatal issues. For example,
on my T480s the laptop dock connected to it usually disappears during a
suspend cycle, and comes back up a short while after the system has been
resumed. This guarantees pretty much every suspend and resume cycle,
drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn,
a connector hotplug will occur. Now it's Rute Goldberg time: when the
connector hotplug occurs, i915 reprobes /all/ of the connectors,
including eDP. However, eDP probing requires that we power on the panel
VDD which in turn, grabs a wakeref to the appropriate power domain on
the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where
things start breaking, since this all happens before
intel_power_domains_enable() is called we end up leaking the wakeref
that was acquired and never releasing it later. Come next suspend/resume
cycle, this causes us to fail to shut down the GPU properly, which
causes it not to resume properly and die a horrible complicated death.
(as a note: this only happens when there's both an eDP panel and MST
topology connected which is removed mid-suspend. One or the other seems
to always be OK).
We could try to fix the VDD wakeref leak, but this doesn't seem like
it's worth it at all since we aren't able to handle hotplug detection
while resuming anyway. So, let's go with a more robust solution inspired
by nouveau: block fbdev from handling hotplug events until we resume
fbdev. This allows us to still send sysfs hotplug events to be handled
later by user space while we're resuming, while also preventing us from
actually processing any hotplug events we receive until it's safe.
This fixes the wakeref leak observed on the T480s and as such, also
fixes suspend/resume with MST topologies connected on this machine.
Changes since v2:
* Don't call drm_fb_helper_hotplug_event() under lock, do it after lock
(Chris Wilson)
* Don't call drm_fb_helper_hotplug_event() in
intel_fbdev_output_poll_changed() under lock (Chris Wilson)
* Always set ifbdev->hpd_waiting (Chris Wilson)
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: Todd Previte <tprevite@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v3.17+
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129191001.442-2-lyude@redhat.com
2019-01-30 02:09:59 +07:00
|
|
|
bool send_hpd;
|
2016-07-14 00:34:45 +07:00
|
|
|
|
2017-11-26 02:41:55 +07:00
|
|
|
if (!ifbdev)
|
|
|
|
return;
|
|
|
|
|
|
|
|
intel_fbdev_sync(ifbdev);
|
drm/i915: Block fbdev HPD processing during suspend
When resuming, we check whether or not any previously connected
MST topologies are still present and if so, attempt to resume them. If
this fails, we disable said MST topologies and fire off a hotplug event
so that userspace knows to reprobe.
However, sending a hotplug event involves calling
drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a
connector reprobe in the caller's thread - something we can't do at the
point in which i915 calls drm_dp_mst_topology_mgr_resume() since
hotplugging hasn't been fully initialized yet.
This currently causes some rather subtle but fatal issues. For example,
on my T480s the laptop dock connected to it usually disappears during a
suspend cycle, and comes back up a short while after the system has been
resumed. This guarantees pretty much every suspend and resume cycle,
drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn,
a connector hotplug will occur. Now it's Rute Goldberg time: when the
connector hotplug occurs, i915 reprobes /all/ of the connectors,
including eDP. However, eDP probing requires that we power on the panel
VDD which in turn, grabs a wakeref to the appropriate power domain on
the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where
things start breaking, since this all happens before
intel_power_domains_enable() is called we end up leaking the wakeref
that was acquired and never releasing it later. Come next suspend/resume
cycle, this causes us to fail to shut down the GPU properly, which
causes it not to resume properly and die a horrible complicated death.
(as a note: this only happens when there's both an eDP panel and MST
topology connected which is removed mid-suspend. One or the other seems
to always be OK).
We could try to fix the VDD wakeref leak, but this doesn't seem like
it's worth it at all since we aren't able to handle hotplug detection
while resuming anyway. So, let's go with a more robust solution inspired
by nouveau: block fbdev from handling hotplug events until we resume
fbdev. This allows us to still send sysfs hotplug events to be handled
later by user space while we're resuming, while also preventing us from
actually processing any hotplug events we receive until it's safe.
This fixes the wakeref leak observed on the T480s and as such, also
fixes suspend/resume with MST topologies connected on this machine.
Changes since v2:
* Don't call drm_fb_helper_hotplug_event() under lock, do it after lock
(Chris Wilson)
* Don't call drm_fb_helper_hotplug_event() in
intel_fbdev_output_poll_changed() under lock (Chris Wilson)
* Always set ifbdev->hpd_waiting (Chris Wilson)
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: Todd Previte <tprevite@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v3.17+
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129191001.442-2-lyude@redhat.com
2019-01-30 02:09:59 +07:00
|
|
|
|
|
|
|
mutex_lock(&ifbdev->hpd_lock);
|
|
|
|
send_hpd = !ifbdev->hpd_suspended;
|
|
|
|
ifbdev->hpd_waiting = true;
|
|
|
|
mutex_unlock(&ifbdev->hpd_lock);
|
|
|
|
|
|
|
|
if (send_hpd && (ifbdev->vma || ifbdev->helper.deferred_setup))
|
2016-07-14 00:34:45 +07:00
|
|
|
drm_fb_helper_hotplug_event(&ifbdev->helper);
|
2010-05-07 13:42:51 +07:00
|
|
|
}
|
2011-04-22 04:18:32 +07:00
|
|
|
|
2013-10-08 22:44:49 +07:00
|
|
|
void intel_fbdev_restore_mode(struct drm_device *dev)
|
2011-04-22 04:18:32 +07:00
|
|
|
{
|
2016-07-14 00:34:45 +07:00
|
|
|
struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
|
2011-04-22 04:18:32 +07:00
|
|
|
|
2015-07-09 06:25:21 +07:00
|
|
|
if (!ifbdev)
|
2013-04-06 03:12:39 +07:00
|
|
|
return;
|
|
|
|
|
2016-06-21 15:16:55 +07:00
|
|
|
intel_fbdev_sync(ifbdev);
|
2017-06-22 23:02:11 +07:00
|
|
|
if (!ifbdev->vma)
|
2016-07-14 00:34:45 +07:00
|
|
|
return;
|
2016-06-21 15:16:55 +07:00
|
|
|
|
2017-02-15 17:59:19 +07:00
|
|
|
if (drm_fb_helper_restore_fbdev_mode_unlocked(&ifbdev->helper) == 0)
|
|
|
|
intel_fbdev_invalidate(ifbdev);
|
2011-04-22 04:18:32 +07:00
|
|
|
}
|