* 2 questions about git and merging @ 2015-05-26 13:09 Rainer Koenig 2015-05-26 14:04 ` Daniel Vetter 0 siblings, 1 reply; 8+ messages in thread From: Rainer Koenig @ 2015-05-26 13:09 UTC (permalink / raw) To: dri-devel 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? 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. Thanks for any explanation Rainer -- Dipl.-Inf. (FH) Rainer Koenig Project Manager Linux Clients Dept. PDG WPS R&D SW OSE Fujitsu Technology Solutions Bürgermeister-Ullrich-Str. 100 86199 Augsburg Germany Telephone: +49-821-804-3321 Telefax: +49-821-804-2131 Mail: mailto:Rainer.Koenig@ts.fujitsu.com Internet ts.fujtsu.com Company Details ts.fujitsu.com/imprint.html _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2 questions about git and merging 2015-05-26 13:09 2 questions about git and merging Rainer Koenig @ 2015-05-26 14:04 ` Daniel Vetter 2015-05-26 15:17 ` Jani Nikula 2015-05-27 4:55 ` Rainer Koenig 0 siblings, 2 replies; 8+ messages in thread From: Daniel Vetter @ 2015-05-26 14:04 UTC (permalink / raw) To: Rainer Koenig; +Cc: dri-devel 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 $ git branch --contains $sha1 Add -r if you want to see all the remote branches too. Cheers, Daniel > > Thanks for any explanation > Rainer > -- > Dipl.-Inf. (FH) Rainer Koenig > Project Manager Linux Clients > Dept. PDG WPS R&D SW OSE > > Fujitsu Technology Solutions > Bürgermeister-Ullrich-Str. 100 > 86199 Augsburg > Germany > > Telephone: +49-821-804-3321 > Telefax: +49-821-804-2131 > Mail: mailto:Rainer.Koenig@ts.fujitsu.com > > Internet ts.fujtsu.com > Company Details ts.fujitsu.com/imprint.html > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2 questions about git and merging 2015-05-26 14:04 ` Daniel Vetter @ 2015-05-26 15:17 ` Jani Nikula 2015-05-27 5:03 ` Rainer Koenig 2015-05-27 5:14 ` Dave Airlie 2015-05-27 4:55 ` Rainer Koenig 1 sibling, 2 replies; 8+ messages in thread From: Jani Nikula @ 2015-05-26 15:17 UTC (permalink / raw) To: Daniel Vetter, Rainer Koenig; +Cc: dri-devel 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. BR, Jani. > > $ git branch --contains $sha1 > > Add -r if you want to see all the remote branches too. > > Cheers, Daniel > >> >> Thanks for any explanation >> Rainer >> -- >> Dipl.-Inf. (FH) Rainer Koenig >> Project Manager Linux Clients >> Dept. PDG WPS R&D SW OSE >> >> Fujitsu Technology Solutions >> Bürgermeister-Ullrich-Str. 100 >> 86199 Augsburg >> Germany >> >> Telephone: +49-821-804-3321 >> Telefax: +49-821-804-2131 >> Mail: mailto:Rainer.Koenig@ts.fujitsu.com >> >> Internet ts.fujtsu.com >> Company Details ts.fujitsu.com/imprint.html >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2 questions about git and merging 2015-05-26 15:17 ` Jani Nikula @ 2015-05-27 5:03 ` Rainer Koenig 2015-05-27 5:14 ` Dave Airlie 1 sibling, 0 replies; 8+ messages in thread From: Rainer Koenig @ 2015-05-27 5:03 UTC (permalink / raw) To: Jani Nikula, Daniel Vetter; +Cc: dri-devel@lists.freedesktop.org Am 26.05.2015 um 17:17 schrieb Jani Nikula: > 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. I understand you from a software developers point of view. My real world problem is simply explained, that we do prototype testing for Skylake now with real physical hardware. This hardware should go into prodcution whenever Intel decides to release the Skylake platform, probably in Q4/2015. From that date on people can buy Skylake based PCs and workstations and they probably want to run Linux on those machines. But they don't want to compile their own kernel, they want to stuck with whatever is in the distributions (e.g. RHEL, SLES, Ubuntu whatever). But also distributions have merge windows for new hardware features and the longer it takes for a patch to show up in the vanilla tree the later it will show up in the individual distribution kernel. Working for a hardware vendor I see that this is bad for business. :-) Thanks a lot for the explanations anyway, learned a lot from that. Best regards Rainer -- Dipl.-Inf. (FH) Rainer Koenig Project Manager Linux Clients Dept. PDG WPS R&D SW OSE Fujitsu Technology Solutions Bürgermeister-Ullrich-Str. 100 86199 Augsburg Germany Telephone: +49-821-804-3321 Telefax: +49-821-804-2131 Mail: mailto:Rainer.Koenig@ts.fujitsu.com Internet ts.fujtsu.com Company Details ts.fujitsu.com/imprint.html _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2 questions about git and merging 2015-05-26 15:17 ` Jani Nikula 2015-05-27 5:03 ` Rainer Koenig @ 2015-05-27 5:14 ` Dave Airlie 2015-05-27 6:24 ` Jani Nikula 1 sibling, 1 reply; 8+ messages in thread From: Dave Airlie @ 2015-05-27 5:14 UTC (permalink / raw) To: Jani Nikula; +Cc: dri-devel 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. Dave. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2 questions about git and merging 2015-05-27 5:14 ` Dave Airlie @ 2015-05-27 6:24 ` Jani Nikula 2015-05-27 9:28 ` Daniel Vetter 0 siblings, 1 reply; 8+ messages in thread From: Jani Nikula @ 2015-05-27 6:24 UTC (permalink / raw) To: Dave Airlie; +Cc: dri-devel 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. -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2 questions about git and merging 2015-05-27 6:24 ` Jani Nikula @ 2015-05-27 9:28 ` Daniel Vetter 0 siblings, 0 replies; 8+ messages in thread From: Daniel Vetter @ 2015-05-27 9:28 UTC (permalink / raw) To: Jani Nikula; +Cc: dri-devel On Wed, May 27, 2015 at 09:24:31AM +0300, Jani Nikula wrote: > 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? the planes abi in skl is still wrong, we expose both top plane both as the new unified plane and through the cursor backwards interface the hw provides. Until that's fixed (and that's not the case for 4.2) skl isn't ready imo. It's a fairly small patch, we only need to stop registering the legacy cursor plane and mark the top plane as the cursor one for backwards abi purposes. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2 questions about git and merging 2015-05-26 14:04 ` Daniel Vetter 2015-05-26 15:17 ` Jani Nikula @ 2015-05-27 4:55 ` Rainer Koenig 1 sibling, 0 replies; 8+ messages in thread From: Rainer Koenig @ 2015-05-27 4:55 UTC (permalink / raw) To: Daniel Vetter; +Cc: dri-devel@lists.freedesktop.org Am 26.05.2015 um 16:04 schrieb Daniel Vetter: > -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} Thank you for the explanation. Regards Rainer -- Dipl.-Inf. (FH) Rainer Koenig Project Manager Linux Clients Dept. PDG WPS R&D SW OSE Fujitsu Technology Solutions Bürgermeister-Ullrich-Str. 100 86199 Augsburg Germany Telephone: +49-821-804-3321 Telefax: +49-821-804-2131 Mail: mailto:Rainer.Koenig@ts.fujitsu.com Internet ts.fujtsu.com Company Details ts.fujitsu.com/imprint.html _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-05-27 9:26 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-05-26 13:09 2 questions about git and merging Rainer Koenig 2015-05-26 14:04 ` Daniel Vetter 2015-05-26 15:17 ` Jani Nikula 2015-05-27 5:03 ` Rainer Koenig 2015-05-27 5:14 ` Dave Airlie 2015-05-27 6:24 ` Jani Nikula 2015-05-27 9:28 ` Daniel Vetter 2015-05-27 4:55 ` Rainer Koenig
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.