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

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel