1. 09 Dec, 2014 1 commit
  2. 04 Dec, 2014 2 commits
  3. 03 Dec, 2014 1 commit
  4. 01 Dec, 2014 3 commits
  5. 27 Nov, 2014 7 commits
    • Rob Clark's avatar
      drm/atomic: clear plane's CRTC and FB when shutting down · e5b5341c
      Rob Clark authored
      Otherwise we'd still end up w/ the plane attached to the CRTC, and
      seemingly active, but without an FB.  Which ends up going *boom*
      in the drivers.
      
      Slightly modified version of Daniel's irc suggestion.
      
      Note that the big problem isn't drivers going *boom* here (since we
      already have the situation of planes being left enabled when the crtc
      goes down). The real issue is that the core assumes the primary plane
      always goes down when calling ->set_config with a NULL mode. Ignoring
      that assumption leads to the legacy state pointers plane->fb/crtc
      getting out of sync with atomic, and that then leads to the subsequent
      *boom* all over the place.
      
      CC: Daniel Vetter <daniel@ffwll.ch>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      [danvet: Drop my opinion of what's going sidewides here into the
      commit message as a note.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e5b5341c
    • Daniel Vetter's avatar
      drm: Handle atomic state properly in kms getfoo ioctl · abd69c55
      Daniel Vetter authored
      So the problem with async commit (especially async modeset commit) is
      that the legacy pointers only get updated after the point of no
      return, in the async part of the modeset sequence. At least as
      implemented by the current helper functions. This is done in the
      set_routing_links function in drm_atomic_helper.c.
      
      Which also means that access isn't protected by locks but only
      coordinated by synchronizing with async workers. No problem thus far,
      until we lock at the getconnector/encoder ioctls.
      
      So fix this up by adding special cases for atomic drivers: For those
      we need to look at state objects. Unfortunately digging out the
      correct encoder->crtc link is a bit of work, so wrap this up in a
      helper function.
      
      Moving the assignments of connector->encoder and encoder->crtc earlier
      isn't a good idea because the point of the atomic helpers is that we
      stage the state updates. That way the disable functions can still
      inspect the links and rely upon them.
      
      v2: Extract full encoder->crtc lookup into helper (Rob).
      
      v3: Extract drm_connector_get_encoder too since - we need to always
      return state->best_encoder when there is a state otherwise we might
      return stale data if there's a pending async disable (and chase
      unlocked pointers, too). Same issue with encoder_get_crtc but there
      it's a bit more tricky to handle.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Sean Paul <seanpaul@chromium.org>
      Reviewed-by: default avatarSean Paul <seanpaul@chromium.org>
      Lightly-Tested-by: default avatarSean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      abd69c55
    • Rob Clark's avatar
      drm: use mode_object_find helpers · 933f622f
      Rob Clark authored
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      933f622f
    • Rob Clark's avatar
      drm: fix indentation · 417009fb
      Rob Clark authored
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      417009fb
    • Rob Clark's avatar
      93b02beb
    • Rob Clark's avatar
      drm/atomic: add plane iterator macros · dd275956
      Rob Clark authored
      Add helper macros to iterate the current, or incoming set of planes
      attached to a crtc.  These helpers are only available for drivers
      converted to use atomic-helpers.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      [danvet: Squash in fixup from Rob to move the planemask iterator to
      drm_crtc.h and document it. That one is needed by the atomic ioctl so
      can't be in a helper library.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      dd275956
    • Rob Clark's avatar
      drm/atomic: track bitmask of planes attached to crtc · 6ddd388a
      Rob Clark authored
      Chasing plane->state->crtc of planes that are *not* part of the same
      atomic update is racy, making it incredibly awkward (or impossible) to
      do something simple like iterate over all planes and figure out which
      ones are attached to a crtc.
      
      Solve this by adding a bitmask of currently attached planes in the
      crtc-state.
      
      Note that the transitional helpers do not maintain the plane_mask.  But
      they only support the legacy ioctls, which have sufficient brute-force
      locking around plane updates that they can continue to loop over all
      planes to see what is attached to a crtc the old way.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      [danvet:
      - Drop comments about locking in set_crtc_for_plane since they're a
        bit misleading - we already should hold lock for the current crtc.
      - Also WARN_ON if get_state on the old crtc fails since that should
        have been done already.
      - Squash in fixup to check get_plane_state return value, reported by
        Dan Carpenter and acked by Rob Clark.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6ddd388a
  6. 25 Nov, 2014 10 commits
  7. 21 Nov, 2014 16 commits
    • Rob Clark's avatar
      drm/atomic: shutdown *current* encoder · 46df9adb
      Rob Clark authored
      In disable_outputs() we need to shut down the outgoing encoder, not the
      incoming one (we have already swapped-state at this point).  Without
      this, we end up telling the driver to crtc->dpms(OFF) without first
      encoder->dpms(OFF), and that makes some hw quite unhappy.
      
      v2: missing WARN_ON() hunk and comment
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      46df9adb
    • Rob Clark's avatar
      drm/atomic: check mode_changed *after* atomic_check · 934ce1c2
      Rob Clark authored
      The intention is that drivers can set crtc_state->mode_changed in their
      atomic_check() fxns if they encounter a scenario that requires full
      modeset.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      934ce1c2
    • Rob Clark's avatar
      drm/msm/mdp4: fix mixer setup for multi-crtc + planes · 4dd14fe6
      Rob Clark authored
      On mdp4 there is a single global LAYERMIXER_IN_CFG register.  The
      previous logic to share that between multiple crtcs didn't actually
      handle plane-disable very well.  Easier just to look at all of the
      crtcs each time.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      4dd14fe6
    • Rob Clark's avatar
      drm/msm/mdp5: dpms(OFF) cleanups · d6ac4a84
      Rob Clark authored
      When disabling the interface (INTF), the change doesn't latch until next
      vblank, so we need to wait for vblank.
      
      Also, to be pedantic, in the crtc, set all the mixer stages to unused.
      It shouldn't really matter, since at this point we have already disabled
      the INTF and waited for necessary vblank.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      d6ac4a84
    • Rob Clark's avatar
      drm/msm/mdp5: atomic · ed851963
      Rob Clark authored
      Convert mdp5 over to atomic helpers.  Extend/wrap drm_plane_state to
      track plane zpos and to keep track of the needed when applying the
      atomic update.  In mdp5's plane->atomic_check() we also need to check
      for updates which require SMP reallocation, in order to trigger full
      modeset.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      ed851963
    • Rob Clark's avatar
      drm/msm: atomic fixes · 3e2f29e4
      Rob Clark authored
      Fixes for a couple little issues found in testing.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      3e2f29e4
    • Rob Clark's avatar
      drm/msm/mdp5: remove global mdp5_ctl_mgr · 32c0e3e2
      Rob Clark authored
      A bit cleaner.. and won't resulting in an attempt to kfree() a static
      global in unload path.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      32c0e3e2
    • Rob Clark's avatar
      drm/msm/mdp5: don't use void * for opaque types · 42238da8
      Rob Clark authored
      For example, use 'struct mdp5_smp *' everywhere instead of 'void *', but
      only declare it as 'struct mdp5_smp;' in common headers, so the struct
      body is still private.  The accomplishes the desired modularity while
      still letting the compiler provide some type checking for us.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      42238da8
    • Stephane Viau's avatar
      drm/msm: add multiple CRTC and overlay support · 0deed25b
      Stephane Viau authored
      MDP5 currently support one single CRTC with its private pipe.
      This change allows the configuration of multiple CRTCs with
      the possibility to attach several public planes to these CRTCs.
      Signed-off-by: default avatarStephane Viau <sviau@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      0deed25b
    • Rob Clark's avatar
      drm/msm/mdp5: set rate before enabling clk · ac7a5704
      Rob Clark authored
      Set a "safe" rate at first, in order to read out the hw revision.  And
      then after set the optimal value.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      ac7a5704
    • Stephane Viau's avatar
      drm/msm/mdp5: introduce mdp5_cfg module · 2e362e17
      Stephane Viau authored
      The hardware configuration modification from a version to another
      is quite consequent. Introducing a configuration module
      (mdp5_cfg) may make things more clear and easier to access when a
      new hardware version comes up.
      Signed-off-by: default avatarStephane Viau <sviau@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      2e362e17
    • Stephane Viau's avatar
      drm/msm/mdp5: make SMP module dynamically configurable · bfcdfb0e
      Stephane Viau authored
      The Shared Memory Pool (SMP) has its own limitation, features and
      state. Some examples are:
       - the number of Memory Macro Block (MMB) and their size
       - the number of lines that can be fetched
       - the state of MMB currently allocated
       - the computation of number of blocks required per plane
       - client IDs ...
      
      In order to avoid private data to be overwritten by other modules,
      let's make these private to the SMP module.
      
      Some of these depend on the hardware configuration, let's add them
      to the mdp5_config struct.
      
      In some hw configurations, some MMBs are statically tied to RGB
      pipes and cannot be re-allocated dynamically. This change
      introduces the concept of MMB static usage and makes sure that
      dynamic MMB requests are dimensioned accordingly.
      
      A note on passing a pipe pointer, instead of client IDs:
      Client IDs are SMP-related information. Passing PIPE information
      to SMP lets SMP module to find out which SMP client(s) are used.
      This allows the SMP module to access the PIPE pointer, which can
      be used for FIFO watermark configuration.
      By the way, even though REG_MDP5_PIPE_REQPRIO_FIFO_WM_* registers
      are part of the PIPE registers, their functionality is to reflect
      the behavior of the SMP block. These registers access is now
      restricted to the SMP module.
      Signed-off-by: default avatarStephane Viau <sviau@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      bfcdfb0e
    • Rob Clark's avatar
      drm/msm/hdmi: remove useless kref · d1a717bd
      Rob Clark authored
      A left-over from prior to component framework.  The original intent was
      to deal with hdmi getting unloaded before the master component, but that
      isn't really going to work anyways.  These days with the component
      framework taking care to unload the master component first, we don't
      have to worry about this.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      d1a717bd
    • Stephane Viau's avatar
      drm/msm/mdp5: get the core clock rate from MDP5 config · 3f307963
      Stephane Viau authored
      The core clock rate depends on the hw configuration. Once we have
      read the hardware revision, we can set the core clock to its
      maximum value.
      Before then, the clock is set at a rate supported by all MDP5
      revisions.
      Signed-off-by: default avatarStephane Viau <sviau@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      3f307963
    • Rob Clark's avatar
      drm/msm/mdp5: use irqdomains · f6a8eaca
      Rob Clark authored
      For mdp5, the irqs of hdmi/eDP/dsi0/dsi1 blocks get routed through the
      mdp block.  In order to decouple hdmi/eDP/etc, register an irq domain
      in mdp5.  When hdmi/dsi/etc are used with mdp4, they can directly setup
      their irqs in their DT nodes as normal.  When used with mdp5, instead
      set the mdp device as the interrupt-parent, as in:
      
      	mdp: qcom,mdss_mdp@fd900000 {
      		compatible = "qcom,mdss_mdp";
      		interrupt-controller;
      		#interrupt-cells = <1>;
      		...
      	};
      
      	hdmi: qcom,hdmi_tx@fd922100 {
      		compatible = "qcom,hdmi-tx-8074";
      		interrupt-parent = <&mdp>;
      		interrupts = <8 0>;   /* MDP5_HW_INTR_STATUS.INTR_HDMI */
      		...
      	};
      
      There is a slight awkwardness, in that we cannot disable child irqs
      at the mdp level, they can only be cleared in the child block.  So
      you must not use threaded irq handlers in the child.  I'm not sure
      if there is a better way to deal with that.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      f6a8eaca
    • Dave Airlie's avatar
      Merge branch 'drm-next-3.19' of git://people.freedesktop.org/~agd5f/linux into drm-next · ed1e8777
      Dave Airlie authored
      - More CI dpm fixes
      - Initial DPM fan control for SI/CI (disabled by default)
      - GPUVM multi-ring efficiency improvements
      - Some cursor fixes
      
      * 'drm-next-3.19' of git://people.freedesktop.org/~agd5f/linux: (22 commits)
        drm/radeon: update the VM after setting BO address v4
        drm/radeon: sync PT updates as shared v2
        drm/radeon: sync PD updates as shared
        drm/radeon: fence BO_VAs manually
        drm/radeon: use one VMID for each ring
        drm/radeon: track VM update fences separately
        drm/radeon: fence PT updates manually v2
        drm/radeon: split semaphore and sync object handling v2
        drm/radeon: remove unnecessary VM syncs
        drm/radeon: stop re-reserving the BO in radeon_vm_bo_set_addr
        drm/radeon: rework vm_flush parameters
        drm/radeon/ci: disable needless sclk changes
        drm/radeon/ci: force pcie level before sclk and mclk
        drm/radeon/ci: use different smc command for pcie dpm
        drm/radeon/ci: apply disp voltage changes before clk changes
        drm/radeon: fix PCC debugging message for CI DPM
        drm/radeon/dpm: add thermal dpm support for CI
        drm/radeon/dpm: add smc fan control for CI (v2)
        drm/radeon/dpm: add smc fan control for SI (v2)
        drm/radeon: work around a hw bug in MGCG on CIK
        ...
      ed1e8777