Re: [Intel-gfx] [PATCH 00/12] Broadwell 3.14 backports
On Mon, Mar 24, 2014 at 04:17:42PM -0700, Ben Widawsky wrote: > On Mon, Mar 24, 2014 at 04:14:32PM -0700, Ausmus, James wrote: > > On Sat, Mar 22, 2014 at 4:34 AM, Daniel Vetter wrote: > > > On Fri, Mar 21, 2014 at 05:51:01PM -0700, Ben Widawsky wrote: > > >> Let's try this again. I've pushed a branch here: > > >> http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=bdw-backports > > >> > > >> I need to re-review some of the merge conflicts for 4g GGTT, which I > > >> will try to do before Monday. > > >> > > >> Daniel: please make sure this is what you had in mind. I don't know > > >> where you want Cc: stable tags. > > > > > > We don't need cc: stable, we just need to submit it (since it has the > > > upstream sha1s already, which is the requirement for stable patches). Cc: > > > stable is only for when you want it to get backport anyway. Otherwise > > > looks good. I dunno whether git cherry-pick can be told to use the sha1 > > > reference layout Greg prefers or not, he uses "This is in > > > upstream." between the commit header and the actual commit message. But > > > ime his scripts reformat your commit messages anyway. > > > > > >> James: please test this as soon as possible. > > > > > > Once this is tested and we conclude it's sufficient to get bdw going on > > > 3.14 without hilarity I think we should do a quick review on intel-gfx to > > > check that the impact outside of bdw is indeed minimal. Then once drm-next > > > has landed with all the referenced commits we can submit it to Greg with a > > > small cover letter why we want this and that plan B would be to kill bdw > > > in 3.14. > > > > This seems to be working well for me, with the one caveat that on boot > > and once per resume I'm hitting the WARN(!i915_preliminary_hw_support, > > "GEN8_CENTROID_PIXEL_OPT_DIS not be needed for production") code in > > gen8_init_clock_gating - can that WARN be dropped via "drm/i915: Don't > > use i915_preliminary_hw_support to mean pre-production" ? > > > > Both with and without that patch added, the series is: > > > > Tested-by: James Ausmus > > Thanks. > > Daniel, the patch is added to my backports branch. I think given that > that it removes a WARN which we know to be bogus, it's a good patch for > stable. But it's your call. Oh, that patch definitely should go to stable if we fix up bdw in 3.14 ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Broadwell 3.14 backports
On Mon, Mar 24, 2014 at 04:14:32PM -0700, Ausmus, James wrote: > On Sat, Mar 22, 2014 at 4:34 AM, Daniel Vetter wrote: > > On Fri, Mar 21, 2014 at 05:51:01PM -0700, Ben Widawsky wrote: > >> Let's try this again. I've pushed a branch here: > >> http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=bdw-backports > >> > >> I need to re-review some of the merge conflicts for 4g GGTT, which I > >> will try to do before Monday. > >> > >> Daniel: please make sure this is what you had in mind. I don't know > >> where you want Cc: stable tags. > > > > We don't need cc: stable, we just need to submit it (since it has the > > upstream sha1s already, which is the requirement for stable patches). Cc: > > stable is only for when you want it to get backport anyway. Otherwise > > looks good. I dunno whether git cherry-pick can be told to use the sha1 > > reference layout Greg prefers or not, he uses "This is in > > upstream." between the commit header and the actual commit message. But > > ime his scripts reformat your commit messages anyway. > > > >> James: please test this as soon as possible. > > > > Once this is tested and we conclude it's sufficient to get bdw going on > > 3.14 without hilarity I think we should do a quick review on intel-gfx to > > check that the impact outside of bdw is indeed minimal. Then once drm-next > > has landed with all the referenced commits we can submit it to Greg with a > > small cover letter why we want this and that plan B would be to kill bdw > > in 3.14. > > This seems to be working well for me, with the one caveat that on boot > and once per resume I'm hitting the WARN(!i915_preliminary_hw_support, > "GEN8_CENTROID_PIXEL_OPT_DIS not be needed for production") code in > gen8_init_clock_gating - can that WARN be dropped via "drm/i915: Don't > use i915_preliminary_hw_support to mean pre-production" ? > > Both with and without that patch added, the series is: > > Tested-by: James Ausmus Thanks. Daniel, the patch is added to my backports branch. I think given that that it removes a WARN which we know to be bogus, it's a good patch for stable. But it's your call. [snip] -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Broadwell 3.14 backports
On Sat, Mar 22, 2014 at 4:34 AM, Daniel Vetter wrote: > On Fri, Mar 21, 2014 at 05:51:01PM -0700, Ben Widawsky wrote: >> Let's try this again. I've pushed a branch here: >> http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=bdw-backports >> >> I need to re-review some of the merge conflicts for 4g GGTT, which I >> will try to do before Monday. >> >> Daniel: please make sure this is what you had in mind. I don't know >> where you want Cc: stable tags. > > We don't need cc: stable, we just need to submit it (since it has the > upstream sha1s already, which is the requirement for stable patches). Cc: > stable is only for when you want it to get backport anyway. Otherwise > looks good. I dunno whether git cherry-pick can be told to use the sha1 > reference layout Greg prefers or not, he uses "This is in > upstream." between the commit header and the actual commit message. But > ime his scripts reformat your commit messages anyway. > >> James: please test this as soon as possible. > > Once this is tested and we conclude it's sufficient to get bdw going on > 3.14 without hilarity I think we should do a quick review on intel-gfx to > check that the impact outside of bdw is indeed minimal. Then once drm-next > has landed with all the referenced commits we can submit it to Greg with a > small cover letter why we want this and that plan B would be to kill bdw > in 3.14. This seems to be working well for me, with the one caveat that on boot and once per resume I'm hitting the WARN(!i915_preliminary_hw_support, "GEN8_CENTROID_PIXEL_OPT_DIS not be needed for production") code in gen8_init_clock_gating - can that WARN be dropped via "drm/i915: Don't use i915_preliminary_hw_support to mean pre-production" ? Both with and without that patch added, the series is: Tested-by: James Ausmus > > Thanks for doing this, > Daniel > >> >> Thanks. >> >> >> On Fri, Mar 21, 2014 at 11:48:09AM -0700, Ben Widawsky wrote: >> > The following patches are the backported "simple" fixes for 3.14. Some >> > of these already had Cc: stable on them, but required conflict >> > resolution which I've provided (presumably they canbe dropped if it's >> > easier for upstream). There will be another series of backports which >> > has fixes that require more than a single patch. >> > >> > I will not have a machine to test these on until Monday, but I am >> > mailing them out now in case our QA can get it tested sooner. >> > >> > Ben Widawsky (2): >> > drm/i915/bdw: Use scratch page table for GEN8 PPGTT >> > drm/i915/bdw: Restore PPAT on thaw >> > >> > Damien Lespiau (1): >> > drm/i915/bdw: The TLB invalidation mechanism has been removed from >> > INSTPM >> > >> > Jani Nikula (1): >> > drm/i915: don't flood the logs about bdw semaphores >> > >> > Kenneth Graunke (2): >> > drm/i915: Add a partial instruction shootdown workaround on Broadwell. >> > drm/i915: Add thread stall DOP clock gating workaround on Broadwell. >> > >> > Mika Kuoppala (2): >> > drm/i915: Fix forcewake counts for gen8 >> > drm/i915: Do forcewake reset on gen8 >> > >> > Ville Syrjälä (4): >> > drm/i915: Disable semaphore wait event idle message on BDW >> > drm/i915: Implement WaDisableSDEUnitClockGating:bdw >> > drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw >> > drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW >> > >> > drivers/gpu/drm/i915/i915_drv.c | 5 - >> > drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++ >> > drivers/gpu/drm/i915/i915_reg.h | 10 ++ >> > drivers/gpu/drm/i915/intel_pm.c | 18 -- >> > drivers/gpu/drm/i915/intel_ringbuffer.c | 12 +--- >> > drivers/gpu/drm/i915/intel_uncore.c | 29 +++-- >> > 6 files changed, 61 insertions(+), 20 deletions(-) >> > >> > -- >> > 1.9.1 >> > >> > ___ >> > Intel-gfx mailing list >> > Intel-gfx@lists.freedesktop.org >> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx >> >> -- >> Ben Widawsky, Intel Open Source Technology Center > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- James Ausmus Sr. Software Engineer SSG-OTC ChromeOS Integration ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Broadwell 3.14 backports
On Fri, Mar 21, 2014 at 05:51:01PM -0700, Ben Widawsky wrote: > Let's try this again. I've pushed a branch here: > http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=bdw-backports > > I need to re-review some of the merge conflicts for 4g GGTT, which I > will try to do before Monday. > > Daniel: please make sure this is what you had in mind. I don't know > where you want Cc: stable tags. We don't need cc: stable, we just need to submit it (since it has the upstream sha1s already, which is the requirement for stable patches). Cc: stable is only for when you want it to get backport anyway. Otherwise looks good. I dunno whether git cherry-pick can be told to use the sha1 reference layout Greg prefers or not, he uses "This is in upstream." between the commit header and the actual commit message. But ime his scripts reformat your commit messages anyway. > James: please test this as soon as possible. Once this is tested and we conclude it's sufficient to get bdw going on 3.14 without hilarity I think we should do a quick review on intel-gfx to check that the impact outside of bdw is indeed minimal. Then once drm-next has landed with all the referenced commits we can submit it to Greg with a small cover letter why we want this and that plan B would be to kill bdw in 3.14. Thanks for doing this, Daniel > > Thanks. > > > On Fri, Mar 21, 2014 at 11:48:09AM -0700, Ben Widawsky wrote: > > The following patches are the backported "simple" fixes for 3.14. Some > > of these already had Cc: stable on them, but required conflict > > resolution which I've provided (presumably they canbe dropped if it's > > easier for upstream). There will be another series of backports which > > has fixes that require more than a single patch. > > > > I will not have a machine to test these on until Monday, but I am > > mailing them out now in case our QA can get it tested sooner. > > > > Ben Widawsky (2): > > drm/i915/bdw: Use scratch page table for GEN8 PPGTT > > drm/i915/bdw: Restore PPAT on thaw > > > > Damien Lespiau (1): > > drm/i915/bdw: The TLB invalidation mechanism has been removed from > > INSTPM > > > > Jani Nikula (1): > > drm/i915: don't flood the logs about bdw semaphores > > > > Kenneth Graunke (2): > > drm/i915: Add a partial instruction shootdown workaround on Broadwell. > > drm/i915: Add thread stall DOP clock gating workaround on Broadwell. > > > > Mika Kuoppala (2): > > drm/i915: Fix forcewake counts for gen8 > > drm/i915: Do forcewake reset on gen8 > > > > Ville Syrjälä (4): > > drm/i915: Disable semaphore wait event idle message on BDW > > drm/i915: Implement WaDisableSDEUnitClockGating:bdw > > drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw > > drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW > > > > drivers/gpu/drm/i915/i915_drv.c | 5 - > > drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++ > > drivers/gpu/drm/i915/i915_reg.h | 10 ++ > > drivers/gpu/drm/i915/intel_pm.c | 18 -- > > drivers/gpu/drm/i915/intel_ringbuffer.c | 12 +--- > > drivers/gpu/drm/i915/intel_uncore.c | 29 +++-- > > 6 files changed, 61 insertions(+), 20 deletions(-) > > > > -- > > 1.9.1 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Ben Widawsky, Intel Open Source Technology Center -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Broadwell 3.14 backports
On Fri, Mar 21, 2014 at 05:17:34PM -0700, Ben Widawsky wrote: > On Fri, Mar 21, 2014 at 05:06:06PM -0700, Ben Widawsky wrote: > > On Fri, Mar 21, 2014 at 04:47:05PM -0700, Greg KH wrote: > > > I have no idea what is going on here, what this original email was from > > > / about, or what I am supposed to do here... > > > > > > The stable patch process is pretty well defined, and documented, is that > > > lacking somehow, and if so, in what? > > > > > > greg k-h > > > > My apologies, I didn't understand what Daniel had originally wanted from > > me, and I think the plan changed a bit in flight. I'm sorry you got > > dragged into it. The stable process documentation is perfectly adequate. > > > > And if it wasn't clear, like Daniel said, please ignore these 12 patches > for now. Sorry again. For clarification: BDW support was enabled for the first time in 3.14, but in the -rc phase suddenly lots of workaround patches and little fixes start to pile in. Since pretty much no one has the hardware already I decided to withold all bdw fixes and queued them for -next. Once it all stabilized we could then reevaluate whether bdw support in 3.14 makes sense or not, i.e. whether to backport a pile of fixes or just disable it again. bdw seems to have calmed down now and it doesn't look too bad (it's a bit more than these 12 patches here, but all fairly isolated), so I've asked Ben to assemble the required patches, backport and test them and then submit it all to stable (once drm-next has landed, ofc). Ben was a bit overeager and submitted them to stable a bit too early ;-) My apologies for the fuzz and my unclear communication. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Broadwell 3.14 backports
Let's try this again. I've pushed a branch here: http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=bdw-backports I need to re-review some of the merge conflicts for 4g GGTT, which I will try to do before Monday. Daniel: please make sure this is what you had in mind. I don't know where you want Cc: stable tags. James: please test this as soon as possible. Thanks. On Fri, Mar 21, 2014 at 11:48:09AM -0700, Ben Widawsky wrote: > The following patches are the backported "simple" fixes for 3.14. Some > of these already had Cc: stable on them, but required conflict > resolution which I've provided (presumably they canbe dropped if it's > easier for upstream). There will be another series of backports which > has fixes that require more than a single patch. > > I will not have a machine to test these on until Monday, but I am > mailing them out now in case our QA can get it tested sooner. > > Ben Widawsky (2): > drm/i915/bdw: Use scratch page table for GEN8 PPGTT > drm/i915/bdw: Restore PPAT on thaw > > Damien Lespiau (1): > drm/i915/bdw: The TLB invalidation mechanism has been removed from > INSTPM > > Jani Nikula (1): > drm/i915: don't flood the logs about bdw semaphores > > Kenneth Graunke (2): > drm/i915: Add a partial instruction shootdown workaround on Broadwell. > drm/i915: Add thread stall DOP clock gating workaround on Broadwell. > > Mika Kuoppala (2): > drm/i915: Fix forcewake counts for gen8 > drm/i915: Do forcewake reset on gen8 > > Ville Syrjälä (4): > drm/i915: Disable semaphore wait event idle message on BDW > drm/i915: Implement WaDisableSDEUnitClockGating:bdw > drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw > drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW > > drivers/gpu/drm/i915/i915_drv.c | 5 - > drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++ > drivers/gpu/drm/i915/i915_reg.h | 10 ++ > drivers/gpu/drm/i915/intel_pm.c | 18 -- > drivers/gpu/drm/i915/intel_ringbuffer.c | 12 +--- > drivers/gpu/drm/i915/intel_uncore.c | 29 +++-- > 6 files changed, 61 insertions(+), 20 deletions(-) > > -- > 1.9.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Broadwell 3.14 backports
On Fri, Mar 21, 2014 at 05:06:06PM -0700, Ben Widawsky wrote: > On Fri, Mar 21, 2014 at 04:47:05PM -0700, Greg KH wrote: > > On Fri, Mar 21, 2014 at 03:14:48PM -0700, Ben Widawsky wrote: > > > On Fri, Mar 21, 2014 at 08:49:35PM +0100, Daniel Vetter wrote: > > > > On Fri, Mar 21, 2014 at 7:48 PM, Ben Widawsky > > > > wrote: > > > > > The following patches are the backported "simple" fixes for 3.14. Some > > > > > of these already had Cc: stable on them, but required conflict > > > > > resolution which I've provided (presumably they canbe dropped if it's > > > > > easier for upstream). There will be another series of backports which > > > > > has fixes that require more than a single patch. > > > > > > > > > > I will not have a machine to test these on until Monday, but I am > > > > > mailing them out now in case our QA can get it tested sooner. > > > > > > > > > > Ben Widawsky (2): > > > > > drm/i915/bdw: Use scratch page table for GEN8 PPGTT > > > > > drm/i915/bdw: Restore PPAT on thaw > > > > > > > > > > Damien Lespiau (1): > > > > > drm/i915/bdw: The TLB invalidation mechanism has been removed from > > > > > INSTPM > > > > > > > > > > Jani Nikula (1): > > > > > drm/i915: don't flood the logs about bdw semaphores > > > > > > > > > > Kenneth Graunke (2): > > > > > drm/i915: Add a partial instruction shootdown workaround on > > > > > Broadwell. > > > > > drm/i915: Add thread stall DOP clock gating workaround on Broadwell. > > > > > > > > > > Mika Kuoppala (2): > > > > > drm/i915: Fix forcewake counts for gen8 > > > > > drm/i915: Do forcewake reset on gen8 > > > > > > > > > > Ville Syrjälä (4): > > > > > drm/i915: Disable semaphore wait event idle message on BDW > > > > > drm/i915: Implement WaDisableSDEUnitClockGating:bdw > > > > > drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw > > > > > drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW > > > > > > > > The stable team requires a reference to the sha1 of the upstream > > > > commit, which your patches seem to lack. git cherry-pick -x > > > > automatically adds that for you. > > > > > > I decided not to do this because in the git help it says, > > > "This is done only for cherry picks without conflicts." I believe only > > > one of these patches didn't actually have a conflict (so I should have > > > done it for that). So I will assume I should ignore this recommendation > > > from the git help. I didn't want to make it seem like these patches did > > > not have conflicts. > > > > > > > > > > > Also please don't send out backports to stable if we still want to do > > > > some testing on them. Adding Greg and stable so he knows that he can > > > > bin this series for now. Of course all the patches in here which > > > > already have cc: stable in upstream should still go through the normal > > > > process (presuming they don't conflict ofc). But since most of these > > > > patches are from drm-intel-next we must wait anyway until drm-next has > > > > been merged into Linus' tree. > > > > > > > > > > Since you added Greg, I am curious - as noted in the cover letter, I've > > > done the merge conflict resolution on the patches which already had Cc: > > > stable. I didn't intentionally include any patches which already had Cc: > > > stable and didn't require conflict resolution. Are those > > > interesting/useful, should I drop them from the series? > > > > I have no idea what is going on here, what this original email was from > > / about, or what I am supposed to do here... > > > > The stable patch process is pretty well defined, and documented, is that > > lacking somehow, and if so, in what? > > > > greg k-h > > My apologies, I didn't understand what Daniel had originally wanted from > me, and I think the plan changed a bit in flight. I'm sorry you got > dragged into it. The stable process documentation is perfectly adequate. > And if it wasn't clear, like Daniel said, please ignore these 12 patches for now. Sorry again. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Broadwell 3.14 backports
On Fri, Mar 21, 2014 at 04:47:05PM -0700, Greg KH wrote: > On Fri, Mar 21, 2014 at 03:14:48PM -0700, Ben Widawsky wrote: > > On Fri, Mar 21, 2014 at 08:49:35PM +0100, Daniel Vetter wrote: > > > On Fri, Mar 21, 2014 at 7:48 PM, Ben Widawsky > > > wrote: > > > > The following patches are the backported "simple" fixes for 3.14. Some > > > > of these already had Cc: stable on them, but required conflict > > > > resolution which I've provided (presumably they canbe dropped if it's > > > > easier for upstream). There will be another series of backports which > > > > has fixes that require more than a single patch. > > > > > > > > I will not have a machine to test these on until Monday, but I am > > > > mailing them out now in case our QA can get it tested sooner. > > > > > > > > Ben Widawsky (2): > > > > drm/i915/bdw: Use scratch page table for GEN8 PPGTT > > > > drm/i915/bdw: Restore PPAT on thaw > > > > > > > > Damien Lespiau (1): > > > > drm/i915/bdw: The TLB invalidation mechanism has been removed from > > > > INSTPM > > > > > > > > Jani Nikula (1): > > > > drm/i915: don't flood the logs about bdw semaphores > > > > > > > > Kenneth Graunke (2): > > > > drm/i915: Add a partial instruction shootdown workaround on Broadwell. > > > > drm/i915: Add thread stall DOP clock gating workaround on Broadwell. > > > > > > > > Mika Kuoppala (2): > > > > drm/i915: Fix forcewake counts for gen8 > > > > drm/i915: Do forcewake reset on gen8 > > > > > > > > Ville Syrjälä (4): > > > > drm/i915: Disable semaphore wait event idle message on BDW > > > > drm/i915: Implement WaDisableSDEUnitClockGating:bdw > > > > drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw > > > > drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW > > > > > > The stable team requires a reference to the sha1 of the upstream > > > commit, which your patches seem to lack. git cherry-pick -x > > > automatically adds that for you. > > > > I decided not to do this because in the git help it says, > > "This is done only for cherry picks without conflicts." I believe only > > one of these patches didn't actually have a conflict (so I should have > > done it for that). So I will assume I should ignore this recommendation > > from the git help. I didn't want to make it seem like these patches did > > not have conflicts. > > > > > > > > Also please don't send out backports to stable if we still want to do > > > some testing on them. Adding Greg and stable so he knows that he can > > > bin this series for now. Of course all the patches in here which > > > already have cc: stable in upstream should still go through the normal > > > process (presuming they don't conflict ofc). But since most of these > > > patches are from drm-intel-next we must wait anyway until drm-next has > > > been merged into Linus' tree. > > > > > > > Since you added Greg, I am curious - as noted in the cover letter, I've > > done the merge conflict resolution on the patches which already had Cc: > > stable. I didn't intentionally include any patches which already had Cc: > > stable and didn't require conflict resolution. Are those > > interesting/useful, should I drop them from the series? > > I have no idea what is going on here, what this original email was from > / about, or what I am supposed to do here... > > The stable patch process is pretty well defined, and documented, is that > lacking somehow, and if so, in what? > > greg k-h My apologies, I didn't understand what Daniel had originally wanted from me, and I think the plan changed a bit in flight. I'm sorry you got dragged into it. The stable process documentation is perfectly adequate. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Broadwell 3.14 backports
On Fri, Mar 21, 2014 at 03:14:48PM -0700, Ben Widawsky wrote: > On Fri, Mar 21, 2014 at 08:49:35PM +0100, Daniel Vetter wrote: > > On Fri, Mar 21, 2014 at 7:48 PM, Ben Widawsky > > wrote: > > > The following patches are the backported "simple" fixes for 3.14. Some > > > of these already had Cc: stable on them, but required conflict > > > resolution which I've provided (presumably they canbe dropped if it's > > > easier for upstream). There will be another series of backports which > > > has fixes that require more than a single patch. > > > > > > I will not have a machine to test these on until Monday, but I am > > > mailing them out now in case our QA can get it tested sooner. > > > > > > Ben Widawsky (2): > > > drm/i915/bdw: Use scratch page table for GEN8 PPGTT > > > drm/i915/bdw: Restore PPAT on thaw > > > > > > Damien Lespiau (1): > > > drm/i915/bdw: The TLB invalidation mechanism has been removed from > > > INSTPM > > > > > > Jani Nikula (1): > > > drm/i915: don't flood the logs about bdw semaphores > > > > > > Kenneth Graunke (2): > > > drm/i915: Add a partial instruction shootdown workaround on Broadwell. > > > drm/i915: Add thread stall DOP clock gating workaround on Broadwell. > > > > > > Mika Kuoppala (2): > > > drm/i915: Fix forcewake counts for gen8 > > > drm/i915: Do forcewake reset on gen8 > > > > > > Ville Syrjälä (4): > > > drm/i915: Disable semaphore wait event idle message on BDW > > > drm/i915: Implement WaDisableSDEUnitClockGating:bdw > > > drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw > > > drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW > > > > The stable team requires a reference to the sha1 of the upstream > > commit, which your patches seem to lack. git cherry-pick -x > > automatically adds that for you. > > I decided not to do this because in the git help it says, > "This is done only for cherry picks without conflicts." I believe only > one of these patches didn't actually have a conflict (so I should have > done it for that). So I will assume I should ignore this recommendation > from the git help. I didn't want to make it seem like these patches did > not have conflicts. > > > > > Also please don't send out backports to stable if we still want to do > > some testing on them. Adding Greg and stable so he knows that he can > > bin this series for now. Of course all the patches in here which > > already have cc: stable in upstream should still go through the normal > > process (presuming they don't conflict ofc). But since most of these > > patches are from drm-intel-next we must wait anyway until drm-next has > > been merged into Linus' tree. > > > > Since you added Greg, I am curious - as noted in the cover letter, I've > done the merge conflict resolution on the patches which already had Cc: > stable. I didn't intentionally include any patches which already had Cc: > stable and didn't require conflict resolution. Are those > interesting/useful, should I drop them from the series? I have no idea what is going on here, what this original email was from / about, or what I am supposed to do here... The stable patch process is pretty well defined, and documented, is that lacking somehow, and if so, in what? greg k-h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Broadwell 3.14 backports
On Fri, Mar 21, 2014 at 08:49:35PM +0100, Daniel Vetter wrote: > On Fri, Mar 21, 2014 at 7:48 PM, Ben Widawsky > wrote: > > The following patches are the backported "simple" fixes for 3.14. Some > > of these already had Cc: stable on them, but required conflict > > resolution which I've provided (presumably they canbe dropped if it's > > easier for upstream). There will be another series of backports which > > has fixes that require more than a single patch. > > > > I will not have a machine to test these on until Monday, but I am > > mailing them out now in case our QA can get it tested sooner. > > > > Ben Widawsky (2): > > drm/i915/bdw: Use scratch page table for GEN8 PPGTT > > drm/i915/bdw: Restore PPAT on thaw > > > > Damien Lespiau (1): > > drm/i915/bdw: The TLB invalidation mechanism has been removed from > > INSTPM > > > > Jani Nikula (1): > > drm/i915: don't flood the logs about bdw semaphores > > > > Kenneth Graunke (2): > > drm/i915: Add a partial instruction shootdown workaround on Broadwell. > > drm/i915: Add thread stall DOP clock gating workaround on Broadwell. > > > > Mika Kuoppala (2): > > drm/i915: Fix forcewake counts for gen8 > > drm/i915: Do forcewake reset on gen8 > > > > Ville Syrjälä (4): > > drm/i915: Disable semaphore wait event idle message on BDW > > drm/i915: Implement WaDisableSDEUnitClockGating:bdw > > drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw > > drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW > > The stable team requires a reference to the sha1 of the upstream > commit, which your patches seem to lack. git cherry-pick -x > automatically adds that for you. I decided not to do this because in the git help it says, "This is done only for cherry picks without conflicts." I believe only one of these patches didn't actually have a conflict (so I should have done it for that). So I will assume I should ignore this recommendation from the git help. I didn't want to make it seem like these patches did not have conflicts. > > Also please don't send out backports to stable if we still want to do > some testing on them. Adding Greg and stable so he knows that he can > bin this series for now. Of course all the patches in here which > already have cc: stable in upstream should still go through the normal > process (presuming they don't conflict ofc). But since most of these > patches are from drm-intel-next we must wait anyway until drm-next has > been merged into Linus' tree. > Since you added Greg, I am curious - as noted in the cover letter, I've done the merge conflict resolution on the patches which already had Cc: stable. I didn't intentionally include any patches which already had Cc: stable and didn't require conflict resolution. Are those interesting/useful, should I drop them from the series? > Thanks, Daniel > > > > > drivers/gpu/drm/i915/i915_drv.c | 5 - > > drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++ > > drivers/gpu/drm/i915/i915_reg.h | 10 ++ > > drivers/gpu/drm/i915/intel_pm.c | 18 -- > > drivers/gpu/drm/i915/intel_ringbuffer.c | 12 +--- > > drivers/gpu/drm/i915/intel_uncore.c | 29 +++-- > > 6 files changed, 61 insertions(+), 20 deletions(-) > > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Broadwell 3.14 backports
On Fri, Mar 21, 2014 at 7:48 PM, Ben Widawsky wrote: > The following patches are the backported "simple" fixes for 3.14. Some > of these already had Cc: stable on them, but required conflict > resolution which I've provided (presumably they canbe dropped if it's > easier for upstream). There will be another series of backports which > has fixes that require more than a single patch. > > I will not have a machine to test these on until Monday, but I am > mailing them out now in case our QA can get it tested sooner. > > Ben Widawsky (2): > drm/i915/bdw: Use scratch page table for GEN8 PPGTT > drm/i915/bdw: Restore PPAT on thaw > > Damien Lespiau (1): > drm/i915/bdw: The TLB invalidation mechanism has been removed from > INSTPM > > Jani Nikula (1): > drm/i915: don't flood the logs about bdw semaphores > > Kenneth Graunke (2): > drm/i915: Add a partial instruction shootdown workaround on Broadwell. > drm/i915: Add thread stall DOP clock gating workaround on Broadwell. > > Mika Kuoppala (2): > drm/i915: Fix forcewake counts for gen8 > drm/i915: Do forcewake reset on gen8 > > Ville Syrjälä (4): > drm/i915: Disable semaphore wait event idle message on BDW > drm/i915: Implement WaDisableSDEUnitClockGating:bdw > drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw > drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW The stable team requires a reference to the sha1 of the upstream commit, which your patches seem to lack. git cherry-pick -x automatically adds that for you. Also please don't send out backports to stable if we still want to do some testing on them. Adding Greg and stable so he knows that he can bin this series for now. Of course all the patches in here which already have cc: stable in upstream should still go through the normal process (presuming they don't conflict ofc). But since most of these patches are from drm-intel-next we must wait anyway until drm-next has been merged into Linus' tree. Thanks, Daniel > > drivers/gpu/drm/i915/i915_drv.c | 5 - > drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++ > drivers/gpu/drm/i915/i915_reg.h | 10 ++ > drivers/gpu/drm/i915/intel_pm.c | 18 -- > drivers/gpu/drm/i915/intel_ringbuffer.c | 12 +--- > drivers/gpu/drm/i915/intel_uncore.c | 29 +++-- > 6 files changed, 61 insertions(+), 20 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/12] Broadwell 3.14 backports
The following patches are the backported "simple" fixes for 3.14. Some of these already had Cc: stable on them, but required conflict resolution which I've provided (presumably they canbe dropped if it's easier for upstream). There will be another series of backports which has fixes that require more than a single patch. I will not have a machine to test these on until Monday, but I am mailing them out now in case our QA can get it tested sooner. Ben Widawsky (2): drm/i915/bdw: Use scratch page table for GEN8 PPGTT drm/i915/bdw: Restore PPAT on thaw Damien Lespiau (1): drm/i915/bdw: The TLB invalidation mechanism has been removed from INSTPM Jani Nikula (1): drm/i915: don't flood the logs about bdw semaphores Kenneth Graunke (2): drm/i915: Add a partial instruction shootdown workaround on Broadwell. drm/i915: Add thread stall DOP clock gating workaround on Broadwell. Mika Kuoppala (2): drm/i915: Fix forcewake counts for gen8 drm/i915: Do forcewake reset on gen8 Ville Syrjälä (4): drm/i915: Disable semaphore wait event idle message on BDW drm/i915: Implement WaDisableSDEUnitClockGating:bdw drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW drivers/gpu/drm/i915/i915_drv.c | 5 - drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++ drivers/gpu/drm/i915/i915_reg.h | 10 ++ drivers/gpu/drm/i915/intel_pm.c | 18 -- drivers/gpu/drm/i915/intel_ringbuffer.c | 12 +--- drivers/gpu/drm/i915/intel_uncore.c | 29 +++-- 6 files changed, 61 insertions(+), 20 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
