[PULL] drm-intel-next

[Daniel Vetter]

On Mon, Oct 24, 2016 at 9:25 AM, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> Hi Dave,
>
> drm-intel-next-2016-10-24:
> - first slice of the gvt device model (Zhenyu et al)
> - compression support for gpu error states (Chris)
> - sunset clause on gpu errors resulting in dmesg noise telling users
>   how to report them
> - .rodata diet from Tvrtko
> - switch over lots of macros to only take dev_priv (Tvrtko)
> - underrun suppression for dp link training (Ville)
> - lspcon (hmdi 2.0 on skl/bxt) support from Shashank Sharma, polish
>   from Jani
> - gen9 wm fixes from Paulo&Lyude
> - updated ddi programming for kbl (Rodrigo)
> - respect alternate aux/ddc pins (from vbt) for all ddi ports (Ville)
> drm-intel-next-2016-10-10:
> - dsi/backlight fixes (Jani&Shawn)
> - a few reset improvements (Ben, Chris, Imre)
> - refactor port tracking for audio support (Dhinakaran)
> - a pile of gen9 wm fixes from Paulo
> - drop skl pre-production w/a (Jani)
> - refactor forcewake and shadow reg filters into tables, and unify the
>   funcs/macros using them across platforms (Tvrtko)
> - fix DP detection to not require an edid (Ville)
> - register shadow VGA port (for testing), from Ville
>
> NOTE: There's a big conflict between this tree an the rotation stuff from
> Ville in drm-misc. One conflict git spots and it's easy to resolve, the
> other results in compile fail and needs some s/dev/dev_priv/ in a few
> places to fix up. linux-next just reported&fixed them up, but I've been
> soaking the resolutions in drm-intel-nightly a bit too.
>
> And as mentioned I'd like to backmerge drm-misc+rc2 to unblock merging a
> few patches.
>
> And the other bit I've totally forgotten: As soon as you have all the
> merges I'll pull in the s/fence/dma_fence/ patch from Chris into drm-misc.

One more: This pull contains the intial bits of the gvt device model
(essentially paravirt for intel gpus for kvm&xen). We've decided to
run this as a subproject with pull requests from Zhenyu to Jani& me
for now for a few reasons:
- it's a big codebase, separate team and lots (probably most) of
interactions out i915/drm (kvm/xen, qemu in userspace and all that).
Seems to make sense to run it separately
- there's also differences in CI&testing overall. I think running gvt
as an integrated part of drm-intel with the commit model would have
caused fun with accidentally pushing broken patches.
- and personally I'm also interesting in figuring out whether the
committer model also works when mixed with submaintainers, in case we
ever need that for scalability in areas.

Some hiccups, (there was an almost immediate 2nd pull with pile of
bugfixes), but we're working them out. I expect all smooth sailing by
the time the 4.10 merge windo opens.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch