On Mon, Oct 17, 2011 at 01:45:28PM +0200, Dieter Mummenschanz wrote:
Hi Daniel,
first of all I've seemed to screwed up my rc6 kernel parameters causing
rc6 to be enabled in all my previous tests even though I thought it was
disbaled. Sorry for that! Some new tests with i915_enable_rc6
On Mon, Oct 17, 2011 at 01:58:03PM +0200, Daniel Vetter wrote:
On Mon, Oct 17, 2011 at 01:45:28PM +0200, Dieter Mummenschanz wrote:
Hi Daniel,
first of all I've seemed to screwed up my rc6 kernel parameters causing
rc6 to be enabled in all my previous tests even though I thought it was
Hi Daniel,
no problem. dmesg.log attached.
To reproduce the hang: try to play two or more bluray streams at once and
probably a hires wmv stream as well using mplayer-vaapi. also run a opengl game
like Quake3 or prboom-plus (http://prboom-plus.sourceforge.net). You'll need an
additional pwad
Hi,
I already did. Either the stream is too short or the low bitrate doesn't cause
enough rc6 state changes :-(.
Regards,
Dieter
Original-Nachricht
Datum: Mon, 17 Oct 2011 14:13:34 +0200
Von: Gwenole Beauchesne gb.de...@gmail.com
An: Daniel Vetter dan...@ffwll.ch
CC:
Those are two identical fixes for improving EDID detection timings, which
also fix extremely slow xrandr queries in case of phantom outputs
(https://bugs.freedesktop.org/show_bug.cgi?id=41059)
The first fix is a small change to drm_edid, which prevents it from talking to
non-existent adapters by
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.
As the advantage of such change, all the other routines which use
drm_get_edid would benefit for this timeout.
This adds a new function intel_drm_get_valid_edid, which attempts to detect
EDID values from available devices and returns quickly in case no connection
is present. We detect non-existing devices by checking the i2c_transfer
status, and if it fails with the -ENXIO result, we know that the
On Mon, Oct 17, 2011 at 02:37:21PM +0200, Dieter Mummenschanz wrote:
Hi Daniel,
no problem. dmesg.log attached.
To reproduce the hang: try to play two or more bluray streams at once
and probably a hires wmv stream as well using mplayer-vaapi. also run a
opengl game like Quake3 or
Hi Daniel,
I believe I tried that already but I'll give it another shot. To avoid another
screw up: Can I check in proc or sysfs to see, if iommu is really disabled? I
also have pcie_aspm=force set as kernel parameter to save some watts but it
does not seem to contribute to the gpu hangs.
On Mon, Oct 17, 2011 at 03:54:03PM +0200, Dieter Mummenschanz wrote:
Hi Daniel,
I believe I tried that already but I'll give it another shot. To avoid
another screw up: Can I check in proc or sysfs to see, if iommu is
really disabled? I also have pcie_aspm=force set as kernel parameter to
Hi Daniel,
something is odd with your git branch - or my git command:
git clone git://freedesktop.org/~danvet/libva-intel for-dieter
Cloning into for-dieter...
remote: Counting objects: 1632, done.
remote: Compressing objects: 100% (447/447), done.
remote: Total 1632 (delta 1174), reused 1632
2011/10/13 Eric Anholt e...@anholt.net:
---
I kept reviewing the B-Spec on systems with weird issues and
hand-decoding each interesting register (for example, is everything
still sane after resume?), so here's a tool to do so automatically.
tools/Makefile.am | 1 +
On Mon, Oct 17, 2011 at 05:13:02PM +0200, Dieter Mummenschanz wrote:
Hi Daniel,
something is odd with your git branch - or my git command:
It's a headless git repo with just branches. Go into your existing intel
libva driver checkout, create a new branch and merge in my stuff with
git pull
On Thu, 22 Sep 2011 11:16:00 +0530
Jesse Barnes jbar...@virtuousgeek.org wrote:
Misc fixes based on tests with an infoframe analyzer:
- checksum *does* include header bytes
- DIP enable AVI infoframe are tied together in hw, so disable both
and make sure AVI frames are enabled first
On Thu, 22 Sep 2011 11:16:01 +0530
Jesse Barnes jbar...@virtuousgeek.org wrote:
SPD frames are actually type 0x83, not just 0x3.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Another one for -fixes.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
On Thu, 22 Sep 2011 20:29:09 +0530
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Thu, 22 Sep 2011 09:41:01 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, 22 Sep 2011 11:15:58 +0530, Jesse Barnes
jbar...@virtuousgeek.org wrote:
Read link status first, followed by the full
Hi Daniel,
ok I did a git clone git://anongit.freedesktop.org/libva (hope this is the
right one?) and in the libva checkout I issued:
git pull git://freedesktop.org/~danvet/libva-intel for-dieter
warning: no common commits
remote: Counting objects: 1632, done.
remote: Compressing objects:
This adds a hint on where the call trace originated from. This is more of
a guess, but still, it seems to be quite accurate on the traces I tested.
So it appears in the output like:
...
0x06c470c8: 0x780e0002: 3DSTATE_CC_STATE_POINTERS
0x06c470cc: 0x7f81:blend change 1
On Fri, 2011-10-14 at 23:11 -0700, Keith Packard wrote:
On Fri, 14 Oct 2011 12:43:49 -0400, Adam Jackson a...@redhat.com wrote:
The previous code was confused about units, which is pretty reasonable
given that the units themselves are confusing.
Thanks for actually figuring this out; the
On Fri, 14 Oct 2011 17:22:26 -0400
Adam Jackson a...@redhat.com wrote:
According to the gen6 docs, only the DP_A port (on-CPU eDP) still uses
the old IBX bit shift for the link training pattern setup bits.
Signed-off-by: Adam Jackson a...@redhat.com
---
Looks good. Wish I had a test
On Mon, Oct 17, 2011 at 02:25:01PM -0200, Eugeni Dodonov wrote:
This adds a hint on where the call trace originated from. This is more of
a guess, but still, it seems to be quite accurate on the traces I tested.
So it appears in the output like:
...
0x06c470c8: 0x780e0002:
On Mon, Oct 17, 2011 at 15:10, Ben Widawsky b...@bwidawsk.net wrote:
On Mon, Oct 17, 2011 at 02:25:01PM -0200, Eugeni Dodonov wrote:
This adds a hint on where the call trace originated from. This is more of
a guess, but still, it seems to be quite accurate on the traces I tested.
So it
On Tue, 2011-10-11 at 10:45 -0700, Jesse Barnes wrote:
At the point where we check, we can't do much about the failure, but it
can aid debugging. Note that the auto-train override bit will be reset
as part of normal mode setting with this patch if a pipe ever does get
stuck, but that's
2011/10/14 Chris Wilson ch...@chris-wilson.co.uk:
I'm a little more dubious over the value of this patch. The extra
information is nice, but the patch doesn't impact much upon the
readibility of the code. It seems like this should have the potential to
clarify quite a bit of the logic and make
On Mon, 17 Oct 2011 13:37:54 -0200, Paulo Zanoni przan...@gmail.com wrote:
2011/10/13 Eric Anholt e...@anholt.net:
---
I kept reviewing the B-Spec on systems with weird issues and
hand-decoding each interesting register (for example, is everything
still sane after resume?), so here's a
This adds a hint on where the call trace originated from with a helper
macro GUESS_ORIGIN. As its name says, it is more of a guess, but still, it
seems to be quite accurate on most of the traces.
The results of the heuristics are printed at the end of the decoding:
...
0x00062fe8:
On Mon, 2011-10-17 at 08:53 -0700, Jesse Barnes wrote:
Sorry Keith, should have cc'd you on the other two replies to this
thread as well.
This one is mainly increasing the size of the DPCD array we use so that
we read all the cap bytes instead of just the first 8. This makes some
sinks
Hi,
Unfortunately I won't be at the next graphics call, but below is a list
of the bugs we've forwarded upstream from Ubuntu Oneiric for your
reference.
A few of these are blocked waiting for feedback from the reporter; not
sure what to do with those. Several of the GPU lockup bugs likely are
On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov eug...@dodonov.net wrote:
From what I've checked, the other return error value in this context could
be -EREMOTEIO, which could be caused by transmission error so it should be
retried.
Oh, there's -ENOMEM, -EINVAL and probably a few others
On Mon, 17 Oct 2011 13:03:02 -0400, Adam Jackson a...@redhat.com wrote:
[drm:drm_mode_debug_printmodeline], Modeline 28: 0 154000 1920 1968 2000
2080 1200 1203 1209 1235 0x0 0x9
[drm:intel_dp_mode_fixup], Display port link bw 0a lane count 2 clock
27
Ok, nice to see that you've actually
I think Daniel caved in and agrees that making the idle cause the GPU to
be uninterruptible was the correct approach. So this patch is pretty
much the same as v3, except it has David's new global to determine the
IOMMU status. In other words, disregard v4.
For the series:
Tested-by: Ben Widawsky
From: David Woodhouse dw...@infradead.org
To work around a hardware issue, we have to submit IOTLB flushes while
the graphics engine is idle. The graphics driver will (we hope) go to
great lengths to ensure that it gets that right on the affected
chipset(s)... so let's not screw it over by
From: David Woodhouse david.woodho...@intel.com
We really don't want this to work in the general case; device drivers
*shouldn't* care whether they are behind an IOMMU or not. But the
integrated graphics is a special case, because the IOMMU and the GTT are
all kind of smashed into one and
[Description from: Daniel Vetter]
I've just discussed this quickly with Chris on irc and it's probably
best to just kill the list_empty early bailout. gpu_idle isn't a
fastpath, so who cares. One candidate where we emit commands to the ring
without adding anything onto these lists is e.g.
On Mon, Oct 17, 2011 at 18:15, Eric Anholt e...@anholt.net wrote:
On Mon, 17 Oct 2011 13:37:54 -0200, Paulo Zanoni przan...@gmail.com
wrote:
2011/10/13 Eric Anholt e...@anholt.net:
---
I kept reviewing the B-Spec on systems with weird issues and
hand-decoding each interesting
35 matches
Mail list logo
