On 22/12/15 14:31, Chris Wilson wrote:
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.
Plan is for "drm/i915: Avoid writing relocs with addresses in
non-canonical form" to be ready as a fixup either before, or slightly
after rc1. As long as we hit that, slight wobbling in the ABI between
two release candidates shouldn't be an issue. That is my understanding
at least.
Especially given how the announced user plans to pass in user pointer
allocated addresses which will already be in canonical format.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
