drm/fb-helper: Stop using mode_config.mutex for internals

Those are now all protected using fb_helper->lock.

v2: We still need to hold mode_config.mutex right around calling
connector->fill_modes.

v3: I forgot to hold mode_config.mutex while looking at
connector->status and the mode list. Also, we need to patch up the
i915 ->initial_config callback to grab the locks it needs to inspect
the modeset state recovered from the fw.

v4: Don't reorder the probe too much (Ville).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170705045629.31265-1-daniel.vetter@ffwll.ch

drivers/gpu/drm/drm_vblank.c

@@ -836,7 +836,7 @@ static void send_vblank_event(struct drm_device *dev,
  * NOTE: Drivers using this to send out the &drm_crtc_state.event as part of an
  * atomic commit must ensure that the next vblank happens at exactly the same
  * time as the atomic commit is committed to the hardware. This function itself
- * does **not** protect again the next vblank interrupt racing with either this
+ * does **not** protect against the next vblank interrupt racing with either this
  * function call or the atomic commit operation. A possible sequence could be:
  *
  * 1. Driver commits new hardware state into vblank-synchronized registers.