On Fri, Aug 28, 2015 at 11:50:08AM -0300, Paulo Zanoni wrote: > 2015-08-28 11:20 GMT-03:00 Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>: > > On Fri, Aug 14, 2015 at 06:34:07PM -0300, Paulo Zanoni wrote: > >> Always update the currrent crtc, fb and vertical offset after calling > >> enable_fbc. We were forgetting to do so along the failure paths when > >> enabling fbc synchronously. Fix this with a new helper to enable_fbc() > >> and update the state simultaneously. > >> > >> v2: Improve commit message (Chris). > >> > >> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> > >> --- > >> drivers/gpu/drm/i915/intel_fbc.c | 27 +++++++++++++++++---------- > >> 1 file changed, 17 insertions(+), 10 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c > >> index c97aba2..fa9b004 100644 > >> --- a/drivers/gpu/drm/i915/intel_fbc.c > >> +++ b/drivers/gpu/drm/i915/intel_fbc.c > >> @@ -308,6 +308,18 @@ bool intel_fbc_enabled(struct drm_i915_private *dev_priv) > >> return dev_priv->fbc.enabled; > >> } > >> > >> +static void intel_fbc_enable(struct intel_crtc *crtc, > >> + struct drm_framebuffer *fb) > > > > fb could be const > > I guess a lot of things could be constified, if we decide to do this. Personally I like const on .data (especially vfunc tables since those are nice to create exploits if they're writable and you can get at them). And for core functions/vfuncs where the const has a semantic meaning. Otherwise I personally don't see to much value in sprinkling const all over. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
