On Wed, 27 May 2015, Dave Airlie airlied@gmail.com wrote:
On 27 May 2015 at 01:17, Jani Nikula jani.nikula@linux.intel.com wrote:
On Tue, 26 May 2015, Daniel Vetter daniel@ffwll.ch wrote:
On Tue, May 26, 2015 at 03:09:04PM +0200, Rainer Koenig wrote:
Hi,
a week ago I experienced problems on the skylake platform and got the adivce to try out the drm-intel-nightly branch. I tried and it was a success.
So after the initial "git clone" of the tree I tried to keep updated by doing a "git pull" from time to time, but what's really strange is that I got merge conflicts, usually in the file integration-manifest, but sometimes also in source files.
That's looks somewhat weird because I didn't touch any of the files in the tree and I thought that after cloning a frequent "git pull" will keep me up to date without the need to resolve merge conflicts.
What is wrong with my thought? What did I do wrong?
-nigthly is a rebasing tree, git pull does the wrong thing for that. The proper way to track rebasing branches is (assuming you have no local patches that you want to keep):
$ git fetch origin $ git reset --hard @{upstream}
Second, I pulled the "Linus"-tree today and found some log entries that said Merge branch 'drm-fixes-4.1' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
and Merge tag 'drm-intel-fixes-2015-05-21' of git://anongit.freedesktop.org/drm-intel into drm-fixes
So I assumed, that the fix I proved to work one week ago now should also be available in the "vanilla" tree. So I compiled that on my test machine and got my bug back. :-(
So my other question is, how do fixes from drm-intel-nightly find their weay into the "vanilla" linux tree? Is there some sort of process description.
It takes a while. If the patch is in drm-intel-fixes, it will first got to drm-fixes and then to vanilla upstream, then to stable kernels (if it's cc: stable). You can check which branch a patch is in already with
However we don't necessarily queue Skylake fixes to the current development kernels through drm-intel-fixes/drm-fixes, as the Skylake support there is anyway preliminary, the fix (I don't think we figured out which exact commit it was, did we?) may only end up upstream after the next merge window, i.e. at v4.2-rc1.
So 4.1 won't cut it on skylake? I'm not sure everyone in Intel is aware.
My approach has been that I don't queue fixes to current development kernels for platforms that still require i915.preliminary_hw_support=1 or CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=y. Obviously same for stable. I don't think this is unreasonable.
Basically preliminary means the implementation does not have feature parity with the preceding platform, and is expected to be rough around th edges.
Skylake still requires the preliminary flag even in drm-intel-nightly. Damien, should we drop preliminary for Skylake in v4.2? Or already in v4.1?
BR, Jani.