[Intel-gfx] [PULL] drm-intel-next

Chris Wilson chris at chris-wilson.co.uk
Tue Dec 22 06:31:21 PST 2015


On Tue, Dec 22, 2015 at 03:05:14PM +0100, Daniel Vetter wrote:
> On Tue, Dec 22, 2015 at 11:37:18AM +0100, Daniel Vetter wrote:
> > Hi Dave,
> > 
> > Final 4.5 feature pull for drm/i915!
> > 
> > drm-intel-next-2015-12-18:
> > - fix atomic watermark recomputation logic (Maarten)
> > - modeset sequence fixes for LPT (Ville)
> > - more kbl enabling&prep work (Rodrigo, Wayne)
> > - first bits for mst audio
> > - page dirty tracking fixes from Dave Gordon
> > - new get_eld hook from Takashi, also included in the sound tree
> > - fixup cursor handling when placed at address 0 (Ville)
> > - refactor VBT parsing code (Jani)
> > - rpm wakelock debug infrastructure ( Imre)
> > - fbdev is pinned again (Chris)
> > - tune the busywait logic to avoid wasting cpu cycles (Chris)
> > 
> > Two small caveats as a heads up:
> > - the runtime pm wakelock debug stuff catches a few bugs. rpm is disabled
> >   by default, but lots enable it (e.g. powertop does), and we iirc have
> >   fixes floating for most. If we can't squeeze them all in for 4.5 because
> >   too big or late we can just tune down the dmesg noise since the
> >   uncovered bugs are all as old as rpm support.
> > - softpin is still thrashing around: Chris complains that the ABI can't be
> >   used of anything else than beignet, but I think that's ok since easy to
> >   remedy and softpin was done primarily for buffered svm opencl mode. And
> >   then there's some confusion around canonical 48bit addresses that I
> >   don't fully understand myself. I expect Tvrtko to handle this before
> >   your merge window pull goes out.
> 
> So just with Tvrtko and the canonical address is something
> userspace/beignet will never hit under legitimate usage. So it's just a
> bit of closing a corner-case, and the patch+testcase is ready except for
> bit of final polish and unfortunately people going on holidays already.

Nope, it was reported in the wild and it imposes an ABI constraint on
the execobject.offsets.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list