Re: [Intel-gfx] [PATCH] sna: Initialize variable 'iter' to silence clang
Dear Sedat,
thank you for testing stuff with Clang!
Am Dienstag, den 26.02.2013, 15:15 +0100 schrieb Sedat Dilek:
Please always paste the error/warning messages so reviewers see exactly
what it has find.
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
---
src/sna/sna_damage.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/sna/sna_damage.c b/src/sna/sna_damage.c
index ab693af..53ed635 100644
--- a/src/sna/sna_damage.c
+++ b/src/sna/sna_damage.c
@@ -410,7 +410,7 @@ static void __sna_damage_reduce(struct sna_damage *damage)
int n, nboxes;
BoxPtr boxes, free_boxes = NULL;
pixman_region16_t *region = damage-region;
- struct sna_damage_box *iter;
+ struct sna_damage_box *iter = NULL;
Looking at the macro in `src/intel_list.h`
/**
* Loop through the list given by head and set pos to struct in the
list.
*
* Example:
* struct foo *iterator;
* list_for_each_entry(iterator, bar-list_of_foos, entry) {
* [modify iterator]
* }
*
* This macro is not safe for node deletion. Use
list_for_each_entry_safe
* instead.
*
* @param pos Iterator variable of the type of the list elements.
* @param head List head
* @param member Member name of the struct list in the list elements.
*
*/
#define list_for_each_entry(pos, head, member)
\
for (pos = __container_of((head)-next, pos, member);
\
pos-member != (head);
\
pos = __container_of(pos-member.next, pos, member))
the iterator is definitely initialized in the for loop.
pos = __container_of((head)-next
assert(damage-mode != DAMAGE_ALL);
assert(damage-dirty);
@@ -1671,7 +1671,7 @@ void _sna_damage_debug_get_region(struct sna_damage
*damage, RegionRec *r)
{
int n, nboxes;
BoxPtr boxes;
- struct sna_damage_box *iter;
+ struct sna_damage_box *iter = NULL;
RegionCopy(r, damage-region);
if (!damage-dirty)
So in my opinion this patch should not be applied as it would prevent
the compiler to warn next time when there is really a code change where
this variable might be uninitialized.
By the way, does `gcc` warn about this?
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 v.2 03/12] DRM/i915: Convert HPD interrupts to make use of HPD pin assignment in encoders (v2)
This allows to enable HPD interrupts for individual pins to only receive
hotplug events from lines which are connected and working.
v2: Restructured initailization of const arrays following a suggstion
by Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Egbert Eich e...@suse.de
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_irq.c | 151 ---
drivers/gpu/drm/i915/i915_reg.h | 32 -
2 files changed, 123 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5fd3267..7bdc90c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -36,6 +36,59 @@
#include i915_trace.h
#include intel_drv.h
+static const u32 hpd_ibx[] = {
+ [HPD_CRT] = SDE_CRT_HOTPLUG,
+ [HPD_SDVO_B] = SDE_SDVOB_HOTPLUG,
+ [HPD_PORT_B] = SDE_PORTB_HOTPLUG,
+ [HPD_PORT_C] = SDE_PORTC_HOTPLUG,
+ [HPD_PORT_D] = SDE_PORTD_HOTPLUG
+};
+
+static const u32 hpd_cpt[] = {
+ [HPD_CRT] = SDE_CRT_HOTPLUG_CPT,
+ [HPD_PORT_B] = SDE_PORTB_HOTPLUG_CPT,
+ [HPD_PORT_C] = SDE_PORTC_HOTPLUG_CPT,
+ [HPD_PORT_D] = SDE_PORTD_HOTPLUG_CPT
+};
+
+static const u32 hpd_mask_i915[] = {
+ [HPD_CRT] = CRT_HOTPLUG_INT_EN,
+ [HPD_SDVO_B] = SDVOB_HOTPLUG_INT_EN,
+ [HPD_SDVO_C] = SDVOC_HOTPLUG_INT_EN,
+ [HPD_PORT_B] = PORTB_HOTPLUG_INT_EN,
+ [HPD_PORT_C] = PORTC_HOTPLUG_INT_EN,
+ [HPD_PORT_D] = PORTD_HOTPLUG_INT_EN
+};
+
+static const u32 hpd_status_gen4[] = {
+ [HPD_CRT] = CRT_HOTPLUG_INT_STATUS,
+ [HPD_SDVO_B] = SDVOB_HOTPLUG_INT_STATUS_G4X,
+ [HPD_SDVO_C] = SDVOC_HOTPLUG_INT_STATUS_G4X,
+ [HPD_PORT_B] = PORTB_HOTPLUG_INT_STATUS,
+ [HPD_PORT_C] = PORTC_HOTPLUG_INT_STATUS,
+ [HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
+};
+
+static const u32 hpd_status_i965[] = {
+[HPD_CRT] = CRT_HOTPLUG_INT_STATUS,
+[HPD_SDVO_B] = SDVOB_HOTPLUG_INT_STATUS_I965,
+[HPD_SDVO_C] = SDVOC_HOTPLUG_INT_STATUS_I965,
+[HPD_PORT_B] = PORTB_HOTPLUG_INT_STATUS,
+[HPD_PORT_C] = PORTC_HOTPLUG_INT_STATUS,
+[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
+};
+
+static const u32 hpd_status_i915[] = { /* i915 and valleyview are the same */
+ [HPD_CRT] = CRT_HOTPLUG_INT_STATUS,
+ [HPD_SDVO_B] = SDVOB_HOTPLUG_INT_STATUS_I915,
+ [HPD_SDVO_C] = SDVOC_HOTPLUG_INT_STATUS_I915,
+ [HPD_PORT_B] = PORTB_HOTPLUG_INT_STATUS,
+ [HPD_PORT_C] = PORTC_HOTPLUG_INT_STATUS,
+ [HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
+};
+
+
+
/* For display hotplug interrupt */
static void
ironlake_enable_display_irq(drm_i915_private_t *dev_priv, u32 mask)
@@ -596,7 +649,7 @@ static irqreturn_t valleyview_irq_handler(int irq, void
*arg)
DRM_DEBUG_DRIVER(hotplug event received, stat
0x%08x\n,
hotplug_status);
- if (hotplug_status dev_priv-hotplug_supported_mask)
+ if (hotplug_status HOTPLUG_INT_STATUS_I915)
queue_work(dev_priv-wq,
dev_priv-hotplug_work);
@@ -1940,17 +1993,21 @@ static void ibx_enable_hotplug(struct drm_device *dev)
static void ibx_irq_postinstall(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
- u32 mask;
-
- if (HAS_PCH_IBX(dev))
- mask = SDE_HOTPLUG_MASK |
- SDE_GMBUS |
- SDE_AUX_MASK;
- else
- mask = SDE_HOTPLUG_MASK_CPT |
- SDE_GMBUS_CPT |
- SDE_AUX_MASK_CPT;
+ struct drm_mode_config *mode_config = dev-mode_config;
+ struct intel_encoder *intel_encoder;
+ u32 mask = I915_READ(SDEIER);
+ if (HAS_PCH_IBX(dev)) {
+ mask = ~SDE_HOTPLUG_MASK;
+ list_for_each_entry(intel_encoder, mode_config-encoder_list,
base.head)
+ mask |= hpd_ibx[intel_encoder-hpd_pin];
+ mask |= SDE_GMBUS | SDE_AUX_MASK;
+ } else {
+ mask = ~SDE_HOTPLUG_MASK_CPT;
+ list_for_each_entry(intel_encoder, mode_config-encoder_list,
base.head)
+ mask |= hpd_cpt[intel_encoder-hpd_pin];
+ mask |= SDE_GMBUS_CPT | SDE_AUX_MASK_CPT;
+ }
I915_WRITE(SDEIIR, I915_READ(SDEIIR));
I915_WRITE(SDEIMR, ~mask);
I915_WRITE(SDEIER, mask);
@@ -2360,26 +2417,16 @@ static int i915_irq_postinstall(struct drm_device *dev)
static void i915_hpd_irq_setup(struct drm_device *dev)
{
- drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
- u32 hotplug_en;
-
if (I915_HAS_HOTPLUG(dev)) {
- hotplug_en = I915_READ(PORT_HOTPLUG_EN);
+ drm_i915_private_t *dev_priv = (drm_i915_private_t *)
[Intel-gfx] [PATCH v.2 06/12] DRM/i915: Add HPD IRQ storm detection (v2)
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.
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..6ca742d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1059,6 +1059,15 @@ typedef struct drm_i915_private {
/* Old dri1 support infrastructure, beware the dragons ya fools entering
* here! */
struct i915_dri1_state dri1;
+ 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];
} drm_i915_private_t;
/* Iterate over initialised rings */
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 09/13] drm/i915: add reset_state for hw_contexts
On Wed, Feb 27, 2013 at 05:15:08PM -0800, Ian Romanick wrote: On 02/27/2013 01:13 AM, Chris Wilson wrote: On Tue, Feb 26, 2013 at 05:47:12PM -0800, Ian Romanick wrote: On 02/26/2013 03:05 AM, Mika Kuoppala wrote: For arb-robustness, every context needs to have it's own reset state tracking. Default context will be handled in a identical way as the no-context case in further down in the patch set. For no-context case, the reset state will be stored in the file_priv part. v2: handle default context inside get_reset_state This isn't the interface we want. I already sent you the patches for Mesa, and you seem to have completely ignored them. Moreover, this interface provides no mechanism to query for its existence (other than relying on the kernel version), and no method to deprecate it. It's existence, and the existence of any successor, is the only test you need to check for the interface. Testing the flag field up front also lets you know if individual flags are known prior to use. Based on e-mail discussions, I think danvet agrees with me here. Putting guilty / innocent counting in kernel puts policy decisions in the kernel that belong with the user space API that implements them. Putting these choices in the kernel significantly decreases how future proof the interface is. Since any kernel/user interface has to be kept forever, this is just asking for maintenance trouble down the road. I think you have the policy standpoint reversed. Can you elaborate? I've been out of the kernel loop for a long time, but I always thought policy and mechanism were supposed to be separated. In the case of drivers with a user-mode component, the mechanism was in the kernel (where else could it be?), and policy decisions were in user-mode. This is often at odds with keeping the interfaces between kernel and user thin, so that may be where my misunderstanding is. Right, the idea is to keep policy out of the kernel. I disagree that your suggestion succeeds in doing this. [snip to details] There are two requirements in the ARB_robustness extension (and additional layered extensions) that I believe cause problems with all of the proposed counting interfaces. 1. GL contexts that are not affected by a reset (i.e., didn't lose any objects, didn't lose any rendering, etc.) should not observe it. This is the big one that all the browser vendors want. If you have 5 tabs open, a reset caused by a malicious WebGL app in one tab shouldn't, if possible, force them to rebuild all of their state for all the other tabs. 2. After a GL context observes a reset, it is garbage. It must be destroyed and a new one created. This means we only need to know that a reset of any variety affected the context. For me observes implies the ability for the context to inspect global system state, whereas I think you mean if the context and its associated state is affected by a reset. In addition, I'm concerned about having one GL context be able to observe, in any manner, resets that did not affect it. Given that people have figured out how to get encryption keys by observing cache timings, it's not impossible for a malicious program to use information about reset counts to do something. Leaving a potential gap like this in an extension that's used to improved security seems... like we're just asking for a Phoronix article. We don't have any requirement to expose this information, so I don't think we should. So we should not do minor+major pagefault tracking either? I only suggested that you could read the global state because I thought you implied you wanted it. From the display server POV, global state is the most useful as I am more interested in whether I can reliably use the GPU and prevent a DoS from a misbehaving set of clients. We also don't have any requirement to expose this functionality on anything pre-Sandy Bridge. We may want, at some point, to expose it on Ironlake. Based on that, it seems reasonable to tie the availability of reset notifications to hardware contexts. Since we won't test it, Mesa certainly isn't going to expose it on 8xx or 915. From a design standpoint hw contexts are just one function of the context object and not the reverse. Ben has been rightfully arguing that we need contexts in the kernel for far more than supporting logical hw contexts. Based on this, a simplified interface became obvious: for each hardware context, track a mask of kinds of resets that have affected that context. I defined three bits in the mask: The problem is that you added an atomic-read-and-reset into the ioctl. I objected to that policy when Mika presented it earlier as it prevents concurrent accesses and so imposes an explicit usage model. 1. The hw context had a batch executing when the reset occurred. 2. The hw context had a batch pending when the reset occurred. Hopefully in the future we could make most occurrences of this go
Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1
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);
+ {
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] Warnings in `sna_damage.c` (was: [PATCH] sna: Initialize variable 'iter' to silence clang)
Dear Sedat,
Am Donnerstag, den 28.02.2013, 09:45 +0100 schrieb Paul Menzel:
thank you for testing stuff with Clang!
Am Dienstag, den 26.02.2013, 15:15 +0100 schrieb Sedat Dilek:
Please always paste the error/warning messages so reviewers see exactly
what it has find.
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
---
src/sna/sna_damage.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/sna/sna_damage.c b/src/sna/sna_damage.c
index ab693af..53ed635 100644
--- a/src/sna/sna_damage.c
+++ b/src/sna/sna_damage.c
@@ -410,7 +410,7 @@ static void __sna_damage_reduce(struct sna_damage
*damage)
int n, nboxes;
BoxPtr boxes, free_boxes = NULL;
pixman_region16_t *region = damage-region;
- struct sna_damage_box *iter;
+ struct sna_damage_box *iter = NULL;
Looking at the macro in `src/intel_list.h`
/**
* Loop through the list given by head and set pos to struct in the
list.
*
* Example:
* struct foo *iterator;
* list_for_each_entry(iterator, bar-list_of_foos, entry) {
* [modify iterator]
* }
*
* This macro is not safe for node deletion. Use
list_for_each_entry_safe
* instead.
*
* @param pos Iterator variable of the type of the list elements.
* @param head List head
* @param member Member name of the struct list in the list elements.
*
*/
#define list_for_each_entry(pos, head, member)
\
for (pos = __container_of((head)-next, pos, member);
\
pos-member != (head);
\
pos = __container_of(pos-member.next, pos, member))
the iterator is definitely initialized in the for loop.
pos = __container_of((head)-next
assert(damage-mode != DAMAGE_ALL);
assert(damage-dirty);
@@ -1671,7 +1671,7 @@ void _sna_damage_debug_get_region(struct sna_damage
*damage, RegionRec *r)
{
int n, nboxes;
BoxPtr boxes;
- struct sna_damage_box *iter;
+ struct sna_damage_box *iter = NULL;
RegionCopy(r, damage-region);
if (!damage-dirty)
So in my opinion this patch should not be applied as it would prevent
the compiler to warn next time when there is really a code change where
this variable might be uninitialized.
By the way, does `gcc` warn about this?
Using GCC I only see the following warnings in `sna_damage.c`.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.7.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.7/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
4.7.2-15' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --enable-targets=all --enable-multiarch
--with-arch-32=i586 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-15)
$ ./autogen.sh # I’d prefer it did not run ./configure
$ make
[…]
sna_damage.c: In function '__sna_damage_add_box':
sna_damage.c:601:11: warning: cast discards '__attribute__((const))'
qualifier from pointer target type [-Wcast-qual]
sna_damage.c: In function '__sna_damage_contains_box':
sna_damage.c:1292:58: warning: cast discards '__attribute__((const))'
qualifier from pointer target type [-Wcast-qual]
sna_damage.c:1305:59: warning: cast discards '__attribute__((const))'
qualifier from pointer target type [-Wcast-qual]
sna_damage.c: In function '_sna_damage_contains_box__no_reduce':
sna_damage.c:1346:42: warning: cast discards '__attribute__((const))'
qualifier from pointer target type [-Wcast-qual]
sna_damage.c:1347:7: warning: cast discards '__attribute__((const))'
qualifier from pointer target type [-Wcast-qual]
[…]
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] [i-g-t][PATH] debugger: Include path for cairo to fix compiler error
On Thu, Feb 28, 2013 at 01:37:52PM +0800, Xiang, Haihao wrote: From: Xiang, Haihao haihao.xi...@intel.com CC eudb.o In file included from eudb.c:44:0: ../lib/drmtest.h:34:19: fatal error: cairo.h: No such file or directory compilation terminated. make[3]: *** [eudb.o] Error 1 Signed-off-by: Xiang, Haihao haihao.xi...@intel.com --- debugger/Makefile.am |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/debugger/Makefile.am b/debugger/Makefile.am index d76e2ac..fde6e02 100644 --- a/debugger/Makefile.am +++ b/debugger/Makefile.am @@ -11,6 +11,7 @@ AM_CPPFLAGS = \ AM_CFLAGS = \ $(DRM_CFLAGS) \ $(PCIACCESS_CFLAGS) \ - $(CWARNFLAGS) + $(CWARNFLAGS) \ + $(CAIRO_CFLAGS) I already have a similar patch in the assembler branch: http://cgit.freedesktop.org/~damien/intel-gpu-tools/commit/?h=assembler-rebasedid=5e8edce34fe53d02cb923d33152746202247337f I'm waiting on the fdo admins to get access to the repository to push the branch, but I guess I'll nag someone to push the branch for me sooner rather than later. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Regression: Backlight not coming on after resume.
On Thu, 28 Feb 2013, James Courtier-Dutton james.dut...@gmail.com wrote: Bisect done on tree: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Worked on 3.7. Broken on 3.8 Problem: Backlight not coming on after resume. git finally bisected for my Samsung Serial 7 Laptop. Bisecting: 0 revisions left to test after this (roughly 0 steps) [cf0a6584aa6d382f802f2c3cacac23ccbccde0cd] drm/i915: write backlight harder - This is the problem commit. Seems that fixing some machines breaks others, based on the existing comments on that patch. The backlight haunts us again. Could you post the dmesg with drm.debug=0xe module parameter, first running vanilla 3.8, and then with the bad commit reverted, please? Might not be a bad idea to file a bug on Product=DRI, Component=DRM/Intel at https://bugs.freedesktop.org (see https://01.org/linuxgraphics/documentation/how-report-bugs-0 for details) and attach your bisect results and the dmesgs there. Thanks, Jani. ___ 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, Feb 28, 2013 at 12:18 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
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);
+ {
That second '{' is the source of the compile error.
Schei**e, OK I try with a v2.
A hint how to force the error?
- Sedat -
-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] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni przan...@gmail.com 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).
Do I need a specific version of intel-gpu-tools?
Ubuntu/precise has v1.2 in its archives - sufficient?
Note: The error was twice after dozenz of Linux-Next kernel builds.
- Sedat -
[1] http://packages.ubuntu.com/precise/intel-gpu-tools
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/
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
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Document the find_pll() function
From: Ville Syrjälä ville.syrj...@linux.intel.com
The proper use of find_pll() isn't always so easy to determine from the
code itself. Some documentation should help.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ebe9dae..27ad084 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -71,8 +71,24 @@ typedef struct intel_limit intel_limit_t;
struct intel_limit {
intel_range_t dot, vco, n, m, m1, m2, p, p1;
intel_p2_t p2;
- bool (* find_pll)(const intel_limit_t *, struct drm_crtc *,
- int, int, intel_clock_t *, intel_clock_t *);
+ /**
+* find_pll() - Find the best values for the PLL
+* @limit: limits for the PLL
+* @crtc: current CRTC
+* @target: target frequency in kHz
+* @refclk: reference clock frequency in kHz
+* @match_clock: if provided, @best_clock P divider must
+* match the P divider from @match_clock
+* used for LVDS downclocking
+* @best_clock: best PLL values found
+*
+* Returns true on success, false on failure.
+*/
+ bool (*find_pll)(const intel_limit_t *limit,
+struct drm_crtc *crtc,
+int target, int refclk,
+intel_clock_t *match_clock,
+intel_clock_t *best_clock);
};
/* FDI */
--
1.7.12.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Remove a stale and misplaced comment
From: Ville Syrjälä ville.syrj...@linux.intel.com
The load detection code has moved around at some point, but it left
a comment behind. The code now looks to be different enough to make
the comment stale as well. Just remove it.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 27ad084..1281593 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6461,20 +6461,6 @@ static void intel_crtc_gamma_set(struct drm_crtc *crtc,
u16 *red, u16 *green,
intel_crtc_load_lut(crtc);
}
-/**
- * Get a pipe with a simple mode set on it for doing load-based monitor
- * detection.
- *
- * It will be up to the load-detect code to adjust the pipe as appropriate for
- * its requirements. The pipe will be connected to no other encoders.
- *
- * Currently this code will only succeed if there is a pipe with no encoders
- * configured for it. In the future, it could choose to temporarily disable
- * some outputs to free up a pipe for its use.
- *
- * \return crtc, or NULL if no pipes are available.
- */
-
/* VESA 640x480x72Hz mode to set on the pipe */
static struct drm_display_mode load_detect_mode = {
DRM_MODE(640x480, DRM_MODE_TYPE_DEFAULT, 31500, 640, 664,
--
1.7.12.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Kill a few pointless comments
From: Ville Syrjälä ville.syrj...@linux.intel.com
The code is totally obvious so these comments serve no purpose. What's
worse, one of them was wrong. Just remove them.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1281593..0644f20 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -487,7 +487,6 @@ static const intel_limit_t *intel_ironlake_limit(struct
drm_crtc *crtc,
if (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS)) {
if (intel_is_dual_link_lvds(dev)) {
- /* LVDS dual channel */
if (refclk == 10)
limit = intel_limits_ironlake_dual_lvds_100m;
else
@@ -514,10 +513,8 @@ static const intel_limit_t *intel_g4x_limit(struct
drm_crtc *crtc)
if (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS)) {
if (intel_is_dual_link_lvds(dev))
- /* LVDS with dual channel */
limit = intel_limits_g4x_dual_channel_lvds;
else
- /* LVDS with dual channel */
limit = intel_limits_g4x_single_channel_lvds;
} else if (intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI) ||
intel_pipe_has_type(crtc, INTEL_OUTPUT_ANALOG)) {
--
1.7.12.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Regression: Backlight not coming on after resume.
At Thu, 28 Feb 2013 17:33:56 +0200, Jani Nikula wrote: On Thu, 28 Feb 2013, James Courtier-Dutton james.dut...@gmail.com wrote: Bisect done on tree: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Worked on 3.7. Broken on 3.8 Problem: Backlight not coming on after resume. git finally bisected for my Samsung Serial 7 Laptop. Bisecting: 0 revisions left to test after this (roughly 0 steps) [cf0a6584aa6d382f802f2c3cacac23ccbccde0cd] drm/i915: write backlight harder - This is the problem commit. Seems that fixing some machines breaks others, based on the existing comments on that patch. The backlight haunts us again. Could you post the dmesg with drm.debug=0xe module parameter, first running vanilla 3.8, and then with the bad commit reverted, please? Might not be a bad idea to file a bug on Product=DRI, Component=DRM/Intel at https://bugs.freedesktop.org (see https://01.org/linuxgraphics/documentation/how-report-bugs-0 for details) and attach your bisect results and the dmesgs there. I'm afraid the patch doesn't do it right. It fixes for Dell, but the old problem on others back by that. It was merged before actually testing on the machines the original fix was intended for. Now I can confirm a problem (partially) with the latest Linus tree on a new laptop. I write partially because it happens only during the splash screen of S4 hibernation, so I've ignored, so far. James, try to revert that commit. Does it fix? If so, you should check the output of intel_reg_dumper at broken and working states. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Enable/Disable PSR
Hi
So now I finally have the correct spec in hands!
2013/2/25 Rodrigo Vivi rodrigo.v...@gmail.com:
Adding Enable and Disable PSR functionalities. This includes setting the
PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
enabling PSR in the sink via DPCD register and finally enabling PSR on
the host.
This patch is heavily based on initial PSR code by Sateesh Kavuri and
Kumar Shobhit but in a different implementation.
Credits-by: Sateesh Kavuri sateesh.kav...@intel.com
Credits-by: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_reg.h | 40 +
drivers/gpu/drm/i915/intel_dp.c | 183
+++
drivers/gpu/drm/i915/intel_drv.h | 3 +
3 files changed, 226 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b715ecd..1e31f23 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -844,6 +844,8 @@
#define SNB_CPU_FENCE_ENABLE (129)
#define DPFC_CPU_FENCE_OFFSET 0x100104
+/* Framebuffer compression for Haswell */
+#define HSW_FBC_CONTROL0x43208
/*
* GPIO regs
@@ -1580,6 +1582,44 @@
#define BCLRPAT(pipe) _PIPE(pipe, _BCLRPAT_A, _BCLRPAT_B)
#define VSYNCSHIFT(trans) _TRANSCODER(trans, _VSYNCSHIFT_A, _VSYNCSHIFT_B)
+/* HSW eDP PSR registers */
+#define EDP_PSR_CTL0x64800
+#define EDP_PSR_ENABLE (131)
+#define EDP_PSR_LINK_DISABLE (027)
+#define EDP_PSR_LINK_STANDBY (127)
+#define EDP_PSR_MIN_LINK_ENTRY_TIME_MASK (325)
+#define EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES (025)
+#define EDP_PSR_MIN_LINK_ENTRY_TIME_4_LINES (125)
+#define EDP_PSR_MIN_LINK_ENTRY_TIME_2_LINES (225)
+#define EDP_PSR_MIN_LINK_ENTRY_TIME_0_LINES (325)
+#define EDP_PSR_MAX_SLEEP_TIME_SHIFT 20
+#define EDP_PSR_SKIP_AUX_EXIT(112)
+#define EDP_PSR_TP1_TP2_SEL (011)
+#define EDP_PSR_TP1_TP3_SEL (111)
+#define EDP_PSR_TP2_TP3_TIME_500us (08)
+#define EDP_PSR_TP2_TP3_TIME_100us (18)
+#define EDP_PSR_TP2_TP3_TIME_2500us (28)
+#define EDP_PSR_TP2_TP3_TIME_0us (38)
+#define EDP_PSR_TP1_TIME_500us (04)
+#define EDP_PSR_TP1_TIME_100us (14)
+#define EDP_PSR_TP1_TIME_2500us (24)
+#define EDP_PSR_TP1_TIME_0us (34)
+#define EDP_PSR_IDLE_FRAME_SHIFT 0
+
+#define EDP_PSR_AUX_CTL0x64810
+#define EDP_PSR_AUX_DATA1 0x64814
+#define EDP_PSR_AUX_DATA2 0x64818
+#define EDP_PSR_AUX_DATA3 0x6481c
+#define EDP_PSR_AUX_DATA4 0x64820
+#define EDP_PSR_AUX_DATA5 0x64824
+
+#define EDP_PSR_STATUS_CTL 0x64840
+#define EDP_PSR_STATUS_STATE_MASK(729)
+
+#define EDP_PSR_DEBUG_CTL 0x64860
+#define EDP_PSR_DEBUG_MASK_MEMUP (126)
+#define EDP_PSR_DEBUG_MASK_HPD (125)
+
/* VGA port control */
#define ADPA 0x61100
#define PCH_ADPA0xe1100
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5cfa9f4..a420f0d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -83,6 +83,13 @@ static struct drm_device *intel_dp_to_dev(struct intel_dp
*intel_dp)
return intel_dig_port-base.base.dev;
}
+static struct drm_crtc *intel_dp_to_crtc(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+
+ return intel_dig_port-base.base.crtc;
+}
+
static struct intel_dp *intel_attached_dp(struct drm_connector *connector)
{
return enc_to_intel_dp(intel_attached_encoder(connector)-base);
@@ -1443,6 +1450,182 @@ static bool is_edp_psr(struct intel_dp *intel_dp)
(intel_dp-psr_dpcd[0] DP_PSR_IS_SUPPORTED));
}
+static bool
+intel_edp_is_psr_enabled(struct intel_dp* intel_dp)
+{
+ struct drm_device *dev = intel_dp_to_dev(intel_dp);
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ return I915_READ(EDP_PSR_CTL) EDP_PSR_ENABLE;
+}
+
+static void
+intel_edp_psr_enable_src(struct intel_dp *intel_dp)
+{
+ struct drm_device *dev = intel_dp_to_dev(intel_dp);
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t max_sleep_time = 0x1f;
+ uint32_t val = 0x0;
+
+ if (dev_priv-vbt.psr_idle_frames)
+ val |= dev_priv-vbt.psr_idle_frames EDP_PSR_IDLE_FRAME_SHIFT;
+ else
+ val |= 1 EDP_PSR_IDLE_FRAME_SHIFT;
+
+ if (intel_dp-psr_dpcd[1] DP_PSR_NO_TRAIN_ON_EXIT) {
+ val |= EDP_PSR_LINK_STANDBY;
If we set this bit,
Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni przan...@gmail.com 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).
Do I need a specific version of intel-gpu-tools?
Ubuntu/precise has v1.2 in its archives - sufficient?
Note: The error was twice after dozenz of Linux-Next kernel builds.
- Sedat -
[1] http://packages.ubuntu.com/precise/intel-gpu-tools
Installed intel-gpu-tools.
# intel_reg_read
Usage: intel_reg_read [-f | addr]
-f : read back full range of registers.
WARNING! This could be danger to hang the machine!
addr : in 0x format
# intel_reg_read 0x44008
Couldn't map MMIO region: Resource temporarily unavailable
[ 368.281707] intel_reg_read:3657 conflicting memory types
f000-f040 uncached-minus-write-combining
[ 381.521912] intel_reg_read:3658 conflicting memory types
f000-f040 uncached-minus-write-combining
[ 401.136291] intel_reg_read:3659 conflicting memory types
f000-f040 uncached-minus-write-combining
Wrong i-g-t version? Missing enabled kernel-config option? Boot with
i915 debug enabled?
- Sedat -
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/
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
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Enable/Disable PSR
Hi
2013/2/26 Ville Syrjälä ville.syrj...@linux.intel.com:
On Mon, Feb 25, 2013 at 07:55:20PM -0300, Rodrigo Vivi wrote:
Adding Enable and Disable PSR functionalities. This includes setting the
PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
enabling PSR in the sink via DPCD register and finally enabling PSR on
the host.
This patch is heavily based on initial PSR code by Sateesh Kavuri and
Kumar Shobhit but in a different implementation.
Credits-by: Sateesh Kavuri sateesh.kav...@intel.com
Credits-by: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_reg.h | 40 +
drivers/gpu/drm/i915/intel_dp.c | 183
+++
drivers/gpu/drm/i915/intel_drv.h | 3 +
3 files changed, 226 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index b715ecd..1e31f23 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -844,6 +844,8 @@
#define SNB_CPU_FENCE_ENABLE (129)
#define DPFC_CPU_FENCE_OFFSET0x100104
+/* Framebuffer compression for Haswell */
+#define HSW_FBC_CONTROL 0x43208
/*
* GPIO regs
@@ -1580,6 +1582,44 @@
#define BCLRPAT(pipe) _PIPE(pipe, _BCLRPAT_A, _BCLRPAT_B)
#define VSYNCSHIFT(trans) _TRANSCODER(trans, _VSYNCSHIFT_A, _VSYNCSHIFT_B)
+/* HSW eDP PSR registers */
+#define EDP_PSR_CTL 0x64800
+#define EDP_PSR_ENABLE (131)
+#define EDP_PSR_LINK_DISABLE (027)
+#define EDP_PSR_LINK_STANDBY (127)
+#define EDP_PSR_MIN_LINK_ENTRY_TIME_MASK (325)
+#define EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES(025)
+#define EDP_PSR_MIN_LINK_ENTRY_TIME_4_LINES(125)
+#define EDP_PSR_MIN_LINK_ENTRY_TIME_2_LINES(225)
+#define EDP_PSR_MIN_LINK_ENTRY_TIME_0_LINES(325)
+#define EDP_PSR_MAX_SLEEP_TIME_SHIFT 20
+#define EDP_PSR_SKIP_AUX_EXIT (112)
+#define EDP_PSR_TP1_TP2_SEL(011)
+#define EDP_PSR_TP1_TP3_SEL(111)
+#define EDP_PSR_TP2_TP3_TIME_500us (08)
+#define EDP_PSR_TP2_TP3_TIME_100us (18)
+#define EDP_PSR_TP2_TP3_TIME_2500us(28)
+#define EDP_PSR_TP2_TP3_TIME_0us (38)
+#define EDP_PSR_TP1_TIME_500us (04)
+#define EDP_PSR_TP1_TIME_100us (14)
+#define EDP_PSR_TP1_TIME_2500us(24)
+#define EDP_PSR_TP1_TIME_0us (34)
+#define EDP_PSR_IDLE_FRAME_SHIFT 0
+
+#define EDP_PSR_AUX_CTL 0x64810
+#define EDP_PSR_AUX_DATA10x64814
+#define EDP_PSR_AUX_DATA20x64818
+#define EDP_PSR_AUX_DATA30x6481c
+#define EDP_PSR_AUX_DATA40x64820
+#define EDP_PSR_AUX_DATA50x64824
+
+#define EDP_PSR_STATUS_CTL 0x64840
+#define EDP_PSR_STATUS_STATE_MASK (729)
+
+#define EDP_PSR_DEBUG_CTL0x64860
+#define EDP_PSR_DEBUG_MASK_MEMUP (126)
+#define EDP_PSR_DEBUG_MASK_HPD (125)
+
/* VGA port control */
#define ADPA 0x61100
#define PCH_ADPA0xe1100
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 5cfa9f4..a420f0d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -83,6 +83,13 @@ static struct drm_device *intel_dp_to_dev(struct intel_dp
*intel_dp)
return intel_dig_port-base.base.dev;
}
+static struct drm_crtc *intel_dp_to_crtc(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+
+ return intel_dig_port-base.base.crtc;
+}
+
static struct intel_dp *intel_attached_dp(struct drm_connector *connector)
{
return enc_to_intel_dp(intel_attached_encoder(connector)-base);
@@ -1443,6 +1450,182 @@ static bool is_edp_psr(struct intel_dp *intel_dp)
(intel_dp-psr_dpcd[0] DP_PSR_IS_SUPPORTED));
}
+static bool
+intel_edp_is_psr_enabled(struct intel_dp* intel_dp)
+{
+ struct drm_device *dev = intel_dp_to_dev(intel_dp);
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ return I915_READ(EDP_PSR_CTL) EDP_PSR_ENABLE;
+}
+
+static void
+intel_edp_psr_enable_src(struct intel_dp *intel_dp)
+{
+ struct drm_device *dev = intel_dp_to_dev(intel_dp);
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t max_sleep_time = 0x1f;
+ uint32_t val = 0x0;
+
+ if (dev_priv-vbt.psr_idle_frames)
+ val |= dev_priv-vbt.psr_idle_frames EDP_PSR_IDLE_FRAME_SHIFT;
+ else
+ val |= 1 EDP_PSR_IDLE_FRAME_SHIFT;
+
+ if (intel_dp-psr_dpcd[1] DP_PSR_NO_TRAIN_ON_EXIT) {
+ val |= EDP_PSR_LINK_STANDBY;
There
Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1
Hi
2013/2/28 Sedat Dilek sedat.di...@gmail.com:
On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni przan...@gmail.com 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).
Do I need a specific version of intel-gpu-tools?
Ubuntu/precise has v1.2 in its archives - sufficient?
Note: The error was twice after dozenz of Linux-Next kernel builds.
- Sedat -
[1] http://packages.ubuntu.com/precise/intel-gpu-tools
Installed intel-gpu-tools.
# intel_reg_read
Usage: intel_reg_read [-f | addr]
-f : read back full range of registers.
WARNING! This could be danger to hang the machine!
addr : in 0x format
# intel_reg_read 0x44008
Couldn't map MMIO region: Resource temporarily unavailable
[ 368.281707] intel_reg_read:3657 conflicting memory types
f000-f040 uncached-minus-write-combining
[ 381.521912] intel_reg_read:3658 conflicting memory types
f000-f040 uncached-minus-write-combining
[ 401.136291] intel_reg_read:3659 conflicting memory types
f000-f040 uncached-minus-write-combining
Wrong i-g-t version? Missing enabled kernel-config option? Boot with
i915 debug enabled?
Just build the version from git and it should work
(http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/).
- Sedat -
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/
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
--
Paulo Zanoni
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/i915: Added debugfs support for PSR Status
Hi
2013/2/25 Rodrigo Vivi rodrigo.v...@gmail.com:
Adding support for PSR Status, PSR entry counter and performance counters.
Heavily based on initial work from Shobhit.
Credits-by: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 92
+
drivers/gpu/drm/i915/i915_reg.h | 24 ++
2 files changed, 116 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7c65ab8..01021f6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1680,6 +1680,97 @@ static int i915_dpio_info(struct seq_file *m, void
*data)
return 0;
}
+
+static int i915_edp_psr_status(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m-private;
+ struct drm_device *dev = node-minor-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ unsigned int count;
+ u32 psrctl, psrstat, psrperf;
+
+ psrctl = I915_READ(EDP_PSR_CTL);
+ seq_printf(m, PSR Enabled: %s\n,
+ yesno(psrctl EDP_PSR_ENABLE));
+
+ psrstat = I915_READ(EDP_PSR_STATUS_CTL);
+
+ seq_printf(m, PSR Current State: );
+ switch (psrstat EDP_PSR_STATUS_STATE_MASK) {
+ case EDP_PSR_STATUS_STATE_IDLE:
+ seq_printf(m, Reset state\n);
+ break;
+ case EDP_PSR_STATUS_STATE_SRDONACK:
+ seq_printf(m, Wait for TG/Stream to send on frame of data
after SRD conditions are met\n);
+ break;
+ case EDP_PSR_STATUS_STATE_SRDENT:
+ seq_printf(m, SRD entry\n);
+ break;
+ case EDP_PSR_STATUS_STATE_BUFOFF:
+ seq_printf(m, Wait for buffer turn off\n);
+ break;
+ case EDP_PSR_STATUS_STATE_BUFON:
+ seq_printf(m, Wait for buffer turn on\n);
+ break;
+ case EDP_PSR_STATUS_STATE_AUXACK:
+ seq_printf(m, Wait for AUX to acknowledge on SRD
exit\n);
+ break;
+ case EDP_PSR_STATUS_STATE_SRDOFFACK:
+ seq_printf(m, Wait for TG/Stream to acknowledge the
SRD VDM exit\n);
+ break;
+ default:
+ seq_printf(m, Unknown\n);
+ break;
+ }
+
+ seq_printf(m, Link Status: );
+ switch (psrstat EDP_PSR_STATUS_LINK_MASK) {
+ case EDP_PSR_STATUS_LINK_FULL_OFF:
+ seq_printf(m, Link is fully off\n);
+ break;
+ case EDP_PSR_STATUS_LINK_FULL_ON:
+ seq_printf(m, Link is fully on\n);
+ break;
+ case EDP_PSR_STATUS_LINK_STANDBY:
+ seq_printf(m, Link is in standby\n);
+ break;
+ default:
+ seq_printf(m, Unknown\n);
+ break;
+ }
+
+ seq_printf(m, PSR Entry Count: %u\n,
+ psrstat EDP_PSR_STATUS_COUNT_SHIFT
+ EDP_PSR_STATUS_COUNT_MASK);
+
+ seq_printf(m, Max Sleep Timer Counter: %u\n,
+ psrstat EDP_PSR_STATUS_MAX_SLEEP_TIMER_SHIFT
+ EDP_PSR_STATUS_MAX_SLEEP_TIMER_MASK);
+
+ seq_printf(m, Had AUX error: %s\n,
+ yesno(psrstat EDP_PSR_STATUS_AUX_ERROR));
+
+ seq_printf(m, Sending AUX: %s\n,
+ yesno(psrstat EDP_PSR_STATUS_AUX_SENDING));
+
+ seq_printf(m, Sending Idle: %s\n,
+ yesno(psrstat EDP_PSR_STATUS_SENDING_IDLE));
+
+ seq_printf(m, Sending TP2 TP3: %s\n,
+ yesno(psrstat EDP_PSR_STATUS_SENDING_TP2_TP3));
+
+ seq_printf(m, Sending TP1: %s\n,
+ yesno(psrstat EDP_PSR_STATUS_SENDING_TP1));
+
+ seq_printf(m, Idle Count: %u\n,
+ psrstat EDP_PSR_STATUS_IDLE_MASK);
+
+ psrperf = (I915_READ(EDP_PSR_PERF_CNT)) EDP_PSR_PERF_CNT_MASK;
+ seq_printf(m, Performance Counter: %u\n, psrperf);
+
+ return 0;
+}
+
static ssize_t
i915_wedged_read(struct file *filp,
char __user *ubuf,
@@ -2249,6 +2340,7 @@ static struct drm_info_list i915_debugfs_list[] = {
{i915_swizzle_info, i915_swizzle_info, 0},
{i915_ppgtt_info, i915_ppgtt_info, 0},
{i915_dpio, i915_dpio_info, 0},
+ {i915_edp_psr_status, i915_edp_psr_status, 0},
};
#define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1e31f23..1f7e666 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1615,6 +1615,30 @@
#define EDP_PSR_STATUS_CTL 0x64840
#define EDP_PSR_STATUS_STATE_MASK(729)
+#define EDP_PSR_STATUS_STATE_IDLE(029)
+#define
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Hook PSR functionality
Hi
2013/2/25 Rodrigo Vivi rodrigo.v...@gmail.com:
PSR must be enabled after transcoder and port are running.
And it is only available for HSW.
v2: move enable/disable to intel_ddi
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/intel_ddi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 816c45c..bbfdcfd 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1321,6 +1321,7 @@ static void intel_enable_ddi(struct intel_encoder
*intel_encoder)
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
ironlake_edp_backlight_on(intel_dp);
+ intel_edp_enable_psr(intel_dp);
}
if (intel_crtc-eld_vld) {
@@ -1345,6 +1346,7 @@ static void intel_disable_ddi(struct intel_encoder
*intel_encoder)
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
ironlake_edp_backlight_off(intel_dp);
+ intel_edp_disable_psr(intel_dp);
The spec suggests PSR should be disabled even before backlight (it
also suggests audio should be disabled before backlight, and I notice
this seems to be wrong in our code).
}
tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
--
1.8.1.2
___
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 0/8] Enable eDP PSR functionality at HSW - v3
Hi 2013/2/25 Rodrigo Vivi rodrigo.v...@gmail.com: PSR is an eDP feature that allows power saving even with static image at eDP screen. v3: Accepted many suggestions that I received at v2 review, fixing, cleaning and improving the code. v2: Main differences in this v2: - Created vbt struct to get i915 dev_priv more organized and to avoid adding more stuff into it. - migrated hsw macros to use transcoder instead of pipes than I could address eDP - remove patch that was only adding edp psr registers and added them on demand v1: Shobit Kumar has implemented this patch series some time ago, but had no eDP panel with PSR capability to test them. I could test and verify that this series fully identify PSR capability and enables it at HSW. I also verified that it saves from 0.5-1W but only when in blank screen. It seems it is not really entering in sleeping mode with static image at eDP screen yet. What do you mean with blank screen? It seems we disable PSR before blanking the screen, so the 0.5-1W saving could be from the backlight. Did you try masking more bits on the SRD_DEBUG register to see if it enters PSR more easily? The first test I'd try would be to set 1 to all those mask regs and see what happens (maybe we'll enter PSR and never ever leave it again?). Please accept this series as the first part of PSR enabling while we continue working to improve its functionality. Rodrigo Vivi (5): drm/i915: Organize VBT stuff inside drm_i915_private drm/i915: Use cpu_transcoder for HSW_TVIDEO_DIP_* instead of pipe drm/i915: Enable/Disable PSR drm/i915: Added debugfs support for PSR Status drm/i915: Hook PSR functionality Shobhit Kumar (3): drm/i915: Added SDP and VSC structures for handling PSR for eDP drm/i915: Read the EDP DPCD and PSR Capability drm/i915: VBT Parsing for the PSR Feature Block for HSW drivers/gpu/drm/i915/i915_debugfs.c | 92 drivers/gpu/drm/i915/i915_dma.c | 8 +- drivers/gpu/drm/i915/i915_drv.h | 63 ++- drivers/gpu/drm/i915/i915_reg.h | 82 -- drivers/gpu/drm/i915/intel_bios.c| 126 + drivers/gpu/drm/i915/intel_bios.h| 20 +++- drivers/gpu/drm/i915/intel_crt.c | 4 +- drivers/gpu/drm/i915/intel_ddi.c | 2 + drivers/gpu/drm/i915/intel_display.c | 16 +-- drivers/gpu/drm/i915/intel_dp.c | 208 ++- drivers/gpu/drm/i915/intel_drv.h | 4 + drivers/gpu/drm/i915/intel_hdmi.c| 13 ++- drivers/gpu/drm/i915/intel_lvds.c| 20 ++-- drivers/gpu/drm/i915/intel_sdvo.c| 6 +- drivers/gpu/drm/i915/intel_tv.c | 8 +- include/drm/drm_dp_helper.h | 22 16 files changed, 569 insertions(+), 125 deletions(-) -- 1.8.1.2 ___ 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] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 6:33 PM, Paulo Zanoni przan...@gmail.com wrote:
Hi
2013/2/28 Sedat Dilek sedat.di...@gmail.com:
On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni przan...@gmail.com 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).
Do I need a specific version of intel-gpu-tools?
Ubuntu/precise has v1.2 in its archives - sufficient?
Note: The error was twice after dozenz of Linux-Next kernel builds.
- Sedat -
[1] http://packages.ubuntu.com/precise/intel-gpu-tools
Installed intel-gpu-tools.
# intel_reg_read
Usage: intel_reg_read [-f | addr]
-f : read back full range of registers.
WARNING! This could be danger to hang the machine!
addr : in 0x format
# intel_reg_read 0x44008
Couldn't map MMIO region: Resource temporarily unavailable
[ 368.281707] intel_reg_read:3657 conflicting memory types
f000-f040 uncached-minus-write-combining
[ 381.521912] intel_reg_read:3658 conflicting memory types
f000-f040 uncached-minus-write-combining
[ 401.136291] intel_reg_read:3659 conflicting memory types
f000-f040 uncached-minus-write-combining
Wrong i-g-t version? Missing enabled kernel-config option? Boot with
i915 debug enabled?
Just build the version from git and it should work
(http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/).
NO.
$ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
intel-gpu-tools-git
$ cd intel-gpu-tools-git/
$ ./autogen.sh --disable-dumper --- requires swig2.0 and python =3.x
$ sudo ./tools/intel_reg_read 0x44008
0x44008 : 0x0
$ sudo ./tools/intel_reg_read 0xC4008
0xC4008 : 0x0
$ sudo ./tools/intel_reg_dumper /tmp/intel_reg_dumper.txt --- see attachment
Does this help you?
- Sedat -
- Sedat -
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/
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
--
Paulo Zanoni
--
Paulo Zanoni
PGETBL_CTL: 0x
GEN6_INSTDONE_1: 0xfffe
GEN6_INSTDONE_2: 0x
CPU_VGACNTRL: 0x8000 (disabled)
DIGITAL_PORT_HOTPLUG_CNTRL: 0x
RR_HW_CTL: 0x (low 0, high 0)
FDI_PLL_BIOS_0: 0x
FDI_PLL_BIOS_1: 0x
FDI_PLL_BIOS_2: 0x
DISPLAY_PORT_PLL_BIOS_0: 0x
DISPLAY_PORT_PLL_BIOS_1: 0x
DISPLAY_PORT_PLL_BIOS_2: 0x
FDI_PLL_FREQ_CTL: 0x
PIPEACONF: 0xc010 (enabled, active, pf-pd, rotate 0,
8bpc)
HTOTAL_A: 0x05cd0555 (1366 active, 1486 total)
HBLANK_A: 0x05cd0555 (1366 start, 1486 end)
HSYNC_A: 0x05a50585 (1414 start, 1446 end)
VTOTAL_A: 0x031702ff (768 active, 792 total)
VBLANK_A: 0x031702ff (768 start, 792 end)
Re: [Intel-gfx] [PATCH 0/8] Enable eDP PSR functionality at HSW - v3
On Thu, Feb 28, 2013 at 02:52:32PM -0300, Paulo Zanoni wrote: Hi 2013/2/25 Rodrigo Vivi rodrigo.v...@gmail.com: PSR is an eDP feature that allows power saving even with static image at eDP screen. v3: Accepted many suggestions that I received at v2 review, fixing, cleaning and improving the code. v2: Main differences in this v2: - Created vbt struct to get i915 dev_priv more organized and to avoid adding more stuff into it. - migrated hsw macros to use transcoder instead of pipes than I could address eDP - remove patch that was only adding edp psr registers and added them on demand v1: Shobit Kumar has implemented this patch series some time ago, but had no eDP panel with PSR capability to test them. I could test and verify that this series fully identify PSR capability and enables it at HSW. I also verified that it saves from 0.5-1W but only when in blank screen. It seems it is not really entering in sleeping mode with static image at eDP screen yet. What do you mean with blank screen? It seems we disable PSR before blanking the screen, so the 0.5-1W saving could be from the backlight. Did you try masking more bits on the SRD_DEBUG register to see if it enters PSR more easily? The first test I'd try would be to set 1 to all those mask regs and see what happens (maybe we'll enter PSR and never ever leave it again?). One thing I'm wondering if we can even enable PSR w/o implementing the FBC tracking bits. I mean what happens if someone renders to the front buffer while PSR is active? -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/13] drm/i915: add reset_state for hw_contexts
On 02/28/2013 03:14 AM, Chris Wilson wrote: On Wed, Feb 27, 2013 at 05:15:08PM -0800, Ian Romanick wrote: On 02/27/2013 01:13 AM, Chris Wilson wrote: On Tue, Feb 26, 2013 at 05:47:12PM -0800, Ian Romanick wrote: On 02/26/2013 03:05 AM, Mika Kuoppala wrote: For arb-robustness, every context needs to have it's own reset state tracking. Default context will be handled in a identical way as the no-context case in further down in the patch set. For no-context case, the reset state will be stored in the file_priv part. v2: handle default context inside get_reset_state This isn't the interface we want. I already sent you the patches for Mesa, and you seem to have completely ignored them. Moreover, this interface provides no mechanism to query for its existence (other than relying on the kernel version), and no method to deprecate it. It's existence, and the existence of any successor, is the only test you need to check for the interface. Testing the flag field up front also lets you know if individual flags are known prior to use. Based on e-mail discussions, I think danvet agrees with me here. Putting guilty / innocent counting in kernel puts policy decisions in the kernel that belong with the user space API that implements them. Putting these choices in the kernel significantly decreases how future proof the interface is. Since any kernel/user interface has to be kept forever, this is just asking for maintenance trouble down the road. I think you have the policy standpoint reversed. Can you elaborate? I've been out of the kernel loop for a long time, but I always thought policy and mechanism were supposed to be separated. In the case of drivers with a user-mode component, the mechanism was in the kernel (where else could it be?), and policy decisions were in user-mode. This is often at odds with keeping the interfaces between kernel and user thin, so that may be where my misunderstanding is. Right, the idea is to keep policy out of the kernel. I disagree that your suggestion succeeds in doing this. I was trying to put the mechanism for determining what things happened in the kernel and the policy for interpreting what those things mean in user-mode. Ignoring some bugs / misimplementation in my patch (which I try to address below), I thought I was doing that. User-mode gets some information about the state it was in when the reset occurred. It then uses that state to decide the value to return to the application for glGetGraphicsResetStatusARB. After reading the bits below where I talk about other problems in the kernel code I posted, maybe you can address specific ways my proposal fails. I want any glaring interface deficiencies fixed before any code goes in the kernel... I fully understand the pain, on both sides, of shipping a kernel interface only to have to replace it in a year. [snip to details] There are two requirements in the ARB_robustness extension (and additional layered extensions) that I believe cause problems with all of the proposed counting interfaces. 1. GL contexts that are not affected by a reset (i.e., didn't lose any objects, didn't lose any rendering, etc.) should not observe it. This is the big one that all the browser vendors want. If you have 5 tabs open, a reset caused by a malicious WebGL app in one tab shouldn't, if possible, force them to rebuild all of their state for all the other tabs. 2. After a GL context observes a reset, it is garbage. It must be destroyed and a new one created. This means we only need to know that a reset of any variety affected the context. For me observes implies the ability for the context to inspect global system state, whereas I think you mean if the context and its associated state is affected by a reset. I had thought about explicitly defining what I meant by a couple terms in my previous e-mail, but it was already getting quite long. I guess I should have. :( Here's what I meant: A. Affect the context means the reset causes the context to lose some data. It may be rendering that was queued (so framebuffer data is lost), it may be the contents of a buffer, or it may be something else. Either way, the state of some data is not what the application expects it to be because of the reset. B. Observe the reset means the GL context gets some data to know that the reset happened. From the application point of view, this means glGetGraphicsResetStatusARB returns a value other than GL_NO_ERROR. What I was trying the describe in point 1 in my previous message (above) is that B should occur if and only if A occurs. Once B occurs, the application has to create a new context... recompile all of its shaders, reload all of its textures, reload all of its vertex data, etc. We don't want to make apps do that any more often than absolutely necessary. In addition, I'm concerned about having one GL context be able to observe, in any manner, resets that did not affect it. Given that
