diff options
| author | Daniel Vetter <daniel.vetter@ffwll.ch> | 2017-07-05 06:56:29 +0200 |
|---|---|---|
| committer | Daniel Vetter <daniel.vetter@ffwll.ch> | 2017-07-06 10:02:01 +0200 |
| commit | e13a058310509b22b2b45cbdd82d8797e173c3db (patch) | |
| tree | 27f10eafafffccfd27ad744a7fc7da60c7970948 /drivers/gpu/drm/drm_vblank.c | |
| parent | drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy (diff) | |
| download | linux-e13a058310509b22b2b45cbdd82d8797e173c3db.tar.xz linux-e13a058310509b22b2b45cbdd82d8797e173c3db.zip | |
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
Diffstat (limited to 'drivers/gpu/drm/drm_vblank.c')
| -rw-r--r-- | drivers/gpu/drm/drm_vblank.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 05d043e9219f..8099574c8a11 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/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. |