Re: [Intel-gfx] [PATCH 13/15] drm/i915: HDMI detection based on HPD pin live status
On 6 August 2014 00:51, Rodrigo Vivi rodrigo.v...@intel.com wrote: From: Ramalingam C ramalinga...@intel.com This change uses the HPD pins live status bit from South Display Engine(SDE) to identify the HDMI hotplug state. ibx_digital_port_connected? I think a lot of this patch exists already. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Specify bsd rings through exec flag
On Wed, Aug 6, 2014 at 3:32 AM, Zhao, Yakui yakui.z...@intel.com wrote: After the GPU hang occurs on BSD ring during decoding, it needs to specify the corresponding BSD ring to read the decoding status registers related with the BSD ring. Can this be regarded as one open-source usage scenario? Sure, but I'm not sure whether this is the correct way to do this - if some other libva client does an execbuf in-between couldn't these register get overwritten? It sounds like the kernel should capture these registers for userspace in a race-free way and then provide them with maybe an extension to the reset-stats ioctl? I definitely want to see how this is used in libva before signing up for a new kernel interface. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix DEIER and GTIER collecting for BDW.
On Tue, Aug 05, 2014 at 10:07:13AM -0700, Rodrigo Vivi wrote:
BDW has many other Display Engine interrupts and GT interrupts registers.
Collecting it properly on gpu_error_state.
On debugfs all was properly listed already but besides we were also listing
old
DEIER and GTIER that doesn't exist on BDW anymore. This was causing
unclaimed register messages:
https://bugs.freedesktop.org/show_bug.cgi?id=81701
v2: Fix small issues of first version and don't read DEIER regs when pipe's
power well is disabled
v3: bikeshed accepted: use enum pipe pipe instead of int i for pipe
interection
v4: Ben notice previous version was checking for display_power_enabled without
using propper locks. Using _unlocked version isn't reliable and we cannot
get this registers when power well is off. So let's avoid getting all
DE_IER
per pipe for now. If someone think this is an useful information it can be
added later.
v5: Ben: put back debugfs stuff that might be coverred by pm_get and use
gen = 8 trying to predict future.
Cc: Ben Widawsky b...@bwidawsk.net
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Reviewed-by: (v3) Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 19 ++-
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7c25345..73d2308 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -322,7 +322,7 @@ struct drm_i915_error_state {
u32 eir;
u32 pgtbl_er;
u32 ier;
- u32 gtier;
+ u32 gtier[4];
u32 ccid;
u32 derrmr;
u32 forcewake;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 7c478e6..eab41f9 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -361,8 +361,12 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
err_printf(m, PCI ID: 0x%04x\n, dev-pdev-device);
err_printf(m, EIR: 0x%08x\n, error-eir);
err_printf(m, IER: 0x%08x\n, error-ier);
- if (HAS_PCH_SPLIT(dev) || IS_VALLEYVIEW(dev))
- err_printf(m, GTIER: 0x%08x\n, error-gtier);
+ if (INTEL_INFO(dev)-gen = 8) {
+ for (i = 0; i 4; i++)
+ err_printf(m, GTIER gt %d: 0x%08x\n, i,
+error-gtier[i]);
+ } else if (HAS_PCH_SPLIT(dev) || IS_VALLEYVIEW(dev))
+ err_printf(m, GTIER: 0x%08x\n, error-gtier[0]);
err_printf(m, PGTBL_ER: 0x%08x\n, error-pgtbl_er);
err_printf(m, FORCEWAKE: 0x%08x\n, error-forcewake);
err_printf(m, DERRMR: 0x%08x\n, error-derrmr);
@@ -1096,6 +1100,7 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
struct drm_i915_error_state *error)
{
struct drm_device *dev = dev_priv-dev;
+ int i;
/* General organization
* 1. Registers specific to a single generation
@@ -1107,7 +1112,7 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
/* 1: Registers specific to a single generation */
if (IS_VALLEYVIEW(dev)) {
- error-gtier = I915_READ(GTIER);
+ error-gtier[0] = I915_READ(GTIER);
error-ier = I915_READ(VLV_IER);
error-forcewake = I915_READ(FORCEWAKE_VLV);
}
@@ -1141,9 +1146,13 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (HAS_HW_CONTEXTS(dev))
error-ccid = I915_READ(CCID);
- if (HAS_PCH_SPLIT(dev)) {
+ if (INTEL_INFO(dev)-gen = 8) {
+ error-ier = I915_READ(GEN8_DE_MISC_IER);
+ for (i = 0; i 4; i++)
+ error-gtier[i] = I915_READ(GEN8_GT_IER(i));
+ } else if (HAS_PCH_SPLIT(dev)) {
error-ier = I915_READ(DEIER);
- error-gtier = I915_READ(GTIER);
+ error-gtier[0] = I915_READ(GTIER);
} else if (IS_GEN2(dev)) {
error-ier = I915_READ16(IER);
} else if (!IS_VALLEYVIEW(dev)) {
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm: Resetting rotation property
On Wed, Aug 06, 2014 at 09:55:27AM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal sonika.jin...@intel.com
Reset rotation property to 0.
v2: Resetting after disabling the plane
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Still missing a cc: dri-devel here. And please don't resend the entire
series again, just this patch to dri-devel. The patches are merged
already, but we must follow proper procedures for getting core drm patches
in.
Thanks, Daniel
---
drivers/gpu/drm/drm_fb_helper.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3144db9..d139edd 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -345,10 +345,17 @@ static bool restore_fbdev_mode(struct drm_fb_helper
*fb_helper)
drm_warn_on_modeset_not_all_locked(dev);
- list_for_each_entry(plane, dev-mode_config.plane_list, head)
+ list_for_each_entry(plane, dev-mode_config.plane_list, head) {
if (plane-type != DRM_PLANE_TYPE_PRIMARY)
drm_plane_force_disable(plane);
+ if (dev-mode_config.rotation_property) {
+ drm_object_property_set_value(plane-base,
+ dev-mode_config.rotation_property,
+ BIT(DRM_ROTATE_0));
+ }
+ }
+
for (i = 0; i fb_helper-crtc_count; i++) {
struct drm_mode_set *mode_set =
fb_helper-crtc_info[i].mode_set;
struct drm_crtc *crtc = mode_set-crtc;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/15] drm/i915: Upgrade execbuffer fail after resume failure to EIO
On Tue, Aug 05, 2014 at 07:51:14AM -0700, Rodrigo Vivi wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
If we try to execute on a known ring, but it has failed to be
initialised correctly, report that the GPU is hung rather than the
command invalid. This leaves us reporting EINVAL only if the user
requests execution on a ring that is not supported by the device.
This should prevent UXA from getting stuck in a null render loop after a
failed resume.
v2 (Rodrigo): Fix conflict and add VCS2 ring and
s/intel_ring_buffer/intel_engine_cs.
Reported-by: Jiri Kosina ji...@jikos.cz
References: https://bugs.freedesktop.org/show_bug.cgi?id=76554
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
This isn't required any more, see
commit 074c6adaf4e7d1423d373bd5d1afc20b683cb4d0
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Wed Apr 9 09:19:43 2014 +0100
drm/i915: Mark device as wedged if we fail to resume
for the alternate merged patch.
-Daniel
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 60998fc..288ff61 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1233,6 +1233,19 @@ eb_get_batch(struct eb_vmas *eb)
return vma-obj;
}
+static bool
+intel_ring_valid(struct intel_engine_cs *ring)
+{
+ switch (ring-id) {
+ case RCS: return true;
+ case VCS: return HAS_BSD(ring-dev);
+ case BCS: return HAS_BLT(ring-dev);
+ case VECS: return HAS_VEBOX(ring-dev);
+ case VCS2: return HAS_BSD2(ring-dev);
+ default: return false;
+ }
+}
+
static int
i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file,
@@ -1289,7 +1302,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
if (!intel_ring_initialized(ring)) {
DRM_DEBUG(execbuf with invalid ring: %d\n,
(int)(args-flags I915_EXEC_RING_MASK));
- return -EINVAL;
+ return intel_ring_valid(ring) ? -EIO : -EINVAL;
}
if (args-buffer_count 1) {
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/15] drm/i915: Don't promote UC to WT automagically
On Tue, Aug 05, 2014 at 07:51:16AM -0700, Rodrigo Vivi wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
If the object is already UC leave it as UC instead of automagically
promoting it to WT in i915_gem_object_pin_to_display_plane() when
the hardware is WT capable.
Supposedly the user wanted UC for a reason, so let's respect that.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
We don't have a use case for this, so can be dropped.
-Daniel
---
drivers/gpu/drm/i915/i915_gem.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dcd8d7b..5710571 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3840,6 +3840,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
struct intel_engine_cs *pipelined)
{
u32 old_read_domains, old_write_domain;
+ unsigned int cache_level;
bool was_pin_display;
int ret;
@@ -3864,8 +3865,12 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
* of uncaching, which would allow us to flush all the LLC-cached data
* with that bit in the PTE to main memory with just one PIPE_CONTROL.
*/
- ret = i915_gem_object_set_cache_level(obj,
- HAS_WT(obj-base.dev) ?
I915_CACHE_WT : I915_CACHE_NONE);
+ if (HAS_WT(obj-base.dev) obj-cache_level != I915_CACHE_NONE)
+ cache_level = I915_CACHE_WT;
+ else
+ cache_level = I915_CACHE_NONE;
+
+ ret = i915_gem_object_set_cache_level(obj, cache_level);
if (ret)
goto err_unpin_display;
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm: Resetting rotation property
From: Sonika Jindal sonika.jin...@intel.com
Reset rotation property to 0.
v2: Resetting after disabling the plane
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_fb_helper.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3144db9..d139edd 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -345,10 +345,17 @@ static bool restore_fbdev_mode(struct drm_fb_helper
*fb_helper)
drm_warn_on_modeset_not_all_locked(dev);
- list_for_each_entry(plane, dev-mode_config.plane_list, head)
+ list_for_each_entry(plane, dev-mode_config.plane_list, head) {
if (plane-type != DRM_PLANE_TYPE_PRIMARY)
drm_plane_force_disable(plane);
+ if (dev-mode_config.rotation_property) {
+ drm_object_property_set_value(plane-base,
+ dev-mode_config.rotation_property,
+ BIT(DRM_ROTATE_0));
+ }
+ }
+
for (i = 0; i fb_helper-crtc_count; i++) {
struct drm_mode_set *mode_set =
fb_helper-crtc_info[i].mode_set;
struct drm_crtc *crtc = mode_set-crtc;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Perform cmdline mode parsing during connector initialisation
From: Chris Wilson ch...@chris-wilson.co.uk
i915.ko has a custom fbdev initialisation routine that aims to preserve
the current mode set by the BIOS, unless overruled by the user. The
user's wishes are determined by what, if any, mode is specified on the
command line (via the video= parameter). However, that command line mode
is first parsed by drm_fb_helper_initial_config() which is called after
i915.ko's custom initial_config() as a fallback method. So in order for
us to honour it, we need to move the cmdline parser earlier. If we
perform the connector cmdline parsing as soon as we initialise the
connector, that cmdline mode and forced status is then available even if
the fbdev helper is not compiled in or never called.
We also then expose the cmdline user mode in the connector mode lists.
v2: Rebase after connector-name upheaval.
v3: Adapt mga200 to look for the cmdline mode in the new place. Nicely
simplifies things while at that.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk (v2)
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org (v2)
Cc: dri-de...@lists.freedesktop.org
Cc: Julia Lemire jlem...@matrox.com
Cc: Dave Airlie airl...@redhat.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 55 +
drivers/gpu/drm/drm_fb_helper.c| 64 ++
drivers/gpu/drm/drm_modes.c| 1 +
drivers/gpu/drm/drm_probe_helper.c | 17 +
drivers/gpu/drm/mgag200/mgag200_mode.c | 20 +++
include/drm/drm_crtc.h | 1 +
include/drm/drm_fb_helper.h| 1 -
7 files changed, 82 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3c4a62169f28..d3f1e0033475 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -852,6 +852,59 @@ static void drm_mode_remove(struct drm_connector
*connector,
}
/**
+ * drm_connector_get_cmdline_mode - reads the user's cmdline mode
+ * @connector: connector to quwery
+ * @mode: returned mode
+ *
+ * The kernel supports per-connector configration of its consoles through
+ * use of the video= parameter. This function parses that option and
+ * extracts the user's specified mode (or enable/disable status) for a
+ * particular connector. This is typically only used during the early fbdev
+ * setup.
+ */
+static void drm_connector_get_cmdline_mode(struct drm_connector *connector)
+{
+ struct drm_cmdline_mode *mode = connector-cmdline_mode;
+ char *option = NULL;
+
+ if (fb_get_options(connector-name, option))
+ return;
+
+ if (!drm_mode_parse_command_line_for_connector(option,
+ connector,
+ mode))
+ return;
+
+ if (mode-force) {
+ const char *s;
+
+ switch (mode-force) {
+ case DRM_FORCE_OFF:
+ s = OFF;
+ break;
+ case DRM_FORCE_ON_DIGITAL:
+ s = ON - dig;
+ break;
+ default:
+ case DRM_FORCE_ON:
+ s = ON;
+ break;
+ }
+
+ DRM_INFO(forcing %s connector %s\n, connector-name, s);
+ connector-force = mode-force;
+ }
+
+ DRM_DEBUG_KMS(cmdline mode for connector %s %dx%d@%dHz%s%s%s\n,
+ connector-name,
+ mode-xres, mode-yres,
+ mode-refresh_specified ? mode-refresh : 60,
+ mode-rb ? reduced blanking : ,
+ mode-margins ? with margins : ,
+ mode-interlace ? interlaced : );
+}
+
+/**
* drm_connector_init - Init a preallocated connector
* @dev: DRM device
* @connector: the connector to init
@@ -903,6 +956,8 @@ int drm_connector_init(struct drm_device *dev,
connector-edid_blob_ptr = NULL;
connector-status = connector_status_unknown;
+ drm_connector_get_cmdline_mode(connector);
+
list_add_tail(connector-head, dev-mode_config.connector_list);
dev-mode_config.num_connector++;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d139eddb3d61..9a91ee69af2b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -171,60 +171,6 @@ int drm_fb_helper_remove_one_connector(struct
drm_fb_helper *fb_helper,
}
EXPORT_SYMBOL(drm_fb_helper_remove_one_connector);
-static int drm_fb_helper_parse_command_line(struct drm_fb_helper *fb_helper)
-{
- struct drm_fb_helper_connector *fb_helper_conn;
- int i;
-
- for
Re: [Intel-gfx] [PATCH 03/15] drm/i915: Upgrade execbuffer fail after resume failure to EIO
On Wed, Aug 06, 2014 at 09:56:45AM +0200, Daniel Vetter wrote: On Tue, Aug 05, 2014 at 07:51:14AM -0700, Rodrigo Vivi wrote: From: Chris Wilson ch...@chris-wilson.co.uk If we try to execute on a known ring, but it has failed to be initialised correctly, report that the GPU is hung rather than the command invalid. This leaves us reporting EINVAL only if the user requests execution on a ring that is not supported by the device. This should prevent UXA from getting stuck in a null render loop after a failed resume. v2 (Rodrigo): Fix conflict and add VCS2 ring and s/intel_ring_buffer/intel_engine_cs. Reported-by: Jiri Kosina ji...@jikos.cz References: https://bugs.freedesktop.org/show_bug.cgi?id=76554 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com This isn't required any more, see commit 074c6adaf4e7d1423d373bd5d1afc20b683cb4d0 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Wed Apr 9 09:19:43 2014 +0100 drm/i915: Mark device as wedged if we fail to resume for the alternate merged patch. Hmm, there is still a path that ends here, but the example above is already fixed as you say. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/15] drm/i915: honour forced connector modes
On Tue, Aug 05, 2014 at 07:51:15AM -0700, Rodrigo Vivi wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
In the move over to use BIOS connector configs, we lost the ability to
force a specific set of connectors on or off. Try to remedy that by
dropping back to the old behavior if we detect a hard coded connector
config that tries to enable a connector (disabling is easy!).
Based on earlier patches by Jesse Barnes.
v2: Remove Jesse's patch
Reported-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
Queued for -next, thanks for the patch. I've also pulled in the drm
cmdline mode parsing rework. Is that all that's been straggling wrt our
own initial config juggling?
-Daniel
---
drivers/gpu/drm/i915/intel_fbdev.c | 33 -
1 file changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index f475414..5d879d18 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -331,24 +331,6 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
int num_connectors_enabled = 0;
int num_connectors_detected = 0;
- /*
- * If the user specified any force options, just bail here
- * and use that config.
- */
- for (i = 0; i fb_helper-connector_count; i++) {
- struct drm_fb_helper_connector *fb_conn;
- struct drm_connector *connector;
-
- fb_conn = fb_helper-connector_info[i];
- connector = fb_conn-connector;
-
- if (!enabled[i])
- continue;
-
- if (connector-force != DRM_FORCE_UNSPECIFIED)
- return false;
- }
-
save_enabled = kcalloc(dev-mode_config.num_connector, sizeof(bool),
GFP_KERNEL);
if (!save_enabled)
@@ -374,8 +356,18 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
continue;
}
+ if (connector-force == DRM_FORCE_OFF) {
+ DRM_DEBUG_KMS(connector %s is disabled by user,
skipping\n,
+ connector-name);
+ enabled[i] = false;
+ continue;
+ }
+
encoder = connector-encoder;
if (!encoder || WARN_ON(!encoder-crtc)) {
+ if (connector-force DRM_FORCE_OFF)
+ goto bail;
+
DRM_DEBUG_KMS(connector %s has no encoder or crtc,
skipping\n,
connector-name);
enabled[i] = false;
@@ -394,8 +386,7 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
for (j = 0; j fb_helper-connector_count; j++) {
if (crtcs[j] == new_crtc) {
DRM_DEBUG_KMS(fallback: cloned
configuration\n);
- fallback = true;
- goto out;
+ goto bail;
}
}
@@ -466,8 +457,8 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
fallback = true;
}
-out:
if (fallback) {
+bail:
DRM_DEBUG_KMS(Not using firmware configuration\n);
memcpy(enabled, save_enabled, dev-mode_config.num_connector);
kfree(save_enabled);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/15] drm/i915: Refactor the physical and virtual page hws setup
On Tue, Aug 05, 2014 at 07:51:17AM -0700, Rodrigo Vivi wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
We duplicated the legacy physical HWS setup routine for no good reason.
Combine it with the more recent virtual HWS setup for simplicity.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
The duplication is with the legacy ums code, which (hopefully) will
disappear shortly. So no need for this patch.
-Daniel
---
drivers/gpu/drm/i915/i915_dma.c | 16 +--
drivers/gpu/drm/i915/intel_ringbuffer.c | 81
-
2 files changed, 39 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 2e7f03a..f76d2bf 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -104,17 +104,6 @@ void i915_update_dri1_breadcrumb(struct drm_device *dev)
}
}
-static void i915_write_hws_pga(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
- u32 addr;
-
- addr = dev_priv-status_page_dmah-busaddr;
- if (INTEL_INFO(dev)-gen = 4)
- addr |= (dev_priv-status_page_dmah-busaddr 28) 0xf0;
- I915_WRITE(HWS_PGA, addr);
-}
-
/**
* Frees the hardware status page, whether it's a physical address or a
virtual
* address set up by the X Server.
@@ -255,10 +244,7 @@ static int i915_dma_resume(struct drm_device *dev)
}
DRM_DEBUG_DRIVER(hw status page @ %p\n,
ring-status_page.page_addr);
- if (ring-status_page.gfx_addr != 0)
- intel_ring_setup_status_page(ring);
- else
- i915_write_hws_pga(dev);
+ intel_ring_setup_status_page(ring);
DRM_DEBUG_DRIVER(Enabled hardware status page\n);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index b3d8f76..b7894d1 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -443,17 +443,6 @@ u64 intel_ring_get_active_head(struct intel_engine_cs
*ring)
return acthd;
}
-static void ring_setup_phys_status_page(struct intel_engine_cs *ring)
-{
- struct drm_i915_private *dev_priv = ring-dev-dev_private;
- u32 addr;
-
- addr = dev_priv-status_page_dmah-busaddr;
- if (INTEL_INFO(ring-dev)-gen = 4)
- addr |= (dev_priv-status_page_dmah-busaddr 28) 0xf0;
- I915_WRITE(HWS_PGA, addr);
-}
-
static bool stop_ring(struct intel_engine_cs *ring)
{
struct drm_i915_private *dev_priv = to_i915(ring-dev);
@@ -511,10 +500,7 @@ static int init_ring_common(struct intel_engine_cs *ring)
}
}
- if (I915_NEED_GFX_HWS(dev))
- intel_ring_setup_status_page(ring);
- else
- ring_setup_phys_status_page(ring);
+ intel_ring_setup_status_page(ring);
/* Initialize the ring. This must happen _after_ we've cleared the ring
* registers with the above sequence (the readback of the HEAD registers
@@ -1101,39 +1087,48 @@ void intel_ring_setup_status_page(struct
intel_engine_cs *ring)
{
struct drm_device *dev = ring-dev;
struct drm_i915_private *dev_priv = ring-dev-dev_private;
- u32 mmio = 0;
+ u32 mmio, addr;
- /* The ring status page addresses are no longer next to the rest of
- * the ring registers as of gen7.
- */
- if (IS_GEN7(dev)) {
- switch (ring-id) {
- case RCS:
- mmio = RENDER_HWS_PGA_GEN7;
- break;
- case BCS:
- mmio = BLT_HWS_PGA_GEN7;
- break;
- /*
- * VCS2 actually doesn't exist on Gen7. Only shut up
- * gcc switch check warning
+ if (!I915_NEED_GFX_HWS(dev)) {
+ addr = dev_priv-status_page_dmah-busaddr;
+ if (INTEL_INFO(ring-dev)-gen = 4)
+ addr |= (dev_priv-status_page_dmah-busaddr 28)
0xf0;
+ mmio = HWS_PGA;
+ } else {
+ addr = ring-status_page.gfx_addr;
+ /* The ring status page addresses are no longer next to the
rest of
+ * the ring registers as of gen7.
*/
- case VCS2:
- case VCS:
- mmio = BSD_HWS_PGA_GEN7;
- break;
- case VECS:
- mmio = VEBOX_HWS_PGA_GEN7;
- break;
+ if (IS_GEN7(dev)) {
+ switch (ring-id) {
+ default:
+ case RCS:
+ mmio = RENDER_HWS_PGA_GEN7;
+ break;
+ case BCS:
+ mmio = BLT_HWS_PGA_GEN7;
+ break;
Re: [Intel-gfx] [PATCH] drm/i915: Initialize the aliasing ppgtt as part of global gtt
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
Sent: Monday, August 04, 2014 3:19 PM
To: Intel Graphics Development
Cc: Daniel Vetter; Thierry, Michel; Ville Syrjälä
Subject: [PATCH] drm/i915: Initialize the aliasing ppgtt as part of global gtt
Stuffing this into the context setup code doesn't make a lot of sense.
Also reusing the real ppgtt setup code makes even less sense since the
aliasing ppgtt isn't a real address space. Leaving all that stuff
unitialized will make sure that we catch any abusers promptly.
This is also a prep work to clean up the context-ppgtt link.
v2: Fix up the logic fail, I've fumbled it so badly to completely
disable ppgtt on gen6. Spotted by Ville and Michel. Also move around
the pde write into the gen6 init function, since otherwise it won't
work at all.
Cc: Thierry, Michel michel.thie...@intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_context.c | 13 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 42 +++-
-
2 files changed, 31 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3b8367aa8404..7a455fcee3a7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -276,17 +276,6 @@ i915_gem_create_context(struct drm_device *dev,
goto err_unpin;
} else
ctx-vm = ppgtt-base;
-
- /* This case is reserved for the global default context and
- * should only happen once. */
- if (is_global_default_ctx) {
- if (WARN_ON(dev_priv-mm.aliasing_ppgtt)) {
- ret = -EEXIST;
- goto err_unpin;
- }
-
- dev_priv-mm.aliasing_ppgtt = ppgtt;
- }
I expect some problems with full ppgtt this (in some places, the driver is
still making some decisions based on dev_priv-mm.aliasing_ppgtt, which now
will be null).
Should I address these problems in a subsequent patch?
} else if (USES_PPGTT(dev)) {
/* For platforms which only have aliasing PPGTT, we fake the
* address space and refcounting. */
@@ -361,7 +350,7 @@ int i915_gem_context_init(struct drm_device *dev)
}
}
- ctx = i915_gem_create_context(dev, NULL, USES_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, NULL,
USES_FULL_PPGTT(dev));
if (IS_ERR(ctx)) {
DRM_ERROR(Failed to create default global context (error
%ld)\n,
PTR_ERR(ctx));
}
--
1.9.3
smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/15] drm/i915: clean up PPGTT checking logic
On Tue, Aug 05, 2014 at 07:51:18AM -0700, Rodrigo Vivi wrote:
From: Jesse Barnes jbar...@virtuousgeek.org
sanitize_enable_ppgtt is the function that checks all the conditions,
honoring a forced ppgtt status or doing auto-detect as necessary. Just
make sure it returns the right value in all cases and use that in the
macros instead of the confusing intel_enable_ppgtt() function.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 -
3 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5de27f9..67e9da0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2048,8 +2048,8 @@ struct drm_i915_cmd_table {
#define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)-gen = 6)
#define HAS_ALIASING_PPGTT(dev) (INTEL_INFO(dev)-gen = 6)
#define HAS_PPGTT(dev) (INTEL_INFO(dev)-gen = 7
!IS_GEN8(dev))
-#define USES_PPGTT(dev) intel_enable_ppgtt(dev, false)
-#define USES_FULL_PPGTT(dev) intel_enable_ppgtt(dev, true)
+#define USES_PPGTT(dev) (i915.enable_ppgtt)
+#define USES_FULL_PPGTT(dev) (i915.enable_ppgtt == 2)
#define HAS_OVERLAY(dev) (INTEL_INFO(dev)-has_overlay)
#define OVERLAY_NEEDS_PHYSICAL(dev)
(INTEL_INFO(dev)-overlay_needs_physical)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5188936..ffa4bb3 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -33,17 +33,6 @@
static void bdw_setup_private_ppat(struct drm_i915_private *dev_priv);
static void chv_setup_private_ppat(struct drm_i915_private *dev_priv);
-bool intel_enable_ppgtt(struct drm_device *dev, bool full)
-{
- if (i915.enable_ppgtt == 0)
- return false;
-
- if (i915.enable_ppgtt == 1 full)
- return false;
-
- return true;
-}
-
static int sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt)
{
if (enable_ppgtt == 0 || !HAS_ALIASING_PPGTT(dev))
@@ -70,6 +59,9 @@ static int sanitize_enable_ppgtt(struct drm_device *dev,
int enable_ppgtt)
return 0;
}
+ if (HAS_PPGTT(dev))
+ return 2;
This reeneables ppgtt throught the backdoor. Dropped this hunk and merged
the patch.
-Daniel
+
return HAS_ALIASING_PPGTT(dev) ? 1 : 0;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 8d6f7c1..666c938 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -272,7 +272,6 @@ void i915_gem_init_global_gtt(struct drm_device *dev);
void i915_gem_setup_global_gtt(struct drm_device *dev, unsigned long start,
unsigned long mappable_end, unsigned long end);
-bool intel_enable_ppgtt(struct drm_device *dev, bool full);
int i915_gem_init_ppgtt(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt);
void i915_check_and_clear_faults(struct drm_device *dev);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/15] drm/i915: re-order ppgtt sanitize logic v2
On Tue, Aug 05, 2014 at 07:51:19AM -0700, Rodrigo Vivi wrote:
From: Jesse Barnes jbar...@virtuousgeek.org
Put hw limitations first, disabling ppgtt if necessary right away.
After that, check user passed args or auto-detect and do the right
thing, falling back to aliasing PPGTT if the user tries to enable full
PPGTT but it isn't available.
v2: simplify auto-detect case since we already caught the no PPGTT case early
on (Jesse)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ffa4bb3..264f2a6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -35,15 +35,6 @@ static void chv_setup_private_ppat(struct drm_i915_private
*dev_priv);
static int sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt)
{
- if (enable_ppgtt == 0 || !HAS_ALIASING_PPGTT(dev))
- return 0;
-
- if (enable_ppgtt == 1)
- return 1;
-
- if (enable_ppgtt == 2 HAS_PPGTT(dev))
- return 2;
-
#ifdef CONFIG_INTEL_IOMMU
/* Disable ppgtt on SNB if VT-d is on. */
if (INTEL_INFO(dev)-gen == 6 intel_iommu_gfx_mapped) {
@@ -59,10 +50,20 @@ static int sanitize_enable_ppgtt(struct drm_device *dev,
int enable_ppgtt)
return 0;
}
- if (HAS_PPGTT(dev))
- return 2;
+ if (!HAS_ALIASING_PPGTT(dev))
+ return 0;
- return HAS_ALIASING_PPGTT(dev) ? 1 : 0;
+ /* Check user passed enable_ppgtt param and try to honor it */
+ switch (enable_ppgtt) {
+ case 0:
+ return 0;
+ case 1:
+ return 1; /* caught any hw limits above */
+ case 2:
+ /* fall through to auto-detect */
+ default: /* auto-detect */
+ return HAS_PPGTT(dev) ? 2 : 1;
Same issue, so not going to merge for now. Until that's address I guess we
can drop this.
-Daniel
+ }
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/15] drm/i915: Bring GPU Freq to min while suspending.
On Tue, Aug 05, 2014 at 07:51:20AM -0700, Rodrigo Vivi wrote: From: Deepak S deepa...@linux.intel.com We might be leaving the PGU Frequency (and thus vnn) high during the suspend. Flusing the delayed work queue should take care of this. Signed-off-by: Deepak S deepa...@linux.intel.com Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com Queued for -next, thanks for the patch. -Daniel --- drivers/gpu/drm/i915/i915_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 5710571..ddfa279 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4559,7 +4559,7 @@ i915_gem_suspend(struct drm_device *dev) del_timer_sync(dev_priv-gpu_error.hangcheck_timer); cancel_delayed_work_sync(dev_priv-mm.retire_work); - cancel_delayed_work_sync(dev_priv-mm.idle_work); + flush_delayed_work(dev_priv-mm.idle_work); return 0; -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/15] drm/i915: State readout and cross-checking for dp_m2_n2
On Tue, Aug 05, 2014 at 07:51:23AM -0700, Rodrigo Vivi wrote:
From: Vandana Kannan vandana.kan...@intel.com
Adding relevant read out comparison code, in check_crtc_state, for the new
member of crtc_config, dp_m2_n2, which was introduced to store link_m_n
values for a DP downclock mode (if available). Suggested by Daniel.
v2: Changed patch title.
Daniel's review comments incorporated.
Added relevant state readout code for M2_N2. dp_m2_n2 comparison to be done
only when high RR is not in use (This is because alternate m_n register
programming will be done only when low RR is being used).
v3: Modified call to get_m2_n2 which had dp_m_n as param by mistake.
Compare dp_m_n and dp_m2_n2 for gen 7 and below. compare the structures
based on DRRS state for gen 8 and above.
Save and restore M2 N2 registers for gen 7 and below
v4: For Gen=8, check M_N registers against dp_m_n and dp_m2_n2 as there is
only one set of M_N registers
v5: Removed the chunk which saves and restores M2_N2 registers. Modified
get_m_n() to get M2_N2 registers as well. Modified the macro which compares
hw.dp_m_n against sw.dp_m2_n2/sw.dp_m_n for gen 8.
v6: Added check to compare dp_m2_n2 only when DRRS is enabled
v7: Modified drrs check to use has_drrs
v8: Add has_drrs check before reading M2_N2 registers
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Jani Nikula jani.nik...@linux.intel.com
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
Both drrs patches pulled in, thanks.
-Daniel
---
drivers/gpu/drm/i915/intel_display.c | 75
1 file changed, 67 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e798acd..b758826 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7145,7 +7145,8 @@ static void intel_pch_transcoder_get_m_n(struct
intel_crtc *crtc,
static void intel_cpu_transcoder_get_m_n(struct intel_crtc *crtc,
enum transcoder transcoder,
- struct intel_link_m_n *m_n)
+ struct intel_link_m_n *m_n,
+ struct intel_link_m_n *m2_n2)
{
struct drm_device *dev = crtc-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -7159,6 +7160,20 @@ static void intel_cpu_transcoder_get_m_n(struct
intel_crtc *crtc,
m_n-gmch_n = I915_READ(PIPE_DATA_N1(transcoder));
m_n-tu = ((I915_READ(PIPE_DATA_M1(transcoder))
TU_SIZE_MASK) TU_SIZE_SHIFT) + 1;
+ /* Read M2_N2 registers only for gen 8 (M2_N2 available for
+ * gen 8) and if DRRS is supported (to make sure the
+ * registers are not unnecessarily read).
+ */
+ if (m2_n2 INTEL_INFO(dev)-gen 8
+ crtc-config.has_drrs) {
+ m2_n2-link_m = I915_READ(PIPE_LINK_M2(transcoder));
+ m2_n2-link_n = I915_READ(PIPE_LINK_N2(transcoder));
+ m2_n2-gmch_m = I915_READ(PIPE_DATA_M2(transcoder))
+ ~TU_SIZE_MASK;
+ m2_n2-gmch_n = I915_READ(PIPE_DATA_N2(transcoder));
+ m2_n2-tu = ((I915_READ(PIPE_DATA_M2(transcoder))
+ TU_SIZE_MASK) TU_SIZE_SHIFT) + 1;
+ }
} else {
m_n-link_m = I915_READ(PIPE_LINK_M_G4X(pipe));
m_n-link_n = I915_READ(PIPE_LINK_N_G4X(pipe));
@@ -7177,14 +7192,15 @@ void intel_dp_get_m_n(struct intel_crtc *crtc,
intel_pch_transcoder_get_m_n(crtc, pipe_config-dp_m_n);
else
intel_cpu_transcoder_get_m_n(crtc, pipe_config-cpu_transcoder,
- pipe_config-dp_m_n);
+ pipe_config-dp_m_n,
+ pipe_config-dp_m2_n2);
}
static void ironlake_get_fdi_m_n_config(struct intel_crtc *crtc,
struct intel_crtc_config *pipe_config)
{
intel_cpu_transcoder_get_m_n(crtc, pipe_config-cpu_transcoder,
- pipe_config-fdi_m_n);
+ pipe_config-fdi_m_n, NULL);
}
static void ironlake_get_pfit_config(struct intel_crtc *crtc,
@@ -10001,6 +10017,15 @@ static void intel_dump_pipe_config(struct intel_crtc
*crtc,
pipe_config-dp_m_n.gmch_m, pipe_config-dp_m_n.gmch_n,
pipe_config-dp_m_n.link_m, pipe_config-dp_m_n.link_n,
pipe_config-dp_m_n.tu);
+
+ DRM_DEBUG_KMS(dp: %i, gmch_m2: %u, gmch_n2: %u, link_m2: %u, link_n2:
%u, tu2: %u\n,
Re: [Intel-gfx] [PATCH 14/15] drm/i915: capture_reg_state interrupt registers for Gen8
On Tue, Aug 05, 2014 at 07:51:25AM -0700, Rodrigo Vivi wrote:
From: Michel Thierry michel.thie...@intel.com
After unclaimed register detection was enabled for BDW, I started seeing
warnings while reading registers 0x4400c (DEIER) and 0x4401c (GTIER).
From Gen8, DEIER has been split per display engine pipe, and GTIER has
been split in 4.
Signed-off-by: Michel Thierry michel.thie...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
Isn't that now addressed by the other gt/deier patches from you?
-Daniel
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gpu_error.c | 19 ++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 67e9da0..6622a53 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -314,6 +314,8 @@ struct drm_i915_error_state {
u32 eir;
u32 pgtbl_er;
u32 ier;
+ u32 pipe_ier[I915_MAX_PIPES]; /* gen8 */
+ u32 gt_ier[4]; /* gen8 */
u32 ccid;
u32 derrmr;
u32 forcewake;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 0b3f694..e7a4ae0 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -380,6 +380,16 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
if (INTEL_INFO(dev)-gen == 7)
err_printf(m, ERR_INT: 0x%08x\n, error-err_int);
+ if (INTEL_INFO(dev)-gen == 8) {
+ for (i = 0; i ARRAY_SIZE(error-pipe_ier); i++)
+ err_printf(m, PIPE_IER_%d: 0x%08x\n, i,
+error-pipe_ier[i]);
+
+ for (i = 0; i ARRAY_SIZE(error-gt_ier); i++)
+ err_printf(m, GT_IER_%d: 0x%08x\n, i,
+error-gt_ier[i]);
+ }
+
for (i = 0; i ARRAY_SIZE(error-ring); i++) {
err_printf(m, %s command stream:\n, ring_str(i));
i915_ring_error_state(m, dev, error-ring[i]);
@@ -1091,6 +1101,7 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
struct drm_i915_error_state *error)
{
struct drm_device *dev = dev_priv-dev;
+ int i, pipe;
/* General organization
* 1. Registers specific to a single generation
@@ -1135,7 +1146,13 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (HAS_HW_CONTEXTS(dev))
error-ccid = I915_READ(CCID);
- if (HAS_PCH_SPLIT(dev))
+ if (IS_GEN8(dev)) {
+ for_each_pipe(pipe)
+ error-pipe_ier[pipe] =
+ I915_READ(GEN8_DE_PIPE_IER(pipe));
+ for (i = 0; i 4; i++)
+ error-gt_ier[i] = I915_READ(GEN8_GT_IER(i));
+ } else if (HAS_PCH_SPLIT(dev))
error-ier = I915_READ(DEIER) | I915_READ(GTIER);
else {
if (IS_GEN2(dev))
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Initialize the aliasing ppgtt as part of global gtt
On Wed, Aug 06, 2014 at 08:18:52AM +, Thierry, Michel wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
Sent: Monday, August 04, 2014 3:19 PM
To: Intel Graphics Development
Cc: Daniel Vetter; Thierry, Michel; Ville Syrjälä
Subject: [PATCH] drm/i915: Initialize the aliasing ppgtt as part of global
gtt
Stuffing this into the context setup code doesn't make a lot of sense.
Also reusing the real ppgtt setup code makes even less sense since the
aliasing ppgtt isn't a real address space. Leaving all that stuff
unitialized will make sure that we catch any abusers promptly.
This is also a prep work to clean up the context-ppgtt link.
v2: Fix up the logic fail, I've fumbled it so badly to completely
disable ppgtt on gen6. Spotted by Ville and Michel. Also move around
the pde write into the gen6 init function, since otherwise it won't
work at all.
Cc: Thierry, Michel michel.thie...@intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_context.c | 13 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 42 +++-
-
2 files changed, 31 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3b8367aa8404..7a455fcee3a7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -276,17 +276,6 @@ i915_gem_create_context(struct drm_device *dev,
goto err_unpin;
} else
ctx-vm = ppgtt-base;
-
- /* This case is reserved for the global default context and
-* should only happen once. */
- if (is_global_default_ctx) {
- if (WARN_ON(dev_priv-mm.aliasing_ppgtt)) {
- ret = -EEXIST;
- goto err_unpin;
- }
-
- dev_priv-mm.aliasing_ppgtt = ppgtt;
- }
I expect some problems with full ppgtt this (in some places, the
driver is still making some decisions based on
dev_priv-mm.aliasing_ppgtt, which now will be null). Should I address
these problems in a subsequent patch?
Oh, good catch. I've done a bit a review and found two cases:
- Driver unload code. Already fairly broken, made much worse by my series
here. I've fixed that up yesterday and will resend the series with those
additional patches and revised patches.
- cmd parser. I guess that should be a fixup patch on top. I'll also do
that.
Have you spotted any other places?
Thanks, Daniel
} else if (USES_PPGTT(dev)) {
/* For platforms which only have aliasing PPGTT, we fake the
* address space and refcounting. */
@@ -361,7 +350,7 @@ int i915_gem_context_init(struct drm_device *dev)
}
}
- ctx = i915_gem_create_context(dev, NULL, USES_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, NULL,
USES_FULL_PPGTT(dev));
if (IS_ERR(ctx)) {
DRM_ERROR(Failed to create default global context (error
%ld)\n,
PTR_ERR(ctx));
}
--
1.9.3
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Don't grab an fb reference for the idr
The current refcounting scheme is that the fb lookup idr also holds a
reference. This works out nicely bacause thus far we've always
explicitly cleaned up idr entries for framebuffers:
- Userspace fbs get removed in the rmfb ioctl or when the drm file
gets closed.
- Kernel fbs (for fbdev emulation) get cleaned up by the driver code
at module unload time.
But now i915 also reconstructs the bios fbs for a smooth transition.
And that fb is purely transitional and should get removed immmediately
once all crtcs stop using it. Of course if the i915 fbdev code decides
to reuse it as the main fbdev fb then it shouldn't be cleaned up, but
in that case the fbdev code will grab it's own reference.
The problem is now that we also want to register that takeover fb in
the idr, so that userspace can do a smooth transition (animated maybe
even!) itself. But currently we have no one who will clean up the idr
reference once that fb isn't useful any more, and so essentially leak
it.
Fix this by no longer holding a full fb reference for the idr, but
instead just have a weak reference using kref_get_unless_zero. But
that requires us to synchronize and clean up with the idr and fb_lock
in drm_framebuffer_free, so add that. It's a bit ugly that we have to
unconditionally grab the fb_lock, but without that someone might creep
through a race.
This leak was caught by the fb leak check in drm_mode_config_cleanup.
Originally the leak was introduced in
commit 46f297fb83d4f9a6f6891964beb184664341a28b
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Fri Mar 7 08:57:48 2014 -0800
drm/i915: add plane_config fetching infrastructure v2
Cc: Jesse Barnes jbar...@virtuousgeek.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77511
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 46 --
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fa2be24c..33ff631c8d23 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -515,9 +515,6 @@ int drm_framebuffer_init(struct drm_device *dev, struct
drm_framebuffer *fb,
if (ret)
goto out;
- /* Grab the idr reference. */
- drm_framebuffer_reference(fb);
-
dev-mode_config.num_fb++;
list_add(fb-head, dev-mode_config.fb_list);
out:
@@ -527,10 +524,34 @@ out:
}
EXPORT_SYMBOL(drm_framebuffer_init);
+/* dev-mode_config.fb_lock must be held! */
+static void __drm_framebuffer_unregister(struct drm_device *dev,
+struct drm_framebuffer *fb)
+{
+ mutex_lock(dev-mode_config.idr_mutex);
+ idr_remove(dev-mode_config.crtc_idr, fb-base.id);
+ mutex_unlock(dev-mode_config.idr_mutex);
+
+ fb-base.id = 0;
+}
+
static void drm_framebuffer_free(struct kref *kref)
{
struct drm_framebuffer *fb =
container_of(kref, struct drm_framebuffer, refcount);
+ struct drm_device *dev = fb-dev;
+
+ /*
+* The lookup idr holds a weak reference, which has not necessarily been
+* removed at this point. Check for that.
+*/
+ mutex_lock(dev-mode_config.fb_lock);
+ if (fb-base.id) {
+ /* Mark fb as reaped and drop idr ref. */
+ __drm_framebuffer_unregister(dev, fb);
+ }
+ mutex_unlock(dev-mode_config.fb_lock);
+
fb-funcs-destroy(fb);
}
@@ -567,8 +588,10 @@ struct drm_framebuffer *drm_framebuffer_lookup(struct
drm_device *dev,
mutex_lock(dev-mode_config.fb_lock);
fb = __drm_framebuffer_lookup(dev, id);
- if (fb)
- drm_framebuffer_reference(fb);
+ if (fb) {
+ if (!kref_get_unless_zero(fb-refcount))
+ fb = NULL;
+ }
mutex_unlock(dev-mode_config.fb_lock);
return fb;
@@ -612,19 +635,6 @@ static void __drm_framebuffer_unreference(struct
drm_framebuffer *fb)
kref_put(fb-refcount, drm_framebuffer_free_bug);
}
-/* dev-mode_config.fb_lock must be held! */
-static void __drm_framebuffer_unregister(struct drm_device *dev,
-struct drm_framebuffer *fb)
-{
- mutex_lock(dev-mode_config.idr_mutex);
- idr_remove(dev-mode_config.crtc_idr, fb-base.id);
- mutex_unlock(dev-mode_config.idr_mutex);
-
- fb-base.id = 0;
-
- __drm_framebuffer_unreference(fb);
-}
-
/**
* drm_framebuffer_unregister_private - unregister a private fb from the
lookup idr
* @fb: fb to unregister
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/15] drm/i915: Upgrade execbuffer fail after resume failure to EIO
On Wed, Aug 06, 2014 at 09:12:32AM +0100, Chris Wilson wrote: On Wed, Aug 06, 2014 at 09:56:45AM +0200, Daniel Vetter wrote: On Tue, Aug 05, 2014 at 07:51:14AM -0700, Rodrigo Vivi wrote: From: Chris Wilson ch...@chris-wilson.co.uk If we try to execute on a known ring, but it has failed to be initialised correctly, report that the GPU is hung rather than the command invalid. This leaves us reporting EINVAL only if the user requests execution on a ring that is not supported by the device. This should prevent UXA from getting stuck in a null render loop after a failed resume. v2 (Rodrigo): Fix conflict and add VCS2 ring and s/intel_ring_buffer/intel_engine_cs. Reported-by: Jiri Kosina ji...@jikos.cz References: https://bugs.freedesktop.org/show_bug.cgi?id=76554 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com This isn't required any more, see commit 074c6adaf4e7d1423d373bd5d1afc20b683cb4d0 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Wed Apr 9 09:19:43 2014 +0100 drm/i915: Mark device as wedged if we fail to resume for the alternate merged patch. Hmm, there is still a path that ends here, but the example above is already fixed as you say. We have the EIO check both in the resume and driver load paths. Which other path are we missing? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm: Resetting rotation property
On Wed, Aug 06, 2014 at 01:26:00PM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal sonika.jin...@intel.com
Reset rotation property to 0.
v2: Resetting after disabling the plane
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
I've pulled in these 2 simple drm core rotation patches into dinq with
Dave's ack for 3.18.
-Daniel
---
drivers/gpu/drm/drm_fb_helper.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3144db9..d139edd 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -345,10 +345,17 @@ static bool restore_fbdev_mode(struct drm_fb_helper
*fb_helper)
drm_warn_on_modeset_not_all_locked(dev);
- list_for_each_entry(plane, dev-mode_config.plane_list, head)
+ list_for_each_entry(plane, dev-mode_config.plane_list, head) {
if (plane-type != DRM_PLANE_TYPE_PRIMARY)
drm_plane_force_disable(plane);
+ if (dev-mode_config.rotation_property) {
+ drm_object_property_set_value(plane-base,
+ dev-mode_config.rotation_property,
+ BIT(DRM_ROTATE_0));
+ }
+ }
+
for (i = 0; i fb_helper-crtc_count; i++) {
struct drm_mode_set *mode_set =
fb_helper-crtc_info[i].mode_set;
struct drm_crtc *crtc = mode_set-crtc;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Initialize the aliasing ppgtt as part of global gtt
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, August 06, 2014 9:31 AM
To: Thierry, Michel
Cc: Daniel Vetter; Intel Graphics Development
Subject: Re: [PATCH] drm/i915: Initialize the aliasing ppgtt as part of
global gtt
On Wed, Aug 06, 2014 at 08:18:52AM +, Thierry, Michel wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
Sent: Monday, August 04, 2014 3:19 PM
To: Intel Graphics Development
Cc: Daniel Vetter; Thierry, Michel; Ville Syrjälä
Subject: [PATCH] drm/i915: Initialize the aliasing ppgtt as part of
global gtt
Stuffing this into the context setup code doesn't make a lot of sense.
Also reusing the real ppgtt setup code makes even less sense since the
aliasing ppgtt isn't a real address space. Leaving all that stuff
unitialized will make sure that we catch any abusers promptly.
This is also a prep work to clean up the context-ppgtt link.
v2: Fix up the logic fail, I've fumbled it so badly to completely
disable ppgtt on gen6. Spotted by Ville and Michel. Also move around
the pde write into the gen6 init function, since otherwise it won't
work at all.
Cc: Thierry, Michel michel.thie...@intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_context.c | 13 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 42
+++-
-
2 files changed, 31 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3b8367aa8404..7a455fcee3a7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -276,17 +276,6 @@ i915_gem_create_context(struct drm_device
*dev,
goto err_unpin;
} else
ctx-vm = ppgtt-base;
-
- /* This case is reserved for the global default context and
- * should only happen once. */
- if (is_global_default_ctx) {
- if (WARN_ON(dev_priv-mm.aliasing_ppgtt)) {
- ret = -EEXIST;
- goto err_unpin;
- }
-
- dev_priv-mm.aliasing_ppgtt = ppgtt;
- }
I expect some problems with full ppgtt this (in some places, the
driver is still making some decisions based on
dev_priv-mm.aliasing_ppgtt, which now will be null). Should I address
these problems in a subsequent patch?
Oh, good catch. I've done a bit a review and found two cases:
- Driver unload code. Already fairly broken, made much worse by my series
here. I've fixed that up yesterday and will resend the series with those
additional patches and revised patches.
- cmd parser. I guess that should be a fixup patch on top. I'll also do
that.
Have you spotted any other places?
The other place is gen8_ring_dispatch_execbuffer, it won't set the ppgtt
flag in MI_BATCH_BUFFER_START.
Thanks, Daniel
} else if (USES_PPGTT(dev)) {
/* For platforms which only have aliasing PPGTT, we fake the
* address space and refcounting. */
@@ -361,7 +350,7 @@ int i915_gem_context_init(struct drm_device
*dev)
}
}
- ctx = i915_gem_create_context(dev, NULL, USES_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, NULL,
USES_FULL_PPGTT(dev));
if (IS_ERR(ctx)) {
DRM_ERROR(Failed to create default global context (error
%ld)\n,
PTR_ERR(ctx));
}
--
1.9.3
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Initialize the aliasing ppgtt as part of global gtt
On Wed, Aug 06, 2014 at 08:44:34AM +, Thierry, Michel wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Wednesday, August 06, 2014 9:31 AM
To: Thierry, Michel
Cc: Daniel Vetter; Intel Graphics Development
Subject: Re: [PATCH] drm/i915: Initialize the aliasing ppgtt as part of
global gtt
On Wed, Aug 06, 2014 at 08:18:52AM +, Thierry, Michel wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
Sent: Monday, August 04, 2014 3:19 PM
To: Intel Graphics Development
Cc: Daniel Vetter; Thierry, Michel; Ville Syrjälä
Subject: [PATCH] drm/i915: Initialize the aliasing ppgtt as part of
global gtt
Stuffing this into the context setup code doesn't make a lot of sense.
Also reusing the real ppgtt setup code makes even less sense since the
aliasing ppgtt isn't a real address space. Leaving all that stuff
unitialized will make sure that we catch any abusers promptly.
This is also a prep work to clean up the context-ppgtt link.
v2: Fix up the logic fail, I've fumbled it so badly to completely
disable ppgtt on gen6. Spotted by Ville and Michel. Also move around
the pde write into the gen6 init function, since otherwise it won't
work at all.
Cc: Thierry, Michel michel.thie...@intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_context.c | 13 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 42
+++-
-
2 files changed, 31 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3b8367aa8404..7a455fcee3a7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -276,17 +276,6 @@ i915_gem_create_context(struct drm_device
*dev,
goto err_unpin;
} else
ctx-vm = ppgtt-base;
-
- /* This case is reserved for the global default context
and
-* should only happen once. */
- if (is_global_default_ctx) {
- if (WARN_ON(dev_priv-mm.aliasing_ppgtt)) {
- ret = -EEXIST;
- goto err_unpin;
- }
-
- dev_priv-mm.aliasing_ppgtt = ppgtt;
- }
I expect some problems with full ppgtt this (in some places, the
driver is still making some decisions based on
dev_priv-mm.aliasing_ppgtt, which now will be null). Should I address
these problems in a subsequent patch?
Oh, good catch. I've done a bit a review and found two cases:
- Driver unload code. Already fairly broken, made much worse by my series
here. I've fixed that up yesterday and will resend the series with those
additional patches and revised patches.
- cmd parser. I guess that should be a fixup patch on top. I'll also do
that.
Have you spotted any other places?
The other place is gen8_ring_dispatch_execbuffer, it won't set the ppgtt
flag in MI_BATCH_BUFFER_START.
Indeed. I've also found a few other really fishy places. Will follow up
with revised patches.
-Daniel
Thanks, Daniel
} else if (USES_PPGTT(dev)) {
/* For platforms which only have aliasing PPGTT, we
fake the
* address space and refcounting. */
@@ -361,7 +350,7 @@ int i915_gem_context_init(struct drm_device
*dev)
}
}
- ctx = i915_gem_create_context(dev, NULL, USES_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, NULL,
USES_FULL_PPGTT(dev));
if (IS_ERR(ctx)) {
DRM_ERROR(Failed to create default global context
(error
%ld)\n,
PTR_ERR(ctx));
}
--
1.9.3
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/i915: capture_reg_state interrupt registers for Gen8
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Daniel Vetter
Sent: Wednesday, August 06, 2014 9:28 AM
To: Vivi, Rodrigo
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 14/15] drm/i915: capture_reg_state
interrupt
registers for Gen8
On Tue, Aug 05, 2014 at 07:51:25AM -0700, Rodrigo Vivi wrote:
From: Michel Thierry michel.thie...@intel.com
After unclaimed register detection was enabled for BDW, I started seeing
warnings while reading registers 0x4400c (DEIER) and 0x4401c (GTIER).
From Gen8, DEIER has been split per display engine pipe, and GTIER has
been split in 4.
Signed-off-by: Michel Thierry michel.thie...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
Isn't that now addressed by the other gt/deier patches from you?
-Daniel
Yes, Rodrigo's patch (drm/i915: Fix DEIER and GTIER collecting for BDW)
addressed the same thing.
--Michel
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gpu_error.c | 19 ++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 67e9da0..6622a53 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -314,6 +314,8 @@ struct drm_i915_error_state {
u32 eir;
u32 pgtbl_er;
u32 ier;
+ u32 pipe_ier[I915_MAX_PIPES]; /* gen8 */
+ u32 gt_ier[4]; /* gen8 */
u32 ccid;
u32 derrmr;
u32 forcewake;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 0b3f694..e7a4ae0 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -380,6 +380,16 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
if (INTEL_INFO(dev)-gen == 7)
err_printf(m, ERR_INT: 0x%08x\n, error-err_int);
+ if (INTEL_INFO(dev)-gen == 8) {
+ for (i = 0; i ARRAY_SIZE(error-pipe_ier); i++)
+ err_printf(m, PIPE_IER_%d: 0x%08x\n, i,
+ error-pipe_ier[i]);
+
+ for (i = 0; i ARRAY_SIZE(error-gt_ier); i++)
+ err_printf(m, GT_IER_%d: 0x%08x\n, i,
+ error-gt_ier[i]);
+ }
+
for (i = 0; i ARRAY_SIZE(error-ring); i++) {
err_printf(m, %s command stream:\n, ring_str(i));
i915_ring_error_state(m, dev, error-ring[i]);
@@ -1091,6 +1101,7 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
struct drm_i915_error_state *error)
{
struct drm_device *dev = dev_priv-dev;
+ int i, pipe;
/* General organization
* 1. Registers specific to a single generation
@@ -1135,7 +1146,13 @@ static void i915_capture_reg_state(struct
drm_i915_private *dev_priv,
if (HAS_HW_CONTEXTS(dev))
error-ccid = I915_READ(CCID);
- if (HAS_PCH_SPLIT(dev))
+ if (IS_GEN8(dev)) {
+ for_each_pipe(pipe)
+ error-pipe_ier[pipe] =
+
I915_READ(GEN8_DE_PIPE_IER(pipe));
+ for (i = 0; i 4; i++)
+ error-gt_ier[i] = I915_READ(GEN8_GT_IER(i));
+ } else if (HAS_PCH_SPLIT(dev))
error-ier = I915_READ(DEIER) | I915_READ(GTIER);
else {
if (IS_GEN2(dev))
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 34/43] drm/i915/bdw: Make sure gpu reset still works with Execlists
-Original Message-
From: Lespiau, Damien
Sent: Friday, August 01, 2014 3:42 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 34/43] drm/i915/bdw: Make sure gpu reset
still works with Execlists
On Thu, Jul 24, 2014 at 05:04:42PM +0100, Thomas Daniel wrote:
From: Oscar Mateo oscar.ma...@intel.com
If we reset a ring after a hang, we have to make sure that we clear
out all queued Execlists requests.
v2: The ring is, at this point, already being correctly re-programmed
for Execlists, and the hangcheck counters cleared.
v3: Daniel suggests to drop the if (execlists) because the Execlists
queue should be empty in legacy mode (which is true, if we do the
INIT_LIST_HEAD).
v4: Do the pending intel_runtime_pm_put
I don't see a intel_runtime_pm_get() that put() would correspond to.
It is in execlists_context_queue() where the request is added to the queue.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 12
drivers/gpu/drm/i915/intel_ringbuffer.c |1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c index 1c83b9c..143cff7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2567,6 +2567,18 @@ static void i915_gem_reset_ring_cleanup(struct
drm_i915_private *dev_priv,
i915_gem_free_request(request);
}
+ while (!list_empty(ring-execlist_queue)) {
+ struct intel_ctx_submit_request *submit_req;
+
+ submit_req = list_first_entry(ring-execlist_queue,
+ struct intel_ctx_submit_request,
+ execlist_link);
+ list_del(submit_req-execlist_link);
+ intel_runtime_pm_put(dev_priv);
+ i915_gem_context_unreference(submit_req-ctx);
+ kfree(submit_req);
+ }
+
/* These may not have been flush before the reset, do so now */
kfree(ring-preallocated_lazy_request);
ring-preallocated_lazy_request = NULL; diff --git
a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 3188403..6e604c9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1587,6 +1587,7 @@ static int intel_init_ring_buffer(struct drm_device
*dev,
ring-dev = dev;
INIT_LIST_HEAD(ring-active_list);
INIT_LIST_HEAD(ring-request_list);
+ INIT_LIST_HEAD(ring-execlist_queue);
ringbuf-size = 32 * PAGE_SIZE;
ringbuf-ring = ring;
ringbuf-ctx = ring-default_context;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 34/43] drm/i915/bdw: Make sure gpu reset still works with Execlists
-Original Message- From: Lespiau, Damien Sent: Friday, August 01, 2014 3:46 PM To: Daniel, Thomas Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH 34/43] drm/i915/bdw: Make sure gpu reset still works with Execlists On Thu, Jul 24, 2014 at 05:04:42PM +0100, Thomas Daniel wrote: diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 3188403..6e604c9 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1587,6 +1587,7 @@ static int intel_init_ring_buffer(struct drm_device *dev, ring-dev = dev; INIT_LIST_HEAD(ring-active_list); INIT_LIST_HEAD(ring-request_list); + INIT_LIST_HEAD(ring-execlist_queue); It's also a bit weird to now have sites where we initialize this list. or I'm missing something? The legacy ringbuffer init path now also has to initialize the queue because I915_gem_reset_ring_cleanup() now assumes that the list is always valid, even though it will always be empty in legacy mode. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] video/fbdev: Always built-in video= cmdline parsing
In drm/i915 we want to get at the video= cmdline modes even when we
don't have fbdev support enabled, so that users can always override
the kernel's initial mode selection.
But that gives us a direct depency upon the parsing code in the fbdev
subsystem. Since it's so little code just extract these 2 functions
and always build them in.
Whiel at it fix the checkpatch fail in this code.
Cc: Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
--
I prefer if we can merge this through drm-next since we'll use it
there in follow-up patches.
-Daniel
---
drivers/video/fbdev/core/Makefile | 2 +-
drivers/video/fbdev/core/fb_cmdline.c | 103 ++
drivers/video/fbdev/core/fbmem.c | 92 --
3 files changed, 104 insertions(+), 93 deletions(-)
create mode 100644 drivers/video/fbdev/core/fb_cmdline.c
diff --git a/drivers/video/fbdev/core/Makefile
b/drivers/video/fbdev/core/Makefile
index fa306538dac2..891c1f890e03 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -1,4 +1,4 @@
-obj-y += fb_notify.o
+obj-y += fb_notify.o fb_cmdline.o
obj-$(CONFIG_FB) += fb.o
fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
modedb.o fbcvt.o
diff --git a/drivers/video/fbdev/core/fb_cmdline.c
b/drivers/video/fbdev/core/fb_cmdline.c
new file mode 100644
index ..91503a43213e
--- /dev/null
+++ b/drivers/video/fbdev/core/fb_cmdline.c
@@ -0,0 +1,103 @@
+/*
+ * linux/drivers/video/fb_cmdline.c
+ *
+ * Copyright (C) 2014 Intel Corp
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ *
+ * Authors:
+ *Vetter danie.vet...@ffwll.ch
+ */
+#include linux/init.h
+#include linux/fb.h
+
+static char *video_options[FB_MAX] __read_mostly;
+static int ofonly __read_mostly;
+
+/**
+ * fb_get_options - get kernel boot parameters
+ * @name: framebuffer name as it would appear in
+ * the boot parameter line
+ * (video=name:options)
+ * @option: the option will be stored here
+ *
+ * NOTE: Needed to maintain backwards compatibility
+ */
+int fb_get_options(const char *name, char **option)
+{
+ char *opt, *options = NULL;
+ int retval = 0;
+ int name_len = strlen(name), i;
+
+ if (name_len ofonly strncmp(name, offb, 4))
+ retval = 1;
+
+ if (name_len !retval) {
+ for (i = 0; i FB_MAX; i++) {
+ if (video_options[i] == NULL)
+ continue;
+ if (!video_options[i][0])
+ continue;
+ opt = video_options[i];
+ if (!strncmp(name, opt, name_len)
+ opt[name_len] == ':')
+ options = opt + name_len + 1;
+ }
+ }
+ /* No match, pass global option */
+ if (!options option fb_mode_option)
+ options = kstrdup(fb_mode_option, GFP_KERNEL);
+ if (options !strncmp(options, off, 3))
+ retval = 1;
+
+ if (option)
+ *option = options;
+
+ return retval;
+}
+EXPORT_SYMBOL(fb_get_options);
+
+/**
+ * video_setup - process command line options
+ * @options: string of options
+ *
+ * Process command line options for frame buffer subsystem.
+ *
+ * NOTE: This function is a __setup and __init function.
+ *It only stores the options. Drivers have to call
+ *fb_get_options() as necessary.
+ *
+ * Returns zero.
+ *
+ */
+static int __init video_setup(char *options)
+{
+ int i, global = 0;
+
+ if (!options || !*options)
+ global = 1;
+
+ if (!global !strncmp(options, ofonly, 6)) {
+ ofonly = 1;
+ global = 1;
+ }
+
+ if (!global !strchr(options, ':')) {
+ fb_mode_option = options;
+ global = 1;
+ }
+
+ if (!global) {
+ for (i = 0; i FB_MAX; i++) {
+ if (video_options[i] == NULL) {
+ video_options[i] = options;
+ break;
+ }
+ }
+ }
+
+ return 1;
+}
+__setup(video=, video_setup);
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index b5e85f6c1c26..0705d8883ede 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1908,96 +1908,4 @@ int fb_new_modelist(struct fb_info *info)
return err;
}
-static char *video_options[FB_MAX] __read_mostly;
-static int
Re: [Intel-gfx] [PATCH] video/fbdev: Always built-in video= cmdline parsing
On Wed, Aug 6, 2014 at 11:43 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
In drm/i915 we want to get at the video= cmdline modes even when we
don't have fbdev support enabled, so that users can always override
the kernel's initial mode selection.
But that gives us a direct depency upon the parsing code in the fbdev
subsystem. Since it's so little code just extract these 2 functions
and always build them in.
How much is so little? Think memory-constrained systems.
You can still build it depending on CONFIG_FB or CONFIG_DRM_I915.
diff --git a/drivers/video/fbdev/core/Makefile
b/drivers/video/fbdev/core/Makefile
index fa306538dac2..891c1f890e03 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -1,4 +1,4 @@
-obj-y += fb_notify.o
Oh, this is already unconditional. Who are its users?
+obj-y += fb_notify.o fb_cmdline.o
obj-$(CONFIG_FB) += fb.o
fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
modedb.o fbcvt.o
diff --git a/drivers/video/fbdev/core/fb_cmdline.c
b/drivers/video/fbdev/core/fb_cmdline.c
new file mode 100644
index ..91503a43213e
--- /dev/null
+++ b/drivers/video/fbdev/core/fb_cmdline.c
@@ -0,0 +1,103 @@
+/*
+ * linux/drivers/video/fb_cmdline.c
+ *
+ * Copyright (C) 2014 Intel Corp
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ *
+ * Authors:
+ *Vetter danie.vet...@ffwll.ch
+ */
The above chunk doesn't sound appropriate for extracting existing code...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Free pending page flip events at .preclose()
From: Ville Syrjälä ville.syrj...@linux.intel.com
If there are pending page flips when the fd gets closed those page
flips may have events associated to them. When the page flip eventually
completes it will queue the event to file_priv-event_list, but that
may be too late and file_priv-event_list has already been cleaned up.
Thus we leak a bit of kernel memory in the form of the event structure.
To avoid such problems clear out such pending events from
intel_crtc-unpin_work at -preclose(). Any event that already made it
to file_priv-event_list will get cleaned up by the drm_release_events()
a bit later.
We can ignore the file_priv-event_space accounting since file_priv is
going away. This is already how drm core deals with pending vblank
events, which are maintained by the drm core.
What saves us from a total disaster (ie. dereferencing and alrady
freed file_priv) is the fact that the fb descruction triggers a modeset
and there we wait for pending flips.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
drivers/gpu/drm/i915/intel_display.c | 22 ++
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 2e7f03a..c965698 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1981,6 +1981,9 @@ void i915_driver_preclose(struct drm_device *dev, struct
drm_file *file)
i915_gem_context_close(dev, file);
i915_gem_release(dev, file);
mutex_unlock(dev-struct_mutex);
+
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ intel_modeset_preclose(dev, file);
}
void i915_driver_postclose(struct drm_device *dev, struct drm_file *file)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 883af0b..4230e4a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13416,3 +13416,25 @@ intel_display_print_error_state(struct
drm_i915_error_state_buf *m,
err_printf(m, VSYNC: %08x\n, error-transcoder[i].vsync);
}
}
+
+void intel_modeset_preclose(struct drm_device *dev, struct drm_file *file)
+{
+ struct intel_crtc *crtc;
+
+ for_each_intel_crtc(dev, crtc) {
+ struct intel_unpin_work *work;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(dev-event_lock, irqflags);
+
+ work = crtc-unpin_work;
+
+ if (work work-event
+ work-event-base.file_priv == file) {
+ kfree(work-event);
+ work-event = NULL;
+ }
+
+ spin_unlock_irqrestore(dev-event_lock, irqflags);
+ }
+}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 28d185d..8f04ba8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -888,6 +888,7 @@ void intel_mode_from_pipe_config(struct drm_display_mode
*mode,
struct intel_crtc_config *pipe_config);
int intel_format_to_fourcc(int format);
void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc);
+void intel_modeset_preclose(struct drm_device *dev, struct drm_file *file);
/* intel_dp.c */
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm: Warn when leaking flip events on close
From: Ville Syrjälä ville.syrj...@linux.intel.com Warn when there are events on the file_priv-event_list just before file_priv gets freed. This can occur if the driver doesn't clean up pending page flip events in -preclose(). Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_fops.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index 8f91062..0fa4dad 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -529,6 +529,8 @@ int drm_release(struct inode *inode, struct file *filp) if (drm_core_check_feature(dev, DRIVER_PRIME)) drm_prime_destroy_file_private(file_priv-prime); + WARN_ON(!list_empty(file_priv-event_list)); + put_pid(file_priv-pid); kfree(file_priv); -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Don't grab an fb reference for the idr
On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
The current refcounting scheme is that the fb lookup idr also holds a
reference. This works out nicely bacause thus far we've always
explicitly cleaned up idr entries for framebuffers:
- Userspace fbs get removed in the rmfb ioctl or when the drm file
gets closed.
- Kernel fbs (for fbdev emulation) get cleaned up by the driver code
at module unload time.
But now i915 also reconstructs the bios fbs for a smooth transition.
And that fb is purely transitional and should get removed immmediately
once all crtcs stop using it. Of course if the i915 fbdev code decides
to reuse it as the main fbdev fb then it shouldn't be cleaned up, but
in that case the fbdev code will grab it's own reference.
The problem is now that we also want to register that takeover fb in
the idr, so that userspace can do a smooth transition (animated maybe
even!) itself. But currently we have no one who will clean up the idr
reference once that fb isn't useful any more, and so essentially leak
it.
ewww.. couldn't you do some scheme on lastclose to check if no more
crtc's are scanning out that fb, and if not then remove the idr?
BR,
-R
Fix this by no longer holding a full fb reference for the idr, but
instead just have a weak reference using kref_get_unless_zero. But
that requires us to synchronize and clean up with the idr and fb_lock
in drm_framebuffer_free, so add that. It's a bit ugly that we have to
unconditionally grab the fb_lock, but without that someone might creep
through a race.
This leak was caught by the fb leak check in drm_mode_config_cleanup.
Originally the leak was introduced in
commit 46f297fb83d4f9a6f6891964beb184664341a28b
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Fri Mar 7 08:57:48 2014 -0800
drm/i915: add plane_config fetching infrastructure v2
Cc: Jesse Barnes jbar...@virtuousgeek.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77511
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 46
--
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fa2be24c..33ff631c8d23 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -515,9 +515,6 @@ int drm_framebuffer_init(struct drm_device *dev, struct
drm_framebuffer *fb,
if (ret)
goto out;
- /* Grab the idr reference. */
- drm_framebuffer_reference(fb);
-
dev-mode_config.num_fb++;
list_add(fb-head, dev-mode_config.fb_list);
out:
@@ -527,10 +524,34 @@ out:
}
EXPORT_SYMBOL(drm_framebuffer_init);
+/* dev-mode_config.fb_lock must be held! */
+static void __drm_framebuffer_unregister(struct drm_device *dev,
+struct drm_framebuffer *fb)
+{
+ mutex_lock(dev-mode_config.idr_mutex);
+ idr_remove(dev-mode_config.crtc_idr, fb-base.id);
+ mutex_unlock(dev-mode_config.idr_mutex);
+
+ fb-base.id = 0;
+}
+
static void drm_framebuffer_free(struct kref *kref)
{
struct drm_framebuffer *fb =
container_of(kref, struct drm_framebuffer, refcount);
+ struct drm_device *dev = fb-dev;
+
+ /*
+* The lookup idr holds a weak reference, which has not necessarily
been
+* removed at this point. Check for that.
+*/
+ mutex_lock(dev-mode_config.fb_lock);
+ if (fb-base.id) {
+ /* Mark fb as reaped and drop idr ref. */
+ __drm_framebuffer_unregister(dev, fb);
+ }
+ mutex_unlock(dev-mode_config.fb_lock);
+
fb-funcs-destroy(fb);
}
@@ -567,8 +588,10 @@ struct drm_framebuffer *drm_framebuffer_lookup(struct
drm_device *dev,
mutex_lock(dev-mode_config.fb_lock);
fb = __drm_framebuffer_lookup(dev, id);
- if (fb)
- drm_framebuffer_reference(fb);
+ if (fb) {
+ if (!kref_get_unless_zero(fb-refcount))
+ fb = NULL;
+ }
mutex_unlock(dev-mode_config.fb_lock);
return fb;
@@ -612,19 +635,6 @@ static void __drm_framebuffer_unreference(struct
drm_framebuffer *fb)
kref_put(fb-refcount, drm_framebuffer_free_bug);
}
-/* dev-mode_config.fb_lock must be held! */
-static void __drm_framebuffer_unregister(struct drm_device *dev,
-struct drm_framebuffer *fb)
-{
- mutex_lock(dev-mode_config.idr_mutex);
- idr_remove(dev-mode_config.crtc_idr, fb-base.id);
- mutex_unlock(dev-mode_config.idr_mutex);
-
- fb-base.id = 0;
-
- __drm_framebuffer_unreference(fb);
-}
-
/**
* drm_framebuffer_unregister_private - unregister a private fb from the
lookup idr
* @fb: fb to unregister
--
1.9.3
[Intel-gfx] [PATCH] drm: Renaming DP training vswing/pre-emph defines
From: Sonika Jindal sonika.jin...@intel.com Rename the defines to have levels instead of values for vswing and pre-emph levels as the values may differ in other scenarios like low vswing of eDP 1.4 where the values are different. v2: Keeping old and new defines (Danvet), adding description in the commit message Cc: dri-de...@lists.freedesktop.org Signed-off-by: Sonika Jindal sonika.jin...@intel.com --- include/drm/drm_dp_helper.h | 26 ++ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index a21568b..df1e262 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -190,16 +190,26 @@ # define DP_TRAIN_VOLTAGE_SWING_MASK 0x3 # define DP_TRAIN_VOLTAGE_SWING_SHIFT 0 # define DP_TRAIN_MAX_SWING_REACHED(1 2) -# define DP_TRAIN_VOLTAGE_SWING_400(0 0) -# define DP_TRAIN_VOLTAGE_SWING_600(1 0) -# define DP_TRAIN_VOLTAGE_SWING_800(2 0) -# define DP_TRAIN_VOLTAGE_SWING_1200 (3 0) +# define DP_TRAIN_VOLTAGE_SWING_400(0 0) +# define DP_TRAIN_VOLTAGE_SWING_600(1 0) +# define DP_TRAIN_VOLTAGE_SWING_800(2 0) +# define DP_TRAIN_VOLTAGE_SWING_1200 (3 0) + +# define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 0) +# define DP_TRAIN_VOLTAGE_SWING_LEVEL_1 (1 0) +# define DP_TRAIN_VOLTAGE_SWING_LEVEL_2 (2 0) +# define DP_TRAIN_VOLTAGE_SWING_LEVEL_3 (3 0) # define DP_TRAIN_PRE_EMPHASIS_MASK(3 3) -# define DP_TRAIN_PRE_EMPHASIS_0 (0 3) -# define DP_TRAIN_PRE_EMPHASIS_3_5 (1 3) -# define DP_TRAIN_PRE_EMPHASIS_6 (2 3) -# define DP_TRAIN_PRE_EMPHASIS_9_5 (3 3) +# define DP_TRAIN_PRE_EMPHASIS_0 (0 3) +# define DP_TRAIN_PRE_EMPHASIS_3_5 (1 3) +# define DP_TRAIN_PRE_EMPHASIS_6 (2 3) +# define DP_TRAIN_PRE_EMPHASIS_9_5 (3 3) + +# define DP_TRAIN_PRE_EMPHASIS_LEVEL_0 (0 3) +# define DP_TRAIN_PRE_EMPHASIS_LEVEL_1 (1 3) +# define DP_TRAIN_PRE_EMPHASIS_LEVEL_2 (2 3) +# define DP_TRAIN_PRE_EMPHASIS_LEVEL_3 (3 3) # define DP_TRAIN_PRE_EMPHASIS_SHIFT 3 # define DP_TRAIN_MAX_PRE_EMPHASIS_REACHED (1 5) -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 00/19] drm: More vblank on/off work
From: Ville Syrjälä ville.syrj...@linux.intel.com This is mostly a repost of the earlier series [1]. Most of the patches have been reviewed, but I have added quite a few new ones to the end to fix various issues. [1] http://lists.freedesktop.org/archives/dri-devel/2014-May/060518.html Ville Syrjälä (19): drm: Always reject drm_vblank_get() after drm_vblank_off() drm/i915: Warn if drm_vblank_get() still works after drm_vblank_off() drm: Don't clear vblank timestamps when vblank interrupt is disabled drm: Move drm_update_vblank_count() drm: Have the vblank counter account for the time between vblank irq disable and drm_vblank_off() drm: Avoid random vblank counter jumps if the hardware counter has been reset drm: Reduce the amount of dev-vblank[crtc] in the code drm: Fix deadlock between event_lock and vbl_lock/vblank_time_lock drm: Fix race between drm_vblank_off() and drm_queue_vblank_event() drm: Disable vblank interrupt immediately when drm_vblank_offdelay0 drm: Add dev-vblank_disable_immediate flag drm/i915: Opt out of vblank disable timer on gen2 drm: Kick start vblank interrupts at drm_vblank_on() drm: Don't update vblank timestamp when the counter didn't change drm: Update vblank-last in drm_update_vblank_count() drm: Store the vblank timestamp when adjusting the counter during disable drm/i915: Clear .last vblank count before drm_vblank_off() when sanitizing crtc state drm/i915: Update scanline_offset only for active crtcs drm: Fix confusing debug message in drm_update_vblank_count() Documentation/DocBook/drm.tmpl | 7 + drivers/gpu/drm/drm_drv.c| 4 +- drivers/gpu/drm/drm_irq.c| 344 ++- drivers/gpu/drm/i915/i915_irq.c | 8 + drivers/gpu/drm/i915/intel_display.c | 20 +- include/drm/drmP.h | 12 +- 6 files changed, 259 insertions(+), 136 deletions(-) -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 01/19] drm: Always reject drm_vblank_get() after drm_vblank_off()
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make sure drm_vblank_get() never succeeds when called between
drm_vblank_off() and drm_vblank_on(). Borrow a trick from the
old drm_vblank_{pre,post}_modeset() functions and just bump
the refcount in drm_vblank_off() and drop it in drm_vblank_on().
When drm_vblank_get() encounters a 0 refcount and the vblank
interrupt is already disabled it will simply return -EINVAL.
Hopefully the use of inmodeset won't conflict badly with
drm_vblank_{pre,post}_modeset().
For i915 there's a window between drm_vblank_off() and marking the
crtc as inactive where the current code still allows drm_vblank_get().
v2: Describe what drm_vblank_get() does to explain how
a simple refcount bump manages to fix things (Daniel)
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 0de123a..b16a636 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1039,6 +1039,15 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
}
spin_unlock(dev-event_lock);
+ /*
+* Prevent subsequent drm_vblank_get() from re-enabling
+* the vblank interrupt by bumping the refcount.
+*/
+ if (!dev-vblank[crtc].inmodeset) {
+ atomic_inc(dev-vblank[crtc].refcount);
+ dev-vblank[crtc].inmodeset = 1;
+ }
+
spin_unlock_irqrestore(dev-vbl_lock, irqflags);
}
EXPORT_SYMBOL(drm_vblank_off);
@@ -1079,6 +1088,11 @@ void drm_vblank_on(struct drm_device *dev, int crtc)
unsigned long irqflags;
spin_lock_irqsave(dev-vbl_lock, irqflags);
+ /* Drop our private prevent drm_vblank_get refcount */
+ if (dev-vblank[crtc].inmodeset) {
+ atomic_dec(dev-vblank[crtc].refcount);
+ dev-vblank[crtc].inmodeset = 0;
+ }
/* re-enable interrupts if there's are users left */
if (atomic_read(dev-vblank[crtc].refcount) != 0)
WARN_ON(drm_vblank_enable(dev, crtc));
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/19] drm: Don't clear vblank timestamps when vblank interrupt is disabled
From: Ville Syrjälä ville.syrj...@linux.intel.com
Clearing the timestamps causes us to send zeroed timestamps to userspace
if they get sent out in response to the drm_vblank_off(). It's better
to send the very latest timestamp and count instead.
Testcase: igt/kms_flip/modeset-vs-vblank-race
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index b16a636..65d2da9 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -56,14 +56,6 @@
#define DRM_REDUNDANT_VBLIRQ_THRESH_NS 100
/*
- * Clear vblank timestamp buffer for a crtc.
- */
-static void clear_vblank_timestamps(struct drm_device *dev, int crtc)
-{
- memset(dev-vblank[crtc].time, 0, sizeof(dev-vblank[crtc].time));
-}
-
-/*
* Disable vblank irq's on crtc, make sure that last vblank count
* of hardware and corresponding consistent software vblank counter
* are preserved, even if there are any spurious vblank irq's after
@@ -131,9 +123,6 @@ static void vblank_disable_and_save(struct drm_device *dev,
int crtc)
smp_mb__after_atomic();
}
- /* Invalidate all timestamps while vblank irq's are off. */
- clear_vblank_timestamps(dev, crtc);
-
spin_unlock_irqrestore(dev-vblank_time_lock, irqflags);
}
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 02/19] drm/i915: Warn if drm_vblank_get() still works after drm_vblank_off()
From: Ville Syrjälä ville.syrj...@linux.intel.com
v2: Drop the drm_vblank_off() (Daniel)
Use drm_crtc_vblank_{get,put}()
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1b4cb0b..ae5f20d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1342,6 +1342,12 @@ static void assert_sprites_disabled(struct
drm_i915_private *dev_priv,
}
}
+static void assert_vblank_disabled(struct drm_crtc *crtc)
+{
+ if (WARN_ON(drm_crtc_vblank_get(crtc) == 0))
+ drm_crtc_vblank_put(crtc);
+}
+
static void ibx_assert_pch_refclk_enabled(struct drm_i915_private *dev_priv)
{
u32 val;
@@ -3909,6 +3915,8 @@ static void intel_crtc_enable_planes(struct drm_crtc
*crtc)
int pipe = intel_crtc-pipe;
int plane = intel_crtc-plane;
+ assert_vblank_disabled(crtc);
+
drm_vblank_on(dev, pipe);
intel_enable_primary_hw_plane(dev_priv, plane, pipe);
@@ -3958,6 +3966,8 @@ static void intel_crtc_disable_planes(struct drm_crtc
*crtc)
intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_ALL_MASK(pipe));
drm_vblank_off(dev, pipe);
+
+ assert_vblank_disabled(crtc);
}
static void ironlake_crtc_enable(struct drm_crtc *crtc)
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/19] drm: Move drm_update_vblank_count()
From: Ville Syrjälä ville.syrj...@linux.intel.com
Move drm_update_vblank_count() to avoid forward a declaration.
No functional change.
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c | 128 +++---
1 file changed, 64 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 65d2da9..af96517 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -55,6 +55,70 @@
*/
#define DRM_REDUNDANT_VBLIRQ_THRESH_NS 100
+/**
+ * drm_update_vblank_count - update the master vblank counter
+ * @dev: DRM device
+ * @crtc: counter to update
+ *
+ * Call back into the driver to update the appropriate vblank counter
+ * (specified by @crtc). Deal with wraparound, if it occurred, and
+ * update the last read value so we can deal with wraparound on the next
+ * call if necessary.
+ *
+ * Only necessary when going from off-on, to account for frames we
+ * didn't get an interrupt for.
+ *
+ * Note: caller must hold dev-vbl_lock since this reads writes
+ * device vblank fields.
+ */
+static void drm_update_vblank_count(struct drm_device *dev, int crtc)
+{
+ u32 cur_vblank, diff, tslot, rc;
+ struct timeval t_vblank;
+
+ /*
+* Interrupts were disabled prior to this call, so deal with counter
+* wrap if needed.
+* NOTE! It's possible we lost a full dev-max_vblank_count events
+* here if the register is small or we had vblank interrupts off for
+* a long time.
+*
+* We repeat the hardware vblank counter timestamp query until
+* we get consistent results. This to prevent races between gpu
+* updating its hardware counter while we are retrieving the
+* corresponding vblank timestamp.
+*/
+ do {
+ cur_vblank = dev-driver-get_vblank_counter(dev, crtc);
+ rc = drm_get_last_vbltimestamp(dev, crtc, t_vblank, 0);
+ } while (cur_vblank != dev-driver-get_vblank_counter(dev, crtc));
+
+ /* Deal with counter wrap */
+ diff = cur_vblank - dev-vblank[crtc].last;
+ if (cur_vblank dev-vblank[crtc].last) {
+ diff += dev-max_vblank_count;
+
+ DRM_DEBUG(last_vblank[%d]=0x%x, cur_vblank=0x%x =
diff=0x%x\n,
+ crtc, dev-vblank[crtc].last, cur_vblank, diff);
+ }
+
+ DRM_DEBUG(enabling vblank interrupts on crtc %d, missed %d\n,
+ crtc, diff);
+
+ /* Reinitialize corresponding vblank timestamp if high-precision query
+* available. Skip this step if query unsupported or failed. Will
+* reinitialize delayed at next vblank interrupt in that case.
+*/
+ if (rc) {
+ tslot = atomic_read(dev-vblank[crtc].count) + diff;
+ vblanktimestamp(dev, crtc, tslot) = t_vblank;
+ }
+
+ smp_mb__before_atomic();
+ atomic_add(diff, dev-vblank[crtc].count);
+ smp_mb__after_atomic();
+}
+
/*
* Disable vblank irq's on crtc, make sure that last vblank count
* of hardware and corresponding consistent software vblank counter
@@ -799,70 +863,6 @@ void drm_send_vblank_event(struct drm_device *dev, int
crtc,
EXPORT_SYMBOL(drm_send_vblank_event);
/**
- * drm_update_vblank_count - update the master vblank counter
- * @dev: DRM device
- * @crtc: counter to update
- *
- * Call back into the driver to update the appropriate vblank counter
- * (specified by @crtc). Deal with wraparound, if it occurred, and
- * update the last read value so we can deal with wraparound on the next
- * call if necessary.
- *
- * Only necessary when going from off-on, to account for frames we
- * didn't get an interrupt for.
- *
- * Note: caller must hold dev-vbl_lock since this reads writes
- * device vblank fields.
- */
-static void drm_update_vblank_count(struct drm_device *dev, int crtc)
-{
- u32 cur_vblank, diff, tslot, rc;
- struct timeval t_vblank;
-
- /*
-* Interrupts were disabled prior to this call, so deal with counter
-* wrap if needed.
-* NOTE! It's possible we lost a full dev-max_vblank_count events
-* here if the register is small or we had vblank interrupts off for
-* a long time.
-*
-* We repeat the hardware vblank counter timestamp query until
-* we get consistent results. This to prevent races between gpu
-* updating its hardware counter while we are retrieving the
-* corresponding vblank timestamp.
-*/
- do {
- cur_vblank = dev-driver-get_vblank_counter(dev, crtc);
- rc = drm_get_last_vbltimestamp(dev, crtc, t_vblank, 0);
- } while (cur_vblank != dev-driver-get_vblank_counter(dev, crtc));
-
- /* Deal with counter wrap */
- diff = cur_vblank - dev-vblank[crtc].last;
- if (cur_vblank
[Intel-gfx] [PATCH 05/19] drm: Have the vblank counter account for the time between vblank irq disable and drm_vblank_off()
From: Ville Syrjälä ville.syrj...@linux.intel.com
If the vblank irq has already been disabled (via the disable timer) when
we call drm_vblank_off() sample the counter and timestamp one last time.
This will make the sure that the user space visible counter will account
for time between vblank irq disable and drm_vblank_off().
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index af96517..1f86f6c 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -140,6 +140,19 @@ static void vblank_disable_and_save(struct drm_device
*dev, int crtc)
*/
spin_lock_irqsave(dev-vblank_time_lock, irqflags);
+ /*
+* If the vblank interrupt was already disbled update the count
+* and timestamp to maintain the appearance that the counter
+* has been ticking all along until this time. This makes the
+* count account for the entire time between drm_vblank_on() and
+* drm_vblank_off().
+*/
+ if (!dev-vblank[crtc].enabled) {
+ drm_update_vblank_count(dev, crtc);
+ spin_unlock_irqrestore(dev-vblank_time_lock, irqflags);
+ return;
+ }
+
dev-driver-disable_vblank(dev, crtc);
dev-vblank[crtc].enabled = false;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/19] drm: Fix deadlock between event_lock and vbl_lock/vblank_time_lock
From: Ville Syrjälä ville.syrj...@linux.intel.com
Currently both drm_irq.c and several drivers call drm_vblank_put()
while holding event_lock. Now that drm_vblank_put() can disable the
vblank interrupt directly it may need to grab vbl_lock and
vblank_time_lock. That causes deadlocks since we take the locks
in the opposite order in two places in drm_irq.c. So let's make
sure the locking order is always event_lock-vbl_lock-vblank_time_lock.
In drm_vblank_off() pull up event_lock from underneath vbl_lock. Hold
the event_lock across the whole operation to make sure we only send
out the events that were on the queue when we disabled the interrupt,
and not ones that got added just after (assuming drm_vblank_on() already
managed to get called somewhere between).
To sort the other deadlock pull the event_lock out from
drm_handle_vblank_events() into drm_handle_vblank() to be taken outside
vblank_time_lock. Add the appropriate assert_spin_locked() to
drm_handle_vblank_events().
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c | 47 +--
1 file changed, 25 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index b4460bf..9353609 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1037,14 +1037,25 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
unsigned long irqflags;
unsigned int seq;
- spin_lock_irqsave(dev-vbl_lock, irqflags);
+ spin_lock_irqsave(dev-event_lock, irqflags);
+
+ spin_lock(dev-vbl_lock);
vblank_disable_and_save(dev, crtc);
wake_up(vblank-queue);
+ /*
+* Prevent subsequent drm_vblank_get() from re-enabling
+* the vblank interrupt by bumping the refcount.
+*/
+ if (!vblank-inmodeset) {
+ atomic_inc(vblank-refcount);
+ vblank-inmodeset = 1;
+ }
+ spin_unlock(dev-vbl_lock);
+
/* Send any queued vblank events, lest the natives grow disquiet */
seq = drm_vblank_count_and_time(dev, crtc, now);
- spin_lock(dev-event_lock);
list_for_each_entry_safe(e, t, dev-vblank_event_list, base.link) {
if (e-pipe != crtc)
continue;
@@ -1055,18 +1066,7 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
drm_vblank_put(dev, e-pipe);
send_vblank_event(dev, e, seq, now);
}
- spin_unlock(dev-event_lock);
-
- /*
-* Prevent subsequent drm_vblank_get() from re-enabling
-* the vblank interrupt by bumping the refcount.
-*/
- if (!vblank-inmodeset) {
- atomic_inc(vblank-refcount);
- vblank-inmodeset = 1;
- }
-
- spin_unlock_irqrestore(dev-vbl_lock, irqflags);
+ spin_unlock_irqrestore(dev-event_lock, irqflags);
}
EXPORT_SYMBOL(drm_vblank_off);
@@ -1446,12 +1446,11 @@ static void drm_handle_vblank_events(struct drm_device
*dev, int crtc)
{
struct drm_pending_vblank_event *e, *t;
struct timeval now;
- unsigned long flags;
unsigned int seq;
- seq = drm_vblank_count_and_time(dev, crtc, now);
+ assert_spin_locked(dev-event_lock);
- spin_lock_irqsave(dev-event_lock, flags);
+ seq = drm_vblank_count_and_time(dev, crtc, now);
list_for_each_entry_safe(e, t, dev-vblank_event_list, base.link) {
if (e-pipe != crtc)
@@ -1467,8 +1466,6 @@ static void drm_handle_vblank_events(struct drm_device
*dev, int crtc)
send_vblank_event(dev, e, seq, now);
}
- spin_unlock_irqrestore(dev-event_lock, flags);
-
trace_drm_vblank_event(crtc, seq);
}
@@ -1491,15 +1488,18 @@ bool drm_handle_vblank(struct drm_device *dev, int crtc)
if (!dev-num_crtcs)
return false;
+ spin_lock_irqsave(dev-event_lock, irqflags);
+
/* Need timestamp lock to prevent concurrent execution with
* vblank enable/disable, as this would cause inconsistent
* or corrupted timestamps and vblank counts.
*/
- spin_lock_irqsave(dev-vblank_time_lock, irqflags);
+ spin_lock(dev-vblank_time_lock);
/* Vblank irq handling disabled. Nothing to do. */
if (!vblank-enabled) {
- spin_unlock_irqrestore(dev-vblank_time_lock, irqflags);
+ spin_unlock(dev-vblank_time_lock);
+ spin_unlock_irqrestore(dev-event_lock, irqflags);
return false;
}
@@ -1539,10 +1539,13 @@ bool drm_handle_vblank(struct drm_device *dev, int crtc)
crtc, (int) diff_ns);
}
+ spin_unlock(dev-vblank_time_lock);
+
wake_up(vblank-queue);
drm_handle_vblank_events(dev, crtc);
- spin_unlock_irqrestore(dev-vblank_time_lock, irqflags);
+
[Intel-gfx] [PATCH v2 07/19] drm: Reduce the amount of dev-vblank[crtc] in the code
From: Ville Syrjälä ville.syrj...@linux.intel.com
Declare a local struct drm_vblank_crtc * and use that
instead of having to do dig it out via 'dev-vblank[crtc]'
everywhere.
Performed with the following coccinelle incantation,
and a few manual whitespace cleanups:
@@
identifier func,member;
expression num_crtcs;
struct drm_device *dev;
unsigned int crtc;
@@
func (...) {
+ struct drm_vblank_crtc *vblank;
...
if (crtc = num_crtcs)
return ...;
+ vblank = dev-vblank[crtc];
+...
(
- dev-vblank[crtc].member
+ vblank-member
|
- (dev-vblank[crtc])
+ vblank
)
...+
}
@@
struct drm_device *dev;
int crtc;
identifier member;
expression num_crtcs;
@@
for (crtc = 0; crtc num_crtcs; crtc++) {
+ struct drm_vblank_crtc *vblank = dev-vblank[crtc];
+
+...
(
- dev-vblank[crtc].member
+ vblank-member
|
- (dev-vblank[crtc])
+ vblank
)
...+
}
@@
identifier func,member;
@@
func (struct drm_device *dev, int crtc, ...) {
+ struct drm_vblank_crtc *vblank = dev-vblank[crtc];
+...
(
- dev-vblank[crtc].member
+ vblank-member
|
- (dev-vblank[crtc])
+ vblank
)
...+
}
v2: Rebased
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c | 134 +++---
1 file changed, 79 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index fc1525a..b4460bf 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -73,6 +73,7 @@
*/
static void drm_update_vblank_count(struct drm_device *dev, int crtc)
{
+ struct drm_vblank_crtc *vblank = dev-vblank[crtc];
u32 cur_vblank, diff, tslot, rc;
struct timeval t_vblank;
@@ -94,12 +95,12 @@ static void drm_update_vblank_count(struct drm_device *dev,
int crtc)
} while (cur_vblank != dev-driver-get_vblank_counter(dev, crtc));
/* Deal with counter wrap */
- diff = cur_vblank - dev-vblank[crtc].last;
- if (cur_vblank dev-vblank[crtc].last) {
+ diff = cur_vblank - vblank-last;
+ if (cur_vblank vblank-last) {
diff += dev-max_vblank_count;
DRM_DEBUG(last_vblank[%d]=0x%x, cur_vblank=0x%x =
diff=0x%x\n,
- crtc, dev-vblank[crtc].last, cur_vblank, diff);
+ crtc, vblank-last, cur_vblank, diff);
}
DRM_DEBUG(enabling vblank interrupts on crtc %d, missed %d\n,
@@ -110,12 +111,12 @@ static void drm_update_vblank_count(struct drm_device
*dev, int crtc)
* reinitialize delayed at next vblank interrupt in that case.
*/
if (rc) {
- tslot = atomic_read(dev-vblank[crtc].count) + diff;
+ tslot = atomic_read(vblank-count) + diff;
vblanktimestamp(dev, crtc, tslot) = t_vblank;
}
smp_mb__before_atomic();
- atomic_add(diff, dev-vblank[crtc].count);
+ atomic_add(diff, vblank-count);
smp_mb__after_atomic();
}
@@ -127,6 +128,7 @@ static void drm_update_vblank_count(struct drm_device *dev,
int crtc)
*/
static void vblank_disable_and_save(struct drm_device *dev, int crtc)
{
+ struct drm_vblank_crtc *vblank = dev-vblank[crtc];
unsigned long irqflags;
u32 vblcount;
s64 diff_ns;
@@ -147,14 +149,14 @@ static void vblank_disable_and_save(struct drm_device
*dev, int crtc)
* count account for the entire time between drm_vblank_on() and
* drm_vblank_off().
*/
- if (!dev-vblank[crtc].enabled) {
+ if (!vblank-enabled) {
drm_update_vblank_count(dev, crtc);
spin_unlock_irqrestore(dev-vblank_time_lock, irqflags);
return;
}
dev-driver-disable_vblank(dev, crtc);
- dev-vblank[crtc].enabled = false;
+ vblank-enabled = false;
/* No further vblank irq's will be processed after
* this point. Get current hardware vblank count and
@@ -169,9 +171,9 @@ static void vblank_disable_and_save(struct drm_device *dev,
int crtc)
* delayed gpu counter increment.
*/
do {
- dev-vblank[crtc].last = dev-driver-get_vblank_counter(dev,
crtc);
+ vblank-last = dev-driver-get_vblank_counter(dev, crtc);
vblrc = drm_get_last_vbltimestamp(dev, crtc, tvblank, 0);
- } while (dev-vblank[crtc].last != dev-driver-get_vblank_counter(dev,
crtc) (--count) vblrc);
+ } while (vblank-last != dev-driver-get_vblank_counter(dev, crtc)
(--count) vblrc);
if (!count)
vblrc = 0;
@@ -179,7 +181,7 @@ static void vblank_disable_and_save(struct drm_device *dev,
int crtc)
/* Compute time difference to stored timestamp of last vblank
* as updated by last invocation of drm_handle_vblank() in vblank irq.
*/
- vblcount = atomic_read(dev-vblank[crtc].count);
+ vblcount =
[Intel-gfx] [PATCH 09/19] drm: Fix race between drm_vblank_off() and drm_queue_vblank_event()
From: Ville Syrjälä ville.syrj...@linux.intel.com
Currently it's possible that the following will happen:
1. drm_wait_vblank() calls drm_vblank_get()
2. drm_vblank_off() gets called
3. drm_wait_vblank() calls drm_queue_vblank_event() which
adds the event to the queue event though vblank interrupts
are currently disabled (and may not be re-enabled ever again).
To fix the problem, add another vblank-enabled check into
drm_queue_vblank_event().
drm_vblank_off() holds event_lock around the vblank disable,
so no further locking needs to be added to drm_queue_vblank_event().
vblank disable from another source is not possible since
drm_wait_vblank() already holds a vblank reference.
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 9353609..b2428cb 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1270,6 +1270,7 @@ static int drm_queue_vblank_event(struct drm_device *dev,
int pipe,
union drm_wait_vblank *vblwait,
struct drm_file *file_priv)
{
+ struct drm_vblank_crtc *vblank = dev-vblank[pipe];
struct drm_pending_vblank_event *e;
struct timeval now;
unsigned long flags;
@@ -1293,6 +1294,18 @@ static int drm_queue_vblank_event(struct drm_device
*dev, int pipe,
spin_lock_irqsave(dev-event_lock, flags);
+ /*
+* drm_vblank_off() might have been called after we called
+* drm_vblank_get(). drm_vblank_off() holds event_lock
+* around the vblank disable, so no need for further locking.
+* The reference from drm_vblank_get() protects against
+* vblank disable from another source.
+*/
+ if (!vblank-enabled) {
+ ret = -EINVAL;
+ goto err_unlock;
+ }
+
if (file_priv-event_space sizeof e-event) {
ret = -EBUSY;
goto err_unlock;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/19] drm: Avoid random vblank counter jumps if the hardware counter has been reset
From: Ville Syrjälä ville.syrj...@linux.intel.com When drm_vblank_on() is called the hardware vblank counter may have been reset, so we can't trust that the old values sampled prior to drm_vblank_off() have anything to do with the new values. So update the .last count in drm_vblank_on() to make the first drm_vblank_enable() consider that as the reference point. This will correct the user space visible counter to account for the time between drm_vblank_on() and the first drm_vblank_enable() calls. For extra safety subtract one from the .last count in drm_vblank_on() to make sure that user space will never see the same counter value before and after modeset. Reviewed-by: Matt Roper matthew.d.ro...@intel.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_irq.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 1f86f6c..fc1525a 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -1095,6 +1095,18 @@ void drm_vblank_on(struct drm_device *dev, int crtc) atomic_dec(dev-vblank[crtc].refcount); dev-vblank[crtc].inmodeset = 0; } + + /* +* sample the current counter to avoid random jumps +* when drm_vblank_enable() applies the diff +* +* -1 to make sure user will never see the same +* vblank counter value before and after a modeset +*/ + dev-vblank[crtc].last = + (dev-driver-get_vblank_counter(dev, crtc) - 1) + dev-max_vblank_count; + /* re-enable interrupts if there's are users left */ if (atomic_read(dev-vblank[crtc].refcount) != 0) WARN_ON(drm_vblank_enable(dev, crtc)); -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 11/19] drm: Add dev-vblank_disable_immediate flag
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add a flag to drm_device which will cause the vblank code to bypass the
disable timer and always disable the vblank interrupt immediately when
the last reference is dropped.
v2: Add some notes about the flag to the kernel doc
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
Documentation/DocBook/drm.tmpl | 6 ++
drivers/gpu/drm/drm_irq.c | 2 +-
include/drm/drmP.h | 10 ++
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 1cbe2a0..3ec4b2b 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3387,6 +3387,12 @@ void (*disable_vblank) (struct drm_device *dev, int
crtc);/synopsis
module parameter or the varnamedrm_vblank_offdelay/varname global
variable and expressed in milliseconds. Its default value is 5000 ms.
Zero means never disable, and a negative value means disable immediately.
+ Drivers may override the behaviour by setting the
+ structnamedrm_device/structname
+ structfieldvblank_disable_immediate/structfield flag, which when set
+ causes vblank interrupts to be disabled immediately regardless of the
+ drm_vblank_offdelay value. The flag should only be set if there's a
+ properly working hardware vblank counter present.
/para
para
When a vertical blanking interrupt occurs drivers only need to call the
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 99145c4..8dbcc3f 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -994,7 +994,7 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
/* Last user schedules interrupt disable */
if (atomic_dec_and_test(vblank-refcount)) {
- if (drm_vblank_offdelay 0)
+ if (dev-vblank_disable_immediate || drm_vblank_offdelay 0)
vblank_disable_fn((unsigned long)vblank);
else if (drm_vblank_offdelay 0)
mod_timer(vblank-disable_timer,
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index cdcc60b..3c22c35 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1077,6 +1077,16 @@ struct drm_device {
*/
bool vblank_disable_allowed;
+ /*
+* If true, vblank interrupt will be disabled immediately when the
+* refcount drops to zero, as opposed to via the vblank disable
+* timer.
+* This can be set to true it the hardware has a working vblank
+* counter and the driver uses drm_vblank_on() and drm_vblank_off()
+* appropriately.
+*/
+ bool vblank_disable_immediate;
+
/* array of size num_crtcs */
struct drm_vblank_crtc *vblank;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 13/19] drm: Kick start vblank interrupts at drm_vblank_on()
From: Ville Syrjälä ville.syrj...@linux.intel.com If the user is interested in getting accurate vblank sequence numbers all the time they may disable the vblank disable timer entirely. In that case it seems appropriate to kick start the vblank interrupts already from drm_vblank_on(). v2: Adapt to the drm_vblank_offdelay ==0 vs 0 changes Reviewed-by: Matt Roper matthew.d.ro...@intel.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_irq.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 8dbcc3f..af33df1 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -1126,9 +1126,12 @@ void drm_vblank_on(struct drm_device *dev, int crtc) vblank-last = (dev-driver-get_vblank_counter(dev, crtc) - 1) dev-max_vblank_count; - - /* re-enable interrupts if there's are users left */ - if (atomic_read(vblank-refcount) != 0) + /* +* re-enable interrupts if there are users left, or the +* user wishes vblank interrupts to be enabled all the time. +*/ + if (atomic_read(vblank-refcount) != 0 || + (!dev-vblank_disable_immediate drm_vblank_offdelay == 0)) WARN_ON(drm_vblank_enable(dev, crtc)); spin_unlock_irqrestore(dev-vbl_lock, irqflags); } -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/19] drm: Don't update vblank timestamp when the counter didn't change
From: Ville Syrjälä ville.syrj...@linux.intel.com If we already have a timestamp for the current vblank counter, don't update it with a new timestmap. Small errors can creep in between two timestamp queries for the same vblank count, which could be confusing to userspace when it queries the timestamp for the same vblank sequence number twice. This problem gets exposed when the vblank disable timer is not used (or is set to expire quickly) and thus we can get multiple vblank disable-enable transition during the same frame which would all attempt to update the timestamp with the latest estimate. Testcase: igt/kms_flip/flip-vs-expired-vblank Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_irq.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index af33df1..0523f5b 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -106,6 +106,9 @@ static void drm_update_vblank_count(struct drm_device *dev, int crtc) DRM_DEBUG(enabling vblank interrupts on crtc %d, missed %d\n, crtc, diff); + if (diff == 0) + return; + /* Reinitialize corresponding vblank timestamp if high-precision query * available. Skip this step if query unsupported or failed. Will * reinitialize delayed at next vblank interrupt in that case. -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/19] drm: Store the vblank timestamp when adjusting the counter during disable
From: Ville Syrjälä ville.syrj...@linux.intel.com
During vblank disable the code tries to guess based on the
timestamps whether we just missed one vblank or not. And if so
it increments the counter. However it forgets to store the new
timestamp to the approriate slot in our timestamp ring buffer.
So anyone querying the timestamp for the resulting sequence
number would get a stale timestamp. Fix it up by storing the
new timestamp.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 67507a4..e927e5f 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -203,6 +203,13 @@ static void vblank_disable_and_save(struct drm_device
*dev, int crtc)
* hope for the best.
*/
if ((vblrc 0) (abs64(diff_ns) 100)) {
+ /* Store new timestamp in ringbuffer. */
+ vblanktimestamp(dev, crtc, vblcount + 1) = tvblank;
+
+ /* Increment cooked vblank count. This also atomically commits
+* the timestamp computed above.
+*/
+ smp_mb__before_atomic();
atomic_inc(vblank-count);
smp_mb__after_atomic();
}
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/19] drm/i915: Opt out of vblank disable timer on gen2
From: Ville Syrjälä ville.syrj...@linux.intel.com
Now that the vblank races are plugged, we can opt out of using
the vblank disable timer and just let vblank interrupts get
disabled immediately when the last reference is dropped.
Gen2 is the exception since it has no hardware frame counter.
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 87abe86..9fdf738 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4682,6 +4682,14 @@ void intel_irq_init(struct drm_device *dev)
dev-max_vblank_count = 0xff; /* only 24 bits of frame
count */
}
+ /*
+* Opt out of the vblank disable timer on everything except gen2.
+* Gen2 doesn't have a hardware frame counter and so depends on
+* vblank interrupts to produce sane vblank seuquence numbers.
+*/
+ if (!IS_GEN2(dev))
+ dev-vblank_disable_immediate = true;
+
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
dev-driver-get_vblank_timestamp = i915_get_vblank_timestamp;
dev-driver-get_scanout_position = i915_get_crtc_scanoutpos;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/19] drm: Update vblank-last in drm_update_vblank_count()
From: Ville Syrjälä ville.syrj...@linux.intel.com We should update the last in drm_update_vblank_count() to avoid applying the diff more than once. This could occur eg. if drm_vblank_off() gets called multiple times for the crtc. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_irq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 0523f5b..67507a4 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -109,6 +109,8 @@ static void drm_update_vblank_count(struct drm_device *dev, int crtc) if (diff == 0) return; + vblank-last = cur_vblank; + /* Reinitialize corresponding vblank timestamp if high-precision query * available. Skip this step if query unsupported or failed. Will * reinitialize delayed at next vblank interrupt in that case. -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 17/19] drm/i915: Clear .last vblank count before drm_vblank_off() when sanitizing crtc state
From: Ville Syrjälä ville.syrj...@linux.intel.com
We call drm_vblank_off() during crtc sanitation to make sure the
software and hardware states agree. However drm_vblank_off() will
try to update the vblank timestamp and sequence number which lands
us in some trouble.
As the pipe is disabled the hardware frame counter query will
return 0. If the .last doesn't match the code will try to add the
difference to the user visible sequence number. During driver init
that's OK as .last == 0, but during resume .last may be anything.
So we should make sure we don't try to apply the diff here by zeroing
.last beforehand. Otherwise there maybe be a random jump in the user
visible sequence number across suspend.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ae5f20d..c00bcd0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12918,8 +12918,11 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc)
/* restore vblank interrupts to correct state */
if (crtc-active)
drm_vblank_on(dev, crtc-pipe);
- else
+ else {
+ /* avoid random jumps in seq/ts */
+ dev-vblank[crtc-pipe].last = 0;
drm_vblank_off(dev, crtc-pipe);
+ }
/* We need to sanitize the plane - pipe mapping first because this will
* disable the crtc (and hence change the state) if it is wrong. Note
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/19] drm: Fix confusing debug message in drm_update_vblank_count()
From: Ville Syrjälä ville.syrj...@linux.intel.com Now that drm_update_vblank_count() can be called even when we're not about to enable the vblank interrupts we shouldn't print debug messages stating otherwise. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index e927e5f..87abca3 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -103,7 +103,7 @@ static void drm_update_vblank_count(struct drm_device *dev, int crtc) crtc, vblank-last, cur_vblank, diff); } - DRM_DEBUG(enabling vblank interrupts on crtc %d, missed %d\n, + DRM_DEBUG(updating vblank count on crtc %d, missed %d\n, crtc, diff); if (diff == 0) -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] tests/kms_flip: Assert that vblank timestamps aren't zeroed
From: Ville Syrjälä ville.syrj...@linux.intel.com
The kernel might mistakenly send out a zeroed vblank timestamp when
the vblank wait gets terminated early due to crtc disable. Add an
assertion to catch that.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
tests/kms_flip.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 92f4eb5..e8a0b39 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -396,6 +396,9 @@ static int __wait_for_vblank(unsigned int flags, int
crtc_idx,
ret = drmWaitVBlank(drm_fd, wait_vbl);
if (ret == 0) {
+ igt_assert_f(wait_vbl.reply.tval_sec != 0 ||
+wait_vbl.reply.tval_usec != 0,
+zeroed vblank timestamp\n);
reply-ts.tv_sec = wait_vbl.reply.tval_sec;
reply-ts.tv_usec = wait_vbl.reply.tval_usec;
reply-sequence = wait_vbl.reply.sequence;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/19] drm/i915: Update scanline_offset only for active crtcs
From: Ville Syrjälä ville.syrj...@linux.intel.com
update_scanline_offset() in intel_sanitize_crtc() was supposed to
be called only for active crtcs. But due to some underrun patches it
now gets updated for all crtcs on gmch platforms.
Move the update_scanline_offset() to the very beginning of
intel_sanitize_crtc() where we update the vblank state. This seems like
a better place anyway since the scanline offset ought to be up to date
before we might need to consult it. So before any vblanky stuff happens.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c00bcd0..9403b2f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12916,9 +12916,10 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc)
I915_WRITE(reg, I915_READ(reg) ~PIPECONF_FRAME_START_DELAY_MASK);
/* restore vblank interrupts to correct state */
- if (crtc-active)
+ if (crtc-active) {
+ update_scanline_offset(crtc);
drm_vblank_on(dev, crtc-pipe);
- else {
+ } else {
/* avoid random jumps in seq/ts */
dev-vblank[crtc-pipe].last = 0;
drm_vblank_off(dev, crtc-pipe);
@@ -13020,8 +13021,6 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc)
*/
crtc-cpu_fifo_underrun_disabled = true;
crtc-pch_fifo_underrun_disabled = true;
-
- update_scanline_offset(crtc);
}
}
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] video/fbdev: Always built-in video= cmdline parsing
In drm/i915 we want to get at the video= cmdline modes even when we
don't have fbdev support enabled, so that users can always override
the kernel's initial mode selection.
But that gives us a direct depency upon the parsing code in the fbdev
subsystem. Since it's so little code just extract these 2 functions
and always build them in.
Whiel at it fix the checkpatch fail in this code.
v2: Also move fb_mode_option. Spotted by the kbuild.
Cc: Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
--
I prefer if we can merge this through drm-next since we'll use it
there in follow-up patches.
-Daniel
---
drivers/video/fbdev/core/Makefile | 2 +-
drivers/video/fbdev/core/fb_cmdline.c | 106 ++
drivers/video/fbdev/core/fbmem.c | 92 -
drivers/video/fbdev/core/modedb.c | 3 -
4 files changed, 107 insertions(+), 96 deletions(-)
create mode 100644 drivers/video/fbdev/core/fb_cmdline.c
diff --git a/drivers/video/fbdev/core/Makefile
b/drivers/video/fbdev/core/Makefile
index fa306538dac2..891c1f890e03 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -1,4 +1,4 @@
-obj-y += fb_notify.o
+obj-y += fb_notify.o fb_cmdline.o
obj-$(CONFIG_FB) += fb.o
fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
modedb.o fbcvt.o
diff --git a/drivers/video/fbdev/core/fb_cmdline.c
b/drivers/video/fbdev/core/fb_cmdline.c
new file mode 100644
index ..e8ce614bdd03
--- /dev/null
+++ b/drivers/video/fbdev/core/fb_cmdline.c
@@ -0,0 +1,106 @@
+/*
+ * linux/drivers/video/fb_cmdline.c
+ *
+ * Copyright (C) 2014 Intel Corp
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ *
+ * Authors:
+ *Vetter danie.vet...@ffwll.ch
+ */
+#include linux/init.h
+#include linux/fb.h
+
+static char *video_options[FB_MAX] __read_mostly;
+static int ofonly __read_mostly;
+
+const char *fb_mode_option;
+EXPORT_SYMBOL_GPL(fb_mode_option);
+
+/**
+ * fb_get_options - get kernel boot parameters
+ * @name: framebuffer name as it would appear in
+ * the boot parameter line
+ * (video=name:options)
+ * @option: the option will be stored here
+ *
+ * NOTE: Needed to maintain backwards compatibility
+ */
+int fb_get_options(const char *name, char **option)
+{
+ char *opt, *options = NULL;
+ int retval = 0;
+ int name_len = strlen(name), i;
+
+ if (name_len ofonly strncmp(name, offb, 4))
+ retval = 1;
+
+ if (name_len !retval) {
+ for (i = 0; i FB_MAX; i++) {
+ if (video_options[i] == NULL)
+ continue;
+ if (!video_options[i][0])
+ continue;
+ opt = video_options[i];
+ if (!strncmp(name, opt, name_len)
+ opt[name_len] == ':')
+ options = opt + name_len + 1;
+ }
+ }
+ /* No match, pass global option */
+ if (!options option fb_mode_option)
+ options = kstrdup(fb_mode_option, GFP_KERNEL);
+ if (options !strncmp(options, off, 3))
+ retval = 1;
+
+ if (option)
+ *option = options;
+
+ return retval;
+}
+EXPORT_SYMBOL(fb_get_options);
+
+/**
+ * video_setup - process command line options
+ * @options: string of options
+ *
+ * Process command line options for frame buffer subsystem.
+ *
+ * NOTE: This function is a __setup and __init function.
+ *It only stores the options. Drivers have to call
+ *fb_get_options() as necessary.
+ *
+ * Returns zero.
+ *
+ */
+static int __init video_setup(char *options)
+{
+ int i, global = 0;
+
+ if (!options || !*options)
+ global = 1;
+
+ if (!global !strncmp(options, ofonly, 6)) {
+ ofonly = 1;
+ global = 1;
+ }
+
+ if (!global !strchr(options, ':')) {
+ fb_mode_option = options;
+ global = 1;
+ }
+
+ if (!global) {
+ for (i = 0; i FB_MAX; i++) {
+ if (video_options[i] == NULL) {
+ video_options[i] = options;
+ break;
+ }
+ }
+ }
+
+ return 1;
+}
+__setup(video=, video_setup);
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index b5e85f6c1c26..0705d8883ede 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++
Re: [Intel-gfx] [PATCH] drm: Don't grab an fb reference for the idr
On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark wrote:
On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
The current refcounting scheme is that the fb lookup idr also holds a
reference. This works out nicely bacause thus far we've always
explicitly cleaned up idr entries for framebuffers:
- Userspace fbs get removed in the rmfb ioctl or when the drm file
gets closed.
- Kernel fbs (for fbdev emulation) get cleaned up by the driver code
at module unload time.
But now i915 also reconstructs the bios fbs for a smooth transition.
And that fb is purely transitional and should get removed immmediately
once all crtcs stop using it. Of course if the i915 fbdev code decides
to reuse it as the main fbdev fb then it shouldn't be cleaned up, but
in that case the fbdev code will grab it's own reference.
The problem is now that we also want to register that takeover fb in
the idr, so that userspace can do a smooth transition (animated maybe
even!) itself. But currently we have no one who will clean up the idr
reference once that fb isn't useful any more, and so essentially leak
it.
ewww.. couldn't you do some scheme on lastclose to check if no more
crtc's are scanning out that fb, and if not then remove the idr?
There's no natural point really but when we drop the last reference for
it. Going the weak reference route looked the most natural. And I honestly
expect other drivers to eventually do the same - forcing a modeset on
boot-up is kinda not too pretty, and permanently reserving a big
framebuffer just for the bios doesn't sound good either. This approach
would nicely solve it for everyone.
-Daniel
BR,
-R
Fix this by no longer holding a full fb reference for the idr, but
instead just have a weak reference using kref_get_unless_zero. But
that requires us to synchronize and clean up with the idr and fb_lock
in drm_framebuffer_free, so add that. It's a bit ugly that we have to
unconditionally grab the fb_lock, but without that someone might creep
through a race.
This leak was caught by the fb leak check in drm_mode_config_cleanup.
Originally the leak was introduced in
commit 46f297fb83d4f9a6f6891964beb184664341a28b
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Fri Mar 7 08:57:48 2014 -0800
drm/i915: add plane_config fetching infrastructure v2
Cc: Jesse Barnes jbar...@virtuousgeek.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77511
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 46
--
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fa2be24c..33ff631c8d23 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -515,9 +515,6 @@ int drm_framebuffer_init(struct drm_device *dev, struct
drm_framebuffer *fb,
if (ret)
goto out;
- /* Grab the idr reference. */
- drm_framebuffer_reference(fb);
-
dev-mode_config.num_fb++;
list_add(fb-head, dev-mode_config.fb_list);
out:
@@ -527,10 +524,34 @@ out:
}
EXPORT_SYMBOL(drm_framebuffer_init);
+/* dev-mode_config.fb_lock must be held! */
+static void __drm_framebuffer_unregister(struct drm_device *dev,
+struct drm_framebuffer *fb)
+{
+ mutex_lock(dev-mode_config.idr_mutex);
+ idr_remove(dev-mode_config.crtc_idr, fb-base.id);
+ mutex_unlock(dev-mode_config.idr_mutex);
+
+ fb-base.id = 0;
+}
+
static void drm_framebuffer_free(struct kref *kref)
{
struct drm_framebuffer *fb =
container_of(kref, struct drm_framebuffer,
refcount);
+ struct drm_device *dev = fb-dev;
+
+ /*
+* The lookup idr holds a weak reference, which has not necessarily
been
+* removed at this point. Check for that.
+*/
+ mutex_lock(dev-mode_config.fb_lock);
+ if (fb-base.id) {
+ /* Mark fb as reaped and drop idr ref. */
+ __drm_framebuffer_unregister(dev, fb);
+ }
+ mutex_unlock(dev-mode_config.fb_lock);
+
fb-funcs-destroy(fb);
}
@@ -567,8 +588,10 @@ struct drm_framebuffer *drm_framebuffer_lookup(struct
drm_device *dev,
mutex_lock(dev-mode_config.fb_lock);
fb = __drm_framebuffer_lookup(dev, id);
- if (fb)
- drm_framebuffer_reference(fb);
+ if (fb) {
+ if (!kref_get_unless_zero(fb-refcount))
+ fb = NULL;
+ }
mutex_unlock(dev-mode_config.fb_lock);
return fb;
@@ -612,19 +635,6 @@ static void __drm_framebuffer_unreference(struct
drm_framebuffer *fb)
kref_put(fb-refcount, drm_framebuffer_free_bug);
Re: [Intel-gfx] [PATCH] video/fbdev: Always built-in video= cmdline parsing
On Wed, Aug 06, 2014 at 12:27:32PM +0200, Geert Uytterhoeven wrote:
On Wed, Aug 6, 2014 at 11:43 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
In drm/i915 we want to get at the video= cmdline modes even when we
don't have fbdev support enabled, so that users can always override
the kernel's initial mode selection.
But that gives us a direct depency upon the parsing code in the fbdev
subsystem. Since it's so little code just extract these 2 functions
and always build them in.
How much is so little? Think memory-constrained systems.
You can still build it depending on CONFIG_FB or CONFIG_DRM_I915.
I'll do it as an option selected by FB and DRM then.
diff --git a/drivers/video/fbdev/core/Makefile
b/drivers/video/fbdev/core/Makefile
index fa306538dac2..891c1f890e03 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -1,4 +1,4 @@
-obj-y += fb_notify.o
Oh, this is already unconditional. Who are its users?
Welcome in fbdev-land. Not going to fix this, since my dragon-slaying
sword is already broken.
+obj-y += fb_notify.o fb_cmdline.o
obj-$(CONFIG_FB) += fb.o
fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
modedb.o fbcvt.o
diff --git a/drivers/video/fbdev/core/fb_cmdline.c
b/drivers/video/fbdev/core/fb_cmdline.c
new file mode 100644
index ..91503a43213e
--- /dev/null
+++ b/drivers/video/fbdev/core/fb_cmdline.c
@@ -0,0 +1,103 @@
+/*
+ * linux/drivers/video/fb_cmdline.c
+ *
+ * Copyright (C) 2014 Intel Corp
+ *
+ * This file is subject to the terms and conditions of the GNU General
Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ *
+ * Authors:
+ *Vetter danie.vet...@ffwll.ch
+ */
The above chunk doesn't sound appropriate for extracting existing code...
Well it all horribly predates git history, so no idea who actually wrote
this. I'll copy over the old header on top.
-Daniel
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like
that.
-- Linus Torvalds
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Free pending page flip events at .preclose()
On Wed, Aug 06, 2014 at 02:02:51PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
If there are pending page flips when the fd gets closed those page
flips may have events associated to them. When the page flip eventually
completes it will queue the event to file_priv-event_list, but that
may be too late and file_priv-event_list has already been cleaned up.
Thus we leak a bit of kernel memory in the form of the event structure.
To avoid such problems clear out such pending events from
intel_crtc-unpin_work at -preclose(). Any event that already made it
to file_priv-event_list will get cleaned up by the drm_release_events()
a bit later.
We can ignore the file_priv-event_space accounting since file_priv is
going away. This is already how drm core deals with pending vblank
events, which are maintained by the drm core.
What saves us from a total disaster (ie. dereferencing and alrady
freed file_priv) is the fact that the fb descruction triggers a modeset
and there we wait for pending flips.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Do we have an igt for this?
-Daniel
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
drivers/gpu/drm/i915/intel_display.c | 22 ++
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 2e7f03a..c965698 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1981,6 +1981,9 @@ void i915_driver_preclose(struct drm_device *dev,
struct drm_file *file)
i915_gem_context_close(dev, file);
i915_gem_release(dev, file);
mutex_unlock(dev-struct_mutex);
+
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ intel_modeset_preclose(dev, file);
}
void i915_driver_postclose(struct drm_device *dev, struct drm_file *file)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 883af0b..4230e4a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13416,3 +13416,25 @@ intel_display_print_error_state(struct
drm_i915_error_state_buf *m,
err_printf(m, VSYNC: %08x\n, error-transcoder[i].vsync);
}
}
+
+void intel_modeset_preclose(struct drm_device *dev, struct drm_file *file)
+{
+ struct intel_crtc *crtc;
+
+ for_each_intel_crtc(dev, crtc) {
+ struct intel_unpin_work *work;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(dev-event_lock, irqflags);
+
+ work = crtc-unpin_work;
+
+ if (work work-event
+ work-event-base.file_priv == file) {
+ kfree(work-event);
+ work-event = NULL;
+ }
+
+ spin_unlock_irqrestore(dev-event_lock, irqflags);
+ }
+}
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 28d185d..8f04ba8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -888,6 +888,7 @@ void intel_mode_from_pipe_config(struct drm_display_mode
*mode,
struct intel_crtc_config *pipe_config);
int intel_format_to_fourcc(int format);
void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc);
+void intel_modeset_preclose(struct drm_device *dev, struct drm_file *file);
/* intel_dp.c */
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm: Perform cmdline mode parsing during connector initialisation
From: Chris Wilson ch...@chris-wilson.co.uk
i915.ko has a custom fbdev initialisation routine that aims to preserve
the current mode set by the BIOS, unless overruled by the user. The
user's wishes are determined by what, if any, mode is specified on the
command line (via the video= parameter). However, that command line mode
is first parsed by drm_fb_helper_initial_config() which is called after
i915.ko's custom initial_config() as a fallback method. So in order for
us to honour it, we need to move the cmdline parser earlier. If we
perform the connector cmdline parsing as soon as we initialise the
connector, that cmdline mode and forced status is then available even if
the fbdev helper is not compiled in or never called.
We also then expose the cmdline user mode in the connector mode lists.
v2: Rebase after connector-name upheaval.
v3: Adapt mga200 to look for the cmdline mode in the new place. Nicely
simplifies things while at that.
v4: Fix checkpatch.
v5: Select FB_CMDLINE to adapt to the changed fbdev patch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk (v2)
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org (v2)
Cc: dri-de...@lists.freedesktop.org
Cc: Julia Lemire jlem...@matrox.com
Cc: Dave Airlie airl...@redhat.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/Kconfig| 1 +
drivers/gpu/drm/drm_crtc.c | 55 +
drivers/gpu/drm/drm_fb_helper.c| 64 ++
drivers/gpu/drm/drm_modes.c| 1 +
drivers/gpu/drm/drm_probe_helper.c | 17 +
drivers/gpu/drm/mgag200/mgag200_mode.c | 21 +++
include/drm/drm_crtc.h | 1 +
include/drm/drm_fb_helper.h| 1 -
8 files changed, 83 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 31894c8c1773..367f5dd23291 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -8,6 +8,7 @@ menuconfig DRM
tristate Direct Rendering Manager (XFree86 4.1.0 and higher DRI
support)
depends on (AGP || AGP=n) !EMULATED_CMPXCHG MMU HAS_DMA
select HDMI
+ select FB_CMDLINE
select I2C
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 33ff631c8d23..66d3bfb8d264 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -863,6 +863,59 @@ static void drm_mode_remove(struct drm_connector
*connector,
}
/**
+ * drm_connector_get_cmdline_mode - reads the user's cmdline mode
+ * @connector: connector to quwery
+ * @mode: returned mode
+ *
+ * The kernel supports per-connector configration of its consoles through
+ * use of the video= parameter. This function parses that option and
+ * extracts the user's specified mode (or enable/disable status) for a
+ * particular connector. This is typically only used during the early fbdev
+ * setup.
+ */
+static void drm_connector_get_cmdline_mode(struct drm_connector *connector)
+{
+ struct drm_cmdline_mode *mode = connector-cmdline_mode;
+ char *option = NULL;
+
+ if (fb_get_options(connector-name, option))
+ return;
+
+ if (!drm_mode_parse_command_line_for_connector(option,
+ connector,
+ mode))
+ return;
+
+ if (mode-force) {
+ const char *s;
+
+ switch (mode-force) {
+ case DRM_FORCE_OFF:
+ s = OFF;
+ break;
+ case DRM_FORCE_ON_DIGITAL:
+ s = ON - dig;
+ break;
+ default:
+ case DRM_FORCE_ON:
+ s = ON;
+ break;
+ }
+
+ DRM_INFO(forcing %s connector %s\n, connector-name, s);
+ connector-force = mode-force;
+ }
+
+ DRM_DEBUG_KMS(cmdline mode for connector %s %dx%d@%dHz%s%s%s\n,
+ connector-name,
+ mode-xres, mode-yres,
+ mode-refresh_specified ? mode-refresh : 60,
+ mode-rb ? reduced blanking : ,
+ mode-margins ? with margins : ,
+ mode-interlace ? interlaced : );
+}
+
+/**
* drm_connector_init - Init a preallocated connector
* @dev: DRM device
* @connector: the connector to init
@@ -914,6 +967,8 @@ int drm_connector_init(struct drm_device *dev,
connector-edid_blob_ptr = NULL;
connector-status = connector_status_unknown;
+ drm_connector_get_cmdline_mode(connector);
+
[Intel-gfx] [PATCH 1/2] video/fbdev: Always built-in video= cmdline parsing
In drm/i915 we want to get at the video= cmdline modes even when we
don't have fbdev support enabled, so that users can always override
the kernel's initial mode selection.
But that gives us a direct depency upon the parsing code in the fbdev
subsystem. Since it's so little code just extract these 2 functions
and always build them in.
Whiel at it fix the checkpatch fail in this code.
v2: Also move fb_mode_option. Spotted by the kbuild.
v3: Review from Geert:
- Keep the old copyright notice from fb_mem.c, although I have no
idea what exactly applies.
- Only compile this when needed.
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
--
I prefer if we can merge this through drm-next since we'll use it
there in follow-up patches.
-Daniel
---
drivers/video/fbdev/Kconfig | 4 ++
drivers/video/fbdev/core/Makefile | 1 +
drivers/video/fbdev/core/fb_cmdline.c | 110 ++
drivers/video/fbdev/core/fbmem.c | 92
drivers/video/fbdev/core/modedb.c | 3 -
5 files changed, 115 insertions(+), 95 deletions(-)
create mode 100644 drivers/video/fbdev/core/fb_cmdline.c
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 59c98bfd5a8a..f1458c95a688 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -4,6 +4,7 @@
menuconfig FB
tristate Support for frame buffer devices
+ select FB_CMDLINE
---help---
The frame buffer device provides an abstraction for the graphics
hardware. It represents the frame buffer of some video hardware and
@@ -52,6 +53,9 @@ config FIRMWARE_EDID
combination with certain motherboards and monitors are known to
suffer from this problem.
+config FB_CMDLINE
+ bool
+
config FB_DDC
tristate
depends on FB
diff --git a/drivers/video/fbdev/core/Makefile
b/drivers/video/fbdev/core/Makefile
index fa306538dac2..67f28e20a892 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -1,4 +1,5 @@
obj-y += fb_notify.o
+obj-$(CONFIG_FB_CMDLINE) += fb_cmdline.o
obj-$(CONFIG_FB) += fb.o
fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
modedb.o fbcvt.o
diff --git a/drivers/video/fbdev/core/fb_cmdline.c
b/drivers/video/fbdev/core/fb_cmdline.c
new file mode 100644
index ..39509ccd92f1
--- /dev/null
+++ b/drivers/video/fbdev/core/fb_cmdline.c
@@ -0,0 +1,110 @@
+/*
+ * linux/drivers/video/fb_cmdline.c
+ *
+ * Copyright (C) 2014 Intel Corp
+ * Copyright (C) 1994 Martin Schaller
+ *
+ * 2001 - Documented with DocBook
+ * - Brad Douglas b...@neruo.com
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ *
+ * Authors:
+ *Vetter danie.vet...@ffwll.ch
+ */
+#include linux/init.h
+#include linux/fb.h
+
+static char *video_options[FB_MAX] __read_mostly;
+static int ofonly __read_mostly;
+
+const char *fb_mode_option;
+EXPORT_SYMBOL_GPL(fb_mode_option);
+
+/**
+ * fb_get_options - get kernel boot parameters
+ * @name: framebuffer name as it would appear in
+ * the boot parameter line
+ * (video=name:options)
+ * @option: the option will be stored here
+ *
+ * NOTE: Needed to maintain backwards compatibility
+ */
+int fb_get_options(const char *name, char **option)
+{
+ char *opt, *options = NULL;
+ int retval = 0;
+ int name_len = strlen(name), i;
+
+ if (name_len ofonly strncmp(name, offb, 4))
+ retval = 1;
+
+ if (name_len !retval) {
+ for (i = 0; i FB_MAX; i++) {
+ if (video_options[i] == NULL)
+ continue;
+ if (!video_options[i][0])
+ continue;
+ opt = video_options[i];
+ if (!strncmp(name, opt, name_len)
+ opt[name_len] == ':')
+ options = opt + name_len + 1;
+ }
+ }
+ /* No match, pass global option */
+ if (!options option fb_mode_option)
+ options = kstrdup(fb_mode_option, GFP_KERNEL);
+ if (options !strncmp(options, off, 3))
+ retval = 1;
+
+ if (option)
+ *option = options;
+
+ return retval;
+}
+EXPORT_SYMBOL(fb_get_options);
+
+/**
+ * video_setup - process command line options
+ * @options: string of options
+ *
+ * Process command line options for frame buffer subsystem.
+ *
+ * NOTE: This function is a __setup and __init function.
+ *
Re: [Intel-gfx] [PATCH 14/19] drm: Don't update vblank timestamp when the counter didn't change
On Wed, Aug 06, 2014 at 02:49:57PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com If we already have a timestamp for the current vblank counter, don't update it with a new timestmap. Small errors can creep in between two timestamp queries for the same vblank count, which could be confusing to userspace when it queries the timestamp for the same vblank sequence number twice. This problem gets exposed when the vblank disable timer is not used (or is set to expire quickly) and thus we can get multiple vblank disable-enable transition during the same frame which would all attempt to update the timestamp with the latest estimate. Testcase: igt/kms_flip/flip-vs-expired-vblank Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/drm_irq.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index af33df1..0523f5b 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -106,6 +106,9 @@ static void drm_update_vblank_count(struct drm_device *dev, int crtc) DRM_DEBUG(enabling vblank interrupts on crtc %d, missed %d\n, crtc, diff); + if (diff == 0) + return; + /* Reinitialize corresponding vblank timestamp if high-precision query * available. Skip this step if query unsupported or failed. Will * reinitialize delayed at next vblank interrupt in that case. -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Rework GPU reset sequence to match driver load thaw
Hi Daniel,
I think this new patch fixes your issues with the previous one, can you please
let me know.
Thanks,
Alistair.
-Original Message-
From: Mcaulay, Alistair
Sent: Tuesday, August 05, 2014 9:47 AM
To: intel-gfx@lists.freedesktop.org
Cc: Mcaulay, Alistair
Subject: [PATCH v2] drm/i915: Rework GPU reset sequence to match driver
load thaw
From: McAulay, Alistair alistair.mcau...@intel.com
This patch is to address Daniels concerns over different code during reset:
http://lists.freedesktop.org/archives/intel-gfx/2014-June/047758.html
The reason for aiming as hard as possible to use the exact same code for
driver load, gpu reset and runtime pm/system resume is that we've simply
seen too many bugs due to slight variations and unintended omissions.
Tested using igt drv_hangman.
V2: Cleaner way of preventing check_wedge returning -EAGAIN
Signed-off-by: McAulay, Alistair alistair.mcau...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/i915_gem.c | 6 +--
drivers/gpu/drm/i915/i915_gem_context.c | 42 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 67
+
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +-
6 files changed, 23 insertions(+), 104 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c index 5e4fefd..3bfafe6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -806,7 +806,13 @@ int i915_reset(struct drm_device *dev)
!dev_priv-ums.mm_suspended) {
dev_priv-ums.mm_suspended = 0;
+ /* Used to prevent gem_check_wedged returning -EAGAIN
during gpu reset */
+ dev_priv-gpu_error.reload_in_reset = true;
+
ret = i915_gem_init_hw(dev);
+
+ dev_priv-gpu_error.reload_in_reset = false;
+
mutex_unlock(dev-struct_mutex);
if (ret) {
DRM_ERROR(Failed hw init on reset %d\n, ret); diff
--git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 991b663..116daff 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1217,6 +1217,9 @@ struct i915_gpu_error {
/* For missed irq/seqno simulation. */
unsigned int test_irq_rings;
+
+ /* Used to prevent gem_check_wedged returning -EAGAIN during
gpu reset */
+ bool reload_in_reset;
};
enum modeset_restore {
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c index ef047bc..14e1770 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1085,7 +1085,9 @@ i915_gem_check_wedge(struct i915_gpu_error
*error,
if (i915_terminally_wedged(error))
return -EIO;
- return -EAGAIN;
+ /* Check if GPU Reset is in progress */
+ if (!error-reload_in_reset)
+ return -EAGAIN;
}
return 0;
@@ -2590,8 +2592,6 @@ void i915_gem_reset(struct drm_device *dev)
for_each_ring(ring, dev_priv, i)
i915_gem_reset_ring_cleanup(dev_priv, ring);
- i915_gem_context_reset(dev);
-
i915_gem_restore_fences(dev);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index de72a28..d96219f 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -372,42 +372,6 @@ err_destroy:
return ERR_PTR(ret);
}
-void i915_gem_context_reset(struct drm_device *dev) -{
- struct drm_i915_private *dev_priv = dev-dev_private;
- int i;
-
- /* Prevent the hardware from restoring the last context (which
hung) on
- * the next switch */
- for (i = 0; i I915_NUM_RINGS; i++) {
- struct intel_engine_cs *ring = dev_priv-ring[i];
- struct intel_context *dctx = ring-default_context;
- struct intel_context *lctx = ring-last_context;
-
- /* Do a fake switch to the default context */
- if (lctx == dctx)
- continue;
-
- if (!lctx)
- continue;
-
- if (dctx-legacy_hw_ctx.rcs_state i == RCS) {
- WARN_ON(i915_gem_obj_ggtt_pin(dctx-
legacy_hw_ctx.rcs_state,
-
get_context_alignment(dev), 0));
- /* Fake a finish/inactive */
- dctx-legacy_hw_ctx.rcs_state-base.write_domain
= 0;
- dctx-legacy_hw_ctx.rcs_state-active = 0;
- }
-
- if (lctx-legacy_hw_ctx.rcs_state i == RCS)
- i915_gem_object_ggtt_unpin(lctx-
legacy_hw_ctx.rcs_state);
-
- i915_gem_context_unreference(lctx);
- i915_gem_context_reference(dctx);
-
Re: [Intel-gfx] [PATCH 15/19] drm: Update vblank-last in drm_update_vblank_count()
On Wed, Aug 06, 2014 at 02:49:58PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com We should update the last in drm_update_vblank_count() to avoid applying the diff more than once. This could occur eg. if drm_vblank_off() gets called multiple times for the crtc. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Currently we update -last when disabling the vblank and use it when re-enabling it. Those calls should be symmetric, except for driver bugs. Imo would be better to tighten up the checks for that. Or do I completely misunderstand what's going on here? -Daniel --- drivers/gpu/drm/drm_irq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 0523f5b..67507a4 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -109,6 +109,8 @@ static void drm_update_vblank_count(struct drm_device *dev, int crtc) if (diff == 0) return; + vblank-last = cur_vblank; + /* Reinitialize corresponding vblank timestamp if high-precision query * available. Skip this step if query unsupported or failed. Will * reinitialize delayed at next vblank interrupt in that case. -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/19] drm: Don't update vblank timestamp when the counter didn't change
On Wed, Aug 06, 2014 at 02:56:14PM +0200, Daniel Vetter wrote: On Wed, Aug 06, 2014 at 02:49:57PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com If we already have a timestamp for the current vblank counter, don't update it with a new timestmap. Small errors can creep in between two timestamp queries for the same vblank count, which could be confusing to userspace when it queries the timestamp for the same vblank sequence number twice. This problem gets exposed when the vblank disable timer is not used (or is set to expire quickly) and thus we can get multiple vblank disable-enable transition during the same frame which would all attempt to update the timestamp with the latest estimate. Testcase: igt/kms_flip/flip-vs-expired-vblank Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch On second consideration this seems to just paper over drivers that enable vblanks a few too many times. Or a bug in the vblank_get handling in drm_irq.c. If it's just that I think we should just tighten up the checks to catch that and drop this patch here. -Daniel --- drivers/gpu/drm/drm_irq.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index af33df1..0523f5b 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -106,6 +106,9 @@ static void drm_update_vblank_count(struct drm_device *dev, int crtc) DRM_DEBUG(enabling vblank interrupts on crtc %d, missed %d\n, crtc, diff); + if (diff == 0) + return; + /* Reinitialize corresponding vblank timestamp if high-precision query * available. Skip this step if query unsupported or failed. Will * reinitialize delayed at next vblank interrupt in that case. -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/19] drm: Store the vblank timestamp when adjusting the counter during disable
On Wed, Aug 06, 2014 at 02:49:59PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
During vblank disable the code tries to guess based on the
timestamps whether we just missed one vblank or not. And if so
it increments the counter. However it forgets to store the new
timestamp to the approriate slot in our timestamp ring buffer.
So anyone querying the timestamp for the resulting sequence
number would get a stale timestamp. Fix it up by storing the
new timestamp.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 67507a4..e927e5f 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -203,6 +203,13 @@ static void vblank_disable_and_save(struct drm_device
*dev, int crtc)
* hope for the best.
*/
if ((vblrc 0) (abs64(diff_ns) 100)) {
We should use DRM_REDUNDANT_VBLIRQ_THRESH_NS here for symmtry. With that
addressed this is Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
+ /* Store new timestamp in ringbuffer. */
+ vblanktimestamp(dev, crtc, vblcount + 1) = tvblank;
+
+ /* Increment cooked vblank count. This also atomically commits
+ * the timestamp computed above.
+ */
+ smp_mb__before_atomic();
atomic_inc(vblank-count);
smp_mb__after_atomic();
}
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Don't grab an fb reference for the idr
On Wed, Aug 6, 2014 at 8:37 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark wrote:
On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
The current refcounting scheme is that the fb lookup idr also holds a
reference. This works out nicely bacause thus far we've always
explicitly cleaned up idr entries for framebuffers:
- Userspace fbs get removed in the rmfb ioctl or when the drm file
gets closed.
- Kernel fbs (for fbdev emulation) get cleaned up by the driver code
at module unload time.
But now i915 also reconstructs the bios fbs for a smooth transition.
And that fb is purely transitional and should get removed immmediately
once all crtcs stop using it. Of course if the i915 fbdev code decides
to reuse it as the main fbdev fb then it shouldn't be cleaned up, but
in that case the fbdev code will grab it's own reference.
The problem is now that we also want to register that takeover fb in
the idr, so that userspace can do a smooth transition (animated maybe
even!) itself. But currently we have no one who will clean up the idr
reference once that fb isn't useful any more, and so essentially leak
it.
ewww.. couldn't you do some scheme on lastclose to check if no more
crtc's are scanning out that fb, and if not then remove the idr?
There's no natural point really but when we drop the last reference for
it. Going the weak reference route looked the most natural. And I honestly
expect other drivers to eventually do the same - forcing a modeset on
boot-up is kinda not too pretty, and permanently reserving a big
framebuffer just for the bios doesn't sound good either. This approach
would nicely solve it for everyone.
hmm, maybe somebody switched my coffee with decaf, but why isn't
lastclose a natural point?
ofc if that really doesn't work, the weak-ref thing seems like it
would solve it nicely. But if there were a simple solution that
didn't involve making fb refcnting more complex, I guess I would
prefer that
BR,
-R
-Daniel
BR,
-R
Fix this by no longer holding a full fb reference for the idr, but
instead just have a weak reference using kref_get_unless_zero. But
that requires us to synchronize and clean up with the idr and fb_lock
in drm_framebuffer_free, so add that. It's a bit ugly that we have to
unconditionally grab the fb_lock, but without that someone might creep
through a race.
This leak was caught by the fb leak check in drm_mode_config_cleanup.
Originally the leak was introduced in
commit 46f297fb83d4f9a6f6891964beb184664341a28b
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Fri Mar 7 08:57:48 2014 -0800
drm/i915: add plane_config fetching infrastructure v2
Cc: Jesse Barnes jbar...@virtuousgeek.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77511
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 46
--
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fa2be24c..33ff631c8d23 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -515,9 +515,6 @@ int drm_framebuffer_init(struct drm_device *dev,
struct drm_framebuffer *fb,
if (ret)
goto out;
- /* Grab the idr reference. */
- drm_framebuffer_reference(fb);
-
dev-mode_config.num_fb++;
list_add(fb-head, dev-mode_config.fb_list);
out:
@@ -527,10 +524,34 @@ out:
}
EXPORT_SYMBOL(drm_framebuffer_init);
+/* dev-mode_config.fb_lock must be held! */
+static void __drm_framebuffer_unregister(struct drm_device *dev,
+struct drm_framebuffer *fb)
+{
+ mutex_lock(dev-mode_config.idr_mutex);
+ idr_remove(dev-mode_config.crtc_idr, fb-base.id);
+ mutex_unlock(dev-mode_config.idr_mutex);
+
+ fb-base.id = 0;
+}
+
static void drm_framebuffer_free(struct kref *kref)
{
struct drm_framebuffer *fb =
container_of(kref, struct drm_framebuffer,
refcount);
+ struct drm_device *dev = fb-dev;
+
+ /*
+* The lookup idr holds a weak reference, which has not
necessarily been
+* removed at this point. Check for that.
+*/
+ mutex_lock(dev-mode_config.fb_lock);
+ if (fb-base.id) {
+ /* Mark fb as reaped and drop idr ref. */
+ __drm_framebuffer_unregister(dev, fb);
+ }
+ mutex_unlock(dev-mode_config.fb_lock);
+
fb-funcs-destroy(fb);
}
@@ -567,8 +588,10 @@ struct drm_framebuffer *drm_framebuffer_lookup(struct
drm_device *dev,
mutex_lock(dev-mode_config.fb_lock);
fb = __drm_framebuffer_lookup(dev, id);
- if (fb)
-
[Intel-gfx] [PATCH igt] tests: Add kms_flip_event_leak test
From: Ville Syrjälä ville.syrj...@linux.intel.com
kms_flip_event_leak will issue a page flip and close the file
descriptor before the flip has finished. This may cause the kernel
to leak the page flip event. The test itself won't actually fail but
if the kernel notices the leak and WARNs piglit will report a failure.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
tests/Makefile.sources | 1 +
tests/kms_flip_event_leak.c | 132
2 files changed, 133 insertions(+)
create mode 100644 tests/kms_flip_event_leak.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 0eb9369..698e290 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -66,6 +66,7 @@ TESTS_progs_M = \
kms_cursor_crc \
kms_fbc_crc \
kms_flip \
+ kms_flip_event_leak \
kms_flip_tiling \
kms_mmio_vs_cs_flip \
kms_pipe_crc_basic \
diff --git a/tests/kms_flip_event_leak.c b/tests/kms_flip_event_leak.c
new file mode 100644
index 000..9924333
--- /dev/null
+++ b/tests/kms_flip_event_leak.c
@@ -0,0 +1,132 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * 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.
+ *
+ */
+
+#include errno.h
+#include stdbool.h
+#include stdio.h
+#include string.h
+
+#include drmtest.h
+#include igt_debugfs.h
+#include igt_kms.h
+#include intel_chipset.h
+#include intel_batchbuffer.h
+#include ioctl_wrappers.h
+
+typedef struct {
+ int drm_fd;
+ igt_display_t display;
+} data_t;
+
+/*
+ * This test tries to provoke the kernel to leak a pending page flip event
+ * when the fd is closed before the flip has completed. The test itself won't
+ * fail even if the kernel leaks the event, but the resulting dmesg WARN
+ * will cause piglit to report a failure.
+ */
+static bool test(data_t *data, enum pipe pipe, igt_output_t *output)
+{
+ igt_plane_t *primary;
+ drmModeModeInfo *mode;
+ struct igt_fb fb[2];
+ int fd, ret;
+
+ /* select the pipe we want to use */
+ igt_output_set_pipe(output, pipe);
+ igt_display_commit(data-display);
+
+ if (!output-valid) {
+ igt_output_set_pipe(output, PIPE_ANY);
+ igt_display_commit(data-display);
+ return false;
+ }
+
+ primary = igt_output_get_plane(output, IGT_PLANE_PRIMARY);
+ mode = igt_output_get_mode(output);
+
+ igt_create_color_fb(data-drm_fd, mode-hdisplay, mode-vdisplay,
+ DRM_FORMAT_XRGB,
+ true, /* tiled */
+ 0.0, 0.0, 0.0, fb[0]);
+
+ igt_plane_set_fb(primary, fb[0]);
+ igt_display_commit2(data-display, COMMIT_LEGACY);
+
+ fd = drm_open_any();
+
+ ret = drmDropMaster(data-drm_fd);
+ igt_assert(ret == 0);
+
+ ret = drmSetMaster(fd);
+ igt_assert(ret == 0);
+
+ igt_create_color_fb(fd, mode-hdisplay, mode-vdisplay,
+ DRM_FORMAT_XRGB,
+ true, /* tiled */
+ 0.0, 0.0, 0.0, fb[1]);
+ ret = drmModePageFlip(fd, output-config.crtc-crtc_id,
+ fb[1].fb_id, DRM_MODE_PAGE_FLIP_EVENT,
+ data);
+ igt_assert(ret == 0);
+
+ ret = close(fd);
+ igt_assert(ret == 0);
+
+ ret = drmSetMaster(data-drm_fd);
+ igt_assert(ret == 0);
+
+ igt_plane_set_fb(primary, NULL);
+ igt_output_set_pipe(output, PIPE_ANY);
+ igt_display_commit(data-display);
+
+ igt_remove_fb(data-drm_fd, fb[0]);
+
+ return true;
+}
+
+igt_simple_main
+{
+ data_t data = {};
+ igt_output_t *output;
+ int valid_tests = 0;
+ enum pipe pipe;
+
+ igt_skip_on_simulation();
+
+ data.drm_fd = drm_open_any();
+ igt_set_vt_graphics_mode();
+
+
Re: [Intel-gfx] [PATCH 09/19] drm: Fix race between drm_vblank_off() and drm_queue_vblank_event()
On Wed, Aug 06, 2014 at 02:49:52PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Currently it's possible that the following will happen:
1. drm_wait_vblank() calls drm_vblank_get()
2. drm_vblank_off() gets called
3. drm_wait_vblank() calls drm_queue_vblank_event() which
adds the event to the queue event though vblank interrupts
are currently disabled (and may not be re-enabled ever again).
To fix the problem, add another vblank-enabled check into
drm_queue_vblank_event().
drm_vblank_off() holds event_lock around the vblank disable,
so no further locking needs to be added to drm_queue_vblank_event().
vblank disable from another source is not possible since
drm_wait_vblank() already holds a vblank reference.
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
I guess the window is too small here to make this reproducible in a test?
Especially since each attempt will take a few hundred ms ...
-Daniel
---
drivers/gpu/drm/drm_irq.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 9353609..b2428cb 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1270,6 +1270,7 @@ static int drm_queue_vblank_event(struct drm_device
*dev, int pipe,
union drm_wait_vblank *vblwait,
struct drm_file *file_priv)
{
+ struct drm_vblank_crtc *vblank = dev-vblank[pipe];
struct drm_pending_vblank_event *e;
struct timeval now;
unsigned long flags;
@@ -1293,6 +1294,18 @@ static int drm_queue_vblank_event(struct drm_device
*dev, int pipe,
spin_lock_irqsave(dev-event_lock, flags);
+ /*
+ * drm_vblank_off() might have been called after we called
+ * drm_vblank_get(). drm_vblank_off() holds event_lock
+ * around the vblank disable, so no need for further locking.
+ * The reference from drm_vblank_get() protects against
+ * vblank disable from another source.
+ */
+ if (!vblank-enabled) {
+ ret = -EINVAL;
+ goto err_unlock;
+ }
+
if (file_priv-event_space sizeof e-event) {
ret = -EBUSY;
goto err_unlock;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/19] drm/i915: Clear .last vblank count before drm_vblank_off() when sanitizing crtc state
On Wed, Aug 06, 2014 at 02:50:00PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We call drm_vblank_off() during crtc sanitation to make sure the
software and hardware states agree. However drm_vblank_off() will
try to update the vblank timestamp and sequence number which lands
us in some trouble.
As the pipe is disabled the hardware frame counter query will
return 0. If the .last doesn't match the code will try to add the
difference to the user visible sequence number. During driver init
that's OK as .last == 0, but during resume .last may be anything.
So we should make sure we don't try to apply the diff here by zeroing
.last beforehand. Otherwise there maybe be a random jump in the user
visible sequence number across suspend.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ae5f20d..c00bcd0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12918,8 +12918,11 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc)
/* restore vblank interrupts to correct state */
if (crtc-active)
drm_vblank_on(dev, crtc-pipe);
- else
+ else {
+ /* avoid random jumps in seq/ts */
+ dev-vblank[crtc-pipe].last = 0;
Should we have a drm_vblank_reset for this? I guess other drivers will
have similar issues with sorry, just lost it all kind of transitions.
Also this case should only happen when we enter the system resume with the
pipes in dpms off state. In that case we should have sampled something in
drm_vblank_off already and resampling doesn't look like a good idea.
Do we instead need some protection in drm_vblank_off to avoid re-sampling?
-Daniel
drm_vblank_off(dev, crtc-pipe);
+ }
/* We need to sanitize the plane - pipe mapping first because this will
* disable the crtc (and hence change the state) if it is wrong. Note
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/19] drm: Update vblank-last in drm_update_vblank_count()
On Wed, Aug 06, 2014 at 03:08:25PM +0200, Daniel Vetter wrote: On Wed, Aug 06, 2014 at 02:49:58PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com We should update the last in drm_update_vblank_count() to avoid applying the diff more than once. This could occur eg. if drm_vblank_off() gets called multiple times for the crtc. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Currently we update -last when disabling the vblank and use it when re-enabling it. Those calls should be symmetric, except for driver bugs. Imo would be better to tighten up the checks for that. Or do I completely misunderstand what's going on here? The issue is that we want to call drm_vblank_off() in intel_sanitize_crtc() for already disabled crtcs in order to to bump the refcount and set inmodeset=1 so that drm_vblank_get() won't try to enable vblank interrupts if someone calls drm_vblank_get() on it. So during suspend+resume we can get two drm_vblank_off() calls for the same crtc w/o a drm_vblank_on() in between. Although this patch doesn't actually fix the problem really since vblank counter query during sanitize will just return 0 because the pipe isn't active, so there's a later patch to just override .last=0 in intel_sanitize_crtc(). Another approach might be to set .last=0 in drm_vblank_off() itself (after vblank_disable_and_save()), mainly just to hide the details from the caller. -Daniel --- drivers/gpu/drm/drm_irq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 0523f5b..67507a4 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -109,6 +109,8 @@ static void drm_update_vblank_count(struct drm_device *dev, int crtc) if (diff == 0) return; + vblank-last = cur_vblank; + /* Reinitialize corresponding vblank timestamp if high-precision query * available. Skip this step if query unsupported or failed. Will * reinitialize delayed at next vblank interrupt in that case. -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/19] drm: Fix race between drm_vblank_off() and drm_queue_vblank_event()
On Wed, Aug 06, 2014 at 03:23:01PM +0200, Daniel Vetter wrote:
On Wed, Aug 06, 2014 at 02:49:52PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Currently it's possible that the following will happen:
1. drm_wait_vblank() calls drm_vblank_get()
2. drm_vblank_off() gets called
3. drm_wait_vblank() calls drm_queue_vblank_event() which
adds the event to the queue event though vblank interrupts
are currently disabled (and may not be re-enabled ever again).
To fix the problem, add another vblank-enabled check into
drm_queue_vblank_event().
drm_vblank_off() holds event_lock around the vblank disable,
so no further locking needs to be added to drm_queue_vblank_event().
vblank disable from another source is not possible since
drm_wait_vblank() already holds a vblank reference.
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
I guess the window is too small here to make this reproducible in a test?
I must admit that I didn't even try. I supposed I could try it now.
Especially since each attempt will take a few hundred ms ...
-Daniel
---
drivers/gpu/drm/drm_irq.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 9353609..b2428cb 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1270,6 +1270,7 @@ static int drm_queue_vblank_event(struct drm_device
*dev, int pipe,
union drm_wait_vblank *vblwait,
struct drm_file *file_priv)
{
+ struct drm_vblank_crtc *vblank = dev-vblank[pipe];
struct drm_pending_vblank_event *e;
struct timeval now;
unsigned long flags;
@@ -1293,6 +1294,18 @@ static int drm_queue_vblank_event(struct drm_device
*dev, int pipe,
spin_lock_irqsave(dev-event_lock, flags);
+ /*
+* drm_vblank_off() might have been called after we called
+* drm_vblank_get(). drm_vblank_off() holds event_lock
+* around the vblank disable, so no need for further locking.
+* The reference from drm_vblank_get() protects against
+* vblank disable from another source.
+*/
+ if (!vblank-enabled) {
+ ret = -EINVAL;
+ goto err_unlock;
+ }
+
if (file_priv-event_space sizeof e-event) {
ret = -EBUSY;
goto err_unlock;
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/19] drm/i915: Clear .last vblank count before drm_vblank_off() when sanitizing crtc state
On Wed, Aug 06, 2014 at 03:30:17PM +0200, Daniel Vetter wrote:
On Wed, Aug 06, 2014 at 02:50:00PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We call drm_vblank_off() during crtc sanitation to make sure the
software and hardware states agree. However drm_vblank_off() will
try to update the vblank timestamp and sequence number which lands
us in some trouble.
As the pipe is disabled the hardware frame counter query will
return 0. If the .last doesn't match the code will try to add the
difference to the user visible sequence number. During driver init
that's OK as .last == 0, but during resume .last may be anything.
So we should make sure we don't try to apply the diff here by zeroing
.last beforehand. Otherwise there maybe be a random jump in the user
visible sequence number across suspend.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ae5f20d..c00bcd0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12918,8 +12918,11 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc)
/* restore vblank interrupts to correct state */
if (crtc-active)
drm_vblank_on(dev, crtc-pipe);
- else
+ else {
+ /* avoid random jumps in seq/ts */
+ dev-vblank[crtc-pipe].last = 0;
Should we have a drm_vblank_reset for this? I guess other drivers will
have similar issues with sorry, just lost it all kind of transitions.
Also this case should only happen when we enter the system resume with the
pipes in dpms off state. In that case we should have sampled something in
drm_vblank_off already and resampling doesn't look like a good idea.
Do we instead need some protection in drm_vblank_off to avoid re-sampling?
Yeah, I suppose I could try to fix it in drm vblank code somehow. Just
resetting .last=0 in drm_vblank_off() would avoid the seq jump but would
still leave the vblank counter query in place. Admittedly the resulting
debug spam about vblank counter queries on disabled crtcs is rather
annoying.
-Daniel
drm_vblank_off(dev, crtc-pipe);
+ }
/* We need to sanitize the plane - pipe mapping first because this will
* disable the crtc (and hence change the state) if it is wrong. Note
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Don't grab an fb reference for the idr
On Wed, Aug 06, 2014 at 09:12:42AM -0400, Rob Clark wrote: On Wed, Aug 6, 2014 at 8:37 AM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark wrote: On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: The current refcounting scheme is that the fb lookup idr also holds a reference. This works out nicely bacause thus far we've always explicitly cleaned up idr entries for framebuffers: - Userspace fbs get removed in the rmfb ioctl or when the drm file gets closed. - Kernel fbs (for fbdev emulation) get cleaned up by the driver code at module unload time. But now i915 also reconstructs the bios fbs for a smooth transition. And that fb is purely transitional and should get removed immmediately once all crtcs stop using it. Of course if the i915 fbdev code decides to reuse it as the main fbdev fb then it shouldn't be cleaned up, but in that case the fbdev code will grab it's own reference. The problem is now that we also want to register that takeover fb in the idr, so that userspace can do a smooth transition (animated maybe even!) itself. But currently we have no one who will clean up the idr reference once that fb isn't useful any more, and so essentially leak it. ewww.. couldn't you do some scheme on lastclose to check if no more crtc's are scanning out that fb, and if not then remove the idr? There's no natural point really but when we drop the last reference for it. Going the weak reference route looked the most natural. And I honestly expect other drivers to eventually do the same - forcing a modeset on boot-up is kinda not too pretty, and permanently reserving a big framebuffer just for the bios doesn't sound good either. This approach would nicely solve it for everyone. hmm, maybe somebody switched my coffee with decaf, but why isn't lastclose a natural point? There is no lastclose for the bios ;-) Let me elaborate on what happens: 1. BIOS sets up an initial config with a framebuffer in stolen. 2. i915 takes over and reconstructs all the state, so now we have all the crtcs enabled using a framebuffer for all of them which wraps the bios allocation. 2b. (optional) reuse that framebuffer for fbdev. - That special bios fb has the following references: - 1 reference for each crtc that's using it - 1 optional reference if it's reused as the fbdev fb - 1 reference for the idr 3. Userspace takes over, potentially doing a getfb on the current (bios-inherited) fb for smooth transition, but then does a modeset to its own fb. - After this all the we've dropped the crtc references and we also want to drop the idr reference (since no one will ever use this framebuffer again). But there's simply no good place to do that. Lastclose might only happen before we shut down the system again, which is a bit too late. Note that the getfb call creates a gem handle for the fb object, so the backing storage might survive for a lot longer than the fb. ofc if that really doesn't work, the weak-ref thing seems like it would solve it nicely. But if there were a simple solution that didn't involve making fb refcnting more complex, I guess I would prefer that Well I didn't come up with anything else really. Plan b would be to add hooks after any plane updates and manually check whether that special fb has lost all but its idr reference, and if so clean it up. That seems to be a lot more fragile and convoluted than converting the idr to a weak reference. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Free pending page flip events at .preclose()
On Wed, Aug 06, 2014 at 02:02:51PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
If there are pending page flips when the fd gets closed those page
flips may have events associated to them. When the page flip eventually
completes it will queue the event to file_priv-event_list, but that
may be too late and file_priv-event_list has already been cleaned up.
Thus we leak a bit of kernel memory in the form of the event structure.
To avoid such problems clear out such pending events from
intel_crtc-unpin_work at -preclose(). Any event that already made it
to file_priv-event_list will get cleaned up by the drm_release_events()
a bit later.
We can ignore the file_priv-event_space accounting since file_priv is
going away. This is already how drm core deals with pending vblank
events, which are maintained by the drm core.
What saves us from a total disaster (ie. dereferencing and alrady
freed file_priv) is the fact that the fb descruction triggers a modeset
and there we wait for pending flips.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
drivers/gpu/drm/i915/intel_display.c | 22 ++
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 2e7f03a..c965698 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1981,6 +1981,9 @@ void i915_driver_preclose(struct drm_device *dev,
struct drm_file *file)
i915_gem_context_close(dev, file);
i915_gem_release(dev, file);
mutex_unlock(dev-struct_mutex);
+
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ intel_modeset_preclose(dev, file);
}
void i915_driver_postclose(struct drm_device *dev, struct drm_file *file)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 883af0b..4230e4a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13416,3 +13416,25 @@ intel_display_print_error_state(struct
drm_i915_error_state_buf *m,
err_printf(m, VSYNC: %08x\n, error-transcoder[i].vsync);
}
}
+
+void intel_modeset_preclose(struct drm_device *dev, struct drm_file *file)
+{
+ struct intel_crtc *crtc;
+
+ for_each_intel_crtc(dev, crtc) {
+ struct intel_unpin_work *work;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(dev-event_lock, irqflags);
+
+ work = crtc-unpin_work;
+
+ if (work work-event
+ work-event-base.file_priv == file) {
+ kfree(work-event);
+ work-event = NULL;
+ }
+
+ spin_unlock_irqrestore(dev-event_lock, irqflags);
+ }
I wonder whether we shouldn't do this in the drm core, with a per-file
event list. Anyway, good for now together with the igt, we can pimp this
later.
Queued for -next, thanks for the patch.
-Daniel
+}
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 28d185d..8f04ba8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -888,6 +888,7 @@ void intel_mode_from_pipe_config(struct drm_display_mode
*mode,
struct intel_crtc_config *pipe_config);
int intel_format_to_fourcc(int format);
void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc);
+void intel_modeset_preclose(struct drm_device *dev, struct drm_file *file);
/* intel_dp.c */
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] tests/pm_rpm: add planes subtests
2014-08-05 18:51 GMT-03:00 Matt Roper matthew.d.ro...@intel.com: On Tue, Aug 05, 2014 at 06:34:38PM -0300, Paulo Zanoni wrote: 2014-07-28 20:47 GMT-03:00 Matt Roper matthew.d.ro...@intel.com: On Mon, Jul 28, 2014 at 03:37:15PM -0300, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com Just like the cursor subtests, these also trigger WARNs on the current Kernel. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com I feel like a lot of the setup you have to do here is duplicating logic we have in the igt_kms library. Was there functionality lacking from that library that prevented you from using it to write this test? If so, I can look into adding it. Every single ioctl we call can result in runtime PM get/put calls inside the driver, so for pm_rpm.c I would like to keep using the low level interfaces, to make sure the suspends and resumes are controlled. Anyway, I never really looked at the library before. It seems the biggest functionality missing from it is documentation. I just took a look at the .c file and couldn't find anything that looked like would reduce my diffstat, since the libdrm functions we call on pm_rpm.c are very simple. Any suggestions? The main areas where I thought it might be possible to slim down a bit by using igt_kms were all the setup code --- grabbing plane resources, counting/looping over planes, grabbing properties to check plane types, etc. igt_kms will build up the plane list internally and hide a lot of that long, boring code from your tests. But since you've already written the test without it, I don't feel there's any major need to rewrite it with igt_kms; I was just curious if there was anything specific you thought was lacking from the library so that we could address it in the future. The big problem I see is that all/most functions take the igt_display_t type as an argument instead of taking plain libdrm types, so either you fully adopt the API, or you don't use it at all. To be able to use igt_kms at all I'd have to call igt_display_init(), which does way too much stuff, and is probably going to grow more, and at some point do something that gets too many power refcounts and breaks runtime PM. I would really love if the igt_kms functions were little helpers that accepted the plain libdrm types as arguments instead of its own types. This way, I would, for example, probably be able to reuse get_plane_property() or other functions. I see that on a lot of cases, we pass igt_display_t just to use the FD, so why not just use the FD? I'll try to write some patches to reuse the stuff I want to reuse, then you can comment on them. I did add some kerneldoc comments when I added the new interfaces in preparation for universal planes atomic modeset, but you're right that there's still a lot that could be better documented going forward. Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling Development Intel Corporation (916) 356-2795 -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/19] drm: Update vblank-last in drm_update_vblank_count()
On Wed, Aug 06, 2014 at 04:30:29PM +0300, Ville Syrjälä wrote: On Wed, Aug 06, 2014 at 03:08:25PM +0200, Daniel Vetter wrote: On Wed, Aug 06, 2014 at 02:49:58PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com We should update the last in drm_update_vblank_count() to avoid applying the diff more than once. This could occur eg. if drm_vblank_off() gets called multiple times for the crtc. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Currently we update -last when disabling the vblank and use it when re-enabling it. Those calls should be symmetric, except for driver bugs. Imo would be better to tighten up the checks for that. Or do I completely misunderstand what's going on here? The issue is that we want to call drm_vblank_off() in intel_sanitize_crtc() for already disabled crtcs in order to to bump the refcount and set inmodeset=1 so that drm_vblank_get() won't try to enable vblank interrupts if someone calls drm_vblank_get() on it. So during suspend+resume we can get two drm_vblank_off() calls for the same crtc w/o a drm_vblank_on() in between. Although this patch doesn't actually fix the problem really since vblank counter query during sanitize will just return 0 because the pipe isn't active, so there's a later patch to just override .last=0 in intel_sanitize_crtc(). Another approach might be to set .last=0 in drm_vblank_off() itself (after vblank_disable_and_save()), mainly just to hide the details from the caller. Resetting -last (if it works, need to be careful with drivers calling _off multiple times perhaps) sounds like the much simpler option, and probably does what everyone expects anyway. -Daniel -Daniel --- drivers/gpu/drm/drm_irq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 0523f5b..67507a4 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -109,6 +109,8 @@ static void drm_update_vblank_count(struct drm_device *dev, int crtc) if (diff == 0) return; + vblank-last = cur_vblank; + /* Reinitialize corresponding vblank timestamp if high-precision query * available. Skip this step if query unsupported or failed. Will * reinitialize delayed at next vblank interrupt in that case. -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Ville Syrjälä Intel OTC -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] tests/pm_rpm: add planes subtests
On Wed, Aug 06, 2014 at 11:11:41AM -0300, Paulo Zanoni wrote: 2014-08-05 18:51 GMT-03:00 Matt Roper matthew.d.ro...@intel.com: On Tue, Aug 05, 2014 at 06:34:38PM -0300, Paulo Zanoni wrote: 2014-07-28 20:47 GMT-03:00 Matt Roper matthew.d.ro...@intel.com: On Mon, Jul 28, 2014 at 03:37:15PM -0300, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com Just like the cursor subtests, these also trigger WARNs on the current Kernel. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com I feel like a lot of the setup you have to do here is duplicating logic we have in the igt_kms library. Was there functionality lacking from that library that prevented you from using it to write this test? If so, I can look into adding it. Every single ioctl we call can result in runtime PM get/put calls inside the driver, so for pm_rpm.c I would like to keep using the low level interfaces, to make sure the suspends and resumes are controlled. Anyway, I never really looked at the library before. It seems the biggest functionality missing from it is documentation. I just took a look at the .c file and couldn't find anything that looked like would reduce my diffstat, since the libdrm functions we call on pm_rpm.c are very simple. Any suggestions? The main areas where I thought it might be possible to slim down a bit by using igt_kms were all the setup code --- grabbing plane resources, counting/looping over planes, grabbing properties to check plane types, etc. igt_kms will build up the plane list internally and hide a lot of that long, boring code from your tests. But since you've already written the test without it, I don't feel there's any major need to rewrite it with igt_kms; I was just curious if there was anything specific you thought was lacking from the library so that we could address it in the future. The big problem I see is that all/most functions take the igt_display_t type as an argument instead of taking plain libdrm types, so either you fully adopt the API, or you don't use it at all. To be able to use igt_kms at all I'd have to call igt_display_init(), which does way too much stuff, and is probably going to grow more, and at some point do something that gets too many power refcounts and breaks runtime PM. I would really love if the igt_kms functions were little helpers that accepted the plain libdrm types as arguments instead of its own types. This way, I would, for example, probably be able to reuse get_plane_property() or other functions. I see that on a lot of cases, we pass igt_display_t just to use the FD, so why not just use the FD? I'll try to write some patches to reuse the stuff I want to reuse, then you can comment on them. igt_kms is kinda a helper library in the larva stage and still looking for an optimal design. Personally I'm also not really happy with it, which is why I didn't write the documentation back when I've done that for all other igt stuff - it just wasn't clear yet what the different parts should do. -Daniel I did add some kerneldoc comments when I added the new interfaces in preparation for universal planes atomic modeset, but you're right that there's still a lot that could be better documented going forward. Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling Development Intel Corporation (916) 356-2795 -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/chv: Implement SSEU info for CHV
On Tue, Aug 05, 2014 at 02:41:54PM +0100, Damien Lespiau wrote: On Tue, Aug 05, 2014 at 08:47:54AM -0500, Jeff McGee wrote: + + /* Copy SSEU info to the const device info with pointer magic */ + *(struct intel_sseu_info *)dev_priv-info.sseu = sseu_info; I've thought gcc just does a memcpy for plain strut assignments, i.e. + dev_priv-info.sseu = sseu_info; That's what we have intel_device_info_runtime_init(), the SSEU init function should be called from there. -- Damien Agree. I will move the call to intel_device_info_runtime_init(). -Jeff ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/15] drm/i915: vma/ppgtt lifetime rules
From: Michel Thierry michel.thie...@intel.com
VMAs should take a reference of the address space they use.
Now, when the fd is closed, it will release the ref that the context was
holding, but it will still be referenced by any vmas that are still
active.
ppgtt_release() should then only be called when the last thing referencing
it releases the ref, and it can just call the base cleanup and free the
ppgtt.
Note that with this we will extend the lifetime of ppgtts which
contain shared objects. But all the non-shared objects will get
removed as soon as they drop of the active list and for the shared
ones the shrinker can eventually reap them. Since we currently can't
evict ppgtt pagetables either I don't think that temporary leak is
important.
Signed-off-by: Michel Thierry michel.thie...@intel.com
[danvet: Add note about potential ppgtt leak with this approach.]
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 8
drivers/gpu/drm/i915/i915_gem_context.c | 23 +++
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
4 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7c25345ce3e5..5a18680011da 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2510,7 +2510,9 @@ void i915_gem_object_ggtt_unpin(struct
drm_i915_gem_object *obj);
/* i915_gem_context.c */
#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt, base)
+#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
int __must_check i915_gem_context_init(struct drm_device *dev);
+void ppgtt_release(struct kref *kref);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dcd8d7b42552..25a32b9c9b4b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4499,12 +4499,20 @@ struct i915_vma *i915_gem_obj_to_vma(struct
drm_i915_gem_object *obj,
void i915_gem_vma_destroy(struct i915_vma *vma)
{
+ struct i915_address_space *vm = NULL;
+ struct i915_hw_ppgtt *ppgtt = NULL;
WARN_ON(vma-node.allocated);
/* Keep the vma as a placeholder in the execbuffer reservation lists */
if (!list_empty(vma-exec_list))
return;
+ vm = vma-vm;
+ ppgtt = vm_to_ppgtt(vm);
+
+ if (ppgtt)
+ kref_put(ppgtt-ref, ppgtt_release);
+
list_del(vma-vma_link);
kfree(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3b99390e467a..ae706cba05ae 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -108,30 +108,13 @@ static void do_ppgtt_cleanup(struct i915_hw_ppgtt *ppgtt)
return;
}
- /*
-* Make sure vmas are unbound before we take down the drm_mm
-*
-* FIXME: Proper refcounting should take care of this, this shouldn't be
-* needed at all.
-*/
- if (!list_empty(vm-active_list)) {
- struct i915_vma *vma;
-
- list_for_each_entry(vma, vm-active_list, mm_list)
- if (WARN_ON(list_empty(vma-vma_link) ||
- list_is_singular(vma-vma_link)))
- break;
-
- i915_gem_evict_vm(ppgtt-base, true);
- } else {
- i915_gem_retire_requests(dev);
- i915_gem_evict_vm(ppgtt-base, false);
- }
+ /* vmas should already be unbound */
+ WARN_ON(!list_empty(vm-active_list));
ppgtt-base.cleanup(ppgtt-base);
}
-static void ppgtt_release(struct kref *kref)
+void ppgtt_release(struct kref *kref)
{
struct i915_hw_ppgtt *ppgtt =
container_of(kref, struct i915_hw_ppgtt, ref);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1411613f2174..90c3d0fae3f1 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2159,10 +2159,15 @@ i915_gem_obj_lookup_or_create_vma(struct
drm_i915_gem_object *obj,
struct i915_address_space *vm)
{
struct i915_vma *vma;
+ struct i915_hw_ppgtt *ppgtt = NULL;
vma = i915_gem_obj_to_vma(obj, vm);
if (!vma)
vma = __i915_gem_vma_create(obj, vm);
+ ppgtt = vm_to_ppgtt(vm);
+ if (ppgtt)
+ kref_get(ppgtt-ref);
+
return vma;
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/15] drm/i915: Add proper prefix to obj_to_ggtt
Stuff in headers really aught to have this.
Reviewed-by: Michel Thierry michel.thie...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 11 ++-
drivers/gpu/drm/i915/i915_gem.c | 2 +-
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 31422bc07445..0c10c9ab1b96 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2466,7 +2466,7 @@ static inline bool i915_gem_obj_is_pinned(struct
drm_i915_gem_object *obj) {
}
/* Some GGTT VM helpers */
-#define obj_to_ggtt(obj) \
+#define i915_obj_to_ggtt(obj) \
(((struct drm_i915_private *)(obj)-base.dev-dev_private)-gtt.base)
static inline bool i915_is_ggtt(struct i915_address_space *vm)
{
@@ -2486,19 +2486,19 @@ i915_vm_to_ppgtt(struct i915_address_space *vm)
static inline bool i915_gem_obj_ggtt_bound(struct drm_i915_gem_object *obj)
{
- return i915_gem_obj_bound(obj, obj_to_ggtt(obj));
+ return i915_gem_obj_bound(obj, i915_obj_to_ggtt(obj));
}
static inline unsigned long
i915_gem_obj_ggtt_offset(struct drm_i915_gem_object *obj)
{
- return i915_gem_obj_offset(obj, obj_to_ggtt(obj));
+ return i915_gem_obj_offset(obj, i915_obj_to_ggtt(obj));
}
static inline unsigned long
i915_gem_obj_ggtt_size(struct drm_i915_gem_object *obj)
{
- return i915_gem_obj_size(obj, obj_to_ggtt(obj));
+ return i915_gem_obj_size(obj, i915_obj_to_ggtt(obj));
}
static inline int __must_check
@@ -2506,7 +2506,8 @@ i915_gem_obj_ggtt_pin(struct drm_i915_gem_object *obj,
uint32_t alignment,
unsigned flags)
{
- return i915_gem_object_pin(obj, obj_to_ggtt(obj), alignment, flags |
PIN_GLOBAL);
+ return i915_gem_object_pin(obj, i915_obj_to_ggtt(obj),
+ alignment, flags | PIN_GLOBAL);
}
static inline int
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c43ccfdf45a5..f4e57fe05c6a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5266,7 +5266,7 @@ struct i915_vma *i915_gem_obj_to_ggtt(struct
drm_i915_gem_object *obj)
return NULL;
vma = list_first_entry(obj-vma_list, typeof(*vma), vma_link);
- if (vma-vm != obj_to_ggtt(obj))
+ if (vma-vm != i915_obj_to_ggtt(obj))
return NULL;
return vma;
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/15] drm/i915: Only refcount ppgtt if it actually is one
This essentially unbreaks non-ppgtt operation where we'd scribble over
random memory.
While at it give the vm_to_ppgtt function a proper prefix and make it
a bit more paranoid.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 10 +-
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 194367f0ba1a..31422bc07445 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2475,6 +2475,15 @@ static inline bool i915_is_ggtt(struct
i915_address_space *vm)
return vm == ggtt;
}
+static inline struct i915_hw_ppgtt *
+i915_vm_to_ppgtt(struct i915_address_space *vm)
+{
+ WARN_ON(i915_is_ggtt(vm));
+
+ return container_of(vm, struct i915_hw_ppgtt, base);
+}
+
+
static inline bool i915_gem_obj_ggtt_bound(struct drm_i915_gem_object *obj)
{
return i915_gem_obj_bound(obj, obj_to_ggtt(obj));
@@ -2510,7 +2519,6 @@ void i915_gem_object_ggtt_unpin(struct
drm_i915_gem_object *obj);
/* i915_gem_context.c */
#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt, base)
-#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
int __must_check i915_gem_context_init(struct drm_device *dev);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b33a677b4b1e..c43ccfdf45a5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4508,7 +4508,8 @@ void i915_gem_vma_destroy(struct i915_vma *vma)
vm = vma-vm;
- i915_ppgtt_put(vm_to_ppgtt(vm));
+ if (!i915_is_ggtt(vm))
+ i915_ppgtt_put(i915_vm_to_ppgtt(vm));
list_del(vma-vma_link);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 83ee41e5c1c7..3753bf184865 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2204,7 +2204,8 @@ i915_gem_obj_lookup_or_create_vma(struct
drm_i915_gem_object *obj,
if (!vma)
vma = __i915_gem_vma_create(obj, vm);
- i915_ppgtt_get(vm_to_ppgtt(vm));
+ if (!i915_is_ggtt(vm))
+ i915_ppgtt_get(i915_vm_to_ppgtt(vm));
return vma;
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/15] drm/i915: Allow i915_gem_setup_global_gtt to fail
We already needs this just as a safety check in case the preallocation
reservation dance fails. But we definitely need this to be able to
move tha aliasing ppgtt setup back out of the context code to this
place, where it belongs.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c | 7 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 16 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 4 ++--
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f4e57fe05c6a..d8399ee622b9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4762,7 +4762,12 @@ int i915_gem_init(struct drm_device *dev)
DRM_DEBUG_DRIVER(allow wake ack timed out\n);
}
- i915_gem_init_userptr(dev);
+ ret = i915_gem_init_userptr(dev);
+ if (ret) {
+ mutex_unlock(dev-struct_mutex);
+ return ret;
+ }
+
i915_gem_init_global_gtt(dev);
ret = i915_gem_context_init(dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 3753bf184865..4fa7807ed4d5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1709,10 +1709,10 @@ static void i915_gtt_color_adjust(struct drm_mm_node
*node,
}
}
-void i915_gem_setup_global_gtt(struct drm_device *dev,
- unsigned long start,
- unsigned long mappable_end,
- unsigned long end)
+int i915_gem_setup_global_gtt(struct drm_device *dev,
+ unsigned long start,
+ unsigned long mappable_end,
+ unsigned long end)
{
/* Let GEM Manage all of the aperture.
*
@@ -1745,8 +1745,10 @@ void i915_gem_setup_global_gtt(struct drm_device *dev,
WARN_ON(i915_gem_obj_ggtt_bound(obj));
ret = drm_mm_reserve_node(ggtt_vm-mm, vma-node);
- if (ret)
- DRM_DEBUG_KMS(Reservation failed\n);
+ if (ret) {
+ DRM_DEBUG_KMS(Reservation failed: %i\n, ret);
+ return ret;
+ }
obj-has_global_gtt_mapping = 1;
}
@@ -1763,6 +1765,8 @@ void i915_gem_setup_global_gtt(struct drm_device *dev,
/* And finally clear the reserved guard page */
ggtt_vm-clear_range(ggtt_vm, end - PAGE_SIZE, PAGE_SIZE, true);
+
+ return 0;
}
void i915_gem_init_global_gtt(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 0b04ef6167f8..bea3541d5525 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -271,8 +271,8 @@ struct i915_hw_ppgtt {
int i915_gem_gtt_init(struct drm_device *dev);
void i915_gem_init_global_gtt(struct drm_device *dev);
-void i915_gem_setup_global_gtt(struct drm_device *dev, unsigned long start,
- unsigned long mappable_end, unsigned long end);
+int i915_gem_setup_global_gtt(struct drm_device *dev, unsigned long start,
+ unsigned long mappable_end, unsigned long end);
bool intel_enable_ppgtt(struct drm_device *dev, bool full);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/15] drm/i915: Track file_priv, not ctx in the ppgtt structure
Hardware contexts reference a ppgtt, not the other way round. And the
only user of this (in debugfs) actually only cares about which file
the ppgtt is associated with. So give it what it wants.
While at it give the ppgtt create function a proper nameplace.
Reviewed-by: Michel Thierry michel.thie...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_gem_context.c | 22 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 21 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 6 +-
4 files changed, 28 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 330caa1ab9f9..5c40d49042b8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -333,7 +333,7 @@ static int per_file_stats(int id, void *ptr, void *data)
}
ppgtt = container_of(vma-vm, struct i915_hw_ppgtt,
base);
- if (ppgtt-ctx ppgtt-ctx-file_priv !=
stats-file_priv)
+ if (ppgtt-file_priv != stats-file_priv)
continue;
if (obj-ring) /* XXX per-vma statistic */
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 899c6a7a5920..3b8367aa8404 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -181,26 +181,6 @@ i915_gem_alloc_context_obj(struct drm_device *dev, size_t
size)
return obj;
}
-static struct i915_hw_ppgtt *
-create_vm_for_ctx(struct drm_device *dev, struct intel_context *ctx)
-{
- struct i915_hw_ppgtt *ppgtt;
- int ret;
-
- ppgtt = kzalloc(sizeof(*ppgtt), GFP_KERNEL);
- if (!ppgtt)
- return ERR_PTR(-ENOMEM);
-
- ret = i915_ppgtt_init(dev, ppgtt);
- if (ret) {
- kfree(ppgtt);
- return ERR_PTR(ret);
- }
-
- ppgtt-ctx = ctx;
- return ppgtt;
-}
-
static struct intel_context *
__create_hw_context(struct drm_device *dev,
struct drm_i915_file_private *file_priv)
@@ -287,7 +267,7 @@ i915_gem_create_context(struct drm_device *dev,
}
if (create_vm) {
- struct i915_hw_ppgtt *ppgtt = create_vm_for_ctx(dev, ctx);
+ struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev, file_priv);
if (IS_ERR_OR_NULL(ppgtt)) {
DRM_DEBUG_DRIVER(PPGTT setup failed (%ld)\n,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index baa94199239b..83ee41e5c1c7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1222,6 +1222,27 @@ int i915_ppgtt_init(struct drm_device *dev, struct
i915_hw_ppgtt *ppgtt)
return ret;
}
+struct i915_hw_ppgtt *
+i915_ppgtt_create(struct drm_device *dev, struct drm_i915_file_private *fpriv)
+{
+ struct i915_hw_ppgtt *ppgtt;
+ int ret;
+
+ ppgtt = kzalloc(sizeof(*ppgtt), GFP_KERNEL);
+ if (!ppgtt)
+ return ERR_PTR(-ENOMEM);
+
+ ret = i915_ppgtt_init(dev, ppgtt);
+ if (ret) {
+ kfree(ppgtt);
+ return ERR_PTR(ret);
+ }
+
+ ppgtt-file_priv = fpriv;
+
+ return ppgtt;
+}
+
void i915_ppgtt_release(struct kref *kref)
{
struct i915_hw_ppgtt *ppgtt =
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 380e034c66f8..0b04ef6167f8 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -34,6 +34,8 @@
#ifndef __I915_GEM_GTT_H__
#define __I915_GEM_GTT_H__
+struct drm_i915_file_private;
+
typedef uint32_t gen6_gtt_pte_t;
typedef uint64_t gen8_gtt_pte_t;
typedef gen8_gtt_pte_t gen8_ppgtt_pde_t;
@@ -258,7 +260,7 @@ struct i915_hw_ppgtt {
dma_addr_t *gen8_pt_dma_addr[4];
};
- struct intel_context *ctx;
+ struct drm_i915_file_private *file_priv;
int (*enable)(struct i915_hw_ppgtt *ppgtt);
int (*switch_mm)(struct i915_hw_ppgtt *ppgtt,
@@ -276,6 +278,8 @@ bool intel_enable_ppgtt(struct drm_device *dev, bool full);
int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt);
void i915_ppgtt_release(struct kref *kref);
+struct i915_hw_ppgtt *i915_ppgtt_create(struct drm_device *dev,
+ struct drm_i915_file_private *fpriv);
static inline void i915_ppgtt_get(struct i915_hw_ppgtt *ppgtt)
{
if (ppgtt)
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/15] drm/i915: Move i915_gem_chipset_flush to where it belongs
Include depency hell ftw! So need to move this into a real function.
Also fix up the header include order in i915_drv.h: The rule is to
always include core headers first, then local stuff.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 7 ---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d349dd75ed69..194367f0ba1a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2556,13 +2556,6 @@ int __must_check i915_gem_evict_something(struct
drm_device *dev,
int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
int i915_gem_evict_everything(struct drm_device *dev);
-/* belongs in i915_gem_gtt.h */
-static inline void i915_gem_chipset_flush(struct drm_device *dev)
-{
- if (INTEL_INFO(dev)-gen 6)
- intel_gtt_chipset_flush();
-}
-
/* i915_gem_stolen.c */
int i915_gem_init_stolen(struct drm_device *dev);
int i915_gem_stolen_setup_compression(struct drm_device *dev, int size, int
fb_cpp);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1a20e1b4f052..baa94199239b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2031,6 +2031,12 @@ static void gen6_gmch_remove(struct i915_address_space
*vm)
teardown_scratch_page(vm-dev);
}
+void i915_gem_chipset_flush(struct drm_device *dev)
+{
+ if (INTEL_INFO(dev)-gen 6)
+ intel_gtt_chipset_flush();
+}
+
static int i915_gmch_probe(struct drm_device *dev,
size_t *gtt_total,
size_t *stolen,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 57d401343e8d..380e034c66f8 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -294,4 +294,6 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev);
int __must_check i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj);
void i915_gem_gtt_finish_object(struct drm_i915_gem_object *obj);
+void i915_gem_chipset_flush(struct drm_device *dev);
+
#endif
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/15] drm/i915: Fix up checks for aliasing ppgtt
A subsequent patch will no longer initialize the aliasing ppgtt if we
have full ppgtt enabled, since we simply don't need that any more.
Unfortunately a few places check for the aliasing ppgtt instead of
checking for ppgtt in general. Fix them up.
One special case are the gtt offset and size macros, which have some
code to remap the aliasing ppgtt to the global gtt. The aliasing ppgtt
is _not_ a logical address space, so passing that in as the vm is
plain and simple a bug. So just WARN about it and carry on - we have a
gracefully fall-through anyway if we can't find the vma.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 4 +---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 8 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +---
4 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index dea99d92fb4a..c45856bcc8b9 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -842,8 +842,6 @@ finish:
*/
bool i915_needs_cmd_parser(struct intel_engine_cs *ring)
{
- struct drm_i915_private *dev_priv = ring-dev-dev_private;
-
if (!ring-needs_cmd_parser)
return false;
@@ -852,7 +850,7 @@ bool i915_needs_cmd_parser(struct intel_engine_cs *ring)
* disabled. That will cause all of the parser's PPGTT checks to
* fail. For now, disable parsing when PPGTT is off.
*/
- if (!dev_priv-mm.aliasing_ppgtt)
+ if (USES_PPGTT(ring-dev))
return false;
return (i915.enable_cmd_parser == 1);
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 2e7f03ad5ee2..e5ac1a6e9d26 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -999,7 +999,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
value = HAS_WT(dev);
break;
case I915_PARAM_HAS_ALIASING_PPGTT:
- value = dev_priv-mm.aliasing_ppgtt || USES_FULL_PPGTT(dev);
+ value = USES_PPGTT(dev);
break;
case I915_PARAM_HAS_WAIT_TIMEOUT:
value = 1;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d8399ee622b9..a79deb189146 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5114,9 +5114,7 @@ unsigned long i915_gem_obj_offset(struct
drm_i915_gem_object *o,
struct drm_i915_private *dev_priv = o-base.dev-dev_private;
struct i915_vma *vma;
- if (!dev_priv-mm.aliasing_ppgtt ||
- vm == dev_priv-mm.aliasing_ppgtt-base)
- vm = dev_priv-gtt.base;
+ WARN_ON(vm == dev_priv-mm.aliasing_ppgtt-base);
list_for_each_entry(vma, o-vma_list, vma_link) {
if (vma-vm == vm)
@@ -5157,9 +5155,7 @@ unsigned long i915_gem_obj_size(struct
drm_i915_gem_object *o,
struct drm_i915_private *dev_priv = o-base.dev-dev_private;
struct i915_vma *vma;
- if (!dev_priv-mm.aliasing_ppgtt ||
- vm == dev_priv-mm.aliasing_ppgtt-base)
- vm = dev_priv-gtt.base;
+ WARN_ON(vm == dev_priv-mm.aliasing_ppgtt-base);
BUG_ON(list_empty(o-vma_list));
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 05969f03c0c1..390e38325b37 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1977,9 +1977,7 @@ gen8_ring_dispatch_execbuffer(struct intel_engine_cs
*ring,
u64 offset, u32 len,
unsigned flags)
{
- struct drm_i915_private *dev_priv = ring-dev-dev_private;
- bool ppgtt = dev_priv-mm.aliasing_ppgtt != NULL
- !(flags I915_DISPATCH_SECURE);
+ bool ppgtt = USES_PPGTT(ring-dev) !(flags I915_DISPATCH_SECURE);
int ret;
ret = intel_ring_begin(ring, 4);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/15] drm/i915: Some cleanups for the ppgtt lifetime handling
So when reviewing Michel's patch I've noticed a few things and cleaned
them up:
- The early checks in ppgtt_release are now redundant: The inactive
list should always be empty now, so we can ditch these checks. Even
for the aliasing ppgtt (though that's a different confusion) since
we tear that down after all the objects are gone.
- The ppgtt handling functions are splattered all over. Consolidate
them in i915_gem_gtt.c, give them OCD prefixes and add wrappers for
get/put.
- There was a bit a confusion in ppgtt_release about whether it cares
about the active or inactive list. It should care about them both,
so augment the WARNINGs to check for both.
There's still create_vm_for_ctx left to do, put that is blocked on the
removal of ppgtt-ctx. Once that's done we can rename it to
i915_ppgtt_create and move it to its siblings for handling ppgtts.
v2: Move the ppgtt checks into the inline get/put functions as
suggested by Chris.
v3: Inline the now redundant ppgtt local variable.
Cc: Michel Thierry michel.thie...@intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 5 +
drivers/gpu/drm/i915/i915_gem_context.c | 36 -
drivers/gpu/drm/i915/i915_gem_gtt.c | 20 +-
drivers/gpu/drm/i915/i915_gem_gtt.h | 14 -
5 files changed, 33 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5a18680011da..d349dd75ed69 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2512,7 +2512,6 @@ void i915_gem_object_ggtt_unpin(struct
drm_i915_gem_object *obj);
#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt, base)
#define vm_to_ppgtt(vm) container_of(vm, struct i915_hw_ppgtt, base)
int __must_check i915_gem_context_init(struct drm_device *dev);
-void ppgtt_release(struct kref *kref);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 25a32b9c9b4b..b33a677b4b1e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4500,7 +4500,6 @@ struct i915_vma *i915_gem_obj_to_vma(struct
drm_i915_gem_object *obj,
void i915_gem_vma_destroy(struct i915_vma *vma)
{
struct i915_address_space *vm = NULL;
- struct i915_hw_ppgtt *ppgtt = NULL;
WARN_ON(vma-node.allocated);
/* Keep the vma as a placeholder in the execbuffer reservation lists */
@@ -4508,10 +4507,8 @@ void i915_gem_vma_destroy(struct i915_vma *vma)
return;
vm = vma-vm;
- ppgtt = vm_to_ppgtt(vm);
- if (ppgtt)
- kref_put(ppgtt-ref, ppgtt_release);
+ i915_ppgtt_put(vm_to_ppgtt(vm));
list_del(vma-vma_link);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index ae706cba05ae..899c6a7a5920 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -96,33 +96,6 @@
#define GEN6_CONTEXT_ALIGN (6410)
#define GEN7_CONTEXT_ALIGN 4096
-static void do_ppgtt_cleanup(struct i915_hw_ppgtt *ppgtt)
-{
- struct drm_device *dev = ppgtt-base.dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct i915_address_space *vm = ppgtt-base;
-
- if (ppgtt == dev_priv-mm.aliasing_ppgtt ||
- (list_empty(vm-active_list) list_empty(vm-inactive_list))) {
- ppgtt-base.cleanup(ppgtt-base);
- return;
- }
-
- /* vmas should already be unbound */
- WARN_ON(!list_empty(vm-active_list));
-
- ppgtt-base.cleanup(ppgtt-base);
-}
-
-void ppgtt_release(struct kref *kref)
-{
- struct i915_hw_ppgtt *ppgtt =
- container_of(kref, struct i915_hw_ppgtt, ref);
-
- do_ppgtt_cleanup(ppgtt);
- kfree(ppgtt);
-}
-
static size_t get_context_alignment(struct drm_device *dev)
{
if (IS_GEN6(dev))
@@ -171,8 +144,7 @@ void i915_gem_context_free(struct kref *ctx_ref)
ppgtt = ctx_to_ppgtt(ctx);
}
- if (ppgtt)
- kref_put(ppgtt-ref, ppgtt_release);
+ i915_ppgtt_put(ppgtt);
if (ctx-legacy_hw_ctx.rcs_state)
drm_gem_object_unreference(ctx-legacy_hw_ctx.rcs_state-base);
list_del(ctx-link);
@@ -219,7 +191,7 @@ create_vm_for_ctx(struct drm_device *dev, struct
intel_context *ctx)
if (!ppgtt)
return ERR_PTR(-ENOMEM);
- ret = i915_gem_init_ppgtt(dev, ppgtt);
+ ret = i915_ppgtt_init(dev, ppgtt);
if (ret) {
kfree(ppgtt);
return ERR_PTR(ret);
@@ -231,7 +203,7 @@
[Intel-gfx] [PATCH 10/15] drm/i915: Only track real ppgtt for a context
There's a bit a confusion since we track the global gtt,
the aliasing and real ppgtt in the ctx-vm pointer. And not
all callers really bother to check for the different cases and just
presume that it points to a real ppgtt.
Now looking closely we don't actually need -vm to always point at an
address space - the only place that cares actually has fixup code
already to decide whether to look at the per-proces or the global
address space.
So switch to just tracking the ppgtt directly and ditch all the
extraneous code.
v2: Fixup the ppgtt debugfs file to not oops on a NULL ctx-ppgtt.
Also drop the early exit - without aliasing ppgtt we want to dump all
the ppgtts of the contexts if we have full ppgtt.
v3: Actually git add the compile fix.
Reviewed-by: Michel Thierry michel.thie...@intel.com
Cc: Thierry, Michel michel.thie...@intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
OTC-Jira: VIZ-3724
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c| 11 ---
drivers/gpu/drm/i915/i915_drv.h| 3 +--
drivers/gpu/drm/i915/i915_gem_context.c| 28 +++-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +++--
drivers/gpu/drm/i915/i915_gpu_error.c | 10 +++---
5 files changed, 26 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5c40d49042b8..115cf2cec475 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1815,7 +1815,13 @@ static int per_file_ctx(int id, void *ptr, void *data)
{
struct intel_context *ctx = ptr;
struct seq_file *m = data;
- struct i915_hw_ppgtt *ppgtt = ctx_to_ppgtt(ctx);
+ struct i915_hw_ppgtt *ppgtt = ctx-ppgtt;
+
+ if (!ppgtt) {
+ seq_printf(m, no ppgtt for context %d\n,
+ ctx-user_handle);
+ return 0;
+ }
if (i915_gem_context_is_default(ctx))
seq_puts(m, default context:\n);
@@ -1875,8 +1881,7 @@ static void gen6_ppgtt_info(struct seq_file *m, struct
drm_device *dev)
seq_printf(m, pd gtt offset: 0x%08x\n, ppgtt-pd_offset);
ppgtt-debug_dump(ppgtt, m);
- } else
- return;
+ }
list_for_each_entry_reverse(file, dev-filelist, lhead) {
struct drm_i915_file_private *file_priv = file-driver_priv;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0c10c9ab1b96..f1cfc0999e6b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -622,7 +622,7 @@ struct intel_context {
uint8_t remap_slice;
struct drm_i915_file_private *file_priv;
struct i915_ctx_hang_stats hang_stats;
- struct i915_address_space *vm;
+ struct i915_hw_ppgtt *ppgtt;
struct {
struct drm_i915_gem_object *rcs_state;
@@ -2519,7 +2519,6 @@ i915_gem_object_ggtt_unbind(struct drm_i915_gem_object
*obj)
void i915_gem_object_ggtt_unpin(struct drm_i915_gem_object *obj);
/* i915_gem_context.c */
-#define ctx_to_ppgtt(ctx) container_of((ctx)-vm, struct i915_hw_ppgtt, base)
int __must_check i915_gem_context_init(struct drm_device *dev);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 7a455fcee3a7..c00e5d027774 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -136,15 +136,8 @@ void i915_gem_context_free(struct kref *ctx_ref)
{
struct intel_context *ctx = container_of(ctx_ref,
typeof(*ctx), ref);
- struct i915_hw_ppgtt *ppgtt = NULL;
- if (ctx-legacy_hw_ctx.rcs_state) {
- /* We refcount even the aliasing PPGTT to keep the code
symmetric */
- if (USES_PPGTT(ctx-legacy_hw_ctx.rcs_state-base.dev))
- ppgtt = ctx_to_ppgtt(ctx);
- }
-
- i915_ppgtt_put(ppgtt);
+ i915_ppgtt_put(ctx-ppgtt);
if (ctx-legacy_hw_ctx.rcs_state)
drm_gem_object_unreference(ctx-legacy_hw_ctx.rcs_state-base);
list_del(ctx-link);
@@ -240,7 +233,6 @@ i915_gem_create_context(struct drm_device *dev,
bool create_vm)
{
const bool is_global_default_ctx = file_priv == NULL;
- struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_context *ctx;
int ret = 0;
@@ -274,15 +266,10 @@ i915_gem_create_context(struct drm_device *dev,
PTR_ERR(ppgtt));
ret = PTR_ERR(ppgtt);
goto err_unpin;
- } else
- ctx-vm = ppgtt-base;
- } else if (USES_PPGTT(dev)) {
- /*
[Intel-gfx] [PATCH 12/15] drm/i915: Extract common cleanup into i915_ppgtt_release
Address space cleanup isn't really a job for the low-level cleanup callbacks. Without this change we can't reuse the low-level cleanup callback for the aliasing ppgtt cleanup. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index a4c1740d79be..bbf113ed7339 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -403,9 +403,6 @@ static void gen8_ppgtt_cleanup(struct i915_address_space *vm) struct i915_hw_ppgtt *ppgtt = container_of(vm, struct i915_hw_ppgtt, base); - list_del(vm-global_link); - drm_mm_takedown(vm-mm); - gen8_ppgtt_unmap_pages(ppgtt); gen8_ppgtt_free(ppgtt); } @@ -1029,8 +1026,6 @@ static void gen6_ppgtt_cleanup(struct i915_address_space *vm) struct i915_hw_ppgtt *ppgtt = container_of(vm, struct i915_hw_ppgtt, base); - list_del(vm-global_link); - drm_mm_takedown(ppgtt-base.mm); drm_mm_remove_node(ppgtt-node); gen6_ppgtt_unmap_pages(ppgtt); @@ -1255,6 +1250,9 @@ void i915_ppgtt_release(struct kref *kref) WARN_ON(!list_empty(ppgtt-base.active_list)); WARN_ON(!list_empty(ppgtt-base.inactive_list)); + list_del(ppgtt-base.global_link); + drm_mm_takedown(ppgtt-base.mm); + ppgtt-base.cleanup(ppgtt-base); kfree(ppgtt); } -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/15] drm/i915: Initialize the aliasing ppgtt as part of global gtt
Stuffing this into the context setup code doesn't make a lot of sense.
Also reusing the real ppgtt setup code makes even less sense since the
aliasing ppgtt isn't a real address space. Leaving all that stuff
unitialized will make sure that we catch any abusers promptly.
This is also a prep work to clean up the context-ppgtt link.
v2: Fix up the logic fail, I've fumbled it so badly to completely
disable ppgtt on gen6. Spotted by Ville and Michel. Also move around
the pde write into the gen6 init function, since otherwise it won't
work at all.
Cc: Thierry, Michel michel.thie...@intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_context.c | 13 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 42 +++--
2 files changed, 31 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3b8367aa8404..7a455fcee3a7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -276,17 +276,6 @@ i915_gem_create_context(struct drm_device *dev,
goto err_unpin;
} else
ctx-vm = ppgtt-base;
-
- /* This case is reserved for the global default context and
-* should only happen once. */
- if (is_global_default_ctx) {
- if (WARN_ON(dev_priv-mm.aliasing_ppgtt)) {
- ret = -EEXIST;
- goto err_unpin;
- }
-
- dev_priv-mm.aliasing_ppgtt = ppgtt;
- }
} else if (USES_PPGTT(dev)) {
/* For platforms which only have aliasing PPGTT, we fake the
* address space and refcounting. */
@@ -361,7 +350,7 @@ int i915_gem_context_init(struct drm_device *dev)
}
}
- ctx = i915_gem_create_context(dev, NULL, USES_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, NULL, USES_FULL_PPGTT(dev));
if (IS_ERR(ctx)) {
DRM_ERROR(Failed to create default global context (error
%ld)\n,
PTR_ERR(ctx));
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4fa7807ed4d5..a4c1740d79be 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1188,35 +1188,38 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
ppgtt-node.size 20,
ppgtt-node.start / PAGE_SIZE);
+ gen6_write_pdes(ppgtt);
+ DRM_DEBUG(Adding PPGTT at offset %x\n,
+ ppgtt-pd_offset 10);
+
return 0;
}
-int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
+int __hw_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- int ret = 0;
ppgtt-base.dev = dev;
ppgtt-base.scratch = dev_priv-gtt.base.scratch;
if (INTEL_INFO(dev)-gen 8)
- ret = gen6_ppgtt_init(ppgtt);
+ return gen6_ppgtt_init(ppgtt);
else if (IS_GEN8(dev))
- ret = gen8_ppgtt_init(ppgtt, dev_priv-gtt.base.total);
+ return gen8_ppgtt_init(ppgtt, dev_priv-gtt.base.total);
else
BUG();
+}
+int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int ret = 0;
- if (!ret) {
- struct drm_i915_private *dev_priv = dev-dev_private;
+ ret = __hw_ppgtt_init(dev, ppgtt);
+ if (ret == 0) {
kref_init(ppgtt-ref);
drm_mm_init(ppgtt-base.mm, ppgtt-base.start,
ppgtt-base.total);
i915_init_vm(dev_priv, ppgtt-base);
- if (INTEL_INFO(dev)-gen 8) {
- gen6_write_pdes(ppgtt);
- DRM_DEBUG(Adding PPGTT at offset %x\n,
- ppgtt-pd_offset 10);
- }
}
return ret;
@@ -1728,6 +1731,7 @@ int i915_gem_setup_global_gtt(struct drm_device *dev,
struct drm_mm_node *entry;
struct drm_i915_gem_object *obj;
unsigned long hole_start, hole_end;
+ int ret;
BUG_ON(mappable_end end);
@@ -1739,7 +1743,7 @@ int i915_gem_setup_global_gtt(struct drm_device *dev,
/* Mark any preallocated objects as occupied */
list_for_each_entry(obj, dev_priv-mm.bound_list, global_list) {
struct i915_vma *vma = i915_gem_obj_to_vma(obj, ggtt_vm);
- int ret;
+
DRM_DEBUG_KMS(reserving preallocated space: %lx + %zx\n,
i915_gem_obj_ggtt_offset(obj), obj-base.size);
@@ -1766,6
[Intel-gfx] [PATCH 11/15] drm/i915: Drop create_vm argument to i915_gem_create_context
Now that all the flow is streamlined the rule is simple: We create
a new ppgtt for a new context when we have full ppgtt enabled.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_context.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index c00e5d027774..655ed6228aab 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -229,8 +229,7 @@ err_out:
*/
static struct intel_context *
i915_gem_create_context(struct drm_device *dev,
- struct drm_i915_file_private *file_priv,
- bool create_vm)
+ struct drm_i915_file_private *file_priv)
{
const bool is_global_default_ctx = file_priv == NULL;
struct intel_context *ctx;
@@ -258,7 +257,7 @@ i915_gem_create_context(struct drm_device *dev,
}
}
- if (create_vm) {
+ if (USES_FULL_PPGTT(dev)) {
struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev, file_priv);
if (IS_ERR_OR_NULL(ppgtt)) {
@@ -337,7 +336,7 @@ int i915_gem_context_init(struct drm_device *dev)
}
}
- ctx = i915_gem_create_context(dev, NULL, USES_FULL_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, NULL);
if (IS_ERR(ctx)) {
DRM_ERROR(Failed to create default global context (error
%ld)\n,
PTR_ERR(ctx));
@@ -438,7 +437,7 @@ int i915_gem_context_open(struct drm_device *dev, struct
drm_file *file)
idr_init(file_priv-context_idr);
mutex_lock(dev-struct_mutex);
- ctx = i915_gem_create_context(dev, file_priv, USES_FULL_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, file_priv);
mutex_unlock(dev-struct_mutex);
if (IS_ERR(ctx)) {
@@ -696,7 +695,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
if (ret)
return ret;
- ctx = i915_gem_create_context(dev, file_priv, USES_FULL_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, file_priv);
mutex_unlock(dev-struct_mutex);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/15] drm/i915: don't touch console_lock for I915_FBDEV=n
We still have locking hilarity between the console_lock and the world,
so really don't bother with it if at all possible. This shuts up a
locdep splat I'm seeing after a system s/r cycle followed by reloading
i915.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6c4b25ce8bb0..f522a6371bc0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -554,9 +554,11 @@ static int i915_drm_freeze(struct drm_device *dev)
intel_uncore_forcewake_reset(dev, false);
intel_opregion_fini(dev);
+#ifdef CONFIG_DRM_I915_FBDEV
console_lock();
intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED);
console_unlock();
+#endif
dev_priv-suspend_count++;
@@ -677,6 +679,7 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
restore_gtt_mappings)
intel_opregion_init(dev);
+#ifdef CONFIG_DRM_I915_FBDEV
/*
* The console lock can be pretty contented on resume due
* to all the printk activity. Try to keep it out of the hot
@@ -688,6 +691,7 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
restore_gtt_mappings)
} else {
schedule_work(dev_priv-console_resume_work);
}
+#endif
mutex_lock(dev_priv-modeset_restore_lock);
dev_priv-modeset_restore = MODESET_DONE;
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/15] drm/i915: Cleanup aliasging ppgtt alongside the global gtt
Also remove related WARN_ONs which seem to have been hit since a rather
long time. But apperently no one noticed since our module reload is
already WARNING-infested :(
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c | 4
drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index c176a6c97c80..94afe7c4458b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1388,7 +1388,6 @@ cleanup_gem:
i915_gem_cleanup_ringbuffer(dev);
i915_gem_context_fini(dev);
mutex_unlock(dev-struct_mutex);
- WARN_ON(dev_priv-mm.aliasing_ppgtt);
cleanup_irq:
drm_irq_uninstall(dev);
cleanup_gem_stolen:
@@ -1897,7 +1896,6 @@ int i915_driver_unload(struct drm_device *dev)
mutex_lock(dev-struct_mutex);
i915_gem_cleanup_ringbuffer(dev);
i915_gem_context_fini(dev);
- WARN_ON(dev_priv-mm.aliasing_ppgtt);
mutex_unlock(dev-struct_mutex);
i915_gem_cleanup_stolen(dev);
@@ -1905,8 +1903,6 @@ int i915_driver_unload(struct drm_device *dev)
i915_free_hws(dev);
}
- WARN_ON(!list_empty(dev_priv-vm_list));
-
drm_vblank_cleanup(dev);
intel_teardown_gmbus(dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 2eab0b6a32e8..ff031bb1f296 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1801,6 +1801,12 @@ void i915_global_gtt_cleanup(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
struct i915_address_space *vm = dev_priv-gtt.base;
+ if (dev_priv-mm.aliasing_ppgtt) {
+ struct i915_hw_ppgtt *ppgtt = dev_priv-mm.aliasing_ppgtt;
+
+ ppgtt-base.cleanup(ppgtt-base);
+ }
+
if (drm_mm_initialized(vm-mm)) {
drm_mm_takedown(vm-mm);
list_del(vm-global_link);
@@ -1808,6 +1814,7 @@ void i915_global_gtt_cleanup(struct drm_device *dev)
vm-cleanup(vm);
}
+
static int setup_scratch_page(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/15] drm/i915: Extract commmon global gtt cleanup code
We want to move the aliasing ppgtt cleanup back into the global
gtt cleanup code for symmetric, but first we need to create such
a place.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c | 4 ++--
drivers/gpu/drm/i915/i915_gem_gtt.c | 20
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
3 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index e5ac1a6e9d26..c176a6c97c80 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1817,7 +1817,7 @@ out_mtrrfree:
arch_phys_wc_del(dev_priv-gtt.mtrr);
io_mapping_free(dev_priv-gtt.mappable);
out_gtt:
- dev_priv-gtt.base.cleanup(dev_priv-gtt.base);
+ i915_global_gtt_cleanup(dev);
out_regs:
intel_uncore_fini(dev);
pci_iounmap(dev-pdev, dev_priv-regs);
@@ -1916,7 +1916,7 @@ int i915_driver_unload(struct drm_device *dev)
destroy_workqueue(dev_priv-wq);
pm_qos_remove_request(dev_priv-pm_qos);
- dev_priv-gtt.base.cleanup(dev_priv-gtt.base);
+ i915_global_gtt_cleanup(dev);
intel_uncore_fini(dev);
if (dev_priv-regs != NULL)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index bbf113ed7339..2eab0b6a32e8 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1796,6 +1796,18 @@ void i915_gem_init_global_gtt(struct drm_device *dev)
i915_gem_setup_global_gtt(dev, 0, mappable_size, gtt_size);
}
+void i915_global_gtt_cleanup(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct i915_address_space *vm = dev_priv-gtt.base;
+
+ if (drm_mm_initialized(vm-mm)) {
+ drm_mm_takedown(vm-mm);
+ list_del(vm-global_link);
+ }
+
+ vm-cleanup(vm);
+}
static int setup_scratch_page(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -2064,10 +2076,6 @@ static void gen6_gmch_remove(struct i915_address_space
*vm)
struct i915_gtt *gtt = container_of(vm, struct i915_gtt, base);
- if (drm_mm_initialized(vm-mm)) {
- drm_mm_takedown(vm-mm);
- list_del(vm-global_link);
- }
iounmap(gtt-gsm);
teardown_scratch_page(vm-dev);
}
@@ -2106,10 +2114,6 @@ static int i915_gmch_probe(struct drm_device *dev,
static void i915_gmch_remove(struct i915_address_space *vm)
{
- if (drm_mm_initialized(vm-mm)) {
- drm_mm_takedown(vm-mm);
- list_del(vm-global_link);
- }
intel_gmch_remove();
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index bea3541d5525..6b30ebad0a0a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -273,6 +273,7 @@ int i915_gem_gtt_init(struct drm_device *dev);
void i915_gem_init_global_gtt(struct drm_device *dev);
int i915_gem_setup_global_gtt(struct drm_device *dev, unsigned long start,
unsigned long mappable_end, unsigned long end);
+void i915_global_gtt_cleanup(struct drm_device *dev);
bool intel_enable_ppgtt(struct drm_device *dev, bool full);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Slice/Subslice/EU info via GETPARAM
On Tue, Aug 05, 2014 at 04:50:16PM +0200, Daniel Vetter wrote: On Tue, Aug 5, 2014 at 4:03 PM, Jeff McGee jeff.mc...@intel.com wrote: Also, usual broken record request: I need open-source userspace using this (mesa, ddx, libva). -Daniel This is kind of chicken-and-egg problem that I haven't been through. I assume that we build new interfaces up the stack (kernel-libdrm-usermode). Any tips or docs on how to proceed? You need to have the full thing ready with kernel, igt, libdrm, and umd driver patches (and maybe even testcases for the new umd feature, e.g. for some of the arb robustness stuff we've done). Then you post them all to relevant mailing lists and go through the review process for all parts. Once that's done and _all_ parts are reviewed, merging starts with kernel+igt, then libdrm + libdrm release, then umd. -Daniel Thanks Daniel. Is it acceptable to get the kernel part merged with only an igt test (technically an open-source userspace component)? I think probably not, but have to ask. -Jeff ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Generalize drain latency computation
Modify drain latency computation to use it for any plane. Same function can be
used for primary, cursor and sprite planes.
v2: Adressed review comments by Imre and Ville.
- Moved clock round up in separate patch
- Added WARN check for clock and pixel size
- Simplified bit masking
- Use cursor_base instead of reg read
v3: Changed to bitwise shorthand operator for plane_dl assignment.
Signed-off-by: Gajanan Bhat gajanan.b...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 87 ++-
2 files changed, 51 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 187f862..08916df 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4009,6 +4009,7 @@ enum punit_power_well {
#define DDL_PLANE_PRECISION_64 (17)
#define DDL_PLANE_PRECISION_32 (07)
#define DDL_PLANE_SHIFT0
+#define DRAIN_LATENCY_MASK 0x7f
/* FIFO watermark sizes etc */
#define G4X_FIFO_LINE_SIZE 64
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ba8dfeb..cabea4b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1277,33 +1277,24 @@ static bool g4x_compute_srwm(struct drm_device *dev,
display, cursor);
}
-static bool vlv_compute_drain_latency(struct drm_device *dev,
-int plane,
-int *plane_prec_mult,
-int *plane_dl,
-int *cursor_prec_mult,
-int *cursor_dl)
+static bool vlv_compute_drain_latency(struct drm_crtc *crtc,
+ int pixel_size,
+ int *prec_mult,
+ int *drain_latency)
{
- struct drm_crtc *crtc;
- int clock, pixel_size;
int entries;
+ int clock = to_intel_crtc(crtc)-config.adjusted_mode.crtc_clock;
- crtc = intel_get_crtc_for_plane(dev, plane);
- if (!intel_crtc_active(crtc))
+ if (WARN(clock == 0, Pixel clock is zero!\n))
return false;
- clock = to_intel_crtc(crtc)-config.adjusted_mode.crtc_clock;
- pixel_size = crtc-primary-fb-bits_per_pixel / 8; /* BPP */
+ if (WARN(pixel_size == 0, Pixel size is zero!\n))
+ return false;
entries = (clock / 1000) * pixel_size;
- *plane_prec_mult = (entries 128) ?
- DRAIN_LATENCY_PRECISION_64 : DRAIN_LATENCY_PRECISION_32;
- *plane_dl = (64 * (*plane_prec_mult) * 4) / entries;
-
- entries = (clock / 1000) * 4; /* BPP is always 4 for cursor */
- *cursor_prec_mult = (entries 128) ?
- DRAIN_LATENCY_PRECISION_64 : DRAIN_LATENCY_PRECISION_32;
- *cursor_dl = (64 * (*cursor_prec_mult) * 4) / entries;
+ *prec_mult = (entries 128) ? DRAIN_LATENCY_PRECISION_64 :
+ DRAIN_LATENCY_PRECISION_32;
+ *drain_latency = (64 * (*prec_mult) * 4) / entries;
return true;
}
@@ -1318,24 +1309,46 @@ static bool vlv_compute_drain_latency(struct drm_device
*dev,
static void vlv_update_drain_latency(struct drm_crtc *crtc)
{
- struct drm_device *dev = crtc-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- enum pipe pipe = to_intel_crtc(crtc)-pipe;
- int plane_prec, plane_dl;
- int cursor_prec, cursor_dl;
- int plane_prec_mult, cursor_prec_mult;
-
- if (vlv_compute_drain_latency(dev, pipe, plane_prec_mult, plane_dl,
- cursor_prec_mult, cursor_dl)) {
- cursor_prec = (cursor_prec_mult == DRAIN_LATENCY_PRECISION_64) ?
- DDL_CURSOR_PRECISION_64 : DDL_CURSOR_PRECISION_32;
- plane_prec = (plane_prec_mult == DRAIN_LATENCY_PRECISION_64) ?
- DDL_PLANE_PRECISION_64 : DDL_PLANE_PRECISION_32;
-
- I915_WRITE(VLV_DDL(pipe), cursor_prec |
- (cursor_dl DDL_CURSOR_SHIFT) |
- plane_prec | (plane_dl DDL_PLANE_SHIFT));
+ struct drm_i915_private *dev_priv = crtc-dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pixel_size;
+ int drain_latency;
+ enum pipe pipe = intel_crtc-pipe;
+ int plane_prec, prec_mult, plane_dl;
+
+ plane_dl = I915_READ(VLV_DDL(pipe)) ~(DDL_PLANE_PRECISION_64 |
+ DRAIN_LATENCY_MASK | DDL_CURSOR_PRECISION_64 |
+ (DRAIN_LATENCY_MASK DDL_CURSOR_SHIFT));
+
+ if (!intel_crtc_active(crtc)) {
+ I915_WRITE(VLV_DDL(pipe), plane_dl);
+ return;
+ }
+
+ /* Primary plane Drain Latency */
+ pixel_size =
Re: [Intel-gfx] [PATCH 04/15] drm/i915: honour forced connector modes
On Tue, 5 Aug 2014 07:51:15 -0700
Rodrigo Vivi rodrigo.v...@intel.com wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
In the move over to use BIOS connector configs, we lost the ability to
force a specific set of connectors on or off. Try to remedy that by
dropping back to the old behavior if we detect a hard coded connector
config that tries to enable a connector (disabling is easy!).
Based on earlier patches by Jesse Barnes.
v2: Remove Jesse's patch
Reported-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_fbdev.c | 33 -
1 file changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index f475414..5d879d18 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -331,24 +331,6 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
int num_connectors_enabled = 0;
int num_connectors_detected = 0;
- /*
- * If the user specified any force options, just bail here
- * and use that config.
- */
- for (i = 0; i fb_helper-connector_count; i++) {
- struct drm_fb_helper_connector *fb_conn;
- struct drm_connector *connector;
-
- fb_conn = fb_helper-connector_info[i];
- connector = fb_conn-connector;
-
- if (!enabled[i])
- continue;
-
- if (connector-force != DRM_FORCE_UNSPECIFIED)
- return false;
- }
-
save_enabled = kcalloc(dev-mode_config.num_connector, sizeof(bool),
GFP_KERNEL);
if (!save_enabled)
@@ -374,8 +356,18 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
continue;
}
+ if (connector-force == DRM_FORCE_OFF) {
+ DRM_DEBUG_KMS(connector %s is disabled by user,
skipping\n,
+ connector-name);
+ enabled[i] = false;
+ continue;
+ }
+
encoder = connector-encoder;
if (!encoder || WARN_ON(!encoder-crtc)) {
+ if (connector-force DRM_FORCE_OFF)
+ goto bail;
+
DRM_DEBUG_KMS(connector %s has no encoder or crtc,
skipping\n,
connector-name);
enabled[i] = false;
@@ -394,8 +386,7 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
for (j = 0; j fb_helper-connector_count; j++) {
if (crtcs[j] == new_crtc) {
DRM_DEBUG_KMS(fallback: cloned
configuration\n);
- fallback = true;
- goto out;
+ goto bail;
}
}
@@ -466,8 +457,8 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
fallback = true;
}
-out:
if (fallback) {
+bail:
DRM_DEBUG_KMS(Not using firmware configuration\n);
memcpy(enabled, save_enabled, dev-mode_config.num_connector);
kfree(save_enabled);
Could have sworn I'd already R-b'd this one, but maybe that was the
other one to read the force config earlier. Anyway:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Slice/Subslice/EU info via GETPARAM
On Wed, Aug 06, 2014 at 09:43:44AM -0500, Jeff McGee wrote: On Tue, Aug 05, 2014 at 04:50:16PM +0200, Daniel Vetter wrote: On Tue, Aug 5, 2014 at 4:03 PM, Jeff McGee jeff.mc...@intel.com wrote: Also, usual broken record request: I need open-source userspace using this (mesa, ddx, libva). -Daniel This is kind of chicken-and-egg problem that I haven't been through. I assume that we build new interfaces up the stack (kernel-libdrm-usermode). Any tips or docs on how to proceed? You need to have the full thing ready with kernel, igt, libdrm, and umd driver patches (and maybe even testcases for the new umd feature, e.g. for some of the arb robustness stuff we've done). Then you post them all to relevant mailing lists and go through the review process for all parts. Once that's done and _all_ parts are reviewed, merging starts with kernel+igt, then libdrm + libdrm release, then umd. -Daniel Thanks Daniel. Is it acceptable to get the kernel part merged with only an igt test (technically an open-source userspace component)? I think probably not, but have to ask. Not really. The entire idea behind this is that only once we have the full stack picture available we can properly assess whether the interface fullfills the goal. That requires an actual implementation of the feature for the entire stack. And Dave Airlie (as the drm upstream maintainer) requires that that entire pile is open-source. So we really don't have wiggle room here. And personally I don't want to open the opportunity for discussions for each specific feature on whether a bare-bones demonstration test in igt is good enough or not, it really should be something shippable to users. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Generalize drain latency computation
On Thu, Aug 07, 2014 at 01:58:24AM +0530, Gajanan Bhat wrote:
Modify drain latency computation to use it for any plane. Same function can be
used for primary, cursor and sprite planes.
v2: Adressed review comments by Imre and Ville.
- Moved clock round up in separate patch
- Added WARN check for clock and pixel size
- Simplified bit masking
- Use cursor_base instead of reg read
v3: Changed to bitwise shorthand operator for plane_dl assignment.
Signed-off-by: Gajanan Bhat gajanan.b...@intel.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 87
++-
2 files changed, 51 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 187f862..08916df 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4009,6 +4009,7 @@ enum punit_power_well {
#define DDL_PLANE_PRECISION_64 (17)
#define DDL_PLANE_PRECISION_32 (07)
#define DDL_PLANE_SHIFT 0
+#define DRAIN_LATENCY_MASK 0x7f
/* FIFO watermark sizes etc */
#define G4X_FIFO_LINE_SIZE 64
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ba8dfeb..cabea4b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1277,33 +1277,24 @@ static bool g4x_compute_srwm(struct drm_device *dev,
display, cursor);
}
-static bool vlv_compute_drain_latency(struct drm_device *dev,
- int plane,
- int *plane_prec_mult,
- int *plane_dl,
- int *cursor_prec_mult,
- int *cursor_dl)
+static bool vlv_compute_drain_latency(struct drm_crtc *crtc,
+ int pixel_size,
+ int *prec_mult,
+ int *drain_latency)
{
- struct drm_crtc *crtc;
- int clock, pixel_size;
int entries;
+ int clock = to_intel_crtc(crtc)-config.adjusted_mode.crtc_clock;
- crtc = intel_get_crtc_for_plane(dev, plane);
- if (!intel_crtc_active(crtc))
+ if (WARN(clock == 0, Pixel clock is zero!\n))
return false;
- clock = to_intel_crtc(crtc)-config.adjusted_mode.crtc_clock;
- pixel_size = crtc-primary-fb-bits_per_pixel / 8; /* BPP */
+ if (WARN(pixel_size == 0, Pixel size is zero!\n))
+ return false;
entries = (clock / 1000) * pixel_size;
- *plane_prec_mult = (entries 128) ?
- DRAIN_LATENCY_PRECISION_64 : DRAIN_LATENCY_PRECISION_32;
- *plane_dl = (64 * (*plane_prec_mult) * 4) / entries;
-
- entries = (clock / 1000) * 4; /* BPP is always 4 for cursor */
- *cursor_prec_mult = (entries 128) ?
- DRAIN_LATENCY_PRECISION_64 : DRAIN_LATENCY_PRECISION_32;
- *cursor_dl = (64 * (*cursor_prec_mult) * 4) / entries;
+ *prec_mult = (entries 128) ? DRAIN_LATENCY_PRECISION_64 :
+DRAIN_LATENCY_PRECISION_32;
+ *drain_latency = (64 * (*prec_mult) * 4) / entries;
return true;
}
@@ -1318,24 +1309,46 @@ static bool vlv_compute_drain_latency(struct
drm_device *dev,
static void vlv_update_drain_latency(struct drm_crtc *crtc)
{
- struct drm_device *dev = crtc-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- enum pipe pipe = to_intel_crtc(crtc)-pipe;
- int plane_prec, plane_dl;
- int cursor_prec, cursor_dl;
- int plane_prec_mult, cursor_prec_mult;
-
- if (vlv_compute_drain_latency(dev, pipe, plane_prec_mult, plane_dl,
- cursor_prec_mult, cursor_dl)) {
- cursor_prec = (cursor_prec_mult == DRAIN_LATENCY_PRECISION_64) ?
- DDL_CURSOR_PRECISION_64 : DDL_CURSOR_PRECISION_32;
- plane_prec = (plane_prec_mult == DRAIN_LATENCY_PRECISION_64) ?
- DDL_PLANE_PRECISION_64 : DDL_PLANE_PRECISION_32;
-
- I915_WRITE(VLV_DDL(pipe), cursor_prec |
-(cursor_dl DDL_CURSOR_SHIFT) |
-plane_prec | (plane_dl DDL_PLANE_SHIFT));
+ struct drm_i915_private *dev_priv = crtc-dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pixel_size;
+ int drain_latency;
+ enum pipe pipe = intel_crtc-pipe;
+ int plane_prec, prec_mult, plane_dl;
+
+ plane_dl = I915_READ(VLV_DDL(pipe)) ~(DDL_PLANE_PRECISION_64 |
+DRAIN_LATENCY_MASK | DDL_CURSOR_PRECISION_64 |
+(DRAIN_LATENCY_MASK DDL_CURSOR_SHIFT));
+
+ if (!intel_crtc_active(crtc)) {
+
Re: [Intel-gfx] [PATCH v2 i-g-t] lib/chv: CHV media pipeline command sequence
On Wed, Aug 06, 2014 at 10:30:50AM +0800, Xiang, Haihao wrote:
Enable gem_media_fill test for CHV platform. In addition to differences in
media IP blocks from Broadwell, the command sequence also differs for
programming the media pipeline, e.g., should not send a MEDIA_STATE_FLUSH
right before the MI_BATCH_BUFFER_END of batch buffers using MEDIA_OBJECT.
Uses explicit IS_BROADWELL / IS_CHERRYVIEW to distinguish in gen8 media
fill handling.
Signed-off-by: Sean V Kelley sean.v.kel...@intel.com
---
lib/Makefile.sources| 1 +
lib/intel_batchbuffer.c | 4 +-
lib/media_fill.h| 7 +
lib/media_fill_gen8lp.c | 370
4 files changed, 381 insertions(+), 1 deletion(-)
create mode 100644 lib/media_fill_gen8lp.c
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index aa9a130..242d2e0 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -25,6 +25,7 @@ libintel_tools_la_SOURCES = \
media_fill.h\
media_fill_gen7.c \
media_fill_gen8.c \
+ media_fill_gen8lp.c \
gen7_media.h\
gen8_media.h\
rendercopy_i915.c \
diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
index e868922..2c253d5 100644
--- a/lib/intel_batchbuffer.c
+++ b/lib/intel_batchbuffer.c
@@ -460,10 +460,12 @@ igt_media_fillfunc_t igt_get_media_fillfunc(int devid)
{
igt_media_fillfunc_t fill = NULL;
- if (IS_GEN8(devid))
+ if (IS_BROADWELL(devid))
fill = gen8_media_fillfunc;
else if (IS_GEN7(devid))
fill = gen7_media_fillfunc;
+ else if (IS_CHERRYVIEW(devid))
+ fill = gen8lp_media_fillfunc;
return fill;
}
diff --git a/lib/media_fill.h b/lib/media_fill.h
index d417c75..ca35aeb 100644
--- a/lib/media_fill.h
+++ b/lib/media_fill.h
@@ -18,4 +18,11 @@ gen7_media_fillfunc(struct intel_batchbuffer *batch,
unsigned width, unsigned height,
uint8_t color);
+void
+gen8lp_media_fillfunc(struct intel_batchbuffer *batch,
+ struct igt_buf *dst,
+ unsigned x, unsigned y,
+ unsigned width, unsigned height,
+ uint8_t color);
+
#endif /* RENDE_MEDIA_FILL_H */
diff --git a/lib/media_fill_gen8lp.c b/lib/media_fill_gen8lp.c
new file mode 100644
index 000..74dc573
--- /dev/null
+++ b/lib/media_fill_gen8lp.c
@@ -0,0 +1,370 @@
+#include intel_bufmgr.h
+#include i915_drm.h
+
+#include media_fill.h
+#include gen8_media.h
+#include intel_reg.h
+#include drmtest.h
+
+#include assert.h
+
+
+static const uint32_t media_kernel[][4] = {
+ { 0x0041, 0x20202288, 0x0020, 0x },
+ { 0x0061, 0x20800208, 0x008d, 0x },
+ { 0x0021, 0x20800208, 0x00450040, 0x },
+ { 0x0001, 0x20880608, 0x, 0x000f000f },
+ { 0x0081, 0x20a00208, 0x0020, 0x },
+ { 0x0081, 0x20e00208, 0x0020, 0x },
+ { 0x0081, 0x21200208, 0x0020, 0x },
+ { 0x0081, 0x21600208, 0x0020, 0x },
+ { 0x0c800031, 0x24000a40, 0x0e80, 0x120a8000 },
+ { 0x0061, 0x2e000208, 0x008d, 0x },
+ { 0x07800031, 0x2a40, 0x0e000e00, 0x8210 },
+};
+
+static uint32_t
+batch_used(struct intel_batchbuffer *batch)
+{
+ return batch-ptr - batch-buffer;
+}
+
+static uint32_t
+batch_align(struct intel_batchbuffer *batch, uint32_t align)
+{
+ uint32_t offset = batch_used(batch);
+ offset = ALIGN(offset, align);
+ batch-ptr = batch-buffer + offset;
+ return offset;
+}
+
+static void *
+batch_alloc(struct intel_batchbuffer *batch, uint32_t size, uint32_t align)
+{
+ uint32_t offset = batch_align(batch, align);
+ batch-ptr += size;
+ return memset(batch-buffer + offset, 0, size);
+}
+
+static uint32_t
+batch_offset(struct intel_batchbuffer *batch, void *ptr)
+{
+ return (uint8_t *)ptr - batch-buffer;
+}
+
+static uint32_t
+batch_copy(struct intel_batchbuffer *batch, const void *ptr, uint32_t
size, uint32_t align)
+{
+ return batch_offset(batch, memcpy(batch_alloc(batch, size, align), ptr,
size));
+}
+
+static void
+gen8_render_flush(struct intel_batchbuffer *batch, uint32_t batch_end)
+{
+ int ret;
+
+ ret = drm_intel_bo_subdata(batch-bo, 0, 4096, batch-buffer);
+ if (ret == 0)
+ ret = drm_intel_bo_mrb_exec(batch-bo, batch_end,
+ NULL, 0, 0, 0);
+ assert(ret == 0);
+}
+
+static uint32_t
+gen8_fill_curbe_buffer_data(struct intel_batchbuffer *batch,
+ uint8_t color)
+{
+ uint8_t *curbe_buffer;
+ uint32_t offset;
+
+ curbe_buffer = batch_alloc(batch, sizeof(uint32_t) * 8, 64);
+ offset =
Re: [Intel-gfx] [PATCH v2] drm/i915: Rework GPU reset sequence to match driver load thaw
Hi,
alistair.mcau...@intel.com writes:
From: McAulay, Alistair alistair.mcau...@intel.com
This patch is to address Daniels concerns over different code during reset:
http://lists.freedesktop.org/archives/intel-gfx/2014-June/047758.html
The reason for aiming as hard as possible to use the exact same code for
driver load, gpu reset and runtime pm/system resume is that we've simply
seen too many bugs due to slight variations and unintended omissions.
Tested using igt drv_hangman.
V2: Cleaner way of preventing check_wedge returning -EAGAIN
Signed-off-by: McAulay, Alistair alistair.mcau...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/i915_gem.c | 6 +--
drivers/gpu/drm/i915/i915_gem_context.c | 42 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 67
+
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +-
6 files changed, 23 insertions(+), 104 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5e4fefd..3bfafe6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -806,7 +806,13 @@ int i915_reset(struct drm_device *dev)
!dev_priv-ums.mm_suspended) {
dev_priv-ums.mm_suspended = 0;
+ /* Used to prevent gem_check_wedged returning -EAGAIN during
gpu reset */
+ dev_priv-gpu_error.reload_in_reset = true;
+
ret = i915_gem_init_hw(dev);
+
+ dev_priv-gpu_error.reload_in_reset = false;
+
mutex_unlock(dev-struct_mutex);
if (ret) {
DRM_ERROR(Failed hw init on reset %d\n, ret);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 991b663..116daff 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1217,6 +1217,9 @@ struct i915_gpu_error {
/* For missed irq/seqno simulation. */
unsigned int test_irq_rings;
+
+ /* Used to prevent gem_check_wedged returning -EAGAIN during gpu reset
*/
+ bool reload_in_reset;
};
enum modeset_restore {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ef047bc..14e1770 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1085,7 +1085,9 @@ i915_gem_check_wedge(struct i915_gpu_error *error,
if (i915_terminally_wedged(error))
return -EIO;
- return -EAGAIN;
+ /* Check if GPU Reset is in progress */
+ if (!error-reload_in_reset)
+ return -EAGAIN;
}
return 0;
@@ -2590,8 +2592,6 @@ void i915_gem_reset(struct drm_device *dev)
for_each_ring(ring, dev_priv, i)
i915_gem_reset_ring_cleanup(dev_priv, ring);
- i915_gem_context_reset(dev);
-
i915_gem_restore_fences(dev);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index de72a28..d96219f 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -372,42 +372,6 @@ err_destroy:
return ERR_PTR(ret);
}
-void i915_gem_context_reset(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
- int i;
-
- /* Prevent the hardware from restoring the last context (which hung) on
- * the next switch */
- for (i = 0; i I915_NUM_RINGS; i++) {
- struct intel_engine_cs *ring = dev_priv-ring[i];
- struct intel_context *dctx = ring-default_context;
- struct intel_context *lctx = ring-last_context;
-
- /* Do a fake switch to the default context */
- if (lctx == dctx)
- continue;
-
- if (!lctx)
- continue;
-
- if (dctx-legacy_hw_ctx.rcs_state i == RCS) {
-
WARN_ON(i915_gem_obj_ggtt_pin(dctx-legacy_hw_ctx.rcs_state,
-
get_context_alignment(dev), 0));
- /* Fake a finish/inactive */
- dctx-legacy_hw_ctx.rcs_state-base.write_domain = 0;
- dctx-legacy_hw_ctx.rcs_state-active = 0;
- }
-
- if (lctx-legacy_hw_ctx.rcs_state i == RCS)
-
i915_gem_object_ggtt_unpin(lctx-legacy_hw_ctx.rcs_state);
-
- i915_gem_context_unreference(lctx);
- i915_gem_context_reference(dctx);
- ring-last_context = dctx;
- }
-}
-
I am with Daniel on this one. I don't understand how can we throw
everything in here away.
We need to force hw to switch to a working context, after reset,
so that our internal state tracking matches.
Further, if we
Re: [Intel-gfx] [PATCH] drm: Don't grab an fb reference for the idr
On Wed, Aug 6, 2014 at 10:07 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Aug 06, 2014 at 09:12:42AM -0400, Rob Clark wrote:
On Wed, Aug 6, 2014 at 8:37 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark wrote:
On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
The current refcounting scheme is that the fb lookup idr also holds a
reference. This works out nicely bacause thus far we've always
explicitly cleaned up idr entries for framebuffers:
- Userspace fbs get removed in the rmfb ioctl or when the drm file
gets closed.
- Kernel fbs (for fbdev emulation) get cleaned up by the driver code
at module unload time.
But now i915 also reconstructs the bios fbs for a smooth transition.
And that fb is purely transitional and should get removed immmediately
once all crtcs stop using it. Of course if the i915 fbdev code decides
to reuse it as the main fbdev fb then it shouldn't be cleaned up, but
in that case the fbdev code will grab it's own reference.
The problem is now that we also want to register that takeover fb in
the idr, so that userspace can do a smooth transition (animated maybe
even!) itself. But currently we have no one who will clean up the idr
reference once that fb isn't useful any more, and so essentially leak
it.
ewww.. couldn't you do some scheme on lastclose to check if no more
crtc's are scanning out that fb, and if not then remove the idr?
There's no natural point really but when we drop the last reference for
it. Going the weak reference route looked the most natural. And I honestly
expect other drivers to eventually do the same - forcing a modeset on
boot-up is kinda not too pretty, and permanently reserving a big
framebuffer just for the bios doesn't sound good either. This approach
would nicely solve it for everyone.
hmm, maybe somebody switched my coffee with decaf, but why isn't
lastclose a natural point?
There is no lastclose for the bios ;-)
Let me elaborate on what happens:
1. BIOS sets up an initial config with a framebuffer in stolen.
2. i915 takes over and reconstructs all the state, so now we have all the
crtcs enabled using a framebuffer for all of them which wraps the bios
allocation.
2b. (optional) reuse that framebuffer for fbdev.
- That special bios fb has the following references:
- 1 reference for each crtc that's using it
- 1 optional reference if it's reused as the fbdev fb
- 1 reference for the idr
3. Userspace takes over, potentially doing a getfb on the current
(bios-inherited) fb for smooth transition, but then does a modeset to its
own fb.
- After this all the we've dropped the crtc references and we also want
to drop the idr reference (since no one will ever use this framebuffer
again). But there's simply no good place to do that. Lastclose might only
happen before we shut down the system again, which is a bit too late.
Well, you could still cleanup your idr reference on current
userspace's lastclose.. that doesn't do much good, I suppose, if
current userspace never exits. But if first userspace is plymouth or
something like that, you would get cleaned up on the
splash-{x11/wayland} transition..
if that isn't sufficient, then yeah I guess the more fancy weak-ref
stuff needed..
BR,
-R
Note that the getfb call creates a gem handle for the fb object, so the
backing storage might survive for a lot longer than the fb.
ofc if that really doesn't work, the weak-ref thing seems like it
would solve it nicely. But if there were a simple solution that
didn't involve making fb refcnting more complex, I guess I would
prefer that
Well I didn't come up with anything else really. Plan b would be to add
hooks after any plane updates and manually check whether that special fb
has lost all but its idr reference, and if so clean it up. That seems to
be a lot more fragile and convoluted than converting the idr to a weak
reference.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Initialize the aliasing ppgtt as part of global gtt
Stuffing this into the context setup code doesn't make a lot of sense.
Also reusing the real ppgtt setup code makes even less sense since the
aliasing ppgtt isn't a real address space. Leaving all that stuff
unitialized will make sure that we catch any abusers promptly.
This is also a prep work to clean up the context-ppgtt link.
v2: Fix up the logic fail, I've fumbled it so badly to completely
disable ppgtt on gen6. Spotted by Ville and Michel. Also move around
the pde write into the gen6 init function, since otherwise it won't
work at all.
v3: Only initialize the aliasing ppgtt when we actually enable it.
Cc: Thierry, Michel michel.thie...@intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_context.c | 13 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 42 +++--
2 files changed, 31 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 4af5f05b24e8..07f4d060575b 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -276,17 +276,6 @@ i915_gem_create_context(struct drm_device *dev,
goto err_unpin;
} else
ctx-vm = ppgtt-base;
-
- /* This case is reserved for the global default context and
-* should only happen once. */
- if (is_global_default_ctx) {
- if (WARN_ON(dev_priv-mm.aliasing_ppgtt)) {
- ret = -EEXIST;
- goto err_unpin;
- }
-
- dev_priv-mm.aliasing_ppgtt = ppgtt;
- }
} else if (USES_PPGTT(dev)) {
/* For platforms which only have aliasing PPGTT, we fake the
* address space and refcounting. */
@@ -361,7 +350,7 @@ int i915_gem_context_init(struct drm_device *dev)
}
}
- ctx = i915_gem_create_context(dev, NULL, USES_PPGTT(dev));
+ ctx = i915_gem_create_context(dev, NULL, USES_FULL_PPGTT(dev));
if (IS_ERR(ctx)) {
DRM_ERROR(Failed to create default global context (error
%ld)\n,
PTR_ERR(ctx));
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index bf70ab44b968..653a1166a3fa 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1141,35 +1141,38 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
ppgtt-node.size 20,
ppgtt-node.start / PAGE_SIZE);
+ gen6_write_pdes(ppgtt);
+ DRM_DEBUG(Adding PPGTT at offset %x\n,
+ ppgtt-pd_offset 10);
+
return 0;
}
-int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
+int __hw_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- int ret = 0;
ppgtt-base.dev = dev;
ppgtt-base.scratch = dev_priv-gtt.base.scratch;
if (INTEL_INFO(dev)-gen 8)
- ret = gen6_ppgtt_init(ppgtt);
+ return gen6_ppgtt_init(ppgtt);
else if (IS_GEN8(dev))
- ret = gen8_ppgtt_init(ppgtt, dev_priv-gtt.base.total);
+ return gen8_ppgtt_init(ppgtt, dev_priv-gtt.base.total);
else
BUG();
+}
+int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int ret = 0;
- if (!ret) {
- struct drm_i915_private *dev_priv = dev-dev_private;
+ ret = __hw_ppgtt_init(dev, ppgtt);
+ if (ret == 0) {
kref_init(ppgtt-ref);
drm_mm_init(ppgtt-base.mm, ppgtt-base.start,
ppgtt-base.total);
i915_init_vm(dev_priv, ppgtt-base);
- if (INTEL_INFO(dev)-gen 8) {
- gen6_write_pdes(ppgtt);
- DRM_DEBUG(Adding PPGTT at offset %x\n,
- ppgtt-pd_offset 10);
- }
}
return ret;
@@ -1710,6 +1713,7 @@ int i915_gem_setup_global_gtt(struct drm_device *dev,
struct drm_mm_node *entry;
struct drm_i915_gem_object *obj;
unsigned long hole_start, hole_end;
+ int ret;
BUG_ON(mappable_end end);
@@ -1721,7 +1725,7 @@ int i915_gem_setup_global_gtt(struct drm_device *dev,
/* Mark any preallocated objects as occupied */
list_for_each_entry(obj, dev_priv-mm.bound_list, global_list) {
struct i915_vma *vma = i915_gem_obj_to_vma(obj, ggtt_vm);
- int ret;
+
DRM_DEBUG_KMS(reserving preallocated space: %lx + %zx\n,
