Summary
We finished a new round of kernel testing. Generally, in this circle, 12 new
bug is filed, 12 bugs are still opened, 11 bugs are closed.
Test Environment
Kernel: (drm-intel-testing)2945111e30137965700f061f6f4bda1bc3ab0ecd
Some additional commit info:
Merge: e5c6537 b514407
Author:
On Wed, Jan 23, 2013 at 04:37:12PM +, Chris Wilson wrote:
> On Wed, Jan 23, 2013 at 05:30:46PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 23, 2013 at 03:20:45PM +, Chris Wilson wrote:
> > > On Wed, Jan 23, 2013 at 04:16:35PM +0100, Daniel Vetter wrote:
> > > > Useful for statistics or on o
On Wed, Jan 23, 2013 at 5:38 PM, Takashi Iwai wrote:
> At Wed, 23 Jan 2013 17:25:08 +0100,
> Daniel Vetter wrote:
>>
>> From: Alan Cox
>>
>> Adjust the console layer to allow a take over call where the caller already
>> holds the locks. Make the fb layer lock in order.
>>
>> This s partly a band
At Wed, 23 Jan 2013 17:25:08 +0100,
Daniel Vetter wrote:
>
> From: Alan Cox
>
> Adjust the console layer to allow a take over call where the caller already
> holds the locks. Make the fb layer lock in order.
>
> This s partly a band aid, the fb layer is terminally confused about the
> locking r
On Wed, Jan 23, 2013 at 05:30:46PM +0100, Daniel Vetter wrote:
> On Wed, Jan 23, 2013 at 03:20:45PM +, Chris Wilson wrote:
> > On Wed, Jan 23, 2013 at 04:16:35PM +0100, Daniel Vetter wrote:
> > > Useful for statistics or on overflowing bug reports to keep things all
> > > lined up.
> > >
> > >
On Wed, Jan 23, 2013 at 03:20:45PM +, Chris Wilson wrote:
> On Wed, Jan 23, 2013 at 04:16:35PM +0100, Daniel Vetter wrote:
> > Useful for statistics or on overflowing bug reports to keep things all
> > lined up.
> >
> > Signed-off-by: Daniel Vetter
>
> I should have added something like this
One of the early return cases missed the mutex unlocking. Hilarity
ensued.
This regression has been introduced in
commit 7b24056be6db7ce907baffdd4cf142ab774ea60c
Author: Daniel Vetter
Date: Wed Dec 12 00:35:33 2012 +0100
drm: don't hold crtc mutexes for connector ->detect callbacks
Bugzi
From: Alan Cox
Adjust the console layer to allow a take over call where the caller already
holds the locks. Make the fb layer lock in order.
This s partly a band aid, the fb layer is terminally confused about the
locking rules it uses for its notifiers it seems.
Signed-off-by: Alan Cox
[danvet
Hi Dave,
First patch is a resend of Alan's fbcon vs. fb notifier deadlock fix.
Without this lockdep is pretty much useless for debugging drm locking
issues, and it looks like quite a few bootup hangs could be blamed on this
one, too.
Since the fbdev maintainer seems to be awol, please merge this
Hi
2013/1/11 Rodrigo Vivi :
> From: Shobhit Kumar
>
> Signed-off-by: Shobhit Kumar
> Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_dp.c | 49
> +
> 1 file changed, 49 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/driver
Hi
2013/1/11 Rodrigo Vivi :
> From: Shobhit Kumar
>
> Signed-off-by: Shobhit Kumar
>
> v2: reuse of just created is_edp_psr and put it at right place.
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_dp.c | 12
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> include/
On Wed, Jan 23, 2013 at 04:16:35PM +0100, Daniel Vetter wrote:
> Useful for statistics or on overflowing bug reports to keep things all
> lined up.
>
> Signed-off-by: Daniel Vetter
I should have added something like this long ago...
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open
Useful for statistics or on overflowing bug reports to keep things all
lined up.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7944d301
On Wed, Jan 23, 2013 at 12:39:01PM +0100, Daniel Vetter wrote:
> On Wed, Jan 23, 2013 at 12:03 PM, Chris Wilson
> wrote:
> > On Mon, Jan 21, 2013 at 02:10:31PM -0800, Ben Widawsky wrote:
> >> Elaborating a bit more on what we can do with the vtable... still hoping
> >> to get feedback.
> >
> > Mu
On Wed, Jan 23, 2013 at 02:34:08PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 22, 2013 at 09:03:20PM +0100, Daniel Vetter wrote:
[cut]
> > On Tue, Jan 22, 2013 at 09:13:04PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > Same thing about interrupt registers, imo those are ok as-is. The only
tbh I have no idea whether you can actually by hw which supports 2x DP
out, it's certainly no common. The description was only from the hw
pov. It might be that the 2x thunderbolt works, otoh I've never tested
thunderbolt so I have no idea how well (or if at all) the pcie + dp
muxing works with our
At 2013-01-22 09:43, Daniel Vetter wrote:
For your 3 monitor required a decen ivb based board should be good
enough, as long as you keep the restriction in mind that 2 of them
need to have the same dotclock (which in practice boils down to either
2x DP monitors or 2x identical monitors with the s
At 2013-01-22 07:36, 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" to
split a DisplayPo
On Wed, Jan 23, 2013 at 12:03 PM, Chris Wilson wrote:
> On Mon, Jan 21, 2013 at 02:10:31PM -0800, Ben Widawsky wrote:
>> Elaborating a bit more on what we can do with the vtable... still hoping
>> to get feedback.
>
> Multiple layers of identical abstraction, just what we like!
>
> One thing that
On Mon, Jan 21, 2013 at 02:10:31PM -0800, Ben Widawsky wrote:
> Elaborating a bit more on what we can do with the vtable... still hoping
> to get feedback.
Multiple layers of identical abstraction, just what we like!
One thing that we lost in this switch is a small string identifying the
chipset.
20 matches
Mail list logo
