On Fri, 13 Jan 2012 17:05:04 -0800, Jesse Barnes
wrote:
> Looks like signing the message the way I did caused it to be packaged
> differently. Then I also had word wrap fail on the inserted file when
> I sent it to myself as plaintext. Lame. I'll be more careful in
> future.
I managed to pul
On Fri, 13 Jan 2012 15:50:14 -0800
Keith Packard wrote:
> On Thu, 12 Jan 2012 08:08:44 -0800, Jesse Barnes
> wrote:
> > We can call the plane init function unconditionally, but don't need to
> > complain if it fails, since that will only happen if we're out of
> > memory (and other things will
On Fri, 13 Jan 2012 15:50:14 -0800
Keith Packard wrote:
> On Thu, 12 Jan 2012 08:08:44 -0800, Jesse Barnes
> wrote:
> > We can call the plane init function unconditionally, but don't need to
> > complain if it fails, since that will only happen if we're out of
> > memory (and other things will
On Sat, 14 Jan 2012 01:31:40 +0100, Daniel Vetter wrote:
> On Fri, Jan 13, 2012 at 04:11:43PM -0800, Keith Packard wrote:
> > On Sat, 14 Jan 2012 00:52:31 +0100, Daniel Vetter wrote:
> > > acc101d drm/i915: Hold gt_lock across forcewake register reads
> > >
> > > Imo this is a simple cleanup (re
On Fri, Jan 13, 2012 at 04:11:43PM -0800, Keith Packard wrote:
> On Sat, 14 Jan 2012 00:52:31 +0100, Daniel Vetter wrote:
> > acc101d drm/i915: Hold gt_lock across forcewake register reads
> >
> > Imo this is a simple cleanup (reading forcewake-protected registers isn't
> > really a fast-path for
On Sat, 14 Jan 2012 00:52:31 +0100, Daniel Vetter wrote:
> - I think we need to amend the commit msg of the voodoo patch with the
> piece of doc I've discovered. If you want I can send out a v3 with that.
Sounds good.
> - I think the HWSTAM revert is material for -next
I'd be OK with pushing
On Sat, Jan 14, 2012 at 12:52:31AM +0100, Daniel Vetter wrote:
> On Fri, Jan 13, 2012 at 08:42:00AM -0800, Keith Packard wrote:
> > On Wed, 4 Jan 2012 19:40:45 +0100, Daniel Vetter
> > wrote:
> >
> > > Two things seem to do the trick on my ivb machine here:
> > > - prevent the gt from powering
On Fri, Jan 13, 2012 at 08:42:00AM -0800, Keith Packard wrote:
> On Wed, 4 Jan 2012 19:40:45 +0100, Daniel Vetter
> wrote:
>
> > Two things seem to do the trick on my ivb machine here:
> > - prevent the gt from powering down while waiting for seqno
> > notification interrupts by grabbing the
On Thu, 12 Jan 2012 08:08:44 -0800, Jesse Barnes
wrote:
> We can call the plane init function unconditionally, but don't need to
> complain if it fails, since that will only happen if we're out of
> memory (and other things will fail) or if we're on the wrong platform
> (which is ok).
Can you pl
On Fri, Jan 13, 2012 at 08:10:42AM -0800, Keith Packard wrote:
> On Thu, 12 Jan 2012 08:59:37 -0800, Jesse Barnes
> wrote:
>
> > ENODEV actually does tell you why the init failed, in case you want to
> > look at the debug logs...
>
> Daniel -- are you OK with merging this as-is? It seems fine t
On Fri, 13 Jan 2012 13:26:08 -0500, Adam Jackson wrote:
> + count &= (~DP_DOWN_STREAM_OUI_SUPPORTED);
> + if ((count & DP_DOWN_STREAM_PORT_COUNT_MASK) == 0)
> + offset = DP_SINK_IEEE_OUI;
> + else
> + offset = DP_BRANCH_IEEE_OUI_OUT;
I suspect the SINK_IEEE_OU
DisplayPort lets you discover the manufacturer OUI of the other end.
This is good, because it means you might be able to have per-phy quirks
to work around other people's bugs, but it's bad because it removes some
incentive to not make buggy hardware.
At any rate DisplayPort is proving fickle enou
On Wed, 4 Jan 2012 19:40:45 +0100, Daniel Vetter
wrote:
> Two things seem to do the trick on my ivb machine here:
> - prevent the gt from powering down while waiting for seqno
> notification interrupts by grabbing the force_wake in get_irq (and
> dropping it in put_irq again).
> - ordering
On Thu, 12 Jan 2012 12:19:44 +0530, Rohit Jain wrote:
> Support for parsing parameters for S3D support and T3 optimization
> support is implemented. The order for the bdb_edp struct was also
> made similar to that indicated in spec.
Merged.
7885d20..96c0a2f drm-intel-fixes -> drm-intel-fixes
On Thu, 12 Jan 2012 08:59:37 -0800, Jesse Barnes
wrote:
> ENODEV actually does tell you why the init failed, in case you want to
> look at the debug logs...
Daniel -- are you OK with merging this as-is? It seems fine to me.
--
keith.pack...@intel.com
pgpGfnmLfiO3d.pgp
Description: PGP signa
Hello,
this list is mainly about development and issues in the newest driver
version. If you can, please try at least the latest (11.10) ubuntu
version. In case the problems don't exist anymore in 11.10, it is more
an ubuntu problem than an intel driver problem.
Greets,
Kiste
hello guys,
16 matches
Mail list logo