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
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
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,
>
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
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
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
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
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
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
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
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
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/
12 matches
Mail list logo