Re: [Intel-gfx] [PATCH] [v4] drm/i915: Capture current context on error
On Mon, Mar 04, 2013 at 05:00:29PM -0800, Ben Widawsky wrote: On error, this represents the state of the currently running context at the time it was loaded. Unfortunately, since we're hung and can't switch out the context this may not tell us too much about the most current state of the context, but does give clues about what has happened since loading. Thanks to recent doc updates, we have a little more confidence regarding what is actually in this memory, and perhaps it will help us gain more insight into certain bugs. AFAICT, the most interesting info is in the first page. To save space, we only capture the first page. In the future, we might want to dump more. Sample of the relevant part of error state: render ring --- HW Context = 0x01b2 [] 1100105f 2028 0880 [0010] 209c feff4040 20c0 efdf0080 [0020] 2178 0001 217c 00145855 [0030] 2310 2314 v2: Move error collection to the ring error code Change format of dump to not confuse intel_error_decode (Chris) Put the context error object with the others (Chris) Don't search bound_list instead of active_list (chris) v3: extract and flatten context recording (daniel) checkpatch related fixes for the copypasta in debugfs v4: bug in v3 (Daniel) - if ((ring-id == RCS) error-ccid) + if ((ring-id != RCS) || !error-ccid) Still a redundant () pair here ... I've killed it. References: https://bugs.freedesktop.org/show_bug.cgi?id=55845 Reviewed-by (v2): Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ben Widawsky b...@bwidawsk.net Cc: Daniel Vetter daniel.vet...@ffwll.ch Queued for -next, thanks for the patch. -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] drm/i915: enable irqs earlier when resuming
We need it to restore the ilk rc6 context, since the gpu wait no requires interrupts. But in general having interrupts around should help in code sanity, since more and more stuff is interrupt driven. This regression has been introduced in commit 3e9605018ab3e333d51cc90fccfde2031886763b Author: Chris Wilson ch...@chris-wilson.co.uk Date: Tue Nov 27 16:22:54 2012 + drm/i915: Rearrange code to only have a single method for waiting upon the ring Like in the driver load code we need to make sure that hotplug interrupts don't cause havoc with our modeset state, hence block them with the existing infrastructure. Again we ignore races where we might loose hotplug interrupts ... Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54691 Cc: sta...@vger.kernel.org (for 3.8 only) Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Mika Kuoppala mika.kuopp...@intel.com Reported-and-Tested-by: Ilya Tumaykin itumay...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_drv.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index b342749..7589a2a 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -493,6 +493,7 @@ static int i915_drm_freeze(struct drm_device *dev) intel_modeset_disable(dev); drm_irq_uninstall(dev); + dev_priv-enable_hotplug_processing = false; } i915_save_state(dev); @@ -566,10 +567,20 @@ static int __i915_drm_thaw(struct drm_device *dev) error = i915_gem_init_hw(dev); mutex_unlock(dev-struct_mutex); + /* We need working interrupts for modeset enabling ... */ + drm_irq_install(dev); + intel_modeset_init_hw(dev); intel_modeset_setup_hw_state(dev, false); - drm_irq_install(dev); + + /* +* ... but also need to make sure that hotplug processing +* doesn't cause havoc. Like in the driver load code we don't +* bother with the tiny race here where we might loose hotplug +* notifications. +* */ intel_hpd_init(dev); + dev_priv-enable_hotplug_processing = true; } intel_opregion_init(dev); -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: enable irqs earlier when resuming
On Tue, Mar 05, 2013 at 09:50:58AM +0100, Daniel Vetter wrote: We need it to restore the ilk rc6 context, since the gpu wait no requires interrupts. But in general having interrupts around should help in code sanity, since more and more stuff is interrupt driven. This regression has been introduced in commit 3e9605018ab3e333d51cc90fccfde2031886763b Author: Chris Wilson ch...@chris-wilson.co.uk Date: Tue Nov 27 16:22:54 2012 + drm/i915: Rearrange code to only have a single method for waiting upon the ring Not entirely, as we can also regard this as an oversight from fixing up the irq sequence during initialisation... :-p Like in the driver load code we need to make sure that hotplug interrupts don't cause havoc with our modeset state, hence block them with the existing infrastructure. Again we ignore races where we might loose hotplug interrupts ... Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54691 Cc: sta...@vger.kernel.org (for 3.8 only) Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Mika Kuoppala mika.kuopp...@intel.com Reported-and-Tested-by: Ilya Tumaykin itumay...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Increase the RC6p threshold.
On Wed, Feb 27, 2013 at 08:23:56AM -0800, Jesse Barnes wrote: Great, then if it helps Stephane, I think we should merge it. Acked-by-top-post: Jesse Barnes jbar...@virtuousgeek.org And applied to -fixes. -Daniel On Wed, 27 Feb 2013 05:50:08 + Zhang, Ouping ouping.zh...@intel.com wrote: Increase the RC6p threshold from 10 to 15, there is no power difference between the two values. for example: (1) I915_WRITE(GEN6_RC6p_THRESHOLD, 10); video time: 11' video avg watt 31.3 watt-hour: 5.6 (2) I915_WRITE(GEN6_RC6p_THRESHOLD, 15); video time: 11' video avg watt 31.2 watt-hour: 5.6 -Original Message- From: Jesse Barnes [mailto:jbar...@virtuousgeek.org] Sent: Tuesday, February 26, 2013 12:14 AM To: Zhang, Ouping Cc: Stéphane Marchesin; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915: Increase the RC6p threshold. How does the watt-hour result compare to before the patch? Thanks, Jesse On Mon, 25 Feb 2013 07:33:38 + Zhang, Ouping ouping.zh...@intel.com wrote: running video workload, video avg watt = 38.4 and watt-hour = 6.9 cat /sys/class/drm/card0/power/rc6_residency_ms cat /sys/class/drm/card0/power/rc6p_residency_ms rc6_residency_ms increase from 6708 to 483627 rc6p_residency_ms increase from 410092 to 423378 -Original Message- From: Jesse Barnes [mailto:jbar...@virtuousgeek.org] Sent: Friday, February 22, 2013 12:50 AM To: Zhang, Ouping Cc: Stéphane Marchesin; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915: Increase the RC6p threshold. You have to modify the kernel to make the change Stephane suggested, then measure the energy consumption across your workloads. I'd expect the residency to change, but I'm ultimately concerned with the energy used. Jesse On Thu, 21 Feb 2013 05:08:10 + Zhang, Ouping ouping.zh...@intel.com wrote: Hi Jesse, Do you mean increase /sys/class/drm/card0/power/rc6p_residency_ms from 10 to 15, and measure power difference on IVB when system is on idle? -Original Message- From: Jesse Barnes [mailto:jbar...@virtuousgeek.org] Sent: Wednesday, February 20, 2013 8:16 AM To: Stéphane Marchesin Cc: intel-gfx@lists.freedesktop.org; Zhang, Ouping Subject: Re: [Intel-gfx] [PATCH] drm/i915: Increase the RC6p threshold. On Tue, 19 Feb 2013 15:53:56 -0800 Stéphane Marchesin marc...@chromium.org wrote: On Tue, Jan 29, 2013 at 7:41 PM, Stéphane Marchesin marc...@chromium.orgwrote: This increases GEN6_RC6p_THRESHOLD from 10 to 15. For some reason this avoids the gen6_gt_check_fifodbg.isra warnings and associated GPU lockups, which makes my ivy bridge machine stable. Ping? Seems ok to me. Ouping, can you measure any power difference between the two values? Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- Jesse Barnes, Intel Open Source Technology Center -- Jesse Barnes, Intel Open Source Technology Center -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v.3 06/12] DRM/i915: Add HPD IRQ storm detection (v3)
Add a hotplug IRQ storm detection (triggered when a hotplug interrupt
fires more than 5 times / sec).
Rationale:
Despite of the many attempts to fix the problem with noisy hotplug
interrupt lines we are still seeing systems which have issues:
Once cause of noise seems to be bad routing of the hotplug line
on the board: cross talk from other signals seems to cause erronous
hotplug interrupts. This has been documented as an erratum for the
the i945GM chipset and thus hotplug support was disabled for this
chipset model but others seem to have this problem, too.
We have seen this issue on a G35 motherboard for example:
Even different motherboards of the same model seem to behave
differently: while some only see only around 10-100 interrupts/s
others seem to see 5k or more.
We've also observed a dependency on the selected video mode.
Also on certain laptops interrupt noise seems to occur duing
battery charging when the battery is at a certain charge levels.
Thus we add a simple algorithm here that detects an 'interrupt storm'
condition.
v2: Fixed comment.
v3: Reordered drm_i915_private: moved hpd state tracking to hotplug work stuff.
Signed-off-by: Egbert Eich e...@suse.de
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h |9 +
drivers/gpu/drm/i915/i915_irq.c | 63 +++---
2 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d8604a6..296278f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -924,6 +924,15 @@ typedef struct drm_i915_private {
struct work_struct hotplug_work;
bool enable_hotplug_processing;
+ struct {
+ unsigned long hpd_last_jiffies;
+ int hpd_cnt;
+ enum {
+ HPD_ENABLED = 0,
+ HPD_DISABLED = 1,
+ HPD_MARK_DISABLED = 2
+ } hpd_mark;
+ } hpd_stats[HPD_NUM_PINS];
int num_pipe;
int num_pch_pll;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c40c7cc..24cb6ed 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -578,6 +578,34 @@ static void gen6_queue_rps_work(struct drm_i915_private
*dev_priv,
queue_work(dev_priv-wq, dev_priv-rps.work);
}
+static inline void hotplug_irq_storm_detect(struct drm_device *dev,
+ u32 hotplug_trigger,
+ const u32 *hpd)
+{
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ unsigned long irqflags;
+ int i;
+
+ spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+
+ for (i = 1; i HPD_NUM_PINS; i++) {
+ if ((hpd[i] hotplug_trigger)
+ dev_priv-hpd_stats[i].hpd_mark == HPD_ENABLED) {
+ if (jiffies (dev_priv-hpd_stats[i].hpd_last_jiffies
+ msecs_to_jiffies(1000)) ||
+ jiffies dev_priv-hpd_stats[i].hpd_last_jiffies) {
+ dev_priv-hpd_stats[i].hpd_last_jiffies =
jiffies;
+ dev_priv-hpd_stats[i].hpd_cnt = 0;
+ } else if (dev_priv-hpd_stats[i].hpd_cnt 5) {
+ dev_priv-hpd_stats[i].hpd_mark =
HPD_MARK_DISABLED;
+ DRM_DEBUG_KMS(HPD interrupt storm detected on
PIN %d\n, i);
+ } else
+ dev_priv-hpd_stats[i].hpd_cnt++;
+ }
+ }
+
+ spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
+}
+
static void gmbus_irq_handler(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = (drm_i915_private_t *)
dev-dev_private;
@@ -646,13 +674,15 @@ static irqreturn_t valleyview_irq_handler(int irq, void
*arg)
/* Consume port. Then clear IIR or we'll miss events */
if (iir I915_DISPLAY_PORT_INTERRUPT) {
u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
+ u32 hotplug_trigger = hotplug_status
HOTPLUG_INT_STATUS_I915;
DRM_DEBUG_DRIVER(hotplug event received, stat
0x%08x\n,
hotplug_status);
- if (hotplug_status HOTPLUG_INT_STATUS_I915)
+ if (hotplug_trigger) {
+ hotplug_irq_storm_detect(dev, hotplug_trigger,
hpd_status_i915);
queue_work(dev_priv-wq,
dev_priv-hotplug_work);
-
+ }
I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
I915_READ(PORT_HOTPLUG_STAT);
}
@@ -676,10 +706,12 @@ static void ibx_irq_handler(struct drm_device *dev, u32
pch_iir)
{
Re: [Intel-gfx] [PATCH] drm/i915: enable irqs earlier when resuming
On Tue, Mar 05, 2013 at 08:53:48AM +, Chris Wilson wrote: On Tue, Mar 05, 2013 at 09:50:58AM +0100, Daniel Vetter wrote: We need it to restore the ilk rc6 context, since the gpu wait no requires interrupts. But in general having interrupts around should help in code sanity, since more and more stuff is interrupt driven. This regression has been introduced in commit 3e9605018ab3e333d51cc90fccfde2031886763b Author: Chris Wilson ch...@chris-wilson.co.uk Date: Tue Nov 27 16:22:54 2012 + drm/i915: Rearrange code to only have a single method for waiting upon the ring Not entirely, as we can also regard this as an oversight from fixing up the irq sequence during initialisation... :-p Added a citation to the relevant commit ... Like in the driver load code we need to make sure that hotplug interrupts don't cause havoc with our modeset state, hence block them with the existing infrastructure. Again we ignore races where we might loose hotplug interrupts ... Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54691 Cc: sta...@vger.kernel.org (for 3.8 only) Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Mika Kuoppala mika.kuopp...@intel.com Reported-and-Tested-by: Ilya Tumaykin itumay...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris wilson ch...@chris-wilson.co.uk ... and merged to -fixes, 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
[Intel-gfx] [PATCH v.2 10/12] DRM/i915: Add Reenable Timer to turn Hotplug Detection back on (v2).
We disable hoptplug detection when we encounter a hotplug event
storm. Still hotplug detection is required on some outputs (like
Display Port). The interrupt storm may be only temporary (on certain
Dell Laptops for instance it happens at certain charging states of
the system). Thus we enable it after a certain grace period (2 minutes).
Should the interrupt storm persist it will be detected immediately
and it will be disabled again.
v2: Reordered drm_i915_private: moved hotplug_reenable_timer to hpd state
tracker.
Signed-off-by: Egbert Eich e...@suse.de
---
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/i915_irq.c | 53 ++-
2 files changed, 54 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 296278f..1fb7c44 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -933,6 +933,8 @@ typedef struct drm_i915_private {
HPD_MARK_DISABLED = 2
} hpd_mark;
} hpd_stats[HPD_NUM_PINS];
+#define I915_REENABLE_HOTPLUG_DELAY (2*60*1000)
+ struct timer_list hotplug_reenable_timer;
int num_pipe;
int num_pch_pll;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d11534c..c688b27 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -367,8 +367,11 @@ static void i915_hotplug_work_func(struct work_struct
*work)
connector_disabled = true;
}
}
- if (connector_disabled)
+ if (connector_disabled) {
drm_kms_helper_poll_enable(dev); /* if there were no outputs to
poll, poll is disabled */
+ mod_timer(dev_priv-hotplug_reenable_timer,
+ jiffies +
msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
+ }
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
@@ -2244,6 +2247,8 @@ static void valleyview_irq_uninstall(struct drm_device
*dev)
if (!dev_priv)
return;
+ del_timer_sync(dev_priv-hotplug_reenable_timer);
+
for_each_pipe(pipe)
I915_WRITE(PIPESTAT(pipe), 0x);
@@ -2265,6 +2270,8 @@ static void ironlake_irq_uninstall(struct drm_device *dev)
if (!dev_priv)
return;
+ del_timer_sync(dev_priv-hotplug_reenable_timer);
+
I915_WRITE(HWSTAM, 0x);
I915_WRITE(DEIMR, 0x);
@@ -2603,6 +2610,8 @@ static void i915_irq_uninstall(struct drm_device * dev)
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
int pipe;
+ del_timer_sync(dev_priv-hotplug_reenable_timer);
+
if (I915_HAS_HOTPLUG(dev)) {
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -2851,6 +2860,8 @@ static void i965_irq_uninstall(struct drm_device * dev)
if (!dev_priv)
return;
+ del_timer_sync(dev_priv-hotplug_reenable_timer);
+
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -2866,6 +2877,44 @@ static void i965_irq_uninstall(struct drm_device * dev)
I915_WRITE(IIR, I915_READ(IIR));
}
+static void i915_reenable_hotplug_timer_func(unsigned long data)
+{
+ drm_i915_private_t *dev_priv = (drm_i915_private_t *)data;
+ struct drm_device *dev = dev_priv-dev;
+ struct drm_mode_config *mode_config = dev-mode_config;
+ unsigned long irqflags;
+ int i;
+
+ spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+ for (i = 1; i HPD_NUM_PINS; i++) {
+ if (dev_priv-hpd_stats[i].hpd_mark == HPD_MARK_DISABLED) {
+ struct drm_connector *connector;
+
+ dev_priv-hpd_stats[i].hpd_mark = HPD_ENABLED;
+ list_for_each_entry(connector,
mode_config-connector_list, head) {
+ struct intel_connector *intel_connector =
to_intel_connector(connector);
+
+ if (intel_connector-encoder-hpd_pin == i) {
+ if (connector-polled !=
intel_connector-polled)
+ DRM_DEBUG_DRIVER(Reenabling
HPD on connector %s\n,
+
drm_get_connector_name(connector));
+ connector-polled =
intel_connector-polled;
+ if (!connector-polled)
+ connector-polled =
DRM_CONNECTOR_POLL_HPD;
+ }
+ }
+
+ if (IS_HASWELL(dev) ||
+ IS_IVYBRIDGE(dev) ||
+ (HAS_PCH_SPLIT(dev)))
+
Re: [Intel-gfx] ThinkPad T420 + kernel 3.8.x + external VGA display == wrong resolution
On Mon, Mar 4, 2013 at 10:47 PM, Toralf Förster toralf.foers...@gmx.de wrote: It is a (small) regression to 3.7.10 with intel integrated graphics i915 - but nevertheless : With an external VGA display (1680x1050) and a closed internal LVDS1 display (1440x900) the external display starts X11 with 1440x900 - for kernel 3.7.x. With 3.8.2 (and .1) now the external display is driven with just 800x600. Hm, sounds like we fail to properly read the EDID. Can you please boot both the working and broken kernel with drm.debug=0xe and attach the complete dmesg? To keep everything together please file a bug on bugs.freedesktop.org against DRI - DRM(Intel) and attach the files there together with your quick description of the regression above. Thanks, Daniel -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/28] drm/i915: fix VLV limits and m/n/p calculations
On Fri, Mar 01, 2013 at 01:14:16PM -0800, Jesse Barnes wrote:
For high res modes m n p calculation is fixed for VLV platform.
Signed-off-by: Vijay Purushothaman vijay.a.purushotha...@intel.com
Signed-off-by: Pallavi G pallav...@intel.com
Signed-off-by: Yogesh M yogesh.mohan.marimu...@intel.com
Signed-off-by: Gajanan Bhat gajanan.b...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3b189fa..fd4a0d4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -380,21 +380,21 @@ static const intel_limit_t intel_limits_vlv_dac = {
.m1 = { .min = 2, .max = 3 },
.m2 = { .min = 11, .max = 156 },
.p = { .min = 10, .max = 30 },
- .p1 = { .min = 2, .max = 3 },
+ .p1 = { .min = 1, .max = 3 },
.p2 = { .dot_limit = 27,
.p2_slow = 2, .p2_fast = 20 },
.find_pll = intel_vlv_find_best_pll,
};
static const intel_limit_t intel_limits_vlv_hdmi = {
- .dot = { .min = 2, .max = 165000 },
- .vco = { .min = 400, .max = 5994000},
- .n = { .min = 1, .max = 7 },
+ .dot = { .min = 25000, .max = 18 },
+ .vco = { .min = 404, .max = 596 },
+ .n = { .min = 1, .max = 5 },
.m = { .min = 60, .max = 300 }, /* guess */
.m1 = { .min = 2, .max = 3 },
- .m2 = { .min = 11, .max = 156 },
+ .m2 = { .min = 15, .max = 149 },
.p = { .min = 10, .max = 30 },
- .p1 = { .min = 2, .max = 3 },
+ .p1 = { .min = 1, .max = 3 },
.p2 = { .dot_limit = 27,
.p2_slow = 2, .p2_fast = 20 },
.find_pll = intel_vlv_find_best_pll,
@@ -408,7 +408,7 @@ static const intel_limit_t intel_limits_vlv_dp = {
.m1 = { .min = 2, .max = 3 },
.m2 = { .min = 11, .max = 156 },
.p = { .min = 10, .max = 30 },
- .p1 = { .min = 2, .max = 3 },
+ .p1 = { .min = 1, .max = 3 },
.p2 = { .dot_limit = 27,
.p2_slow = 2, .p2_fast = 20 },
.find_pll = intel_vlv_find_best_pll,
@@ -809,10 +809,14 @@ intel_vlv_find_best_pll(const intel_limit_t *limit,
struct drm_crtc *crtc,
int target, int refclk, intel_clock_t *match_clock,
intel_clock_t *best_clock)
{
+#define LONG_OVERFLOW 0x7FFF
+#define DIFF_OVERFLOW (LONG_OVERFLOW/1)
+
u32 p1, p2, m1, m2, vco, bestn, bestm1, bestm2, bestp1, bestp2;
u32 m, n, fastclk;
u32 updrate, minupdate, fracbits, p;
- unsigned long bestppm, ppm, absppm;
+ long bestppm, ppm, absppm, ppmdiff, absppmdiff;
+ unsigned long ulMult = 1;
int dotclk, flag;
flag = 0;
@@ -841,8 +845,15 @@ intel_vlv_find_best_pll(const intel_limit_t *limit,
struct drm_crtc *crtc,
m = m1 * m2;
vco = updrate * m;
if (vco = limit-vco.min vco
limit-vco.max) {
- ppm = 100 * ((vco / p) -
fastclk) / fastclk;
- absppm = (ppm 0) ? ppm :
(-ppm);
+ ppmdiff = ((100*vco)/p) -
(100*fastclk);
+ absppmdiff = (ppmdiff 0) ?
ppmdiff : (-ppmdiff);
+ ulMult = 1;
+ while (absppmdiff
DIFF_OVERFLOW) {
+ absppmdiff /= 10;
+ ulMult *= 10;
+ }
+ absppm =
((absppmdiff*1)/fastclk)*ulMult;
+
This seems to expect long to be 32 bits. If it needs 64bit math it
should use proper sized types, and of course the division needs to
use something like div_s64().
Also it should use abs()/abs64() instead of the open-coded versions.
That would also allow getting rid of some of these temporary variables.
if (absppm 100 ((p1 * p2)
(bestp1 * bestp2))) {
bestppm = 0;
flag = 1;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 IGT 2/6] intel_reg_dumper: recognize LPT
On Fri, Mar 01, 2013 at 05:44:18PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
tools/intel_reg_dumper.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/intel_reg_dumper.c b/tools/intel_reg_dumper.c
index 20f332f..b66a1ea 100644
--- a/tools/intel_reg_dumper.c
+++ b/tools/intel_reg_dumper.c
@@ -2326,8 +2326,12 @@ int main(int argc, char** argv)
if (devid) {
if (IS_GEN5(devid))
pch = PCH_IBX;
- else
+ else if (IS_GEN6(devid) || IS_IVYBRIDGE(devid))
pch = PCH_CPT;
+ else if (IS_HASWELL(devid))
+ pch = PCH_LPT;
+ else
+ pch = PCH_NONE;
In patch 6/6 you're fixing the PCH detection code in lib/ maybe it'd be
a good idea to use it to detect the PCH of having heuristics on device 2
- PCH mappings?
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/26] drm/i915: fix VLV limits and m/n/p calculations
On Fri, Mar 1, 2013 at 11:08 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: From: Pallavi G pallav...@intel.com For high res modes m n p calculation is fixed for VLV platform. Signed-off-by: Vijay Purushothaman vijay.a.purushotha...@intel.com Signed-off-by: Pallavi G pallav...@intel.com Signed-off-by: Yogesh M yogesh.mohan.marimu...@intel.com Signed-off-by: Gajanan Bhat gajanan.b...@intel.com I'll throw a few more nits on top: - From: should usually also be the first sob line or maybe a quick comment about the origins of the patch. - This function indents a few too many levels by any standard. - I'd prefer if we switch dp to just select the desired m/n/p values for a given clock like on all other platforms. See the vlv FIXME in https://patchwork.kernel.org/patch/2173841/ Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Turn off hsync and vsync on ADPA when disabling crt
According to PRM we need to disable hsync and vsync even though ADPA is disabled. The previous code did infact do the opposite so we fix it. Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com --- drivers/gpu/drm/i915/intel_crt.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index 969d08c..32a3693 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.c @@ -88,7 +88,7 @@ static void intel_disable_crt(struct intel_encoder *encoder) u32 temp; temp = I915_READ(crt-adpa_reg); - temp = ~(ADPA_HSYNC_CNTL_DISABLE | ADPA_VSYNC_CNTL_DISABLE); + temp |= ADPA_HSYNC_CNTL_DISABLE | ADPA_VSYNC_CNTL_DISABLE; temp = ~ADPA_DAC_ENABLE; I915_WRITE(crt-adpa_reg, temp); } -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Turn off hsync and vsync on ADPA when disabling crt
On Tue, Mar 05, 2013 at 02:24:48PM +0100, Patrik Jakobsson wrote: According to PRM we need to disable hsync and vsync even though ADPA is disabled. The previous code did infact do the opposite so we fix it. Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com --- drivers/gpu/drm/i915/intel_crt.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c index 969d08c..32a3693 100644 --- a/drivers/gpu/drm/i915/intel_crt.c +++ b/drivers/gpu/drm/i915/intel_crt.c @@ -88,7 +88,7 @@ static void intel_disable_crt(struct intel_encoder *encoder) u32 temp; temp = I915_READ(crt-adpa_reg); - temp = ~(ADPA_HSYNC_CNTL_DISABLE | ADPA_VSYNC_CNTL_DISABLE); + temp |= ADPA_HSYNC_CNTL_DISABLE | ADPA_VSYNC_CNTL_DISABLE; Accroding to the docs these bits don't exist on PCH platforms. intel_crt_dpms() already has a check for this, so I suppose intel_disable_crt() should have one too. Also I noticed that we seem to have the hsync and vsync disable bits reversed. At least that's what the docs are telling me. temp = ~ADPA_DAC_ENABLE; I915_WRITE(crt-adpa_reg, temp); } -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v.3 10/12] DRM/i915: Add Reenable Timer to turn Hotplug Detection back on (v3).
We disable hoptplug detection when we encounter a hotplug event
storm. Still hotplug detection is required on some outputs (like
Display Port). The interrupt storm may be only temporary (on certain
Dell Laptops for instance it happens at certain charging states of
the system). Thus we enable it after a certain grace period (2 minutes).
Should the interrupt storm persist it will be detected immediately
and it will be disabled again.
v2: Reordered drm_i915_private: moved hotplug_reenable_timer to hpd state
tracker.
v3: Clarified loop start value,
Removed superfluous test for Ivybridge and Haswell,
Restructured loop to avoid deep nesting (all suggested by Ville Syrjälä)
Signed-off-by: Egbert Eich e...@suse.de
---
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/i915_irq.c | 53 ++-
2 files changed, 54 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 296278f..1fb7c44 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -933,6 +933,8 @@ typedef struct drm_i915_private {
HPD_MARK_DISABLED = 2
} hpd_mark;
} hpd_stats[HPD_NUM_PINS];
+#define I915_REENABLE_HOTPLUG_DELAY (2*60*1000)
+ struct timer_list hotplug_reenable_timer;
int num_pipe;
int num_pch_pll;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d11534c..76903af 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -367,8 +367,11 @@ static void i915_hotplug_work_func(struct work_struct
*work)
connector_disabled = true;
}
}
- if (connector_disabled)
+ if (connector_disabled) {
drm_kms_helper_poll_enable(dev); /* if there were no outputs to
poll, poll is disabled */
+ mod_timer(dev_priv-hotplug_reenable_timer,
+ jiffies +
msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
+ }
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
@@ -2244,6 +2247,8 @@ static void valleyview_irq_uninstall(struct drm_device
*dev)
if (!dev_priv)
return;
+ del_timer_sync(dev_priv-hotplug_reenable_timer);
+
for_each_pipe(pipe)
I915_WRITE(PIPESTAT(pipe), 0x);
@@ -2265,6 +2270,8 @@ static void ironlake_irq_uninstall(struct drm_device *dev)
if (!dev_priv)
return;
+ del_timer_sync(dev_priv-hotplug_reenable_timer);
+
I915_WRITE(HWSTAM, 0x);
I915_WRITE(DEIMR, 0x);
@@ -2603,6 +2610,8 @@ static void i915_irq_uninstall(struct drm_device * dev)
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
int pipe;
+ del_timer_sync(dev_priv-hotplug_reenable_timer);
+
if (I915_HAS_HOTPLUG(dev)) {
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -2851,6 +2860,8 @@ static void i965_irq_uninstall(struct drm_device * dev)
if (!dev_priv)
return;
+ del_timer_sync(dev_priv-hotplug_reenable_timer);
+
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -2866,6 +2877,44 @@ static void i965_irq_uninstall(struct drm_device * dev)
I915_WRITE(IIR, I915_READ(IIR));
}
+static void i915_reenable_hotplug_timer_func(unsigned long data)
+{
+ drm_i915_private_t *dev_priv = (drm_i915_private_t *)data;
+ struct drm_device *dev = dev_priv-dev;
+ struct drm_mode_config *mode_config = dev-mode_config;
+ unsigned long irqflags;
+ int i;
+
+ spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+ for (i = (HPD_NONE + 1); i HPD_NUM_PINS; i++) {
+ struct drm_connector *connector;
+
+ if (dev_priv-hpd_stats[i].hpd_mark != HPD_MARK_DISABLED)
+ continue;
+
+ dev_priv-hpd_stats[i].hpd_mark = HPD_ENABLED;
+
+ list_for_each_entry(connector, mode_config-connector_list,
head) {
+ struct intel_connector *intel_connector =
to_intel_connector(connector);
+
+ if (intel_connector-encoder-hpd_pin == i) {
+ if (connector-polled !=
intel_connector-polled)
+ DRM_DEBUG_DRIVER(Reenabling HPD on
connector %s\n,
+
drm_get_connector_name(connector));
+ connector-polled = intel_connector-polled;
+ if (!connector-polled)
+ connector-polled =
DRM_CONNECTOR_POLL_HPD;
+ }
+ }
+
+ if (HAS_PCH_SPLIT(dev))
+
[Intel-gfx] [PATCH v.2 09/12] DRM/i915: Disable HPD interrupt on pin when irq storm is detected (v2)
This patch disables hotplug interrupts if an 'interrupt storm'
has been detected.
Noise on the interrupt line renders the hotplug interrupt useless:
each hotplug event causes the devices to be rescanned which will
will only increase the system load.
Thus disable the hotplug interrupts and fall back to periodic
device polling.
v2: Fixed cleanup typo.
Signed-off-by: Egbert Eich e...@suse.de
---
drivers/gpu/drm/i915/i915_irq.c | 69 ++-
1 files changed, 53 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d9c99d7..0abef6a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -87,7 +87,8 @@ static const u32 hpd_status_i915[] = { /* i915 and valleyview
are the same */
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
-
+static void ibx_hpd_irq_setup(struct drm_device *dev);
+static void i915_hpd_irq_setup(struct drm_device *dev);
/* For display hotplug interrupt */
static void
@@ -338,7 +339,11 @@ static void i915_hotplug_work_func(struct work_struct
*work)
hotplug_work);
struct drm_device *dev = dev_priv-dev;
struct drm_mode_config *mode_config = dev-mode_config;
- struct intel_encoder *encoder;
+ struct intel_connector *intel_connector;
+ struct intel_encoder *intel_encoder;
+ struct drm_connector *connector;
+ unsigned long irqflags;
+ bool connector_disabled = false;
/* HPD irq before everything is fully set up. */
if (!dev_priv-enable_hotplug_processing)
@@ -347,9 +352,29 @@ static void i915_hotplug_work_func(struct work_struct
*work)
mutex_lock(mode_config-mutex);
DRM_DEBUG_KMS(running encoder hotplug functions\n);
- list_for_each_entry(encoder, mode_config-encoder_list, base.head)
- if (encoder-hot_plug)
- encoder-hot_plug(encoder);
+ spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+ list_for_each_entry(connector, mode_config-connector_list, head) {
+ intel_connector = to_intel_connector(connector);
+ intel_encoder = intel_connector-encoder;
+ if (intel_encoder-hpd_pin HPD_NONE
+ dev_priv-hpd_stats[intel_encoder-hpd_pin].hpd_mark ==
HPD_MARK_DISABLED
+ connector-polled == DRM_CONNECTOR_POLL_HPD) {
+ pr_warn(HPD interrupt storm detected on connector %s
disabling\n,
+ drm_get_connector_name(connector));
+ dev_priv-hpd_stats[intel_encoder-hpd_pin].hpd_mark =
HPD_DISABLED;
+ connector-polled = DRM_CONNECTOR_POLL_CONNECT
+ | DRM_CONNECTOR_POLL_DISCONNECT;
+ connector_disabled = true;
+ }
+ }
+ if (connector_disabled)
+ drm_kms_helper_poll_enable(dev); /* if there were no outputs to
poll, poll is disabled */
+
+ spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
+
+ list_for_each_entry(intel_encoder, mode_config-encoder_list,
base.head)
+ if (intel_encoder-hot_plug)
+ intel_encoder-hot_plug(intel_encoder);
mutex_unlock(mode_config-mutex);
@@ -578,13 +603,14 @@ static void gen6_queue_rps_work(struct drm_i915_private
*dev_priv,
queue_work(dev_priv-wq, dev_priv-rps.work);
}
-static inline void hotplug_irq_storm_detect(struct drm_device *dev,
+static inline bool hotplug_irq_storm_detect(struct drm_device *dev,
u32 hotplug_trigger,
const u32 *hpd)
{
drm_i915_private_t *dev_priv = dev-dev_private;
unsigned long irqflags;
int i;
+ bool ret = false;
spin_lock_irqsave(dev_priv-irq_lock, irqflags);
@@ -598,12 +624,15 @@ static inline void hotplug_irq_storm_detect(struct
drm_device *dev,
} else if (dev_priv-hpd_stats[i].hpd_cnt 5) {
dev_priv-hpd_stats[i].hpd_mark =
HPD_MARK_DISABLED;
DRM_DEBUG_KMS(HPD interrupt storm detected on
PIN %d\n, i);
+ ret = true;
} else
dev_priv-hpd_stats[i].hpd_cnt++;
}
}
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
+
+ return ret;
}
static void gmbus_irq_handler(struct drm_device *dev)
@@ -679,7 +708,8 @@ static irqreturn_t valleyview_irq_handler(int irq, void
*arg)
DRM_DEBUG_DRIVER(hotplug event received, stat
0x%08x\n,
hotplug_status);
if (hotplug_trigger) {
- hotplug_irq_storm_detect(dev, hotplug_trigger,
hpd_status_i915);
+
[Intel-gfx] [PATCH v.3 11/12] DRM/i915: Add bit field to record which pins have received HPD events (v3)
This way it is possible to limit 're'-detect() of displays to connectors
which have received an HPD event.
v2: Reordered drm_i915_private: Move hpd_event_bits to hpd state tracking.
v3: Fix patch.
Signed-off-by: Egbert Eich e...@suse.de
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_irq.c | 47 ++-
2 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1fb7c44..d48d1e6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -933,6 +933,7 @@ typedef struct drm_i915_private {
HPD_MARK_DISABLED = 2
} hpd_mark;
} hpd_stats[HPD_NUM_PINS];
+ u32 hpd_event_bits;
#define I915_REENABLE_HOTPLUG_DELAY (2*60*1000)
struct timer_list hotplug_reenable_timer;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index fd68b21..9e8d5b4 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -330,6 +330,24 @@ static int i915_get_vblank_timestamp(struct drm_device
*dev, int pipe,
crtc);
}
+/**
+ * drm_helper_hpd_irq_single_connector_event() - call this function with
mode_config.mutex lock held
+ */
+
+static int intel_hpd_irq_single_connector_event(struct drm_device *dev, struct
drm_connector *connector)
+{
+ enum drm_connector_status old_status;
+
+ old_status = connector-status;
+
+ connector-status = connector-funcs-detect(connector, false);
+ DRM_DEBUG_KMS([CONNECTOR:%d:%s] status updated from %d to %d\n,
+ connector-base.id,
+ drm_get_connector_name(connector),
+ old_status, connector-status);
+ return (old_status != connector-status);
+}
+
/*
* Handle hotplug events outside the interrupt handler proper.
*/
@@ -344,6 +362,8 @@ static void i915_hotplug_work_func(struct work_struct *work)
struct drm_connector *connector;
unsigned long irqflags;
bool connector_disabled = false;
+ bool changed = false;
+ u32 hpd_event_bits;
/* HPD irq before everything is fully set up. */
if (!dev_priv-enable_hotplug_processing)
@@ -353,6 +373,9 @@ static void i915_hotplug_work_func(struct work_struct *work)
DRM_DEBUG_KMS(running encoder hotplug functions\n);
spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+
+ hpd_event_bits = dev_priv-hpd_event_bits;
+ dev_priv-hpd_event_bits = 0;
list_for_each_entry(connector, mode_config-connector_list, head) {
intel_connector = to_intel_connector(connector);
intel_encoder = intel_connector-encoder;
@@ -366,6 +389,10 @@ static void i915_hotplug_work_func(struct work_struct
*work)
| DRM_CONNECTOR_POLL_DISCONNECT;
connector_disabled = true;
}
+ if (hpd_event_bits (1 intel_encoder-hpd_pin)) {
+ DRM_DEBUG_KMS(Connector %s (pin %i) received hotplug
event.\n,
+ drm_get_connector_name(connector),
intel_encoder-hpd_pin);
+ }
}
if (connector_disabled) {
drm_kms_helper_poll_enable(dev); /* if there were no outputs to
poll, poll is disabled */
@@ -375,14 +402,20 @@ static void i915_hotplug_work_func(struct work_struct
*work)
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
- list_for_each_entry(intel_encoder, mode_config-encoder_list,
base.head)
- if (intel_encoder-hot_plug)
- intel_encoder-hot_plug(intel_encoder);
-
+ list_for_each_entry(connector, mode_config-connector_list, head) {
+ intel_connector = to_intel_connector(connector);
+ intel_encoder = intel_connector-encoder;
+ if (hpd_event_bits (1 intel_encoder-hpd_pin)) {
+ if (intel_encoder-hot_plug)
+ intel_encoder-hot_plug(intel_encoder);
+ if (intel_hpd_irq_single_connector_event(dev,
connector))
+ changed = true;
+ }
+ }
mutex_unlock(mode_config-mutex);
- /* Just fire off a uevent and let userspace tell us what to do */
- drm_helper_hpd_irq_event(dev);
+ if (changed)
+ drm_kms_helper_hotplug_event(dev);
}
static void ironlake_handle_rps_change(struct drm_device *dev)
@@ -620,12 +653,14 @@ static inline bool hotplug_irq_storm_detect(struct
drm_device *dev,
for (i = 1; i HPD_NUM_PINS; i++) {
if ((hpd[i] hotplug_trigger)
dev_priv-hpd_stats[i].hpd_mark == HPD_ENABLED) {
+ dev_priv-hpd_event_bits |= (1 i);
if (jiffies
Re: [Intel-gfx] [PATCH] drm/i915: Turn off hsync and vsync on ADPA when disabling crt
Accroding to the docs these bits don't exist on PCH platforms. intel_crt_dpms() already has a check for this, so I suppose intel_disable_crt() should have one too. Also I noticed that we seem to have the hsync and vsync disable bits reversed. At least that's what the docs are telling me. The PCH check just forces suspend and standby to off and we're only doing dpms off in intel_disable_crt() so no need to check it there. I'm looking at the 965/G35 PRM and the sync disable are defined correctly but used incorrectly in intel_disable_crt(). That's what my patch fixes. I haven't checked the other PRMs. Is it different on newer hardware? I'm thinking that this is related to the bug 56359. The thing that triggers it seems to be that ADPA sometimes get connected to the same pipe as LVDS and somehow VSYNC and HSYNC trickles through. This might be fixed by setting the ADPA pipe again in intel_enable_crt() and/or intel_crt_dpms(). Thanks Patrik ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Align scanouts to 256k when VT-d is enabled
From the w/a database:
'To prevent false VT-d type 6 error:
The primary display plane must be 256KiB aligned, and require an extra
128 PTEs of padding afterward;
The sprites planes must be 128KiB aligned, and require an extra 64 PTEs
of padding afterward;
The cursors must be 64KiB aligned, and require an extra 2 PTEs of
padding afterward.'
As we use the same function to pin the primary and sprite planes, we can
simply use the more strict requirements for scanouts for both.
Instead of using explicit padding PTEs following the scanout objects, we
should be able to use the scratch page that is always mapped into the
unused PTEs to avoid the VT-d error.
References: https://bugs.freedesktop.org/show_bug.cgi?id=59626
References: https://bugs.freedesktop.org/show_bug.cgi?id=59627
References: https://bugs.freedesktop.org/show_bug.cgi?id=59631
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 30 +-
drivers/gpu/drm/i915/intel_sprite.c |5 +
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a8966aa..139213b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1937,6 +1937,15 @@ static void intel_disable_plane(struct drm_i915_private
*dev_priv,
intel_wait_for_vblank(dev_priv-dev, pipe);
}
+static bool need_vtd_wa(struct drm_device *dev)
+{
+#ifdef CONFIG_INTEL_IOMMU
+ if (INTEL_INFO(dev)-gen = 6 intel_iommu_gfx_mapped)
+ return true;
+#endif
+ return false;
+}
+
int
intel_pin_and_fence_fb_obj(struct drm_device *dev,
struct drm_i915_gem_object *obj,
@@ -1967,6 +1976,14 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
BUG();
}
+ /* Note that the w/a also requires 64 PTE of padding following the
+* bo. We currently fill all unused PTE with the shadow page and so
+* we should always have valid PTE following the scanout preventing
+* the VT-d warning.
+*/
+ if (need_vtd_wa(dev) alignment 256 * 1024)
+ alignment = 256 * 1024;
+
dev_priv-mm.interruptible = false;
ret = i915_gem_object_pin_to_display_plane(obj, alignment, pipelined);
if (ret)
@@ -6308,13 +6325,24 @@ static int intel_crtc_cursor_set(struct drm_crtc *crtc,
/* we only need to pin inside GTT if cursor is non-phy */
mutex_lock(dev-struct_mutex);
if (!dev_priv-info-cursor_needs_physical) {
+ unsigned alignment;
+
if (obj-tiling_mode) {
DRM_ERROR(cursor cannot be tiled\n);
ret = -EINVAL;
goto fail_locked;
}
- ret = i915_gem_object_pin_to_display_plane(obj, 0, NULL);
+ /* Note that the w/a also requires 2 PTE of padding following
+* the bo. We currently fill all unused PTE with the shadow
+* page and so we should always have valid PTE following the
+* cursor preventing the VT-d warning.
+*/
+ alignment = 0;
+ if (need_vtd_wa(dev))
+ alignment = 64*1024;
+
+ ret = i915_gem_object_pin_to_display_plane(obj, alignment,
NULL);
if (ret) {
DRM_ERROR(failed to move cursor bo into the GTT\n);
goto fail_locked;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 1b6eb76..d28525b 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -513,6 +513,11 @@ intel_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
mutex_lock(dev-struct_mutex);
+ /* Note that this will apply the VT-d workaround for scanouts,
+* which is more restrictive than required for sprites. (The
+* primary plane requires 256KiB alignment with 64 PTE padding,
+* the sprite planes only require 128KiB alignment and 32 PTE padding.
+*/
ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
if (ret)
goto out_unlock;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Apply alignment restrictions on scanout surfaces for VT-d
From the w/a database:
'To prevent false VT-d type 6 error:
The primary display plane must be 256KiB aligned, and require an extra
128 PTEs of padding afterward;
The sprites planes must be 128KiB aligned, and require an extra 64 PTEs
of padding afterward;
The cursors must be 64KiB aligned, and require an extra 2 PTEs of
padding afterward.'
As we use the same function to pin the primary and sprite planes, we can
simply use the more strict requirements for scanouts for both.
Instead of using explicit padding PTEs following the scanout objects, we
should be able to use the scratch page that is always mapped into the
unused PTEs to avoid the VT-d error.
References: https://bugs.freedesktop.org/show_bug.cgi?id=59626
References: https://bugs.freedesktop.org/show_bug.cgi?id=59627
References: https://bugs.freedesktop.org/show_bug.cgi?id=59631
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 30 +-
drivers/gpu/drm/i915/intel_sprite.c |5 +
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a8966aa..139213b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1937,6 +1937,15 @@ static void intel_disable_plane(struct drm_i915_private
*dev_priv,
intel_wait_for_vblank(dev_priv-dev, pipe);
}
+static bool need_vtd_wa(struct drm_device *dev)
+{
+#ifdef CONFIG_INTEL_IOMMU
+ if (INTEL_INFO(dev)-gen = 6 intel_iommu_gfx_mapped)
+ return true;
+#endif
+ return false;
+}
+
int
intel_pin_and_fence_fb_obj(struct drm_device *dev,
struct drm_i915_gem_object *obj,
@@ -1967,6 +1976,14 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
BUG();
}
+ /* Note that the w/a also requires 64 PTE of padding following the
+* bo. We currently fill all unused PTE with the shadow page and so
+* we should always have valid PTE following the scanout preventing
+* the VT-d warning.
+*/
+ if (need_vtd_wa(dev) alignment 256 * 1024)
+ alignment = 256 * 1024;
+
dev_priv-mm.interruptible = false;
ret = i915_gem_object_pin_to_display_plane(obj, alignment, pipelined);
if (ret)
@@ -6308,13 +6325,24 @@ static int intel_crtc_cursor_set(struct drm_crtc *crtc,
/* we only need to pin inside GTT if cursor is non-phy */
mutex_lock(dev-struct_mutex);
if (!dev_priv-info-cursor_needs_physical) {
+ unsigned alignment;
+
if (obj-tiling_mode) {
DRM_ERROR(cursor cannot be tiled\n);
ret = -EINVAL;
goto fail_locked;
}
- ret = i915_gem_object_pin_to_display_plane(obj, 0, NULL);
+ /* Note that the w/a also requires 2 PTE of padding following
+* the bo. We currently fill all unused PTE with the shadow
+* page and so we should always have valid PTE following the
+* cursor preventing the VT-d warning.
+*/
+ alignment = 0;
+ if (need_vtd_wa(dev))
+ alignment = 64*1024;
+
+ ret = i915_gem_object_pin_to_display_plane(obj, alignment,
NULL);
if (ret) {
DRM_ERROR(failed to move cursor bo into the GTT\n);
goto fail_locked;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 1b6eb76..d28525b 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -513,6 +513,11 @@ intel_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
mutex_lock(dev-struct_mutex);
+ /* Note that this will apply the VT-d workaround for scanouts,
+* which is more restrictive than required for sprites. (The
+* primary plane requires 256KiB alignment with 64 PTE padding,
+* the sprite planes only require 128KiB alignment and 32 PTE padding.
+*/
ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
if (ret)
goto out_unlock;
--
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 v.3 11/12] DRM/i915: Add bit field to record which pins have received HPD events (v3)
On Tue, Mar 05, 2013 at 08:00:30AM -0500, Egbert Eich wrote: This way it is possible to limit 're'-detect() of displays to connectors which have received an HPD event. v2: Reordered drm_i915_private: Move hpd_event_bits to hpd state tracking. v3: Fix patch. Oops, forget this patch. It's messed up. Sorry, Egbert. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Turn off hsync and vsync on ADPA when disabling crt
On Tue, Mar 05, 2013 at 03:33:26PM +0100, Patrik Jakobsson wrote: Accroding to the docs these bits don't exist on PCH platforms. intel_crt_dpms() already has a check for this, so I suppose intel_disable_crt() should have one too. Also I noticed that we seem to have the hsync and vsync disable bits reversed. At least that's what the docs are telling me. The PCH check just forces suspend and standby to off and we're only doing dpms off in intel_disable_crt() so no need to check it there. You're right. I assumed that the check would somehow avoid setting these bits too, but it doesn't. So I guess we don't really care that they don't exist. I'm looking at the 965/G35 PRM and the sync disable are defined correctly but used incorrectly in intel_disable_crt(). That's what my patch fixes. I haven't checked the other PRMs. Is it different on newer hardware? This is what the docs say: 11:10 Monitor DPMS: (for CRT port) ... ... 00 = ... (will not affect sync pulses) 01 = ... (HSYNC pulses, VSYNC does not) 10 = ... (VSYNC pulses, HSYNC does not) 11 = ... (Neither HSYNC nor VSYNC pulses) These are our definintions: #define ADPA_VSYNC_CNTL_DISABLE (111) #define ADPA_HSYNC_CNTL_DISABLE (110) As you can see they don't match. -- 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 04/26] drm/i915: update VLV PLL and DPIO code
On Sat, 02 Mar 2013, Jesse Barnes jbar...@virtuousgeek.org wrote:
From: Pallavi G pallav...@intel.com
In Valleyview voltage swing, pre-emphasis and lane control registers can
be programmed only through the h/w side band fabric. Update
vlv_update_pll, i9xx_crtc_enable, and intel_enable_pll with the
appropriate programming.
We need to make sure that the tx lane reset occurs in both the full mode
set and DPMS paths, so factor things out to allow that.
v2: use different DPIO_DIVISOR values for VGA and DisplayPort
v3: Fix update pll logic to use same DPIO_DIVISOR DPIO_REFSFR values
for all display interfaces
v4: collapse with various updates
v5: squash with crtc enable/pll enable bits
Signed-off-by: Pallavi G pallav...@intel.com
Signed-off-by: Vijay Purushothaman vijay.a.purushotha...@intel.com
Signed-off-by: Gajanan Bhat gajanan.b...@intel.com
Signed-off-by: Ben Widawsky benjamin.widaw...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 54 ++-
drivers/gpu/drm/i915/intel_display.c | 266
++
drivers/gpu/drm/i915/intel_dp.c |8 +-
3 files changed, 261 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fd55b20..b0124e3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -388,14 +388,61 @@
#define _DPIO_CORE_CLK_B 0x803c
#define DPIO_CORE_CLK(pipe) _PIPE(pipe, _DPIO_CORE_CLK_A, _DPIO_CORE_CLK_B)
+#define _DPIO_IREF_CTL_A 0x8040
+#define _DPIO_IREF_CTL_B 0x8060
+#define DPIO_IREF_CTL(pipe) _PIPE(pipe, _DPIO_IREF_CTL_A, _DPIO_IREF_CTL_B)
+
+#define _DPIO_IREF_A 0x8044
+#define _DPIO_IREF_B 0x8064
+#define DPIO_IREF(pipe) _PIPE(pipe, _DPIO_IREF_A, _DPIO_IREF_B)
+
+#define _DPIO_PLL_CML_A 0x804c
+#define _DPIO_PLL_CML_B 0x806c
+#define DPIO_PLL_CML(pipe) _PIPE(pipe, _DPIO_PLL_CML_A, _DPIO_PLL_CML_B)
+
#define _DPIO_LFP_COEFF_A0x8048
#define _DPIO_LFP_COEFF_B0x8068
#define DPIO_LFP_COEFF(pipe) _PIPE(pipe, _DPIO_LFP_COEFF_A,
_DPIO_LFP_COEFF_B)
+#define DPIO_CALIBRATION 0x80ac
+
#define DPIO_FASTCLK_DISABLE 0x8100
-#define DPIO_DATA_CHANNEL1 0x8220
-#define DPIO_DATA_CHANNEL2 0x8420
+#define _DPIO_PCS_TX_0 0x8200
+#define _DPIO_PCS_TX_1 0x8400
+#define DPIO_PCS_TX(pipe) _PIPE(pipe, _DPIO_PCS_TX_0, _DPIO_PCS_TX_1)
+
+#define _DPIO_PCS_CLK_0 0x8204
+#define _DPIO_PCS_CLK_1 0x8404
+#define DPIO_PCS_CLK(pipe) _PIPE(pipe, _DPIO_PCS_CLK_0, _DPIO_PCS_CLK_1)
+
+#define _DPIO_PCS_STAGGER_0 0x8230
+#define _DPIO_PCS_STAGGER_1 0x8430
+#define DPIO_PCS_STAGGER(pipe) _PIPE(pipe, _DPIO_PCS_STAGGER_0, \
+ _DPIO_PCS_STAGGER_1)
+
+#define _DPIO_TX_CTL_0 0x82ac
+#define _DPIO_TX_CTL_1 0x84ac
+#define DPIO_TX_CTL(pipe) _PIPE(pipe, _DPIO_TX_CTL_0, _DPIO_TX_CTL_1)
+
+#define _DPIO_TX_LANE_0 0x82b8
+#define _DPIO_TX_LANE_1 0x84b8
+#define DPIO_TX_LANE(pipe) _PIPE(pipe, _DPIO_TX_LANE_0, _DPIO_TX_LANE_1)
+
+#define _DPIO_DATA_CHANNEL1 0x8220
+#define _DPIO_DATA_CHANNEL2 0x8420
+#define DPIO_DATA_CHANNEL(pipe) _PIPE(pipe, _DPIO_DATA_CHANNEL1,
_DPIO_DATA_CHANNEL2)
+
+#define _DPIO_DATA_LANE0 0x0220
+#define _DPIO_DATA_LANE1 0x0420
+#define _DPIO_DATA_LANE2 0x2620
+#define _DPIO_DATA_LANE3 0x2820
+#define DPIO_DATA_LANE_A(pipe) _PIPE(pipe, _DPIO_DATA_LANE0,
_DPIO_DATA_LANE2)
+#define DPIO_DATA_LANE_B(pipe) _PIPE(pipe, _DPIO_DATA_LANE1,
_DPIO_DATA_LANE3)
+#define DPIO_DATA_CHANNEL1 0x8220
+#define DPIO_DATA_CHANNEL2 0x8420
+
+#define DPIO_TX_BROADCAST0xc044
/*
* Fence registers
@@ -956,7 +1003,10 @@
#define DPLL_FPA01_P1_POST_DIV_MASK0x00ff /* i915 */
#define DPLL_FPA01_P1_POST_DIV_MASK_PINEVIEW 0x00ff8000 /* Pineview
*/
#define DPLL_LOCK_VLV (115)
+#define DPLL_INTEGRATED_CRI_CLK_VLV(114)
#define DPLL_INTEGRATED_CLOCK_VLV (113)
+#define DPLL_PORTC_READY_MASK (0xf 4)
+#define DPLL_PORTB_READY_MASK (0xf)
#define DPLL_FPA01_P1_POST_DIV_MASK_I830 0x001f
/*
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 794c23e5..cb4ecad 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3648,6 +3648,56 @@ static void intel_crtc_dpms_overlay(struct intel_crtc
*intel_crtc, bool enable)
*/
}
+static void vlv_pll_enable_reset(struct drm_crtc *crtc)
+{
+ struct
Re: [Intel-gfx] [PATCH 09/26] drm/i915: add power context allocation and setup on VLV
On Sat, 02 Mar 2013, Jesse Barnes jbar...@virtuousgeek.org wrote:
The Gunit has a separate reg for this, so allocate some stolen space for
the power context and initialize the reg.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h|2 ++
drivers/gpu/drm/i915/i915_gem_stolen.c | 41
drivers/gpu/drm/i915/i915_reg.h|1 +
3 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 48426e1..871d7c8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1024,6 +1024,8 @@ typedef struct drm_i915_private {
struct i915_gpu_error gpu_error;
+ struct drm_mm_node *vlv_pctx;
+
/* list of fbdev register on this device */
struct intel_fbdev *fbdev;
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 69d97cb..0d137de 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -171,11 +171,49 @@ void i915_gem_stolen_cleanup_compression(struct
drm_device *dev)
dev_priv-cfb_size = 0;
}
+static void i915_setup_pctx(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_mm_node *pctx;
+ unsigned long pctx_paddr;
+ int pctx_size = 24*1024;
+
+ pctx = drm_mm_search_free(dev_priv-mm.stolen, pctx_size, 4096, 0);
+ if (pctx)
+ pctx = drm_mm_get_block(pctx, pctx_size, 4096);
+ if (!pctx)
+ goto err;
+
+ pctx_paddr = dev_priv-mm.stolen_base + pctx-start;
+ if (!pctx_paddr)
+ goto err_free_pctx;
+
+ dev_priv-vlv_pctx = pctx;
+ I915_WRITE(VLV_PCBR, pctx_paddr);
+
+ return;
+
+err_free_pctx:
+ drm_mm_put_block(pctx);
+err:
+ DRM_DEBUG(not enough stolen space for PCTX, disabling\n);
+}
+
+static void i915_cleanup_pctx(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ I915_WRITE(VLV_PCBR, 0);
+ drm_mm_put_block(dev_priv-vlv_pctx);
+}
+
void i915_gem_cleanup_stolen(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
i915_gem_stolen_cleanup_compression(dev);
+ if (IS_VALLEYVIEW(dev) i915_powersave)
+ i915_cleanup_pctx(dev);
drm_mm_takedown(dev_priv-mm.stolen);
}
@@ -193,6 +231,9 @@ int i915_gem_init_stolen(struct drm_device *dev)
/* Basic memrange allocator for stolen space */
drm_mm_init(dev_priv-mm.stolen, 0, dev_priv-gtt.stolen_size);
+ if (IS_VALLEYVIEW(dev) i915_powersave)
+ i915_setup_pctx(dev);
If the setup failed or someone toggled powersave on after module
loading, this oopses. Not likely I guess.
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 766518b..539301d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -623,6 +623,7 @@
#define VLV_IIR (VLV_DISPLAY_BASE + 0x20a4)
#define VLV_IMR (VLV_DISPLAY_BASE + 0x20a8)
#define VLV_ISR (VLV_DISPLAY_BASE + 0x20ac)
+#define VLV_PCBR (VLV_DISPLAY_BASE + 0x2120)
#define I915_PIPE_CONTROL_NOTIFY_INTERRUPT (118)
#define I915_DISPLAY_PORT_INTERRUPT(117)
#define I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT (115)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Turn off hsync and vsync on ADPA when disabling crt
On Tue, Mar 5, 2013 at 3:59 PM, Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Tue, Mar 05, 2013 at 03:33:26PM +0100, Patrik Jakobsson wrote: Accroding to the docs these bits don't exist on PCH platforms. intel_crt_dpms() already has a check for this, so I suppose intel_disable_crt() should have one too. Also I noticed that we seem to have the hsync and vsync disable bits reversed. At least that's what the docs are telling me. The PCH check just forces suspend and standby to off and we're only doing dpms off in intel_disable_crt() so no need to check it there. You're right. I assumed that the check would somehow avoid setting these bits too, but it doesn't. So I guess we don't really care that they don't exist. I'm looking at the 965/G35 PRM and the sync disable are defined correctly but used incorrectly in intel_disable_crt(). That's what my patch fixes. I haven't checked the other PRMs. Is it different on newer hardware? This is what the docs say: 11:10 Monitor DPMS: (for CRT port) ... ... 00 = ... (will not affect sync pulses) 01 = ... (HSYNC pulses, VSYNC does not) 10 = ... (VSYNC pulses, HSYNC does not) 11 = ... (Neither HSYNC nor VSYNC pulses) These are our definintions: #define ADPA_VSYNC_CNTL_DISABLE (111) #define ADPA_HSYNC_CNTL_DISABLE (110) As you can see they don't match. Aha, you're right. I thought you meant disable = 0 and enable = 1. So when we're doing suspend we are in fact doing standby and vice versa. -Patrik ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Turn off hsync and vsync on ADPA when disabling crt
On Tue, Mar 05, 2013 at 04:59:12PM +0200, Ville Syrjälä wrote: On Tue, Mar 05, 2013 at 03:33:26PM +0100, Patrik Jakobsson wrote: Accroding to the docs these bits don't exist on PCH platforms. intel_crt_dpms() already has a check for this, so I suppose intel_disable_crt() should have one too. Also I noticed that we seem to have the hsync and vsync disable bits reversed. At least that's what the docs are telling me. The PCH check just forces suspend and standby to off and we're only doing dpms off in intel_disable_crt() so no need to check it there. You're right. I assumed that the check would somehow avoid setting these bits too, but it doesn't. So I guess we don't really care that they don't exist. The dpms state gets clamped to the values support by the hw in intel_crt_dpms. So I think we should care also in intel_crt_disable. I'm looking at the 965/G35 PRM and the sync disable are defined correctly but used incorrectly in intel_disable_crt(). That's what my patch fixes. I haven't checked the other PRMs. Is it different on newer hardware? This is what the docs say: 11:10 Monitor DPMS: (for CRT port) ... ... 00 = ... (will not affect sync pulses) 01 = ... (HSYNC pulses, VSYNC does not) 10 = ... (VSYNC pulses, HSYNC does not) 11 = ... (Neither HSYNC nor VSYNC pulses) These are our definintions: #define ADPA_VSYNC_CNTL_DISABLE (111) #define ADPA_HSYNC_CNTL_DISABLE (110) As you can see they don't match. I've checked gen2/3 docs and they agree with this, so we need to update the #define. -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: Apply alignment restrictions on scanout surfaces for VT-d
On Tue, Mar 05, 2013 at 02:52:39PM +, Chris Wilson wrote:
From the w/a database:
'To prevent false VT-d type 6 error:
The primary display plane must be 256KiB aligned, and require an extra
128 PTEs of padding afterward;
The sprites planes must be 128KiB aligned, and require an extra 64 PTEs
of padding afterward;
The cursors must be 64KiB aligned, and require an extra 2 PTEs of
padding afterward.'
As we use the same function to pin the primary and sprite planes, we can
simply use the more strict requirements for scanouts for both.
Instead of using explicit padding PTEs following the scanout objects, we
should be able to use the scratch page that is always mapped into the
unused PTEs to avoid the VT-d error.
References: https://bugs.freedesktop.org/show_bug.cgi?id=59626
References: https://bugs.freedesktop.org/show_bug.cgi?id=59627
References: https://bugs.freedesktop.org/show_bug.cgi?id=59631
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 30 +-
drivers/gpu/drm/i915/intel_sprite.c |5 +
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a8966aa..139213b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1937,6 +1937,15 @@ static void intel_disable_plane(struct
drm_i915_private *dev_priv,
intel_wait_for_vblank(dev_priv-dev, pipe);
}
+static bool need_vtd_wa(struct drm_device *dev)
Bikeshed to need_vtd_scanout_wa?
-Daniel
+{
+#ifdef CONFIG_INTEL_IOMMU
+ if (INTEL_INFO(dev)-gen = 6 intel_iommu_gfx_mapped)
+ return true;
+#endif
+ return false;
+}
+
int
intel_pin_and_fence_fb_obj(struct drm_device *dev,
struct drm_i915_gem_object *obj,
@@ -1967,6 +1976,14 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
BUG();
}
+ /* Note that the w/a also requires 64 PTE of padding following the
+ * bo. We currently fill all unused PTE with the shadow page and so
+ * we should always have valid PTE following the scanout preventing
+ * the VT-d warning.
+ */
+ if (need_vtd_wa(dev) alignment 256 * 1024)
+ alignment = 256 * 1024;
+
dev_priv-mm.interruptible = false;
ret = i915_gem_object_pin_to_display_plane(obj, alignment, pipelined);
if (ret)
@@ -6308,13 +6325,24 @@ static int intel_crtc_cursor_set(struct drm_crtc
*crtc,
/* we only need to pin inside GTT if cursor is non-phy */
mutex_lock(dev-struct_mutex);
if (!dev_priv-info-cursor_needs_physical) {
+ unsigned alignment;
+
if (obj-tiling_mode) {
DRM_ERROR(cursor cannot be tiled\n);
ret = -EINVAL;
goto fail_locked;
}
- ret = i915_gem_object_pin_to_display_plane(obj, 0, NULL);
+ /* Note that the w/a also requires 2 PTE of padding following
+ * the bo. We currently fill all unused PTE with the shadow
+ * page and so we should always have valid PTE following the
+ * cursor preventing the VT-d warning.
+ */
+ alignment = 0;
+ if (need_vtd_wa(dev))
+ alignment = 64*1024;
+
+ ret = i915_gem_object_pin_to_display_plane(obj, alignment,
NULL);
if (ret) {
DRM_ERROR(failed to move cursor bo into the GTT\n);
goto fail_locked;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 1b6eb76..d28525b 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -513,6 +513,11 @@ intel_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
mutex_lock(dev-struct_mutex);
+ /* Note that this will apply the VT-d workaround for scanouts,
+ * which is more restrictive than required for sprites. (The
+ * primary plane requires 256KiB alignment with 64 PTE padding,
+ * the sprite planes only require 128KiB alignment and 32 PTE padding.
+ */
ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
if (ret)
goto out_unlock;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v.3 12/12] DRM/i915: Only reprobe display on encoder which has received an HPD event.
Instead of calling into the DRM helper layer to poll all connectors for
changes in connected displays probe only those connectors which have
received a hotplug event.
Signed-off-by: Egbert Eich e...@suse.de
---
drivers/gpu/drm/i915/i915_irq.c | 37 +++--
1 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d65d76a..9e8d5b4 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -330,6 +330,24 @@ static int i915_get_vblank_timestamp(struct drm_device
*dev, int pipe,
crtc);
}
+/**
+ * drm_helper_hpd_irq_single_connector_event() - call this function with
mode_config.mutex lock held
+ */
+
+static int intel_hpd_irq_single_connector_event(struct drm_device *dev, struct
drm_connector *connector)
+{
+ enum drm_connector_status old_status;
+
+ old_status = connector-status;
+
+ connector-status = connector-funcs-detect(connector, false);
+ DRM_DEBUG_KMS([CONNECTOR:%d:%s] status updated from %d to %d\n,
+ connector-base.id,
+ drm_get_connector_name(connector),
+ old_status, connector-status);
+ return (old_status != connector-status);
+}
+
/*
* Handle hotplug events outside the interrupt handler proper.
*/
@@ -344,6 +362,7 @@ static void i915_hotplug_work_func(struct work_struct *work)
struct drm_connector *connector;
unsigned long irqflags;
bool connector_disabled = false;
+ bool changed = false;
u32 hpd_event_bits;
/* HPD irq before everything is fully set up. */
@@ -383,14 +402,20 @@ static void i915_hotplug_work_func(struct work_struct
*work)
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
- list_for_each_entry(intel_encoder, mode_config-encoder_list,
base.head)
- if (intel_encoder-hot_plug)
- intel_encoder-hot_plug(intel_encoder);
-
+ list_for_each_entry(connector, mode_config-connector_list, head) {
+ intel_connector = to_intel_connector(connector);
+ intel_encoder = intel_connector-encoder;
+ if (hpd_event_bits (1 intel_encoder-hpd_pin)) {
+ if (intel_encoder-hot_plug)
+ intel_encoder-hot_plug(intel_encoder);
+ if (intel_hpd_irq_single_connector_event(dev,
connector))
+ changed = true;
+ }
+ }
mutex_unlock(mode_config-mutex);
- /* Just fire off a uevent and let userspace tell us what to do */
- drm_helper_hpd_irq_event(dev);
+ if (changed)
+ drm_kms_helper_hotplug_event(dev);
}
static void ironlake_handle_rps_change(struct drm_device *dev)
--
1.7.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Turn off hsync and vsync on ADPA when disabling crt
On Tue, Mar 05, 2013 at 04:23:59PM +0100, Daniel Vetter wrote: On Tue, Mar 05, 2013 at 04:59:12PM +0200, Ville Syrjälä wrote: On Tue, Mar 05, 2013 at 03:33:26PM +0100, Patrik Jakobsson wrote: Accroding to the docs these bits don't exist on PCH platforms. intel_crt_dpms() already has a check for this, so I suppose intel_disable_crt() should have one too. Also I noticed that we seem to have the hsync and vsync disable bits reversed. At least that's what the docs are telling me. The PCH check just forces suspend and standby to off and we're only doing dpms off in intel_disable_crt() so no need to check it there. You're right. I assumed that the check would somehow avoid setting these bits too, but it doesn't. So I guess we don't really care that they don't exist. The dpms state gets clamped to the values support by the hw in intel_crt_dpms. So I think we should care also in intel_crt_disable. The point was that in intel_crt_dpms() we don't care whether the hsync/vsync disable bits actually exist. We just set them whenever the dpms mode warrants it. So for off we always set both bits, and off is always supported. And intel_crt_disable() is equal to intel_crt_dpms(DRM_MODE_DPMS_OFF) so the behaviour is consistent across the board. Whether or not there could be side effects from setting those bits on PCH plaforms is another matter. If there are, then the clamping stuff is not enough and we need to add PCH checks to both functions. -- 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: Turn off hsync and vsync on ADPA when disabling crt
On Tue, Mar 05, 2013 at 05:41:04PM +0200, Ville Syrjälä wrote: On Tue, Mar 05, 2013 at 04:23:59PM +0100, Daniel Vetter wrote: On Tue, Mar 05, 2013 at 04:59:12PM +0200, Ville Syrjälä wrote: On Tue, Mar 05, 2013 at 03:33:26PM +0100, Patrik Jakobsson wrote: Accroding to the docs these bits don't exist on PCH platforms. intel_crt_dpms() already has a check for this, so I suppose intel_disable_crt() should have one too. Also I noticed that we seem to have the hsync and vsync disable bits reversed. At least that's what the docs are telling me. The PCH check just forces suspend and standby to off and we're only doing dpms off in intel_disable_crt() so no need to check it there. You're right. I assumed that the check would somehow avoid setting these bits too, but it doesn't. So I guess we don't really care that they don't exist. The dpms state gets clamped to the values support by the hw in intel_crt_dpms. So I think we should care also in intel_crt_disable. The point was that in intel_crt_dpms() we don't care whether the hsync/vsync disable bits actually exist. We just set them whenever the dpms mode warrants it. So for off we always set both bits, and off is always supported. And intel_crt_disable() is equal to intel_crt_dpms(DRM_MODE_DPMS_OFF) so the behaviour is consistent across the board. Whether or not there could be side effects from setting those bits on PCH plaforms is another matter. If there are, then the clamping stuff is not enough and we need to add PCH checks to both functions. Oh right, I've missed that when reworking that code - we set the bits in the OFF case ... I guess that'd be worthwile to amend, if just to keep out any future surprises. -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 IGT 2/6] intel_reg_dumper: recognize LPT
Hi
2013/3/5 Damien Lespiau damien.lesp...@intel.com:
On Fri, Mar 01, 2013 at 05:44:18PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
tools/intel_reg_dumper.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/intel_reg_dumper.c b/tools/intel_reg_dumper.c
index 20f332f..b66a1ea 100644
--- a/tools/intel_reg_dumper.c
+++ b/tools/intel_reg_dumper.c
@@ -2326,8 +2326,12 @@ int main(int argc, char** argv)
if (devid) {
if (IS_GEN5(devid))
pch = PCH_IBX;
- else
+ else if (IS_GEN6(devid) || IS_IVYBRIDGE(devid))
pch = PCH_CPT;
+ else if (IS_HASWELL(devid))
+ pch = PCH_LPT;
+ else
+ pch = PCH_NONE;
In patch 6/6 you're fixing the PCH detection code in lib/ maybe it'd be
a good idea to use it to detect the PCH of having heuristics on device 2
- PCH mappings?
Do you mean 1/6? We can't use intel_check_pch() here because we're
using the file and devid options: we're dumping registers from a
file, not from real hardware. So sometimes you create the file on one
machine (e.g., IVB) and dump on another (e.g. ILK).
--
Damien
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 black screen introduced by ACPI changes
Thanks Daniel I am recompiling the kernel. I will also open a bug in bugzilla when I collect all the relative information. Chris On Mon, Mar 4, 2013 at 9:50 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Two things to test: - Can you please check whether any of the backlight drivers in /sys/class/backlight does anything? You need to frob the brightness file. Please also list all the drivers you have. This is the good one before the acpi change. lrwxrwxrwx. 1 root root 0 Mar 4 15:05 acpi_video0 - ../../devices/pci:00/:00:01.0/:01:00.0/backlight/acpi_video0 lrwxrwxrwx. 1 root root 0 Mar 4 15:05 acpi_video1 - ../../devices/pci:00/:00:02.0/backlight/acpi_video1 lrwxrwxrwx. 1 root root 0 Mar 4 15:05 intel_backlight - ../../devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/intel_backlight The brightness,actual_brightness and max_brightness are all 4648. - Please grab the lates git of intel-gpu-tools and attach the output of intel_reg_dumper for both a working and a broken kernel. The git tree is at: I attach the reg dump file here. Thanks Chris intel-reg-dump.good Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 black screen introduced by ACPI changes
On Mon, Mar 4, 2013 at 3:16 PM, Chris Li l...@chrisli.org wrote: Two things to test: - Can you please check whether any of the backlight drivers in /sys/class/backlight does anything? You need to frob the brightness file. Please also list all the drivers you have. This is the kernel with the ACPI change causing the black screen. lrwxrwxrwx. 1 root root 0 Mar 4 15:20 acpi_video0 - ../../devices/pci:00/:00:01.0/:01:00.0/backlight/acpi_video0 lrwxrwxrwx. 1 root root 0 Mar 4 15:20 acpi_video1 - ../../devices/pci:00/:00:02.0/backlight/acpi_video1 lrwxrwxrwx. 1 root root 0 Mar 4 15:20 intel_backlight - ../../devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/intel_backlight Here is the interesting part. The brightness and max_brightness is all set to 4648, However, the actual brightness is 0. The bl_power is also 0. I think you are on to some thing. I attach the reg dump as intel-reg-bad. Chris intel-reg-bad Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ThinkPad T420 + kernel 3.8.x + external VGA display == wrong resolution
On 03/05/2013 11:41 AM, Daniel Vetter wrote: against DRI - DRM(Intel) and attach the files there together with your quick description of the regression above. Thanks, Daniel np : https://bugs.freedesktop.org/show_bug.cgi?id=61861 -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH IGT 2/6] intel_reg_dumper: recognize LPT
On Tue, Mar 05, 2013 at 01:05:32PM -0300, Paulo Zanoni wrote:
Hi
2013/3/5 Damien Lespiau damien.lesp...@intel.com:
On Fri, Mar 01, 2013 at 05:44:18PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
tools/intel_reg_dumper.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/intel_reg_dumper.c b/tools/intel_reg_dumper.c
index 20f332f..b66a1ea 100644
--- a/tools/intel_reg_dumper.c
+++ b/tools/intel_reg_dumper.c
@@ -2326,8 +2326,12 @@ int main(int argc, char** argv)
if (devid) {
if (IS_GEN5(devid))
pch = PCH_IBX;
- else
+ else if (IS_GEN6(devid) || IS_IVYBRIDGE(devid))
pch = PCH_CPT;
+ else if (IS_HASWELL(devid))
+ pch = PCH_LPT;
+ else
+ pch = PCH_NONE;
In patch 6/6 you're fixing the PCH detection code in lib/ maybe it'd be
a good idea to use it to detect the PCH of having heuristics on device 2
- PCH mappings?
Do you mean 1/6? We can't use intel_check_pch() here because we're
using the file and devid options: we're dumping registers from a
file, not from real hardware. So sometimes you create the file on one
machine (e.g., IVB) and dump on another (e.g. ILK).
Ah, of course, not enough context for that to be obvious :) For that I
guess I get to review the rest of the patches.
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Xen-devel] eDP screen corruption using linux 3.8 xen 4.2
Adding intel-gfx to this thread in the hopes that someone there might have some ideas since the fengzhe.zh...@intel.com address was bouncing. Thread origins, for that list's reference: http://markmail.org/thread/m4jhronecq4fvyk6 On Tue, Mar 5, 2013 at 11:42 AM, Jan Beulich jbeul...@suse.com wrote: On 05.03.13 at 17:33, Ben Guthro b...@guthro.net wrote: I turned up the debug, but didn't see this I am seeing other oops messages in the log now though...not sure if these are related. The first one likely is related (rax being 00aa00aa and apparently used as memory address, and that value very much looks like 2 pixels from a 32-bit pixel map). So I'd guess that there's once again some physical/machine address mixup. Jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix incorrect definition of ADPA HSYNC and VSYNC bits
Disable bits for ADPA HSYNC and VSYNC where mixed up resulting in suspend becoming standby and vice versa. Fixed by swapping their bit position. Reported-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com --- drivers/gpu/drm/i915/i915_reg.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 527b664..848992f 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1613,9 +1613,9 @@ #define ADPA_CRT_HOTPLUG_FORCE_TRIGGER (116) #define ADPA_USE_VGA_HVPOLARITY (115) #define ADPA_SETS_HVPOLARITY 0 -#define ADPA_VSYNC_CNTL_DISABLE (111) +#define ADPA_VSYNC_CNTL_DISABLE (110) #define ADPA_VSYNC_CNTL_ENABLE 0 -#define ADPA_HSYNC_CNTL_DISABLE (110) +#define ADPA_HSYNC_CNTL_DISABLE (111) #define ADPA_HSYNC_CNTL_ENABLE 0 #define ADPA_VSYNC_ACTIVE_HIGH (14) #define ADPA_VSYNC_ACTIVE_LOW0 -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, 2013-02-28 at 11:31 -0300, Paulo Zanoni wrote:
Hi
2013/2/28 Chris Wilson ch...@chris-wilson.co.uk:
On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek sedat.di...@gmail.com
wrote:
Hi,
I am seeing this also on Linux-Next.
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
/var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
This seems to be hard reproducible...
Laptop-LCD... Sandybridge Mobile-GT2.
Is there a way to force the error?
Possible patch see [1].
- Sedat -
[1] https://patchwork.kernel.org/patch/2192721/
That was:
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR(dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n,
+ has_aux_irq, status);
+ }
You applied
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR(dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n,
+ has_aux_irq, status);
+ {
In addition to this, after the problem happens can you please dump the
registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
by running intel-reg-read (from intel-gpu-tools) or by changing the
DRM_ERROR above to also print the result of I915_READ(0x44008) and
I915_READ(0xC4008).
If you conclude that the value of 0x44008 is 0x0 while the value of
0xC4008 is not, then this patch should help:
https://patchwork.kernel.org/patch/2177841/
I can trigger the bug on an ILK consistently by calling udelay(400) just
before 'I915_WRITE(SDEIIR, pch_iir);' in ironlake_irq_handler() until
the first timeout. Afterwards SDEIIR will contain SDE_AUXD and DEIIR
will be 0 and no more AUXD events will be serviced. With Paolo's patch I
can't trigger the bug even with the udelay being in place.
--Imre
That second '{' is the source of the compile error.
-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 mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: also disable south interrupts when handling them
On Fri, Feb 22, 2013 at 05:05:28PM -0300, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com From the docs: IIR can queue up to two interrupt events. When the IIR is cleared, it will set itself again after one clock if a second event was stored. Only the rising edge of the PCH Display interrupt will cause the North Display IIR (DEIIR) PCH Display Interrupt even bit to be set, so all PCH Display Interrupts, including back to back interrupts, must be cleared before a new PCH Display interrupt can cause DEIIR to be set. The current code works fine because we don't get many interrupts, but if we enable the PCH FIFO underrun interrupts we'll start getting so many interrupts that at some point new PCH interrupts won't cause DEIIR to be set. The initial implementation I tried was to turn the code that checks SDEIIR into a loop, but we can still get interrupts even after the loop is done (and before the irq handler finishes), so we have to either disable the interrupts or mask them. In the end I concluded that just disabling the PCH interrupts is enough, you don't even need the loop, so this is what this patch implements. I've tested it and it passes the 2 PCH FIFO underrun interrupt storms I can reproduce: the ironlake_crtc_disable case and the wrong watermarks case. In other words, here's how to reproduce the problem fixed by this patch: 1 - Enable PCH FIFO underrun interrupts (SERR_INT on SNB+) 2 - Boot the machine 3 - While booting we'll get tons of PCH FIFO underrun interrupts 4 - Plug a new monitor 5 - Run xrandr, notice it won't detect the new monitor 6 - Read SDEIIR and notice it's not 0 while DEIIR is 0 Q: Can't we just clear DEIIR before SDEIIR? A: It doesn't work. SDEIIR has to be completely cleared (including the interrupts stored on its back queue) before it can flip DEIIR's bit to 1 again, and even while you're clearing it you'll be getting more and more interrupts. Q: Why does it work by just disabling+enabling the south interrupts? A: Because when we re-enable them, if there's something on the SDEIIR register (maybe an interrupt stored on the queue), the re-enabling will make DEIIR's bit flip to 1, and since we'll already have interrupts enabled we'll get another interrupt, then run our irq handler again to process the back interrupts. v2: Even bigger commit message, added code comments. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com Since this seems to fix the dp aux irq timeout regression I've merged this to -fixes. Also volunteered Imre for a review, I'll add that if it pops up in the next few days. Big thanks to PauloImre for tracking this down. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix incorrect definition of ADPA HSYNC and VSYNC bits
Patrik Jakobsson patrik.r.jakobs...@gmail.com writes: Disable bits for ADPA HSYNC and VSYNC where mixed up resulting in suspend becoming standby and vice versa. Fixed by swapping their bit position. Reported-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com Confirmed in the 945 and 845 specs. Reviewed-by: Eric Anholt e...@anholt.net pgpAuBMtEMvY_.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: Fix incorrect definition of ADPA HSYNC and VSYNC bits
Dear Patrik, Am Dienstag, den 05.03.2013, 19:09 +0100 schrieb Patrik Jakobsson: Disable bits for ADPA HSYNC and VSYNC where mixed up resulting in suspend becoming standby and vice versa. nice find. Could you elaborate on the symptoms please as I have never experienced any issues with suspend and resume on my ASUS Eee PC 701 4G? Fixed by swapping their bit position. Reported-by: Ville Syrjälä ville.syrj...@linux.intel.com Where did Ville report this? Maybe my questions are already answered there. Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com --- drivers/gpu/drm/i915/i915_reg.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) […] 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
Re: [Intel-gfx] [PATCH 16/26] drm/i915: turbo RC6 support for VLV
On Sat, 2 Mar 2013, Jesse Barnes wrote:
From: Ben Widawsky b...@bwidawsk.net
Uses slightly different interfaces than other platforms.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_pm.c | 148 +--
1 file changed, 144 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e3947cb..d16f4f40 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2477,6 +2477,47 @@ void gen6_set_rps(struct drm_device *dev, u8 val)
trace_intel_gpu_freq_change(val * 50);
}
+void valleyview_set_rps(struct drm_device *dev, u8 val)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 limits = gen6_rps_limits(dev_priv, val);
+ u32 pval;
+
+ WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));
+ WARN_ON(val dev_priv-rps.max_delay);
+ WARN_ON(val dev_priv-rps.min_delay);
+
+ if (val == dev_priv-rps.cur_delay)
+ return;
+
+ valleyview_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val);
+
+ do {
+ valleyview_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS, pval);
+ if (time_after(jiffies, timeout)) {
+ DRM_DEBUG_DRIVER(timed out waiting for Punit\n);
+ break;
+ }
+ udelay(10);
+ } while (pval 1);
+
+ valleyview_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS, pval);
+ if ((pval 8) != val)
+ DRM_DEBUG_DRIVER(punit overrode freq: %d requested, but got
%d\n,
+ val, pval 8);
+
+ /* Make sure we continue to get interrupts
+* until we hit the minimum or maximum frequencies.
+*/
+ I915_WRITE(GEN6_RP_INTERRUPT_LIMITS, limits);
+
+ dev_priv-rps.cur_delay = val;
Shouldn't we store pval 8 instead of val in cur_delay in order to
reclaim the rps state? If we store val here, the requested frequency will
eventually exceed max_delay if punit overrides with a lower frequency.
+
+ trace_intel_gpu_freq_change(val * 50);
+}
+
+
static void gen6_disable_rps(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -2714,6 +2755,100 @@ static void gen6_update_ring_freq(struct drm_device
*dev)
}
}
+static void valleyview_enable_rps(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_ring_buffer *ring;
+ u32 gtfifodbg, val;
+ int i;
+
+ WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));
+
+ if ((gtfifodbg = I915_READ(GTFIFODBG))) {
+ DRM_ERROR(GT fifo had a previous error %x\n, gtfifodbg);
+ I915_WRITE(GTFIFODBG, gtfifodbg);
+ }
+
+ gen6_gt_force_wake_get(dev_priv);
+
+ I915_WRITE(GEN6_RC_SLEEP, 0);
+
+ I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 0x0028);
+ I915_WRITE(GEN6_RC_EVALUATION_INTERVAL, 125000);
+ I915_WRITE(GEN6_RC_IDLE_HYSTERSIS, 0x19);
+
+ for_each_ring(ring, dev_priv, i)
+ I915_WRITE(RING_MAX_IDLE(ring-mmio_base), 10);
+
+ I915_WRITE(GEN6_RC1e_THRESHOLD, 1000);
+ I915_WRITE(GEN6_RC6_THRESHOLD, 0xc350);
+
+ I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
+ I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
+ I915_WRITE(GEN6_RP_UP_EI, 66000);
+ I915_WRITE(GEN6_RP_DOWN_EI, 35);
+
+ I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
+
+ I915_WRITE(GEN6_RP_CONTROL,
+ GEN6_RP_MEDIA_TURBO |
+ GEN6_RP_MEDIA_HW_NORMAL_MODE |
+ GEN6_RP_MEDIA_IS_GFX |
+ GEN6_RP_ENABLE |
+ GEN6_RP_UP_BUSY_AVG |
+ GEN6_RP_DOWN_IDLE_CONT);
+
+ /* allows RC6 residency counter to work */
+ I915_WRITE(0x138104, 0x00ff);
+ I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE);
+
+ valleyview_punit_read(dev_priv, PUNIT_FUSE_BUS1, val);
+ DRM_DEBUG_DRIVER(max GPU freq: %d\n, val);
+ dev_priv-rps.max_delay = val;
+
+ valleyview_punit_read(dev_priv, PUNIT_REG_GPU_LFM, val);
+ DRM_DEBUG_DRIVER(min GPU freq: %d\n, val);
+ dev_priv-rps.min_delay = val;
+
+ valleyview_punit_read(dev_priv, PUNIT_FUSE_BUS2, val);
+ DRM_DEBUG_DRIVER(max GPLL freq: %d\n, val);
+
+ valleyview_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS, val);
+ DRM_DEBUG_DRIVER(DDR speed: );
+ if (((val 6) 3) == 0) {
+ dev_priv-mem_freq = 800;
+ printk(800 MHz\n);
+ } else if (((val 6) 3) == 1) {
+ printk(1066 MHz\n);
+ dev_priv-mem_freq = 1066;
+ } else if (((val 6) 3) == 2) {
+ printk(1333 MHz\n);
+ dev_priv-mem_freq = 1333;
+ } else if (((val 6) 3) == 3)
+ printk(invalid\n);
+
