1. 10 Feb, 2017 2 commits
  2. 08 Feb, 2017 7 commits
  3. 07 Feb, 2017 13 commits
  4. 06 Feb, 2017 18 commits
    • Dan Carpenter's avatar
      drm/msm: return -EFAULT if copy_from_user() fails · 21c42da1
      Dan Carpenter authored
      copy_from_user_inatomic() is actually a local function that returns
      -EFAULT or positive values on error.  Otherwise copy_from_user() returns
      the number of bytes remaining to be copied.  We want to return -EFAULT
      here.
      
      I removed an unlikely() because we just did a copy_from_user()
      so I don't think it can possibly make a difference.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      21c42da1
    • Archit Taneja's avatar
      drm/msm/dsi: Add PHY/PLL for 8x96 · f079f6d9
      Archit Taneja authored
      Extend the DSI PHY/PLL drivers to support the DSI 14nm PHY/PLL
      found on 8x96.
      
      These are picked up from the downstream driver. The PHY part is similar
      to the other DSI PHYs. The PLL driver requires some trickery so that
      one DSI PLL can drive both the DSIs (i.e, dual DSI mode).
      
      In the case of dual DSI mode. One DSI instance becomes the clock master,
      and other the clock slave. The master PLL's output (Byte and Pixel clock)
      is fed to both the DSI hosts/PHYs.
      
      When the DSIs are configured in dual DSI mode, the PHY driver communicates
      to the PLL driver using msm_dsi_pll_set_usecase() which instance is the
      master and which one is the slave. When setting rate, the master PLL also
      configures some of the slave PLL/PHY registers which need to be identical
      to the master's for correct dual DSI behaviour.
      
      There are 2 PLL post dividers that should have ideally been modelled as
      generic clk_divider clocks, but require some customization for dual DSI.
      In particular, when the master PLL's post-diviers are set, the slave PLL's
      post-dividers need to be set too. The clk_ops for these use clk_divider's
      helper ops and flags internally to prevent redundant code.
      
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      f079f6d9
    • Hai Li's avatar
      drm/msm/dsi: Add new method to calculate 14nm PHY timings · a4df68fa
      Hai Li authored
      The 14nm DSI PHY on 8x96 (called PHY v2 downstream) requires a different
      set of calculations for computing D-PHY timing params. Create a
      timing_calc_v2 func for the newer v2 PHYs.
      Signed-off-by: default avatarHai Li <hali@codeaurora.org>
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      a4df68fa
    • Hai Li's avatar
      drm/msm/dsi: Move PHY operations out of host · b62aa70a
      Hai Li authored
      Since DSI PHY has been a separate platform device, it should not
      depend on the resources in host to be functional. This change is
      to trigger PHY operations in manager, instead of host, so that
      host and PHY can be completely separated.
      Signed-off-by: default avatarHai Li <hali@codeaurora.org>
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      b62aa70a
    • Archit Taneja's avatar
      drm/msm/dsi: Reset both PHYs before clock operation for dual DSI · 34d9545b
      Archit Taneja authored
      In case of dual DSI, some registers in PHY1 have been programmed
      during PLL0 clock's set_rate. The PHY1 reset called by host1 later
      will silently reset those PHY1 registers. This change is to reset
      and enable both PHYs before any PLL clock operation.
      
      [Originally worked on by Hai Li <hali@codeaurora.org>. Fixed up
      by Archit Taneja <architt@codeaurora.org>]
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      34d9545b
    • Hai Li's avatar
      drm/msm/dsi: Pass down use case to PHY · 57bf4338
      Hai Li authored
      For some new types of DSI PHY, more settings depend on
      use cases controlled by DSI manager. This change allows
      DSI manager to setup PHY with a use case.
      Signed-off-by: default avatarHai Li <hali@codeaurora.org>
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      57bf4338
    • Hai Li's avatar
      drm/msm/dsi: Return more timings from PHY to host · dceac340
      Hai Li authored
      The DSI host is required to configure more timings calculated
      in PHY. By introducing a shared structure, this change allows
      more timing information passed from PHY to host.
      Signed-off-by: default avatarHai Li <hali@codeaurora.org>
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      dceac340
    • Archit Taneja's avatar
      drm/msm/dsi: Add a PHY op that initializes version specific stuff · 25c45d89
      Archit Taneja authored
      Create an init() op for dsi_phy which sets up things specific to
      a given DSI PHY.
      
      The dsi_phy driver probe expects every DSI version to get a
      "dsi_phy_regulator" mmio base. This isn't the case for 8x96.
      Creating an init() op will allow us to accommodate such
      differences.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      25c45d89
    • Archit Taneja's avatar
      drm/msm/dsi: Add 8x96 info in dsi_cfg · 3a3ff88a
      Archit Taneja authored
      Add 8x96 DSI data in dsi_cfg. The downstream kernel's dsi_host driver
      enables core_mmss_clk. We're seeing some branch clock warnings on
      8x96 when enabling this. There doesn't seem to be any negative effect
      with not enabling this clock, so use it once we figure out why we
      get the warnings.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      3a3ff88a
    • Archit Taneja's avatar
      drm/msm/dsi: Don't error if a DSI host doesn't have a device connected · a1b1a4f7
      Archit Taneja authored
      The driver returns an error if a DSI DT node is populated, but no device
      is connected to it or if the data-lane map isn't present. Ideally, such
      a DSI node shouldn't be probed at all (i.e, its status should be set to
      "disabled in DT"), but there isn't any harm in registering the DSI device
      even if it doesn't have a bridge/panel connected to it.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      a1b1a4f7
    • Archit Taneja's avatar
      drm/msm/mdp5: Add support for legacy cursor updates · 10967a06
      Archit Taneja authored
      This code has been more or less picked up from the vc4 and intel
      implementations of update_plane() funcs for cursor planes.
      
      The update_plane() func is usually the drm_atomic_helper_update_plane
      func that will issue an atomic commit with the plane updates. Such
      commits are not intended to be done faster than the vsync rate.
      
      The legacy cursor userspace API, on the other hand, expects the kernel
      to handle cursor updates immediately.
      
      Create a fast path in update_plane, which updates the cursor registers
      and flushes the configuration. The fast path is taken when there is only
      a change in the cursor's position in the crtc, or a change in the
      cursor's crop co-ordinates. For anything else, we go via the slow path.
      
      We take the slow path even when the fb changes, and when there is
      currently no fb tied to the plane. This should hopefully ensure that we
      always take a slow path for every new fb. This in turn should ensure that
      the fb is pinned/prepared.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      10967a06
    • Archit Taneja's avatar
      drm/msm/mdp5: Refactor mdp5_plane_atomic_check · 9142364e
      Archit Taneja authored
      In mdp5_plane_atomic_check, we get crtc_state from drm_plane_state.
      
      Later, for cursor planes, we'll populate the update_plane() func that
      takes a fast asynchronous path to implement cursor movements. There, we
      would need to call a similar atomic_check func to validate the plane
      state, but crtc_state would need to be derived differently.
      
      Refactor mdp5_plane_atomic_check to mdp5_plane_atomic_check_with_state
      such that the latter takes crtc_state as an argument.
      
      This is similar to what the intel driver has done for async cursor
      updates.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      9142364e
    • Archit Taneja's avatar
      drm/msm/mdp5: Add cursor planes · bff8fba4
      Archit Taneja authored
      Register cursor drm_planes. The loop in modeset_init that inits the
      planes and crtcs has to be refactored a bit. We first iterate all the
      hwpipes to find the cursor planes. Then, we loop again to create
      crtcs.
      
      In msm_atomic_wait_for_commit_done, remove the check which bypasses
      waiting for vsyncs if state->legacy_cursor_updates is true.
      
      We will later create a fast path for cursor position changes in the
      cursor plane's update_plane func that doesn't go via the regular
      atomic commit path. For rest of cursor related updates, we will have
      to wait for vsyncs, so ignore the legacy_cursor_updates flag.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      bff8fba4
    • Archit Taneja's avatar
      drm/msm/mdp5: Misc cursor plane bits · 5798c8e0
      Archit Taneja authored
      These are various changes added in preparation for cursor planes:
      
      - Add a pipe_cursor block for 8x96 in mdp5_cfg.
      - Add a new pipe CAP called MDP_PIPE_CAP_CURSOR. Use this to ensure we
        assign a cursor SSPP for a drm_plane with type DRM_PLANE_TYPE_CURSOR.
      - Update mdp5_ctl_blend_mask/ext_blend_mask funcs to incorporate cursor
        SSPPs.
      - In mdp5_ctl_blend, iterate through MAX_STAGES instead of stage_cnt,
        we need to do this because we can now have empty stages in between.
      - In mdp5_crtc_atomic_check, make sure that the cursor plane has the
        highest zorder, and stage the cursor plane to the maximum stage #
        present on the HW.
      - Create drm_crtc_funcs that doesn't try to implement cursors using the
        older LM cursor HW.
      - Pass drm_plane_type in mdp5_plane_init instead of a bool telling
        whether plane is primary or not.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      5798c8e0
    • Archit Taneja's avatar
      drm/msm/mdp5: Configure COLOR3_OUT propagation · 829200ac
      Archit Taneja authored
      In MDP5 Layer Mixer HW, the blender output is only the blended color
      components (i.e R, G and B, or COLOR0/1/2 in MDP5 HW terminology). This
      is fed to the BG input of the next blender. We also need to provide an
      alpha (COLOR3) value for the BG input at the next stage.
      
      This is configured via using the REG_MDP5_LM_BLEND_COLOR_OUT register.
      For each stage, we can propagate either the BG or FG alpha to the next
      stage.
      
      The approach taken by the driver is to propagate FG alpha, if the plane
      staged on that blender has an alpha. If it doesn't, we try to propagate
      the base layer's alpha.
      
      This is borrowed from downstream MDP5 kernel driver. Without this, we
      don't see any cursor plane content.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      829200ac
    • Archit Taneja's avatar
      drm/msm/mdp5: Use plane helpers to configure src/dst rectangles · 3b6acf14
      Archit Taneja authored
      The MDP5 plane's atomic_check ops doesn't perform clipping tests.
      This didn't hurt us much in the past, but clipping becomes important
      with cursor planes.
      
      Use drm_plane_helper_check_state, the way rockchip/intel/mtk drivers
      already do. Use these drivers as reference.
      
      Clipping requires knowledge of the crtc width and height. This requires
      us to call drm_atomic_helper_check_modeset before
      drm_atomic_helper_check_planes in the driver's atomic_check op, because
      check_modetest will populate the mode for the crtc, needed to populate
      the clip rectangle.
      
      We update the plane_enabled(state) local helper to use state->visible,
      since state->visible and 'state->fb && state->crtc' represent the same
      thing.
      
      One issue with the existing code is that we don't have a way to disable
      the plane when it's completely clipped out. Until there isn't an update
      on the crtc (which would de-stage the plane), we would still see the
      plane in its last 'visible' configuration.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      3b6acf14
    • Archit Taneja's avatar
      drm/msm/mdp5: Prepare CRTC/LM for empty stages · 106f9727
      Archit Taneja authored
      Use SSPP_NONE in mdp5_plane_pipe() if there is now hwpipe allocated for
      the drm_plane. Returning '0' means we are returning VIG0 pipe.
      
      Also, use the mdp5_pipe enum to pass around the stage array. Initialize
      the stage to SSPP_NONE by default.
      
      We do the above because 1) Cursor plane has to be staged at the topmost
      blender of the LM, which can result in empty stages in between 2) In
      the future, when we support multiple LMs per CRTC. We could have stages
      which don't have any pipe assigned to them.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      106f9727
    • Archit Taneja's avatar
      drm/msm/mdp5: Create only as many CRTCs as we need · e5366ffe
      Archit Taneja authored
      We currently create CRTCs equaling to the # of Layer Mixer blocks we
      have on the MDP5 HW. This number is generally more than the # of encoders
      (INTFs) we have in the MDSS HW. The number of encoders connected to
      displays on the platform (as described by DT) would be even lesser.
      
      Create only N drm_crtcs, where N is the number of drm_encoders
      successfully registered. To do this, we call modeset_init_intf() before
      we init the drm_crtcs and drm_planes.
      
      Because of this change, setting encoder->possible_crtcs needs to be moved
      from construct_encoder() to a later point when we know how many CRTCs we
      have.
      Signed-off-by: default avatarArchit Taneja <architt@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      e5366ffe