Re: [Intel-gfx] [PATCH] drm/i915: WA: FBC Render Nuke.
On Mon, Jun 03, 2013 at 03:41:49PM -0300, Rodrigo Vivi wrote:
WaFbcNukeOn3DBlt for IVB, HSW.
According BSPec: Workaround: Do not enable Render Command Streamer tracking
for FBC.
Instead insert a LRI to address 0x50380 with data 0x0004 after the
PIPE_CONTROL that
follows each render submission.
v2: Chris noticed that flush_domains check was missing here and also
suggested to do
LRI only when fbc is enabled. To avoid do a I915_READ on every flush lets
use the
module parameter check.
v3: Adding Wa name as Damien suggested.
v4: Ville noticed VLV doesn't support fbc at all and comment came wrong from
spec.
v5: Ville noticed than on blt a Cache Clean LRI should be used instead the
Nuke one.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 32
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cc4c223..f37ddee 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -977,6 +977,9 @@
/* Framebuffer compression for Ivybridge */
#define IVB_FBC_RT_BASE 0x7020
+#define MSG_FBC_REND_STATE 0x50380
+#define FBC_REND_NUKE (12)
+#define FBC_REND_CACHE_CLEAN (11)
#define _HSW_PIPE_SLICE_CHICKEN_1_A 0x420B0
#define _HSW_PIPE_SLICE_CHICKEN_1_B 0x420B4
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1879188..e830a9b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -274,7 +274,7 @@ static void gen7_enable_fbc(struct drm_crtc *crtc,
unsigned long interval)
struct drm_i915_gem_object *obj = intel_fb-obj;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- I915_WRITE(IVB_FBC_RT_BASE, obj-gtt_offset | ILK_FBC_RT_VALID);
+ I915_WRITE(IVB_FBC_RT_BASE, obj-gtt_offset);
if (!intel_edp_is_psr_enabled(dev))
I915_WRITE(ILK_DPFC_CONTROL, DPFC_CTL_EN | DPFC_CTL_LIMIT_1X |
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 3d2c236..3e24639 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -280,6 +280,30 @@ gen7_render_ring_cs_stall_wa(struct intel_ring_buffer
*ring)
return 0;
}
+static int gen7_ring_fbc_flush(struct intel_ring_buffer *ring, bool nuke)
+{
+ struct drm_device *dev = ring-dev;
+ int ret;
+
+ if (i915_enable_fbc == 0)
+ return 0;
+
+ if (i915_enable_fbc 0 !IS_HASWELL(dev))
+ return 0;
+
+ ret = intel_ring_begin(ring, 4);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_NOOP);
+ /* WaFbcNukeOn3DBlt:ivb/hsw */
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, MSG_FBC_REND_STATE);
+ intel_ring_emit(ring, nuke ? FBC_REND_NUKE : FBC_REND_CACHE_CLEAN);
+ intel_ring_advance(ring);
+
+ return 0;
+}
+
static int
gen7_render_ring_flush(struct intel_ring_buffer *ring,
u32 invalidate_domains, u32 flush_domains)
@@ -336,6 +360,9 @@ gen7_render_ring_flush(struct intel_ring_buffer *ring,
intel_ring_emit(ring, 0);
intel_ring_advance(ring);
+ if (flush_domains)
+ return gen7_ring_fbc_flush(ring, true);
+
return 0;
}
@@ -1623,6 +1650,7 @@ gen6_ring_dispatch_execbuffer(struct intel_ring_buffer
*ring,
static int blt_ring_flush(struct intel_ring_buffer *ring,
u32 invalidate, u32 flush)
{
+ struct drm_device *dev = ring-dev;
uint32_t cmd;
int ret;
@@ -1645,6 +1673,10 @@ static int blt_ring_flush(struct intel_ring_buffer
*ring,
intel_ring_emit(ring, 0);
intel_ring_emit(ring, MI_NOOP);
intel_ring_advance(ring);
+
+ if (IS_GEN7(dev))
+ return gen7_ring_fbc_flush(ring, false);
Still no flush_domains check?
Oh and looks like you need to rebase the patch since these functions
got renamed.
+
return 0;
}
--
1.7.11.7
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Add kernel-doc for plane functions
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_crtc.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f00ba75..f1f11e1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -795,6 +795,21 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
}
EXPORT_SYMBOL(drm_encoder_cleanup);
+/**
+ * drm_plane_init - Initialise a new plane object
+ * @dev: DRM device
+ * @plane: plane object to init
+ * @possible_crtcs: bitmask of possible CRTCs
+ * @funcs: callbacks for the new plane
+ * @formats: array of supported formats (%DRM_FORMAT_*)
+ * @format_count: number of elements in @formats
+ * @priv: plane is private (hidden from userspace)?
+ *
+ * Inits a new object created as base part of an driver plane object.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure.
+ */
int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
unsigned long possible_crtcs,
const struct drm_plane_funcs *funcs,
@@ -843,6 +858,13 @@ int drm_plane_init(struct drm_device *dev, struct
drm_plane *plane,
}
EXPORT_SYMBOL(drm_plane_init);
+/**
+ * drm_plane_cleanup - Cleans up the core plane usage.
+ * @plane: plane to cleanup
+ *
+ * Cleanup @plane. Removes from drm modesetting space
+ * does NOT free object, caller does that.
+ */
void drm_plane_cleanup(struct drm_plane *plane)
{
struct drm_device *dev = plane-dev;
@@ -859,6 +881,15 @@ void drm_plane_cleanup(struct drm_plane *plane)
}
EXPORT_SYMBOL(drm_plane_cleanup);
+/**
+ * drm_plane_force_disable - Forcibly disable a plane
+ * @plane: plane to disable
+ *
+ * Forces the plane to be disabled.
+ *
+ * Used when the plane's current framebuffer is destroyed,
+ * and when restoring fbdev mode.
+ */
void drm_plane_force_disable(struct drm_plane *plane)
{
int ret;
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: WA: FBC Render Nuke.
On Tue, Jun 04, 2013 at 10:06:08AM +0300, Ville Syrjälä wrote: On Mon, Jun 03, 2013 at 03:41:49PM -0300, Rodrigo Vivi wrote: + if (IS_GEN7(dev)) + return gen7_ring_fbc_flush(ring, false); Still no flush_domains check? And if we are being picky, not using the fbc_dirty flag either. Also pass the dword to gen7_ring_fbc_flush() rather than bool nuke, as it is more descriptive and flexible. -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 3/3] drm/fb-helper: Disable cursors and planes when restoring fbdev mode
On Mon, Jun 03, 2013 at 04:10:42PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Cursors and plane can obscure whatever fbdev wants to show the user.
Disable them all in drm_fb_helper_restore_fbdev_mode.
After the cursors and planes have been disabled, user space needs to
explicitly re-enable them to make them visible again.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Yeah, I like that color ;-) For the series:
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_fb_helper.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0df0ebb..3d13ca6e2 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -287,13 +287,27 @@ EXPORT_SYMBOL(drm_fb_helper_debug_leave);
*/
bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper *fb_helper)
{
+ struct drm_device *dev = fb_helper-dev;
+ struct drm_plane *plane;
bool error = false;
- int i, ret;
+ int i;
+
+ drm_warn_on_modeset_not_all_locked(dev);
- drm_warn_on_modeset_not_all_locked(fb_helper-dev);
+ list_for_each_entry(plane, dev-mode_config.plane_list, head)
+ drm_plane_force_disable(plane);
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;
+ int ret;
+
+ if (crtc-funcs-cursor_set) {
+ ret = crtc-funcs-cursor_set(crtc, NULL, 0, 0, 0);
+ if (ret)
+ error = true;
+ }
+
ret = drm_mode_set_config_internal(mode_set);
if (ret)
error = true;
--
1.8.1.5
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 2/2] drm: Remove some unused stuff from drm_plane
On Mon, Jun 03, 2013 at 04:11:42PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
There's a bunch of unused members inside drm_plane, bloating the size of
the structure needlessly. Eliminate them.
v2: Remove all of it from kernel-doc too
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Yeah, makes sense to ditch this. We can think about this again when atomic
modeset and plane properties pop up again. For both patches:
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 2 +-
include/drm/drm_crtc.h | 11 ---
2 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 865ebfe..f00ba75 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1749,7 +1749,7 @@ int drm_mode_getplane(struct drm_device *dev, void
*data,
plane_resp-plane_id = plane-base.id;
plane_resp-possible_crtcs = plane-possible_crtcs;
- plane_resp-gamma_size = plane-gamma_size;
+ plane_resp-gamma_size = 0;
/*
* This ioctl is called twice, once to determine how much space is
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index db7a885..3c14b46 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -654,11 +654,7 @@ struct drm_plane_funcs {
* @format_count: number of formats supported
* @crtc: currently bound CRTC
* @fb: currently bound fb
- * @gamma_size: size of gamma table
- * @gamma_store: gamma correction table
- * @enabled: enabled flag
* @funcs: helper functions
- * @helper_private: storage for drver layer
* @properties: property tracking for this plane
*/
struct drm_plane {
@@ -674,14 +670,7 @@ struct drm_plane {
struct drm_crtc *crtc;
struct drm_framebuffer *fb;
- /* CRTC gamma size for reporting to userspace */
- uint32_t gamma_size;
- uint16_t *gamma_store;
-
- bool enabled;
-
const struct drm_plane_funcs *funcs;
- void *helper_private;
struct drm_object_properties properties;
};
--
1.8.1.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 1/3] drm/i915: rearrange vlv dp enable and pre_enable callbacks
Currently -pre_enable and -enable are called back to back. Rearrange
the DP callbacks to make it possible to move -enable call later.
Basically do everything in -pre_enable on VLV, and make -enable a NOP.
There should be no functional changes.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 67 ---
1 file changed, 35 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a899f93..543cb12 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1405,47 +1405,46 @@ static void intel_enable_dp(struct intel_encoder
*encoder)
intel_dp_complete_link_train(intel_dp);
intel_dp_stop_link_train(intel_dp);
ironlake_edp_backlight_on(intel_dp);
+}
- if (IS_VALLEYVIEW(dev)) {
- struct intel_digital_port *dport =
- enc_to_dig_port(encoder-base);
- int channel = vlv_dport_to_channel(dport);
-
- vlv_wait_port_ready(dev_priv, channel);
- }
+static void vlv_enable_dp(struct intel_encoder *encoder)
+{
}
static void intel_pre_enable_dp(struct intel_encoder *encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);
struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
+
+ if (dport-port == PORT_A)
+ ironlake_edp_pll_on(intel_dp);
+}
+
+static void vlv_pre_enable_dp(struct intel_encoder *encoder)
+{
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);
+ struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
struct drm_device *dev = encoder-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(encoder-base.crtc);
+ int port = vlv_dport_to_channel(dport);
+ int pipe = intel_crtc-pipe;
+ u32 val;
- if (dport-port == PORT_A !IS_VALLEYVIEW(dev))
- ironlake_edp_pll_on(intel_dp);
+ val = vlv_dpio_read(dev_priv, DPIO_DATA_LANE_A(port));
+ val = 0;
+ if (pipe)
+ val |= (121);
+ else
+ val = ~(121);
+ val |= 0x001000c4;
+ vlv_dpio_write(dev_priv, DPIO_DATA_CHANNEL(port), val);
+ vlv_dpio_write(dev_priv, DPIO_PCS_CLOCKBUF0(port), 0x00760018);
+ vlv_dpio_write(dev_priv, DPIO_PCS_CLOCKBUF8(port), 0x00400888);
- if (IS_VALLEYVIEW(dev)) {
- struct intel_crtc *intel_crtc =
- to_intel_crtc(encoder-base.crtc);
- int port = vlv_dport_to_channel(dport);
- int pipe = intel_crtc-pipe;
- u32 val;
-
- val = vlv_dpio_read(dev_priv, DPIO_DATA_LANE_A(port));
- val = 0;
- if (pipe)
- val |= (121);
- else
- val = ~(121);
- val |= 0x001000c4;
- vlv_dpio_write(dev_priv, DPIO_DATA_CHANNEL(port), val);
+ intel_enable_dp(encoder);
- vlv_dpio_write(dev_priv, DPIO_PCS_CLOCKBUF0(port),
-0x00760018);
- vlv_dpio_write(dev_priv, DPIO_PCS_CLOCKBUF8(port),
-0x00400888);
- }
+ vlv_wait_port_ready(dev_priv, port);
}
static void intel_dp_pre_pll_enable(struct intel_encoder *encoder)
@@ -3187,14 +3186,18 @@ intel_dp_init(struct drm_device *dev, int output_reg,
enum port port)
drm_encoder_helper_add(intel_encoder-base, intel_dp_helper_funcs);
intel_encoder-compute_config = intel_dp_compute_config;
- intel_encoder-enable = intel_enable_dp;
- intel_encoder-pre_enable = intel_pre_enable_dp;
intel_encoder-disable = intel_disable_dp;
intel_encoder-post_disable = intel_post_disable_dp;
intel_encoder-get_hw_state = intel_dp_get_hw_state;
intel_encoder-get_config = intel_dp_get_config;
- if (IS_VALLEYVIEW(dev))
+ if (IS_VALLEYVIEW(dev)) {
+ intel_encoder-enable = vlv_enable_dp;
+ intel_encoder-pre_enable = vlv_pre_enable_dp;
intel_encoder-pre_pll_enable = intel_dp_pre_pll_enable;
+ } else {
+ intel_encoder-enable = intel_enable_dp;
+ intel_encoder-pre_enable = intel_pre_enable_dp;
+ }
intel_dig_port-port = port;
intel_dig_port-dp.output_reg = output_reg;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: rearrange vlv hdmi enable and pre_enable callbacks
Currently -pre_enable and -enable are called back to back. Rearrange
the HDMI callbacks to make it possible to move -enable call later.
Basically do everything in -pre_enable on VLV, and make -enable a NOP.
There should be no functional changes.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_hdmi.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 8062a92..7e3a4f4 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -719,14 +719,10 @@ static void intel_enable_hdmi(struct intel_encoder
*encoder)
I915_WRITE(intel_hdmi-hdmi_reg, temp);
POSTING_READ(intel_hdmi-hdmi_reg);
}
+}
- if (IS_VALLEYVIEW(dev)) {
- struct intel_digital_port *dport =
- enc_to_dig_port(encoder-base);
- int channel = vlv_dport_to_channel(dport);
-
- vlv_wait_port_ready(dev_priv, channel);
- }
+static void vlv_enable_hdmi(struct intel_encoder *encoder)
+{
}
static void intel_disable_hdmi(struct intel_encoder *encoder)
@@ -1049,6 +1045,10 @@ static void intel_hdmi_pre_enable(struct intel_encoder
*encoder)
0x00760018);
vlv_dpio_write(dev_priv, DPIO_PCS_CLOCKBUF8(port),
0x00400888);
+
+ intel_enable_hdmi(encoder);
+
+ vlv_wait_port_ready(dev_priv, port);
}
static void intel_hdmi_pre_pll_enable(struct intel_encoder *encoder)
@@ -1231,14 +1231,16 @@ void intel_hdmi_init(struct drm_device *dev, int
hdmi_reg, enum port port)
drm_encoder_helper_add(intel_encoder-base, intel_hdmi_helper_funcs);
intel_encoder-compute_config = intel_hdmi_compute_config;
- intel_encoder-enable = intel_enable_hdmi;
intel_encoder-disable = intel_disable_hdmi;
intel_encoder-get_hw_state = intel_hdmi_get_hw_state;
intel_encoder-get_config = intel_hdmi_get_config;
if (IS_VALLEYVIEW(dev)) {
+ intel_encoder-enable = vlv_enable_hdmi;
intel_encoder-pre_enable = intel_hdmi_pre_enable;
intel_encoder-pre_pll_enable = intel_hdmi_pre_pll_enable;
intel_encoder-post_disable = intel_hdmi_post_disable;
+ } else {
+ intel_encoder-enable = intel_enable_hdmi;
}
intel_encoder-type = INTEL_OUTPUT_HDMI;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: move encoder-enable callback later in VLV crtc enable
Encoder -pre_enable and -enable callbacks were moved back to back in VLV crtc enable sequence, which is not very useful. Move -enable call at the end of the sequence. With the previously rearranged VLV DP and HDMI -pre_enable and -enable callbacks in place, this should not cause any functional changes. Signed-off-by: Jani Nikula jani.nik...@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 c112466..4250beb 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3607,10 +3607,6 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc) if (encoder-pre_enable) encoder-pre_enable(encoder); - /* VLV wants encoder enabling _before_ the pipe is up. */ - for_each_encoder_on_crtc(dev, crtc, encoder) - encoder-enable(encoder); - /* Enable panel fitting for eDP */ i9xx_pfit_enable(intel_crtc); @@ -3624,6 +3620,9 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc) intel_crtc_dpms_overlay(intel_crtc, true); intel_crtc_update_cursor(crtc, true); + for_each_encoder_on_crtc(dev, crtc, encoder) + encoder-enable(encoder); + mutex_unlock(dev_priv-dpio_lock); } -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: move encoder-enable callback later in VLV crtc enable
Failed to mention that this should address Daniel's complaints about the -pre_enable and -enable calls being in the same spot [1]. And while I needed this for something else, it should be easy to do the eDP backlight fix Daniel mentions on top. Cheers, Jani. [1] http://mid.gmane.org/cakmk7ufs9emvmw8bns24e5unm1d7jrfvg3sd5sdftveamgf...@mail.gmail.com On Tue, 04 Jun 2013, Jani Nikula jani.nik...@intel.com wrote: Encoder -pre_enable and -enable callbacks were moved back to back in VLV crtc enable sequence, which is not very useful. Move -enable call at the end of the sequence. With the previously rearranged VLV DP and HDMI -pre_enable and -enable callbacks in place, this should not cause any functional changes. Signed-off-by: Jani Nikula jani.nik...@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 c112466..4250beb 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3607,10 +3607,6 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc) if (encoder-pre_enable) encoder-pre_enable(encoder); - /* VLV wants encoder enabling _before_ the pipe is up. */ - for_each_encoder_on_crtc(dev, crtc, encoder) - encoder-enable(encoder); - /* Enable panel fitting for eDP */ i9xx_pfit_enable(intel_crtc); @@ -3624,6 +3620,9 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc) intel_crtc_dpms_overlay(intel_crtc, true); intel_crtc_update_cursor(crtc, true); + for_each_encoder_on_crtc(dev, crtc, encoder) + encoder-enable(encoder); + mutex_unlock(dev_priv-dpio_lock); } -- 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
[Intel-gfx] [PATCH 0/9] drm/i915: Unify some modeset sequences v2
Reposting the whole set for clarity. Changes from v1: - Rebasing due to other changes - Fixed sprite disable in ironlake_crtc_disable() - Improved some commit messages - More asserts ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/9] drm/i915: Always load the display palette before enabling the pipe
From: Ville Syrjälä ville.syrj...@linux.intel.com Loading the palette after the planes are enabled can risk showing incorrect colors. ILK+ already load the palette before even the pipe is enabled. Just follow the same order for gen2-4 and VLV. According to BSpec the requirements for palette access are display core clock and display PLL running. In certain platforms just the core clock may be enough. But we definitely should have both running when this gets called during the modeset. v2: Amend the commit message with some display PLL/core clock info Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index eda2262..c28b402 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3615,10 +3615,11 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc) /* Enable panel fitting for eDP */ i9xx_pfit_enable(intel_crtc); + intel_crtc_load_lut(crtc); + intel_enable_pipe(dev_priv, pipe, false); intel_enable_plane(dev_priv, plane, pipe); - intel_crtc_load_lut(crtc); intel_update_fbc(dev); /* Give the overlay scaler a chance to enable if it's on this pipe */ @@ -3654,12 +3655,13 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc) /* Enable panel fitting for LVDS */ i9xx_pfit_enable(intel_crtc); + intel_crtc_load_lut(crtc); + intel_enable_pipe(dev_priv, pipe, false); intel_enable_plane(dev_priv, plane, pipe); if (IS_G4X(dev)) g4x_fixup_plane(dev_priv, pipe); - intel_crtc_load_lut(crtc); intel_update_fbc(dev); /* Give the overlay scaler a chance to enable if it's on this pipe */ -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/9] drm/i915: Always enable the cursor right after the primary plane
From: Ville Syrjälä ville.syrj...@linux.intel.com Follow the same sequence when enabling the cursor plane during modeset. No point in doing this stuff in different order on different generations. This should also avoid a needless wait for vblank for the g4x cursor workaround when the cursor gets enabled anyway. Acked-by: Egbert Eich e...@suse.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index c28b402..c2e6e91 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3216,6 +3216,7 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc) intel_enable_pipe(dev_priv, pipe, intel_crtc-config.has_pch_encoder); intel_enable_plane(dev_priv, plane, pipe); + intel_crtc_update_cursor(crtc, true); if (intel_crtc-config.has_pch_encoder) ironlake_pch_enable(crtc); @@ -3224,8 +3225,6 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc) intel_update_fbc(dev); mutex_unlock(dev-struct_mutex); - intel_crtc_update_cursor(crtc, true); - for_each_encoder_on_crtc(dev, crtc, encoder) encoder-enable(encoder); @@ -3325,6 +3324,7 @@ static void haswell_crtc_enable(struct drm_crtc *crtc) intel_enable_pipe(dev_priv, pipe, intel_crtc-config.has_pch_encoder); intel_enable_plane(dev_priv, plane, pipe); + intel_crtc_update_cursor(crtc, true); hsw_enable_ips(intel_crtc); @@ -3335,8 +3335,6 @@ static void haswell_crtc_enable(struct drm_crtc *crtc) intel_update_fbc(dev); mutex_unlock(dev-struct_mutex); - intel_crtc_update_cursor(crtc, true); - for_each_encoder_on_crtc(dev, crtc, encoder) encoder-enable(encoder); @@ -3619,12 +3617,12 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc) intel_enable_pipe(dev_priv, pipe, false); intel_enable_plane(dev_priv, plane, pipe); + intel_crtc_update_cursor(crtc, true); intel_update_fbc(dev); /* Give the overlay scaler a chance to enable if it's on this pipe */ intel_crtc_dpms_overlay(intel_crtc, true); - intel_crtc_update_cursor(crtc, true); mutex_unlock(dev_priv-dpio_lock); } @@ -3659,6 +3657,7 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc) intel_enable_pipe(dev_priv, pipe, false); intel_enable_plane(dev_priv, plane, pipe); + intel_crtc_update_cursor(crtc, true); if (IS_G4X(dev)) g4x_fixup_plane(dev_priv, pipe); @@ -3666,7 +3665,6 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc) /* Give the overlay scaler a chance to enable if it's on this pipe */ intel_crtc_dpms_overlay(intel_crtc, true); - intel_crtc_update_cursor(crtc, true); for_each_encoder_on_crtc(dev, crtc, encoder) encoder-enable(encoder); -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/9] drm/i915: Enable the overlay right after primary and cursor planes
From: Ville Syrjälä ville.syrj...@linux.intel.com Again follow the same sequence for all generations, because doing otherwise just doesn't make sense. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index c2e6e91..05510f5 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3619,11 +3619,11 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc) intel_enable_plane(dev_priv, plane, pipe); intel_crtc_update_cursor(crtc, true); - intel_update_fbc(dev); - /* Give the overlay scaler a chance to enable if it's on this pipe */ intel_crtc_dpms_overlay(intel_crtc, true); + intel_update_fbc(dev); + mutex_unlock(dev_priv-dpio_lock); } @@ -3661,11 +3661,11 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc) if (IS_G4X(dev)) g4x_fixup_plane(dev_priv, pipe); - intel_update_fbc(dev); - /* Give the overlay scaler a chance to enable if it's on this pipe */ intel_crtc_dpms_overlay(intel_crtc, true); + intel_update_fbc(dev); + for_each_encoder_on_crtc(dev, crtc, encoder) encoder-enable(encoder); } -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/9] drm/i915: Drop overlay DPMS call from valleyview_crtc_enable
From: Ville Syrjälä ville.syrj...@linux.intel.com VLV doesn't have the old video overlay. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index dac2db7..61bee12 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3619,9 +3619,6 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc) intel_enable_plane(dev_priv, plane, pipe); intel_crtc_update_cursor(crtc, true); - /* Give the overlay scaler a chance to enable if it's on this pipe */ - intel_crtc_dpms_overlay(intel_crtc, true); - intel_update_fbc(dev); mutex_unlock(dev_priv-dpio_lock); -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/9] drm/i915: Follow the same sequence when disabling planes
From: Ville Syrjälä ville.syrj...@linux.intel.com First disable FBC, then IPS, then disable all planes, and finally disable the pipe. v2: Mention IPS in the commit message Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 05510f5..dac2db7 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3383,13 +3383,13 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc) intel_crtc_wait_for_pending_flips(crtc); drm_vblank_off(dev, pipe); - intel_crtc_update_cursor(crtc, false); - - intel_disable_plane(dev_priv, plane, pipe); if (dev_priv-cfb_plane == plane) intel_disable_fbc(dev); + intel_crtc_update_cursor(crtc, false); + intel_disable_plane(dev_priv, plane, pipe); + intel_set_pch_fifo_underrun_reporting(dev, pipe, false); intel_disable_pipe(dev_priv, pipe); @@ -3462,7 +3462,6 @@ static void haswell_crtc_disable(struct drm_crtc *crtc) intel_crtc_wait_for_pending_flips(crtc); drm_vblank_off(dev, pipe); - intel_crtc_update_cursor(crtc, false); /* FBC must be disabled before disabling the plane on HSW. */ if (dev_priv-cfb_plane == plane) @@ -3470,6 +3469,7 @@ static void haswell_crtc_disable(struct drm_crtc *crtc) hsw_disable_ips(intel_crtc); + intel_crtc_update_cursor(crtc, false); intel_disable_plane(dev_priv, plane, pipe); if (intel_crtc-config.has_pch_encoder) @@ -3703,13 +3703,14 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc) /* Give the overlay scaler a chance to disable if it's on this pipe */ intel_crtc_wait_for_pending_flips(crtc); drm_vblank_off(dev, pipe); - intel_crtc_dpms_overlay(intel_crtc, false); - intel_crtc_update_cursor(crtc, false); if (dev_priv-cfb_plane == plane) intel_disable_fbc(dev); + intel_crtc_dpms_overlay(intel_crtc, false); + intel_crtc_update_cursor(crtc, false); intel_disable_plane(dev_priv, plane, pipe); + intel_disable_pipe(dev_priv, pipe); i9xx_pfit_disable(intel_crtc); -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/9] drm/i915: Disable/restore all sprite planes around modeset
From: Ville Syrjälä ville.syrj...@linux.intel.com
Disable/restore sprite planes around mode-set just like we do for the
primary and cursor planes. Now that we have working sprite clipping,
this actually works quite decently.
Previosuly we didn't even bother to disable sprites when changing mode,
which could lead to a corrupted sprite appearing on the screen after a
modeset (at least on my IVB). Not sure if all hardware generations would
be so forgiving when enabled sprites end up outside the pipe dimensons.
v2: Disable rather than enable sprites in ironlake_crtc_disable()
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 29 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_sprite.c | 8
3 files changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 61bee12..e928a54 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3161,6 +3161,28 @@ static void ironlake_pfit_enable(struct intel_crtc *crtc)
}
}
+static void intel_enable_planes(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc-dev;
+ enum pipe pipe = to_intel_crtc(crtc)-pipe;
+ struct intel_plane *intel_plane;
+
+ list_for_each_entry(intel_plane, dev-mode_config.plane_list,
base.head)
+ if (intel_plane-pipe == pipe)
+ intel_plane_restore(intel_plane-base);
+}
+
+static void intel_disable_planes(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc-dev;
+ enum pipe pipe = to_intel_crtc(crtc)-pipe;
+ struct intel_plane *intel_plane;
+
+ list_for_each_entry(intel_plane, dev-mode_config.plane_list,
base.head)
+ if (intel_plane-pipe == pipe)
+ intel_plane_disable(intel_plane-base);
+}
+
static void ironlake_crtc_enable(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc-dev;
@@ -3216,6 +3238,7 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
intel_enable_pipe(dev_priv, pipe,
intel_crtc-config.has_pch_encoder);
intel_enable_plane(dev_priv, plane, pipe);
+ intel_enable_planes(crtc);
intel_crtc_update_cursor(crtc, true);
if (intel_crtc-config.has_pch_encoder)
@@ -3324,6 +3347,7 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
intel_enable_pipe(dev_priv, pipe,
intel_crtc-config.has_pch_encoder);
intel_enable_plane(dev_priv, plane, pipe);
+ intel_enable_planes(crtc);
intel_crtc_update_cursor(crtc, true);
hsw_enable_ips(intel_crtc);
@@ -3388,6 +3412,7 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
intel_disable_fbc(dev);
intel_crtc_update_cursor(crtc, false);
+ intel_disable_planes(crtc);
intel_disable_plane(dev_priv, plane, pipe);
intel_set_pch_fifo_underrun_reporting(dev, pipe, false);
@@ -3470,6 +3495,7 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
hsw_disable_ips(intel_crtc);
intel_crtc_update_cursor(crtc, false);
+ intel_disable_planes(crtc);
intel_disable_plane(dev_priv, plane, pipe);
if (intel_crtc-config.has_pch_encoder)
@@ -3617,6 +3643,7 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
intel_enable_pipe(dev_priv, pipe, false);
intel_enable_plane(dev_priv, plane, pipe);
+ intel_enable_planes(crtc);
intel_crtc_update_cursor(crtc, true);
intel_update_fbc(dev);
@@ -3654,6 +3681,7 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc)
intel_enable_pipe(dev_priv, pipe, false);
intel_enable_plane(dev_priv, plane, pipe);
+ intel_enable_planes(crtc);
intel_crtc_update_cursor(crtc, true);
if (IS_G4X(dev))
g4x_fixup_plane(dev_priv, pipe);
@@ -3706,6 +3734,7 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
intel_crtc_dpms_overlay(intel_crtc, false);
intel_crtc_update_cursor(crtc, false);
+ intel_disable_planes(crtc);
intel_disable_plane(dev_priv, plane, pipe);
intel_disable_pipe(dev_priv, pipe);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fdf6303..0355315 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -633,6 +633,7 @@ extern void intel_connector_dpms(struct drm_connector *,
int mode);
extern bool intel_connector_get_hw_state(struct intel_connector *connector);
extern void intel_modeset_check_state(struct drm_device *dev);
extern void intel_plane_restore(struct drm_plane *plane);
+extern void intel_plane_disable(struct drm_plane *plane);
static inline struct intel_encoder *intel_attached_encoder(struct
drm_connector *connector)
diff --git
[Intel-gfx] [PATCH 7/9] drm/i915: Improve assert_planes_disabled()
From: Ville Syrjälä ville.syrj...@linux.intel.com
Ever since gen4 primary planes were fixed to pipes.
And for gen2-3, don't check plane B if it doesn't exist.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e928a54..9c89ddf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1102,12 +1102,13 @@ static void assert_plane(struct drm_i915_private
*dev_priv,
static void assert_planes_disabled(struct drm_i915_private *dev_priv,
enum pipe pipe)
{
+ struct drm_device *dev = dev_priv-dev;
int reg, i;
u32 val;
int cur_pipe;
- /* Planes are fixed to pipes on ILK+ */
- if (HAS_PCH_SPLIT(dev_priv-dev) || IS_VALLEYVIEW(dev_priv-dev)) {
+ /* Primary planes are fixed to pipes on gen4+ */
+ if (INTEL_INFO(dev)-gen = 4) {
reg = DSPCNTR(pipe);
val = I915_READ(reg);
WARN((val DISPLAY_PLANE_ENABLE),
@@ -1117,7 +1118,7 @@ static void assert_planes_disabled(struct
drm_i915_private *dev_priv,
}
/* Need to check both planes against the pipe */
- for (i = 0; i 2; i++) {
+ for (i = 0; i INTEL_INFO(dev)-num_pipes; i++) {
reg = DSPCNTR(i);
val = I915_READ(reg);
cur_pipe = (val DISPPLANE_SEL_PIPE_MASK)
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 9/9] drm/i915: Assert dpll running in intel_crtc_load_lut() on pre-PCH platforms
From: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 90d02c7..3be69bc 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6340,6 +6340,9 @@ void intel_crtc_load_lut(struct drm_crtc *crtc) if (!crtc-enabled || !intel_crtc-active) return; + if (!HAS_PCH_SPLIT(dev_priv-dev)) + assert_pll_enabled(dev_priv, pipe); + /* use legacy palette for Ironlake */ if (HAS_PCH_SPLIT(dev)) palreg = LGC_PALETTE(pipe); -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9] drm/i915: Spruce up assert_sprites_disabled()
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make assert_sprites_disabled() operational on all platforms where
we currently have sprite support enabled.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9c89ddf..90d02c7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1132,19 +1132,30 @@ static void assert_planes_disabled(struct
drm_i915_private *dev_priv,
static void assert_sprites_disabled(struct drm_i915_private *dev_priv,
enum pipe pipe)
{
+ struct drm_device *dev = dev_priv-dev;
int reg, i;
u32 val;
- if (!IS_VALLEYVIEW(dev_priv-dev))
- return;
-
- /* Need to check both planes against the pipe */
- for (i = 0; i dev_priv-num_plane; i++) {
- reg = SPCNTR(pipe, i);
+ if (IS_VALLEYVIEW(dev)) {
+ for (i = 0; i dev_priv-num_plane; i++) {
+ reg = SPCNTR(pipe, i);
+ val = I915_READ(reg);
+ WARN((val SP_ENABLE),
+sprite %c assertion failure, should be off on
pipe %c but is still active\n,
+sprite_name(pipe, i), pipe_name(pipe));
+ }
+ } else if (INTEL_INFO(dev)-gen = 7) {
+ reg = SPRCTL(pipe);
+ val = I915_READ(reg);
+ WARN((val SPRITE_ENABLE),
+sprite %c assertion failure, should be off on pipe %c but
is still active\n,
+plane_name(pipe), pipe_name(pipe));
+ } else if (INTEL_INFO(dev)-gen = 5) {
+ reg = DVSCNTR(pipe);
val = I915_READ(reg);
- WARN((val SP_ENABLE),
+ WARN((val DVS_ENABLE),
sprite %c assertion failure, should be off on pipe %c but
is still active\n,
-sprite_name(pipe, i), pipe_name(pipe));
+plane_name(pipe), pipe_name(pipe));
}
}
--
1.8.1.5
___
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: fix EDID/sink-based bpp clamping
On Mon, Jun 03, 2013 at 08:50:29AM +0100, Chris Wilson wrote: On Sun, Jun 02, 2013 at 01:26:24PM +0200, Daniel Vetter wrote: Since this is run in the compute config stage we need to check the new_ pointers, i.e the stage output routing, not the current modeset layout. Also there was a little logic bug in properly skipping connectors: The old code did not skip any unused connectors and so clamped to whatever was left in there (usually 0 if that connector hasn't seen a EDID 1.4 screen ever since boot-up). This has been broken when moving the pipe bpp selection in commit 4e53c2e010e531b4a014692199e978482d471c7e Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Wed Mar 27 00:44:58 2013 +0100 drm/i915: precompute pipe bpp before touching the hw To avoid too much casting switch from drm_ to intel_ types. Also add a bit of debug output to help reconstructing what's going on. v2: Try to clarify this a bit: - s/pipe_config_set_bpp/compute_baseline_pipe_bpp/ to make it clearer at which stage this function is run. Also add a comment about what it does. - Extract the sink clamping into it's own function. v3: Actually make it compile. v4: Split out all the prep refactoring to make the bugfix stick out really badly. Also elaborate a bit in the commit message about the nature of the bugfix. Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Yes, that does show how badly I misread the first patch! For both, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Both merged, thanks for the review. I'll ping QA to test the 30bpp patch, too. -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 5/7] drm/i915: store adjusted dotclock in adjusted_mode-clock
On Mon, Jun 03, 2013 at 01:54:40PM -0300, Paulo Zanoni wrote:
2013/6/1 Daniel Vetter daniel.vet...@ffwll.ch:
... not the port clock. This allows us to kill the funny semantics
around pixel_target_clock.
Since the dpll code still needs the real port clock, add a new
port_clock field to the pipe configuration. Handling the default case
for that one is a bit tricky, since encoders might not consistently
overwrite it when retrying the crtc/encoder bw arbitrage step in the
compute config stage. Hence we need to always clear port_clock and
update it again if the encoder hasn't put in something more specific.
This can't be done in one step since the encoder might want to adjust
the mode first.
I was a bit on the fence whether I should subsume the pixel multiplier
handling into the port_clock, too. But then I decided against this
since it's on an abstract level still the dotclock of the adjusted
mode, and only our hw makes it a bit special due to the separate pixel
mulitplier setting (which requires that the dpll runs at the
non-multiplied dotclock).
So after this patch the adjusted_mode accurately describes the mode we
feed into the port, after the panel fitter and pixel multiplier (or
line doubling, if we ever bother with that) have done their job.
Since the fdi link is between the pfit and the pixel multiplier steps
we need to be careful with calculating the fdi link config.
v2: Fix up ilk cpu pll handling.
v3: Introduce an fdi_dotclock variable in ironlake_fdi_compute_config
to make it clearer that we transmit the adjusted_mode without the
pixel multiplier taken into account. The old code multiplied the the
available link bw with the pixel multiplier, which results in the same
fdi configuration, but is much more confusing.
v4: Rebase on top of Imre's is_cpu_edp removal.
v5: Rebase on top of Paulo's haswell watermark fixes, which introduce
a new place which looked at the pixel_clock and so needed conversion.
v6: Split out prep patches as requested by Paulo Zanoni. Also rebase
on top of the fdi dotclock handling fix in the fdi lanes/bw
computation code.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org (v3)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Due to my comments on patch 3, there's a possibility you may need to
rebase this patch.
My only optional bikeshed is to print port_clock inside
intel_dump_pipe_config. If you rebase, you may consider doing it :)
Yeah, I think I'll follow up with another pipe config dump patch to add
lots more stuff. Already screamed around because it wasn't as complete as
I've wished for ;-)
-Daniel
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com (v6)
---
drivers/gpu/drm/i915/intel_ddi.c | 3 ++-
drivers/gpu/drm/i915/intel_display.c | 32 +---
drivers/gpu/drm/i915/intel_dp.c | 18 +++---
drivers/gpu/drm/i915/intel_drv.h | 13 +++--
drivers/gpu/drm/i915/intel_hdmi.c| 4 +---
drivers/gpu/drm/i915/intel_pm.c | 5 +
6 files changed, 35 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 9649df8..486c46b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -624,7 +624,7 @@ intel_ddi_calculate_wrpll(int clock /* in Hz */,
clock, *p_out, *n2_out, *r2_out);
}
-bool intel_ddi_pll_mode_set(struct drm_crtc *crtc, int clock)
+bool intel_ddi_pll_mode_set(struct drm_crtc *crtc)
{
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_encoder *intel_encoder =
intel_ddi_get_crtc_encoder(crtc);
@@ -634,6 +634,7 @@ bool intel_ddi_pll_mode_set(struct drm_crtc *crtc, int
clock)
int type = intel_encoder-type;
enum pipe pipe = intel_crtc-pipe;
uint32_t reg, val;
+ int clock = intel_crtc-config.port_clock;
/* TODO: reuse PLLs when possible (compare values) */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 761254d..103f4e9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3992,7 +3992,7 @@ static int ironlake_fdi_compute_config(struct
intel_crtc *intel_crtc,
{
struct drm_device *dev = intel_crtc-base.dev;
struct drm_display_mode *adjusted_mode =
pipe_config-adjusted_mode;
- int target_clock, lane, link_bw, fdi_dotclock;
+ int lane, link_bw, fdi_dotclock;
bool setup_ok, needs_recompute = false;
retry:
@@ -4005,12 +4005,7 @@ retry:
*/
link_bw = intel_fdi_link_freq(dev) * MHz(100)/KHz(1)/10;
- if (pipe_config-pixel_target_clock)
- target_clock = pipe_config-pixel_target_clock;
- else
- target_clock = adjusted_mode-clock;
-
Re: [Intel-gfx] [PATCH 7/7] drm/i915: check for strange pfit pipe assignemnt on ivb/hsw
On Mon, Jun 03, 2013 at 02:08:33PM -0300, Paulo Zanoni wrote:
2013/6/1 Daniel Vetter daniel.vet...@ffwll.ch:
Panel fitters on ivb/hsw are not created equal since not all of them
support the new high-quality upscaling mode. To offset this the hw
allows us to freely assign the pfits to pipes.
Since our code currently doesn't support this we might fall over when
taking over firmware state. So check for this case and WARN about it.
We can then improve the code once we've hit this in the wild. Or once
we decide to support the improved upscale modes, though that requires
global arbitrage of modeset resources across crtcs.
Suggested-by: Mika Kuoppala mika.kuopp...@intel.com
Cc: Mika Kuoppala mika.kuopp...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 432e699..2b6e141 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5806,6 +5806,14 @@ static void ironlake_get_pfit_config(struct
intel_crtc *crtc,
if (tmp PF_ENABLE) {
pipe_config-pch_pfit.pos =
I915_READ(PF_WIN_POS(crtc-pipe));
pipe_config-pch_pfit.size =
I915_READ(PF_WIN_SZ(crtc-pipe));
+
+ /* We currently do not free assignements of panel fitters on
+* ivb/hsw (since we don't use the higher upscaling modes
which
+* differentiates them) so just WARN about this case for
now. */
+ if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) {
Or just check for IS_GEN7 or, to be future-proof, check for gen = 7
since there's a higher chance that newer gens will be similar to gen 7
instead of the previous ones.
As discussed in private, I think the explicit list here is better. But
checking for IS_GEN7 is a good idea - I didn't realize that vlv is already
excluded here. So applied that little changed.
Anyway: Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Merged all patches from this series, thanks a lot for your critical
review. It's not always fun, but it _does_ improve the patches by a lot
;-)
Cheers, Daniel
+ WARN_ON((tmp PF_PIPE_SEL_MASK_IVB) !=
+ PF_PIPE_SEL_IVB(crtc-pipe));
+ }
}
}
--
1.7.11.7
--
Paulo Zanoni
--
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/i915: Track clients and print their object usage in debugfs
By stashing a pointer of who opened the device and keeping a list of
open fd, we can then walk each client and inspect how many objects they
have open. For example,
i915_gem_objects:
1102 objects, 613646336 bytes
663 [662] objects, 468783104 [468750336] bytes in gtt
37 [37] active objects, 46874624 [46874624] bytes
626 [625] inactive objects, 421908480 [421875712] bytes
282 unbound objects, 6512640 bytes
85 purgeable objects, 6787072 bytes
28 pinned mappable objects, 3686400 bytes
40 fault mappable objects, 27783168 bytes
2145386496 [536870912] gtt total
Xorg: 43 objects, 32243712 bytes (10223616 active, 16683008 inactive, 4096
unbound)
gnome-shell: 30 objects, 28381184 bytes (0 active, 28336128 inactive, 0 unbound)
xonotic-linux64: 1032 objects, 569933824 bytes (46874624 active, 383545344
inactive, 6508544 unbound)
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 41 +++
drivers/gpu/drm/i915/i915_dma.c | 18 ---
drivers/gpu/drm/i915/i915_drv.h |5 -
drivers/gpu/drm/i915/i915_gem.c |1 +
4 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0e7e3c0..6c95e17 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -196,6 +196,32 @@ static int i915_gem_object_list_info(struct seq_file *m,
void *data)
} \
} while (0)
+struct file_stats {
+ int count;
+ size_t total, active, inactive, unbound;
+};
+
+static int per_file_stats(int id, void *ptr, void *data)
+{
+ struct drm_i915_gem_object *obj = ptr;
+ struct file_stats *stats = data;
+
+ stats-count++;
+ stats-total += obj-base.size;
+
+ if (obj-gtt_space) {
+ if (!list_empty(obj-ring_list))
+ stats-active += obj-base.size;
+ else
+ stats-inactive += obj-base.size;
+ } else {
+ if (!list_empty(obj-global_list))
+ stats-unbound += obj-base.size;
+ }
+
+ return 0;
+}
+
static int i915_gem_object_info(struct seq_file *m, void* data)
{
struct drm_info_node *node = (struct drm_info_node *) m-private;
@@ -204,6 +230,7 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
u32 count, mappable_count, purgeable_count;
size_t size, mappable_size, purgeable_size;
struct drm_i915_gem_object *obj;
+ struct drm_i915_file_private *file;
int ret;
ret = mutex_lock_interruptible(dev-struct_mutex);
@@ -263,6 +290,20 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
dev_priv-gtt.total,
dev_priv-gtt.mappable_end - dev_priv-gtt.start);
+ seq_printf(m, \n);
+ list_for_each_entry(file, dev_priv-clients, link) {
+ struct file_stats stats;
+ memset(stats, 0, sizeof(stats));
+ idr_for_each(file-base-object_idr, per_file_stats, stats);
+ seq_printf(m, %s: %u objects, %zu bytes (%zu active, %zu
inactive, %zu unbound)\n,
+ file-task-comm,
+ stats.count,
+ stats.total,
+ stats.active,
+ stats.inactive,
+ stats.unbound);
+ }
+
mutex_unlock(dev-struct_mutex);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index ad4c493..a2d511f 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1805,6 +1805,7 @@ int i915_driver_unload(struct drm_device *dev)
int i915_driver_open(struct drm_device *dev, struct drm_file *file)
{
+ struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_file_private *file_priv;
DRM_DEBUG_DRIVER(\n);
@@ -1813,12 +1814,18 @@ int i915_driver_open(struct drm_device *dev, struct
drm_file *file)
return -ENOMEM;
file-driver_priv = file_priv;
+ file_priv-base = file;
spin_lock_init(file_priv-mm.lock);
INIT_LIST_HEAD(file_priv-mm.request_list);
idr_init(file_priv-context_idr);
+ file_priv-task = current;
+ mutex_lock(dev-struct_mutex);
+ list_add_tail(file_priv-link, dev_priv-clients);
+ mutex_unlock(dev-struct_mutex);
+
return 0;
}
@@ -1855,10 +1862,15 @@ void i915_driver_lastclose(struct drm_device * dev)
i915_dma_cleanup(dev);
}
-void i915_driver_preclose(struct drm_device * dev, struct drm_file *file_priv)
+void i915_driver_preclose(struct drm_device * dev, struct drm_file *file)
{
- i915_gem_context_close(dev, file_priv);
- i915_gem_release(dev, file_priv);
+ struct drm_i915_file_private *file_priv = file-driver_priv;
+
+
[Intel-gfx] [PATCH] drm/i915: Always disable trickle feed on Broadwater/Crestline
The programming notes for Broadwater and Crestline mandate that the trickle feed disable bit is asserted. See section 1.16.2 MI_ARB_STATE. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk --- drivers/gpu/drm/i915/intel_pm.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 4126fb1..3dfb5be 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4930,6 +4930,9 @@ static void crestline_init_clock_gating(struct drm_device *dev) I915_WRITE(DSPCLK_GATE_D, 0); I915_WRITE(RAMCLK_GATE_D, 0); I915_WRITE16(DEUC, 0); + + I915_WRITE(MI_ARB_STATE, + _MASKED_BIT_ENABLE(MI_ARB_DISPLAY_TRICKLE_FEED_DISABLE)); } static void broadwater_init_clock_gating(struct drm_device *dev) @@ -4942,6 +4945,9 @@ static void broadwater_init_clock_gating(struct drm_device *dev) I965_ISC_CLOCK_GATE_DISABLE | I965_FBC_CLOCK_GATE_DISABLE); I915_WRITE(RENCLK_GATE_D2, 0); + + I915_WRITE(MI_ARB_STATE, + _MASKED_BIT_ENABLE(MI_ARB_DISPLAY_TRICKLE_FEED_DISABLE)); } static void gen3_init_clock_gating(struct drm_device *dev) -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Disable primary plane trickle feed for g4x
On Tue, May 21, 2013 at 03:28:32PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com The docs say that the trickle feed disable bit is present (for primary planes only, not video sprites) on CTG, and that it must be set for ELK. Just set it for all g4x chipsets. v2: Do it in init_clock_gating too Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk The bspec says this bit is ignored on Cantiga, so this should be harmless there. -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 2/3] drm/i915: Disable trickle feed via MI_ARB_STATE for gen4
On Tue, May 21, 2013 at 03:28:33PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com According to BSpec, trickle feed should be disabled for BW and mobile CL. Those constraints seem to match all of our gen4 chipsets. Trickle feed is disabled via the MI_ARB_STATE register instead of per plane controls on gen4. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Foolish me overlooking this patch earlier. -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 3/3] drm/i915: Try harder to disable trickle feed on VLV
On Tue, May 21, 2013 at 03:28:34PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com The specs are a bit unclear whether the per-plane trickle feed disable control exists on VLV. There is another trickle feed disable control in the MI_ARB register. Based on some quick register dumps from Jani's VLV machine, the per-plane bits don't actually seem to exist, so I'm guessing we should use the MI_ARB method instead. I think neither. I'm guessing this behaviour is covered by 'Note: On mobile products this bit will be ignored such that Trickle Feed is always disabled.' in the DSP.CNTR spec. And I don't think MI_ARB_STATE is applicable as it wasn't used for the display block VLV was based upon. Being VPN-less I can't actually dig through the VLV bspec to confirm. -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
[Intel-gfx] [PATCH] drm/i915/sdvo: Use intel_sdvo-ddc instead of intel_sdvo-i2c for DDC.
In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used for DDC. Thus the code will always have to rely on a LVDS panel mode supplied by VBT. In most cases this succeeds, so this didn't get detected for quite a while. Signed-off-by: Egbert Eich e...@suse.de --- drivers/gpu/drm/i915/intel_sdvo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index 7068195..8618b15 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -1848,7 +1848,7 @@ static void intel_sdvo_get_lvds_modes(struct drm_connector *connector) * Assume that the preferred modes are * arranged in priority order. */ - intel_ddc_get_modes(connector, intel_sdvo-i2c); + intel_ddc_get_modes(connector, intel_sdvo-ddc); if (list_empty(connector-probed_modes) == false) goto end; -- 1.8.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/sdvo: Use intel_sdvo-ddc instead of intel_sdvo-i2c for DDC.
On Tue, Jun 04, 2013 at 05:13:21PM +0200, Egbert Eich wrote: In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used for DDC. Thus the code will always have to rely on a LVDS panel mode supplied by VBT. In most cases this succeeds, so this didn't get detected for quite a while. Signed-off-by: Egbert Eich e...@suse.de Good catch! Cc: sta...@vger.kernel.org Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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] drm/i915/sdvo: Use intel_sdvo-ddc instead of intel_sdvo-i2c for DDC.
On Tue, Jun 04, 2013 at 04:35:32PM +0100, Chris Wilson wrote: On Tue, Jun 04, 2013 at 05:13:21PM +0200, Egbert Eich wrote: In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used for DDC. Thus the code will always have to rely on a LVDS panel mode supplied by VBT. In most cases this succeeds, so this didn't get detected for quite a while. Signed-off-by: Egbert Eich e...@suse.de Good catch! Cc: sta...@vger.kernel.org Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Yeah, nice catch. If my history digging is correct this has been broken in commit f899fc64cda8569d0529452aafc0da31c042df2e Author: Chris Wilson ch...@chris-wilson.co.uk Date: Tue Jul 20 15:44:45 2010 -0700 drm/i915: use GMBUS to manage i2c links Patch merged with that note added, thanks. -Daniel -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 -- 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 3/3] drm/i915: Try harder to disable trickle feed on VLV
On Tue, Jun 04, 2013 at 03:19:12PM +0100, Chris Wilson wrote: On Tue, May 21, 2013 at 03:28:34PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com The specs are a bit unclear whether the per-plane trickle feed disable control exists on VLV. There is another trickle feed disable control in the MI_ARB register. Based on some quick register dumps from Jani's VLV machine, the per-plane bits don't actually seem to exist, so I'm guessing we should use the MI_ARB method instead. I think neither. I'm guessing this behaviour is covered by 'Note: On mobile products this bit will be ignored such that Trickle Feed is always disabled.' in the DSP.CNTR spec. And I don't think MI_ARB_STATE is applicable as it wasn't used for the display block VLV was based upon. Being VPN-less I can't actually dig through the VLV bspec to confirm. The register spec has it, and it's even highlighted so it was apparetnly changed at some point. Also note that the register seems to differ from MI_ARB_STATE by being the non masked type, so clearly someone felt the need to edit it for some reason. The display cluster doc also says that trickle feed is configurable, but doesn't go into any further details on the subject. I guess we should confirm on real hardware whether the bit sticks. I don't remember if I poked Jani to do that since he was a bit busy with other stuff when I made the patch. Anyways, that could give us a hint whether the bit really does something. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, Three regression fixes and one no-lvds quirk update. The regression Egbert Eich tracked down goes back to 2.6.37 ... ugh. The other two are pretty minor: One bogus modeset state checker WARN and a patch to prevent X dying in a SIGBUS after a gpu hang with failed (or not implement as on gen2/3) gpu reset. Cheers, Daniel The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e: Linux 3.10-rc4 (2013-06-02 17:11:17 +0900) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-06-04 for you to fetch changes up to 53d3b4d7778daf15900867336c85d3f8dd70600c: drm/i915/sdvo: Use intel_sdvo-ddc instead of intel_sdvo-i2c for DDC. (2013-06-04 17:48:43 +0200) Ben Mesman (1): drm/i915: no lvds quirk for hp t5740 Daniel Vetter (2): drm/i915: Fix spurious -EIO/SIGBUS on wedged gpus drm/i915: Quirk the pipe A quirk in the modeset state checker Egbert Eich (1): drm/i915/sdvo: Use intel_sdvo-ddc instead of intel_sdvo-i2c for DDC. drivers/gpu/drm/i915/i915_gem.c |7 ++- drivers/gpu/drm/i915/intel_display.c |5 + drivers/gpu/drm/i915/intel_lvds.c|4 ++-- drivers/gpu/drm/i915/intel_sdvo.c|2 +- 4 files changed, 10 insertions(+), 8 deletions(-) -- 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 i-g-t 2/3] tools: Remove unused tools/intel_iosf_read.c
Also intel_iosf_read() does not exist, and would need a bit more
arguments.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
tools/intel_iosf_read.c | 70 -
1 file changed, 70 deletions(-)
delete mode 100644 tools/intel_iosf_read.c
diff --git a/tools/intel_iosf_read.c b/tools/intel_iosf_read.c
deleted file mode 100644
index 15cd82c..000
--- a/tools/intel_iosf_read.c
+++ /dev/null
@@ -1,70 +0,0 @@
-/*
- * Copyright © 2012 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.
- *
- * Authors:
- * Vijay Purushothaman vijay.a.purushotha...@intel.com
- *
- */
-
-#include unistd.h
-#include stdlib.h
-#include stdio.h
-#include err.h
-#include string.h
-#include intel_gpu_tools.h
-
-static void usage(char *cmdname)
-{
- printf(Warning : This program will work only on Valleyview\n);
- printf(Usage: %s [addr]\n, cmdname);
- printf(\t addr : in 0x format\n);
-}
-
-int main(int argc, char** argv)
-{
- int ret = 0;
- uint32_t reg, val;
- char *cmdname = strdup(argv[0]);
- struct pci_device *dev = intel_get_pci_device();
-
- if (argc != 2 || !IS_VALLEYVIEW(dev-device_id)) {
- usage(cmdname);
- ret = 1;
- goto out;
- }
-
- sscanf(argv[1], 0x%x, reg);
-
- intel_register_access_init(dev, 0);
-
- ret = intel_iosf_read(reg, val);
- if (ret)
- fprintf(stderr, iosf read failed: %d\n, ret);
-
- printf(Read IOSF register: 0x%x - Value : 0x%x\n, reg, val);
-
- intel_register_access_fini();
-
-out:
- free(cmdname);
- return ret;
-}
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/3] tools: Remove intel_disable_clock_gating
This tool only supports ILK. I take the fact that nobody has felt the
need to update it for later platforms as a sign it's not very useful.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
Android.mk | 33 --
tools/.gitignore | 1 -
tools/Makefile.am | 1 -
tools/intel_disable_clock_gating.c | 71 --
4 files changed, 106 deletions(-)
delete mode 100644 tools/intel_disable_clock_gating.c
diff --git a/Android.mk b/Android.mk
index 3be3462..a44740c 100644
--- a/Android.mk
+++ b/Android.mk
@@ -68,39 +68,6 @@ include $(BUILD_EXECUTABLE)
#
include $(CLEAR_VARS)
-LOCAL_SRC_FILES := \
- tools/intel_disable_clock_gating.c \
- lib/intel_pci.c \
- lib/intel_gpu_tools.h \
- tools/intel_reg.h \
- lib/intel_batchbuffer.h \
- lib/intel_batchbuffer.c \
- lib/intel_mmio.c\
- tools/intel_chipset.h
-
-
-LOCAL_C_INCLUDES +=\
- $(LOCAL_PATH)/lib \
- $(TOPDIR)hardware/intel/libdrm/include/drm \
- $(TOPDIR)hardware/intel/libdrm/intel\
- $(LOCAL_PATH)/../libpciaccess/include/
-
-LOCAL_CFLAGS += -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1
-LOCAL_CFLAGS += -DANDROID
-
-
-LOCAL_MODULE := intel_disable_clock_gating
-LOCAL_MODULE_TAGS := optional
-
-LOCAL_SHARED_LIBRARIES := libpciaccess \
- libdrm \
- libdrm_intel
-
-include $(BUILD_EXECUTABLE)
-
-#
-include $(CLEAR_VARS)
-
LOCAL_SRC_FILES := \
tools/intel_audio_dump.c \
lib/intel_pci.c \
diff --git a/tools/.gitignore b/tools/.gitignore
index 23ac628..8c6622d 100644
--- a/tools/.gitignore
+++ b/tools/.gitignore
@@ -3,7 +3,6 @@ intel_audio_dump
intel_backlight
intel_bios_dumper
intel_bios_reader
-intel_disable_clock_gating
intel_dpio_read
intel_dpio_write
intel_dump_decode
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 2519169..1686b9c 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -3,7 +3,6 @@ SUBDIRS = quick_dump
endif
bin_PROGRAMS = \
- intel_disable_clock_gating \
intel_audio_dump\
intel_backlight \
intel_bios_dumper \
diff --git a/tools/intel_disable_clock_gating.c
b/tools/intel_disable_clock_gating.c
deleted file mode 100644
index 8dde3e1..000
--- a/tools/intel_disable_clock_gating.c
+++ /dev/null
@@ -1,71 +0,0 @@
-/*
- * Copyright © 2010 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.
- *
- * Authors:
- * Zhenyu Wang zhen...@linux.intel.com
- *
- */
-
-#include unistd.h
-#include stdlib.h
-#include stdio.h
-#include err.h
-#include string.h
-#include intel_gpu_tools.h
-
-int main(int argc, char** argv)
-{
- struct pci_device *pci_dev;
-
- pci_dev = intel_get_pci_device();
- intel_get_mmio(pci_dev);
-
- if (IS_GEN5(pci_dev-device_id)) {
- printf(Restore method:\n);
-
- printf(intel_reg_write 0x%x 0x%08x\n,
- PCH_3DCGDIS0, INREG(PCH_3DCGDIS0));
- OUTREG(PCH_3DCGDIS0, 0x);
-
- printf(intel_reg_write 0x%x 0x%08x\n,
- PCH_3DCGDIS1, INREG(PCH_3DCGDIS1));
- OUTREG(PCH_3DCGDIS1, 0x);
-
- printf(intel_reg_write 0x%x 0x%08x\n,
- PCH_3DRAMCGDIS0, INREG(PCH_3DRAMCGDIS0));
- OUTREG(PCH_3DRAMCGDIS0, 0x);
-
- printf(intel_reg_write 0x%x
[Intel-gfx] [PATCH i-g-t 1/3] instdone: Add an assert to make sure we never overflow instdone_bits
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
lib/instdone.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/instdone.c b/lib/instdone.c
index 4679a9c..ad5c62f 100644
--- a/lib/instdone.c
+++ b/lib/instdone.c
@@ -37,6 +37,7 @@ int num_instdone_bits = 0;
static void
add_instdone_bit(uint32_t reg, uint32_t bit, const char *name)
{
+ assert(num_instdone_bits MAX_INSTDONE_BITS);
instdone_bits[num_instdone_bits].reg = reg;
instdone_bits[num_instdone_bits].bit = bit;
instdone_bits[num_instdone_bits].name = name;
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: update FBC maximum fb sizes
On Mon, Jun 3, 2013 at 11:15 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
CTG/ILK/SNB/IVB support 4kx2k surfaces. HSW supports 4kx4k, but
without proper front buffer invalidation on the last 2k lines, so
don't enable FBC on these cases for now.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 49a1887..cf123c1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -431,7 +431,7 @@ void intel_disable_fbc(struct drm_device *dev)
* - no pixel mulitply/line duplication
* - no alpha buffer discard
* - no dual wide
- * - framebuffer = 2048 in width, 1536 in height
+ * - framebuffer = max_hdisplay in width, max_vdisplay in height
*
* We can't assume that any compression will take place (worst case),
* so the compressed buffer has to be the same size as the uncompressed
@@ -449,6 +449,7 @@ void intel_update_fbc(struct drm_device *dev)
struct intel_framebuffer *intel_fb;
struct drm_i915_gem_object *obj;
int enable_fbc;
+ unsigned int max_hdisplay, max_vdisplay;
if (!i915_powersave)
return;
@@ -507,8 +508,16 @@ void intel_update_fbc(struct drm_device *dev)
dev_priv-no_fbc_reason = FBC_UNSUPPORTED_MODE;
goto out_disable;
}
- if ((crtc-mode.hdisplay 2048) ||
- (crtc-mode.vdisplay 1536)) {
+
+ if (IS_G4X(dev) || INTEL_INFO(dev)-gen 4) {
Bikeshed-time: I prefer gen checks to be of the form gen = x or gen
y because:
- It looks more like C code should look like.
- We we talk about platform ranges we tend to use e.g. ilk+ and
pre-gen6, so would fit more naturally with the written word.
Patch looks good otherwise, but for a bit I was thinking wait, g4x is
gen4, what's going on here? ...
Cheers, Daniel
+ max_hdisplay = 4096;
+ max_vdisplay = 2048;
+ } else {
+ max_hdisplay = 2048;
+ max_vdisplay = 1536;
+ }
+ if ((crtc-mode.hdisplay max_hdisplay) ||
+ (crtc-mode.vdisplay max_vdisplay)) {
DRM_DEBUG_KMS(mode too large for compression, disabling\n);
dev_priv-no_fbc_reason = FBC_MODE_TOO_LARGE;
goto out_disable;
--
1.8.1.2
___
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: update FBC maximum fb sizes
2013/6/4 Daniel Vetter dan...@ffwll.ch:
On Mon, Jun 3, 2013 at 11:15 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
CTG/ILK/SNB/IVB support 4kx2k surfaces. HSW supports 4kx4k, but
without proper front buffer invalidation on the last 2k lines, so
don't enable FBC on these cases for now.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 49a1887..cf123c1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -431,7 +431,7 @@ void intel_disable_fbc(struct drm_device *dev)
* - no pixel mulitply/line duplication
* - no alpha buffer discard
* - no dual wide
- * - framebuffer = 2048 in width, 1536 in height
+ * - framebuffer = max_hdisplay in width, max_vdisplay in height
*
* We can't assume that any compression will take place (worst case),
* so the compressed buffer has to be the same size as the uncompressed
@@ -449,6 +449,7 @@ void intel_update_fbc(struct drm_device *dev)
struct intel_framebuffer *intel_fb;
struct drm_i915_gem_object *obj;
int enable_fbc;
+ unsigned int max_hdisplay, max_vdisplay;
if (!i915_powersave)
return;
@@ -507,8 +508,16 @@ void intel_update_fbc(struct drm_device *dev)
dev_priv-no_fbc_reason = FBC_UNSUPPORTED_MODE;
goto out_disable;
}
- if ((crtc-mode.hdisplay 2048) ||
- (crtc-mode.vdisplay 1536)) {
+
+ if (IS_G4X(dev) || INTEL_INFO(dev)-gen 4) {
Bikeshed-time: I prefer gen checks to be of the form gen = x or gen
y because:
- It looks more like C code should look like.
- We we talk about platform ranges we tend to use e.g. ilk+ and
pre-gen6, so would fit more naturally with the written word.
Patch looks good otherwise, but for a bit I was thinking wait, g4x is
gen4, what's going on here? ...
Yeah, you're right. I was trying to find out how do I check for
Cantiga+? and basically copied the line I found inside
intel_crtc_compute_config. We could really have a map between these
older codenames and our checks somewhere.
Cheers, Daniel
+ max_hdisplay = 4096;
+ max_vdisplay = 2048;
+ } else {
+ max_hdisplay = 2048;
+ max_vdisplay = 1536;
+ }
+ if ((crtc-mode.hdisplay max_hdisplay) ||
+ (crtc-mode.vdisplay max_vdisplay)) {
DRM_DEBUG_KMS(mode too large for compression, disabling\n);
dev_priv-no_fbc_reason = FBC_MODE_TOO_LARGE;
goto out_disable;
--
1.8.1.2
___
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
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: update FBC maximum fb sizes
On Tue, Jun 04, 2013 at 02:46:14PM -0300, Paulo Zanoni wrote:
2013/6/4 Daniel Vetter dan...@ffwll.ch:
On Mon, Jun 3, 2013 at 11:15 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
CTG/ILK/SNB/IVB support 4kx2k surfaces. HSW supports 4kx4k, but
without proper front buffer invalidation on the last 2k lines, so
don't enable FBC on these cases for now.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 49a1887..cf123c1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -431,7 +431,7 @@ void intel_disable_fbc(struct drm_device *dev)
* - no pixel mulitply/line duplication
* - no alpha buffer discard
* - no dual wide
- * - framebuffer = 2048 in width, 1536 in height
+ * - framebuffer = max_hdisplay in width, max_vdisplay in height
*
* We can't assume that any compression will take place (worst case),
* so the compressed buffer has to be the same size as the uncompressed
@@ -449,6 +449,7 @@ void intel_update_fbc(struct drm_device *dev)
struct intel_framebuffer *intel_fb;
struct drm_i915_gem_object *obj;
int enable_fbc;
+ unsigned int max_hdisplay, max_vdisplay;
if (!i915_powersave)
return;
@@ -507,8 +508,16 @@ void intel_update_fbc(struct drm_device *dev)
dev_priv-no_fbc_reason = FBC_UNSUPPORTED_MODE;
goto out_disable;
}
- if ((crtc-mode.hdisplay 2048) ||
- (crtc-mode.vdisplay 1536)) {
+
+ if (IS_G4X(dev) || INTEL_INFO(dev)-gen 4) {
Bikeshed-time: I prefer gen checks to be of the form gen = x or gen
y because:
- It looks more like C code should look like.
- We we talk about platform ranges we tend to use e.g. ilk+ and
pre-gen6, so would fit more naturally with the written word.
Patch looks good otherwise, but for a bit I was thinking wait, g4x is
gen4, what's going on here? ...
Yeah, you're right. I was trying to find out how do I check for
Cantiga+? and basically copied the line I found inside
intel_crtc_compute_config. We could really have a map between these
older codenames and our checks somewhere.
We should maybe also have some feature macro for ctg+ display. Much
of the north display changed already for ctg rather than ilk.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: update FBC maximum fb sizes
From: Paulo Zanoni paulo.r.zan...@intel.com
CTG/ILK/SNB/IVB support 4kx2k surfaces. HSW supports 4kx4k, but
without proper front buffer invalidation on the last 2k lines, so
don't enable FBC on these cases for now.
v2: Use gen = 5, not gen 4 (Daniel).
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4126fb1..1db2a57 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -431,7 +431,7 @@ void intel_disable_fbc(struct drm_device *dev)
* - no pixel mulitply/line duplication
* - no alpha buffer discard
* - no dual wide
- * - framebuffer = 2048 in width, 1536 in height
+ * - framebuffer = max_hdisplay in width, max_vdisplay in height
*
* We can't assume that any compression will take place (worst case),
* so the compressed buffer has to be the same size as the uncompressed
@@ -449,6 +449,7 @@ void intel_update_fbc(struct drm_device *dev)
struct intel_framebuffer *intel_fb;
struct drm_i915_gem_object *obj;
int enable_fbc;
+ unsigned int max_hdisplay, max_vdisplay;
if (!i915_powersave)
return;
@@ -507,8 +508,16 @@ void intel_update_fbc(struct drm_device *dev)
dev_priv-no_fbc_reason = FBC_UNSUPPORTED_MODE;
goto out_disable;
}
- if ((crtc-mode.hdisplay 2048) ||
- (crtc-mode.vdisplay 1536)) {
+
+ if (IS_G4X(dev) || INTEL_INFO(dev)-gen = 5) {
+ max_hdisplay = 4096;
+ max_vdisplay = 2048;
+ } else {
+ max_hdisplay = 2048;
+ max_vdisplay = 1536;
+ }
+ if ((crtc-mode.hdisplay max_hdisplay) ||
+ (crtc-mode.vdisplay max_vdisplay)) {
DRM_DEBUG_KMS(mode too large for compression, disabling\n);
dev_priv-no_fbc_reason = FBC_MODE_TOO_LARGE;
goto out_disable;
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/34] PPGTT prep part 2 (and unmerged part 1)
On Sat, May 25, 2013 at 12:26:34PM -0700, Ben Widawsky wrote: Hello. I'm continuing to develop full PPGTT support for the i915 driver. This series is a follow-up to the previously posted RFC [1]. This series contains reworked versions of the unmerged patches (fingers crossed that I didn't miss review comments). I've rebased this series to hell and back, so I'm sure there are some lingering errors due to that. I've found several, but my eyes are no longer capable of finding them. I've also added some last minute fixups, which I always promise myself I'll never do because they always have bugs. To reiterate the steps I am planning to take which I did this in the previous RFC [1], but it has changed a bit: 1. Make a link between contexts and PPGTT. Every context has it's own address space implemented. 2. Create the VMA/VM, plumb through the driver. 3. Create a context per fd. This involves abstracting the notion of context to not just mean a HW context, but also an address space. 4. Switch address spaces on context switch. 5. Develop interfaces. This patch series addresses steps 1 2. A lot of the future patches should have much less room for debate on what color to paint the bikeshed, so I feel this is a good point to submit for some review. I am currently developing 3 4. I have some half baked patches which aren't really ready, but do give me some notion that things will work. Note that The order of 3 and 4 really matter because if we start switching page tables for applications not using contexts, everything will blow up pretty badly. To not scare off potential reviewers, even though the series is as long as it is, many of the patches really could be squashed. To keep rebase + easier review, I've split things out to multiple steps. 1-5: Random fixes. 6-15: Equivalent to reworked version of the PPGTT prep part 1 6-9: Make PPGTT PDE allocation more generic 10-15: Tie contexts to PPGTT. 16-34: create the VM and VMAs. 16-20: Mostly cut and paste to set us up for future patches. 21-25: Set up the address space abstraction. 26-31: Reorganize code to prepare for VMAs 31-34: are logically one patch. I split them out for my own debug after the enormous patch didn't work. I'm fine with squashing them in to 1 after review, or leaving a large bisect warning (as I've done). I do have a work in progress branch on fd.o [2]. This may not reflect this series 1:1 as it will have rebases, plus some future patches as I feel they are ready. If someone wants a branch on fd.o for review, please let me know. References: [1] http://lists.freedesktop.org/archives/intel-gfx/2013-April/027144.html [2] http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=ppgtt-prep-2 I've forced pushed the following to my repo linked above: Rebased on the latest -nightly as the time. Added a patch to disable ppgtt when on gen6 + vtd. This would have broken in the old series. The patch is a bit tricky in that it will make the code paths identical for PPGTT and non-PPGTT on GEN6, however it won't write the PPGTT enable bits when vt-d is enabled. This patch is untested... Kill guard page first, then move PDEs to a BO. Originally the patches were submitted in the reverse order. Since we already have the PDEs above the guard page, the guard page is immediately killable. Rename gtt_list to global_list. This just clears confusion, and has already been merged by Daniel. Pin and unpin pages at bind/unbind. This will help keep put_pages clean. This too has already been merged by Daniel. -- Ben Widawsky, 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] drm/i915: Track clients and print their object usage in debugfs
On Tue, Jun 04, 2013 at 02:26:19PM +0100, Chris Wilson wrote:
By stashing a pointer of who opened the device and keeping a list of
open fd, we can then walk each client and inspect how many objects they
have open. For example,
i915_gem_objects:
1102 objects, 613646336 bytes
663 [662] objects, 468783104 [468750336] bytes in gtt
37 [37] active objects, 46874624 [46874624] bytes
626 [625] inactive objects, 421908480 [421875712] bytes
282 unbound objects, 6512640 bytes
85 purgeable objects, 6787072 bytes
28 pinned mappable objects, 3686400 bytes
40 fault mappable objects, 27783168 bytes
2145386496 [536870912] gtt total
Xorg: 43 objects, 32243712 bytes (10223616 active, 16683008 inactive, 4096
unbound)
gnome-shell: 30 objects, 28381184 bytes (0 active, 28336128 inactive, 0
unbound)
xonotic-linux64: 1032 objects, 569933824 bytes (46874624 active, 383545344
inactive, 6508544 unbound)
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 41
+++
drivers/gpu/drm/i915/i915_dma.c | 18 ---
drivers/gpu/drm/i915/i915_drv.h |5 -
drivers/gpu/drm/i915/i915_gem.c |1 +
4 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0e7e3c0..6c95e17 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -196,6 +196,32 @@ static int i915_gem_object_list_info(struct seq_file *m,
void *data)
} \
} while (0)
+struct file_stats {
+ int count;
+ size_t total, active, inactive, unbound;
+};
+
+static int per_file_stats(int id, void *ptr, void *data)
+{
+ struct drm_i915_gem_object *obj = ptr;
+ struct file_stats *stats = data;
+
+ stats-count++;
+ stats-total += obj-base.size;
+
+ if (obj-gtt_space) {
+ if (!list_empty(obj-ring_list))
+ stats-active += obj-base.size;
+ else
+ stats-inactive += obj-base.size;
+ } else {
+ if (!list_empty(obj-global_list))
+ stats-unbound += obj-base.size;
+ }
+
+ return 0;
+}
+
static int i915_gem_object_info(struct seq_file *m, void* data)
{
struct drm_info_node *node = (struct drm_info_node *) m-private;
@@ -204,6 +230,7 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
u32 count, mappable_count, purgeable_count;
size_t size, mappable_size, purgeable_size;
struct drm_i915_gem_object *obj;
+ struct drm_i915_file_private *file;
int ret;
ret = mutex_lock_interruptible(dev-struct_mutex);
@@ -263,6 +290,20 @@ static int i915_gem_object_info(struct seq_file *m,
void* data)
dev_priv-gtt.total,
dev_priv-gtt.mappable_end - dev_priv-gtt.start);
+ seq_printf(m, \n);
+ list_for_each_entry(file, dev_priv-clients, link) {
+ struct file_stats stats;
+ memset(stats, 0, sizeof(stats));
+ idr_for_each(file-base-object_idr, per_file_stats, stats);
+ seq_printf(m, %s: %u objects, %zu bytes (%zu active, %zu
inactive, %zu unbound)\n,
+file-task-comm,
+stats.count,
+stats.total,
+stats.active,
+stats.inactive,
+stats.unbound);
+ }
+
Isn't this already tracked in the drm_device, dev-filelist? I think we
can just use that instead, no?
mutex_unlock(dev-struct_mutex);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index ad4c493..a2d511f 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1805,6 +1805,7 @@ int i915_driver_unload(struct drm_device *dev)
int i915_driver_open(struct drm_device *dev, struct drm_file *file)
{
+ struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_file_private *file_priv;
DRM_DEBUG_DRIVER(\n);
@@ -1813,12 +1814,18 @@ int i915_driver_open(struct drm_device *dev, struct
drm_file *file)
return -ENOMEM;
file-driver_priv = file_priv;
+ file_priv-base = file;
spin_lock_init(file_priv-mm.lock);
INIT_LIST_HEAD(file_priv-mm.request_list);
idr_init(file_priv-context_idr);
+ file_priv-task = current;
+ mutex_lock(dev-struct_mutex);
+ list_add_tail(file_priv-link, dev_priv-clients);
+ mutex_unlock(dev-struct_mutex);
+
return 0;
}
@@ -1855,10 +1862,15 @@ void i915_driver_lastclose(struct drm_device * dev)
i915_dma_cleanup(dev);
}
-void i915_driver_preclose(struct drm_device * dev, struct drm_file
*file_priv)
+void i915_driver_preclose(struct drm_device * dev, struct drm_file
[Intel-gfx] [PATCH] drm/i915: Track clients and print their object usage in debugfs
By stashing a pointer of who opened the device and keeping a list of
open fd, we can then walk each client and inspect how many objects they
have open. For example,
i915_gem_objects:
1102 objects, 613646336 bytes
663 [662] objects, 468783104 [468750336] bytes in gtt
37 [37] active objects, 46874624 [46874624] bytes
626 [625] inactive objects, 421908480 [421875712] bytes
282 unbound objects, 6512640 bytes
85 purgeable objects, 6787072 bytes
28 pinned mappable objects, 3686400 bytes
40 fault mappable objects, 27783168 bytes
2145386496 [536870912] gtt total
Xorg: 43 objects, 32243712 bytes (10223616 active, 16683008 inactive, 4096
unbound)
gnome-shell: 30 objects, 28381184 bytes (0 active, 28336128 inactive, 0 unbound)
xonotic-linux64: 1032 objects, 569933824 bytes (46874624 active, 383545344
inactive, 6508544 unbound)
v2: Use existing drm-filelist as pointed out by Ben.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 43 +++
drivers/gpu/drm/i915/i915_dma.c |2 ++
drivers/gpu/drm/i915/i915_drv.h |2 +-
3 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0e7e3c0..9d45552 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -196,6 +196,32 @@ static int i915_gem_object_list_info(struct seq_file *m,
void *data)
} \
} while (0)
+struct file_stats {
+ int count;
+ size_t total, active, inactive, unbound;
+};
+
+static int per_file_stats(int id, void *ptr, void *data)
+{
+ struct drm_i915_gem_object *obj = ptr;
+ struct file_stats *stats = data;
+
+ stats-count++;
+ stats-total += obj-base.size;
+
+ if (obj-gtt_space) {
+ if (!list_empty(obj-ring_list))
+ stats-active += obj-base.size;
+ else
+ stats-inactive += obj-base.size;
+ } else {
+ if (!list_empty(obj-global_list))
+ stats-unbound += obj-base.size;
+ }
+
+ return 0;
+}
+
static int i915_gem_object_info(struct seq_file *m, void* data)
{
struct drm_info_node *node = (struct drm_info_node *) m-private;
@@ -204,6 +230,7 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
u32 count, mappable_count, purgeable_count;
size_t size, mappable_size, purgeable_size;
struct drm_i915_gem_object *obj;
+ struct drm_file *file;
int ret;
ret = mutex_lock_interruptible(dev-struct_mutex);
@@ -263,6 +290,22 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
dev_priv-gtt.total,
dev_priv-gtt.mappable_end - dev_priv-gtt.start);
+ seq_printf(m, \n);
+ list_for_each_entry_reverse(file, dev-filelist, lhead) {
+ struct drm_i915_file_private *file_priv = file-driver_priv;
+ struct file_stats stats;
+
+ memset(stats, 0, sizeof(stats));
+ idr_for_each(file-object_idr, per_file_stats, stats);
+ seq_printf(m, %s: %u objects, %zu bytes (%zu active, %zu
inactive, %zu unbound)\n,
+ file_priv-task-comm,
+ stats.count,
+ stats.total,
+ stats.active,
+ stats.inactive,
+ stats.unbound);
+ }
+
mutex_unlock(dev-struct_mutex);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index ad4c493..e3ac0e6 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1819,6 +1819,8 @@ int i915_driver_open(struct drm_device *dev, struct
drm_file *file)
idr_init(file_priv-context_idr);
+ file_priv-task = current;
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 496cd37..8497dc9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1068,7 +1068,6 @@ typedef struct drm_i915_private {
struct mutex modeset_restore_lock;
struct i915_gtt gtt;
-
struct i915_gem_mm mm;
/* Kernel Modesetting */
@@ -1352,6 +1351,7 @@ struct drm_i915_gem_request {
};
struct drm_i915_file_private {
+ struct task_struct *task;
struct {
spinlock_t lock;
struct list_head request_list;
--
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/i915: Track clients and print their object usage in debugfs
By stashing a pointer of who opened the device and keeping a list of
open fd, we can then walk each client and inspect how many objects they
have open. For example,
i915_gem_objects:
1102 objects, 613646336 bytes
663 [662] objects, 468783104 [468750336] bytes in gtt
37 [37] active objects, 46874624 [46874624] bytes
626 [625] inactive objects, 421908480 [421875712] bytes
282 unbound objects, 6512640 bytes
85 purgeable objects, 6787072 bytes
28 pinned mappable objects, 3686400 bytes
40 fault mappable objects, 27783168 bytes
2145386496 [536870912] gtt total
Xorg: 43 objects, 32243712 bytes (10223616 active, 16683008 inactive, 4096
unbound)
gnome-shell: 30 objects, 28381184 bytes (0 active, 28336128 inactive, 0 unbound)
xonotic-linux64: 1032 objects, 569933824 bytes (46874624 active, 383545344
inactive, 6508544 unbound)
v2: Use existing drm-filelist as pointed out by Ben.
v3: Not even stashing the task_struct is required as Ben pointed out
drm_file-pid.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 42 +++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0e7e3c0..d4e78b6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -196,6 +196,32 @@ static int i915_gem_object_list_info(struct seq_file *m,
void *data)
} \
} while (0)
+struct file_stats {
+ int count;
+ size_t total, active, inactive, unbound;
+};
+
+static int per_file_stats(int id, void *ptr, void *data)
+{
+ struct drm_i915_gem_object *obj = ptr;
+ struct file_stats *stats = data;
+
+ stats-count++;
+ stats-total += obj-base.size;
+
+ if (obj-gtt_space) {
+ if (!list_empty(obj-ring_list))
+ stats-active += obj-base.size;
+ else
+ stats-inactive += obj-base.size;
+ } else {
+ if (!list_empty(obj-global_list))
+ stats-unbound += obj-base.size;
+ }
+
+ return 0;
+}
+
static int i915_gem_object_info(struct seq_file *m, void* data)
{
struct drm_info_node *node = (struct drm_info_node *) m-private;
@@ -204,6 +230,7 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
u32 count, mappable_count, purgeable_count;
size_t size, mappable_size, purgeable_size;
struct drm_i915_gem_object *obj;
+ struct drm_file *file;
int ret;
ret = mutex_lock_interruptible(dev-struct_mutex);
@@ -263,6 +290,21 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
dev_priv-gtt.total,
dev_priv-gtt.mappable_end - dev_priv-gtt.start);
+ seq_printf(m, \n);
+ list_for_each_entry_reverse(file, dev-filelist, lhead) {
+ struct file_stats stats;
+
+ memset(stats, 0, sizeof(stats));
+ idr_for_each(file-object_idr, per_file_stats, stats);
+ seq_printf(m, %s: %u objects, %zu bytes (%zu active, %zu
inactive, %zu unbound)\n,
+ get_pid_task(file-pid, PIDTYPE_PID)-comm,
+ stats.count,
+ stats.total,
+ stats.active,
+ stats.inactive,
+ stats.unbound);
+ }
+
mutex_unlock(dev-struct_mutex);
return 0;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Track clients and print their object usage in debugfs
On Tue, Jun 04, 2013 at 11:18:03PM +0100, Chris Wilson wrote:
By stashing a pointer of who opened the device and keeping a list of
open fd, we can then walk each client and inspect how many objects they
have open. For example,
i915_gem_objects:
1102 objects, 613646336 bytes
663 [662] objects, 468783104 [468750336] bytes in gtt
37 [37] active objects, 46874624 [46874624] bytes
626 [625] inactive objects, 421908480 [421875712] bytes
282 unbound objects, 6512640 bytes
85 purgeable objects, 6787072 bytes
28 pinned mappable objects, 3686400 bytes
40 fault mappable objects, 27783168 bytes
2145386496 [536870912] gtt total
Xorg: 43 objects, 32243712 bytes (10223616 active, 16683008 inactive, 4096
unbound)
gnome-shell: 30 objects, 28381184 bytes (0 active, 28336128 inactive, 0
unbound)
xonotic-linux64: 1032 objects, 569933824 bytes (46874624 active, 383545344
inactive, 6508544 unbound)
v2: Use existing drm-filelist as pointed out by Ben.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 43
+++
drivers/gpu/drm/i915/i915_dma.c |2 ++
drivers/gpu/drm/i915/i915_drv.h |2 +-
3 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0e7e3c0..9d45552 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -196,6 +196,32 @@ static int i915_gem_object_list_info(struct seq_file *m,
void *data)
} \
} while (0)
+struct file_stats {
+ int count;
+ size_t total, active, inactive, unbound;
+};
+
+static int per_file_stats(int id, void *ptr, void *data)
+{
+ struct drm_i915_gem_object *obj = ptr;
+ struct file_stats *stats = data;
+
+ stats-count++;
+ stats-total += obj-base.size;
+
+ if (obj-gtt_space) {
+ if (!list_empty(obj-ring_list))
+ stats-active += obj-base.size;
+ else
+ stats-inactive += obj-base.size;
+ } else {
+ if (!list_empty(obj-global_list))
+ stats-unbound += obj-base.size;
+ }
+
+ return 0;
+}
+
static int i915_gem_object_info(struct seq_file *m, void* data)
{
struct drm_info_node *node = (struct drm_info_node *) m-private;
@@ -204,6 +230,7 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
u32 count, mappable_count, purgeable_count;
size_t size, mappable_size, purgeable_size;
struct drm_i915_gem_object *obj;
+ struct drm_file *file;
int ret;
ret = mutex_lock_interruptible(dev-struct_mutex);
@@ -263,6 +290,22 @@ static int i915_gem_object_info(struct seq_file *m,
void* data)
dev_priv-gtt.total,
dev_priv-gtt.mappable_end - dev_priv-gtt.start);
+ seq_printf(m, \n);
+ list_for_each_entry_reverse(file, dev-filelist, lhead) {
+ struct drm_i915_file_private *file_priv = file-driver_priv;
+ struct file_stats stats;
+
+ memset(stats, 0, sizeof(stats));
+ idr_for_each(file-object_idr, per_file_stats, stats);
+ seq_printf(m, %s: %u objects, %zu bytes (%zu active, %zu
inactive, %zu unbound)\n,
+file_priv-task-comm,
+stats.count,
+stats.total,
+stats.active,
+stats.inactive,
+stats.unbound);
+ }
+
mutex_unlock(dev-struct_mutex);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index ad4c493..e3ac0e6 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1819,6 +1819,8 @@ int i915_driver_open(struct drm_device *dev, struct
drm_file *file)
idr_init(file_priv-context_idr);
+ file_priv-task = current;
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 496cd37..8497dc9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1068,7 +1068,6 @@ typedef struct drm_i915_private {
struct mutex modeset_restore_lock;
struct i915_gtt gtt;
-
struct i915_gem_mm mm;
/* Kernel Modesetting */
This hunk probably doesn't belong here.
@@ -1352,6 +1351,7 @@ struct drm_i915_gem_request {
};
struct drm_i915_file_private {
+ struct task_struct *task;
struct {
spinlock_t lock;
struct list_head request_list;
Reviewed-by: Ben Widawsky b...@bwidawsk.net
--
Ben Widawsky, 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] drm/i915: Track clients and print their object usage in debugfs
On Tue, Jun 04, 2013 at 11:49:08PM +0100, Chris Wilson wrote: By stashing a pointer of who opened the device and keeping a list of open fd, we can then walk each client and inspect how many objects they have open. For example, i915_gem_objects: 1102 objects, 613646336 bytes 663 [662] objects, 468783104 [468750336] bytes in gtt 37 [37] active objects, 46874624 [46874624] bytes 626 [625] inactive objects, 421908480 [421875712] bytes 282 unbound objects, 6512640 bytes 85 purgeable objects, 6787072 bytes 28 pinned mappable objects, 3686400 bytes 40 fault mappable objects, 27783168 bytes 2145386496 [536870912] gtt total Xorg: 43 objects, 32243712 bytes (10223616 active, 16683008 inactive, 4096 unbound) gnome-shell: 30 objects, 28381184 bytes (0 active, 28336128 inactive, 0 unbound) xonotic-linux64: 1032 objects, 569933824 bytes (46874624 active, 383545344 inactive, 6508544 unbound) v2: Use existing drm-filelist as pointed out by Ben. v3: Not even stashing the task_struct is required as Ben pointed out drm_file-pid. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Ben Widawsky b...@bwidawsk.net - Ben Widawsky, 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] drm: Add kernel-doc for plane functions
Hi Ville,
Thank you for the patch.
On Tuesday 04 June 2013 10:58:35 ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_crtc.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f00ba75..f1f11e1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -795,6 +795,21 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
}
EXPORT_SYMBOL(drm_encoder_cleanup);
+/**
+ * drm_plane_init - Initialise a new plane object
+ * @dev: DRM device
+ * @plane: plane object to init
+ * @possible_crtcs: bitmask of possible CRTCs
+ * @funcs: callbacks for the new plane
+ * @formats: array of supported formats (%DRM_FORMAT_*)
+ * @format_count: number of elements in @formats
+ * @priv: plane is private (hidden from userspace)?
+ *
+ * Inits a new object created as base part of an driver plane object.
s/an driver/a driver/
+ *
+ * RETURNS:
+ * Zero on success, error code on failure.
+ */
int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
unsigned long possible_crtcs,
const struct drm_plane_funcs *funcs,
@@ -843,6 +858,13 @@ int drm_plane_init(struct drm_device *dev, struct
drm_plane *plane, }
EXPORT_SYMBOL(drm_plane_init);
+/**
+ * drm_plane_cleanup - Cleans up the core plane usage.
Nitpicking, you could remove the full stop at the end of the line to be
consistent with the other two kerneldoc blocks.
And s/Cleans/Clean/
+ * @plane: plane to cleanup
+ *
+ * Cleanup @plane. Removes from drm modesetting space
+ * does NOT free object, caller does that.
As this is documentation, I'd use a more verbose style.
This function clean up @plane and removes it from the DRM mode setting core.
Note that the function does *not* free the plane structure itself, this is the
responsibility of the caller.
+ */
void drm_plane_cleanup(struct drm_plane *plane)
{
struct drm_device *dev = plane-dev;
@@ -859,6 +881,15 @@ void drm_plane_cleanup(struct drm_plane *plane)
}
EXPORT_SYMBOL(drm_plane_cleanup);
+/**
+ * drm_plane_force_disable - Forcibly disable a plane
+ * @plane: plane to disable
+ *
+ * Forces the plane to be disabled.
This feels a bit unclear to me. In particular, how is force_disable
different from just disabling the plane ? Maybe the function should be renamed
to drm_plane_disable(), and the documentation updated to mention that the
function just disables the plane and disassociate with from its frame buffer.
+ *
+ * Used when the plane's current framebuffer is destroyed,
+ * and when restoring fbdev mode.
+ */
void drm_plane_force_disable(struct drm_plane *plane)
{
int ret;
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
