From: Daniel Vetter <daniel@ffwll.ch> To: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Subject: Re: linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree Date: Tue, 14 Jul 2015 09:34:36 +0200 [thread overview] Message-ID: <20150714073436.GA3736@phenom.ffwll.local> (raw) In-Reply-To: <20150714121112.29dc5e75@canb.auug.org.au> On Tue, Jul 14, 2015 at 12:11:12PM +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the drm-intel tree got a conflict in: > > drivers/gpu/drm/i915/intel_display.c > > between commit: > > 8aa3053bf731 ("drm/i915: fix oops in primary_check_plane") > > from the drm-intel-fixes tree and commit: > > da20eabd2c69 ("drm/i915: Split plane updates of crtc->atomic into a helper, v2.") > > from the drm-intel tree. > > I fixed it up (but it probably needs more - see below) and can carry > the fix as necessary. > > Daniel, can you please merge your fixes branch into your main branch > (maybe after Linus has merged it) and fix these conflicts correctly as > these conflicts tend to go on and on as the files get changed. Well the problem is that they indeed go on and on and we still change them so they resurface all the time. I've done a few backmerges in my next branch already, I plan to do the next backmerge somewhen this week. Sorry about all the pain this is causing. -Daniel > > -- > Cheers, > Stephen Rothwell sfr@canb.auug.org.au > > diff --cc drivers/gpu/drm/i915/intel_display.c > index 85ac6d85dc39,00c60c1c5162..000000000000 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@@ -4851,25 -4802,13 +4802,16 @@@ static void intel_crtc_disable_planes(s > { > struct drm_device *dev = crtc->dev; > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > - struct intel_plane *intel_plane; > + struct drm_plane *p; > int pipe = intel_crtc->pipe; > > + if (!intel_crtc->active) > + return; > + > - intel_crtc_wait_for_pending_flips(crtc); > - > - intel_pre_disable_primary(crtc); > - > intel_crtc_dpms_overlay_disable(intel_crtc); > - for_each_intel_plane(dev, intel_plane) { > - if (intel_plane->pipe == pipe) { > - struct drm_crtc *from = intel_plane->base.crtc; > > - intel_plane->disable_plane(&intel_plane->base, > - from ?: crtc, true); > - } > - } > + drm_for_each_plane_mask(p, dev, plane_mask) > + to_intel_plane(p)->disable_plane(p, crtc); > > /* > * FIXME: Once we grow proper nuclear flip support out of this we need > @@@ -13382,47 -13751,11 +13757,14 @@@ static void intel_begin_crtc_commit(str > struct drm_device *dev = crtc->dev; > struct drm_i915_private *dev_priv = dev->dev_private; > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > - struct intel_plane *intel_plane; > - struct drm_plane *p; > - unsigned fb_bits = 0; > - > - /* Track fb's for any planes being disabled */ > - list_for_each_entry(p, &dev->mode_config.plane_list, head) { > - intel_plane = to_intel_plane(p); > - > - if (intel_crtc->atomic.disabled_planes & > - (1 << drm_plane_index(p))) { > - switch (p->type) { > - case DRM_PLANE_TYPE_PRIMARY: > - fb_bits = INTEL_FRONTBUFFER_PRIMARY(intel_plane->pipe); > - break; > - case DRM_PLANE_TYPE_CURSOR: > - fb_bits = INTEL_FRONTBUFFER_CURSOR(intel_plane->pipe); > - break; > - case DRM_PLANE_TYPE_OVERLAY: > - fb_bits = INTEL_FRONTBUFFER_SPRITE(intel_plane->pipe); > - break; > - } > > - mutex_lock(&dev->struct_mutex); > - i915_gem_track_fb(intel_fb_obj(p->fb), NULL, fb_bits); > - mutex_unlock(&dev->struct_mutex); > - } > - } > - > - if (intel_crtc->atomic.wait_for_flips) > - intel_crtc_wait_for_pending_flips(crtc); > - > - if (intel_crtc->atomic.disable_fbc) > - intel_fbc_disable(dev); > + if (!needs_modeset(crtc->state)) > + intel_pre_plane_update(intel_crtc); > > + if (intel_crtc->atomic.disable_ips) > + hsw_disable_ips(intel_crtc); > + > - if (intel_crtc->atomic.pre_disable_primary) > - intel_pre_disable_primary(crtc); > - > - if (intel_crtc->atomic.update_wm) > + if (intel_crtc->atomic.update_wm_pre) > intel_update_watermarks(crtc); > > intel_runtime_pm_get(dev_priv); -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch> To: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-next@vger.kernel.org Subject: Re: linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree Date: Tue, 14 Jul 2015 09:34:36 +0200 [thread overview] Message-ID: <20150714073436.GA3736@phenom.ffwll.local> (raw) In-Reply-To: <20150714121112.29dc5e75@canb.auug.org.au> On Tue, Jul 14, 2015 at 12:11:12PM +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the drm-intel tree got a conflict in: > > drivers/gpu/drm/i915/intel_display.c > > between commit: > > 8aa3053bf731 ("drm/i915: fix oops in primary_check_plane") > > from the drm-intel-fixes tree and commit: > > da20eabd2c69 ("drm/i915: Split plane updates of crtc->atomic into a helper, v2.") > > from the drm-intel tree. > > I fixed it up (but it probably needs more - see below) and can carry > the fix as necessary. > > Daniel, can you please merge your fixes branch into your main branch > (maybe after Linus has merged it) and fix these conflicts correctly as > these conflicts tend to go on and on as the files get changed. Well the problem is that they indeed go on and on and we still change them so they resurface all the time. I've done a few backmerges in my next branch already, I plan to do the next backmerge somewhen this week. Sorry about all the pain this is causing. -Daniel > > -- > Cheers, > Stephen Rothwell sfr@canb.auug.org.au > > diff --cc drivers/gpu/drm/i915/intel_display.c > index 85ac6d85dc39,00c60c1c5162..000000000000 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@@ -4851,25 -4802,13 +4802,16 @@@ static void intel_crtc_disable_planes(s > { > struct drm_device *dev = crtc->dev; > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > - struct intel_plane *intel_plane; > + struct drm_plane *p; > int pipe = intel_crtc->pipe; > > + if (!intel_crtc->active) > + return; > + > - intel_crtc_wait_for_pending_flips(crtc); > - > - intel_pre_disable_primary(crtc); > - > intel_crtc_dpms_overlay_disable(intel_crtc); > - for_each_intel_plane(dev, intel_plane) { > - if (intel_plane->pipe == pipe) { > - struct drm_crtc *from = intel_plane->base.crtc; > > - intel_plane->disable_plane(&intel_plane->base, > - from ?: crtc, true); > - } > - } > + drm_for_each_plane_mask(p, dev, plane_mask) > + to_intel_plane(p)->disable_plane(p, crtc); > > /* > * FIXME: Once we grow proper nuclear flip support out of this we need > @@@ -13382,47 -13751,11 +13757,14 @@@ static void intel_begin_crtc_commit(str > struct drm_device *dev = crtc->dev; > struct drm_i915_private *dev_priv = dev->dev_private; > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > - struct intel_plane *intel_plane; > - struct drm_plane *p; > - unsigned fb_bits = 0; > - > - /* Track fb's for any planes being disabled */ > - list_for_each_entry(p, &dev->mode_config.plane_list, head) { > - intel_plane = to_intel_plane(p); > - > - if (intel_crtc->atomic.disabled_planes & > - (1 << drm_plane_index(p))) { > - switch (p->type) { > - case DRM_PLANE_TYPE_PRIMARY: > - fb_bits = INTEL_FRONTBUFFER_PRIMARY(intel_plane->pipe); > - break; > - case DRM_PLANE_TYPE_CURSOR: > - fb_bits = INTEL_FRONTBUFFER_CURSOR(intel_plane->pipe); > - break; > - case DRM_PLANE_TYPE_OVERLAY: > - fb_bits = INTEL_FRONTBUFFER_SPRITE(intel_plane->pipe); > - break; > - } > > - mutex_lock(&dev->struct_mutex); > - i915_gem_track_fb(intel_fb_obj(p->fb), NULL, fb_bits); > - mutex_unlock(&dev->struct_mutex); > - } > - } > - > - if (intel_crtc->atomic.wait_for_flips) > - intel_crtc_wait_for_pending_flips(crtc); > - > - if (intel_crtc->atomic.disable_fbc) > - intel_fbc_disable(dev); > + if (!needs_modeset(crtc->state)) > + intel_pre_plane_update(intel_crtc); > > + if (intel_crtc->atomic.disable_ips) > + hsw_disable_ips(intel_crtc); > + > - if (intel_crtc->atomic.pre_disable_primary) > - intel_pre_disable_primary(crtc); > - > - if (intel_crtc->atomic.update_wm) > + if (intel_crtc->atomic.update_wm_pre) > intel_update_watermarks(crtc); > > intel_runtime_pm_get(dev_priv); -- 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
next prev parent reply other threads:[~2015-07-14 7:31 UTC|newest] Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-07-14 2:11 linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree Stephen Rothwell 2015-07-14 2:11 ` Stephen Rothwell 2015-07-14 7:34 ` Daniel Vetter [this message] 2015-07-14 7:34 ` Daniel Vetter -- strict thread matches above, loose matches on Subject: below -- 2022-02-25 17:08 broonie 2022-02-25 17:08 ` broonie 2022-02-23 14:46 broonie 2022-02-23 14:46 ` broonie 2022-02-02 23:59 Stephen Rothwell 2022-02-02 23:59 ` Stephen Rothwell 2021-08-02 15:18 Mark Brown 2020-06-30 1:52 Stephen Rothwell 2020-06-30 1:52 ` Stephen Rothwell 2020-07-06 1:51 ` Stephen Rothwell 2020-07-06 1:51 ` Stephen Rothwell 2020-03-11 2:36 Stephen Rothwell 2020-03-11 2:36 ` Stephen Rothwell 2020-03-20 1:57 ` Stephen Rothwell 2020-03-20 1:57 ` Stephen Rothwell 2019-03-21 23:57 Stephen Rothwell 2019-03-21 23:57 ` Stephen Rothwell 2019-03-31 22:59 ` Stephen Rothwell 2017-10-18 9:27 Mark Brown 2017-10-18 9:27 ` Mark Brown 2017-10-16 11:35 Mark Brown 2017-10-16 11:35 ` Mark Brown 2017-10-17 8:11 ` Arnd Bergmann 2017-10-17 8:11 ` Arnd Bergmann 2017-10-17 8:30 ` Mark Brown 2017-10-17 8:30 ` Mark Brown 2017-10-12 18:44 Mark Brown 2017-10-12 18:44 ` Mark Brown 2017-10-12 18:36 Mark Brown 2017-10-12 18:36 ` Mark Brown 2017-06-08 3:07 Stephen Rothwell 2017-06-08 3:04 Stephen Rothwell 2017-03-21 0:37 Stephen Rothwell 2017-03-21 0:37 ` Stephen Rothwell 2016-08-24 1:42 Stephen Rothwell 2016-08-24 1:42 ` Stephen Rothwell 2016-08-24 1:32 Stephen Rothwell 2016-08-24 1:32 ` Stephen Rothwell 2016-06-22 1:40 Stephen Rothwell 2016-06-22 1:40 ` Stephen Rothwell 2015-11-18 0:30 Stephen Rothwell 2015-11-18 0:30 ` Stephen Rothwell 2015-09-30 1:32 Stephen Rothwell 2015-09-30 1:32 ` Stephen Rothwell 2015-09-24 1:25 Stephen Rothwell 2015-09-24 1:25 ` Stephen Rothwell 2015-09-24 8:57 ` Jani Nikula 2015-09-24 8:57 ` Jani Nikula 2015-09-24 11:52 ` Stephen Rothwell 2015-07-15 0:15 Stephen Rothwell 2015-07-15 0:15 ` Stephen Rothwell 2015-07-10 2:15 Stephen Rothwell 2015-07-10 2:15 ` Stephen Rothwell 2015-07-10 2:08 Stephen Rothwell 2015-07-10 2:08 ` Stephen Rothwell 2015-02-27 0:36 Stephen Rothwell 2015-02-27 0:36 ` Stephen Rothwell 2015-02-26 0:15 Stephen Rothwell 2015-02-26 0:15 ` Stephen Rothwell 2015-02-25 1:05 Stephen Rothwell 2015-02-25 1:05 ` Stephen Rothwell 2015-01-09 2:06 Stephen Rothwell 2015-01-09 2:06 ` Stephen Rothwell 2014-05-22 5:58 Stephen Rothwell 2014-05-22 5:58 ` Stephen Rothwell 2014-04-30 2:37 Stephen Rothwell 2014-04-30 2:37 ` Stephen Rothwell 2013-12-16 1:45 Stephen Rothwell 2013-12-16 1:45 ` Stephen Rothwell 2013-12-02 1:04 Stephen Rothwell 2013-12-02 1:04 ` Stephen Rothwell 2013-12-02 1:13 ` Stephen Rothwell 2013-12-02 1:13 ` Stephen Rothwell 2013-09-25 2:00 Stephen Rothwell 2013-09-25 2:00 ` Stephen Rothwell 2013-09-20 1:40 Stephen Rothwell 2013-09-20 1:40 ` Stephen Rothwell 2013-07-26 3:14 Stephen Rothwell 2013-07-26 3:14 ` Stephen Rothwell 2013-07-26 3:10 Stephen Rothwell 2013-07-26 3:10 ` Stephen Rothwell 2013-07-18 2:07 Stephen Rothwell 2013-07-18 2:07 ` Stephen Rothwell 2013-07-18 1:44 Stephen Rothwell 2013-07-18 1:44 ` Stephen Rothwell 2013-07-16 2:05 Stephen Rothwell 2013-07-16 2:05 ` Stephen Rothwell
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20150714073436.GA3736@phenom.ffwll.local \ --to=daniel@ffwll.ch \ --cc=daniel.vetter@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-next@vger.kernel.org \ --cc=maarten.lankhorst@linux.intel.com \ --cc=sfr@canb.auug.org.au \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.