1. 22 Jul, 2015 9 commits
    • Daniel Vetter's avatar
      drm/radeon: Take all modeset locks for DP MST hotplug · 2ee6bcdc
      Daniel Vetter authored
      Similar with the i915 take all modeset locks for mst hotplug. This is
      needed to make sure radeon holds both mode_config.mutex and
      mode_config.connection_mutex when updating the connector_list, which
      is the new (interim) locking regime we want for that.
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      2ee6bcdc
    • Daniel Vetter's avatar
      drm/i915: Take all modeset locks for DP MST hotplug · 8bb4da1d
      Daniel Vetter authored
      While auditing various users of the connector/encoder lists I realized
      that the atomic code is a very prolific user of them. And it only ever
      grabs the mode_config->connection_mutex, but not the
      mode_config->mutex like all the other code walking encoder/connector
      lists.
      
      The problem is that we can't grab the mode_config.mutex late in atomic
      code since that would lead to locking inversions. And we don't want to
      grab it unconditionally like the legacy set_config modeset path since
      that would render all the fine-grained locking moot.
      
      Instead just grab more locks in the dp mst hotplug code. Note that
      drm_connector_init (which is the one adding the connector to these
      lists) already uses drm_modeset_lock_all.
      
      The other reason for grabbing all locks is that the dpms off in the
      unplug function amounts to a modeset, so better to take all required
      locks for that.
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      8bb4da1d
    • Daniel Vetter's avatar
      drm: Check locking in drm_for_each_fb · 4676ba0b
      Daniel Vetter authored
      Ever since framebuffers are reference counted we have a special lock
      for the global fb list. Make sure users of that list do hold that
      lock when using the new iterators.
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      4676ba0b
    • Daniel Vetter's avatar
      drm/i915: Use drm_for_each_fb in i915_debugfs.c · 3a58ee10
      Daniel Vetter authored
      Just so I have a user for this macro.
      
      v2: Use the right macro - somehow I thought gcc should scream at me,
      but list_for_each isn't really typesafe unfortunately. Spotted by
      Ville.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      3a58ee10
    • Daniel Vetter's avatar
      drm: Check locking in drm_for_each_connector · 7a3f3d66
      Daniel Vetter authored
      Because of DP MST connectors can now be hotplugged and we must hold
      the right lock when walking the connector lists.  Enforce this by
      checking the locking in our shiny new list walking macros.
      
      v2: Extract the locking check into a small static inline helper to
      help readability. This will be more important when we make the
      read list access rules more complicated in later patches. Inspired by
      comments from Chris. Unfortunately, due to header loops around the
      definition of struct drm_device the function interface is a bit funny.
      
      v3: Encoders aren't hotadded/removed. For each dp mst encoder we
      statically create one fake encoder per pipe so that we can support as
      many mst sinks as the hw can (Dave).
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Dave Airlie <airlied@redhat.com>
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      7a3f3d66
    • Daniel Vetter's avatar
      drm/fbdev-helper: Grab mode_config.mutex in drm_fb_helper_single_add_all_connectors · 169faeca
      Daniel Vetter authored
      This is now truly only duct-tape to keep locking checks happy since
      calling this function when hpd or polling are already enabled is a
      bug. The fbdev helper can't cope with hotplug changes yet at this
      point, only after that.
      
      Otoh a bit more robustness in this function can't hurt, and with this
      fbdev can actually cope with hotplug changes. And it's also more
      consistent with the connector hotadd/remove dp mst needs to do.
      Therefore document this as new official behavior.
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      169faeca
    • Daniel Vetter's avatar
      drm/probe-helper: Grab mode_config.mutex in poll_init/enable · 8c4ccc4a
      Daniel Vetter authored
      So on first looks this seems superflous since drivers should ensure
      correct ordering to not make this a problem. Otoh ordering constraints
      between hdp, fbdev load and enabling polling are already tricky on
      some hardware and it helps to be more robust.
      
      But the real goal is to just shut up a locking WARN_ON I'd like to
      add, which means init code gets some additional locks just for
      uniformity.
      
      v2: Also grab the lock for the public poll_enable, not just poll_init
      which is used for resume, with the same justification.
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      8c4ccc4a
    • Daniel Vetter's avatar
      drm: Add modeset object iterators · 6295d607
      Daniel Vetter authored
      And roll them out across drm_* files. The point here isn't code
      prettification (it helps with that too) but that some of these lists
      aren't static any more. And having macros will gives us a convenient
      place to put locking checks into.
      
      I didn't add an iterator for props since that's only used by a
      list_for_each_entry_safe in the driver teardown code.
      
      Search&replace was done with the below cocci spatch. Note that there's
      a bunch more places that didn't match and which would need some manual
      changes, but I've intentially left these out for this mostly automated
      patch.
      
      iterator name drm_for_each_crtc;
      struct drm_crtc *crtc;
      struct drm_device *dev;
      expression head;
      @@
      - list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
      + drm_for_each_crtc (crtc, dev) {
      ...
      }
      
      @@
      iterator name drm_for_each_encoder;
      struct drm_encoder *encoder;
      struct drm_device *dev;
      expression head;
      @@
      - list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
      + drm_for_each_encoder (encoder, dev) {
      ...
      }
      
      @@
      iterator name drm_for_each_fb;
      struct drm_framebuffer *fb;
      struct drm_device *dev;
      expression head;
      @@
      - list_for_each_entry(fb, &dev->mode_config.fb_list, head) {
      + drm_for_each_fb (fb, dev) {
      ...
      }
      
      @@
      iterator name drm_for_each_connector;
      struct drm_connector *connector;
      struct drm_device *dev;
      expression head;
      @@
      - list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
      + drm_for_each_connector (connector, dev) {
      ...
      }
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      6295d607
    • Daniel Vetter's avatar
      drm: Simplify drm_for_each_legacy_plane arguments · 4ea50e99
      Daniel Vetter authored
      No need to pass the planelist when everyone just uses
      dev->mode_config.plane_list anyway.
      
      I want to add a pile more of iterators with unified (obj, dev)
      arguments. This is just prep.
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      4ea50e99
  2. 17 Jul, 2015 4 commits
  3. 15 Jul, 2015 16 commits
  4. 14 Jul, 2015 11 commits