Re: [Intel-gfx] [PATCH] drm/i915: move encoder-mode_set calls to crtc_mode_set
On Wed, Oct 31, 2012 at 10:46:36PM +, Chris Wilson wrote: On Wed, 31 Oct 2012 19:26:13 +0100, Daniel Vetter daniel.vet...@ffwll.ch wrote: Makes more sense to group the entire mode_set stage into one function. Noticed while discussiing the rather confusing set of function names with Paulo Zanoni. Unfortunately I don't have an idea to make the function names lesss confusion. v2: Use for_each_encoder_on_crtc as suggested by Chris Wilson. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Just a simple piece of code movement, with a sprinkling of sugar on top. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Queued for -next, thanks for the review. -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 1/2] drm/i915: Kill i915_gem_execbuffer_wait_for_flips()
On Wed, 31 Oct 2012 17:18:47 -0700, Eric Anholt e...@anholt.net wrote: ville.syrj...@linux.intel.com writes: From: Ville Syrjälä ville.syrj...@linux.intel.com As per Chris Wilson's suggestion make i915_gem_execbuffer_wait_for_flips() go away. This was used to stall the GPU ring while there are pending page flips involving the relevant BO. Ie. while the BO is still being scanned out by the display controller. The recommended alternative is to use the page flip events to wait for the page flips to fully complete before reusing the BO of the old front buffer. Or use more buffers. So, after this change, if userland submits an execbuf between having requested a pageflip and the vblank that the flip shows up on, does that exec block? The code itself is dysfunctional and would cause a GPU hang on snb/ivb. Why should the kernel be imposing a policy upon userspace where none is required? -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] [pull] drm-intel-fixes
Hi Dave, Nothing big at all for -fixes, just small stuff: - Two patches to fix bugs on i830M - ums regression fixer due to kicking firmeware fbs (Chris) - tune down a too loud warning (Jani) - be more careful with sdvo infoframes, which fixes a long-standing sdvo-hdmi regression Cheers, Daniel The following changes since commit b8e902f24fdd16c4373ddc37a4e150c4afe9c6db: drm/ttm: Fix a theoretical race in ttm_bo_cleanup_refs() (2012-10-23 10:15:21 +1000) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to 1623392af9da983f3ad088a75076c9da05e5600d: drm/i915: Only kick out vesafb if we takeover the fbcon with KMS (2012-10-26 17:46:35 +0200) Chris Wilson (1): drm/i915: Only kick out vesafb if we takeover the fbcon with KMS Daniel Vetter (3): drm/i915: fix overlay on i830M drm/i915: VGA needs to be on pipe A on i830M drm/i915: clear the entire sdvo infoframe buffer Jani Nikula (1): drm/i915: be less verbose about inability to provide vendor backlight drivers/gpu/drm/i915/i915_dma.c|3 +- drivers/gpu/drm/i915/intel_crt.c |2 +- drivers/gpu/drm/i915/intel_overlay.c | 14 ++-- drivers/gpu/drm/i915/intel_panel.c |2 +- drivers/gpu/drm/i915/intel_sdvo.c | 62 +--- drivers/gpu/drm/i915/intel_sdvo_regs.h |2 ++ 6 files changed, 59 insertions(+), 26 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
Re: [Intel-gfx] [PATCH 1/2] drm: fix order of event_lock wrt. vblank_time_clock
On Thu, 2012-11-01 at 00:03 +0200, Imre Deak wrote:
drm_vblank_off() requires callers to hold the event_lock, while itself
locking vbl_time and vblank_time_lock. This defines a dependency chain
that conflicts with the one in drm_handle_vblank() where we first lock
vblank_time_lock and then the event_lock. Fix this by reversing the
locking order in drm_handle_vblank().
This should've triggered a lockdep warning in the exynos driver, the
rest of the drivers were ok, since they are not using drm_vblank_off(),
or as in the case of the intel driver were not holding the event_lock
when calling drm_vblank_off(). This latter issue is addressed in the
next patch.
I just realized this is better solved by fixing the lock order in the
exynos driver. That way we can take the event_lock close to what it
really locks. Fixing things there will also leave the other drivers
unaffected.
I'll follow up with v2 doing this.
--Imre
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/drm_irq.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
Tested with i915, the rest of the drivers should be checked with
lockdep enabled.
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3a3d0ce..2193d4a 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1236,17 +1236,21 @@ done:
return ret;
}
+/**
+ * drm_handle_vblank_events - send pending vblank events
+ * @dev: DRM device
+ * @crtc: crtc where the vblank(s) happened
+ *
+ * Must be called with @dev-event_lock held.
+ */
static void drm_handle_vblank_events(struct drm_device *dev, int crtc)
{
struct drm_pending_vblank_event *e, *t;
struct timeval now;
- unsigned long flags;
unsigned int seq;
seq = drm_vblank_count_and_time(dev, crtc, now);
- spin_lock_irqsave(dev-event_lock, flags);
-
list_for_each_entry_safe(e, t, dev-vblank_event_list, base.link) {
if (e-pipe != crtc)
continue;
@@ -1266,8 +1270,6 @@ static void drm_handle_vblank_events(struct drm_device
*dev, int crtc)
e-event.sequence);
}
- spin_unlock_irqrestore(dev-event_lock, flags);
-
trace_drm_vblank_event(crtc, seq);
}
@@ -1285,21 +1287,22 @@ bool drm_handle_vblank(struct drm_device *dev, int
crtc)
s64 diff_ns;
struct timeval tvblank;
unsigned long irqflags;
+ bool ret = false;
if (!dev-num_crtcs)
return false;
+ spin_lock_irqsave(dev-event_lock, irqflags);
+
/* Need timestamp lock to prevent concurrent execution with
* vblank enable/disable, as this would cause inconsistent
* or corrupted timestamps and vblank counts.
*/
- spin_lock_irqsave(dev-vblank_time_lock, irqflags);
+ spin_lock(dev-vblank_time_lock);
/* Vblank irq handling disabled. Nothing to do. */
- if (!dev-vblank_enabled[crtc]) {
- spin_unlock_irqrestore(dev-vblank_time_lock, irqflags);
- return false;
- }
+ if (!dev-vblank_enabled[crtc])
+ goto unlock_ret;
/* Fetch corresponding timestamp for this vblank interval from
* driver and store it in proper slot of timestamp ringbuffer.
@@ -1340,7 +1343,12 @@ bool drm_handle_vblank(struct drm_device *dev, int
crtc)
DRM_WAKEUP(dev-vbl_queue[crtc]);
drm_handle_vblank_events(dev, crtc);
- spin_unlock_irqrestore(dev-vblank_time_lock, irqflags);
- return true;
+ ret = true;
+
+unlock_ret:
+ spin_unlock(dev-vblank_time_lock);
+ spin_unlock_irqrestore(dev-event_lock, irqflags);
+
+ return ret;
}
EXPORT_SYMBOL(drm_handle_vblank);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Flush outstanding unpin tasks before pageflipping
If we accumulate unpin tasks because we are pageflipping faster than the
system can schedule its workers, we can effectively create a
pin-leak. The solution taken here is to limit the number of unpin tasks
we have per-crtc and to flush those outstanding tasks if we accumulate
too many. This should prevent any jitter in the normal case, and also
prevent the hang if we should run too fast.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46991
Reported-and-tested-by: Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 22 --
drivers/gpu/drm/i915/intel_drv.h |4 +++-
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 69b1739..800b195 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6908,14 +6908,19 @@ static void intel_unpin_work_fn(struct work_struct
*__work)
{
struct intel_unpin_work *work =
container_of(__work, struct intel_unpin_work, work);
+ struct drm_device *dev = work-crtc-dev;
- mutex_lock(work-dev-struct_mutex);
+ mutex_lock(dev-struct_mutex);
intel_unpin_fb_obj(work-old_fb_obj);
drm_gem_object_unreference(work-pending_flip_obj-base);
drm_gem_object_unreference(work-old_fb_obj-base);
- intel_update_fbc(work-dev);
- mutex_unlock(work-dev-struct_mutex);
+ intel_update_fbc(dev);
+ mutex_unlock(dev-struct_mutex);
+
+ BUG_ON(atomic_read(to_intel_crtc(work-crtc)-unpin_work_count) == 0);
+ atomic_dec(to_intel_crtc(work-crtc)-unpin_work_count);
+
kfree(work);
}
@@ -6963,9 +6968,9 @@ static void do_intel_finish_page_flip(struct drm_device
*dev,
atomic_clear_mask(1 intel_crtc-plane,
obj-pending_flip.counter);
-
wake_up(dev_priv-pending_flip_queue);
- schedule_work(work-work);
+
+ queue_work(dev_priv-wq, work-work);
trace_i915_flip_complete(intel_crtc-plane, work-pending_flip_obj);
}
@@ -7266,7 +7271,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
return -ENOMEM;
work-event = event;
- work-dev = crtc-dev;
+ work-crtc = crtc;
intel_fb = to_intel_framebuffer(crtc-fb);
work-old_fb_obj = intel_fb-obj;
INIT_WORK(work-work, intel_unpin_work_fn);
@@ -7291,6 +7296,9 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb-obj;
+ if (atomic_read(intel_crtc-unpin_work_count) = 2)
+ flush_workqueue(dev_priv-wq);
+
ret = i915_mutex_lock_interruptible(dev);
if (ret)
goto cleanup;
@@ -7309,6 +7317,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
* the flip occurs and the object is no longer visible.
*/
atomic_add(1 intel_crtc-plane, work-old_fb_obj-pending_flip);
+ atomic_inc(intel_crtc-unpin_work_count);
ret = dev_priv-display.queue_flip(dev, crtc, fb, obj);
if (ret)
@@ -7323,6 +7332,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
return 0;
cleanup_pending:
+ atomic_dec(intel_crtc-unpin_work_count);
atomic_sub(1 intel_crtc-plane, work-old_fb_obj-pending_flip);
drm_gem_object_unreference(work-old_fb_obj-base);
drm_gem_object_unreference(obj-base);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 164696f..1345c44 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -216,6 +216,8 @@ struct intel_crtc {
} vblank_work;
int fdi_lanes;
+ atomic_t unpin_work_count;
+
/* Display surface base address adjustement for pageflips. Note that on
* gen4+ this only adjusts up to a tile, offsets within a tile are
* handled in the hw itself (with the TILEOFF register). */
@@ -403,7 +405,7 @@ intel_get_crtc_for_plane(struct drm_device *dev, int plane)
struct intel_unpin_work {
struct work_struct work;
- struct drm_device *dev;
+ struct drm_crtc *crtc;
struct drm_i915_gem_object *old_fb_obj;
struct drm_i915_gem_object *pending_flip_obj;
struct drm_pending_vblank_event *event;
--
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 2/2] drm/i915: lock event_lock for drm_vblank_off()
On Wed, 2012-10-31 at 23:46 +0100, Daniel Vetter wrote: On Thu, Nov 01, 2012 at 12:03:39AM +0200, Imre Deak wrote: drm_vblank_off() requires callers to hold the event_lock. Signed-off-by: Imre Deak imre.d...@intel.com Hm, do we put this code through its paces already in flip_test by scheduling a vblank wait in the future (a second or so), and then disabling the display? There isn't such a test case yet, but this bug is triggered with what we have already, the 'wait-for-vblank + dpms off' test. But it might make sense to delay the vblank as you say, in case disabling takes a long time and the vblank arrives before we get to drm_vblank_off(). I can add something for that. --Imre -Daniel --- drivers/gpu/drm/i915/intel_display.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index b453901..56f1119 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3413,6 +3413,7 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc) struct intel_encoder *encoder; int pipe = intel_crtc-pipe; int plane = intel_crtc-plane; + unsigned long flags; u32 reg, temp; @@ -3423,7 +3424,11 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc) encoder-disable(encoder); intel_crtc_wait_for_pending_flips(crtc); + + spin_lock_irqsave(dev-event_lock, flags); drm_vblank_off(dev, pipe); + spin_unlock_irqrestore(dev-event_lock, flags); + intel_crtc_update_cursor(crtc, false); intel_disable_plane(dev_priv, plane, pipe); @@ -3495,6 +3500,7 @@ static void haswell_crtc_disable(struct drm_crtc *crtc) int plane = intel_crtc-plane; enum transcoder cpu_transcoder = intel_crtc-cpu_transcoder; bool is_pch_port; + unsigned long flags; if (!intel_crtc-active) return; @@ -3505,7 +3511,11 @@ static void haswell_crtc_disable(struct drm_crtc *crtc) encoder-disable(encoder); intel_crtc_wait_for_pending_flips(crtc); + + spin_lock_irqsave(dev-event_lock, flags); drm_vblank_off(dev, pipe); + spin_unlock_irqrestore(dev-event_lock, flags); + intel_crtc_update_cursor(crtc, false); intel_disable_plane(dev_priv, plane, pipe); @@ -3617,6 +3627,7 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc) struct intel_encoder *encoder; int pipe = intel_crtc-pipe; int plane = intel_crtc-plane; + unsigned long flags; if (!intel_crtc-active) @@ -3627,7 +3638,11 @@ 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); + + spin_lock_irqsave(dev-event_lock, flags); drm_vblank_off(dev, pipe); + spin_unlock_irqrestore(dev-event_lock, flags); + intel_crtc_dpms_overlay(intel_crtc, false); intel_crtc_update_cursor(crtc, false); -- 1.7.9.5 ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/doc: integrate crtc helper api into docbook
Hi Daniel,
Thanks for the patch.
(text reflowed for review purpose to fit the e-mail line length limit)
On Wednesday 31 October 2012 10:11:48 Daniel Vetter wrote:
- Add the missing doc for drm_helper_move_panel_connectors_to_head.
- Fixup any outdated stuff in existing sections. I've only looked at
those kerneldoc headers that actually resulted in a complaint from
the kerneldoc parser tool.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
After fixing the small mistake below,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/DocBook/drm.tmpl| 4 +++
drivers/gpu/drm/drm_crtc_helper.c | 54
2 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index ca45155..43e706e 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2106,6 +2106,10 @@ void intel_crt_init(struct drm_device *dev)
/listitem
/itemizedlist
/sect2
+sect2
+ titleModeset Helper Functions Reference/title
+!Edrivers/gpu/drm/drm_crtc_helper.c
+/sect2
/sect1
!-- Internals: vertical blanking --
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c index 1021f505..e2e19ef 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -92,22 +92,21 @@ static void drm_mode_validate_flag(struct drm_connector
*connector,
/**
* drm_helper_probe_single_connector_modes - get complete set of display
* modes
- * @dev: DRM device
+ * @connector: connector to probe
* @maxX: max width for modes
* @maxY: max height for modes
*
* LOCKING:
* Caller must hold mode config lock.
*
- * Based on @dev's mode_config layout, scan all the connectors and try to
- * detect modes on them. Modes will first be added to the connector's
- * probed_modes list, then culled (based on validity and the @maxX, @maxY
- * parameters) and put into the normal modes list.
- *
- * Intended to be used either at bootup time or when major configuration
- * changes have occurred.
+ * Based on the helper callbacks implemented by @connector try to detect
+ * all valid modes. Modes will first be added to the connector's
+ * probed_modes list, then culled (based on validity and the @maxX, @maxY
+ * parameters) and put into the normal modes list.
*
- * FIXME: take into account monitor limits
+ * Intended to be use as a generic implementation of the -probe()
+ * @connector callback for drivers that use the crtc helpers for output
+ * mode filtering and conector detection.
*
* RETURNS:
* Number of modes found on @connector.
@@ -353,17 +352,23 @@ drm_crtc_prepare_encoders(struct drm_device *dev)
}
/**
- * drm_crtc_set_mode - set a mode
+ * drm_crtc_set_mode - internal helper to set a mode
The function is actually now called drm_crtc_helper_set_mode.
* @crtc: CRTC to program
* @mode: mode to use
* @x: width of mode
* @y: height of mode
+ * @old_fb: old framebuffer, for cleanup
*
* LOCKING:
* Caller must hold mode config lock.
*
* Try to set @mode on @crtc. Give @crtc and its associated connectors a
- * chance to fixup or reject the mode prior to trying to set it.
+ * chance to fixup or reject the mode prior to trying to set it. This is an
+ * internal helper that drivers could e.g. use to update properties that
+ * require the entire output pipe to be disabled and re-enabled in a new
+ * configuration. For example for changing whether audio is enabled on a
+ * hdmi link or for changing panel fitter or dither attributes. It is also
+ * called by the drm_crtc_helper_set_config() helper function.
*
* RETURNS:
* True if the mode was set successfully, or false otherwise.
@@ -519,20 +524,19 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
/**
* drm_crtc_helper_set_config - set a new config from userspace
- * @crtc: CRTC to setup
- * @crtc_info: user provided configuration
- * @new_mode: new mode to set
- * @connector_set: set of connectors for the new config
- * @fb: new framebuffer
+ * @set: mode set configuration
*
* LOCKING:
* Caller must hold mode config lock.
*
- * Setup a new configuration, provided by the user in @crtc_info, and
- * enable it.
+ * Setup a new configuration, provided by the upper layers (either an ioctl
+ * call from userspace or internally e.g. from the fbdev suppport code) in
+ * @set, and enable it. This is the main helper functions for drivers that
+ * implement kernel mode setting with the crtc helper functions and the
+ * assorted -prepare(), -modeset() and -commit() interfaces.
*
* RETURNS:
- * Zero. (FIXME)
+ * Returns 0 on success, -ERRNO on failure.
*/
int drm_crtc_helper_set_config(struct drm_mode_set *set)
{
@@ -828,12 +832,14 @@ static int drm_helper_choose_crtc_dpms(struct drm_crtc
*crtc) }
/**
Re: [Intel-gfx] [PATCH 4/4] drm/doc: add new dp helpers into drm DocBook
Hi Daniel,
Thanks for the patch.
On Wednesday 31 October 2012 10:11:50 Daniel Vetter wrote:
I didn't bother with documenting the really trivial new extract
something from dpcd helpers, but the i2c over aux ch is now
documented a bit.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
Documentation/DocBook/drm.tmpl | 6 ++
drivers/gpu/drm/drm_dp_helper.c | 20
include/drm/drm_dp_helper.h | 7 +++
3 files changed, 33 insertions(+)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 15729eb..71edb57 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2115,6 +2115,12 @@ void intel_crt_init(struct drm_device *dev)
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
!Edrivers/gpu/drm/drm_fb_helper.c
/sect2
+sect2
+ titleDisplay Port Helper Functions Reference/title
+!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
+!Iinclude/drm/drm_dp_helper.h
+!Edrivers/gpu/drm/drm_dp_helper.c
+/sect2
/sect1
!-- Internals: vertical blanking --
diff --git a/drivers/gpu/drm/drm_dp_helper.c
b/drivers/gpu/drm/drm_dp_helper.c index 3c4cccd..2ff6482 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -30,6 +30,15 @@
#include drm/drm_dp_helper.h
#include drm/drmP.h
+/**
+ * DOC: dp helpers
+ *
+ * These functions contain some come logic and helpers at various
s/come/core/
+ * abstraction levels to deal with Display Port sink devices and related
+ * things like DP aux channel transfers, EDID reading over DP aux channels,
+ * decoding certain DPCD blocks, ...
+ */
+
/* Run a single AUX_CH I2C transaction, writing/reading data as necessary
*/ static int
i2c_algo_dp_aux_transaction(struct i2c_adapter *adapter, int mode,
@@ -193,6 +202,17 @@ i2c_dp_aux_prepare_bus(struct i2c_adapter *adapter)
return 0;
}
+/**
+ * i2c_dp_aux_add_bus() - register a i2c adaptar using the aux ch helper
s/a i2c adaptar/an I2C adapter/
(feel free to drop the caps if preferred)
+ * @adapter: i2c adapter to register
+ *
+ * This registers an i2c adapater that uses dp aux channel as it's
+ * underlaying transport. The driver needs to fill out the
+ * i2c_algo_dp_aux_data structure which will be used by the the i2c over
s/the the/the/
+ * dp aux algo.
s/algo/algorithm/ ?
+ *
+ * RETURNS:
+ * 0 on success, -ERRNO on failure.
+ */
int
i2c_dp_aux_add_bus(struct i2c_adapter *adapter)
{
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c09d367..3f94ede 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -312,6 +312,13 @@
#define MODE_I2C_READ4
#define MODE_I2C_STOP8
+/**
+ * struct i2c_algo_dp_aux_data - driver interface structure for i2c over dp
+ * aux algo
s/algo/algorithm/ ?
+ * @running: set by the algo indicating whether an i2c is ongoing or
+ * whether the i2c bus is quiescent
+ * @address: i2c target address for the currently ongoing transfer
+ * @aux_ch: driver callback to transfer a single byte of the i2c payload
+ */
struct i2c_algo_dp_aux_data {
bool running;
u16 address;
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [QA 11/01] Testing report for `drm-intel-testing` (was: Updated -next)
Summary We finished a new round of kernel testing. Generally, in this circle, 1 new bug is filed, 11 bugs are still opened,3 bugs are closed. Test Environment Kernel: (drm-intel-testing)b9960e75b5a348759c6e8c9ffb3f45e40ad702a5 Some additional commit info: Merge: 8e740cd 1623392 Author: Daniel Vetter daniel.vet...@ffwll.chmailto:daniel.vet...@ffwll.ch Date: Fri Oct 26 21:10:48 2012 +0200 Hardware We covered the platform: IvyBridge, SandyBridge, IronLake, G45 and Pineview Findings New Bug: Bug 56568https://bugs.freedesktop.org/show_bug.cgi?id=56568 - [IVB] 3-pipe (VGA + 2 DVI) fail to work Opened Bugs: Bug 36997https://bugs.freedesktop.org/show_bug.cgi?id=36997 - [G45 SDVO] TV can't display -- SDVO xfer fails due to Pending. Bug 41976 - [IVB] screen turn to be black while switching between console and x-window with 3-pipe active Bug 42194 - [IVB/SNB] coldplug new monitors for fbcon on lastclose() Bug 44309 - [IVB eDP] 3 pipe doesn't work with eDP monitor Bug 45729 - [bisected regression] Incorrect Mode Timing on DP Display, with 3.3-rc (due to interlaced CEA modes) Bug 50569 - [ILK] System reboot after S4 Bug 51975 - [IVB]can't find the HDMI audio device Bug 55271 - [ILK regression] DP fail to light up after S4 with X and glxgears Bug 52424 - [Bisected SNB Regression] glxgears causes GPU hung Bug 54111 - [IVB]I-G-T/module_reload fail with *ERROR* Memory manager not clean. Delaying takedown Bug 54764 - [ILK regression] DP display some mode not able to light up Closed Bug: Bug 54253 - [SNB]eDP can't work while booting with miniVGA Bug 55268 - [SNB] eDP can't light up after reboot with micro HDMI Bug 55276 - [SNB regression]some dp display modes can't light up Thanks --Sun, Yi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm/i915: Fix display pixel format handling
On Wed, Oct 31, 2012 at 01:20:23PM -0700, Jesse Barnes wrote: On Wed, 31 Oct 2012 17:50:14 +0200 ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Fix support for all RGB/BGR pixel formats (except the 16:16:16:16 float format). Fix intel_init_framebuffer() to match hardware and driver limitations: * RGB332 is not supported at all * CI8 is supported * XRGB1555 co. are supported on Gen3 and earlier * XRGB210101010 co. are supported from Gen4 onwards * BGR formats are supported from Gen4 onwards * YUV formats are supported from Gen5 onwards (driver limitation) Yeah looks nice. I love how our definitions have the component order reversed relative to the fourcc-ish codes. Yeah. I just copied the names more or less blindly from the spec. I usually prefer to keep register definitons and specs in sync, since it makes it easier to search for stuff in the spec. But if people are bothered by this mess, I won't object to changing the defns to match the fourcc stuff. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Check framebuffer stride more thoroughly
On Wed, Oct 31, 2012 at 01:25:11PM -0700, Jesse Barnes wrote:
On Wed, 31 Oct 2012 17:50:18 +0200
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make sure the the framebuffer stride is smaller than 32k. That
seems to be the limit on recent hardware. Not quite sure if
=Gen4 has smaller limits.
Also when using a tiled memory make sure the object stride matches
the framebuffer stride.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
I had an earlier version a long time ago that tried to use smaller stride
limits
on =Gen4, but as there isn't clear information what those limits are, I
decided
to just check for the 32K limit everywhere. It's definitely an upper bound
for
the older hardware as well.
drivers/gpu/drm/i915/intel_display.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b42637b..f431f2a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8235,6 +8235,14 @@ int intel_framebuffer_init(struct drm_device *dev,
if (mode_cmd-pitches[0] 63)
return -EINVAL;
+ /* FIXME = Gen4 stride limits are bit unclear */
+ if (mode_cmd-pitches[0] 32768)
+ return -EINVAL;
+
+ if (obj-tiling_mode != I915_TILING_NONE
+ mode_cmd-pitches[0] != obj-stride)
+ return -EINVAL;
+
/* Reject formats not supported by any plane early. */
switch (mode_cmd-pixel_format) {
case DRM_FORMAT_C8:
The bspec archive should have the pre-gen4 info, but this is a good
start.
I trawled through them when I made the original patch, but the
information in the specs was lacking. Eg. for some registers they
just state something like for tiled surfaces the stride is limited to
N, with no mention what the untiled limit is. So if someone wants to
figure out the real limits, the best option would be to test on real
HW. Currently I have access only to Gen5+ HW, so I can't do it myself.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm/i915: Fix display pixel format handling
On Thu, 1 Nov 2012 16:03:13 +0200, Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Wed, Oct 31, 2012 at 01:20:23PM -0700, Jesse Barnes wrote: On Wed, 31 Oct 2012 17:50:14 +0200 ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Fix support for all RGB/BGR pixel formats (except the 16:16:16:16 float format). Fix intel_init_framebuffer() to match hardware and driver limitations: * RGB332 is not supported at all * CI8 is supported * XRGB1555 co. are supported on Gen3 and earlier * XRGB210101010 co. are supported from Gen4 onwards * BGR formats are supported from Gen4 onwards * YUV formats are supported from Gen5 onwards (driver limitation) Yeah looks nice. I love how our definitions have the component order reversed relative to the fourcc-ish codes. Yeah. I just copied the names more or less blindly from the spec. I usually prefer to keep register definitons and specs in sync, since it makes it easier to search for stuff in the spec. But if people are bothered by this mess, I won't object to changing the defns to match the fourcc stuff. We have the same issue in userspace, where we follow the spec counter to the common convention. It is just one of those things you get used to. -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 06/11] drm/i915: Check the framebuffer offset
On Wed, Oct 31, 2012 at 01:26:12PM -0700, Jesse Barnes wrote:
On Wed, 31 Oct 2012 17:50:19 +0200
ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The current code can't deal with framebuffers with an offset. Return an
error when trying to create such a framebuffer until the rest of the
code is fixed to handle them.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
I had an earlier version that actually added the handling for the offsets,
but as I still haven't managed to write test cases for that, I decided
that just refusing any offset is a good enough solution for now.
drivers/gpu/drm/i915/intel_display.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f431f2a..a3496f5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8276,6 +8276,10 @@ int intel_framebuffer_init(struct drm_device *dev,
return -EINVAL;
}
+ /* FIXME need to adjust LINOFF/TILEOFF accordingly. */
+ if (mode_cmd-offsets[0] != 0)
+ return -EINVAL;
+
ret = drm_framebuffer_init(dev, intel_fb-base, intel_fb_funcs);
if (ret) {
DRM_ERROR(framebuffer init failed %d\n, ret);
Userspace doesn't use this today at all even in the panning case?
If it does, then the user is going to be upset when nothing happens.
Only the x/y offsets are effective with the current code.
I
know it worked at one point at least, but that may have been back in
the UMS days...
Before my time.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/11] drm/i915: Add SURFLIVE register definitions
On Wed, Oct 31, 2012 at 11:57:00PM +0100, Daniel Vetter wrote: On Wed, Oct 31, 2012 at 01:23:05PM -0700, Jesse Barnes wrote: On Wed, 31 Oct 2012 17:50:15 +0200 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 Fails to apply here somehow. Also, this thing is base64 encoded, which confused my normal workflow for a bit ... Dunno what exactly caused this havoc. Strange. I had it sitting on top of drm-intel-next when I sent it. The whole series seems to be base64 after I got it back from the list. Maybe it's out wonderful mail system trying to do something clever. Base64 itself shouldn't disturb git-am co. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/i915: Check the framebuffer offset
On Thu, Nov 1, 2012 at 3:09 PM, Ville Syrjälä ville.syrj...@linux.intel.com wrote: Userspace doesn't use this today at all even in the panning case? If it does, then the user is going to be upset when nothing happens. Only the x/y offsets are effective with the current code. I know it worked at one point at least, but that may have been back in the UMS days... Before my time. Afaik the fb-offsets have been added to support planar formats with all planes smashed into the same buffer object (where the fourcc alone doesn't specify anything about inter-plane offsets). We don't support planar buffers, so enforcing an offset of 0 is imo totally ok. -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 02/11] drm/i915: Add SURFLIVE register definitions
On Thu, Nov 1, 2012 at 3:16 PM, Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Wed, Oct 31, 2012 at 11:57:00PM +0100, Daniel Vetter wrote: On Wed, Oct 31, 2012 at 01:23:05PM -0700, Jesse Barnes wrote: On Wed, 31 Oct 2012 17:50:15 +0200 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 Fails to apply here somehow. Also, this thing is base64 encoded, which confused my normal workflow for a bit ... Dunno what exactly caused this havoc. Strange. I had it sitting on top of drm-intel-next when I sent it. The whole series seems to be base64 after I got it back from the list. Maybe it's out wonderful mail system trying to do something clever. Base64 itself shouldn't disturb git-am co. Yeah, git am coped fine, but patch was a bit upset. I've then feed it the decoded text/plain part, which resulted in some strange conflicts. Dunno what has happened there. Can you simply resend a new patch rebased on top of latest dinq? Thanks, 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 02/11] drm/i915: Add SURFLIVE register definitions
On Thu, Nov 01, 2012 at 03:19:34PM +0100, Daniel Vetter wrote: On Thu, Nov 1, 2012 at 3:16 PM, Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Wed, Oct 31, 2012 at 11:57:00PM +0100, Daniel Vetter wrote: On Wed, Oct 31, 2012 at 01:23:05PM -0700, Jesse Barnes wrote: On Wed, 31 Oct 2012 17:50:15 +0200 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 Fails to apply here somehow. Also, this thing is base64 encoded, which confused my normal workflow for a bit ... Dunno what exactly caused this havoc. Strange. I had it sitting on top of drm-intel-next when I sent it. The whole series seems to be base64 after I got it back from the list. Maybe it's out wonderful mail system trying to do something clever. Base64 itself shouldn't disturb git-am co. Yeah, git am coped fine, but patch was a bit upset. I've then feed it the decoded text/plain part, which resulted in some strange conflicts. Dunno what has happened there. Can you simply resend a new patch rebased on top of latest dinq? Will do. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: CPT/PPT pch dp transcoder workaround
On Thu, 1 Nov 2012 09:15:30 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
We need to set the timing override chicken bit after fdi link training
has completed and before we enable the dp transcoder. We also have to
clear that bit again after disabling the pch dp transcoder.
See Graphics BSpec: vol4g North Display Engine Registers [IVB],
Display Mode Set Sequence and Graphics BSpec: vol4h South Display
Engine Registers [CPT, PPT], South Display Engine Transcoder and FDI
Control, Transcoder Debug and DFT, TRANS_CHICKEN_2 bit 31:
Workaround : Enable the override prior to enabling the transcoder.
Disable the override after disabling the transcoder.
While at it, use the _PIPE macro for the other TRANS_DP register.
v2: Keep the w/a as-is, but kill the original (but wrongly placed)
workaround introduced in
commit 3bcf603f6d5d18bd9d076dc280de71f48add4101
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Wed Jul 27 11:51:40 2011 -0700
drm/i915: apply timing generator bug workaround on CPT and PPT
and
commit d4270e57efe9e2536798c59e1ed2fd0a1e5cdfcf
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Tue Oct 11 10:43:02 2011 -0700
drm/i915: export a CPT mode set verification function
Note that this old code has unconditionally set the w/a, which might
explain why fdi link training sometimes silently fails, and especially
why the auto-train did not seem to work properly.
v3: Paulo Zanoni pointed out that this workaround is also required on
the LPT PCH. And Arthur Ranyan confirmed that this workaround is
requierd for all ports on the pch, not just DP: The important part
is that the bit is set whenever the pch transcoder is enabled, and
that it is _not_ set while the fdi link is trained. It is also
important that the pch transcoder is fully disabled, i.e. we have to
wait for bit 30 to clear before clearing the w/a bit.
Hence move to workaround into enable/disable_transcoder, where the pch
transcoder gets enabled/disabled.
v4: Whitespace changes dropped.
v5: Don't run the w/a on IBX, we only need it on CPT/PPT and LPT.
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Paulo Zanoni przan...@gmail.com
Cc: Arthur Ranyan arthur.j.run...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_reg.h | 5 +++--
drivers/gpu/drm/i915/intel_display.c | 32 +++-
drivers/gpu/drm/i915/intel_pm.c | 4
3 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2dd880f..f1fe3a0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3806,7 +3806,8 @@
#define _TRANSA_CHICKEN2 0xf0064
#define _TRANSB_CHICKEN2 0xf1064
#define TRANS_CHICKEN2(pipe) _PIPE(pipe, _TRANSA_CHICKEN2, _TRANSB_CHICKEN2)
-#define TRANS_AUTOTRAIN_GEN_STALL_DIS (131)
+#define TRANS_CHICKEN2_TIMING_OVERRIDE (131)
+
#define SOUTH_CHICKEN1 0xc2000
#define FDIA_PHASE_SYNC_SHIFT_OVR 19
@@ -4064,7 +4065,7 @@
#define TRANS_DP_CTL_A 0xe0300
#define TRANS_DP_CTL_B 0xe1300
#define TRANS_DP_CTL_C 0xe2300
-#define TRANS_DP_CTL(pipe) (TRANS_DP_CTL_A + (pipe) * 0x01000)
+#define TRANS_DP_CTL(pipe) _PIPE(pipe, TRANS_DP_CTL_A, TRANS_DP_CTL_B)
#define TRANS_DP_OUTPUT_ENABLE (131)
#define TRANS_DP_PORT_SEL_B (029)
#define TRANS_DP_PORT_SEL_C (129)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 129059b..675079a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1673,9 +1673,9 @@ static void intel_disable_pch_pll(struct intel_crtc
*intel_crtc)
static void intel_enable_transcoder(struct drm_i915_private *dev_priv,
enum pipe pipe)
{
- int reg;
- u32 val, pipeconf_val;
+ struct drm_device *dev = dev_priv-dev;
struct drm_crtc *crtc = dev_priv-pipe_to_crtc_mapping[pipe];
+ uint32_t reg, val, pipeconf_val;
/* PCH only available on ILK+ */
BUG_ON(dev_priv-info-gen 5);
@@ -1693,6 +1693,16 @@ static void intel_enable_transcoder(struct
drm_i915_private *dev_priv,
DRM_ERROR(Attempting to enable transcoder on Haswell with pipe
0\n);
return;
}
+
+ if (!HAS_PCH_IBX(dev)) {
+ /* Workaround: Set the timing override bit before enabling the
+ * pch transcoder. */
+ reg = TRANS_CHICKEN2(pipe);
+ val = I915_READ(reg);
+ val |= TRANS_CHICKEN2_TIMING_OVERRIDE;
+ I915_WRITE(reg, val);
+ }
I'd like this better if it were HAS_PCH_CPT; we use that as a synonym
for PPT elsehwere, and it shouldn't apply to LPT right? I see LPT has
the bit, but I don't know if it's needed (the changelong
Re: [Intel-gfx] [PATCH 06/11] drm/i915: Check the framebuffer offset
On Thu, 1 Nov 2012 15:18:04 +0100 Daniel Vetter dan...@ffwll.ch wrote: On Thu, Nov 1, 2012 at 3:09 PM, Ville Syrjälä ville.syrj...@linux.intel.com wrote: Userspace doesn't use this today at all even in the panning case? If it does, then the user is going to be upset when nothing happens. Only the x/y offsets are effective with the current code. I know it worked at one point at least, but that may have been back in the UMS days... Before my time. Afaik the fb-offsets have been added to support planar formats with all planes smashed into the same buffer object (where the fourcc alone doesn't specify anything about inter-plane offsets). We don't support planar buffers, so enforcing an offset of 0 is imo totally ok. Ok yeah was confusing it with the x/y offsets. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/i915: Check the framebuffer offset
On Thu, Nov 01, 2012 at 03:18:04PM +0100, Daniel Vetter wrote: On Thu, Nov 1, 2012 at 3:09 PM, Ville Syrjälä ville.syrj...@linux.intel.com wrote: Userspace doesn't use this today at all even in the panning case? If it does, then the user is going to be upset when nothing happens. Only the x/y offsets are effective with the current code. I know it worked at one point at least, but that may have been back in the UMS days... Before my time. Afaik the fb-offsets have been added to support planar formats with all planes smashed into the same buffer object (where the fourcc alone doesn't specify anything about inter-plane offsets). We don't support planar buffers, so enforcing an offset of 0 is imo totally ok. There's also another use case for it. That is, if you specify a source rectangle for a plane, which is smaller than the full fb, then it's perfectly legal for the plane to access the pixels outside the source rectangle to produce good looking filtered edges. But when the source rectangle edge matches the fb edge, then it's clearly not OK to do that. So if you want to cut the edges of your source rectangle sharply, then you can do it through fb-offsets[]. It's similar to texturing w/ GL_CLAMP_TO_EDGE. The texture coordinates are clamped so that nothing outside the texture is sampled, but when sampling inside the texture, the filter can blend in texels that are not inside the area specified by the texture coordinates. But I supose doing this could be easier if we just added a property to the plane which specifies how the filtering is done at the edges of the source rectangle. Then you at least wouldn't need to create a new fb every time the source rectangle changes. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/8] drm/i915: implement WaDisableVLVClockGating_VBIIssue on VLV
On 11/01/12 16:50, Jesse Barnes wrote: No, it's in the gunit spec. I'm still working on getting that one opened up. In that case, for the whole lot: Reviewed-by: Antti Koskipää antti.koski...@intel.com -- - Antti ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/36] drm/i915: train Haswell FDI at the right time
On Wed, Oct 31, 2012 at 06:12:25PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Haswell FDI link training is very different from the previous
generations.
After this commit, hsw_fdi_link_train is responsible for implementing
all the steps described as Enable and train FDI from the Haswell
CRT mode set sequence documentation.
We need to train the FDI before enabling the pipes and planes, so
we're moving the call from lpt_pch_enable to haswell_crtc_enable
directly.
We are also removing ironlake_fdi_pll_enable since the PLL enablement
on Haswell is completely different and is also done during the link
training steps.
There are still quite a few things we need to fix on
hsw_fdi_link_train, so stay tuned for the next patches :)
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 17 +++--
drivers/gpu/drm/i915/intel_ddi.c | 34 --
drivers/gpu/drm/i915/intel_display.c | 5 +
3 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0514823..abdc002 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3917,16 +3917,21 @@
#define FDI_PORT_WIDTH_2X_LPT (119)
#define FDI_PORT_WIDTH_1X_LPT (019)
-#define _FDI_RXA_MISC0xf0010
-#define _FDI_RXB_MISC0xf1010
+#define _FDI_RXA_MISC0xf0010
+#define _FDI_RXB_MISC0xf1010
+#define FDI_RX_PWRDN_LANE1_MASK (326)
+#define FDI_RX_PWRDN_LANE1_VAL(x) ((x)26)
+#define FDI_RX_PWRDN_LANE0_MASK (324)
+#define FDI_RX_PWRDN_LANE0_VAL(x) ((x)24)
+#define FDI_RX_TP1_TO_TP2_48(220)
+#define FDI_RX_TP1_TO_TP2_64(320)
+#define FDI_RX_FDI_DELAY_90 (0x900)
+#define FDI_RX_MISC(pipe) _PIPE(pipe, _FDI_RXA_MISC, _FDI_RXB_MISC)
+
#define _FDI_RXA_TUSIZE1 0xf0030
#define _FDI_RXA_TUSIZE2 0xf0038
#define _FDI_RXB_TUSIZE1 0xf1030
#define _FDI_RXB_TUSIZE2 0xf1038
-#define FDI_RX_TP1_TO_TP2_48(220)
-#define FDI_RX_TP1_TO_TP2_64(320)
-#define FDI_RX_FDI_DELAY_90 (0x900)
-#define FDI_RX_MISC(pipe) _PIPE(pipe, _FDI_RXA_MISC, _FDI_RXB_MISC)
#define FDI_RX_TUSIZE1(pipe) _PIPE(pipe, _FDI_RXA_TUSIZE1, _FDI_RXB_TUSIZE1)
#define FDI_RX_TUSIZE2(pipe) _PIPE(pipe, _FDI_RXA_TUSIZE2, _FDI_RXB_TUSIZE2)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 67bd6ba..39a53b4 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -154,7 +154,30 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc-pipe;
- u32 reg, temp, i;
+ u32 reg, temp, i, rx_ctl_val;
+
+ /* Set the FDI_RX_MISC pwrdn lanes and the 2 workarounds listed at the
+ * mode set sequence for CRT port document:
+ * - TP1 to TP2 time with the default value
+ * - FDI delay to 90h
+ */
+ I915_WRITE(_FDI_RXA_MISC, FDI_RX_PWRDN_LANE1_VAL(2) |
+ FDI_RX_PWRDN_LANE0_VAL(2) |
+ FDI_RX_TP1_TO_TP2_48 | FDI_RX_FDI_DELAY_90);
+
+ /* Enable the PCH Receiver FDI PLL */
+ rx_ctl_val = FDI_RX_PLL_ENABLE | FDI_RX_ENHANCE_FRAME_ENABLE |
+ ((intel_crtc-fdi_lanes - 1) 19);
You switch here to a variable selection of the port width/number of fdi
lanes you're using on the RX side. But the TX side below is still fixed to
2X. I guess this part here belongs in another patch?
-Daniel
+ I915_WRITE(_FDI_RXA_CTL, rx_ctl_val);
+ POSTING_READ(_FDI_RXA_CTL);
+ udelay(220);
+
+ /* Switch from Rawclk to PCDclk */
+ rx_ctl_val |= FDI_PCDCLK;
+ I915_WRITE(_FDI_RXA_CTL, rx_ctl_val);
+
+ /* Configure Port Clock Select */
+ I915_WRITE(PORT_CLK_SEL(PORT_E), intel_crtc-ddi_pll_sel);
/* Start the training iterating through available voltages and emphasis
*/
for (i=0; i ARRAY_SIZE(hsw_ddi_buf_ctl_values); i++) {
@@ -176,15 +199,6 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
udelay(600);
- /* We need to program FDI_RX_MISC with the default TP1 to TP2
- * values before enabling the receiver, and configure the delay
- * for the FDI timing generator to 90h. Luckily, all the other
- * bits are supposed to be zeroed, so we can write those values
- * directly.
- */
- I915_WRITE(FDI_RX_MISC(pipe), FDI_RX_TP1_TO_TP2_48 |
- FDI_RX_FDI_DELAY_90);
-
/* Enable CPU FDI Receiver with auto-training */
Re: [Intel-gfx] [PATCH] drm/i915: Flush outstanding unpin tasks before pageflipping
On Thu, 1 Nov 2012 09:26:26 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
If we accumulate unpin tasks because we are pageflipping faster than the
system can schedule its workers, we can effectively create a
pin-leak. The solution taken here is to limit the number of unpin tasks
we have per-crtc and to flush those outstanding tasks if we accumulate
too many. This should prevent any jitter in the normal case, and also
prevent the hang if we should run too fast.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46991
Reported-and-tested-by: Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 22 --
drivers/gpu/drm/i915/intel_drv.h |4 +++-
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 69b1739..800b195 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6908,14 +6908,19 @@ static void intel_unpin_work_fn(struct work_struct
*__work)
{
struct intel_unpin_work *work =
container_of(__work, struct intel_unpin_work, work);
+ struct drm_device *dev = work-crtc-dev;
- mutex_lock(work-dev-struct_mutex);
+ mutex_lock(dev-struct_mutex);
intel_unpin_fb_obj(work-old_fb_obj);
drm_gem_object_unreference(work-pending_flip_obj-base);
drm_gem_object_unreference(work-old_fb_obj-base);
- intel_update_fbc(work-dev);
- mutex_unlock(work-dev-struct_mutex);
+ intel_update_fbc(dev);
+ mutex_unlock(dev-struct_mutex);
+
+ BUG_ON(atomic_read(to_intel_crtc(work-crtc)-unpin_work_count) == 0);
+ atomic_dec(to_intel_crtc(work-crtc)-unpin_work_count);
+
kfree(work);
}
@@ -6963,9 +6968,9 @@ static void do_intel_finish_page_flip(struct drm_device
*dev,
atomic_clear_mask(1 intel_crtc-plane,
obj-pending_flip.counter);
-
wake_up(dev_priv-pending_flip_queue);
- schedule_work(work-work);
+
+ queue_work(dev_priv-wq, work-work);
trace_i915_flip_complete(intel_crtc-plane, work-pending_flip_obj);
}
@@ -7266,7 +7271,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
return -ENOMEM;
work-event = event;
- work-dev = crtc-dev;
+ work-crtc = crtc;
intel_fb = to_intel_framebuffer(crtc-fb);
work-old_fb_obj = intel_fb-obj;
INIT_WORK(work-work, intel_unpin_work_fn);
@@ -7291,6 +7296,9 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb-obj;
+ if (atomic_read(intel_crtc-unpin_work_count) = 2)
+ flush_workqueue(dev_priv-wq);
+
Have you by chance tested this with the async flip patch? I wonder if
in that case whether 2 is too small, and something like 100 might be
better (though really async flips are for cases where we can't keep up
with refresh, so a small number shouldn't hurt too much there either).
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/36] drm/i915: use the right FDI_RX_CTL register on Haswell
On Wed, Oct 31, 2012 at 06:12:26PM -0200, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com There is only one PCH transcoder, so it's always _FDI_RXA_CTL. Using pipe here is wrong. While at it, also reuse the rx_ctl_val variable created in the previous commit. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/intel_ddi.c | 24 1 file changed, 8 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 39a53b4..c397da3 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -153,8 +153,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) struct drm_device *dev = crtc-dev; struct drm_i915_private *dev_priv = dev-dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - int pipe = intel_crtc-pipe; - u32 reg, temp, i, rx_ctl_val; + u32 temp, i, rx_ctl_val; /* Set the FDI_RX_MISC pwrdn lanes and the 2 workarounds listed at the * mode set sequence for CRT port document: @@ -199,17 +198,10 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) udelay(600); - /* Enable CPU FDI Receiver with auto-training */ - reg = FDI_RX_CTL(pipe); - I915_WRITE(reg, - I915_READ(reg) | - FDI_LINK_TRAIN_AUTO | - FDI_RX_ENABLE | - FDI_LINK_TRAIN_PATTERN_1_CPT | The LINK_TRAIN_PAT1 here seems to disappear. Is that simply because when using auto training, we may not set this? If so, please mention that in the commit message. All the other flags are set, safe for ... - FDI_RX_ENHANCE_FRAME_ENABLE | - FDI_PORT_WIDTH_2X_LPT | ... dropping the 2X_LPT mode here will blow up on low-res, see my comment in the previous patch. -Daniel - FDI_RX_PLL_ENABLE); - POSTING_READ(reg); + /* Enable PCH FDI Receiver with auto-training */ + rx_ctl_val |= FDI_RX_ENABLE | FDI_LINK_TRAIN_AUTO; + I915_WRITE(_FDI_RXA_CTL, rx_ctl_val); + POSTING_READ(_FDI_RXA_CTL); udelay(100); temp = I915_READ(DP_TP_STATUS(PORT_E)); @@ -231,9 +223,9 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) I915_WRITE(DP_TP_CTL(PORT_E), I915_READ(DP_TP_CTL(PORT_E)) ~DP_TP_CTL_ENABLE); - I915_WRITE(FDI_RX_CTL(pipe), - I915_READ(FDI_RX_CTL(pipe)) - ~FDI_RX_PLL_ENABLE); + + rx_ctl_val = ~FDI_RX_PLL_ENABLE; + I915_WRITE(_FDI_RXA_CTL, rx_ctl_val); continue; } } -- 1.7.11.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/36] drm/i915: program the FDI RX TUSIZE register on hsw_fdi_link_train
On Wed, Oct 31, 2012 at 06:12:29PM -0200, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com According to the mode set sequence documentation, this is the right place. According to the FDI_RX_TUSIZE register description, this is the value we should set. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/intel_ddi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 0cb6441..5d33f62 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -196,6 +196,9 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) udelay(600); + /* Program PCH FDI Receiver TU */ + I915_WRITE(_FDI_RXA_TUSIZE1, 0x7E00); + I think you also want to remove the setting of RX_TU_SIZE in lpt_pch_enable. And we have nice symbolic constants to encode that 0-based 64 shifter by 25 bits ... -Daniel /* Enable PCH FDI Receiver with auto-training */ rx_ctl_val |= FDI_RX_ENABLE | FDI_LINK_TRAIN_AUTO; I915_WRITE(_FDI_RXA_CTL, rx_ctl_val); -- 1.7.11.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/36] drm/i915: properly program FDI_RX_MISC pwrdn lane values on HSW
On Wed, Oct 31, 2012 at 06:12:30PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
That's what our mode set sequence documentation says we need to do.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
As already bikeshedded on irc, I think the comment is a bit useless.
Instead of program foo I think set foo in bla and unset foo in bla
explains more ...
-Daniel
---
drivers/gpu/drm/i915/intel_ddi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 5d33f62..0239888 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -205,6 +205,12 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
POSTING_READ(_FDI_RXA_CTL);
udelay(100);
+ /* Program FDI_RX_MISC pwrdn lanes */
+ temp = I915_READ(_FDI_RXA_MISC);
+ temp = ~(FDI_RX_PWRDN_LANE1_MASK | FDI_RX_PWRDN_LANE0_MASK);
+ I915_WRITE(_FDI_RXA_MISC, temp);
+ POSTING_READ(_FDI_RXA_MISC);
+
temp = I915_READ(DP_TP_STATUS(PORT_E));
if (temp DP_TP_STATUS_AUTOTRAIN_DONE) {
DRM_DEBUG_DRIVER(BUF_CTL training done on %d step\n,
i);
@@ -227,6 +233,14 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
rx_ctl_val = ~FDI_RX_PLL_ENABLE;
I915_WRITE(_FDI_RXA_CTL, rx_ctl_val);
+
+ temp = I915_READ(_FDI_RXA_MISC);
+ temp = ~(FDI_RX_PWRDN_LANE1_MASK |
+ FDI_RX_PWRDN_LANE0_MASK);
+ temp |= FDI_RX_PWRDN_LANE1_VAL(2) |
+ FDI_RX_PWRDN_LANE0_VAL(2);
+ I915_WRITE(_FDI_RXA_MISC, temp);
+
continue;
}
}
--
1.7.11.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/36] drm/i915: try each voltage twice at hsw_fdi_link_train
On Wed, Oct 31, 2012 at 06:12:35PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
From the mode set sequence document: Each setting should be tried at
least twice before failing mode set.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index f8ca3c4..94c6b76 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -179,7 +179,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
I915_WRITE(PORT_CLK_SEL(PORT_E), intel_crtc-ddi_pll_sel);
/* Start the training iterating through available voltages and emphasis
*/
- for (i=0; i ARRAY_SIZE(hsw_ddi_buf_ctl_values); i++) {
+ for (i = 0; i ARRAY_SIZE(hsw_ddi_buf_ctl_values) * 2; i++) {
/* Configure DP_TP_CTL with auto-training */
I915_WRITE(DP_TP_CTL(PORT_E),
DP_TP_CTL_FDI_AUTOTRAIN |
@@ -191,7 +191,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
I915_WRITE(DDI_BUF_CTL(PORT_E),
DDI_BUF_CTL_ENABLE |
((intel_crtc-fdi_lanes - 1) 1) |
-hsw_ddi_buf_ctl_values[i]);
+hsw_ddi_buf_ctl_values[i 1]);
I think a simple / 2 is clearer here and symmetric with the * 2 above. The
compiler will apply clever tricks for you anyway ;-)
-Daniel
POSTING_READ(DDI_BUF_CTL(PORT_E));
udelay(600);
--
1.7.11.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Flush outstanding unpin tasks before pageflipping
On Thu, 1 Nov 2012 08:07:59 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Thu, 1 Nov 2012 09:26:26 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
If we accumulate unpin tasks because we are pageflipping faster than the
system can schedule its workers, we can effectively create a
pin-leak. The solution taken here is to limit the number of unpin tasks
we have per-crtc and to flush those outstanding tasks if we accumulate
too many. This should prevent any jitter in the normal case, and also
prevent the hang if we should run too fast.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46991
Reported-and-tested-by: Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 22 --
drivers/gpu/drm/i915/intel_drv.h |4 +++-
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 69b1739..800b195 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6908,14 +6908,19 @@ static void intel_unpin_work_fn(struct work_struct
*__work)
{
struct intel_unpin_work *work =
container_of(__work, struct intel_unpin_work, work);
+ struct drm_device *dev = work-crtc-dev;
- mutex_lock(work-dev-struct_mutex);
+ mutex_lock(dev-struct_mutex);
intel_unpin_fb_obj(work-old_fb_obj);
drm_gem_object_unreference(work-pending_flip_obj-base);
drm_gem_object_unreference(work-old_fb_obj-base);
- intel_update_fbc(work-dev);
- mutex_unlock(work-dev-struct_mutex);
+ intel_update_fbc(dev);
+ mutex_unlock(dev-struct_mutex);
+
+ BUG_ON(atomic_read(to_intel_crtc(work-crtc)-unpin_work_count) == 0);
+ atomic_dec(to_intel_crtc(work-crtc)-unpin_work_count);
+
kfree(work);
}
@@ -6963,9 +6968,9 @@ static void do_intel_finish_page_flip(struct
drm_device *dev,
atomic_clear_mask(1 intel_crtc-plane,
obj-pending_flip.counter);
-
wake_up(dev_priv-pending_flip_queue);
- schedule_work(work-work);
+
+ queue_work(dev_priv-wq, work-work);
trace_i915_flip_complete(intel_crtc-plane, work-pending_flip_obj);
}
@@ -7266,7 +7271,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
return -ENOMEM;
work-event = event;
- work-dev = crtc-dev;
+ work-crtc = crtc;
intel_fb = to_intel_framebuffer(crtc-fb);
work-old_fb_obj = intel_fb-obj;
INIT_WORK(work-work, intel_unpin_work_fn);
@@ -7291,6 +7296,9 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb-obj;
+ if (atomic_read(intel_crtc-unpin_work_count) = 2)
+ flush_workqueue(dev_priv-wq);
+
Have you by chance tested this with the async flip patch? I wonder if
in that case whether 2 is too small, and something like 100 might be
better (though really async flips are for cases where we can't keep up
with refresh, so a small number shouldn't hurt too much there either).
The limit on 2 is due to the limited resolution of pincount. Hence my
earlier fear for your async flip patch.
-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 18/36] drm/i915: don't write FDI_RX_TUSIZE on lpt_pch_enable
On Wed, Oct 31, 2012 at 06:12:37PM -0200, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com This is done way earlier on HSW/LPT and is just wrong here. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com Ok, I'll probably regret it right away, but I think splitting the fdi link training code up into that many patches was a bit too much - imo it makes reviewing more painful, since you can essentially only check things once you have all patches applied and can look at the end result. So in hindsight I think the following 2 patches would have been good enough: - move RX_TU_SIZE programming to the right spot (since that also touches code outside of the fdi link train code) - fixup the fdi link train. It is essentially a complete rewrite, it's not a lot of code (I think just 100 lines in the end), and you pretty much can only check the end result with bspec. Ofc, this commit needs a nice big commit message that explains all the little fixes that have been required. In a way this is a special case, since all the changes are concentrated in just one fucntion and don't have any implications towards other code outside of that function. For other fixes that are not so well contained, I still prefer small patches over big patches ;-) Cheers, Daniel --- drivers/gpu/drm/i915/intel_display.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index ee81932..f9441d1 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3142,11 +3142,6 @@ static void lpt_pch_enable(struct drm_crtc *crtc) assert_transcoder_disabled(dev_priv, pipe); - /* Write the TU size bits before fdi link training, so that error - * detection works. */ - I915_WRITE(FDI_RX_TUSIZE1(pipe), -I915_READ(PIPE_DATA_M1(pipe)) TU_SIZE_MASK); - /* XXX: pch pll's can be enabled any time before we enable the PCH * transcoder, and we actually should do this to not upset any PCH * transcoder that already use the clock when we share it. -- 1.7.11.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: CPT/PPT pch dp transcoder workaround
On Thu, Nov 01, 2012 at 07:37:36AM -0700, Jesse Barnes wrote:
v3: Paulo Zanoni pointed out that this workaround is also required on
the LPT PCH. And Arthur Ranyan confirmed that this workaround is
requierd for all ports on the pch, not just DP: The important part
is that the bit is set whenever the pch transcoder is enabled, and
that it is _not_ set while the fdi link is trained. It is also
important that the pch transcoder is fully disabled, i.e. we have to
wait for bit 30 to clear before clearing the w/a bit.
See above: Paulo Zanoni pointed out that this workaround is also required
on the LPT PCH.
+ if (!HAS_PCH_IBX(dev)) {
+ /* Workaround: Set the timing override bit before enabling the
+* pch transcoder. */
+ reg = TRANS_CHICKEN2(pipe);
+ val = I915_READ(reg);
+ val |= TRANS_CHICKEN2_TIMING_OVERRIDE;
+ I915_WRITE(reg, val);
+ }
I'd like this better if it were HAS_PCH_CPT; we use that as a synonym
for PPT elsehwere, and it shouldn't apply to LPT right? I see LPT has
the bit, but I don't know if it's needed (the changelong and summary
are misleading if so).
Paulo's vga patch bomb will split this up, so we can use HAS_PCH_CPT
instead of !IBX. But since I've written this patch against dinq without
paulo's patches, hence HAS_CPT would be wrong. So:
What colour would please you most, Sir?
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Flush outstanding unpin tasks before pageflipping
On Thu, 1 Nov 2012 16:29:35 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Nov 01, 2012 at 03:18:46PM +, Chris Wilson wrote:
On Thu, 1 Nov 2012 08:07:59 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Thu, 1 Nov 2012 09:26:26 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
If we accumulate unpin tasks because we are pageflipping faster than the
system can schedule its workers, we can effectively create a
pin-leak. The solution taken here is to limit the number of unpin tasks
we have per-crtc and to flush those outstanding tasks if we accumulate
too many. This should prevent any jitter in the normal case, and also
prevent the hang if we should run too fast.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46991
Reported-and-tested-by: Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 22 --
drivers/gpu/drm/i915/intel_drv.h |4 +++-
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 69b1739..800b195 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6908,14 +6908,19 @@ static void intel_unpin_work_fn(struct
work_struct *__work)
{
struct intel_unpin_work *work =
container_of(__work, struct intel_unpin_work, work);
+ struct drm_device *dev = work-crtc-dev;
- mutex_lock(work-dev-struct_mutex);
+ mutex_lock(dev-struct_mutex);
intel_unpin_fb_obj(work-old_fb_obj);
drm_gem_object_unreference(work-pending_flip_obj-base);
drm_gem_object_unreference(work-old_fb_obj-base);
- intel_update_fbc(work-dev);
- mutex_unlock(work-dev-struct_mutex);
+ intel_update_fbc(dev);
+ mutex_unlock(dev-struct_mutex);
+
+
BUG_ON(atomic_read(to_intel_crtc(work-crtc)-unpin_work_count) == 0);
+ atomic_dec(to_intel_crtc(work-crtc)-unpin_work_count);
+
kfree(work);
}
@@ -6963,9 +6968,9 @@ static void do_intel_finish_page_flip(struct
drm_device *dev,
atomic_clear_mask(1 intel_crtc-plane,
obj-pending_flip.counter);
-
wake_up(dev_priv-pending_flip_queue);
- schedule_work(work-work);
+
+ queue_work(dev_priv-wq, work-work);
trace_i915_flip_complete(intel_crtc-plane,
work-pending_flip_obj);
}
@@ -7266,7 +7271,7 @@ static int intel_crtc_page_flip(struct drm_crtc
*crtc,
return -ENOMEM;
work-event = event;
- work-dev = crtc-dev;
+ work-crtc = crtc;
intel_fb = to_intel_framebuffer(crtc-fb);
work-old_fb_obj = intel_fb-obj;
INIT_WORK(work-work, intel_unpin_work_fn);
@@ -7291,6 +7296,9 @@ static int intel_crtc_page_flip(struct drm_crtc
*crtc,
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb-obj;
+ if (atomic_read(intel_crtc-unpin_work_count) = 2)
+ flush_workqueue(dev_priv-wq);
+
Have you by chance tested this with the async flip patch? I wonder if
in that case whether 2 is too small, and something like 100 might be
better (though really async flips are for cases where we can't keep up
with refresh, so a small number shouldn't hurt too much there either).
The limit on 2 is due to the limited resolution of pincount. Hence my
earlier fear for your async flip patch.
I think for asyn flips we simply need to have a real flip queue in our
code, instead of abusing the implicit list in the workqueue code ...
One other thing is that with async flips we don't have a natural limit on
the number of pinned framebuffers any more, which means we can easily
exhaust all mappable GTT space. Hence we need to integrate that new,
explicit flip queue into our eviction code, too.
For now I'm rather happy with the flush_wq ducttape presented here ;-)
Yeah I don't have a problem with it as long as we don't block when
queuing flips in real life. :)
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: CPT/PPT pch dp transcoder workaround
On Thu, 1 Nov 2012 16:33:45 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Nov 01, 2012 at 07:37:36AM -0700, Jesse Barnes wrote:
v3: Paulo Zanoni pointed out that this workaround is also required on
the LPT PCH. And Arthur Ranyan confirmed that this workaround is
requierd for all ports on the pch, not just DP: The important part
is that the bit is set whenever the pch transcoder is enabled, and
that it is _not_ set while the fdi link is trained. It is also
important that the pch transcoder is fully disabled, i.e. we have to
wait for bit 30 to clear before clearing the w/a bit.
See above: Paulo Zanoni pointed out that this workaround is also required
on the LPT PCH.
+ if (!HAS_PCH_IBX(dev)) {
+ /* Workaround: Set the timing override bit before enabling the
+ * pch transcoder. */
+ reg = TRANS_CHICKEN2(pipe);
+ val = I915_READ(reg);
+ val |= TRANS_CHICKEN2_TIMING_OVERRIDE;
+ I915_WRITE(reg, val);
+ }
I'd like this better if it were HAS_PCH_CPT; we use that as a synonym
for PPT elsehwere, and it shouldn't apply to LPT right? I see LPT has
the bit, but I don't know if it's needed (the changelong and summary
are misleading if so).
Paulo's vga patch bomb will split this up, so we can use HAS_PCH_CPT
instead of !IBX. But since I've written this patch against dinq without
paulo's patches, hence HAS_CPT would be wrong. So:
What colour would please you most, Sir?
Just fix the changelog summary then!
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/36] drm/i915: rename intel_enable_pch_pll to ironlake_enable_pch_pll
On Wed, Oct 31, 2012 at 06:12:38PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Because this function is only for the older PCHs, not the newer ones.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Ok, I've merged patches 1-6 plus this one here for now. gtg, will resume
reviewing afterwards.
Thanks a lot for digging through this mess.
Cheers, Daniel
---
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 f9441d1..39f5bd1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1579,14 +1579,14 @@ out_unlock:
}
/**
- * intel_enable_pch_pll - enable PCH PLL
+ * ironlake_enable_pch_pll - enable PCH PLL
* @dev_priv: i915 private structure
* @pipe: pipe PLL to enable
*
* The PCH PLL needs to be enabled before the PCH transcoder, since it
* drives the transcoder clock.
*/
-static void intel_enable_pch_pll(struct intel_crtc *intel_crtc)
+static void ironlake_enable_pch_pll(struct intel_crtc *intel_crtc)
{
struct drm_i915_private *dev_priv = intel_crtc-base.dev-dev_private;
struct intel_pch_pll *pll;
@@ -3053,7 +3053,7 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
* Note that enable_pch_pll tries to do the right thing, but get_pch_pll
* unconditionally resets the pll - we need that to have the right LVDS
* enable sequence. */
- intel_enable_pch_pll(intel_crtc);
+ ironlake_enable_pch_pll(intel_crtc);
if (HAS_PCH_CPT(dev)) {
u32 sel;
@@ -3149,7 +3149,7 @@ static void lpt_pch_enable(struct drm_crtc *crtc)
* Note that enable_pch_pll tries to do the right thing, but get_pch_pll
* unconditionally resets the pll - we need that to have the right LVDS
* enable sequence. */
- intel_enable_pch_pll(intel_crtc);
+ ironlake_enable_pch_pll(intel_crtc);
lpt_program_iclkip(crtc);
--
1.7.11.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Only check for valid PP_{ON, OFF}_DELAYS on pre ILK hardware
Hi
2012/10/31 Damien Lespiau damien.lesp...@gmail.com:
From: Damien Lespiau damien.lesp...@intel.com
ILK+ have this register on the PCH. This check was triggering unclaimed
writes.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
The patch looks correct, so:
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
The only problem is: we're not doing anything here for the
HAS_PCH_SPLIT platforms. Shouldn't we be doing something? We do have
eDP code to set the PCH_PP registers, but not LVDS code for this.
Also, each encoder probably needs different values.
So my suggestion would be: apply this patch (since it fixes a problem)
and then, in the future, maybe, move this code to the encoder-specific
callbacks, and also consider the HAS_PCH_SPLIT + LVDS case.
---
drivers/gpu/drm/i915/intel_bios.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 0ed6baf..87e9b92 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -762,7 +762,8 @@ void intel_setup_bios(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
/* Set the Panel Power On/Off timings if uninitialized. */
- if ((I915_READ(PP_ON_DELAYS) == 0) (I915_READ(PP_OFF_DELAYS) ==
0)) {
+ if (!HAS_PCH_SPLIT(dev)
+ I915_READ(PP_ON_DELAYS) == 0 I915_READ(PP_OFF_DELAYS) == 0) {
/* Set T2 to 40ms and T5 to 200ms */
I915_WRITE(PP_ON_DELAYS, 0x019007d0);
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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: Flush outstanding unpin tasks before pageflipping
On Thu, 1 Nov 2012 08:34:47 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Thu, 1 Nov 2012 16:29:35 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Nov 01, 2012 at 03:18:46PM +, Chris Wilson wrote:
On Thu, 1 Nov 2012 08:07:59 -0700, Jesse Barnes
jbar...@virtuousgeek.org wrote:
On Thu, 1 Nov 2012 09:26:26 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
If we accumulate unpin tasks because we are pageflipping faster than
the
system can schedule its workers, we can effectively create a
pin-leak. The solution taken here is to limit the number of unpin
tasks
we have per-crtc and to flush those outstanding tasks if we accumulate
too many. This should prevent any jitter in the normal case, and also
prevent the hang if we should run too fast.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46991
Reported-and-tested-by: Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 22 --
drivers/gpu/drm/i915/intel_drv.h |4 +++-
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 69b1739..800b195 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6908,14 +6908,19 @@ static void intel_unpin_work_fn(struct
work_struct *__work)
{
struct intel_unpin_work *work =
container_of(__work, struct intel_unpin_work, work);
+ struct drm_device *dev = work-crtc-dev;
- mutex_lock(work-dev-struct_mutex);
+ mutex_lock(dev-struct_mutex);
intel_unpin_fb_obj(work-old_fb_obj);
drm_gem_object_unreference(work-pending_flip_obj-base);
drm_gem_object_unreference(work-old_fb_obj-base);
- intel_update_fbc(work-dev);
- mutex_unlock(work-dev-struct_mutex);
+ intel_update_fbc(dev);
+ mutex_unlock(dev-struct_mutex);
+
+
BUG_ON(atomic_read(to_intel_crtc(work-crtc)-unpin_work_count) ==
0);
+ atomic_dec(to_intel_crtc(work-crtc)-unpin_work_count);
+
kfree(work);
}
@@ -6963,9 +6968,9 @@ static void do_intel_finish_page_flip(struct
drm_device *dev,
atomic_clear_mask(1 intel_crtc-plane,
obj-pending_flip.counter);
-
wake_up(dev_priv-pending_flip_queue);
- schedule_work(work-work);
+
+ queue_work(dev_priv-wq, work-work);
trace_i915_flip_complete(intel_crtc-plane,
work-pending_flip_obj);
}
@@ -7266,7 +7271,7 @@ static int intel_crtc_page_flip(struct drm_crtc
*crtc,
return -ENOMEM;
work-event = event;
- work-dev = crtc-dev;
+ work-crtc = crtc;
intel_fb = to_intel_framebuffer(crtc-fb);
work-old_fb_obj = intel_fb-obj;
INIT_WORK(work-work, intel_unpin_work_fn);
@@ -7291,6 +7296,9 @@ static int intel_crtc_page_flip(struct drm_crtc
*crtc,
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb-obj;
+ if (atomic_read(intel_crtc-unpin_work_count) = 2)
+ flush_workqueue(dev_priv-wq);
+
Have you by chance tested this with the async flip patch? I wonder if
in that case whether 2 is too small, and something like 100 might be
better (though really async flips are for cases where we can't keep up
with refresh, so a small number shouldn't hurt too much there either).
The limit on 2 is due to the limited resolution of pincount. Hence my
earlier fear for your async flip patch.
I think for asyn flips we simply need to have a real flip queue in our
code, instead of abusing the implicit list in the workqueue code ...
One other thing is that with async flips we don't have a natural limit on
the number of pinned framebuffers any more, which means we can easily
exhaust all mappable GTT space. Hence we need to integrate that new,
explicit flip queue into our eviction code, too.
For now I'm rather happy with the flush_wq ducttape presented here ;-)
Yeah I don't have a problem with it as long as we don't block when
queuing flips in real life. :)
Actually I've justified the blocking here to myself, and prefer it to
simply running the crtc-unpin_work. If userspace is swamping the system
so badly that we can run the kthreads quick enough, it deserves a stall.
Note that the unpin leak is still about the 3rd most common bug in fedora,
so this stall will be forced on many machines.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Re: [Intel-gfx] [PATCH 1/5] drm/i915: check whether the pch is the soulmate of the cpu
Hi
2012/10/31 Daniel Vetter daniel.vet...@ffwll.ch:
We don't really support fancy north display/pch combinations, so
put a big yelling WARN_ON in there. It /should/ be impossible, but
alas, the rumours don't stop (mostly due to really early silicon
sometimes using older PCHs).
v2: Fixup the logic fumble noticed by Paulo Zanoni. I should actually
try to test run the patch next time around ...
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6d0afc9..a5ece75 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -423,19 +423,23 @@ void intel_detect_pch(struct drm_device *dev)
dev_priv-pch_type = PCH_IBX;
dev_priv-num_pch_pll = 2;
DRM_DEBUG_KMS(Found Ibex Peak PCH\n);
+ WARN_ON(!IS_GEN5(dev));
} else if (id == INTEL_PCH_CPT_DEVICE_ID_TYPE) {
dev_priv-pch_type = PCH_CPT;
dev_priv-num_pch_pll = 2;
DRM_DEBUG_KMS(Found CougarPoint PCH\n);
+ WARN_ON(!(IS_GEN6(dev) || IS_IVYBRIDGE(dev)));
} else if (id == INTEL_PCH_PPT_DEVICE_ID_TYPE) {
/* PantherPoint is CPT compatible */
dev_priv-pch_type = PCH_CPT;
dev_priv-num_pch_pll = 2;
DRM_DEBUG_KMS(Found PatherPoint PCH\n);
+ WARN_ON(!(IS_GEN6(dev) || IS_IVYBRIDGE(dev)));
} else if (id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
dev_priv-pch_type = PCH_LPT;
dev_priv-num_pch_pll = 0;
DRM_DEBUG_KMS(Found LynxPoint PCH\n);
+ WARN_ON(!IS_HASWELL(dev));
}
BUG_ON(dev_priv-num_pch_pll I915_NUM_PLLS);
}
--
1.7.11.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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: Flush outstanding unpin tasks before pageflipping
On Thu, 01 Nov 2012 15:52:23 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, 1 Nov 2012 08:34:47 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Thu, 1 Nov 2012 16:29:35 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Nov 01, 2012 at 03:18:46PM +, Chris Wilson wrote:
On Thu, 1 Nov 2012 08:07:59 -0700, Jesse Barnes
jbar...@virtuousgeek.org wrote:
On Thu, 1 Nov 2012 09:26:26 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
If we accumulate unpin tasks because we are pageflipping faster
than the
system can schedule its workers, we can effectively create a
pin-leak. The solution taken here is to limit the number of unpin
tasks
we have per-crtc and to flush those outstanding tasks if we
accumulate
too many. This should prevent any jitter in the normal case, and
also
prevent the hang if we should run too fast.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46991
Reported-and-tested-by: Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 22 --
drivers/gpu/drm/i915/intel_drv.h |4 +++-
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 69b1739..800b195 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6908,14 +6908,19 @@ static void intel_unpin_work_fn(struct
work_struct *__work)
{
struct intel_unpin_work *work =
container_of(__work, struct intel_unpin_work, work);
+ struct drm_device *dev = work-crtc-dev;
- mutex_lock(work-dev-struct_mutex);
+ mutex_lock(dev-struct_mutex);
intel_unpin_fb_obj(work-old_fb_obj);
drm_gem_object_unreference(work-pending_flip_obj-base);
drm_gem_object_unreference(work-old_fb_obj-base);
- intel_update_fbc(work-dev);
- mutex_unlock(work-dev-struct_mutex);
+ intel_update_fbc(dev);
+ mutex_unlock(dev-struct_mutex);
+
+
BUG_ON(atomic_read(to_intel_crtc(work-crtc)-unpin_work_count) ==
0);
+ atomic_dec(to_intel_crtc(work-crtc)-unpin_work_count);
+
kfree(work);
}
@@ -6963,9 +6968,9 @@ static void do_intel_finish_page_flip(struct
drm_device *dev,
atomic_clear_mask(1 intel_crtc-plane,
obj-pending_flip.counter);
-
wake_up(dev_priv-pending_flip_queue);
- schedule_work(work-work);
+
+ queue_work(dev_priv-wq, work-work);
trace_i915_flip_complete(intel_crtc-plane,
work-pending_flip_obj);
}
@@ -7266,7 +7271,7 @@ static int intel_crtc_page_flip(struct
drm_crtc *crtc,
return -ENOMEM;
work-event = event;
- work-dev = crtc-dev;
+ work-crtc = crtc;
intel_fb = to_intel_framebuffer(crtc-fb);
work-old_fb_obj = intel_fb-obj;
INIT_WORK(work-work, intel_unpin_work_fn);
@@ -7291,6 +7296,9 @@ static int intel_crtc_page_flip(struct
drm_crtc *crtc,
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb-obj;
+ if (atomic_read(intel_crtc-unpin_work_count) = 2)
+ flush_workqueue(dev_priv-wq);
+
Have you by chance tested this with the async flip patch? I wonder if
in that case whether 2 is too small, and something like 100 might be
better (though really async flips are for cases where we can't keep up
with refresh, so a small number shouldn't hurt too much there either).
The limit on 2 is due to the limited resolution of pincount. Hence my
earlier fear for your async flip patch.
I think for asyn flips we simply need to have a real flip queue in our
code, instead of abusing the implicit list in the workqueue code ...
One other thing is that with async flips we don't have a natural limit on
the number of pinned framebuffers any more, which means we can easily
exhaust all mappable GTT space. Hence we need to integrate that new,
explicit flip queue into our eviction code, too.
For now I'm rather happy with the flush_wq ducttape presented here ;-)
Yeah I don't have a problem with it as long as we don't block when
queuing flips in real life. :)
Actually I've justified the blocking here to myself, and prefer it to
simply running the crtc-unpin_work. If userspace is swamping the system
so badly that we can run the kthreads quick enough, it deserves a stall.
Note that the unpin leak is still about the 3rd most common bug in fedora,
so this stall will be forced on
Re: [Intel-gfx] [PATCH 27/36] drm/i915: don't assert_pch_pll_enabled on lpt_enable_pch_transcoder
On Wed, Oct 31, 2012 at 06:12:46PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
These asserts are specific to IBX/CPT/PPT. Inside the assert_pch_pll
function we even return in case we detect LPT, but I prefer to just
not call it. In the future we might rename to something like
ibx_assert_pch_pll.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Can't we now remove the HAS_LPT check from assert_pch_pll? Afaics we only
call it from ilk_pch_transcoder_enable and from the pch_pll handling
functions, both of which should no longer be called from haswell code.
For renaming them, I think that particular problem will solve itself once
we move all the ilk-ivb crtc/pch code into it's own file. With all these
splits you've done here for vga, I don't see much common code between
older pch and new-style ddi pch any more ...
-Daniel
---
drivers/gpu/drm/i915/intel_display.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7e8f4ed..0884137 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1722,16 +1722,10 @@ static void lpt_enable_pch_transcoder(struct
drm_i915_private *dev_priv,
{
int reg;
u32 val, pipeconf_val;
- struct drm_crtc *crtc = dev_priv-pipe_to_crtc_mapping[pipe];
/* PCH only available on ILK+ */
BUG_ON(dev_priv-info-gen 5);
- /* Make sure PCH DPLL is enabled */
- assert_pch_pll_enabled(dev_priv,
-to_intel_crtc(crtc)-pch_pll,
-to_intel_crtc(crtc));
-
/* FDI must be feeding us bits for PCH ports */
assert_fdi_tx_enabled(dev_priv, pipe);
assert_fdi_rx_enabled(dev_priv, pipe);
--
1.7.11.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: CPT/PPT pch dp transcoder workaround
Hi
2012/11/1 Daniel Vetter daniel.vet...@ffwll.ch:
We need to set the timing override chicken bit after fdi link training
has completed and before we enable the dp transcoder. We also have to
clear that bit again after disabling the pch dp transcoder.
See Graphics BSpec: vol4g North Display Engine Registers [IVB],
Display Mode Set Sequence and Graphics BSpec: vol4h South Display
Engine Registers [CPT, PPT], South Display Engine Transcoder and FDI
Control, Transcoder Debug and DFT, TRANS_CHICKEN_2 bit 31:
Workaround : Enable the override prior to enabling the transcoder.
Disable the override after disabling the transcoder.
While at it, use the _PIPE macro for the other TRANS_DP register.
v2: Keep the w/a as-is, but kill the original (but wrongly placed)
workaround introduced in
commit 3bcf603f6d5d18bd9d076dc280de71f48add4101
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Wed Jul 27 11:51:40 2011 -0700
drm/i915: apply timing generator bug workaround on CPT and PPT
and
commit d4270e57efe9e2536798c59e1ed2fd0a1e5cdfcf
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Tue Oct 11 10:43:02 2011 -0700
drm/i915: export a CPT mode set verification function
Note that this old code has unconditionally set the w/a, which might
explain why fdi link training sometimes silently fails, and especially
why the auto-train did not seem to work properly.
v3: Paulo Zanoni pointed out that this workaround is also required on
the LPT PCH. And Arthur Ranyan confirmed that this workaround is
requierd for all ports on the pch, not just DP: The important part
s/requierd/required/
is that the bit is set whenever the pch transcoder is enabled, and
that it is _not_ set while the fdi link is trained. It is also
important that the pch transcoder is fully disabled, i.e. we have to
wait for bit 30 to clear before clearing the w/a bit.
Hence move to workaround into enable/disable_transcoder, where the pch
transcoder gets enabled/disabled.
v4: Whitespace changes dropped.
v5: Don't run the w/a on IBX, we only need it on CPT/PPT and LPT.
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Paulo Zanoni przan...@gmail.com
Cc: Arthur Ranyan arthur.j.run...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
For me, it doesn't matter if you do !HAS_PCH_IBX or HAS_PCH_CPT, I
will have to fork the functions for LPT anyway, so I will fix that,
independently of what you do here.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 5 +++--
drivers/gpu/drm/i915/intel_display.c | 32 +++-
drivers/gpu/drm/i915/intel_pm.c | 4
3 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2dd880f..f1fe3a0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3806,7 +3806,8 @@
#define _TRANSA_CHICKEN20xf0064
#define _TRANSB_CHICKEN20xf1064
#define TRANS_CHICKEN2(pipe) _PIPE(pipe, _TRANSA_CHICKEN2, _TRANSB_CHICKEN2)
-#define TRANS_AUTOTRAIN_GEN_STALL_DIS(131)
+#define TRANS_CHICKEN2_TIMING_OVERRIDE(131)
+
#define SOUTH_CHICKEN1 0xc2000
#define FDIA_PHASE_SYNC_SHIFT_OVR 19
@@ -4064,7 +4065,7 @@
#define TRANS_DP_CTL_A 0xe0300
#define TRANS_DP_CTL_B 0xe1300
#define TRANS_DP_CTL_C 0xe2300
-#define TRANS_DP_CTL(pipe) (TRANS_DP_CTL_A + (pipe) * 0x01000)
+#define TRANS_DP_CTL(pipe) _PIPE(pipe, TRANS_DP_CTL_A, TRANS_DP_CTL_B)
#define TRANS_DP_OUTPUT_ENABLE(131)
#define TRANS_DP_PORT_SEL_B (029)
#define TRANS_DP_PORT_SEL_C (129)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 129059b..675079a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1673,9 +1673,9 @@ static void intel_disable_pch_pll(struct intel_crtc
*intel_crtc)
static void intel_enable_transcoder(struct drm_i915_private *dev_priv,
enum pipe pipe)
{
- int reg;
- u32 val, pipeconf_val;
+ struct drm_device *dev = dev_priv-dev;
struct drm_crtc *crtc = dev_priv-pipe_to_crtc_mapping[pipe];
+ uint32_t reg, val, pipeconf_val;
/* PCH only available on ILK+ */
BUG_ON(dev_priv-info-gen 5);
@@ -1693,6 +1693,16 @@ static void intel_enable_transcoder(struct
drm_i915_private *dev_priv,
DRM_ERROR(Attempting to enable transcoder on Haswell with
pipe 0\n);
return;
}
+
+ if (!HAS_PCH_IBX(dev)) {
+ /* Workaround: Set the timing override bit before enabling the
+* pch transcoder. */
+ reg = TRANS_CHICKEN2(pipe);
+ val = I915_READ(reg);
+ val |= TRANS_CHICKEN2_TIMING_OVERRIDE;
+
Re: [Intel-gfx] [PATCH 29/36] drm/i915: use PIPECONF_INTERLACE_MASK_HSW on lpt_enable_pch_transcoder
On Wed, Oct 31, 2012 at 06:12:48PM -0200, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com ... instead of PIPECONF_INTERLACE_MASK. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com My Bspec here still has bits 23:21 for the interlaced bits on the lpt pch, but everything with bit 23 set is a reserved value. Sinc we set the correct stuff anyway, I don't think we need to change the mask here - the same would apply to cpt. So I'll drop this one here. -Daniel --- drivers/gpu/drm/i915/intel_display.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 066994f..4fbb296 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1733,7 +1733,8 @@ static void lpt_enable_pch_transcoder(struct drm_i915_private *dev_priv, pipeconf_val = I915_READ(PIPECONF(cpu_transcoder)); val = ~TRANS_INTERLACE_MASK; - if ((pipeconf_val PIPECONF_INTERLACE_MASK) == PIPECONF_INTERLACED_ILK) + if ((pipeconf_val PIPECONF_INTERLACE_MASK_HSW) == + PIPECONF_INTERLACED_ILK) val |= TRANS_INTERLACED; else val |= TRANS_PROGRESSIVE; -- 1.7.11.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: implement WADP0ClockGatingDisable
Hi
2012/10/31 Daniel Vetter daniel.vet...@ffwll.ch:
Found in Bspec vol4h South Display Engine Registers [CPT, PPT],
section 5.3.1 TRANS_CHICKEN_1—Transcoder Chicken Bits 1
v2: Make it compile.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com (v1)
R-B still applies... When I'm reviewing your patches I usually assume
they compile, so I didn't really try to compile this one :)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_pm.c | 6 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f1fe3a0..14851ab 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3803,6 +3803,10 @@
#define TRANS_6BPC (25)
#define TRANS_12BPC(35)
+#define _TRANSA_CHICKEN10xf0060
+#define _TRANSB_CHICKEN10xf1060
+#define TRANS_CHICKEN1(pipe) _PIPE(pipe, _TRANSA_CHICKEN1, _TRANSB_CHICKEN1)
+#define TRANS_CHICKEN1_DP0UNIT_GC_DISABLE (14)
#define _TRANSA_CHICKEN20xf0064
#define _TRANSB_CHICKEN20xf1064
#define TRANS_CHICKEN2(pipe) _PIPE(pipe, _TRANSA_CHICKEN2, _TRANSB_CHICKEN2)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3469fbd..a0e8f51 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3786,6 +3786,7 @@ static void ibx_init_clock_gating(struct drm_device
*dev)
static void cpt_init_clock_gating(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ int pipe;
/*
* On Ibex Peak and Cougar Point, we need to disable clock
@@ -3795,6 +3796,11 @@ static void cpt_init_clock_gating(struct drm_device
*dev)
I915_WRITE(SOUTH_DSPCLK_GATE_D, PCH_DPLSUNIT_CLOCK_GATE_DISABLE);
I915_WRITE(SOUTH_CHICKEN2, I915_READ(SOUTH_CHICKEN2) |
DPLS_EDP_PPS_FIX_DIS);
+ /* WADP0ClockGatingDisable */
+ for_each_pipe(pipe) {
+ I915_WRITE(TRANS_CHICKEN1(pipe),
+ TRANS_CHICKEN1_DP0UNIT_GC_DISABLE);
+ }
}
void intel_init_clock_gating(struct drm_device *dev)
--
1.7.11.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 31/36] drm/i915: don't assert_pch_ports_disabled on LPT
On Wed, Oct 31, 2012 at 06:12:50PM -0200, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com That function is made for IBX. Running it on LPT will trigger tons of unclaimed register errors. The only port remaining on LPT is PCH_ADPA. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com Actually I've had to stay around for a while longer before heading off, so reviewed and applied a few more patches, up to this one here (minus the one I've dropped). Thanks, Daniel --- 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 10ea4f5..7d858f8 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1775,9 +1775,6 @@ static void lpt_disable_pch_transcoder(struct drm_i915_private *dev_priv, assert_fdi_tx_disabled(dev_priv, pipe); assert_fdi_rx_disabled(dev_priv, pipe); - /* Ports must be off as well */ - assert_pch_ports_disabled(dev_priv, pipe); - reg = TRANSCONF(pipe); val = I915_READ(reg); val = ~TRANS_ENABLE; -- 1.7.11.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Flush outstanding unpin tasks before pageflipping
On Thu, 1 Nov 2012 09:04:02 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 01 Nov 2012 15:52:23 + Chris Wilson ch...@chris-wilson.co.uk wrote: Actually I've justified the blocking here to myself, and prefer it to simply running the crtc-unpin_work. If userspace is swamping the system so badly that we can run the kthreads quick enough, it deserves a stall. Note that the unpin leak is still about the 3rd most common bug in fedora, so this stall will be forced on many machines. Hm funky, why does Fedora hit it so much? Does some of the GNOME shell stuff run unthrottled or something? I don't think so. I trust that in Tvrtko's use case, he is not so much as hogging the GPU as keeping the system as a whole relatively busy. So I suspect it is more to do with CPU starvation of the kthreads than anything else. Tvrtko, do you have any feeling for why your machine was easily suspectible to this leak? Are the stalls noticeable and do they affect your performance targets? -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: Only check for valid PP_{ON, OFF}_DELAYS on pre ILK hardware
On Thu, Nov 1, 2012 at 4:52 PM, Paulo Zanoni przan...@gmail.com wrote: The only problem is: we're not doing anything here for the HAS_PCH_SPLIT platforms. Shouldn't we be doing something? We do have eDP code to set the PCH_PP registers, but not LVDS code for this. Also, each encoder probably needs different values. So my suggestion would be: apply this patch (since it fixes a problem) and then, in the future, maybe, move this code to the encoder-specific callbacks, and also consider the HAS_PCH_SPLIT + LVDS case. It's even worse than that: This code is also run on ums setups, so potentially we could break some old setups here ... -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/5] drm/i915: kill pch_init_clock_gating indirection
Hi
2012/10/31 Daniel Vetter daniel.vet...@ffwll.ch:
Now that we no longer pretend to have flexibility in matching any
north display block with any pch, we can ditch this.
v2: Fix the embarassing rebase fail that Paulo Zanoni spotted.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_pm.c | 78
-
2 files changed, 38 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index faf57d6..7186a41a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -270,7 +270,6 @@ struct drm_i915_display_funcs {
struct drm_crtc *crtc);
void (*fdi_link_train)(struct drm_crtc *crtc);
void (*init_clock_gating)(struct drm_device *dev);
- void (*init_pch_clock_gating)(struct drm_device *dev);
int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a0e8f51..058e52e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3324,6 +3324,18 @@ void intel_enable_gt_powersave(struct drm_device *dev)
}
}
+static void ibx_init_clock_gating(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ /*
+* On Ibex Peak and Cougar Point, we need to disable clock
+* gating for the panel power sequencer or it will fail to
+* start up when no ports are active.
+*/
+ I915_WRITE(SOUTH_DSPCLK_GATE_D, PCH_DPLSUNIT_CLOCK_GATE_DISABLE);
+}
+
static void ironlake_init_clock_gating(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -3382,6 +3394,28 @@ static void ironlake_init_clock_gating(struct
drm_device *dev)
I915_WRITE(_3D_CHICKEN2,
_3D_CHICKEN2_WM_READ_PIPELINED 16 |
_3D_CHICKEN2_WM_READ_PIPELINED);
+
+ ibx_init_clock_gating(dev);
+}
+
+static void cpt_init_clock_gating(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int pipe;
+
+ /*
+* On Ibex Peak and Cougar Point, we need to disable clock
+* gating for the panel power sequencer or it will fail to
+* start up when no ports are active.
+*/
+ I915_WRITE(SOUTH_DSPCLK_GATE_D, PCH_DPLSUNIT_CLOCK_GATE_DISABLE);
+ I915_WRITE(SOUTH_CHICKEN2, I915_READ(SOUTH_CHICKEN2) |
+ DPLS_EDP_PPS_FIX_DIS);
+ /* WADP0ClockGatingDisable */
+ for_each_pipe(pipe) {
+ I915_WRITE(TRANS_CHICKEN1(pipe),
+ TRANS_CHICKEN1_DP0UNIT_GC_DISABLE);
+ }
}
static void gen6_init_clock_gating(struct drm_device *dev)
@@ -3464,6 +3498,8 @@ static void gen6_init_clock_gating(struct drm_device
*dev)
* platforms I checked have a 0 for this. (Maybe BIOS overrides?) */
I915_WRITE(GEN6_GT_MODE, _MASKED_BIT_DISABLE(0x));
I915_WRITE(GEN6_GT_MODE, _MASKED_BIT_ENABLE(GEN6_GT_MODE_HI));
+
+ cpt_init_clock_gating(dev);
}
static void gen7_setup_fixed_func_scheduler(struct drm_i915_private
*dev_priv)
@@ -3608,6 +3644,8 @@ static void ivybridge_init_clock_gating(struct
drm_device *dev)
snpcr = ~GEN6_MBC_SNPCR_MASK;
snpcr |= GEN6_MBC_SNPCR_MED;
I915_WRITE(GEN6_MBCUNIT_SNPCR, snpcr);
+
+ cpt_init_clock_gating(dev);
}
static void valleyview_init_clock_gating(struct drm_device *dev)
@@ -3771,46 +3809,11 @@ static void i830_init_clock_gating(struct drm_device
*dev)
I915_WRITE(DSPCLK_GATE_D, OVRUNIT_CLOCK_GATE_DISABLE);
}
-static void ibx_init_clock_gating(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
-
- /*
-* On Ibex Peak and Cougar Point, we need to disable clock
-* gating for the panel power sequencer or it will fail to
-* start up when no ports are active.
-*/
- I915_WRITE(SOUTH_DSPCLK_GATE_D, PCH_DPLSUNIT_CLOCK_GATE_DISABLE);
-}
-
-static void cpt_init_clock_gating(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
- int pipe;
-
- /*
-* On Ibex Peak and Cougar Point, we need to disable clock
-* gating for the panel power sequencer or it will fail to
-* start up when no ports are active.
-*/
- I915_WRITE(SOUTH_DSPCLK_GATE_D, PCH_DPLSUNIT_CLOCK_GATE_DISABLE);
- I915_WRITE(SOUTH_CHICKEN2, I915_READ(SOUTH_CHICKEN2) |
- DPLS_EDP_PPS_FIX_DIS);
- /*
[Intel-gfx] dmesg filter
The goal here is to make dmesg output with the full verbosity a bit easier to parse by a human. The script will transform: [drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1 [drm:drm_ioctl], pid=699, cmd=0xc010645b, nr=0x5b, dev 0xe200, auth=1 [drm:drm_ioctl], pid=699, cmd=0xc0106461, nr=0x61, dev 0xe200, auth=1 [drm:drm_ioctl], pid=699, cmd=0xc01c64ae, nr=0xae, dev 0xe200, auth=1 [drm:drm_mode_addfb], [FB:32] [drm:drm_ioctl], pid=699, cmd=0xc0106464, nr=0x64, dev 0xe200, auth=1 [drm:drm_vm_open_locked], 0x7fd9302fe000,0x00a0 [drm:drm_ioctl], pid=699, cmd=0x400c645f, nr=0x5f, dev 0xe200, auth=1 [drm:drm_ioctl], pid=699, cmd=0xc00464af, nr=0xaf, dev 0xe200, auth=1 [drm:intel_crtc_set_config], [CRTC:3] [NOFB] to [drm:drm_ioctl], [pid=699], [dev=0xe200], DRM_I915_GEM_THROTTLE [drm:drm_ioctl], [pid=699], [dev=0xe200], DRM_I915_GEM_CREATE [drm:drm_ioctl], [pid=699], [dev=0xe200], DRM_I915_GEM_SET_TILING [drm:drm_ioctl], [pid=699], [dev=0xe200], DRM_IOCTL_MODE_ADDFB [drm:drm_mode_addfb], [FB:32] [drm:drm_ioctl], [pid=699], [dev=0xe200], DRM_I915_GEM_MMAP_GTT [drm:drm_vm_open_locked], 0x7fd9302fe000,0x00a0 [drm:drm_ioctl], [pid=699], [dev=0xe200], DRM_I915_GEM_SET_DOMAIN [drm:drm_ioctl], [pid=699], [dev=0xe200], DRM_IOCTL_MODE_RMFB [drm:intel_crtc_set_config], [CRTC:3] [NOFB] It can be used as a Unix filter or with a file as argument. HTH, -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] scripts: Add a dmesg filter to prettify ioctl traces
From: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
scripts/Makefile.am | 2 +-
scripts/dmesg_filter | 195 +++
2 files changed, 196 insertions(+), 1 deletion(-)
create mode 100755 scripts/dmesg_filter
diff --git a/scripts/Makefile.am b/scripts/Makefile.am
index baf3612..cbaafea 100644
--- a/scripts/Makefile.am
+++ b/scripts/Makefile.am
@@ -1,3 +1,3 @@
dist_noinst_SCRIPTS = who.sh
-noinst_PYTHON = throttle.py
+noinst_PYTHON = throttle.py dmesg_filter
diff --git a/scripts/dmesg_filter b/scripts/dmesg_filter
new file mode 100755
index 000..782a942
--- /dev/null
+++ b/scripts/dmesg_filter
@@ -0,0 +1,195 @@
+#!/usr/bin/env python
+import fileinput
+import re
+import sys
+
+DRM_COMMAND_BASE = 0x40
+DRM_COMMAND_END = 0xA0
+
+drm_ioctls = (
+('DRM_IOCTL_VERSION', 0x00),
+('DRM_IOCTL_GET_UNIQUE', 0x01),
+('DRM_IOCTL_GET_MAGIC', 0x02),
+('DRM_IOCTL_IRQ_BUSID', 0x03),
+('DRM_IOCTL_GET_MAP', 0x04),
+('DRM_IOCTL_GET_CLIENT', 0x05),
+('DRM_IOCTL_GET_STATS', 0x06),
+('DRM_IOCTL_SET_VERSION', 0x07),
+('DRM_IOCTL_MODESET_CTL', 0x08),
+('DRM_IOCTL_GEM_CLOSE', 0x09),
+('DRM_IOCTL_GEM_FLINK', 0x0a),
+('DRM_IOCTL_GEM_OPEN', 0x0b),
+('DRM_IOCTL_GET_CAP', 0x0c),
+
+('DRM_IOCTL_SET_UNIQUE', 0x10),
+('DRM_IOCTL_AUTH_MAGIC', 0x11),
+('DRM_IOCTL_BLOCK', 0x12),
+('DRM_IOCTL_UNBLOCK', 0x13),
+('DRM_IOCTL_CONTROL', 0x14),
+('DRM_IOCTL_ADD_MAP', 0x15),
+('DRM_IOCTL_ADD_BUFS', 0x16),
+('DRM_IOCTL_MARK_BUFS', 0x17),
+('DRM_IOCTL_INFO_BUFS', 0x18),
+('DRM_IOCTL_MAP_BUFS', 0x19),
+('DRM_IOCTL_FREE_BUFS', 0x1a),
+
+('DRM_IOCTL_RM_MAP', 0x1b),
+
+('DRM_IOCTL_SET_SAREA_CTX', 0x1c),
+('DRM_IOCTL_GET_SAREA_CTX', 0x1d),
+
+('DRM_IOCTL_SET_MASTER', 0x1e),
+('DRM_IOCTL_DROP_MASTER', 0x1f),
+
+('DRM_IOCTL_ADD_CTX', 0x20),
+('DRM_IOCTL_RM_CTX', 0x21),
+('DRM_IOCTL_MOD_CTX', 0x22),
+('DRM_IOCTL_GET_CTX', 0x23),
+('DRM_IOCTL_SWITCH_CTX', 0x24),
+('DRM_IOCTL_NEW_CTX', 0x25),
+('DRM_IOCTL_RES_CTX', 0x26),
+('DRM_IOCTL_ADD_DRAW', 0x27),
+('DRM_IOCTL_RM_DRAW', 0x28),
+('DRM_IOCTL_DMA', 0x29),
+('DRM_IOCTL_LOCK', 0x2a),
+('DRM_IOCTL_UNLOCK', 0x2b),
+('DRM_IOCTL_FINISH', 0x2c),
+
+('DRM_IOCTL_PRIME_HANDLE_TO_FD', 0x2d),
+('DRM_IOCTL_PRIME_FD_TO_HANDLE', 0x2e),
+
+('DRM_IOCTL_AGP_ACQUIRE', 0x30),
+('DRM_IOCTL_AGP_RELEASE', 0x31),
+('DRM_IOCTL_AGP_ENABLE', 0x32),
+('DRM_IOCTL_AGP_INFO', 0x33),
+('DRM_IOCTL_AGP_ALLOC',0x34),
+('DRM_IOCTL_AGP_FREE', 0x35),
+('DRM_IOCTL_AGP_BIND', 0x36),
+('DRM_IOCTL_AGP_UNBIND', 0x37),
+
+('DRM_IOCTL_SG_ALLOC', 0x38),
+('DRM_IOCTL_SG_FREE', 0x39),
+
+('DRM_IOCTL_WAIT_VBLANK', 0x3a),
+
+('DRM_IOCTL_UPDATE_DRAW', 0x3f),
+
+('DRM_IOCTL_MODE_GETRESOURCES', 0xA0),
+('DRM_IOCTL_MODE_GETCRTC', 0xA1),
+('DRM_IOCTL_MODE_SETCRTC', 0xA2),
+('DRM_IOCTL_MODE_CURSOR', 0xA3),
+('DRM_IOCTL_MODE_GETGAMMA', 0xA4),
+('DRM_IOCTL_MODE_SETGAMMA', 0xA5),
+('DRM_IOCTL_MODE_GETENCODER', 0xA6),
+('DRM_IOCTL_MODE_GETCONNECTOR', 0xA7),
+('DRM_IOCTL_MODE_ATTACHMODE', 0xA8),
+('DRM_IOCTL_MODE_DETACHMODE', 0xA9),
+
+('DRM_IOCTL_MODE_GETPROPERTY', 0xAA),
+('DRM_IOCTL_MODE_SETPROPERTY', 0xAB),
+('DRM_IOCTL_MODE_GETPROPBLOB', 0xAC),
+('DRM_IOCTL_MODE_GETFB', 0xAD),
+('DRM_IOCTL_MODE_ADDFB', 0xAE),
+('DRM_IOCTL_MODE_RMFB', 0xAF),
+('DRM_IOCTL_MODE_PAGE_FLIP', 0xB0),
+('DRM_IOCTL_MODE_DIRTYFB', 0xB1),
+
+('DRM_IOCTL_MODE_CREATE_DUMB', 0xB2),
+('DRM_IOCTL_MODE_MAP_DUMB', 0xB3),
+('DRM_IOCTL_MODE_DESTROY_DUMB', 0xB4),
+('DRM_IOCTL_MODE_GETPLANERESOURCES', 0xB5),
+('DRM_IOCTL_MODE_GETPLANE', 0xB6),
+('DRM_IOCTL_MODE_SETPLANE', 0xB7),
+('DRM_IOCTL_MODE_ADDFB2', 0xB8),
+('DRM_IOCTL_MODE_OBJ_GETPROPERTIES', 0xB9),
+('DRM_IOCTL_MODE_OBJ_SETPROPERTY', 0xBA),
+)
+
+intel_ioctls = (
+('DRM_I915_INIT', 0x00),
+('DRM_I915_FLUSH', 0x01),
+('DRM_I915_FLIP', 0x02),
+('DRM_I915_BATCHBUFFER', 0x03),
+('DRM_I915_IRQ_EMIT', 0x04),
+('DRM_I915_IRQ_WAIT', 0x05),
+('DRM_I915_GETPARAM', 0x06),
+('DRM_I915_SETPARAM', 0x07),
+('DRM_I915_ALLOC', 0x08),
+('DRM_I915_FREE', 0x09),
+('DRM_I915_INIT_HEAP', 0x0a),
+('DRM_I915_CMDBUFFER', 0x0b),
+('DRM_I915_DESTROY_HEAP', 0x0c),
+('DRM_I915_SET_VBLANK_PIPE', 0x0d),
+('DRM_I915_GET_VBLANK_PIPE', 0x0e),
+('DRM_I915_VBLANK_SWAP', 0x0f),
+('DRM_I915_HWS_ADDR', 0x11),
+('DRM_I915_GEM_INIT', 0x13),
+('DRM_I915_GEM_EXECBUFFER', 0x14),
+('DRM_I915_GEM_PIN', 0x15),
+('DRM_I915_GEM_UNPIN', 0x16),
+('DRM_I915_GEM_BUSY', 0x17),
+('DRM_I915_GEM_THROTTLE', 0x18),
+('DRM_I915_GEM_ENTERVT', 0x19),
+('DRM_I915_GEM_LEAVEVT', 0x1a),
+('DRM_I915_GEM_CREATE', 0x1b),
+('DRM_I915_GEM_PREAD', 0x1c),
+
Re: [Intel-gfx] [PATCH 07/36] drm/i915: use the right FDI_RX_CTL register on Haswell
Hi 2012/11/1 Daniel Vetter dan...@ffwll.ch: On Wed, Oct 31, 2012 at 06:12:26PM -0200, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com There is only one PCH transcoder, so it's always _FDI_RXA_CTL. Using pipe here is wrong. While at it, also reuse the rx_ctl_val variable created in the previous commit. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/intel_ddi.c | 24 1 file changed, 8 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 39a53b4..c397da3 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -153,8 +153,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) struct drm_device *dev = crtc-dev; struct drm_i915_private *dev_priv = dev-dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - int pipe = intel_crtc-pipe; - u32 reg, temp, i, rx_ctl_val; + u32 temp, i, rx_ctl_val; /* Set the FDI_RX_MISC pwrdn lanes and the 2 workarounds listed at the * mode set sequence for CRT port document: @@ -199,17 +198,10 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) udelay(600); - /* Enable CPU FDI Receiver with auto-training */ - reg = FDI_RX_CTL(pipe); - I915_WRITE(reg, - I915_READ(reg) | - FDI_LINK_TRAIN_AUTO | - FDI_RX_ENABLE | - FDI_LINK_TRAIN_PATTERN_1_CPT | The LINK_TRAIN_PAT1 here seems to disappear. Is that simply because when using auto training, we may not set this? If so, please mention that in the commit message. All the other flags are set, safe for ... - FDI_RX_ENHANCE_FRAME_ENABLE | - FDI_PORT_WIDTH_2X_LPT | ... dropping the 2X_LPT mode here will blow up on low-res, see my comment in the previous patch. It would blow up if everything else was actually working... If you take a look at intel_ddi_enable_pipe_func, you will see that before my series it sets the width to 1x where the other pieces of our code set to 2x, which is just wrong. On my series, as I change the functions I change them to use the correct width, and after patch 8 we do have the correct width being set, but VGA really doesn't work yet because of the other thousand problems it has: you can't notice the difference in patch 8 because you need all the other future fixes. So I really think we should just assume VGA is a total failure until before the very last patch :) -Daniel - FDI_RX_PLL_ENABLE); - POSTING_READ(reg); + /* Enable PCH FDI Receiver with auto-training */ + rx_ctl_val |= FDI_RX_ENABLE | FDI_LINK_TRAIN_AUTO; + I915_WRITE(_FDI_RXA_CTL, rx_ctl_val); + POSTING_READ(_FDI_RXA_CTL); udelay(100); temp = I915_READ(DP_TP_STATUS(PORT_E)); @@ -231,9 +223,9 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) I915_WRITE(DP_TP_CTL(PORT_E), I915_READ(DP_TP_CTL(PORT_E)) ~DP_TP_CTL_ENABLE); - I915_WRITE(FDI_RX_CTL(pipe), - I915_READ(FDI_RX_CTL(pipe)) - ~FDI_RX_PLL_ENABLE); + + rx_ctl_val = ~FDI_RX_PLL_ENABLE; + I915_WRITE(_FDI_RXA_CTL, rx_ctl_val); continue; } } -- 1.7.11.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 29/36] drm/i915: use PIPECONF_INTERLACE_MASK_HSW on lpt_enable_pch_transcoder
Hi 2012/11/1 Daniel Vetter dan...@ffwll.ch: On Wed, Oct 31, 2012 at 06:12:48PM -0200, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com ... instead of PIPECONF_INTERLACE_MASK. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com My Bspec here still has bits 23:21 for the interlaced bits on the lpt pch, but everything with bit 23 set is a reserved value. Sinc we set the correct stuff anyway, I don't think we need to change the mask here - the same would apply to cpt. So I'll drop this one here. But here we're dealing with pipeconf_val which the value we read in PIPECONF, which is on the CPU, not on the PCH. TRANS_CONF has bits 23:21 for the interlaced mode, but PIPECONF has bits 22:21 for the interlaced mode. We're reading from PIPECONF to write to TRANSCONF, but the mask is being applied to pipeconf, so the mask should be 22:21. I still think my patch is correct. -Daniel --- drivers/gpu/drm/i915/intel_display.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 066994f..4fbb296 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1733,7 +1733,8 @@ static void lpt_enable_pch_transcoder(struct drm_i915_private *dev_priv, pipeconf_val = I915_READ(PIPECONF(cpu_transcoder)); val = ~TRANS_INTERLACE_MASK; - if ((pipeconf_val PIPECONF_INTERLACE_MASK) == PIPECONF_INTERLACED_ILK) + if ((pipeconf_val PIPECONF_INTERLACE_MASK_HSW) == + PIPECONF_INTERLACED_ILK) val |= TRANS_INTERLACED; else val |= TRANS_PROGRESSIVE; -- 1.7.11.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] dmesg filter
Damien Lespiau damien.lesp...@gmail.com writes: The goal here is to make dmesg output with the full verbosity a bit easier to parse by a human. The script will transform: Couldn't a little bit of preprocessor in the kernel ioctl definitions give us decent names right in the dmesg? pgpKO3MXBo1nr.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Flush outstanding unpin tasks before pageflipping
On Thu, 01 Nov 2012 16:52:05 + Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk wrote: On Thursday 01 November 2012 16:20:03 Chris Wilson wrote: On Thu, 1 Nov 2012 09:04:02 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 01 Nov 2012 15:52:23 + Chris Wilson ch...@chris-wilson.co.uk wrote: Actually I've justified the blocking here to myself, and prefer it to simply running the crtc-unpin_work. If userspace is swamping the system so badly that we can run the kthreads quick enough, it deserves a stall. Note that the unpin leak is still about the 3rd most common bug in fedora, so this stall will be forced on many machines. Hm funky, why does Fedora hit it so much? Does some of the GNOME shell stuff run unthrottled or something? I don't think so. I trust that in Tvrtko's use case, he is not so much as hogging the GPU as keeping the system as a whole relatively busy. So I suspect it is more to do with CPU starvation of the kthreads than anything else. Tvrtko, do you have any feeling for why your machine was easily suspectible to this leak? Are the stalls noticeable and do they affect your performance targets? We didn't bother looking for any stalls, but for a long time we were occasionally hitting this pin_count BUG i915_gem_object_pin. So it didn't in fact affect our performance targets as much it completely wrecked our system. If this patch causes an occasional stall instead, given that this bug triggers every 3-4 hours of uptime, we are fine with that. If a frame or so is missed every couple hours on low end hardware we don't care that much. More on the actual workload... Only recently we got lucky and found a platform and workload where it happens reliably. And this patch reliably fixes that. In this workload CPU is being loaded 50-60% decoding a movie and rendering it to a full screen window. Our proprietary compositor page flips at 60Hz only, not faster. Together with another small semi-transparent window being rendered on top of the full screen movie. Movie played is a 25fps one, which means the full screen window is damaged 25 out of 60 frames (give or take) which is when we render to our back buffer and page flip at the vsync rate (60Hz). According to intel_gpu_top tool, GPU load is roughly at 40%, apart from the Framebuffer Compression metric which is maxed out, if that is one is at all valid. This particular scenario triggers the bug only on two of our Atom based platform both with a NM10/Pineview G/i915 chipset. Ah ok on Atom you're probably CPU constrained a bit, but still at 50-60% utilization the kthreads should be running at least sometimes... But it sounds like a case of the kthreads not running instead of queueing too fast anyway (not that the latter is really possible without some hacking to the flip code). -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5 v4] drm/i915: Stop using AGP layer for GEN6+
As a quick hack we make the old intel_gtt structure mutable so we can
fool a bunch of the existing code which depends on elements in that data
structure. We can/should try to remove this in a subsequent patch.
This should preserve the old gtt init behavior which upon writing these
patches seems incorrect. The next patch will fix these things.
The one exception is VLV which doesn't have the preserved flush control
write behavior. Since we want to do that for all GEN6+ stuff, we'll
handle that in a later patch. Mainstream VLV support doesn't actually
exist yet anyway.
v2: Update the comment to remove the voodoo
Check that the last pte written matches what we readback
v3: actually kill cache_level_to_agp_type since most of the flags will
disappear in an upcoming patch
v4: v3 was actually not what we wanted (Daniel)
Make the ggtt bind assertions better and stricter (Chris)
Fix some uncaught errors at gtt init (Chris)
Some other random stuff that Chris wanted
CC: Chris Wilson ch...@chris-wilson.co.uk
CC: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/char/agp/intel-gtt.c | 2 +-
drivers/gpu/drm/i915/i915_dma.c| 16 +-
drivers/gpu/drm/i915/i915_drv.h| 10 +-
drivers/gpu/drm/i915/i915_gem.c| 12 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c| 256 +
drivers/gpu/drm/i915/i915_reg.h| 6 +
include/drm/intel-gtt.h| 3 +-
8 files changed, 256 insertions(+), 51 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 38390f7..4dfbb80 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1686,7 +1686,7 @@ int intel_gmch_probe(struct pci_dev *bridge_pdev, struct
pci_dev *gpu_pdev,
}
EXPORT_SYMBOL(intel_gmch_probe);
-const struct intel_gtt *intel_gtt_get(void)
+struct intel_gtt *intel_gtt_get(void)
{
return intel_private.base;
}
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index d04facb..d9b4a49 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1494,19 +1494,9 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
goto free_priv;
}
- ret = intel_gmch_probe(dev_priv-bridge_dev, dev-pdev, NULL);
- if (!ret) {
- DRM_ERROR(failed to set up gmch\n);
- ret = -EIO;
+ ret = i915_gem_gtt_init(dev);
+ if (ret)
goto put_bridge;
- }
-
- dev_priv-mm.gtt = intel_gtt_get();
- if (!dev_priv-mm.gtt) {
- DRM_ERROR(Failed to initialize GTT\n);
- ret = -ENODEV;
- goto put_gmch;
- }
i915_kick_out_firmware_fb(dev_priv);
@@ -1680,7 +1670,7 @@ out_mtrrfree:
out_rmmap:
pci_iounmap(dev-pdev, dev_priv-regs);
put_gmch:
- intel_gmch_remove();
+ i915_gem_gtt_fini(dev);
put_bridge:
pci_dev_put(dev_priv-bridge_dev);
free_priv:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a2c5e89..7274360 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -686,7 +686,7 @@ typedef struct drm_i915_private {
struct {
/** Bridge to intel-gtt-ko */
- const struct intel_gtt *gtt;
+ struct intel_gtt *gtt;
/** Memory allocator for GTT stolen memory */
struct drm_mm stolen;
/** Memory allocator for GTT */
@@ -1505,6 +1505,14 @@ void i915_gem_init_global_gtt(struct drm_device *dev,
unsigned long start,
unsigned long mappable_end,
unsigned long end);
+int i915_gem_gtt_init(struct drm_device *dev);
+void i915_gem_gtt_fini(struct drm_device *dev);
+extern inline void i915_gem_chipset_flush(struct drm_device *dev)
+{
+ if (INTEL_INFO(dev)-gen 6)
+ intel_gtt_chipset_flush();
+}
+
/* i915_gem_evict.c */
int __must_check i915_gem_evict_something(struct drm_device *dev, int min_size,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7dd1034..859ac4f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -845,12 +845,12 @@ out:
* domain anymore. */
if (obj-base.write_domain != I915_GEM_DOMAIN_CPU) {
i915_gem_clflush_object(obj);
- intel_gtt_chipset_flush();
+ i915_gem_chipset_flush(dev);
}
}
if (needs_clflush_after)
- intel_gtt_chipset_flush();
+ i915_gem_chipset_flush(dev);
return ret;
}
@@ -3058,7 +3058,7 @@ i915_gem_object_flush_cpu_write_domain(struct
drm_i915_gem_object *obj)
[Intel-gfx] [PATCH 2/5] drm/i915: Calculate correct stolen size for GEN7+
This bug existed in the old code, but was easier to fix here in the
rework. Unfortunately gen7 doesn't have a nice way to figure out the
size and we must use a lookup table.
As Jesse pointed out, there is some confusion in the docs about these
definitions. We're picking the one which seems more accurate, but we
really aren't certain.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +-
drivers/gpu/drm/i915/i915_reg.h | 2 ++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e3118c3..2e73acf 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -511,6 +511,15 @@ static inline unsigned int gen6_get_stolen_size(u16
snb_gmch_ctl)
return snb_gmch_ctl 25; /* 32 MB units */
}
+static inline unsigned int gen7_get_stolen_size(u16 snb_gmch_ctl)
+{
+ static const int stolen_decoder[] = {
+ 0, 0, 0, 0, 0, 32, 48, 64, 128, 256, 96, 160, 224, 352};
+ snb_gmch_ctl = IVB_GMCH_GMS_SHIFT;
+ snb_gmch_ctl = IVB_GMCH_GMS_MASK;
+ return stolen_decoder[snb_gmch_ctl] 20;
+}
+
int i915_gem_gtt_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -556,7 +565,10 @@ int i915_gem_gtt_init(struct drm_device *dev)
pci_read_config_word(dev-pdev, SNB_GMCH_CTRL, snb_gmch_ctl);
dev_priv-mm.gtt-gtt_total_entries =
gen6_get_total_gtt_size(snb_gmch_ctl) / sizeof(gtt_pte_t);
- dev_priv-mm.gtt-stolen_size = gen6_get_stolen_size(snb_gmch_ctl);
+ if (INTEL_INFO(dev)-gen 7)
+ dev_priv-mm.gtt-stolen_size =
gen6_get_stolen_size(snb_gmch_ctl);
+ else
+ dev_priv-mm.gtt-stolen_size =
gen7_get_stolen_size(snb_gmch_ctl);
dev_priv-mm.gtt-gtt_mappable_entries = pci_resource_len(dev-pdev, 2)
PAGE_SHIFT;
/* 64/512MB is the current min/max we actually know of, but this is
just a
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bfcb64e..4dcc71e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -46,6 +46,8 @@
#defineSNB_GMCH_GGMS_MASK 0x3
#defineSNB_GMCH_GMS_SHIFT 3 /* Graphics Mode Select */
#defineSNB_GMCH_GMS_MASK0x1f
+#defineIVB_GMCH_GMS_SHIFT 4
+#defineIVB_GMCH_GMS_MASK0xf
/* PCI config space */
--
1.8.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: Kill off now unused gen6+ AGP code
Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/char/agp/intel-agp.h | 91 - drivers/char/agp/intel-gtt.c | 307 +-- include/drm/intel-gtt.h | 4 - 3 files changed, 3 insertions(+), 399 deletions(-) diff --git a/drivers/char/agp/intel-agp.h b/drivers/char/agp/intel-agp.h index 6ec0fff..1042c1b 100644 --- a/drivers/char/agp/intel-agp.h +++ b/drivers/char/agp/intel-agp.h @@ -62,12 +62,6 @@ #define I810_PTE_LOCAL 0x0002 #define I810_PTE_VALID 0x0001 #define I830_PTE_SYSTEM_CACHED 0x0006 -/* GT PTE cache control fields */ -#define GEN6_PTE_UNCACHED 0x0002 -#define HSW_PTE_UNCACHED 0x -#define GEN6_PTE_LLC 0x0004 -#define GEN6_PTE_LLC_MLC 0x0006 -#define GEN6_PTE_GFDT 0x0008 #define I810_SMRAM_MISCC 0x70 #define I810_GFX_MEM_WIN_SIZE 0x0001 @@ -97,7 +91,6 @@ #define G4x_GMCH_SIZE_VT_2M(G4x_GMCH_SIZE_2M | G4x_GMCH_SIZE_VT_EN) #define GFX_FLSH_CNTL 0x2170 /* 915+ */ -#define GFX_FLSH_CNTL_VLV 0x101008 #define I810_DRAM_CTL 0x3000 #define I810_DRAM_ROW_00x0001 @@ -148,29 +141,6 @@ #define INTEL_I7505_AGPCTRL0x70 #define INTEL_I7505_MCHCFG 0x50 -#define SNB_GMCH_CTRL 0x50 -#define SNB_GMCH_GMS_STOLEN_MASK 0xF8 -#define SNB_GMCH_GMS_STOLEN_32M(1 3) -#define SNB_GMCH_GMS_STOLEN_64M(2 3) -#define SNB_GMCH_GMS_STOLEN_96M(3 3) -#define SNB_GMCH_GMS_STOLEN_128M (4 3) -#define SNB_GMCH_GMS_STOLEN_160M (5 3) -#define SNB_GMCH_GMS_STOLEN_192M (6 3) -#define SNB_GMCH_GMS_STOLEN_224M (7 3) -#define SNB_GMCH_GMS_STOLEN_256M (8 3) -#define SNB_GMCH_GMS_STOLEN_288M (9 3) -#define SNB_GMCH_GMS_STOLEN_320M (0xa 3) -#define SNB_GMCH_GMS_STOLEN_352M (0xb 3) -#define SNB_GMCH_GMS_STOLEN_384M (0xc 3) -#define SNB_GMCH_GMS_STOLEN_416M (0xd 3) -#define SNB_GMCH_GMS_STOLEN_448M (0xe 3) -#define SNB_GMCH_GMS_STOLEN_480M (0xf 3) -#define SNB_GMCH_GMS_STOLEN_512M (0x10 3) -#define SNB_GTT_SIZE_0M(0 8) -#define SNB_GTT_SIZE_1M(1 8) -#define SNB_GTT_SIZE_2M(2 8) -#define SNB_GTT_SIZE_MASK (3 8) - /* pci devices ids */ #define PCI_DEVICE_ID_INTEL_E7221_HB 0x2588 #define PCI_DEVICE_ID_INTEL_E7221_IG 0x258a @@ -219,66 +189,5 @@ #define PCI_DEVICE_ID_INTEL_IRONLAKE_MA_HB 0x0062 #define PCI_DEVICE_ID_INTEL_IRONLAKE_MC2_HB0x006a #define PCI_DEVICE_ID_INTEL_IRONLAKE_M_IG 0x0046 -#define PCI_DEVICE_ID_INTEL_SANDYBRIDGE_HB 0x0100 /* Desktop */ -#define PCI_DEVICE_ID_INTEL_SANDYBRIDGE_GT1_IG 0x0102 -#define PCI_DEVICE_ID_INTEL_SANDYBRIDGE_GT2_IG 0x0112 -#define PCI_DEVICE_ID_INTEL_SANDYBRIDGE_GT2_PLUS_IG0x0122 -#define PCI_DEVICE_ID_INTEL_SANDYBRIDGE_M_HB 0x0104 /* Mobile */ -#define PCI_DEVICE_ID_INTEL_SANDYBRIDGE_M_GT1_IG 0x0106 -#define PCI_DEVICE_ID_INTEL_SANDYBRIDGE_M_GT2_IG 0x0116 -#define PCI_DEVICE_ID_INTEL_SANDYBRIDGE_M_GT2_PLUS_IG 0x0126 -#define PCI_DEVICE_ID_INTEL_SANDYBRIDGE_S_HB 0x0108 /* Server */ -#define PCI_DEVICE_ID_INTEL_SANDYBRIDGE_S_IG 0x010A -#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_HB 0x0150 /* Desktop */ -#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_GT1_IG 0x0152 -#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_GT2_IG 0x0162 -#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_M_HB 0x0154 /* Mobile */ -#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_M_GT1_IG 0x0156 -#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_M_GT2_IG 0x0166 -#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_HB 0x0158 /* Server */ -#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_GT1_IG 0x015A -#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_GT2_IG 0x016A -#define PCI_DEVICE_ID_INTEL_VALLEYVIEW_HB 0x0F00 /* VLV1 */ -#define PCI_DEVICE_ID_INTEL_VALLEYVIEW_IG 0x0F30 -#define PCI_DEVICE_ID_INTEL_HASWELL_HB 0x0400 /* Desktop */ -#define PCI_DEVICE_ID_INTEL_HASWELL_D_GT1_IG 0x0402 -#define PCI_DEVICE_ID_INTEL_HASWELL_D_GT2_IG 0x0412 -#define PCI_DEVICE_ID_INTEL_HASWELL_D_GT2_PLUS_IG 0x0422 -#define PCI_DEVICE_ID_INTEL_HASWELL_M_HB 0x0404 /* Mobile */ -#define PCI_DEVICE_ID_INTEL_HASWELL_M_GT1_IG 0x0406 -#define PCI_DEVICE_ID_INTEL_HASWELL_M_GT2_IG 0x0416 -#define PCI_DEVICE_ID_INTEL_HASWELL_M_GT2_PLUS_IG 0x0426 -#define PCI_DEVICE_ID_INTEL_HASWELL_S_HB 0x0408 /* Server */ -#define PCI_DEVICE_ID_INTEL_HASWELL_S_GT1_IG 0x040a -#define PCI_DEVICE_ID_INTEL_HASWELL_S_GT2_IG 0x041a -#define PCI_DEVICE_ID_INTEL_HASWELL_S_GT2_PLUS_IG 0x042a -#define PCI_DEVICE_ID_INTEL_HASWELL_E_HB
[Intel-gfx] [PATCH 4/5] drm/i915: flush system agent TLBs on SNB
This allows us to map the PTEs WC. I've not done thorough testing or
performance measurements with this patch, but it should be decent.
This is based on a patch from Jesse with the original commit message
I've only lightly tested this so far, but the corruption seems to be
gone if I write the GFX_FLSH_CNTL reg after binding an object. This
register should control the TLB for the system agent, which is what CPU
mapped objects will go through.
It has been updated for the new AGP-less code by me, and included with
it is feedback from the original patch.
v2: Updated to reflect paranoia on pte updates/register posting reads.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Reviewed-by [v1]: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 11 +--
drivers/gpu/drm/i915/i915_reg.h | 2 ++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 2e73acf..052b439 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -378,6 +378,13 @@ static void gen6_ggtt_bind_object(struct
drm_i915_gem_object *obj,
* hardware should work, we must keep this posting read for paranoia.
*/
WARN_ON(readl(gtt_entries[i-1]) != pte_encode(dev, addr, level));
+
+ /* This next bit makes the above posting read even more important. We
+* want to flush the TLBs only after we're certain all the PTE updates
+* have finished.
+*/
+ I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+ POSTING_READ(GFX_FLSH_CNTL_GEN6);
}
void i915_gem_gtt_bind_object(struct drm_i915_gem_object *obj,
@@ -588,8 +595,8 @@ int i915_gem_gtt_init(struct drm_device *dev)
goto err_out;
}
- dev_priv-mm.gtt-gtt = ioremap(gtt_bus_addr,
- dev_priv-mm.gtt-gtt_total_entries *
sizeof(gtt_pte_t));
+ dev_priv-mm.gtt-gtt = ioremap_wc(gtt_bus_addr,
+ dev_priv-mm.gtt-gtt_total_entries
* sizeof(gtt_pte_t));
if (!dev_priv-mm.gtt-gtt) {
DRM_ERROR(Failed to map the gtt page table\n);
teardown_scratch_page(dev);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4dcc71e..3d42c60 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -688,6 +688,8 @@
#define CM0_RC_OP_FLUSH_DISABLE (10)
#define BB_ADDR0x02140 /* 8 bytes */
#define GFX_FLSH_CNTL 0x02170 /* 915+ only */
+#define GFX_FLSH_CNTL_GEN6 0x101008
+#define GFX_FLSH_CNTL_EN (10)
#define ECOSKPD0x021d0
#define ECO_GATING_CX_ONLY (13)
#define ECO_FLIP_DONE(10)
--
1.8.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Move the remaining gtt code
It's pretty much all consolidated now that we've killed AGP. We can move
the one outlier, and defines too.
(Kill some unused defines in the process)
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem.c | 62 --
drivers/gpu/drm/i915/i915_gem_gtt.c | 76 +
drivers/gpu/drm/i915/i915_reg.h | 17 -
3 files changed, 76 insertions(+), 79 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 859ac4f..b6a0c74 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3875,68 +3875,6 @@ void i915_gem_init_swizzling(struct drm_device *dev)
I915_WRITE(ARB_MODE, _MASKED_BIT_ENABLE(ARB_MODE_SWIZZLE_IVB));
}
-void i915_gem_init_ppgtt(struct drm_device *dev)
-{
- drm_i915_private_t *dev_priv = dev-dev_private;
- uint32_t pd_offset;
- struct intel_ring_buffer *ring;
- struct i915_hw_ppgtt *ppgtt = dev_priv-mm.aliasing_ppgtt;
- uint32_t __iomem *pd_addr;
- uint32_t pd_entry;
- int i;
-
- if (!dev_priv-mm.aliasing_ppgtt)
- return;
-
-
- pd_addr = dev_priv-mm.gtt-gtt + ppgtt-pd_offset/sizeof(uint32_t);
- for (i = 0; i ppgtt-num_pd_entries; i++) {
- dma_addr_t pt_addr;
-
- if (dev_priv-mm.gtt-needs_dmar)
- pt_addr = ppgtt-pt_dma_addr[i];
- else
- pt_addr = page_to_phys(ppgtt-pt_pages[i]);
-
- pd_entry = GEN6_PDE_ADDR_ENCODE(pt_addr);
- pd_entry |= GEN6_PDE_VALID;
-
- writel(pd_entry, pd_addr + i);
- }
- readl(pd_addr);
-
- pd_offset = ppgtt-pd_offset;
- pd_offset /= 64; /* in cachelines, */
- pd_offset = 16;
-
- if (INTEL_INFO(dev)-gen == 6) {
- uint32_t ecochk, gab_ctl, ecobits;
-
- ecobits = I915_READ(GAC_ECO_BITS);
- I915_WRITE(GAC_ECO_BITS, ecobits | ECOBITS_PPGTT_CACHE64B);
-
- gab_ctl = I915_READ(GAB_CTL);
- I915_WRITE(GAB_CTL, gab_ctl | GAB_CTL_CONT_AFTER_PAGEFAULT);
-
- ecochk = I915_READ(GAM_ECOCHK);
- I915_WRITE(GAM_ECOCHK, ecochk | ECOCHK_SNB_BIT |
- ECOCHK_PPGTT_CACHE64B);
- I915_WRITE(GFX_MODE, _MASKED_BIT_ENABLE(GFX_PPGTT_ENABLE));
- } else if (INTEL_INFO(dev)-gen = 7) {
- I915_WRITE(GAM_ECOCHK, ECOCHK_PPGTT_CACHE64B);
- /* GFX_MODE is per-ring on gen7+ */
- }
-
- for_each_ring(ring, dev_priv, i) {
- if (INTEL_INFO(dev)-gen = 7)
- I915_WRITE(RING_MODE_GEN7(ring),
- _MASKED_BIT_ENABLE(GFX_PPGTT_ENABLE));
-
- I915_WRITE(RING_PP_DIR_DCLV(ring), PP_DIR_DCLV_2G);
- I915_WRITE(RING_PP_DIR_BASE(ring), pd_offset);
- }
-}
-
static bool
intel_enable_blt(struct drm_device *dev)
{
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 052b439..d9cc245 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -30,6 +30,20 @@
typedef uint32_t gtt_pte_t;
+/* PPGTT stuff */
+#define GEN6_GTT_ADDR_ENCODE(addr) ((addr) | (((addr) 28) 0xff0))
+
+#define GEN6_PDE_VALID (1 0)
+/* gen6+ has bit 11-4 for physical addr bit 39-32 */
+#define GEN6_PDE_ADDR_ENCODE(addr) GEN6_GTT_ADDR_ENCODE(addr)
+
+#define GEN6_PTE_VALID (1 0)
+#define GEN6_PTE_UNCACHED (1 1)
+#define HSW_PTE_UNCACHED (0)
+#define GEN6_PTE_CACHE_LLC (2 1)
+#define GEN6_PTE_CACHE_LLC_MLC (3 1)
+#define GEN6_PTE_ADDR_ENCODE(addr) GEN6_GTT_ADDR_ENCODE(addr)
+
static inline gtt_pte_t pte_encode(struct drm_device *dev,
dma_addr_t addr,
enum i915_cache_level level)
@@ -262,6 +276,68 @@ void i915_ppgtt_unbind_object(struct i915_hw_ppgtt *ppgtt,
obj-base.size PAGE_SHIFT);
}
+void i915_gem_init_ppgtt(struct drm_device *dev)
+{
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ uint32_t pd_offset;
+ struct intel_ring_buffer *ring;
+ struct i915_hw_ppgtt *ppgtt = dev_priv-mm.aliasing_ppgtt;
+ uint32_t __iomem *pd_addr;
+ uint32_t pd_entry;
+ int i;
+
+ if (!dev_priv-mm.aliasing_ppgtt)
+ return;
+
+
+ pd_addr = dev_priv-mm.gtt-gtt + ppgtt-pd_offset/sizeof(uint32_t);
+ for (i = 0; i ppgtt-num_pd_entries; i++) {
+ dma_addr_t pt_addr;
+
+ if (dev_priv-mm.gtt-needs_dmar)
+ pt_addr = ppgtt-pt_dma_addr[i];
+ else
+ pt_addr = page_to_phys(ppgtt-pt_pages[i]);
+
+ pd_entry = GEN6_PDE_ADDR_ENCODE(pt_addr);
+
[Intel-gfx] [PATCH v2] drm/i915: Add SURFLIVE register definitions
From: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- v2: Rebased on top of drm-intel-next-queued drivers/gpu/drm/i915/i915_reg.h |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index d4520d5..fc3bf58 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3043,6 +3043,7 @@ #define _DSPASURF 0x7019C /* 965+ only */ #define _DSPATILEOFF 0x701A4 /* 965+ only */ #define _DSPAOFFSET0x701A4 /* HSW */ +#define _DSPASURFLIVE 0x701AC #define DSPCNTR(plane) _PIPE(plane, _DSPACNTR, _DSPBCNTR) #define DSPADDR(plane) _PIPE(plane, _DSPAADDR, _DSPBADDR) @@ -3053,6 +3054,7 @@ #define DSPTILEOFF(plane) _PIPE(plane, _DSPATILEOFF, _DSPBTILEOFF) #define DSPLINOFF(plane) DSPADDR(plane) #define DSPOFFSET(plane) _PIPE(plane, _DSPAOFFSET, _DSPBOFFSET) +#define DSPSURFLIVE(plane) _PIPE(plane, _DSPASURFLIVE, _DSPBSURFLIVE) /* Display/Sprite base address macros */ #define DISP_BASEADDR_MASK (0xf000) @@ -3099,6 +3101,7 @@ #define _DSPBSURF 0x7119C #define _DSPBTILEOFF 0x711A4 #define _DSPBOFFSET0x711A4 +#define _DSPBSURFLIVE 0x711AC /* Sprite A control */ #define _DVSACNTR 0x72180 @@ -3164,6 +3167,7 @@ #define DVSTILEOFF(pipe) _PIPE(pipe, _DVSATILEOFF, _DVSBTILEOFF) #define DVSKEYVAL(pipe) _PIPE(pipe, _DVSAKEYVAL, _DVSBKEYVAL) #define DVSKEYMSK(pipe) _PIPE(pipe, _DVSAKEYMSK, _DVSBKEYMSK) +#define DVSSURFLIVE(pipe) _PIPE(pipe, _DVSASURFLIVE, _DVSBSURFLIVE) #define _SPRA_CTL 0x70280 #define SPRITE_ENABLE(131) @@ -3199,6 +3203,7 @@ #define _SPRA_KEYMAX 0x702a0 #define _SPRA_TILEOFF 0x702a4 #define _SPRA_OFFSET 0x702a4 +#define _SPRA_SURFLIVE 0x702ac #define _SPRA_SCALE0x70304 #define SPRITE_SCALE_ENABLE (131) #define SPRITE_FILTER_MASK (329) @@ -3220,6 +3225,7 @@ #define _SPRB_KEYMAX 0x712a0 #define _SPRB_TILEOFF 0x712a4 #define _SPRB_OFFSET 0x712a4 +#define _SPRB_SURFLIVE 0x712ac #define _SPRB_SCALE0x71304 #define _SPRB_GAMC 0x71400 @@ -3236,6 +3242,7 @@ #define SPROFFSET(pipe) _PIPE(pipe, _SPRA_OFFSET, _SPRB_OFFSET) #define SPRSCALE(pipe) _PIPE(pipe, _SPRA_SCALE, _SPRB_SCALE) #define SPRGAMC(pipe) _PIPE(pipe, _SPRA_GAMC, _SPRB_GAMC) +#define SPRSURFLIVE(pipe) _PIPE(pipe, _SPRA_SURFLIVE, _SPRB_SURFLIVE) /* VBIOS regs */ #define VGACNTRL 0x71400 -- 1.7.8.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] dmesg filter
On Thu, Nov 1, 2012 at 4:56 PM, Eric Anholt e...@anholt.net wrote: Damien Lespiau damien.lesp...@gmail.com writes: The goal here is to make dmesg output with the full verbosity a bit easier to parse by a human. The script will transform: Couldn't a little bit of preprocessor in the kernel ioctl definitions give us decent names right in the dmesg? Oh, that sounds entirely possible. For some reason I assumed people would not like that change. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] drm/i915: i915_gem_execbuffer_wait_for_flips and other flip stuff
Another attempt at getting rid of i915_gem_execbuffer_wait_for_flips(). There's two versions of the patch: 3a just skips the function on SNB+ 3b kills it completely I'll let someone else make the decision which way to go. Just dropping it looks reasonably safe to me. xf86-video-intel never seemed to depend on it feature, based on the fact that when the page flip ioctl was introduced, the event was used from the get go to complete the DRI2 swaps. DRI2 has always (well as long as it had page flip support) throttled the client in the GetBuffers request if there were pending swaps. Of course I can't be 100% sure that there isn't some other piece of user space code depending on this feature. This series was basically just boot tested. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3b/3] drm/i915: Kill i915_gem_execbuffer_wait_for_flips()
From: Ville Syrjälä ville.syrj...@linux.intel.com
As per Chris Wilson's suggestion make
i915_gem_execbuffer_wait_for_flips() go away.
This was used to stall the GPU ring while there are pending
page flips involving the relevant BO. Ie. while the BO is still
being scanned out by the display controller.
The recommended alternative is to use the page flip events to
wait for the page flips to fully complete before reusing the BO
of the old front buffer. Or use more buffers.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
v2: Fixed the wait_event() logic mixup of v1
drivers/gpu/drm/i915/i915_drv.h|7
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 42
drivers/gpu/drm/i915/intel_display.c | 13
3 files changed, 0 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a2c5e89..facfd2e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1055,13 +1055,6 @@ struct drm_i915_gem_object {
/** for phy allocated objects */
struct drm_i915_gem_phys_object *phys_obj;
-
- /**
-* Number of crtcs where this object is currently the fb, but
-* will be page flipped away on the next vblank. When it
-* reaches 0, dev_priv-pending_flip_queue will be woken up.
-*/
- atomic_t pending_flip;
};
#define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 91d43d5..2e527be 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -611,44 +611,11 @@ err:
}
static int
-i915_gem_execbuffer_wait_for_flips(struct intel_ring_buffer *ring, u32 flips)
-{
- u32 plane, flip_mask;
- int ret;
-
- /* Check for any pending flips. As we only maintain a flip queue depth
-* of 1, we can simply insert a WAIT for the next display flip prior
-* to executing the batch and avoid stalling the CPU.
-*/
-
- for (plane = 0; flips plane; plane++) {
- if (((flips plane) 1) == 0)
- continue;
-
- if (plane)
- flip_mask = MI_WAIT_FOR_PLANE_B_FLIP;
- else
- flip_mask = MI_WAIT_FOR_PLANE_A_FLIP;
-
- ret = intel_ring_begin(ring, 2);
- if (ret)
- return ret;
-
- intel_ring_emit(ring, MI_WAIT_FOR_EVENT | flip_mask);
- intel_ring_emit(ring, MI_NOOP);
- intel_ring_advance(ring);
- }
-
- return 0;
-}
-
-static int
i915_gem_execbuffer_move_to_gpu(struct intel_ring_buffer *ring,
struct list_head *objects)
{
struct drm_i915_gem_object *obj;
uint32_t flush_domains = 0;
- uint32_t flips = 0;
int ret;
list_for_each_entry(obj, objects, exec_list) {
@@ -659,18 +626,9 @@ i915_gem_execbuffer_move_to_gpu(struct intel_ring_buffer
*ring,
if (obj-base.write_domain I915_GEM_DOMAIN_CPU)
i915_gem_clflush_object(obj);
- if (obj-base.pending_write_domain)
- flips |= atomic_read(obj-pending_flip);
-
flush_domains |= obj-base.write_domain;
}
- if (flips) {
- ret = i915_gem_execbuffer_wait_for_flips(ring, flips);
- if (ret)
- return ret;
- }
-
if (flush_domains I915_GEM_DOMAIN_CPU)
intel_gtt_chipset_flush();
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7bf4749..68bea06 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2182,10 +2182,6 @@ intel_finish_fb(struct drm_framebuffer *old_fb)
bool was_interruptible = dev_priv-mm.interruptible;
int ret;
- wait_event(dev_priv-pending_flip_queue,
- atomic_read(dev_priv-mm.wedged) ||
- atomic_read(obj-pending_flip) == 0);
-
/* Big Hammer, we also need to ensure that any pending
* MI_WAIT_FOR_EVENT inside a user batch buffer on the
* current scanout is retired before unpinning the old
@@ -6897,9 +6893,6 @@ static void do_intel_finish_page_flip(struct drm_device
*dev,
obj = work-old_fb_obj;
- atomic_clear_mask(1 intel_crtc-plane,
- obj-pending_flip.counter);
-
wake_up(dev_priv-pending_flip_queue);
schedule_work(work-work);
@@ -7241,11 +7234,6 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
work-enable_stall_check = true;
- /* Block clients from rendering to the new back buffer until
-* the flip occurs and the object is no longer visible.
-
[Intel-gfx] [PATCH 1/3] drm/i915: Wait for pending flips in intel_pipe_set_base()
From: Ville Syrjälä ville.syrj...@linux.intel.com
intel_pipe_set_base() never actually waited for any pending page flips
on the CRTC. It looks like it tried to, by calling intel_finish_fb() on
the current front buffer. But the pending flips were actually tracked
in the BO of the previous front buffer, so the call to intel_finish_fb()
never did anything useful.
Now even the pending_flip counter is gone, so we should just
use intel_crtc_wait_for_pending_flips(), but since we're already holding
struct_mutex when we would call that function, we need another version
of it, that itself doesn't lock struct_mutex.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 51 +
1 files changed, 32 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1a38267..7bf4749 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2228,6 +2228,37 @@ static void intel_crtc_update_sarea_pos(struct drm_crtc
*crtc, int x, int y)
}
}
+static bool intel_crtc_has_pending_flip(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ unsigned long flags;
+ bool pending;
+
+ if (atomic_read(dev_priv-mm.wedged))
+ return false;
+
+ spin_lock_irqsave(dev-event_lock, flags);
+ pending = to_intel_crtc(crtc)-unpin_work != NULL;
+ spin_unlock_irqrestore(dev-event_lock, flags);
+
+ return pending;
+}
+
+static void intel_crtc_wait_for_pending_flips_locked(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (crtc-fb == NULL)
+ return;
+
+ wait_event(dev_priv-pending_flip_queue,
+ !intel_crtc_has_pending_flip(crtc));
+
+ intel_finish_fb(crtc-fb);
+}
+
static int
intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *fb)
@@ -2261,8 +2292,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
return ret;
}
- if (crtc-fb)
- intel_finish_fb(crtc-fb);
+ intel_crtc_wait_for_pending_flips_locked(crtc);
ret = dev_priv-display.update_plane(crtc, fb, x, y);
if (ret) {
@@ -2901,23 +2931,6 @@ static void ironlake_fdi_disable(struct drm_crtc *crtc)
udelay(100);
}
-static bool intel_crtc_has_pending_flip(struct drm_crtc *crtc)
-{
- struct drm_device *dev = crtc-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- unsigned long flags;
- bool pending;
-
- if (atomic_read(dev_priv-mm.wedged))
- return false;
-
- spin_lock_irqsave(dev-event_lock, flags);
- pending = to_intel_crtc(crtc)-unpin_work != NULL;
- spin_unlock_irqrestore(dev-event_lock, flags);
-
- return pending;
-}
-
static void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc-dev;
--
1.7.8.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 29/36] drm/i915: use PIPECONF_INTERLACE_MASK_HSW on lpt_enable_pch_transcoder
On Thu, Nov 01, 2012 at 02:53:40PM -0200, Paulo Zanoni wrote: Hi 2012/11/1 Daniel Vetter dan...@ffwll.ch: On Wed, Oct 31, 2012 at 06:12:48PM -0200, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com ... instead of PIPECONF_INTERLACE_MASK. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com My Bspec here still has bits 23:21 for the interlaced bits on the lpt pch, but everything with bit 23 set is a reserved value. Sinc we set the correct stuff anyway, I don't think we need to change the mask here - the same would apply to cpt. So I'll drop this one here. But here we're dealing with pipeconf_val which the value we read in PIPECONF, which is on the CPU, not on the PCH. TRANS_CONF has bits 23:21 for the interlaced mode, but PIPECONF has bits 22:21 for the interlaced mode. We're reading from PIPECONF to write to TRANSCONF, but the mask is being applied to pipeconf, so the mask should be 22:21. I still think my patch is correct. Ah, now I see, thanks for the correction, patch applied. Btw, while reading Bspec I've noticed some restrictions on the interlaced mode we're using (i.e. progressive-interlaced conversion): We seem to need a 7x5 panel fitter (which doesn't exist on all pipes) and have a limit of 2048 on the source width ... -Daniel -Daniel --- drivers/gpu/drm/i915/intel_display.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 066994f..4fbb296 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1733,7 +1733,8 @@ static void lpt_enable_pch_transcoder(struct drm_i915_private *dev_priv, pipeconf_val = I915_READ(PIPECONF(cpu_transcoder)); val = ~TRANS_INTERLACE_MASK; - if ((pipeconf_val PIPECONF_INTERLACE_MASK) == PIPECONF_INTERLACED_ILK) + if ((pipeconf_val PIPECONF_INTERLACE_MASK_HSW) == + PIPECONF_INTERLACED_ILK) val |= TRANS_INTERLACED; else val |= TRANS_PROGRESSIVE; -- 1.7.11.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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
Re: [Intel-gfx] [PATCH v2] drm/i915: Add SURFLIVE register definitions
On Thu, Nov 01, 2012 at 07:26:45PM +0200, 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 --- Queued for -next, thanks for the patch. And don't ask me why it didn't work last time around ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: set the correct number of FDI lanes on Haswell
From: Paulo Zanoni paulo.r.zan...@intel.com
We had 2 places using X2 and one place using X1.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 67bd6ba..a7a555f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -171,7 +171,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
I915_WRITE(DDI_BUF_CTL(PORT_E),
temp |
DDI_BUF_CTL_ENABLE |
- DDI_PORT_WIDTH_X2 |
+ ((intel_crtc-fdi_lanes - 1) 1) |
hsw_ddi_buf_ctl_values[i]);
udelay(600);
@@ -193,7 +193,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
FDI_RX_ENABLE |
FDI_LINK_TRAIN_PATTERN_1_CPT |
FDI_RX_ENHANCE_FRAME_ENABLE |
- FDI_PORT_WIDTH_2X_LPT |
+ ((intel_crtc-fdi_lanes - 1) 19) |
FDI_RX_PLL_ENABLE);
POSTING_READ(reg);
udelay(100);
@@ -952,6 +952,7 @@ void intel_ddi_enable_pipe_func(struct drm_crtc *crtc)
} else if (type == INTEL_OUTPUT_ANALOG) {
temp |= TRANS_DDI_MODE_SELECT_FDI;
+ temp |= (intel_crtc-fdi_lanes - 1) 1;
} else if (type == INTEL_OUTPUT_DISPLAYPORT ||
type == INTEL_OUTPUT_EDP) {
--
1.7.11.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: fix Haswell FDI link training code
From: Paulo Zanoni paulo.r.zan...@intel.com This commit makes hsw_fdi_link_train responsible for implementing everything described in the Enable and train FDI section from the Hawell CRT mode set sequence documentation. We completely rewrite hsw_fdi_link_train to match the documentation and we also call it in the right place. This patch was initially sent as a series of tiny patches fixing every little problem of the function, but since there were too many patches fixing the same function it got a little difficult to get the big picture of how the function would be in the end, so here we amended all the patches into a single big patch fixing the whole function. Problems we fixed: 1 - Train Haswell FDI at the right time. We need to train the FDI before enabling the pipes and planes, so we're moving the call from lpt_pch_enable to haswell_crtc_enable directly. We are also removing ironlake_fdi_pll_enable since the PLL enablement on Haswell is completely different and is also done during the link training steps. 2 - Use the right FDI_RX_CTL register on Haswell There is only one PCH transcoder, so it's always _FDI_RXA_CTL. Using pipe here is wrong. 3 - Don't rely on DDI_BUF_CTL previous values Just set the bits we want, everything else is zero. Also POSTING_READ the register before sleeping. 4 - Program the FDI RX TUSIZE register on hsw_fdi_link_train According to the mode set sequence documentation, this is the right place. According to the FDI_RX_TUSIZE register description, this is the value we should set. Also remove the code that sets this register from the old location: lpt_pch_enable. 5 - Properly program FDI_RX_MISC pwrdn lane values on HSW 6 - Wait only 35us for the FDI link training First we wait 30us for the FDI receiver lane calibration, then we wait 5us for the FDI auto training time. 7 - Remove an useless indentation level on hsw_fdi_link_train We already break when the link training succeeds. 8 - Disable FDI_RX_ENABLE, not FDI_RX_PLL_ENABLE When we fail the training. 9 - Change Haswell FDI link training error messages We shouldn't call DRM_ERROR when still looping through voltage levels since this is expected and not really a failure. So in this commit we adjust the error path to only DRM_ERROR when we really fail after trying everything. While at it, replace DRM_DEBUG_DRIVER with DRM_DEBUG_KMS since it's what we use everywhere. 10 - Try each voltage twice at hsw_fdi_link_train Now with Daniel Vetter's suggestion to use /2 instead of 1. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/i915_reg.h | 17 -- drivers/gpu/drm/i915/intel_ddi.c | 108 +-- drivers/gpu/drm/i915/intel_display.c | 11 +--- 3 files changed, 76 insertions(+), 60 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index d4520d5..a167d76 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3924,16 +3924,21 @@ #define FDI_PORT_WIDTH_2X_LPT (119) #define FDI_PORT_WIDTH_1X_LPT (019) -#define _FDI_RXA_MISC0xf0010 -#define _FDI_RXB_MISC0xf1010 +#define _FDI_RXA_MISC 0xf0010 +#define _FDI_RXB_MISC 0xf1010 +#define FDI_RX_PWRDN_LANE1_MASK (326) +#define FDI_RX_PWRDN_LANE1_VAL(x) ((x)26) +#define FDI_RX_PWRDN_LANE0_MASK (324) +#define FDI_RX_PWRDN_LANE0_VAL(x) ((x)24) +#define FDI_RX_TP1_TO_TP2_48 (220) +#define FDI_RX_TP1_TO_TP2_64 (320) +#define FDI_RX_FDI_DELAY_90 (0x900) +#define FDI_RX_MISC(pipe) _PIPE(pipe, _FDI_RXA_MISC, _FDI_RXB_MISC) + #define _FDI_RXA_TUSIZE1 0xf0030 #define _FDI_RXA_TUSIZE2 0xf0038 #define _FDI_RXB_TUSIZE1 0xf1030 #define _FDI_RXB_TUSIZE2 0xf1038 -#define FDI_RX_TP1_TO_TP2_48 (220) -#define FDI_RX_TP1_TO_TP2_64 (320) -#define FDI_RX_FDI_DELAY_90 (0x900) -#define FDI_RX_MISC(pipe) _PIPE(pipe, _FDI_RXA_MISC, _FDI_RXB_MISC) #define FDI_RX_TUSIZE1(pipe) _PIPE(pipe, _FDI_RXA_TUSIZE1, _FDI_RXB_TUSIZE1) #define FDI_RX_TUSIZE2(pipe) _PIPE(pipe, _FDI_RXA_TUSIZE2, _FDI_RXB_TUSIZE2) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index a7a555f..92c2d61 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -153,11 +153,33 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) struct drm_device *dev = crtc-dev; struct drm_i915_private *dev_priv = dev-dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - int pipe = intel_crtc-pipe; - u32 reg, temp, i; + u32 temp, i, rx_ctl_val; + + /* Set the FDI_RX_MISC pwrdn lanes and the 2 workarounds listed at the +* mode set sequence for CRT port document: +
[Intel-gfx] [PATCH 3/4] drm/i915: fix Haswell FDI link disable path
From: Paulo Zanoni paulo.r.zan...@intel.com
This covers the Disable FDI section from the CRT mode set sequence.
This disables the FDI receiver and also the FDI pll.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 26 ++
drivers/gpu/drm/i915/intel_display.c | 3 +--
drivers/gpu/drm/i915/intel_drv.h | 4 +++-
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 92c2d61..38bc79d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1364,6 +1364,32 @@ void intel_ddi_prepare_link_retrain(struct drm_encoder
*encoder)
udelay(600);
}
+void intel_ddi_fdi_disable(struct drm_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = crtc-dev-dev_private;
+ struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
+ uint32_t val;
+
+ intel_ddi_post_disable(intel_encoder);
+
+ val = I915_READ(_FDI_RXA_CTL);
+ val = ~FDI_RX_ENABLE;
+ I915_WRITE(_FDI_RXA_CTL, val);
+
+ val = I915_READ(_FDI_RXA_MISC);
+ val = ~(FDI_RX_PWRDN_LANE1_MASK | FDI_RX_PWRDN_LANE0_MASK);
+ val |= FDI_RX_PWRDN_LANE1_VAL(2) | FDI_RX_PWRDN_LANE0_VAL(2);
+ I915_WRITE(_FDI_RXA_MISC, val);
+
+ val = I915_READ(_FDI_RXA_CTL);
+ val = ~FDI_PCDCLK;
+ I915_WRITE(_FDI_RXA_CTL, val);
+
+ val = I915_READ(_FDI_RXA_CTL);
+ val = ~FDI_RX_PLL_ENABLE;
+ I915_WRITE(_FDI_RXA_CTL, val);
+}
+
static void intel_ddi_hot_plug(struct intel_encoder *intel_encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(intel_encoder-base);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 69ed903..276a1c4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3619,10 +3619,9 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
encoder-post_disable(encoder);
if (is_pch_port) {
- ironlake_fdi_disable(crtc);
lpt_disable_pch_transcoder(dev_priv, pipe);
intel_disable_pch_pll(intel_crtc);
- ironlake_fdi_pll_disable(intel_crtc);
+ intel_ddi_fdi_disable(crtc);
}
intel_crtc-active = false;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 08238ef..bcc5241 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -662,6 +662,8 @@ extern bool intel_ddi_pll_mode_set(struct drm_crtc *crtc,
int clock);
extern void intel_ddi_put_crtc_pll(struct drm_crtc *crtc);
extern void intel_ddi_set_pipe_settings(struct drm_crtc *crtc);
extern void intel_ddi_prepare_link_retrain(struct drm_encoder *encoder);
-bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector);
+extern bool
+intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector);
+extern void intel_ddi_fdi_disable(struct drm_crtc *crtc);
#endif /* __INTEL_DRV_H__ */
--
1.7.11.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: use PIPECONF_INTERLACE_MASK_HSW on lpt_enable_pch_transcoder
From: Paulo Zanoni paulo.r.zan...@intel.com ... instead of PIPECONF_INTERLACE_MASK. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/intel_display.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 276a1c4..9b29d7c 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1703,7 +1703,8 @@ static void ironlake_enable_pch_transcoder(struct drm_i915_private *dev_priv, } val = ~TRANS_INTERLACE_MASK; - if ((pipeconf_val PIPECONF_INTERLACE_MASK) == PIPECONF_INTERLACED_ILK) + if ((pipeconf_val PIPECONF_INTERLACE_MASK_HSW) == + PIPECONF_INTERLACED_ILK) if (HAS_PCH_IBX(dev_priv-dev) intel_pipe_has_type(crtc, INTEL_OUTPUT_SDVO)) val |= TRANS_LEGACY_INTERLACED_ILK; -- 1.7.11.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 36/36] drm/i915: don't assert disabled FDI before disabling the FDI
On Wed, Oct 31, 2012 at 06:12:55PM -0200, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com On Haswell/LPT we must disable the PCH transcoder before we disable the FDI, so don't check for disabled FDI there. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com Ok, I've slurped in the last few patches here, safe for patch 35, I'll do that last. Next up: fdi link train madness ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: move panel connectors to the front
On Wed, Oct 31, 2012 at 04:05:33PM -0400, Adam Jackson wrote: On 10/27/12 9:52 AM, Daniel Vetter wrote: This essentially reverts commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae Author: Adam Jackson a...@redhat.com Date: Fri Jul 16 14:46:29 2010 -0400 drm/i915: Initialize LVDS and eDP outputs before anything else simply because it doesn't scale: It misses SDVO and DVO panels, and now with DDI encoders on haswell this is becoming unmanageable. Instead we simply sort the connector list after everything is set up. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Adam Jackson a...@redhat.com Slurped both this and the drm helper patch into dinq, thanks for the review. I'll annoy Dave about including the doc patches into his tree directly, he should get the pull which has the drm_dp_helper.c rename tomorrow. -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/5] drm/i915: kill pch_init_clock_gating indirection
On Thu, Nov 01, 2012 at 02:35:13PM -0200, Paulo Zanoni wrote: Hi 2012/10/31 Daniel Vetter daniel.vet...@ffwll.ch: Now that we no longer pretend to have flexibility in matching any north display block with any pch, we can ditch this. v2: Fix the embarassing rebase fail that Paulo Zanoni spotted. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com Series merged to dinq, thanks for the review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: fix Haswell FDI link training code
This is wrong Ignore it. I messed up rebasing it against the new patches. 2012/11/1 Paulo Zanoni przan...@gmail.com: From: Paulo Zanoni paulo.r.zan...@intel.com This commit makes hsw_fdi_link_train responsible for implementing everything described in the Enable and train FDI section from the Hawell CRT mode set sequence documentation. We completely rewrite hsw_fdi_link_train to match the documentation and we also call it in the right place. This patch was initially sent as a series of tiny patches fixing every little problem of the function, but since there were too many patches fixing the same function it got a little difficult to get the big picture of how the function would be in the end, so here we amended all the patches into a single big patch fixing the whole function. Problems we fixed: 1 - Train Haswell FDI at the right time. We need to train the FDI before enabling the pipes and planes, so we're moving the call from lpt_pch_enable to haswell_crtc_enable directly. We are also removing ironlake_fdi_pll_enable since the PLL enablement on Haswell is completely different and is also done during the link training steps. 2 - Use the right FDI_RX_CTL register on Haswell There is only one PCH transcoder, so it's always _FDI_RXA_CTL. Using pipe here is wrong. 3 - Don't rely on DDI_BUF_CTL previous values Just set the bits we want, everything else is zero. Also POSTING_READ the register before sleeping. 4 - Program the FDI RX TUSIZE register on hsw_fdi_link_train According to the mode set sequence documentation, this is the right place. According to the FDI_RX_TUSIZE register description, this is the value we should set. Also remove the code that sets this register from the old location: lpt_pch_enable. 5 - Properly program FDI_RX_MISC pwrdn lane values on HSW 6 - Wait only 35us for the FDI link training First we wait 30us for the FDI receiver lane calibration, then we wait 5us for the FDI auto training time. 7 - Remove an useless indentation level on hsw_fdi_link_train We already break when the link training succeeds. 8 - Disable FDI_RX_ENABLE, not FDI_RX_PLL_ENABLE When we fail the training. 9 - Change Haswell FDI link training error messages We shouldn't call DRM_ERROR when still looping through voltage levels since this is expected and not really a failure. So in this commit we adjust the error path to only DRM_ERROR when we really fail after trying everything. While at it, replace DRM_DEBUG_DRIVER with DRM_DEBUG_KMS since it's what we use everywhere. 10 - Try each voltage twice at hsw_fdi_link_train Now with Daniel Vetter's suggestion to use /2 instead of 1. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/i915_reg.h | 17 -- drivers/gpu/drm/i915/intel_ddi.c | 108 +-- drivers/gpu/drm/i915/intel_display.c | 11 +--- 3 files changed, 76 insertions(+), 60 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index d4520d5..a167d76 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3924,16 +3924,21 @@ #define FDI_PORT_WIDTH_2X_LPT (119) #define FDI_PORT_WIDTH_1X_LPT (019) -#define _FDI_RXA_MISC0xf0010 -#define _FDI_RXB_MISC0xf1010 +#define _FDI_RXA_MISC 0xf0010 +#define _FDI_RXB_MISC 0xf1010 +#define FDI_RX_PWRDN_LANE1_MASK (326) +#define FDI_RX_PWRDN_LANE1_VAL(x) ((x)26) +#define FDI_RX_PWRDN_LANE0_MASK (324) +#define FDI_RX_PWRDN_LANE0_VAL(x) ((x)24) +#define FDI_RX_TP1_TO_TP2_48 (220) +#define FDI_RX_TP1_TO_TP2_64 (320) +#define FDI_RX_FDI_DELAY_90 (0x900) +#define FDI_RX_MISC(pipe) _PIPE(pipe, _FDI_RXA_MISC, _FDI_RXB_MISC) + #define _FDI_RXA_TUSIZE1 0xf0030 #define _FDI_RXA_TUSIZE2 0xf0038 #define _FDI_RXB_TUSIZE1 0xf1030 #define _FDI_RXB_TUSIZE2 0xf1038 -#define FDI_RX_TP1_TO_TP2_48 (220) -#define FDI_RX_TP1_TO_TP2_64 (320) -#define FDI_RX_FDI_DELAY_90 (0x900) -#define FDI_RX_MISC(pipe) _PIPE(pipe, _FDI_RXA_MISC, _FDI_RXB_MISC) #define FDI_RX_TUSIZE1(pipe) _PIPE(pipe, _FDI_RXA_TUSIZE1, _FDI_RXB_TUSIZE1) #define FDI_RX_TUSIZE2(pipe) _PIPE(pipe, _FDI_RXA_TUSIZE2, _FDI_RXB_TUSIZE2) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index a7a555f..92c2d61 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -153,11 +153,33 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) struct drm_device *dev = crtc-dev; struct drm_i915_private *dev_priv = dev-dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - int pipe
Re: [Intel-gfx] [PATCH] scripts: Add a dmesg filter to prettify ioctl traces
Am Donnerstag, den 01.11.2012, 16:42 + schrieb Damien Lespiau: From: Damien Lespiau damien.lesp...@intel.com The content of the cover letter would have been very useful for this commit message body. ;-) Signed-off-by: Damien Lespiau damien.lesp...@intel.com […] Thanks, Paul signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: fix Haswell FDI link training code
From: Paulo Zanoni paulo.r.zan...@intel.com This commit makes hsw_fdi_link_train responsible for implementing everything described in the Enable and train FDI section from the Hawell CRT mode set sequence documentation. We completely rewrite hsw_fdi_link_train to match the documentation and we also call it in the right place. This patch was initially sent as a series of tiny patches fixing every little problem of the function, but since there were too many patches fixing the same function it got a little difficult to get the big picture of how the function would be in the end, so here we amended all the patches into a single big patch fixing the whole function. Problems we fixed: 1 - Train Haswell FDI at the right time. We need to train the FDI before enabling the pipes and planes, so we're moving the call from lpt_pch_enable to haswell_crtc_enable directly. We are also removing ironlake_fdi_pll_enable since the PLL enablement on Haswell is completely different and is also done during the link training steps. 2 - Use the right FDI_RX_CTL register on Haswell There is only one PCH transcoder, so it's always _FDI_RXA_CTL. Using pipe here is wrong. 3 - Don't rely on DDI_BUF_CTL previous values Just set the bits we want, everything else is zero. Also POSTING_READ the register before sleeping. 4 - Program the FDI RX TUSIZE register on hsw_fdi_link_train According to the mode set sequence documentation, this is the right place. According to the FDI_RX_TUSIZE register description, this is the value we should set. Also remove the code that sets this register from the old location: lpt_pch_enable. 5 - Properly program FDI_RX_MISC pwrdn lane values on HSW 6 - Wait only 35us for the FDI link training First we wait 30us for the FDI receiver lane calibration, then we wait 5us for the FDI auto training time. 7 - Remove an useless indentation level on hsw_fdi_link_train We already break when the link training succeeds. 8 - Disable FDI_RX_ENABLE, not FDI_RX_PLL_ENABLE When we fail the training. 9 - Change Haswell FDI link training error messages We shouldn't call DRM_ERROR when still looping through voltage levels since this is expected and not really a failure. So in this commit we adjust the error path to only DRM_ERROR when we really fail after trying everything. While at it, replace DRM_DEBUG_DRIVER with DRM_DEBUG_KMS since it's what we use everywhere. 10 - Try each voltage twice at hsw_fdi_link_train Now with Daniel Vetter's suggestion to use /2 instead of 1. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/i915_reg.h | 17 -- drivers/gpu/drm/i915/intel_ddi.c | 108 +-- drivers/gpu/drm/i915/intel_display.c | 11 +--- 3 files changed, 76 insertions(+), 60 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 3674891..5e820fa 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3936,16 +3936,21 @@ #define FDI_PORT_WIDTH_2X_LPT (119) #define FDI_PORT_WIDTH_1X_LPT (019) -#define _FDI_RXA_MISC0xf0010 -#define _FDI_RXB_MISC0xf1010 +#define _FDI_RXA_MISC 0xf0010 +#define _FDI_RXB_MISC 0xf1010 +#define FDI_RX_PWRDN_LANE1_MASK (326) +#define FDI_RX_PWRDN_LANE1_VAL(x) ((x)26) +#define FDI_RX_PWRDN_LANE0_MASK (324) +#define FDI_RX_PWRDN_LANE0_VAL(x) ((x)24) +#define FDI_RX_TP1_TO_TP2_48 (220) +#define FDI_RX_TP1_TO_TP2_64 (320) +#define FDI_RX_FDI_DELAY_90 (0x900) +#define FDI_RX_MISC(pipe) _PIPE(pipe, _FDI_RXA_MISC, _FDI_RXB_MISC) + #define _FDI_RXA_TUSIZE1 0xf0030 #define _FDI_RXA_TUSIZE2 0xf0038 #define _FDI_RXB_TUSIZE1 0xf1030 #define _FDI_RXB_TUSIZE2 0xf1038 -#define FDI_RX_TP1_TO_TP2_48 (220) -#define FDI_RX_TP1_TO_TP2_64 (320) -#define FDI_RX_FDI_DELAY_90 (0x900) -#define FDI_RX_MISC(pipe) _PIPE(pipe, _FDI_RXA_MISC, _FDI_RXB_MISC) #define FDI_RX_TUSIZE1(pipe) _PIPE(pipe, _FDI_RXA_TUSIZE1, _FDI_RXB_TUSIZE1) #define FDI_RX_TUSIZE2(pipe) _PIPE(pipe, _FDI_RXA_TUSIZE2, _FDI_RXB_TUSIZE2) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index a7a555f..92c2d61 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -153,11 +153,33 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) struct drm_device *dev = crtc-dev; struct drm_i915_private *dev_priv = dev-dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - int pipe = intel_crtc-pipe; - u32 reg, temp, i; + u32 temp, i, rx_ctl_val; + + /* Set the FDI_RX_MISC pwrdn lanes and the 2 workarounds listed at the +* mode set sequence for CRT port document: +
[Intel-gfx] [PATCH 3/4] drm/i915: fix Haswell FDI link disable path
From: Paulo Zanoni paulo.r.zan...@intel.com
This covers the Disable FDI section from the CRT mode set sequence.
This disables the FDI receiver and also the FDI pll.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 26 ++
drivers/gpu/drm/i915/intel_display.c | 3 +--
drivers/gpu/drm/i915/intel_drv.h | 4 +++-
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 92c2d61..38bc79d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1364,6 +1364,32 @@ void intel_ddi_prepare_link_retrain(struct drm_encoder
*encoder)
udelay(600);
}
+void intel_ddi_fdi_disable(struct drm_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = crtc-dev-dev_private;
+ struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
+ uint32_t val;
+
+ intel_ddi_post_disable(intel_encoder);
+
+ val = I915_READ(_FDI_RXA_CTL);
+ val = ~FDI_RX_ENABLE;
+ I915_WRITE(_FDI_RXA_CTL, val);
+
+ val = I915_READ(_FDI_RXA_MISC);
+ val = ~(FDI_RX_PWRDN_LANE1_MASK | FDI_RX_PWRDN_LANE0_MASK);
+ val |= FDI_RX_PWRDN_LANE1_VAL(2) | FDI_RX_PWRDN_LANE0_VAL(2);
+ I915_WRITE(_FDI_RXA_MISC, val);
+
+ val = I915_READ(_FDI_RXA_CTL);
+ val = ~FDI_PCDCLK;
+ I915_WRITE(_FDI_RXA_CTL, val);
+
+ val = I915_READ(_FDI_RXA_CTL);
+ val = ~FDI_RX_PLL_ENABLE;
+ I915_WRITE(_FDI_RXA_CTL, val);
+}
+
static void intel_ddi_hot_plug(struct intel_encoder *intel_encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(intel_encoder-base);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 58911bd..8fbfc731f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3632,9 +3632,8 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
encoder-post_disable(encoder);
if (is_pch_port) {
- ironlake_fdi_disable(crtc);
lpt_disable_pch_transcoder(dev_priv);
- ironlake_fdi_pll_disable(intel_crtc);
+ intel_ddi_fdi_disable(crtc);
}
intel_crtc-active = false;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 08238ef..bcc5241 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -662,6 +662,8 @@ extern bool intel_ddi_pll_mode_set(struct drm_crtc *crtc,
int clock);
extern void intel_ddi_put_crtc_pll(struct drm_crtc *crtc);
extern void intel_ddi_set_pipe_settings(struct drm_crtc *crtc);
extern void intel_ddi_prepare_link_retrain(struct drm_encoder *encoder);
-bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector);
+extern bool
+intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector);
+extern void intel_ddi_fdi_disable(struct drm_crtc *crtc);
#endif /* __INTEL_DRV_H__ */
--
1.7.11.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/18] drm/i915: Fix detection of stolen base for gen2
On Fri, 19 Oct 2012 18:03:08 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
It was not until the G33 refresh, that a PCI config register was
introduced that explicitly said where the stolen memory was. Prior to
865G there was not even a register that said where the end of usable
low memory was and where the stolen memory began (or ended depending
upon chipset). Before then, one has to look at the BIOS memory maps to
find the Top of Memory. Alas that is not exported by arch/x86 and so we
have to resort to disabling stolen memory on gen2 for the time being.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h|1 +
drivers/gpu/drm/i915/i915_gem_stolen.c | 69
++--
2 files changed, 31 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4728d30..687f379 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -705,6 +705,7 @@ typedef struct drm_i915_private {
unsigned long gtt_start;
unsigned long gtt_mappable_end;
unsigned long gtt_end;
+ unsigned long stolen_base; /* limited to low memory (32-bit) */
struct io_mapping *gtt_mapping;
phys_addr_t gtt_base_addr;
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index ada2e90..a01ff74 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -43,56 +43,43 @@
* for is a boon.
*/
-#define PTE_ADDRESS_MASK 0xf000
-#define PTE_ADDRESS_MASK_HIGH0x00f0 /* i915+ */
-#define PTE_MAPPING_TYPE_UNCACHED(0 1)
-#define PTE_MAPPING_TYPE_DCACHE (1 1) /* i830 only */
-#define PTE_MAPPING_TYPE_CACHED (3 1)
-#define PTE_MAPPING_TYPE_MASK(3 1)
-#define PTE_VALID(1 0)
-
-/**
- * i915_stolen_to_phys - take an offset into stolen memory and turn it into
- * a physical one
- * @dev: drm device
- * @offset: address to translate
- *
- * Some chip functions require allocations from stolen space and need the
- * physical address of the memory in question.
- */
-static unsigned long i915_stolen_to_phys(struct drm_device *dev, u32 offset)
+static unsigned long i915_stolen_to_physical(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct pci_dev *pdev = dev_priv-bridge_dev;
u32 base;
-#if 0
/* On the machines I have tested the Graphics Base of Stolen Memory
- * is unreliable, so compute the base by subtracting the stolen memory
- * from the Top of Low Usable DRAM which is where the BIOS places
- * the graphics stolen memory.
+ * is unreliable, so on those compute the base by subtracting the
+ * stolen memory from the Top of Low Usable DRAM which is where the
+ * BIOS places the graphics stolen memory.
+ *
+ * On gen2, the layout is slightly different with the Graphics Segment
+ * immediately following Top of Memory (or Top of Usable DRAM). Note
+ * it appears that TOUD is only reported by 865g, so we just use the
+ * top of memory as determined by the e820 probe.
+ *
+ * XXX gen2 requires an unavailable symbol and 945gm fails with
+ * its value of TOLUD.
*/
+ base = 0;
if (INTEL_INFO(dev)-gen 3 || IS_G33(dev)) {
- /* top 32bits are reserved = 0 */
+ /* Read Graphics Base of Stolen Memory directly */
pci_read_config_dword(pdev, 0xA4, base);
- } else {
- /* XXX presume 8xx is the same as i915 */
- pci_bus_read_config_dword(pdev-bus, 2, 0x5C, base);
- }
-#else
- if (INTEL_INFO(dev)-gen 3 || IS_G33(dev)) {
- u16 val;
- pci_read_config_word(pdev, 0xb0, val);
- base = val 4 20;
- } else {
+#if 0
+ } else if (IS_GEN3(dev)) {
u8 val;
+ /* Stolen is immediately below Top of Low Usable DRAM */
pci_read_config_byte(pdev, 0x9c, val);
base = val 3 27;
- }
- base -= dev_priv-mm.gtt-stolen_size;
+ base -= dev_priv-mm.gtt-stolen_size;
+ } else {
+ /* Stolen is immediately above Top of Memory */
+ base = max_low_pfn_mapped PAGE_SHIFT;
#endif
+ }
- return base + offset;
+ return base;
}
Comments on this below.
static void i915_warn_stolen(struct drm_device *dev)
@@ -117,7 +104,7 @@ static void i915_setup_compression(struct drm_device
*dev, int size)
if (!compressed_fb)
goto err;
- cfb_base = i915_stolen_to_phys(dev, compressed_fb-start);
+ cfb_base = dev_priv-mm.stolen_base + compressed_fb-start;
Re: [Intel-gfx] [PATCH 03/18] drm/i915: Fix location of stolen memory register for SandyBridge+
On Sun, 28 Oct 2012 09:48:35 + Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, 26 Oct 2012 14:58:45 -0700, Ben Widawsky b...@bwidawsk.net wrote: On Fri, 19 Oct 2012 18:03:09 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: A few of the earlier registers where enlarged and so the Base Data of Stolen Memory Register (BDSM) was pushed to 0xb0. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org This patch seems irrelevant to me. I have a i915_stolen_to_phys which already looks correct (git blame shows you last updated it in April). Can you help unconfuse me? As the patch suggests the current registers being used by stolen-to-phys are incorrect for SNB+. -Chris It looks like all you've done here is fix up the bug you left from patch2. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
