1. 05 Jun, 2014 28 commits
  2. 04 Jun, 2014 12 commits
    • Rob Clark's avatar
      drm: convert crtc and connection_mutex to ww_mutex (v5) · 51fd371b
      Rob Clark authored
      For atomic, it will be quite necessary to not need to care so much
      about locking order.  And 'state' gives us a convenient place to stash a
      ww_ctx for any sort of update that needs to grab multiple crtc locks.
      
      Because we will want to eventually make locking even more fine grained
      (giving locks to planes, connectors, etc), split out drm_modeset_lock
      and drm_modeset_acquire_ctx to track acquired locks.
      
      Atomic will use this to keep track of which locks have been acquired
      in a transaction.
      
      v1: original
      v2: remove a few things not needed until atomic, for now
      v3: update for v3 of connection_mutex patch..
      v4: squash in docbook
      v5: doc tweaks/fixes
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      51fd371b
    • Dave Airlie's avatar
      drm/dp: add a hw mutex around the transfer functions. (v2) · 4f71d0cb
      Dave Airlie authored
      This should avoid races between connector probing and HPD
      irqs in the future, currently mode_config.mutex blocks this
      possibility.
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      4f71d0cb
    • Dave Airlie's avatar
      Merge tag 'topic/core-stuff-2014-06-02' of git://anongit.freedesktop.org/drm-intel into drm-next · 885ae1c5
      Dave Airlie authored
      Just flushing out my pile of random drm patches for the merge window,
      nothing big. And it all hung around in drm-intel trees for a while (only
      just rebased now).
      
      * tag 'topic/core-stuff-2014-06-02' of git://anongit.freedesktop.org/drm-intel:
        imx-drm: imx-tve: remove unused variable
        drm: Missed clflushopt in drm_clflush_virt_range
        drm/plane: Fix a couple of checkpatch warnings
        drm/plane: Fix sparse warnings
        drm/exynos: Fix double locks at PM resume
        drm/ast: Fix double lock at PM resume
        drm/dp-helper: Deprecate old i2c-over-dp_aux heleprs
      885ae1c5
    • Dave Airlie's avatar
      Merge branch 'exynos-drm-next' of... · b33a51e4
      Dave Airlie authored
      Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
      
      Summary:
      - Resolve probe order and deferred probe issue with component framework
        support.
      - Resolve hdmi dt broken issue.
        . HDMI DT support, which was broken since CCF (common clock framework)
          support, and considring legacy dt binding.
      - Consolidate HDMI part.
        . APB based phy support for Exynos5420 and later, and fixups related
          to power on/off sequence.
      - Consolidate IPP part.
        . Mostly bug fixups and code cleanups.
      - Trivial fixups and code cleanups.
      
      * 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: (64 commits)
        drm/exynos: consider deferred probe case
        drm/exynos: remove unnecessary exynos_hdmi.h file
        drm/exynos/fimd: allow multiplatform configuration
        drm/exynos: add hdmiphy power on/off sequence
        drm/exynos: ipp: remove description of non-existing field
        drm/exynos: ipp: update comment for struct drm_ipp_buf_info
        drm/exynos: ipp: rearrange c_node->event_lock using routine
        drm/exynos: ipp: rearrange c_node->mem_lock using routines
        drm/exynos: ipp: add ipp_remove_id()
        drm/exynos: ipp: add cmd_lock for cmd_list
        drm/exynos: ipp: rename cmd_lock to lock
        drm/exynos: ipp: remove duplicated setting
        drm/exynos: ipp: remove usless list_empty() functions
        drm/exynos: Use PTR_ERR_OR_ZERO in exynos_dp_core.c
        drm/exynos: remove hardware overlays disable from fimd probe
        drm/exynos: Fix checkpatch warning in exynos_dp_reg.c
        drm/exynos: add fimd dependency to fimd related encoders
        drm/exynos: remove redundant mutex_unlock
        drm/exynos/fimc: simplify and rename fimc_dst_get_buf_seq
        drm/exynos/fimc: replace mutex by spinlock
        ...
      b33a51e4
    • Dave Airlie's avatar
      Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next · 1c404d88
      Dave Airlie authored
      Pretty small pull this time around for msm.  Adds some useful debugfs
      I'd been carrying around on a branch for a while, plus few fixes.  And
      Kconfig update for the great ARCH_MSM -> ARCH_QCOM split.
      
      * 'msm-next' of git://people.freedesktop.org/~robclark/linux:
        drm/msm: use correct gfp flag for vram allocation
        drm/msm/mdp5: fix error return value
        drm/msm: remove redundant private plane cleanup
        drm/msm: add perf logging debugfs
        drm/msm: add rd logging debugfs
        drm/msm: update for ARCH_MSM -> ARCH_QCOM
        drm/msm/hdmi: use gpio and HPD polling
        drm/msm/mdp5: fix crash in error/unload paths
      1c404d88
    • Daniel Vetter's avatar
      drm: Move plane helpers into drm_kms_helper.ko · 04381b98
      Daniel Vetter authored
      The drm core shouldn't depend upon any helpers, and we make sure this
      doesn't accidentally happen by moving them into the helper-only
      drm_kms_helper.ko module.
      
      v2: Don't break the build for vmwgfx, spotted by Matt.
      
      v3: Unbreak the depency loop around CONFIG_FB (not actually a loop
      since it involves select). Reported by Chris.
      
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Thomas Hellstrom <thellstrom@vmware.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      04381b98
    • Daniel Vetter's avatar
      drm: Split connection_mutex out of mode_config.mutex (v3) · 6e9f798d
      Daniel Vetter authored
      After the split-out of crtc locks from the big mode_config.mutex
      there's still two major areas it protects:
      - Various connector probe states, like connector->status, EDID
        properties, probed mode lists and similar information.
      - The links from connector->encoder and encoder->crtc and other
        modeset-relevant connector state (e.g. properties which control the
        panel fitter).
      
      The later is used by modeset operations. But they don't really care
      about the former since it's allowed to e.g. enable a disconnected VGA
      output or with a mode not in the probed list.
      
      Thus far this hasn't been a problem, but for the atomic modeset
      conversion Rob Clark needs to convert all modeset relevant locks into
      w/w locks. This is required because the order of acquisition is
      determined by how userspace supplies the atomic modeset data. This has
      run into troubles in the detect path since the i915 load detect code
      needs _both_ protections offered by the mode_config.mutex: It updates
      probe state and it needs to change the modeset configuration to enable
      the temporary load detect pipe.
      
      The big deal here is that for the probe/detect users of this lock a
      plain mutex fits best, but for atomic modesets we really want a w/w
      mutex. To fix this lets split out a new connection_mutex lock for the
      modeset relevant parts.
      
      For simplicity I've decided to only add one additional lock for all
      connector/encoder links and modeset configuration states. We have
      piles of different modeset objects in addition to those (like bridges
      or panels), so adding per-object locks would be much more effort.
      
      Also, we're guaranteed (at least for now) to do a full modeset if we
      need to acquire this lock. Which means that fine-grained locking is
      fairly irrelevant compared to the amount of time the full modeset will
      take.
      
      I've done a full audit, and there's just a few things that justify
      special focus:
      - Locking in drm_sysfs.c is almost completely absent. We should
        sprinkle mode_config.connection_mutex over this file a bit, but
        since it already lacks mode_config.mutex this patch wont make the
        situation any worse. This is material for a follow-up patch.
      
      - omap has a omap_framebuffer_flush function which walks the
        connector->encoder->crtc links and is called from many contexts.
        Some look like they don't acquire mode_config.mutex, so this is
        already racy. Again fixing this is material for a separate patch.
      
      - The radeon hot_plug function to retrain DP links looks at
        connector->dpms. Currently this happens without any locking, so is
        already racy. I think radeon_hotplug_work_func should gain
        mutex_lock/unlock calls for the mode_config.connection_mutex.
      
      - Same applies to i915's intel_dp_hot_plug. But again, this is already
        racy.
      
      - i915 load_detect code needs to acquire this lock. Which means the
        w/w dance due to Rob's work will be nicely contained to _just_ this
        function.
      
      I've added fixme comments everywhere where it looks suspicious but in
      the sysfs code. After a quick irc discussion with Dave Airlie it
      sounds like the lack of locking in there is due to sysfs cleanup fun
      at module unload.
      
      v1: original (only compile tested)
      
      v2: missing mutex_init(), etc (from Rob Clark)
      
      v3: i915 needs more care in the conversion:
      - Protect the edp pp logic with the connection_mutex.
      - Use connection_mutex in the backlight code due to
        get_pipe_from_connector.
      - Use drm_modeset_lock_all in suspend/resume paths.
      - Update lock checks in the overlay code.
      
      Cc: Alex Deucher <alexdeucher@gmail.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarRob Clark <robdclark@gmail.com>
      6e9f798d
    • Rob Clark's avatar
      drm: spiff out FB refcnting traces · 8291272a
      Rob Clark authored
      I find myself making this change locally whenever debugging FB reference
      counting.  Which seems a bit silly.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Reviewed-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      8291272a
    • Rob Clark's avatar
      drm: add signed-range property type · ebc44cf3
      Rob Clark authored
      Like range, but values are signed.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Reviewed-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      ebc44cf3
    • Rob Clark's avatar
      drm: add object property type · 98f75de4
      Rob Clark authored
      An object property is an id (idr) for a drm mode object.  This
      will allow a property to be used set/get a framebuffer, CRTC, etc.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      98f75de4
    • Rob Clark's avatar
      drm: add extended property types · 5ea22f24
      Rob Clark authored
      If we continue to use bitmask for type, we will quickly run out of room
      to add new types.  Split this up so existing part of bitmask range
      continues to function as before, but reserve a chunk of the remaining
      space for an integer type-id.  Wrap this all up in some type-check
      helpers to keep the backwards-compat uglyness contained.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5ea22f24
    • Rob Clark's avatar
      drm: helpers to find mode objects · a2b34e22
      Rob Clark authored
      Add a few more useful helpers to find mode objects.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a2b34e22