On Tue, Jan 22, 2013 at 03:42:14PM -0800, Ben Widawsky wrote:
> On Tue, 22 Jan 2013 15:33:27 +0100
> daniel.vet...@ffwll.ch wrote:
>
> > From: Daniel Vetter
> >
> > commit 09153000b8ca32a539a1207edebabd0d40b6c61b
> > Author: Daniel Vetter
> > Date: Wed Dec 12 14:06:44 2012 +0100
> >
> >
On Tue, 22 Jan 2013 15:33:27 +0100
daniel.vet...@ffwll.ch wrote:
> From: Daniel Vetter
>
> commit 09153000b8ca32a539a1207edebabd0d40b6c61b
> Author: Daniel Vetter
> Date: Wed Dec 12 14:06:44 2012 +0100
>
> drm/i915: rework locking for intel_dpio|sbi_read|write
>
> reworked the locking a
On Mon, Jan 21, 2013 at 01:03:48PM -0600, David Woodhouse wrote:
> On Sun, 2013-01-20 at 23:50 +0100, Daniel Vetter wrote:
> > DMAR support on g4x/gm45 integrated gpus seems to be totally busted.
> > So don't bother, but instead disable it by default to allow distros to
> > unconditionally enable D
From: Daniel Vetter
commit 09153000b8ca32a539a1207edebabd0d40b6c61b
Author: Daniel Vetter
Date: Wed Dec 12 14:06:44 2012 +0100
drm/i915: rework locking for intel_dpio|sbi_read|write
reworked the locking around sbi_read/write functions for 3.8-fixes.
But
commit dde86e2db54545ef981b648050
On Tue, Jan 22, 2013 at 8:44 PM, Karsten Nielsen wrote:
> Hi,
>
> I am just curios is there anyone that has any suggestions as to what might be
> wrong ?
I've looked at your video and logs, but didn't have an immediate idea.
Can you please file a bug for this at bugs.freedesktop.org against DRI
Hi,
I am just curios is there anyone that has any suggestions as to what might be
wrong ?
Thanks,
Karsten
-Original message-
From: Karsten Nielsen
Sent: Fri 21-12-2012 10:52
Subject:Re: [Intel-gfx] Intel HD 4000 and Sunix DPD2000 scrolling screen
To: Daniel Vetter ;
CC
On Tue, Jan 22, 2013 at 11:25:25PM +0800, Wang Xingchao wrote:
> ELD info should be updated dynamically according to hot plug event.
> For haswell chip, clear/set the eld valid bit and output enable bit
> from callback intel_disable/eanble_ddi().
>
> Reviewed-by: Ville Syrjälä
> Reviewed-by: Rodr
Thanks for your testing. Can you give me any hints why the performance is so
bad on my System?
I'm using openSUSE 12.2, Mesa 9.0.1, the latest xf86-video-intel and Kernel
3.7.3
Am Dienstag, 22. Januar 2013 schrieb Zhang, Xiong Y :
> Using the latest mesa master tree, I test it on my Core i7-260
On Mon, 2013-01-21 at 19:48 +0100, Daniel Vetter wrote:
> We already have the quirk entry for the mobile platform, but also
> reports on some desktop versions. So be paranoid and set it
> everywhere.
>
> References:
> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg33138.html
> Cc:
On Tue, Jan 22, 2013 at 7:15 PM, Mihai Moldovan wrote:
> * On 21.01.2013 07:11 PM, Mihai Moldovan wrote:
>> I'm also currently testing a kernel without the Intel IOMMU feature
>> [CONFIG_INTEL_IOMMU=n, but CONFIG_IOMMU_SUPPORT=y]. [...] At least
>> not seeing USB and PCI(e) issues. I'll leave the
* On 21.01.2013 07:11 PM, Mihai Moldovan wrote:
> I'm also currently testing a kernel without the Intel IOMMU feature
> [CONFIG_INTEL_IOMMU=n, but CONFIG_IOMMU_SUPPORT=y]. [...] At least
> not seeing USB and PCI(e) issues. I'll leave the box running for some
> more [time] [...]
No freezes for >22h
ELD info should be updated dynamically according to hot plug event.
For haswell chip, clear/set the eld valid bit and output enable bit
from callback intel_disable/eanble_ddi().
Reviewed-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
Signed-off-by: Wang Xingchao
---
drivers/gpu/drm/i915/intel_ddi
On Tue, Jan 22, 2013 at 02:48:29PM +0100, Daniel Vetter wrote:
> On Tue, Jan 22, 2013 at 2:22 PM, Egbert Eich wrote:
>
> Hm, I've thought the hw supports short dp pulses on eDP port A in case
> the panel needs our attention, but maybe I've mixed that up with the
> dp aux irq for port A. In any ca
On Fri, Jan 18, 2013 at 06:29:05PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The current code was wrong in many different ways, so this is a full
> rewrite. We don't have "different power wells for different parts of
> the GPU", we have a single power well, but we have multiple register
On Tue, Jan 22, 2013 at 02:04:09PM +0100, Daniel Vetter wrote:
> On Mon, Jan 21, 2013 at 03:45:48PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 18, 2013 at 06:29:08PM -0200, Paulo Zanoni wrote:
> > > From: Paulo Zanoni
> > >
> > > If the power well is disabled, we should not try to read its
> > >
On Tue, Jan 22, 2013 at 2:22 PM, Egbert Eich wrote:
> On Thu, Jan 17, 2013 at 03:45:26PM +0100, Daniel Vetter wrote:
>> On Thu, Jan 17, 2013 at 03:01:06PM +0100, Egbert Eich wrote:
>> > Hi Daniel,
>> >
>> > On Fri, Jan 11, 2013 at 09:34:08PM +0100, Daniel Vetter wrote:
>> > >
>> > > Nice work, and
On Tue, Jan 22, 2013 at 02:02:26PM +0100, Daniel Vetter wrote:
> On Mon, Jan 21, 2013 at 03:37:42PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 18, 2013 at 06:29:05PM -0200, Paulo Zanoni wrote:
> > > From: Paulo Zanoni
> > >
> > > The current code was wrong in many different ways, so this is a fu
Hi Daniel,
I've played around a bit now, and implemented your suggestions:
On Thu, Jan 17, 2013 at 03:45:26PM +0100, Daniel Vetter wrote:
> On Thu, Jan 17, 2013 at 03:01:06PM +0100, Egbert Eich wrote:
> > Hi Daniel,
> >
> > On Fri, Jan 11, 2013 at 09:34:08PM +0100, Daniel Vetter wrote:
> > >
>
On Mon, Jan 21, 2013 at 03:45:48PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 18, 2013 at 06:29:08PM -0200, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > If the power well is disabled, we should not try to read its
> > registers, otherwise we'll get "unclaimed register" messages.
> >
> > Sig
On Mon, Jan 21, 2013 at 03:37:42PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 18, 2013 at 06:29:05PM -0200, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > The current code was wrong in many different ways, so this is a full
> > rewrite. We don't have "different power wells for different parts
On Tue, Jan 22, 2013 at 12:28:16PM +, Chris Wilson wrote:
> On Tue, Jan 22, 2013 at 02:12:17PM +0200, Mika Kuoppala wrote:
> > When machine was rebooted or module was reloaded,
> > gem_hw_init() set last_seqno to be identical to next_seqno.
> > This lead to situation that waits for first ever r
On Tue, Jan 22, 2013 at 02:12:17PM +0200, Mika Kuoppala wrote:
> When machine was rebooted or module was reloaded,
> gem_hw_init() set last_seqno to be identical to next_seqno.
> This lead to situation that waits for first ever request
> always passed immediately regardless if it was actually
> exe
As a precaution against the driver fouling up and missing a hang leaving
the caller in an indefinite wait, manually inspect for a GPU hang if we
timeout whilst waiting for a seqno.
v2: To avoid issues with multiple clients running hangchecks
concurrently or in very rapid succession, make sure we o
When machine was rebooted or module was reloaded,
gem_hw_init() set last_seqno to be identical to next_seqno.
This lead to situation that waits for first ever request
always passed immediately regardless if it was actually
executed.
Use gem_set_seqno() to be consistent how hw is
initialized on ini
As a precaution against the driver fouling up and missing a hang leaving
the caller in an indefinite wait, manually inspect for a GPU hang if we
timeout whilst waiting for a seqno.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c |3 +++
1 file changed, 3 insertions(+)
diff -
On Tue, Jan 22, 2013 at 12:50:33PM +0200, Jani Nikula wrote:
> Some long standing brightness fixes for a few Acer machines under
> eMachines and Packard Bell brands. These should remove the need to use
> i915.invert_brightness=1 on affected machines.
Queued up all three patches for -next, thanks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44156
Reported-by: Alan Zimmerman
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
inde
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=31522#c35
[Note: There are more than one broken setups in the bug. This fixes one.]
Reported-by: Martins
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59628
Reported-by: Roland Gruber
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
Some long standing brightness fixes for a few Acer machines under
eMachines and Packard Bell brands. These should remove the need to use
i915.invert_brightness=1 on affected machines.
BR,
Jani.
Jani Nikula (3):
drm/i915: add quirk to invert brightness on eMachines G725
drm/i915: add quirk to
On Tue, Jan 22, 2013 at 7:36 AM, Ian Pilcher wrote:
> On 01/21/2013 06:05 PM, Csillag wrote:
>> But now, thanks to GIGABYTE's PR about Thunderbolt and 4K (
>> http://www.gigabyte.com/MicroSite/323/4k.html ), I realized that it
>> might be possible to use a "DisplayPort to Dual-DisplayPort Adapter"
Using the latest mesa master tree, I test it on my Core i7-2600 :
1) In default configuration, the monitor's refresh rate is 60FPS, so the test
result is 59.3 FPS
2) export vblank_mode = 0, then the test result is 170 FPS.
I don't see the big difference between using direct transfer or using P
32 matches
Mail list logo
