I'll try to do this early next week, and report back.
On Fri, Aug 10, 2012 at 7:37 PM, Ben Widawsky wrote:
> On 2012-08-10 09:25, Ben Guthro wrote:
>>
>> Hello, I've been attempting to get a Shark Bay / Haswell platform up &
>> running, and have been having some difficulties that I'm hoping you
On 2012-08-10 09:25, Ben Guthro wrote:
Hello, I've been attempting to get a Shark Bay / Haswell platform up
&
running, and have been having some difficulties that I'm hoping you
all can possibly help with.
I first tried the 3.5 kernel, and had some success after applying the
following patch:
ht
On Thu, 9 Aug 2012 22:33:58 +0200, Daniel Vetter
wrote:
> Since forcewake is now protected by a spinlock, we don't need to grab
> dev->struct_mutex any more. This way we can also get rid of a stale
> comment, noticed by Ben Widawsky while reviewing some locking changes.
>
> Signed-off-by: Danie
Seems like I am a bit late for the party :)
I can also confirm that
[PATCH] drm/i915: Apply post-sync write for pipe control invalidates
works.
Tested-by: Bernhard Froemel
Thanks Daniel!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http:
well...it gave me a different stack...but still no graphics:
This is with the drm-intel-fixes branch merged in - I thought that
branch might help...but it didn't seem to.
[ 16.615950] [ cut here ]
[ 16.621229] WARNING: at
/data/home/bguthro/dev/newdev-tip/linux-3.2/dr
On Fri, Aug 10, 2012 at 06:49:03PM +0200, Bernhard Froemel wrote:
> Hello Daniel and Francois,
>
> apologies for posting 'out of thread'.
>
> > Can you please re-grab the
> > dumps?
> http://luna.vmars.tuwien.ac.at/~froemel/ird_noi915.txt
> http://luna.vmars.tuwien.ac.at/~froemel/ird_i915.txt
> h
On Fri, Aug 10, 2012 at 12:51:42PM -0400, Ben Guthro wrote:
> specifically, I get the following in my serial console - it is a
> warning...but seems to coincide with when standard vesa modes are
> switching over to the higer res KMS modes:
Can you try to boot with i915.i915_enable_rc6=0 please?
-D
specifically, I get the following in my serial console - it is a
warning...but seems to coincide with when standard vesa modes are
switching over to the higer res KMS modes:
[ 15.889193] [drm:__gen6_gt_force_wake_mt_get] *ERROR* Force wake
wait timed out
[ 15.897707] [drm] Supports vblank time
Hello Daniel and Francois,
apologies for posting 'out of thread'.
> Can you please re-grab the
> dumps?
http://luna.vmars.tuwien.ac.at/~froemel/ird_noi915.txt
http://luna.vmars.tuwien.ac.at/~froemel/ird_i915.txt
http://luna.vmars.tuwien.ac.at/~froemel/ird_i915_pC.txt (short freeze,
screen looks f
On Fri, Aug 10, 2012 at 04:18:45PM +0300, Jani Nikula wrote:
> On Fri, 10 Aug 2012, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > If we don't find the exact refresh rate, go with the next one. This
> > makes some modes work for me. They won't have the best settings, but
> > will at least hav
On Fri, Aug 10, 2012 at 04:27:23PM +0300, Jani Nikula wrote:
> On Fri, 10 Aug 2012, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > - intel_encoder->type is INTEL_OUTPUT_SOMETHING
> > - drm_encoder->encoder_type is DRM_MODE_ENCODER_SOMETHING
> >
> > Here we're using intel_encoder, so compa
Hello, I've been attempting to get a Shark Bay / Haswell platform up &
running, and have been having some difficulties that I'm hoping you
all can possibly help with.
I first tried the 3.5 kernel, and had some success after applying the
following patch:
https://patchwork.kernel.org/patch/1229541/
HI Deak,
> -Original Message-
> From: Imre Deak [mailto:imre.d...@gmail.com]
> Sent: Friday, August 10, 2012 9:15 PM
> To: Wang, Xingchao
> Cc: dan...@ffwll.ch; przan...@gmail.com; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 3/4] drm/i915: Haswell HDMI audio
> init
Hi,
I am having an issue with a new Dell E5520 laptop (Intel(R) Core(TM) i5-2520 CPU
@ 2.5GHz) running Linux Mint 13 (Kernel: Linux 3.2.0-23-generic (i686)). I am
using the graphics driver that ships with the kernel:
00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core
On Fri, 10 Aug 2012, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> - intel_encoder->type is INTEL_OUTPUT_SOMETHING
> - drm_encoder->encoder_type is DRM_MODE_ENCODER_SOMETHING
>
> Here we're using intel_encoder, so compare the oranges against
> oranges. While at it, rename the variable to "inte
On Fri, 10 Aug 2012, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If we don't find the exact refresh rate, go with the next one. This
> makes some modes work for me. They won't have the best settings, but
> will at least have something. Just returning from this function when
> we don't find the p
Hi,
couple of comments inlined:
On Thu, Aug 9, 2012 at 11:52 AM, Wang Xingchao wrote:
> Added new haswell_write_eld() to initialize Haswell HDMI audio registers
> to generate an unsolicited response to the audio controller driver to
> indicate that the controller sequence should start.
>
> Signe
From: Paulo Zanoni
- intel_encoder->type is INTEL_OUTPUT_SOMETHING
- drm_encoder->encoder_type is DRM_MODE_ENCODER_SOMETHING
Here we're using intel_encoder, so compare the oranges against
oranges. While at it, rename the variable to "intel_encoder" so we
keep our naming standards used everyw
From: Paulo Zanoni
If we don't find the exact refresh rate, go with the next one. This
makes some modes work for me. They won't have the best settings, but
will at least have something. Just returning from this function when
we don't find the perfect settings does not help us at all.
Version 2:
On Tue, Jul 31, 2012 at 07:23:18AM -0700, Greg KH wrote:
> On Tue, Jul 31, 2012 at 09:17:15AM +, Xu, Anhua wrote:
> > Thanks Chris. I add this in the the commit description. The updated patch
> > is below:
> >
> > commit 71c3ff04834a01c81a5843996b87397273eb538d
> > Author: Xu Anhua
> > Date
On Fri, 10 Aug 2012, Chris Wilson wrote:
> On Fri, 10 Aug 2012 12:57:59 +0300, Jani Nikula
> wrote:
>> On Fri, 10 Aug 2012, Chris Wilson wrote:
>> > When invalidating the TLBs it is documentated as requiring a post-sync
>> > write. Failure to do so seems to result in a GPU hang.
>> >
>> > Expos
After three moths development, Im pleased to release glamor version 0.5.0.
The major improvements
are as below:
1. Support tiling large pixmap to multiple small textures.
2. Enable gradient shader.
3. Optimize glyphs rendering performance
4. Implement first shader t
Hello,
I confirm this patch work apply to kernel 3.6-rc1
Best regards
On 10/08/2012 11:10, Daniel Vetter wrote:
> This has originally been introduced to not oversubscribe the dp links
> in
>
> commit 885a5fb5b120a5c7e0b3baad7b0feb5a89f76c18
> Author: Zhenyu Wang
> Date: Tue Jan 12 05:38:31
On Fri, 10 Aug 2012 11:07:47 +0100, Chris Wilson
wrote:
> On Fri, 10 Aug 2012 12:57:59 +0300, Jani Nikula
> wrote:
> > On Fri, 10 Aug 2012, Chris Wilson wrote:
> > > When invalidating the TLBs it is documentated as requiring a post-sync
> > > write. Failure to do so seems to result in a GPU ha
On Fri, 10 Aug 2012 12:57:59 +0300, Jani Nikula
wrote:
> On Fri, 10 Aug 2012, Chris Wilson wrote:
> > When invalidating the TLBs it is documentated as requiring a post-sync
> > write. Failure to do so seems to result in a GPU hang.
> >
> > Exposure to this hang on IVB seems to be a result of rem
On Fri, 10 Aug 2012, Chris Wilson wrote:
> When invalidating the TLBs it is documentated as requiring a post-sync
> write. Failure to do so seems to result in a GPU hang.
>
> Exposure to this hang on IVB seems to be a result of removing the extra
> stalls required for SNB pipecontrol workarounds:
On Thu, Aug 09, 2012 at 12:29:16PM +0200, Daniel Vetter wrote:
> On Thu, Aug 09, 2012 at 10:58:30AM +0100, Chris Wilson wrote:
> > Avoid the forcewake overhead when simply retiring requests, as often the
> > last seen seqno is good enough to satisfy the retirment process and will
> > be promptly re
When invalidating the TLBs it is documentated as requiring a post-sync
write. Failure to do so seems to result in a GPU hang.
Exposure to this hang on IVB seems to be a result of removing the extra
stalls required for SNB pipecontrol workarounds:
commit 6c6cf5aa9c583478b19e23149feaa92d01fb8c2d
Au
This has originally been introduced to not oversubscribe the dp links
in
commit 885a5fb5b120a5c7e0b3baad7b0feb5a89f76c18
Author: Zhenyu Wang
Date: Tue Jan 12 05:38:31 2010 +0800
drm/i915: fix pixel color depth setting on eDP
Since then we've fixed up the dp link bandwidth calculation code
When invalidating the TLBs it is documentated as requiring a post-sync
write. Failure to do so seems to result in a GPU hang.
Reported-by: yex.t...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53322
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 3
30 matches
Mail list logo
