On Wed, 30 May 2012 23:15:39 +0200, Daniel Vetter wrote:
> On Wed, May 30, 2012 at 01:41:28PM -0700, Ben Widawsky wrote:
> > On Wed, 30 May 2012 20:21:33 +0200
> > Daniel Vetter wrote:
> > > I've tested this by pimping the i-g-t test some more and also checking
> > > the polling behviour of the w
On Thu, May 31, 2012 at 9:24 PM, Singh, Satyeshwar
wrote:
> Is there a reason for the 30 ms delay in the first place?
git blame says there is, it supposedely fixes a bug with tv detection.
-Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
_
On Thu, 31 May 2012 14:57:43 +0200
Daniel Vetter wrote:
> Positively checking for the required feature/gen is simpler than build
> a cascade of negative "we need to bail" checks. And the later won't
> scale if we add more stuff that doesn't fit in nicely.
>
> Signed-Off-by: Daniel Vetter
Review
On Thu, 31 May 2012 14:57:42 +0200
Daniel Vetter wrote:
> This fixes an (albeit really hard to hit) race resulting in an oops:
> - The parity work get scheduled.
> - We re-init the irq state and call INIT_WORK again.
> - The workqueue code tries to run the work item and stumbles over a
> work i
On Thu, 31 May 2012 14:57:41 +0200
Daniel Vetter wrote:
> Notice by Fengguang Wu's automatic sparse checker.
>
> Reported-by: Fengguang Wu
> Signed-Off-by: Daniel Vetter
Reviewed-by: Ben Widawsky
___
Intel-gfx mailing list
Intel-gfx@lists.freedeskto
On Thu, 31 May 2012 12:45:56 +0200
Daniel Vetter wrote:
> On Fri, May 25, 2012 at 04:56:25PM -0700, Ben Widawsky wrote:
> > Dumb binary interfaces which allow root-only updates of the cache
> > remapping registers. As mentioned in a previous patch, software using
> > this interface needs to know
2012/5/30 Dave Jones :
> On Wed, May 30, 2012 at 05:58:48PM -0400, Dave Jones wrote:
> > On Wed, May 30, 2012 at 11:51:54PM +0200, Daniel Vetter wrote:
> > > On Wed, May 30, 2012 at 11:31 PM, Dave Jones wrote:
> > > > On this hardware:
> > > >
> > > > 00:02.0 VGA compatible controller: In
On Thu, May 31, 2012 at 1:08 PM, Chris Wilson wrote:
> Whilst most monitors do wire up the HPD presence pin, it seems quite a
> few KVM do not. Therefore if we simply rely on the HPD pin being
> asserted to indicate a connected monitor we fail miserable, so fall back
> to performing a DCC query fo
Positively checking for the required feature/gen is simpler than build
a cascade of negative "we need to bail" checks. And the later won't
scale if we add more stuff that doesn't fit in nicely.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_sysfs.c | 24 +++-
1
This fixes an (albeit really hard to hit) race resulting in an oops:
- The parity work get scheduled.
- We re-init the irq state and call INIT_WORK again.
- The workqueue code tries to run the work item and stumbles over a
work item that should be on it's runlist.
Also initiliaze the work item u
Notice by Fengguang Wu's automatic sparse checker.
Reported-by: Fengguang Wu
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4a45752
On Thu, May 31, 2012 at 01:08:53PM +0100, Chris Wilson wrote:
> Whilst most monitors do wire up the HPD presence pin, it seems quite a
> few KVM do not. Therefore if we simply rely on the HPD pin being
> asserted to indicate a connected monitor we fail miserable, so fall back
> to performing a DCC
Whilst most monitors do wire up the HPD presence pin, it seems quite a
few KVM do not. Therefore if we simply rely on the HPD pin being
asserted to indicate a connected monitor we fail miserable, so fall back
to performing a DCC query for the EDID.
Reported-and-tested-by: Matthieu LAVIE
Bugzilla:
On Thu, May 31, 2012 at 11:31:50AM +0100, Chris Wilson wrote:
> On Thu, 31 May 2012 12:03:53 +0200, Daniel Vetter wrote:
> > On Thu, May 31, 2012 at 10:49:59AM +0100, Chris Wilson wrote:
> > > On Wed, 30 May 2012 15:34:20 +0200, Daniel Vetter
> > > wrote:
> > > > Instead of abusing into mode->cl
On Fri, May 25, 2012 at 04:56:25PM -0700, Ben Widawsky wrote:
> Dumb binary interfaces which allow root-only updates of the cache
> remapping registers. As mentioned in a previous patch, software using
> this interface needs to know about HW limits, and other programming
> considerations as the ker
On Thu, 31 May 2012 12:03:53 +0200, Daniel Vetter wrote:
> On Thu, May 31, 2012 at 10:49:59AM +0100, Chris Wilson wrote:
> > On Wed, 30 May 2012 15:34:20 +0200, Daniel Vetter
> > wrote:
> > > Instead of abusing into mode->clock, because we should touch that
> > > one at all. First prep step to c
On Thu, May 31, 2012 at 10:49:59AM +0100, Chris Wilson wrote:
> On Wed, 30 May 2012 15:34:20 +0200, Daniel Vetter
> wrote:
> > Instead of abusing into mode->clock, because we should touch that
> > one at all. First prep step to constify the mode argument to the
> > intel_dp_mode_fixup function.
>
On Wed, 30 May 2012 15:34:20 +0200, Daniel Vetter
wrote:
> Instead of abusing into mode->clock, because we should touch that
> one at all. First prep step to constify the mode argument to the
> intel_dp_mode_fixup function.
>
> The next patch will stop us from modifying mode->clock.
>
> Signed-
On Thu, May 24, 2012 at 09:26:49PM +0200, Daniel Vetter wrote:
> A 30 ms delay is simply way too big to waste cpu cycles on.
>
> Signed-off-by: Daniel Vetter
I've queued this patch here for -next with Chris' irc ack added.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 4
On Wed, May 30, 2012 at 01:56:01PM +0100, Chris Wilson wrote:
> On Wed, 30 May 2012 14:52:26 +0200, Daniel Vetter
> wrote:
> > Jesse extracted this nice helper in his i9xx_crtc_mode_set refactor,
> > but we have the identical code in ironlake_ccrtc_mode_set. And that
> > function is huge, so extr
On Wed, May 30, 2012 at 12:19:22PM -0300, Eugeni Dodonov wrote:
> On 05/30/2012 12:15 PM, Daniel Vetter wrote:
> >Already discovered in
> >
> >commit 5a117db77e47e3946d1aaa7ce8deafafd9d76746
> >Author: Eugeni Dodonov
> >Date: Thu Jan 5 09:34:29 2012 -0200
> >
> > drm/i915: there is no pipe Cx
21 matches
Mail list logo
