On Wed, Mar 27, 2013 at 5:54 PM, Jesse Barnes <jbar...@virtuousgeek.org> wrote:
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 3e22305..3672b8d 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -4320,14 +4320,15 @@ static void i9xx_update_pll_dividers(struct drm_crtc
>> *crtc,
>> }
>>
>> static void vlv_update_pll(struct drm_crtc *crtc,
>> - struct drm_display_mode *mode,
>> - struct drm_display_mode *adjusted_mode,
>> intel_clock_t *clock, intel_clock_t *reduced_clock,
>> int num_connectors)
>> {
>> 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 drm_display_mode *adjusted_mode =
>> + &intel_crtc->config.adjusted_mode;
>> + struct drm_display_mode *mode = &intel_crtc->config.requested_mode;
>
> These arg compaction changes could probably be squashed into the
> initial crtc_config patch to make this one smaller.
See my little commit message update, but I've done things in such an
incremental way to avoid rebase hell and allow me to move things
around easier. What you see here is by far not my very first approach
;-)
To make everyone's OCD happy we can do a cleanup pass at the end, but
atm I'd like to avoid massive sed patches - too high churn.
>> @@ -5907,8 +5909,12 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
>> encoder->base.base.id,
>> drm_get_encoder_name(&encoder->base),
>> mode->base.id, mode->name);
>> - encoder_funcs = encoder->base.helper_private;
>> - encoder_funcs->mode_set(&encoder->base, mode, adjusted_mode);
>> + if (encoder->mode_set) {
>> + encoder->mode_set(encoder);
>> + } else {
>> + encoder_funcs = encoder->base.helper_private;
>> + encoder_funcs->mode_set(&encoder->base, mode,
>> adjusted_mode);
>> + }
>> }
>
> This made me do a double take; maybe it's time to
> s/encoder/intel_encoder in this function...
Yeah, we're halfway between mostly using intel_encoder and not so much
drm_encoder. Again, I think we can do a sed jobs once things settle,
meanwhile it's gonna be a bit ugly. Personally I don't care ;-)
-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
