Message ID | 87pnvneq5i.fsf@intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [PULL] drm-intel-next for v4.21/v5.1 | expand |
On Fri, 2 Nov 2018 at 20:21, Jani Nikula <jani.nikula@intel.com> wrote: > > > Hi Dave - > > I just tagged this minutes ago, but I'm sending this now because I'll be > out for about a week. I don't expect you to pull this until some time > after -rc1 anyway. I'm asking Joonas and Rodrigo to tell you if this > one's a go or a no go. > > There's a couple of backmerges in there, and I'd probably like to do > another one once you've backmerged from Linus. > > I suck at making myself write proper changelogs. It's a random unordered > jumble, I'm afraid. One of these days I'll learn to do it > right. Promise! So I haven't pulled this for a couple of reasons, mostly my fault, but it would be nice if you could regenerate it with more of drm-intel-next-queued pull in. To explain further: a) I rebased drm-next to v4.20-rc3 because I was away last week and had failed to merge anything. b) I pulled drm-misc-next + amdgpu (nothing major here). c) I pulled this and got a conflict that nobody else has resolved in intel_sprite.c and realised it was a pain to resolve with this merge. intel_sprite.c got a fix in drm-fixes 27971d613fcb5b6ad96320bc4f2c90f4d4fde768 drm/i915: Clean up skl_program_scaler() This isn't in this pull request, it's only in drm-intel-next-queued, so I have to create a new merge state that has never occured anywhere else, and if I just wait for the next i915 pull has no need to exist here, the merge looked minorly complicated and it seems likely I'd probably get it wrong, when waiting will just make it all happen. So please send me an updated pull and sorry for the delay that caused the noise. Dave.