On Tue, Dec 22, 2015 at 04:31:22PM +0000, Tvrtko Ursulin wrote: > > 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. What about the other ABI issue you just ignored? What about the severe scaling issues that were known and addressed before you pushed a patch *out of context*? > Especially given how the announced user plans to pass in user > pointer allocated addresses which will already be in canonical > format. Not good enough for ABI as the existing code that you just enabled didn't adhere to the required ABI. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
