Re: [Intel-gfx] [PATCH] drm/i915: only hook up hpd pulse for DP outputs

2014-08-03 Thread Dave Airlie
On 4 August 2014 16:15, Chris Wilson wrote: > On HSW+, the digital encoders are shared between HDMI and DP outputs, > with one encoder masquerading as both. The VBT should tell us if we need > to have DP or HDMI support on a particular port, but if we don't have DP > support and we enable the DP h

[Intel-gfx] [PATCH] drm/i915: only hook up hpd pulse for DP outputs

2014-08-03 Thread Chris Wilson
On HSW+, the digital encoders are shared between HDMI and DP outputs, with one encoder masquerading as both. The VBT should tell us if we need to have DP or HDMI support on a particular port, but if we don't have DP support and we enable the DP hpd pulse handler then we cause an oops. Don't hook u

Re: [Intel-gfx] reverse dp link param selection, prefer fast over wide again

2014-08-03 Thread Daniel Vetter
Adding relevant mailing lists, please don't forget that next time around. At least with haswell based models the most likely cause for this is lack of DP mst support. We have something from Dave Airlie queued up for 3.17. -Daniel On Fri, Jul 25, 2014 at 10:19 PM, wrote: > Hi Jani and Daniel, >

Re: [Intel-gfx] i915 bug

2014-08-03 Thread Daniel Vetter
Hi Keith, Still working on the i915 driver. Please cc relevant mailing lists next time around (added) since I tend to be busy and let's continue tracking this bug in bugzilla. Thanks, Daniel On Thu, Jul 31, 2014 at 4:00 PM, Keith Grider wrote: > Daniel, > > Are you still involved with the drm/i

Re: [Intel-gfx] [PATCH 06/12] Remove glamor support from UXA acceleration

2014-08-03 Thread Eric Anholt
Keith Packard writes: > Makes UXA no longer include calls to glamor acceleration functions. > > Signed-off-by: Keith Packard > --- > src/uxa/Makefile.am| 9 -- > src/uxa/intel_dri.c| 60 + > src/uxa/intel_driver.c | 1 - > src/uxa/intel_uxa.c| 49 --- > src

Re: [Intel-gfx] [PATCH 03/12] Don't use GetScratchPixmapHeader for shadow pixmaps

2014-08-03 Thread Eric Anholt
Keith Packard writes: > GetScratchPixmapHeader should only be used for local memory pixmaps, > as used by PutImage and friends. That's because when you free the > scratch pixmap header, it doesn't actually free the pixmap; instead, > it gets stuffed in pScreen->pScratchPixmap and any private data

Re: [Intel-gfx] [PATCH 10/12] Add glamor back into the driver

2014-08-03 Thread Eric Anholt
Keith Packard writes: > This adds glamor support back into the driver, but instad of going > through UXA, this uses it directly instead. This is hard to read with the conditionalizing all of the UXA code in the same commit as adding the glamor code. Then there are a bunch of unrelated whitespac

Re: [Intel-gfx] [PATCH 08/12] Get rid of glamor stubs in intel_glamor.h

2014-08-03 Thread Eric Anholt
Keith Packard writes: > This eliminates the stubs in intel_glamor.h and replaces them with > ifdefs instead. I don't feel strongly about this either way -- ifdefs are more traditional userland style, while stubs are more kernel style. Acked-by: Eric Anholt pgpv5IVwrtIC1.pgp Description: PGP

Re: [Intel-gfx] [PATCH 00/12] Rework intel 2D driver glamor support

2014-08-03 Thread Eric Anholt
Keith Packard writes: > I spent the day just cleaning up this patch series and testing. I > think it's ready for others to use and review. I've been running it on > two machines for a couple of days now and it's been solid. Patches 2, 4 are: Reviewed-by: Eric Anholt Patch 5 is: Acked-by: Eri

Re: [Intel-gfx] [PATCH 07/12] Add intel_flush to abstract flushing pending acceleration operations

2014-08-03 Thread Eric Anholt
Keith Packard writes: > intel_flush flushes any pending acceleration operations to the > hardware, just like intel_uxa_batch_submit does today except that it is > not uxa-specific. This seems like an obvious cleanup (and in one case a fix), and we ought to even apply it right away as long as it

Re: [Intel-gfx] [PATCH 09/12] Do more checks for proposed flip pixmaps

2014-08-03 Thread Eric Anholt
Keith Packard writes: > Make sure the pitch and tiling are correct. > Make sure there's a BO we can get at. I thought we couldn't change these parameters, but now I can't find what prevents them from changing. Can you cite sources? pgpAYiuAwpzYm.pgp Description: PGP signature

Re: [Intel-gfx] [PATCH 01/12] Stop trying to out-guess mesa for BO allocation

2014-08-03 Thread Eric Anholt
Keith Packard writes: I don't see anything indicating that this code path is only used by glamor. > --- > src/uxa/intel_uxa.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/uxa/intel_uxa.c b/src/uxa/intel_uxa.c > index b396188..717754f 100644 > --- a/src/uxa/intel_uxa.c > +++ b/