On Sun, Sep 9, 2012 at 5:00 PM, Daniel Vetter wrote:
>
> We need two special things to properly wire this up:
> - Add another argument to gmbus_wait_hw_status to pass in the
> correct interrupt bit in gmbus4.
> - Since we can only get an irq for one of the two events we want,
> hand-roll the w
I also experience tearing when viewing web sites with chromium and
scrolling downwards webnewspapers etc.
Hope this adds more relevant info.
On Sun, Sep 9, 2012 at 8:00 PM, Chris Wilson wrote:
> On Sun, 09 Sep 2012 10:55:46 -0700, Ben Widawsky wrote:
>> On 2012-09-09 08:48, Roberth Sjonøy wrote
Hello
What can I do then?
Wait for SNA to mature more?
Other settings with UXA or SNA?
Regards
Roberth Sjonøy
On Sun, Sep 9, 2012 at 8:00 PM, Chris Wilson wrote:
> On Sun, 09 Sep 2012 10:55:46 -0700, Ben Widawsky wrote:
>> On 2012-09-09 08:48, Roberth Sjonøy wrote:
>> > Hello
>> >
>> > I ru
On Sun, 9 Sep 2012 12:42:55 -0700
Ben Widawsky wrote:
> On the Intel driver we've developed and reviewed some patches which
> enable GPU frequency settings in sysfs. Similar interfaces have
> existed for some time in our debugfs, but now we're getting interest
> from users like PowerTOP and have
On the Intel driver we've developed and reviewed some patches which
enable GPU frequency settings in sysfs. Similar interfaces have existed
for some time in our debugfs, but now we're getting interest from users
like PowerTOP and have decided to formalize it. Most likely other DRM
drivers have simi
This has been tons of fun to figure out with git blame. The first
notion of this code block goes back to the original cpu edp enabling
for ilk in
commit 32f9d658aee5be09ebdd28fc730630e61d0b46db
Author: Zhenyu Wang
Date: Fri Jul 24 01:00:32 2009 +0800
drm/i915: Add eDP support on IGDNG mobi
On Fri, 7 Sep 2012 19:43:41 -0700, Ben Widawsky wrote:
> In order to keep our cached values in sync with the hardware, we need a
> posting read here.
>
> CC: Chris Wilson
> Signed-off-by: Ben Widawsky
Yes, a POSTING_READ does look required here.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wi
On Fri, 7 Sep 2012 19:43:42 -0700, Ben Widawsky wrote:
> With the new "standardized" sysfs interfaces we need to be a bit more
> careful about setting the RPS values.
>
> Because the sysfs code and the rps workqueue can run at the same time,
> if the sysfs setter wins the race to the mutex, the
Dear list,
I've previously had an issue with my Dell Laptop (Latitude E5520) which
has a i915 graphics card on a Sandy Bridge (2011-12-13 "Fan running with
Intel Graphics"). The fan was running because apparently the GPU was not
going into powersave mode.
Now, by sheer stupidity on my part, I've
On Sun, 09 Sep 2012 10:55:46 -0700, Ben Widawsky wrote:
> On 2012-09-09 08:48, Roberth Sjonøy wrote:
> > Hello
> >
> > I run Arch Linux, with it's latest x.org and kernel, and I have
> > compiled libdrm and the intel driver from git, and I update it today.
> >
> > Buit this is issue exists even w
On 2012-09-09 08:48, Roberth Sjonøy wrote:
Hello
I run Arch Linux, with it's latest x.org and kernel, and I have
compiled libdrm and the intel driver from git, and I update it today.
Buit this is issue exists even with the releases.
WIth UXA, rendering of the windows in my XFCE4-desktop goes j
On 2012-09-09 02:50, Daniel Vetter wrote:
On Sun, Sep 9, 2012 at 3:59 AM, Ben Widawsky
wrote:
On 2012-09-06 06:43, Daniel Vetter wrote:
Otherwise the new&shiny irq-driven gmbus and dp aux code won't work
that
well. Noticed since the dp aux code doesn't have an automatic
fallback
with a tim
-- Forwarded message --
From: Roberth Sjonøy
Date: Sun, Sep 9, 2012 at 6:52 PM
Subject: Re: [Intel-gfx] Fighting tearing
To: Paul Menzel
Tested with SNA. tearing is gone, but the performance of rendering
windows in totally unacceptable.
Regards,
Roberth Sjonøy
On Sun, Sep 9,
-- Forwarded message --
From: Roberth Sjonøy
Date: Sun, Sep 9, 2012 at 6:48 PM
Subject: Re: [Intel-gfx] Fighting tearing
To: Paul Menzel
On Sun, Sep 9, 2012 at 6:42 PM, Paul Menzel
wrote:
> Dear Roberth,
>
>
> Am Sonntag, den 09.09.2012, 17:48 +0200 schrieb Roberth Sjonøy:
>
>>
Dear Roberth,
Am Sonntag, den 09.09.2012, 17:48 +0200 schrieb Roberth Sjonøy:
> I run Arch Linux, with it's latest x.org and kernel,
that is xorg-server 1.12.4-1 [1] and linux 3.5.3-1 [2].
> and I have compiled libdrm and the intel driver from git, and I update
> it today.
Please provide the
Hello
I run Arch Linux, with it's latest x.org and kernel, and I have
compiled libdrm and the intel driver from git, and I update it today.
Buit this is issue exists even with the releases.
WIth UXA, rendering of the windows in my XFCE4-desktop goes just
fines, good performance, windows (exspeci
Less clutter in the traces. And in both cases we yell rather loud
into the logs if we time out. Patch suggested by Chris Wilson.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_i2c.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
On Sun, 9 Sep 2012 11:29:24 +0200, Daniel Vetter
wrote:
> At least on the platforms that have a dp aux irq and also have it
> enabled - vlv/hsw should have one, too. But I don't have a machine to
> test this on, and the current code doesn't support dp yet anyway on
> those platforms. Judging fro
On Sun, 9 Sep 2012 11:54:16 +0200, Daniel Vetter
wrote:
> Currently we've only frobbed this bit at irq_init time, but did
> not restore it at resume time. Move it to the gen3 clock gating
> function to fix this.
>
> Notice while reading through code.
>
> Cc: sta...@vger.kernel.org (for 3.5 onl
Currently we've only frobbed this bit at irq_init time, but did
not restore it at resume time. Move it to the gen3 clock gating
function to fix this.
Notice while reading through code.
Cc: sta...@vger.kernel.org (for 3.5 only)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 3
At least on the platforms that have a dp aux irq and also have it
enabled - vlv/hsw should have one, too. But I don't have a machine to
test this on, and the current code doesn't support dp yet anyway on
those platforms. Judging from docs there's no dp aux interrupt for gm45.
Also, I only have an
Hi All,
New -testing cycle. Highlights from this -next:
- New modeset code framework.
- Tiny fix in the fb helper to go through the official dpms interface
instead of calling the crtc helper code.
- forcewake code frobbery from Ben, code should be more in-line with what
Windows does now.
- fix
At least on the platforms that have a dp aux irq and also have it
enabled - vlv/hsw should have one, too. But I don't have a machine to
test this on, and the current code doesn't support dp yet anyway on
those platforms. Judging from docs there's no dp aux interrupt for gm45.
Also, I only have an
Doesn't do anything yet than call dp_aux_irq_handler.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f836e89
The same optimization has already been applied to the ivb irq handler in
commit 0e43406bcc1868a316eea6012a0a09d992c53521
Author: Chris Wilson
Date: Wed May 9 21:45:44 2012 +0100
drm/i915: Simplify interrupt processing for IvyBridge
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i
GMBUS_ACTIVE has inverted sense and so doesn't fit into the
wait_hw_status helper, hence create a new gmbus_wait_idle functions.
Also, we only care about the idle irq event and nothing else, which
allows us to use the wait_event_timeout helper directly without
jumping through hoops to catch NAKs.
We need two special things to properly wire this up:
- Add another argument to gmbus_wait_hw_status to pass in the
correct interrupt bit in gmbus4.
- Since we can only get an irq for one of the two events we want,
hand-roll the wait_event_timeout code so that we wake up every
jiffie and can c
Only enables the interrupt and puts a irq handler into place, doesn't
do anything yet.
Unfortunately there's no gmbus interrupt support for gen2/3 (safe for
pnv, but there the irq is marked as "Test mode").
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 18 ++
The gmbus interrupt generation is rather fiddly: We can only ever
enable one interrupt source (but we always want to check for NAK
in addition to the real bit). And the bits in the gmbus status
register don't map at all to the bis in the irq register.
To prepare for this mess, start by extracting
Otherwise the new&shiny irq-driven gmbus and dp aux code won't work that
well. Noticed since the dp aux code doesn't have an automatic fallback
with a timeout (since the hw provides for that already).
v2: Simple move drm_irq_install before intel_modeset_gem_init, as
suggested by Ben Widawsky.
Sig
On Sun, Sep 9, 2012 at 3:59 AM, Ben Widawsky wrote:
> On 2012-09-06 06:43, Daniel Vetter wrote:
>>
>> Otherwise the new&shiny irq-driven gmbus and dp aux code won't work that
>> well. Noticed since the dp aux code doesn't have an automatic fallback
>> with a timeout (since the hw provides for that
31 matches
Mail list logo
